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 EBEC4C04A95 for ; Tue, 25 Oct 2022 09:13:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71DDB8E0002; Tue, 25 Oct 2022 05:13:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CF278E0001; Tue, 25 Oct 2022 05:13:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 595A28E0002; Tue, 25 Oct 2022 05:13:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 47BFD8E0001 for ; Tue, 25 Oct 2022 05:13:43 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 15B3CAB187 for ; Tue, 25 Oct 2022 09:13:43 +0000 (UTC) X-FDA: 80058909126.01.5E6C0C5 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf29.hostedemail.com (Postfix) with ESMTP id 5E0E6120019 for ; Tue, 25 Oct 2022 09:13:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666689222; x=1698225222; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=4W/ovsSPupI5rLSaIdoBpNhRPZ/toECDmp5MStaycPo=; b=KfYaZ+iLrVua3tiRiO66ln7dzLU8bPJ4PYjThGITvTHMpPthvKGjTFjb HUFyS0ESssnAyq6GEZdimJuNMjDX0on6YU0iXnxBQVcWgVGFT3wxrO0ls MxjnSvVgvipSVGFSDL6TU/hDSKCL65FQmfyjseu0jyCFNEK9lDYSUI0kQ fHLb5Ib41TeQNBSYJbWnISoCdw+pzkXL9a0KCOmqULmfw6tW63qzCR47a bhveNGKTPQDJZOZ4FQGensOTtGTeiu9C6aPi43WTXBjuHSuKZEv6LV4NU 9Fm837v346vQNfMkiW30FBAzHDJBC2zk/yZgcYgrmcNgqGmrvRdJLooYW A==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="334224403" X-IronPort-AV: E=Sophos;i="5.95,211,1661842800"; d="scan'208";a="334224403" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2022 02:13:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="876738255" X-IronPort-AV: E=Sophos;i="5.95,211,1661842800"; d="scan'208";a="876738255" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga006.fm.intel.com with ESMTP; 25 Oct 2022 02:13:38 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1onG08-001uxm-1K; Tue, 25 Oct 2022 12:13:36 +0300 Date: Tue, 25 Oct 2022 12:13:36 +0300 From: Andy Shevchenko To: Petr Mladek Cc: Konrad Rzeszutek Wilk , Jane Chu , rostedt@goodmis.org, senozhatsky@chromium.org, linux@rasmusvillemoes.dk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com, haakon.bugge@oracle.com, john.haxby@oracle.com Subject: Re: [PATCH v3 1/1] vsprintf: protect kernel from panic due to non-canonical pointer dereference Message-ID: References: <20221019194159.2923873-1-jane.chu@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666689222; a=rsa-sha256; cv=none; b=8ZjvXwIkW0XVdesNomCJWV1H0plkkD/62JQXouDX/zgrgNAUHy8x6Dhe+GM8BX0H1Fqk7m f+kTPxMe1P6QjwaiRkL/N7GBiNPdsKa1hdgdBswvt/V+51WxNDAiq0HE2Oy+Ydf6QlFG7O euhjPBEEZ9+aSRcMcfPG7jJUoypfJZo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KfYaZ+iL; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf29.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666689222; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JMWjRO3urAVutNCcaXPjQUxVuveRHKzofoiGegUtrS4=; b=CVL1IUohTpGPUCHUYy+ji57KArOccF9fkLNX+oGvv31E0r+G6tIsf/rsmKb7soBGHuhPXk lPbGNf2UkTD/0l/l8OsnwqFAJ0npIowCE3CtoKz3dTOGnR1aMKfcGB4n6nFyyeqwBmH1Vd FqzECUpayuHM43wVuIynDgsVuOtSJRU= X-Rspamd-Queue-Id: 5E0E6120019 Authentication-Results: imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KfYaZ+iL; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf29.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=andriy.shevchenko@linux.intel.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: yy4zn5p51n868j1boeikpjazfqw8mcop X-HE-Tag: 1666689222-771620 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, Oct 25, 2022 at 10:40:37AM +0200, Petr Mladek wrote: > On Thu 2022-10-20 19:03:23, Andy Shevchenko wrote: > > On Thu, Oct 20, 2022 at 10:52:03AM -0400, Konrad Rzeszutek Wilk wrote: ... > > OK, let's assume user recognizes this as a bug, what should they do in order > > to provide a better description of the bug, so developer can easily debug > > and fix it? > > WARN() would provide similar information as panic() without actually > crashing the kernel. Unless one provides panic_on_warn (or how is it called?). > > > Would we not want that experience for users ? > > > > Yes, if it is a bug in the kernel we want to know it with all possible details. > > Hiding bugs is a way to nowhere. > > I agree but we should always distinguish between fatal problems where > the system could hardly continue working and unexpected behavior that > is not critical. > > Many error code paths handle unexpected situations. Some problems are > caused by users and some by bugs in the code. The kernel could always > refuse doing some operation rather than crash. People will report > it because it does not work. And there are non-destructive ways how > to show useful debugging information. Initially, if I understand correctly, the idea of that check was exactly to guard against special pointers (NULL and error). Now this is getting wider and I'm not sure hiding a crash is good thing to go. Hypothetical situation: the "invalid" pointer is just one that gets LSB shuffled a bit (some of the frameworks use lower bits to keep some information there). That said, kernel is not going to crash elsewhere. How user will know that unmasked pointer went to the printf()? I honestly think that this or similar change will bring more harm than help. -- With Best Regards, Andy Shevchenko