1. 25 Oct, 2019 9 commits
    • Mike Christie's avatar
      nbd: verify socket is supported during setup · cf1b2326
      Mike Christie authored
      nbd requires socket families to support the shutdown method so the nbd
      recv workqueue can be woken up from its sock_recvmsg call. If the socket
      does not support the callout we will leave recv works running or get hangs
      later when the device or module is removed.
      
      This adds a check during socket connection/reconnection to make sure the
      socket being passed in supports the needed callout.
      
      Reported-by: syzbot+24c12fa8d218ed26011a@syzkaller.appspotmail.com
      Fixes: e9e006f5 ("nbd: fix max number of supported devs")
      Tested-by: default avatarRichard W.M. Jones <rjones@redhat.com>
      Signed-off-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      cf1b2326
    • Mark Brown's avatar
      ata: libahci_platform: Fix regulator_get_optional() misuse · 962399bb
      Mark Brown authored
      This driver is using regulator_get_optional() to handle all the supplies
      that it handles, and only ever enables and disables all supplies en masse
      without ever doing any other configuration of the device to handle missing
      power. These are clear signs that the API is being misused - it should only
      be used for supplies that may be physically absent from the system and in
      these cases the hardware usually needs different configuration if the
      supply is missing. Instead use normal regualtor_get(), if the supply is
      not described in DT then the framework will substitute a dummy regulator in
      so no special handling is needed by the consumer driver.
      
      In the case of the PHY regulator the handling in the driver is a hack to
      deal with integrated PHYs; the supplies are only optional in the sense
      that that there's some confusion in the code about where they're bound to.
      From a code point of view they function exactly as normal supplies so can
      be treated as such. It'd probably be better to model this by instantiating
      a PHY object for integrated PHYs.
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      962399bb
    • Josef Bacik's avatar
      nbd: handle racing with error'ed out commands · 7ce23e8e
      Josef Bacik authored
      We hit the following warning in production
      
      print_req_error: I/O error, dev nbd0, sector 7213934408 flags 80700
      ------------[ cut here ]------------
      refcount_t: underflow; use-after-free.
      WARNING: CPU: 25 PID: 32407 at lib/refcount.c:190 refcount_sub_and_test_checked+0x53/0x60
      Workqueue: knbd-recv recv_work [nbd]
      RIP: 0010:refcount_sub_and_test_checked+0x53/0x60
      Call Trace:
       blk_mq_free_request+0xb7/0xf0
       blk_mq_complete_request+0x62/0xf0
       recv_work+0x29/0xa1 [nbd]
       process_one_work+0x1f5/0x3f0
       worker_thread+0x2d/0x3d0
       ? rescuer_thread+0x340/0x340
       kthread+0x111/0x130
       ? kthread_create_on_node+0x60/0x60
       ret_from_fork+0x1f/0x30
      ---[ end trace b079c3c67f98bb7c ]---
      
      This was preceded by us timing out everything and shutting down the
      sockets for the device.  The problem is we had a request in the queue at
      the same time, so we completed the request twice.  This can actually
      happen in a lot of cases, we fail to get a ref on our config, we only
      have one connection and just error out the command, etc.
      
      Fix this by checking cmd->status in nbd_read_stat.  We only change this
      under the cmd->lock, so we are safe to check this here and see if we've
      already error'ed this command out, which would indicate that we've
      completed it as well.
      Reviewed-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      7ce23e8e
    • Josef Bacik's avatar
      nbd: protect cmd->status with cmd->lock · de6346ec
      Josef Bacik authored
      We already do this for the most part, except in timeout and clear_req.
      For the timeout case we take the lock after we grab a ref on the config,
      but that isn't really necessary because we're safe to touch the cmd at
      this point, so just move the order around.
      
      For the clear_req cause this is initiated by the user, so again is safe.
      Reviewed-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      de6346ec
    • Jens Axboe's avatar
      io_uring: fix bad inflight accounting for SETUP_IOPOLL|SETUP_SQTHREAD · 2b2ed975
      Jens Axboe authored
      We currently assume that submissions from the sqthread are successful,
      and if IO polling is enabled, we use that value for knowing how many
      completions to look for. But if we overflowed the CQ ring or some
      requests simply got errored and already completed, they won't be
      available for polling.
      
      For the case of IO polling and SQTHREAD usage, look at the pending
      poll list. If it ever hits empty then we know that we don't have
      anymore pollable requests inflight. For that case, simply reset
      the inflight count to zero.
      Reported-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Reviewed-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      2b2ed975
    • Jens Axboe's avatar
      io_uring: used cached copies of sq->dropped and cq->overflow · 498ccd9e
      Jens Axboe authored
      We currently use the ring values directly, but that can lead to issues
      if the application is malicious and changes these values on our behalf.
      Created in-kernel cached versions of them, and just overwrite the user
      side when we update them. This is similar to how we treat the sq/cq
      ring tail/head updates.
      Reported-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Reviewed-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      498ccd9e
    • Pavel Begunkov's avatar
      io_uring: Fix race for sqes with userspace · 935d1e45
      Pavel Begunkov authored
      io_ring_submit() finalises with
      1. io_commit_sqring(), which releases sqes to the userspace
      2. Then calls to io_queue_link_head(), accessing released head's sqe
      
      Reorder them.
      Signed-off-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      935d1e45
    • Pavel Begunkov's avatar
      io_uring: Fix broken links with offloading · fb5ccc98
      Pavel Begunkov authored
      io_sq_thread() processes sqes by 8 without considering links. As a
      result, links will be randomely subdivided.
      
      The easiest way to fix it is to call io_get_sqring() inside
      io_submit_sqes() as do io_ring_submit().
      
      Downsides:
      1. This removes optimisation of not grabbing mm_struct for fixed files
      2. It submitting all sqes in one go, without finer-grained sheduling
      with cq processing.
      Signed-off-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      fb5ccc98
    • Pavel Begunkov's avatar
      io_uring: Fix corrupted user_data · 84d55dc5
      Pavel Begunkov authored
      There is a bug, where failed linked requests are returned not with
      specified @user_data, but with garbage from a kernel stack.
      
      The reason is that io_fail_links() uses req->user_data, which is
      uninitialised when called from io_queue_sqe() on fail path.
      Signed-off-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      84d55dc5
  2. 24 Oct, 2019 3 commits
  3. 20 Oct, 2019 6 commits
  4. 19 Oct, 2019 22 commits