1. 08 Jan, 2019 1 commit
  2. 02 Jan, 2019 1 commit
  3. 28 Dec, 2018 1 commit
  4. 19 Dec, 2018 1 commit
  5. 18 Dec, 2018 2 commits
  6. 05 Dec, 2018 6 commits
  7. 01 Nov, 2018 1 commit
  8. 18 Oct, 2018 1 commit
    • J. Bruce Fields's avatar
      sunrpc: safely reallow resvport min/max inversion · 826799e6
      J. Bruce Fields authored
      Commits ffb6ca33 and e08ea3a9 prevent setting xprt_min_resvport
      greater than xprt_max_resvport, but may also break simple code that sets
      one parameter then the other, if the new range does not overlap the old.
      
      Also it looks racy to me, unless there's some serialization I'm not
      seeing.  Granted it would probably require malicious privileged processes
      (unless there's a chance these might eventually be settable in unprivileged
      containers), but still it seems better not to let userspace panic the
      kernel.
      
      Simpler seems to be to allow setting the parameters to whatever you want
      but interpret xprt_min_resvport > xprt_max_resvport as the empty range.
      
      Fixes: ffb6ca33 "sunrpc: Prevent resvport min/max inversion..."
      Fixes: e08ea3a9 "sunrpc: Prevent rexvport min/max inversion..."
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      826799e6
  9. 02 Oct, 2018 2 commits
  10. 30 Sep, 2018 14 commits
  11. 31 Jul, 2018 1 commit
  12. 07 May, 2018 1 commit
  13. 10 Apr, 2018 2 commits
  14. 12 Feb, 2018 1 commit
    • Denys Vlasenko's avatar
      net: make getname() functions return length rather than use int* parameter · 9b2c45d4
      Denys Vlasenko authored
      Changes since v1:
      Added changes in these files:
          drivers/infiniband/hw/usnic/usnic_transport.c
          drivers/staging/lustre/lnet/lnet/lib-socket.c
          drivers/target/iscsi/iscsi_target_login.c
          drivers/vhost/net.c
          fs/dlm/lowcomms.c
          fs/ocfs2/cluster/tcp.c
          security/tomoyo/network.c
      
      Before:
      All these functions either return a negative error indicator,
      or store length of sockaddr into "int *socklen" parameter
      and return zero on success.
      
      "int *socklen" parameter is awkward. For example, if caller does not
      care, it still needs to provide on-stack storage for the value
      it does not need.
      
      None of the many FOO_getname() functions of various protocols
      ever used old value of *socklen. They always just overwrite it.
      
      This change drops this parameter, and makes all these functions, on success,
      return length of sockaddr. It's always >= 0 and can be differentiated
      from an error.
      
      Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
      
      rpc_sockname() lost "int buflen" parameter, since its only use was
      to be passed to kernel_getsockname() as &buflen and subsequently
      not used in any way.
      
      Userspace API is not changed.
      
          text    data     bss      dec     hex filename
      30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
      30108109 2633612  873672 33615393 200ee21 vmlinux.o
      Signed-off-by: default avatarDenys Vlasenko <dvlasenk@redhat.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: linux-kernel@vger.kernel.org
      CC: netdev@vger.kernel.org
      CC: linux-bluetooth@vger.kernel.org
      CC: linux-decnet-user@lists.sourceforge.net
      CC: linux-wireless@vger.kernel.org
      CC: linux-rdma@vger.kernel.org
      CC: linux-sctp@vger.kernel.org
      CC: linux-nfs@vger.kernel.org
      CC: linux-x25@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b2c45d4
  15. 09 Feb, 2018 1 commit
    • Trond Myklebust's avatar
      SUNRPC: Don't call __UDPX_INC_STATS() from a preemptible context · 0afa6b44
      Trond Myklebust authored
      Calling __UDPX_INC_STATS() from a preemptible context leads to a
      warning of the form:
      
       BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u5:0/31
       caller is xs_udp_data_receive_workfn+0x194/0x270
       CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1b #2
       Workqueue: xprtiod xs_udp_data_receive_workfn
       Call Trace:
        dump_stack+0x85/0xc1
        check_preemption_disabled+0xce/0xe0
        xs_udp_data_receive_workfn+0x194/0x270
        process_one_work+0x318/0x620
        worker_thread+0x20a/0x390
        ? process_one_work+0x620/0x620
        kthread+0x120/0x130
        ? __kthread_bind_mask+0x60/0x60
        ret_from_fork+0x24/0x30
      
      Since we're taking a spinlock in those functions anyway, let's fix the
      issue by moving the call so that it occurs under the spinlock.
      Reported-by: default avatarkernel test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      0afa6b44
  16. 06 Feb, 2018 1 commit
  17. 15 Jan, 2018 2 commits
  18. 30 Nov, 2017 1 commit