Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp718390ioo; Sat, 21 May 2022 11:57:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiNq5m8fXdqThA7NWi7S4X0Dt5LPGZOj67D/wT+x9GxZa5xnSrVpfboqxvWsiYwNm+uUXr X-Received: by 2002:a63:570a:0:b0:3f6:2e7c:4b58 with SMTP id l10-20020a63570a000000b003f62e7c4b58mr13149914pgb.249.1653159433565; Sat, 21 May 2022 11:57:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653159433; cv=none; d=google.com; s=arc-20160816; b=idQQcyL/Zn7kTzHn19xS1l/Qvm0zwTqxC0CP1kQXfhZFDTmIpMxZS/Ky5h7mfFEGo9 OPXy0X4mI1ePEkycmjNs9IEsxKjlBFzxegyeSfcXWigRx8nL3sqc5QOdoba2VRSi60Rh 4TxsLfK2iJseQP2WeHppl2hmjF58q38OkoqUDNAcvW1+0jAgrk491mMFVcH0UIbFqR3e 3piATQiCtiJGFkW48z/AwbG/9eACP4g/1RpFte+PprPj09witoOp/LqH7EIbFUKQ5mnX ahZJldzUVsAxc1em4O+pjZBACDjAyKGfL+VrZXlikT7t9CdUqnQ9gY3lXzt30+nmI9Zj f2jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=fqrIHZwAoXe6uJjNuXerIxi6smgZP2vObgQJrTdLlBw=; b=qZfS3UdHdNNNwt4lDX0aD4f81mmY9V7h8MOJJGRzkuTMNIB4y4kjN+5aJIfBhrTRW+ Mo0DO2fpr1Ao1lcWE8rp4vY8k6VJwUGkt/D008tOOlWZCrM574OAZDhEnFSraQaOoyIS P2tEzOKeFxUJegxkp/kCMPRgcyRcicfEo03USsbVBE7qvpM7gVuJNDQ58kir31VlWiJm kjQzyy8Ld1S9zl1FjEeZyI1fYoo6VKCgdWR96LxTwZVQzoi7LchWRokjKkFjLttC0GY9 FvWhYMWogCA/XeK/eAObjxf/3gbHe0Im1+3nJtMvtrcW9XjuEzFUlOBatzESPMozgkpv zMRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=iJWmZerX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c13-20020a62e80d000000b0050aaf7a1bbcsi7659217pfi.37.2022.05.21.11.57.01; Sat, 21 May 2022 11:57:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=iJWmZerX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241107AbiESRpg (ORCPT + 99 others); Thu, 19 May 2022 13:45:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240091AbiESRpf (ORCPT ); Thu, 19 May 2022 13:45:35 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3341A5012 for ; Thu, 19 May 2022 10:45:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BB10CB8276B for ; Thu, 19 May 2022 17:45:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20601C385AA; Thu, 19 May 2022 17:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1652982331; bh=XTqlTDp8vpzw/d57Gk8js0SUxWL/JNoh0jjWesaOhhc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iJWmZerXyVB+ZXw70rsMHe+AOM4sC3xMYx2HodoCNnUVPYpzjyCQ1yiqWPbP4adW5 katOidFEtGfejhIz8Vvy7F/6kgSbBomwmb7TKxb6fGWg7m0/csITw7UkKagWHlDuVo pLRE+whzhcFyEebRO5jCgzSx5oMSJ1O/zVLn/eus= Date: Thu, 19 May 2022 19:45:27 +0200 From: Greg Kroah-Hartman To: Chris Down Cc: linux-kernel@vger.kernel.org, Petr Mladek , kernel-team@fb.com Subject: Re: [RFC PATCH] printk: console: Allow each console to have its own loglevel Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2022 at 04:55:08PM +0100, Chris Down wrote: > Greg Kroah-Hartman writes: > > On Thu, May 19, 2022 at 04:08:04PM +0100, Chris Down wrote: > > > Greg Kroah-Hartman writes: > > > > > struct console { > > > > > char name[16]; > > > > > void (*write)(struct console *, const char *, unsigned); > > > > > @@ -179,9 +173,11 @@ struct console { > > > > > void *data; > > > > > struct console *next; > > > > > int level; > > > > > - struct device classdev; > > > > > + struct device *classdev; > > > > > > > > Ick, no, keep the real structure here. It can properly handle the > > > > reference counting for the object. Just correctly clean up in the > > > > release function, not anywhere else. > > > > > > Sorry, I'm getting more and more confused about what you're asking me to do, > > > and less and less clear on the rationale. > > > > > > Can you please clarify what "correctly cleaning up" would mean for a > > > non-pointer `struct device'? > > > > > > Is your concern that... > > > > > > register_console(c) > > > device_initialize(c->d) > > > device_add(c->d) > > > unregister_console(c) > > > device_unregister(c->d) console_classdev_release(c->d) > > > register_console(c) > > > device_initialize(c->d) <-- classdev was not previously zeroed out > > > in console_classdev_release() and bad things may happen > > > > Note, you can not "recycle" a structure in the driver model. So when > > the console is unregistered, it should be freed. When it is registered, > > it should be created. Perhaps that is the confusion here? > > I suspect you're close to the source of the confusion. So your point is that > the `struct console' should be freed when the driver refcount drops to 0 > rather than trying to do it the other way around. Right? When the "device" refcount, not driver. refcounts are for data. > So, just to try to come to a solution, here's the lay of the land as I > understand it. Currently pretty much all consoles are statically defined > (and most of the non-static cases are false positives) > > % git grep 'struct console.*=' -- '*.c' | awk '/static/ { print "static"; } !/static/ { print "non-static" }' | sort | uniq -c > 15 non-static > 105 static ah, ok, then we have a problem, and your change to the struct device being a pointer is correct. That's the problem when you only see a tiny bit of the kernel in a patch, sorry for the confusion. But you still need to free the device structure that is pointed to by the device in the release function. Your release function can not be "empty" like your original patch was. thanks, greg k-h