1. 02 11月, 2011 9 次提交
    • 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
    • G
      net/ethernet: Move mac89x0.c from apple to cirrus · 0a3360e1
      Geert Uytterhoeven 提交于
      Macintosh CS89x0 based ethernet cards use a Crystal Semiconductor (Now
      Cirrus Logic) CS89x0 chip, so the mac89x0 driver should be in
      drivers/net/ethernet/cirrus instead of drivers/net/ethernet/apple.
      
      This also fixes a build problem, as the driver needs a header file from the
      cirrus directory:
      
      drivers/net/ethernet/apple/mac89x0.c:107:20: error: cs89x0.h: No such file or directory
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a3360e1
    • C
      net/ethernet: sc92031 is not Realtek · 1b6b7172
      Cesar Eduardo Barros 提交于
      While the SC92031 could be found on fake "Realtek" NICs, it has no
      relationship to Realtek, and is actually from Silan.
      
      Create a new subdirectory for silan and move sc92031 there.
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b6b7172
    • P
      isdn: hisax: Fix typo 'HISAX_DE_AOC' · 048ca169
      Paul Bolle 提交于
      That should probably be 'CONFIG_DE_AOC'.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      048ca169
    • 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
    • W
      bonding:update speed/duplex for NETDEV_CHANGE · 98f41f69
      Weiping Pan 提交于
      Zheng Liang(lzheng@redhat.com) found a bug that if we config bonding with
      arp monitor, sometimes bonding driver cannot get the speed and duplex from
      its slaves, it will assume them to be 100Mb/sec and Full, please see
      /proc/net/bonding/bond0.
      But there is no such problem when uses miimon.
      
      (Take igb for example)
      I find that the reason is that after dev_open() in bond_enslave(),
      bond_update_speed_duplex() will call igb_get_settings()
      , but in that function,
      it runs ethtool_cmd_speed_set(ecmd, -1); ecmd->duplex = -1;
      because igb get an error value of status.
      So even dev_open() is called, but the device is not really ready to get its
      settings.
      
      Maybe it is safe for us to call igb_get_settings() only after
      this message shows up, that is "igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex,
      Flow Control: RX".
      
      So I prefer to update the speed and duplex for a slave when reseices
      NETDEV_CHANGE/NETDEV_UP event.
      
      Changelog
      V2:
      1 remove the "fake 100/Full" logic in bond_update_speed_duplex(),
        set speed and duplex to -1 when it gets error value of speed and duplex.
      2 delete the warning in bond_enslave() if bond_update_speed_duplex() returns
        error.
      3 make bond_info_show_slave() handle bad values of speed and duplex.
      Signed-off-by: NWeiping Pan <wpan@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98f41f69
    • 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
  2. 01 11月, 2011 31 次提交