[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Aug 2006 14:57:11 +0200
From: Eric Dumazet <dada1@...mosbay.com>
To: Andi Kleen <ak@...e.de>
Cc: Ravikiran G Thirumalai <kiran@...lex86.org>,
"Shai Fultheim (Shai@...lex86.org)" <shai@...lex86.org>,
pravin b shelar <pravin.shelar@...softinc.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] NUMA futex hashing
On Tuesday 08 August 2006 14:47, Andi Kleen wrote:
> On Tuesday 08 August 2006 14:29, Eric Dumazet wrote:
> > On Tuesday 08 August 2006 12:36, Andi Kleen wrote:
> > > > We may have special case for PRIVATE futexes (they dont need to be
> > > > chained in a global table, but a process private table)
> > >
> > > What do you mean with PRIVATE futex?
> > >
> > > Even if the futex mapping is only visible by a single MM mmap_sem is
> > > still needed to protect against other threads doing mmap.
> >
> > Hum... I would call that a user error.
> >
> > If a thread is munmap()ing the vma that contains active futexes, result
> > is undefined.
>
> We can't allow anything that could crash the kernel, corrupt a kernel,
> data structure, allow writing to freed memory etc. No matter how
> defined it is or not. Working with a vma that doesn't have
> an existence guarantee would be just that.
As I said, we do not walk the vmas anymore, no crashes are ever possible.
Just keep a process private list of 'private futexes' , indexed by their
virtual address. This list can be of course stored in a efficient data
structure, an AVL or RB tree, or hash table.
The validity of the virtual address is still tested by normal get_user()
call.. If the memory was freed by a thread, then a normal EFAULT error will
be reported... eventually.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists