From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2228C433DB for ; Wed, 10 Feb 2021 07:26:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 770EC64E45 for ; Wed, 10 Feb 2021 07:26:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 770EC64E45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CC59F6B006C; Wed, 10 Feb 2021 02:26:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C75766B0070; Wed, 10 Feb 2021 02:26:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8B326B0071; Wed, 10 Feb 2021 02:26:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id A04296B006C for ; Wed, 10 Feb 2021 02:26:34 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6B1C51856C054 for ; Wed, 10 Feb 2021 07:26:34 +0000 (UTC) X-FDA: 77801525508.24.flesh03_02157af2760e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 4006D1A4A0 for ; Wed, 10 Feb 2021 07:26:34 +0000 (UTC) X-HE-Tag: flesh03_02157af2760e X-Filterd-Recvd-Size: 3913 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Wed, 10 Feb 2021 07:26:33 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E0EAA64E32; Wed, 10 Feb 2021 07:26:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612941992; bh=h5aoe/jOHYaMcTgcBJi5YW8xNBqHjK9eF+9xhJ40xVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GsNW6pT9hwr9RG3jmzpAYBRsx3142303lE2ZvIVYp3+8LuQiTtI9XajsoA1GmEmBe KG8hmZV7kPGe0Sa8yM15RA4ktjyv6jVz7xRb44yFYSpFq3tuCEfTg4ObxY7Rhnusde rkWNPlMxvfTxMfQaLUXgFhwRdIK/ZKtsRTvFyV5w= Date: Wed, 10 Feb 2021 08:26:28 +0100 From: Greg KH To: John Hubbard Cc: Minchan Kim , Andrew Morton , linux-mm , LKML , surenb@google.com, joaodias@google.com, willy@infradead.org Subject: Re: [PATCH v2] mm: cma: support sysfs Message-ID: References: <7cc229f4-609c-71dd-9361-063ef1bf7c73@nvidia.com> <09e60732-6a46-dd00-f9d5-4ef17ee685c8@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 09, 2021 at 11:16:07PM -0800, John Hubbard wrote: > On 2/9/21 11:12 PM, Minchan Kim wrote: > ... > > > > Agreed. How about this for the warning part? > > > > > > > > + > > > > +/* > > > > + * note: kobj_type should provide a release function to free dynamically > > > > + * allocated object since kobject is responsible for controlling lifespan > > > > + * of the object. However, cma_area is static object so technially, it > > > > + * doesn't need release function. It's very exceptional case so pleaes > > > > + * do not follow this model. > > > > + */ > > > > static struct kobj_type cma_ktype = { > > > > .sysfs_ops = &kobj_sysfs_ops, > > > > .default_groups = cma_groups > > > > + .release = NULL, /* do not follow. See above */ > > > > }; > > > > > > > > > > No, please no. Just do it the correct way, what is the objection to > > > creating a few dynamic kobjects from the heap? How many of these are > > > you going to have that it will somehow be "wasteful"? > > > > > > Please do it properly. > > > > Oh, I misunderstood your word "don't provide a release function for the > > kobject" so thought you agreed on John. If you didn't, we are stuck again: > > IIUC, the objection from John was the cma_stat lifetime should be on parent > > object, which is reasonable and make code simple. > > Frankly speaking, I don't have strong opinion about either approach. > > John? > > > > We should do it as Greg requests, now that it's quite clear that he's insisting > on this. Not a big deal. > > I just am not especially happy about the inability to do natural, efficient > things here, such as use a statically allocated set of things with sysfs. And > I remain convinced that the above is not "improper"; it's a reasonable > step, given the limitations of the current sysfs design. I just wanted to say > that out loud, as my proposal sinks to the bottom of the trench here. haha :) What is "odd" is that you are creating an object in the kernel that you _never_ free. That's not normal at all in the kernel, and so, your wish to have a kobject that you never free represent this object also is not normal :) thanks, greg k-h