scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach

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

---
 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]

index 23149b9..a550de1 100644
@@ -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

No problem with that.

Cheers,

Hannes

Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Hi James,

Can we get this patch staged for 3.5?

Thanks,
Mike

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.

---
 drivers/scsi/device_handler/scsi_dh.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 23149b9..a550de1 100644
@@ -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

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

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

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,

Regards,

Chandra

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.

---
 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!

index 23149b9..a550de1 100644
@@ -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

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.

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

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

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

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.

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.

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.

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

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.

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.

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

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

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.

_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.

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.

I suggest you read the licence document.

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

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

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

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.

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

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.

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

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.

You asserting something doesn't make it so.

What the hell are you talking about?

Please stop the insanity.

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.

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

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.

"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.

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.

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.

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.

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.

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

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

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

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

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