> >
> > 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/