Re: null TTY in tty_fasync?
Jeff Garzik wrote: > > Andrew Morton wrote: > > Having stared sleepily at the code for several evenings I see no way in > > which serial_driver.refcount can be non-zero while serial.o's module > > refcount is zero. But it happened. > > Is it possible to replace serial_driver.refcount with calls to > GET_USE_COUNT()? No need to have two refcounts for the same thing, > usually... I'm a frayed knot. The refcounts are owned by the device driver but are exported to and manipulated by the tty layer. They must exist whether or not the driver is within a module. Similar to net_device.refcnt. Now, could the module refcount be replaced by a callback called "i_want_to_unload_you_is_this_ok()"? And could that function test the tty-layer refcount for zeroness and if true, mark the module as dead and return TRUE? Now you're talking. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: null TTY in tty_fasync?
Jeff Garzik wrote: Andrew Morton wrote: Having stared sleepily at the code for several evenings I see no way in which serial_driver.refcount can be non-zero while serial.o's module refcount is zero. But it happened. Is it possible to replace serial_driver.refcount with calls to GET_USE_COUNT()? No need to have two refcounts for the same thing, usually... I'm a frayed knot. The refcounts are owned by the device driver but are exported to and manipulated by the tty layer. They must exist whether or not the driver is within a module. Similar to net_device.refcnt. Now, could the module refcount be replaced by a callback called "i_want_to_unload_you_is_this_ok()"? And could that function test the tty-layer refcount for zeroness and if true, mark the module as dead and return TRUE? Now you're talking. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: null TTY in tty_fasync?
Andrew Morton wrote: > Having stared sleepily at the code for several evenings I see no way in > which serial_driver.refcount can be non-zero while serial.o's module > refcount is zero. But it happened. Is it possible to replace serial_driver.refcount with calls to GET_USE_COUNT()? No need to have two refcounts for the same thing, usually... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: null TTY in tty_fasync?
Marco d'Itri wrote: > > At the end of a UUCP poll this message was logged: > > Sep 19 23:42:47 wonderland kernel: Warning: null TTY for (04:40) in tty_fasync > > What does it mean? > Very hard to say. Ted, Google says this has only been reported three or four times. Could we please have a BUG() in that code path? It's probably unrelated to Harley's crash (http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0049.html), but then, I have no explanation for Harley's crash. Having stared sleepily at the code for several evenings I see no way in which serial_driver.refcount can be non-zero while serial.o's module refcount is zero. But it happened. We can rule out the schedule() in release_dev(), which is definitely an rmmod window bug, because Harley has confirmed that the "release_dev: %s: read/write wait queue active!" message did not come out (he still has the logs). It's something else. It would be a shame to put the `struct module *owner' stuff into the tty layer prior to having an explanation for all of this, even though it's on the todo list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: null TTY in tty_fasync?
Marco d'Itri wrote: At the end of a UUCP poll this message was logged: Sep 19 23:42:47 wonderland kernel: Warning: null TTY for (04:40) in tty_fasync What does it mean? Very hard to say. Ted, Google says this has only been reported three or four times. Could we please have a BUG() in that code path? It's probably unrelated to Harley's crash (http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0049.html), but then, I have no explanation for Harley's crash. Having stared sleepily at the code for several evenings I see no way in which serial_driver.refcount can be non-zero while serial.o's module refcount is zero. But it happened. We can rule out the schedule() in release_dev(), which is definitely an rmmod window bug, because Harley has confirmed that the "release_dev: %s: read/write wait queue active!" message did not come out (he still has the logs). It's something else. It would be a shame to put the `struct module *owner' stuff into the tty layer prior to having an explanation for all of this, even though it's on the todo list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
