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 E5322C001B0 for ; Wed, 26 Jul 2023 18:00:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B7DC6B0071; Wed, 26 Jul 2023 14:00:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 368146B0072; Wed, 26 Jul 2023 14:00:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 258D18D0001; Wed, 26 Jul 2023 14:00:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 16FB26B0071 for ; Wed, 26 Jul 2023 14:00:04 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D26B51C9759 for ; Wed, 26 Jul 2023 18:00:03 +0000 (UTC) X-FDA: 81054526686.02.EB653AC Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf28.hostedemail.com (Postfix) with ESMTP id C6B4FC0029 for ; Wed, 26 Jul 2023 18:00:01 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P7WnNeLW; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690394402; 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=bGK72/2uFFAFURzSmoidnNrT7qXYHkSsD+/Ej2DNnKc=; b=duOc6lDSw0mPWYyzT3Jm4/tC3zJbdRXRQORfBNLZTeuMU1FYL8wYw/WW6ECphBY+YQjnh4 p94EXFQ6hz0+7Jx7k12IKmAF2uC3SpPXIw8CoRLAHS6CL5J4mKwYOKFohf5JQfdFR0MnFv Jih/2hzgE/8zurgiuekNY127mqD/G5E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690394402; a=rsa-sha256; cv=none; b=rQaW1GPf9Zu8J6Gz5CwVlt4aTohSGEoNxGc7dOlLu89qGFPg4FKXONS0oiQSwcfh4DFtEZ SwXDX5LVHngQ+w3bGade9hdoPi4YpiEM16ftqKBSmvQrUapOcIkhu7uzS10gNxdNg23zl/ vdcI7YM3/CMhtSMkSUcoHG36limvYCE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P7WnNeLW; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5221ee899a0so60581a12.1 for ; Wed, 26 Jul 2023 11:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1690394400; x=1690999200; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bGK72/2uFFAFURzSmoidnNrT7qXYHkSsD+/Ej2DNnKc=; b=P7WnNeLWPcYwJm0VZthWtrpDrBd4LFSWkMkVFeEdLo3UMtiE7UBt0w0R+oRRHHOS8T HFFWfhePg/sSY/+H6bW/9M/e7L4dCiygsg0yB9fyS2my6QuNurc5WSRxiMcWkAaFhpmY hm0KN598pzfDP1r2IXriDTrGthGyVg1t+WIJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690394400; x=1690999200; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bGK72/2uFFAFURzSmoidnNrT7qXYHkSsD+/Ej2DNnKc=; b=KjxXTdBM3aDLp3nbsyiKtS0u2aNieJ8mlOuLCaTqk26HKBmZWZL/NIyJ/Nnyx6Wc0F 1ucW1cMSZN+gROlCRR6ZownBn5o/DtZt/zszm5002GNbV0bAE2l97kxqPj65PG3QDKiz mTW3ZSrMwH5Mix+E7nRGvZj3GQjvCIDARvWzAUanTr5PTyXOJBtn1Jbi4Cc9cQMvOGim RQxLnRXXayhictuVIhxI+QRLn1l3AXq6Edjk065L0yHbmEceMcbjrjNikXWRRZad+39b 7eh7NGfNg3ZOhcFT4qwYKfTz/8CVX2aiJOwDKOQ/3a5mOhhpBDYiF5Xv6RsvfYKMBnx2 nvjA== X-Gm-Message-State: ABy/qLbsUwzCPdsZb53z+q0ub0ndXlOjrpyOdRaZRmTSIVS5E62pygBp aU1I7hIGubXZ0p3Ayz5TAgrAtYY4V6GvpvO4sB0xbbVf X-Google-Smtp-Source: APBJJlFNihhfnVn1oX+xFjFDZ+LPxqiu0P49dyEzxt4A0dY1N/daWdR5teFFiLFy+FlGU4zauAufrA== X-Received: by 2002:a05:6402:648:b0:51e:34a1:8bf7 with SMTP id u8-20020a056402064800b0051e34a18bf7mr1979798edx.39.1690394399800; Wed, 26 Jul 2023 10:59:59 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id s26-20020aa7d79a000000b005224d15d3dfsm2321062edq.87.2023.07.26.10.59.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jul 2023 10:59:58 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5221ee899a0so60536a12.1 for ; Wed, 26 Jul 2023 10:59:58 -0700 (PDT) X-Received: by 2002:a05:6402:683:b0:522:2b76:1985 with SMTP id f3-20020a056402068300b005222b761985mr2046463edy.2.1690394398336; Wed, 26 Jul 2023 10:59:58 -0700 (PDT) MIME-Version: 1.0 References: <8d063a26-43f5-0bb7-3203-c6a04dc159f8@proxmox.com> In-Reply-To: From: Linus Torvalds Date: Wed, 26 Jul 2023 10:59:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: segfaults of processes while being killed after commit "mm: make the page fault mmap locking killable" To: Fiona Ebner Cc: "Eric W. Biederman" , Oleg Nesterov , akpm@linux-foundation.org, Thomas Lamprecht , Wolfgang Bumiller , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C6B4FC0029 X-Rspam-User: X-Stat-Signature: yai6omeiac4gs7qpr8tr7go7b6jh73fe X-Rspamd-Server: rspam03 X-HE-Tag: 1690394401-238025 X-HE-Meta: U2FsdGVkX1+XPvWVQ9M2gNcn4Asrbg6kvMZqPIvJaH1oW+pKRnhmkJD0T1RI+R/UaULAmP+NnIHxTuRuRvqDQG/YTjJ50eSj3oBYPugXTN49De1jiKGsC9Rx9WLrzbHhjAv4VivLVYvQKix1ZXGlmekmAwr0qT23UuuKT7d+9DhnL7RwT1f9ArQnR+DZj9VqtUrRz4iEywlBmpPWJg1YnZSgL5YIWvFOn6+El2GElX//mINHkgTHhhBdAURbvFEyEEw/+UkNlLVyYRYsKMp74AGjbTwNP/Zj/b97Wojljm4iYr5qeY/o0PMUMLfJyMmmk6ReXeCWb9O0k+fFCq7Fh8ofxu4rMYGy+qhl73k+U8GgidcYoTaT/W0JzlSrsRUruiNuG9rQ+Fy3BQASZY3FfPA4+I32zrh3+1Dv+E3nkuy1gorkpg+D7iDg7BERM3nEzOQZEGp36jOcLTHSP+eUT6AeKKWCdO8WzWKsV6FTaLITvwqz5ZrCfHlfpZpc7JRpt5kp4DfY32IGKWKHTX48ifpRGeF9VH4PLGOlPqlu89PIMxaRVo0aNH3WLhEdx7AymwmkEElgVkhwVCmLCVhugIsG62w5npLzw3bCtN9pWV9ogv2QTZd74AGFk5l6zcRuXV1qXfXOUMT+EsRqz88h96a9UXvDne81nzo7S1JMnAStOXVPhrWuQtkKFygh7C5f8Y0+RA/fG4mo3QAwdujJSIhd5EAiTRBHII0b1UUuC3qOaJEbupSCju52T7DxjqwqAe44wFfER5NlaEkT9e11C5XgD3FDg/uXJX8gueAfGfQFCwIKWaBH4tn5gdzIg05eD4f0c011TlRxdDlRvVqSJwmgl3h2Pq6qqv3OqRp0gfOdX8EUaYcMIPiFmWUNT4rkloeBQ9zsUy9H++QSY0zVBKAFG2Iot9BJdu1cWX+L4xrNHTXAtgTTzwx7dPOqfGxp7ID/GPvfo1dDk939itT ZoQ2NCvn Y8wcfNytx6SNS2NLnO/no6WpqHIU12Y+w0qrZf02vwAaFUf09/unNJvMoNO9GwCR2uE0Yo5VWLifg4/LDYEMvUNIuSjXwZR8U5ILU53zPehvcMIx2ol/El6me1qrOx+3hcgioM67yQbjpBqOm/CoI7YBc4MiE22BU9WplXbWtn6P7U8q/ng2Jg1wi5oZUBUatv34fYtRWsbrnbPq5eJi2J5tFfnGm53qsfU86rdTk7F2ZddrDyGuKT83aiC1oNygvEGmTTEteup3A9s9fvmD8KPCG2F8od9y4rUfwGsKAr+LBfj8u/20CppuedHKhMb0AjO+lv/oq/infOd1p4Qzr8i/x7IkwA8mJ0d7rPcYFrWLQjHrHYHbgObp41EEWE1mfoSk2yVr9gMdQwsjbcidXvNogZqdJsTrGCnDLUW1QVzY1a4QxAKR0V0pm/H3Gw0g9i1vbw+E07qsfR4DX8UBlMzs0wk7BF+PP1HqNsQ0SK4r30NPeU4rW4kuowF5vDAsiCN5swzbvj09pYikeBnQsiiMUvmHoAr02keIaVGaVElrgw3oyhIbNJbSzEQ== 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 Wed, 26 Jul 2023 at 01:19, Fiona Ebner wrote: > > Checking the status from waitpid, it does show that the process was > terminated by signal 9, even if the segfault was logged. Thanks for verifying. That's what I thought, and I had just entirely forgotten about the logging of failed page faults. This whole "fatal signals during IO can also cause a failed page fault" has been true for a long long time, but because it's done later by the actual VM code, there we actually end up going through "fault_signal_pending()" and suppressing the logging of the page fault failure that way. > > But before we revert it, would you mind trying out the attached > > trivial patch instead? > > The patch works for me too :) (after adding the missing tsk argument > like Thomas pointed out) So it turns out that not only did I forget the argument, I decided that I put that test for fatal signals in the wrong place. The patch obviously does fix the problem on x86, and we could do the same thing for all the other architectures that do this signal logging. But there's actually a much better place to put the fatal signal check, which will take care of all architectures: just do it in the 'unhandled_signal()' function. So I fixed the missing argument, and moved the test to a different place, but I still added your (and Thomas') "Tested-by:" even if you ended up testing something that was a bit different. Oleg, I took your Acked-by too. Despite the final patch being somewhat different. Holler if you see something objectionable. It's commit 5f0bc0b042fc ("mm: suppress mm fault logging if fatal signal already pending") in my tree now. And because it's a bit different from what you already tested, it would be lovely to just get a confirmation that I didn't screw anything up when I decided I needed to make a fix that covers more than just x86. Thanks, Linus