1. 13 2月, 2010 4 次提交
    • S
      IPv6: keep permanent addresses on admin down · dc2b99f7
      stephen hemminger 提交于
      Permanent IPV6 addresses should not be removed when the link is
      set to admin down, only when device is removed.
      
      When link is lost permanent addresses should be marked as tentative
      so that when link comes back they are subject to duplicate address
      detection (if DAD was enabled for that address).
      
      Other routing systems keep manually configured IPv6 addresses
      when link is set down.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc2b99f7
    • P
      ipv6: fib: fix crash when changing large fib while dumping it · 2bec5a36
      Patrick McHardy 提交于
      When the fib size exceeds what can be dumped in a single skb, the
      dump is suspended and resumed once the last skb has been received
      by userspace. When the fib is changed while the dump is suspended,
      the walker might contain stale pointers, causing a crash when the
      dump is resumed.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
      IP: [<ffffffffa01bce04>] fib6_walk_continue+0xbb/0x124 [ipv6]
      PGD 5347a067 PUD 65c7067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      ...
      RIP: 0010:[<ffffffffa01bce04>]
      [<ffffffffa01bce04>] fib6_walk_continue+0xbb/0x124 [ipv6]
      ...
      Call Trace:
       [<ffffffff8104aca3>] ? mutex_spin_on_owner+0x59/0x71
       [<ffffffffa01bd105>] inet6_dump_fib+0x11b/0x1b9 [ipv6]
       [<ffffffff81371af4>] netlink_dump+0x5b/0x19e
       [<ffffffff8134f288>] ? consume_skb+0x28/0x2a
       [<ffffffff81373b69>] netlink_recvmsg+0x1ab/0x2c6
       [<ffffffff81372781>] ? netlink_unicast+0xfa/0x151
       [<ffffffff813483e0>] __sock_recvmsg+0x6d/0x79
       [<ffffffff81348a53>] sock_recvmsg+0xca/0xe3
       [<ffffffff81066d4b>] ? autoremove_wake_function+0x0/0x38
       [<ffffffff811ed1f8>] ? radix_tree_lookup_slot+0xe/0x10
       [<ffffffff810b3ed7>] ? find_get_page+0x90/0xa5
       [<ffffffff810b5dc5>] ? filemap_fault+0x201/0x34f
       [<ffffffff810ef152>] ? fget_light+0x2f/0xac
       [<ffffffff813519e7>] ? verify_iovec+0x4f/0x94
       [<ffffffff81349a65>] sys_recvmsg+0x14d/0x223
      
      Store the serial number when beginning to walk the fib and reload
      pointers when continuing to walk after a change occured. Similar
      to other dumping functions, this might cause unrelated entries to
      be missed when entries are deleted.
      Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2bec5a36
    • G
      dccp: allow probing of CCID-array length · 69a6a0b3
      Gerrit Renker 提交于
      This fixes a problem in the DCCP getsockopt() API: currently there is no way
      for a user to a priori know the number of built-in CCIDs, other than trying
      DCCP_SOCKOPT_AVAILABLE_CCIDS in a loop, incrementing the option length until
      EINVAL is no longer returned.
      
      This patch truncates the array to the user-provided length. No copy is made
      when the length is <= 0.
      
      Due to the length restriction in do_dccp_getsockopt() to sizeof(int), the
      minimum array length remains 4, which is a reasonable default (only 3
      CCIDs, CCID-2..4, are currently defined).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69a6a0b3
    • J
      net: use netdev_mc_count and netdev_mc_empty when appropriate · 4cd24eaf
      Jiri Pirko 提交于
      This patch replaces dev->mc_count in all drivers (hopefully I didn't miss
      anything). Used spatch and did small tweaks and conding style changes when
      it was suitable.
      
      Jirka
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cd24eaf
  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 10 次提交
    • 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