On Thu, 16 Jan 2025, Jan Beulich wrote:
> On 15.01.2025 19:02, Mikulas Patocka wrote:
> > On Tue, 14 Jan 2025, Sami Tolvanen wrote:
> >> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka
> >> wrote:
> >>> On PA-RISC, with the kernel 6.12.9, I get unalign
On Tue, 14 Jan 2025, Sami Tolvanen wrote:
> Hi Mikulas,
>
> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka wrote:
> >
> > Hi
> >
> > On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> > a module is loaded. The w
Hi
On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
a module is loaded. The warnings are caused by the fact that the
.gnu.linkonce.this_module section is not aligned to the appropriate
boundary. If I dump the module content with "objdump -h configs.ko", I get
this. Not
On Wed, 7 Apr 2021, Linus Torvalds wrote:
> On Wed, Apr 7, 2021 at 9:33 AM Suren Baghdasaryan wrote:
> >
> > Trying my hand at backporting the patchsets Peter mentioned proved
> > this to be far from easy with many dependencies. Let me look into
> > Vlastimil's suggestion to backport only 1783
Hi
I announce a new version of NVFS - a filesystem for persistent memory.
http://people.redhat.com/~mpatocka/nvfs/
git://leontynka.twibright.com/nvfs.git
Changes since the last release:
I reworked file read/write handling:
* the functions nvfs_read and nvfs_write were deleted be
On Thu, 21 Jan 2021, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 10:12:01AM -0500, Mikulas Patocka wrote:
> > Do you have some idea how to optimize the generic code that calls
> > ->read_iter?
>
> Yes.
>
> > It might be better to maintain an f_iocb_flag
On Wed, 20 Jan 2021, Jan Kara wrote:
> Yeah, I agree. I'm against ext4 private solution for this read problem. And
> I'm also against duplicating ->read_iter functionatily in ->read handler.
> The maintenance burden of this code duplication is IMHO just too big. We
> rather need to improve the
On Tue, 12 Jan 2021, Zhongwei Cai wrote:
>
> I'm working with Mingkai on optimizations for Ext4-dax.
What specific patch are you working on? Please, post it somewhere.
> We think that optmizing the read-iter method cannot achieve the
> same performance as the read method for Ext4-dax.
> We
On Mon, 11 Jan 2021, Matthew Wilcox wrote:
> On Sun, Jan 10, 2021 at 04:19:15PM -0500, Mikulas Patocka wrote:
> > I put counters into vfs_read and vfs_readv.
> >
> > After a fresh boot of the virtual machine, the counters show "13385 4".
> > After a ke
On Mon, 11 Jan 2021, David Laight wrote:
> From: Al Viro On Behalf Of Al Viro
> > Sent: 10 January 2021 16:20
> >
> > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > > Hi
> > >
> > > I announce a new version of NVFS -
On Sun, 10 Jan 2021, Al Viro wrote:
> On Sun, Jan 10, 2021 at 04:14:55PM -0500, Mikulas Patocka wrote:
>
> > That's a good point. I split nvfs_rw_iter to separate functions
> > nvfs_read_iter and nvfs_write_iter - and inlined nvfs_rw_iter_locked into
> &
On Sun, 10 Jan 2021, Matthew Wilcox wrote:
> > That is the reason for that 10% degradation with read_iter.
>
> You seem to be focusing on your argument for "let's just permit
> filesystems to implement both ->read and ->read_iter". My suggestion
> is that we need to optimise the ->read_iter p
On Sun, 10 Jan 2021, Al Viro wrote:
> On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > Hi
> >
> > I announce a new version of NVFS - a filesystem for persistent memory.
> > http://people.redhat.com/~mpatocka/nvfs/
> Ut
On Thu, 7 Jan 2021, Matthew Wilcox wrote:
> On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > I'd like to ask about this piece of code in __kernel_read:
> > if (unlikely(!file->f_op->read_iter || file->f_op->read))
> >
Hi
I announce a new version of NVFS - a filesystem for persistent memory.
http://people.redhat.com/~mpatocka/nvfs/
git://leontynka.twibright.com/nvfs.git
Changes since the last release:
* I added a microjournal to the filesystem, it can hold up to 16 entries.
Each CPU has it's
softirq
>
> drivers/md/dm-crypt.c | 138 +-
> 1 file changed, 123 insertions(+), 15 deletions(-)
>
> --
> 2.20.1
>
Acked-by: Mikulas Patocka
On Wed, 30 Dec 2020, Ignat Korchagin wrote:
> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> index 53791138d78b..e4fd690c70e1 100644
> --- a/drivers/md/dm-crypt.c
> +++ b/drivers/md/dm-crypt.c
> @@ -1539,7 +1549,10 @@ static blk_status_t crypt_convert(struct crypt_config
> *cc,
>
Hi
This patch doesn't handle allocation failure gracefully.
Mikulas
On Tue, 29 Dec 2020, Ignat Korchagin wrote:
> Commit 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 made it possible for some code
> paths in dm-crypt to be executed in softirq context, when the underlying
> driver
> processes IO
On Fri, 11 Dec 2020, Johannes Thumshirn wrote:
> On 11/12/2020 15:57, SelvaKumar S wrote:
> [...]
> > +int blk_copy_emulate(struct block_device *bdev, struct blk_copy_payload
> > *payload,
> > + gfp_t gfp_mask)
> > +{
> > + struct request_queue *q = bdev_get_queue(bdev);
> > + s
e called. And if
it can't be called, you don't need to add a code that prints an error in
that case.
If we don't have DM_WRITECACHE_HAS_PMEM, the compiler optimizer will
remove all the code guarded with if (WC_MODE_PMEM(wc)) as unreachable.
Mikulas
From: Mikulas Patocka
Subject:
Acked-by: Mikulas Patocka
On Tue, 10 Nov 2020, Nick Desaulniers wrote:
> This reverts commit 43aeaa29573924df76f44eda2bbd94ca36e407b5.
>
> Since
> commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
> the minimum supported version of GCC is gcc-4.9
On Thu, 24 Sep 2020, Mikulas Patocka wrote:
> On Tue, 22 Sep 2020, Matthew Wilcox wrote:
>
> > > There is a small window when renamed inode is neither in source nor in
> > > target directory. Fsck will reclaim such inode and add it to lost+found -
> > > jus
On Tue, 22 Sep 2020, Matthew Wilcox wrote:
> > > The NVFS indirect block tree has a fan-out of 16,
> >
> > No. The top level in the inode contains 16 blocks (11 direct and 5
> > indirect). And each indirect block can have 512 pointers (4096/8). You can
> > format the device with larger block
On Wed, 23 Sep 2020, Dave Chinner wrote:
> > > dir-test /mnt/test/linux-2.6 63000 1048576
> > > nvfs 6.6s
> > > ext4 dax 8.4s
> > > xfs dax 12.2s
> > >
> > >
> > > dir-test /mnt/test/linux-2.6 63000 1048576 link
> > > nvfs 4.7s
> > > ext4 dax 5.6s
> > > x
On Wed, 23 Sep 2020, Jan Kara wrote:
> On Tue 22-09-20 12:46:05, Mikulas Patocka wrote:
> > > mapping 2^21 blocks requires a 5 level indirect tree. Which one if going
> > > to be faster to truncate away - a single record or 2 million individual
> > > blocks?
On Wed, 23 Sep 2020, Jan Kara wrote:
> Hi!
>
> On Wed 23-09-20 05:20:55, Mikulas Patocka wrote:
> > There seems to be a bug in ext4 - when I create very large directory, ext4
> > fails with -ENOSPC despite the fact that there is plenty of free space and
> > fr
Hi
There seems to be a bug in ext4 - when I create very large directory, ext4
fails with -ENOSPC despite the fact that there is plenty of free space and
free inodes on the filesystem.
How to reproduce:
download the program dir-test:
http://people.redhat.com/~mpatocka/benchmarks/dir-test.c
# m
sn't clearly explained
>
> On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote:
> > On Wed, 16 Sep 2020, Mikulas Patocka wrote:
> > > On Wed, 16 Sep 2020, Dan Williams wrote:
> > > > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka
>
On Tue, 22 Sep 2020, Matthew Wilcox wrote:
> On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote:
> > The same for directories - NVFS hashes the file name and uses radix-tree
> > to locate a directory page where the directory entry is located. XFS
> > b+trees
On Wed, 16 Sep 2020, Mikulas Patocka wrote:
>
>
> On Wed, 16 Sep 2020, Dan Williams wrote:
>
> > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka
> > wrote:
> > >
> > > > My first question about nvfs is how it compares to a daxfs with
> &g
On Tue, 15 Sep 2020, Dan Williams wrote:
> > TODO:
> >
> > - programs run approximately 4% slower when running from Optane-based
> > persistent memory. Therefore, programs and libraries should use page cache
> > and not DAX mapping.
>
> This needs to be based on platform firmware data f(ACPI H
Hi
I'd like to ask about this problem: when we write to a file, the kernel
takes the write inode lock. When we read from a file, no lock is taken -
thus the read syscall can read data that are halfway modified by the write
syscall.
The standard specifies the effects of the write syscall are at
On Wed, 16 Sep 2020, Dan Williams wrote:
> On Wed, Sep 16, 2020 at 3:57 AM Mikulas Patocka wrote:
> >
> >
> >
> > I'm submitting this patch that adds the required exports (so that we could
> > use __copy_from_user_flushcache on x86, arm64 and powerpc). P
On Wed, 16 Sep 2020, Dan Williams wrote:
> On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka wrote:
> >
> >
> >
> > On Wed, 16 Sep 2020, Dan Williams wrote:
> >
> > > On Wed, Sep 16, 2020 at 3:57 AM Mikulas Patocka
> > > wrote:
> > &
On Wed, 16 Sep 2020, Dan Williams wrote:
> On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka wrote:
> >
> > > My first question about nvfs is how it compares to a daxfs with
> > > executables and other binaries configured to use page cache with the
> > > new
On Tue, 15 Sep 2020, Mikulas Patocka wrote:
>
>
> On Tue, 15 Sep 2020, Mikulas Patocka wrote:
>
> > > > - __copy_from_user_inatomic_nocache doesn't flush cache for leading and
> > > > trailing bytes.
> > >
> > > You
On Tue, 15 Sep 2020, Matthew Wilcox wrote:
> On Tue, Sep 15, 2020 at 08:34:41AM -0400, Mikulas Patocka wrote:
> > - when the fsck.nvfs tool mmaps the device /dev/pmem0, the kernel uses
> > buffer cache for the mapping. The buffer cache slows does fsck by a factor
> > of
On Tue, 15 Sep 2020, Dan Williams wrote:
> > - when the fsck.nvfs tool mmaps the device /dev/pmem0, the kernel uses
> > buffer cache for the mapping. The buffer cache slows does fsck by a factor
> > of 5 to 10. Could it be possible to change the kernel so that it maps DAX
> > based block device
On Tue, 15 Sep 2020, Mikulas Patocka wrote:
> > > - __copy_from_user_inatomic_nocache doesn't flush cache for leading and
> > > trailing bytes.
> >
> > You want copy_user_flushcache(). See how fs/dax.c arranges for
> > dax_copy_from_iter() to r
Hi
I am developing a new filesystem suitable for persistent memory - nvfs.
The goal is to have a small and fast filesystem that can be used on
DAX-based devices. Nvfs maps the whole device into linear address space
and it completely bypasses the overhead of the block layer and buffer
cache.
I
On Wed, 9 Sep 2020, Darrick J. Wong wrote:
> On Sat, Sep 05, 2020 at 01:02:33PM -0400, Mikulas Patocka wrote:
> > > >
> >
> > I've written this program that tests it - you can integrate it into your
> > testsuite.
>
> I don't get it. You&#
section, and these faults will incorrectly update the timestamp of the
objtool binary. The updated timestamp causes make to rebuild the whole
tree.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
fs/xfs/xfs_file.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions
On Sat, 5 Sep 2020, Darrick J. Wong wrote:
> On Sat, Sep 05, 2020 at 08:13:02AM -0400, Mikulas Patocka wrote:
> > When running in a dax mode, if the user maps a page with MAP_PRIVATE and
> > PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime
> > whe
section, and these faults will incorrectly update the timestamp of the
objtool binary. The updated timestamp causes make to rebuild the whole
tree.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
fs/xfs/xfs_file.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions
section, and these faults will incorrectly update the timestamp of the
objtool binary. The updated timestamp causes make to rebuild the whole
tree.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
fs/ext2/file.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index
On Fri, 4 Sep 2020, Mikulas Patocka wrote:
> Hmm, so I've found another bug in dax mode.
>
> If you extract the Linux kernel tree on dax-based ext2 filesystem (use the
> real ext2 driver, not ext4), and then you run make twice, the second
> invocation will rebuild every
On Thu, 3 Sep 2020, Mikulas Patocka wrote:
> Hi
>
> There's a bug when you run strace from dax-based filesystem.
Hmm, so I've found another bug in dax mode.
If you extract the Linux kernel tree on dax-based ext2 filesystem (use the
real ext2 driver, not ext4), and then
On Thu, 3 Sep 2020, Linus Torvalds wrote:
> On Thu, Sep 3, 2020 at 12:24 PM Mikulas Patocka wrote:
> >
> > There's a bug when you run strace from dax-based filesystem.
> >
> > -- create real or emulated persistent memory device (/dev/pmem0)
> > mkfs.ext
Hi
There's a bug when you run strace from dax-based filesystem.
-- create real or emulated persistent memory device (/dev/pmem0)
mkfs.ext2 /dev/pmem0
-- mount it
mount -t ext2 -o dax /dev/pmem0 /mnt/test
-- copy the system to it (well, you can copy just a few files that are
needed for running
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
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
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:
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
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, 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-
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 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(),
> > &
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 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 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.
> > > + */
>
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 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
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.
>
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 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
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 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'
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
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
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
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
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
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
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:
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:
> > >
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
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
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
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
&
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 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 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
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 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
On Thu, 19 Sep 2019, Greg KH wrote:
> On Thu, Sep 19, 2019 at 05:18:15PM +0800, Xiaoming Ni wrote:
> > Using kzalloc() to allocate memory in function con_init(), but not
> > checking the return value, there is a risk of null pointer references
> > oops.
> >
> > Signed-off-by: Xiaoming Ni
>
>
On Wed, 4 Sep 2019, Huaisheng HS1 Ye wrote:
> > -Original Message-
> > From: Mikulas Patocka
> > Sent: Wednesday, September 4, 2019 4:49 PM
> > On Mon, 2 Sep 2019, Huaisheng Ye wrote:
> >
> > > From: Huaisheng Ye
> > >
> >
dm_table_find_target returns
NULL and its callers test the returned value for NULL. The macro
dm_target_is_valid is deleted. In alloc_targets, we no longer allocate an
extra zeroed target.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-ioctl.c |2 +-
drivers/md/dm-table.c |8
.
This patch fixes the bug by testing the sector number at the beginning of
dm_table_find_target. We add an "inline" keyword to the function
dm_table_get_size because this is hot path.
Signed-off-by: Mikulas Patocka
Reported-by: Zhang Tao
Fixes: 512875bd9661 ("dm: table detect i
Hi
I tested it and the bug is real - with some table sizes,
dm_table_find_target will access memory out of bounds if the sector
argument is beyond limit.
Your patch fixes some of these cases, but not all of them.
I used this script to test all possible table sizes:
#!/bin/bash -e
sync
dmsetup
On Thu, 31 Jan 2019, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> This patch set could be used for dm-writecache when use persistent
> memory as cache data device.
>
> Patch 1 and 2 go towards removing unused parameter and codes which
> actually doesn't really work.
I agree that there is so
On Thu, 2 Aug 2018, David Airlie wrote:
>
> I'm pretty sure udlkms handles this already.
>
> Dave.
But it crashes on unplug :-)
Mikulas
> On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka wrote:
>
>
> On Wed, 1 Aug 2018, Geert Uytterhoeven w
robot got the below dmesg and the first bad commit is
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > >
> > > commit d50d82faa0c964e31f7a946ba8aba7c715ca7ab0
> > > Author: Mikulas Patocka
> > > AuthorDate:
If you run aptitude on framebuffer console, the display is corrupted. The
corruption is caused by the commit d8ae7242. The patch adds "offset" to
"start" when calling scr_memsetw, but it forgets to do the same addition
on a subsequent call to do_update_region.
Signed-off
On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> On Wed, 2018-09-19 at 16:03 -0400, Mikulas Patocka wrote:
> >
> > On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> > > Thanks much for the testing, Mikulas.
> > > Could you try to bisect which of the patches causes
1 - 100 of 897 matches
Mail list logo
