[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1307473581.3091.61.camel@edumazet-laptop>
Date: Tue, 07 Jun 2011 21:06:21 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Andrew Lutomirski <luto@....edu>
Cc: Darren Hart <dvhart@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
David Oliver <david@...advisors.com>,
linux-kernel@...r.kernel.org,
Shawn Bohrer <sbohrer@...advisors.com>,
Zachary Vonler <zvonler@...advisors.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Hugh Dickins <hughd@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: Change in functionality of futex() system call.
Le mardi 07 juin 2011 à 14:43 -0400, Andrew Lutomirski a écrit :
> I have some software I'm working on that uses shared files and could
> easily use futexes. I don't want random read-only processes to
> interfere with the futex protocol.
Relying on kernel doing 'the right thing for you' wont work on old
kernels. Some people still want to run 2.6.18 ones, for very good
reasons. Also this 'magical protection' is not documented on man pages,
so this is would be a bad choice.
Regression being one year old, you can bet many machines run with
previous behavior (safe too, unless your application design is not
secured)
> There's a difference between slowing down users by abusing a kernel
> hash and deadlocking users by eating a wakeup. (If you eat a wakeup
> the wakeup won't magically come back later. It's gone.)
Sure, you could let messages queues, named pipes, being readable as
well. Or your files being writeable, who knows, and lost your data too.
I dont know why I even discuss the point. A regression was added, you
cant justify it saying futexes were insecure from 2002 to 2010.
--
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