lkml.org 
[lkml]   [1999]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] __lock_sock race condition in 2.3.18*
Date
Hello!

> lhash lock. Do you see it? I am rather certain this is a problem
> even if it is not exactly the case Andrea is seeing.

.................!!!!!! [ Relax. Keyboard in innocent. 8) ]

I bet it is exactly the thing which Angrea sees. /proc/net/tcp
violates main anti-dead lock rule.


> 2) Are you sure lhash wlock attempts (and thus potential sleeps)
> cannot happen from BH context? Consider case where during user
> context listening socket destruction some dangling reference
> remains, BH deletes final reference and performs final listening
> socket destruction. Or am I missing something?

Transitions LISTEN <-> CLOSE occur only in process context.



It was the only thing which was able to save us of intrinsic
lock clash, but I cheated myself and used it incorrectly.

OK... Then scenario #2 (refused earlier) is still appropriate.
But it will cost us spinlock in accept() and, seems, closes
perspective to make backlog processing in release_sock()
not holding spinlock...

Do you see? We kill sleep lock for lhash and revert it to rwlock.
/proc/net/tcp grabs socket spinlock (violating anti-dead lock rule),
but does not check for users.

All manipulations with syn queue made in process context (i.e. accept())
also grab spinlock in addition(!) to "users" count. Deadlock is avoided
because (and while) lhash lock is never acquired while socket spinlock
is held.

Alexey

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.061 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site