On Mon, Dec 07, 2020 at 02:19:16PM +0100, Christoph Hellwig wrote:
> Change the policy so that a BLKROSET on the whole device also affects
> partitions. To quote Martin K. Petersen:
>
> It's very common for database folks to twiddle the read-only state of
> block devices and partitions. I know
init(, disk, DISK_PITER_INCL_EMPTY);
> - while ((part = disk_part_iter_next()))
> - part->bd_read_only = flag;
> - disk_part_iter_exit();
> + set_disk_ro_uevent(disk, read_only);
> }
> -
> EXPORT_SYMBOL(set_disk_ro);
>
> int bdev_read_only(struct block
LY) && sb->s_bdev &&
> + bdev_read_only(sb->s_bdev))
> return -EACCES;
> #endif
>
> --
> 2.29.2
>
Reviewed-by: Ming Lei
--
Ming
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
ollowing RDWR checks.
>*/
> - if (get_disk_ro(pmd->bdev->bd_disk))
> + if (bdev_read_only(pmd->bdev))
> return 0;
>
> features = le32_to_cpu(disk_super->compat_ro_flags) &
> ~THIN_FEATURE_COMPAT_RO_SUPP;
> --
> 2.29.2
>
Reviewed-by: Ming Lei
--
Ming
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Dec 03, 2020 at 09:26:35AM +0800, Ming Lei wrote:
> Hi,
>
> Qian reported there is hang during booting when shared host tagset is
> introduced on megaraid sas. Sumit reported the whole SCSI probe takes
> about ~45min in his test.
>
> Turns out it is caused by n
On Thu, Dec 03, 2020 at 09:03:43PM -0500, Mike Snitzer wrote:
> On Thu, Dec 03 2020 at 8:12pm -0500,
> Ming Lei wrote:
>
> > On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> > > On Wed, Dec 02 2020 at 10:26pm -0500,
> > > Ming Lei wrote:
> >
On Thu, Dec 03, 2020 at 08:27:38AM -0800, Keith Busch wrote:
> On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> > On Wed, Dec 02 2020 at 10:26pm -0500,
> > Ming Lei wrote:
> >
> > > I understand it isn't related with correctness, because the underlyin
On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> On Wed, Dec 02 2020 at 10:26pm -0500,
> Ming Lei wrote:
>
> > On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote:
> > > commit 22ada802ede8 ("block: use lcm_not_zero() when stackin
On Thu, Dec 03, 2020 at 09:29:51AM +0100, Christoph Hellwig wrote:
> On Thu, Dec 03, 2020 at 03:10:55PM +0800, Ming Lei wrote:
> > On Thu, Dec 03, 2020 at 02:40:04PM +0800, Ming Lei wrote:
> > > On Tue, Dec 01, 2020 at 05:54:18PM +0100, Christoph Hellwig wrote:
> > > &g
On Thu, Dec 03, 2020 at 02:40:04PM +0800, Ming Lei wrote:
> On Tue, Dec 01, 2020 at 05:54:18PM +0100, Christoph Hellwig wrote:
> > Replace the gendisk pointer in struct bio with a pointer to the newly
> > improved struct block device. From that the gendisk can be trivial
On Tue, Dec 01, 2020 at 05:54:18PM +0100, Christoph Hellwig wrote:
> Replace the gendisk pointer in struct bio with a pointer to the newly
> improved struct block device. From that the gendisk can be trivially
> accessed with an extra indirection, but it also allows to directly
> look up all
On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote:
> commit 22ada802ede8 ("block: use lcm_not_zero() when stacking
> chunk_sectors") broke chunk_sectors limit stacking. chunk_sectors must
> reflect the most limited of all devices in the IO stack.
>
> Otherwise malformed IO may result.
On Wed, Dec 02, 2020 at 11:18:31AM +, John Garry wrote:
> On 02/12/2020 03:31, Ming Lei wrote:
> > On Tue, Dec 01, 2020 at 09:02:18PM +0800, John Garry wrote:
> > > It has been reported many times that a use-after-free can be
> > > intermittently
> > >
On Tue, Dec 01, 2020 at 09:02:18PM +0800, John Garry wrote:
> It has been reported many times that a use-after-free can be intermittently
> found when iterating busy requests:
>
> -
> https://lore.kernel.org/linux-block/8376443a-ec1b-0cef-8244-ed584b96f...@huawei.com/
> -
>
and the request is still processed
> correctly, better remove the warning as this is the fast path.
>
> Suggested-by: Ming Lei
> Signed-off-by: Daniel Wagner
> ---
>
> v2:
> - remove the warning as suggested by Ming
> v1:
> - initial version
>
> https:/
On Thu, Nov 26, 2020 at 10:51:52AM +0100, Daniel Wagner wrote:
> The current warning looks aweful like a proper crash. This is
> confusing. There is not much information to gained from the stack
> trace anyway, let's drop it.
>
> While at it print the cpumask as there might be additial helpful
>
On Thu, Nov 26, 2020 at 01:44:36PM +, Pavel Begunkov wrote:
> On 26/11/2020 02:46, Ming Lei wrote:
> > On Sun, Nov 22, 2020 at 03:35:46PM +, Pavel Begunkov wrote:
> >> map->swap_lock protects map->cleared from concurrent modification,
> >> however sb
On Sun, Nov 22, 2020 at 03:35:46PM +, Pavel Begunkov wrote:
> map->swap_lock protects map->cleared from concurrent modification,
> however sbitmap_deferred_clear() is already atomically drains it, so
> it's guaranteed to not loose bits on concurrent
> sbitmap_deferred_clear().
>
> A one
_advance((bio_vec), &(iter), \
> - (bvl).bv_len) : bvec_iter_skip_zero_bvec(&(iter)))
> + bvec_iter_advance_single((bio_vec), &(iter), (bvl).bv_len))
>
> /* for iterating one bio from start to end */
> #define BVEC_ITER_ALL_INIT (struct bvec_iter)
> \
> --
> 2.24.0
>
Looks fine,
Reviewed-by: Ming Lei
Thanks,
Ming
On Fri, Nov 20, 2020 at 02:06:10AM +, Matthew Wilcox wrote:
> On Fri, Nov 20, 2020 at 01:56:22AM +, Pavel Begunkov wrote:
> > On 20/11/2020 01:49, Matthew Wilcox wrote:
> > > On Fri, Nov 20, 2020 at 01:39:05AM +, Pavel Begunkov wrote:
> > >> On 20/11/2020 01:20, Matthew Wilcox wrote:
>
On Fri, Nov 20, 2020 at 01:39:05AM +, Pavel Begunkov wrote:
> On 20/11/2020 01:20, Matthew Wilcox wrote:
> > On Thu, Nov 19, 2020 at 11:24:38PM +, Pavel Begunkov wrote:
> >> The block layer spends quite a while in iov_iter_npages(), but for the
> >> bvec case the number of pages is already
On Fri, Nov 13, 2020 at 01:36:16PM -0800, Sagi Grimberg wrote:
>
> > > But if you think this has a better home, I'm assuming that the guys
> > > will be open to that.
> >
> > Also see the reply from Ming. It's a balancing act - don't want to add
> > extra overhead to the core, but also don't
Hello,
On Thu, Nov 12, 2020 at 09:07:52AM -0500, Rachit Agarwal wrote:
> From: Rachit Agarwal >
>
> Hi All,
>
> I/O batching is beneficial for optimizing IOPS and throughput for various
> applications. For instance, several kernel block drivers would benefit from
> batching,
> including mmc
On Wed, Nov 11, 2020 at 09:42:17AM -0500, Qian Cai wrote:
> On Wed, 2020-11-11 at 17:27 +0800, Ming Lei wrote:
> > Can this issue disappear by applying the following change?
>
> This makes the system boot again as well.
OK, actually it isn't necessary to register one new lock ke
On Wed, Nov 11, 2020 at 12:57:59PM +0530, Sumit Saxena wrote:
> On Tue, Nov 10, 2020 at 11:12 PM John Garry wrote:
> >
> > On 09/11/2020 14:05, John Garry wrote:
> > > On 09/11/2020 13:39, Qian Cai wrote:
> > >>> I suppose I could try do this myself also, but an authentic version
> > >>> would be
.
GCC: gcc version 10.2.1 20200826 (Red Hat 10.2.1-3) (GCC)
--
Ming Lei
50
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15bf75b850
Not reproduce this issue by above C reproducer with the kernel config
in hours running
on linus tree.
Thanks,
Ming Lei
+ if (queue_is_mq(q)) {
> + struct blk_mq_hw_ctx *hctx;
> + int i;
> +
> cancel_delayed_work_sync(>requeue_work);
>
> + queue_for_each_hw_ctx(q, hctx, i)
> + cancel_delayed_work_sync(>run_work);
> + }
> +
Looks fine:
Reviewed-by: Ming Lei
Thanks,
Ming
On Thu, Oct 08, 2020 at 07:23:02PM -0600, Jens Axboe wrote:
> On 10/8/20 2:28 PM, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit 2b0d3d3e4fcfb19d10f9a82910b8f0f05c56ee3e
> > Author: Ming Lei
> > Date: Thu Oct 1 15:48:41 2020 +
>
On Thu, Oct 01, 2020 at 11:48:40PM +0800, Ming Lei wrote:
> Hi,
>
> The 1st patch removes memory footprint of percpu_ref in fast path
> from 7 words to 2 words, since it is often used in fast path and
> embedded in user struct.
>
> The 2nd patch moves .q_usage_cou
: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d5a3e1a4c2f7..67935b3bef6c 100644
--- a/include/linux/blkdev.h
V2:
- pass 'gfp' to kzalloc() for fixing block/027 failure reported by
kernel test robot
- protect percpu_ref_is_zero() with destroying percpu-refcount by
spin lock
Ming Lei (2):
percpu_ref: reduce memory footprint of percpu_ref in fast path
block: m
-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
include/linux/percpu-refcount.h | 52 ++--
lib/percpu-refcount.c | 131 ++
3 files changed, 123 insertions(+), 62 deletions(-)
diff --git a/drivers/infiniband/sw/rdmavt/mr.c
b/drivers
On Wed, Sep 30, 2020 at 12:00:15PM -0400, Tejun Heo wrote:
> On Wed, Sep 30, 2020 at 04:26:56PM +0800, Ming Lei wrote:
> > diff --git a/include/linux/percpu-refcount.h
> > b/include/linux/percpu-refcount.h
> > index 87d8a38bdea1..1d6ed9ca23dd 100644
> > --- a/incl
-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
include/linux/percpu-refcount.h | 45 --
lib/percpu-refcount.c | 131 ++
3 files changed, 116 insertions(+), 62 deletions(-)
diff --git a/drivers/infiniband/sw/rdmavt/mr.c
b/drivers
: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d5a3e1a4c2f7..67935b3bef6c 100644
--- a/include/linux/blkdev.h
027 failure reported by
kernel test robot
- protect percpu_ref_is_zero() with destroying percpu-refcount by
spin lock
Ming Lei (2):
percpu_ref: reduce memory footprint of percpu_ref in fast path
block: move 'q_usage_counter' into front of 'request_queue'
drivers/infinib
: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d5a3e1a4c2f7..67935b3bef6c 100644
--- a/include/linux/blkdev.h
-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
include/linux/percpu-refcount.h | 45 --
lib/percpu-refcount.c | 131 ++
3 files changed, 116 insertions(+), 62 deletions(-)
diff --git a/drivers/infiniband/sw/rdmavt/mr.c
b/drivers
...@vger.kernel.org
Cc: Sagi Grimberg
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
drivers/md/md.c | 2 +-
include/linux/percpu-refcount.h | 1 +
lib/percpu-refcount.c | 6 ++
3 files changed, 8 insertions(+), 1
unt by
spin lock
Ming Lei (3):
percpu_ref: add percpu_ref_is_initialized for MD
percpu_ref: reduce memory footprint of percpu_ref in fast path
block: move 'q_usage_counter' into front of 'request_queue'
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
drivers/md/md.c | 2 +-
incl
m_cache *cachep)
> @@ -3402,9 +3406,9 @@ static void cache_flusharray(struct kmem_cache *cachep,
> struct array_cache *ac)
> }
> #endif
> spin_unlock(>list_lock);
> - slabs_destroy(cachep, );
> ac->avail -= batchcount;
> memmove(ac->entry, &(ac->entry[batchcount]), sizeof(void *)*ac->avail);
> + slabs_destroy(cachep, );
> }
The issue can't be reproduced after applying this patch:
Tested-by: Ming Lei
Thanks,
Ming
On Fri, Sep 25, 2020 at 03:31:45PM +0800, Ming Lei wrote:
> On Thu, Sep 24, 2020 at 09:13:11PM -0400, Theodore Y. Ts'o wrote:
> > On Thu, Sep 24, 2020 at 10:33:45AM -0400, Theodore Y. Ts'o wrote:
> > > HOWEVER, thanks to a hint from a colleague at $WORK, and realizing
> >
On Thu, Sep 24, 2020 at 09:13:11PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 24, 2020 at 10:33:45AM -0400, Theodore Y. Ts'o wrote:
> > HOWEVER, thanks to a hint from a colleague at $WORK, and realizing
> > that one of the stack traces had virtio balloon in the trace, I
> > realized that when I
On Fri, Sep 25, 2020 at 09:14:16AM +0800, Ming Lei wrote:
> On Thu, Sep 24, 2020 at 10:33:45AM -0400, Theodore Y. Ts'o wrote:
> > On Thu, Sep 24, 2020 at 08:59:01AM +0800, Ming Lei wrote:
> > >
> > > The list corruption issue can be reproduced on kvm/qumu guest too
On Thu, Sep 24, 2020 at 10:33:45AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 24, 2020 at 08:59:01AM +0800, Ming Lei wrote:
> >
> > The list corruption issue can be reproduced on kvm/qumu guest too when
> > running xfstests(ext4) generic/038.
> >
> &
On Thu, Sep 17, 2020 at 10:30:12AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 17, 2020 at 10:20:51AM +0800, Ming Lei wrote:
> >
> > Obviously there is other more serious issue, since 568f27006577 is
> > completely reverted in your test, and you still see list corruption
&
On Thu, Sep 17, 2020 at 09:04:55AM +0100, Christoph Hellwig wrote:
> On Wed, Sep 16, 2020 at 09:07:14AM -0400, Brian Foster wrote:
> > Dave described the main purpose earlier in this thread [1]. The initial
> > motivation is that we've had downstream reports of soft lockup problems
> > in
On Thu, Sep 17, 2020 at 10:30:12AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 17, 2020 at 10:20:51AM +0800, Ming Lei wrote:
> >
> > Obviously there is other more serious issue, since 568f27006577 is
> > completely reverted in your test, and you still see list corruption
&
On Wed, Sep 16, 2020 at 04:20:26PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Sep 16, 2020 at 07:09:41AM +0800, Ming Lei wrote:
> > > The problem is it's a bit tricky to revert 568f27006577, since there
> > > is a merge conflict in blk_kick_flush(). I attempted to do the bisec
On Tue, Sep 15, 2020 at 11:39:46PM -0400, Mike Snitzer wrote:
> On Tue, Sep 15 2020 at 9:48pm -0400,
> Ming Lei wrote:
>
> > On Tue, Sep 15, 2020 at 09:28:14PM -0400, Mike Snitzer wrote:
> > > On Tue, Sep 15 2020 at 9:08pm -0400,
> > > Ming Lei wrote:
> >
On Tue, Sep 15, 2020 at 09:28:14PM -0400, Mike Snitzer wrote:
> On Tue, Sep 15 2020 at 9:08pm -0400,
> Ming Lei wrote:
>
> > On Tue, Sep 15, 2020 at 01:23:57PM -0400, Mike Snitzer wrote:
> > > blk_queue_split() has become compulsory from .submit_bio -- reg
On Tue, Sep 15, 2020 at 01:23:57PM -0400, Mike Snitzer wrote:
> blk_queue_split() has become compulsory from .submit_bio -- regardless
> of whether it is recursing. Update DM core to always call
> blk_queue_split().
>
> dm_queue_split() is removed because __split_and_process_bio() handles
>
On Tue, Sep 15, 2020 at 06:45:41PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Sep 15, 2020 at 03:33:03PM +0800, Ming Lei wrote:
> > Hi Theodore,
> >
> > On Tue, Sep 15, 2020 at 12:45:19AM -0400, Theodore Y. Ts'o wrote:
> > > On Thu, Sep 03, 2020 at 11:55:28PM
On Tue, Sep 15, 2020 at 04:21:54AM +, Damien Le Moal wrote:
> On 2020/09/15 10:10, Damien Le Moal wrote:
> > On 2020/09/15 0:04, Mike Snitzer wrote:
> >> On Sun, Sep 13 2020 at 8:46pm -0400,
> >> Damien Le Moal wrote:
> >>
> >>> On 2020/09/12 6:53, Mike Snitzer wrote:
>
Hi Theodore,
On Tue, Sep 15, 2020 at 12:45:19AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 03, 2020 at 11:55:28PM -0400, Theodore Y. Ts'o wrote:
> > Worse, right now, -rc1 and -rc2 is causing random crashes in my
> > gce-xfstests framework. Sometimes it happens before we've run even a
> >
On Mon, Sep 14, 2020 at 12:43:06AM +, Damien Le Moal wrote:
> On 2020/09/12 22:53, Ming Lei wrote:
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> >> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> >> REQ_OP_WRITE_ZEROES
On Mon, Sep 14, 2020 at 10:49:28AM -0400, Mike Snitzer wrote:
> On Sat, Sep 12 2020 at 9:52am -0400,
> Ming Lei wrote:
>
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> > > blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
>
lk_rq_get_max_sectors(struct request *rq,
> --
> 2.15.0
>
is_power_of_2() is cheap enough for fast path, so looks fine to support
non-power-of-2 chunk sectors.
Maybe NVMe PCI can remove the power_of_2() limit too.
Reviewed-by: Ming Lei
Thanks,
Ming
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
unk_sectors)
> - t->chunk_sectors = min_not_zero(t->chunk_sectors,
> - b->chunk_sectors);
> -
> t->zoned = max(t->zoned, b->zoned);
> return ret;
> }
Looks fine:
Reviewed-by: Ming Lei
Thanks,
Ming
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors() didn't call it for
> those operations.
Actually WRITE_SAME & WRITE_ZEROS are handled by the following if
On Thu, Sep 10, 2020 at 10:24:39AM -0400, Mike Snitzer wrote:
> [cc'ing dm-devel and linux-block because this is upstream concern too]
>
> On Wed, Sep 09 2020 at 1:00pm -0400,
> Vijayendra Suman wrote:
>
> >Hello Mike,
> >
> >While Running pgbench tool with 5.4.17 kernel build
> >
>
: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 7d82959e7b86..7b1e53084799 100644
--- a/include/linux/blkdev.h
...@vger.kernel.org
Cc: Sagi Grimberg
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
drivers/md/md.c | 2 +-
include/linux/percpu-refcount.h | 1 +
lib/percpu-refcount.c | 6 ++
3 files changed, 8 insertions(+), 1
Kabatova
V2:
- pass 'gfp' to kzalloc() for fixing block/027 failure reported by
kernel test robot
- protect percpu_ref_is_zero() with destroying percpu-refcount by
spin lock
Ming Lei (3):
percpu_ref: add percpu_ref_is_initialized for MD
percpu_ref: reduce
-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
include/linux/percpu-refcount.h | 45 --
lib/percpu-refcount.c | 131 ++
3 files changed, 116 insertions(+), 62 deletions(-)
diff --git a/drivers/infiniband/sw/rdmavt/mr.c
b/drivers
*same_page = false;
> return false;
> + }
> bv->bv_len += len;
> bio->bi_iter.bi_size += len;
> return true;
Reviewed-by: Ming Lei
--
Ming Lei
Hello Haifeng,
On Wed, Sep 09, 2020 at 02:11:20AM +, Zhao, Haifeng wrote:
> Ming, Christoph,
> Could you point out the patch aimed to fix this issue ? I would like to
> try it. This issue blocked my other PCI patch developing and verification
> work,
> I am not a BLOCK/NVMe expert,
ueue *q)
>
> kobject_uevent(q->mq_kobj, KOBJ_REMOVE);
> kobject_del(q->mq_kobj);
> +out_kobj:
> kobject_put(>kobj);
> return ret;
> }
> --
> 2.28.0
>
Looks good fix:
Reviewed-by: Ming Lei
--
Ming
-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d0d61bc81615..7575fa0aae6e 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -397,6 +397,8 @@ struct
(), then memory footprint of
'percpu_ref' in fast path is reduced a lot and becomes suitable to put
into hot cacheline of user structure.
Cc: Sagi Grimberg
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2
(two threads
per core) machine, dual socket/numa.
V2:
- pass 'gfp' to kzalloc() for fixing block/027 failure reported by
kernel test robot
- protect percpu_ref_is_zero() with destroying percpu-refcount by
spin lock
Ming Lei (2):
percpu_ref: reduce memory footprint
left;\
> skip = __v.iov_len; \
>
> and end up seeing overflows ("n" supposes to be less than PAGE_SIZE) before
> the
> soft-lockups and a dead system,
>
> [ 4300.249180][T470195] ITER_IOVEC left = 0, n = 48566423
>
> Thoughts?
Does the following patch make a difference for you?
https://lore.kernel.org/linux-block/20200817100055.2495905-1-ming@redhat.com/
thanks,
Ming Lei
On Tue, Aug 25, 2020 at 10:49:17AM -0400, Brian Foster wrote:
> cc Ming
>
> On Tue, Aug 25, 2020 at 10:42:03AM +1000, Dave Chinner wrote:
> > On Mon, Aug 24, 2020 at 11:48:41AM -0400, Brian Foster wrote:
> > > On Mon, Aug 24, 2020 at 04:04:17PM +0100, Christoph Hellwig wrote:
> > > > On Mon, Aug
On Wed, Aug 26, 2020 at 10:06:51AM +0800, Xianting Tian wrote:
> Replace various magic -1 constants for tags with BLK_MQ_NO_TAG.
> And move the definition of BLK_MQ_NO_TAG from 'block/blk-mq-tag.h'
> to 'include/linux/blk-mq.h'
All three symbols are supposed for block core internal code only, so
-off-by: Ming Lei
---
include/linux/blkdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index bb5636cc17b9..d8dba550ecac 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -396,6 +396,8 @@ struct
(two threads
per core) machine, dual socket/numa.
Ming Lei (2):
percpu_ref: reduce memory footprint of percpu_ref in fast path
block: move 'q_usage_counter' into front of 'request_queue'
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
include/linux/blkdev.h| 3 +-
include/linux
(), then memory footprint of
'percpu_ref' in fast path is reduced a lot and becomes suitable to put
into hot cacheline of user structure.
Cc: Sagi Grimberg
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Bart Van Assche
Signed-off-by: Ming Lei
---
drivers/infiniband/sw/rdmavt/mr.c | 2
On Tue, Aug 18, 2020 at 11:20:22AM -0400, Mike Snitzer wrote:
> On Tue, Aug 18 2020 at 10:50am -0400,
> Jens Axboe wrote:
>
> > On 8/18/20 2:07 AM, Ming Lei wrote:
> > > c616cbee97ae ("blk-mq: punt failed direct issue to dispatch list")
> > > supposed
me_page = ((vec_end_addr & PAGE_MASK) == page_addr);
> - if (!*same_page && pfn_to_page(PFN_DOWN(vec_end_addr)) + 1 != page)
> - return false;
> - return true;
> + if (*same_page)
> + return true;
> + return (bv->bv_page + bv_end / PAGE_SIZE) == (page + off / PAGE_SIZE);
Looks this way is more straightforward, meantime can cover compound
pages:
Reviewed-by: Ming Lei
Thanks,
Ming
On Sun, Aug 09, 2020 at 03:25:22PM +0100, Matthew Wilcox wrote:
> On Sun, Aug 09, 2020 at 10:40:05AM +0800, Ming Lei wrote:
> > Hello Matthew,
> >
> > On Fri, Aug 07, 2020 at 06:44:16PM +0100, Matthew Wilcox wrote:
> > >
> > > Everything sta
On Sun, Aug 09, 2020 at 10:31:23AM +0800, Ming Lei wrote:
> On Fri, Aug 07, 2020 at 03:11:48PM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 07, 2020 at 09:41:14PM +0800, Ming Lei wrote:
> > > On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> > > > FWIW,
Hello Matthew,
On Fri, Aug 07, 2020 at 06:44:16PM +0100, Matthew Wilcox wrote:
>
> Everything starts going very slowly after this commit:
>
> commit 37f4a24c2469a10a4c16c641671bd766e276cf9f (refs/bisect/bad)
> Author: Ming Lei
> Date: Tue Jun 30 22:03:57 2020 +08
On Fri, Aug 07, 2020 at 03:11:48PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 07, 2020 at 09:41:14PM +0800, Ming Lei wrote:
> > On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> > > FWIW, my preference would be to have for_each_bvec() advance past
> > > zero-
On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> On Fri, Aug 07, 2020 at 01:27:27PM +0100, Al Viro wrote:
> > On Fri, Aug 07, 2020 at 07:35:08PM +0900, Tetsuo Handa wrote:
> > > syzbot is reporting hung task at pipe_release() [1], for for_each_bvec()
> > > from
> > > iterate_bvec() from
ularity in
> __blkdev_issue_discard() before composing the discard bio. If the value
> is 0, then prints a warning oops information and returns -EOPNOTSUPP to
> the caller to indicate that this buggy device driver doesn't support
> discard request.
>
> Fixes: 9b15d109a6b2 ("block: impro
On Wed, Aug 05, 2020 at 09:54:00AM +0800, Coly Li wrote:
> On 2020/8/5 07:58, Ming Lei wrote:
> > On Tue, Aug 04, 2020 at 10:23:32PM +0800, Coly Li wrote:
> >> When some buggy driver doesn't set its queue->limits.discard_granularity
> >> (e.g. current loop de
) and bio_aligned_discard_max_sectors(). If it is
> 0 from some buggy driver queue, prints a warning oops information and
> set queue_logical_block_size(q) to a local variable discard_granularity.
> This local variable is used in round_up() and round_down() calculation,
> now req_sects won't be 0 and n
*vblk = disk->private_data;
> struct virtio_device *vdev = vblk->vdev;
> --
> 2.7.4
>
Reviewed-by: Ming Lei
--
Ming
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
*vblk = disk->private_data;
> struct virtio_device *vdev = vblk->vdev;
> --
> 2.7.4
>
Reviewed-by: Ming Lei
--
Ming
On Mon, Jul 27, 2020 at 11:31:56AM +0200, Petr Vorel wrote:
> Hi,
>
> > FYI, we noticed the following commit (built with gcc-9):
>
> > commit: 6e6fcbc27e7788af54139c53537395d95560f2ef ("blk-mq: support batching
> > dispatch in case of io")
> >
On Thu, Jun 11, 2020 at 03:22:51PM +0800, Ming Lei wrote:
> BDI is unregistered from del_gendisk() which is usually done in device's
> release handler from device hotplug or error handling context, so BDI
> can be unregistered anytime.
>
> It should be normal for __mark_inode_
On Sun, Jul 26, 2020 at 03:55:11PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 6e6fcbc27e7788af54139c53537395d95560f2ef ("blk-mq: support batching
> dispatch in case of io")
>
On Tue, Jul 14, 2020 at 8:38 AM Ming Lei wrote:
>
> On Wed, Jul 08, 2020 at 09:14:05PM +0800, Ming Lei wrote:
> > IO requests may be held in scheduler queue because of resource contention.
> > However, not like normal completion, when queueing request failed, we don't
> >
device_add_disk(>dev, vblk->disk, virtblk_attr_groups);
> return 0;
>
> +out_cleanup_queue:
> + blk_cleanup_queue(vblk->disk->queue);
> + vblk->disk->queue = NULL;
> out_free_tags:
> blk_mq_free_tag_set(>tag_set);
> out_put_disk:
> --
> 2.26.2
>
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Looks fine,
Reviewed-by: Ming Lei
--
Ming Lei
device_add_disk(>dev, vblk->disk, virtblk_attr_groups);
> return 0;
>
> +out_cleanup_queue:
> + blk_cleanup_queue(vblk->disk->queue);
> + vblk->disk->queue = NULL;
> out_free_tags:
> blk_mq_free_tag_set(>tag_set);
> out_put_disk:
> --
&g
thus no need to validate
> > rq->internal_tag again,
> > and remove it.
>
> A gentle ping?
Reviewed-by: Ming Lei
--
Ming
On Fri, Jul 10, 2020 at 04:22:10PM +0800, Baolin Wang wrote:
> Hi,
>
> On Sat, Jul 04, 2020 at 03:26:14PM +0800, Baolin Wang wrote:
> > Remove unnecessary local variable 'ret' in blk_mq_dispatch_hctx_list().
> >
>
> A gentle ping?
Reviewed-by: Ming Lei
--
Ming
On Thu, Jul 02, 2020 at 04:53:04PM +0530, Sachin Sant wrote:
> Starting with linux-next 20200701 release I am observing automated regressions
> tests taking longer time to complete. A test which took 10 minutes with
> next-20200630
> took more than 60 minutes against next-20200701.
>
>
be(struct virtio_device *vdev)
> put_disk(vblk->disk);
> out_free_vq:
> vdev->config->del_vqs(vdev);
> + kfree(vblk->vqs);
> out_free_vblk:
> kfree(vblk);
> out_free_index:
> --
> 2.25.0.4.g0ad7144999
>
Reviewed-by: Mi
501 - 600 of 12343 matches
Mail list logo
