We don't do anything with it, that's just the legacy path.
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3f91c6e5b17a..4c82dc44d4d8 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -51
This will ease in the conversion to blk-mq, where we can't set
a timeout handler after queue init.
Cc: Johannes Thumshirn
Cc: Benjamin Block
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
block/bsg-lib.c | 3 ++-
drivers/scsi/scsi_transport_fc.c
Convert from the old request_fn style driver to blk-mq.
Cc: David Miller
Signed-off-by: Jens Axboe
---
drivers/block/sunvdc.c | 149 +++--
1 file changed, 98 insertions(+), 51 deletions(-)
diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c
index
. And then people see that, and do the same. It's a bit
frustrating. I like to be able to see the SOB chain in a patch, and if
it's intermingled with other things, it's much harder to read. At least
for me.
I'll continue fixing these up, but I do hope that at least the regulars
on the block side use the proper formatting.
--
Jens Axboe
On 10/24/18 6:02 AM, Jens Axboe wrote:
> On 10/24/18 5:52 AM, Jens Axboe wrote:
>> On 10/24/18 5:30 AM, Jens Axboe wrote:
>>> On 10/24/18 5:19 AM, Christoph Hellwig wrote:
>>>> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote:
>>>>> JFYI, I
On 10/24/18 5:52 AM, Jens Axboe wrote:
> On 10/24/18 5:30 AM, Jens Axboe wrote:
>> On 10/24/18 5:19 AM, Christoph Hellwig wrote:
>>> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote:
>>>> JFYI, I also reordered the series to make it correct. You can apply
On 10/24/18 5:30 AM, Jens Axboe wrote:
> On 10/24/18 5:19 AM, Christoph Hellwig wrote:
>> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote:
>>> JFYI, I also reordered the series to make it correct. You can apply
>>> this one:
>>>
>>> http:
On 10/24/18 5:19 AM, Christoph Hellwig wrote:
> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote:
>> JFYI, I also reordered the series to make it correct. You can apply
>> this one:
>>
>> http://git.kernel.dk/cgit/linux-block/
On 10/23/18 11:40 AM, Benjamin Block wrote:
> On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote:
>> On 10/22/18 4:03 AM, Benjamin Block wrote:
>>> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
>>>
>>> Ok so, that gets past the stage wh
e.
2) The ordering of the signed-off-by. Someone told me that this is
patchwork, but I absolutely hate it. SOB should go last, not before
the reviewed-by. I fixed that up too.
--
Jens Axboe
On 10/22/18 9:21 AM, Benjamin Block wrote:
> On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote:
>> On 10/22/18 4:03 AM, Benjamin Block wrote:
>>> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
>>>> On 10/19/18 9:01 AM, Benjamin Block wrote:
>&
On 10/22/18 4:03 AM, Benjamin Block wrote:
> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
>> On 10/19/18 9:01 AM, Benjamin Block wrote:
>>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
>>>> On 10/17/18 9:55 AM, Benjamin Block wrote:
>&
On 10/19/18 9:57 AM, Benjamin Block wrote:
> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
>> On 10/19/18 9:01 AM, Benjamin Block wrote:
>>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
>>>> On 10/17/18 9:55 AM, Benjamin Block wrote:
>&
On 10/19/18 9:01 AM, Benjamin Block wrote:
> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
>> On 10/17/18 9:55 AM, Benjamin Block wrote:
>>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
>>>> Requires a few changes to the FC transpo
On 10/18/18 2:58 PM, Ondrej Zary wrote:
> On Thursday 18 October 2018 22:28:35 Jens Axboe wrote:
>> On 10/18/18 2:22 PM, Ondrej Zary wrote:
>>> On Thursday 18 October 2018 22:10:31 Jens Axboe wrote:
>>>> On 10/18/18 2:04 PM, Ondrej Zary wrote:
>>>>> On
On 10/18/18 2:22 PM, Ondrej Zary wrote:
> On Thursday 18 October 2018 22:10:31 Jens Axboe wrote:
>> On 10/18/18 2:04 PM, Ondrej Zary wrote:
>>> On Thursday 18 October 2018 21:59:09 Jens Axboe wrote:
>>>> On 10/18/18 1:55 PM, Ondrej Zary wrote:
>>>>> On
On 10/18/18 2:04 PM, Ondrej Zary wrote:
> On Thursday 18 October 2018 21:59:09 Jens Axboe wrote:
>> On 10/18/18 1:55 PM, Ondrej Zary wrote:
>>> On Thursday 18 October 2018 20:58:57 Jens Axboe wrote:
>>>> On 10/18/18 12:34 PM, Ondrej Zary wrote:
>>>>>
On 10/18/18 1:55 PM, Ondrej Zary wrote:
> On Thursday 18 October 2018 20:58:57 Jens Axboe wrote:
>> On 10/18/18 12:34 PM, Ondrej Zary wrote:
>>> Hello,
>>> aha1542 works fine in 4.17 but crashes in 4.18. It's hard to bisect because
>>> of many commits that
It looks like the ISA bioset pool isn't being initialized. You should
have messages like this in your dmesg:
isa pool size: 16 pages
(which you do), but also something on the bioset section. Do you have
this one:
pool size: 64 pages
as well?
--
Jens Axboe
On 10/17/18 12:08 PM, Douglas Gilbert wrote:
> On 2018-10-17 11:55 a.m., Benjamin Block wrote:
>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
>>> Requires a few changes to the FC transport class as well.
>>>
>>> Cc: Johannes Thumshirn
>&g
On 10/17/18 9:55 AM, Benjamin Block wrote:
> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
>> Requires a few changes to the FC transport class as well.
>>
>> Cc: Johannes Thumshirn
>> Cc: Benjamin Block
>> Cc: linux-scsi@vger.kernel
m.
>
> The 'myrs' driver supports the newer (V2) firmware interface, which is
> SCSI based and doesn't need the translation layer.
>
> And the weird proc interface from DAC960 has been converted to sysfs
> attributes.
>
> Tested with eXtremeRAID 1100 (for V1 Firmware) and Mylex AcceleRAID 170
> (for V2 Firmware).
Applied 3/3 in for-4.20/block
--
Jens Axboe
Firmware) and Mylex AcceleRAID 170
> (for V2 Firmware).
Martin, are you taking the two new drivers? Then I'll queue up the
old driver removal.
--
Jens Axboe
>> and your reviewed-by (and mine).
>
>> Martin, is this queued up?
>
> Nope, I was waiting for Hannes to address the feedback from Bart and
> Johannes.
Hannes, please get this resent with Johannes comment addressed. Bart's
comment should no longer be relevant.
You can add his and mine reviewed-by, as per previous email.
--
Jens Axboe
On 10/16/18 8:55 AM, Bart Van Assche wrote:
> On Tue, 2018-10-16 at 08:31 -0600, Jens Axboe wrote:
>> This check is only viable for non scsi-mq. Since that is going away,
>> kill this legacy check.
>>
>> Cc: Bart Van Assche
>> Cc: Parav Pandit
>> Cc: linu
Requires a few changes to the FC transport class as well.
Cc: Johannes Thumshirn
Cc: Benjamin Block
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
block/bsg-lib.c | 102 +--
drivers/scsi/scsi_transport_fc.c | 61 ++
2
We just need to free the request here. Additionally, this is
currently wrong for a queue that's using MQ currently, it'll
crash.
Cc: Doug Gilbert
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
drivers/scsi/sg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Would be nice to fix up the SCSI midlayer instead, but this will
do for now.
Cc: Christoph Hellwig
Cc: Satish Kharat
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
drivers/scsi/fnic/fnic_scsi.c | 61 +++
1 file changed, 12 insertions(+), 49
This is currently wrong since it isn't dependent on if we're using
mq or not. At least now it'll be correct when we force mq.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
drivers/scsi/osd/osd_initiator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This check is only viable for non scsi-mq. Since that is going away,
kill this legacy check.
Cc: Bart Van Assche
Cc: Parav Pandit
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
drivers/infiniband/ulp/srp/ib_srp.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers
On 10/14/18 6:45 PM, Damien Le Moal wrote:
> Jens,
>
> On 2018/10/14 7:43, Jens Axboe wrote:
>> On 10/12/18 4:08 AM, Damien Le Moal wrote:
>>> This series improves zoned block device support (reduce overhead) and
>>> introduces many simplifications to
nt to funnel this series? 1-3 look separate, so perhaps they
should go through the scsi tree. Then I can take the rest. Or do some
of the later ones depend on 1-3 being in, in terms of applying cleanly?
I can also take all of them, looks like only #3 needs a SCSI ack.
--
Jens Axboe
scsi&r=3&b=201810&w=2.
I'm guessing it's just too big. I got it, but probably due to the CC.
--
Jens Axboe
On 8/24/18 6:21 PM, Jens Axboe wrote:
> On 8/24/18 5:16 PM, Ming Lei wrote:
>> Hi,
>>
>> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> Was testing other things today, but ended up with this:
>>>
>>>
On 8/24/18 5:16 PM, Ming Lei wrote:
> Hi,
>
> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Was testing other things today, but ended up with this:
>>
>> # echo "write through" > /sys/block/sde/device/scsi_disk/4
On 8/24/18 4:20 PM, Jens Axboe wrote:
> Hi,
>
> Was testing other things today, but ended up with this:
>
> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>
> hanging. Looking closer, the request is successfully queued and the
>
scsi_mq
so I'm guessing it's some one-off or similar. I won't have more time
to look into this today, so might have to wait until Monday.
--
Jens Axboe
On 6/20/18 5:52 AM, Maurizio Lombardi wrote:
> Hi Jens,
>
> Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
>> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>>>
>>>
>>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>>>> It's been many years
On 5/23/18 3:20 PM, Randy Dunlap wrote:
> On 05/23/2018 02:14 PM, Jens Axboe wrote:
>> On 5/23/18 2:52 PM, Kees Cook wrote:
>>> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
>>>> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>>>>> On Wed, May 2
On 5/23/18 2:52 PM, Kees Cook wrote:
> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
>> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
>>>>> Should I move to code to a new drivers/scsi/scsi_sense.c
On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>
>
> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>> It's been many years, but back in the day the program writing the cd
>> would eject the disc once done. This of course forces a reload of
>> the toc and clearing o
On 5/23/18 8:25 AM, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to
>>> drivers/scsi/Makefile as:
>>>
>>> obj-$(CONFIG_BLK_SCSI_REQUEST)+=
On 5/22/18 5:49 PM, Kees Cook wrote:
> On Tue, May 22, 2018 at 4:42 PM, Jens Axboe wrote:
>> On May 22, 2018, at 5:31 PM, Kees Cook wrote:
>>>
>>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>>>> On 5/22/18 1:13 PM, Christoph Hellwig wro
On May 22, 2018, at 5:31 PM, Kees Cook wrote:
>
>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote:
>>>> I think Martin and Chr
On 5/22/18 1:13 PM, Christoph Hellwig wrote:
> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe wrote:
>> I think Martin and Christoph are objecting to moving the code to
>> block/scsi_ioctl.h. I don't care too much about where the code is, but
>> think it would be ni
block/scsi_ioctl.h. I don't care too much about where the code is, but
think it would be nice to have the definitions in a separate header. But
if they prefer just pulling in all of SCSI for it, well then I guess
it's pointless to move the header bits. Seems very heavy handed to me,
though.
--
Jens Axboe
of
the toc and clearing of the flag. What program is this? Seems like
it should probably eject when it's done.
There are many commands that will indicate writing to the device, but
not cause anything that should force a reload. A mode select comes to
mind.
--
Jens Axboe
On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is more used than
>> the percpu_
g = iscsit_wait_for_tag(se_sess, state, &cpu);
> if (tag < 0)
> return NULL;
Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.
sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.
Rest looks fine to me.
--
Jens Axboe
On 4/27/18 9:48 AM, Bart Van Assche wrote:
> On Fri, 2018-04-27 at 09:39 -0600, Jens Axboe wrote:
>> blk_mq_tagset_busy_iter(&shost->tag_set, scsi_host_check_in_flight,
>> &in_flight);
>> return in_flight.cnt + atomic_read(&shost->host_bu
annes was concerned
about (older drivers doing internal command issue), I would suggest that those
drivers get instrumented to include a inc/dec of the host busy count for
internal commands that bypass the normal tagging. That means the mq case needs
to be
blk_mq_tagset_busy_iter(&shost->tag_
On 4/26/18 1:20 AM, Christoph Hellwig wrote:
> On Tue, Apr 24, 2018 at 08:02:56PM -0600, Jens Axboe wrote:
>> On 4/24/18 12:16 PM, Christoph Hellwig wrote:
>>> ide_toggle_bounce did select various strange block bounce limits, including
>>> not bouncing at all as soon as
the issue was that the PIO code could not handle
highmem. That's not the case anymore, so this should be fine.
Reviewed-by: Jens Axboe
--
Jens Axboe
.store = queue_timeout_store,
+};
+
static struct attribute *default_attrs[] = {
&queue_requests_entry.attr,
&queue_ra_entry.attr,
@@ -714,6 +741,7 @@ static struct attribute *default_attrs[] = {
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
&throtl_sample_time_entry.attr,
#endif
+ &queue_timeout_entry.attr,
NULL,
};
--
Jens Axboe
for SCSI. In
retrospect, it should have been under queue/ from the start, now we'll
end up with duplicate entries for SCSI.
--
Jens Axboe
On 4/18/18 3:08 AM, Paolo Valente wrote:
>
>
>> Il giorno 18 apr 2018, alle ore 00:57, Jens Axboe ha
>> scritto:
>>
>> On 4/17/18 3:48 PM, Jens Axboe wrote:
>>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>>> On Tue, Apr 17, 2018 at 2:39 PM, Jen
On 4/17/18 5:06 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 3:57 PM, Jens Axboe wrote:
>> On 4/17/18 3:48 PM, Jens Axboe wrote:
>>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>>> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
>>>>> On 4/17/18 3:
On 4/17/18 4:57 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe wrote:
>> On 4/17/18 3:42 PM, Kees Cook wrote:
>>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>>> may attempt to read rq->elv fields. When reques
On 4/17/18 3:48 PM, Jens Axboe wrote:
> On 4/17/18 3:47 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
>>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote:
>>>>> I see elv.priv
On 4/17/18 3:47 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote:
>>>> I see elv.priv[1] assignments made in a few places -- is it possi
eave that
> to Paolo to figure out. Also, my Fixes line is kind of a best-guess. This
> is where icq was originally wiped, so it seemed as good a commit as any.
Yeah, that's probably a bit too broad for fixes :-)
--
Jens Axboe
put_io_context(rq->elv.icq->ioc);
> - rq->elv.icq = NULL;
> + memset(&rq->elv, 0, sizeof(rq->elv));
> }
> }
This looks like a BFQ problem, this should not be necessary. Paolo,
you're calling your own prepare request handler from the insert
as well, and your prepare request does nothing if rq->elv.icq == NULL.
--
Jens Axboe
row separate by a
> collapsed goto. FML. :)
>
> ...
> bfqq->dispatched++;
> goto inc_in_driver_start_rq;
> ...
> inc_in_driver_start_rq:
> bfqd->rq_in_driver++;
> ...
>
> And there's the 0x100 (256):
>
> struct bfq_queue {
> ...
> intdispatched; /* 256 4 */
>
> So bfqq is corrupted somewhere... I'll keep digging. I hope you're all
> enjoying my live debugging transcript. ;)
It has to be the latter bfqq->dispatched increment, as those are
transient (and bfqd is not).
Adding Paolo.
--
Jens Axboe
t elevator_queue is allocated when the scheduler is attached
to the queue. This can get freed and allocated if you switch
the scheduler on a queue, otherwise it persists until the queue
is torn down (and the scheduler data is freed).
> Regardless, I'll check for elevator data changing too...
It should not change unless you switch IO schedulers. If you're
using BFQ and not switching, then it won't change.
--
Jens Axboe
Signed-off-by: Jens Axboe
---
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 0cf25d789d05..3f3cb72e0c0c 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -587,18 +587,28 @@ static int sr_block_ioctl(struct block_device *bdev,
fmode_t mode, unsigned cmd,
static un
On 4/11/18 10:14 AM, Jan Kara wrote:
> Hello,
>
> On Wed 11-04-18 08:11:13, Jens Axboe wrote:
>> On 4/11/18 7:58 AM, Jan Kara wrote:
>>> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>>>> Been running some tests and I keep running into issues with hotplug.
On 4/11/18 7:58 AM, Jan Kara wrote:
> Hi,
>
> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>> Been running some tests and I keep running into issues with hotplug.
>> This looks similar to what Bart posted the other day, but it looks
>> more deeply rooted than just hav
> https://www.mail-archive.com/linux-block@vger.kernel.org/msg20209.html.
Yeah, I forgot the link in my reply, thanks.
--
Jens Axboe
1ff0c8bb38
--
Jens Axboe
anks for debugging this. However, the scsi code looks a bit dangerous,
if it assumes that ->sense_len is >= SCSI_SENSE_BUFFERSIZE. I think the
correct fix would be to fix that assumption, and ensure that the path
of sr is correctly setting sense_len.
--
Jens Axboe
On 3/28/18 9:13 PM, Zephaniah E. Loss-Cutler-Hull wrote:
> On 03/28/2018 06:02 PM, Jens Axboe wrote:
>> On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote:
>>> I am not subscribed to any of the lists on the To list here, please CC
>>> me on any replies.
>>
guess that this is dying inside
> blkg_rwstat_add, which calls percpu_counter_add_batch, which is what RIP
> is pointing at.
Leaving the whole thing here for Paolo - it's crashing off insertion of
a request coming out of SG_IO. Don't think we've seen this BFQ failure
case before.
You can mitigate this by switching the scsi-mq devices to mq-deadline
instead.
--
Jens Axboe
rivers using this API accordingly.
Looks good to me, I'll queue it up for 4.17.
--
Jens Axboe
ng that Martin will eventually queue this up. But probably
for 4.17, then we can always flag it for a backport to stable once
it's been thoroughly tested.
--
Jens Axboe
onfusing, and also makes sure we can sanity check the requests
> we get. The current code will happily execute scsi commands against
> bsg-lib queues, and transport pass through against scsi nodes, without
> any indication to the driver that we are doing the wrong thing.
Applied for 4.17, thanks.
--
Jens Axboe
t task acquires the s_umount lock and then the sr_mutex_lock;
> the second task acquires the sr_mutex_lock and then the s_umount lock.
>
> This patch fixes the issue by moving check_disk_change() out of
> cdrom_open() and let the caller take care of it.
Looks good to me, applied.
--
Jens Axboe
data is provided, no obvious performance loss is observed when the whole
> hw queue depth is same.
GLOBAL implies that it's, strangely enough, global. That isn't really the
case. Why not call this BLK_MQ_F_HOST_TAGS or something like that? I'd
welcome better names, but global doesn't seem to be a great choice.
BLK_MQ_F_SET_TAGS?
--
Jens Axboe
fied that this patch makes HPSA working with the linus
> tree with this patchset.
Do you have any performance numbers for this patchset? I'd be curious
to know how big the hit is.
--
Jens Axboe
On 1/30/18 8:27 PM, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 20:22 -0700, Jens Axboe wrote:
>> On 1/30/18 8:21 PM, Bart Van Assche wrote:
>>> On Tue, 2018-01-30 at 20:17 -0700, Jens Axboe wrote:
>>>> BLK_STS_RESOURCE should always be safe to return, and i
On 1/30/18 8:21 PM, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 20:17 -0700, Jens Axboe wrote:
>> BLK_STS_RESOURCE should always be safe to return, and it should work
>> the same as STS_DEV_RESOURCE, except it may cause an extra queue
>> run.
>>
>>
ted via blk_mq_sched_restart()
>
> 3) if SCHED_RESTART is set concurently in context because of
> BLK_STS_RESOURCE, blk_mq_delay_run_hw_queue() will cover the above two
> cases and make sure IO hang can be avoided.
>
> One invariant is that queue will be rerun if SCHED_RESTART is set.
Applied, thanks.
--
Jens Axboe
ers easier to
> read or to implement. So why is this patch considered useful?
It does fix the run bug on global resources, I'm assuming you mean
it doesn't fix any EXTRA bugs compared to just use the delayed
run?
--
Jens Axboe
rce. For resources of wider scope, allocation
failure can happen without having pending IO. This means that we can't
rely on request completions freeing these resources, as IO may not be in
flight. Examples of that are kernel memory allocations, DMA mappings, or
any other system wide resources.
--
Jens Axboe
On 1/29/18 4:46 PM, James Bottomley wrote:
> On Mon, 2018-01-29 at 14:00 -0700, Jens Axboe wrote:
>> On 1/29/18 1:56 PM, James Bottomley wrote:
>>>
>>> On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote:
>>> [...]
>>>>
>>>> 2. When to e
to iron out the last kinks with it being off
by default, I think we should attempt to flip the switch again
for 4.16.
--
Jens Axboe
useful error.
>
> Patch below does not show this (unchanged) line:
>ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
> That 'ret' was being overridden when that function failed.
Thanks, applied.
--
Jens Axboe
a block dependency for 4.16. But it doesn't matter much.
Completely up to you - I already have 1-5, I can add 6/7 as well, or
just can do it in your tree. Let me know what you prefer.
--
Jens Axboe
vers into
> lib/scatterlist.c. Please consider this patch series for kernel v4.16.
Thanks Bart, applied for 4.16.
--
Jens Axboe
gt; path
> thanks to "mq-deadline" being aliased to "deadline".
>
> Comments are as always very much appreciated.
This looks OK for me for 4.16. I can grab all of them, or I can leave
the last two for Martin to apply if he prefers that, though that will
add a block tree dependency for SCSI.
Martin?
--
Jens Axboe
> ZBC blk-mq/scsi-mq support or if this is an acceptable solution.
I'll give it a thorough look-over on Monday.
--
Jens Axboe
that
> problem. These patches have been tested on top of the block layer for-next
> branch. Please consider these changes for kernel v4.15.
Applied, thanks Bart.
--
Jens Axboe
ld be removed. It'll just confuse
users and cause useless bug reports.
> Jens, this patch series still applies cleanly on top of your for-4.15/block
> branch. Are you fine with this patch series or do you perhaps want me to
> repost it with Oleksandr's Tested-by tag added to each patch?
Since you need to kill the warning anyway, let's get it respun.
--
Jens Axboe
t lib/list_debug.c:56
> __list_del_entry_valid+0x92/0xa0
> Call Trace:
> process_one_work+0x11b/0x660
> worker_thread+0x3d/0x3b0
> kthread+0x129/0x140
> ret_from_fork+0x27/0x40
Looks good to me, applied.
--
Jens Axboe
On 11/08/2017 11:22 AM, Laurence Oberman wrote:
> On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote:
>> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
>>> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
>>>> At this point, I have no idea what Bart
On 11/08/2017 08:59 AM, Ming Lei wrote:
> On Wed, Nov 08, 2017 at 02:20:41PM +0800, Ming Lei wrote:
>> On Tue, Nov 07, 2017 at 08:17:59PM -0700, Jens Axboe wrote:
>>> On 11/07/2017 08:12 PM, Ming Lei wrote:
>>>> On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wr
On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
>> At this point, I have no idea what Bart's setup looks like. Bart, it
>> would be REALLY helpful if you could tell us how you are reproducing
>> your hang. I don
On 11/07/2017 08:12 PM, Ming Lei wrote:
> On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wrote:
>> On 11/07/2017 06:03 PM, Ming Lei wrote:
>>> On Tue, Nov 07, 2017 at 03:06:31PM -0700, Jens Axboe wrote:
>>>> On 11/07/2017 10:36 AM, Jens Axboe wrote:
>>&g
configuration. My null_blk
test case is basically the same. But it would be nice if all of this was
out in the open, so everybody is clear on exactly what is being
run/tested.
However, where my trace is hung off getting a scheduler tag, yours seems
to be waiting on IO completion. So not the same fingerprint, which is
worrisome.
--
Jens Axboe
On 11/07/2017 07:58 PM, Ming Lei wrote:
> On Tue, Nov 07, 2017 at 07:55:32PM -0700, Jens Axboe wrote:
>> On 11/07/2017 05:39 PM, Ming Lei wrote:
>>> On Tue, Nov 07, 2017 at 04:20:08PM +, Bart Van Assche wrote:
>>>> On Tue, 2017-11-07 at 10:11 +0800, Ming Lei wro
On 11/07/2017 06:03 PM, Ming Lei wrote:
> On Tue, Nov 07, 2017 at 03:06:31PM -0700, Jens Axboe wrote:
>> On 11/07/2017 10:36 AM, Jens Axboe wrote:
>>> On 11/07/2017 10:10 AM, Jens Axboe wrote:
>>>> On 11/07/2017 09:29 AM, Jens Axboe wrote:
>>>>>
201 - 300 of 1039 matches
Mail list logo
