LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ian Kent <raven@themaw.net>
Cc: Cedric Le Goater <clg@fr.ibm.com>,
sukadev@us.ibm.com, Andrew Morton <akpm@osdl.org>,
Dave Hansen <haveblue@us.ibm.com>,
Serge Hallyn <serue@us.ibm.com>,
Herbert Poetzl <herbert@13thfloor.at>,
containers@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference
Date: Fri, 16 Mar 2007 13:21:51 -0600 [thread overview]
Message-ID: <m1hcslm1tc.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1174063618.3397.58.camel@raven.themaw.net> (Ian Kent's message of "Sat, 17 Mar 2007 01:46:58 +0900")
Ian Kent <raven@themaw.net> writes:
> On Fri, 2007-03-16 at 15:44 +0100, Cedric Le Goater wrote:
>> > How about you send over the autofs4 bit and I'll have a look (the autofs
>> > patch looked fine). That would save me a bit of time and if there are
>> > any changes needed I can send an updated patch for you guys to review. I
>> > don't think autofs4 uses pids differently, in principle, than autofs so
>> > it "should" be straight forward.
>>
>> Here's the latest.
>
> That looks OK to me, assuming the "find_get_pid" and friends do what
> they suggest, but I'll give it a closer look tomorrow.
>
> A ref count is used here, what affect does that have on a thread (or
> process) that may go away (or be summarily killed) without umounting the
> mount?
Nothing.
The primary advantage is that you are pid wrap around safe as the struct
pid will never point to another process after one of those events occurs.
struct pid is a very small structure so not freeing it when the process
it originally referred to goes away is no big deal. Although not leaking
when you stop using it is still important.
The other big use of struct pid is that to get the user space pid value
you call pid_nr(). Depending on the pid namespace of the caller the return
value of pid_nr() can be different. So when you store a pid or pass a pid
between processes that should be done by passing a struct pid because those
processes could be in different pid namespaces.
>> Index: 2.6.20/fs/autofs4/waitq.c
>> ===================================================================
>> --- 2.6.20.orig/fs/autofs4/waitq.c
>> +++ 2.6.20/fs/autofs4/waitq.c
>> @@ -292,8 +292,8 @@ int autofs4_wait(struct autofs_sb_info *
>> wq->ino = autofs4_get_ino(sbi);
>> wq->uid = current->uid;
>> wq->gid = current->gid;
>> - wq->pid = current->pid;
>> - wq->tgid = current->tgid;
>> + wq->pid = pid_nr(task_pid(current));
>> + wq->tgid = pid_nr(task_tgid(current));
>> wq->status = -EINTR; /* Status return if interrupted */
>> atomic_set(&wq->wait_ctr, 2);
>> mutex_unlock(&sbi->wq_mutex);
I have a concern with this bit as I my quick review said the wait queue
persists, and if so we should be cache the struct pid pointer, not the
pid_t value. Heck the whol pid_nr(task_xxx(current)) idiom I find very
suspicious.
Eric
next prev parent reply other threads:[~2007-03-16 19:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 4:51 sukadev
2007-03-16 4:04 ` Ian Kent
2007-03-16 11:32 ` Eric W. Biederman
2007-03-16 14:31 ` Ian Kent
2007-03-16 14:44 ` Cedric Le Goater
2007-03-16 16:46 ` Ian Kent
2007-03-16 19:21 ` Eric W. Biederman [this message]
2007-03-19 20:08 ` Serge E. Hallyn
2007-03-19 20:40 ` Eric W. Biederman
2007-03-19 21:19 ` Serge E. Hallyn
2007-03-19 21:43 ` Eric W. Biederman
2007-03-20 20:15 ` Serge E. Hallyn
2007-03-20 20:45 ` Eric W. Biederman
2007-03-20 21:41 ` Serge E. Hallyn
2007-03-20 22:01 ` Eric W. Biederman
2007-03-21 20:58 ` Serge E. Hallyn
2007-03-22 2:28 ` Ian Kent
2007-03-22 14:33 ` Herbert Poetzl
2007-03-22 15:03 ` Ian Kent
2007-03-22 15:29 ` Eric W. Biederman
2007-03-22 15:22 ` Eric W. Biederman
2007-03-22 18:07 ` Serge E. Hallyn
2007-03-22 2:00 ` Ian Kent
2007-03-22 2:19 ` Serge E. Hallyn
2007-03-22 3:18 ` Ian Kent
2007-03-22 13:31 ` Serge E. Hallyn
2007-03-22 14:48 ` Ian Kent
2007-03-22 15:06 ` Ian Kent
2007-03-22 6:43 ` Eric W. Biederman
2007-03-22 13:28 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1hcslm1tc.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
--subject='Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).