Hi. I found a suspected bug while I review nfs_free_seqid() in nfs4state.c
It seems that nfs_free_seqid() tried to use "test and test-set" idiom
(double checked locking)
but the second "test" is missed so that It may occur data race when
other thread makes
&seqid->list not empty before the thread executiong nfs_free_seqid()
holds spin_lock(&sequence->lock) after checking !list_empty(&seqid->list).
I do not have much background for nfs so that it might not be a real bug
so please review the code and let me know whether it is real one or not.
Thanks.
Sincerely,
Shin Hong
On Thu, 2009-01-15 at 19:53 +0900, =ED=99=8D=EC=8B=A0 shin hong wrote:
> Hi. I found a suspected bug while I review nfs_free_seqid() in nfs4st=
ate.c
>=20
> It seems that nfs_free_seqid() tried to use "test and test-set" idiom
> (double checked locking)
> but the second "test" is missed so that It may occur data race when
> other thread makes
> &seqid->list not empty before the thread executiong nfs_free_seqid()
> holds spin_lock(&sequence->lock) after checking !list_empty(&seqid->l=
ist).
>=20
> I do not have much background for nfs so that it might not be a real =
bug
> so please review the code and let me know whether it is real one or n=
ot.
> Thanks.
Hi,
Unlike the struct rpc_sequence, the struct nfs_seqid is always owned by
a single process, so there is no race here.
Cheers
Trond