linux-kernel - Re: [patch] floppy: suspend/resume fix

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: <20061112194000.GC14005@flint.arm.linux.org.uk>
Date:	Sun, 12 Nov 2006 19:40:01 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Mikael Pettersson <mikpe@...uu.se>, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] floppy: suspend/resume fix

On Sun, Nov 12, 2006 at 07:09:53PM +0100, Ingo Molnar wrote:
> 
> * Mikael Pettersson <mikpe@...uu.se> wrote:
> 
> > Sorry, no joy. The first access post-resume still fails and generates:
> 
> ok, then someone who knows the floppy driver better than me should put 
> the right stuff into the suspend/resume hooks :-)

At a guess, what's probably happening is that the floppy drive, when
powered on after resume, reports "disk changed" because it doesn't
know any better.

We interpret "disk changed" to mean the disk has been removed and
possibly changed (which _is_ correct) and thereby abort any further
IO (irrespective of resume.)

Now, consider the following two scenarios:

1. You suspend and then resume, leaving the disk in the floppy drive.

2. You suspend, remove the floppy disk, insert a totally different disk
   in the same drive, and then resume.

What should you do?  (Hint: without reading the disk and comparing it
with what you have cached you don't know if the disk has been changed
or not.)

If you argue that in case (1) you should continue to allow IO, then
you potentially end up scribbling over a disk when someone does (2).

So I'd argue that the behaviour being seen by Mikael is the _safest_
behaviour, and the most correct behaviour given the limitations of
the hardware.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/