linux-kernel - Re: What's in libata-dev.git

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:	Mon, 11 Sep 2006 21:51:06 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Jens Axboe <axboe@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jeff Garzik <jeff@...zik.org>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>
Subject: Re: What's in libata-dev.git

On Mon, Sep 11 2006, Linus Torvalds wrote:
> 
> 
> On Mon, 11 Sep 2006, Jens Axboe wrote:
> > 
> > So this is a confirmed, broken case? Why has no one complained for 2.4
> > and 2.6?
> 
> Oh, I didn't even notice that we do that by default already. That's a bit 
> scary - I remember people having their disks trashed.
> 
> Maybe the broken disks are old enough to not be an issue any more, or 
> maybe something else makes it effectively impossible to trigger in 
> practice?

Well, as I said, I don't think we ever saw a case that was demonstrably
due to the 256 sector issue. And I really don't think it is as obscure a
fact that people seem to think it is.

> You do need to get 32 pages of contiguous IO for it to happen, and while I 
> don't see anything else that would limit it, maybe there is something that 
> does? (Some other limiter like max_phys_segments might, but that 
> particular one defaults to much more than 32)

It should be pretty trivial to reach, the other IDE limits are basically
way beyond 128kb of contig io. People are hitting this during boot even
I bet, so...

> Of course, we do hopefully handle requests that fail a lot more 
> gracefully these days, so if the drive says it didn't do it, maybe we just 
> fix it up properly, in a way we didn't use to.. Ie we may have fixed the 
> thing that caused corruption just by fixing something else ;)

If the firmware is really buggy in that it doesn't recognise the 0 case
as being 256, you'd see immediate transfer errors. This going by
unnoticed is highly unlikely.

-- 
Jens Axboe

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