On Tue, 2017-02-21 at 18:58 +0000, Bart Van Assche wrote: > On 02/20/2017 01:38 PM, Nicholas A. Bellinger wrote: > > However, looking at transport_generic_free_cmd() in the context of > > ib_srpt and ib_isert, I don't see how this scenario can ever happen in > > as-is in upstream code. > > > > Namely, all of the transport_generic_free_cmd() callers in ib_srpt and > > ib_isert pass wait_for_tasks = false. And the only time > > transport_generic_free_cmd() will block is when wait_for_tasks = true, > > or when wait_for_tasks = true && abort = true. > > > > So as-is in upstream, how can transport_generic_free_cmd() ever block > > when wait_for_tasks = false..? > > I will check the other patches in this series for changes that trigger a > call to wait_for_completion() if wait_for_tasks == false. > Given there has not been any follow-up to identify a case in upstream where ib_isert or ib_srpt is using target_generic_free_cmd() with wait_for_tasks = true or a case where wait_for_tasks = false blocks, I'll conclude this was a bugfix incorrectly CC'ed to stable for breakage introduced by other changes in this series. To reiterate the importance of having bug-fixes, especially those intended for stable, always be leading other patches.. There is no way for a maintainer to know which bug-fixes are to existing code unless they precede all other patches and not intermixed with various other changes. The bug-fixes to existing upstream code need to be tested on their own without the other changes (especially those that effect the same area) invalidating the tests.