On 08/08/16 03:22, Peter Zijlstra wrote:
> That would be the exact scenario I drew a picture of, no? I'm still
> failing to see the hole there.
>
> Please draw a picture like that and illustrate the hole.
Hi Peter,
This is the sequence of which I think that it leads to the missed wakeup:
Task
On 08/08/16 07:09, Paolo wrote:
2) To provide per-process service guarantees, an I/O scheduler must
create per-process internal queues. BFQ and CFQ use I/O contexts to
achieve this goal. Is something like that (or exactly the same)
available also in blk-mq? If so, do you have any suggestion, or l
On 08/08/2016 09:20 AM, Oleg Nesterov wrote:
Do you use external modules during the testing?
Hello Oleg,
No external modules were loaded when I triggered the lockup I mentioned
in the patch description. Although the SRP test software I referred to
earlier can be run against the SCST SRP targ
On 08/23/16 13:42, Mikko Rapeli wrote:
> On Tue, Aug 23, 2016 at 02:28:19PM +0000, Bart Van Assche wrote:
>> On 08/23/16 06:57, Bart Van Assche wrote:
>>> On 08/22/16 11:32, Mikko Rapeli wrote:
>>>> - * uint32_t (*get_region_size)(struct dm_dirty_log *log);
>>&g
scsi/for-next'
>
> System booted fine when the below commit is reverted:
>
> commit 270065e92c317845d69095ec8e3d18616b5b39d5
> Author: Bart Van Assche
> Date: Thu Aug 3 14:40:14 2017 -0700
>
> scsi: scsi-mq: Always unprepare before requeuing a request
He
On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
> Linux-next booted with the below warnings on powerpc
>
> [ ... ]
>
> boot warnings:
> --
> kvm: exiting hardware virtualization
> [ cut here ]
> WARNING: CPU: 15 PID: 0 at block/blk-mq.c: __blk_mq_run
On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
> As of next-20170809, linux-next on powerpc boot hung with below trace
> message.
> [ ... ]
> System booted fine when the below commit is reverted:
Hello Abdul,
Can you check whether applying the following commit on top of next-20170809
fix
On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
> > > Linux-next booted with the below warnings on powerpc
> > >
> > >
On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote:
> On 08/16/2017 12:21 PM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
> > > As of next-20170809, linux-next on powerpc boot hung with below trace
> > > message.
> > >
&g
On Thu, 2017-08-17 at 15:18 +0530, Chaitra Basappa wrote:
> We analyzed this issue and could figure out it is not because of driver,
> its because the "sense" field of the 'struct scsi_request' is not being
> populated properly from the upper layer.
> And this "sense" member is being referenced in
On Thu, 2017-08-17 at 16:30 -0400, Steven Rostedt wrote:
> On Thu, 17 Aug 2017 12:24:39 -0400
> Waiman Long wrote:
>
> > On 08/17/2017 09:34 AM, Steven Rostedt wrote:
> > > On Wed, 16 Aug 2017 16:40:40 -0400
> > > Waiman Long wrote:
> > >
> > > > The lockdep code had reported the following uns
instead of "residua"? Anyway:
Reviewed-by: Bart Van Assche
On Mon, 2017-10-16 at 16:34 +0300, Michael S. Tsirkin wrote:
> I don't see how it'll help make things better. OTOH if the specific
> drivers are tagged in the makefile, they can be gradually moved out to
> staging or something to help trigger action.
Do you really want to move drivers like qla2xxx
On Mon, 2017-10-16 at 18:27 +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 16, 2017 at 01:57:35PM +0000, Bart Van Assche wrote:
> > On Mon, 2017-10-16 at 16:34 +0300, Michael S. Tsirkin wrote:
> > > I don't see how it'll help make things better. OTOH if the specific
>
On Mon, 2017-10-16 at 13:30 +0200, Hannes Reinecke wrote:
> On Fri, Oct 13, 2017 at 05:08:52PM +0000, Bart Van Assche wrote:
> > (+Himanshu Madhani)
> >
> > Himanshu, do you perhaps know whether it is safe to increase cmd_per_lun for
> > the qla2xxx initiator driver
Signed-off-by: Bart Van Assche
Cc: linux-s...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Michael S. Tsirkin
Cc: Christoph Hellwig
Cc: Leon Romanovsky
Cc: Andrew Morton
---
[v2]: Elaborated patch description
include/uapi/linux/types.h | 4
1 file c
On Mon, 2017-10-16 at 19:50 +0300, Michael S. Tsirkin wrote:
> Right but qla_nvme also triggers these warnings. That's the problem with
> disabling them tree-wide. To me it looks like the time we are spending
> arguing about work-arounds would be better spent just fixing the
> majority of the code.
On Mon, 2017-10-16 at 22:57 +0300, Michael S. Tsirkin wrote:
> On Mon, Oct 16, 2017 at 10:26:33AM -0700, Bart Van Assche wrote:
> > I think that this shows that the followed approach does not work,
> > probably because several driver authors do not use sparse. For
> > devel
On 10/16/17 23:38, Hannes Reinecke wrote:
Again, these are just some pre-defined values to avoid I/O starvation
when having several LUNs. _if_ we can guarantee I/O fairness between
several (hundreds!) devices all sharing the same tagspace we wouldn't
need these variables.
I think we already hav
On Sun, 2017-05-28 at 13:33 +0800, kernel test robot wrote:
> [ 207.874416] WARNING: CPU: 0 PID: 419 at block/blk-merge.c:674
> attempt_merge+0xd1/0x11a6
I will fix this by adding if (!q->mq_ops) in front of the lockdep_assert_held()
statement in attempt_merge().
Bart.
On Mon, 2017-10-30 at 17:04 -0700, Kees Cook wrote:
> On Fri, Oct 27, 2017 at 5:57 AM, Bart Van Assche
> wrote:
> > On Fri, 2017-10-27 at 02:19 -0700, Kees Cook wrote:
> > > In preparation for unconditionally passing the struct timer_list pointer
> > > to
> &
On Tue, 2017-10-31 at 13:20 -0400, Martin K. Petersen wrote:
> > That tree passed the iSCSI target tests I ran so feel free to add my
> > Reviewed-by and Tested-by to [PATCH v2] target/iscsi: Convert timers
> > to use timer_setup().
>
> Is that with your rebased patch from a few days ago?
Hello M
On Tue, 2017-10-31 at 18:03 +, Madhani, Himanshu wrote:
> On Oct 31, 2017, at 8:49 AM, Martin K. Petersen
> wrote:
> > > In preparation for unconditionally passing the struct timer_list
> > > pointer to all timer callbacks, switch to using the new timer_setup()
> > > and from_timer() to pass
On Mon, 2017-10-23 at 17:12 +0200, Roman Penyaev wrote:
> On Fri, Oct 20, 2017 at 10:05 PM, Bart Van Assche wrote:
> > Commit 6d8c6c0f97ad is something I came up with to fix queue lockups in the
> > SCSI and dm-mq drivers.
>
> You mean fairness? (some hctx get less am
On Thu, 2017-11-02 at 12:19 +0100, Arnd Bergmann wrote:
> After the cdrom cleanup, I get randconfig warnings for some configurations:
>
> warning: (BLK_DEV_IDECD && BLK_DEV_SR) selects CDROM which has unmet direct
> dependencies (BLK_DEV)
Hello Arnd,
Since Jens has already queued your patch it'
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_IDECD && BLK_DEV_SR) selects CDROM which has unmet direct
> > dependencies (BLK_DEV)
> >
>
On Mon, 2017-10-23 at 11:08 +0900, Byungchul Park wrote:
> On Sun, Oct 22, 2017 at 02:34:56PM +0000, Bart Van Assche wrote:
> > On Sat, 2017-10-21 at 11:23 +0900, Byungchul Park wrote:
> > > On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche
> > > wrote:
> > &
On Wed, 2017-10-25 at 16:10 +0200, Kees Cook wrote:
> However, maintainers: sorry to send this one -- it can't be merged
> yet, this uses timer_setup_on_stack() which is only in -next right
> now. If it looks okay, though, I can carry this in the timer tree.
Hello Kees,
Can you have a look at the
On Thu, 2017-10-26 at 10:24 +0200, Kees Cook wrote:
> On Wed, Oct 25, 2017 at 5:03 PM, Bart Van Assche
> wrote:
> > On Wed, 2017-10-25 at 16:10 +0200, Kees Cook wrote:
> > > However, maintainers: sorry to send this one -- it can't be merged
> > > yet, this u
On Fri, 2017-11-03 at 11:02 -0700, Andrew Morton wrote:
> Also, checkpatch says
>
> WARNING: use of in_atomic() is incorrect outside core kernel code
> #43: FILE: mm/memory.c:4491:
> + if (in_atomic())
>
> I don't recall why we did that, but perhaps this should be revisited?
Is the comment
On Fri, 2017-11-03 at 23:48 +0100, Arnd Bergmann wrote:
> When CDROM is enabled, but nothing else selects BLK_SCSI_REQUEST,
> we get this link error:
>
> cdrom.c:(.text+0x7a18): undefined reference to `scsi_cmd_blk_ioctl'
Hello Arnd,
Can you check whether this issue still occurs with Jens' for-4
On Wed, 2017-11-01 at 19:18 +, Madhani, Himanshu wrote:
> Hi Kees,
>
> > On Nov 1, 2017, at 11:46 AM, Kees Cook wrote:
> >
> > On Tue, Oct 31, 2017 at 12:13 PM, Kees Cook wrote:
> > > This breaks out the logical steps to convert the qla2xxx timers:
> > >
> > > 1) init_timer() -> setup_tim
On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote:
> Several false positives were reported, so I tried to fix them.
>
> It would be appreciated if you tell me if it works as expected, or let
> me know your opinion.
What I have been wondering about is whether the crosslock checking makes
sen
On Thu, 2017-10-19 at 10:57 +0900, Byungchul Park wrote:
> On Wed, Oct 18, 2017 at 02:29:56PM +0000, Bart Van Assche wrote:
> > On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote:
> > > Several false positives were reported, so I tried to fix them.
> > >
> >
On Thu, 2017-10-19 at 14:55 +0900, Byungchul Park wrote:
> Now the performance regression was fixed, re-enable
> CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS.
>
> Signed-off-by: Byungchul Park
> ---
> lib/Kconfig.debug | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Thu, 2017-10-19 at 17:34 +0200, Thomas Gleixner wrote:
> I really disagree with your reasoning completely
>
> 1) When lockdep was introduced more than ten years ago it was far from
>perfect and we spent a reasonable amount of time to improve it, analyze
>false positives and add the miss
On Wed, 2017-10-18 at 12:22 +0200, Roman Pen wrote:
> the patch below fixes queue stalling when shared hctx marked for restart
> (BLK_MQ_S_SCHED_RESTART bit) but q->shared_hctx_restart stays zero. The
> root cause is that hctxs are shared between queues, but 'shared_hctx_restart'
> belongs to the
On Thu, 2017-10-19 at 21:12 +0200, Thomas Gleixner wrote:
> And just for the record, I wasted enough of my time already to decode 'can
> not happen' dead locks where completions or other wait primitives have been
> involved. I rather spend time annotating stuff after analyzing it proper
> than chas
On Thu, 2017-10-19 at 13:33 -0700, Matthew Wilcox wrote:
> For example, the page lock is not annotatable with lockdep -- we return
> to userspace with it held, for heaven's sake! So it is quite easy for
> someone not familiar with the MM locking hierarchy to inadvertently
> introduce an ABBA deadl
On Wed, 2017-10-18 at 18:38 +0900, Byungchul Park wrote:
> Sometimes, we want to initialize completions with sparate lockdep maps
> to assign lock classes under control. For example, the workqueue code
> manages lockdep maps, as it can classify lockdep maps properly.
> Provided a function for that
On Fri, 2017-10-27 at 02:19 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Includes a fix for correcting an
> on-stack timer u
On 10/05/15 02:26, Rasmus Villemoes wrote:
- {0x041A, "Logical unit not ready, start stop unit command in "
-"progress"},
- {0x041B, "Logical unit not ready, sanitize in progress"},
- {0x041C, "Logical unit not ready, additional power use not yet "
-"granted"},
On 10/05/15 02:26, Rasmus Villemoes wrote:
struct error_info {
unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */
- const char * text;
+ unsigned short size;
};
Had you considered to use the type uint16_t instead of unsigned short ?
Bart.
--
To unsubscribe
On 10/15/2015 05:10 AM, Christoph Hellwig wrote:
This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT
commands.
Hello Christoph,
Can you explain why this functionality has been added to the sd driver
instead of the SCSI core ? Aren't persistent reservations a concept that
applie
On 10/22/2015 10:12 AM, Vitaly Kuznetsov wrote:
On some host errors storvsc module tries to remove sdev by scheduling a job
which does the following:
sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun);
if (sdev) {
scsi_remove_device(sdev);
scsi_device_put(sdev);
}
On 10/26/15 07:54, Peter Oberparleiter wrote:
Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
returns the value of that number instead of the number of bytes written.
This behavior can confuse programs expecting POSIX write() semantics.
Fix this by returning the number of bytes wr
On 10/03/15 23:18, Geliang Tang wrote:
BUG_ON() already contain an unlikely compiler flag. Drop it.
Signed-off-by: Geliang Tang
Reviewed-by: Bart Van Assche
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
On Fri, 2018-08-03 at 01:17 +0800, Ming Lei wrote:
> Not mentioning big CPU utilization is consumed unnecessarily for iterating
> over all queues even though there is only one active queue, is this fair from
> system view?
I hope that someone will come up some day with a better solution than the
l
This patch avoids that gcc reports the following when building with W=1:
lib/vsprintf.c:1941:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
switch (fmt[1]) {
^~
Fixes: ce4fecf1fe15 ("vsprintf: Add %p extension "%pOF" for device tree")
Sig
On Tue, 2018-08-14 at 17:39 +0200, Hannes Reinecke wrote:
> While I have considered having nvme_nvm_register_sysfs() returning a
> pointer I would then have to remove the 'static' declaration from the
> nvm_dev_attr_group_12/20.
> Which I didn't really like, either.
Hmm ... I don't see why the sta
On Wed, 2018-07-25 at 21:05 -0600, Jason Gunthorpe wrote:
> On Thu, Jul 26, 2018 at 10:55:53AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the rdma tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > net/sunrpc/xprtrdma/svc_rdma_rw.c: I
On 07/26/18 10:48, Jens Axboe wrote:
On 7/26/18 1:48 AM, Christoph Hellwig wrote:
On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index 86121a7a19b2..8c30ac7d8078 100644
--- a/drivers/nvme/target/rdma.c
+++ b
On Fri, 2018-07-13 at 15:29 +0200, Patrick Steinhardt wrote:
> When power management for SCSI is enabled and if a device uses blk-mq,
> it is possible to trigger a `NULL` pointer exception when resuming that
> device. The NPE is triggered when trying to dereference the `request_fn`
> function point
On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote:
> On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds
> wrote:
> >
> > Honestly, I'd like to just encourage people to get the sparse update
> > from Luc Van Oostenryck instead.
> >
> > For a while there it looked like Chris Li would just pull f
On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote:
> On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds
> wrote:
> > Honestly, I'd like to just encourage people to get the sparse update
> > from Luc Van Oostenryck instead.
> >
> > For a while there it looked like Chris Li would just pull from
On Tue, 2018-01-23 at 10:22 +0100, Mike Snitzer wrote:
> On Thu, Jan 18 2018 at 5:20pm -0500,
> Bart Van Assche wrote:
>
> > On Thu, 2018-01-18 at 17:01 -0500, Mike Snitzer wrote:
> > > And yet Laurence cannot reproduce any such lockups with your test...
> >
>
On Tue, 2018-01-23 at 04:45 -0800, Joe Perches wrote:
> Perhaps the email subject could be improved to describe
> the new macro and as well, this macro, without a pr_fmt
> define somewhat above it loses the __func__ output too.
Hmm ... I thought that the pr_debug() output can be configured to incl
On Tue, 2018-01-23 at 11:55 +0100, Johannes Thumshirn wrote:
> Use pr_debug instead of hand craftet macros. This way it is not needed to
> re-compile the kernel to enable bsg debug outputs and it's possible to
> selectively enable specific prints.
Reviewed-by: Bart Van Assche
On Thu, 2017-05-11 at 11:16 +0100, Colin King wrote:
> From: Colin Ian King
>
> Making target_parse_xcopy_cmd static fixes sparse warning:
>
> "warning: symbol 'target_parse_xcopy_cmd' was not declared. Should
> it be static?"
>
> Fixes: 1bd05294519f76 ("target/iscsi: Fix a deadlock between th
On Thu, 2018-01-11 at 01:04 -0500, Douglas Gilbert wrote:
> Monitoring that program with 'free' from another terminal I see
> about 2.5 GBytes of ram "swallowed" almost immediately when the test
> program runs. When the program exits (about 50 seconds later) as far
> as I can see all that ram is gi
On Tue, 2018-01-09 at 08:29 -0800, Tejun Heo wrote:
> Currently, blk-mq timeout path synchronizes against the usual
> issue/completion path using a complex scheme involving atomic
> bitflags, REQ_ATOM_*, memory barriers and subtle memory coherence
> rules. Unfortunatley, it contains quite a few ho
On Fri, 2018-01-12 at 14:07 -0700, Jens Axboe wrote:
> You're really not making it easy for folks to run this :-)
My hope is that the ib_srp and ib_srpt patches will be accepted upstream soon.
As long as these are not upstream, anyone who wants to retrieve these patches
is welcome to clone
https:
On 01/17/18 18:41, Ming Lei wrote:
BLK_STS_RESOURCE can be returned from driver when any resource
is running out of. And the resource may not be related with tags,
such as kmalloc(GFP_ATOMIC), when queue is idle under this kind of
BLK_STS_RESOURCE, restart can't work any more, then IO hang may
be
On Thu, 2018-01-18 at 12:03 -0500, Mike Snitzer wrote:
> On Thu, Jan 18 2018 at 11:50am -0500,
> Bart Van Assche wrote:
> > My comments about the above are as follows:
> > - It can take up to q->rq_timeout jiffies after a .queue_rq()
> > implementation retur
On Thu, 2018-01-18 at 13:30 -0500, Mike Snitzer wrote:
> 1%!? Where are you getting that number? Ming has detailed more
> significant performance gains than 1%.. and not just on lpfc (though you
> keep seizing on lpfc because of the low queue_depth of 3).
That's what I derived from the numbers y
On Thu, 2018-01-18 at 15:48 -0500, Mike Snitzer wrote:
> For Bart's test the underlying scsi-mq driver is what is regularly
> hitting this case in __blk_mq_try_issue_directly():
>
> if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q))
Hello Mike,
That code path is not the code path th
On Thu, 2018-01-18 at 16:23 -0500, Mike Snitzer wrote:
> On Thu, Jan 18 2018 at 3:58P -0500,
> Bart Van Assche wrote:
>
> > On Thu, 2018-01-18 at 15:48 -0500, Mike Snitzer wrote:
> > > For Bart's test the underlying scsi-mq driver is what is regular
On Thu, 2018-01-18 at 17:01 -0500, Mike Snitzer wrote:
> And yet Laurence cannot reproduce any such lockups with your test...
Hmm ... maybe I misunderstood Laurence but I don't think that Laurence has
already succeeded at running an unmodified version of my tests. In one of the
e-mails Laurence se
On Thu, 2018-01-18 at 17:18 -0500, Laurence Oberman wrote:
> OK, I ran 5 at once of 5 separate mount points.
> I am using 4k block sizes
> Its solid consistent for me. No stalls no gaps.
Hi Laurence,
That's great news and thank you for having shared this information but I think
it should be menti
On Thu, 2018-01-18 at 15:39 -0700, Jens Axboe wrote:
> When you do have a solid test case, please please submit a blktests
> test case for it! This needs to be something we can regularly in
> testing.
Hello Jens,
That sounds like a good idea to me. BTW, I think the reason why so far I
can reprodu
On Fri, 2018-01-19 at 10:32 +0800, Ming Lei wrote:
> Now most of times both NVMe and SCSI won't return BLK_STS_RESOURCE, and
> it should be DM-only which returns STS_RESOURCE so often.
That's wrong at least for SCSI. See also
https://marc.info/?l=linux-block&m=151578329417076.
Bart.
On Fri, 2018-01-19 at 15:26 +0800, Ming Lei wrote:
> Please see queue_delayed_work_on(), hctx->run_work is shared by all
> scheduling, once blk_mq_delay_run_hw_queue(100ms) returns, no new
> scheduling can make progress during the 100ms.
How about addressing that as follows:
diff --git a/block/bl
On Fri, 2018-01-19 at 23:33 +0800, Ming Lei wrote:
> On Fri, Jan 19, 2018 at 03:20:13PM +0000, Bart Van Assche wrote:
> > On Fri, 2018-01-19 at 15:26 +0800, Ming Lei wrote:
> > > Please see queue_delayed_work_on(), hctx->run_work is shared by all
> > > scheduling,
On Fri, 2018-01-19 at 15:34 +0800, Ming Lei wrote:
> Could you explain a bit when SCSI target replies with BUSY very often?
>
> Inside initiator, we have limited the max per-LUN requests and per-host
> requests already before calling .queue_rq().
That's correct. However, when a SCSI initiator and
On Mon, 2018-01-22 at 12:06 +0100, Dmitry Vyukov wrote:
> general protection fault: [#1] SMP KASAN
How about the untested patch below?
Thanks,
Bart.
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index cd9b6ebd7257..04a644b39d79 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@
On 01/21/18 23:53, Johannes Thumshirn wrote:
- dprintk("map hdr %llx/%u %llx/%u\n", (unsigned long long)
hdr->dout_xferp,
+ pr_debug("map hdr %llx/%u %llx/%u\n",
+(unsigned long long) hdr->dout_xferp,
hdr->dout_xfer_len, (unsigned long long) hdr->din_x
On Mon, 2018-01-22 at 20:06 +0100, Dmitry Vyukov wrote:
> On Mon, Jan 22, 2018 at 7:57 PM, Douglas Gilbert
> wrote:
> > As far as I remember, Dmitry has not indicated in multiple reports
> > over several years what /dev/sg0 is.
>
> That's because I know nothing about sg. If you give a command to
On Mon, 2018-01-22 at 12:23 -0800, Joe Perches wrote:
> On Mon, 2018-01-22 at 08:53 +0100, Johannes Thumshirn wrote:
> > Use pr_debug instead of hand crafted macros. This way it is not needed to
> > re-compile the kernel to enable bsg debug outputs and it's possible to
> > selectively enable specif
On 01/05/18 22:30, Dan Williams wrote:
On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote:
Please expand this.
It is not clear what the static analysis is looking for. Have a clear
description of what is being fixed is crucial for allowing any of these
changes.
For the details given in
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> Add convenience macro for polling an event that does not have a
> waitqueue.
>
> Signed-off-by: Michal Suchanek
> ---
> include/linux/delay.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/delay.h
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> - ret=cdo->tray_move(cdi,0);
> + ret = cdo->tray_move(cdi, 0);
Please separate whitespace-only changes from functional changes such that
this patch series becomes easier to review.
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> +static int cdrom_tray_close(struct cdrom_device_info *cdi)
> +{
> + int ret;
> +
> + ret = cdi->ops->tray_move(cdi, 0);
> + if (ret || !cdi->ops->drive_status)
> + return ret;
> +
> + return poll_event_interrup
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> When the drive closes it can take tens of seconds until the disc is
> analyzed. Wait for the drive to become ready or report an error.
>
> Signed-off-by: Michal Suchanek
> ---
> drivers/cdrom/cdrom.c | 9 +
> 1 file changed, 9 i
On 01/19/18 07:24, Jens Axboe wrote:
That's what I thought. So for a low queue depth underlying queue, it's
quite possible that this situation can happen. Two potential solutions
I see:
1) As described earlier in this thread, having a mechanism for being
notified when the scarce resource bec
A minor comment: please consider to reorder these two functions such that the
lock function appears first and the unlock function second. Anyway:
Reviewed-by: Bart Van Assche
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> +static void blk_mq_rq_update_aborted_gstate(struct request *rq, u64 gstate)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + u64_stats_update_begin(&rq->aborted_gstate_sync);
> + rq->aborted_gstate = gstate;
> +
ce the tests. This will allow removing
> REQ_ATOM_COMPLETE usages from blk-mq.
Reviewed-by: Bart Van Assche
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> @@ -156,12 +156,12 @@ void blk_timeout_work(struct work_struct *work)
> */
> void blk_abort_request(struct request *req)
> {
> - if (blk_mark_rq_complete(req))
> - return;
> -
> if (req->q->mq_ops) {
> - blk
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> @@ -230,6 +232,27 @@ struct request {
>
> unsigned short write_hint;
>
> + /*
> + * On blk-mq, the lower bits of ->gstate carry the MQ_RQ_* state
> + * value and the upper bits the generation number which is
> + * mo
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> After the recent updates to use generation number and state based
> synchronization, blk-mq no longer depends on REQ_ATOM_COMPLETE except
> to avoid firing the same timeout multiple times.
>
> Remove all REQ_ATOM_COMPLETE usages and use a new r
MQ_RQ_COMPLETE and replace REQ_ATOM_STARTED usages with
> blk_mq_rq_state() tests. REQ_ATOM_STARTED no longer has any users
> left and is removed.
Reviewed-by: Bart Van Assche
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> The RCU protection has been expanded to cover both queueing and
> completion paths making ->queue_rq_srcu a misnomer. Rename it to
> ->srcu as suggested by Bart.
Reviewed-by: Bart Van Assche
On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote:
> Greeting's,
>
> Linux next kernel panics on powerpc when module qla2xxx is load/unload.
>
> Machine Type: Power 8 PowerVM LPAR
> Kernel : 4.15.0-rc2-next-20171211
> gcc : version 4.8.5
> Test type: module load/unload few times
>
> Trace m
On Mon, 2018-01-08 at 11:15 -0800, Tejun Heo wrote:
> Currently, blk-mq protects only the issue path with RCU. This patch
> puts the completion path under the same RCU protection. This will be
> used to synchronize issue/completion against timeout by later patches,
> which will also add the comme
On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote:
> +/*
> + * SCSI command sizes are as follows, in bytes, for fixed size commands, per
> + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode
> + * determine its group.
> + * The size table is encoded into a 32-bit value by
On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote:
> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> scsi_dh_{alua,emc,rdac} use variable-length array declarations to
> store command blocks, with the appropriate size as determined by
> COM
On Sat, 2018-03-10 at 14:14 +0100, Stephen Kitt wrote:
> The two patches I sent were supposed to be alternative solutions; see
> https://marc.info/?l=linux-scsi&m=152063671005295&w=2 for the introduction (I
> seem to have messed up the headers, so the mails didn’t end up threaded
> properly).
The
On Tue, 2018-03-06 at 09:33 -0800, Tejun Heo wrote:
> 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work
> reliably") added rcu_read_[un]lock_sched() to blk_queue_enter() along
> with other changes but it doesn't seem to be doing anything.
>
> blk_queue_enter() is called with @q - the p
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
> sgl_alloc_order explicitly takes a 64-bit length (unsigned long long) but
> then rejects it in overflow checking if greater than 4GiB allocation was
> requested. This is a consequence of using unsigned int for the right hand
> side conditio
On Wed, 2018-03-07 at 12:47 +, Tvrtko Ursulin wrote:
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index 9884be50a2c0..e13a759c5c49 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -493,7 +493,7 @@ struct scatterlist *sgl_alloc_order(unsigned long length,
> unsigned int
101 - 200 of 1594 matches
Mail list logo
