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: <1343295687.3115.27.camel@dabdike>
Date:	Thu, 26 Jul 2012 13:41:27 +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:27 +0200, Paolo Bonzini wrote:
> Il 26/07/2012 11:21, James Bottomley ha scritto:
> >> > 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.
> 
> But virtio-scsi gets it right even if you use method=0 and method=1
> interchangeably.

I don't actually understand this statement.  LUNS < 256 may be encoded
either way (they should be encoded with address method=0 but they don't
have to be) if you address the array with the wrong method, it doesn't
have to give you your lun.  Therefore we have to map back to whatever
the array gave us.  Hence the 1:1 mapping.  You're proposing an
injective mapping, so you can't reliably reverse it; that's why we don't
do it that way in SCSI.

> ibmvscsi (see function lun_from_dev) does something similar to
> virtio-scsi, except here I need both directions.
> 
> > That does mean that arrays that use address method=1 in REPORT LUNS have
> > their lun numbers start at 16384.
> 
> That is ugly.  I can see how it may be needed on buggy hardware, but
> here we know it's not.

It's nothing to do with buggy hardware ... it's to do with having an
exact representation of the lun.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ