linux-kernel - Re: [PATCH v2 01/11] ntfsplus: in-memory, on-disk structures and headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251202054105.GA15524@lst.de>
Date: Tue, 2 Dec 2025 06:41:05 +0100
From: Christoph Hellwig <hch@....de>
To: Matthew Wilcox <willy@...radead.org>
Cc: Namjae Jeon <linkinjeon@...nel.org>, viro@...iv.linux.org.uk,
	brauner@...nel.org, tytso@....edu, jack@...e.cz, djwong@...nel.org,
	josef@...icpanda.com, sandeen@...deen.net, rgoldwyn@...e.com,
	xiang@...nel.org, dsterba@...e.com, pali@...nel.org,
	ebiggers@...nel.org, neil@...wn.name, amir73il@...il.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	iamjoonsoo.kim@....com, cheol.lee@....com, jay.sim@....com,
	gunho.lee@....com
Subject: Re: [PATCH v2 01/11] ntfsplus: in-memory, on-disk structures and
 headers

On Mon, Dec 01, 2025 at 11:46:08AM +0000, Matthew Wilcox wrote:
> On Mon, Dec 01, 2025 at 03:22:43AM -0800, Christoph Hellwig wrote:
> > On Mon, Dec 01, 2025 at 07:13:49PM +0900, Namjae Jeon wrote:
> > > CPU intensive spinning only occurs if signals are delivered extremely
> > > frequently...
> > > Are there any ways to improve this EINTR handling?
> > > Thanks!
> > 
> > Have an option to not abort when fatal signals are pending?
> 
> I'd rather not add a sixth argument to do_read_cache_folio().

I can understand that, OTOH unexpected failure modes aren't nice either.

> And I'm not sure the right question is being asked here.  Storage can
> disappear at any moment -- somebody unplugs the USB device, the NBD
> device that's hosting the filesystem experiences a network outage, etc.

Yes, and we fully need to handle that.

> So every filesystem _should_ handle fatal signals gracefully.

Absolutely,

> The task
> must die, even if it's in the middle of reading metadata.  I know that's
> not always the easiest thing to do, but it is the right thing to do.

A few fatal_signal_pending isn't helping with that.  What is needed is
to make sure all error completions happen in this case, preferably
in a timely way so that all resources get unlocked and cleaned up.

A strategic fatal_signal_pending() here and there can help to speed this
up, but is has not effect on the fundamentals of file system error
handling.  In fact in some places it will make the error handling much
harder because you now have to handle extra corner cases.