Skip to content
  1. Feb 04, 2010
    • Amit Kumar Salecha's avatar
      netxen: protect resource cleanup by rtnl lock · e15eec28
      Amit Kumar Salecha authored
      
      
      o context resources can be in used, while resource cleanup is in progress,
        during fw recover.
      o Null pointer execption can occur in send_cmd_desc, if fw recovery
        module frees tx ring without rtnl lock.
      o Same applies to ethtool register dump.
      
      Signed-off-by: default avatarAmit Kumar Salecha <amit.salecha@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e15eec28
    • Amit Kumar Salecha's avatar
      netxen: fix tx timeout recovery for NX2031 chip · 41f3e0b1
      Amit Kumar Salecha authored
      
      
      For NX2031, first try to scrub interrupt before requesting firmware
      reset. Return statement was missing after scrubbbing interrupt.
      
      Signed-off-by: default avatarVernon Mauery <vernux@us.ibm.com>
      Signed-off-by: default avatarAmit Kumar Salecha <amit.salecha@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41f3e0b1
    • Gerrit Renker's avatar
      dccp: fix auto-loading of dccp(_probe) · 1386be55
      Gerrit Renker authored
      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: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1386be55
    • Gerrit Renker's avatar
      dccp: fix bug in cache allocation · 8ed030dd
      Gerrit Renker authored
      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: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ed030dd
    • stephen hemminger's avatar
      sky2: fix transmit DMA map leakage · f6815077
      stephen hemminger authored
      
      
      The book keeping structure for transmit always had the flags value
      cleared so transmit DMA maps were never released correctly.
      Based on patch by Jarek Poplawski, problem observed by Michael Breuer.
      
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6815077
    • Alexey Dobriyan's avatar
      netlink: fix for too early rmmod · 974c37e9
      Alexey Dobriyan authored
      
      
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      974c37e9
    • Alexey Dobriyan's avatar
      af_key: fix netns ops ordering on module load/unload · 180211b8
      Alexey Dobriyan authored
      
      
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Tested-by: default avatarLuca Tettamanti <kronos.it@gmail.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      180211b8
  2. Feb 03, 2010
    • Evgeniy Polyakov's avatar
      connector: Delete buggy notification code. · f98bfbd7
      Evgeniy Polyakov authored
      
      
      On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote:
      > > There are at least two ways to fix it: using a big cannon and a small
      > > one. The former way is to disable notification registration, since it is
      > > not used by anyone at all. Second way is to check whether calling
      > > process is root and its destination group is -1 (kind of priveledged
      > > one) before command is dispatched to workqueue.
      > 
      > Well if no one is using it, removing it makes the most sense, right?
      > 
      > No objection from me, care to make up a patch either way for this?
      
      Getting it is not used, let's drop support for notifications about
      (un)registered events from connector.
      Another option was to check credentials on receiving, but we can always
      restore it without bugs if needed, but genetlink has a wider code base
      and none complained, that userspace can not get notification when some
      other clients were (un)registered.
      
      Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the
      code.
      
      Signed-off-by: default avatarEvgeniy Polyakov <zbr@ioremap.net>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f98bfbd7
    • David S. Miller's avatar
  3. Feb 02, 2010
  4. Feb 01, 2010
  5. Jan 30, 2010
  6. Jan 29, 2010
  7. Jan 28, 2010
  8. Jan 27, 2010
  9. Jan 26, 2010
  10. Jan 25, 2010
  11. Jan 24, 2010