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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01BD4C3279B for ; Mon, 2 Jul 2018 13:33:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B68DF25DC5 for ; Mon, 2 Jul 2018 13:33:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B68DF25DC5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.vnet.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbeGBNdY (ORCPT ); Mon, 2 Jul 2018 09:33:24 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40820 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752366AbeGBNdW (ORCPT ); Mon, 2 Jul 2018 09:33:22 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w62DUS1S133543 for ; Mon, 2 Jul 2018 09:33:22 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2jyjkbxb16-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 02 Jul 2018 09:33:21 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Jul 2018 14:33:19 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 2 Jul 2018 14:33:14 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w62DXCbq36503734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Jul 2018 13:33:12 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A6F64C046; Mon, 2 Jul 2018 14:32:55 +0100 (BST) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 845084C050; Mon, 2 Jul 2018 14:32:54 +0100 (BST) Received: from [9.145.48.243] (unknown [9.145.48.243]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 2 Jul 2018 14:32:54 +0100 (BST) Subject: Re: [RFC v3 PATCH 5/5] x86: check VM_DEAD flag in page fault To: Michal Hocko Cc: Yang Shi , willy@infradead.org, akpm@linux-foundation.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, tglx@linutronix.de, hpa@zytor.com, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org References: <1530311985-31251-1-git-send-email-yang.shi@linux.alibaba.com> <1530311985-31251-6-git-send-email-yang.shi@linux.alibaba.com> <84eba553-2e0b-1a90-d543-6b22c1b3c5f8@linux.vnet.ibm.com> <20180702121528.GM19043@dhcp22.suse.cz> <80406cbd-67f4-ca4c-cd54-aeb305579a72@linux.vnet.ibm.com> <20180702124558.GP19043@dhcp22.suse.cz> From: Laurent Dufour Date: Mon, 2 Jul 2018 15:33:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180702124558.GP19043@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18070213-0020-0000-0000-000002A23315 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18070213-0021-0000-0000-000020EE4490 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-02_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=838 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807020156 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/2018 14:45, Michal Hocko wrote: > On Mon 02-07-18 14:26:09, Laurent Dufour wrote: >> On 02/07/2018 14:15, Michal Hocko wrote: >>> On Mon 02-07-18 10:45:03, Laurent Dufour wrote: >>>> On 30/06/2018 00:39, Yang Shi wrote: >>>>> Check VM_DEAD flag of vma in page fault handler, if it is set, trigger >>>>> SIGSEGV. >>>>> >>>>> Cc: Michal Hocko >>>>> Cc: Thomas Gleixner >>>>> Cc: Ingo Molnar >>>>> Cc: "H. Peter Anvin" >>>>> Signed-off-by: Yang Shi >>>>> --- >>>>> arch/x86/mm/fault.c | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c >>>>> index 9a84a0d..3fd2da5 100644 >>>>> --- a/arch/x86/mm/fault.c >>>>> +++ b/arch/x86/mm/fault.c >>>>> @@ -1357,6 +1357,10 @@ static inline bool smap_violation(int error_code, struct pt_regs *regs) >>>>> bad_area(regs, error_code, address); >>>>> return; >>>>> } >>>>> + if (unlikely(vma->vm_flags & VM_DEAD)) { >>>>> + bad_area(regs, error_code, address); >>>>> + return; >>>>> + } >>>> >>>> This will have to be done for all the supported architectures, what about doing >>>> this check in handle_mm_fault() and return VM_FAULT_SIGSEGV ? >>> >>> We already do have a model for that. Have a look at MMF_UNSTABLE. >> >> MMF_UNSTABLE is a mm's flag, here this is a VMA's flag which is checked. > > Yeah, and we have the VMA ready for all places where we do check the > flag. check_stable_address_space can be made to get vma rather than mm. Yeah, this would have been more efficient to check that flag at the beginning of the page fault handler rather than the end, but this way it will be easier to handle the speculative page fault too ;)