Hi,
I think I am triggering a blk-mq + bfq bug that I can reproduce 100%
of the time by using gdisk (1.0.1-1 in Debian stretch) to write a
partition table to a USB flash drive. After it is triggered, IO hangs
forever to that device and the machine cannot be shut down cleanly.
I have reproduced t
On Thu, Nov 30, 2017 at 04:08:46PM -0800, Bart Van Assche wrote:
> The blk_mq_sched_restart() call from inside blk_mq_free_request()
> only runs those queues for which BLK_MQ_S_SCHED_RESTART has been
> set. Hence set that flag from inside blk_mq_mark_tag_wait() whether
> or not a queue is shared.
>
On Thu, Nov 30, 2017 at 04:08:47PM -0800, Bart Van Assche wrote:
> During request dispatch, after a scheduler or per-CPU queue has
> been examined, .put_budget() is called if the examined queue is
> empty. Since a new request may be queued concurrently with the
> .put_budget() call, a request queue
On 11/30/2017 05:08 PM, Bart Van Assche wrote:
> This patch does not change any functionality.
Unless these actually found real bugs, I think it's pointless.
Add a comment. And this:
> @@ -1003,9 +1007,14 @@ bool blk_mq_get_driver_tag(struct request *rq, struct
> blk_mq_hw_ctx **hctx,
> static
On 11/30/2017 05:08 PM, Bart Van Assche wrote:
> The following code at the end of blk_mq_dispatch_rq_list() detects
> whether or not wake_up(&hctx->dispatch_wait) has been called
> concurrently with pushing back requests onto the dispatch list:
>
> list_empty_careful(&hctx->dispatch_wait.entry
On Thu, Nov 30, 2017 at 04:08:45PM -0800, Bart Van Assche wrote:
> blk_mq_sched_mark_restart_hctx() must be called before
Could you please describe the theory on commit log? Like, why is it
a must? and what is the issue to be fixed?
> blk_mq_dispatch_rq_list() is called. Make sure that
> BLK_MQ_
On Mon, Nov 27, 2017 at 05:14:46PM +, Bart Van Assche wrote:
> On Mon, 2017-11-27 at 13:07 +0800, Ming Lei wrote:
> > If .queue_rq() returns BLK_STS_RESOURCE, blk-mq will rerun the queue in
> > the three situations:
> >
> > 1) if BLK_MQ_S_SCHED_RESTART is set
> > - queue is rerun after one rq
On Thu, Nov 30, 2017 at 10:51:57PM +0100, Pavel Machek wrote:
> Hi!
>
> > Proposed solution:
> >
> > Instead of fixing such semantics and trying to get all filesystems to do it
> > right, we can easily do away with all freezing calls if the filesystem
> > implements a proper freeze_fs() callback.
The following code at the end of blk_mq_dispatch_rq_list() detects
whether or not wake_up(&hctx->dispatch_wait) has been called
concurrently with pushing back requests onto the dispatch list:
list_empty_careful(&hctx->dispatch_wait.entry)
Since blk_mq_dispatch_wake() is protected by another l
During request dispatch, after a scheduler or per-CPU queue has
been examined, .put_budget() is called if the examined queue is
empty. Since a new request may be queued concurrently with the
.put_budget() call, a request queue needs to be rerun after each
.put_budget() call.
Fixes: commit 1f460b63
blk_mq_sched_mark_restart_hctx() must be called before
blk_mq_dispatch_rq_list() is called. Make sure that
BLK_MQ_S_SCHED_RESTART is set before any blk_mq_dispatch_rq_list()
call occurs.
Fixes: commit b347689ffbca ("blk-mq-sched: improve dispatching from sw queue")
Signed-off-by: Bart Van Assche
The blk_mq_sched_restart() call from inside blk_mq_free_request()
only runs those queues for which BLK_MQ_S_SCHED_RESTART has been
set. Hence set that flag from inside blk_mq_mark_tag_wait() whether
or not a queue is shared.
Signed-off-by: Bart Van Assche
Cc: Ming Lei
Cc: Omar Sandoval
Cc: Chri
Hello Jens,
This patch series fixes the issues I came across while reviewing and testing
the v4.15-rc1 block layer. Please consider these patches for v4.15-rc /
v4.16 as appropriate.
Thanks,
Bart.
Bart Van Assche (7):
blk-mq: Fix spelling in a source code comment
block: Document more lockin
Reduce the number of return statements from three to one. Reduce the
number of spin_unlock(&this_hctx->lock) calls from two to one. Fix
a misleading comment: since blk-mq-tag.c always uses wake_up_all()
other waiters are woken up whether or not the current hctx is removed
from the wait list. This p
Change "nedeing" into "needing" and "caes" into "cases".
Fixes: commit f906a6a0f426 ("blk-mq: improve tag waiting setup for non-shared
tags")
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Omar Sandoval
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
---
block/blk-mq.c | 4 ++--
1 file
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
---
block/blk-mq.c | 13 +++--
block/blk-timeout.c | 3 +++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.
On Friday, December 1, 2017 12:30:33 AM CET Dave Chinner wrote:
> On Thu, Nov 30, 2017 at 09:32:53PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 30, 2017 at 5:21 PM, Jan Kara wrote:
> > > On Wed 29-11-17 15:23:52, Luis R. Rodriguez wrote:
> > >> This removes superflous freezer calls as they ar
On Thu, Nov 30, 2017 at 09:32:53PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 30, 2017 at 5:21 PM, Jan Kara wrote:
> > On Wed 29-11-17 15:23:52, Luis R. Rodriguez wrote:
> >> This removes superflous freezer calls as they are no longer needed
> >> as the VFS now performs filesystem freezing/thaw
On 11/30/2017 02:58 PM, Michael Lyle wrote:
> Hi Linus & Jens--
>
> Just one small clarification:
>
> On 11/30/2017 01:14 PM, Jens Axboe wrote:
>> - Pull bcache fixes from Michael Lyle. Most important is a regression
>> fix for a case where bcache could return the wrong data in some
>> circum
Hi Linus & Jens--
Just one small clarification:
On 11/30/2017 01:14 PM, Jens Axboe wrote:
> - Pull bcache fixes from Michael Lyle. Most important is a regression
> fix for a case where bcache could return the wrong data in some
> circumstances.
The fix for the block-layer data corruption iss
Hi!
> Proposed solution:
>
> Instead of fixing such semantics and trying to get all filesystems to do it
> right, we can easily do away with all freezing calls if the filesystem
> implements a proper freeze_fs() callback. The following 9 filesystems have
> freeze_fs() implemented as such we can l
On 11/28/2017 02:37 AM, Paolo Valente wrote:
> Commit a33801e8b473 ("block, bfq: move debug blkio stats behind
> CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs:
> one reported in [1], plus a similar one in another function. This
> commit removes both batches, in the way sugges
Hi Linus,
A selection of fixes/changes that should make it into this series. This
pull request contains:
- NVMe, two merges, containing:
- pci-e, rdma, and fc fixes
- Device quirks
- Fix for a badblocks leak in null_blk
- Pull bcache fixes from Michael Lyle. Most important is a
On Thu, Nov 30, 2017 at 08:53:52PM +, Bart Van Assche wrote:
> On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote:
> > On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> > > The md resync
> > > thread must be stopped before a system is frozen. Today the md driver uses
>
On Thu, 2017-11-30 at 20:42 +0100, Luis R. Rodriguez wrote:
> On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> > The md resync
> > thread must be stopped before a system is frozen. Today the md driver uses
> > the kthread freezing mechanism for that purpose. Do you have a plan for
On Thu, Nov 30, 2017 at 5:21 PM, Jan Kara wrote:
> On Wed 29-11-17 15:23:52, Luis R. Rodriguez wrote:
>> This removes superflous freezer calls as they are no longer needed
>> as the VFS now performs filesystem freezing/thaw if the filesystem has
>> support for it.
>>
>> The following Coccinelle ru
On Thu, Nov 30, 2017 at 05:01:13PM +, Bart Van Assche wrote:
> It's great to see that you are making progress with this work :-) However,
> what's not clear to me is what your (long-term) plan is for freezing
> filesystems that e.g. exist on top of a md RAID1 block device?
The original approac
On Thu, Nov 30, 2017 at 06:13:10PM +0100, Jan Kara wrote:
> ... I dislike the _by_user() suffix as there may be different places that
> call freeze_super() (e.g. device mapper does this during some operations).
> Clearly we need to distinguish "by system suspend" and "the other" cases.
> So please
On Wed 29-11-17 15:23:48, Luis R. Rodriguez wrote:
> The question of whether or not a superblock is frozen needs to be
> augmented in the future to account for differences between a user
> initiated freeze and a kernel initiated freeze done automatically
> on behalf of the kernel.
>
> Provide help
On Wed, 2017-11-29 at 15:23 -0800, Luis R. Rodriguez wrote:
> This is a followup from the original RFC which proposed to start
> to kill kthread freezing all together [0]. Instead of going straight
> out to the jugular for kthread freezing this series only addresses
> killing freezer calls on files
On Wed 29-11-17 15:23:47, Luis R. Rodriguez wrote:
> thaw_super() hold a write lock, however we wish to also enable
> callers which already hold the write lock. To do this provide a helper
> and make thaw_super() use it. This way, all that thaw_super() does
> now is lock handling and active count m
On Wed 29-11-17 15:23:46, Luis R. Rodriguez wrote:
> freeze_super() holds a write lock, however we wish to also enable
> callers which already hold the write lock. To do this provide a helper
> and make freeze_super() use it. This way, all that freeze_super() does
> now is lock handling and active
On Wed 29-11-17 15:23:50, Luis R. Rodriguez wrote:
> There are use cases where we wish to traverse the superblock list
> but also capture errors, and in which case we want to avoid having
> our callers issue a lock themselves since we can do the locking for
> the callers. Provide a iterate_supers_e
On Fri, Dec 1, 2017 at 12:41 AM, Jiri Kosina wrote:
> On Fri, 1 Dec 2017, Yu Chen wrote:
>
>> BTW, is nfs able to be included in this set? I also encountered a
>> freeze() failure due to nfs access during that stage recently.
>
> The freezer usage in NFS is magnitudes more complicated, so it makes
On Fri, 1 Dec 2017, Yu Chen wrote:
> BTW, is nfs able to be included in this set? I also encountered a
> freeze() failure due to nfs access during that stage recently.
The freezer usage in NFS is magnitudes more complicated, so it makes sense
to first go after the lower hanging fruit to figure
On Thu, Nov 30, 2017 at 7:23 AM, Luis R. Rodriguez wrote:
> This is a followup from the original RFC which proposed to start
> to kill kthread freezing all together [0]. Instead of going straight
> out to the jugular for kthread freezing this series only addresses
> killing freezer calls on filesy
On Wed 29-11-17 15:23:52, Luis R. Rodriguez wrote:
> This removes superflous freezer calls as they are no longer needed
> as the VFS now performs filesystem freezing/thaw if the filesystem has
> support for it.
>
> The following Coccinelle rule was used as follows:
>
> spatch --sp-file fs-freeze-
Mariusz,
>>> One potential solution for that is to change type of some queue limits
>>> (at least discard_granularity and discard_alignment, maybe more, like
>>> max_discard_sectors?) from 32 bits to 64 bits.
You're still restricted by the max bio size which is 32 bits on 32-bit
platforms.
> Le
Josef,
> For some reason we had discard granularity set to 512 always even when
> discards were disabled. Fix this by having the default be 0, and then
> if we turn it on set the discard granularity to the blocksize.
Originally, discard_max_bytes was the queue limit used to indicate
whether dis
From: Goldwyn Rodrigues
Fixes: fbbaf700e7b1 ("block: trace completion of all bios.")
Signed-off-by: Goldwyn Rodrigues
---
block/bio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/bio.c b/block/bio.c
index 228229f3bb76..3f4940dd00da 100644
--- a/block/bio.c
+++ b/blo
Hi,
do you have any comments to this?
Regards,
Mariusz
On 11/22/2017 09:12 AM, Mariusz Dabrowski wrote:
On 11/17/2017 07:40 PM, Shaohua Li wrote:
On Wed, Nov 15, 2017 at 11:25:12AM +0100, Mariusz Dabrowski wrote:
Hi all,
In order to be compliant with a pass-throug drive behavior, RAID queue
41 matches
Mail list logo
