Prev: Don't apply for write lock on tasklist_lock if parent doesn't ptrace other processes
Next: [PATCH] sched: No need for bootmem special cases
From: Andrew Morton on 15 Jul 2010 16:10
(cc linux-arm-kernel)

On Tue, 13 Jul 2010 15:05:58 +0100
Lee Jones <lee.jones(a)canonical.com> wrote:

> >From 219005d9522043bc42ddb51d59688959eed0d443 Mon Sep 17 00:00:00 2001
> From: Lee Jones <lee.jones(a)canonical.com>
> Date: Tue, 13 Jul 2010 15:02:17 +0100
> Subject: [PATCH] UBUNTU: [Upstream] Stop ARM boards crashing when CUPS is loaded
>
> BugLink: http://bugs.launchpad.net/bugs/601226
>
> When CUPS loads, it tries to load several drivers that it may need.
> When one of these drivers, specifically parport_pc is loaded on ARM
> based systems, it causes a segmentation fault as the ISA addresses
> which are attempted are not writable on non-PC based architectures.
> This code prevents ISA addresses from being attempted except on x86.
>

That sounds like a pretty serious problem. But presumably it isn't -
otherwise it would have been fixed earlier!

So what actions are required to trigger this bug and why aren't others
seeing it?

> arch/arm/include/asm/parport.h | 7 +++++--

This should probably go via the arm tree.

>
> diff --git a/arch/arm/include/asm/parport.h b/arch/arm/include/asm/parport.h
> index 26e94b0..a1874f8 100644
> --- a/arch/arm/include/asm/parport.h
> +++ b/arch/arm/include/asm/parport.h
> @@ -9,10 +9,13 @@
> #ifndef __ASMARM_PARPORT_H
> #define __ASMARM_PARPORT_H
>
> -static int __devinit parport_pc_find_isa_ports (int autoirq, int autodma);
> static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)

It's strange that this function isn't marked inline. It's in a .h
file. But many arch/*/include/asm/parport.h's do it this way. They're
probably broken. It adds a risk that unneeded code will be generated
into each compilation unit which includes these headers, although gcc
can probably fix that, depending on the version. Plus it's plain odd.

> {
> - return parport_pc_find_isa_ports (autoirq, autodma);
> +/* parport_pc_find_isa_ports uses direct register addresses which are
> + * only correct on x86 architectures. This may have undesirable
> + * consequences (including segfaults) when used on other architectures.
> + */
> + return 0;
> }

That comment layout is whacky. I did this:

--- a/arch/arm/include/asm/parport.h~parport-prevent-arm-boards-frmo-crashing-when-cups-is-loaded-fix
+++ a/arch/arm/include/asm/parport.h
@@ -9,12 +9,13 @@
#ifndef __ASMARM_PARPORT_H
#define __ASMARM_PARPORT_H

-static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)
+static int __devinit parport_pc_find_nonpci_ports(int autoirq, int autodma)
{
-/* parport_pc_find_isa_ports uses direct register addresses which are
- * only correct on x86 architectures. This may have undesirable
- * consequences (including segfaults) when used on other architectures.
- */
+ /*
+ * parport_pc_find_isa_ports() uses direct register addresses which are
+ * only correct on x86 architectures. This may have undesirable
+ * consequences (including segfaults) when used on other architectures.
+ */
return 0;
}

_

--
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: Martin Michlmayr on 16 Jul 2010 05:50
* Lee Jones <lee.jones(a)canonical.com> [2010-07-16 10:08]:
> >> That sounds like a pretty serious problem. But presumably it isn't -
> >> otherwise it would have been fixed earlier!
>
> Well it is a problem on OMAP based boards.

It's not just OMAP. Debian received a similar bug report a few days
too and it was on Marvell Orion hardware. I simply disabled the
parport_pc module on ARM.

--
Martin Michlmayr
http://www.cyrius.com/
--
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: Greg KH on 26 Jul 2010 18:30
On Fri, Jul 16, 2010 at 12:12:07PM +0100, Lee Jones wrote:
> On 16/07/10 10:32, Lee Jones wrote:
> >> The best solution is probably for the parport code to go through a
> >> modernisation cycle like the serial code did, essentially using
> >> platform devices to pass the base addresses. This would make the
> >> driver more portable, and eliminates this problem entirely (because
> >> platforms which don't have parports won't register the platform device(s)
> >> necessary for parport to even probe illegal addresses.)
>
> I have lobbied for one of our partners to conduct this work, but I don't
> think this would be something that is in their interest to fix.
> Nevertheless, I am currently waiting on a reply from them.
>
> FAO GregKH,
>
> Do you think this would be something that may interest you and your Linux
> drivers project? Or perhaps a student who wants to get their feet wet and
> play with some platform driver code.

Yes, sure, that would be good. Post it on the driverdevel mailing list
and see who responds.

thanks,

greg k-h
--
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: Don't apply for write lock on tasklist_lock if parent doesn't ptrace other processes
Next: [PATCH] sched: No need for bootmem special cases