]> git.baikalelectronics.ru Git - kernel.git/commit
Revert "fs/pipe: use kvcalloc to allocate a pipe_buffer array"
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 20 Apr 2022 19:07:53 +0000 (12:07 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 20 Apr 2022 19:07:53 +0000 (12:07 -0700)
commitf9d2040ab9e3a06f820d4cc42dbdf247a1b2ac2b
tree22d5345c6b93c87085042d943208d37c541b6c38
parentaade0adff489bd8303059a9a566a56087848690f
Revert "fs/pipe: use kvcalloc to allocate a pipe_buffer array"

This reverts commit 85e1ff626f3e1e1b1e832857208c53e78b8fb30d.

It turns out that making the pipe almost arbitrarily large has some
rather unexpected downsides.  The kernel test robot reports a kernel
warning that is due to pipe->max_usage now growing to the point where
the iter_file_splice_write() buffer allocation can no longer be
satisfied as a slab allocation, and the

        int nbufs = pipe->max_usage;
        struct bio_vec *array = kcalloc(nbufs, sizeof(struct bio_vec),
                                        GFP_KERNEL);

code sequence there will now always fail as a result.

That code could be modified to use kvcalloc() too, but I feel very
uncomfortable making those kinds of changes for a very niche use case
that really should have other options than make these kinds of
fundamental changes to pipe behavior.

Maybe the CRIU process dumping should be multi-threaded, and use
multiple pipes and multiple cores, rather than try to use one larger
pipe to minimize splice() calls.

Reported-by: kernel test robot <oliver.sang@intel.com>
Link: https://lore.kernel.org/all/20220420073717.GD16310@xsang-OptiPlex-9020/
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/pipe.c