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

[Jason A. Donenfeld]

On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@xxxxxxx> wrote:
> I just gave this patch to checkpatch.pl...
On Tue, Jul 31, 2018 at 10:22 PM Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxx> wrote:
> Does ratelimiter_selftest still always fail on slow CPUs?

No.

On Tue, Jul 31, 2018 at 10:27 PM Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> 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