Messages in this thread |  | | From | "Jason A. Donenfeld" <> | Date | Fri, 3 Aug 2018 02:35:40 +0200 | Subject | Re: [PATCH v1 3/3] net: WireGuard secure network tunnel |
| |
On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@lunn.ch> wrote: > I just gave this patch to checkpatch.pl... On Tue, Jul 31, 2018 at 10:22 PM Stephen Hemminger <stephen@networkplumber.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@lunn.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@git.icu> wrote: > Does ratelimiter_selftest still always fail on slow CPUs?
No.
On Tue, Jul 31, 2018 at 10:27 PM Stephen Hemminger <stephen@networkplumber.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
|  |