On Fri, 2016-03-25 at 02:28 +0100, Oleg Nesterov wrote: > Hi Ian, > > I can't really recall this old discussion, so I can be easily wrong... > > On 03/24, Ian Kent wrote: > > > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: > > > > > > IOW. Please the the "patch" below. It is obviously incomplete and > > > wrong, > > > and it can be more clear/clean. And probably we need another API. > > > Just > > > to explain what I mean. > > I hope you didn't miss this part ;) Not at all. > > In particular, we want to turn task_work_add(..., bool notify) into > task_work_add(..., how_to_notify mask) and this "mask" should allow > to force TIF_SIGPENDING. The point of posting the reply was to try and get some advice as my understanding of the signalling subsystem is fairly poor. LOL, I'll have another look at the task_work_add() code and see if I can understand what your trying to tell me. > > > > With this patch call_usermodehelper(..., UMH_IN_MY_NS) should do > > > exec > > > from the caller's namespace. > > > > Umm ... I don't think this can work. > > > > I don't think it can be assumed that the init process of a container > > will behave like an init process. > > > > If you try and do this with a Docker container that has /bin/bash as > > the > > init process signals never arrive and work doesn't start until some > > other signal arrives > > only if it blocks/ignores SIGCHLD? But this doesn't matter, see above > and > note the "until we have task_work_add_interruptibel()" in the pseudo > -code > I showed. It seems, and this is not the only case I've encountered, that the init process in docker containers can be a problem when you want to capture and handle signals. I've seen this with /bin/bash and supervisord so far. I don't know if it is the docker container creation doing this or something else .... certainly I can catch signals within subordinate processes. The other thing that occurs to me is that just about anything in a container could be subverted so the definition of a privileged process which can be used as a template form execution is essentially undefined. Mmm ... maybe I've got that wrong too, ;) Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
