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 6C4F2C4828F for ; Fri, 2 Feb 2024 13:28:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A12A16B0074; Fri, 2 Feb 2024 08:28:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C2DB6B0078; Fri, 2 Feb 2024 08:28:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B1FB6B007B; Fri, 2 Feb 2024 08:28:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7C7706B0074 for ; Fri, 2 Feb 2024 08:28:23 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4A86980F3D for ; Fri, 2 Feb 2024 13:28:23 +0000 (UTC) X-FDA: 81746942886.07.8CD1EAB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id D69B016000A for ; Fri, 2 Feb 2024 13:28:20 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=S5WBL7m9; 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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706880501; 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=x606Z/KcYmnJxZy76x1M0MtI6Q/G0bPc8vDseQeRUmU=; b=2s7lPkknY3bHeIu1W5jNt5BpKM5+CB9eSNHAzcMosvRJQkvT/oKpSI8Z2Q6iUof75sXB5I Zokrl2IZJdteu+hNQMfLTxYBqsWwGrrpsdUZ+ADNb61J3si/yK2+JxkHY3FRheOX3T0/39 4Na8k/4YCuMz3dggawurE5vGHQH9HGc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706880501; a=rsa-sha256; cv=none; b=37W2UxQTEPLMQRkgfA0Dp19lc6UgygtlwALM/r/etNNqG8tNNOb7FSp/NCNE/jC+o6OUnn 7+LgH6w9UUJYw8vfcCyW4+AMwflOxR7uFKC8IlXmoaDI/RkYzqKZ7ul9C9VB5qDC/3csPI 1CHU3EOXlmY/xwz68lCOFseJS0hqlH8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=S5WBL7m9; 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; dmarc=none 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=x606Z/KcYmnJxZy76x1M0MtI6Q/G0bPc8vDseQeRUmU=; b=S5WBL7m9BVakDCbUA5iktIyy+z 2GAiwwP+ORnRd08ykLvyBOEkXEfAgFlPtoah70U0i0zVxMLI3AeMcP/21lexi3zu73uEumzhzNO2H faJO8AQwTgPSLJytSDp5/UzPxhu4Zml47OuOUF/WUY8HcxQx60j03bqod6xJHVA+lpzuCYb9XE/gI wkzLW36PE53ECK1CcOfHbILwfQnXSPkPxUIRVxTsMv56FWOa58LlOqHPSas7PqYtXW9iuawnxrj43 MbOSdG6H8q7upE9gcLwnfoEpu7OEsYvz3ELcOaq+khI+u7mSri8TKAAbcQL35d5xN6htmFXCcYvBh UV3Wc8Ag==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVtaY-000000019bW-3Ywr; Fri, 02 Feb 2024 13:28:14 +0000 Date: Fri, 2 Feb 2024 13:28:14 +0000 From: Matthew Wilcox To: David Howells Cc: lsf-pc@lists.linux-foundation.org, Kent Overstreet , dwmw2@infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [LSF/MM/BPF TOPIC] Replacing TASK_(UN)INTERRUPTIBLE with regions of uninterruptibility Message-ID: References: <2701318.1706863882@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2701318.1706863882@warthog.procyon.org.uk> X-Rspamd-Queue-Id: D69B016000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: djpz8s9tiajux5dpdtqrnuckfoiikpju X-HE-Tag: 1706880500-720793 X-HE-Meta: U2FsdGVkX1/OmZH2fSCpUizMa3XMrZ3KvYvKT71Uiry/iveG3xDlZGVesdXfRVWLDzS6e1sY7GhDNI1r0i2MyFxFrRGg+EoSz4Fqi5ZqmYXYNtmIrXoAygJQ7RxrsCcjHnWq2gaFpdUnLrr8K1DcctPQ8+qB3YCdQEQju4SyF6hmYjX/92UnStIFPHHOtsuwHWlgf5b4jN3n4BjKvm4ZSGM+LJMfdbxt1WipV0+LjRGn2p082t9zSCRTdJaufuEJJKIYOYN0LyzgDpFaWGwHtb7xFEACvF+SqXM+M7obF2yKNbRNROyXWEsq51RLtPF7d/IJ+mnKTRKAES8t/mW5xHd8xST7AvFuOF1LUEcRoauJV2cHC1MNej0xPyI8boKslo5ZplNdldSTgGzaKyaLzJ/VfAWiZycoG0V8pLMAan8Q4In68jVc+Zi0XUIaGONYkaeFYW0EoO5JneVh7cTRSF6GhTLJ7muAk5ubJytQ1s2R6e4aJ3toj1Dl+wY++VMW2Oy4AgltRU8RAy3yd/SGiZrR2KZb858WuTFBMAHmmGUIDNJA8pcuIST0lPM0GhFihbikz2cF4+0riXpsT3KTJ78zODLAFD9vER8vyJM465vye3oD75NgY/H6FJTGfOumkBiBuDOq2gbB7aenzWj3z+WvVD3/BVPKmQtbMBEqzZrtjtjWyENners6ApEjxSn54y8P9E2FU5y83cyshbLU2QjdXB4c22l/7q1p95N6tv68eNar0L0gsd+SCxlFMjT4pnpYR/ptGSYbhmCyqtsBUq3bzBp3TwDfLYUlOREr0KoOviYeGm3vLNMwEvFzpnaHBhYeM/SQ7F88UisbxQCcvwVnWJKpAAh3WM2nkSHejMqOrl5KMHYiYRLIhj1XzoMzeXCHt/UPuZb5XcT/BTx1HfvJNh9dZqYqBSBpv9ByWhdwCfKbcowrvNhcc+Fs98LlrmRkqsXngElIh2R4luH zRlCrIzl e+ax4L4leFVb08KS2Rg0lW5LgCD7W7UrEFGizKT/3Zx9EAXoOzlgP8NZwchWWU73ua942uWVp1FURRKxTEa5IZCUMXNUnk2rSZLyE3FNA0phr8m9y1si/nb4vL7UaJuQZ6eox5UfxOzDXqGawmgdgUNtTvgve7glu56qM9Xmv37xwS9sT32pHJbaIOg== 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 08:51:22AM +0000, David Howells wrote: > Hi, > > We have various locks, mutexes, etc., that are taken on entry to filesystem > code, for example, and a bunch of them are taken interruptibly or killably (or > ought to be) - but filesystem code might be called into from uninterruptible > code, such as the memory allocator, fscache, etc.. > > Does it make sense to replace TASK_{INTERRUPTIBLE,KILLABLE,UNINTERRUPTIBLE} > with begin/end functions that define the area of uninterruptibility? The > regions would need to handle being nested, so maybe some sort of counter in > the task_struct counter would work. I don't think filesystems ever want to do stuff interruptible. That allows any signal, including SIGALRM, SIGWINCH or SIGUSR[12] to interrupt your sleep, and user code just isn't written to handle that (short reads, etc). But killable is useful. If I hit ^C, I want the task to die. Maybe some of its resources hang around futilely waiting for a packet that will never arrive; so be it. So I would not define inode_lock_interruptible(). But I would define inode_lock_killable(). I'd be happy to see that overridden by a task_set_uninterruptible(), but we do need a new API to give filesystems a chance to handle "I didn't get the lock, abort".