On Mon, May 20, 2013 at 05:10:01PM +0200, Oleg Nesterov wrote:
> On 05/20, Stanislav Kinsbursky wrote:
> >
> > Moreover, set_fs_root() is not exported.
>
> Then it should be exported, I think ;)
Maybe--there are objections, see below.
> Or you can export the new helper.
>
> > And adding an ability of a root swap to usermode helper looks quite
> > logical. At least from the
> > "containers" point of view, which usually have it's own root.
>
> But it is not logical to uglify the code, imho.
>
> OK, why nfs can't simply use this code
>
> static int umh_set_fs_root(struct subprocess_info *info, struct cred
> *new)
> {
> set_fs_root(current->fs, sub_info->data);
> return 0;
> }
>
> int call_usermodehelper_root(char *path, char **argv, char **envp, int
> wait,
> struct path *root)
> {
>
> struct subprocess_info *info;
>
> info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
> umh_set_fs_root, NULL,
> root);
> if (info == NULL)
> return -ENOMEM;
> return call_usermodehelper_exec(info, wait);
> }
Right, that's more or less what Stanislav proposed before:
https://patchwork.kernel.org/patch/2449081/
(though with an open-coded set_fs_root). Jeff and I asked him to try
this approach instead.
> ? Why do you want to add the new member, the new arguments, the new helpers?
- It's simpler for callers to be able to say "run this help in
that namespace" in a single line. We expect there will be
more such callers, so the mild complication of the API seems
worth it for the convenience.
- set_fs_root looks like something that shouldn't really be used
outside of a small number of well-known callers in core code.
This has come up a few times before; one I could find on a quick
search:
http://thread.gmane.org/gmane.linux.kernel/267932/focus=267998
Consensus there seems to be that users of the previously
exported set_fs_root were mostly buggy. And specifically that
adding the parameter to the usermode_helper api would be safer
than exporting set_fs_root.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
