1. 28 2月, 2017 1 次提交
  2. 25 2月, 2017 1 次提交
  3. 26 12月, 2016 1 次提交
    • T
      ktime: Get rid of the union · 2456e855
      Thomas Gleixner 提交于
      ktime is a union because the initial implementation stored the time in
      scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
      variant for 32bit machines. The Y2038 cleanup removed the timespec variant
      and switched everything to scalar nanoseconds. The union remained, but
      become completely pointless.
      
      Get rid of the union and just keep ktime_t as simple typedef of type s64.
      
      The conversion was done with coccinelle and some manual mopping up.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      2456e855
  4. 25 12月, 2016 1 次提交
  5. 14 11月, 2016 1 次提交
    • S
      sunrpc: svc_age_temp_xprts_now should not call setsockopt non-tcp transports · ea08e392
      Scott Mayhew 提交于
      This fixes the following panic that can occur with NFSoRDMA.
      
      general protection fault: 0000 [#1] SMP
      Modules linked in: rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi
      scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp
      scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm
      mlx5_ib ib_core intel_powerclamp coretemp kvm_intel kvm sg ioatdma
      ipmi_devintf ipmi_ssif dcdbas iTCO_wdt iTCO_vendor_support pcspkr
      irqbypass sb_edac shpchp dca crc32_pclmul ghash_clmulni_intel edac_core
      lpc_ich aesni_intel lrw gf128mul glue_helper ablk_helper mei_me mei
      ipmi_si cryptd wmi ipmi_msghandler acpi_pad acpi_power_meter nfsd
      auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod
      crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper
      syscopyarea sysfillrect sysimgblt ahci fb_sys_fops ttm libahci mlx5_core
      tg3 crct10dif_pclmul drm crct10dif_common
      ptp i2c_core libata crc32c_intel pps_core fjes dm_mirror dm_region_hash
      dm_log dm_mod
      CPU: 1 PID: 120 Comm: kworker/1:1 Not tainted 3.10.0-514.el7.x86_64 #1
      Hardware name: Dell Inc. PowerEdge R320/0KM5PX, BIOS 2.4.2 01/29/2015
      Workqueue: events check_lifetime
      task: ffff88031f506dd0 ti: ffff88031f584000 task.ti: ffff88031f584000
      RIP: 0010:[<ffffffff8168d847>]  [<ffffffff8168d847>]
      _raw_spin_lock_bh+0x17/0x50
      RSP: 0018:ffff88031f587ba8  EFLAGS: 00010206
      RAX: 0000000000020000 RBX: 20041fac02080072 RCX: ffff88031f587fd8
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 20041fac02080072
      RBP: ffff88031f587bb0 R08: 0000000000000008 R09: ffffffff8155be77
      R10: ffff880322a59b00 R11: ffffea000bf39f00 R12: 20041fac02080072
      R13: 000000000000000d R14: ffff8800c4fbd800 R15: 0000000000000001
      FS:  0000000000000000(0000) GS:ffff880322a40000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f3c52d4547e CR3: 00000000019ba000 CR4: 00000000001407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
      20041fac02080002 ffff88031f587bd0 ffffffff81557830 20041fac02080002
      ffff88031f587c78 ffff88031f587c40 ffffffff8155ae08 000000010157df32
      0000000800000001 ffff88031f587c20 ffffffff81096acb ffffffff81aa37d0
      Call Trace:
      [<ffffffff81557830>] lock_sock_nested+0x20/0x50
      [<ffffffff8155ae08>] sock_setsockopt+0x78/0x940
      [<ffffffff81096acb>] ? lock_timer_base.isra.33+0x2b/0x50
      [<ffffffff8155397d>] kernel_setsockopt+0x4d/0x50
      [<ffffffffa0386284>] svc_age_temp_xprts_now+0x174/0x1e0 [sunrpc]
      [<ffffffffa03b681d>] nfsd_inetaddr_event+0x9d/0xd0 [nfsd]
      [<ffffffff81691ebc>] notifier_call_chain+0x4c/0x70
      [<ffffffff810b687d>] __blocking_notifier_call_chain+0x4d/0x70
      [<ffffffff810b68b6>] blocking_notifier_call_chain+0x16/0x20
      [<ffffffff815e8538>] __inet_del_ifa+0x168/0x2d0
      [<ffffffff815e8cef>] check_lifetime+0x25f/0x270
      [<ffffffff810a7f3b>] process_one_work+0x17b/0x470
      [<ffffffff810a8d76>] worker_thread+0x126/0x410
      [<ffffffff810a8c50>] ? rescuer_thread+0x460/0x460
      [<ffffffff810b052f>] kthread+0xcf/0xe0
      [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
      [<ffffffff81696418>] ret_from_fork+0x58/0x90
      [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
      Code: ca 75 f1 5d c3 0f 1f 80 00 00 00 00 eb d9 66 0f 1f 44 00 00 0f 1f
      44 00 00 55 48 89 e5 53 48 89 fb e8 7e 04 a0 ff b8 00 00 02 00 <f0> 0f
      c1 03 89 c2 c1 ea 10 66 39 c2 75 03 5b 5d c3 83 e2 fe 0f
      RIP  [<ffffffff8168d847>] _raw_spin_lock_bh+0x17/0x50
      RSP <ffff88031f587ba8>
      Signed-off-by: NScott Mayhew <smayhew@redhat.com>
      Fixes: c3d4879e ("sunrpc: Add a function to close temporary transports immediately")
      Reviewed-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ea08e392
  6. 08 11月, 2016 1 次提交
    • P
      udp: do fwd memory scheduling on dequeue · 7c13f97f
      Paolo Abeni 提交于
      A new argument is added to __skb_recv_datagram to provide
      an explicit skb destructor, invoked under the receive queue
      lock.
      The UDP protocol uses such argument to perform memory
      reclaiming on dequeue, so that the UDP protocol does not
      set anymore skb->desctructor.
      Instead explicit memory reclaiming is performed at close() time and
      when skbs are removed from the receive queue.
      The in kernel UDP protocol users now need to call a
      skb_recv_udp() variant instead of skb_recv_datagram() to
      properly perform memory accounting on dequeue.
      
      Overall, this allows acquiring only once the receive queue
      lock on dequeue.
      
      Tested using pktgen with random src port, 64 bytes packet,
      wire-speed on a 10G link as sender and udp_sink as the receiver,
      using an l4 tuple rxhash to stress the contention, and one or more
      udp_sink instances with reuseport.
      
      nr sinks	vanilla		patched
      1		440		560
      3		2150		2300
      6		3650		3800
      9		4450		4600
      12		6250		6450
      
      v1 -> v2:
       - do rmem and allocated memory scheduling under the receive lock
       - do bulk scheduling in first_packet_length() and in udp_destruct_sock()
       - avoid the typdef for the dequeue callback
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c13f97f
  7. 23 10月, 2016 1 次提交
    • P
      udp: use it's own memory accounting schema · 850cbadd
      Paolo Abeni 提交于
      Completely avoid default sock memory accounting and replace it
      with udp-specific accounting.
      
      Since the new memory accounting model encapsulates completely
      the required locking, remove the socket lock on both enqueue and
      dequeue, and avoid using the backlog on enqueue.
      
      Be sure to clean-up rx queue memory on socket destruction, using
      udp its own sk_destruct.
      
      Tested using pktgen with random src port, 64 bytes packet,
      wire-speed on a 10G link as sender and udp_sink as the receiver,
      using an l4 tuple rxhash to stress the contention, and one or more
      udp_sink instances with reuseport.
      
      nr readers      Kpps (vanilla)  Kpps (patched)
      1               170             440
      3               1250            2150
      6               3000            3650
      9               4200            4450
      12              5700            6250
      
      v4 -> v5:
        - avoid unneeded test in first_packet_length
      
      v3 -> v4:
        - remove useless sk_rcvqueues_full() call
      
      v2 -> v3:
        - do not set the now unsed backlog_rcv callback
      
      v1 -> v2:
        - add memory pressure support
        - fixed dropwatch accounting for ipv6
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      850cbadd
  8. 02 8月, 2016 2 次提交
    • T
      SUNRPC: Detect immediate closure of accepted sockets · c7995f8a
      Trond Myklebust 提交于
      This modification is useful for debugging issues that happen while
      the socket is being initialised.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c7995f8a
    • T
      SUNRPC: accept() may return sockets that are still in SYN_RECV · b2f21f7d
      Trond Myklebust 提交于
      We're seeing traces of the following form:
      
       [10952.396347] svc: transport ffff88042ba4a 000 dequeued, inuse=2
       [10952.396351] svc: tcp_accept ffff88042ba4 a000 sock ffff88042a6e4c80
       [10952.396362] nfsd: connect from 10.2.6.1, port=187
       [10952.396364] svc: svc_setup_socket ffff8800b99bcf00
       [10952.396368] setting up TCP socket for reading
       [10952.396370] svc: svc_setup_socket created ffff8803eb10a000 (inet ffff88042b75b800)
       [10952.396373] svc: transport ffff8803eb10a000 put into queue
       [10952.396375] svc: transport ffff88042ba4a000 put into queue
       [10952.396377] svc: server ffff8800bb0ec000 waiting for data (to = 3600000)
       [10952.396380] svc: transport ffff8803eb10a000 dequeued, inuse=2
       [10952.396381] svc_recv: found XPT_CLOSE
       [10952.396397] svc: svc_delete_xprt(ffff8803eb10a000)
       [10952.396398] svc: svc_tcp_sock_detach(ffff8803eb10a000)
       [10952.396399] svc: svc_sock_detach(ffff8803eb10a000)
       [10952.396412] svc: svc_sock_free(ffff8803eb10a000)
      
      i.e. an immediate close of the socket after initialisation.
      
      The culprit appears to be the test at the end of svc_tcp_init, which
      checks if the newly created socket is in the TCP_ESTABLISHED state,
      and immediately closes it if not. The evidence appears to suggest that
      the socket might still be in the SYN_RECV state at this time.
      
      The fix is to check for both states, and then to add a check in
      svc_tcp_state_change() to ensure we don't close the socket when
      it transitions into TCP_ESTABLISHED.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b2f21f7d
  9. 14 7月, 2016 4 次提交
  10. 14 4月, 2016 1 次提交
  11. 12 4月, 2016 1 次提交
  12. 11 11月, 2015 1 次提交
  13. 10 11月, 2015 1 次提交
  14. 24 10月, 2015 1 次提交
  15. 12 4月, 2015 1 次提交
  16. 10 12月, 2014 1 次提交
  17. 20 11月, 2014 1 次提交
  18. 29 8月, 2014 1 次提交
  19. 18 8月, 2014 1 次提交
  20. 30 7月, 2014 2 次提交
  21. 18 7月, 2014 1 次提交
  22. 31 5月, 2014 1 次提交
  23. 23 5月, 2014 2 次提交
  24. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  25. 01 4月, 2014 1 次提交
    • S
      nfsd: check passed socket's net matches NFSd superblock's one · 30646394
      Stanislav Kinsbursky 提交于
      There could be a case, when NFSd file system is mounted in network, different
      to socket's one, like below:
      
      "ip netns exec" creates new network and mount namespace, which duplicates NFSd
      mount point, created in init_net context. And thus NFS server stop in nested
      network context leads to RPCBIND client destruction in init_net.
      Then, on NFSd start in nested network context, rpc.nfsd process creates socket
      in nested net and passes it into "write_ports", which leads to RPCBIND sockets
      creation in init_net context because of the same reason (NFSd monut point was
      created in init_net context). An attempt to register passed socket in nested
      net leads to panic, because no RPCBIND client present in nexted network
      namespace.
      
      This patch add check that passed socket's net matches NFSd superblock's one.
      And returns -EINVAL error to user psace otherwise.
      
      v2: Put socket on exit.
      Reported-by: NWeng Meiling <wengmeiling.weng@huawei.com>
      Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      30646394
  26. 10 10月, 2013 1 次提交
  27. 09 10月, 2013 1 次提交
    • E
      ipv6: make lookups simpler and faster · efe4208f
      Eric Dumazet 提交于
      TCP listener refactoring, part 4 :
      
      To speed up inet lookups, we moved IPv4 addresses from inet to struct
      sock_common
      
      Now is time to do the same for IPv6, because it permits us to have fast
      lookups for all kind of sockets, including upcoming SYN_RECV.
      
      Getting IPv6 addresses in TCP lookups currently requires two extra cache
      lines, plus a dereference (and memory stall).
      
      inet6_sk(sk) does the dereference of inet_sk(__sk)->pinet6
      
      This patch is way bigger than its IPv4 counter part, because for IPv4,
      we could add aliases (inet_daddr, inet_rcv_saddr), while on IPv6,
      it's not doable easily.
      
      inet6_sk(sk)->daddr becomes sk->sk_v6_daddr
      inet6_sk(sk)->rcv_saddr becomes sk->sk_v6_rcv_saddr
      
      And timewait socket also have tw->tw_v6_daddr & tw->tw_v6_rcv_saddr
      at the same offset.
      
      We get rid of INET6_TW_MATCH() as INET6_MATCH() is now the generic
      macro.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efe4208f
  28. 01 8月, 2013 1 次提交
    • N
      NFSD/sunrpc: avoid deadlock on TCP connection due to memory pressure. · 447383d2
      NeilBrown 提交于
      Since we enabled auto-tuning for sunrpc TCP connections we do not
      guarantee that there is enough write-space on each connection to
      queue a reply.
      
      If memory pressure causes the window to shrink too small, the request
      throttling in sunrpc/svc will not accept any requests so no more requests
      will be handled.  Even when pressure decreases the window will not
      grow again until data is sent on the connection.
      This means we get a deadlock:  no requests will be handled until there
      is more space, and no space will be allocated until a request is
      handled.
      
      This can be simulated by modifying svc_tcp_has_wspace to inflate the
      number of byte required and removing the 'svc_sock_setbufsize' calls
      in svc_setup_socket.
      
      I found that multiplying by 16 was enough to make the requirement
      exceed the default allocation.  With this modification in place:
         mount -o vers=3,proto=tcp 127.0.0.1:/home /mnt
      would block and eventually time out because the nfs server could not
      accept any requests.
      
      This patch relaxes the request throttling to always allow at least one
      request through per connection.  It does this by checking both
        sk_stream_min_wspace() and xprt->xpt_reserved
      are zero.
      The first is zero when the TCP transmit queue is empty.
      The second is zero when there are no RPC requests being processed.
      When both of these are zero the socket is idle and so one more
      request can safely be allowed through.
      
      Applying this patch allows the above mount command to succeed cleanly.
      Tracing shows that the allocated write buffer space quickly grows and
      after a few requests are handled, the extra tests are no longer needed
      to permit further requests to be processed.
      
      The main purpose of request throttling is to handle the case when one
      client is slow at collecting replies and the send queue gets full of
      replies that the client hasn't acknowledged (at the TCP level) yet.
      As we only change behaviour when the send queue is empty this main
      purpose is still preserved.
      Reported-by: NBen Myers <bpm@sgi.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      447383d2
  29. 25 7月, 2013 1 次提交
  30. 02 7月, 2013 2 次提交
    • J
      svcrpc: don't error out on small tcp fragment · 1f691b07
      J. Bruce Fields 提交于
      Though clients we care about mostly don't do this, it is possible for
      rpc requests to be sent in multiple fragments.  Here we have a sanity
      check to ensure that the final received rpc isn't too small--except that
      the number we're actually checking is the length of just the final
      fragment, not of the whole rpc.  So a perfectly legal rpc that's
      unluckily fragmented could cause the server to close the connection
      here.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      1f691b07
    • J
      svcrpc: fix handling of too-short rpc's · cf3aa02c
      J. Bruce Fields 提交于
      If we detect that an rpc is too short, we abort and close the
      connection.  Except, there's a bug here: we're leaving sk_datalen
      nonzero without leaving any pages in the sk_pages array.  The most
      likely result of the inconsistency is a subsequent crash in
      svc_tcp_clear_pages.
      
      Also demote the BUG_ON in svc_tcp_clear_pages to a WARN.
      
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      cf3aa02c
  31. 01 2月, 2013 1 次提交
  32. 18 12月, 2012 2 次提交
新手
引导
客服 返回
顶部