From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Dmitry Safonov <dima@arista.com>,
linux-kernel@vger.kernel.org
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
David Ahern <dsahern@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Ido Schimmel <idosch@mellanox.com>,
netdev@vger.kernel.org
Subject: Re: [RFC 1/4] net/ipv4/fib: Remove run-time check in tnode_alloc()
Date: Mon, 1 Apr 2019 16:55:02 +0100 [thread overview]
Message-ID: <c82b92e9-9809-87d2-85dc-67044d4e7632@gmail.com> (raw)
In-Reply-To: <5beb631cf0dcc03d5afad3a29671677bdbc7b931.camel@linux.intel.com>
Hi Alexander,
On 4/1/19 4:40 PM, Alexander Duyck wrote:
>> @@ -333,8 +328,7 @@ static struct tnode *tnode_alloc(int bits)
>> {
>> size_t size;
>>
>> - /* verify bits is within bounds */
>> - if (bits > TNODE_VMALLOC_MAX)
>> + if ((BITS_PER_LONG <= KEYLENGTH) && unlikely(bits >= BITS_PER_LONG))
>> return NULL;
>>
>> /* determine size and verify it is non-zero and didn't overflow */
>
> I think it would be better if we left TNODE_VMALLOC_MAX instead of
> replacing it with BITS_PER_LONG. This way we know that we are limited
> by the size of the node on 32b systems, and by the KEYLENGTH on 64b
> systems. The basic idea is to maintain the logic as to why we are doing
> it this way instead of just burying things by using built in constants
> that are close enough to work.
>
> So for example I believe TNODE_VMALLOC_MAX is 31 on a 32b system.
This is also true after the change: bits == 31 will *not* return.
> The
> main reason for that is because we have to subtract the TNODE_SIZE from
> the upper limit for size. By replacing TNODE_VMALLOC_MAX with
> BITS_PER_LONG that becomes abstracted away and it becomes more likely
> that somebody will mishandle it later.
So, I wanted to remove run-time check here on x86_64..
I could do it by adding !CONFIG_64BIT around the check.
But, I thought about the value of the check:
I believe it's here not to limit maximum allocated size:
kzalloc()/vzalloc() will fail and we should be fine with that.
In my opinion it's rather to check that (1UL << bits) wouldn't result in UB.
Thanks,
Dmitry
next prev parent reply other threads:[~2019-04-01 15:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 15:30 [RFC 0/4] net/fib: Speed up trie rebalancing for full view Dmitry Safonov
2019-03-26 15:30 ` [RFC 1/4] net/ipv4/fib: Remove run-time check in tnode_alloc() Dmitry Safonov
2019-04-01 15:40 ` Alexander Duyck
2019-04-01 15:55 ` Dmitry Safonov [this message]
2019-04-01 17:50 ` Alexander Duyck
2019-04-04 16:33 ` Dmitry Safonov
2019-03-26 15:30 ` [RFC 2/4] net/fib: Provide fib_balance_budget sysctl Dmitry Safonov
2019-04-01 18:09 ` Alexander Duyck
2019-04-04 18:31 ` Dmitry Safonov
2019-03-26 15:30 ` [RFC 3/4] net/fib: Check budget before should_{inflate,halve}() Dmitry Safonov
2019-04-01 18:20 ` Alexander Duyck
2019-03-26 15:30 ` [RFC 4/4] net/ipv4/fib: Don't synchronise_rcu() every 512Kb Dmitry Safonov
2019-03-26 15:39 ` David Ahern
2019-03-26 17:15 ` Dmitry Safonov
2019-03-26 17:57 ` David Ahern
2019-03-26 18:17 ` Dmitry Safonov
2019-03-26 23:14 ` Dmitry Safonov
2019-03-27 3:33 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c82b92e9-9809-87d2-85dc-67044d4e7632@gmail.com \
--to=0x7f454c46@gmail.com \
--cc=alexander.h.duyck@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dima@arista.com \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=idosch@mellanox.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.