Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp257696yba; Fri, 3 May 2019 00:59:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzBF6olV86sh5cjNfc4bnIGnzYT7RcHoW1Z53mJTChZ+Mvoyr64lVXX/H4bNn8o0/FY6auT X-Received: by 2002:a62:414a:: with SMTP id o71mr8038652pfa.240.1556870377188; Fri, 03 May 2019 00:59:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556870377; cv=none; d=google.com; s=arc-20160816; b=JjwxxjiXWfUK2Rm2/HwKAc0fuZqCD84DAZbUbMsFCCgLJyCeNqP+O3R6q4R3bS3gZq 4Ju+a1yrchhuh8F6Am8jxIiMKQmN0qsvgHmo4MDBOnoxqwpqGeZ1KHhVhidTTYShVZs6 PdpkYO1ENunjP7UAPe8I9HMANGmWBMF4KLdlJKS9EMt7BLRcm80dkAB5nf6mviihiG4a lNUoarfPorZcDnHmIuzz0+qzllCctK/u1poOT4Bhbidn5Uvewytvr9ezFbT2ormpDrpL E0+Z/DrgjWd9M4oDwu2LvX63kWEmhySO1xjSNHUkXX2c/9pXp6Zomkb04LqMcEaVTz04 Amww== 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=FTFeDBP5CsqdyQtWWE875arCIwJGJg40/gN9BhZE6B4=; b=gHU+8lP6KBdInGCgMZKzpsLKfIt1zt00wVl7Q5+EDMI+jFm3f9cCbGnivyqK5MPXhX yjGYFgEQkucq9n3zubYOpW3PIByGtsIy1QNwkUXQ+P3ekYurrWHdoGqtuoxk3JEDeD3J AMVV2ZFiDtmd1abksiuOPlroILUzPZd3wQdwn07fbTnkUtsTIrs1TnMLiDkqKoVcGfJ3 30WPDfPCltwr+MRWA2P4Si92xapKLrL97aKHowkOrCIpkrAxoxX6RfwpQLCfQGT/2iK/ QzfG7kv7C0HNf66UxpOQf7gmBnhcV4a3B+7ygq6JUiQzv4r1pIwytghpb9Pj7xAtCE0E +8ZA== 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 98si1561136plb.84.2019.05.03.00.59.22; Fri, 03 May 2019 00:59:37 -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 S1727119AbfECH4b (ORCPT + 99 others); Fri, 3 May 2019 03:56:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:55794 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725777AbfECH4b (ORCPT ); Fri, 3 May 2019 03:56:31 -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 E9BFAAEE3; Fri, 3 May 2019 07:56:28 +0000 (UTC) Date: Fri, 3 May 2019 09:56:28 +0200 From: Petr Mladek To: "Tobin C. Harding" Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Tyrel Datwyler , Andy Shevchenko , Miroslav Benes , Viresh Kumar , Linux Kernel Mailing List Subject: Re: kobject_init_and_add() confusion Message-ID: <20190503075628.kw6h2coyoft2w6o5@pathway.suse.cz> References: <20190430233803.GB10777@eros.localdomain> <20190502083412.dhqw35juhm42wgmk@pathway.suse.cz> <20190503011626.GA7416@eros.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190503011626.GA7416@eros.localdomain> 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 Fri 2019-05-03 11:16:26, Tobin C. Harding wrote: > On Thu, May 02, 2019 at 10:34:12AM +0200, Petr Mladek wrote: > > On Wed 2019-05-01 09:38:03, Tobin C. Harding wrote: > > I guess that we need two examples. I currently understand > > it the following way: > > > > 1. sysfs interface and the structure can be freed anytime: > > > > struct A > > { > > struct kobject kobj; > > ... > > }; > > > > void fn(void) > > { > > struct A *a; > > int ret; > > > > a = kzalloc(sizeof(*a), GFP_KERNEL); > > if (!a) > > return; > > > > /* > > * Initialize structure before we make it accessible via > > * sysfs. > > */ > > ret = some_init_fn(); > > if (ret) { > > goto init_err; > > } > > > > ret = kobject_init_and_add(&a->kobj, ktype, NULL, "foo"); > > if (ret) > > goto kobj_err; > > > > return 0; > > > > kobj_err: > > /* kobject_init() always succeds and take reference. */ > > kobject_put(kobj); > > return ret; > > > > init_err: > > /* kobject was not initialized, simple free is enough */ > > kfree(a); > > return ret; > > } > > > > > > 2. Structure must be registered into the subsystem before > > it can be made visible via sysfs: > > > > struct A > > { > > struct kobject kobj; > > ... > > }; > > > > void fn(void) > > { > > struct A *a; > > int ret; > > > > a = kzalloc(sizeof(*a), GFP_KERNEL); > > if (!a) > > return; > > > > ret = some_init_fn(); > > if (ret) { > > goto init_err; > > } > > > > /* > > * Structure is in a reasonable state and can be freed > > * via the kobject release callback. > > */ > > kobject_init(&a->kobj); > > > > /* > > * Register the structure so that it can cooperate > > * with the rest of the system. > > */ > > ret = register_fn(a); > > ` if (ret) > > goto register_err; > > > > > > /* Make it visible via sysfs */ > > ret = kobject_add(&a->kobj, ktype, NULL, "foo"); > > if (ret) { > > goto kobj_add_err; > > } > > > > /* Manipulate the structure somehow */ > > ret = action_fn(a); > > if (ret) > > goto action_err; > > > > mutex_unlock(&my_mutex); > > return 0; > > > > action_err: > > /* > > * Destroy sysfs interface but the structure > > * is still needed. > > */ > > kobject_del(&a->kboject); > > kobject_add_err: > > /* Make it invisible to the system. */ > > unregister_fn(a); > > register_err: > > /* Release the structure unsing the kobject callback */ > > kobject_put(&a->kobj); > > return; > > > > init_err: > > /* > > * Custom init failed. Kobject release callback would do > > * a double free or so. Simple free is enough. > > */ > > kfree(a); > > } > > > > I would really prefer if we clearly understand where each variant makes > > sense before we start modifying the code and documentation. > > Hi Petr, > > Shall we work these two examples into samples/kobject/. I'm AFK now for > the rest of the week but I can do it on Monday if you don't mind me > doing it? Sounds good to me. The current samples/kobject/kobject-example shows the most simple case when the kobject is standalone. While the above samples shows how to have it bundled in a bigger structure. Thanks, Petr