Re: futex() on vdso makes process unkillable

From: KOSAKI Motohiro
Date: Mon Jan 25 2010 - 02:28:08 EST


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.


--
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/