1. 19 Feb, 2009 2 commits
    • Sebastian Siewior's avatar
      net/mv643xx: use GFP_ATOMIC while atomic · 82a5bd6a
      Sebastian Siewior authored
      dev_set_rx_mode() grabs netif_addr_lock_bh():
      
      |BUG: sleeping function called from invalid context at /home/bigeasy/git/cryptodev-2.6/mm/slub.c:1599
      |in_atomic(): 1, irqs_disabled(): 0, pid: 859, name: ifconfig
      |2 locks held by ifconfig/859:
      | #0:  (rtnl_mutex){--..}, at: [<c0239ccc>] rtnl_lock+0x18/0x20
      | #1:  (_xmit_ETHER){-...}, at: [<c022d094>] dev_set_rx_mode+0x1c/0x30
      |[<c029f118>] (dump_stack+0x0/0x14) from [<c003df28>] (__might_sleep+0x11c/0x13c)
      |[<c003de0c>] (__might_sleep+0x0/0x13c) from [<c00a8854>] (kmem_cache_alloc+0x30/0xd4)
      | r5:c78093a0 r4:c034a47c
      |[<c00a8824>] (kmem_cache_alloc+0x0/0xd4) from [<c01a5fd0>] (mv643xx_eth_set_rx_mode+0x70/0x188)
      |[<c01a5f60>] (mv643xx_eth_set_rx_mode+0x0/0x188) from [<c022ced0>] (__dev_set_rx_mode+0x40/0xac)
      |[<c022ce90>] (__dev_set_rx_mode+0x0/0xac) from [<c022d09c>] (dev_set_rx_mode+0x24/0x30)
      | r6:00001043 r5:c78090f8 r4:c7809000
      |[<c022d078>] (dev_set_rx_mode+0x0/0x30) from [<c02304c4>] (dev_open+0xe4/0x114)
      | r5:c7809350 r4:c7809000
      |[<c02303e0>] (dev_open+0x0/0x114) from [<c022fd18>] (dev_change_flags+0xb0/0x190)
      | r5:00000041 r4:c7809000
      |[<c022fc68>] (dev_change_flags+0x0/0x190) from [<c0270250>] (devinet_ioctl+0x2f0/0x710)
      | r7:c7221e70 r6:c7aadb00 r5:00000000 r4:00000001
      |[<c026ff60>] (devinet_ioctl+0x0/0x710) from [<c02717c8>] (inet_ioctl+0xd4/0x110)
      |[<c02716f4>] (inet_ioctl+0x0/0x110) from [<c021fb74>] (sock_ioctl+0x1f4/0x254)
      | r4:c7242b40
      |[<c021f980>] (sock_ioctl+0x0/0x254) from [<c00b8160>] (vfs_ioctl+0x38/0x98)
      | r6:beec9bb8 r5:00008914 r4:c7242b40
      |[<c00b8128>] (vfs_ioctl+0x0/0x98) from [<c00b873c>] (do_vfs_ioctl+0x484/0x4d4)
      | r6:00008914 r5:c7242b40 r4:c74db1c0
      |[<c00b82b8>] (do_vfs_ioctl+0x0/0x4d4) from [<c00b87cc>] (sys_ioctl+0x40/0x64)
      |[<c00b878c>] (sys_ioctl+0x0/0x64) from [<c00269a0>] (ret_fast_syscall+0x0/0x2c)
      |[42949399.520000]  r7:00000036 r6:beec9c80 r5:00000041 r4:beec9bb8
      Signed-off-by: default avatarSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Acked-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82a5bd6a
    • Jie Yang's avatar
      atl1c: Atheros L1C Gigabit Ethernet driver · 43250ddd
      Jie Yang authored
      Supporting AR8131, and AR8132.
      Signed-off-by: default avatarJie Yang <jie.yang@atheros.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43250ddd
  2. 18 Feb, 2009 1 commit
    • David S. Miller's avatar
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller authored
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92a0acce
  3. 16 Feb, 2009 1 commit
    • Tobias Diedrich's avatar
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich authored
      Commit f55c21fd ("forcedeth: call
      restore mac addr in nv_shutdown path"), which was introduced to fix
      the regression tracked at
      http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the
      wake-on-lan mac to be reversed in the shutdown path.  Apparently the
      forcedeth situation is rather messy in that the mac we need to
      writeback for a subsequent modprobe to work is exactly the reverse of
      what is needed for proper wake-on-lan.
      
      The following patch explains the situation in the comments and
      makes the call to nv_restore_mac_addr() conditional (only called if
      we are not really going for poweroff).
      
      Tobias Diedrich wrote:
      > Hmm, I had not tried WOL for some time.
      > With 2.6.29-rc3 is see the following behaviour:
      > 
      > State            WOL Behaviour
      > ------------------------------
      > shutdown         reversed MAC
      > disk/shutdown    reversed MAC
      > disk/platform    OK
      > 
      > Apparently nv_restore_mac_addr() restores the MAC in the wrong order
      > for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15).  platform
      > works, because the MAC is not touched in the nv_suspend() path.
      > 
      > A possible fix might be to only call nv_restore_mac_addr() if
      > system_state != SYSTEM_POWER_OFF.
      
      With the following patch:
      shutdown         OK
      disk/shutdown    OK
      disk/platform    OK
      kexec            OK
      Signed-off-by: default avatarTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: default avatarPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34edaa88
  4. 13 Feb, 2009 21 commits
  5. 11 Feb, 2009 11 commits
  6. 09 Feb, 2009 4 commits
    • Herbert Xu's avatar
      bridge: Fix LRO crash with tun · 4906f998
      Herbert Xu authored
      > Kernel BUG at drivers/net/tun.c:444
      > invalid opcode: 0000 [1] SMP
      > last sysfs file: /class/net/lo/ifindex
      > CPU 0
      > Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat xt_state ip_conntrack
      > nfnetlink ipt_REJECT xt_tcpudp iptable_filter d
      > Pid: 6912, comm: qemu-kvm Tainted: G      2.6.18-128.el5 #1
      > RIP: 0010:[<ffffffff886f57b0>]  [<ffffffff886f57b0>]
      > :tun:tun_chr_readv+0x2b1/0x3a6
      > RSP: 0018:ffff8102202c5e48  EFLAGS: 00010246
      > RAX: 0000000000000000 RBX: ffff8102202c5e98 RCX: 0000000004010000
      > RDX: ffff810227063680 RSI: ffff8102202c5e9e RDI: ffff8102202c5e92
      > RBP: 0000000000010ff6 R08: 0000000000000000 R09: 0000000000000001
      > R10: ffff8102202c5e94 R11: 0000000000000202 R12: ffff8102275357c0
      > R13: ffff81022755e500 R14: 0000000000000000 R15: ffff8102202c5ef8
      > FS:  00002ae4398db980(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      > CR2: 00002ae4ab514000 CR3: 0000000221344000 CR4: 00000000000026e0
      > Process qemu-kvm (pid: 6912, threadinfo ffff8102202c4000, task
      > ffff81022e58d820)
      > Stack:  00000000498735cb ffff810229d1a3c0 0000000000000000 ffff81022e58d820
      >  ffffffff8008a461 ffff81022755e528 ffff81022755e528 ffffffff8009f925
      >  000005ea05ea0000 ffff8102209d0000 00001051143e1600 ffffffff8003c00e
      > Call Trace:
      >  [<ffffffff8008a461>] default_wake_function+0x0/0xe
      >  [<ffffffff8009f925>] enqueue_hrtimer+0x55/0x70
      >  [<ffffffff8003c00e>] hrtimer_start+0xbc/0xce
      >  [<ffffffff886f58bf>] :tun:tun_chr_read+0x1a/0x1f
      >  [<ffffffff8000b3f3>] vfs_read+0xcb/0x171
      >  [<ffffffff800117d4>] sys_read+0x45/0x6e
      >  [<ffffffff8005d116>] system_call+0x7e/0x83
      >
      >
      > Code: 0f 0b 68 40 62 6f 88 c2 bc 01 f6 42 0a 08 74 0c 80 4c 24 41
      > RIP  [<ffffffff886f57b0>] :tun:tun_chr_readv+0x2b1/0x3a6
      >  RSP <ffff8102202c5e48>
      >  <0>Kernel panic - not syncing: Fatal exception
      
      This crashed when an LRO packet generated by bnx2x reached a
      tun device through the bridge.  We're supposed to drop it at
      the bridge.  However, because the check was placed in br_forward
      instead of __br_forward, it's only effective if we are sending
      the packet through a single port.
      
      This patch fixes it by moving the check into __br_forward.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4906f998
    • Noriaki TAKAMIYA's avatar
      IPv6: fix to set device name when new IPv6 over IPv6 tunnel device is created. · 20461c17
      Noriaki TAKAMIYA authored
      When the user creates IPv6 over IPv6 tunnel, the device name created
      by the kernel isn't set to t->parm.name, which is referred as the
      result of ioctl().
      Signed-off-by: default avatarNoriaki TAKAMIYA <takamiya@po.ntts.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20461c17
    • Jarek Poplawski's avatar
      gianfar: Fix boot hangs while bringing up gianfar ethernet · 8707bdd4
      Jarek Poplawski authored
      Ira Snyder found that commit 8c7396ae
      "gianfar: Merge Tx and Rx interrupt for scheduling clean up ring" can
      cause hangs. It's because there was removed clearing of interrupts in
      gfar_schedule_cleanup() (which is called by an interrupt handler) in
      case when netif scheduling has been disabled. This patch brings back
      this action and a comment.
      Reported-by: default avatarIra Snyder <iws@ovro.caltech.edu>
      Reported-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      Bisected-by: default avatarIra Snyder <iws@ovro.caltech.edu>
      Tested-by: default avatarPeter Korsgaard <jacmet@sunsite.dk>
      Tested-by: default avatarIra Snyder <iws@ovro.caltech.edu>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8707bdd4
    • Qu Haoran's avatar
      netfilter: xt_sctp: sctp chunk mapping doesn't work · d4e2675a
      Qu Haoran authored
      When user tries to map all chunks given in argument, kernel
      works on a copy of the chunkmap, but at the end it doesn't
      check the copy, but the orginal one.
      Signed-off-by: default avatarQu Haoran <haoran.qu@6wind.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4e2675a