> 1. Race in `xfs_bmapi_reserve_delalloc()` and `xfs_vn_getattr()` > ---------------------------------------------------------------- > > A data race on `ip->i_delayed_blks`. This is indeed a case for data_race as getattr is just reporting without any locks. Can you send a patch? > 2. Race on `xfs_trans_ail_update_bulk` in `xfs_inode_item_format` > -------------------------------------. > > We observed unsynchronized access to `lip->li_lsn`, which may exhibit > store/load tearing. However, we did not observe any symptoms > indicating harmful behavior. I think we'll need READ_ONCE/WRITE_ONCE here to be safe on 64-bit systems to avoid tearing/reordering. But that still won't help with 32-bit systems. Other lsn fields use an atomic64_t for, which is pretty heavy-handed. > Function: xfs_alloc_longest_free_extent+0x164/0x580 > Function: xfs_alloc_update_counters+0x238/0x720 fs/xfs/libxfs/xfs_alloc.c:908 Both of these should be called with b_sema held. Does your tool treat a semaphore with an initial count of 1 as a lock? That is still a pattern in Linux as mutexes don't allow non-owner unlocks. > 4. Race on `pag->pagf_longest` > ------------------------------ > > Similar to the previous race, this field appears to be safely used > under current access patterns. Same here I think. > > Possibly Harmful Race > ====================== > > 1. Race on `bp->b_addr` between `xfs_buf_map_pages()` and `xfs_buf_offset()` > ---------------------------------------------------------------------------- And I think this is another case of b_sema synchronization unless I'm missing something.
