Prev: md versus partition scanning (bd_invalidated)
Next: v3 Define memory_block_size_bytes() for ppc/pseries
From: Marcelo Tosatti on 21 Jul 2010 16:10
On Fri, Jun 11, 2010 at 10:32:23AM -0700, Stephen Hemminger wrote:
> Fix races between timers and bottom half by using delayed work
> and a single threaded queue.
>
> Still needs more testing.
>
> Signed-off-by: Stephen Hemminger <shemminger(a)vyatta.com>
>
> ---
> drivers/block/floppy.c | 172 ++++++++++++++++++++++++++-----------------------
> 1 file changed, 94 insertions(+), 78 deletions(-)

Stephen,

Can confirm this fixes the following oops seen under KVM guests.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000035
IP: [<ffffffff812141f0>] setup_rw_floppy+0x229/0x2ca
PGD 284b8067 PUD 3d79f067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/resource
CPU 1
Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables
scsi_wait_scan uhci_hcd ohci_hcd ehci_hcd

Pid: 28, comm: events/1 Not tainted 2.6.35-rc5-35033-g14e84ff #221
/Bochs RIP: 0010:[<ffffffff812141f0>] [<ffffffff812141f0>] setup_rw_floppy+0x229/0x2ca
RSP: 0018:ffff88003e1a1e60 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000009 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000286 RDI: 0000000000000000
RBP: 00000000000000da R08: 0000000000000000 R09: ffffffff81214bdb
R10: 0000000000000000 R11: ffffffff817f7660 R12: 0000000000000000
R13: 0000000000000008 R14: ffffffff81214bdb R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff880001a40000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000035 CR3: 000000003a428000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/1 (pid: 28, threadinfo ffff88003e1a0000, task
ffff88003e19a8f0)
Stack:
0000000000000000 ffff88003e1a1ef8 ffffffff81692f00 ffff880001a56680
<0> ffff88003e19a8f0 ffffffff810466f1 0000000000000000 ffff88003e19a8f0
<0> ffffffff810495ad ffff88003e1a1ea8 ffff88003e1a1ea8 ffff88003e1a1ef8
Call Trace:
[<ffffffff810466f1>] ? worker_thread+0x150/0x1f0
[<ffffffff810495ad>] ? autoremove_wake_function+0x0/0x2e
[<ffffffff810465a1>] ? worker_thread+0x0/0x1f0
[<ffffffff810492bf>] ? kthread+0x79/0x81
[<ffffffff81002be4>] ? kernel_thread_helper+0x4/0x10


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 22 Jul 2010 15:20
On Wed, Jul 21, 2010 at 12:55 PM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote:
>
> Can confirm this fixes the following oops seen under KVM guests.
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000035

Hmm. That does make me want to merge it early, but at the same time I
suspect it has gotten almost no testing on real hardware. So despite
looking "obvious" and fixing one bug, I'm a bit nervous and I suspect
that the prudent thing to do is still to take it early in the 2.3.36
merge window, and just mark it for stable.

Is anybody a big floppy user (on _real_ hardware, preferably with more
than a couple machines) and could test it? I do feel kind of stupid
for not taking it, but I don't have the hardware or the interest in
really installing any in my current machines, and even if it looks
fine and fixes some issue, I just don't feel safe enough without some
more confirmation... As far as I know, the floppy oops thing has
_only_ been seen on KVM (likely due to timing that just doesn't happen
on real hardware), and while the KVM floppy emulation is probably
fairly good, it also clearly isn't equivalent to hardware.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: david on 22 Jul 2010 18:30
I don't use floopies much anymore, but I've got a fair number of machines
around that have floppy drives (purchased across about 6 years with from a
couple vendors and a variety of motherboards)

If someone can go to the effort of documenting what testing you want done
I may be able to do it.

I would be installing new builds onto the machines to test them, so
you can do testing that locks up the boxes without impacting anything.

the easier it is to do the tests, the more machines I can test on
(bootable CD images that I could just pop in and then check the screen
later would be ideal ;-)

these systems will not have network access.

David Lang


On Thu, 22 Jul 2010, Linus
Torvalds wrote:

> On Wed, Jul 21, 2010 at 12:55 PM, Marcelo Tosatti <mtosatti(a)redhat.com> wrote:
>>
>> Can confirm this fixes the following oops seen under KVM guests.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000035
>
> Hmm. That does make me want to merge it early, but at the same time I
> suspect it has gotten almost no testing on real hardware. So despite
> looking "obvious" and fixing one bug, I'm a bit nervous and I suspect
> that the prudent thing to do is still to take it early in the 2.3.36
> merge window, and just mark it for stable.
>
> Is anybody a big floppy user (on _real_ hardware, preferably with more
> than a couple machines) and could test it? I do feel kind of stupid
> for not taking it, but I don't have the hardware or the interest in
> really installing any in my current machines, and even if it looks
> fine and fixes some issue, I just don't feel safe enough without some
> more confirmation... As far as I know, the floppy oops thing has
> _only_ been seen on KVM (likely due to timing that just doesn't happen
> on real hardware), and while the KVM floppy emulation is probably
> fairly good, it also clearly isn't equivalent to hardware.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 22 Jul 2010 19:10
On Thu, Jul 22, 2010 at 3:22 PM, <david(a)lang.hm> wrote:
>
> I don't use floopies much anymore, but I've got a fair number of machines
> around that have floppy drives (purchased across about 6 years with from a
> couple vendors and a variety of motherboards)
>
> If someone can go to the effort of documenting what testing you want done I
> may be able to do it.

It doesn't really need to be all that extensive. The "interesting"
operations tend to be (apart from just reading and writing data, of
course):

- formatting a floppy (it's special, and historically relatively
often broke without people noticing for a while)

- the floppy format auto-detection

- floppy disk change detection

so just formatting floppies to a couple of different formats (ie do
you possibly have DD and HD floppies?), mkfs them and write something
to them, and then moving them to another machine and checking that
reading the data off them through the auto-detected formats (/dev/fd0)
works and gives the right results (just sha1sum the files).

The disk change detect can be a bit hard to see. It's unreliable with
some media, so iirc we always flush caches after the last close (we
didn't use to do that, and the disk change detection needed to just be
reliable - and you could test that the disk change logic worked by
just timing a read of the media and seeing if it came out of the
cache). I think for floppies, the thing to see is if format detection
works correctly when you switch between formats. Perhaps also the
read-only marker (ie switch the floppy between read-only and
read-write, and see that the status of the floppy is correctly
noticed: you should get a nice error if you try to write a read-only
floppy, rather than getting IO errors).

I can't think of anything else relevant.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: md versus partition scanning (bd_invalidated)
Next: v3 Define memory_block_size_bytes() for ppc/pseries