From: Andrew Morton <akpm@linux-foundation.org> Date: 2021-12-02 04:29:17
On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui [off-list ref] wrote:
在 2021/12/2 上午11:26, Andrew Morton 写道:
quoted
quoted
Delete the WARN_ON() and return NULL directly for oversized parameter
in kvmalloc() calls.
Also add unlikely().
Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
Signed-off-by: Bixuan Cui<redacted>
---
There are a lot of oversize warnings and patches about kvmalloc() calls
recently. Maybe these warnings are not very necessary.
Or maybe they are. Please let's take a look at these warnings, one at
a time. If a large number of them are bogus then sure, let's disable
the runtime test. But perhaps it's the case that calling code has
genuine issues and should be repaired.
Such as：
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!
From: Jeremy Sowden <hidden> Date: 2021-12-02 11:14:48
On 2021-12-01, at 20:29:05 -0800, Andrew Morton wrote:
On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui wrote:
quoted
在 2021/12/2 上午11:26, Andrew Morton 写道:
quoted
quoted
Delete the WARN_ON() and return NULL directly for oversized
parameter in kvmalloc() calls.
Also add unlikely().
Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
Signed-off-by: Bixuan Cui<redacted>
---
There are a lot of oversize warnings and patches about kvmalloc()
calls recently. Maybe these warnings are not very necessary.
Or maybe they are. Please let's take a look at these warnings,
one at a time. If a large number of them are bogus then sure,
let's disable the runtime test. But perhaps it's the case that
calling code has genuine issues and should be repaired.
Such as：
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!
From: Bixuan Cui <hidden> Date: 2021-12-02 11:50:20
在 2021/12/2 下午12:29, Andrew Morton 写道:
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!
On Thu, Dec 2, 2021 at 2:38 AM Jeremy Sowden [off-list ref] wrote:
On 2021-12-01, at 20:29:05 -0800, Andrew Morton wrote:
quoted
On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui wrote:
quoted
在 2021/12/2 上午11:26, Andrew Morton 写道:
quoted
quoted
Delete the WARN_ON() and return NULL directly for oversized
parameter in kvmalloc() calls.
Also add unlikely().
Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
Signed-off-by: Bixuan Cui<redacted>
---
There are a lot of oversize warnings and patches about kvmalloc()
calls recently. Maybe these warnings are not very necessary.
Or maybe they are. Please let's take a look at these warnings,
one at a time. If a large number of them are bogus then sure,
let's disable the runtime test. But perhaps it's the case that
calling code has genuine issues and should be repaired.
Such as：
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!
From: Jeremy Sowden <hidden> Date: 2021-12-02 21:17:04
On 2021-12-02, at 07:34:36 -0800, Alexei Starovoitov wrote:
On Thu, Dec 2, 2021 at 2:38 AM Jeremy Sowden wrote:
quoted
On 2021-12-01, at 20:29:05 -0800, Andrew Morton wrote:
quoted
On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui wrote:
quoted
在 2021/12/2 上午11:26, Andrew Morton 写道:
quoted
quoted
Delete the WARN_ON() and return NULL directly for oversized
parameter in kvmalloc() calls.
Also add unlikely().
Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
Signed-off-by: Bixuan Cui<redacted>
---
There are a lot of oversize warnings and patches about kvmalloc()
calls recently. Maybe these warnings are not very necessary.
Or maybe they are. Please let's take a look at these warnings,
one at a time. If a large number of them are bogus then sure,
let's disable the runtime test. But perhaps it's the case that
calling code has genuine issues and should be repaired.
Such as：
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!
How is this a "fix" ?
u32 was the limit and because of the new warn the limit
got reduced to s32.
Every subsystem is supposed to do this "fix" now?
My intention was only to provide information about what had been done in
the ipset case. In that case, there was already a check in place to
ensure that the requested hash-table size would not result in integer
overflow, and it was adjusted to reflect the limit imposed by the new
warning (one imagines that there is not much demand for hash-tables that
big).
I'm not familiar with the other cases, and so I would not presume to
make suggestions about whether those warnings were useful.
J.
From: Sean Christopherson <seanjc@google.com> Date: 2021-12-03 19:37:39
+Paolo, I'm pretty sure he's still not subscribed to the KVM mailing list :-)
On Wed, Dec 01, 2021, Andrew Morton wrote:
On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui [off-list ref] wrote:
quoted
在 2021/12/2 上午11:26, Andrew Morton 写道:
quoted
quoted
Delete the WARN_ON() and return NULL directly for oversized parameter
in kvmalloc() calls.
Also add unlikely().
Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
Signed-off-by: Bixuan Cui<redacted>
---
There are a lot of oversize warnings and patches about kvmalloc() calls
recently. Maybe these warnings are not very necessary.
Or maybe they are. Please let's take a look at these warnings, one at
a time. If a large number of them are bogus then sure, let's disable
the runtime test. But perhaps it's the case that calling code has
genuine issues and should be repaired.
Such as：
Thanks, that's helpful.
Let's bring all these to the attention of the relevant developers.
If the consensus is "the code's fine, the warning is bogus" then let's
consider retiring the warning.
If the consensus is otherwise then hopefully they will fix their stuff!