Re: [PATCH -next] mm: delete oversized WARN_ON() in kvmalloc() calls
flat view
From: Jeremy Sowden <hidden>
Date: 2021-12-02 21:17:04
Also in:
bpf, kvm, linux-mm, lkml, netfilter-devel
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!(cc bpf@vger.kernel.org)(cc netdev@vger.kernel.org, maintainers)(cc kvm@vger.kernel.org)(cc netfilter-devel@vger.kernel.org)The netfilter bug has since been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=7bbc3d385bd813077acaf0e6fdb2a86a901f5382How 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.
Attachments
- signature.asc [application/pgp-signature] 833 bytes