[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181024200946.GB25475@1wt.eu>
Date: Wed, 24 Oct 2018 22:09:46 +0200
From: Willy Tarreau <w@....eu>
To: Eric Dumazet <edumazet@...gle.com>
Cc: joe@...ches.com, wanghaifine@...il.com,
David Miller <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Change judgment len position
On Wed, Oct 24, 2018 at 10:03:08AM -0700, Eric Dumazet wrote:
> On Wed, Oct 24, 2018 at 9:54 AM Joe Perches <joe@...ches.com> wrote:
>
> > I think if the point is to test for negative numbers,
> > it's clearer to do that before using min_t.and it's
> > probably clearer not to use min_t at all.
> >
>
> ...
>
> >
> > if (len > sizeof(int))
> > len = sizeof(int);
>
> It is a matter of taste really, I know some people (like me) sometimes
> mixes min() and max()
I do mix them up a lot as well because I tend to read "x=min(y,4)" as
"take y with a minimum value of 4" which in fact would be "max(y,4)".
> I would suggest that if someones wants to change the current code, a
> corresponding test
> would be added in tools/testing/selftests/net
In any case, what matters to me is that for now the only risk the existing
code represents is to overwrite up to one int of some userspace if the size
is negative, and we don't want that a wrong fix results in doing something
worse by accident like reading 2GB of kernel memory. I agree that Joe's
test with len<0 then len>sizeof(int) seems to work, but a test is probably
useful at least to ensure that the next person who passes there and wants
to turn this into min_t() again clearly catches all bad cases.
Regards,
Willy
Powered by blists - more mailing lists