On Tue, Oct 30, 2018 at 08:00:04AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:11743c56785c Merge tag 'rpmsg-v4.20' of git://github.com/a..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1512119940
> kernel
On Wed, Oct 24, 2018 at 9:18 PM Ming Lei wrote:
>
> rq_qos_exit() removes the current q->rq_qos, this action has to be
> done after queue is frozen, otherwise the IO queue path may never
> be waken up, then IO hang is caused.
>
> So fixes this issue by moving rq_qos_exit() after queue is frozen.
>
Reviewed-by: Sagi Grimberg
+static int queue_irq_offset(struct nvme_dev *dev)
+{
+ /* if we have more than 1 vec, admin queue offsets us 1 */
offsets us by 1?
+ if (dev->num_vecs > 1)
+ return 1;
+
+ return 0;
+}
+
...
@@ -1934,13 +2048,48 @@ static int nvme_setup_io_queues(struct
On 2018/10/30 16:14, Masato Suzuki wrote:
> Allow the creation of conventional zones by adding the zone_nr_conv
> configuration attribute. This new attribute is used only for zoned devices
> and indicates the number of conventional zones to create. The default value
> is 0. Since host-managed zoned
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 1821f448f7c4..8329017badc8 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -72,20 +72,37 @@ void blk_mq_try_issue_list_directly(struct blk_mq_hw_ctx
*hctx,
*/
extern int blk_mq_hw_queue_to_node(struct blk_mq_queue_map *qmap, unsigned
It can be useful for a user to verify what type a given hardware
queue is, expose this information in sysfs.
I assume the user is expected to understand the meaning of the
enumeration it sees in accessing this field correct?
Would be nice to output some meaningful string but I'm not
yet sure
@@ -2342,10 +2346,16 @@ static void blk_mq_map_swqueue(struct request_queue *q)
ctx = per_cpu_ptr(q->queue_ctx, i);
hctx = blk_mq_map_queue_type(q, 0, i);
-
+ hctx->type = 0;
cpumask_set_cpu(i, hctx->cpumask);
- ctx->index_hw
static inline struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *q,
+unsigned int flags,
unsigned int cpu)
{
struct blk_mq_tag_set *set = q->tag_set;
@@ -84,7 +85,7 @@
Reviewed-by: Sagi Grimberg
@@ -41,12 +41,12 @@ int blk_mq_rdma_map_queues(struct blk_mq_tag_set *set,
goto fallback;
for_each_cpu(cpu, mask)
- set->mq_map[cpu] = queue;
+ set->map[0].mq_map[cpu] = queue;
Any reason not to change the signature l
Reviewed-by: Sagi Grimberg
On Tue, 2018-10-30 at 16:06 -0700, Evan Green wrote:
> This series addresses some errors seen when using the loop
> device directly backed by a block device. The first change plumbs
> out the correct error message, and the second change prevents the
> error from occurring in many cases.
Hi Evan,
If the backing device for a loop device is a block device,
then mirror the discard properties of the underlying block
device into the loop device. While in there, differentiate
between REQ_OP_DISCARD and REQ_OP_WRITE_ZEROES, which are
different for block devices, but which the loop device had
just
Properly plumb out EOPNOTSUPP from loop driver operations, which may
get returned when for instance a discard operation is attempted but not
supported by the underlying block device. Before this change, everything
was reported in the log as an I/O error, which is scary and not
helpful in debugging.
This series addresses some errors seen when using the loop
device directly backed by a block device. The first change plumbs
out the correct error message, and the second change prevents the
error from occurring in many cases.
Evan Green (2):
loop: Report EOPNOTSUPP properly
loop: Better disc
On 10/30/18 5:29 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to clean up an indentation issue, remove tabs
Applied, thanks.
--
Jens Axboe
On Tue, Oct 30, 2018 at 12:32:36PM -0600, Jens Axboe wrote:
> This series adds support for multiple queue maps for blk-mq.
> Since blk-mq was introduced, it's only support a single queue
> map. This means you can have 1 set of queues, and the mapping
> purely depends on what CPU an IO originated fr
It's just a pointer to set->mq_map, use that instead. Move the
assignment a bit earlier, so we always know it's valid.
Reviewed-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 13 -
block/blk-mq
This is in preparation for allowing multiple sets of maps per
queue, if so desired.
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
Signed-off-by: Jens Axboe
---
block/blk-mq-cpumap.c | 10
block/blk-mq-pci.c| 10
block/blk-mq-rdm
The mapping used to be dependent on just the CPU location, but
now it's a tuple of (type, cpu) instead. This is a prep patch
for allowing a single software queue to map to multiple hardware
queues. No functional changes in this patch.
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
---
b
Add support for the tag set carrying multiple queue maps, and
for the driver to inform blk-mq how many it wishes to support
through setting set->nr_maps.
This adds an mq_ops helper for drivers that support more than 1
map, mq_ops->flags_to_type(). The function takes request/bio flags
and CPU, and
Prep patch for being able to place request based not just on
CPU location, but also on the type of request.
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
---
block/blk-flush.c | 7 +++---
block/blk-mq-debugfs.c | 4 +++-
block/blk-mq-sched.c | 16 ++
block/blk-mq-t
It can be useful for a user to verify what type a given hardware
queue is, expose this information in sysfs.
Reviewed-by: Hannes Reinecke
Reviewed-by: Bart Van Assche
Signed-off-by: Jens Axboe
---
block/blk-mq-sysfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/block/blk-mq
We use IOCB_HIPRI to poll for IO in the caller instead of scheduling.
This information is not available for (or after) IO submission. The
driver may make different queue choices based on the type of IO, so
make the fact that we will poll for this IO known to the lower layers
as well.
Reviewed-by:
Add a queue offset to the tag map. This enables users to map
iteratively, for each queue map type they support.
Bump maximum number of supported maps to 2, we're now fully
able to support more than 1 map.
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
---
block/blk-mq-cpumap.c | 9 +++
It's somewhat strange to have a list insertion function that
relies on the fact that the caller has mapped things correctly.
Pass in the hardware queue directly for insertion, which makes
for a much cleaner interface and implementation.
Signed-off-by: Jens Axboe
---
block/blk-mq-sched.c | 8 +--
A driver may have a need to allocate multiple sets of MSI/MSI-X
interrupts, and have them appropriately affinitized. Add support for
defining a number of sets in the irq_affinity structure, of varying
sizes, and get each set affinitized correctly across the machine.
Cc: Thomas Gleixner
Cc: linux-
Currently we only look at the software queue, but with support
for multiple maps, we should also look at the hardware queue.
This is important since we'll flush out the request list if
either the software queue or hardware queue don't match.
This sorts by software queue first, then hardware queue
NVMe does round-robin between queues by default, which means that
sharing a queue map for both reads and writes can be problematic
in terms of read servicing. It's much easier to flood the queue
with writes and reduce the read servicing.
Implement two queue maps, one for reads and one for writes.
Adds support for defining a variable number of poll queues, currently
configurable with the 'poll_queues' module parameter. Defaults to
a single poll queue.
And now we finally have poll support without triggering interrupts!
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
---
drivers/nv
We call blk_mq_map_queue() a lot, at least two times for each
request per IO, sometimes more. Since we now have an indirect
call as well in that function. cache the mapping so we don't
have to re-call blk_mq_map_queue() for the same request
multiple times.
Signed-off-by: Jens Axboe
---
block/blk
This series adds support for multiple queue maps for blk-mq.
Since blk-mq was introduced, it's only support a single queue
map. This means you can have 1 set of queues, and the mapping
purely depends on what CPU an IO originated from. With this
patch set, drivers can implement mappings that depend
Doesn't do anything right now, but it's needed as a prep patch
to get the interfaces right.
While in there, correct the blk_mq_map_queue() CPU type to an unsigned
int.
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
---
block/blk-mq.h | 9 -
1 file changed, 8 insertions(+), 1 de
With multiple maps, nr_cpu_ids is no longer the maximum number of
hardware queues we support on a given devices. The initializer of
the tag_set can have set ->nr_hw_queues larger than the available
number of CPUs, since we can exceed that with multiple queue maps.
Reviewed-by: Hannes Reinecke
Rev
Subject: Re: [PATCH v2] block: fix rdma queue mapping
Sagi - From what I can tell, i40iw is also exposed to this same issue
if the IRQ affinity is configured by user.
managed affinity does not allow setting smp_affinity from userspace.
OK. But our device IRQs are not set-up as to be mana
On 10/30/18 11:46 AM, Thomas Gleixner wrote:
> On Tue, 30 Oct 2018, Jens Axboe wrote:
>> On 10/30/18 11:25 AM, Thomas Gleixner wrote:
>>> Jens,
>>>
>>> On Tue, 30 Oct 2018, Jens Axboe wrote:
On 10/30/18 10:02 AM, Keith Busch wrote:
> pci_alloc_irq_vectors_affinity() starts at the provided
On Tue, 30 Oct 2018, Jens Axboe wrote:
> On 10/30/18 11:25 AM, Thomas Gleixner wrote:
> > Jens,
> >
> > On Tue, 30 Oct 2018, Jens Axboe wrote:
> >> On 10/30/18 10:02 AM, Keith Busch wrote:
> >>> pci_alloc_irq_vectors_affinity() starts at the provided max_vecs. If
> >>> that doesn't work, it will i
On 10/30/18 11:34 AM, Jens Axboe wrote:
> On 10/30/18 11:25 AM, Thomas Gleixner wrote:
>> Jens,
>>
>> On Tue, 30 Oct 2018, Jens Axboe wrote:
>>> On 10/30/18 10:02 AM, Keith Busch wrote:
pci_alloc_irq_vectors_affinity() starts at the provided max_vecs. If
that doesn't work, it will iterate
On Tue, Oct 30, 2018 at 11:33:51AM -0600, Jens Axboe wrote:
> On 10/30/18 11:22 AM, Keith Busch wrote:
> > On Tue, Oct 30, 2018 at 11:09:04AM -0600, Jens Axboe wrote:
> >> Pretty trivial, below. This also keeps the queue mapping calculations
> >> more clean, as we don't have to do one after we're d
On 10/30/18 11:25 AM, Thomas Gleixner wrote:
> Jens,
>
> On Tue, 30 Oct 2018, Jens Axboe wrote:
>> On 10/30/18 10:02 AM, Keith Busch wrote:
>>> pci_alloc_irq_vectors_affinity() starts at the provided max_vecs. If
>>> that doesn't work, it will iterate down to min_vecs without returning to
>>> the
On 10/30/18 11:22 AM, Keith Busch wrote:
> On Tue, Oct 30, 2018 at 11:09:04AM -0600, Jens Axboe wrote:
>> Pretty trivial, below. This also keeps the queue mapping calculations
>> more clean, as we don't have to do one after we're done allocating
>> IRQs.
>
> Yep, this addresses my concern. It less
Jens,
On Tue, 30 Oct 2018, Jens Axboe wrote:
> On 10/30/18 10:02 AM, Keith Busch wrote:
> > pci_alloc_irq_vectors_affinity() starts at the provided max_vecs. If
> > that doesn't work, it will iterate down to min_vecs without returning to
> > the caller. The caller doesn't have a chance to adjust i
On Tue, Oct 30, 2018 at 11:09:04AM -0600, Jens Axboe wrote:
> Pretty trivial, below. This also keeps the queue mapping calculations
> more clean, as we don't have to do one after we're done allocating
> IRQs.
Yep, this addresses my concern. It less efficient than PCI since PCI
can usually jump str
On 10/30/18 2:08 AM, Ming Lei wrote:
> Requests can be added to plug list from different ctx because of
> preemption. However, blk_mq_sched_insert_requests() requires that
> all requests in 'hctx_list' belong to same ctx.
Yeah, I tried to get around it, but I think I'll just respin and keep
the '
On Tue, 2018-10-30 at 12:02 -0400, Theodore Y. Ts'o wrote:
> On Tue, Oct 30, 2018 at 08:02:55AM -0700, Bart Van Assche wrote:
> > Details about how the build fails on 32-bit systems would have been welcome
> > in the commit message. Anyway:
> >
> > Reviewed-by: Bart Van Assche
>
> For the record
On 10/30/18 10:42 AM, Jens Axboe wrote:
> On 10/30/18 10:02 AM, Keith Busch wrote:
>> On Tue, Oct 30, 2018 at 09:18:05AM -0600, Jens Axboe wrote:
>>> On 10/30/18 9:08 AM, Keith Busch wrote:
On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote:
> The sum of the set can't exceed the nv
On 30/10/2018 17:49, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_ring+33]
> RIP: ff
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
Typical call stack involving panic -
#8 page_fault at 8175936f
[exception RIP: blkif_free_ring+33]
RIP: a0149491 RSP: 8804f7673c08 RFLAGS: 00010292
.
On 10/30/18 10:02 AM, Keith Busch wrote:
> On Tue, Oct 30, 2018 at 09:18:05AM -0600, Jens Axboe wrote:
>> On 10/30/18 9:08 AM, Keith Busch wrote:
>>> On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote:
The sum of the set can't exceed the nvecs passed in, the nvecs passed in
should
On 10/30/2018 3:39 AM, Roger Pau Monné wrote:
On Mon, Oct 29, 2018 at 11:31:56AM -0700, Manjunath Patil wrote:
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
Typical call stack involving panic -
#8 page_fault at 81
Thank you Juergen for your comments.
I will soon send v2 patch.
-Thanks,
Manjunath
On 10/30/2018 12:04 AM, Juergen Gross wrote:
On 29/10/2018 19:31, Manjunath Patil wrote:
info->nr_rings isn't adjusted in case of ENOMEM error from
negotiate_mq(). This leads to kernel panic in error path.
Typi
On Tue, Oct 30, 2018 at 09:18:05AM -0600, Jens Axboe wrote:
> On 10/30/18 9:08 AM, Keith Busch wrote:
> > On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote:
> >> The sum of the set can't exceed the nvecs passed in, the nvecs passed in
> >> should be the less than or equal to nvecs. Granted
On Tue, Oct 30, 2018 at 08:02:55AM -0700, Bart Van Assche wrote:
> Details about how the build fails on 32-bit systems would have been welcome
> in the commit message. Anyway:
>
> Reviewed-by: Bart Van Assche
For the record, here's the failure. It's the usual incomprehensible
C++ error reportin
On 10/30/18, 8:14 AM, "Masato Suzuki" wrote:
Allow the creation of conventional zones by adding the zone_nr_conv
configuration attribute. This new attribute is used only for zoned devices
and indicates the number of conventional zones to create. The default value
is 0. Since host-
On 10/30/18 9:08 AM, Keith Busch wrote:
> On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote:
>> The sum of the set can't exceed the nvecs passed in, the nvecs passed in
>> should be the less than or equal to nvecs. Granted this isn't enforced,
>> and perhaps that should be the case.
>
> T
On Tue, Oct 30, 2018 at 08:53:37AM -0600, Jens Axboe wrote:
> The sum of the set can't exceed the nvecs passed in, the nvecs passed in
> should be the less than or equal to nvecs. Granted this isn't enforced,
> and perhaps that should be the case.
That should at least initially be true for a prope
On Tue, 2018-10-30 at 10:36 -0400, Theodore Ts'o wrote:
> Signed-off-by: Theodore Ts'o
> ---
> src/discontiguous-io.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/discontiguous-io.cpp b/src/discontiguous-io.cpp
> index 5e0ee0f..f51a305 100644
> --- a/src/discont
Hello,
syzbot found the following crash on:
HEAD commit:11743c56785c Merge tag 'rpmsg-v4.20' of git://github.com/a..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1512119940
kernel config: https://syzkaller.appspot.com/x/.config?x=93932074d01b4a5
das
On 10/30/18 8:45 AM, Keith Busch wrote:
> On Tue, Oct 30, 2018 at 08:36:35AM -0600, Jens Axboe wrote:
>> On 10/30/18 8:26 AM, Keith Busch wrote:
>>> On Mon, Oct 29, 2018 at 10:37:35AM -0600, Jens Axboe wrote:
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index f4f29b9d90ee..2
On Tue, Oct 30, 2018 at 08:36:35AM -0600, Jens Axboe wrote:
> On 10/30/18 8:26 AM, Keith Busch wrote:
> > On Mon, Oct 29, 2018 at 10:37:35AM -0600, Jens Axboe wrote:
> >> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
> >> index f4f29b9d90ee..2046a0f0f0f1 100644
> >> --- a/kernel/irq/af
Signed-off-by: Theodore Ts'o
---
src/discontiguous-io.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/discontiguous-io.cpp b/src/discontiguous-io.cpp
index 5e0ee0f..f51a305 100644
--- a/src/discontiguous-io.cpp
+++ b/src/discontiguous-io.cpp
@@ -251,7 +251,7 @@ int mai
On 10/30/18 8:26 AM, Keith Busch wrote:
> On Mon, Oct 29, 2018 at 10:37:35AM -0600, Jens Axboe wrote:
>> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>> index f4f29b9d90ee..2046a0f0f0f1 100644
>> --- a/kernel/irq/affinity.c
>> +++ b/kernel/irq/affinity.c
>> @@ -180,6 +180,7 @@ irq_cre
On Mon, Oct 29, 2018 at 10:37:35AM -0600, Jens Axboe wrote:
> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
> index f4f29b9d90ee..2046a0f0f0f1 100644
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -180,6 +180,7 @@ irq_create_affinity_masks(int nvecs, const struct
> i
On 10/30/18 3:41 AM, Ming Lei wrote:
> On Mon, Oct 29, 2018 at 09:04:33AM -0600, Jens Axboe wrote:
>> On 10/29/18 8:50 AM, Jens Axboe wrote:
>>> On 10/29/18 6:00 AM, Ming Lei wrote:
On Thu, Oct 25, 2018 at 03:10:11PM -0600, Jens Axboe wrote:
> The first round of this went into 4.20-rc, but
From: Colin Ian King
Trivial fix to clean up an indentation issue, remove tabs
Signed-off-by: Colin Ian King
---
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
inde
On Mon, Oct 29, 2018 at 11:31:56AM -0700, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_r
On Mon, Oct 29, 2018 at 09:04:33AM -0600, Jens Axboe wrote:
> On 10/29/18 8:50 AM, Jens Axboe wrote:
> > On 10/29/18 6:00 AM, Ming Lei wrote:
> >> On Thu, Oct 25, 2018 at 03:10:11PM -0600, Jens Axboe wrote:
> >>> The first round of this went into 4.20-rc, but we've still some of
> >>> them pending.
On Tue, Oct 30, 2018 at 02:40:15AM +, Balbir Singh wrote:
> I ran into a bug where after hibernation due to incompatible
> backends, the block driver returned BLK_STS_NOTSUPP, with the
> current message it's hard to find out what the command flags
> were. Adding req->cmd_flags help make the pro
On Mon, Oct 29, 2018 at 10:37:35AM -0600, Jens Axboe wrote:
> A driver may have a need to allocate multiple sets of MSI/MSI-X
> interrupts, and have them appropriately affinitized. Add support for
> defining a number of sets in the irq_affinity structure, of varying
> sizes, and get each set affini
On Mon, Oct 29, 2018 at 01:49:18PM -0600, Jens Axboe wrote:
> On 10/29/18 1:30 PM, Jens Axboe wrote:
> > On 10/29/18 1:27 PM, Bart Van Assche wrote:
> >> On Mon, 2018-10-29 at 10:37 -0600, Jens Axboe wrote:
> >>> void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
> >>> {
> >>>
On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote:
> LGTM, for both:
I also have this one on top as requested by Martin. The core block
bidi support is unfortunately also used by bsg-lib, although it is
not anywhere near as invasive. But that is another argument for
looking into moving
Allow the creation of conventional zones by adding the zone_nr_conv
configuration attribute. This new attribute is used only for zoned devices
and indicates the number of conventional zones to create. The default value
is 0. Since host-managed zoned block devices must always have at least one
seque
On 29/10/2018 19:31, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_ring+33]
> RIP: ff
80 matches
Mail list logo
