On Tue, 31 Mar 2020, Dan Williams wrote:
> > The benchmark shows that 64-byte non-temporal avx512 vmovntdq is as good
> > as 8, 16 or 32-bytes writes.
> > ramnvdimm
> > sequential write-nt 4 bytes 4.1 GB/s 1.3 GB/s
> > sequ
If all the bytes are equal to DISCARD_FILLER, we want to accept the
buffer. If any of the bytes is different, we must do thorough tag-by-tag
checking.
The condition was inverted.
Signed-off-by: Mikulas Patocka
Fixes: 84597a44a9d8 ("dm integrity: add optional discard support")
--
dri
: Mikulas Patocka
I tested dm-writecache performance on a machine with Optane nvdimm and it
turned out that for larger writes, cached stores + cache flushing perform
better than non-temporal stores. This is the throughput of dm-writecache
measured with this command:
dd if=/dev/zero of=/dev/mapper
On Tue, 7 Apr 2020, Andy Lutomirski wrote:
>
> > On Apr 7, 2020, at 8:01 AM, Mikulas Patocka wrote:
> >
> > [ resending this to x86 maintainers ]
> >
> > Hi
> >
> > I tested performance of various methods how to write to optane-based
> >
On Tue, 7 Apr 2020, Dan Williams wrote:
> On Tue, Apr 7, 2020 at 8:02 AM Mikulas Patocka wrote:
> >
> > [ resending this to x86 maintainers ]
> >
> > Hi
> >
> > I tested performance of various methods how to write to optane-based
> > persistent m
. destroy old target
Metadata that were written by the old target between steps 1 and 2 would
not be visible by the new target.
This patch fixes the data corruption by loading the metadata in the resume
handler.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v4.18+
Fixes: 48debafe4f2f
On Wed, 8 Apr 2020, Dan Williams wrote:
> On Wed, Apr 8, 2020 at 11:54 AM Mikulas Patocka wrote:
> >
> >
> >
> > On Tue, 7 Apr 2020, Dan Williams wrote:
> >
> > > On Tue, Apr 7, 2020 at 8:02 AM Mikulas Patocka
> > > wrote:
> > >
On Tue, 14 Apr 2020, Mike Snitzer wrote:
> On Wed, Apr 08 2020 at 3:02pm -0400,
> Mikulas Patocka wrote:
>
> > The dm-writecache reads metadata in the target constructor. However, when
> > we reload the target, there could be another active instance running on
> &g
size(wc->ssd_dev->bdev) >> SECTOR_SHIFT,
+ (sector_t)wc->metadata_sectors));
From: Mikulas Patocka
dm writecache: fix data corruption when reloading the target
The dm-writecache reads metadata in the target constructor. However, when
we reload the target, ther
On Wed, 15 Apr 2020, Mike Snitzer wrote:
> > > > + r = writecache_read_metadata(wc,
> > > > +
> > > > min((sector_t)bdev_logical_block_size(wc->ssd_dev->bdev) >>
> > > > SECTOR_SHIFT,
> > > > + (sector_t)wc->metadata_sectors));
> >
nging memcpy_flushcache.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-writecache.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/md/dm-writecache.c
===
--- linux-2.6.orig/dr
On Wed, 15 Apr 2020, Mikulas Patocka wrote:
>
>
> On Wed, 15 Apr 2020, Mike Snitzer wrote:
>
> > > > > + r = writecache_read_metadata(wc,
> > > > > +
> > > > > min((sector_t)bdev_logical
old target
Metadata that were written by the old target between steps 1 and 2 would
not be visible by the new target.
This patch fixes the data corruption by loading the metadata in the resume
handler.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v4.18+
Fixes: 48debafe4f2f
Test if dm-writecache block size is smaller than devices' logical block
size and reject target load in that case.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-writecache.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6/drivers/md/dm-writeca
On Thu, 9 Apr 2020, Mikulas Patocka wrote:
> With dm-writecache on emulated pmem (with the memmap argument), we get
>
> With the original kernel:
> 8508 - 11378
> real0m4.960s
> user0m0.638s
> sys 0m4.312s
>
> With dm-writecache hacked to use cached
On Thu, 16 Apr 2020, Dan Williams wrote:
> On Thu, Apr 16, 2020 at 1:24 AM Mikulas Patocka wrote:
> >
> >
> >
> > On Thu, 9 Apr 2020, Mikulas Patocka wrote:
> >
> > > With dm-writecache on emulated pmem (with the memmap argument), we get
> &
On Sat, 18 Apr 2020, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 17 April 2020 13:47
> ...
> > Index: linux-2.6/drivers/md/dm-writecache.c
> > ===
> > --- linux-2.6.orig/drivers/md/dm
Remove superfluous test if dax_dev is NULL - dax_direct_access already
does this test.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-writecache.c |4
1 file changed, 4 deletions(-)
Index: linux-2.6/drivers/md/dm-writecache.c
memcpy_flushcache_bikesheddedname(data, buf, size);
>
> and have the default fallback memcpy_flushcache() and let the
> architecture sort the size limit and the underlying technology out.
>
> So x86 can use clflushopt or implement it with movdir64b and any other
> architect
Hi
This is the clflushopt patch for the next merge window.
Mikulas
From: Mikulas Patocka
When testing the dm-writecache target on a real Optane-based persistent
memory, it turned out that explicit cache flushing using the clflushopt
instruction performs better than non-temporal stores for
On Wed, 29 Apr 2020, Heinz Mauelshagen wrote:
> On 4/29/20 6:30 PM, Mikulas Patocka wrote:
> > Hi
> >
> > This is the clflushopt patch for the next merge window.
> >
> > Mikulas
> >
> >
> > From: Mikulas Patocka
> >
> &g
On Thu, 30 Apr 2020, Mike Snitzer wrote:
> On Thu, Apr 30 2020 at 1:49pm -0400,
> Gabriel Krisman Bertazi wrote:
>
> > Gabriel Krisman Bertazi writes:
> >
> > > Hi Mike,
> > >
> > > Please find an updated version of HST integrating the change you
> > > requested to also support BIO based m
Hi
I suggest to delete dm_bufio_discard_buffers because no one is using it.
If you need it in the future, tell me - and I will optimize it, so that it
walks the rb-tree of buffers instead of doing block-by-block lookups.
Mikulas
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
inde
On Sat, 30 May 2020, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> When wc_entry has been removed from wbl->list in writeback, it will
> be not used again except waiting to be set free in writecache_free_entry.
>
> That is a little of annoying, it has to reinitialize lru of wc_entry
> in endi
iable backed_off) and
if we finish the request, we return -EINPROGRESS to indicate that the user
can send more requests.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_a
retry.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/md/dm-crypt.c
===
--- linux-2.6.orig/drivers/md/dm-crypt.c
+++ linux-2.6/drivers/md/dm-crypt.c
@@ -1534,6 +1534,7 @@ static blk_status_t
Hi
These patches fix bugs in the Intel QAT driver.
https://bugzilla.redhat.com/show_bug.cgi?id=1813394
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Use GFP_KERNEL when the flag CRYPTO_TFM_REQ_MAY_SLEEP is present.
Also, use GFP_KERNEL when setting a key.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_algs.c
the caller should stop sending more requests.
When the request is returned with -EINPROGRESS, the caller can send more
requests.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_asym_algs.c
cause I/O
errors. So, we sleep and retry.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/md/dm-integrity.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/drivers/md/dm-integrity.c
===
--- linux
Hi
These patches add a new function dm_bufio_forger_buffers and use it in the
dm-ebs target. It is more efficient than calling dm_bufio_forget in a
loop. The loop could cause excessive CPU consumption when discarding a
larget range.
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://ww
Introduce a function forget_buffer_locked that forgets a range of buffers.
It is more efficient than calling forget_buffer in a loop.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-bufio.c| 60 +++
include/linux/dm-bufio.h |7 +
2
Use dm_bufio_forget_buffers instead of block-by-block loop and
dm_bufio_forget. dm_bufio_forget_buffers is faster than the loop because
it searches for used buffers using rb-tree.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-ebs-target.c |4 ++--
1 file changed, 2 insertions(+), 2
dm-bufio use unnatural ordering in the rb-tree - blocks with smaller
nubmers were put to the right node and blocks with bigget numbers were put
to the left node.
This patch reverses the logic, so that i's natural.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-bufio.c |6 +++---
1
This patch adds status line documentation.
Signed-off-by: Mikulas Patocka
---
Documentation/admin-guide/device-mapper/dm-integrity.rst |8
1 file changed, 8 insertions(+)
Index: linux-2.6/Documentation/admin-guide/device-mapper/dm-integrity.rst
On Tue, 2 Jun 2020, Giovanni Cabiddu wrote:
> Hi Mikulas,
>
> thanks for your patch. See below.
>
> > + qat_req->backed_off = backed_off =
> > adf_should_back_off(ctx->inst->sym_tx);
> > +again:
> > + ret = adf_send_message(ctx->inst->sym_tx, (uint32_t *)msg);
> > if (ret == -EAGAIN)
On Wed, 3 Jun 2020, Giovanni Cabiddu wrote:
> > > > +bool adf_should_back_off(struct adf_etr_ring_data *ring)
> > > > +{
> > > > + return atomic_read(ring->inflights) >
> > > > ADF_MAX_INFLIGHTS(ring->ring_size, ring->msg_size) * 15 / 16;
> > > How did you came up with 15/16?
> >
> > I
fix an integer overflow in logical block size")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
Reviewed-by: Mikulas Patocka
> ---
> drivers/md/dm-crypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm-crypt.c b/driv
Hi
I'd like to ask to remove these two patches:
> dm crypt: sleep and retry on allocation errors
> dm integrity: sleep and retry on allocation errors
Retrying the request in dm-crypt is not safe because crypt_convert_block
already advanced to the next block (even in the case of allo
Hi
I've found out that a lot of hardware crypto drivers use GFP_ATOMIC. Some
of them switch between GFP_ATOMIC and GFP_KERNEL based on the flag
CRYPTO_TFM_REQ_MAY_SLEEP.
dm-crypt and dm-integrity don't use CRYPTO_TFM_REQ_MAY_SLEEP (because
GFP_KERNEL allocation requests can recurse back to the
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
> >
> > Do you have another idea how to solve this problem?
>
> I think the better approach would be to modify the drivers to not
> allocate any memory. In gener
On Fri, 12 Jun 2020, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> When uncommitted entry has been discarded, correct wc->uncommitted_block
> for getting the exact number.
>
> Signed-off-by: Huaisheng Ye
Acked-by: Mikulas Patocka
Also, add:
Cc: sta...@vger.kernel.org
On Fri, 12 Jun 2020, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> The array bio_in_progress is only used with ssd mode. So skip
> writecache_wait_for_ios in writecache_discard when pmem mode.
>
> Signed-off-by: Huaisheng Ye
Acked-by: Mikulas Patocka
> ---
> dr
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote:
> >
> > Yes, fixing the drivers would be the best - but you can hardly find any
> > person who has all the crypto hardware and who is willing to rewrite all
&
anytime (causing random I/O errors) and
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Signed-off-by: Mikulas Patocka
Index: linux-2.6/include/linux/crypto.h
===
--- linux-2.6.orig/include/linux/crypto.h
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5 +++--
crypto/ccm.c |7 ---
crypto/chacha20poly1305.c
Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
that sleeps.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/amlogic/amlogic-gxl-cipher.c |5 ++-
drivers/crypto/cavium/cpt/cptvf_a
Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
allocate memory.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c |8 +-
drivers/crypto/amlogic/amlogic-gxl-core.c
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> > CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> > that s
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 02:18:17PM -0400, Mikulas Patocka wrote:
> >
> >
> > On Tue, 16 Jun 2020, Eric Biggers wrote:
> >
> > > On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > >
There is this call chain:
cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v4.11+
Fixes:
There is this call chain:
sec_alg_skcipher_encrypt -> sec_alg_skcipher_crypto ->
sec_alg_alloc_and_calc_split_sizes -> kcalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
I'm resending the patches with your comments resolved...
Mikulas
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 11:01:31AM -0400, Mikulas Patocka wrote:
> > Introduce a new flag CRYPTO_ALG_ALLOCATES_MEMORY and modify dm-crypt, so
> > that it uses only
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5 +++--
crypto/ccm.c |7 ---
crypto/chacha20poly1305.c
drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher
Signed-off-by: Mikulas Patocka
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c |8 +-
drivers/crypto/amlogic/amlogic-gxl-core.c |4 -
drivers/crypto/axis
Don't use crypto drivers that have the flag CRYPTO_ALG_ALLOCATES_MEMORY
set. These drivers allocate memory and thus they are unsuitable for block
I/O processing.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-crypt.c | 17 +++--
1 file changed, 11 insertions(+), 6 dele
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, 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]: https://www.spinics.net/lists/dm-crypt
On Sat, 20 Jun 2020, Herbert Xu wrote:
> 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'
Hi
I suggest to join memalloc_noio and memalloc_nofs into just one flag that
prevents both filesystem recursion and i/o recursion.
Note that any I/O can recurse into a filesystem via the loop device, thus
it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is set
and PF_MEMALLO
On Fri, 26 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 17, 2020 at 11:09:28AM -0400, Mikulas Patocka wrote:
> >
> > Index: linux-2.6/include/linux/crypto.h
> > ===
> > --- linux-2.6.orig/include/linux
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5
On Sat, 27 Jun 2020, Dave Chinner wrote:
> On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote:
> > Hi
> >
> > I suggest to join memalloc_noio and memalloc_nofs into just one flag that
> > prevents both filesystem recursion and i/o recursion.
>
On Fri, 26 Jun 2020, Eric Biggers wrote:
> On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> > +/*
> > + * Pass these flags down through the crypto API.
> > + */
> > +#define CRYPTO_ALG_INHERITED_FLAGS (CRYPTO_ALG_ASYNC |
> > CRYPTO_ALG_ALLOC
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |2 +-
crypto/authenc.c |4 ++--
crypto/authencesn.c |4
On Fri, 26 Jun 2020, Eric Biggers wrote:
> On Fri, Jun 26, 2020 at 09:46:17AM -0700, Eric Biggers wrote:
> > On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> > > +/*
> > > + * Pass these flags down through the crypto API.
> > > + */
>
On Sun, 28 Jun 2020, Eric Biggers wrote:
> On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> > >
> > > cryptd_create_skcipher(), cryptd_create_hash(), cryptd_create_aead(), and
> > > crypto_rfc4309_create() are also missing setting the mask.
&
On Mon, 29 Jun 2020, Dave Chinner wrote:
> On Sat, Jun 27, 2020 at 09:09:09AM -0400, Mikulas Patocka wrote:
> >
> >
> > On Sat, 27 Jun 2020, Dave Chinner wrote:
> >
> > > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote:
> >
On Tue, 30 Jun 2020, Michal Suchanek wrote:
> The writecache driver does not handle asynchronous pmem. Reject it when
> supplied as cache.
>
> Link: https://lore.kernel.org/linux-nvdimm/87lfk5hahc@linux.ibm.com/
> Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver")
>
> Signed-off-
On Mon, 29 Jun 2020, Mikulas Patocka wrote:
> On Sun, 28 Jun 2020, Eric Biggers wrote:
>
> > On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> > > >
> > > > cryptd_create_skcipher(), cryptd_create_hash(), cryptd_create_aead(),
> > &
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |2 +-
crypto/authenc.c |7 ---
crypto/authencesn.c |7
On Sun, 28 Jun 2020, Eric Biggers wrote:
> On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> >
> > > Also, "seqiv" instances can be created without
> > > CRYPTO_ALG_ALLOCATES_MEMORY set,
> > > despite seqiv_aead_encrypt() allo
On Tue, 30 Jun 2020, Michal Suchanek wrote:
> The writecache driver does not handle asynchronous pmem. Reject it when
> supplied as cache.
>
> Link: https://lore.kernel.org/linux-nvdimm/87lfk5hahc@linux.ibm.com/
> Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver")
>
> Signed-off-
er")
>
> Signed-off-by: Michal Suchanek
Acked-by: Mikulas Patocka
> ---
> drivers/md/dm-writecache.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c
> index 30505d70f423..5358894bb9fd 100644
&
On Tue, 30 Jun 2020, Mikulas Patocka wrote:
>
>
> On Tue, 30 Jun 2020, Michal Suchanek wrote:
>
> > The writecache driver does not handle asynchronous pmem. Reject it when
> > supplied as cache.
> >
> > Link: https://lore.kernel.org/linux-nvdimm/87l
On Tue, 30 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 30, 2020 at 09:56:22AM -0400, Mikulas Patocka wrote:
> > Index: linux-2.6/crypto/cryptd.c
> > ===
> > --- linux-2.6.orig/crypto/cryptd.c 2020-06-29 16:
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |8 +---
crypto/authenc.c |7 ---
crypto/authencesn.c
On Tue, 30 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 30, 2020 at 01:01:16PM -0400, Mikulas Patocka wrote:
> > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
> > > index 7240e8bbdebb..643f7f1cc91c 100644
> > > --- a/crypto/pcrypt.c
> > > +++ b/c
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |8 +---
crypto/authenc.c |7 ---
crypto/authencesn.c
nts from aead_geniv_alloc()
> crypto: algapi - use common mechanism for inheriting flags
> crypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY
> crypto: algapi - remove crypto_check_attr_type()
>
> Mikulas Patocka (2):
> crypto: set the flag CRYPTO_ALG_A
Hi
I report a crash in md-raid. I have 5.8-rc3 kernel with debugging enabled.
The crash happened when running the "shell/integrity-blocksize.sh" lvm
test.
The crash is not reproducible.
Mikulas
[ 1188.640677] device-mapper: raid: Superblocks created for new raid set
[ 1188.679378] md/raid1:m
o a workqueue. Please review
it.
Mikulas
From: Mikulas Patocka
kswapd should not block because it degrades system performance.
So, move reclaim of buffers to a workqueue.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-bufio.c | 60 ++
1 fi
On Mon, 6 Jul 2020, Eric Biggers wrote:
> On Wed, Jul 01, 2020 at 03:59:10AM -0400, Mikulas Patocka wrote:
> > Thanks for cleaning this up.
> >
> > Mikulas
>
> Do you have any real comments on this?
>
> Are the usage restrictions okay for dm-crypt?
>
bc34a2
Signed-off-by: Mikulas Patocka
Reported-by: Khazhismel Kumykov
Reported-by: Tahsin Erdogan
Reported-by: Gabriel Krisman Bertazi
Cc: sta...@vger.kernel.org
---
drivers/md/dm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/m
On Mon, 13 Jul 2020, Horia Geantă wrote:
> On 7/13/2020 7:01 PM, Eric Biggers wrote:
> > On Mon, Jul 13, 2020 at 06:49:00PM +0300, Horia Geantă wrote:
> >> On 7/1/2020 7:52 AM, Eric Biggers wrote:
> >>> From: Mikulas Patocka
> >>>
> >>>
turns off the allocation on read.
Signed-off-by: Mikulas Patocka
---
mm/shmem.c |8
1 file changed, 8 deletions(-)
Index: linux-2.6/mm/shmem.c
===
--- linux-2.6.orig/mm/shmem.c 2020-06-29 14:50:06.0 +0200
Hi Mike
Please submit this to Linus and to RHEL-8.
Mikulas
From: Mikulas Patocka
The patch adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 broke recalculation on
dm-integrity. The patch replaces a private variable "suspending" with a
call to "dm_suspended".
The problem
On Wed, 22 Jul 2020, Mike Snitzer wrote:
> On Wed, Jul 22 2020 at 2:46pm -0400,
> Mikulas Patocka wrote:
>
> > Hi Mike
> >
> > Please submit this to Linus and to RHEL-8.
> >
> > Mikulas
> >
> >
> >
> > From: Mikulas Patoc
On Wed, 22 Jul 2020, Mikulas Patocka wrote:
>
>
> On Wed, 22 Jul 2020, Mike Snitzer wrote:
>
> > On Wed, Jul 22 2020 at 2:46pm -0400,
> > Mikulas Patocka wrote:
> >
> > > Hi Mike
> > >
> > > Please submit this to Linus and to RHE
On Thu, 23 Jul 2020, Mike Snitzer wrote:
> On Thu, Jul 23 2020 at 10:42am -0400,
> Mikulas Patocka wrote:
>
> > In order to fix this race condition, we add a function dm_suspending that
> > is only true during the postsuspend phase and use it instea
fsets passed to dax_direct_access.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # 4.18+
Fixes: 48debafe4f2f ("dm: add writecache target")
---
drivers/md/dm-writecache.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/md/
not see the problem if the corruption occured while the LV was
> inactive.
Hi
Here I'm submitting a patch for this bug. Try it.
Mikulas
From: Mikulas Patocka
Subject: [PATCH] dm-integrity: fix error reporting in bitmap mode after creation
The dm-integrity target did not report errors
On Wed, 23 Sep 2020, Sudhakar Panneerselvam wrote:
> Could someone review this patch set, please?
>
> Thanks
> Sudhakar
Hi
I'd like to ask - what sector size do you use in dm-crypt? Could the issue
be fixed just by using the smallest possible 512-byte sectors?
What I/O method does qemu use
On Wed, 23 Sep 2020, Mike Snitzer wrote:
> You've clearly done a nice job with these changes. Looks clean.
>
> BUT, I'm struggling to just accept that dm-crypt needs to go to these
> extra lengths purely because of one bad apple usecase.
>
> These alignment constraints aren't new. Are there
Hi Mike
Could you send this to Linus before v5.9 is released?
Mikulas
From: Mikulas Patocka
If q->limits.discard_granularity is zero, the block core will warn in
__blkdev_issue_discard. This patch sets it to a minimum - 512 bytes.
Signed-off-by: Mikulas Patocka
Fixes: b35fd7422c2f (&qu
On Thu, 24 Sep 2020, Mike Snitzer wrote:
> On Thu, Sep 24 2020 at 10:34am -0400,
> Mikulas Patocka wrote:
>
> > Hi Mike
> >
> > Could you send this to Linus before v5.9 is released?
> >
> > Mikulas
> >
> >
> >
> > From: Mik
This patch fixes a warning WARN_ON_ONCE(!q->limits.discard_granularity).
The reason is that the function raid_io_hints overwrote
limits->discard_granularity with zero. We need to properly stack the
limits instead of overwriting them.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kern
On Thu, 24 Sep 2020, John Dorminy wrote:
> I don't understand how this works...
>
> Can chunk_size_bytes be 0? If not, how is discard_granularity being set to 0?
Yes - chunk_size_bytes is 0 here.
> I think also limits is local to the ti in question here, initialized
> by blk_set_stacking_lim
On Thu, 24 Sep 2020, Mike Snitzer wrote:
> WAIT... Could it be that raid_io_hints _really_ meant to special case
> raid0 and raid10 -- due to their striping/splitting requirements!?
> So, not raid1 but raid0?
>
> E.g.:
>
> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
> index 56b72
On Thu, 24 Sep 2020, Sudhakar Panneerselvam wrote:
> Hello Eric,
>
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@kernel.org]
> > Sent: Wednesday, September 23, 2020 11:14 PM
> > To: Mike Snitzer
> > Cc: Sudhakar Panneerselvam ;
> > damien.lem...@wdc.com; ssudhak...@gm
1 - 100 of 1094 matches
Mail list logo
