Re: [PATCH v7 2/2] Return bytes transferred for partial direct I/O

On Thu, Feb 08, 2018 at 12:59:48PM -0600, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > In case direct I/O encounters an error midway, it returns the error. > Instead it should be returning the number of bytes transferred so far. > > Test case for filesystems (with

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote: > On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney > wrote: > > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: > >> Function is going to be used in transport over RDMA module > >> in subsequent

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Sat, May 19, 2018 at 1:25 PM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > Another one list_for_each_entry_rcu()-like macro I am aware of is used in > block/blk-mq-sched.c, is called list_for_each_entry_rcu_rr():

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Sat, May 19, 2018 at 1:21 PM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > I need -rr behaviour for doing IO load-balancing when I choose next RDMA > connection from the list in order to send a request, i.e. my code is > something like the following: [ incomplete pseudoicode ] >

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Fri, May 18, 2018 at 6:56 PM, Linus Torvalds wrote: > On Fri, May 18, 2018 at 6:07 AM Roman Pen > wrote: > >> Function is going to be used in transport over RDMA module >> in subsequent patches. > > Does this really merit its own

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney wrote: > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: >> Function is going to be used in transport over RDMA module >> in subsequent patches. >> >> Function returns next element in round-robin fashion, >>

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: > Function is going to be used in transport over RDMA module > in subsequent patches. > > Function returns next element in round-robin fashion, > i.e. head will be skipped. NULL will be returned if list > is observed as empty. > >

Re: [PATCH] bdi: Fix oops in wb_workfn()

Tetsuo Handa wrote: > Jan Kara wrote: > > Make wb_workfn() use wakeup_wb() for requeueing the work which takes all > > the necessary precautions against racing with bdi unregistration. > > Yes, this patch will solve NULL pointer dereference bug. But is it OK to leave > list_empty(>work_list) ==

Re: [PATCH blktests] Fix block/011 to not use sysfs for device disabling

On Sat, May 19, 2018 at 1:42 AM, Keith Busch wrote: > The PCI sysfs interface may not be a dependable method for toggling the > PCI device state to trigger the timeouts. This patch goes directly to > the config space to make device failure occur. > > The success of this

[PATCH V2] blk-mq: avoid to starve tag allocation after allocation process migrates

When the allocation process is scheduled back and the mapped hw queue is changed, do one extra wake up on orignal queue for compensating wake up miss, so other allocations on the orignal queue won't be starved. This patch fixes one request allocation hang issue, which can be triggered easily in

[PATCH] blk-mq: avoid to starve tag allocation after allocation process migrates

When the allocation process is scheduled back and the mapped hw queue is changed, do one extra wake up on orignal queue for compensating wake up miss, so other allocations on the orignal queue won't be starved. This patch fixes one request allocation hang issue, which can be triggered easily in