Re: futex() on vdso makes process unkillable

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

Hi

> CC to futex folks.
> 
> > I was experimenting with futexes and was a little surprised to
> > discover that futex() works on read-only pages.  This creates quite a
> > high bandwidth side channel that allows two processes to communicate
> > if, for example, they share a library.  (Mind you, this is not much
> > different from file locks, which also work on read-only file
> > descriptors.)
> > 
> > I also found a couple of differences between 2.6.24 (from Ubuntu
> > hardy) and 2.6.31 (from Ubuntu karmic).  The first is a definite bug
> > in 2.6.31:
> > 
> > 1) On 2.6.31 i686, using futex() on the vdso causes the process to get
> > stuck, consuming CPU in an unkillable state.  Both FUTEX_WAIT and
> > FUTEX_WAKE cause the problem.  The problem doesn't occur on 2.6.24.
> > (BTW, I was testing to see whether futex() on the vdso allows any two
> > processes to communicate.  This appears not to be the case on 2.6.24.)
> > 
> > A test program is below.
> > 
> > 
> > 2) Suppose a file is mapped into two processes with MAP_PRIVATE.  Can
> > the resulting mappings be used to communicate via futex()?  i.e. Does
> > futex() consider the mappings to be the same?
> > 
> > On 2.6.24, the futex wakeup is not transferred; pages must be mapped
> > with MAP_SHARED for futex to work.  On 2.6.31, the futex wakeup *is*
> > transferred; futex works with either MAP_SHARED or MAP_PRIVATE.
> > 
> > 2.6.24's behaviour seems more correct, because the mappings are
> > logically different, even if the underlying memory pages are the same
> > before copy-on-write is triggered.  Is 2.6.31's behaviour a
> > regression, or is the kernel's behaviour here supposed to be
> > undefined?

Futex should work both file anon anon. however I personally think 
vdso is not file nor anon. it is special mappings. nobody defined
futex spec on special mappings. (yes, undefined).

Personally, I think EINVAL or EFAULT are best result of vdso futexing, like as
futexing againt kernel address. but I guess another person have another thinking.

I'd like to hear futex folks's opinion.


Thanks.