Bug 6409 - Under very high load, winbind panics
Summary: Under very high load, winbind panics
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-26 06:02 UTC by Volker Lendecke
Modified: 2009-05-27 02:56 UTC (History)
1 user (show)

See Also:
obnox: review+


Attachments
Patch for 3.2 (1.74 KB, patch)
2009-05-26 06:03 UTC, Volker Lendecke
no flags Details
Patch for 3.3 (1.74 KB, patch)
2009-05-26 06:04 UTC, Volker Lendecke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Lendecke 2009-05-26 06:02:03 UTC
In winbind, we do multiple events in one select round. This needs fixing, but
as long as we're still using it, for efficiency reasons we need to do that.
    
What can happen is the following: We have outgoing data pending for a client,
thus
    
    state->fd_event.flags == EVENT_FD_WRITE
    
Now a new client comes in, we go through the list of clients to find an idle
one. The detection for idle clients in remove_idle_client does not take the
pending data into account. We close the socket that has pending outgoing data,
the accept(2) one syscall later gives us the same socket.

In new_connection(), we do a setup_async_read, setting up a read fde. The
select from before however had found the socket (that we had already closed!!)
to be writable. In rw_callback we only want to see a readable flag, and we
panic in the SMB_ASSERT(flags == EVENT_FD_READ).
Comment 1 Volker Lendecke 2009-05-26 06:03:19 UTC
Created attachment 4206 [details]
Patch for 3.2
Comment 2 Volker Lendecke 2009-05-26 06:04:23 UTC
Created attachment 4207 [details]
Patch for 3.3
Comment 3 Michael Adam 2009-05-26 06:37:41 UTC
Oh, this is bad!
We definitely need this for 3.3 and 3.2.

The patch is correct and necessary even without the crashes:
We should only drop those client connections that we are
awaiting new requests from, not those that are still waiting
for our answer...

Michael
Comment 4 Karolin Seeger 2009-05-27 02:56:12 UTC
Pushed, thanks!

Closing out bug report.