[GIT PULL] Block changes for 4.17-rc

2018-04-02 Thread Jens Axboe
h=for-4.17/merged if you wish, that's the above pull request merged with master. Please pull! git://git.kernel.dk/linux-block.git tags/for-4.17/block-20180402 Anshuman Khandual (1): lib/scatterlist: Add SG_CHAIN and SG_END macr

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Bart Van Assche
On Mon, 2018-04-02 at 15:16 -0700, t...@kernel.org wrote: > AFAIK, > there's one non-critical race condition which has always been there. > We have a larger race window for that case but don't yet know whether > that's problematic or not. If that actually is problematic, we can > figure out a way

Re: [PATCH] blk-mq: Directly schedule q->timeout_work when aborting a request

2018-04-02 Thread Jens Axboe
On 4/2/18 4:04 PM, Tejun Heo wrote: > Request abortion is performed by overriding deadline to now and > scheduling timeout handling immediately. For the latter part, the > code was using mod_timer(timeout, 0) which can't guarantee that the > timer runs afterwards. Let's schedule the underlying

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread t...@kernel.org
Hello, On Mon, Apr 02, 2018 at 10:09:18PM +, Bart Van Assche wrote: > Please elaborate what your long-term goal is for the blk-mq timeout handler. Hmm... I don't really have any plans beyond what's been posted. > The legacy block layer suspends request state changes while a timeout is >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Bart Van Assche
On Mon, 2018-04-02 at 15:01 -0700, t...@kernel.org wrote: > On Mon, Apr 02, 2018 at 09:56:41PM +, Bart Van Assche wrote: > > This patch increases the time during which .aborted_gstate == .gstate if the > > timeout is reset. Does that increase the chance that a completion will be > > missed >

Re: 4.16-rc2+git: pata_serverworks: hanging ata detection thread on HP DL380G3

2018-04-02 Thread Tejun Heo
Hello, Meelis. Can you please verify whether the following patch fixes the problem? Thanks. Subject: blk-mq: Directly schedule q->timeout_work when aborting a request Request abortion is performed by overriding deadline to now and scheduling timeout handling immediately. For the latter part,

[PATCH] blk-mq: Directly schedule q->timeout_work when aborting a request

2018-04-02 Thread Tejun Heo
Request abortion is performed by overriding deadline to now and scheduling timeout handling immediately. For the latter part, the code was using mod_timer(timeout, 0) which can't guarantee that the timer runs afterwards. Let's schedule the underlying work item directly instead. This fixes the

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread t...@kernel.org
Hello, On Mon, Apr 02, 2018 at 09:56:41PM +, Bart Van Assche wrote: > This patch increases the time during which .aborted_gstate == .gstate if the > timeout is reset. Does that increase the chance that a completion will be > missed > if the request timeout is reset? It sure does, but we're

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Bart Van Assche
On Mon, 2018-04-02 at 14:10 -0700, Tejun Heo wrote: > On Mon, Apr 02, 2018 at 02:08:37PM -0700, Bart Van Assche wrote: > > On 04/02/18 12:01, Tejun Heo wrote: > > > + * As nothing prevents from completion happening while > > > + * ->aborted_gstate is set, this may lead to ignored completions > >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread t...@kernel.org
Hello, On Mon, Apr 02, 2018 at 09:31:34PM +, Bart Van Assche wrote: > > > > +* As nothing prevents from completion happening while > > > > +* ->aborted_gstate is set, this may lead to ignored completions > > > > +* and further spurious timeouts. > > > > +*/ > >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Bart Van Assche
On Mon, 2018-04-02 at 14:10 -0700, Tejun Heo wrote: > On Mon, Apr 02, 2018 at 02:08:37PM -0700, Bart Van Assche wrote: > > On 04/02/18 12:01, Tejun Heo wrote: > > > + * As nothing prevents from completion happening while > > > + * ->aborted_gstate is set, this may lead to ignored completions > >

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Tejun Heo
On Mon, Apr 02, 2018 at 02:08:37PM -0700, Bart Van Assche wrote: > On 04/02/18 12:01, Tejun Heo wrote: > >+ * As nothing prevents from completion happening while > >+ * ->aborted_gstate is set, this may lead to ignored completions > >+ * and further spurious timeouts. > >+ */ > >+

Re: [PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Bart Van Assche
On 04/02/18 12:01, Tejun Heo wrote: +* As nothing prevents from completion happening while +* ->aborted_gstate is set, this may lead to ignored completions +* and further spurious timeouts. +*/ + if (rq->rq_flags & RQF_MQ_TIMEOUT_RESET) +

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

2018-04-02 Thread Sitsofe Wheeler
Hi Tejun, On 2 April 2018 at 21:29, Tejun Heo wrote: > > Can you see whether the following patch makes any difference? > > Thanks. > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index a05e367..f0e6e41 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c >

Re: [PATCH 1/2] blk-mq: Factor out [s]rcu synchronization

2018-04-02 Thread Bart Van Assche
On 04/02/18 12:00, Tejun Heo wrote: Factor out [s]rcu synchronization in blk_mq_timeout_work() into blk_mq_timeout_sync_rcu(). This is to add another user in the future and doesn't cause any functional changes. Reviewed-by: Bart Van Assche

Re: [BISECTED][REGRESSION] Hang while booting EeePC 900

2018-04-02 Thread Tejun Heo
Hello, Sitsofe. Can you see whether the following patch makes any difference? Thanks. diff --git a/block/blk-timeout.c b/block/blk-timeout.c index a05e367..f0e6e41 100644 --- a/block/blk-timeout.c +++ b/block/blk-timeout.c @@ -165,7 +165,7 @@ void blk_abort_request(struct request *req)

[PATCH 1/2] blk-mq: Factor out [s]rcu synchronization

2018-04-02 Thread Tejun Heo
Factor out [s]rcu synchronization in blk_mq_timeout_work() into blk_mq_timeout_sync_rcu(). This is to add another user in the future and doesn't cause any functional changes. Signed-off-by: Tejun Heo Cc: Bart Van Assche --- Hello, We were tracking this

[PATCH 2/2] blk-mq: Fix request handover from timeout path to normal execution

2018-04-02 Thread Tejun Heo
When a request is handed over from normal execution to timeout, we synchronize using ->aborted_gstate and RCU grace periods; however, when a request is being returned from timeout handling to normal execution for BLK_EH_RESET_TIMER, we were skipping the same synchronization. This means that it

Re: Multi-Actuator SAS HDD First Look

2018-04-02 Thread Tim Walker
On Mon, Apr 2, 2018 at 10:29 AM, Douglas Gilbert wrote: > On 2018-04-02 11:34 AM, Tim Walker wrote: >> >> On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert >> wrote: >>> >>> On 2018-03-30 04:01 PM, Bart Van Assche wrote: On Fri,

Re: Multi-Actuator SAS HDD First Look

2018-04-02 Thread Douglas Gilbert
On 2018-04-02 11:34 AM, Tim Walker wrote: On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert wrote: On 2018-03-30 04:01 PM, Bart Van Assche wrote: On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote: Yes I will be there to discuss the multi-LUN approach. I wanted to

Re: 4.16-rc2+git: pata_serverworks: hanging ata detection thread on HP DL380G3

2018-04-02 Thread Tejun Heo
Hello, On Fri, Mar 30, 2018 at 11:47:24AM +0300, Meelis Roos wrote: > Added CC-s, start of the thread is at > https://lkml.org/lkml/2018/2/26/165 > > > > > 4.16 git bootup on HP Proliant DL380 G3 pauses for a a minute or two > > > > and > > > > then continues with "blocked for more than 120

Re: Multi-Actuator SAS HDD First Look

2018-04-02 Thread Tim Walker
On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert wrote: > On 2018-03-30 04:01 PM, Bart Van Assche wrote: >> >> On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote: >>> >>> Yes I will be there to discuss the multi-LUN approach. I wanted to get >>> these interface details