1. 27 2月, 2018 2 次提交
  2. 24 2月, 2018 3 次提交
  3. 23 2月, 2018 8 次提交
  4. 22 2月, 2018 10 次提交
  5. 21 2月, 2018 6 次提交
  6. 20 2月, 2018 11 次提交
    • P
      tipc: don't call sock_release() in atomic context · 26736a08
      Paolo Abeni 提交于
      syzbot reported a scheduling while atomic issue at netns
      destruction time:
      
      BUG: sleeping function called from invalid context at net/core/sock.c:2769
      in_atomic(): 1, irqs_disabled(): 0, pid: 85, name: kworker/u4:3
      5 locks held by kworker/u4:3/85:
        #0:  ((wq_completion)"%s""netns"){+.+.}, at: [<00000000c9792deb>]
      process_one_work+0xaaf/0x1af0 kernel/workqueue.c:2084
        #1:  (net_cleanup_work){+.+.}, at: [<00000000adc12e2a>]
      process_one_work+0xb01/0x1af0 kernel/workqueue.c:2088
        #2:  (net_sem){++++}, at: [<000000009ccb5669>] cleanup_net+0x23f/0xd20
      net/core/net_namespace.c:494
        #3:  (net_mutex){+.+.}, at: [<00000000a92767d9>] cleanup_net+0xa7d/0xd20
      net/core/net_namespace.c:496
        #4:  (&(&srv->idr_lock)->rlock){+...}, at: [<000000001343e568>]
      spin_lock_bh include/linux/spinlock.h:315 [inline]
        #4:  (&(&srv->idr_lock)->rlock){+...}, at: [<000000001343e568>]
      tipc_topsrv_stop+0x231/0x610 net/tipc/topsrv.c:685
      CPU: 0 PID: 85 Comm: kworker/u4:3 Not tainted 4.16.0-rc1+ #230
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Workqueue: netns cleanup_net
      Call Trace:
        __dump_stack lib/dump_stack.c:17 [inline]
        dump_stack+0x194/0x257 lib/dump_stack.c:53
        ___might_sleep+0x2b2/0x470 kernel/sched/core.c:6128
        __might_sleep+0x95/0x190 kernel/sched/core.c:6081
        lock_sock_nested+0x37/0x110 net/core/sock.c:2769
        lock_sock include/net/sock.h:1463 [inline]
        tipc_release+0x103/0xff0 net/tipc/socket.c:572
        sock_release+0x8d/0x1e0 net/socket.c:594
        tipc_topsrv_stop+0x3c0/0x610 net/tipc/topsrv.c:696
        tipc_exit_net+0x15/0x40 net/tipc/core.c:96
        ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:148
        cleanup_net+0x6ba/0xd20 net/core/net_namespace.c:529
        process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
        worker_thread+0x223/0x1990 kernel/workqueue.c:2247
        kthread+0x33c/0x400 kernel/kthread.c:238
        ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
      
      This is caused by tipc_topsrv_stop() releasing the listener socket
      with the idr lock held. This changeset addresses the issue moving
      the release operation outside such lock.
      
      Reported-and-tested-by: syzbot+749d9d87c294c00ca856@syzkaller.appspotmail.com
      Fixes: 0ef897be ("tipc: separate topology server listener socket from subcsriber sockets")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by:  ///jon
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26736a08
    • J
      tipc: fix bug on error path in tipc_topsrv_kern_subscr() · 96c252bf
      Jon Maloy 提交于
      In commit cc1ea9ffadf7 ("tipc: eliminate struct tipc_subscriber") we
      re-introduced an old bug on the error path in the function
      tipc_topsrv_kern_subscr(). We now re-introduce the correction too.
      
      Reported-by: syzbot+f62e0f2a0ef578703946@syzkaller.appspotmail.com
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96c252bf
    • K
      net: Convert iptable_filter_net_ops · da349fad
      Kirill Tkhai 提交于
      These pernet_operations register and unregister
      net::ipv4.iptable_filter table. Since there are
      no packets in-flight at the time of exit method
      is working, iptables rules should not be touched.
      Also, pernet_operations should not send ipv4
      packets each other. So, it's safe to mark them
      async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da349fad
    • K
      net: Convert ip_tables_net_ops, udplite6_net_ops and xt_net_ops · 4d6b8076
      Kirill Tkhai 提交于
      ip_tables_net_ops and udplite6_net_ops create and destroy /proc entries.
      xt_net_ops does nothing.
      
      So, we are able to mark them async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d6b8076
    • K
      net: Convert ip6_frags_ops · 5fc094f5
      Kirill Tkhai 提交于
      Exit methods calls inet_frags_exit_net() with global ip6_frags
      as argument. So, after we make the pernet_operations async,
      a pair of exit methods may be called to iterate this hash table.
      Since there is inet_frag_worker(), which already may work
      in parallel with inet_frags_exit_net(), and it can make the same
      cleanup, that inet_frags_exit_net() does, it's safe. So we may
      mark these pernet_operations as async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5fc094f5
    • K
      net: Convert fib6_net_ops, ipv6_addr_label_ops and ip6_segments_ops · d16784d9
      Kirill Tkhai 提交于
      These pernet_operations register and unregister tables
      and lists for packets forwarding. All of the entities
      are per-net. Init methods makes simple initializations,
      and since net is not visible for foreigners at the time
      it is working, it can't race with anything. Exit method
      is executed when there are only local devices, and there
      mustn't be packets in-flight. Also, it looks like no one
      pernet_operations want to send ipv6 packets to foreign
      net. The same reasons are for ipv6_addr_label_ops and
      ip6_segments_ops. So, we are able to mark all them as
      async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d16784d9
    • K
      net: Convert xfrm6_net_ops · b4891413
      Kirill Tkhai 提交于
      These pernet_operations create sysctl tables and
      initialize net::xfrm.xfrm6_dst_ops used for routing.
      It doesn't look like another pernet_operations send
      ipv6 packets to foreign net namespaces, so it should
      be safe to mark the pernet_operations as async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4891413
    • K
      net: Convert ip6_flowlabel_net_ops · a7852a76
      Kirill Tkhai 提交于
      These pernet_operations create and destroy /proc entries.
      ip6_fl_purge() makes almost the same actions as timer
      ip6_fl_gc_timer does, and as it can be executed in parallel
      with ip6_fl_purge(), two parallel ip6_fl_purge() may be
      executed. So, we can mark it async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7852a76
    • K
      net: Convert ping_v6_net_ops · ac34cb6c
      Kirill Tkhai 提交于
      These pernet_operations only register and unregister /proc
      entries, so it's possible to mark them async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac34cb6c
    • K
      net: Convert ipv6_sysctl_net_ops · 58708cae
      Kirill Tkhai 提交于
      These pernet_operations create and destroy sysctl tables.
      They are not touched by another net pernet_operations.
      So, it's possible to execute them in parallel with others.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58708cae
    • K
      net: Convert tcpv6_net_ops · fef65a2c
      Kirill Tkhai 提交于
      These pernet_operations create and destroy net::ipv6.tcp_sk
      socket, which is used in tcp_v6_send_response() only. It looks
      like foreign pernet_operations don't want to set ipv6 connection
      inside destroyed net, so this socket may be created in destroyed
      in parallel with anything else. inet_twsk_purge() is also safe
      for that, as described in patch for tcp_sk_ops. So, it's possible
      to mark them as async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fef65a2c