1. 30 Apr, 2020 2 commits
  2. 27 Apr, 2020 1 commit
    • Niklas Cassel's avatar
      nvme: prevent double free in nvme_alloc_ns() error handling · 132be623
      Niklas Cassel authored
      When jumping to the out_put_disk label, we will call put_disk(), which will
      trigger a call to disk_release(), which calls blk_put_queue().
      
      Later in the cleanup code, we do blk_cleanup_queue(), which will also call
      blk_put_queue().
      
      Putting the queue twice is incorrect, and will generate a KASAN splat.
      
      Set the disk->queue pointer to NULL, before calling put_disk(), so that the
      first call to blk_put_queue() will not free the queue.
      
      The second call to blk_put_queue() uses another pointer to the same queue,
      so this call will still free the queue.
      
      Fixes: 85136c01 ("lightnvm: simplify geometry enumeration")
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@wdc.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      132be623
  3. 23 Apr, 2020 2 commits
    • Damien Le Moal's avatar
      null_blk: Cleanup zoned device initialization · d205bde7
      Damien Le Moal authored
      Move all zoned mode related code from null_blk_main.c to
      null_blk_zoned.c, avoiding an ugly #ifdef in the process.
      Rename null_zone_init() into null_init_zoned_dev(), null_zone_exit()
      into null_free_zoned_dev() and add the new function
      null_register_zoned_dev() to finalize the zoned dev setup before
      add_disk().
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      d205bde7
    • Damien Le Moal's avatar
      null_blk: Fix zoned command handling · 9dd44c7e
      Damien Le Moal authored
      For write operations issued to a null_blk device with zoned mode
      enabled, the state and write pointer position of the zone targeted by
      the command should be checked before badblocks and memory backing
      are handled as the write may be first failed due to, for instance, a
      sector position not aligned with the zone write pointer. This order of
      checking for errors reflects more accuratly the behavior of physical
      zoned devices.
      
      Furthermore, the write pointer position of the target zone should be
      incremented only and only if no errors are reported by badblocks and
      memory backing handling.
      
      To fix this, introduce the small helper function null_process_cmd()
      which execute null_handle_badblocks() and null_handle_memory_backed()
      and use this function in null_zone_write() to correctly handle write
      requests to zoned null devices depending on the type and state of the
      write target zone. Also call this function in null_handle_zoned() to
      process read requests to zoned null devices.
      
      null_process_cmd() is called directly from null_handle_cmd() for
      regular null devices, resulting in no functional change for these type
      of devices. To have symmetric names, the function null_handle_zoned()
      is renamed to null_process_zoned_cmd().
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: default avatarChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      9dd44c7e
  4. 21 Apr, 2020 2 commits
  5. 20 Apr, 2020 1 commit
    • Douglas Anderson's avatar
      bdev: Reduce time holding bd_mutex in sync in blkdev_close() · b849dd84
      Douglas Anderson authored
      While trying to "dd" to the block device for a USB stick, I
      encountered a hung task warning (blocked for > 120 seconds).  I
      managed to come up with an easy way to reproduce this on my system
      (where /dev/sdb is the block device for my USB stick) with:
      
        while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done
      
      With my reproduction here are the relevant bits from the hung task
      detector:
      
       INFO: task udevd:294 blocked for more than 122 seconds.
       ...
       udevd           D    0   294      1 0x00400008
       Call trace:
        ...
        mutex_lock_nested+0x40/0x50
        __blkdev_get+0x7c/0x3d4
        blkdev_get+0x118/0x138
        blkdev_open+0x94/0xa8
        do_dentry_open+0x268/0x3a0
        vfs_open+0x34/0x40
        path_openat+0x39c/0xdf4
        do_filp_open+0x90/0x10c
        do_sys_open+0x150/0x3c8
        ...
      
       ...
       Showing all locks held in the system:
       ...
       1 lock held by dd/2798:
        #0: ffffff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204
       ...
       dd              D    0  2798   2764 0x00400208
       Call trace:
        ...
        schedule+0x8c/0xbc
        io_schedule+0x1c/0x40
        wait_on_page_bit_common+0x238/0x338
        __lock_page+0x5c/0x68
        write_cache_pages+0x194/0x500
        generic_writepages+0x64/0xa4
        blkdev_writepages+0x24/0x30
        do_writepages+0x48/0xa8
        __filemap_fdatawrite_range+0xac/0xd8
        filemap_write_and_wait+0x30/0x84
        __blkdev_put+0x88/0x204
        blkdev_put+0xc4/0xe4
        blkdev_close+0x28/0x38
        __fput+0xe0/0x238
        ____fput+0x1c/0x28
        task_work_run+0xb0/0xe4
        do_notify_resume+0xfc0/0x14bc
        work_pending+0x8/0x14
      
      The problem appears related to the fact that my USB disk is terribly
      slow and that I have a lot of RAM in my system to cache things.
      Specifically my writes seem to be happening at ~15 MB/s and I've got
      ~4 GB of RAM in my system that can be used for buffering.  To write 4
      GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
      
      The 267 second number is a problem because in __blkdev_put() we call
      sync_blockdev() while holding the bd_mutex.  Any other callers who
      want the bd_mutex will be blocked for the whole time.
      
      The problem is made worse because I believe blkdev_put() specifically
      tells other tasks (namely udev) to go try to access the device at right
      around the same time we're going to hold the mutex for a long time.
      
      Putting some traces around this (after disabling the hung task detector),
      I could confirm:
       dd:    437.608600: __blkdev_put() right before sync_blockdev() for sdb
       udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb
       dd:    661.468451: __blkdev_put() right after sync_blockdev() for sdb
       udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb
      
      A simple fix for this is to realize that sync_blockdev() works fine if
      you're not holding the mutex.  Also, it's not the end of the world if
      you sync a little early (though it can have performance impacts).
      Thus we can make a guess that we're going to need to do the sync and
      then do it without holding the mutex.  We still do one last sync with
      the mutex but it should be much, much faster.
      
      With this, my hung task warnings for my test case are gone.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      b849dd84
  6. 18 Apr, 2020 1 commit
  7. 17 Apr, 2020 28 commits
  8. 16 Apr, 2020 3 commits
    • Linus Torvalds's avatar
      Merge tag 'tag-chrome-platform-fixes-for-v5.7-rc2' of... · 2fcd8014
      Linus Torvalds authored
      Merge tag 'tag-chrome-platform-fixes-for-v5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
      
      Pull chrome-platform fixes from Benson Leung:
       "Two small fixes for cros_ec_sensorhub_ring.c, addressing issues
        introduced in the cros_ec_sensorhub FIFO support commit"
      
      * tag 'tag-chrome-platform-fixes-for-v5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
        platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages
        platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample()
      2fcd8014
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · c8372665
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Disable RISCV BPF JIT builds when !MMU, from Björn Töpel.
      
       2) nf_tables leaves dangling pointer after free, fix from Eric Dumazet.
      
       3) Out of boundary write in __xsk_rcv_memcpy(), fix from Li RongQing.
      
       4) Adjust icmp6 message source address selection when routes have a
          preferred source address set, from Tim Stallard.
      
       5) Be sure to validate HSR protocol version when creating new links,
          from Taehee Yoo.
      
       6) CAP_NET_ADMIN should be sufficient to manage l2tp tunnels even in
          non-initial namespaces, from Michael Weiß.
      
       7) Missing release firmware call in mlx5, from Eran Ben Elisha.
      
       8) Fix variable type in macsec_changelink(), caught by KASAN. Fix from
          Taehee Yoo.
      
       9) Fix pause frame negotiation in marvell phy driver, from Clemens
          Gruber.
      
      10) Record RX queue early enough in tun packet paths such that XDP
          programs will see the correct RX queue index, from Gilberto Bertin.
      
      11) Fix double unlock in mptcp, from Florian Westphal.
      
      12) Fix offset overflow in ARM bpf JIT, from Luke Nelson.
      
      13) marvell10g needs to soft reset PHY when coming out of low power
          mode, from Russell King.
      
      14) Fix MTU setting regression in stmmac for some chip types, from
          Florian Fainelli.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (101 commits)
        amd-xgbe: Use __napi_schedule() in BH context
        mISDN: make dmril and dmrim static
        net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes
        net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode
        tipc: fix incorrect increasing of link window
        Documentation: Fix tcp_challenge_ack_limit default value
        net: tulip: make early_486_chipsets static
        dt-bindings: net: ethernet-phy: add desciption for ethernet-phy-id1234.d400
        ipv6: remove redundant assignment to variable err
        net/rds: Use ERR_PTR for rds_message_alloc_sgs()
        net: mscc: ocelot: fix untagged packet drops when enslaving to vlan aware bridge
        selftests/bpf: Check for correct program attach/detach in xdp_attach test
        libbpf: Fix type of old_fd in bpf_xdp_set_link_opts
        libbpf: Always specify expected_attach_type on program load if supported
        xsk: Add missing check on user supplied headroom size
        mac80211: fix channel switch trigger from unknown mesh peer
        mac80211: fix race in ieee80211_register_hw()
        net: marvell10g: soft-reset the PHY when coming out of low power
        net: marvell10g: report firmware version
        net/cxgb4: Check the return from t4_query_params properly
        ...
      c8372665
    • Sebastian Andrzej Siewior's avatar
      amd-xgbe: Use __napi_schedule() in BH context · d518691c
      Sebastian Andrzej Siewior authored
      The driver uses __napi_schedule_irqoff() which is fine as long as it is
      invoked with disabled interrupts by everybody. Since the commit
      mentioned below the driver may invoke xgbe_isr_task() in tasklet/softirq
      context. This may lead to list corruption if another driver uses
      __napi_schedule_irqoff() in IRQ context.
      
      Use __napi_schedule() which safe to use from IRQ and softirq context.
      
      Fixes: 85b85c85 ("amd-xgbe: Re-issue interrupt if interrupt status not cleared")
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d518691c