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 9770CC4828D for ; Sat, 3 Feb 2024 17:27:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABAB36B0071; Sat, 3 Feb 2024 12:27:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A6B1A6B0072; Sat, 3 Feb 2024 12:27:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97FEF6B0074; Sat, 3 Feb 2024 12:27:36 -0500 (EST) 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 89FDE6B0071 for ; Sat, 3 Feb 2024 12:27:36 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D897CA1AE4 for ; Sat, 3 Feb 2024 17:27:35 +0000 (UTC) X-FDA: 81751174470.23.6DF59A9 Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf26.hostedemail.com (Postfix) with ESMTP id EA0CF140004 for ; Sat, 3 Feb 2024 17:27:33 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Vxbk//bq"; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706981254; 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=PNfWOtiIX9Cs1s0iRQar9DY2eJFWlkoqzcILXEBLG2w=; b=vjyfIuG+xXuz3egPDuKNnnD5hopqWuOM1jYohmHAJde+FSAzQLIKC9nU6FvQV8ONQO9daW dMigQcWTLVsevhMwTcOYpLqI3PplE+1q3SgKj8cICs5G1JPrYHw+rBT1hflr5TQQp9vltG sKJUB/za69KE0NXhFyFuO4F7rSLWnwE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706981254; a=rsa-sha256; cv=none; b=quqChYbHrpEAJlRxVObNXYBJ93OBdrDzMWCoG6a9ZnmtRd1dw/rCJmJ0p+yHlZbSedUkCK 4rr2C45GZVB4ZgqP/t7jDa07iqALllkeOJ6+uyF2tD5MOw1hTQwabA3r5oZ74tk1Xdq43N KiCY+rdRttDPROItfFmdB8QyCdrSuBs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Vxbk//bq"; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Sat, 3 Feb 2024 12:27:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706981251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PNfWOtiIX9Cs1s0iRQar9DY2eJFWlkoqzcILXEBLG2w=; b=Vxbk//bq0QVbzqN0BHqgioxL2dabqdrTquCmMO1mINh6CExN88qnaknvQgA5eyh5jEp7kk /aGkV/MAANk/H/RUpo69ARWu6S6FmLKd8VsG3x+rtD7vWgMwSh+XUTL9OE0Hd1TsdOKi9O 7wRtrJmID8149ldNUx5f4rNpLVSjNHs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Al Viro Cc: David Howells , Miklos Szeredi , lsf-pc@lists.linux-foundation.org, Matthew Wilcox , dwmw2@infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner Subject: Re: [LSF/MM/BPF TOPIC] Replacing TASK_(UN)INTERRUPTIBLE with regions of uninterruptibility Message-ID: References: <2701318.1706863882@warthog.procyon.org.uk> <2704767.1706869832@warthog.procyon.org.uk> <2751706.1706872935@warthog.procyon.org.uk> <20240202162346.GB2087318@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240202162346.GB2087318@ZenIV> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: d4qyzre31xeb774m9k8eayrus7pu31bm X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EA0CF140004 X-Rspam-User: X-HE-Tag: 1706981253-11209 X-HE-Meta: U2FsdGVkX1/uSoZ56a77yAq4j5SXXT9u9h2Cn15mJUFIYqA2PQQG2NBkq8Hg3621g8pSU/GdL0z/WUDghCzvzAGo9oF6qMBD9lvwYgEySHLVmonDTbgEY2eF8a4w6YGMMyyaEurCSvRkW0t5ao43F8IkDsVMSumVeuh7GNhJOhGJ6X1L7r3RJ6xwk63C7sy7jYrzIU6M+i8KrRpwDRTbpv0WBBj0XaUw0bRya5cwazCTvz7RsFmUzEcOh7AHycqj9NhCwZkJKJNGXvTOMlh68dZQGAzlm0CyiwrkVwGOczlw9yPqBSChqGfaRnEoTVQCK1ODIXchUk3KCqhMbmfoQzT6Y48V3gRX5R52XeWJd5b5dXxcTyjar3zSxLjIlQ4PeAISvV8qgvZkhLY31cb2AeH49yU8aszpJHTO8fYnYdva0wdPSvJWrRvCsRduRdmZXa/i6g5yrh9ubvH2CZsgjGoo3mzDUFxaRAyvEvs02e802i3epwv15hJIZPlv76ZTy6OIckThkMVhIAAnAZMhKN6CDif16c48xtkocqvKxmIp2MprC5JnGTbNLp6SU601g1lrj1mwNlcHvlM+lV560y46IBXuW+Rx1es8+3lqlrCHYlH0CsBpohYRmQz/stpI8FP8+TI3NFsJLVtJ1OMLE6VKLr78oPX8gozkQInDT6nnVkoJkoMnfVcWDonVeWr7BORTDcpnJZU0/NwP8eqH0fVlC6xXwcRUgqRR5a4ogKJIZgxI0Vte0Nz4KB7BtqB0KhIX5ZdW8X41Yh62pt4D1/JFdRxBGxZax70cIjWuw/caGI808I3KyKOgO6YJN1nbJQB4I0n5jZeMlkWhQXFm1ek9NtdK/Jf/dEQOlaGofKRp2ycuRVP7Zn3Tf9oGsncnDDNanmFNu4x1AysC+kQecV2JaqT3qQ/X0nkIOgBAHAuKIcP+3ESk76C9bhZ1ry8DDNhfOPbfvF2R+EgAoGb MNanb4+5 FiokLZ+GfxaXzusLFcUTq7e0qhBuX5b8/Ty9CFSjTzCh5dis8HOMCp39B/in+poYoIFYkOtU+3b+VgZfr5XZVCmpuaieEvpRiv0bpgzr745vKckgiTZ3E9ATG/A2ZJXtsQhj+ 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 Fri, Feb 02, 2024 at 04:23:46PM +0000, Al Viro wrote: > On Fri, Feb 02, 2024 at 11:22:15AM +0000, David Howells wrote: > > Miklos Szeredi wrote: > > > > > Just making inode_lock() interruptible would break everything. > > > > Why? Obviously, you'd need to check the result of the inode_lock(), which I > > didn't put in my very rough example code, but why would taking the lock at the > > front of a vfs op like mkdir be a problem? > > Plenty of new failure exits to maintain? I don't currently see a reason to go around converting existing uninterruptible sleeps; the main benefit of the proposal as I see it would be that we could mark sleeps as either interruptible or killable correctly, since that really depends on what syscall we're in and what userspace is expecting. If kernel code can correctly do one it can do both, so this is a pretty straightforward change. But it is an interesting idea, I'd be curious to see what comes out of playing around with some refactorings. There's some other wait_event() related ideas kicking around too... Willy and Dave and I were talking about the "asynchronous waits" that io_uring is wanting to do - I believe this is currently just done in an ad-hoc way for waiting on a folio lock. It seemed like it might be possible to do this in a more generic way by simply dynamically allocating the waitlist entry, and signalling via task_struct the wait/wakeup should be delivered to a kiocb, instead of to a thread. Another thing I've been wanting to do is embed a sequence number in wait_queue_head_t, which would be incremented on wakeup. This would change prepare_to_wait() to "read current sequence number", then later we sleep until the sequence number has changed from what we initially read. This would let us fix double expansion of the wait condition in the wait_event() macros, and it would also mean we're not flipping task state before running the cond expression...