[RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

[RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

[Mike Snitzer]

Some scsi_dh modules are known to conflict with with 3rd party multipath
drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath).

Allow 3rd party multipath drivers to programatically detach a scsi_dh
using the scsi_dh_detach() interface rather than require writing
'detach' to /sys/block/sdX/queue/dh_state

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
 drivers/scsi/device_handler/scsi_dh.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

[begs the question: why are _any_ of the scsi_dh symbols
EXPORT_SYMBOL_GPL?  Linux would benefit from more 3rd party use of
scsi_dh*.  As it stands, Linux is being held back from having better
default handling of multipath LUNs purely because 3rd parties may not
play nicely with scsi_dh* being attached]

diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c
index 23149b9..a550de1 100644
--- a/drivers/scsi/device_handler/scsi_dh.c
+++ b/drivers/scsi/device_handler/scsi_dh.c
@@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q)
 	}
 	put_device(&sdev->sdev_gendev);
 }
-EXPORT_SYMBOL_GPL(scsi_dh_detach);
+EXPORT_SYMBOL(scsi_dh_detach);
 
 static struct notifier_block scsi_dh_nb = {
 	.notifier_call = scsi_dh_notifier

Re: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

[Hannes Reinecke]

On 12/15/2011 10:44 PM, Mike Snitzer wrote:
> Some scsi_dh modules are known to conflict with with 3rd party multipath
> drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath).
> 
> Allow 3rd party multipath drivers to programatically detach a scsi_dh
> using the scsi_dh_detach() interface rather than require writing
> 'detach' to /sys/block/sdX/queue/dh_state
> 
> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
No problem with that.

Acked-by: Hannes Reinecke <hare@suse.de>

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: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

[Mike Snitzer]

On Tue, Dec 20 2011 at  2:31am -0500,
Hannes Reinecke <hare@suse.de> wrote:

> On 12/15/2011 10:44 PM, Mike Snitzer wrote:
> > Some scsi_dh modules are known to conflict with with 3rd party multipath
> > drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath).
> > 
> > Allow 3rd party multipath drivers to programatically detach a scsi_dh
> > using the scsi_dh_detach() interface rather than require writing
> > 'detach' to /sys/block/sdX/queue/dh_state
> > 
> > Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> No problem with that.
> 
> Acked-by: Hannes Reinecke <hare@suse.de>

Thanks Hannes,

So will this change make it into 3.3?  In general, I'm not clear on
where scsi_dh changes are staged for upstream inclusion.

Mike

Re: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

[Mike Snitzer]

On Tue, Dec 20 2011 at  2:31am -0500,
Hannes Reinecke <hare@suse.de> wrote:

> On 12/15/2011 10:44 PM, Mike Snitzer wrote:
> > Some scsi_dh modules are known to conflict with with 3rd party multipath
> > drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath).
> > 
> > Allow 3rd party multipath drivers to programatically detach a scsi_dh
> > using the scsi_dh_detach() interface rather than require writing
> > 'detach' to /sys/block/sdX/queue/dh_state
> > 
> > Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> No problem with that.
> 
> Acked-by: Hannes Reinecke <hare@suse.de>

Hi James,

Can we get this patch staged for 3.5?

Thanks,
Mike

[RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach

[Mike Snitzer]

Allow 3rd party multipath drivers to programatically detach a scsi_dh
using the scsi_dh_detach() interface.  This is as improvement over
requiring them to write 'detach' to /sys/block/sdX/queue/dh_state

End result is both Linux and 3rd party multipath drivers can coexist
without compromising Linux's default handling of multipath LUNs.

Linux has suffered from races associated with attaching a scsi_dh to a
device too late (after an HBA driver has started the SCSI device scan).
Attaching a scsi_dh too late results in default sense handling that does
not silently fail IO to passive paths, which creates excessive delays
and IO errors during normal boot on a system with hundreds of LUNs.

To fix this the appropriate scsi_dh must be attached before the HBA
driver(s) are even loaded.  But some scsi_dh are known to conflict with
3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc
conflict with EMC PowerPath).  This patch allows 3rd party drivers to
resolve the conflict by detaching an attached scsi_dh.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Hannes Reinecke <hare@suse.de>
Cc: Chandra Seetharaman <sekharan@us.ibm.com>
---
 drivers/scsi/device_handler/scsi_dh.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c
index 23149b9..a550de1 100644
--- a/drivers/scsi/device_handler/scsi_dh.c
+++ b/drivers/scsi/device_handler/scsi_dh.c
@@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q)
 	}
 	put_device(&sdev->sdev_gendev);
 }
-EXPORT_SYMBOL_GPL(scsi_dh_detach);
+EXPORT_SYMBOL(scsi_dh_detach);
 
 static struct notifier_block scsi_dh_nb = {
 	.notifier_call = scsi_dh_notifier

Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach

[James Bottomley]

On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote:
> Allow 3rd party multipath drivers to programatically detach a scsi_dh
> using the scsi_dh_detach() interface.  This is as improvement over
> requiring them to write 'detach' to /sys/block/sdX/queue/dh_state
> 
> End result is both Linux and 3rd party multipath drivers can coexist
> without compromising Linux's default handling of multipath LUNs.
> 
> Linux has suffered from races associated with attaching a scsi_dh to a
> device too late (after an HBA driver has started the SCSI device scan).
> Attaching a scsi_dh too late results in default sense handling that does
> not silently fail IO to passive paths, which creates excessive delays
> and IO errors during normal boot on a system with hundreds of LUNs.
> 
> To fix this the appropriate scsi_dh must be attached before the HBA
> driver(s) are even loaded.  But some scsi_dh are known to conflict with
> 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc
> conflict with EMC PowerPath).  This patch allows 3rd party drivers to
> resolve the conflict by detaching an attached scsi_dh.

This changelog is a bit misleading, isn't it?

The basic problem is that binary only third party drivers can't use the
scsi_dh_detach callback because it's GPL only.  The only module I know
which suffers this problem is powerpath, is that right?

So this patch actually relaxes our GPL only policy to allow powerpath to
detach correctly. I really don't like the characterisation in the
current proposed changelog of this being a "third party" problem because
quite a few third party modules actually provide source and are thus GPL
compliant.

The whole point of GPL only symbols is to make life difficult for binary
modules, so I could just say this might be indicative of the success of
that policy.  On the other hand, I'm not going to be religious about
this.  If you get the ack of the dh handler maintainer (Chandra
Seetharaman) I'll apply this policy relaxation with a proper changelog
that says what we're doing (allowing powerpath to bind to the symbol).

James

Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach

[Mike Snitzer]

On Fri, Apr 20 2012 at 11:17am -0400,
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote:
> > Allow 3rd party multipath drivers to programatically detach a scsi_dh
> > using the scsi_dh_detach() interface.  This is as improvement over
> > requiring them to write 'detach' to /sys/block/sdX/queue/dh_state
> > 
> > End result is both Linux and 3rd party multipath drivers can coexist
> > without compromising Linux's default handling of multipath LUNs.
> > 
> > Linux has suffered from races associated with attaching a scsi_dh to a
> > device too late (after an HBA driver has started the SCSI device scan).
> > Attaching a scsi_dh too late results in default sense handling that does
> > not silently fail IO to passive paths, which creates excessive delays
> > and IO errors during normal boot on a system with hundreds of LUNs.
> > 
> > To fix this the appropriate scsi_dh must be attached before the HBA
> > driver(s) are even loaded.  But some scsi_dh are known to conflict with
> > 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc
> > conflict with EMC PowerPath).  This patch allows 3rd party drivers to
> > resolve the conflict by detaching an attached scsi_dh.
> 
> This changelog is a bit misleading, isn't it?
>
> The basic problem is that binary only third party drivers can't use the
> scsi_dh_detach callback because it's GPL only.  The only module I know
> which suffers this problem is powerpath, is that right?
> 
> So this patch actually relaxes our GPL only policy to allow powerpath to
> detach correctly. I really don't like the characterisation in the
> current proposed changelog of this being a "third party" problem because
> quite a few third party modules actually provide source and are thus GPL
> compliant.
>
> The whole point of GPL only symbols is to make life difficult for binary
> modules, so I could just say this might be indicative of the success of
> that policy.  On the other hand, I'm not going to be religious about
> this.  If you get the ack of the dh handler maintainer (Chandra
> Seetharaman) I'll apply this policy relaxation with a proper changelog
> that says what we're doing (allowing powerpath to bind to the symbol).

Would s/3rd party/proprietary/ be OK?

There are other proprietary multipath drivers (e.g. veritas DMP).  So
the issue is theoretically more generic than powerpath.  But in practice
powerpath is the most widely deployed conflict that motivated this
change.

Though I could easily imagine our policy to treat Powerpath with kid
gloves has made us unaware of the potential for other proprietary
multipath drivers having the same conflict with scsi_dh.

FYI, I'm looking to have RHEL7 blaze trails and shake things up by
forcing proprietary multipath drivers to detach scsi_dh (EMC is aware of
this).

Mike

Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach

[Chandra Seetharaman]

Mike,

First off, sorry for not responding on this earlier. When I saw the
original patch, I was thinking it is a generic policy issue, and James
would be a better person to make decision on this, and forgot about it.

Now only realized that James was waiting on me.

I am not very religious either, and agree with James on changing the
Changelog.

With that change,

Acked-by: Chandra Seetharaman <sekharan@us.ibm.com>

Regards,

Chandra
On Fri, 2012-04-20 at 19:17 +0400, James Bottomley wrote:
> On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote:
> > Allow 3rd party multipath drivers to programatically detach a scsi_dh
> > using the scsi_dh_detach() interface.  This is as improvement over
> > requiring them to write 'detach' to /sys/block/sdX/queue/dh_state
> > 
> > End result is both Linux and 3rd party multipath drivers can coexist
> > without compromising Linux's default handling of multipath LUNs.
> > 
> > Linux has suffered from races associated with attaching a scsi_dh to a
> > device too late (after an HBA driver has started the SCSI device scan).
> > Attaching a scsi_dh too late results in default sense handling that does
> > not silently fail IO to passive paths, which creates excessive delays
> > and IO errors during normal boot on a system with hundreds of LUNs.
> > 
> > To fix this the appropriate scsi_dh must be attached before the HBA
> > driver(s) are even loaded.  But some scsi_dh are known to conflict with
> > 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc
> > conflict with EMC PowerPath).  This patch allows 3rd party drivers to
> > resolve the conflict by detaching an attached scsi_dh.
> 
> This changelog is a bit misleading, isn't it?
> 
> The basic problem is that binary only third party drivers can't use the
> scsi_dh_detach callback because it's GPL only.  The only module I know
> which suffers this problem is powerpath, is that right?
> 
> So this patch actually relaxes our GPL only policy to allow powerpath to
> detach correctly. I really don't like the characterisation in the
> current proposed changelog of this being a "third party" problem because
> quite a few third party modules actually provide source and are thus GPL
> compliant.
> 
> The whole point of GPL only symbols is to make life difficult for binary
> modules, so I could just say this might be indicative of the success of
> that policy.  On the other hand, I'm not going to be religious about
> this.  If you get the ack of the dh handler maintainer (Chandra
> Seetharaman) I'll apply this policy relaxation with a proper changelog
> that says what we're doing (allowing powerpath to bind to the symbol).
> 
> James
> 
> 
> --
> 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 v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to
detach a scsi_dh using scsi_dh_detach.  This is an improvement over
requiring them to write 'detach' to /sys/block/sdX/queue/dh_state

End result is Linux and PowerPath can coexist without compromising
Linux's default handling of multipath LUNs.

Linux has suffered from the race where a scsi_dh is not available to be
attached to a SCSI device until too late (after an HBA driver has
started the SCSI device scan that may attach a scsi_dh).  Attaching a
scsi_dh too late results in default sense handling that does not
silently end IO to passive paths, which creates excessive delays and IO
errors during normal boot of a system with hundreds of LUNs.

To fix this the appropriate scsi_dh must be available to be attached
before an HBA driver's SCSI device scan.  But once attached, both
scsi_dh_alua and scsi_dh_emc are known to conflict with PowerPath --
allowing PowerPath to use scsi_dh_detach resolves such conflicts.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Hannes Reinecke <hare@suse.de>
Acked-by: Chandra Seetharaman <sekharan@us.ibm.com>
---
 drivers/scsi/device_handler/scsi_dh.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

v2: header tweaks, added Chandra's Acked-by
    p.s. James, if you still think I'm too indirect or long-winded
    please feel free to change the header accordingly.  Thanks!

diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c
index 23149b9..a550de1 100644
--- a/drivers/scsi/device_handler/scsi_dh.c
+++ b/drivers/scsi/device_handler/scsi_dh.c
@@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q)
 	}
 	put_device(&sdev->sdev_gendev);
 }
-EXPORT_SYMBOL_GPL(scsi_dh_detach);
+EXPORT_SYMBOL(scsi_dh_detach);
 
 static struct notifier_block scsi_dh_nb = {
 	.notifier_call = scsi_dh_notifier

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Alan Cox]

On Fri, 20 Apr 2012 13:34:05 -0400
Mike Snitzer <snitzer@redhat.com> wrote:

> Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to
> detach a scsi_dh using scsi_dh_detach. 

That I doubt somehow. The GPL covers *all* derivative works.
EXPORT_SYMBOL doesn't magically make code non-derivative. If you need to
modify the kernel to make your driver work *and* you want to claim it is
not derivative then I hope there are good lawyers involved 8-)

The kernel is GPL, all derived works of a GPL codebase are required to be
GPL. There is no magic rule about modules. I've stated that repeatedly
for anything containing a line of code I own. GregKH has made it very
clear for his code, and so it goes on.

> End result is Linux and PowerPath can coexist without compromising
> Linux's default handling of multipath LUNs.

So your specific purpose seems to me to be to enable a third party piece
of non-free code to hook into a piece of GPL code that it needs (which to
me implies it is derivative if it does). There is an offence of
"conspiracy to commit copyright infringement" so merely grinning and
saying its for a third party doesn't let your company off the hook either.

You should probably forward it to your legal teams before taking any
other action. Deleting it won't make it go away. It's up to them to
decide if they think they can argue properly that the work is not
derivative. I shall be most intrigued to see anyone make that argument,
but hey I'm not a lawyer.

I'm dying to see anyone make the moral argument for it too.

Alan

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

On Fri, Apr 20 2012 at  4:41pm -0400,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Fri, 20 Apr 2012 13:34:05 -0400
> Mike Snitzer <snitzer@redhat.com> wrote:
> 
> > Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to
> > detach a scsi_dh using scsi_dh_detach. 
> 
> That I doubt somehow. The GPL covers *all* derivative works.
> EXPORT_SYMBOL doesn't magically make code non-derivative. If you need to
> modify the kernel to make your driver work *and* you want to claim it is
> not derivative then I hope there are good lawyers involved 8-)

Um... now I see that cc'ing LKML was a mistake:

GPL zealots reading into this _way_ more than is warranted... awesome.

> The kernel is GPL, all derived works of a GPL codebase are required to be
> GPL. There is no magic rule about modules. I've stated that repeatedly
> for anything containing a line of code I own. GregKH has made it very
> clear for his code, and so it goes on.

This isn't about adding Linux functionality to a proprietary driver.

It is about the fact that:

1)
Linux's scsi_dh* adds additional SCSI sense processing that conflicts
with processing that a long established competing proprietary driver
also does (and did long before scsi_dh* was introduced).

2)
If Linux is masking SCSI sense that Powerpath needs to see in order to
function then they need a way to shut off that conflicting functionality
in Linux.  What they have enjoyed until now is that Linux has treated
them with kid gloves -- by not always attaching scsi_dh to each SCSI
device during SCSI device scan.

Well it is now time to put Linux (and Linux multipathing) first!  But
doing so while exposing an interface that allows Linux to not have to
make compromises about how good it can be.

> > End result is Linux and PowerPath can coexist without compromising
> > Linux's default handling of multipath LUNs.
> 
> So your specific purpose seems to me to be to enable a third party piece
> of non-free code to hook into a piece of GPL code that it needs (which to
> me implies it is derivative if it does). There is an offence of
> "conspiracy to commit copyright infringement" so merely grinning and
> saying its for a third party doesn't let your company off the hook either.
> 
> You should probably forward it to your legal teams before taking any
> other action. Deleting it won't make it go away. It's up to them to
> decide if they think they can argue properly that the work is not
> derivative. I shall be most intrigued to see anyone make that argument,
> but hey I'm not a lawyer.
> 
> I'm dying to see anyone make the moral argument for it too.

I think you're blinded by some innate violent pain reaction to seeing
s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/

As I said in the header, Linux's ability to properly support scanning
LUNs with multiple paths has been fragile for _years_ purely because we
never had the balls to always attach the scsi_dh which enables Linux to
work well.  We didn't because of fear that we'd break PowerPath.

As a result, Linux has suffered (in the form of reduced functionality).
Now your arguing that the because scsi_dh_detach() will become
EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to
use it?!? -- even though they clearly cannot use scsi_dh* in their
non-GPL driver because all the other scsi_dh* interfaces (like
scsi_dh_attach!) are _GPL?

The two other people (scsi_dh maintainers) that Acked-by this change
work for companies other than EMC.  James is the SCSI maintainer and
understands what is going on here.  Like me, they are domain experts.

What are you?  You're not a lawyer, you're also clearly uninformed.  So
why even weigh in on something if you cannot understand what the hell is
being proposed?

You're being a troll... sad really.

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Alan Cox]

> > The kernel is GPL, all derived works of a GPL codebase are required to be
> > GPL. There is no magic rule about modules. I've stated that repeatedly
> > for anything containing a line of code I own. GregKH has made it very
> > clear for his code, and so it goes on.
> 
> This isn't about adding Linux functionality to a proprietary driver.

Let me quote back your previous message

	"Allow a proprietary non-GPL multipath driver, like EMC
	PowerPath, to detach a scsi_dh using scsi_dh_detach."

what part of that isn't about proprietary drivers.

> If Linux is masking SCSI sense that Powerpath needs to see in order to
> function then they need a way to shut off that conflicting functionality
> in Linux.  What they have enjoyed until now is that Linux has treated
> them with kid gloves -- by not always attaching scsi_dh to each SCSI
> device during SCSI device scan.

They can submit the powerpath code to the GPL kernel and it can get dealt
with nicely.

> > I'm dying to see anyone make the moral argument for it too.
> 
> I think you're blinded by some innate violent pain reaction to seeing
> s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/

No. I'm just reminding you and Red Hat that the kernel is subject to the
GPLv2 licence and that adding/removing _GPL from a symbol doesn't
magically allow you to use proprietary modules as you claim.

> As I said in the header, Linux's ability to properly support scanning
> LUNs with multiple paths has been fragile for _years_ purely because we
> never had the balls to always attach the scsi_dh which enables Linux to
> work well.  We didn't because of fear that we'd break PowerPath.

Thats unfortunate. You mean your company has been intentionally
leaving the Linux kernel poorer for the sake of dubious proprietary
code ?

You might want to stop digging, or at least use a spade not an excavator.

> As a result, Linux has suffered (in the form of reduced functionality).
> Now your arguing that the because scsi_dh_detach() will become
> EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to

I suspect it is already a derived work, but right now that's their
problem. You are making it yours as well.

> The two other people (scsi_dh maintainers) that Acked-by this change
> work for companies other than EMC.  James is the SCSI maintainer and
> understands what is going on here.  Like me, they are domain experts.
> 
> What are you?

I'm a rights holder. Domain expertise isn't relevant here. The code I
provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL
or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the
kernel be modified to match it) cannot call it.

I'm recommended by my lawyer to always remind people of this when such a
claim is made. It ensures that triple damages for wilful infringement
will apply unless the other party can show it reviewed the situation
carefully and its appropriately qualified legal staff reached a different
conclusion.

Obviously what action you take is up to Red Hat's legal (and PR) folks.
However I'd suggest you talk to them first, as per Red Hat training
unless that has changed..

Alan

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

On Fri, Apr 20 2012 at  6:20pm -0400,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > > The kernel is GPL, all derived works of a GPL codebase are required to be
> > > GPL. There is no magic rule about modules. I've stated that repeatedly
> > > for anything containing a line of code I own. GregKH has made it very
> > > clear for his code, and so it goes on.
> > 
> > This isn't about adding Linux functionality to a proprietary driver.
> 
> Let me quote back your previous message
> 
> 	"Allow a proprietary non-GPL multipath driver, like EMC
> 	PowerPath, to detach a scsi_dh using scsi_dh_detach."
> 
> what part of that isn't about proprietary drivers.

Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss
right over the fact that what is being proposed is reasonable.

Any multipath driver should be able to detach a scsi_dh module.  As is
evidenced by the fact that they can already make use of sysfs to do so.

Relaxing the scsi_dh_detach interface makes it easier for a long
standing proprietary driver to get out of Linux's way.

But yeah, I'm sure you'll gloss over that too.
 
> > If Linux is masking SCSI sense that Powerpath needs to see in order to
> > function then they need a way to shut off that conflicting functionality
> > in Linux.  What they have enjoyed until now is that Linux has treated
> > them with kid gloves -- by not always attaching scsi_dh to each SCSI
> > device during SCSI device scan.
> 
> They can submit the powerpath code to the GPL kernel and it can get dealt
> with nicely.
> 
> > > I'm dying to see anyone make the moral argument for it too.
> > 
> > I think you're blinded by some innate violent pain reaction to seeing
> > s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/
> 
> No. I'm just reminding you and Red Hat that the kernel is subject to the
> GPLv2 licence and that adding/removing _GPL from a symbol doesn't
> magically allow you to use proprietary modules as you claim.
> 
> > As I said in the header, Linux's ability to properly support scanning
> > LUNs with multiple paths has been fragile for _years_ purely because we
> > never had the balls to always attach the scsi_dh which enables Linux to
> > work well.  We didn't because of fear that we'd break PowerPath.
> 
> Thats unfortunate. You mean your company has been intentionally
> leaving the Linux kernel poorer for the sake of dubious proprietary
> code ?
> 
> You might want to stop digging, or at least use a spade not an excavator.

_Upstream_ has kept it that way because we've been concerned about
breaking PowerPath in enterprises where Linux is deployed.  Upstream has
been good citizens to the fault of Linux.

Please stop being a drama queen and stop putting words in my mouth.

> > As a result, Linux has suffered (in the form of reduced functionality).
> > Now your arguing that the because scsi_dh_detach() will become
> > EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to
> 
> I suspect it is already a derived work, but right now that's their
> problem. You are making it yours as well.
> 
> > The two other people (scsi_dh maintainers) that Acked-by this change
> > work for companies other than EMC.  James is the SCSI maintainer and
> > understands what is going on here.  Like me, they are domain experts.
> > 
> > What are you?
> 
> I'm a rights holder. Domain expertise isn't relevant here. The code I
> provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL
> or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the
> kernel be modified to match it) cannot call it.

Remind me again when you ever developed anything to do with scsi_dh?

To be clear: PowerPath doesn't _need_ this.  Not even close.

Linux is improved by not having to walk on egg shells that attaching a
helpful linux-only layer in kernel will somehow screw up some 3rd party
software that a customer values.

You still don't get it... yet you'll saber rattle behind generic GPL
lawyer-up nonsense.

It is sad that you didn't even read the important technical aspects of
my previous reply that prove you're being a troll.

I implore you to defer to the domain experts and refrain from continued
late Friday night geek melo-drama.

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Alan Cox]

> Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss
> right over the fact that what is being proposed is reasonable.

I suggest you read the licence document.

> Any multipath driver should be able to detach a scsi_dh module.  As is
> evidenced by the fact that they can already make use of sysfs to do so.

They can call the _GPL version if they are GPL, so there is no problem.

> Relaxing the scsi_dh_detach interface makes it easier for a long
> standing proprietary driver to get out of Linux's way.

So we are back to this being for a proprietary driver trying to link with
GPL code.

> _Upstream_ has kept it that way because we've been concerned about
> breaking PowerPath in enterprises where Linux is deployed.  Upstream has
> been good citizens to the fault of Linux.

Not from where I am standing. It sounds like upstream has suffered for
the benefit of a dubious proprietary module.

> > I'm a rights holder. Domain expertise isn't relevant here. The code I
> > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL
> > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the
> > kernel be modified to match it) cannot call it.
> 
> Remind me again when you ever developed anything to do with scsi_dh?

It's part of the same kernel. It's GPL code. You can take your own code
and relicense it to be non GPL if you wish, but not mine nor Greg's nor
anyone elses.

> To be clear: PowerPath doesn't _need_ this.  Not even close.

Then we don't need to apply it ? Thank you for clarifying that.

> Linux is improved by not having to walk on egg shells that attaching a
> helpful linux-only layer in kernel will somehow screw up some 3rd party
> software that a customer values.

That's a problem for Red Hat. Don't dump it on upstream. If the kernel
would work better with scsi_dh always attached we should always attach
it. It's the problem of the out of tree people how they cope. They'll
figure something out.

And you still have the same confusion

There is no "Linux only" magic in _GPL. Any derivative work of a GPL work
must be distributed under the GPL.

> You still don't get it... yet you'll saber rattle behind generic GPL
> lawyer-up nonsense.

This has gone far enough but it seems your management has already jumped
on it. Not my preferred way of handling such matters but Red Hat legal and
PR need to rein you in before you cause some serious damage.

Alan

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

On Fri, Apr 20 2012 at  7:14pm -0400,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss
> > right over the fact that what is being proposed is reasonable.
> 
> I suggest you read the licence document.
> 
> > Any multipath driver should be able to detach a scsi_dh module.  As is
> > evidenced by the fact that they can already make use of sysfs to do so.
> 
> They can call the _GPL version if they are GPL, so there is no problem.
> 
> > Relaxing the scsi_dh_detach interface makes it easier for a long
> > standing proprietary driver to get out of Linux's way.
> 
> So we are back to this being for a proprietary driver trying to link with
> GPL code.
> 
> > _Upstream_ has kept it that way because we've been concerned about
> > breaking PowerPath in enterprises where Linux is deployed.  Upstream has
> > been good citizens to the fault of Linux.
> 
> Not from where I am standing. It sounds like upstream has suffered for
> the benefit of a dubious proprietary module.
> 
> > > I'm a rights holder. Domain expertise isn't relevant here. The code I
> > > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL
> > > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the
> > > kernel be modified to match it) cannot call it.
> > 
> > Remind me again when you ever developed anything to do with scsi_dh?
> 
> It's part of the same kernel. It's GPL code. You can take your own code
> and relicense it to be non GPL if you wish, but not mine nor Greg's nor
> anyone elses.

The scsi_dh maintainer (Chandra) acked the change.  Hannes, the author of
scsi_dh_attach, acked the change.  You don't have a leg to stand on.
Time for you to face that fact.

> > To be clear: PowerPath doesn't _need_ this.  Not even close.
> 
> Then we don't need to apply it ? Thank you for clarifying that.
> 
> > Linux is improved by not having to walk on egg shells that attaching a
> > helpful linux-only layer in kernel will somehow screw up some 3rd party
> > software that a customer values.
> 
> That's a problem for Red Hat. Don't dump it on upstream. If the kernel
> would work better with scsi_dh always attached we should always attach
> it. It's the problem of the out of tree people how they cope. They'll
> figure something out.
> 
> And you still have the same confusion
> 
> There is no "Linux only" magic in _GPL. Any derivative work of a GPL work
> must be distributed under the GPL.

You asserting something doesn't make it so.

> > You still don't get it... yet you'll saber rattle behind generic GPL
> > lawyer-up nonsense.
> 
> This has gone far enough but it seems your management has already jumped
> on it. Not my preferred way of handling such matters but Red Hat legal and
> PR need to rein you in before you cause some serious damage.

What the hell are you talking about?

Please stop the insanity.

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

On Fri, Apr 20 2012 at  7:14pm -0400,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> There is no "Linux only" magic in _GPL. Any derivative work of a GPL work
> must be distributed under the GPL.

The author and maintainers of the scsi_dh code agreed that relaxing
scsi_dh_detach's export was fine and they acked the change.  Their
rights are important too.

And I understand what you're saying about you and others being rights
holders that have a say.  But communication has broken down because
you've been unwilling to concede that those who have acked this
relaxation _know_ that what scsi_dh provides is _not_ unique
functionality to Linux or Linux SCSI multipathing.

Allowing a proprietary driver to use scsi_dh_detach to unload scsh_dh*'s
associated additional SCSI sense and error processing doesn't implicitly
mean said driver is using derived work to achieve it's comparable
processing.  It simply means their offering reasonably conflicts with
what Linux is providing:

All SCSI multipathing drivers are expected to interpret and react to
SCSI sense information.  Doing so is not an innovation unique to Linux.
Because it is not unique it collides with a long established proprietary
driver's offering.

> > You still don't get it... yet you'll saber rattle behind generic GPL
> > lawyer-up nonsense.
> 
> This has gone far enough but it seems your management has already jumped
> on it. Not my preferred way of handling such matters but Red Hat legal and
> PR need to rein you in before you cause some serious damage.

Yes, secretly switching channels to google+ and lobbing questions about
Red Hat's commitment to free software at one of Red Hat's OSS community
leaders probably isn't the preferred way to handle such things.

But seeing a s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ change clearly does
trigger a negative reaction for some (and that really doesn't make them
"zealots").  However the validity of making that change should not be so
easily stifled with rhetorical GPL violation theory or legal threat.  I
don't respond well to threats but could have certainly used more tact in
my original responses to you.

You capture the hearts and minds of many Linux and GPL stakeholders and
are well respected -- and believe it or not I'm not some naive or
reckless individual.  I am a professional Linux developer who works for
the most respected name in Open Source development.

And I now do _not_ have concerns of legal issues associated with this
change.  I genuinely do appreciate your concern though.

You view this change as detrimental to Linux and think it could
theoretically be enabling proprietary use of derived work.  Reasonable
initial concern but this change does not do that for the intended use --
as hard as it may be to believe it actually benefits Linux multipathing.
And as I said on google+:

"I've been very pragmatic with my reasoning behind this change and
followed the established process of getting author and maintainer
buy-off.  None of us are out to hurt Linux."

With that said, I'm leaving the decision of whether or not to relax
scsi_dh_detach's export in the very capable hands of James Bottomley.

I'll be fine with whatever James decides but do hope that this outcry
will not serve to establish precedent that ties our hands in the future
when comparable decisions need to be made about the improvement of
Linux's interfaces and overall function.

Regards,
Mike

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Alan Cox]

> The author and maintainers of the scsi_dh code agreed that relaxing
> scsi_dh_detach's export was fine and they acked the change.  Their
> rights are important too.

They can only grant rights beyond the GPL providing they remove everyone
elses code. But that isn't the big issue. I wish you'd go talk to your
legal team, then you might understand the real problem here. But you
won't, so I'll hopefully be talking to them tomorrow.

> And I understand what you're saying about you and others being rights
> holders that have a say.  But communication has broken down because
> you've been unwilling to concede that those who have acked this
> relaxation _know_ that what scsi_dh provides is _not_ unique
> functionality to Linux or Linux SCSI multipathing.

"Unwilling to concede". There is nothing to concede. The GPL spells out
the rules. Also if you'd have talked to Red Hat legal you'd have
understood there are other issues here.

> Allowing a proprietary driver to use scsi_dh_detach to unload scsh_dh*'s
> associated additional SCSI sense and error processing doesn't implicitly
> mean said driver is using derived work to achieve it's comparable
> processing.  It simply means their offering reasonably conflicts with
> what Linux is providing:

Can I suggest you don't make legal statements from a Red Hat address
without talking to your legal team. It's not a good idea and tends to get
people into trouble.

> All SCSI multipathing drivers are expected to interpret and react to
> SCSI sense information.  Doing so is not an innovation unique to Linux.
> Because it is not unique it collides with a long established proprietary
> driver's offering.

That's their problem. They chose not to play ball, and they are going to
have to run after us and sort their own mess out. They'll cope as they've
had a lot of practice at it.

> Yes, secretly switching channels to google+ and lobbing questions about
> Red Hat's commitment to free software at one of Red Hat's OSS community
> leaders probably isn't the preferred way to handle such things.

I didn't do anything secret. How is posting publically "secret". Also I
made very sure the people who needed to see it in Red Hat did, so they
can do something about it and rein you in. It's had the right effect and
it means the right folks in Red Hat can look at the issue itself.

> You capture the hearts and minds of many Linux and GPL stakeholders and
> are well respected -- and believe it or not I'm not some naive or
> reckless individual.  I am a professional Linux developer who works for
> the most respected name in Open Source development.

I spent ten years at Red Hat, I'd like them to keep that reputation which
is one of the reasons this bothers me a lot. The other being the legal
issues.

> And I now do _not_ have concerns of legal issues associated with this
> change.  I genuinely do appreciate your concern though.

Well that's for Red Hat management and legal to determine, unless you are
also a practicing IP lawyer as well ?

> With that said, I'm leaving the decision of whether or not to relax
> scsi_dh_detach's export in the very capable hands of James Bottomley.
> 
> I'll be fine with whatever James decides but do hope that this outcry
> will not serve to establish precedent that ties our hands in the future
> when comparable decisions need to be made about the improvement of
> Linux's interfaces and overall function.

This isn't tying your hands. There are two things which tie your hands
here - the GPL (intentionally) and certain properties of US law - which
I'll discuss with the appropriate Red Hat people in an appropriate forum.
You clearly are not that appropriate person.

Perhaps after that they can explain to you in the proper manner internally

- Why legal matters should be referred to lawyers for checking.
- Why your patch may raise a particularly nasty potential problem if it
  were merged

Alan

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Mike Snitzer]

Funny thing happens when you assume too much...

Anyway, your no compromises approach is admirable but it doesn't erase
the fact that all proprietary Linux drivers use EXPORT_SYMBOL code.

So what you're really saying is no proprietary drivers are allowed to be
loaded into a Linux kernel.  Nice that you've made this scsi_dh_detach
change the frontline of a battle that has already been lost years ago.

Thanks for your time,
Mike

Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL

[Alan Cox]

> Anyway, your no compromises approach is admirable but it doesn't erase
> the fact that all proprietary Linux drivers use EXPORT_SYMBOL code.

People still steal from shops. It doesn't mean we should abolish the idea
of theft.

> So what you're really saying is no proprietary drivers are allowed to be
> loaded into a Linux kernel.

The GPL defines the boundary. Whether it is possible for a work to be
non-derivative and a kernel module is a matter for the lawyers to debate.
If it is derivative however I don't think there is quite so much doubt.

Linus wrote the following

|>"On Wed, 3 Dec 2003, Kendall Bennett wrote:
|>
|> I have heard many people reference the fact that the although the Linux
|> Kernel is under the GNU GPL license, that the code is licensed with an
|> exception clause that says binary loadable modules do not have to be
|> under the GPL.
|
|Nope. No such exception exists.
|
|There's a clarification that user-space programs that use the standard
|system call interfaces aren't considered derived works, but even that
|isn't an "exception" - it's just a statement of a border of what is
|clearly considered a "derived work". User programs are _clearly_ not
|derived works of the kernel, and as such whatever the kernel license is
|just doesn't matter.
|
|And in fact, when it comes to modules, the GPL issue is exactly the same.
|The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
|anything that is a derived work has to be GPL'd. It's that simple.

(and then goes on to discuss further his own personal opinion)

http://kerneltrap.org/node/1735

But you still misunderstand the fundamental problem, and this really
needs to be discussed with Red Hat legal.

Alan