UBIFS: possible bug for the absence of memory barrier

UBIFS: possible bug for the absence of memory barrier

[홍신 shin hong]

Hello. I am reporting the possible bugs caused by absence of memory barriers.

Since I do not have much background,
I can not convince that the codes are buggy.
But I hope that this report is helpful.
Please examine the issue and let me know your opinion.

In add_replay_bud() of UBIFS in Linux 2.6.30.5, it newly allocate a bud_entry
object and initialize and then link it to the replay_buds list.

The last initialization operation is "b->sqnum = sqnum ;" and
the linking to the list "list_add_tail(&b->list, &c->replay_buds;".

However, since there is no memory barrier between these two,
the execution order might be changed
so that uninitialized data might be accessible to other threads.

Therefore, race condition might occur and it may result error.

Please examine this issue.
Thank you

Sincerely
Shin Hong

Re: UBIFS: possible bug for the absence of memory barrier

[Adrian Hunter]

홍신 shin hong wrote:
> Hello. I am reporting the possible bugs caused by absence of memory barriers.
> 
> Since I do not have much background,
> I can not convince that the codes are buggy.
> But I hope that this report is helpful.
> Please examine the issue and let me know your opinion.
> 
> In add_replay_bud() of UBIFS in Linux 2.6.30.5, it newly allocate a bud_entry
> object and initialize and then link it to the replay_buds list.
> 
> The last initialization operation is "b->sqnum = sqnum ;" and
> the linking to the list "list_add_tail(&b->list, &c->replay_buds;".
> 
> However, since there is no memory barrier between these two,
> the execution order might be changed
> so that uninitialized data might be accessible to other threads.
> 
> Therefore, race condition might occur and it may result error.
> 
> Please examine this issue.
> Thank you
> 
> Sincerely
> Shin Hong

A race is not possible because there is only one thread that can be
replaying because it is only done when mounting.