Messages in this thread | | | Date | Fri, 9 Jul 1999 00:33:38 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: NFS lockd |
| |
On Thu, 8 Jul 1999, H.J. Lu wrote:
> > > > I have a NFS-related question for you: in fs/lockd/clntlock.c::reclaimer() > > we have a very suspiciously-looking place - loop over the active locks > > runs by ->fl_next, not ->fl_nextlink. AFAICS it's a bug, but I'ld like to > > hear your confirmation on that. Comments? > > I am not familiar with the code. Does anyone have comments?
OK, AFAICS the thing is supposed to kick in on the clients when server recovers after the reboot. It should look through the list of locks we were holding and try to reacquire them. Current variant does very odd thing - it reacquires some locks on one file (more or less random one, at it). ->fl_next holds the list of active locks on given inode. ->fl_{next,prev}link holds the list of all active locks.
reclaimer() starts in file_lock_table (head of ->fl_nextlink list) and goes by ->fl_next. Notice that reclaimer() is a kernel thread. Unless something, somewhere cares to launch such a thread for every file with a lock *and* reshuffle the global list we have a typo ;-) Otherwise we have a *really* elaborated sabotage.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |