linux-kernel - Re: [PATCH] btrfs: Use refcount_t instead of atomic_t for mmap

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] [day] [month] [year] [list]

Message-ID: <20250429093525.GC9140@twin.jikos.cz>
Date: Tue, 29 Apr 2025 11:35:25 +0200
From: David Sterba <dsterba@...e.cz>
To: Qu Wenruo <wqu@...e.com>
Cc: Bo Liu <liubo03@...pur.com>, clm@...com, josef@...icpanda.com,
	dsterba@...e.com, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: Use refcount_t instead of atomic_t for mmap_count

On Tue, Apr 29, 2025 at 05:12:27PM +0930, Qu Wenruo wrote:
> 
> 
> 在 2025/4/29 16:50, Bo Liu 写道:
> > Use an API that resembles more the actual use of mmap_count.
> > Found by cocci:
> > fs/btrfs/bio.c:153:5-24: WARNING: atomic_dec_and_test variation before object free at line 155
> 
> Please explain this better, I didn't see anything wrong about the 
> decreasing the atomic to zero then freeing it.

Yeah, we'd need better explanation for that.  The refcount can catch
underflow, which I'm not expecting to happen for the repair bio as it's
set up, sent and the endio is done. We might assert that the
repair_count is 0 right before freeing the bios, but otherwise the
repair_count does not match a refcount semantics.