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
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
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
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
>
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
>
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,
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
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
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
> >
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.
> > > > +*/
> >
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
> >
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.
> >+ */
> >+
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)
+
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
>
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
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)
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
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
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,
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
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
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
22 matches
Mail list logo