bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add the .MASTER node to the eth-multiplexer.


From: Sergiu Ivanov
Subject: Re: [PATCH] Add the .MASTER node to the eth-multiplexer.
Date: Tue, 22 Dec 2009 22:07:31 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hello,

On Tue, Dec 22, 2009 at 07:37:21PM +0800, Da Zheng wrote:
> Sergiu Ivanov wrote:
> > @@ -85,6 +89,18 @@ new_node (struct lnode *ln, struct node **np)
> >  struct node *
> >  lookup (char *name)
> >  {
> > +  if (strcmp(name, MASTER_NODE_NAME) == 0)
> > +    {
> > +      netfs_nref (master_node);
> > +
> > +      /* netfs_attempt_lookup expects the returned node not to be
> > +    locked, while `master_node` might have been locked in the
> > +    previous lookups.  */
> > +      mutex_unlock (&master_node->lock);
> So the lock might or might not have been locked? Why is it so?

Take a look at netfs_impl.c:lookup(): the multiplexer creates a node
on any lookup request.  Then netfs_attempt_lookup locks this node.
OTOH, there is only one .MASTER node (and it does not correspond to
any pseudo-device).  When .MASTER is looked up for the first time, it
is locked by netfs_attempt_lookup.  Should anybody look it up the
second time, the multiplexer will hang because netfs_attempt_lookup
will try to re-lock the .MASTER node.  This is why the .MASTER node is
explicitly unlocked here.

It has just occurred to me that it might also be acceptable to not
lock the .MASTER node at all: after all, it is little more than a flag
telling the multiplexer to act differently.  What do you think?

Regards,
Sergiu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]