linux-kernel - Re: Linux 2.6.25-rc4

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:	Tue, 18 Mar 2008 20:56:45 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
cc:	Anders Eriksson <aeriksson@...tmail.fm>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jens Axboe <jens.axboe@...cle.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.25-rc4

On Tue, 18 Mar 2008, Linus Torvalds wrote:
> 
> But the absolute first thing we should do is to make the code at least as 
> robust as it used to be, and preferably aim _higher_ in robustness rather 
> than lower!

An example of this "aim higher", I think that we obviously should complete 
the command if the controller says it's done with it (like the old 
"drive_cmd_intr()" code used to do), but we might decide that printing a 
warning would be the proper way to then also inform the user about the 
fact that we expected the command to want more data, but it never did.

That way, the code not only handles the unexpected situation gracefully, 
but the very fact that it was unexpected also gets logged.

[ And at that point your patch to make the specific SMART subcommands have 
  strict logic about the data direction will actually matter - although 
  maybe it turns out that there are _other_ tools that send other 
  commands, and we decide that the warning isn't useful after all! ]

The thing is, I know for a fact that some system vendors use Linux for 
burn-in and testing/setup of their components, and I would not be in the 
least surprised if some of them use HDIO_DRIVE_CMD to do some 
vendor-specific stuff.

And I think it's a fine thing to try to use just one set of code (the 
taskfile code) to drive all these special commands, but the fact is, the 
old HDIO_DRIVE_CMD interface fundamentally doesn't even _have_ the 
capability to specify the total taskfile state.

So we simply know as a fact that
 (a) people do use an interface that used to work (HDIO_DRIVE_CMD)
and
 (b) it will fundamentally *never* have complete taskfile state, so we 
     *have* to live with the fact that some of our commands simply don't 
     have the full state that the taskfile code may have historically 
     depended on but the old ide_drive_cmd() code didn't and cannot depend 
     on.

Your patch tries to fix (b), but we also know that it fundamentally simply 
*cannot* fix it for all cases. So even trying to is really pretty futile, 
I think (although we can obviously hope that nobody uses HDIO_DRIVE_CMD 
any more for anything but SMART and really simple commands, but that 
sounds rather unlikely).

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