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

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

[Ginger]

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;

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

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

[Chao Yu]

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