Re: [RFC][PATCH] Fix hang in posix_locks_deadlock()



On Wed, Oct 17, 2007 at 02:51:57PM -0400, George G. Davis wrote:
---
Not sure if this is the correct fix but it does resolve the hangs we're
observing in posix_locks_deadlock().

Please disregard the previous patch, it's not quite right - causes occasional
segfaults and clearly did not retain the posix_same_owner() checks implemented
in the original code. Here's a new version which I believe retains the
intent of the original code:

diff --git a/fs/locks.c b/fs/locks.c
index 7f9a3ea..e012b27 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -702,14 +702,12 @@ static int posix_locks_deadlock(struct file_lock *caller_fl,
{
struct file_lock *fl;

-next_task:
if (posix_same_owner(caller_fl, block_fl))
return 1;
list_for_each_entry(fl, &blocked_list, fl_link) {
if (posix_same_owner(fl, block_fl)) {
- fl = fl->fl_next;
- block_fl = fl;
- goto next_task;
+ if (posix_same_owner(caller_fl, fl))
+ return 1;
}
}
return 0;


I'm not sure about those "fl = fl->fl_next; block_fl = fl;" statements,
first, the order of those statements seems reversed to me. Otherwise,
I think the intent was to advance the "fl" for loop variable to the next
entry in the list but it doesn't work out that way at all - the for
loop restarts from the beginning - this is where we get into an
infinite loop condition. Whether the test case I posted before is
valid or not, I reckon it shouldn't be possible for non-root Joe user
to contrive a test case which can hang the system as we're observing
with that test case. The above patch fixes the hang.

Comments greatly appreciated...

--
Regards,
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [RFC][PATCH] Fix hang in posix_locks_deadlock()
    ... observing in posix_locks_deadlock. ... I think the intent was to advance the "fl" for loop variable to the next ... to contrive a test case which can hang the system as we're observing ... The above patch fixes the hang. ...
    (Linux-Kernel)
  • Re: [patch] properly stop devices before poweroff
    ... I guess the stream of badness was occured as follows: ... I think the following patch will remove this stream of badness. ... By the way, I don't think this stream of badness is related to hang up, ...
    (Linux-Kernel)
  • Re: rpc.lockd brokenness (2)
    ... I'm unable to verify if the patch ... I do have a lockd hang, ... Can anybody else verify if the system hangs on pidfile_open when: ...
    (freebsd-stable)
  • Re: Better news
    ... SO hang in there. ... I quit long-term once before for 5 yrs using the patch. ... Been on the verge of quitting again for awhile now (aren't we ... DO need to clean for other reasons though! ...
    (alt.support.arthritis)
  • Re: Better news
    ... SO hang in there. ... I quit long-term once before for 5 yrs using the patch. ... Been on the verge of quitting again for awhile now (aren't we ... Mike has no school today and I'm taking the day off to do the floor. ...
    (alt.support.arthritis)