03 Oct, 2017

4 commits

  • Since the previous commit removed any case where grow_buffers()
    would return failure due to memory allocations, we can safely
    remove the case where we have to call free_more_memory() in
    this function.

    Since this is also the last user of free_more_memory(), kill
    it off completely.

    Reviewed-by: Nikolay Borisov
    Reviewed-by: Jan Kara
    Signed-off-by: Jens Axboe

    Jens Axboe
     
  • We currently use it for find_or_create_page(), which means that it
    cannot fail. Ensure we also pass in 'retry == true' to
    alloc_page_buffers(), which also ensure that it cannot fail.

    After this, there are no failure cases in grow_dev_page() that
    occur because of a failed memory allocation.

    Reviewed-by: Nikolay Borisov
    Reviewed-by: Jan Kara
    Signed-off-by: Jens Axboe

    Jens Axboe
     
  • Instead of adding weird retry logic in that function, utilize
    __GFP_NOFAIL to ensure that the vm takes care of handling any
    potential retries appropriately. This means we don't have to
    call free_more_memory() from here.

    Reviewed-by: Nikolay Borisov
    Reviewed-by: Jan Kara
    Signed-off-by: Jens Axboe

    Jens Axboe
     
  • For some reason, the laptop mode IO completion notified was never wired
    up for blk-mq. Ensure that we trigger the callback appropriately, to arm
    the laptop mode flush timer.

    Reviewed-by: Christoph Hellwig
    Reviewed-by: Bart Van Assche
    Signed-off-by: Jens Axboe

    Jens Axboe
     

01 Oct, 2017

1 commit


30 Sep, 2017

2 commits


27 Sep, 2017

1 commit

  • The code is only for blkcg not for all cgroups

    Fixes: d4478e92d618 ("block/loop: make loop cgroup aware")
    Reported-by: kbuild test robot
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     

26 Sep, 2017

20 commits

  • This patch fix the following build warning:
    drivers/block/cryptoloop.c:46:8: warning: variable 'cipher' set but not used [-Wunused-but-set-variable]

    Signed-off-by: Corentin Labbe
    Signed-off-by: Jens Axboe

    Corentin Labbe
     
  • loop block device handles IO in a separate thread. The actual IO
    dispatched isn't cloned from the IO loop device received, so the
    dispatched IO loses the cgroup context.

    I'm ignoring buffer IO case now, which is quite complicated. Making the
    loop thread aware cgroup context doesn't really help. The loop device
    only writes to a single file. In current writeback cgroup
    implementation, the file can only belong to one cgroup.

    For direct IO case, we could workaround the issue in theory. For
    example, say we assign cgroup1 5M/s BW for loop device and cgroup2
    10M/s. We can create a special cgroup for loop thread and assign at
    least 15M/s for the underlayer disk. In this way, we correctly throttle
    the two cgroups. But this is tricky to setup.

    This patch tries to address the issue. We record bio's css in loop
    command. When loop thread is handling the command, we then use the API
    provided in patch 1 to set the css for current task. The bio layer will
    use the css for new IO (from patch 3).

    Acked-by: Tejun Heo
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     
  • bio_blkcg is the only API to get cgroup info for a bio right now. If
    bio_blkcg finds current task is a kthread and has original blkcg
    associated, it will use the css instead of associating the bio to
    current task. This makes it possible that kthread dispatches bios on
    behalf of other threads.

    Acked-by: Tejun Heo
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     
  • Nobody uses the APIs right now.

    Acked-by: Tejun Heo
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     
  • kthread usually runs jobs on behalf of other threads. The jobs should be
    charged to cgroup of original threads. But the jobs run in a kthread,
    where we lose the cgroup context of original threads. The patch adds a
    machanism to record cgroup info of original threads in kthread context.
    Later we can retrieve the cgroup info and attach the cgroup info to jobs.

    Since this mechanism is only required by kthread, we store the cgroup
    info in kthread data instead of generic task_struct.

    Acked-by: Tejun Heo
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     
  • Pull compat fix from Al Viro:
    "I really wish gcc warned about conversions from pointer to function
    into void *..."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    fix a typo in put_compat_shm_info()

    Linus Torvalds
     
  • "uip" misspelled as "up"; unfortunately, the latter happens to be
    a function and gcc is happy to convert it to void *...

    Signed-off-by: Al Viro

    Al Viro
     
  • Pull block fixes from Jens Axboe:

    - Two sets of NVMe pull requests from Christoph:
    - Fixes for the Fibre Channel host/target to fix spec compliance
    - Allow a zero keep alive timeout
    - Make the debug printk for broken SGLs work better
    - Fix queue zeroing during initialization
    - Set of RDMA and FC fixes
    - Target div-by-zero fix

    - bsg double-free fix.

    - ndb unknown ioctl fix from Josef.

    - Buffered vs O_DIRECT page cache inconsistency fix. Has been floating
    around for a long time, well reviewed. From Lukas.

    - brd overflow fix from Mikulas.

    - Fix for a loop regression in this merge window, where using a union
    for two members of the loop_cmd turned out to be a really bad idea.
    From Omar.

    - Fix for an iostat regression fix in this series, using the wrong API
    to get at the block queue. From Shaohua.

    - Fix for a potential blktrace delection deadlock. From Waiman.

    * 'for-linus' of git://git.kernel.dk/linux-block: (30 commits)
    nvme-fcloop: fix port deletes and callbacks
    nvmet-fc: sync header templates with comments
    nvmet-fc: ensure target queue id within range.
    nvmet-fc: on port remove call put outside lock
    nvme-rdma: don't fully stop the controller in error recovery
    nvme-rdma: give up reconnect if state change fails
    nvme-core: Use nvme_wq to queue async events and fw activation
    nvme: fix sqhd reference when admin queue connect fails
    block: fix a crash caused by wrong API
    fs: Fix page cache inconsistency when mixing buffered and AIO DIO
    nvmet: implement valid sqhd values in completions
    nvme-fabrics: Allow 0 as KATO value
    nvme: allow timed-out ios to retry
    nvme: stop aer posting if controller state not live
    nvme-pci: Print invalid SGL only once
    nvme-pci: initialize queue memory before interrupts
    nvmet-fc: fix failing max io queue connections
    nvme-fc: use transport-specific sgl format
    nvme: add transport SGL definitions
    nvme.h: remove FC transport-specific error values
    ...

    Linus Torvalds
     
  • Pull gfs2 fix from Bob Peterson:
    "GFS2: Fix an old regression in GFS2's debugfs interface

    This fixes a regression introduced by commit 88ffbf3e037e ("GFS2: Use
    resizable hash table for glocks"). The regression caused the glock dump
    in debugfs to not report all the glocks, which makes debugging
    extremely difficult"

    * tag 'gfs2-for-linus-4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
    gfs2: Fix debugfs glocks dump

    Linus Torvalds
     
  • Pull Microblaze fixes from Michal Simek:

    - Kbuild fix

    - use vma_pages

    - setup default little endians

    * tag 'microblaze-4.14-rc3' of git://git.monstr.eu/linux-2.6-microblaze:
    arch: change default endian for microblaze
    microblaze: Cocci spatch "vma_pages"
    microblaze: Add missing kvm_para.h to Kbuild

    Linus Torvalds
     
  • Pull tracing fixes from Steven Rostedt:
    "Stack tracing and RCU has been having issues with each other and
    lockdep has been pointing out constant problems.

    The changes have been going into the stack tracer, but it has been
    discovered that the problem isn't with the stack tracer itself, but it
    is with calling save_stack_trace() from within the internals of RCU.

    The stack tracer is the one that can trigger the issue the easiest,
    but examining the problem further, it could also happen from a WARN()
    in the wrong place, or even if an NMI happened in this area and it did
    an rcu_read_lock().

    The critical area is where RCU is not watching. Which can happen while
    going to and from idle, or bringing up or taking down a CPU.

    The final fix was to put the protection in kernel_text_address() as it
    is the one that requires RCU to be watching while doing the stack
    trace.

    To make this work properly, Paul had to allow rcu_irq_enter() happen
    after rcu_nmi_enter(). This should have been done anyway, since an NMI
    can page fault (reading vmalloc area), and a page fault triggers
    rcu_irq_enter().

    One patch is just a consolidation of code so that the fix only needed
    to be done in one location"

    * tag 'trace-v4.14-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
    tracing: Remove RCU work arounds from stack tracer
    extable: Enable RCU if it is not watching in kernel_text_address()
    extable: Consolidate *kernel_text_address() functions
    rcu: Allow for page faults in NMI handlers

    Linus Torvalds
     
  • Now that there are potentially long delays between when a remoteport or
    targetport delete calls is made and when the callback occurs (dev_loss_tmo
    timeout), no longer block in the delete routines and move the final nport
    puts to the callbacks.

    Moved the fcloop_nport_get/put/free routines to avoid forward declarations.

    Ensure port_info structs used in registrations are nulled in case fields
    are not set (ex: devloss_tmo values).

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • Comments were incorrect:
    - defer_rcv was in host port template. moved to target port template
    - Added Mandatory statements for target port template items

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • When searching for queue id's ensure they are within the expected range.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • Avoid calling the put routine, as it may traverse to free routines while
    holding the target lock.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • By calling nvme_stop_ctrl on a already failed controller will wait for the
    scan work to complete (only by identify timeout expiration which is 60
    seconds). This is unnecessary when we already know that the controller has
    failed.

    Reported-by: Yi Zhang
    Signed-off-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Sagi Grimberg
     
  • If we failed to transition to state LIVE after a successful reconnect,
    then controller deletion already started. In this case there is no
    point moving forward with reconnect.

    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Sagi Grimberg
     
  • async_event_work might race as it is executed from two different
    workqueues at the moment.

    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Sagi Grimberg
     
  • Fix bug in sqhd patch.

    It wasn't the sq that was at risk. In the case where the admin queue
    connect command fails, the sq->size field is not set. Therefore, this
    becomes a divide by zero error.

    Add a quick check to bypass under this failure condition.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • The switch to rhashtables (commit 88ffbf3e03) broke the debugfs glock
    dump (/sys/kernel/debug/gfs2//glocks) for dumps bigger than a
    single buffer: the right function for restarting an rhashtable iteration
    from the beginning of the hash table is rhashtable_walk_enter;
    rhashtable_walk_stop + rhashtable_walk_start will just resume from the
    current position.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Bob Peterson
    Cc: stable@vger.kernel.org # v4.3+

    Andreas Gruenbacher
     

25 Sep, 2017

12 commits

  • part_stat_show takes a part device not a disk, so we should use
    part_to_disk.

    Fixes: d62e26b3ffd2("block: pass in queue to inflight accounting")
    Cc: Bart Van Assche
    Cc: Omar Sandoval
    Signed-off-by: Shaohua Li
    Signed-off-by: Jens Axboe

    Shaohua Li
     
  • Currently when mixing buffered reads and asynchronous direct writes it
    is possible to end up with the situation where we have stale data in the
    page cache while the new data is already written to disk. This is
    permanent until the affected pages are flushed away. Despite the fact
    that mixing buffered and direct IO is ill-advised it does pose a thread
    for a data integrity, is unexpected and should be fixed.

    Fix this by deferring completion of asynchronous direct writes to a
    process context in the case that there are mapped pages to be found in
    the inode. Later before the completion in dio_complete() invalidate
    the pages in question. This ensures that after the completion the pages
    in the written area are either unmapped, or populated with up-to-date
    data. Also do the same for the iomap case which uses
    iomap_dio_complete() instead.

    This has a side effect of deferring the completion to a process context
    for every AIO DIO that happens on inode that has pages mapped. However
    since the consensus is that this is ill-advised practice the performance
    implication should not be a problem.

    This was based on proposal from Jeff Moyer, thanks!

    Reviewed-by: Jan Kara
    Reviewed-by: Darrick J. Wong
    Reviewed-by: Jeff Moyer
    Signed-off-by: Lukas Czerner
    Signed-off-by: Jens Axboe

    Lukas Czerner
     
  • To support sqhd, for initiators that are following the spec and
    paying attention to sqhd vs their sqtail values:

    - add sqhd to struct nvmet_sq
    - initialize sqhd to 0 in nvmet_sq_setup
    - rather than propagate the 0's-based qsize value from the connect message
    which requires a +1 in every sqhd update, and as nothing else references
    it, convert to 1's-based value in nvmt_sq/cq_setup() calls.
    - validate connect message sqsize being non-zero per spec.
    - updated assign sqhd for every completion that goes back.

    Also remove handling the NULL sq case in __nvmet_req_complete, as it can't
    happen with the current code.

    Signed-off-by: James Smart
    Reviewed-by: Sagi Grimberg
    Reviewed-by: Max Gurtovoy
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • Currently, driver code allows user to set 0 as KATO
    (Keep Alive TimeOut), but this is not being respected.
    This patch enforces the expected behavior.

    Signed-off-by: Guilherme G. Piccoli
    Reviewed-by: Sagi Grimberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Guilherme G. Piccoli
     
  • Currently the nvme_req_needs_retry() applies several checks to see if
    a retry is allowed. On of those is whether the current time has exceeded
    the start time of the io plus the timeout length. This check, if an io
    times out, means there is never a retry allowed for the io. Which means
    applications see the io failure.

    Remove this check and allow the io to timeout, like it does on other
    protocols, and retries to be made.

    On the FC transport, a frame can be lost for an individual io, and there
    may be no other errors that escalate for the connection/association.
    The io will timeout, which causes the transport to escalate into creating
    a new association, but the io that timed out, due to this retry logic, has
    already failed back to the application and things are hosed.

    Signed-off-by: James Smart
    Reviewed-by: Keith Busch
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • If an nvme async_event command completes, in most cases, a new
    async event is posted. However, if the controller enters a
    resetting or reconnecting state, there is nothing to block the
    scheduled work element from posting the async event again. Nor are
    there calls from the transport to stop async events when an
    association dies.

    In the case of FC, where the association is torn down, the aer must
    be aborted on the FC link and completes through the normal job
    completion path. Thus the terminated async event ends up being
    rescheduled even though the controller isn't in a valid state for
    the aer, and the reposting gets the transport into a partially torn
    down data structure.

    It's possible to hit the scenario on rdma, although much less likely
    due to an aer completing right as the association is terminated and
    as the association teardown reclaims the blk requests via
    nvme_cancel_request() so its immediate, not a link-related action
    like on FC.

    Fix by putting controller state checks in both the async event
    completion routine where it schedules the async event and in the
    async event work routine before it calls into the transport. It's
    effectively a "stop_async_events()" behavior. The transport, when
    it creates a new association with the subsystem will transition
    the state back to live and is already restarting the async event
    posting.

    Signed-off-by: James Smart
    [hch: remove taking a lock over reading the controller state]
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • The WARN_ONCE macro returns true if the condition is true, not if the
    warn was raised, so we're printing the scatter list every time it's
    invalid. This is excessive and makes debugging harder, so this patch
    prints it just once.

    Signed-off-by: Keith Busch
    Reviewed-by: Martin K. Petersen
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Keith Busch
     
  • A spurious interrupt before the nvme driver has initialized the completion
    queue may inadvertently cause the driver to believe it has a completion
    to process. This may result in a NULL dereference since the nvmeq's tags
    are not set at this point.

    The patch initializes the host's CQ memory so that a spurious interrupt
    isn't mistaken for a real completion.

    Signed-off-by: Keith Busch
    Reviewed-by: Johannes Thumshirn
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Keith Busch
     
  • fc transport is treating NVMET_NR_QUEUES as maximum queue count, e.g.
    admin queue plus NVMET_NR_QUEUES-1 io queues. But NVMET_NR_QUEUES is
    the number of io queues, so maximum queue count is really
    NVMET_NR_QUEUES+1.

    Fix the handling in the target fc transport

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • Sync with NVM Express spec change and FC-NVME 1.18.

    FC transport sets SGL type to Transport SGL Data Block Descriptor and
    subtype to transport-specific value 0x0A.

    Removed the warn-on's on the PRP fields. They are unneeded. They were
    to check for values from the upper layer that weren't set right, and
    for the most part were fine. But, with Async events, which reuse the
    same structure and 2nd time issued the SGL overlay converted them to
    the Transport SGL values - the warn-on's were errantly firing.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • Add transport SGL defintions from NVMe TP 4008, required for
    the final NVMe-FC standard.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart
     
  • The NVM express group recinded the reserved range for the transport.
    Remove the FC-centric values that had been defined.

    Signed-off-by: James Smart
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    James Smart