On 2021-12-02, at 07:34:36 -0800, Alexei Starovoitov wrote:
> On Thu, Dec 2, 2021 at 2:38 AM Jeremy Sowden wrote:
> > On 2021-12-01, at 20:29:05 -0800, Andrew Morton wrote:
> > > On Thu, 2 Dec 2021 12:05:15 +0800 Bixuan Cui wrote:
> > > > 在 2021/12/2 上午11:26, Andrew Morton 写道:
> > > > >> 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<cuibixuan@xxxxxxxxxxxxxxxxx>
> > > > >> ---
> > > > >> 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!
> > >
> > > > https://syzkaller.appspot.com/bug?id=24452f89446639c901ac07379ccc702808471e8e
> > >
> > > (cc bpf@xxxxxxxxxxxxxxx)
> > >
> > > > https://syzkaller.appspot.com/bug?id=f7c5a86e747f9b7ce333e7295875cd4ede2c7a0d
> > >
> > > (cc netdev@xxxxxxxxxxxxxxx, maintainers)
> > >
> > > > https://syzkaller.appspot.com/bug?id=8f306f3db150657a1f6bbe1927467084531602c7
> > >
> > > (cc kvm@xxxxxxxxxxxxxxx)
> > >
> > > > https://syzkaller.appspot.com/bug?id=6f30adb592d476978777a1125d1f680edfc23e00
> > >
> > > (cc netfilter-devel@xxxxxxxxxxxxxxx)
> >
> > The netfilter bug has since been fixed:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=7bbc3d385bd813077acaf0e6fdb2a86a901f5382
>
> 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.
Attachment:
signature.asc
Description: PGP signature
