On 12/7/18 8:20 PM, Martin K. Petersen wrote:
>
> Jens,
>
> This went in through your tree. Can you please pick this fix up?
Yep, applied, thanks Dan.
--
Jens Axboe
q_complete_request(cmd->request)))
>> +clear_bit(__SCMD_COMPLETE, >flags);
>> }
>
> This looks a little odd to me. If we didn't complete the command
> someone else did. Why would we clear the bit in this case?
It's strictly for the fake timeout, it didn't complete it, it just
ignored it. This is an artifact of the weird way that works.
--
Jens Axboe
On 10/26/18 10:06 AM, Benjamin Block wrote:
> On Thu, Oct 25, 2018 at 05:12:59PM -0600, Jens Axboe wrote:
>> On 10/23/18 12:07 PM, Jens Axboe wrote:
>>> On 10/23/18 11:40 AM, Benjamin Block wrote:
>>>>
>>>> So I tried 4.19.0 with only the two patches from
On 10/23/18 12:07 PM, Jens Axboe wrote:
> 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:
&
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-blo
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
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/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
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: l
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(-)
diff --git
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 --git a/drivers
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 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_d
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, but
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 <ax...@kernel.dk> wrote:
>>>> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>>&g
On 5/23/18 2:52 PM, Kees Cook wrote:
> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <ax...@kernel.dk> 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
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 clearin
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 <ax...@kernel.dk> wrote:
>> On May 22, 2018, at 5:31 PM, Kees Cook <keesc...@chromium.org> wrote:
>>>
>>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <ax...@kernel.d
On May 22, 2018, at 5:31 PM, Kees Cook <keesc...@chromium.org> wrote:
>
>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axbo
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 nice to
bjecting 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 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
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 <mawil...@microsoft.com>
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is
ght 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(>tag_set, scsi_host_check_in_flight,
>> _flight);
>> return in_flight.cnt + atomic_read(>host_busy);
>>
>> The
q case needs
to be
blk_mq_tagset_busy_iter(>tag_set, scsi_host_check_in_flight,
_flight);
return in_flight.cnt + atomic_read(>host_busy);
The atomic read is basically free, once we get rid of the dirty of that
variable on each IO.
--
Jens Axboe
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
of DMA, 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 <ax...@kernel.dk>
--
Jens Axboe
uct attribute *default_attrs[] = {
_requests_entry.attr,
_ra_entry.attr,
@@ -714,6 +741,7 @@ static struct attribute *default_attrs[] = {
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
_sample_time_entry.attr,
#endif
+ _timeout_entry.attr,
NULL,
};
--
Jens Axboe
CSI. 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 <ax...@kernel.dk> ha
>> scritto:
>>
>> On 4/17/18 3:48 PM, Jens Axboe wrote:
>>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>>> On Tue, Ap
On 4/17/18 5:06 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 3:57 PM, Jens Axboe <ax...@kernel.dk> 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 <ax...@kernel.dk
On 4/17/18 4:57 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe <ax...@kernel.dk> 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
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 <ax...@kernel.dk> wrote:
>>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chro
On 4/17/18 3:47 PM, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe <ax...@kernel.dk> wrote:
>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chromium.org> wrote:
>>>> I see el
s to also check the RQF_ELVPRIV flag, but I'll leave 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
if (rq->elv.icq) {
> put_io_context(rq->elv.icq->ioc);
> - rq->elv.icq = NULL;
> + memset(>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
>>
>> WTF is this addl?
>
> What are the chances? :P Two ++ statements in a 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
struct 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
-by: Jens Axboe <ax...@kernel.dk>
---
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
w.mail-archive.com/linux-block@vger.kernel.org/msg20209.html.
Yeah, I forgot the link in my reply, thanks.
--
Jens Axboe
--
Jens Axboe
Thanks 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.
>>
I'd 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
at 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
ss 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
at least HPSA/virtio-scsi are found broken with v4.15+.
>
> The 7th & 8th patch fixes HPSA's IO issue which is caused by the reply
> queue selection algorithem.
>
> Laurence has verified 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, an
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.
>>
>>
fter any in-flight IO is
> completed 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
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
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
t 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, , gfp_mask, copy);
> That 'ret' was being overridden when that function failed.
Thanks, applied.
--
Jens Axboe
have 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
> 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
t should 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
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 do
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
y 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:
>>>>>
, it often means there isn't pending request not
> completed. So if that is true, your hang is _not_ related with RESTART.
You need to check sched_tags as well. It could still be a restart race
or problem, if tags is empty but sched_tags has busy bits.
--
Jens Axboe
On 11/07/2017 03:34 PM, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 15:06 -0700, Jens Axboe wrote:
>> Just to keep everyone in the loop, this bug is not new to
>> for-4.15/block, nor is it new to the current 4.14-rc or 4.13. So it's
>> probably different to what Bart is hi
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:
>>> On 11/07/2017 09:20 AM, Bart Van Assche wrote:
>>>> On Tue, 2017-11-07 at 10:11 +0800, Ming Lei wrote:
>>>>> If
On 11/07/2017 10:10 AM, Jens Axboe wrote:
> On 11/07/2017 09:29 AM, Jens Axboe wrote:
>> On 11/07/2017 09:20 AM, Bart Van Assche wrote:
>>> On Tue, 2017-11-07 at 10:11 +0800, Ming Lei wrote:
>>>> If you can reproduce, please provide me at least the following log
>
On 11/07/2017 09:29 AM, Jens Axboe wrote:
> On 11/07/2017 09:20 AM, Bart Van Assche wrote:
>> On Tue, 2017-11-07 at 10:11 +0800, Ming Lei wrote:
>>> If you can reproduce, please provide me at least the following log
>>> first:
>>>
>>> find /sys/ker
es. This is with shared tags as well. So if you still see the failure
case with the current tree AND the above patch, then I'll try and get
a test case setup that hits it too so we can get to the bottom of this.
--
Jens Axboe
it for 4.15.
Bart, does this fix your hang?
--
Jens Axboe
On 11/02/2017 09:01 AM, Bart Van Assche wrote:
> On Thu, 2017-11-02 at 08:27 -0600, Jens Axboe wrote:
>> On 11/02/2017 05:19 AM, Arnd Bergmann wrote:
>>> After the cdrom cleanup, I get randconfig warnings for some configurations:
>>>
>>> warning: (BLK_DEV_IDEC
ependency for both drivers. The other
> drivers that select 'CDROM' already have this and don't need a change.
Thanks Arnd, applied.
--
Jens Axboe
previous
>> ones.
>
> I don't mind taking them through SCSI if Jens agrees.
I'm fine with that, as long as the last issue Benjamin brought up has
been fixed up.
--
Jens Axboe
On 10/17/2017 05:40 PM, Bart Van Assche wrote:
> On Tue, 2017-10-17 at 17:28 -0600, Jens Axboe wrote:
>> On 10/17/2017 05:26 PM, Bart Van Assche wrote:
>>> It is known that during the resume following a hibernate, especially when
>>> using an md RAID1 array cre
greatly prefer if we had some folks that have
tested and verified it.
--
Jens Axboe
1 - 100 of 692 matches
Mail list logo
