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 06A2FC433EF for ; Fri, 11 Mar 2022 21:23:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85FB98D0002; Fri, 11 Mar 2022 16:23:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80F348D0001; Fri, 11 Mar 2022 16:23:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D6B38D0002; Fri, 11 Mar 2022 16:23:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 5B4278D0001 for ; Fri, 11 Mar 2022 16:23:36 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1ED8D2107B for ; Fri, 11 Mar 2022 21:23:36 +0000 (UTC) X-FDA: 79233382032.14.301CE08 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP id 07A991C0029 for ; Fri, 11 Mar 2022 21:23:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647033815; x=1678569815; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=rCFdGeOoGSRoO6cqnYj1xlhLSbsmex/R1MQnhd4g/08=; b=Ogfcu+wGA+bki1GrHYECKWBRrPMsrtIPwTdhKxnXFNf7cRN88q0wdL2W to5N8TE85wnwWSqwN4rZiE5t9iJDTj8thMcb14tTYpUmjf+7SBgtVzNe2 Jag2WIwZCCEM8MGbzD/MKcAGjlEjk4Ya2+To1vqKqWtJZGvmd6xgRUufd bJ/APflPS1wDbG4fRByM0RUeG8iZfMtXJrZI7Nygnjpkmkz0rKV3mrO5Z bWSWFJdK3IzkARKUfMxq/Co7McirhMWlQk+ozQAGfIkJTspKwF4LlQ7W6 AlnkVcF2jP664+PhVAJBcJDBY8/7AioBod3W0oHJhcRQqaGthopCqXL91 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10283"; a="253218508" X-IronPort-AV: E=Sophos;i="5.90,174,1643702400"; d="scan'208";a="253218508" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 13:23:33 -0800 X-IronPort-AV: E=Sophos;i="5.90,174,1643702400"; d="scan'208";a="645060406" Received: from cpeirce-mobl1.amr.corp.intel.com (HELO [10.212.128.243]) ([10.212.128.243]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 13:23:32 -0800 Message-ID: <103853ef-3afb-bb94-5ffd-8318d1a1d1a0@intel.com> Date: Fri, 11 Mar 2022 13:23:26 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Nadav Amit Cc: Linux-MM , Linux Kernel Mailing List , Andrew Morton , Andrea Arcangeli , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Xu , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , "x86@kernel.org" References: <20220311190749.338281-1-namit@vmware.com> <20220311190749.338281-3-namit@vmware.com> <70e08bd5-187a-daee-2822-1d9a437a9cff@intel.com> From: Dave Hansen Subject: Re: [RESEND PATCH v3 2/5] x86/mm: check exec permissions on fault In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Ogfcu+wG; spf=none (imf18.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 07A991C0029 X-Stat-Signature: zpxkg9xidwhg1d4nheezsbyxjj6uskfe X-HE-Tag: 1647033814-728264 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/11/22 13:16, Nadav Amit wrote: >> This is really about checking the sanity of the "hardware"-provided >> error code. Let's just do it in handle_page_fault(), maybe hidden in a >> function like: >> >> void check_error_code_sanity(unsigned long error_code) >> { >> WARN_ON_ONCE(...); >> } >> >> You can leave the X86_PF_PK check in place for now. It's probably going >> away soon anyway. > Done. Thanks. But note that removing the check from access_error() means > that if the assertion is broken, userspace might crash inadvertently > (in contrast to the version I sent, which would have potentially led to > infinite stream of page-faults). I don’t know which behavior is better, > so let’s go with your version and just hope it doesn’t happen. Actually, crashing sounds much nicer to me than infinite page faults. It's a lot easier to debug, *especially* with a warning on dmesg.