[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100127174706.GA6333@redhat.com>
Date: Wed, 27 Jan 2010 18:47:06 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org, nhorman@...driver.com,
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 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.
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.
> +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.
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