linux-kernel - Re: [PATCH 2/3] scsi: add scsi_device->alt

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]

Date:	Sun, 10 May 2009 10:26:48 +0900
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	jeff@...zik.org, linux-ide@...r.kernel.org, jens.axboe@...cle.com,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	Mauelshagen@...Hat.com, dm-devel@...Hat.com,
	dan.j.williams@...il.com
Subject: Re: [PATCH 2/3] scsi: add scsi_device->alt_capacity

Hello, James.

James Bottomley wrote:
> On Sun, 2009-05-10 at 01:09 +0900, Tejun Heo wrote:
>> James Bottomley wrote:
>>> This is done at slightly the wrong level.  Capacity is actually a
>>> property of struct scsi_disk not struct scsi_device ... shouldn't
>>> alt_capacity be at the same level?
>> Hmmm... I think that was my first try and then I moved it to sdev for
>> some reason I can't rememer now.  I'll look into it again and try to
>> move it into sdev.
> 
> Really one of the things I was wondering is why even scsi_disk ...
> capacity is in there, but it's also in gendisk, so I've thought
> (admittedly never translated it to action) that we could just remove the
> duplication in scsi_disk.
> 
> This alt_capacity looks to be a pure ATA thing...  I can't find it
> in the SCSI specs and there doesn't seem to be a SAT equivalent of
> the commands.  Ideally, what should be happening is that the ata ULD
> would issue the capacity commands and just set the block
> alt_capacity without having to worry about transporting the value up
> and down the stack.  Matthew Wilcox thought we could begin an
> implementation of the ATA uld using the ATA_16 command to transport
> it through SCSI ... this might provide the good reason to begin
> that.

Yeap, it's a purely ATA specific workaround.

Now I remembered what was the problem.  The problem was that the
latest hook libata can use is ->slave_configure which is called before
HLD attaches, so there's no sdkp or genhd associated during libata
configuration.  Longer term, this definitely is something which should
be stripped out of SCSI whether that happens with ATA HLD on top of
SCSI or a completely separate stack.  Any better ideas on how to work
around this for now?

Thanks.

-- 
tejun
--
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/