From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751201AbdAPSuV convert rfc822-to-8bit (ORCPT ); Mon, 16 Jan 2017 13:50:21 -0500 Received: from mga07.intel.com ([134.134.136.100]:38974 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750851AbdAPSuT (ORCPT ); Mon, 16 Jan 2017 13:50:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,240,1477983600"; d="scan'208";a="809540622" From: "Odzioba, Lukasz" To: Ingo Molnar , Borislav Petkov CC: "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "luto@kernel.org" , "slaoub@gmail.com" , "bp@suse.de" , "dave.hansen@linux.intel.com" , "Kleen, Andi" Subject: RE: [PATCH 1/1] x86: sanitize argument of clearcpuid command-line option Thread-Topic: [PATCH 1/1] x86: sanitize argument of clearcpuid command-line option Thread-Index: AQHSYRIfgAy+y7BKm0uKvFBWeulAcaEeuGKAgArXx4CAEf2RkA== Date: Mon, 16 Jan 2017 18:50:15 +0000 Message-ID: References: <1482933340-11857-1-git-send-email-lukasz.odzioba@intel.com> <20161229102105.GD11221@nazgul.tnic> <20170105075559.GA2098@gmail.com> In-Reply-To: <20170105075559.GA2098@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjg2ODA0MTAtNTNkMy00MjYzLTk2ODEtZTc4ODMwNTkzY2NjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InRnY1BCZ0poYzVwajA3Rm51d2NUbnVtcWppc2hZVkFWeEdGXC9xa0cyVUJrPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, January 5, 2017 8:56 AM, Ingo Molnar wrote: > > Good one, queued it up. Hi Ingo, thanks for picking up the patch. > When we don't accept the value we should at least inform the user (via a printk > that includes the 'clearcpuid' token in its message) that we totally ignored > whatever he wanted. Something like: > > pr_warn("x86/cpu: Ignoring invalid "clearcpuid=%s' option!\n", arg) > > Which would save quite a bit of head scratching and frustration when someone has a > bad enough day to add silly typos to the kernel cmdline. Is there any particular reason why we have such warnings only for early params? early_param handlers return non-zero values on success: linux/init.h: " * Emits warning if fn returns non-zero." __setup handlers in most cases seem to return 1 on success, is the expected behaviour documented somewhere? After looking at some of the ~500 usages of __setup macro it seems that handler's ret code doesn't matter so much, because it is treated differently in various parts of the kernel. If we make it consistent possibly it could be solved similarly to early params by something like this: diff --git a/init/main.c b/init/main.c index b0c9d6f..261178e 100644 --- a/init/main.c +++ b/init/main.c @@ -182,8 +182,12 @@ static bool __init obsolete_checksetup(char *line) pr_warn("Parameter %s is obsolete, ignored\n", p->str); return true; - } else if (p->setup_func(line + n)) - return true; + } else { + if (p->setup_func(line + n)) + return true; + else + pr_warn("Malformed option '%s'\n", line); + } Thanks, Lukas