James.Smart@xxxxxxxxxx wrote: > We recently saw this as well. It's related to the number of targets > that go away simultaneously. > > There ends up being many delete rport items on the work queue, and > when the 1st one stalls to flush the work queues, it starts the 2nd, > which stops to flush, and so on. > > My inclination is to look at what we have on the work queue and see if we can > circumvent some of the flush calls. Snooping the work queue? That sounds a little, um, like a hack? If the code is correct, and the end result is correct, is the test for recursion level and the associated dump_stack() necessary? (Yeah, I know, newbie questions. :) Mike ...snip... - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
