Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH v2 0/4] fix / cleanup async scsi scanning

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


dan.j.williams at intel

May 30, 2012, 11:21 AM

Post #1 of 6 (158 views)
Permalink
[PATCH v2 0/4] fix / cleanup async scsi scanning

Commit a7a20d10 "[SCSI] sd: limit the scope of the async probe domain"
introduces a boot regression by moving sd probe work off of the global
async queue. Using a local async domain hides the probe work from being
synchronized by wait_for_device_probe()->async_synchronize_full().

Fix this by teaching async_synchronize_full() to flush all async work
regardless of domain, and take the opportunity to convert scsi scanning
to async_schedule(). This enables wait_for_device_probe() to flush scsi
scanning work.

Changes since v1: http://marc.info/?l=linux-scsi&m=133793153025832&w=2

1/ Tested to fix the boot hang that Meelis reported with v1. Reworked
async_synchronize_full() to walk through all the active domains,
otherwise we spin on !list_empty(async_domains) and prevent the async
context from running.

2/ Added the ability for domains to opt-out of global syncing as
requested by Arjan, but also needed for domains that don't want to worry
about list corruption when the domain goes out of scope (stack-allocated
domains).

---

Dan Williams (4):
async: introduce 'async_domain' type
async: make async_synchronize_full() flush all work regardless of domain
scsi: queue async scan work to an async_schedule domain
scsi: cleanup usages of scsi_complete_async_scans


drivers/regulator/core.c | 2 +
drivers/scsi/libsas/sas_ata.c | 2 +
drivers/scsi/scsi.c | 4 ++
drivers/scsi/scsi_priv.h | 3 +-
drivers/scsi/scsi_scan.c | 24 +++----------
drivers/scsi/scsi_wait_scan.c | 15 +++-----
include/linux/async.h | 36 +++++++++++++++++--
include/scsi/scsi_scan.h | 11 ------
kernel/async.c | 76 +++++++++++++++++++++++++++++++----------
kernel/power/hibernate.c | 8 ----
kernel/power/user.c | 2 -
11 files changed, 107 insertions(+), 76 deletions(-)
delete mode 100644 include/scsi/scsi_scan.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at alien8

May 30, 2012, 11:22 AM

Post #2 of 6 (154 views)
Permalink
Re: [PATCH v2 0/4] fix / cleanup async scsi scanning [In reply to]

On Wed, May 30, 2012 at 11:21:25AM -0700, Dan Williams wrote:
> Commit a7a20d10 "[SCSI] sd: limit the scope of the async probe domain"
> introduces a boot regression by moving sd probe work off of the global
> async queue. Using a local async domain hides the probe work from being
> synchronized by wait_for_device_probe()->async_synchronize_full().
>
> Fix this by teaching async_synchronize_full() to flush all async work
> regardless of domain, and take the opportunity to convert scsi scanning
> to async_schedule(). This enables wait_for_device_probe() to flush scsi
> scanning work.

Looks like those fix a similar boot issue I reported earlier:

http://marc.info/?l=linux-kernel&m=133839683405526&w=2

Should I give them a run or are they still in review?

Thanks.

--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dan.j.williams at intel

May 30, 2012, 11:29 AM

Post #3 of 6 (157 views)
Permalink
Re: [PATCH v2 0/4] fix / cleanup async scsi scanning [In reply to]

On Wed, May 30, 2012 at 11:22 AM, Borislav Petkov <bp [at] alien8> wrote:
> On Wed, May 30, 2012 at 11:21:25AM -0700, Dan Williams wrote:
>> Commit a7a20d10 "[SCSI] sd: limit the scope of the async probe domain"
>> introduces a boot regression by moving sd probe work off of the global
>> async queue.  Using a local async domain hides the probe work from being
>> synchronized by wait_for_device_probe()->async_synchronize_full().
>>
>> Fix this by teaching async_synchronize_full() to flush all async work
>> regardless of domain, and take the opportunity to convert scsi scanning
>> to async_schedule().  This enables wait_for_device_probe() to flush scsi
>> scanning work.
>
> Looks like those fix a similar boot issue I reported earlier:
>
> http://marc.info/?l=linux-kernel&m=133839683405526&w=2
>
> Should I give them a run or are they still in review?
>

They're ready for a run, but are likely 3.6 material. For 3.5 I think
James is going with the smaller fix posted here:

http://marc.info/?l=linux-scsi&m=133796775807498&w=2

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


w41ter at gmail

May 30, 2012, 3:33 PM

Post #4 of 6 (146 views)
Permalink
Re: [PATCH v2 0/4] fix / cleanup async scsi scanning [In reply to]

On 05/30/2012 11:29 AM, Dan Williams wrote:
> For 3.5 I think
> James is going with the smaller fix posted here:
>
> http://marc.info/?l=linux-scsi&m=133796775807498&w=2

Hi Dan. I replied to that thread not long ago, explaining
that I still have a booting problem after that patch. Just
a corner case maybe, but it's *my* corner case ;)

From that article click twice on "next in thread" to see it.

Many thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mroos at linux

May 31, 2012, 2:05 AM

Post #5 of 6 (147 views)
Permalink
Re: [PATCH v2 0/4] fix / cleanup async scsi scanning [In reply to]

> Commit a7a20d10 "[SCSI] sd: limit the scope of the async probe domain"
> introduces a boot regression by moving sd probe work off of the global
> async queue. Using a local async domain hides the probe work from being
> synchronized by wait_for_device_probe()->async_synchronize_full().
>
> Fix this by teaching async_synchronize_full() to flush all async work
> regardless of domain, and take the opportunity to convert scsi scanning
> to async_schedule(). This enables wait_for_device_probe() to flush scsi
> scanning work.
>
> Changes since v1: http://marc.info/?l=linux-scsi&m=133793153025832&w=2
>
> 1/ Tested to fix the boot hang that Meelis reported with v1. Reworked
> async_synchronize_full() to walk through all the active domains,
> otherwise we spin on !list_empty(async_domains) and prevent the async
> context from running.
>
> 2/ Added the ability for domains to opt-out of global syncing as
> requested by Arjan, but also needed for domains that don't want to worry
> about list corruption when the domain goes out of scope (stack-allocated
> domains).

Tested successfully on my Netra X1 where the original problem happened,
on top of 3.4.0-08215-g1e2aec8. Thank you!

--
Meelis Roos (mroos [at] linux)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bp at alien8

May 31, 2012, 6:37 AM

Post #6 of 6 (144 views)
Permalink
Re: [PATCH v2 0/4] fix / cleanup async scsi scanning [In reply to]

On Wed, May 30, 2012 at 11:29:23AM -0700, Dan Williams wrote:
> They're ready for a run, but are likely 3.6 material. For 3.5 I think
> James is going with the smaller fix posted here:
>
> http://marc.info/?l=linux-scsi&m=133796775807498&w=2

Yep,

both the smaller fix and the 4-patch set cure the box here, thanks.

Tested-by: Borislav Petkov <bp [at] alien8>

--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.