On 05/27/14 10:09, James Bottomley wrote: > On Tue, 2014-05-27 at 10:06 +0200, Bart Van Assche wrote: >> As you probably know scsi_put_command() can get called from softirq >> context. A BUG_ON() in that context might make it unnecessary hard for a >> user to collect call traces. > > Why? The messages dumped are the same, the trace just starts from the > IRQ context ... I don't see what the problem is. > > The question isn't ease of gathering the data, it's correctness. The > point is that if the assert fails we have a free of an in-use command > leading to a nasty use after free ... the machine state is hosed at that > point.
Please keep in mind that even if the SCSI mid-layer functions correctly it is still possible that another driver in the system could cause these tests to fail if it triggers e.g. a use-after-free. If BUG_ON() is invoked the dumped message will be displayed on the screen but will not be saved in the system log. This is inconvenient because it means that if someone wants to capture the dumped message a camera is necessary and one has to step to the physical console to capture this message. Using WARN_ON() or WARN_ON_ONCE() makes it a lot easier for users to capture any message that is displayed. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
