On 10/17, Martin Schwidefsky wrote:
>
> On Thu, 16 Oct 2014 23:58:34 +0200
> Oleg Nesterov wrote:
>
> > I also agree that the changelog could mention exec_mmap. Plus a comment
> > about UMH_NO_WAIT && sub_info->complete == NULL. So yes, perhaps v2 makes
> > sense if Martin agrees.
>
> Version 2 of
On Thu, 16 Oct 2014 23:58:34 +0200
Oleg Nesterov wrote:
> I also agree that the changelog could mention exec_mmap. Plus a comment
> about UMH_NO_WAIT && sub_info->complete == NULL. So yes, perhaps v2 makes
> sense if Martin agrees.
Version 2 of the patch. All change requests have gone in except
On Thu, 16 Oct 2014 23:58:34 +0200
Oleg Nesterov wrote:
> On 10/17, Tetsuo Handa wrote:
> >
> > Ah, I see. Here is a draft of an updated patch.
>
> Do you mean this part
>
> > sub_info->retval = retval;
> > + /* wait_for_helper() will call umh_complete() if UMH_WAIT_PROC.
On Fri, 17 Oct 2014 06:30:29 +0900
Tetsuo Handa wrote:
> Regarding UMH_NO_WAIT, the sub_info structure can be freed by
> __call_usermodehelper() before the worker thread returns from
> do_execve(), allowing memory corruption when do_execve() failed
> after exec_mmap() is called.
>
> Regarding UM
On 10/17, Tetsuo Handa wrote:
>
> Ah, I see. Here is a draft of an updated patch.
Do you mean this part
> sub_info->retval = retval;
> + /* wait_for_helper() will call umh_complete() if UMH_WAIT_PROC.
*/
> + if (wait != UMH_WAIT_PROC)
> +
Oleg Nesterov wrote:
> On 10/17, Tetsuo Handa wrote:
> >
> > For both UMH_NO_WAIT and UMH_WAIT_EXEC cases,
> >
> > kernel_thread(call_helper, sub_info, CLONE_VFORK | SIGCHLD)
> >
> > in __call_usermodehelper() waits for do_execve() to succeed or do_exit(),
>
> Well, not really. kernel_thread(CLO
6 matches
Mail list logo