Re: 2.6.17-mm4

Re: 2.6.17-mm4

[Michal Piotrowski]

Hi,

On 29/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm4/
>
>

This looks very strange.

BUG: unable to handle kernel paging request at virtual address 6b6b6c07
printing eip:
c0138594
*pde=00000000
Oops: 0002 [#1]
4K_STACK PREEMPT SMP
last sysfs file /class/net/eth0/address
Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
p4_clockmod speedstep_lib binfmt_misc

(gdb) list *0xc0138594
0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
warning: Source file is more recent than executable.

91       *
92       * Atomically increments @v by 1.
93       */
94      static __inline__ void atomic_inc(atomic_t *v)
95      {
96              __asm__ __volatile__(
97                      LOCK_PREFIX "incl %0"
98                      :"=m" (v->counter)
99                      :"m" (v->counter));
100     }

Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm4/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm4

[Dave Jones]

On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:

 > This looks very strange.
 > 
 > BUG: unable to handle kernel paging request at virtual address 6b6b6c07

Looks like a use after free.

 > printing eip:
 > c0138594
 > *pde=00000000
 > Oops: 0002 [#1]
 > 4K_STACK PREEMPT SMP
 > last sysfs file /class/net/eth0/address
 > Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
 > p4_clockmod speedstep_lib binfmt_misc
 > 
 > (gdb) list *0xc0138594
 > 0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
 > warning: Source file is more recent than executable.

got a backtrace ?

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-mm4

[Michal Piotrowski]

On 29/06/06, Dave Jones <davej@redhat.com> wrote:
> On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:
>
>  > This looks very strange.
>  >
>  > BUG: unable to handle kernel paging request at virtual address 6b6b6c07
>
> Looks like a use after free.
>
>  > printing eip:
>  > c0138594
>  > *pde=00000000
>  > Oops: 0002 [#1]
>  > 4K_STACK PREEMPT SMP
>  > last sysfs file /class/net/eth0/address
>  > Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
>  > p4_clockmod speedstep_lib binfmt_misc
>  >
>  > (gdb) list *0xc0138594
>  > 0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
>  > warning: Source file is more recent than executable.
>
> got a backtrace ?

Unfortunately no.

>
>                 Dave
>
> --
> http://www.codemonkey.org.uk
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm4

[Dave Jones]

On Thu, Jun 29, 2006 at 10:46:24PM +0200, Michal Piotrowski wrote:
 > On 29/06/06, Dave Jones <davej@redhat.com> wrote:
 > >On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:
 > >
 > > > This looks very strange.
 > > >
 > > > BUG: unable to handle kernel paging request at virtual address 6b6b6c07
 > >
 > >Looks like a use after free.
 > >
 > > > printing eip:
 > > > c0138594
 > > > *pde=00000000
 > > > Oops: 0002 [#1]
 > > > 4K_STACK PREEMPT SMP
 > > > last sysfs file /class/net/eth0/address
 > > > Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
 > > > p4_clockmod speedstep_lib binfmt_misc
 > > >
 > > > (gdb) list *0xc0138594
 > > > 0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
 > > > warning: Source file is more recent than executable.
 > >
 > >got a backtrace ?
 > 
 > Unfortunately no.

nothing useful from 'bt' from that gdb prompt ?

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-mm4

[Michal Piotrowski]

On 29/06/06, Dave Jones <davej@redhat.com> wrote:
> On Thu, Jun 29, 2006 at 10:46:24PM +0200, Michal Piotrowski wrote:
>  > On 29/06/06, Dave Jones <davej@redhat.com> wrote:
>  > >On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:
>  > >
>  > > > This looks very strange.
>  > > >
>  > > > BUG: unable to handle kernel paging request at virtual address 6b6b6c07
>  > >
>  > >Looks like a use after free.
>  > >
>  > > > printing eip:
>  > > > c0138594
>  > > > *pde=00000000
>  > > > Oops: 0002 [#1]
>  > > > 4K_STACK PREEMPT SMP
>  > > > last sysfs file /class/net/eth0/address
>  > > > Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
>  > > > p4_clockmod speedstep_lib binfmt_misc
>  > > >
>  > > > (gdb) list *0xc0138594
>  > > > 0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
>  > > > warning: Source file is more recent than executable.
>  > >
>  > >got a backtrace ?
>  >
>  > Unfortunately no.
>
> nothing useful from 'bt' from that gdb prompt ?

(gdb) bt
No stack.

>
>                 Dave
>
> --
> http://www.codemonkey.org.uk
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm4

[Andrew Morton]

"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> On 29/06/06, Dave Jones <davej@redhat.com> wrote:
> > On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:
> >
> >  > This looks very strange.
> >  >
> >  > BUG: unable to handle kernel paging request at virtual address 6b6b6c07
> >
> > Looks like a use after free.
> >
> >  > printing eip:
> >  > c0138594
> >  > *pde=00000000
> >  > Oops: 0002 [#1]
> >  > 4K_STACK PREEMPT SMP
> >  > last sysfs file /class/net/eth0/address
> >  > Modules linked in: ipv6 af_packet ipt_REJECT xt_tcpudp x_tables
> >  > p4_clockmod speedstep_lib binfmt_misc
> >  >
> >  > (gdb) list *0xc0138594
> >  > 0xc0138594 is in __lock_acquire (include2/asm/atomic.h:96).
> >  > warning: Source file is more recent than executable.
> >
> > got a backtrace ?
> 
> Unfortunately no.
> 

How irritating.

CONFIG_FRAME_POINTER=y
# CONFIG_UNWIND_INFO is not set

OK.  Perhaps try setting 8k stacks?

Disable lockdep?

Re: 2.6.17-mm4

[Ingo Molnar]

* Dave Jones <davej@redhat.com> wrote:

> On Thu, Jun 29, 2006 at 10:39:33PM +0200, Michal Piotrowski wrote:
> 
>  > This looks very strange.
>  > 
>  > BUG: unable to handle kernel paging request at virtual address 6b6b6c07
> 
> Looks like a use after free.

i'm too hunting use-after-free bugs - the ones fixed below fix certain 
crashes, but i'm still seeing a nasty one.

the crash is independent on lockdep enabled or disabled. See:

  http://redhat.com/~mingo/misc/

for the config and the crash.log.

	Ingo

-----------------
Subject: fix platform_device_put/del mishaps
From: Ingo Molnar <mingo@elte.hu>

this fixes drivers/char/pc8736x_gpio.c and drivers/char/scx200_gpio.c
to use the platform_device_del/put ops correctly.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/char/pc8736x_gpio.c |    5 +++--
 drivers/char/scx200_gpio.c  |    6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

Index: linux/drivers/char/pc8736x_gpio.c
===================================================================
--- linux.orig/drivers/char/pc8736x_gpio.c
+++ linux/drivers/char/pc8736x_gpio.c
@@ -319,9 +319,10 @@ static int __init pc8736x_gpio_init(void
 	return 0;
 
 undo_platform_dev_add:
-	platform_device_put(pdev);
+	platform_device_del(pdev);
 undo_platform_dev_alloc:
-	kfree(pdev);
+	platform_device_put(pdev);
+
 	return rc;
 }
 
Index: linux/drivers/char/scx200_gpio.c
===================================================================
--- linux.orig/drivers/char/scx200_gpio.c
+++ linux/drivers/char/scx200_gpio.c
@@ -126,9 +126,10 @@ static int __init scx200_gpio_init(void)
 undo_chrdev_region:
 	unregister_chrdev_region(dev, num_pins);
 undo_platform_device_add:
-	platform_device_put(pdev);
+	platform_device_del(pdev);
 undo_malloc:
-	kfree(pdev);
+	platform_device_put(pdev);
+
 	return rc;
 }
 
@@ -136,7 +137,6 @@ static void __exit scx200_gpio_cleanup(v
 {
 	kfree(scx200_devices);
 	unregister_chrdev_region(MKDEV(major, 0), num_pins);
-	platform_device_put(pdev);
 	platform_device_unregister(pdev);
 	/* kfree(pdev); */
 }

Re: 2.6.17-mm4

[Michal Piotrowski]

On 29/06/06, Andrew Morton <akpm@osdl.org> wrote:
[snip]
> OK.  Perhaps try setting 8k stacks?
>
> Disable lockdep?
>

I don't see that now. I will try to reproduce this with a previous
config + Ingo's "Ignore loglevel on printks" patch.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm4

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> i'm too hunting use-after-free bugs - the ones fixed below fix certain 
> crashes, but i'm still seeing a nasty one.
> 
> the crash is independent on lockdep enabled or disabled. See:
> 
>   http://redhat.com/~mingo/misc/
> 
> for the config and the crash.log.

ok, managed to debug the reason for this crash via .config bisecting, 
it's caused by:

   CONFIG_SCSI_PATA_QDI=y

which is a new option in -mm4. Disabling it makes the -mm4 allyesconfig 
bzImage work again.

and running qdi_init() either causes memory corruption, or it causes 
something to be misprogrammed on the motherboard (something wrt. irq 
routing perhaps), which crashes the box afterwards. (but that happens 
dozens of initcalls later, so the breakage is subtle)

it does things like:

        static const unsigned long qd_port[2] = { 0x30, 0xB0 };
        static const unsigned long ide_port[2] = { 0x170, 0x1F0 };

        [...]
                unsigned long port = qd_port[i];
        [...]
                        r = inb_p(port);
                        outb_p(0x19, port);
                        res = inb_p(port);
                        outb_p(r, port);

so it reads/writes port 0x30 and 0xb0. Are those used by something else 
on modern hardware?

i know, i shouldnt be running an ancient Vesa Local Bus driver's init 
routine, but still, the allyesconfig bzImage is quite useful in finding 
various bugs ...

	Ingo

Re: 2.6.17-mm4

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Ar Gwe, 2006-06-30 am 01:05 +0200, ysgrifennodd Ingo Molnar:
> > it does things like:
> > 
> >         static const unsigned long qd_port[2] = { 0x30, 0xB0 };
> >         static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
> > 
> >         [...]
> >                 unsigned long port = qd_port[i];
> >         [...]
> >                         r = inb_p(port);
> >                         outb_p(0x19, port);
> >                         res = inb_p(port);
> >                         outb_p(r, port);
> > 
> > so it reads/writes port 0x30 and 0xb0. Are those used by something else 
> > on modern hardware?
> 
> Not especially. Perhaps the best thing to do here would be to make qdi 
> compiled into the kernel (as opposed to modular) only do so if 
> "probe_qdi=1" or similar is set.

ok. Is that the standard way of dealing with potentially intrusive 
probes?

	Ingo

Re: 2.6.17-mm4

[Arjan van de Ven]

On Fri, 2006-06-30 at 11:07 +0100, Alan Cox wrote:
> Ar Gwe, 2006-06-30 am 01:05 +0200, ysgrifennodd Ingo Molnar:
> > it does things like:
> > 
> >         static const unsigned long qd_port[2] = { 0x30, 0xB0 };
> >         static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
> > 
> >         [...]
> >                 unsigned long port = qd_port[i];
> >         [...]
> >                         r = inb_p(port);
> >                         outb_p(0x19, port);
> >                         res = inb_p(port);
> >                         outb_p(r, port);
> > 
> > so it reads/writes port 0x30 and 0xb0. Are those used by something else 
> > on modern hardware?
> 
> Not especially. Perhaps the best thing to do here would be to make qdi
> compiled into the kernel (as opposed to modular) only do so if
> "probe_qdi=1" or similar is set.

another quick hack is to check for vesa lb... eg if pci is present, skip
this thing entirely :)

Re: 2.6.17-mm4

[Alan Cox]

Ar Gwe, 2006-06-30 am 01:05 +0200, ysgrifennodd Ingo Molnar:
> it does things like:
> 
>         static const unsigned long qd_port[2] = { 0x30, 0xB0 };
>         static const unsigned long ide_port[2] = { 0x170, 0x1F0 };
> 
>         [...]
>                 unsigned long port = qd_port[i];
>         [...]
>                         r = inb_p(port);
>                         outb_p(0x19, port);
>                         res = inb_p(port);
>                         outb_p(r, port);
> 
> so it reads/writes port 0x30 and 0xb0. Are those used by something else 
> on modern hardware?

Not especially. Perhaps the best thing to do here would be to make qdi
compiled into the kernel (as opposed to modular) only do so if
"probe_qdi=1" or similar is set.

Will sort that out if nobody beats me to it.

Alan

Re: 2.6.17-mm4

[Andreas Mohr]

Hi,

On Fri, Jun 30, 2006 at 11:54:02AM +0200, Arjan van de Ven wrote:
> On Fri, 2006-06-30 at 11:07 +0100, Alan Cox wrote:
> > Not especially. Perhaps the best thing to do here would be to make qdi
> > compiled into the kernel (as opposed to modular) only do so if
> > "probe_qdi=1" or similar is set.
> 
> another quick hack is to check for vesa lb... eg if pci is present, skip
> this thing entirely :)

Eh? You haven't really heard of those quite popular ISA/VLB/PCI 486 combo
boards, now have you? ;)
(IIRC I had one of those things a looooong time ago)

Andreas Mohr

Re: 2.6.17-mm4

[Alan Cox]

Ar Gwe, 2006-06-30 am 11:54 +0200, ysgrifennodd Arjan van de Ven:
> another quick hack is to check for vesa lb... eg if pci is present, skip
> this thing entirely :)

Not really, many people made VLB/PCI combo boards.

Alan

Re: 2.6.17-mm4

[Dave Jones]

On Fri, Jun 30, 2006 at 01:14:30PM +0100, Alan Cox wrote:
 > Ar Gwe, 2006-06-30 am 11:54 +0200, ysgrifennodd Arjan van de Ven:
 > > another quick hack is to check for vesa lb... eg if pci is present, skip
 > > this thing entirely :)
 > 
 > Not really, many people made VLB/PCI combo boards.

- check the pci version (I'm pretty sure these were pre PCI 2.0 ?)
- check for dmi existance
  DMI came after VLB didn't it?  Even if not, the BIOS date may
  give clues. I don't recall VLB after 1996 or so.
- check for acpi existance.
  surely no-one made an acpi aware vlb machine :)

There are probably other creative ways.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-mm4

[Alan Cox]

Ar Gwe, 2006-06-30 am 13:27 -0400, ysgrifennodd Dave Jones:
>   surely no-one made an acpi aware vlb machine :)
> 
> There are probably other creative ways.

And the not-so-creative simple one which is how old IDE addresses much
of this:

Date: Fri Jun 30 16:39:20 2006 +0100
Subject: [PATCH 13/20] My name is Ingo Molnar, you killed my make allyesconfig, prepare to die

Teach the qdi driver to be more polite about probing when compiled in
so that people who make allyesconfig don't get burned.

Alan

Signed-off-by: Alan Cox <alan@redhat.com>


---

 drivers/scsi/pata_qdi.c |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

12b633d45a8600147314c2ce33b28f92f52c92bd
diff --git a/drivers/scsi/pata_qdi.c b/drivers/scsi/pata_qdi.c
index ca6fef0..f8fc0ef 100644
--- a/drivers/scsi/pata_qdi.c
+++ b/drivers/scsi/pata_qdi.c
@@ -26,7 +26,7 @@
 #include <linux/platform_device.h>
 
 #define DRV_NAME "pata_qdi"
-#define DRV_VERSION "0.2.3"
+#define DRV_VERSION "0.2.4"
 
 #define NR_HOST 4	/* Two 6580s */
 
@@ -41,7 +41,13 @@ struct qdi_data {
 
 static struct ata_host_set *qdi_host[NR_HOST];
 static struct qdi_data qdi_data[NR_HOST];
-static int nr_qdi_host = 0;
+static int nr_qdi_host;
+
+#ifdef MODULE
+static int probe_qdi = 1;
+#else
+static int probe_qdi;
+#endif
 
 static void qdi6500_set_piomode(struct ata_port *ap, struct ata_device *adev)
 {
@@ -302,6 +308,9 @@ static __init int qdi_init(void)
 	int ct = 0;
 	int i;
 	
+	if (probe_qdi == 0)
+		return;
+	
 	/*
  	 *	Check each possible QD65xx base address
 	 */
@@ -390,3 +399,5 @@ MODULE_VERSION(DRV_VERSION);
 module_init(qdi_init);
 module_exit(qdi_exit);
 
+module_param(probe_qdi, int, 0);
+
-- 
1.2.GIT