linux-kernel - Re: todays git: WARNING: at drivers/ata/libata-sff.c:1017 ata_sff_hsm

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: <1231598170.3642.12.camel@localhost.localdomain>
Date:	Sat, 10 Jan 2009 08:36:10 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Sergei Shtylyov <sshtylyov@...mvista.com>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	linux-ide@...r.kernel.org, Jeff Garzik <jgarzik@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: todays git: WARNING: at drivers/ata/libata-sff.c:1017
	ata_sff_hsm_move+0x45e/0x750()

On Sat, 2009-01-10 at 12:21 +0000, Alan Cox wrote:
> >    That's the typical REQUEST SENSE command with 18-byte data length.
> 
> Which means something has become horribly broken in the core libata stack.
> An 18 byte inquiry would have 18 bytes as the *last* sg element. That
> would therefore not trigger the WARN_ON. Someone has passed an sg list
> that isn't properly terminated perhaps ?
> 
> I wonder if the pad code broke this.

I don't think it's anything to do with padding or the block layer.

I think we sent out a request sense with 96 bytes of space for a reply,
which is bog standard for SCSI. The device sent back a payload of 18
bytes, which is perfectly legal ... request sense is a variable payload
command, the device doesn't have to fill the buffer we give it.

18, by the way, is the typical reply length for non descriptor sense
format with no additional information, so this is really expected
behaviour.

Your problem is that the *device* is wanting to transfer a set of bytes
not divisible by four.  If you want to use word based PIO, you'll have
to fall back to collecting bytes for the last two.  Alternatively, you
could just do byte PIO for all reply lengths like this ... they occur
all over the SCSI standard, but not usually in critical paths.

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/