1. 13 2月, 2010 1 次提交
  2. 12 2月, 2010 1 次提交
  3. 11 2月, 2010 12 次提交
  4. 09 2月, 2010 7 次提交
  5. 06 2月, 2010 2 次提交
  6. 05 2月, 2010 4 次提交
  7. 04 2月, 2010 12 次提交
    • A
      net: maintain namespace isolation between vlan and real device · 8a83a00b
      Arnd Bergmann 提交于
      In the vlan and macvlan drivers, the start_xmit function forwards
      data to the dev_queue_xmit function for another device, which may
      potentially belong to a different namespace.
      
      To make sure that classification stays within a single namespace,
      this resets the potentially critical fields.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a83a00b
    • J
      net/rds: remove uses of NIPQUAD, use %pI4 · 6884b348
      Joe Perches 提交于
      Signed-off-by: NJoe Perches <joe@perches.com>
      Cc: Andy Grover <andy.grover@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6884b348
    • T
      irda: add missing BKL in irnet_ppp ioctl · 3fdde0a1
      Thadeu Lima de Souza Cascardo 提交于
      One ioctl has been forgotten when the BKL was push down into irnet_ppp
      ioctl function.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3fdde0a1
    • T
      irda: unbalanced lock_kernel in irnet_ppp · 454debe4
      Thadeu Lima de Souza Cascardo 提交于
      Add the missing unlock_kernel in one ioctl operation.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      454debe4
    • N
      Bluetooth: Enter active mode before establishing a SCO link. · c390216b
      Nick Pelly 提交于
      When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
      to establish a SCO link. Fix by requesting active mode before requesting
      SCO connection. This improves SCO setup time to ~500ms.
      
      Bluetooth headsets that use a long interval time, and exhibit the long
      SCO connection time include Motorola H790, HX1 and H17. They have a
      CSR 2.1 chipset.
      
      Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
      TI1271.
      
      2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 1 mode 0x02 interval 2048
          Mode: Sniff
      2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 1 voice setting 0x0060
      2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
          status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
          Air mode: CVSD
      Signed-off-by: NNick Pelly <npelly@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c390216b
    • G
      dccp: fix auto-loading of dccp(_probe) · 1386be55
      Gerrit Renker 提交于
      This fixes commit (38ff3e6b) ("dccp_probe:
      Fix module load dependencies between dccp and dccp_probe", from 15 Jan).
      
      It fixes the construction of the first argument of try_then_request_module(),
      where only valid return codes from the first argument should be returned.
      
      What we do now is assign the result of register_jprobe() to ret, without
      the side effect of the comparison.
      Acked-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1386be55
    • G
      dccp: fix bug in cache allocation · 8ed030dd
      Gerrit Renker 提交于
      This fixes a bug introduced in commit de4ef86c
      ("dccp: fix dccp rmmod when kernel configured to use slub", 17 Jan): the
      vsnprintf used sizeof(slab_name_fmt), which became truncated to 4 bytes, since
      slab_name_fmt is now a 4-byte pointer and no longer a 32-character array.
      
      This lead to error messages such as
       FATAL: Error inserting dccp: No buffer space available
      
       >> kernel: [ 1456.341501] kmem_cache_create: duplicate cache cci
      generated due to the truncation after the 3rd character.
      
      Fixed for the moment by introducing a symbolic constant. Tested to fix the bug.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ed030dd
    • A
      netlink: fix for too early rmmod · 974c37e9
      Alexey Dobriyan 提交于
      Netlink code does module autoload if protocol userspace is asking for is
      not ready. However, module can dissapear right after it was autoloaded.
      Example: modprobe/rmmod stress-testing and xfrm_user.ko providing NETLINK_XFRM.
      
      netlink_create() in such situation _will_ create userspace socket and
      _will_not_ pin module. Now if module was removed and we're going to call
      ->netlink_rcv into nothing:
      
      BUG: unable to handle kernel paging request at ffffffffa02f842a
      					       ^^^^^^^^^^^^^^^^
      	modules are loaded near these addresses here
      
      IP: [<ffffffffa02f842a>] 0xffffffffa02f842a
      PGD 161f067 PUD 1623063 PMD baa12067 PTE 0
      Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
      CPU 1
      Pid: 11515, comm: ip Not tainted 2.6.33-rc5-netns-00594-gaaa5728-dirty #6 P5E/P5E
      RIP: 0010:[<ffffffffa02f842a>]  [<ffffffffa02f842a>] 0xffffffffa02f842a
      RSP: 0018:ffff8800baa3db48  EFLAGS: 00010292
      RAX: ffff8800baa3dfd8 RBX: ffff8800be353640 RCX: 0000000000000000
      RDX: ffffffff81959380 RSI: ffff8800bab7f130 RDI: 0000000000000001
      RBP: ffff8800baa3db58 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000011
      R13: ffff8800be353640 R14: ffff8800bcdec240 R15: ffff8800bd488010
      FS:  00007f93749656f0(0000) GS:ffff880002300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffffffffa02f842a CR3: 00000000ba82b000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process ip (pid: 11515, threadinfo ffff8800baa3c000, task ffff8800bab7eb30)
      Stack:
       ffffffff813637c0 ffff8800bd488000 ffff8800baa3dba8 ffffffff8136397d
      <0> 0000000000000000 ffffffff81344adc 7fffffffffffffff 0000000000000000
      <0> ffff8800baa3ded8 ffff8800be353640 ffff8800bcdec240 0000000000000000
      Call Trace:
       [<ffffffff813637c0>] ? netlink_unicast+0x100/0x2d0
       [<ffffffff8136397d>] netlink_unicast+0x2bd/0x2d0
      
      	netlink_unicast_kernel:
      		nlk->netlink_rcv(skb);
      
       [<ffffffff81344adc>] ? memcpy_fromiovec+0x6c/0x90
       [<ffffffff81364263>] netlink_sendmsg+0x1d3/0x2d0
       [<ffffffff8133975b>] sock_sendmsg+0xbb/0xf0
       [<ffffffff8106cdeb>] ? __lock_acquire+0x27b/0xa60
       [<ffffffff810a18c3>] ? might_fault+0x73/0xd0
       [<ffffffff810a18c3>] ? might_fault+0x73/0xd0
       [<ffffffff8106db22>] ? __lock_release+0x82/0x170
       [<ffffffff810a190e>] ? might_fault+0xbe/0xd0
       [<ffffffff810a18c3>] ? might_fault+0x73/0xd0
       [<ffffffff81344c77>] ? verify_iovec+0x47/0xd0
       [<ffffffff8133a509>] sys_sendmsg+0x1a9/0x360
       [<ffffffff813c2be5>] ? _raw_spin_unlock_irqrestore+0x65/0x70
       [<ffffffff8106aced>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff813c2bc2>] ? _raw_spin_unlock_irqrestore+0x42/0x70
       [<ffffffff81197004>] ? __up_read+0x84/0xb0
       [<ffffffff8106ac95>] ? trace_hardirqs_on_caller+0x145/0x190
       [<ffffffff813c207f>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8100262b>] system_call_fastpath+0x16/0x1b
      Code:  Bad RIP value.
      RIP  [<ffffffffa02f842a>] 0xffffffffa02f842a
       RSP <ffff8800baa3db48>
      CR2: ffffffffa02f842a
      
      If module was quickly removed after autoloading, return -E.
      
      Return -EPROTONOSUPPORT if module was quickly removed after autoloading.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      974c37e9
    • A
      af_key: fix netns ops ordering on module load/unload · 180211b8
      Alexey Dobriyan 提交于
      1. After sock_register() returns, it's possible to create sockets,
         even if module still not initialized fully (blame generic module code
         for that!)
      2. Consequently, pfkey_create() can be called with pfkey_net_id still not
         initialized which will BUG_ON in net_generic():
      	kernel BUG at include/net/netns/generic.h:43!
      3. During netns shutdown, netns ops should be unregistered after
         key manager unregistered because key manager calls can be triggered
         from xfrm_user module:
      
         	general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      	pfkey_broadcast+0x111/0x210 [af_key]
      	pfkey_send_notify+0x16a/0x300 [af_key]
      	km_state_notify+0x41/0x70
      	xfrm_flush_sa+0x75/0x90 [xfrm_user]
      4. Unregister netns ops after socket ops just in case and for symmetry.
      
      Reported by Luca Tettamanti.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Tested-by: NLuca Tettamanti <kronos.it@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      180211b8
    • N
      Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket · 6c2718da
      Nick Pelly 提交于
      When processing a RFCOMM UA frame when the socket is closed and we were
      not the RFCOMM initiator would cause rfcomm_session_put() to be called
      twice during rfcomm_process_rx(). This would cause a kernel panic in
      rfcomm_session_close() then.
      
      This could be easily reproduced during disconnect with devices such as
      Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect
      request. This trace for this looks like:
      
      2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0041 len 4 [psm 3]
           RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
      2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5
         handle 1 packets 1
      2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0040 len 4 [psm 3]
           RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
      2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0041 len 4 [psm 3]
           RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
      2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5
         handle 1 packets 1
      2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
         L2CAP(d): cid 0x0040 len 4 [psm 3]
           RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
      2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
         L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041
      
      Avoid calling rfcomm_session_put() twice by skipping this call
      in rfcomm_recv_ua() if the socket is closed.
      Signed-off-by: NNick Pelly <npelly@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6c2718da
    • M
      Bluetooth: Fix sleeping function in RFCOMM within invalid context · 485f1eff
      Marcel Holtmann 提交于
      With the commit 9e726b17 the
      rfcomm_session_put() gets accidentially called from a timeout
      callback and results in this:
      
      BUG: sleeping function called from invalid context at net/core/sock.c:1897
      in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
      Pid: 0, comm: swapper Tainted: P           2.6.32 #31
      Call Trace:
       <IRQ>  [<ffffffff81036455>] __might_sleep+0xf8/0xfa
       [<ffffffff8138ef1d>] lock_sock_nested+0x29/0xc4
       [<ffffffffa03921b3>] lock_sock+0xb/0xd [l2cap]
       [<ffffffffa03948e6>] l2cap_sock_shutdown+0x1c/0x76 [l2cap]
       [<ffffffff8106adea>] ? clockevents_program_event+0x75/0x7e
       [<ffffffff8106bea2>] ? tick_dev_program_event+0x37/0xa5
       [<ffffffffa0394967>] l2cap_sock_release+0x27/0x67 [l2cap]
       [<ffffffff8138c971>] sock_release+0x1a/0x67
       [<ffffffffa03d2492>] rfcomm_session_del+0x34/0x53 [rfcomm]
       [<ffffffffa03d24c5>] rfcomm_session_put+0x14/0x16 [rfcomm]
       [<ffffffffa03d28b4>] rfcomm_session_timeout+0xe/0x1a [rfcomm]
       [<ffffffff810554a8>] run_timer_softirq+0x1e2/0x29a
       [<ffffffffa03d28a6>] ? rfcomm_session_timeout+0x0/0x1a [rfcomm]
       [<ffffffff8104e0f6>] __do_softirq+0xfe/0x1c5
       [<ffffffff8100e8ce>] ? timer_interrupt+0x1a/0x21
       [<ffffffff8100cc4c>] call_softirq+0x1c/0x28
       [<ffffffff8100e05b>] do_softirq+0x33/0x6b
       [<ffffffff8104daf6>] irq_exit+0x36/0x85
       [<ffffffff8100d7a9>] do_IRQ+0xa6/0xbd
       [<ffffffff8100c493>] ret_from_intr+0x0/0xa
       <EOI>  [<ffffffff812585b3>] ? acpi_idle_enter_bm+0x269/0x294
       [<ffffffff812585a9>] ? acpi_idle_enter_bm+0x25f/0x294
       [<ffffffff81373ddc>] ? cpuidle_idle_call+0x97/0x107
       [<ffffffff8100aca0>] ? cpu_idle+0x53/0xaa
       [<ffffffff81429006>] ? rest_init+0x7a/0x7c
       [<ffffffff8177bc8c>] ? start_kernel+0x389/0x394
       [<ffffffff8177b29c>] ? x86_64_start_reservations+0xac/0xb0
       [<ffffffff8177b384>] ? x86_64_start_kernel+0xe4/0xeb
      
      To fix this, the rfcomm_session_put() needs to be moved out of
      rfcomm_session_timeout() into rfcomm_process_sessions(). In that
      context it is perfectly fine to sleep and disconnect the socket.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NDavid John <davidjon@xenontk.org>
      485f1eff
    • N
      Bluetooth: Fallback eSCO to SCO on error 0x1a (Unsupported Remote Feature) · 1038a00b
      Nick Pelly 提交于
      General Motors carkits that use LGE BT chipsets return this error code
      when an eSCO is attempted, despite advertising eSCO support.
      
      2009-08-13 14:41:39.755518 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
         handle 1 voice setting 0x0060
      2009-08-13 14:41:39.757563 > HCI Event: Command Status (0x0f) plen 4
         Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-08-13 14:41:39.789484 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
         status 0x1a handle 257 bdaddr 00:1E:B2:23:5E:B3 type eSCO
         Error: Unsupported Remote Feature / Unsupported LMP Feature
      Signed-off-by: NJaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: NNick Pelly <npelly@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      1038a00b
  8. 03 2月, 2010 1 次提交