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: <CAKYAXd-UO=E-AXv4QiwY6svgjdO59LsW_4T6YcmJuW9nXZJEzg@mail.gmail.com>
Date: Mon, 1 Dec 2025 19:13:49 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>, viro@...iv.linux.org.uk, brauner@...nel.org, 
	hch@....de, 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 1, 2025 at 5:47 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Sun, Nov 30, 2025 at 11:14:24PM -0800, Christoph Hellwig wrote:
> > > + * ntfs_read_mapping_folio - map a folio into accessible memory, reading it if necessary
> >
> > The very long comment for something that is just a trivial wrapper
> > around read_mapping_folio is odd.  Also why does ntrfs need the special
> > EINTR handling that other file systems don't?
>
> I would presume that this is because NTFS is using the page cache for
> metadata and they don't want the metadata read to be interrupted by a
> fatal signal.
Right.
> Of course, this turns into a spinning instead of sleeping
> wait, so very bad for CPU usage.
CPU intensive spinning only occurs if signals are delivered extremely
frequently...
Are there any ways to improve this EINTR handling?
Thanks!