linux-kernel - Re: long boot delays caused by 070ad7e7 floppy change

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: <CA+55aFyvzz3Lp9zeA6X+QMan0iZFWq_0Xd+ff_trnP1tpn2iJQ@mail.gmail.com>
Date:	Tue, 3 Jul 2012 10:07:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Calvin Walton <calvin.walton@...stin.ca>
Cc:	Andi Kleen <andi@...stfloor.org>, Jiri Kosina <jkosina@...e.cz>,
	linux-kernel@...r.kernel.org, shemminger@...tta.com
Subject: Re: long boot delays caused by 070ad7e7 floppy change

On Tue, Jul 3, 2012 at 6:47 AM, Calvin Walton <calvin.walton@...stin.ca> wrote:
>
> I'm seeing the same issue, so I've given this a try. Here are the
> messages printed when floppy debugging is enabled:
>
> [    0.714318] floppy0: reschedule timeout lock fdc
> [   20.729798] floppy0: reschedule timeout do wakeup

Ok, that 20 s timeout is a hint.

20s is the floppy "max timeout" value, and it's used in various
places. HOWEVER. The "lock fdc" case absolutely should not be using
that timeout. It should use the floppy "UDP->timeout" value, which
should be just 3s. Which is still a long time, but not nearly as long
as that.

Can you add a DPRINT() to the lock_fdc() function just before calling
reschedule_timeout() to print out what the "drive" is? Something like
yhhis (whitespace-damaged due to cut-and-paste):

    diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
    index cce7df367b79..00b52cef9d22 100644
    --- a/drivers/block/floppy.c
    +++ b/drivers/block/floppy.c
    @@ -876,6 +876,7 @@ static int lock_fdc(int drive, bool interruptible)

     	command_status = FD_COMMAND_NONE;

    +	DPRINT("lock_fdc: %d (out of %d)\n", drive, N_DRIVE);
     	reschedule_timeout(drive, "lock fdc");
     	set_fdc(drive);
     	return 0;

because maybe the 'drive' variable is crap there. In fact, add a

        WARN_ON_ONCE(dive < 0 || drive >= N_DRIVE);

in there too. Because if it is out of range, I'd want to see the call chain.

(And you still need floppy=debug to see that debug message, of course).

                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/