[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6acd0aea-2e7b-e30e-214f-81f4c3766ead@linux.alibaba.com>
Date: Thu, 12 Jan 2023 11:58:27 +0800
From: Jingbo Xu <jefflexu@...ux.alibaba.com>
To: David Howells <dhowells@...hat.com>,
Hou Tao <houtao@...weicloud.com>
Cc: linux-cachefs@...hat.com, Jeff Layton <jlayton@...nel.org>,
linux-erofs@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
houtao1@...wei.com
Subject: Re: [PATCH v2 1/2] fscache: Use wait_on_bit() to wait for the freeing
of relinquished volume
On 1/12/23 12:06 AM, David Howells wrote:
> Hou Tao <houtao@...weicloud.com> wrote:
>
>> clear_bit(FSCACHE_VOLUME_ACQUIRE_PENDING, &cursor->flags);
>> + /*
>> + * Paired with barrier in wait_on_bit(). Check
>> + * wake_up_bit() and waitqueue_active() for details.
>> + */
>> + smp_mb__after_atomic();
>> wake_up_bit(&cursor->flags, FSCACHE_VOLUME_ACQUIRE_PENDING);
>
> What two values are you applying a partial ordering to?
Yeah Hou Tao has explained that a full barrier is needed here to avoid
the potential reordering at the waker side.
As I was also researching on this these days, I'd like to share my
thought on this, hopefully if it could give some insight :)
Without the barrier at the waker side, it may suffer from the following
race:
```
CPU0 - waker CPU1 - waiter
if (waitqueue_active(wq_head)) <-- find no wq_entry in wq_head list
wake_up(wq_head);
for (;;) {
prepare_to_wait(...);
# add wq_entry into wq_head list
if (@cond) <-- @cond is false
break;
schedule(); <-- wq_entry still in
wq_head list,
wait for next wakeup
}
finish_wait(&wq_head, &wait);
@cond = true;
```
in which case the waiter misses the wakeup for one time.
--
Thanks,
Jingbo
Powered by blists - more mailing lists