Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 04 7月, 2006 4 次提交
    • A
      [PATCH] bcm43xx: netlink deadlock fix · 6abd219c
      由 Arjan van de Ven 提交于 
      reported by Jure Repinc:

> > http://bugzilla.kernel.org/show_bug.cgi?id=6773

> > checked out dmesg output and found the message
> >
> > ======================================================
> > [ BUG: hard-safe -> hard-unsafe lock order detected! ]
> > ------------------------------------------------------
> >
> > starting at line 660 of the dmesg.txt that I will attach.

The patch below should fix the deadlock, albeit I suspect it's not the
"right" fix; the right fix may well be to move the rx processing in bcm43xx
to softirq context.  [it's debatable, ipw2200 hit this exact same bug; at
some point it's better to bite the bullet and move this to the common layer
as my patch below does]

Make the nl_table_lock irq-safe; it's taken for read in various netlink
functions, including functions that several wireless drivers (ipw2200,
bcm43xx) want to call from hardirq context.

The deadlock was found by the lock validator.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: N"David S. Miller" <davem@davemloft.net>
Cc: jamal <hadi@cyberus.ca>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6abd219c
    • H
      [PATCH] lockdep: special s390 print_symbol() version · b02454f4
      由 Heiko Carstens 提交于 
      Have a special version of print_symbol() for s390 which clears the most
significant bit of addr before calling __print_symbol().  This seems to be
better than checking/changing each place in the kernel that saves an
instruction pointer.

Without this the output would look like:

hardirqs last  enabled at (30907): [<80018c6a>] 0x80018c6a
hardirqs last disabled at (30908): [<8001e48c>] 0x8001e48c
softirqs last  enabled at (30904): [<8001dc96>] 0x8001dc96
softirqs last disabled at (30897): [<8001dc50>] 0x8001dc50

instead of this:

hardirqs last  enabled at (19421): [<80018c72>] cpu_idle+0x176/0x1c4
hardirqs last disabled at (19422): [<8001e494>] io_no_vtime+0xa/0x1a
softirqs last  enabled at (19418): [<8001dc9e>] do_softirq+0xa6/0xe8
softirqs last disabled at (19411): [<8001dc58>] do_softirq+0x60/0xe8
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b02454f4
    • A
      [PATCH] genirq ia64 cleanup · dada0769
      由 Andrew Morton 提交于 
      Remove duplicate/redundant/wrong  IRQF_PERCPU definition.

Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dada0769
    • J
      [PATCH] time initialisation fix · 88fecaa2
      由 john stultz 提交于 
      We're not reay to take a timer interrupt until timekeeping_init() has run.
But time_init() will start the time interrupt and if it is called with
local interrupts enabled we'll immediately take an interrupt and die.

Fix that by running timekeeping_init() prior to time_init().

We don't know _why_ local interrupts got enabled on Jesse Brandeburg's
machine.  That's a separate as-yet-unsolved problem.  THe patch adds a little
bit of debugging to detect that.

This whole requirement that local interrupts be held off during early boot
keeps on biting us.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      88fecaa2
  3. 03 7月, 2006 36 次提交