linux-kernel - Re: [Cluster-devel] [PATCH 06/32] sched: Add task_struct->faults_disabled

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZHBpg4ndZ2CLP7mi@infradead.org>
Date:   Fri, 26 May 2023 01:10:43 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Kent Overstreet <kent.overstreet@...ux.dev>
Cc:     Andreas Grünbacher 
        <andreas.gruenbacher@...il.com>,
        Christoph Hellwig <hch@...radead.org>, Jan Kara <jack@...e.cz>,
        cluster-devel@...hat.com, "Darrick J . Wong" <djwong@...nel.org>,
        linux-kernel@...r.kernel.org, dhowells@...hat.com,
        linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Kent Overstreet <kent.overstreet@...il.com>
Subject: Re: [Cluster-devel] [PATCH 06/32] sched: Add
 task_struct->faults_disabled_mapping

On Thu, May 25, 2023 at 07:20:46PM -0400, Kent Overstreet wrote:
> > > I'm absolutely not in favour to add workarounds for thes kind of locking
> > > problems to the core kernel.  I already feel bad for allowing the
> > > small workaround in iomap for btrfs, as just fixing the locking back
> > > then would have avoid massive ratholing.
> > 
> > Please let me know when those btrfs changes are in a presentable shape ...
> 
> I would also be curious to know what btrfs needs and what the approach
> is there.

btrfs has the extent locked, where "extent locked" is a somewhat magic
range lock that actually includes different lock bits.  It does so
because it clears the page writeback bit when the data made it to the
media, but before the metadata required to find it is commited, and
the extent lock prevents it from trying to do a readpage on something
that has actually very recently been written back but not fully
commited.  Once btrfs is changed to only clear the page writeback bit
once the write is fully commited like in other file systems this extra
level of locking can go away, and there are no more locks in the
readpage path that are also taken by the direct I/O code.  With that
a lot of code in btrfs working around this can go away, including the
no fault direct I/O code.