mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	miklos@szeredi.hu, linux-kernel@vger.kernel.org,
	xemul@openvz.org
Subject: Re: futex strangeness in 2.6.23-mm1/UML
Date: Tue, 23 Oct 2007 10:54:11 +0800	[thread overview]
Message-ID: <1193108052.3082.21.camel@raven.themaw.net> (raw)
In-Reply-To: <20071022213812.32bdac03@bree.surriel.com>

On Mon, 2007-10-22 at 21:38 -0400, Rik van Riel wrote:
> On Mon, 22 Oct 2007 21:11:43 -0400
> Rik van Riel <riel@redhat.com> wrote:
> 
> > I have my systems set up to automount my home directory over
> > NFS when I log in.  When trying to log in to the system with
> > 2.6.23-mm1, I get the messages from above in my syslog, and
> > the NFS filesystem is not automounted.
> > 
> > I am thinking something in autofs or the pid-namespace* patches
> > does not match up and uses a wrong PID number or process pointer
> > when trying to lock things.
> > 
> > Which code is at fault I have no idea...
> 
> I still do not know for sure, but I have found some code that
> puzzles me.
> 
> At fork() time, task->pid is set to task->pid->numbers[0].nr
> 
> On the other hand, fork() returns to the parent process:
> 
> task->pid[PIDTYPE_PID]->numbers[task->pid->level].nr
> 
> I have not unravelled the code enough yet to be sure whether
> this is always the same number, but having a wrong PID number
> somewhere could certainly explain these autofs4 errors:
> 
> Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent cache
> rwlock lock failed
> Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: 11 at
> 65 in cache.c
> 
> After all, autofs4 puts various kinds of PID information of the
> daemon into the autofs4 waitqueue:
> 
> fs/autofs4/waitq.c:296:
>                 wq->uid = current->uid;
>                 wq->gid = current->gid;
>                 wq->pid = current->pid;
>                 wq->tgid = current->tgid;
> 
> Could this be related?

Probably not wrt the pthreads lock fail.
The value passed to the daemon are used for information purposes.

The pid is used only to log who is asking for the mount.
The uid and gid are used to find user name and group name and the four
bits of user information are used to set values in the environment for
use as macros within the map.

If the values in the wait request are wrong then we probably wouldn't
even know as few people will be even aware they are available.

Ian



  reply	other threads:[~2007-10-23  2:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22 17:29 Miklos Szeredi
2007-10-22 18:53 ` Rik van Riel
2007-10-22 20:48   ` Miklos Szeredi
2007-10-22 21:29     ` Rik van Riel
2007-10-23  0:07       ` Rik van Riel
2007-10-23  0:16         ` Andrew Morton
2007-10-23  1:11           ` Rik van Riel
2007-10-23  1:38             ` Rik van Riel
2007-10-23  2:54               ` Ian Kent [this message]
2007-10-23  3:41               ` Jeff Dike
2007-10-23  7:36           ` Miklos Szeredi
2007-10-23  8:55             ` Pavel Emelyanov
2007-10-23 10:23               ` Miklos Szeredi
2007-10-23 13:52               ` Rik van Riel
2007-10-23 16:00                 ` Andrew Morton

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=1193108052.3082.21.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=riel@redhat.com \
    --cc=xemul@openvz.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®