[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53236662.3020707@hurleysoftware.com>
Date: Fri, 14 Mar 2014 16:28:18 -0400
From: Peter Hurley <peter@...leysoftware.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: Sree Harsha Totakura <sreeharsha@...akura.in>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: pppd service crash in linux-3.13.6
On 03/14/2014 03:23 PM, Oleg Nesterov wrote:
> On 03/14, Peter Hurley wrote:
>>
>>> On 03/13/2014 01:06 PM, Oleg Nesterov wrote:
>>>>
>>>> OTOH, why we should delay disassociate_ctty? IOW, do you see any
>>>> potential problem with the trivial patch below?
>>
>> Won't work.
>>
>> cgroup_exit() can exec a userspace process (the notify_on_exit() facility)
> ^^^^^^^^^^^^^^^^
>
> can't find anything named notify_on_exit, perhap you meant
> cgroup_release_agent? Although I guess this should not matter.
Sorry, I meant the notify_on_release() facility as discussed in the
function header comments of cgroup_exit().
Yes, cgroup_release_agent() is the work function that is scheduled.
>> which requires both namespace and tty facilities.
>
> Hmm... why?
>
> The exiting task obviously can't exec. The only way to spawn a userspace
> process is call_usermodehelper(), it should work just fine, no?
You're correct, in the immediate sense that the user command exec'd will
not inherit open file descriptors.
But what if it expects to be able to find the intact children of
the foreground process group, and can't because the controlling tty
has already been torn down and all the children already sent SIGHUP.
I know that's not what the user command is intended for, but
userspace can be enterprising for establishing dependencies on
kernel constructs.
Or what if the user command expects to find and join the user namespace
of the dying process but now it's already been freed?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists