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

[Da Zheng]

Sergiu Ivanov wrote:
> 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.
netfs_attempt_lookup locks this node and the node is unlocked by libnetfs, 
right? I forget a lot:-)
So why can the second lookup not wait until the first one finishes? Or do you 
think there will be a dead lock?
When we do the normal file lookup, it's also possible that two programs look up 
the same file at the same time. It seems OK. Does other filesystems use the 
same trick as you do?
> 
> 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?
> 
.MASTER is almost completely static. I guess it should be OK if we don't lock 
it.

Zheng Da