1. 07 Nov, 2011 7 commits
    • Stratos Psomadakis's avatar
      Fix broken backport for IPv6 tunnels · c5ed1561
      Stratos Psomadakis authored
      Fix broken backport for IPv6 tunnels in 2.6.32-longterm kernels.
      
      upstream commit d5aa407f ("tunnels: fix
      netns vs proto registration ordering") , which was included in
      2.6.32.44-longterm, was not backported correctly, and results in a NULL
      pointer dereference in ip6_tunnel.c for longterm kernels >=2.6.32.44
      
      Use [un]register_pernet_gen_device() instead of
      [un]register_pernet_device() to fix it.
      Signed-off-by: default avatarStratos Psomadakis <psomas@gentoo.org>
      Cc: Wolfgang Walter <wolfgang.walter@stwm.de>
      Cc: Tim Gardner <tim.gardner@canonical.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c5ed1561
    • Ian Campbell's avatar
      sparc: fix array bounds error setting up PCIC NMI trap · abc7edfb
      Ian Campbell authored
      commit 4a0342ca upstream.
      
        CC      arch/sparc/kernel/pcic.o
      arch/sparc/kernel/pcic.c: In function 'pcic_probe':
      arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
      cc1: all warnings being treated as errors
      
      I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
      the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
      to be 4 instructions long and I presume from the usage that instructions are
      int sized.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: sparclinux@vger.kernel.org
      Reviewed-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      abc7edfb
    • David S. Miller's avatar
      sparc: Allow handling signals when stack is corrupted. · 910098ec
      David S. Miller authored
      commit 5598473a upstream.
      
      If we can't push the pending register windows onto the user's stack,
      we disallow signal delivery even if the signal would be delivered on a
      valid seperate signal stack.
      
      Add a register window save area in the signal frame, and store any
      unsavable windows there.
      
      On sigreturn, if any windows are still queued up in the signal frame,
      try to push them back onto the stack and if that fails we kill the
      process immediately.
      
      This allows the debug/tst-longjmp_chk2 glibc test case to pass.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      910098ec
    • Daniel Schwierzeck's avatar
      atm: br2684: Fix oops due to skb->dev being NULL · 3fe9d0a9
      Daniel Schwierzeck authored
      commit fbe5e29e upstream.
      
      This oops have been already fixed with commit
      
          27141666
      
          atm: [br2684] Fix oops due to skb->dev being NULL
      
          It happens that if a packet arrives in a VC between the call to open it on
          the hardware and the call to change the backend to br2684, br2684_regvcc
          processes the packet and oopses dereferencing skb->dev because it is
          NULL before the call to br2684_push().
      
      but have been introduced again with commit
      
          b6211ae7
      
          atm: Use SKB queue and list helpers instead of doing it by-hand.
      Signed-off-by: default avatarDaniel Schwierzeck <daniel.schwierzeck@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3fe9d0a9
    • Stanislaw Gruszka's avatar
      rt2x00: do not drop usb dev reference counter on suspend · 165b1d34
      Stanislaw Gruszka authored
      commit 543cc38c upstream.
      
      When hibernating ->resume may not be called by usb core, but disconnect
      and probe instead, so we do not increase the counter after decreasing
      it in ->supend. As a result we free memory early, and get crash when
      unplugging usb dongle.
      
      BUG: unable to handle kernel paging request at 6b6b6b9f
      IP: [<c06909b0>] driver_sysfs_remove+0x10/0x30
      *pdpt = 0000000034f21001 *pde = 0000000000000000
      Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO
      EIP: 0060:[<c06909b0>] EFLAGS: 00010202 CPU: 1
      EIP is at driver_sysfs_remove+0x10/0x30
      EAX: 6b6b6b6b EBX: f52bba34 ECX: 00000000 EDX: 6b6b6b6b
      ESI: 6b6b6b6b EDI: c0a0ea20 EBP: f61c9e68 ESP: f61c9e64
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process khubd (pid: 20, ti=f61c8000 task=f6138270 task.ti=f61c8000)
      Call Trace:
       [<c06909ef>] __device_release_driver+0x1f/0xa0
       [<c0690b20>] device_release_driver+0x20/0x40
       [<c068fd64>] bus_remove_device+0x84/0xe0
       [<c068e12a>] ? device_remove_attrs+0x2a/0x80
       [<c068e267>] device_del+0xe7/0x170
       [<c06d93d4>] usb_disconnect+0xd4/0x180
       [<c06d9d61>] hub_thread+0x691/0x1600
       [<c0473260>] ? wake_up_bit+0x30/0x30
       [<c0442a39>] ? complete+0x49/0x60
       [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
       [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
       [<c0472eb4>] kthread+0x74/0x80
       [<c0472e40>] ? kthread_worker_fn+0x150/0x150
       [<c0809b3e>] kernel_thread_helper+0x6/0x10
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      165b1d34
    • Wang Zhi's avatar
      USB: EHCI: Do not rely on PORT_SUSPEND to stop USB resuming in ehci_bus_resume(). · 4f122ebf
      Wang Zhi authored
      commit d0f2fb25 upstream.
      
      From EHCI Spec p.28 HC should clear PORT_SUSPEND when SW clears
      PORT_RESUME. In Intel Oaktrail platform, MPH (Multi-Port Host
      Controller) core clears PORT_SUSPEND directly when SW sets PORT_RESUME
      bit. If we rely on PORT_SUSPEND bit to stop USB resume, we will miss
      the action of clearing PORT_RESUME. This will cause unexpected long
      resume signal on USB bus.
      Signed-off-by: default avatarWang Zhi <zhi.wang@windriver.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4f122ebf
    • Jean-Christophe PLAGNIOL-VILLARD's avatar
      USB: ftdi_sio: add Calao reference board support · b39d45e2
      Jean-Christophe PLAGNIOL-VILLARD authored
      commit c96fbdd0 upstream.
      
      Calao use on there dev kits a FT2232 where the port 0 is used for the JTAG and
      port 1 for the UART
      
      They use the same VID and PID as FTDI Chip but they program the manufacturer
      name in the eeprom
      
      So use this information to detect it
      Signed-off-by: default avatarJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: Gregory Hermant <gregory.hermant@calao-systems.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b39d45e2
  2. 29 Aug, 2011 20 commits
  3. 16 Aug, 2011 7 commits
  4. 08 Aug, 2011 6 commits