[PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

Before commit 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for blk-mq"), we run queue after 3ms if queue is idle and SCSI device queue isn't ready, which is done in handling BLK_STS_RESOURCE. After commit 0df21c86bdbf is introduced, queue won't be run any more under this situation.

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

On Tue, Dec 05, 2017 at 03:19:46PM +0900, Byungchul Park wrote: > On 12/5/2017 2:46 PM, Byungchul Park wrote: > > On 12/5/2017 2:30 PM, Matthew Wilcox wrote: > > > On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote: > > > > For now, wait_for_completion() / complete() works with

Re: [PATCH] [PATCH v2] bcache: segregate flash only volume write streams from cached devices

Tang Junhui-- Hi On 12/03/2017 10:11 PM, tang.jun...@zte.com.cn wrote: > From: Tang Junhui > > Hello Mike & Coly > > Could you please have a reveiw for this patch? > >> From: Tang Junhui >> >> In such scenario that there are some flash only

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Tue, Dec 05, 2017 at 01:16:24PM +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 11:48:07PM +, Holger Hoffstätte wrote: > > On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote: > > > > > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > > >> On Sun, 2017-12-03 at 00:31

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

On 12/5/2017 2:46 PM, Byungchul Park wrote: On 12/5/2017 2:30 PM, Matthew Wilcox wrote: On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote: For now, wait_for_completion() / complete() works with lockdep, add lock_page() / unlock_page() and its family to lockdep support. Changes

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

On 12/5/2017 2:30 PM, Matthew Wilcox wrote: On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote: For now, wait_for_completion() / complete() works with lockdep, add lock_page() / unlock_page() and its family to lockdep support. Changes from v1 - Move lockdep_map_cross outside of

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote: > For now, wait_for_completion() / complete() works with lockdep, add > lock_page() / unlock_page() and its family to lockdep support. > > Changes from v1 > - Move lockdep_map_cross outside of page_ext to make it flexible > -

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 11:48:07PM +, Holger Hoffstätte wrote: > On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote: > > > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > >> On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > >> > Fixes: 0df21c86bdbf ("scsi: implement

Re: [PATCH 1/2] scsi-mq: Only show the CDB if available

On Tue, Dec 05, 2017 at 01:59:51AM +, Bart Van Assche wrote: > On Tue, 2017-12-05 at 09:15 +0800, Ming Lei wrote: > > On Mon, Dec 04, 2017 at 04:38:08PM -0800, Bart Van Assche wrote: > > > Since the next patch will make it possible that scsi_show_rq() gets > > > called before the CDB pointer

Re: [PATCH 1/2] scsi-mq: Only show the CDB if available

On Mon, Dec 04, 2017 at 10:42:28PM -0500, Martin K. Petersen wrote: > > Hi Ming, > > > Please cook a patch for fixing the crash issue only, since we need > > to backport the fix to stable kernel. > > I thought you were going to submit a V5 that addressed James' concerns? > > -- > Martin K.

Re: [PATCH 1/2] scsi-mq: Only show the CDB if available

On Tue, 2017-12-05 at 09:15 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 04:38:08PM -0800, Bart Van Assche wrote: > > Since the next patch will make it possible that scsi_show_rq() gets > > called before the CDB pointer is changed into a non-NULL value, > > only show the CDB if the CDB pointer

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, Dec 05, 2017 at 01:13:43AM +, Bart Van Assche wrote: > On Tue, 2017-12-05 at 09:04 +0800, Ming Lei wrote: > > Then no reason to revert commit(0df21c86bdbf scsi: implement .get_budget an > > .put_budget for blk-mq) for one issue which may never happen in reality > > since > > this

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, 2017-12-05 at 09:04 +0800, Ming Lei wrote: > Then no reason to revert commit(0df21c86bdbf scsi: implement .get_budget an > .put_budget for blk-mq) for one issue which may never happen in reality since > this reproducer need out-of-tree patch. Sorry but I disagree completely. You seem to

Re: [PATCH 1/2] scsi-mq: Only show the CDB if available

On Mon, Dec 04, 2017 at 04:38:08PM -0800, Bart Van Assche wrote: > Since the next patch will make it possible that scsi_show_rq() gets > called before the CDB pointer is changed into a non-NULL value, > only show the CDB if the CDB pointer is not NULL. Additionally, > show the request timeout and

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, Dec 05, 2017 at 12:29:59AM +, Bart Van Assche wrote: > On Tue, 2017-12-05 at 08:20 +0800, Ming Lei wrote: > > Also it is a bit odd to see request in hctx->dispatch now, and it can only > > happen now when scsi_target_queue_ready() returns false, so I guess you > > apply > > some

[PATCH 0/2] Show commands stuck in a timeout handler in debugfs

Hello Jens, While debugging an issue with the SCSI error handler I noticed that commands that got stuck in that error handler are not shown in debugfs. That is very annoying for anyone who relies on the information in debugfs for root-causing such an issue. Hence this patch series that makes sure

[PATCH 1/2] scsi-mq: Only show the CDB if available

Since the next patch will make it possible that scsi_show_rq() gets called before the CDB pointer is changed into a non-NULL value, only show the CDB if the CDB pointer is not NULL. Additionally, show the request timeout and SCSI command flags. This patch also fixes a bug that was reported by Ming

[PATCH 2/2] blk-mq-debugfs: Also show requests that have not yet been started

When debugging e.g. the SCSI timeout handler it is important that requests that have not yet been started or that already have completed are also reported through debugfs. Signed-off-by: Bart Van Assche Cc: Ming Lei Cc: Christoph Hellwig

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, 2017-12-05 at 08:20 +0800, Ming Lei wrote: > Also it is a bit odd to see request in hctx->dispatch now, and it can only > happen now when scsi_target_queue_ready() returns false, so I guess you apply > some change on target->can_queue(such as setting it as 1 in srp/ib code > manually)?

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Mon, Dec 04, 2017 at 11:32:27PM +, Bart Van Assche wrote: > On Tue, 2017-12-05 at 07:01 +0800, Ming Lei wrote: > > On Mon, Dec 04, 2017 at 10:48:18PM +, Bart Van Assche wrote: > > > On Tue, 2017-12-05 at 06:42 +0800, Ming Lei wrote: > > > > On Mon, Dec 04, 2017 at 09:30:32AM -0800, Bart

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: >> On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: >> > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for >> > blk-mq") >> >> It might be safer to revert

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, 2017-12-05 at 07:01 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 10:48:18PM +, Bart Van Assche wrote: > > On Tue, 2017-12-05 at 06:42 +0800, Ming Lei wrote: > > > On Mon, Dec 04, 2017 at 09:30:32AM -0800, Bart Van Assche wrote: > > > > * A systematic lockup for SCSI queues with

Re: [PATCH] kyber: fix another domain token wait queue hang

On Mon, Dec 04, 2017 at 03:12:15PM -0800, Omar Sandoval wrote: > From: Omar Sandoval > > Commit 8cf466602028 ("kyber: fix hang on domain token wait queue") fixed > a hang caused by leaving wait entries on the domain token wait queue > after the __sbitmap_queue_get() retry

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 01:59, Jeff Moyer wrote: > Kirill Tkhai writes: > >> On 05.12.2017 00:52, Tejun Heo wrote: >>> Hello, Kirill. >>> >>> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: > Can you please explain how this is a fundamental resource which can't

[PATCH] kyber: fix another domain token wait queue hang

From: Omar Sandoval Commit 8cf466602028 ("kyber: fix hang on domain token wait queue") fixed a hang caused by leaving wait entries on the domain token wait queue after the __sbitmap_queue_get() retry succeeded, making that wait entry a "dud" which won't in turn wake more entries

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 02:02, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: >>> If the only reason is kernel memory consumption protection, the only >>> thing we need to do is making sure that memory used for aio commands >>> are accounted against

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Kirill. On Tue, Dec 05, 2017 at 01:49:42AM +0300, Kirill Tkhai wrote: > > If the only reason is kernel memory consumption protection, the only > > thing we need to do is making sure that memory used for aio commands > > are accounted against cgroup kernel memory consumption and > >

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Mon, Dec 04, 2017 at 10:48:18PM +, Bart Van Assche wrote: > On Tue, 2017-12-05 at 06:42 +0800, Ming Lei wrote: > > On Mon, Dec 04, 2017 at 09:30:32AM -0800, Bart Van Assche wrote: > > > * A systematic lockup for SCSI queues with queue depth 1. The > > > following test reproduces that bug

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Kirill Tkhai writes: > On 05.12.2017 00:52, Tejun Heo wrote: >> Hello, Kirill. >> >> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: Can you please explain how this is a fundamental resource which can't be controlled otherwise? >>> >>> Currently,

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Tue, 2017-12-05 at 06:45 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > > blk-mq") > > > > It might be safer to

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 00:52, Tejun Heo wrote: > Hello, Kirill. > > On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: >>> Can you please explain how this is a fundamental resource which can't >>> be controlled otherwise? >> >> Currently, aio_nr and aio_max_nr are global. In case of containers

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Tue, 2017-12-05 at 06:42 +0800, Ming Lei wrote: > On Mon, Dec 04, 2017 at 09:30:32AM -0800, Bart Van Assche wrote: > > * A systematic lockup for SCSI queues with queue depth 1. The > > following test reproduces that bug systematically: > > - Change the SRP initiator such that SCSI target

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote: > On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for > > blk-mq") > > It might be safer to revert commit 0df21c86bdbf instead of trying to fix all > issues

Re: [PATCH] blk-mq: Fix several SCSI request queue lockups

On Mon, Dec 04, 2017 at 09:30:32AM -0800, Bart Van Assche wrote: > Commit 0df21c86bdbf introduced several bugs: > * A SCSI queue stall for queue depths > 1, addressed by commit > 88022d7201e9 ("blk-mq: don't handle failure in .get_budget") This one is committed already. > * A systematic lockup

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Kirill. On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote: > > Can you please explain how this is a fundamental resource which can't > > be controlled otherwise? > > Currently, aio_nr and aio_max_nr are global. In case of containers this > means that a single container may

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

On 05.12.2017 00:35, Jeff Moyer wrote: > Kirill Tkhai writes: > >> Hi, Benjamin, >> >> On 04.12.2017 19:52, Benjamin LaHaise wrote: >>> Hi Kirill, >>> >>> On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: Hi, this patch set introduces accounting

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Tejun, On 04.12.2017 23:07, Tejun Heo wrote: > On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: >> this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. >> It may be used to limit number of aio requests, which are available for >> a cgroup, and could be

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Kirill Tkhai writes: > Hi, Benjamin, > > On 04.12.2017 19:52, Benjamin LaHaise wrote: >> Hi Kirill, >> >> On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: >>> Hi, >>> >>> this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. >>> It may

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hi, Benjamin, On 04.12.2017 19:52, Benjamin LaHaise wrote: > Hi Kirill, > > On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: >> Hi, >> >> this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. >> It may be used to limit number of aio requests, which are

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hello, Kirill. On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: > this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. > It may be used to limit number of aio requests, which are available for > a cgroup, and could be useful for containers. Can you please

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On Mon, Dec 04, 2017 at 05:48:36PM +0800, Xiao Yang wrote: > On 2017/12/04 17:25, Eryu Guan wrote: > > On Mon, Dec 04, 2017 at 05:15:17PM +0800, Xiao Yang wrote: > > > On 2017/12/04 16:29, Eryu Guan wrote: > > > > On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: > > > > > If the entire

[PATCH] blk-mq: Fix several SCSI request queue lockups

Commit 0df21c86bdbf introduced several bugs: * A SCSI queue stall for queue depths > 1, addressed by commit 88022d7201e9 ("blk-mq: don't handle failure in .get_budget") * A systematic lockup for SCSI queues with queue depth 1. The following test reproduces that bug systematically: - Change

Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hi Kirill, On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote: > Hi, > > this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. > It may be used to limit number of aio requests, which are available for > a cgroup, and could be useful for containers. > > The

[PATCH 2/3] arm64: don't override dma_max_pfn

The generic version now takes dma_pfn_offset into account, so there is no more need for an architecture override. Signed-off-by: Christoph Hellwig --- arch/arm64/include/asm/dma-mapping.h | 9 - 1 file changed, 9 deletions(-) diff --git

[PATCH 1/3] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

This makes sure the generic version can be used with architectures / devices that have a DMA offset in the direct mapping. Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/3] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops

The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound by the dma mask in the device because it directly maps to a physical address range (modulo an offset in the device), or if it is virtualized by an iommu and can map any address (that includes virtual iommus like swiotlb).

replace PCI_DMA_BUS_IS_PHYS with a per-instance flag

Hi all, this small series tries to get rid of the global and misnamed PCI_DMA_BUS_IS_PHYS flag, and replace it with a setting in each struct dma_map_ops instance.

Re: [PATCH] um: Convert ubd driver to blk-mq

On Sun, Dec 03, 2017 at 10:49:23PM +0100, Richard Weinberger wrote: > Convert the driver to the modern blk-mq framework. > As byproduct we get rid of our open coded restart logic and let > blk-mq handle it. > > Signed-off-by: Richard Weinberger > --- > arch/um/drivers/ubd_kern.c

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On Wed, Nov 29, 2017 at 08:18:09PM +0100, Christian Borntraeger wrote: > Works fine under KVM with virtio-blk, but still hangs during boot in an LPAR. > FWIW, the system not only has scsi disks via fcp but also DASDs as a boot > disk. > Seems that this is the place where the system stops. (see

[PATCH 2/5] aio: Export aio_nr_lock and aio_max_nr initial value to include/linux/aio.h

Next patch will use the values in more files, so let's make them visible external. Signed-off-by: Kirill Tkhai --- fs/aio.c|4 ++-- include/linux/aio.h |4 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/aio.c b/fs/aio.c index

[PATCH 1/5] aio: Move aio_nr increment to separate function

There is no functional changes, only a preparation for next patches. Signed-off-by: Kirill Tkhai --- fs/aio.c | 44 1 file changed, 32 insertions(+), 12 deletions(-) diff --git a/fs/aio.c b/fs/aio.c index

[PATCH 5/5] blkcg: Add cgroup file to configure blkcg::blkg_aio_max_nr

Add a file to configure per-cgroup maximum number of available aio requests. Allow write the values, which are less then currently allocated numbers of requests. Show numbers of currently allocated and maximum available requests. Signed-off-by: Kirill Tkhai ---

[PATCH 4/5] blkcg: Charge aio requests in blkio cgroup hierarchy

This patch adds accounting of number of requests of allocated aio contexts per blkio cgroup, and aggregates child cgroups requests up the hierarhy. This may be used to limit aio requests available for containers. By default, newly allocated blkcg::blkg_aio_max_nr is set to "unlimited" value (see

[PATCH 3/5] blkcg: Add blkcg::blkg_aio_nr and blkcg::blkg_aio_max_nr

This adds new members of struct blkcg, which will be used to account numbers of cgroup's aio requests. Also, blkcg_root is used to store sysctl variables aio_nr and aio_max_nr. Signed-off-by: Kirill Tkhai --- block/blk-cgroup.c |4 fs/aio.c

[PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup

Hi, this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup. It may be used to limit number of aio requests, which are available for a cgroup, and could be useful for containers. The accounting is hierarchical, and aio contexts, allocated in child cgroup, are accounted in

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote: > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for blk-mq") It might be safer to revert commit 0df21c86bdbf instead of trying to fix all issues introduced by that commit for kernel version v4.15 ... Bart.

Re: [PATCH V2 0/2] block: fix queue freeze and cleanup

On 12/01/2017 10:49 PM, Ming Lei wrote: Unfortunately v2 has been found to exhibit another problem, an Oops in the systemd shutdown path for device-mapper LVM volumes at least, when calling 'q->request_fn(q)' if 'q->request_fn' is NULL. That issue can be fixed easily in V2 and we understand

Re: WARNING in kmalloc_slab (3)

On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote: > Looks like BLKTRACESETUP doesn't limit the '.buf_nr' parameter, allowing > anyone > who can open a block device to cause an extremely large kmalloc. Here's a > simplified reproducer: > There are lots of places which allow people

Re: blk-mq + bfq: udevd hang on usb2 storages

On Fri, Dec 01, 2017 at 06:04:29PM +0100, Alban Browaeys wrote: > I initially reported as https://bugzilla.kernel.org/show_bug.cgi?id=198 > 023 . > > I have now bisected this issue to commit a6a252e6491443c1c1 "blk-mq- > sched: decide how to handle flush rq via RQF_FLUSH_SEQ". > > This is with

[PATCH V2] block, bfq: remove batches of confusing ifdefs

Commit a33801e8b473 ("block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs: one reported in [1], plus a similar one in another function. This commit removes both batches, in the way suggested in [1]. [1]

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On 2017/12/04 17:25, Eryu Guan wrote: On Mon, Dec 04, 2017 at 05:15:17PM +0800, Xiao Yang wrote: On 2017/12/04 16:29, Eryu Guan wrote: On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: If the entire block device is formatted with a filesystem and mounted, running "blockdev

Re: WARNING in kmalloc_slab (3)

On Mon, Dec 04, 2017 at 09:18:05AM +0100, Dmitry Vyukov wrote: > On Mon, Dec 4, 2017 at 9:14 AM, Dan Carpenter > wrote: > > On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote: > >> Looks like BLKTRACESETUP doesn't limit the '.buf_nr' parameter, allowing > >>

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On Mon, Dec 04, 2017 at 05:15:17PM +0800, Xiao Yang wrote: > On 2017/12/04 16:29, Eryu Guan wrote: > > On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: > > > If the entire block device is formatted with a filesystem and > > > mounted, running "blockdev --rereadpt" should fail and return

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On 2017/12/04 16:29, Eryu Guan wrote: On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: If the entire block device is formatted with a filesystem and mounted, running "blockdev --rereadpt" should fail and return EBUSY instead of pass. Signed-off-by: Xiao Yang

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 09:44:55AM +0100, Johannes Thumshirn wrote: > Ming Lei writes: > > > > I am happy to do that, but recently I am very busy, so it may be done > > a bit late by me. > > > > But anyone should reproduce the issue 100% with V4.15-rc kernel by just > >

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

Ming Lei writes: > I am happy to do that, but recently I am very busy, so it may be done > a bit late by me. > > But anyone should reproduce the issue 100% with V4.15-rc kernel by just > running the above script, not any specific hardware is required at all, > so that means

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

On Mon, Dec 04, 2017 at 09:19:33AM +0100, Johannes Thumshirn wrote: > > Hi Ming, > > Ming Lei writes: > > This issue can be triggered by the following script: > > > > #!/bin/sh > > rmmod scsi_debug > > modprobe scsi_debug max_queue=1 > > > > DEVICE=`ls -d >

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: > If the entire block device is formatted with a filesystem and > mounted, running "blockdev --rereadpt" should fail and return > EBUSY instead of pass. > > Signed-off-by: Xiao Yang As we have blktests[1] now, I

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

Hi Ming, Ming Lei writes: > This issue can be triggered by the following script: > > #!/bin/sh > rmmod scsi_debug > modprobe scsi_debug max_queue=1 > > DEVICE=`ls -d > /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 >

Re: WARNING in kmalloc_slab (3)

On Mon, Dec 4, 2017 at 9:14 AM, Dan Carpenter wrote: > On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote: >> Looks like BLKTRACESETUP doesn't limit the '.buf_nr' parameter, allowing >> anyone >> who can open a block device to cause an extremely large kmalloc.