On Sat, 2006-11-18 at 16:12 +0300, Andrey Borzenkov wrote:

> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.19-rc5-2avb #2
> - ---------------------------------------------
> pppd/26425 is trying to acquire lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170
> [irda]
>
> but task is already holding lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea857>] irlmp_slsap_inuse+0x37/0x170
> [irda]
>
> other info that might help us debug this:
> 1 lock held by pppd/26425:
>  #0:  (&hashbin->hb_spinlock){....}, at: [<dfdea857>]
> irlmp_slsap_inuse+0x37/0x170 [irda]
>
> stack backtrace:
>  [<c010413c>] dump_trace+0x1cc/0x200
>  [<c010418a>] show_trace_log_lvl+0x1a/0x30
>  [<c01047f2>] show_trace+0x12/0x20
>  [<c01048c9>] dump_stack+0x19/0x20
>  [<c01346ca>] __lock_acquire+0x8fa/0xc20
>  [<c0134d2d>] lock_acquire+0x5d/0x80
>  [<c02a851c>] _spin_lock+0x2c/0x40
>  [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 [irda]
>  [<dfdebab2>] irlmp_open_lsap+0x62/0x180 [irda]
>  [<dfdf35d1>] irttp_open_tsap+0x181/0x230 [irda]
>  [<dfdc0c3d>] ircomm_open_tsap+0x5d/0xa0 [ircomm]
>  [<dfdc05d8>] ircomm_open+0xb8/0xd0 [ircomm]
>  [<dfdd0477>] ircomm_tty_open+0x4f7/0x570 [ircomm_tty]
>  [<c020bbe4>] tty_open+0x174/0x340
>  [<c016bd69>] chrdev_open+0x89/0x170
>  [<c0167bd6>] __dentry_open+0xa6/0x1d0
>  [<c0167da5>] nameidata_to_filp+0x35/0x40
>  [<c0167df9>] do_filp_open+0x49/0x50
>  [<c0167e47>] do_sys_open+0x47/0xd0
>  [<c0167f0c>] sys_open+0x1c/0x20
>  [<c010307d>] sysenter_past_esp+0x56/0x8d
>  [<b7f86410>] 0xb7f86410
>  =======================

The comment at the nesting lock says:

	/* Careful for priority inversions here !
	 * irlmp->links is never taken while another IrDA
	 * spinlock is held, so we are safe. Jean II */

So, under the assumption the author was right, it just needs a lockdep
annotation.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The "u16 *" derefs of skb->data need to be wrapped inside of
a get_unaligned().

Thanks to Gustavo Zacarias for the bug report.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I actually dont have a test case for these; i just found them by
inspection. Refer to patch "[XFRM]: Sub-policies broke policy events"
for more info
Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
Acked-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

XFRM policy events are broken when sub-policy feature is turned on.
A simple test to verify this:
run ip xfrm mon on one window and add then delete a policy on another
window ..
Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
Acked-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The IGMPV3_EXP() macro doesn't correctly shift the normalization bit, so
time-out values are longer than they should be.

Thanks to Dirk Ooms for finding the problem in IGMPv3 - MLDv2 had a
similar problem that was already fixed a year ago. :-(
Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Any L2CAP connection in disconnecting state shall not response
to any further config requests from the remote side. So in case
such a request is received, ignore it.
Signed-off-by: NVille Tervo <ville.tervo@nokia.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When sending a positive config response it shall include the actual
MTU to be used on this channel. This differs from the Bluetooth 1.1
specification where it was enough to acknowledge the config request.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If the RFCOMM session is no longer attached to the TTY device, then it
makes no sense to go through with changing the termios settings.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

After an inquiry completed or got canceled the Bluetooth core should
check for any pending connect attempts.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To receive uvents for the low-level ACL and SCO links, they must be
assigned to a subsystem. It is enough to attach them to the already
established Bluetooth bus.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Signed-off-by: NYasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Signed-off-by: NYasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

RFC4191 explicitly states that the procedures are applicable to
hosts only.  We should not have changed behavior of routers.
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Only routers in "FAILED" state should be considered unreachable.
Otherwise, we do not try to use speicific routes unless all least specific
routers are considered unreachable.
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
  [PATCH] x86_64: Align data segment to PAGE_SIZE boundary
  [PATCH] x86-64: increase PHB1 split transaction timeout
  [PATCH] x86-64: Fix C3 timer test

o Explicitly align data segment to PAGE_SIZE boundary otherwise depending on
  config options and tool chain it might be placed on a non PAGE_SIZE aligned
  boundary and vmlinux loaders like kexec fail when they encounter a
  PT_LOAD type segment which is not aligned to PAGE_SIZE boundary.
Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

SGI-PV: 958376
SGI-Modid: xfs-linux-melb:xfs-kern:27503a
Signed-off-by: NDavid Chinner <dgc@sgi.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

xfs_bmap_add_extent_delay_real()

SGI-PV: 957008
SGI-Modid: xfs-linux-melb:xfs-kern:27457a
Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
Signed-off-by: NShailendra Tripathi <stripathi@agami.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

ipath uses skb functions and won't build without CONFIG_NET.

Spotted by Randy Dunlap.
Signed-off-by: NBryan O'Sullivan <bryan.osullivan@qlogic.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

This is a quick hack to overcome the fact that SRCU currently does not
allow static initializers, and we need to sometimes initialize those
things before any other initializers (even "core" ones) can do so.

Currently we don't allow this at all for modules, and the only user that
needs is right now is cpufreq. As reported by Thomas Gleixner:

   "Commit b4dfdbb3 ("[PATCH] cpufreq:
    make the transition_notifier chain use SRCU breaks cpu frequency
    notification users, which register the callback > on core_init
    level."

Cc: Thomas Gleixner <tglx@timesys.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>,
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband:
  IPoIB: Clear high octet in QP number

Switch to using irq_handler_t for interrupt function handler pointers.

Change name of m68knommu's irq_hanlder_t data structure so it doesn't
clash with the common type (include/linux/interrupt.h).
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix a build error for the  enter:now PCI card.
Signed-off-by: NToralf Foerster <toralf.foerster@gmx.de>
Acked-by: NKarsten Keil <kkeil@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix printk format warnings:
drivers/char/ftape/zftape/zftape-buffers.c:87: warning: format '%d' expects type
'int', but argument 3 has type 'size_t'
drivers/char/ftape/zftape/zftape-buffers.c:104: warning: format '%d' expects type
 'int', but argument 3 has type 'size_t'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is to fix compile error of x86-64 memory hotplug without any NUMA
option.

  CC      arch/x86_64/mm/init.o
arch/x86_64/mm/init.c:501: error: redefinition of 'memory_add_physaddr_to_nid'
include/linux/memory_hotplug.h:71: error: previous definition of 'memory_add_phys
addr_to_nid' was here
arch/x86_64/mm/init.c:509: error: redefinition of 'memory_add_physaddr_to_nid'
arch/x86_64/mm/init.c:501: error: previous definition of 'memory_add_physaddr_to_
nid' was here

I confirmed compile completion with !NUMA, (NUMA & !ACPI_NUMA),
or (NUMA & ACPI_NUMA).
Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Acked-by: NAndi Kleen <ak@suse.de>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

i2c_bit_add_bus() returns -E;
-E != 0		=>	err = 1
probe fails with positive error code
Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org>
Cc: Deepak Saxena <dsaxena@mvista.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Having unbound PCMCIA devices: doing a 'find /sys' after a 'rmmod pcmcia'
gives an oops because the pcmcia_device is not unregisterd from the driver
core.

fixes bugzilla #7481
Signed-off-by: NDaniel Ritz <daniel.ritz@gmx.ch>
Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Pavol Gono <Palo.Gono@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch has removed one too many semicolon in crypto.h.
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

* 'fixes4linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbglaw/vax-linux:
  lkkbd: Remove my old snail-mail address

I moved from Sweden to Finland 2.5 years ago, thought it might be time
to update my CREDITS entry (simply removing the address completely
seemed the sanest option).
Signed-off-by: NDavid Weinehall <tao@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This reverts commit 37605a69.

Again.

This same bug has now been introduced twice: it was done earlier by
commit b8d35192, only to be reverted
last time in commit 72945b2b.

We must NOT try to queue up notify handlers to another thread than the
normal ACPI execution thread, because the notifications on some systems
seem to just keep on accumulating until we run out of memory and/or
threads.

Keeping events within the one deferred execution thread automatically
throttles the events properly.

At least the Compaq N620c will lock up completely on the first thermal
event without this patch reverted.

Cc: David Brownell <david-b@pacbell.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When showing the stack backtrace, make sure that we never accept not
only an unchanging frame pointer, but also a frame pointer that moves
back down the stack frame.  It must always grow up (toward older stack
frames).

I doubt this has triggered, but a subtly corrupt stack with extremely
unlucky contents could cause us to loop forever on a bogus endless frame
pointer chain.

This review was triggered by much worse problems happening in some of
the other stack unwinding code.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

lockdep got confused by certain locks in modules:

 INFO: trying to register non-static key.
 the code is fine but needs lockdep annotation.
 turning off the locking correctness validator.

 Call Trace:
  [<ffffffff8026f40d>] dump_trace+0xaa/0x3f2
  [<ffffffff8026f78f>] show_trace+0x3a/0x60
  [<ffffffff8026f9d1>] dump_stack+0x15/0x17
  [<ffffffff802abfe8>] __lock_acquire+0x724/0x9bb
  [<ffffffff802ac52b>] lock_acquire+0x4d/0x67
  [<ffffffff80267139>] rt_spin_lock+0x3d/0x41
  [<ffffffff8839ed3f>] :ip_conntrack:__ip_ct_refresh_acct+0x131/0x174
  [<ffffffff883a1334>] :ip_conntrack:udp_packet+0xbf/0xcf
  [<ffffffff8839f9af>] :ip_conntrack:ip_conntrack_in+0x394/0x4a7
  [<ffffffff8023551f>] nf_iterate+0x41/0x7f
  [<ffffffff8025946a>] nf_hook_slow+0x64/0xd5
  [<ffffffff802369a2>] ip_rcv+0x24e/0x506
  [...]

Steven Rostedt found the bug: static_obj() check did not take
PERCPU_ENOUGH_ROOM into account, so in-module DEFINE_PER_CPU-area locks
were triggering this message.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The scheduler on Andreas Friedrich's hyperthreading system stopped
working properly: the scheduler would never move tasks to another CPU!
The lask known working kernel was 2.6.8.

After a couple of attempts to corner the bug, the following smoking gun
was found:

  BIOS reported wrong ACPI idfor the processor
  CPU#1: set_cpus_allowed(), swapper:1, 3 -> 2
   [<c0103bbe>] show_trace_log_lvl+0x34/0x4a
   [<c0103ceb>] show_trace+0x2c/0x2e
   [<c01045f8>] dump_stack+0x2b/0x2d
   [<c0116a77>] set_cpus_allowed+0x52/0xec
   [<c0101d86>] cpu_idle_wait+0x2e/0x100
   [<c0259c57>] acpi_processor_power_exit+0x45/0x58
   [<c0259752>] acpi_processor_remove+0x46/0xea
   [<c025c6fb>] acpi_start_single_object+0x47/0x54
   [<c025cee5>] acpi_bus_register_driver+0xa4/0xd3
   [<c04ab2d7>] acpi_processor_init+0x57/0x77
   [<c01004d7>] init+0x146/0x2fd
   [<c0103a87>] kernel_thread_helper+0x7/0x10

a quick look at cpu_idle_wait() shows how broken that code is
on i386: it changes the init task's affinity map but never
restores it ...

and because all userspace tasks get forked by init, they all
inherited that single-CPU affinity mask. x86_64 cloned this
bug too.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Andreas Friedrich <andreas.friedrich@fujitsu-siemens.com>
Cc: Wolfgang Erig <Wolfgang.Erig@fujitsu-siemens.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

the new dwarf2 unwinder crashes while trying to dump the stack:

  Leftover inexact backtrace:

  Unable to handle kernel paging request at ffffffff82800000 RIP:
   [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
  PGD 203027 PUD 205027 PMD 0
  Oops: 0000 [2] PREEMPT SMP
  CPU 0
  Modules linked in:
  Pid: 30, comm: khelper Not tainted 2.6.19-rc6-rt1 #11
  RIP: 0010:[<ffffffff8026cf26>]  [<ffffffff8026cf26>] dump_trace+0x35b/0x3d2
  RSP: 0000:ffff81003fb9d848  EFLAGS: 00010006
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: ffffffff805b3520 RDI: 0000000000000000
  RBP: ffffffff827ffff9 R08: ffffffff80aad000 R09: 0000000000000005
  R10: ffffffff80aae000 R11: ffffffff8037961b R12: ffff81003fb9d858
  R13: 0000000000000000 R14: ffffffff80598460 R15: ffffffff80ab1fc0
  FS:  0000000000000000(0000) GS:ffffffff806c4200(0000) knlGS:0000000000000000
  CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  CR2: ffffffff82800000 CR3: 0000000000201000 CR4: 00000000000006e0

this crash happened because it did not sanitize the dwarf2 data it
got, and got an unaligned stack pointer - which happily walked past
the process stack (and eventually reached the end of kernel memory
and pagefaulted there) due to this naive iteration condition:

        HANDLE_STACK (((long) stack & (THREAD_SIZE-1)) != 0);

note that i386 is alot more conservative when it comes to trusting
stack pointers:

  static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
  {
         return  p > (void *)tinfo &&
                 p < (void *)tinfo + THREAD_SIZE - 3;
  }

but the x86_64 code did not take this bit of i386 code.

The fix is to align the stack pointer.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Andi Kleen <ak@suse.de>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I moved to a different town and my old snail-mail address is invalid
now.  Also, there's no need at all to have any address like that in
the sources, so remove it completely.
Signed-off-by: NJan-Benedict Glaw <jbglaw@lug-owl.de>

Benh points out that the msgs[0].flags entry never got initialized, and
since it's an automatic stack allocation, it could have any random
value, which is bad.

Rewrite the initializer to explicitly initialize all fields of the small
i2c_msg structure array we generate.  Just to keep it all obvious, let's
handle msgs[1].buf in the same initializer while we're at it, instead of
initializing that one separately later.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>