Re: [PATCH 1/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- From: Neil Horman <nhorman@xxxxxxxxxxxxx>
- Date: Sun, 31 Jan 2010 10:41:35 -0500
On Sun, Jan 31, 2010 at 03:46:06PM +0100, Oleg Nesterov wrote:
On 01/29, Neil Horman wrote:Yeah, this will only apply to latest -mm
Add init function to usermodehelper
Convert call_usermodehelper_cleanup to usermodehelper_fns and allow it to assign
both an init function and a cleanup function.
Can't apply this patch, I guess -mm tree has other changes which
this patch depends on. However afaics this series is fine, just
a couple of nits.
Yeah, I can do that.@@ -154,7 +155,9 @@ struct subprocess_info {
enum umh_wait wait;
int retval;
struct file *stdin;
- void (*cleanup)(char **argv, char **envp);
+ int (*init)(void *data);
+ void (*cleanup)(char **argv, char **envp, void *data);
+ void *data;
OK, we add *data. But why this patch changes the prototype of ->cleanup() ?
OTOH, I completely agree, it should be changed, and it should lose the
ugly argv/envp arguments.
Since we add subprocess_info->data ptr, I think both ->init and ->cleanup
funcs should have the single arg, "subprocess_info *info". argv, envp, data
they all can be accessed via *info.
Also. It is not clear why this patch changes call_usermodehelper_setup()Yeah, that seems reasonable, Honestly, I'm a bit confused as to why there are
to set info->data. Unless the caller uses call_usermodehelper_setinit()
or call_usermodehelper_setcleanup() info->data is not used. Perhaps
it is better to have a single helper which takes (init, cleanup, data)
args.
What do you think?
set* helpers in the first place, we could just eliminate them entirely, since
callers can set all three independently with call_usermodehelper_fns. Anywho,
I'll clean that up some more.
In any case, I believe you should fix the subjects ;)Not sure whats wrong with the subjects, although I guess I am doing a good bit
more than just fixing that at this point :). I'll expand them.
Give me a few days, and I'll repost.
Neil
Oleg.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH] exec: allow core_pipe recursion check to look for a value of 1 rather than 0
- From: Neil Horman
- Re: [PATCH 0/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- From: Neil Horman
- Re: [PATCH 1/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- From: Neil Horman
- Re: [PATCH 1/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- From: Oleg Nesterov
- [PATCH] exec: allow core_pipe recursion check to look for a value of 1 rather than 0
- Prev by Date: Re: A spammer, wanting to poison our bayes seems to have found a hole at vger.kernel.org
- Next by Date: Re: bio too big - in nested raid setup
- Previous by thread: Re: [PATCH 1/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- Next by thread: Re: [PATCH 2/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)
- Index(es):
Relevant Pages
|