linux-kernel - Re: [PATCH 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number

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: <1343294472.3115.22.camel@dabdike>
Date:	Thu, 26 Jul 2012 13:21:12 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN
 number

On Thu, 2012-07-26 at 11:04 +0200, Paolo Bonzini wrote:
> Il 26/07/2012 10:52, James Bottomley ha scritto:
> >> > +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
> >> > +{
> >> > +	unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
> >> > +	return lun & 16383;
> >> > +}
> >> > +
> > Why are you rolling your own incomplete version of scsilun_to_int here?
> 
> Because scsilun_to_int does not do the AND, so it would have exactly the
> same bug I'm fixing.

It's not a bug ... it's the encoding.  All the other devices use this
too.  Ideally we should have switched to 64 bit lun numbers for the
encoding to be exact, but nothing so far has gone over 32 bits.  If we
don't encode the Address method as part of the lun number, we don't get
the reverse transform right and the addressing often fails.

That does mean that arrays that use address method=1 in REPORT LUNS have
their lun numbers start at 16384.

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/