On Tue, Feb 04 2014 at 6:31am -0500, Hannes Reinecke <hare@xxxxxxx> wrote: > On 02/04/2014 12:26 PM, Junichi Nomura wrote: > > On 02/04/14 19:54, Hannes Reinecke wrote: > >> We only need to take care to add a small delay when calling > >> __pg_init_all_paths() to move processing off to a workqueue; otherwise > >> pg_init_done() might end up calling scsi_dh_activate() directly, which > >> might use non-atomic memory allocations or issue I/O. > > > > Hi Hannes, > > > > could you tell me how "might end up calling scsi_dh_active()" happens? > > > > queue_delayed_work() > > queue_delayed_work_on() > > __queue_delayed_work() > > if (!delay) > > __queue_work() > > get_work_pool() > > insert_work() > > set_work_pwq() > > get_pwq() > > if (__need_more_worker()) > > wake_up_worker() > > > > queue_work() doesn't execute the work itself. > > > > What am I missing? > > > As mentioned, I stumbled across the same issue when developing the > asynchronous SCSI aborts. I'll see to have it recreated with this > patchset. Just to verify, this seems to be the only outstanding question for this patchset? What value are you using for HZ? If this portion of the change does turn out to be meaningul: Rather than tieing to HZ should we just use an explicitly non-zero value for __pg_init_all_paths()'s @min_delay? -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
