Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp739413ioo; Sat, 21 May 2022 12:42:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTMT6bjICIV/bKmuyFJ/Nbc0lg8WoD0taS9FtId4eNW2Q07l+03gMvd8jn0wx/gtuL+kDM X-Received: by 2002:a17:902:e0d3:b0:161:f0c7:b810 with SMTP id e19-20020a170902e0d300b00161f0c7b810mr9545312pla.138.1653162130755; Sat, 21 May 2022 12:42:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653162130; cv=none; d=google.com; s=arc-20160816; b=YODyCV5G7Gp+RvB2w6SPnwyGQcIY3BAsNuTdtUT9lCdGvckh+TkYsL4BcsCOcc6BT4 UsZ1+l8qgTt6Gz7wxWkthQxdp/ybKaUsWzlGNodZwQs7FB60cEhibn4Zt5wquVx9eOK8 IN3fyU9Smya4faENnlpZkTGr7tKH6wGApRig5UYV/yWidhIMpSKDIRRqw/vpbQKh99s9 RODNz0ZYF7GNj7Mhy4h7cxcrN14DBjRad7ANORhwEz8k2symCH1DKH7hUGe/eARQ5fdK gf6Ezm/+G/zc1dVK789SHAEFhBe/hPrsBRmFJef8TX54la5gIa+vN5ntPCqyLQIz/arJ eahQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=2w3QCxHuyZHZWTrIBErbgmf9ZNgUm4m0vFJEtVVQ6So=; b=WCv3tqklu/eZvVGEPQcZdU9e/tl60b0J0G3ZT8XHqy2NmII+23bHs8vTA74omUt3X/ AibeoLEDnqBubcPMPN/+f3mpN9OmDMljATzdZr5r0NBvD4uD0TIRNZU878lSiLkOpdzQ rMa8GX2KaR9R9ENy3e19Rw3WWVYmbO6AKz+hkRPtP/Wya5XfVRNz//N/1KCJppCEdOKS ggLSeXNH/07jzO4yRMAv7LCuaEaSShmwxfRGVglbwvHAMNlA76fFNv9WgFM34W4Cw3zi x6RtP5wDpDyOq8xzAlmonWP21DOHEo+zNw9WQMXo/HOU7M901IlLAQTX8Qw5ZEmMfEt0 Wk8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chrisdown.name header.s=google header.b=L4h1ArFV; 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=chrisdown.name Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j187-20020a638bc4000000b003f5d7f39d37si4236374pge.18.2022.05.21.12.41.58; Sat, 21 May 2022 12:42:10 -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=@chrisdown.name header.s=google header.b=L4h1ArFV; 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=chrisdown.name Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240514AbiESPIw (ORCPT + 99 others); Thu, 19 May 2022 11:08:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240634AbiESPI2 (ORCPT ); Thu, 19 May 2022 11:08:28 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CE18ED726 for ; Thu, 19 May 2022 08:08:08 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id w4so7562676wrg.12 for ; Thu, 19 May 2022 08:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2w3QCxHuyZHZWTrIBErbgmf9ZNgUm4m0vFJEtVVQ6So=; b=L4h1ArFVfv0MGM4j7EKy4nHdFCAxWnLl1wVyU+zrGpShZrQNffuKoOaMSWlYep9Nse Q+zzsTUxyYjiptKsGiFmn6ZC1VhT3n0Pib8DmO252qsfnb+IsZ25yHaGnVoAzr1LZ+gL YEe1hWoqDl4iR6uDmyhg7TP6Vl2TLOgYOBnaw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2w3QCxHuyZHZWTrIBErbgmf9ZNgUm4m0vFJEtVVQ6So=; b=6zu3zOLMS+3l7RlD5op8YmfRgPUMPFJ9ZS50Z6EPuJ8i8Zhah1VcxrH20dkrVNKtTu JHVgYSg+B3Y8QbHBOfPfyHIfonLKld/aQm+AH+HWN07p2UhgAZIiSjN5bH0zKR6WtahT wCv92SAaP5JQM4xJxHORHG/KTIIjWTfHJ4GiTibOAD3DhCgUglCVygerF1jHVhU4yOBc x0GXGBYpVSdoASxhvHEF6Mk3GjdmKoKodUt2wPRZ0HXUQbRuHFGVc+rh2RKyjBmr+lVh 88zhr1Qb3TSfH3u51wpxmAKIgkBGfb5wg89dkddFVe+J0C3lVDlaahQ6Hjm9pKAjcD8n nZ6g== X-Gm-Message-State: AOAM530XgfMXfssU3twas35HifTbQo5oN94wiJjq/3HV2DbZlxNbe1/F nqYlmQnF0o1Gju1M7iy9/ruMAA== X-Received: by 2002:a05:6000:1688:b0:20d:a533:fc5 with SMTP id y8-20020a056000168800b0020da5330fc5mr4442241wrd.338.1652972886591; Thu, 19 May 2022 08:08:06 -0700 (PDT) Received: from localhost ([2620:10d:c092:400::4:c1eb]) by smtp.gmail.com with ESMTPSA id w6-20020a05600c038600b00397335cf750sm1244435wmd.47.2022.05.19.08.08.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 08:08:05 -0700 (PDT) Date: Thu, 19 May 2022 16:08:04 +0100 From: Chris Down To: Greg Kroah-Hartman 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; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.4 (c3baa83e) (2022-04-30) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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 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 If that's not the point, I could really use some clarification about what "correctly cleaning up" means for a non-pointer `struct device' :-)