Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Dec 2012 05:13:44 +0000
From: Al Viro <>
To: "Eric W. Biederman" <>
Cc: Vasily Kulikov <>,
	Containers <>,
	Serge Hallyn <>,
	"Serge E. Hallyn" <>,,
Subject: Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts

On Fri, Dec 28, 2012 at 08:05:32PM -0800, Eric W. Biederman wrote:

> Yes.  Gcc can't turn a tail call into a jump in even the most basic
> cases apparently.

What.  The.  Fuck?

You have introduced unlimited recursion on kernel stack.  OK, it's
unpleasant, but it can happen to anybody.  But then you have the gall
to complain about gcc optimizations not saving your broken code.  Are
you serious?

It's not a question of gcc being not smart enough, and while we are
at it, it's *not* a basic case at all - we have recursion going through
the callback and we have non-trivial return value on top of that; if
the caller of kref_put() had checked said return value, you would've
been unable to turn that into a loop at all.

Are you seriously saying that you relied on compiler being smart enough
	* notice that return value of kref_put() is ignored
	* notice that therefore the return value of kref_sub() is ignored
	* notice that you have this call of put_user_ns() calling
kref_put() calling kref_sub() inside the callback we'd passed through the
last two levels of calls and that we are dealing with the tail recursion
... so that your code wouldn't have stepped into unlimited recursion?
I sincerely hope that you are not that much of an idiot.  If nothing else,
even if gcc did spot that one, the result would've been extremely brittle -
minor change to kref.h several year down the road and we'd get the problem.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.