[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100127212511.GB15052@hmsreliant.think-freely.org>
Date: Wed, 27 Jan 2010 16:25:11 -0500
From: Neil Horman <nhorman@...driver.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
abelay@....edu, benh@...nel.crashing.org,
drbd-dev@...ts.linbit.com, gregkh@...e.de, jmoskovc@...hat.com,
menage@...gle.com, mfasheh@...e.com, mingo@...hat.com,
neilb@...e.de, shemminger@...ux-foundation.org, spock@...too.org,
t.sailer@...mni.ethz.ch, takedakn@...data.co.jp,
viro@...iv.linux.org.uk
Subject: Re: +
exec-allow-core_pipe-recursion-check-to-look-for-a-value-of-1-rather
-than-0.patch added to -mm tree
On Wed, Jan 27, 2010 at 06:47:06PM +0100, Oleg Nesterov wrote:
> On 01/26, Andrew Morton wrote:
> >
> > From: Neil Horman <nhorman@...driver.com>
> >
> > What I've done is modify the
> > call_usermodehelper() api such that an extra parameter is added, a
> > function pointer which will be called by the user helper task, after it
> > forks, but before it execs the required process.
>
> Personally I agree, I think this fptr can be useful, not only for coredump.
>
> > This will give the
> > caller the opportunity to get a callback in the process's context,
> > allowing it to do whatever it needs to to the process in the kernel
>
> in this case it probably needs "void *data" argument, otherwise the
> usage is very limited.
>
I'd thought of that, but I wasn't sure what data would be passed that the caller
wouldn't already be able to glean. Certainly not opposed to adding something of
that nature though.
> Currently only d_coredump() needs this new feature, but please note
> that ____call_usermodehelper() was already "uglified" for the coredumping
> over the pipe.
>
> If we add sub_info->finit(), then probably we should move the code
> under "if (sub_info->stdin)" from ____call_usermodehelper() to
> core_pipe_setup() ?
>
> > +/*
> > + * This is used as a helper to set up the task that execs
> > + * our user space core collector application
> > + * Its called in the context of the task thats going to
> > + * exec itself to be the helper, so we can modify current here
> > + */
>
> very minor nit, perhaps the comment should explain what is the meaning
> of the magical rlim_cur = 1 value? It is not immediately obvious we
> check cprm.limit == 1 below.
>
Yeah, Andrew asked me to clean up that comment as well, I'll post a follow on
patch after I tinker with the suggestions in this email and your other note as
well for a bit.
> > +void core_pipe_setup(void)
> > +{
> > + task_lock(current->group_leader);
> > + current->signal->rlim[RLIMIT_CORE].rlim_cur = 1;
> > + task_unlock(current->group_leader);
> > +}
>
> Well, this thread must be the kernel thread and thus it should be
> ->group_leader and I don't think we really need task_lock() her,
> but this is minor and perhaps ->group_leader + task_lock() look
> better even if not needed.
>
Perhaps, I wasn't sure, I was just following the code used by the core limit
proc write patch series.
Neil
> Oleg.
>
>
--
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