linux-kernel - Re: [GIT PULL] Btrfs fixes for 6.11-rc6

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: <20240828121836.GG25962@suse.cz>
Date: Wed, 28 Aug 2024 14:18:36 +0200
From: David Sterba <dsterba@...e.cz>
To: Filipe Manana <fdmanana@...nel.org>
Cc: David Sterba <dsterba@...e.com>, torvalds@...ux-foundation.org,
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 6.11-rc6

On Wed, Aug 28, 2024 at 12:50:22PM +0100, Filipe Manana wrote:
> On Wed, Aug 28, 2024 at 12:23 PM David Sterba <dsterba@...e.com> wrote:
> >
> > Hi,
> >
> > a few more misc fixes. Please pull, thanks.
> >
> > - fix use-after-free when submitting bios for read, after an error and
> >   partially submitted bio the original one is freed while it can be still be
> >   accessed again
> >
> > - fix fstests case btrfs/301, with enabled quotas wait for delayed iputs when
> >   flushing delalloc
> >
> > - fix regression in periodic block group reclaim, an unitialized value can be
> >   returned if there are no block groups to reclaim
> 
> There's some confusion here.
> 
> First, it's not a regression because the uninitialized return value
> has been there since periodic block group reclaim was introduced.

I used the word regression because it's been added in the same
development cycle, i.e. the dynamic reclaim, but yeah maybe it's too
strong.

> Secondly, and more important, is that it doesn't cause any problem
> because the only caller of the function ignores its return value.
> 
> So this is effectively more of a cleanup than anything else, and could
> have waited for the next merge window.
> I see you also added a Fixes tag to the changelog, which will trigger
> stable backports.

For completeness of the periodic reclaim code I'd rather add it now,
before 6.11 is released. The Fixes tag is for reference where it was
added,

> Unless there are compiler versions or static analysis tools that
> complain with warnings, it will be just overhead to backport to stable
> releases.

No backports should be triggered by that because it hasn't been
released

$ git describe --contains e4ca3932ae90
v6.11-rc1~157^2~32