1. 14 11月, 2011 2 次提交
  2. 13 11月, 2011 1 次提交
  3. 10 11月, 2011 3 次提交
  4. 09 11月, 2011 4 次提交
  5. 08 11月, 2011 8 次提交
    • A
      Bluetooth: Use miliseconds for L2CAP channel timeouts · f3f668b0
      Andrzej Kaczmarek 提交于
      Timers set by __set_chan_timer() should use miliseconds instead of
      jiffies. Commit 942ecc9c updated
      l2cap_set_timer() so it expects timeout to be specified in msecs
      instead of jiffies. This makes timeouts unreliable when CONFIG_HZ
      is not set to 1000.
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      f3f668b0
    • A
      Bluetooth: Revert: Fix L2CAP connection establishment · 4dff523a
      Arek Lichwa 提交于
      This reverts commit 33060542.
      The commit introduces regression when two 2.1 devices attempt
      establish rfcomm channel. Such connection is refused since there's
      a security block issue on l2cap. It means the link is unencrypted.
      
      2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
          0000: 14 00 40 00 06 00 02 00  0f 35 03 19 12 00 ff ff
      ..@......5....˙˙
          0010: 35 05 0a 00 00 ff ff 00                           5....˙˙.
      2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
          L2CAP(d): cid 0x0040 len 84 [psm 0]
            0000: 07 00 02 00 4f 00 4c 35  4a 35 48 09 00 00 0a 00
      ....O.L5J5H.....
            0010: 01 00 00 09 00 01 35 03  19 12 00 09 00 05 35 03
      ......5.......5.
            0020: 19 10 02 09 00 09 35 08  35 06 19 12 00 09 01 02
      ......5.5.......
            0030: 09 02 00 09 01 02 09 02  01 09 00 0a 09 02 02 09
      ................
            0040: 00 00 09 02 03 09 00 00  09 02 04 28 01 09 02 05
      ...........(....
            0050: 09 00 02 00                                       ....
      2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
      (0x01|0x0011) plen 2
          handle 1
      2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
          Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
      2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
          bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
      (0x01|0x000b) plen 22
          bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
      2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
          Link Key Request Reply (0x01|0x000b) ncmd 1
          status 0x00 bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
          status 0x00 handle 1
      2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 02 05 04 00  03 00 41 00              ..........A.
      2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
          Unknown (0x00|0x0000) status 0x00 ncmd 2
      2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
          L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
            Connection refused - security block
      2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 06 06 04 00  40 00 40 00              ........@.@.
      2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
          L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
      2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
      3
          handle 1 reason 0x13
          Reason: Remote User Terminated Connection
      2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
          Disconnect (0x01|0x0006) status 0x00 ncmd 1
      2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
          status 0x00 handle 1 reason 0x16
          Reason: Connection Terminated by Local Host
      Signed-off-by: NArek Lichwa <arkadiusz.lichwa@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      4dff523a
    • R
      wanrouter: Remove kernel_lock annotations · 039c811c
      Richard Weinberger 提交于
      The BKL is gone, these annotations are useless.
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      039c811c
    • J
      mac80211: uAPSD - fix IEEE80211_FCTL_MOREDATA bit setting · 24b9c373
      Janusz.Dziedzic@tieto.com 提交于
      Set IEEE80211_FCTL_MOREDATA bit also in case we have buffered
      frames (more than one) only for one AC.
      Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      24b9c373
    • J
      cfg80211: fix cmp_ies · 3b6ef633
      Johannes Berg 提交于
      When comparing two items by IE, the sort order
      wasn't stable, which could lead to issues in the
      rbtree. Make it stable by making a missing IE
      sort before a present IE.
      
      Also sort by length first if it differs and then
      by contents.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3b6ef633
    • J
      cfg80211: allow setting TXQ parameters only in AP mode · 133a3ff2
      Johannes Berg 提交于
      In other modes the parameters should not be set.
      Right now, mac80211 will set them, even if the
      user asked for setting them on VLANs which the
      driver doesn't know about, causing all kinds of
      trouble.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      133a3ff2
    • J
      nl80211: fix HT capability attribute validation · 6c739419
      Johannes Berg 提交于
      Since the NL80211_ATTR_HT_CAPABILITY attribute is
      used as a struct, it needs a minimum, not maximum
      length. Enforce that properly. Not doing so could
      potentially lead to reading after the buffer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6c739419
    • E
      mac80211: use min rate as basic rate for buggy APs · 3432f923
      Eliad Peller 提交于
      Some buggy APs (and even P2P_GO) don't advertise their
      basic rates in the association response.
      
      In such case, use the min supported rate as the
      basic rate.
      Reported-by: NPontus Fuchs <pontus.fuchs@gmail.com>
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3432f923
  6. 04 11月, 2011 4 次提交
    • O
      af_packet: de-inline some helper functions · eea49cc9
      Olof Johansson 提交于
      This popped some compiler errors due to mismatched prototypes. Just
      remove most manual inlines, the compiler should be able to figure out
      what makes sense to inline and not.
      
      net/packet/af_packet.c:252: warning: 'prb_curr_blk_in_use' declared inline after being called
      net/packet/af_packet.c:252: warning: previous declaration of 'prb_curr_blk_in_use' was here
      net/packet/af_packet.c:258: warning: 'prb_queue_frozen' declared inline after being called
      net/packet/af_packet.c:258: warning: previous declaration of 'prb_queue_frozen' was here
      net/packet/af_packet.c:248: warning: 'packet_previous_frame' declared inline after being called
      net/packet/af_packet.c:248: warning: previous declaration of 'packet_previous_frame' was here
      net/packet/af_packet.c:251: warning: 'packet_increment_head' declared inline after being called
      net/packet/af_packet.c:251: warning: previous declaration of 'packet_increment_head' was here
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Cc: Chetan Loke <loke.chetan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eea49cc9
    • T
      net: Add back alignment for size for __alloc_skb · bc417e30
      Tony Lindgren 提交于
      Commit 87fb4b7b (net: more
      accurate skb truesize) changed the alignment of size. This
      can cause problems at least on some machines with NFS root:
      
      Unhandled fault: alignment exception (0x801) at 0xc183a43a
      Internal error: : 801 [#1] PREEMPT
      Modules linked in:
      CPU: 0    Not tainted  (3.1.0-08784-g5eeee4a #733)
      pc : [<c02fbba0>]    lr : [<c02fbb9c>]    psr: 60000013
      sp : c180fef8  ip : 00000000  fp : c181f580
      r10: 00000000  r9 : c044b28c  r8 : 00000001
      r7 : c183a3a0  r6 : c1835be0  r5 : c183a412  r4 : 000001f2
      r3 : 00000000  r2 : 00000000  r1 : ffffffe6  r0 : c183a43a
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 0005317f  Table: 10004000  DAC: 00000017
      Process swapper (pid: 1, stack limit = 0xc180e270)
      Stack: (0xc180fef8 to 0xc1810000)
      fee0:                                                       00000024 00000000
      ff00: 00000000 c183b9c0 c183b8e0 c044b28c c0507ccc c019dfc4 c180ff2c c0503cf8
      ff20: c180ff4c c180ff4c 00000000 c1835420 c182c740 c18349c0 c05233c0 00000000
      ff40: 00000000 c00e6bb8 c180e000 00000000 c04dd82c c0507e7c c050cc18 c183b9c0
      ff60: c05233c0 00000000 00000000 c01f34f4 c0430d70 c019d364 c04dd898 c04dd898
      ff80: c04dd82c c0507e7c c180e000 00000000 c04c584c c01f4918 c04dd898 c04dd82c
      ffa0: c04ddd28 c180e000 00000000 c0008758 c181fa60 3231d82c 00000037 00000000
      ffc0: 00000000 c04dd898 c04dd82c c04ddd28 00000013 00000000 00000000 00000000
      ffe0: 00000000 c04b2224 00000000 c04b21a0 c001056c c001056c 00000000 00000000
      Function entered at [<c02fbba0>] from [<c019dfc4>]
      Function entered at [<c019dfc4>] from [<c01f34f4>]
      Function entered at [<c01f34f4>] from [<c01f4918>]
      Function entered at [<c01f4918>] from [<c0008758>]
      Function entered at [<c0008758>] from [<c04b2224>]
      Function entered at [<c04b2224>] from [<c001056c>]
      Code: e1a00005 e3a01028 ebfa7cb0 e35a0000 (e5858028)
      
      Here PC is at __alloc_skb and &shinfo->dataref is unaligned because
      skb->end can be unaligned without this patch.
      
      As explained by Eric Dumazet <eric.dumazet@gmail.com>, this happens
      only with SLOB, and not with SLAB or SLUB:
      
      * Eric Dumazet <eric.dumazet@gmail.com> [111102 15:56]:
      >
      > Your patch is absolutely needed, I completely forgot about SLOB :(
      >
      > since, kmalloc(386) on SLOB gives exactly ksize=386 bytes, not nearest
      > power of two.
      >
      > [   60.305763] malloc(size=385)->ffff880112c11e38 ksize=386 -> nsize=2
      > [   60.305921] malloc(size=385)->ffff88007c92ce28 ksize=386 -> nsize=2
      > [   60.306898] malloc(size=656)->ffff88007c44ad28 ksize=656 -> nsize=272
      > [   60.325385] malloc(size=656)->ffff88007c575868 ksize=656 -> nsize=272
      > [   60.325531] malloc(size=656)->ffff88011c777230 ksize=656 -> nsize=272
      > [   60.325701] malloc(size=656)->ffff880114011008 ksize=656 -> nsize=272
      > [   60.346716] malloc(size=385)->ffff880114142008 ksize=386 -> nsize=2
      > [   60.346900] malloc(size=385)->ffff88011c777690 ksize=386 -> nsize=2
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc417e30
    • E
      net: add missing bh_unlock_sock() calls · 918eb399
      Eric Dumazet 提交于
      Simon Kirby reported lockdep warnings and following messages :
      
      [104661.897577] huh, entered softirq 3 NET_RX ffffffff81613740
      preempt_count 00000101, exited with 00000102?
      
      [104661.923653] huh, entered softirq 3 NET_RX ffffffff81613740
      preempt_count 00000101, exited with 00000102?
      
      Problem comes from commit 0e734419
      (ipv4: Use inet_csk_route_child_sock() in DCCP and TCP.)
      
      If inet_csk_route_child_sock() returns NULL, we should release socket
      lock before freeing it.
      
      Another lock imbalance exists if __inet_inherit_port() returns an error
      since commit 093d2823 ( tproxy: fix hash locking issue when using
      port redirection in __inet_inherit_port()) a backport is also needed for
      >= 2.6.37 kernels.
      Reported-by: NSimon Kirby <sim@hostway.ca>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Balazs Scheidler <bazsi@balabit.hu>
      CC: KOVACS Krisztian <hidden@balabit.hu>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NSimon Kirby <sim@hostway.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      918eb399
    • E
      l2tp: fix race in l2tp_recv_dequeue() · e2e210c0
      Eric Dumazet 提交于
      Misha Labjuk reported panics occurring in l2tp_recv_dequeue()
      
      If we release reorder_q.lock, we must not keep a dangling pointer (tmp),
      since another thread could manipulate reorder_q.
      
      Instead we must restart the scan at beginning of list.
      Reported-by: NMisha Labjuk <spiked.yar@gmail.com>
      Tested-by: NMisha Labjuk <spiked.yar@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2e210c0
  7. 03 11月, 2011 4 次提交
  8. 02 11月, 2011 5 次提交
    • E
      udp: fix a race in encap_rcv handling · 0ad92ad0
      Eric Dumazet 提交于
      udp_queue_rcv_skb() has a possible race in encap_rcv handling, since
      this pointer can be changed anytime.
      
      We should use ACCESS_ONCE() to close the race.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ad92ad0
    • D
      x25: Fix NULL dereference in x25_recvmsg · 501e89d3
      Dave Jones 提交于
      commit cb101ed2 in 3.0 introduced a bug in x25_recvmsg()
      When passed bogus junk from userspace, x25->neighbour can be NULL,
      as shown in this oops..
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
      IP: [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
      PGD 1015f3067 PUD 105072067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0
      Pid: 27928, comm: iknowthis Not tainted 3.1.0+ #2 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
      RIP: 0010:[<ffffffffa05482bd>]  [<ffffffffa05482bd>] x25_recvmsg+0x4d/0x280 [x25]
      RSP: 0018:ffff88010c0b7cc8  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff88010c0b7d78 RCX: 0000000000000c02
      RDX: ffff88010c0b7d78 RSI: ffff88011c93dc00 RDI: ffff880103f667b0
      RBP: ffff88010c0b7d18 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff880103f667b0
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      FS:  00007f479ce7f700(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000000001c CR3: 000000010529e000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process iknowthis (pid: 27928, threadinfo ffff88010c0b6000, task ffff880103faa4f0)
      Stack:
       0000000000000c02 0000000000000c02 ffff88010c0b7d18 ffffff958153cb37
       ffffffff8153cb60 0000000000000c02 ffff88011c93dc00 0000000000000000
       0000000000000c02 ffff88010c0b7e10 ffff88010c0b7de8 ffffffff815372c2
      Call Trace:
       [<ffffffff8153cb60>] ? sock_update_classid+0xb0/0x180
       [<ffffffff815372c2>] sock_aio_read.part.10+0x142/0x150
       [<ffffffff812d6752>] ? inode_has_perm+0x62/0xa0
       [<ffffffff815372fd>] sock_aio_read+0x2d/0x40
       [<ffffffff811b05e2>] do_sync_read+0xd2/0x110
       [<ffffffff812d3796>] ? security_file_permission+0x96/0xb0
       [<ffffffff811b0a91>] ? rw_verify_area+0x61/0x100
       [<ffffffff811b103d>] vfs_read+0x16d/0x180
       [<ffffffff811b109d>] sys_read+0x4d/0x90
       [<ffffffff81657282>] system_call_fastpath+0x16/0x1b
      Code: 8b 66 20 4c 8b 32 48 89 d3 48 89 4d b8 45 89 c7 c7 45 cc 95 ff ff ff 4d 85 e4 0f 84 ed 01 00 00 49 8b 84 24 18 05 00 00 4c 89 e7
       78 1c 01 45 19 ed 31 f6 e8 d5 37 ff e0 41 0f b6 44 24 0e 41
      Signed-off-by: NDave Jones <davej@redhat.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      501e89d3
    • A
      net: make the tcp and udp file_operations for the /proc stuff const · 73cb88ec
      Arjan van de Ven 提交于
      the tcp and udp code creates a set of struct file_operations at runtime
      while it can also be done at compile time, with the added benefit of then
      having these file operations be const.
      
      the trickiest part was to get the "THIS_MODULE" reference right; the naive
      method of declaring a struct in the place of registration would not work
      for this reason.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73cb88ec
    • M
      vlan: Don't propagate flag changes on down interfaces. · deede2fa
      Matthijs Kooijman 提交于
      When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
      flags are cleared or set on the underlying interface. So, if these flags
      are changed on a vlan interface that is not up, the flags underlying
      interface might be set or cleared twice.
      
      Only propagating flag changes when a device is up makes sure this does
      not happen. It also makes sure that an underlying device is not set to
      promiscuous or allmulti mode for a vlan device that is down.
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      deede2fa
    • D
      neigh: Kill bogus SMP protected debugging message. · 045f7b3b
      David S. Miller 提交于
      Whatever situations make this state legitimate when SMP
      also would be legitimate when !SMP and f.e. preemption is
      enabled.
      
      This is dubious enough that we should just delete it entirely.  If we
      want to add debugging for neigh timer races, better more thorough
      mechanisms are needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      045f7b3b
  9. 01 11月, 2011 9 次提交