| Message ID | cover.1708429856.git.fdmanana@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs: fix a couple KCSAN warnings | expand |
On Tue, Feb 20, 2024 at 12:24:32PM +0000, fdmanana@kernel.org wrote: > From: Filipe Manana <fdmanana@suse.com> > > KCSAN reports a couple data races around access to block reserves. > While they are very likely harmless it generates some noise and reports > will keep coming, so address these. > > Filipe Manana (2): > btrfs: fix data races when accessing the reserved amount of block reserves > btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve Thre's another way to "fix" the KCSAN warnings, adding a data_race() annotation to the access when it does not matter if the lock is taken or not. In commit 748f553c3c4c "btrfs: add KCSAN annotations for unlocked access to block_rsv->full" this was added for 'full', have you considered that for 'reserved' too? The spin lock is also correct regarding the warning but still increases the lock contention.
On Wed, Feb 21, 2024 at 11:13 AM David Sterba <dsterba@suse.cz> wrote: > > On Tue, Feb 20, 2024 at 12:24:32PM +0000, fdmanana@kernel.org wrote: > > From: Filipe Manana <fdmanana@suse.com> > > > > KCSAN reports a couple data races around access to block reserves. > > While they are very likely harmless it generates some noise and reports > > will keep coming, so address these. > > > > Filipe Manana (2): > > btrfs: fix data races when accessing the reserved amount of block reserves > > btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve > > Thre's another way to "fix" the KCSAN warnings, adding a data_race() > annotation to the access when it does not matter if the lock is taken or > not. > > In commit 748f553c3c4c "btrfs: add KCSAN annotations for unlocked access > to block_rsv->full" this was added for 'full', have you considered that > for 'reserved' too? The spin lock is also correct regarding the warning > but still increases the lock contention. Yes, I have considered that, and in the change logs of the patches I mention why I chose to take the lock instead. As for the contention,, these aren't that heavy given the contexts where they are used and how much little work they do.
On Wed, Feb 21, 2024 at 11:25:16AM +0000, Filipe Manana wrote: > On Wed, Feb 21, 2024 at 11:13 AM David Sterba <dsterba@suse.cz> wrote: > > > > On Tue, Feb 20, 2024 at 12:24:32PM +0000, fdmanana@kernel.org wrote: > > > From: Filipe Manana <fdmanana@suse.com> > > > > > > KCSAN reports a couple data races around access to block reserves. > > > While they are very likely harmless it generates some noise and reports > > > will keep coming, so address these. > > > > > > Filipe Manana (2): > > > btrfs: fix data races when accessing the reserved amount of block reserves > > > btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve > > > > Thre's another way to "fix" the KCSAN warnings, adding a data_race() > > annotation to the access when it does not matter if the lock is taken or > > not. > > > > In commit 748f553c3c4c "btrfs: add KCSAN annotations for unlocked access > > to block_rsv->full" this was added for 'full', have you considered that > > for 'reserved' too? The spin lock is also correct regarding the warning > > but still increases the lock contention. > > Yes, I have considered that, and in the change logs of the patches I > mention why I chose to take the lock instead. Ah sorry, I skimmed the changelogs too quickly, it's indeed there. For both patches, Reviewed-by: David Sterba <dsterba@suse.com>
From: Filipe Manana <fdmanana@suse.com> KCSAN reports a couple data races around access to block reserves. While they are very likely harmless it generates some noise and reports will keep coming, so address these. Filipe Manana (2): btrfs: fix data races when accessing the reserved amount of block reserves btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve fs/btrfs/block-rsv.c | 2 +- fs/btrfs/block-rsv.h | 32 ++++++++++++++++++++++++++++++++ fs/btrfs/space-info.c | 26 +++++++++++++------------- 3 files changed, 46 insertions(+), 14 deletions(-)