It's generally dangerous to allocate such large quantities of memory
within the kernel owing to our propensity to use 'int' to represent
a length. If somebody really needs it, we can add a kvmalloc_large()
later, but let's default to "You can't allocate that much memory".
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
---
fs/seq_file.c | 3 ---
mm/util.c | 7 +++++++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 4a2cda04d3e2..b117b212ef28 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -32,9 +32,6 @@ static void seq_set_overflow(struct seq_file *m)
static void *seq_buf_alloc(unsigned long size)
{
- if (unlikely(size > MAX_RW_COUNT))
- return NULL;
-
return kvmalloc(size, GFP_KERNEL_ACCOUNT);
}
diff --git a/mm/util.c b/mm/util.c
index 9043d03750a7..8ff2a8924d5f 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -593,6 +593,13 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
if (ret || size <= PAGE_SIZE)
return ret;
+ /*
+ * Succeeding for sizes above 2GiB can lead to truncation if
+ * someone casts the size to an int.
+ */
+ if (size > INT_MAX)
+ return NULL;
+
return __vmalloc_node(size, 1, flags, node,
__builtin_return_address(0));
}
--
2.30.2
On Wed, Jul 21, 2021 at 07:41:31PM +0100, Matthew Wilcox (Oracle) wrote:
> It's generally dangerous to allocate such large quantities of memory
> within the kernel owing to our propensity to use 'int' to represent
> a length. If somebody really needs it, we can add a kvmalloc_large()
> later, but let's default to "You can't allocate that much memory".
If we really need it, maybe we can add a GFP_LARGE_ALLOC to allow
allocations larger than 2GB later on? I can't quite see why that
would ever be needed, but that's probably a failure of my imagination. :-)
- Ted
On Wed 21-07-21 19:41:31, Matthew Wilcox wrote:
> It's generally dangerous to allocate such large quantities of memory
> within the kernel owing to our propensity to use 'int' to represent
> a length. If somebody really needs it, we can add a kvmalloc_large()
> later, but let's default to "You can't allocate that much memory".
I do agree that limiting kvmalloc allocation size is a reasonable thing
to do but I do not really see why we should remove the check from
seq_buf_alloc. Implicitly relying on kvmalloc to workaround a bug that
was in seq_buf code seems like a step backwards to me.
--
Michal Hocko
SUSE Labs