1. 27 5月, 2019 5 次提交
  2. 27 2月, 2019 1 次提交
  3. 26 1月, 2019 1 次提交
  4. 16 12月, 2018 1 次提交
    • M
      net: ipv4: do not handle duplicate fragments as overlapping · ade44640
      Michal Kubecek 提交于
      Since commit 7969e5c4 ("ip: discard IPv4 datagrams with overlapping
      segments.") IPv4 reassembly code drops the whole queue whenever an
      overlapping fragment is received. However, the test is written in a way
      which detects duplicate fragments as overlapping so that in environments
      with many duplicate packets, fragmented packets may be undeliverable.
      
      Add an extra test and for (potentially) duplicate fragment, only drop the
      new fragment rather than the whole queue. Only starting offset and length
      are checked, not the contents of the fragments as that would be too
      expensive. For similar reason, linear list ("run") of a rbtree node is not
      iterated, we only check if the new fragment is a subset of the interval
      covered by existing consecutive fragments.
      
      v2: instead of an exact check iterating through linear list of an rbtree
      node, only check if the new fragment is subset of the "run" (suggested
      by Eric Dumazet)
      
      Fixes: 7969e5c4 ("ip: discard IPv4 datagrams with overlapping segments.")
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ade44640
  5. 06 12月, 2018 1 次提交
    • J
      ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes · ebaf39e6
      Jiri Wiesner 提交于
      The *_frag_reasm() functions are susceptible to miscalculating the byte
      count of packet fragments in case the truesize of a head buffer changes.
      The truesize member may be changed by the call to skb_unclone(), leaving
      the fragment memory limit counter unbalanced even if all fragments are
      processed. This miscalculation goes unnoticed as long as the network
      namespace which holds the counter is not destroyed.
      
      Should an attempt be made to destroy a network namespace that holds an
      unbalanced fragment memory limit counter the cleanup of the namespace
      never finishes. The thread handling the cleanup gets stuck in
      inet_frags_exit_net() waiting for the percpu counter to reach zero. The
      thread is usually in running state with a stacktrace similar to:
      
       PID: 1073   TASK: ffff880626711440  CPU: 1   COMMAND: "kworker/u48:4"
        #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480
        #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b
        #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c
        #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856
        #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0
       #10 [ffff880621563e38] process_one_work at ffffffff81096f14
      
      It is not possible to create new network namespaces, and processes
      that call unshare() end up being stuck in uninterruptible sleep state
      waiting to acquire the net_mutex.
      
      The bug was observed in the IPv6 netfilter code by Per Sundstrom.
      I thank him for his analysis of the problem. The parts of this patch
      that apply to IPv4 and IPv6 fragment reassembly are preemptive measures.
      Signed-off-by: NJiri Wiesner <jwiesner@suse.com>
      Reported-by: NPer Sundstrom <per.sundstrom@redqube.se>
      Acked-by: NPeter Oskolkov <posk@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebaf39e6
  6. 02 11月, 2018 1 次提交
    • C
      net: drop skb on failure in ip_check_defrag() · 7de414a9
      Cong Wang 提交于
      Most callers of pskb_trim_rcsum() simply drop the skb when
      it fails, however, ip_check_defrag() still continues to pass
      the skb up to stack. This is suspicious.
      
      In ip_check_defrag(), after we learn the skb is an IP fragment,
      passing the skb to callers makes no sense, because callers expect
      fragments are defrag'ed on success. So, dropping the skb when we
      can't defrag it is reasonable.
      
      Note, prior to commit 88078d98, this is not a big problem as
      checksum will be fixed up anyway. After it, the checksum is not
      correct on failure.
      
      Found this during code review.
      
      Fixes: 88078d98 ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7de414a9
  7. 22 9月, 2018 2 次提交
    • P
      net/ipfrag: let ip[6]frag_high_thresh in ns be higher than in init_net · 83619623
      Peter Oskolkov 提交于
      Currently, ip[6]frag_high_thresh sysctl values in new namespaces are
      hard-limited to those of the root/init ns.
      
      There are at least two use cases when it would be desirable to
      set the high_thresh values higher in a child namespace vs the global hard
      limit:
      
      - a security/ddos protection policy may lower the thresholds in the
        root/init ns but allow for a special exception in a child namespace
      - testing: a test running in a namespace may want to set these
        thresholds higher in its namespace than what is in the root/init ns
      
      The new behavior:
      
       # ip netns add testns
       # ip netns exec testns bash
      
       # sysctl -w net.ipv4.ipfrag_high_thresh=9000000
       net.ipv4.ipfrag_high_thresh = 9000000
      
       # sysctl net.ipv4.ipfrag_high_thresh
       net.ipv4.ipfrag_high_thresh = 9000000
      
       # sysctl -w net.ipv6.ip6frag_high_thresh=9000000
       net.ipv6.ip6frag_high_thresh = 9000000
      
       # sysctl net.ipv6.ip6frag_high_thresh
       net.ipv6.ip6frag_high_thresh = 9000000
      
      The old behavior:
      
       # ip netns add testns
       # ip netns exec testns bash
      
       # sysctl -w net.ipv4.ipfrag_high_thresh=9000000
       net.ipv4.ipfrag_high_thresh = 9000000
      
       # sysctl net.ipv4.ipfrag_high_thresh
       net.ipv4.ipfrag_high_thresh = 4194304
      
       # sysctl -w net.ipv6.ip6frag_high_thresh=9000000
       net.ipv6.ip6frag_high_thresh = 9000000
      
       # sysctl net.ipv6.ip6frag_high_thresh
       net.ipv6.ip6frag_high_thresh = 4194304
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83619623
    • Z
      ipv4: remove redundant null pointer check before kfree_skb · 1d08962f
      zhong jiang 提交于
      kfree_skb has taken the null pointer into account. hence it is safe
      to remove the redundant null pointer check before kfree_skb.
      Signed-off-by: Nzhong jiang <zhongjiang@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d08962f
  8. 11 9月, 2018 1 次提交
  9. 10 9月, 2018 1 次提交
    • T
      ip: frags: fix crash in ip_do_fragment() · 5d407b07
      Taehee Yoo 提交于
      A kernel crash occurrs when defragmented packet is fragmented
      in ip_do_fragment().
      In defragment routine, skb_orphan() is called and
      skb->ip_defrag_offset is set. but skb->sk and
      skb->ip_defrag_offset are same union member. so that
      frag->sk is not NULL.
      Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
      defragmented packet is fragmented.
      
      test commands:
         %iptables -t nat -I POSTROUTING -j MASQUERADE
         %hping3 192.168.4.2 -s 1000 -p 2000 -d 60000
      
      splat looks like:
      [  261.069429] kernel BUG at net/ipv4/ip_output.c:636!
      [  261.075753] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  261.083854] CPU: 1 PID: 1349 Comm: hping3 Not tainted 4.19.0-rc2+ #3
      [  261.100977] RIP: 0010:ip_do_fragment+0x1613/0x2600
      [  261.106945] Code: e8 e2 38 e3 fe 4c 8b 44 24 18 48 8b 74 24 08 e9 92 f6 ff ff 80 3c 02 00 0f 85 da 07 00 00 48 8b b5 d0 00 00 00 e9 25 f6 ff ff <0f> 0b 0f 0b 44 8b 54 24 58 4c 8b 4c 24 18 4c 8b 5c 24 60 4c 8b 6c
      [  261.127015] RSP: 0018:ffff8801031cf2c0 EFLAGS: 00010202
      [  261.134156] RAX: 1ffff1002297537b RBX: ffffed0020639e6e RCX: 0000000000000004
      [  261.142156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880114ba9bd8
      [  261.150157] RBP: ffff880114ba8a40 R08: ffffed0022975395 R09: ffffed0022975395
      [  261.158157] R10: 0000000000000001 R11: ffffed0022975394 R12: ffff880114ba9ca4
      [  261.166159] R13: 0000000000000010 R14: ffff880114ba9bc0 R15: dffffc0000000000
      [  261.174169] FS:  00007fbae2199700(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
      [  261.183012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  261.189013] CR2: 00005579244fe000 CR3: 0000000119bf4000 CR4: 00000000001006e0
      [  261.198158] Call Trace:
      [  261.199018]  ? dst_output+0x180/0x180
      [  261.205011]  ? save_trace+0x300/0x300
      [  261.209018]  ? ip_copy_metadata+0xb00/0xb00
      [  261.213034]  ? sched_clock_local+0xd4/0x140
      [  261.218158]  ? kill_l4proto+0x120/0x120 [nf_conntrack]
      [  261.223014]  ? rt_cpu_seq_stop+0x10/0x10
      [  261.227014]  ? find_held_lock+0x39/0x1c0
      [  261.233008]  ip_finish_output+0x51d/0xb50
      [  261.237006]  ? ip_fragment.constprop.56+0x220/0x220
      [  261.243011]  ? nf_ct_l4proto_register_one+0x5b0/0x5b0 [nf_conntrack]
      [  261.250152]  ? rcu_is_watching+0x77/0x120
      [  261.255010]  ? nf_nat_ipv4_out+0x1e/0x2b0 [nf_nat_ipv4]
      [  261.261033]  ? nf_hook_slow+0xb1/0x160
      [  261.265007]  ip_output+0x1c7/0x710
      [  261.269005]  ? ip_mc_output+0x13f0/0x13f0
      [  261.273002]  ? __local_bh_enable_ip+0xe9/0x1b0
      [  261.278152]  ? ip_fragment.constprop.56+0x220/0x220
      [  261.282996]  ? nf_hook_slow+0xb1/0x160
      [  261.287007]  raw_sendmsg+0x21f9/0x4420
      [  261.291008]  ? dst_output+0x180/0x180
      [  261.297003]  ? sched_clock_cpu+0x126/0x170
      [  261.301003]  ? find_held_lock+0x39/0x1c0
      [  261.306155]  ? stop_critical_timings+0x420/0x420
      [  261.311004]  ? check_flags.part.36+0x450/0x450
      [  261.315005]  ? _raw_spin_unlock_irq+0x29/0x40
      [  261.320995]  ? _raw_spin_unlock_irq+0x29/0x40
      [  261.326142]  ? cyc2ns_read_end+0x10/0x10
      [  261.330139]  ? raw_bind+0x280/0x280
      [  261.334138]  ? sched_clock_cpu+0x126/0x170
      [  261.338995]  ? check_flags.part.36+0x450/0x450
      [  261.342991]  ? __lock_acquire+0x4500/0x4500
      [  261.348994]  ? inet_sendmsg+0x11c/0x500
      [  261.352989]  ? dst_output+0x180/0x180
      [  261.357012]  inet_sendmsg+0x11c/0x500
      [ ... ]
      
      v2:
       - clear skb->sk at reassembly routine.(Eric Dumarzet)
      
      Fixes: fa0f5273 ("ip: use rb trees for IP frag queue.")
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d407b07
  10. 30 8月, 2018 1 次提交
    • P
      ip: fail fast on IP defrag errors · 0ff89efb
      Peter Oskolkov 提交于
      The current behavior of IP defragmentation is inconsistent:
      - some overlapping/wrong length fragments are dropped without
        affecting the queue;
      - most overlapping fragments cause the whole frag queue to be dropped.
      
      This patch brings consistency: if a bad fragment is detected,
      the whole frag queue is dropped. Two major benefits:
      - fail fast: corrupted frag queues are cleared immediately, instead of
        by timeout;
      - testing of overlapping fragments is now much easier: any kind of
        random fragment length mutation now leads to the frag queue being
        discarded (IP packet dropped); before this patch, some overlaps were
        "corrected", with tests not seeing expected packet drops.
      
      Note that in one case (see "if (end&7)" conditional) the current
      behavior is preserved as there are concerns that this could be
      legitimate padding.
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ff89efb
  11. 12 8月, 2018 2 次提交
    • P
      ip: process in-order fragments efficiently · a4fd284a
      Peter Oskolkov 提交于
      This patch changes the runtime behavior of IP defrag queue:
      incoming in-order fragments are added to the end of the current
      list/"run" of in-order fragments at the tail.
      
      On some workloads, UDP stream performance is substantially improved:
      
      RX: ./udp_stream -F 10 -T 2 -l 60
      TX: ./udp_stream -c -H <host> -F 10 -T 5 -l 60
      
      with this patchset applied on a 10Gbps receiver:
      
        throughput=9524.18
        throughput_units=Mbit/s
      
      upstream (net-next):
      
        throughput=4608.93
        throughput_units=Mbit/s
      Reported-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4fd284a
    • P
      ip: add helpers to process in-order fragments faster. · 353c9cb3
      Peter Oskolkov 提交于
      This patch introduces several helper functions/macros that will be
      used in the follow-up patch. No runtime changes yet.
      
      The new logic (fully implemented in the second patch) is as follows:
      
      * Nodes in the rb-tree will now contain not single fragments, but lists
        of consecutive fragments ("runs").
      
      * At each point in time, the current "active" run at the tail is
        maintained/tracked. Fragments that arrive in-order, adjacent
        to the previous tail fragment, are added to this tail run without
        triggering the re-balancing of the rb-tree.
      
      * If a fragment arrives out of order with the offset _before_ the tail run,
        it is inserted into the rb-tree as a single fragment.
      
      * If a fragment arrives after the current tail fragment (with a gap),
        it starts a new "tail" run, as is inserted into the rb-tree
        at the end as the head of the new run.
      
      skb->cb is used to store additional information
      needed here (suggested by Eric Dumazet).
      Reported-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      353c9cb3
  12. 07 8月, 2018 1 次提交
  13. 06 8月, 2018 2 次提交
  14. 01 8月, 2018 1 次提交
    • E
      ipv4: frags: handle possible skb truesize change · 4672694b
      Eric Dumazet 提交于
      ip_frag_queue() might call pskb_pull() on one skb that
      is already in the fragment queue.
      
      We need to take care of possible truesize change, or we
      might have an imbalance of the netns frags memory usage.
      
      IPv6 is immune to this bug, because RFC5722, Section 4,
      amended by Errata ID 3089 states :
      
        When reassembling an IPv6 datagram, if
        one or more its constituent fragments is determined to be an
        overlapping fragment, the entire datagram (and any constituent
        fragments) MUST be silently discarded.
      
      Fixes: 158f323b ("net: adjust skb->truesize in pskb_expand_head()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4672694b
  15. 05 4月, 2018 1 次提交
  16. 01 4月, 2018 10 次提交
    • E
      inet: frags: get rid of ipfrag_skb_cb/FRAG_CB · bf663371
      Eric Dumazet 提交于
      ip_defrag uses skb->cb[] to store the fragment offset, and unfortunately
      this integer is currently in a different cache line than skb->next,
      meaning that we use two cache lines per skb when finding the insertion point.
      
      By aliasing skb->ip_defrag_offset and skb->dev, we pack all the fields
      in a single cache line and save precious memory bandwidth.
      
      Note that after the fast path added by Changli Gao in commit
      d6bebca9 ("fragment: add fast path for in-order fragments")
      this change wont help the fast path, since we still need
      to access prev->len (2nd cache line), but will show great
      benefits when slow path is entered, since we perform
      a linear scan of a potentially long list.
      
      Also, note that this potential long list is an attack vector,
      we might consider also using an rb-tree there eventually.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf663371
    • E
      inet: frags: do not clone skb in ip_expire() · 1eec5d56
      Eric Dumazet 提交于
      An skb_clone() was added in commit ec4fbd64 ("inet: frag: release
      spinlock before calling icmp_send()")
      
      While fixing the bug at that time, it also added a very high cost
      for DDOS frags, as the ICMP rate limit is applied after this
      expensive operation (skb_clone() + consume_skb(), implying memory
      allocations, copy, and freeing)
      
      We can use skb_get(head) here, all we want is to make sure skb wont
      be freed by another cpu.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1eec5d56
    • E
      inet: frags: break the 2GB limit for frags storage · 3e67f106
      Eric Dumazet 提交于
      Some users are willing to provision huge amounts of memory to be able
      to perform reassembly reasonnably well under pressure.
      
      Current memory tracking is using one atomic_t and integers.
      
      Switch to atomic_long_t so that 64bit arches can use more than 2GB,
      without any cost for 32bit arches.
      
      Note that this patch avoids an overflow error, if high_thresh was set
      to ~2GB, since this test in inet_frag_alloc() was never true :
      
      if (... || frag_mem_limit(nf) > nf->high_thresh)
      
      Tested:
      
      $ echo 16000000000 >/proc/sys/net/ipv4/ipfrag_high_thresh
      
      <frag DDOS>
      
      $ grep FRAG /proc/net/sockstat
      FRAG: inuse 14705885 memory 16000002880
      
      $ nstat -n ; sleep 1 ; nstat | grep Reas
      IpReasmReqds                    3317150            0.0
      IpReasmFails                    3317112            0.0
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e67f106
    • E
      inet: frags: remove inet_frag_maybe_warn_overflow() · 2d44ed22
      Eric Dumazet 提交于
      This function is obsolete, after rhashtable addition to inet defrag.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d44ed22
    • E
      inet: frags: get rif of inet_frag_evicting() · 399d1404
      Eric Dumazet 提交于
      This refactors ip_expire() since one indentation level is removed.
      
      Note: in the future, we should try hard to avoid the skb_clone()
      since this is a serious performance cost.
      Under DDOS, the ICMP message wont be sent because of rate limits.
      
      Fact that ip6_expire_frag_queue() does not use skb_clone() is
      disturbing too. Presumably IPv6 should have the same
      issue than the one we fixed in commit ec4fbd64
      ("inet: frag: release spinlock before calling icmp_send()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      399d1404
    • E
      inet: frags: remove some helpers · 6befe4a7
      Eric Dumazet 提交于
      Remove sum_frag_mem_limit(), ip_frag_mem() & ip6_frag_mem()
      
      Also since we use rhashtable we can bring back the number of fragments
      in "grep FRAG /proc/net/sockstat /proc/net/sockstat6" that was
      removed in commit 434d3054 ("inet: frag: don't account number
      of fragment queues")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6befe4a7
    • E
      inet: frags: use rhashtables for reassembly units · 648700f7
      Eric Dumazet 提交于
      Some applications still rely on IP fragmentation, and to be fair linux
      reassembly unit is not working under any serious load.
      
      It uses static hash tables of 1024 buckets, and up to 128 items per bucket (!!!)
      
      A work queue is supposed to garbage collect items when host is under memory
      pressure, and doing a hash rebuild, changing seed used in hash computations.
      
      This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
      occurring every 5 seconds if host is under fire.
      
      Then there is the problem of sharing this hash table for all netns.
      
      It is time to switch to rhashtables, and allocate one of them per netns
      to speedup netns dismantle, since this is a critical metric these days.
      
      Lookup is now using RCU. A followup patch will even remove
      the refcount hold/release left from prior implementation and save
      a couple of atomic operations.
      
      Before this patch, 16 cpus (16 RX queue NIC) could not handle more
      than 1 Mpps frags DDOS.
      
      After the patch, I reach 9 Mpps without any tuning, and can use up to 2GB
      of storage for the fragments (exact number depends on frags being evicted
      after timeout)
      
      $ grep FRAG /proc/net/sockstat
      FRAG: inuse 1966916 memory 2140004608
      
      A followup patch will change the limits for 64bit arches.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      648700f7
    • E
      inet: frags: refactor ipfrag_init() · 483a6e4f
      Eric Dumazet 提交于
      We need to call inet_frags_init() before register_pernet_subsys(),
      as a prereq for following patch ("inet: frags: use rhashtables for reassembly units")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      483a6e4f
    • E
      inet: frags: add a pointer to struct netns_frags · 093ba729
      Eric Dumazet 提交于
      In order to simplify the API, add a pointer to struct inet_frags.
      This will allow us to make things less complex.
      
      These functions no longer have a struct inet_frags parameter :
      
      inet_frag_destroy(struct inet_frag_queue *q  /*, struct inet_frags *f */)
      inet_frag_put(struct inet_frag_queue *q /*, struct inet_frags *f */)
      inet_frag_kill(struct inet_frag_queue *q /*, struct inet_frags *f */)
      inet_frags_exit_net(struct netns_frags *nf /*, struct inet_frags *f */)
      ip6_expire_frag_queue(struct net *net, struct frag_queue *fq)
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      093ba729
    • E
      inet: frags: change inet_frags_init_net() return value · 787bea77
      Eric Dumazet 提交于
      We will soon initialize one rhashtable per struct netns_frags
      in inet_frags_init_net().
      
      This patch changes the return value to eventually propagate an
      error.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      787bea77
  17. 28 3月, 2018 1 次提交
  18. 13 2月, 2018 1 次提交
    • K
      net: Convert pernet_subsys, registered from inet_init() · f84c6821
      Kirill Tkhai 提交于
      arp_net_ops just addr/removes /proc entry.
      
      devinet_ops allocates and frees duplicate of init_net tables
      and (un)registers sysctl entries.
      
      fib_net_ops allocates and frees pernet tables, creates/destroys
      netlink socket and (un)initializes /proc entries. Foreign
      pernet_operations do not touch them.
      
      ip_rt_proc_ops only modifies pernet /proc entries.
      
      xfrm_net_ops creates/destroys /proc entries, allocates/frees
      pernet statistics, hashes and tables, and (un)initializes
      sysctl files. These are not touched by foreigh pernet_operations
      
      xfrm4_net_ops allocates/frees private pernet memory, and
      configures sysctls.
      
      sysctl_route_ops creates/destroys sysctls.
      
      rt_genid_ops only initializes fields of just allocated net.
      
      ipv4_inetpeer_ops allocated/frees net private memory.
      
      igmp_net_ops just creates/destroys /proc files and socket,
      noone else interested in.
      
      tcp_sk_ops seems to be safe, because tcp_sk_init() does not
      depend on any other pernet_operations modifications. Iteration
      over hash table in inet_twsk_purge() is made under RCU lock,
      and it's safe to iterate the table this way. Removing from
      the table happen from inet_twsk_deschedule_put(), but this
      function is safe without any extern locks, as it's synchronized
      inside itself. There are many examples, it's used in different
      context. So, it's safe to leave tcp_sk_exit_batch() unlocked.
      
      tcp_net_metrics_ops is synchronized on tcp_metrics_lock and safe.
      
      udplite4_net_ops only creates/destroys pernet /proc file.
      
      icmp_sk_ops creates percpu sockets, not touched by foreign
      pernet_operations.
      
      ipmr_net_ops creates/destroys pernet fib tables, (un)registers
      fib rules and /proc files. This seem to be safe to execute
      in parallel with foreign pernet_operations.
      
      af_inet_ops just sets up default parameters of newly created net.
      
      ipv4_mib_ops creates and destroys pernet percpu statistics.
      
      raw_net_ops, tcp4_net_ops, udp4_net_ops, ping_v4_net_ops
      and ip_proc_ops only create/destroy pernet /proc files.
      
      ip4_frags_ops creates and destroys sysctl file.
      
      So, it's safe to make the pernet_operations async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Acked-by: NAndrei Vagin <avagin@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f84c6821
  19. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  20. 18 10月, 2017 1 次提交
    • K
      inet: frags: Convert timers to use timer_setup() · 78802011
      Kees Cook 提交于
      In preparation for unconditionally passing the struct timer_list pointer to
      all timer callbacks, switch to using the new timer_setup() and from_timer()
      to pass the timer pointer explicitly.
      
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@osg.samsung.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Pablo Neira Ayuso <pablo@netfilter.org>
      Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: linux-wpan@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: netfilter-devel@vger.kernel.org
      Cc: coreteam@netfilter.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: Stefan Schmidt <stefan@osg.samsung.com> # for ieee802154
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78802011
  21. 04 9月, 2017 1 次提交
  22. 01 7月, 2017 1 次提交
  23. 23 3月, 2017 1 次提交
    • E
      inet: frag: release spinlock before calling icmp_send() · ec4fbd64
      Eric Dumazet 提交于
      Dmitry reported a lockdep splat [1] (false positive) that we can fix
      by releasing the spinlock before calling icmp_send() from ip_expire()
      
      This is a false positive because sending an ICMP message can not
      possibly re-enter the IP frag engine.
      
      [1]
      [ INFO: possible circular locking dependency detected ]
      4.10.0+ #29 Not tainted
      -------------------------------------------------------
      modprobe/12392 is trying to acquire lock:
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>] spin_lock
      include/linux/spinlock.h:299 [inline]
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>] __netif_tx_lock
      include/linux/netdevice.h:3486 [inline]
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff837a8182>]
      sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
      
      but task is already holding lock:
       (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>] spin_lock
      include/linux/spinlock.h:299 [inline]
       (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>]
      ip_expire+0x51/0x6c0 net/ipv4/ip_fragment.c:201
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&(&q->lock)->rlock){+.-...}:
             validate_chain kernel/locking/lockdep.c:2267 [inline]
             __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
             lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
             __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
             _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
             spin_lock include/linux/spinlock.h:299 [inline]
             ip_defrag+0x3a2/0x4130 net/ipv4/ip_fragment.c:669
             ip_check_defrag+0x4e3/0x8b0 net/ipv4/ip_fragment.c:713
             packet_rcv_fanout+0x282/0x800 net/packet/af_packet.c:1459
             deliver_skb net/core/dev.c:1834 [inline]
             dev_queue_xmit_nit+0x294/0xa90 net/core/dev.c:1890
             xmit_one net/core/dev.c:2903 [inline]
             dev_hard_start_xmit+0x16b/0xab0 net/core/dev.c:2923
             sch_direct_xmit+0x31f/0x6d0 net/sched/sch_generic.c:182
             __dev_xmit_skb net/core/dev.c:3092 [inline]
             __dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
             dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
             neigh_resolve_output+0x6b9/0xb10 net/core/neighbour.c:1308
             neigh_output include/net/neighbour.h:478 [inline]
             ip_finish_output2+0x8b8/0x15a0 net/ipv4/ip_output.c:228
             ip_do_fragment+0x1d93/0x2720 net/ipv4/ip_output.c:672
             ip_fragment.constprop.54+0x145/0x200 net/ipv4/ip_output.c:545
             ip_finish_output+0x82d/0xe10 net/ipv4/ip_output.c:314
             NF_HOOK_COND include/linux/netfilter.h:246 [inline]
             ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
             dst_output include/net/dst.h:486 [inline]
             ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
             ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
             ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
             raw_sendmsg+0x26de/0x3a00 net/ipv4/raw.c:655
             inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:761
             sock_sendmsg_nosec net/socket.c:633 [inline]
             sock_sendmsg+0xca/0x110 net/socket.c:643
             ___sys_sendmsg+0x4a3/0x9f0 net/socket.c:1985
             __sys_sendmmsg+0x25c/0x750 net/socket.c:2075
             SYSC_sendmmsg net/socket.c:2106 [inline]
             SyS_sendmmsg+0x35/0x60 net/socket.c:2101
             do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
             return_from_SYSCALL_64+0x0/0x7a
      
      -> #0 (_xmit_ETHER#2){+.-...}:
             check_prev_add kernel/locking/lockdep.c:1830 [inline]
             check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
             validate_chain kernel/locking/lockdep.c:2267 [inline]
             __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
             lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
             __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
             _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
             spin_lock include/linux/spinlock.h:299 [inline]
             __netif_tx_lock include/linux/netdevice.h:3486 [inline]
             sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
             __dev_xmit_skb net/core/dev.c:3092 [inline]
             __dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
             dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
             neigh_hh_output include/net/neighbour.h:468 [inline]
             neigh_output include/net/neighbour.h:476 [inline]
             ip_finish_output2+0xf6c/0x15a0 net/ipv4/ip_output.c:228
             ip_finish_output+0xa29/0xe10 net/ipv4/ip_output.c:316
             NF_HOOK_COND include/linux/netfilter.h:246 [inline]
             ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
             dst_output include/net/dst.h:486 [inline]
             ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
             ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
             ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
             icmp_push_reply+0x372/0x4d0 net/ipv4/icmp.c:394
             icmp_send+0x156c/0x1c80 net/ipv4/icmp.c:754
             ip_expire+0x40e/0x6c0 net/ipv4/ip_fragment.c:239
             call_timer_fn+0x241/0x820 kernel/time/timer.c:1268
             expire_timers kernel/time/timer.c:1307 [inline]
             __run_timers+0x960/0xcf0 kernel/time/timer.c:1601
             run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
             __do_softirq+0x31f/0xbe7 kernel/softirq.c:284
             invoke_softirq kernel/softirq.c:364 [inline]
             irq_exit+0x1cc/0x200 kernel/softirq.c:405
             exiting_irq arch/x86/include/asm/apic.h:657 [inline]
             smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
             apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:707
             __read_once_size include/linux/compiler.h:254 [inline]
             atomic_read arch/x86/include/asm/atomic.h:26 [inline]
             rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:350 [inline]
             __rcu_is_watching kernel/rcu/tree.c:1133 [inline]
             rcu_is_watching+0x83/0x110 kernel/rcu/tree.c:1147
             rcu_read_lock_held+0x87/0xc0 kernel/rcu/update.c:293
             radix_tree_deref_slot include/linux/radix-tree.h:238 [inline]
             filemap_map_pages+0x6d4/0x1570 mm/filemap.c:2335
             do_fault_around mm/memory.c:3231 [inline]
             do_read_fault mm/memory.c:3265 [inline]
             do_fault+0xbd5/0x2080 mm/memory.c:3370
             handle_pte_fault mm/memory.c:3600 [inline]
             __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3714
             handle_mm_fault+0x1e2/0x480 mm/memory.c:3751
             __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1397
             do_page_fault+0x54/0x70 arch/x86/mm/fault.c:1460
             page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1011
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&q->lock)->rlock);
                                     lock(_xmit_ETHER#2);
                                     lock(&(&q->lock)->rlock);
        lock(_xmit_ETHER#2);
      
       *** DEADLOCK ***
      
      10 locks held by modprobe/12392:
       #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff81329758>]
      __do_page_fault+0x2b8/0xb60 arch/x86/mm/fault.c:1336
       #1:  (rcu_read_lock){......}, at: [<ffffffff8188cab6>]
      filemap_map_pages+0x1e6/0x1570 mm/filemap.c:2324
       #2:  (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
      spin_lock include/linux/spinlock.h:299 [inline]
       #2:  (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
      pte_alloc_one_map mm/memory.c:2944 [inline]
       #2:  (&(ptlock_ptr(page))->rlock#2){+.+...}, at: [<ffffffff81984a78>]
      alloc_set_pte+0x13b8/0x1b90 mm/memory.c:3072
       #3:  (((&q->timer))){+.-...}, at: [<ffffffff81627e72>]
      lockdep_copy_map include/linux/lockdep.h:175 [inline]
       #3:  (((&q->timer))){+.-...}, at: [<ffffffff81627e72>]
      call_timer_fn+0x1c2/0x820 kernel/time/timer.c:1258
       #4:  (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>] spin_lock
      include/linux/spinlock.h:299 [inline]
       #4:  (&(&q->lock)->rlock){+.-...}, at: [<ffffffff8389a4d1>]
      ip_expire+0x51/0x6c0 net/ipv4/ip_fragment.c:201
       #5:  (rcu_read_lock){......}, at: [<ffffffff8389a633>]
      ip_expire+0x1b3/0x6c0 net/ipv4/ip_fragment.c:216
       #6:  (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>] spin_trylock
      include/linux/spinlock.h:309 [inline]
       #6:  (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>] icmp_xmit_lock
      net/ipv4/icmp.c:219 [inline]
       #6:  (slock-AF_INET){+.-...}, at: [<ffffffff839b3313>]
      icmp_send+0x803/0x1c80 net/ipv4/icmp.c:681
       #7:  (rcu_read_lock_bh){......}, at: [<ffffffff838ab9a1>]
      ip_finish_output2+0x2c1/0x15a0 net/ipv4/ip_output.c:198
       #8:  (rcu_read_lock_bh){......}, at: [<ffffffff836d1dee>]
      __dev_queue_xmit+0x23e/0x1e60 net/core/dev.c:3324
       #9:  (dev->qdisc_running_key ?: &qdisc_running_key){+.....}, at:
      [<ffffffff836d3a27>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
      
      stack backtrace:
      CPU: 0 PID: 12392 Comm: modprobe Not tainted 4.10.0+ #29
      Hardware name: Google Google Compute Engine/Google Compute Engine,
      BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
       print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
       check_prev_add kernel/locking/lockdep.c:1830 [inline]
       check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
       validate_chain kernel/locking/lockdep.c:2267 [inline]
       __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
       lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
       __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
       _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
       spin_lock include/linux/spinlock.h:299 [inline]
       __netif_tx_lock include/linux/netdevice.h:3486 [inline]
       sch_direct_xmit+0x282/0x6d0 net/sched/sch_generic.c:180
       __dev_xmit_skb net/core/dev.c:3092 [inline]
       __dev_queue_xmit+0x13e5/0x1e60 net/core/dev.c:3358
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3423
       neigh_hh_output include/net/neighbour.h:468 [inline]
       neigh_output include/net/neighbour.h:476 [inline]
       ip_finish_output2+0xf6c/0x15a0 net/ipv4/ip_output.c:228
       ip_finish_output+0xa29/0xe10 net/ipv4/ip_output.c:316
       NF_HOOK_COND include/linux/netfilter.h:246 [inline]
       ip_output+0x1f0/0x7a0 net/ipv4/ip_output.c:404
       dst_output include/net/dst.h:486 [inline]
       ip_local_out+0x95/0x170 net/ipv4/ip_output.c:124
       ip_send_skb+0x3c/0xc0 net/ipv4/ip_output.c:1492
       ip_push_pending_frames+0x64/0x80 net/ipv4/ip_output.c:1512
       icmp_push_reply+0x372/0x4d0 net/ipv4/icmp.c:394
       icmp_send+0x156c/0x1c80 net/ipv4/icmp.c:754
       ip_expire+0x40e/0x6c0 net/ipv4/ip_fragment.c:239
       call_timer_fn+0x241/0x820 kernel/time/timer.c:1268
       expire_timers kernel/time/timer.c:1307 [inline]
       __run_timers+0x960/0xcf0 kernel/time/timer.c:1601
       run_timer_softirq+0x21/0x80 kernel/time/timer.c:1614
       __do_softirq+0x31f/0xbe7 kernel/softirq.c:284
       invoke_softirq kernel/softirq.c:364 [inline]
       irq_exit+0x1cc/0x200 kernel/softirq.c:405
       exiting_irq arch/x86/include/asm/apic.h:657 [inline]
       smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
       apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:707
      RIP: 0010:__read_once_size include/linux/compiler.h:254 [inline]
      RIP: 0010:atomic_read arch/x86/include/asm/atomic.h:26 [inline]
      RIP: 0010:rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:350 [inline]
      RIP: 0010:__rcu_is_watching kernel/rcu/tree.c:1133 [inline]
      RIP: 0010:rcu_is_watching+0x83/0x110 kernel/rcu/tree.c:1147
      RSP: 0000:ffff8801c391f120 EFLAGS: 00000a03 ORIG_RAX: ffffffffffffff10
      RAX: dffffc0000000000 RBX: ffff8801c391f148 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 000055edd4374000 RDI: ffff8801dbe1ae0c
      RBP: ffff8801c391f1a0 R08: 0000000000000002 R09: 0000000000000000
      R10: dffffc0000000000 R11: 0000000000000002 R12: 1ffff10038723e25
      R13: ffff8801dbe1ae00 R14: ffff8801c391f680 R15: dffffc0000000000
       </IRQ>
       rcu_read_lock_held+0x87/0xc0 kernel/rcu/update.c:293
       radix_tree_deref_slot include/linux/radix-tree.h:238 [inline]
       filemap_map_pages+0x6d4/0x1570 mm/filemap.c:2335
       do_fault_around mm/memory.c:3231 [inline]
       do_read_fault mm/memory.c:3265 [inline]
       do_fault+0xbd5/0x2080 mm/memory.c:3370
       handle_pte_fault mm/memory.c:3600 [inline]
       __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3714
       handle_mm_fault+0x1e2/0x480 mm/memory.c:3751
       __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1397
       do_page_fault+0x54/0x70 arch/x86/mm/fault.c:1460
       page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1011
      RIP: 0033:0x7f83172f2786
      RSP: 002b:00007fffe859ae80 EFLAGS: 00010293
      RAX: 000055edd4373040 RBX: 00007f83175111c8 RCX: 000055edd4373238
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007f8317510970
      RBP: 00007fffe859afd0 R08: 0000000000000009 R09: 0000000000000000
      R10: 0000000000000064 R11: 0000000000000000 R12: 000055edd4373040
      R13: 0000000000000000 R14: 00007fffe859afe8 R15: 0000000000000000
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec4fbd64
  24. 28 4月, 2016 1 次提交