Re: Race between vmtruncate and mapped areas?

[Daniel McNeil <daniel@osdl.org>]

On Thu, 2003-05-15 at 12:19, Andrea Arcangeli wrote:
> On Thu, May 15, 2003 at 09:38:26AM -0700, Daniel McNeil wrote:
> > On Thu, 2003-05-15 at 02:40, Andrea Arcangeli wrote:
> > > On Thu, May 15, 2003 at 02:20:00AM -0700, Andrew Morton wrote:
> > > > Andrea Arcangeli <andrea@suse.de> wrote:
> > > > >
> > > > > and it's still racy
> > > > 
> > > > damn, and it just booted ;)
> > > > 
> > > > I'm just a little bit concerned over the ever-expanding inode.  Do you
> > > > think the dual sequence numbers can be replaced by a single generation
> > > > counter?
> > > 
> > > yes, I wrote it as a single counter first, but was unreadable and it had
> > > more branches, so I added the other sequence number to make it cleaner.
> > > I don't mind another 4 bytes, that cacheline should be hot anyways.
> > 
> > You could use the seqlock.h sequence locking.  It only uses 1 sequence
> > counter.  The 2.5 isize patch 1 has a sequence lock without the spinlock
> > so it only uses 4 bytes and it is somewhat more readable.  I don't
> > think it has more branches.
> > 
> > I've attached the isize seqlock.h patch.
> 
> what do you think of the rmb vs mb in the reader side? Can I use rmb
> too? I used mb() to go safe. I mean gettimeofday is a no brainer since
> it does only reads inside the critical section anyways. But here I feel
> I need mb().
> 
> 
> And yes, there are no more branches sorry, just an additional or.
> 
> Andrea

rmb() is safe on the read side.  In fact, The mb()s only need to be
smp_rmb()s and the wmb()s only need to be smp_wmb()s.

Also, the mb() after the spin_lock(&mm->page_table_lock);
is not even needed since spin_lock() acts as a memory barrier.

Why do you feel you need the mb()?
Isn't everything the reader might do protected already?
You just using the sequence value to know whether you should
cleanup and retry.

Also, I like using the seqlock.h approach since it gives consistent
use of sequence locks, is a bit more readable, and documents and hides
all the memory barrier stuff.

Is there any possibility that the truncate side can run faster than
the reader side?  
-- 
Daniel McNeil <daniel@osdl.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>