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 3AA0CC48291 for ; Fri, 2 Feb 2024 09:43:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4FBA6B0074; Fri, 2 Feb 2024 04:43:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FF076B0078; Fri, 2 Feb 2024 04:43:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EE216B007D; Fri, 2 Feb 2024 04:43:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7F5C86B0074 for ; Fri, 2 Feb 2024 04:43:44 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1A51C1A01E3 for ; Fri, 2 Feb 2024 09:43:44 +0000 (UTC) X-FDA: 81746376768.18.342FEE6 Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 0F7988000E for ; Fri, 2 Feb 2024 09:43:41 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="UpZI7/dm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706867022; 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=cP0oRR5YByefU6AaquqTNRU3Kc+VM9PTtupCs9QuvV4=; b=y7J68nUdYUHm/Wr1pfl5LGOdNCglRXn27Hn7ZnUAGQyF1FXSZrPQf07QMhZ3vlRISvl/Hm K1aCk7Ipd5OwlaE0gGFyE6rzXOo/pI3Ub/rK+pWhH6SwhCScDhUCmZEp0jnibKFsEHlZxM hnNDpC+EEWXYTPzLCHEaTouUZGpiIrg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="UpZI7/dm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706867022; a=rsa-sha256; cv=none; b=WoHTFyB8wqJnlg2i6tJdm8k2OoRj8aI1rtGBcnWj5dMYLDekLKs3QwKie1CNUjQwyFgYCc Afyf56BrdmOlBOqJ/YJfMnM7n/p1J7Z+oWnomnex80lrRwrstAg34SoV3CdMchKGY98y3R tLqNP7e4dH3wJXLee/+1oLgNBNJPTMo= Date: Fri, 2 Feb 2024 04:43:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706867020; 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=cP0oRR5YByefU6AaquqTNRU3Kc+VM9PTtupCs9QuvV4=; b=UpZI7/dmWBH+yc92OxbMLYekpoU7Zx9sJST7r/+Iuxm72I/jn439rkK2l8rSZNgc1lNCR0 sIcoCdTlkcuTmWlR5XMy1OHg8qA1uW5eIF7J6lePTjIRKoE4SU4TDKs6QN8b1aEyI1UgaJ B8z+l7rD5CAJ1eS5g3QWwQ2X36hXNUo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Miklos Szeredi Cc: David Howells , lsf-pc@lists.linux-foundation.org, Matthew Wilcox , 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: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0F7988000E X-Stat-Signature: d1skzruipiuwf4iembd5g9qc9m8q6faj X-Rspam-User: X-HE-Tag: 1706867021-562552 X-HE-Meta: U2FsdGVkX1+6erIlrd+PoUtHAlTIwJeC9KzCjhvI+sFAdiCDv9XZr2VEAuXhd9UX3XVp/bt6a6/emQSo5/ne9WPdUYh+X7AaBBACqA+72R3p0cn9DJDHA7FZcFmqzVK6kCN6zylTTvYJAvhw+JcDd0SN3WigEei3lBKg6Wx3NO6ga2/aTHXMA0f+kIp+30+I6q/nPkPr7R4fR6tc6HdCAVaaMQGXuWHrNqiEDbNTsceEDYLL3KVHVJUhRmhjgmae5RwRZlJGix+IbjsgeA0L5GG57Nx3vA/3OLrRioOPp6/CW3LTyjltmRo8fHvcw1Wo0JaQmkTkzBCqqz8T/eMVlmN7FayfSVaQOaV6XWnx73qBsCVFffW2Z6hzquqELJZPOnxNOmwlvGx+9lbl26wGVPKHjzpNFFB5r+I3iWo06b/hAUuxFTfe0fKartWU9ZNyVlcJqnndoY5pIp89RGiwNvuahodnO4pzv1X/LSVcfi7LlT9hL4sKwZUzzPEqhczp1lkTsAxBA3V7XTYWopOXi5icM/tiVHk69bnNfEc5H18DIQfwmkkADqgtwAeyDIAUuOGlode88X9GlBtHFClwhwojquiGPC44rTuZbuCeTZ9Ti0kvK4rGlZTrbzkjSc+H8fwJMpD5+vD0OCqHlFg93lDxySge9UaHTK6L9/4wXcytl3F3dGzcbsXYn+OipE0ZH2etgm9GTifjtA0JJfb1vRudp+OFvy3f6qJVzdxAKUgtuw2/CrAtXwLHvyvNaBBWEf3rgp8ZyKHeTG4RixLq9QfkNgJWw6eoAfnmxdYcaxpaPzodMWgMPGw5vR6TZ4/jpvmHDZBdRorpzSKnt1Dn7talCUTakTP5ofPOf5K3pk0sNDylZTqW5Wncf96W4meb4wLlKHmF7nZGprk9CVJK4UiCFVu0ps+sIE9XnQEQ/0rfN13MLFoIstZZ8DwKRMQQZhOBDKD5xOa/V0t9EmX Pp9E8OBa fL7N2Kxqvv/CR4AWUPJO/7/WOkkoMWd/7TO4ja2XknjG435fxGjQ2df+4jtC7Rc5XhUln4XZKACTrBrN1bzJ4lQ2HCxMunX+EaR19/fbHbNtfURSo51zHL2RORk2ji0oJ/AvgzKeqlzp4LCi/YGhvCIVe5wiZltnhllxd+r5jpxRFwLbh3jkPuYAzPA== 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 10:08:59AM +0100, Miklos Szeredi wrote: > On Fri, 2 Feb 2024 at 09:51, 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.. > > Are you suggesting to make lots more filesystem/vfs/mm sleeps > killable? That would present problems with being called from certain > contexts. > > Or are there bugs already? I believe it's both. Potentially we could get rid of e.g. mutex_lock_interruptible() and mutex_lock_killable() so our API surface goes down, and I've seen at least one bug where we were checking for a signal pending and bailing out where we really didn't want to be. I think we'd need the new API prototyped in order to have a concrete discussion though.