[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46d2a694-6a85-0f8e-4156-9bb1c4dbdb69@redhat.com>
Date: Tue, 8 Jun 2021 18:37:38 -0400
From: Jon Maloy <jmaloy@...hat.com>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: ying.xue@...driver.com, David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
tipc-discussion@...ts.sourceforge.net,
Menglong Dong <dong.menglong@....com.cn>,
Zeal Robot <zealci@....com.cn>
Subject: Re: [PATCH net-next] net: tipc: fix FB_MTU eat two pages
On 6/7/21 8:51 AM, Menglong Dong wrote:
> On Sat, Jun 05, 2021 at 10:25:53AM -0400, Jon Maloy wrote:
>>
>> On 6/4/21 9:28 PM, Menglong Dong wrote:
>>> Hello Maloy,
>>>
>>> On Sat, Jun 5, 2021 at 3:20 AM Jon Maloy <jmaloy@...hat.com> wrote:
>>>> [...]
>>>
>>> So if I use the non-crypto version, the size allocated will be:
>>>
>>> PAGE_SIZE - BUF_HEADROOM_non-crypto - BUF_TAILROOM_non-crypt +
>>> BUF_HEADROOM_crypto + BUF_TAILROOM_crypto
>>>
>>> which is larger than PAGE_SIZE.
>>>
>>> So, I think the simple way is to define FB_MTU in 'crypto.h'. Is this
>>> acceptable?
>>>
>>> Thanks!
>>> Menglong Dong
>>>
I spent a little more time looking into this. I think the best we can do
is to keep FB_MTU internal to msg.c, and then add an outline function to
msg.c that can be used by bcast.c. The way it is used is never time
critical.
I also see that we could need a little cleanup around this. There is a
redundant align() function that should be removed and replaced with the
global ALIGN() macro.
Even tipc_buf_acquire() should use this macro instead of the explicit
method that is used now.
In general, I stongly dislike conditional code, and it is not necessary
in this function. If we redefine the non-crypto BUF_TAILROOM to 0
instead of 16 (it is not used anywhere else) we could get rid of this too.
But I leave that to you. If you only fix the FB_MTU macro I am content.
///jon
Powered by blists - more mailing lists