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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1334935036.13001.27.camel@dabdike>
Date:	Fri, 20 Apr 2012 19:17:16 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Mike Snitzer <snitzer@...hat.com>
Cc:	linux-scsi@...r.kernel.org, Hannes Reinecke <hare@...e.de>,
	Chandra Seetharaman <sekharan@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath
 drivers to use scsi_dh_detach

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/