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=-8.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 D1749C433DB for ; Tue, 9 Feb 2021 05:27:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A65964D73 for ; Tue, 9 Feb 2021 05:27:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A65964D73 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 82C0C6B0005; Tue, 9 Feb 2021 00:27:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DAD26B006C; Tue, 9 Feb 2021 00:27:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F0046B006E; Tue, 9 Feb 2021 00:27:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id 5CF606B0005 for ; Tue, 9 Feb 2021 00:27:11 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1DFACA8E1 for ; Tue, 9 Feb 2021 05:27:11 +0000 (UTC) X-FDA: 77797595862.19.cream14_6208d2c27604 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id E96CE1AD7E8 for ; Tue, 9 Feb 2021 05:27:10 +0000 (UTC) X-HE-Tag: cream14_6208d2c27604 X-Filterd-Recvd-Size: 4359 Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 9 Feb 2021 05:27:10 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Mon, 08 Feb 2021 21:27:09 -0800 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Feb 2021 05:27:08 +0000 Received: from MacBook-Pro-10.local (172.20.145.6) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Feb 2021 05:27:08 +0000 Subject: Re: [PATCH v2] mm: cma: support sysfs From: John Hubbard To: Minchan Kim CC: Andrew Morton , linux-mm , LKML , , , , References: <20210208180142.2765456-1-minchan@kernel.org> <43cd6fc4-5bc5-50ec-0252-ffe09afd68ea@nvidia.com> <3cf67381-9b5a-56ee-2a8f-047955c84128@nvidia.com> Message-ID: <6e3bb5a3-9634-6a1b-f2fd-cbbcb6c8ed66@nvidia.com> Date: Mon, 8 Feb 2021 21:27:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <3cf67381-9b5a-56ee-2a8f-047955c84128@nvidia.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To DRHQMAIL107.nvidia.com (10.27.9.16) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1612848429; bh=qh8VL+gYOXWaYImmhix9zNj5sivO32KEAX2o+472W64=; h=Subject:From:To:CC:References:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=I9TyyKrYmOKlqvb5YAsMK5B7xuGirT/raaKBsXyFOWliYoz1TV8rKNZwTmWUrRfHx B+1RBmcx/XI/P+K6LTJeO0iou8jBCg1yPNF9bR9136jR5B6fl0yh/slSAeunN86mSq 3u+GpLHdNtTS36mvo7/tkUz8Uxm2kw5ec4TeCc/N93wljxuem/V9PvHh2dc3EGXbnR JNGtcKnBMSh78znZF9RlE/O9Bo9FSTbR8TC7FBxP42xJ9+WPKYhJ69ueBnjnIE3+ig BF8hgN7hETKPrQvSGM1ulL8k49jZedhsQkudNlK/cknT0UnaDBkDZ7uobp81NzSwP3 CfqvXr4KdrCbg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2/8/21 9:18 PM, John Hubbard wrote: > On 2/8/21 8:19 PM, Minchan Kim wrote: >> On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: >>> On 2/8/21 3:36 PM, Minchan Kim wrote: >>> ... >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 char name[CMA_MAX_NAME]; >>>>>> +#ifdef CONFIG_CMA_SYSFS >>>>>> +=C2=A0=C2=A0=C2=A0 struct cma_stat=C2=A0=C2=A0=C2=A0 *stat; >>>>> >>>>> This should not be a pointer. By making it a pointer, you've added a = bunch of=20 >>>>> pointless >>>>> extra code to the implementation. >>>> >>>> Originally, I went with the object lifetime with struct cma as you >>>> suggested to make code simple. However, Greg KH wanted to have >>>> release for kobj_type since it is consistent with other kboject >>>> handling. >>> >>> Are you talking about the kobj in your new struct cma_stat? That seems >>> like circular logic if so. I'm guessing Greg just wanted kobj methods >>> to be used *if* you are dealing with kobjects. That's a narrower point. >>> >>> I can't imagine that he would have insisted on having additional >>> allocations just so that kobj freeing methods could be used. :) >> >> I have no objection if Greg agree static kobject is okay in this >> case. Greg? >> >=20 > What I meant is, no kobject at all in the struct cma_stat member > variable. The lifetime of the cma_stat member is the same as the > containing struct, so no point in putting a kobject into it. >=20 ...unless...are you actually *wanting* to keep the lifetimes separate? Hmmm, given the short nature of sysfs reads, though, I'd be inclined to just let the parent object own the lifetime. But maybe I'm missing some design point here? thanks, --=20 John Hubbard NVIDIA