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 A4F5FC369D1 for ; Fri, 25 Apr 2025 04:52:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFFD86B0007; Fri, 25 Apr 2025 00:52:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAEB66B0008; Fri, 25 Apr 2025 00:52:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C772E6B000A; Fri, 25 Apr 2025 00:52:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A7BEB6B0007 for ; Fri, 25 Apr 2025 00:52:25 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 49E04C0BDE for ; Fri, 25 Apr 2025 04:52:27 +0000 (UTC) X-FDA: 83371345134.04.9228D50 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id AF577160008 for ; Fri, 25 Apr 2025 04:52:25 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BJVri5ot; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745556745; a=rsa-sha256; cv=none; b=ZStFpFXgLlTJ2+QZt3ammWnO+c38VmbT90ESm0Wpc3xuEK5q5kRJwHFVjdOZWvvdAbA94L a6SwQuxeQr1V/w7vzmIiezOj0YBrqhYj21wwvY4FEh80kK8l25ELQXLLS77s0MBk9Z/Ima tSmoLjCLhLLu8ABlJSv1y8TXqXj0Txc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BJVri5ot; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745556745; 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=YFB4ZF0Whoj32Yw9FFMV1qTPxhW/oefu8NpvR90pwmo=; b=dWx9b8wXWX8s5y409SCigVsPOkXGZHVT6FgMzJMjipqlt3VZm0+eQCEwVUErXVqFw+jKPL ws0UaRgCmpt8DXiJuB/tV2kD5h5F6ovRKLBYvjEh8MaTfdoSu1yIiOTaUTw/hqtfPR7gtF lkXYHQO95utDI/elmmWPUdU+MK85fZE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=YFB4ZF0Whoj32Yw9FFMV1qTPxhW/oefu8NpvR90pwmo=; b=BJVri5otk1pxjU6hwWWNbwGeal i4HaomFTMDjAKOEXyyGZaomJGjvCcMUT+exbtpztdlAYki/4TVu6FOSYKUmFb1M1ahlyu2qR8jsA5 AN9GcVM15y+bHwmu6lDOmvGbyhRbSTJht9A3S4jUSKYLh9mpU701/8ih0bpLxn8ei19RQ7wECjDQm XNx4x61tglPNOs5a3QFd/imh37eSrGmQCD95ehd4BM708sKT7JblkS60i3RIwoEdfeT+AfzB/dJMf JHzHO/TWabc7ae/ATlH1JqC/tUBGD5w8iAz4vHJIV6CA0tyySoCEiSwzogiw9/wn13ajLfBa3c9j6 yvJ2X4/A==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1u8B2y-0000000Dm1m-3s9a; Fri, 25 Apr 2025 04:52:20 +0000 Date: Fri, 25 Apr 2025 05:52:20 +0100 From: Matthew Wilcox To: Peter Xu Cc: Johannes Weiner , Jens Axboe , Andrew Morton , "linux-fsdevel@vger.kernel.org" , Linux-MM Subject: Re: [PATCH] mm/userfaultfd: prevent busy looping for tasks with signals pending Message-ID: References: <27c3a7f5-aad8-4f2a-a66e-ff5ae98f31eb@kernel.dk> <20250424140344.GA840@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: AF577160008 X-Stat-Signature: aoch38y83fsito4j18cphng6x56s66cd X-Rspam-User: X-HE-Tag: 1745556745-946772 X-HE-Meta: U2FsdGVkX18VZSAHR+SDJ32xYpmgnpK+B1lpuZKlPOTVJgJVkzbQmbLmbX8HBPjUx2MR6WqA85SISANJqPXnZsSHe/cyDDlX/184pHmluk9X3kmtZxoAkI4FxNS+wrdwCT+bO5kTBbSedrartjoou66j9DeIbFXFEwfruexXn5sgzqIYOAay3RVhp1349zAK1l8nNLjfYWYpgj0hlIPu7qyl5ht58B6bWS6xhRDgLV/938jjiCa+chlMcoaLaigC81VMUzZtx9KWInjiV/UHcWtDSDDfBCQs9DtcAeekl7e+OQ6n3u9gmqJ7VIy6JRdybI4PXTwQK57RRR5YQuxqfGyShCkax35IkDtVd9/l1vit+3MsASNt4XGIxYZr1OE1idAJ4UXydAxNcWl4ABbHmTzkgqfGX5IT8A34hv9XzLNKnLtbWLjUZ8zqHWPswZ+RfnPcV7127h/pBh3I0dEOjZTTATwWJXRHSuGAjmvdbpubz7VmI3OQfxMFsS6mrUPNeDbCfg2gwx6X+5CL0ME9a7HQH+BdcC2EnaulZd0wAtS+zou66BfL6F3mrOheHX/oWSs01wl3FpEIRzB0xR/+w1TiJ1JFZQqCmuKeajfDVyyYOAsFtw5x9V+2R/Rz0mTiqA7NOkPa2ZiCvFt7WFZJLaEmGOlQ8uZp/r2C7OofDtDE7zAWTxUfgGb9avmxbB0cMU+RE6TY01LN4o116yu4SbpS2je23uVDq4AlFrvdsF6YIqtNNzxzMafCAZxYXxhYu2cY/T15Up0/yLP5vR1bUb+7o10KAlBXA3ffW5my7BpzCbqr6LZH4/Tt30fTJRaqsdXewB+v5n+vuxZnmumuJI1P18Kdo8ByD2NTjeZpEqEbar5zcuSBc16tKAEv6DAiQEzEQ7XVTuQy0y6r2exsUxsCOQn0Kal5w0isIFjHTskViLn9zx+Ol14s9SDkXLGMST7OjoHgSjZQuGjZO/g s0dCXUZt g2HYyaSmIKNlXTprR3bbkXsYd0VwMRuvNM5qgrr0GD3XwabgQtoNHetS47o27sqDf+1OZmQooMPYTpfEYXKkU6Pn+2zTP9EEUMabhMAKlIpUql4Z2sFZOPSx5RXhUa688Se1h2Q9JM7HHRrUwEmsK9NIRv70Y1KHQn8KfBNK8SQzRzh8XBxc1ry0CPFBmAoGz5oa7bPcTtgqP9yp8FqwOJ+F38OFfbrXKULVgVX5UZO0Y/mMQCuQENJbDvhcBQ47kRhLCxkCTtEvzCOo= 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: List-Subscribe: List-Unsubscribe: On Thu, Apr 24, 2025 at 05:45:37PM -0400, Peter Xu wrote: > On Thu, Apr 24, 2025 at 08:42:00PM +0100, Matthew Wilcox wrote: > > On Thu, Apr 24, 2025 at 02:26:37PM -0400, Peter Xu wrote: > > > Secondly, userfaultfd is indeed the only consumer of > > > FAULT_FLAG_INTERRUPTIBLE but not necessary always in the future. While > > > this patch resolves it for userfaultfd, it might get caught again later if > > > something else in the kernel starts to respects the _INTERRUPTIBLE flag > > > request. For example, __folio_lock_or_retry() ignores that flag so far, > > > but logically it should obey too (with a folio_wait_locked_interruptible).. > > > > No. Hell, no. We don't want non-fatal signals being able to interrupt > > that. There's a reason we introduced killable as a concept in the first > > place. > > Not really proposing that as I don't have a use caes. Just curious, could > you explain a bit why having it interruptible is against the killable > concept if (IIUC) it is still killable? Because "interruptible" means it can be interrupted by inane stuff like SIGWINCH and SIGALRM. And then we return from a page fault prematurely and can't actually handle the situation, so we end up going back into the page fault handler anyway having accomplished nothing other than burn CPU. At least it's better than interruptible system calls which just gets you short reads, corrupted data and crashing programs.