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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 202C3C433EF for ; Thu, 3 Mar 2022 22:54:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88CAC8D0002; Thu, 3 Mar 2022 17:54:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83C888D0001; Thu, 3 Mar 2022 17:54:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72BC28D0002; Thu, 3 Mar 2022 17:54:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 67D578D0001 for ; Thu, 3 Mar 2022 17:54:10 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2891722341 for ; Thu, 3 Mar 2022 22:54:10 +0000 (UTC) X-FDA: 79204579860.06.CC70EE4 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 642534000F for ; Thu, 3 Mar 2022 22:54:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description; bh=WhlL7h61341iIESeWTlGbuGhMPR1lyzTfnmPlu4dcLQ=; b=SCFq8+cO6okq1ihYq2bG0Y1KNL AdmVymHxeldmywraXF2E/01Df0bz2MzSsQbpLLy4eD7iL2hltsD/4KXshR4FmgEp3vNhjyv9C94n+ r42JfSLPt8b6a+pAo7vx3UajGo1JZi9bpNegCTmSLaXHJJFzsOKU2PqJ5UPSjoYD6tN6gMQA6pXeY Oh2sGCJ8qeT2mpBtzfjfINkRtttkHBXJjHs8xlRMLgQIdNqdqJBQkXpiq42qvedN4f9IDnGLLYFae DlPxT5/h4R9ZA7udADgVmsGtNDtMBGKN84O9S9kKdGfHx+tPuIvBhjrMJ9PX4mMb0a5Lgof8bVfGX ArPe3CUg==; Received: from [2601:1c0:6280:3f0::aa0b] by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPuKi-00C3nL-37; Thu, 03 Mar 2022 22:54:04 +0000 Message-ID: <8c61e14d-493d-ecea-6bc5-076781e8e93d@infradead.org> Date: Thu, 3 Mar 2022 14:53:59 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 1/2] mm/memcontrol: return 1 from cgroup.memory __setup() handler Content-Language: en-US To: =?UTF-8?Q?Michal_Koutn=c3=bd?= Cc: linux-mm@kvack.org, Igor Zhbanov , Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , cgroups@vger.kernel.org References: <20220222005811.10672-1-rdunlap@infradead.org> <20220302185300.GA19699@blackbody.suse.cz> <9f8d4ddb-81ce-738a-d1f7-346ff9bf8ebd@infradead.org> <20220303101406.GE10867@blackbody.suse.cz> <5130da56-0f22-8212-0ea3-6ddb8a8f5455@infradead.org> From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 642534000F X-Stat-Signature: 1ht6eksh16hpexpu4ujo3j5n9o5arwau X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SCFq8+cO; spf=none (imf17.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=rdunlap@infradead.org; dmarc=none X-Rspamd-Server: rspam07 X-HE-Tag: 1646348049-264328 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 3/3/22 14:32, Michal Koutný wrote: > On Thu, Mar 03, 2022 at 01:53:03PM -0800, Randy Dunlap wrote: >>> Isn't mere presence of the handler sufficient to filter those out? [1] >> >> What is [1] here? > > Please ignore, too much editing on my side. > >> I don't know of any case where "foo=2" should be passed to init if >> there is a setup function for "foo=" defined. > > Good. I was asking because of the following semantics: > - absent handler -- pass to init, Ack: if the handler code is not built, it is an Unknown boot option and is passed to init. > - returns 0 -- filter out, > - returns negative -- filter out, print message. Currently setup functions should return 1 (or any non-zero value) to indicate "handled" or should return 0 to indicate "not handled". Andrew has a patch in mmotm: include/linux/init.h so that the comment before __setup() says: /* * NOTE: __setup functions return values: * @fn returns 1 (or non-zero) if the option argument is "handled" * and returns 0 if the option argument is "not handled". */ >>> (Richer reporting or -EINVAL is by my understanding now a different >>> problem.) -- ~Randy