mbox series

[v2,0/4] mptcp: token container refactor

Message ID cover.1590427813.git.pabeni@redhat.com
Headers show
Series mptcp: token container refactor | expand

Message

Paolo Abeni May 25, 2020, 5:35 p.m. UTC 
This series supersede the RTC patch for token refactor. The relevant patch
is unchanged, but this additional bring in some related minor cleanup
(patch 1/4) and KUNIT (!!!) self-tests (4/4). To make things cleaner it also
moves the existing in-kernel tests (crypto) to KUNIT.

The most relevant changes from v1 are in patch 2/4.

This addresses most of the issues raised by Christoph, Davide and Mat, with the
notable exception of shirinking the hash table bucket size - I'm unable to do
that with the current fixes for the list curruption noted by Christoph.

I hope the trade-off beween the self-contained fix and the avoided memory
optimization is acceptable.

Paolo Abeni (4):
  mptcp: add __init annotation on setup functions
  mptcp: refactor token container.
  mptcp: move crypto test to KUNIT
  mptcp: introduce token KUNIT self-tests

 net/mptcp/Kconfig       |  19 ++-
 net/mptcp/Makefile      |   4 +
 net/mptcp/crypto.c      |  65 +---------
 net/mptcp/crypto_test.c |  72 +++++++++++
 net/mptcp/pm.c          |   2 +-
 net/mptcp/pm_netlink.c  |   2 +-
 net/mptcp/protocol.c    |  39 +++---
 net/mptcp/protocol.h    |  15 ++-
 net/mptcp/subflow.c     |  12 +-
 net/mptcp/token.c       | 258 ++++++++++++++++++++++++++++------------
 net/mptcp/token_test.c  | 138 +++++++++++++++++++++
 11 files changed, 453 insertions(+), 173 deletions(-)
 create mode 100644 net/mptcp/crypto_test.c
 create mode 100644 net/mptcp/token_test.c

Comments

Mat Martineau May 27, 2020, 11:05 p.m. UTC | #1 
Hi Paolo,

On Mon, 25 May 2020, Paolo Abeni wrote:

> This series supersede the RTC patch for token refactor. The relevant patch
> is unchanged, but this additional bring in some related minor cleanup
> (patch 1/4) and KUNIT (!!!) self-tests (4/4). To make things cleaner it also
> moves the existing in-kernel tests (crypto) to KUNIT.
>
> The most relevant changes from v1 are in patch 2/4.
>
> This addresses most of the issues raised by Christoph, Davide and Mat, with the
> notable exception of shirinking the hash table bucket size - I'm unable to do
> that with the current fixes for the list curruption noted by Christoph.
>
> I hope the trade-off beween the self-contained fix and the avoided memory
> optimization is acceptable.
>
> Paolo Abeni (4):
>  mptcp: add __init annotation on setup functions
>  mptcp: refactor token container.
>  mptcp: move crypto test to KUNIT
>  mptcp: introduce token KUNIT self-tests
>

The series looks good to me. Is this something we should let bake in 
mptcp-next for a little bit or do you want to submit for net-next while 
it's still open?

I'm curious to see if there's any netdv pushback on the boot-time memory 
allocation.

--
Mat Martineau
Intel
Paolo Abeni May 28, 2020, 9:29 a.m. UTC | #2 
On Wed, 2020-05-27 at 16:05 -0700, Mat Martineau wrote:
> Hi Paolo,
> 
> On Mon, 25 May 2020, Paolo Abeni wrote:
> 
> > This series supersede the RTC patch for token refactor. The relevant patch
> > is unchanged, but this additional bring in some related minor cleanup
> > (patch 1/4) and KUNIT (!!!) self-tests (4/4). To make things cleaner it also
> > moves the existing in-kernel tests (crypto) to KUNIT.
> > 
> > The most relevant changes from v1 are in patch 2/4.
> > 
> > This addresses most of the issues raised by Christoph, Davide and Mat, with the
> > notable exception of shirinking the hash table bucket size - I'm unable to do
> > that with the current fixes for the list curruption noted by Christoph.
> > 
> > I hope the trade-off beween the self-contained fix and the avoided memory
> > optimization is acceptable.
> > 
> > Paolo Abeni (4):
> >  mptcp: add __init annotation on setup functions
> >  mptcp: refactor token container.
> >  mptcp: move crypto test to KUNIT
> >  mptcp: introduce token KUNIT self-tests
> > 
> 
> The series looks good to me. Is this something we should let bake in 
> mptcp-next for a little bit or do you want to submit for net-next while 
> it's still open?
> 
> I'm curious to see if there's any netdv pushback on the boot-time memory 
> allocation.

I hope should not be problematic, but only the submission could prove
it ;)

My idea would be staging this thing a bit in the export branch to let
syzkaller and internal usage find the most gross mistakes. I'm open to
other options ;)

Thanks!

Paolo