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 B814AC433FE for ; Thu, 20 Oct 2022 13:57:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE37D8E0002; Thu, 20 Oct 2022 09:57:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C93B28E0001; Thu, 20 Oct 2022 09:57:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5B058E0002; Thu, 20 Oct 2022 09:57:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A84598E0001 for ; Thu, 20 Oct 2022 09:57:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6E3D9160826 for ; Thu, 20 Oct 2022 13:57:29 +0000 (UTC) X-FDA: 80041480218.22.FB87A90 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf20.hostedemail.com (Postfix) with ESMTP id 812B41C0005 for ; Thu, 20 Oct 2022 13:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666274248; x=1697810248; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6d05uh/PRRPPMALZrbJAbzB3x4DqqbHlYLonr+PPN3o=; b=Ixy8kyobThwBNKMjwnn3QREXNJpicrET6BaWCjMTPAPUBpTbFpbr23SX ZEHIzVFoCXlEW3U7rr9+w40xatWE3rxkUNwdEz/bSe4stXEVI6wtJMx4W 7Yl5H+8IKDfyUYxrUAoJ3DfQHK/oVqRAt/gGMbi27Cn3T5gSKTMB7/N/R cDntvZjlQ7G5ETa4Gvz5OSjeRAeOWXXE/vv6Yno0EQdD+LLprTbafTQSi xXnf7vxY957/ZqbXv9SipSNrYt1sJvnbJcNak5sxyF+t5tiAY46p1QEzj kvtOHS27xT/D+6sHBqwRHLvWIVbiyg3YhmysV41qLA0BSAUgbqWpi/4Ji w==; X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="368758514" X-IronPort-AV: E=Sophos;i="5.95,198,1661842800"; d="scan'208";a="368758514" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 06:57:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="804894448" X-IronPort-AV: E=Sophos;i="5.95,198,1661842800"; d="scan'208";a="804894448" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga005.jf.intel.com with ESMTP; 20 Oct 2022 06:57:24 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1olW30-00AZfH-1s; Thu, 20 Oct 2022 16:57:22 +0300 Date: Thu, 20 Oct 2022 16:57:22 +0300 From: Andy Shevchenko To: Petr Mladek Cc: Jane Chu , "rostedt@goodmis.org" , "senozhatsky@chromium.org" , "linux@rasmusvillemoes.dk" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Haakon Bugge , John Haxby Subject: Re: [PATCH] vsprintf: protect kernel from panic due to non-canonical pointer dereference Message-ID: References: <20221017191611.2577466-1-jane.chu@oracle.com> <5d987403-a7bf-8996-d639-c99edeaabcdf@oracle.com> <799e5390-2ff5-02b7-2df7-61198d5451e2@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=1666274249; a=rsa-sha256; cv=none; b=42Eq91R4K3bD5IWXPYRb5BRApqOdWqnWxC+Tj1hLkR/X0QE0SnfVwxyKWGJst9ebSwfq2z 1P7ZyZZkOqHHxNEi+UuUCisfEGilUf0JaunK6hnC49qUw2d/jbakVf506BBVuySmoaqeWH 56/Xqdg0cYTZa4gMhNgeVxIRDZsj8z0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Ixy8kyob; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf20.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 134.134.136.31) 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=1666274249; 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=Uz1UJ/NC9wfR0OdCarav6JwJGrHxmj8PYkiZdo+ZEsY=; b=3e9QjOnu+YRXJNn2mI/OAKq9iq4HHF0VuYyK73SC2fRxZ6IgQWUAoJH7Rr/OuASR+CQUZD SsuOlQvLPbqkQ7X/W6zumuBwXoc450Z2VUf3768SQZ2ZbD83ezl9oMMTAA/ldd+Mwcd2rL 5TVAJ9D8EKuewwcqP7pwC3XMYfQh6SE= X-Stat-Signature: 61qc9oa18jberh7yojwjf6e3b9sqmtuc X-Rspamd-Queue-Id: 812B41C0005 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Ixy8kyob; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf20.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=andriy.shevchenko@linux.intel.com X-Rspamd-Server: rspam11 X-HE-Tag: 1666274248-272621 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 Thu, Oct 20, 2022 at 09:44:05AM +0200, Petr Mladek wrote: > On Tue 2022-10-18 23:49:27, Andy Shevchenko wrote: > > On Tue, Oct 18, 2022 at 08:30:01PM +0000, Jane Chu wrote: ... > > Obviously, to see the crash. And let kernel _to crash_. Isn't it what we need > > to see a bug as early as possible? > > I do not agree here. Kernel tries to survive many situations when > thighs does not work as expected. It prints a warning so that > users/developers are aware of the problem and could fix it. How the user will know what the root cause and how to fix it? The crash report will give all needed information, the "(eXXXXXX)" will hide it all, which I consider inappropriate approach. I.o.w. consider "(eXXXXXX)" vs. something like "your stuff crashed kernel because of misaligned / etc pointer which has value of 0xXXXXXXXX and other registers have these values" and so on, so on... > In our case, the crash happened when reading a sysfs file. > IMHO, it is much better to show (-EINVAL) than crash. The bug > when accessing devX_attrY[] does not affect the stability of > the system at all. When I got "eXXXXX" from cat /sys/... I think "OK, something went wrong, I shouldn't really take it seriously". And completely different feelings when you got a crash, right? > And the broken string might be passed in a very rare case, > e.g. in an error path. So that it might be hard to catch > when testing. -- With Best Regards, Andy Shevchenko