lkml.org 
[lkml]   [2009]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] autofs: fix the wrong usage of the deprecated task_pgrp_nr()
On 01/19, Serge E. Hallyn wrote:
>
> Quoting Oleg Nesterov (oleg@redhat.com):
> >
> > Actually, I am very much surprized this one-liner patch has so
> > many questions. Isn't it "obiously correct" ?
>
> I'm not sure which one-liner you're talking about. In fact,
> the patch I'm looking at right now isn't the one i looked at
> before my last response. Dangit.
>
> The patch turning the cached pid_t into a struct pid is
> certainly mostly right. It shouldn't store a pid_t.

This is the next patch. This one does

--- CUR/fs/autofs/inode.c~1_AUTOFS 2009-01-12 23:07:46.000000000 +0100
+++ CUR/fs/autofs/inode.c 2009-01-18 06:18:49.000000000 +0100
@@ -78,7 +78,7 @@ static int parse_options(char *options,

*uid = current_uid();
*gid = current_gid();
- *pgrp = task_pgrp_nr(current);
+ *pgrp = task_pgrp_vnr(current);

*minproto = *maxproto = AUTOFS_PROTO_VERSION;

> But as for passing pid_t's in from userspace

passing pid_t's in from userspace uses current namespace, with
or without the patch.

> and especially
> printing them out in error messages, I believe what Ian was
> trying to do before, which seemed sensible, was to always
> use values in the init_pid_ns. After all, if you do a DPRINTK
> with pid_vnr(somepid), then by the time a human reads the logs
> the subjective pidns might no longer exist. So for logs I'd
> tend to agree with printing out the pid_t in the init_pid_ns.

OK, may be this makes sense, this was not discussed yet. This
can be changed. But otoh, if this code runs within the sub
namespace, then it is not easy to see why oz_mode == true
if we print the value in init_pid_ns.

Oleg.


\
 
 \ /
  Last update: 2009-01-19 21:09    [W:0.073 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site