On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote:
>
> I'm looking at this and I'd like to know why does the crypto API fail in
> hard-irq context and why does it work in tasklet context. What's the exact
> reason behind this?
You're not supposed to do any real work in IRQ
On Sat, Jun 20, 2020 at 07:14:51AM +0800, Ming Lei wrote:
> On Fri, Jun 19, 2020 at 07:04:05PM -0400, Mike Snitzer wrote:
> > On Fri, Jun 19 2020 at 6:52pm -0400,
> > Ming Lei wrote:
> >
> > > On Sat, Jun 20, 2020 at 06:37:44AM +0800, Ming Lei wrote:
> > > > On Fri, Jun 19, 2020 at 01:40:41PM
On Fri, Jun 19, 2020 at 07:04:05PM -0400, Mike Snitzer wrote:
> On Fri, Jun 19 2020 at 6:52pm -0400,
> Ming Lei wrote:
>
> > On Sat, Jun 20, 2020 at 06:37:44AM +0800, Ming Lei wrote:
> > > On Fri, Jun 19, 2020 at 01:40:41PM -0400, Mike Snitzer wrote:
> > > > On Fri, Jun 19 2020 at 12:06pm
On Fri, Jun 19 2020 at 6:52pm -0400,
Ming Lei wrote:
> On Sat, Jun 20, 2020 at 06:37:44AM +0800, Ming Lei wrote:
> > On Fri, Jun 19, 2020 at 01:40:41PM -0400, Mike Snitzer wrote:
> > > On Fri, Jun 19 2020 at 12:06pm -0400,
> > > Mike Snitzer wrote:
> > >
> > > > On Fri, Jun 19 2020 at 6:11am
On Sat, Jun 20, 2020 at 06:37:44AM +0800, Ming Lei wrote:
> On Fri, Jun 19, 2020 at 01:40:41PM -0400, Mike Snitzer wrote:
> > On Fri, Jun 19 2020 at 12:06pm -0400,
> > Mike Snitzer wrote:
> >
> > > On Fri, Jun 19 2020 at 6:11am -0400,
> > > Ming Lei wrote:
> > >
> > > > Hi Mike,
> > > >
> >
On Fri, Jun 19, 2020 at 01:40:41PM -0400, Mike Snitzer wrote:
> On Fri, Jun 19 2020 at 12:06pm -0400,
> Mike Snitzer wrote:
>
> > On Fri, Jun 19 2020 at 6:11am -0400,
> > Ming Lei wrote:
> >
> > > Hi Mike,
> > >
> > > On Fri, Jun 19, 2020 at 05:42:50AM -0400, Mike Snitzer wrote:
> > > > Hi
On Fri, Jun 19, 2020 at 12:06:57PM -0400, Mike Snitzer wrote:
> On Fri, Jun 19 2020 at 6:11am -0400,
> Ming Lei wrote:
>
> > Hi Mike,
> >
> > On Fri, Jun 19, 2020 at 05:42:50AM -0400, Mike Snitzer wrote:
> > > Hi Ming,
> > >
> > > Thanks for the patch! But I'm having a hard time
From: yangerkun
From: yangerkun
Since we support the listbadblocks command, introduce the detail in the
doc.
[Bryan: formatting and wording fixes]
Signed-off-by: yangerkun
Signed-off-by: Bryan Gurney
---
.../admin-guide/device-mapper/dm-dust.rst | 17 +
1 file
From: yangerkun
From: yangerkun
This interface may help anyone who want to know all badblocks without
query block for each.
[Bryan: DMEMIT an empty list if no blocks are in the bad block list.]
Signed-off-by: yangerkun
Signed-off-by: Bryan Gurney
---
drivers/md/dm-dust.c | 27
From: yangerkun
From: yangerkun
Since some type of message will report the results to user directly,
we should update the doc too.
[Bryan: update output examples to include function name printing]
Signed-off-by: yangerkun
Signed-off-by: Bryan Gurney
---
From: yangerkun
From: yangerkun
Some type of message(queryblock/countbadblocks/removebadblock) may better
report results to user directly. Do it with DMEMIT.
[Bryan: maintain __func__ output in DMEMIT messages]
Signed-off-by: yangerkun
Signed-off-by: Bryan Gurney
---
drivers/md/dm-dust.c
On Fri, 2020-06-19 at 11:52 -0500, Benjamin Marzinski wrote:
> On Fri, Jun 19, 2020 at 01:42:47PM +, Martin Wilck wrote:
> > On Thu, 2020-06-18 at 18:17 -0500, Benjamin Marzinski wrote:
> > > On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
> > > >
> > > > It would be more
On Fri, 19 Jun 2020, Mike Snitzer wrote:
> On Fri, Jun 19 2020 at 12:41pm -0400,
> Ignat Korchagin wrote:
>
> > This is a follow up from the long-forgotten [1], but with some more
> > convincing
> > evidence. Consider the following script:
> >
> > [1]:
On Fri, Jun 19, 2020 at 1:43 PM Bryan Gurney wrote:
>
> On Fri, Jun 19, 2020 at 1:29 PM Mike Snitzer wrote:
> >
> > On Fri, Jun 19 2020 at 1:23pm -0400,
> > Bryan Gurney wrote:
> >
> > > On Fri, Jun 19, 2020 at 11:45 AM Mike Snitzer wrote:
> > > >
> > > > On Fri, Jun 19 2020 at 11:40am -0400,
The dm-dust messages "queryblock" and "clearbadblocks" now print
the function name in the DMEMIT output. Update the documentation
to match the appearance of the actual output.
Signed-off-by: Bryan Gurney
---
Documentation/admin-guide/device-mapper/dm-dust.rst | 8
1 file changed, 4
On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
>
> Since we support the listbadblocks command, introduce the detail in the
> doc.
>
> Signed-off-by: yangerkun
> ---
> .../admin-guide/device-mapper/dm-dust.rst| 16
> 1 file changed, 16 insertions(+)
>
> diff --git
On Fri, Jun 19, 2020 at 1:29 PM Mike Snitzer wrote:
>
> On Fri, Jun 19 2020 at 1:23pm -0400,
> Bryan Gurney wrote:
>
> > On Fri, Jun 19, 2020 at 11:45 AM Mike Snitzer wrote:
> > >
> > > On Fri, Jun 19 2020 at 11:40am -0400,
> > > Bryan Gurney wrote:
> > >
> > > > On Fri, Jun 19, 2020 at 8:37
Signed-off-by: Bryan Gurney
---
drivers/md/dm-dust.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-dust.c b/drivers/md/dm-dust.c
index 2ad8fc9293e0..e08f955dfe7b 100644
--- a/drivers/md/dm-dust.c
+++ b/drivers/md/dm-dust.c
@@ -148,9 +148,9 @@ static
On Fri, Jun 19 2020 at 12:06pm -0400,
Mike Snitzer wrote:
> On Fri, Jun 19 2020 at 6:11am -0400,
> Ming Lei wrote:
>
> > Hi Mike,
> >
> > On Fri, Jun 19, 2020 at 05:42:50AM -0400, Mike Snitzer wrote:
> > > Hi Ming,
> > >
> > > Thanks for the patch! But I'm having a hard time understanding
On Fri, Jun 19 2020 at 1:23pm -0400,
Bryan Gurney wrote:
> On Fri, Jun 19, 2020 at 11:45 AM Mike Snitzer wrote:
> >
> > On Fri, Jun 19 2020 at 11:40am -0400,
> > Bryan Gurney wrote:
> >
> > > On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
> > > >
> > > > Some type of
On Fri, Jun 19, 2020 at 11:45 AM Mike Snitzer wrote:
>
> On Fri, Jun 19 2020 at 11:40am -0400,
> Bryan Gurney wrote:
>
> > On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
> > >
> > > Some type of message(queryblock/countbadblocks/removebadblock) may better
> > > report results to user
On Fri, Jun 19 2020 at 12:41pm -0400,
Ignat Korchagin wrote:
> This is a follow up from the long-forgotten [1], but with some more convincing
> evidence. Consider the following script:
>
> #!/bin/bash -e
>
> # create 4G ramdisk
> sudo modprobe brd rd_nr=1 rd_size=4194304
>
> # create a
On Fri, Jun 19, 2020 at 01:42:47PM +, Martin Wilck wrote:
> On Thu, 2020-06-18 at 18:17 -0500, Benjamin Marzinski wrote:
> > On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
> > > On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > > >
> > > > static void
> > > > @@
On Fri, Jun 19, 2020 at 08:32:34AM +0200, Hannes Reinecke wrote:
> >>
> >>fac68d7 is related to the famous "dm-multipath: Accept failed paths for
> >>multipath maps" patch (e.g.
> >>https://patchwork.kernel.org/patch/3368381/#7193001), which never made
> >>it upstream. SUSE kernels have shipped
On Fri, Jun 19 2020 at 3:54am -0400,
Damien Le Moal wrote:
> On 2020/06/19 15:59, Johannes Thumshirn wrote:
> > REQ_OP_ZONE_APPEND bios cannot be split so return EIO if we can't fit it
> > into one IO.
> >
> > Signed-off-by: Johannes Thumshirn
> > ---
> > drivers/md/dm.c | 3 +++
> > 1 file
On Mon, Jun 15 2020 at 2:47am -0400,
Mauro Carvalho Chehab wrote:
> Solves this Sphinx warning:
> Documentation/admin-guide/device-mapper/dm-ebs.rst: WARNING: document
> isn't included in any toctree
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
On Fri, Jun 19 2020 at 6:11am -0400,
Ming Lei wrote:
> Hi Mike,
>
> On Fri, Jun 19, 2020 at 05:42:50AM -0400, Mike Snitzer wrote:
> > Hi Ming,
> >
> > Thanks for the patch! But I'm having a hard time understanding what
> > you've written in the patch header,
> >
> > On Fri, Jun 19 2020 at
On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
>
> This interface may help anyone who want to know all badblocks without
> query block for each.
>
> Signed-off-by: yangerkun
> ---
> drivers/md/dm-dust.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git
Add cond_resched to a loop that fills in the mapper memory area because
the loop can be executed many times.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernek.org
---
drivers/md/dm-writecache.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/drivers/md/dm-writecache.c
On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
>
> Since some type of message will report the results to user directly,
> we should update the doc too.
>
> Signed-off-by: yangerkun
> ---
> .../admin-guide/device-mapper/dm-dust.rst | 15 ---
> 1 file changed, 8
On Fri, Jun 19 2020 at 11:40am -0400,
Bryan Gurney wrote:
> On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
> >
> > Some type of message(queryblock/countbadblocks/removebadblock) may better
> > report results to user directly. Do it with DMEMIT.
> >
> > Signed-off-by: yangerkun
> > ---
> >
On Fri, Jun 19, 2020 at 8:37 AM yangerkun wrote:
>
> Some type of message(queryblock/countbadblocks/removebadblock) may better
> report results to user directly. Do it with DMEMIT.
>
> Signed-off-by: yangerkun
> ---
> drivers/md/dm-dust.c | 31 ++-
> 1 file changed,
On Thu, 2020-06-18 at 18:17 -0500, Benjamin Marzinski wrote:
> On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
> > On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
> > >
> > > static void
> > > @@ -2088,8 +2084,13 @@ check_path (struct vectors * vecs, struct
> > > path
On Thu, 2020-06-18 at 18:12 -0500, Benjamin Marzinski wrote:
> On Thu, Jun 18, 2020 at 08:37:20PM +, Martin Wilck wrote:
> >
> > > -int dm_flush_maps (int retries)
> > > +int dm_flush_maps (int need_suspend, int retries)
> > > {
> > > int r = 1;
> > > struct dm_task *dmt;
> > > @@
Naohiro reported that issuing zone-append bios to a zoned block device
underneath a dm-linear device does not work as expected.
This because we forgot to reverse-map the sector the device wrote to the
original bio.
For zone-append bios, get the offset in the zone of the written sector
from the
This interface may help anyone who want to know all badblocks without
query block for each.
Signed-off-by: yangerkun
---
drivers/md/dm-dust.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/md/dm-dust.c b/drivers/md/dm-dust.c
index
Some type of message(queryblock/countbadblocks/removebadblock) may better
report results to user directly. Do it with DMEMIT.
Signed-off-by: yangerkun
---
drivers/md/dm-dust.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git
REQ_OP_ZONE_APPEND bios cannot be split so return EIO if we can't fit it
into one IO.
Signed-off-by: Johannes Thumshirn
---
drivers/md/dm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 058c34abe9d1..c720a7e3269a 100644
--- a/drivers/md/dm.c
+++
Since we support the listbadblocks command, introduce the detail in the
doc.
Signed-off-by: yangerkun
---
.../admin-guide/device-mapper/dm-dust.rst| 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/admin-guide/device-mapper/dm-dust.rst
List all bad blocks may help user check the status of dust. We add this
logical in dust_status, which will return result to user directly.
Signed-off-by: yangerkun
---
drivers/md/dm-dust.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/md/dm-dust.c
在 2020/6/18 23:40, Mike Snitzer 写道:
On Thu, Jun 18 2020 at 5:06am -0400,
yangerkun wrote:
This patchset will list badblocks while we do 'dmsetup status'.
Image that we have mark block 1 and 2 as bad block, run following
command will list all bad blocks:
$ sudo dmsetup status dust1
Since some type of message will report the results to user directly,
we should update the doc too.
Signed-off-by: yangerkun
---
.../admin-guide/device-mapper/dm-dust.rst | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
This patchset will list badblocks while we do 'dmsetup status'.
Image that we have mark block 1 and 2 as bad block, run following
command will list all bad blocks:
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass verbose badblocks list: 1 2
v1->v2:
Realize this logical in
Since .message support report results to user directly. We can change
some type of message(queryblock/countbadblocks/removebadblock) to return
results to user.
Besides, we add a interface 'listbadblocks' to list all bad block. If
no bad block exists, we will return 'null', or we will list them
Since we can list bad blocks with command status, introduce the detail
in the doc.
Signed-off-by: yangerkun
---
.../admin-guide/device-mapper/dm-dust.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/admin-guide/device-mapper/dm-dust.rst
Two small fixes for issuing REQ_OP_ZONE_APPEND writes to device-mapper. The
first one is an issue reported by Naohiro and fixes a write failure. For
number two I'm not certain if it's the correct fix, hence the RFC tag.
Johannes Thumshirn (2):
dm: update original bio sector on Zone Append
dm:
Hi Mike,
On Fri, Jun 19, 2020 at 05:42:50AM -0400, Mike Snitzer wrote:
> Hi Ming,
>
> Thanks for the patch! But I'm having a hard time understanding what
> you've written in the patch header,
>
> On Fri, Jun 19 2020 at 4:42am -0400,
> Ming Lei wrote:
>
> > dm-rq won't stop queue, meantime
Hi Ming,
Thanks for the patch! But I'm having a hard time understanding what
you've written in the patch header,
On Fri, Jun 19 2020 at 4:42am -0400,
Ming Lei wrote:
> dm-rq won't stop queue, meantime blk-mq won't stop one queue too, so
> remove the check.
It'd be helpful if you could
dm-rq won't stop queue, meantime blk-mq won't stop one queue too, so
remove the check.
dm_stop_queue() actually tries to quiesce hw queues via blk_mq_quiesce_queue(),
we can't check via blk_queue_quiesced for avoiding unnecessary queue
quiesce because the flag is set before synchronize_rcu() and
On 6/19/20 9:49 AM, Damien Le Moal wrote:
From: Shin'ichiro Kawasaki
When dm zoned has multiple devices, random zones are never selected for
reclaim if all reserved sequential write zones are in use and no
sequential write required zones can be selected for reclaim. This can
lead to deadlocks
On 2020/06/19 15:59, Johannes Thumshirn wrote:
> REQ_OP_ZONE_APPEND bios cannot be split so return EIO if we can't fit it
> into one IO.
>
> Signed-off-by: Johannes Thumshirn
> ---
> drivers/md/dm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
>
On 2020/06/19 15:59, Johannes Thumshirn wrote:
> Naohiro reported that issuing zone-append bios to a zoned block device
> underneath a dm-linear device does not work as expected.
>
> This because we forgot to reverse-map the sector the device wrote to the
> original bio.
>
> For zone-append
From: Shin'ichiro Kawasaki
When dm zoned has multiple devices, random zones are never selected for
reclaim if all reserved sequential write zones are in use and no
sequential write required zones can be selected for reclaim. This can
lead to deadlocks as selecting a cache zone allows reclaiming
A couple of fixes for dm-zoned which solve target hangs under severe
zone shortage conditions with a write intensive workload. Both fixes are
for reclaim zone selection.
Damien Le Moal (1):
dm zoned: Fix random zone reclaim selection
Shin'ichiro Kawasaki (1):
dm zoned: Fix reclaim zone
Commit 2094045fe5b5 ("dm zoned: prefer full zones for reclaim")
modified dmz_get_rnd_zone_for_reclaim() to add a search for the buffer
zone with the heaviest weight as an optimal candidate for reclaim. This
modification uses the zone pointer variabl "last" which is set only once
and never modified
On 6/19/20 1:17 AM, Benjamin Marzinski wrote:
On Thu, Jun 18, 2020 at 07:34:38PM +, Martin Wilck wrote:
On Wed, 2020-06-17 at 19:24 -0500, Benjamin Marzinski wrote:
If a multipath device is removed during, or immediately before the
call
to check_path(), multipathd can behave incorrectly. A
56 matches
Mail list logo
