diff options
| author | Linus Torvalds <[email protected]> | 2022-04-20 19:07:53 +0000 |
|---|---|---|
| committer | Linus Torvalds <[email protected]> | 2022-04-20 19:07:53 +0000 |
| commit | 906f904097359d059623ca8d3511d9f341080f2c (patch) | |
| tree | 22d5345c6b93c87085042d943208d37c541b6c38 /tools/perf/util/c++/clang.cpp | |
| parent | x86: __memcpy_flushcache: fix wrong alignment if size > 2^32 (diff) | |
| download | kernel-906f904097359d059623ca8d3511d9f341080f2c.tar.gz kernel-906f904097359d059623ca8d3511d9f341080f2c.zip | |
Revert "fs/pipe: use kvcalloc to allocate a pipe_buffer array"
This reverts commit 5a519c8fe4d620912385f94372fc8472fa98c662.
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 <[email protected]>
Link: https://lore.kernel.org/all/20220420073717.GD16310@xsang-OptiPlex-9020/
Cc: Andrei Vagin <[email protected]>
Cc: Dmitry Safonov <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/util/c++/clang.cpp')
0 files changed, 0 insertions, 0 deletions
