netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).