In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alexey Kuznetsov) writes:
> Hello!
>> that takes care of this). I can see that Alexey commented in
>> the code that he also got his machine to hard lock but I cannot
>> tell from his context whether it was because of using lock_sock
>> or the current version which uses SOCKHASH_LOCK() (which
>> translates into a start_bh_atomic()).
> It is Andi's comment and this commnet is wrong.
> lock_sock() is completely inappropriate for proc.
> Locking looks correct there, probably algorithm itself is wrong
> (stack overrun or something similar).
> I cannot reproduced this lockup.
> Why not to try sysreq-p to look where it looped?
There is one bug (even modulo locking): the if (len >= length) check
in the open_request loop should jump out of both jumps, not just out
of the inner loop. Otherwise the following dump of the LISTEN socket
will overflow the buffer. But even after fixing this there appear an
even stranger effect under load, with a few ( while true ; do cat
/proc/net/tcp >/dev/null ; done ) running: after some time cat will
invent new errnos like 1024 or 896. There must be a generic /proc bug
somewhere.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
