Re: [f2fs-dev] [bug report] potential order violation bug in 'fs/f2fs/segment.c', in '__create_discard_cmd'

[Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>]

On 4/23/26 13:48, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential atomicity bug
> within the 'fs/f2fs' subsystem, more specifically, in
> 'fs/f2fs/segment.c'.
> 
> Kernel version: long-term kernel v6.18.9
> 
> Potential concurrent triggering executions:
> T0:
> __create_discard_cmd
>       --> dc = f2fs_kmem_cache_alloc(discard_cmd_slab, GFP_NOFS, true, NULL);
>       --> list_add_tail(&dc->list, pend_list);
>       --> spin_lock_init(&dc->lock);
>       --> dc->bio_ref = 0;

Hi,

Actually, fields of dc entries are protected by dcc->cmd_lock, so it should be
fine? it needs to fix static analyzer? IIUC.

Thanks,

> 
> In T0, the freshly allocated 'struct discard_cmd *dc' is first added
> to the globally visible list 'pend_list' (i.e., from
> dcc->pend_list[plist_idx(len)]'.
> However, its fields like 'dc->lock' and 'dc->bio_ref' are set up after
> being globally visible.
> This violated the expected order of setting up private local heap
> variables before exposing them to the global state, causing potential
> concurrency bugs with '__issue_discard_cmd()' or
> '__submit_discard_cmd()' within 'fs/f2fs/segment.c'.
> 
> Please kindly check at your convenience. Thank you for your time and
> consideration.
> 
> Best regards,
> Ginger



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel