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

[Christoph Hellwig <hch@lst.de>]

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.