From: Steve S. <ste...@ho...> - 2002-10-12 03:41:23
|
Hi, jd...@ka... wrote: >Where's that reactivate_fd? If it's not called in uml_net_rx, then it's >not called at all. Jeff, are you reading your code? :) uml_net_rx() is static; it is, and pretty much can only be called by uml_net_interrupt(). These are all the exit paths I see out of uml_net_rx as orig: 1) dev_alloc_skb fails. reactivate_fd is called and 0 is returned to uml_net_interrupt, which terminates the while loop, and branches past the if, out of the function. 2) reactivate_fd is called and pkt_len > 0. the packet is injected into the IP subsystem and pkt_len (>0) is returned, restarting the while loop, and calling uml_net_rx again (choose 1,2,3,or 4 again): 3) reactivate_fd is called and pkt_len = 0. 0 is returned to uml_net_interrupt, which terminates the loop and branches past the if, out of the function. 4) reactivate_fd is called and pkt_len < 0. pkt_len (<0) is returned, terminating the while loop, and branching *into* the if, shutting down the device, and exiting the function. With the patch, these are the exit paths: 1) dev_alloc_skb fails. 0 is returned to uml_net_interrupt, which terminates the while loop, and branches into the else where reactivate_fd is called, and exits out of the function. 2) pkt_len > 0. the packet is injected into the IP subsystem and pkt_len (>0) is returned, restarting the while loop, and calling uml_net_rx again (choose 1,2,3, or 4 again): 3) pkt_len = 0. 0 is returned to uml_net_interrupt, which terminates the loop and branches into the else where reactivate_fd is called, and exits out of the function. 4) pkt_len < 0. pkt_len (<0) is returned, terminating the while loop, and branching *into* the if, shutting down the device, and exiting the function. What am I missing? How is this substantially different than what was there, besides the upside that reactivate_fd is called only if the fd is drained and no error condition occured. This means it's called once, and once only per interrupt, unless there's an error, in which case we wouldn't want to know about the fd until we've fixed whatever is causing the error in the first place. The only downside I can see is if the error is recoverable. In that case we *would* want to reactivate the fd. Are there any recoverable errors besides EINTR and EAGAIN (which are already taken care of) that should be handled? Steve Schmidtke And the next poll() won't pick up a packet even if one's >waiting, so the device is permanently dead. > > > I would get a firestorm of "Device umn read returned -9, shutting it > > down". I suspected that the reactivate_fd was causing, in that case, > > sigio_handler() to fire off interrupts, due to POLLERR being flagged, > > faster than dev_close() could shut the interface down. > >We need better error handling, but that's not it. A permanent error like >EBADF should either totally shut down the device (rather than just leaving >the file descriptor disabled) or reconnect to the host. > > Jeff _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |