We have to hold the lock (tp->syn_wait_lock) because in listening_get_first
we return one of the elements of the list guarded by tp->syn_wait_lock, so
we have to make sure that it doesn't disappears under our feet when we go
to the next one in listening_get_next
> OOPS, I just realizes we might be talking about different locks :)
different problem :-)
> I was talking about
> read_[un]lock_bh(&tp->syn_wait_lock); in listening_get_first/next
> What lock are you talking about?
> As far as I can see, in TCP_SEQ_STATE_OPENREQ tp->syn_wait_lock is always
> held and in TCP_SEQ_STATE_LISTENING the tcp_listen_lock and so on?
Notice that we call tcp_listen_lock() only in tcp_get_idx, and tcp_get_idx
is not called for the first record, that is the header of /proc/net/tcp,
we're in TCP_SEQ_STATE_LISTENING that is zero (we zeroed the private seq_file
area in tcp_seq_open, so if the userlevel program only asks for, say, four
bytes (like midnight commander's editor, to read the magic number for the file
to decide which viewer is associated with the type indicated by the magic
number) this will be satisfied with just one call to tcp_seq_show, i.e.
only when tcp_seq_start returns (void *), without calling tcp_get_idx to
call tcp_listen_lock(). b00m, we drop a lock not held, got it?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/