Re: [PATCH] fsstack: fsstack_copy_inode_size locking

[Hugh Dickins]

On Mon, 30 Jun 2008, hooanon05@xxxxxxxxxxx wrote:
> Hugh Dickins:
> > LTP's iogen01 doio tests used to hang nicely on 32-bit SMP when /tmp was a
> > unionfs mount of a tmpfs, i_size_read spinning forever, waiting for a lost
> > seqcount update: fixed by taking i_lock around i_size_write when 32-bit SMP.

(That, of course, is already fixed in Erez's unionfs git, so in mm;
but I thought I'd better repeat the history because some of akpm's
objections to pushing the fix to mainline came from the lack of
this explanation when the patch was submitted for mainline.)

> 
> I don't know why dst->i_lock is affected by src->i_size_seqcount.

It certainly shouldn't be.  The problem would have come from two
racing i_size_write(dst)s, one of the unlocked increments getting
lost, leaving seqcount odd, so the next i_size_read(dst) would
spin forever waiting for it to go even.

> Do you mean that your test issued write(2) to the lower/actual file

I was merely running LTP, on a Core(2) Quad machine, with /tmp as
unionfs mount of a tmpfs.  It wouldn't have been doing anything
directly to the lower file, that would all have been coming via
the unionfs mount.

> so frequently that i_size_read() in unionfs always failed?

I'm not sure what you mean by that.  i_size_read() doesn't fail,
but it may loop; and if the seqcount has got out of step from
concurrent unlocked i_size_write()s, then it'll spin forever.

> 
> Is your test
> iogen01 export LTPROOT; rwtest -N iogen01 -i 120s -s read,write -Da -Dv -n 2 500b:doio.f1.$$ 1000b:doio.f2.$$
> line in runtest/fs?

That looks like it: I don't think I ever tried it as a standalone test,
just investigated what was happening when standard LTP runs hung here.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/