[PATCH #upstream-fixes] libata: clear PIO pad area

[PATCH #upstream-fixes] libata: clear PIO pad area

[Tejun Heo]

ata_sff_data_xfer[32]() use pad area if the transfer size isn't
multiple of transfer size; however, this area wasn't cleared and
garbage data in pad area could be transferred to the device.  Make
sure the pad area is cleared.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Lei Ming <tom.leiming@gmail.com>
---
 drivers/ata/libata-sff.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index c24127d..2487ea7 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -569,7 +569,7 @@ unsigned int ata_sff_data_xfer(struct ata_device *dev, unsigned char *buf,
 
 	/* Transfer trailing byte, if any. */
 	if (unlikely(buflen & 0x01)) {
-		unsigned char pad[2];
+		unsigned char pad[2] = { };
 
 		/* Point buf to the tail of buffer */
 		buf += buflen - 1;
@@ -628,7 +628,7 @@ unsigned int ata_sff_data_xfer32(struct ata_device *dev, unsigned char *buf,
 
 	/* Transfer trailing bytes, if any */
 	if (unlikely(slop)) {
-		unsigned char pad[4];
+		unsigned char pad[4] = { };
 
 		/* Point buf to the tail of buffer */
 		buf += buflen - slop;

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Sergei Shtylyov]

Hello.

On 06-09-2011 8:09, Tejun Heo wrote:

> ata_sff_data_xfer[32]() use pad area if the transfer size isn't
> multiple of transfer size; however, this area wasn't cleared and
> garbage data in pad area could be transferred to the device.  Make
> sure the pad area is cleared.

> Signed-off-by: Tejun Heo<tj@kernel.org>
> Cc: Lei Ming<tom.leiming@gmail.com>

    And what's the problem with garbage data? Why it's worse than 0s?

WBR, Sergei

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Alan Cox]

On Tue, 06 Sep 2011 14:06:23 +0400
Sergei Shtylyov <sshtylyov@mvista.com> wrote:

> Hello.
> 
> On 06-09-2011 8:09, Tejun Heo wrote:
> 
> > ata_sff_data_xfer[32]() use pad area if the transfer size isn't
> > multiple of transfer size; however, this area wasn't cleared and
> > garbage data in pad area could be transferred to the device.  Make
> > sure the pad area is cleared.
> 
> > Signed-off-by: Tejun Heo<tj@kernel.org>
> > Cc: Lei Ming<tom.leiming@gmail.com>
> 
>     And what's the problem with garbage data? Why it's worse than 0s?

It's potentially externally observable on things like an eSATA port so
it probably should be cleared just as we do with network padding.

For the CDB case we clear the rest of the CDB anyway I believe because
some old PATA stuff used to freak if the padding wasn't zero.

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Tejun Heo]

Hello,

On Tue, Sep 06, 2011 at 02:06:23PM +0400, Sergei Shtylyov wrote:
> On 06-09-2011 8:09, Tejun Heo wrote:
> 
> >ata_sff_data_xfer[32]() use pad area if the transfer size isn't
> >multiple of transfer size; however, this area wasn't cleared and
> >garbage data in pad area could be transferred to the device.  Make
> >sure the pad area is cleared.
> 
> >Signed-off-by: Tejun Heo<tj@kernel.org>
> >Cc: Lei Ming<tom.leiming@gmail.com>
> 
>    And what's the problem with garbage data? Why it's worse than 0s?

There were devices which puke on random garbage at the end of CDB and
in general sending indeterministic garbage to external device is a bad
idea.  It increases chance of problems which can be difficult to
reproduce and track down while gaining nothing.  It really is a stupid
thing to do.

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Sergei Shtylyov]

Hello.

On 09/06/2011 08:58 PM, Tejun Heo wrote:

>>> ata_sff_data_xfer[32]() use pad area if the transfer size isn't
>>> multiple of transfer size; however, this area wasn't cleared and
>>> garbage data in pad area could be transferred to the device.  Make
>>> sure the pad area is cleared.

>>> Signed-off-by: Tejun Heo<tj@kernel.org>
>>> Cc: Lei Ming<tom.leiming@gmail.com>

>>     And what's the problem with garbage data? Why it's worse than 0s?

> There were devices which puke on random garbage at the end of CDB and

    Note that ATAPI CDBs are always aligned to 4 bytes, so this path should 
never be hit when sending them.

> in general sending indeterministic garbage to external device is a bad
> idea.  It increases chance of problems which can be difficult to
> reproduce and track down while gaining nothing.

    Problems with "don't care" padding bytes? Dunno...

> It really is a stupid thing to do.

    Well, at least the old code was equally stupid before I patched it. :-)

> Thanks.

WBR, Sergei

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Sergei Shtylyov]

Hello.

On 09/06/2011 09:23 PM, Sergei Shtylyov wrote:

>>>> ata_sff_data_xfer[32]() use pad area if the transfer size isn't
>>>> multiple of transfer size; however, this area wasn't cleared and
>>>> garbage data in pad area could be transferred to the device. Make
>>>> sure the pad area is cleared.

>>>> Signed-off-by: Tejun Heo<tj@kernel.org>
>>>> Cc: Lei Ming<tom.leiming@gmail.com>

>>> And what's the problem with garbage data? Why it's worse than 0s?

>> There were devices which puke on random garbage at the end of CDB and

> Note that ATAPI CDBs are always aligned to 4 bytes, so this path should never be
> hit when sending them.

>> in general sending indeterministic garbage to external device is a bad
>> idea. It increases chance of problems which can be difficult to
>> reproduce and track down while gaining nothing.

> Problems with "don't care" padding bytes? Dunno...

>> It really is a stupid thing to do.

> Well, at least the old code was equally stupid before I patched it. :-)

    Only in ata_sff_data_xfer32(). It was I who removed the padding buffer 
initialization in ata_sff_data_xfer()...

>> Thanks.

WBR, Sergei

Re: [PATCH #upstream-fixes] libata: clear PIO pad area

[Tejun Heo]

On Tue, Sep 06, 2011 at 09:23:01PM +0400, Sergei Shtylyov wrote:
> >There were devices which puke on random garbage at the end of CDB and
> 
>    Note that ATAPI CDBs are always aligned to 4 bytes, so this path
> should never be hit when sending them.

Ah, okay, but still, let's just clear it.  There's nothing to be
gained by not clearing several bytes there.

> >in general sending indeterministic garbage to external device is a bad
> >idea.  It increases chance of problems which can be difficult to
> >reproduce and track down while gaining nothing.
> 
>    Problems with "don't care" padding bytes? Dunno...

Oh yeah, IIRC there were multiple devices which puked on "don't care"
garbage bytes in CDB.  Don't underestimate the crappiness of cheap
ATAPI devices. :)

Thanks.

-- 
tejun