1. 04 2月, 2010 1 次提交
    • 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
  2. 03 2月, 2010 2 次提交
    • E
      connector: Delete buggy notification code. · f98bfbd7
      Evgeniy Polyakov 提交于
      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: NEvgeniy Polyakov <zbr@ioremap.net>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f98bfbd7
    • D
  3. 02 2月, 2010 1 次提交
  4. 01 2月, 2010 1 次提交
  5. 30 1月, 2010 5 次提交
  6. 29 1月, 2010 2 次提交
  7. 28 1月, 2010 7 次提交
  8. 27 1月, 2010 3 次提交
  9. 26 1月, 2010 8 次提交
  10. 25 1月, 2010 3 次提交
  11. 24 1月, 2010 1 次提交
  12. 23 1月, 2010 6 次提交