Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2859117imc; Wed, 13 Mar 2019 03:10:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyxOxzUyYW01sihtPseW+mSaaJJOJIaaz6H5UsFES3aVedK4LBbCvpqQfkqmePXZOjRekqV X-Received: by 2002:a17:902:8ecb:: with SMTP id x11mr43846289plo.40.1552471828171; Wed, 13 Mar 2019 03:10:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552471828; cv=none; d=google.com; s=arc-20160816; b=OAxYvB6gXSZd33GicHc7vRqGLp6etKUrNM/1hhzJ5Odw/J76A04hzbRz4iYRwoa0n6 xlk/ObaFSLvID32WEYIoltOYMyFmYdMBjsEr5AxHxK1JJNeDPbdLUlsuGJZ6vxUyTYdh Y8n/FCkDdJlnAyBRH/pO/01/Iub/G8uBBA76cHtb/TKdgGsjwFJ8F1t7D0F76EgBf/Md Mq+QlCXttrgqPCvLTA4V2yKVUAnupQPCx2XXQ24XeB4zCAZ80CFwxjy3D9oErjo9DERn QgUnTtjjImvueAzPt4Ms2LrLS6P9acmKFuodQIisS0xBnxcU/fIVx5PK26R+Q3zd9ZY+ fuvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=8UxmXkSmLLDJFohtHAi9rdgHNJknB2X2DwcdXf8+TT4=; b=J3aP62JNci7uGhMGdwPJ7sEh33tBLMVcP2wxatpMuLl7BRbdugWhIbLrg4LlH8Qr0U NfAa9U3XazhG81G4j/sdO3daJ9yj4Yc5n6J/InWtqzeRbf7wezpivEA/8+EM2MBdDBeI 8BQf8RfjQEkObCoHF0HIxvcxpMH9hXFNKjbGElGu9l80aD2GU21UaLJIR3qaVZjSdukc odGD6XSDFoUsRG3Hi0uVpNCNs/MD8EUgBop4jKRG4jAOH6MvB8vrJDof0rfZGXka2HXK d4irCSB/pnQ72RYNu5EuOGp3szURDnqYTpZG9VkxxCIAbw1duZSucOmpiWlaEOpsq86i 43Rw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bi12si10357209plb.205.2019.03.13.03.10.11; Wed, 13 Mar 2019 03:10:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726193AbfCMKIb (ORCPT + 99 others); Wed, 13 Mar 2019 06:08:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:51414 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725870AbfCMKIa (ORCPT ); Wed, 13 Mar 2019 06:08:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id B5543B009; Wed, 13 Mar 2019 10:08:28 +0000 (UTC) Date: Wed, 13 Mar 2019 11:08:27 +0100 From: Petr Mladek To: Calvin Owens Cc: Sergey Senozhatsky , Steven Rostedt , Greg Kroah-Hartman , Jonathan Corbet , "linux-kernel@vger.kernel.org" , "linux-serial@vger.kernel.org" Subject: Re: [PATCH 3/4] printk: Add consoles to a virtual "console" bus Message-ID: <20190313100827.oqwoabkgsxfi4zde@pathway.suse.cz> References: <087b13f7812b32cc7c3f9efea71c9bcf324dd031.1551486732.git.calvinowens@fb.com> <20190311133341.vqcagdo4e4vy6dfu@pathway.suse.cz> <20190312215209.GD5982@Haydn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190312215209.GD5982@Haydn> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2019-03-12 21:52:13, Calvin Owens wrote: > On Monday 03/11 at 14:33 +0100, Petr Mladek wrote: > > On Fri 2019-03-01 16:48:19, Calvin Owens wrote: > > > This patch embeds a device struct in the console struct, and registers > > > them on a "console" bus so we can expose attributes in sysfs. > > > > > > Currently, most drivers declare static console structs, and that is > > > incompatible with the dev refcount model. So we end up needing to patch > > > all of the console drivers to: > > > > > > 1. Dynamically allocate the console struct using a new helper > > > 2. Handle the allocation in (1) possibly failing > > > 3. Dispose of (1) with put_device() > > > > > > Early console structures must still be static, since they're required > > > before we're able to allocate memory. The least ugly way I can come up > > > with to handle this is an "is_static" flag in the structure which makes > > > the gets and puts NOPs, and is checked in ->release() to catch mistakes. > > > > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > > index 2e0eb89f046c..67e1e993ab80 100644 > > > --- a/kernel/printk/printk.c > > > +++ b/kernel/printk/printk.c > > > @@ -2706,6 +2770,8 @@ void register_console(struct console *newcon) > > > console_drivers->next = newcon; > > > } > > > > > > + get_console(newcon); > > > + > > > if (newcon->flags & CON_EXTENDED) > > > nr_ext_console_drivers++; > > > > > > @@ -2730,6 +2796,7 @@ void register_console(struct console *newcon) > > > exclusive_console_stop_seq = console_seq; > > > logbuf_unlock_irqrestore(flags); > > > } > > > + console_register_device(newcon); > > > > This calls console_init_device() for the statically defined > > early consoles. I guess that it would invalidate the above > > get_console(). > > The get_console() macro checks for ->is_static and is a NOP if it's > set, which is definitely confusing. > > > Also it is not symmetric with unregister_console(). We add it > > to the console_subsys here and did not remove it when > > the console is unregistered. > > We do a put() in the unregister path, somebody could hold a reference > through sysfs so we can't just remove it. Or am I misunderstanding? To be honest, I am not sure what the effect of get_device() and put_device() is. But they are called also in device_add(). This suggests that the sysfs interface and struct device stay even when we call device_put() in unregister_console(). This is an asymmetry. The sysfs interface is created only for successfully registered console but it stays even after unregistration (if it works as I expect). Another problem is that register_console()/unregister_console() might get called repeatedly for the same console. But device_add() should get called only once. I think that we could do better, see below. > > IMHO, this might be done already in allocate_console(). > > And eventually in printk_late_init() for consoles that > > are allocated earlier. > > > > I am not familiar with the device-related sysfs API. > > But I see that device_initialize() and device_add() > > can be done by device_register(). The separate > > calls are needed only when a special reference > > handling is needed. Are we special? > > We're special: the console initcalls run before the device core is > initialized, initialize() lets us use the refcount. But console_init_device() is called later from printk_late_init() for the statically defined structures (early consoles). This would reset the refcount for these consoles. I think that we should delay calling console_init_device() for all consoles until printk_late_done is set. Then it should be safe to call device_register() there. Best Regards, Petr