1. 10 Mar, 2020 5 commits
    • Jens Axboe's avatar
      io_uring: add IOSQE_BUFFER_SELECT support for IORING_OP_RECVMSG · 52de1fe1
      Jens Axboe authored
      Like IORING_OP_READV, this is limited to supporting just a single
      segment in the iovec passed in.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      52de1fe1
    • Jens Axboe's avatar
      net: abstract out normal and compat msghdr import · 0a384abf
      Jens Axboe authored
      This splits it into two parts, one that imports the message, and one
      that imports the iovec. This allows a caller to only do the first part,
      and import the iovec manually afterwards.
      
      No functional changes in this patch.
      Acked-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0a384abf
    • Jens Axboe's avatar
      io_uring: add IOSQE_BUFFER_SELECT support for IORING_OP_READV · 4d954c25
      Jens Axboe authored
      This adds support for the vectored read. This is limited to supporting
      just 1 segment in the iov, and is provided just for convenience for
      applications that use IORING_OP_READV already.
      
      The iov helpers will be used for IORING_OP_RECVMSG as well.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      4d954c25
    • Jens Axboe's avatar
      io_uring: support buffer selection for OP_READ and OP_RECV · bcda7baa
      Jens Axboe authored
      If a server process has tons of pending socket connections, generally
      it uses epoll to wait for activity. When the socket is ready for reading
      (or writing), the task can select a buffer and issue a recv/send on the
      given fd.
      
      Now that we have fast (non-async thread) support, a task can have tons
      of pending reads or writes pending. But that means they need buffers to
      back that data, and if the number of connections is high enough, having
      them preallocated for all possible connections is unfeasible.
      
      With IORING_OP_PROVIDE_BUFFERS, an application can register buffers to
      use for any request. The request then sets IOSQE_BUFFER_SELECT in the
      sqe, and a given group ID in sqe->buf_group. When the fd becomes ready,
      a free buffer from the specified group is selected. If none are
      available, the request is terminated with -ENOBUFS. If successful, the
      CQE on completion will contain the buffer ID chosen in the cqe->flags
      member, encoded as:
      
      	(buffer_id << IORING_CQE_BUFFER_SHIFT) | IORING_CQE_F_BUFFER;
      
      Once a buffer has been consumed by a request, it is no longer available
      and must be registered again with IORING_OP_PROVIDE_BUFFERS.
      
      Requests need to support this feature. For now, IORING_OP_READ and
      IORING_OP_RECV support it. This is checked on SQE submission, a CQE with
      res == -EOPNOTSUPP will be posted if attempted on unsupported requests.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bcda7baa
    • Jens Axboe's avatar
      io_uring: add IORING_OP_PROVIDE_BUFFERS · ddf0322d
      Jens Axboe authored
      IORING_OP_PROVIDE_BUFFERS uses the buffer registration infrastructure to
      support passing in an addr/len that is associated with a buffer ID and
      buffer group ID. The group ID is used to index and lookup the buffers,
      while the buffer ID can be used to notify the application which buffer
      in the group was used. The addr passed in is the starting buffer address,
      and length is each buffer length. A number of buffers to add with can be
      specified, in which case addr is incremented by length for each addition,
      and each buffer increments the buffer ID specified.
      
      No validation is done of the buffer ID. If the application provides
      buffers within the same group with identical buffer IDs, then it'll have
      a hard time telling which buffer ID was used. The only restriction is
      that the buffer ID can be a max of 16-bits in size, so USHRT_MAX is the
      maximum ID that can be used.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      ddf0322d
  2. 04 Mar, 2020 8 commits
  3. 03 Mar, 2020 1 commit
  4. 02 Mar, 2020 23 commits
  5. 01 Mar, 2020 3 commits
    • Linus Torvalds's avatar
      Linux 5.6-rc4 · 98d54f81
      Linus Torvalds authored
      98d54f81
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · e7086982
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Two more bug fixes (including a regression) for 5.6"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()
        jbd2: fix data races at struct journal_head
      e7086982
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f853ed90
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "More bugfixes, including a few remaining "make W=1" issues such as too
        large frame sizes on some configurations.
      
        On the ARM side, the compiler was messing up shadow stacks between EL1
        and EL2 code, which is easily fixed with __always_inline"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: VMX: check descriptor table exits on instruction emulation
        kvm: x86: Limit the number of "kvm: disabled by bios" messages
        KVM: x86: avoid useless copy of cpufreq policy
        KVM: allow disabling -Werror
        KVM: x86: allow compiling as non-module with W=1
        KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis
        KVM: Introduce pv check helpers
        KVM: let declaration of kvm_get_running_vcpus match implementation
        KVM: SVM: allocate AVIC data structures based on kvm_amd module parameter
        arm64: Ask the compiler to __always_inline functions used by KVM at HYP
        KVM: arm64: Define our own swab32() to avoid a uapi static inline
        KVM: arm64: Ask the compiler to __always_inline functions used at HYP
        kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe()
        KVM: arm/arm64: Fix up includes for trace.h
      f853ed90