[PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Hannes Reinecke]

Hi all,

having been subjected to the pain of trying to bootstrap a really
large machine with systemd I decided to implement LUN masking in
scsi_transport_fc.
The principle is simple: disallow the automated LUN scanning when
discovering a rport, and create udev rules which selectively
enable individual LUNs by echoing the relevant values in the 'scan'
attribute of the SCSI host.
With that I'm able to boot an arbitrary large machine without
running into any udev or systemd imposed timeout.
To _disable_ LUN masking and restoring the original behaviour
I've noticed that the 'scan' sysfs attribute is actually synchronous,
ie the calling process will be blocked until the entire LUN scan
is completed.
So I've added another module parameter 'async_user_scan' to
move the scanning onto the existing scan workqueue, and unblock
the calling process.

As usual, comments and reviews are welcome.

Hannes Reinecke (2):
  scsi_transport_fc: implement 'disable_target_scan' module parameter
  scsi_transport_fc: Implement 'async_user_scan' module parameter

 drivers/scsi/scsi_transport_fc.c | 47 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 44 insertions(+), 3 deletions(-)

-- 
2.6.2

[PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Hannes Reinecke]

On larger installations it makes sense to disable the target scan
per default on boot, and scan the required LUNs directly via udev
rules.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/scsi_transport_fc.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 8a88226..90228b4 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -70,6 +70,18 @@ MODULE_PARM_DESC(dev_loss_tmo,
 		 " fast_io_fail_tmo is not set.");
 
 /*
+ * disable_target_scan: Disable target scan per default
+ *   useful on larger installations where only a small
+ *   number of LUNs are required for booting.
+ */
+static bool fc_disable_target_scan;
+
+module_param_named(disable_target_scan, fc_disable_target_scan,
+		   bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(disable_target_scan,
+		 "Disable target scan on remote ports (default=0)");
+
+/*
  * Redefine so that we can have same named attributes in the
  * sdev/starget/host objects.
  */
@@ -3272,10 +3284,14 @@ fc_scsi_scan_rport(struct work_struct *work)
 	struct Scsi_Host *shost = rport_to_shost(rport);
 	struct fc_internal *i = to_fc_internal(shost->transportt);
 	unsigned long flags;
+	bool disable_target_scan;
+
+	disable_target_scan = fc_disable_target_scan ?
+		fc_disable_target_scan : i->f->disable_target_scan;
 
 	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
 	    (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
-	    !(i->f->disable_target_scan)) {
+	    !disable_target_scan) {
 		scsi_scan_target(&rport->dev, rport->channel,
 			rport->scsi_target_id, SCAN_WILD_CARD, 1);
 	}
-- 
2.6.2

Re: [PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Johannes Thumshirn]

On Mon, Feb 22, 2016 at 08:51:01AM +0100, Hannes Reinecke wrote:
> On larger installations it makes sense to disable the target scan
> per default on boot, and scan the required LUNs directly via udev
> rules.
> 
> Signed-off-by: Hannes Reinecke <hare@suse.de>

Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Christoph Hellwig]

On Mon, Feb 22, 2016 at 08:51:01AM +0100, Hannes Reinecke wrote:
>  /*
> + * disable_target_scan: Disable target scan per default
> + *   useful on larger installations where only a small
> + *   number of LUNs are required for booting.
> + */
> +static bool fc_disable_target_scan;
> +
> +module_param_named(disable_target_scan, fc_disable_target_scan,
> +		   bool, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(disable_target_scan,
> +		 "Disable target scan on remote ports (default=0)");
> +
> +/*
>   * Redefine so that we can have same named attributes in the
>   * sdev/starget/host objects.
>   */
> @@ -3272,10 +3284,14 @@ fc_scsi_scan_rport(struct work_struct *work)
>  	struct Scsi_Host *shost = rport_to_shost(rport);
>  	struct fc_internal *i = to_fc_internal(shost->transportt);
>  	unsigned long flags;
> +	bool disable_target_scan;
> +
> +	disable_target_scan = fc_disable_target_scan ?
> +		fc_disable_target_scan : i->f->disable_target_scan;
>  
>  	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
>  	    (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
> -	    !(i->f->disable_target_scan)) {
> +	    !disable_target_scan) {

Wouldn't this be simpler by just writing:

if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
    (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
    !i->f->disable_target_scan && !disable_target_scan) {

that being said I don't understand why we need this in the FC transport
class.  What is so special about FC that we do it here and not globally?

Re: [PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Hannes Reinecke]

On 03/01/2016 09:12 PM, Christoph Hellwig wrote:
> On Mon, Feb 22, 2016 at 08:51:01AM +0100, Hannes Reinecke wrote:
>>  /*
>> + * disable_target_scan: Disable target scan per default
>> + *   useful on larger installations where only a small
>> + *   number of LUNs are required for booting.
>> + */
>> +static bool fc_disable_target_scan;
>> +
>> +module_param_named(disable_target_scan, fc_disable_target_scan,
>> +		   bool, S_IRUGO|S_IWUSR);
>> +MODULE_PARM_DESC(disable_target_scan,
>> +		 "Disable target scan on remote ports (default=0)");
>> +
>> +/*
>>   * Redefine so that we can have same named attributes in the
>>   * sdev/starget/host objects.
>>   */
>> @@ -3272,10 +3284,14 @@ fc_scsi_scan_rport(struct work_struct *work)
>>  	struct Scsi_Host *shost = rport_to_shost(rport);
>>  	struct fc_internal *i = to_fc_internal(shost->transportt);
>>  	unsigned long flags;
>> +	bool disable_target_scan;
>> +
>> +	disable_target_scan = fc_disable_target_scan ?
>> +		fc_disable_target_scan : i->f->disable_target_scan;
>>  
>>  	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
>>  	    (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
>> -	    !(i->f->disable_target_scan)) {
>> +	    !disable_target_scan) {
> 
> Wouldn't this be simpler by just writing:
> 
> if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
>     (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
>     !i->f->disable_target_scan && !disable_target_scan) {
> 
> that being said I don't understand why we need this in the FC transport
> class.  What is so special about FC that we do it here and not globally?
> 
Main reasons being that
a) it's most commonly on FC where you end up having thousands of LUNs;
SAS domains are of finite size and you'd need to string quite a few SAS
expanders together to achieve a similar setup. And iSCSI is ... well.
b) FC already has the required infrastructure in place where you easily
can suppress a target scan, making the patch really trivial.

So rather than trying to come up with a generic solution and an overly
complicated patch I opted for the simpler version :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Christoph Hellwig]

On Wed, Mar 02, 2016 at 01:59:39PM +0800, Hannes Reinecke wrote:
> Main reasons being that
> a) it's most commonly on FC where you end up having thousands of LUNs;
> SAS domains are of finite size and you'd need to string quite a few SAS
> expanders together to achieve a similar setup. And iSCSI is ... well.
> b) FC already has the required infrastructure in place where you easily
> can suppress a target scan, making the patch really trivial.
> 
> So rather than trying to come up with a generic solution and an overly
> complicated patch I opted for the simpler version :-)

Having a global disable just for all FC is still odd.  Either you
do it for all devices and always initiate a manual scan, or you
need to do it on a per-host basis somehow.

Re: [PATCH 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

[Hannes Reinecke]

On 03/02/2016 05:18 PM, Christoph Hellwig wrote:
> On Wed, Mar 02, 2016 at 01:59:39PM +0800, Hannes Reinecke wrote:
>> Main reasons being that
>> a) it's most commonly on FC where you end up having thousands of LUNs;
>> SAS domains are of finite size and you'd need to string quite a few SAS
>> expanders together to achieve a similar setup. And iSCSI is ... well.
>> b) FC already has the required infrastructure in place where you easily
>> can suppress a target scan, making the patch really trivial.
>>
>> So rather than trying to come up with a generic solution and an overly
>> complicated patch I opted for the simpler version :-)
> 
> Having a global disable just for all FC is still odd.  Either you
> do it for all devices and always initiate a manual scan, or you
> need to do it on a per-host basis somehow.
> 
Understood.

Will be resubmitting with a global switch for all SCSI hosts.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

[Hannes Reinecke]

When invoking a scan via the sysfs 'scan' attribute the process
will be blocked until the scan is completed, which can take a
very long time on large installations.
Enabling the 'async_user_scan' parameter moves the actual
LUN scanning to a workqueue, thereby unblocking the process.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/scsi_transport_fc.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 90228b4..3afe60a9 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -82,6 +82,21 @@ MODULE_PARM_DESC(disable_target_scan,
 		 "Disable target scan on remote ports (default=0)");
 
 /*
+ * async_user_scan: make 'scan' sysfs attribute asynchronous
+ *   on larger installations scanning can take a very long time
+ *   during which the process invoking the scan will be blocked
+ *   on writing to the 'scan' attribute. Enabling this attribute
+ *   will move scanning to a work queue, allowing the process
+ *   to return immediately.
+ */
+static bool fc_async_user_scan;
+
+module_param_named(async_user_scan, fc_async_user_scan,
+		   bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(async_user_scan,
+		 "Allow for asynchronous user LUN scanning (default=0)");
+
+/*
  * Redefine so that we can have same named attributes in the
  * sdev/starget/host objects.
  */
@@ -2121,8 +2136,18 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, u64 lun)
 
 		if ((channel == rport->channel) &&
 		    (id == rport->scsi_target_id)) {
-			spin_unlock_irqrestore(shost->host_lock, flags);
-			scsi_scan_target(&rport->dev, channel, id, lun, 1);
+			if (lun == SCAN_WILD_CARD &&
+			    fc_async_user_scan) {
+				if (!(rport->flags & FC_RPORT_SCAN_PENDING)) {
+					rport->flags |= FC_RPORT_SCAN_PENDING;
+					scsi_queue_work(shost,
+							&rport->scan_work);
+				}
+				spin_unlock_irqrestore(shost->host_lock, flags);
+			} else {
+				spin_unlock_irqrestore(shost->host_lock, flags);
+				scsi_scan_target(&rport->dev, channel, id, lun, 1);
+			}
 			return;
 		}
 	}
-- 
2.6.2

RE: [PATCH 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

[Seymour, Shane M]

Reviewed-by: Shane Seymour <shane.seymour@hpe.com>

Re: [PATCH 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

[Johannes Thumshirn]

On Mon, Feb 22, 2016 at 08:51:02AM +0100, Hannes Reinecke wrote:
> When invoking a scan via the sysfs 'scan' attribute the process
> will be blocked until the scan is completed, which can take a
> very long time on large installations.
> Enabling the 'async_user_scan' parameter moves the actual
> LUN scanning to a workqueue, thereby unblocking the process.
> 
> Signed-off-by: Hannes Reinecke <hare@suse.de>

Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

[Christoph Hellwig]

Bah.  Async scanning seems useful, but it shouldn't be a module option
that breaks exsiting users of the attribute, and it shouldn't be in
the FC transport class.

Just add a new async_scan attribute that works like scan, but works
asynchronously in the core.

Or figure out if we can overload the already parsed but ignored
junk argument in the scan attribute to accept an 'a' for async?

RE: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Seymour, Shane M]

Hi Hannes,

How do you know that a request for an async scan is complete (I'm assuming that you get add or change udev events)? Assuming that someone has manually started a scan on something (e.g. some newly presented devices after boot) and all scans are going to be async how do you when it is complete rather than waiting in a work queue? An example may be a sysfs file that contains unscanned, pending, scanning, scanned so you know when it's complete at the appropriate level in sysfs (the hba and the rports) so you know when can continue if you're polling the status (e.g. checking as part of system admin work with newly presented rports so you can then do something with them).

Thanks
Shane

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Monday, February 22, 2016 6:51 PM
> To: Martin K . Petersen
> Cc: Christoph Hellwig; James Bottomley; Johannes Thumshirn; linux-
> scsi@vger.kernel.org; Hannes Reinecke
> Subject: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
> 
> Hi all,
> 
> having been subjected to the pain of trying to bootstrap a really large
> machine with systemd I decided to implement LUN masking in
> scsi_transport_fc.
> The principle is simple: disallow the automated LUN scanning when
> discovering a rport, and create udev rules which selectively enable individual
> LUNs by echoing the relevant values in the 'scan'
> attribute of the SCSI host.
> With that I'm able to boot an arbitrary large machine without running into any
> udev or systemd imposed timeout.
> To _disable_ LUN masking and restoring the original behaviour I've noticed
> that the 'scan' sysfs attribute is actually synchronous, ie the calling process
> will be blocked until the entire LUN scan is completed.
> So I've added another module parameter 'async_user_scan' to move the
> scanning onto the existing scan workqueue, and unblock the calling process.
> 
> As usual, comments and reviews are welcome.
> 
> Hannes Reinecke (2):
>   scsi_transport_fc: implement 'disable_target_scan' module parameter
>   scsi_transport_fc: Implement 'async_user_scan' module parameter
> 
>  drivers/scsi/scsi_transport_fc.c | 47
> +++++++++++++++++++++++++++++++++++++---
>  1 file changed, 44 insertions(+), 3 deletions(-)
> 
> --
> 2.6.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Hannes Reinecke]

On 02/22/2016 07:39 PM, Seymour, Shane M wrote:
> Hi Hannes,
> 
> How do you know that a request for an async scan is complete (I'm assuming that you get
> add or change udev events)? Assuming that someone has manually started a scan on something
> (e.g. some newly presented devices after boot) and all scans are going
to be async how
> do you when it is complete rather than waiting in a work queue? An
example may be a sysfs
> file that contains unscanned, pending, scanning, scanned so you know
when it's complete
> at the appropriate level in sysfs (the hba and the rports) so you know
when can continue
> if you're polling the status (e.g. checking as part of system admin
work with newly
> presented rports so you can then do something with them).
>
Thing is, I don't.

We have had a similar discussion with the IBM zfcp folks, that it would
be desirable to have a marker in sysfs telling us that the rport is
stable (ie no scanning in progress).
However, this cannot be at the rport level (as the rport itself might be
going away), but rather at some higher level (eg fc_host).

But this has nothing to do with the patchset, right?
We're just disabling the (existing) scan callback, and retrigger it once
the sysfs attribute has been cleared.

We don't change the behaviour during scanning with this patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Seymour, Shane M]

> But this has nothing to do with the patchset, right?

Correct.

Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Ewan Milne]

On Tue, 2016-02-23 at 18:21 +0800, Hannes Reinecke wrote:
> On 02/22/2016 07:39 PM, Seymour, Shane M wrote:
> > Hi Hannes,
> > 
> > How do you know that a request for an async scan is complete (I'm assuming that you get
> > add or change udev events)? Assuming that someone has manually started a scan on something
> > (e.g. some newly presented devices after boot) and all scans are going
> to be async how
> > do you when it is complete rather than waiting in a work queue? An
> example may be a sysfs
> > file that contains unscanned, pending, scanning, scanned so you know
> when it's complete
> > at the appropriate level in sysfs (the hba and the rports) so you know
> when can continue
> > if you're polling the status (e.g. checking as part of system admin
> work with newly
> > presented rports so you can then do something with them).
> >
> Thing is, I don't.
> 
> We have had a similar discussion with the IBM zfcp folks, that it would
> be desirable to have a marker in sysfs telling us that the rport is
> stable (ie no scanning in progress).
> However, this cannot be at the rport level (as the rport itself might be
> going away), but rather at some higher level (eg fc_host).

I am not sure this really helps.  If another process initiates a scan
then sysfs might report that the scanning was still in progress.  If
scans are initiated often enough, you might never observe a stable state.

> 
> But this has nothing to do with the patchset, right?
> We're just disabling the (existing) scan callback, and retrigger it once
> the sysfs attribute has been cleared.
> 
> We don't change the behaviour during scanning with this patchset.
> 
> Cheers,
> 
> Hannes

Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking

[Hannes Reinecke]

On 03/02/2016 03:54 AM, Ewan Milne wrote:
> On Tue, 2016-02-23 at 18:21 +0800, Hannes Reinecke wrote:
>> On 02/22/2016 07:39 PM, Seymour, Shane M wrote:
>>> Hi Hannes,
>>>
>>> How do you know that a request for an async scan is complete (I'm assuming
>>> that you get add or change udev events)? Assuming that someone has
manually
>>> started a scan on something (e.g. some newly presented devices after
boot)
>>> and all scans are going to be async how do you know when it is complete
>>> rather than waiting in a work queue? An example may be a sysfs
>>> file that contains unscanned, pending, scanning, scanned so you know
>>> when it's complete at the appropriate level in sysfs (the hba and the rports)
>>> so you know when can continue if you're polling the status (e.g.
checking
>>> as part of system admin work with newly
>>> presented rports so you can then do something with them).
>>>
>> Thing is, I don't.
>>
>> We have had a similar discussion with the IBM zfcp folks, that it would
>> be desirable to have a marker in sysfs telling us that the rport is
>> stable (ie no scanning in progress).
>> However, this cannot be at the rport level (as the rport itself might be
>> going away), but rather at some higher level (eg fc_host).
> 
> I am not sure this really helps.  If another process initiates a scan
> then sysfs might report that the scanning was still in progress.  If
> scans are initiated often enough, you might never observe a stable state.
> 
True.

Which is one of the reasons why this particular item hasn't made any
progress yet.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] scsi_transport_fc: LUN masking

[Hannes Reinecke]

Hi all,

having been subjected to the pain of trying to bootstrap a really
large machine with systemd I decided to implement LUN masking in
scsi_transport_fc.
The principle is simple: disallow the automated LUN scanning when
discovering a rport, and create udev rules which selectively
enable individual LUNs by echoing the relevant values in the 'scan'
attribute of the SCSI host.
With that I'm able to boot an arbitrary large machine without
running into any udev or systemd imposed timeout.
To _disable_ LUN masking and restoring the original behaviour
I've noticed that the 'scan' sysfs attribute is actually synchronous,
ie the calling process will be blocked until the entire LUN scan
is completed.
So I've added another module parameter 'async_user_scan' to
move the scanning onto the existing scan workqueue, and unblock
the calling process.

As usual, comments and reviews are welcome.

Hannes Reinecke (2):
  scsi_transport_fc: implement 'disable_target_scan' module parameter
  scsi_transport_fc: Implement 'async_user_scan' module parameter

 drivers/scsi/scsi_transport_fc.c | 47 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 44 insertions(+), 3 deletions(-)

-- 
1.8.5.6

[PATCH 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

[Hannes Reinecke]

When invoking a scan via the sysfs 'scan' attribute the process
will be blocked until the scan is completed, which can take a
very long time on large installations.
Enabling the 'async_user_scan' parameter moves the actual
LUN scanning to a workqueue, thereby unblocking the process.

Signed-off-by: Hannes Reinecke <hare@suse.de>
---
 drivers/scsi/scsi_transport_fc.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 72954a8..af1d35b 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -83,6 +83,21 @@ MODULE_PARM_DESC(disable_target_scan,
 		 "Disable target scan on remote ports (default=0)");
 
 /*
+ * async_user_scan: make 'scan' sysfs attribute asynchronous
+ *   on larger installations scanning can take a very long time
+ *   during which the process invoking the scan will be blocked
+ *   on writing to the 'scan' attribute. Enabling this attribute
+ *   will move scanning to a work queue, allowing the process
+ *   to return immediately.
+ */
+static bool fc_async_user_scan;
+
+module_param_named(async_user_scan, fc_async_user_scan,
+		   bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(async_user_scan,
+		 "Allow for asynchronous user LUN scanning (default=0)");
+
+/*
  * Redefine so that we can have same named attributes in the
  * sdev/starget/host objects.
  */
@@ -2121,8 +2136,18 @@ fc_user_scan_tgt(struct Scsi_Host *shost, uint channel, uint id, uint lun)
 
 		if ((channel == rport->channel) &&
 		    (id == rport->scsi_target_id)) {
-			spin_unlock_irqrestore(shost->host_lock, flags);
-			scsi_scan_target(&rport->dev, channel, id, lun, 1);
+			if (lun == SCAN_WILD_CARD &&
+			    fc_async_user_scan) {
+				if (!(rport->flags & FC_RPORT_SCAN_PENDING)) {
+					rport->flags |= FC_RPORT_SCAN_PENDING;
+					scsi_queue_work(shost,
+							&rport->scan_work);
+				}
+				spin_unlock_irqrestore(shost->host_lock, flags);
+			} else {
+				spin_unlock_irqrestore(shost->host_lock, flags);
+				scsi_scan_target(&rport->dev, channel, id, lun, 1);
+			}
 			return;
 		}
 	}
-- 
1.8.5.6