linux-kernel - Re: [PATCH v1 3/3] net: WireGuard secure network tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Aug 2018 02:35:40 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v1 3/3] net: WireGuard secure network tunnel

On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@...n.ch> wrote:
> I just gave this patch to checkpatch.pl...
On Tue, Jul 31, 2018 at 10:22 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
> Please break lines at something reasonable like 100 characters.

If the long lines really truly are dreadful, I have no problem fixing
that up for v2.

On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@...n.ch> wrote:
> > +static __always_inline void swap_endian(u8 *dst, const u8 *src, u8 bits)
> There is a general preference to not force the compile to
> inline. Leave it to decide.

I'm aware this is for the most part the case, and I've read the
variety of threads and documentation of folks explaining why this is a
good policy. In the particular instance of that function, inlining is
in fact always the right thing to do. But I'll give it a double check
to see if the compiler is already figuring that out on its own.

>
> > +#define push(stack, p, len) ({ \
> > +     if (rcu_access_pointer(p)) { \
> > +             BUG_ON(len >= 128); \
> > +             stack[len++] = rcu_dereference_protected(p, lockdep_is_held(lock)); \
> > +     } \
> > +     true; \
> > +})
>
> > +#undef push
> > +
>
> > +#define push(p) ({ BUG_ON(len >= 128); stack[len++] = p; })
>
> This is going to lead to bugs, coders thinking push() does one thing,
> when it actually does something else. I would suggest making these
> helper functions, with useful names.

Good suggestion. Fixed up already for v2.

On Wed, Aug 1, 2018 at 3:21 AM Shawn Landden <shawn@....icu> wrote:
> Does ratelimiter_selftest still always fail on slow CPUs?

No.

On Tue, Jul 31, 2018 at 10:27 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
> This looks like you are doing traversal to free a tree.  The stack is there so that you do the rcu callbacks
> in the proper order. Won't this create an lot of RCU work at once?

Nice observation; you're right. I've fixed this now so that it does
the traversal inside a single RCU callback, and have it queued up for
v2.

Thanks for the suggestions! Keep 'em coming, and I'll keep making modifications.

Thanks,
Jason