1. 02 Feb, 2017 7 commits
    • Omar Sandoval's avatar
      debugfs: add debugfs_lookup() · a7c5437b
      Omar Sandoval authored
      We don't always have easy access to the dentry of a file or directory we
      created in debugfs. Add a helper which allows us to get a dentry we
      previously created.
      
      The motivation for this change is a problem with blktrace and the blk-mq
      debugfs entries introduced in 07e4fead ("blk-mq: create debugfs
      directory tree"). Namely, in some cases, the directory that blktrace
      needs to create may already exist, but in other cases, it may not. We
      _could_ rely on a bunch of implied knowledge to decide whether to create
      the directory or not, but it's much cleaner on our end to just look it
      up.
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a7c5437b
    • Dan Williams's avatar
      scsi, block: fix duplicate bdi name registration crashes · 0dba1314
      Dan Williams authored
      Warnings of the following form occur because scsi reuses a devt number
      while the block layer still has it referenced as the name of the bdi
      [1]:
      
       WARNING: CPU: 1 PID: 93 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
       sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:192'
       [..]
       Call Trace:
        dump_stack+0x86/0xc3
        __warn+0xcb/0xf0
        warn_slowpath_fmt+0x5f/0x80
        ? kernfs_path_from_node+0x4f/0x60
        sysfs_warn_dup+0x62/0x80
        sysfs_create_dir_ns+0x77/0x90
        kobject_add_internal+0xb2/0x350
        kobject_add+0x75/0xd0
        device_add+0x15a/0x650
        device_create_groups_vargs+0xe0/0xf0
        device_create_vargs+0x1c/0x20
        bdi_register+0x90/0x240
        ? lockdep_init_map+0x57/0x200
        bdi_register_owner+0x36/0x60
        device_add_disk+0x1bb/0x4e0
        ? __pm_runtime_use_autosuspend+0x5c/0x70
        sd_probe_async+0x10d/0x1c0
        async_run_entry_fn+0x39/0x170
      
      This is a brute-force fix to pass the devt release information from
      sd_probe() to the locations where we register the bdi,
      device_add_disk(), and unregister the bdi, blk_cleanup_queue().
      
      Thanks to Omar for the quick reproducer script [2]. This patch survives
      where an unmodified kernel fails in a few seconds.
      
      [1]: https://marc.info/?l=linux-scsi&m=147116857810716&w=4
      [2]: http://marc.info/?l=linux-block&m=148554717109098&w=2
      
      Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
      Cc: Bart Van Assche <bart.vanassche@sandisk.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Jan Kara <jack@suse.cz>
      Reported-by: default avatarOmar Sandoval <osandov@osandov.com>
      Tested-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      0dba1314
    • Jan Kara's avatar
      block: Get rid of blk_get_backing_dev_info() · efa7c9f9
      Jan Kara authored
      blk_get_backing_dev_info() is now a simple dereference. Remove that
      function and simplify some code around that.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      efa7c9f9
    • Jan Kara's avatar
      block: Make blk_get_backing_dev_info() safe without open bdev · b1d2dc56
      Jan Kara authored
      Currenly blk_get_backing_dev_info() is not safe to be called when the
      block device is not open as bdev->bd_disk is NULL in that case. However
      inode_to_bdi() uses this function and may be call called from flusher
      worker or other writeback related functions without bdev being open
      which leads to crashes such as:
      
      [113031.075540] Unable to handle kernel paging request for data at address 0x00000000
      [113031.075614] Faulting instruction address: 0xc0000000003692e0
      0:mon> t
      [c0000000fb65f900] c00000000036cb6c writeback_sb_inodes+0x30c/0x590
      [c0000000fb65fa10] c00000000036ced4 __writeback_inodes_wb+0xe4/0x150
      [c0000000fb65fa70] c00000000036d33c wb_writeback+0x30c/0x450
      [c0000000fb65fb40] c00000000036e198 wb_workfn+0x268/0x580
      [c0000000fb65fc50] c0000000000f3470 process_one_work+0x1e0/0x590
      [c0000000fb65fce0] c0000000000f38c8 worker_thread+0xa8/0x660
      [c0000000fb65fd80] c0000000000fc4b0 kthread+0x110/0x130
      [c0000000fb65fe30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      b1d2dc56
    • Jan Kara's avatar
      block: Dynamically allocate and refcount backing_dev_info · d03f6cdc
      Jan Kara authored
      Instead of storing backing_dev_info inside struct request_queue,
      allocate it dynamically, reference count it, and free it when the last
      reference is dropped. Currently only request_queue holds the reference
      but in the following patch we add other users referencing
      backing_dev_info.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      d03f6cdc
    • Jan Kara's avatar
      block: Use pointer to backing_dev_info from request_queue · dc3b17cc
      Jan Kara authored
      We will want to have struct backing_dev_info allocated separately from
      struct request_queue. As the first step add pointer to backing_dev_info
      to request_queue and convert all users touching it. No functional
      changes in this patch.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      dc3b17cc
    • Jan Kara's avatar
      block: Unhash block device inodes on gendisk destruction · f44f1ab5
      Jan Kara authored
      Currently, block device inodes stay around after corresponding gendisk
      hash died until memory reclaim finds them and frees them. Since we will
      make block device inode pin the bdi, we want to free the block device
      inode as soon as the device goes away so that bdi does not stay around
      unnecessarily. Furthermore we need to avoid issues when new device with
      the same major,minor pair gets created since reusing the bdi structure
      would be rather difficult in this case.
      
      Unhashing block device inode on gendisk destruction nicely deals with
      these problems. Once last block device inode reference is dropped (which
      may be directly in del_gendisk()), the inode gets evicted. Furthermore if
      the major,minor pair gets reallocated, we are guaranteed to get new
      block device inode even if old block device inode is not yet evicted and
      thus we avoid issues with possible reuse of bdi.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      f44f1ab5
  2. 01 Feb, 2017 6 commits
  3. 31 Jan, 2017 15 commits
  4. 30 Jan, 2017 2 commits
  5. 27 Jan, 2017 10 commits