Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

[Bart Van Assche <bvanassche@acm.org>]

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.