[OpenAFS-devel] Linux 2.6.12 kernel BUG at fs/namei.c:1189

[Rainer Toebbicke]

chas williams - CONTRACTOR wrote:

> 
> 
> linux's vfs isnt very much like irix, osf, aix or solaris.  it
> revolves around the dentry instead of the inode.  since most ports
> of afs have been to bsd derived vfs filesystems, there are few
> alternative filesystems to examine.
> 

Agreed. I just wanted to remark that the various approaches to adapt 
the AFS client to other systems all have their share of ad hoc 
decisions, a "perhaps"es and are not always crystal clean (think about 
whose credentials are used when pages are written out asynchronously).

The fact that in Linux inodes are somehow grafted on dentries doesn't 
make things easy of course - e.g. when it comes to running the cache 
on tmpfs...

> 
>>A relatively kernel-unspecific way would be to queue an event that is 
>>handled "later" by somebody running near top level. The question is a) 
>>how to queue without a lock and b) whether sometimes things must 
> 
> 
> what would be queued?  checking the inode to see if its time to go away
> or the decrement of the refCount?  queuing a .put_inode() probably isnt
> a good idea.  sleeping in .put_inode() seems to be allowed, but the
> documentation for .put_inode() isn't quite right either:
> 

in put_inode (or after your patch in dentry_iput) you need to clean 
up, i.e. call afs_InactiveVCache(). For that you need the global lock 
- which you cannot always obtain e.g. if you hold it already.

(BTW: I remember one of the comments around afs_InactiveVCache() says 
no locks required - that's obviously a lie).

My patch recovers from the failure to acquire the lock - and postpones 
the cleanup to better times. It becomes the job of the periodic vcache 
sweeper. It could also be handled through a properly managed queue 
(with it's own locking), but the sweeper is probably early enough and 
that's the easiest solution.

>   put_inode: called when the VFS inode is removed from the inode
>         cache. This method is optional
> 
> .put_inode() is called for every iput, regardless of whether the
> inode is being removed from the cache.
> 
> have you tried the patch i sent along in a previous message?  hopefully
> this should fix the problem (it will certainly take AFS_GLOCK less often).

"less often" is not enough - you'd have to guarantee that you you 
never run into it already holding the lock. Or somebody waiting for 
"you" holding the lock which can happen in the kmalloc() chain - then 
"you" that's "kswapd". I doubt that by moving the call from inode 
cleanup to dentry cleanup avoids the scenario altogether.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155