Fixes the following sparse warning:
drivers/block/brd.c:411:15: warning: symbol 'rd_size' was not declared.
Should it be static?
Signed-off-by: Jason Yan
---
drivers/block/brd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 3
blk_queue_split() is always called with the last arg being q->bio_split,
where 'q' is the first arg.
Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
q->bio_split.
This is inconsistent and unnecessary. Remove the last arg and always use
q->bio_split inside blk_queue_sp
This patch converts bioset_create() and bioset_create_nobvec()
to not create a workqueue so alloctions will never trigger
punt_bios_to_rescuer().
It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued()
which preserve the old behaviour.
*All* callers of bioset_create() and bio
A rescuing bioset is only useful if there might be bios from
that same bioset on the bio_list_on_stack queue at a time
when bio_alloc_bioset() is called. This never applies to
q->bio_split.
Allocations from q->bio_split are only ever made from
blk_queue_split() which is only ever called early in
Allocations from blkdev_dio_pool are never made under
generic_make_request, so this bioset does not need a rescuer thread.
Signed-off-by: NeilBrown
---
fs/block_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index c0ca5f0d0369..2eca00
Commit 79bd99596b73 ("blk: improve order of bio handling in
generic_make_request()")
changed current->bio_list so that it did not contain *all* of the
queued bios, but only those submitted by the currently running
make_request_fn.
There are two places which walk the list and requeue selected bios
This is a rebase of the series I sent earlier, based on the
very latest from Linus, which included my first patch.
The first fixes a problem that patch introduced, and so should go to
Linux promptly.
The others are more general improvements and can go in the normal
course of events.
It is possibl
On Thu, Mar 09 2017, Jens Axboe wrote:
> On 03/09/2017 09:32 PM, NeilBrown wrote:
>>
>> I started looking further at the improvements we can make once
>> generic_make_request is fixed, and realised that I had missed an
>> important detail in this patch.
>> Several places test current->bio_list, a
On 03/09/2017 09:38 PM, Jens Axboe wrote:
> On 03/09/2017 09:32 PM, NeilBrown wrote:
>>
>> I started looking further at the improvements we can make once
>> generic_make_request is fixed, and realised that I had missed an
>> important detail in this patch.
>> Several places test current->bio_list,
On 03/09/2017 09:32 PM, NeilBrown wrote:
>
> I started looking further at the improvements we can make once
> generic_make_request is fixed, and realised that I had missed an
> important detail in this patch.
> Several places test current->bio_list, and two actually edit the list.
> With this chan
Allocations from blkdev_dio_pool are never made under
generic_make_request, so this bioset does not need a rescuer thread.
Signed-off-by: NeilBrown
---
fs/block_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index c0ca5f0d0369..2eca0
A rescuing bioset is only useful if there might be bios from
that same bioset on the bio_list_on_stack queue at a time
when bio_alloc_bioset() is called. This never applies to
q->bio_split.
Allocations from q->bio_split are only ever made from
blk_queue_split() which is only ever called early in
This patch converts bioset_create() and bioset_create_nobvec()
to not create a workqueue so alloctions will never trigger
punt_bios_to_rescuer().
It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued()
which preserve the old behaviour.
*All* callers of bioset_create() and bi
blk_queue_split() is always called with the last arg being q->bio_split,
where 'q' is the first arg.
Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
q->bio_split.
This is inconsistent and unnecessary. Remove the last arg and always use
q->bio_split inside blk_queue_s
To avoid recursion on the kernel stack when stacked block devices
are in use, generic_make_request() will, when called recursively,
queue new requests for later handling. They will be handled when the
make_request_fn for the current bio completes.
If any bios are submitted by a make_request_fn,
I started looking further at the improvements we can make once
generic_make_request is fixed, and realised that I had missed an
important detail in this patch.
Several places test current->bio_list, and two actually edit the list.
With this change, that cannot see the whole lists, so it could caus
On 3/9/17 22:44, Johannes Thumshirn wrote:
> On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
>> For a server/target appliance mode where we don't
>> necessarily care about specific IOs but rather want
>> to poll opportunisticly, it is useful to have a
>> non-selective polling interface.
>>
>> Expose a
On Fri, Mar 10, 2017 at 12:58 AM, Bart Van Assche
wrote:
> On Thu, 2017-03-09 at 21:02 +0800, Ming Lei wrote:
>> Before commit 780db2071a(blk-mq: decouble blk-mq freezing
>> from generic bypassing), the dying flag is checked before
>> entering queue, and Tejun converts the checking into .mq_freeze
On Wed, Feb 22, 2017 at 2:29 PM, Adrian Hunter wrote:
> On 09/02/17 17:33, Linus Walleij wrote:
>> The waitqueue in the host context is there to signal back from
>> mmc_request_done() through mmc_wait_data_done() that the hardware
>> is done with a command, and when the wait is over, the core
>> w
On Fri, Mar 3, 2017 at 1:22 PM, Adrian Hunter wrote:
> On 15/02/17 15:49, Linus Walleij wrote:
>> On Fri, Feb 10, 2017 at 1:55 PM, Adrian Hunter
>> wrote:
>>
>>> Enhance mmc_blk_data_prep() to support CQE requests.
>>>
>>> Signed-off-by: Adrian Hunter
>>
>> Hey:
>>
>>> +#include
>> (...)
>>> +
On Thu, Mar 09, 2017 at 12:05:31AM -0800, Tahsin Erdogan wrote:
> blkg_conf_prep() currently calls blkg_lookup_create() while holding
> request queue spinlock. This means allocating memory for struct
> blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM
> failures in call paths lik
On Thu, 2017-03-09 at 21:02 +0800, Ming Lei wrote:
> Before commit 780db2071a(blk-mq: decouble blk-mq freezing
> from generic bypassing), the dying flag is checked before
> entering queue, and Tejun converts the checking into .mq_freeze_depth,
> and assumes the counter is increased just after dying
On Thu, Mar 09, 2017 at 11:16:21AM +0100, Jan Kara wrote:
> SCSI can call device_add_disk() several times for one request queue when
> a device in unbound and bound, creating new gendisk each time. This will
> lead to bdi being repeatedly registered and unregistered. This was not a
> big problem un
On Thu, 2017-03-09 at 15:16 +0200, Sagi Grimberg wrote:
> polling the completion queue directly does not interfere
> with the existing polling logic, hence drop the requirement.
>
> This can be used for polling mode ULPs.
>
> Signed-off-by: Sagi Grimberg
> ---
> drivers/infiniband/core/cq.c | 2
On 03/09/2017 03:16 AM, Jan Kara wrote:
> Hi!
>
> this is a second revision of the series fixing the most urgent bugs that were
> introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
> del_gendisk()" and by 0dba1314d4f8 "scsi, block: fix duplicate bdi name
> registration crashes". I
On Thu, 2017-03-09 at 15:16 +0200, Sagi Grimberg wrote:
> +int blk_mq_poll_batch(struct request_queue *q, unsigned int batch)
> +{
> + struct blk_mq_hw_ctx *hctx;
> +
> + if (!q->mq_ops || !q->mq_ops->poll_batch)
> + return 0;
> +
> + hctx = blk_mq_map_queue(q, smp_processor
Hi Linus,
Sending this a bit sooner than I otherwise would have, as a fix in the
merge window had some unfortunate issues and side effects for some
folks.
This pull request contains:
- Fixes from Jan for the bdi registration/unregistration. These have
been tested by the various parties reporti
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> We don't need it as the core polling context will take
> are of rearming the completion queue.
^ care?
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LI
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> Just some rework to split the logic and make it slightly
> more readable. This will help us to easily add the irq-poll
> logic.
>
> Also, introduce nvme_ring_cq_doorbell helper to mask out the
> cq_vector validity check.
>
> Signed-off-by: Sagi Grimb
Just some rework to split the logic and make it slightly
more readable. This will help us to easily add the irq-poll
logic.
Also, introduce nvme_ring_cq_doorbell helper to mask out the
cq_vector validity check.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/pci.c | 109 +
Hi,
The 1st patch fixes one race between timeout and dying queue.
The 2nd patch improves handling for dying queue.
thanks,
Ming
Ming Lei (2):
blk-mq: don't complete un-started request in timeout handler
blk-mq: start to freeze queue just after setting dying
block/blk-core.c | 7 +--
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> Given that the code is simple enough it seems better
> then passing a tag by reference for each call site.
>
> Signed-off-by: Sagi Grimberg
> ---
Deja-vu again?
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> It doesn't really make sense to do selective polling
> because we never care about specific IOs. Non selective
> polling can actually help by doing some useful work
> while we're submitting a command.
>
> We ask for a batch of (magic) 4 completions wh
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> Prepare to allow passing a batch size to nvme cq processing.
>
> This patch does not change an functionality.
>
> Signed-off-by: Sagi Grimberg
> ---
I think I already did this with the 1st RFC (this patch gives me a deja
vu moment), but:
Reviewed-b
Given that the code is simple enough it seems better
then passing a tag by reference for each call site.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/pci.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/dri
On 03/09/2017 02:16 PM, Sagi Grimberg wrote:
> For a server/target appliance mode where we don't
> necessarily care about specific IOs but rather want
> to poll opportunisticly, it is useful to have a
> non-selective polling interface.
>
> Expose a blk_poll_batch for a batched blkdev polling
> int
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/rdma.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index a17eef3ef6ff..29ac8fcb8d2c 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -1488,6 +1488,13 @@ st
polling the completion queue directly does not interfere
with the existing polling logic, hence drop the requirement.
This can be used for polling mode ULPs.
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/core/cq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/infiniband/cor
For a server/target appliance mode where we don't
necessarily care about specific IOs but rather want
to poll opportunisticly, it is useful to have a
non-selective polling interface.
Expose a blk_poll_batch for a batched blkdev polling
interface so our nvme target (and others) can use.
Signed-off
Prepare to allow passing a batch size to nvme cq processing.
This patch does not change an functionality.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/pci.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index
It doesn't really make sense to do selective polling
because we never care about specific IOs. Non selective
polling can actually help by doing some useful work
while we're submitting a command.
We ask for a batch of (magic) 4 completions which looks
like a decent network<->backend proportion, if
It doesn't really make sense to do selective polling
because we never care about specific IOs. Non selective
polling can actually help by doing some useful work
while we're submitting a command.
We ask for a batch of (magic) 4 completions which looks
like a decent network<->backend proportion, if
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/pci.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index a7ad514c2451..f8dcd0bd19f8 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -789,6 +789,21 @@
We don't need it as the core polling context will take
are of rearming the completion queue.
Signed-off-by: Sagi Grimberg
---
drivers/nvme/host/rdma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 7bad791a7fe9..a17eef3ef6ff 100644
--
Today, our only polling interface is selective in the sense that
it polls for a specific tag (cookie). blk_mq_poll will not complete
until the specific tag has completed (given that the block driver
implements it obviously).
target mode drivers like our nvme and scsi target, can benefit
from oppor
Before commit 780db2071a(blk-mq: decouble blk-mq freezing
from generic bypassing), the dying flag is checked before
entering queue, and Tejun converts the checking into .mq_freeze_depth,
and assumes the counter is increased just after dying flag
is set. Unfortunately we doesn't do that in blk_set_q
When iterating busy request in timeout handler,
if the STARTED flag of one request isn't set, that means
the request is being processed in block layer, and not
dispatched to low level driver yet.
In current implementation of blk_mq_check_expired(),
in case that the request queue becomes dying, un-
Hi,
The 1st patch fixes one race between timeout and dying queue.
The 2nd patch improves handling for dying queue.
thanks,
Ming
Ming Lei (2):
blk-mq: don't complete un-started request in timeout handler
blk-mq: start to freeze queue just after setting dying
block/blk-core.c | 7 +--
cc linux-block
On Thu, Mar 09, 2017 at 04:20:06PM +0530, Abdul Haleem wrote:
> On Wed, 2017-03-08 at 08:17 -0500, Brian Foster wrote:
> > On Tue, Mar 07, 2017 at 10:01:04PM +0530, Abdul Haleem wrote:
> > >
> > > Hi,
> > >
> > > Today's mainline (4.11.0-rc1) booted with warnings on Power7 LPAR.
>
On 2017/3/8 22:05, Jan Kara wrote:
> On Wed 08-03-17 20:16:55, Hou Tao wrote:
>> When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY
>> as the delay of cfq_group's vdisktime if there have been other cfq_groups
>> already.
>>
>> When cfq is under iops mode, commit 9a7f38c42c2b (
SCSI can call device_add_disk() several times for one request queue when
a device in unbound and bound, creating new gendisk each time. This will
lead to bdi being repeatedly registered and unregistered. This was not a
big problem until commit 165a5e22fafb "block: Move bdi_unregister() to
del_gendi
Commit 165a5e22fafb "block: Move bdi_unregister() to del_gendisk()"
added disk->queue dereference to del_gendisk(). Although del_gendisk()
is not supposed to be called without disk->queue valid and
blk_unregister_queue() warns in that case, this change will make it oops
instead. Return to the old m
bdi_writeback_congested structures get created for each blkcg and bdi
regardless whether bdi is registered or not. When they are created in
unregistered bdi and the request queue (and thus bdi) is then destroyed
while blkg still holds reference to bdi_writeback_congested structure,
this structure w
This reverts commit 0dba1314d4f81115dce711292ec7981d17231064. It causes
leaking of device numbers for SCSI when SCSI registers multiple gendisks
for one request_queue in succession. It can be easily reproduced using
Omar's script [1] on kernel with CONFIG_DEBUG_TEST_DRIVER_REMOVE.
Furthermore the p
Hi!
this is a second revision of the series fixing the most urgent bugs that were
introduced by commit 165a5e22fafb "block: Move bdi_unregister() to
del_gendisk()" and by 0dba1314d4f8 "scsi, block: fix duplicate bdi name
registration crashes". In fact before these commits we had a different set o
Jan Kara wrote on 09/03/17 03:18:
Hi!
patches in this series fix the most urgent bugs that were introduced by commit
165a5e22fafb "block: Move bdi_unregister() to del_gendisk()" and by
0dba1314d4f8 "scsi, block: fix duplicate bdi name registration crashes".
In fact before these commits we had
On Wed 08-03-17 17:55:42, Tejun Heo wrote:
> Hello,
>
> On Wed, Mar 08, 2017 at 05:48:31PM +0100, Jan Kara wrote:
> > @@ -710,6 +710,11 @@ static void cgwb_bdi_destroy(struct backing_dev_info
> > *bdi)
> > */
> > atomic_dec(&bdi->usage_cnt);
> > wait_event(cgwb_release_wait, !atomic_
Hello,
On Thu 09-03-17 15:25:23, Tetsuo Handa wrote:
> I noticed that 4.11-rc1 crashes upon boot.
Thanks for report. It should be fixed by patches I've posted yesterday:
https://www.mail-archive.com/linux-block@vger.kernel.org/msg05566.html
blkg_conf_prep() currently calls blkg_lookup_create() while holding
request queue spinlock. This means allocating memory for struct
blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM
failures in call paths like below:
pcpu_alloc+0x68f/0x710
__alloc_percpu_gfp+0xd/0x10
__per
This is a good catch!
I will post a v5 of the patch shortly to the other email thread.
On Wed, Mar 8, 2017 at 9:25 PM, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> commit: ad63af3cb70378a7f780dbef2387a6d13e53a6c9 ("blkcg: allocate struct
> blkcg_gq outside request queu
60 matches
Mail list logo
