[LEDE-DEV] [PATCH] wireguard: bump to 20180304

data from the kernel's memory. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- package/network/services/wireguard/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/services/wireguard/Makefile b/package/network/services/wireguard/Makefile

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

Hi Stijn, That was quick. Thanks! Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > In that case, I'll take a closer look at the patches LEDE ships for > the package and merging them into the upstream repo. If you don't wind up removing that, future packages won't need to include that patc

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

On Sun, Oct 8, 2017 at 3:02 PM, Florian Fainelli wrote: > Still using ipset-dns here, thanks for the reminder, I should probably > migrate to dnsmasq now to achieve the same goals. There may be other > users out there though ;) Cool, okay, good to know! In that case, I'll

[LEDE-DEV] ipset-dns - does anybody actually use this?

Hey, I'm upstream on the ipset-dns project: https://git.zx2c4.com/ipset-dns/about/ It's a part of a core LEDE repo: https://git.lede-project.org/?p=source.git;a=tree;f=package/network/services/ipset-dns Pretty soon after I wrote ipset-dns, I thought it was kind of a hassle, and so I rewrote the

Re: [LEDE-DEV] per-cpu IRQ stack on MIPS

Here's the raw diff of this series directly from -next, in case it helps: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/rawdiff/?id=3cc3434fd6307d06b53b98ce83e76bf9807689b9=fe8bd18ffea5327344d4ec2bf11f47951212abd0~ ___ Lede-dev

Re: [LEDE-DEV] per-cpu IRQ stack on MIPS

On Sun, Jan 15, 2017 at 3:03 PM, Felix Fietkau wrote: > I'd like to run a few more tests today before I merge it, just to make > sure it doesn't break stuff for the release. Of course. Let me know if you run into any difficulties. ___

Re: [LEDE-DEV] per-cpu IRQ stack on MIPS

Hey Felix, On Wed, Jan 11, 2017 at 10:59 AM, Felix Fietkau wrote: >> It prevents crashes when lots of different networking drivers are >> stacked on top of eachother, like gre+l2tp+somethingelse. > I've pushed the backport of these changes to my staging tree at >

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

Actually, > I think the problem with wireguard in github issue 3790 [1] is that > wireguard requires NFPROTO_{IPV4,IPV6} "hashlimit" module and > netfilter subsystem will try to load ipt_hashlimit and ip6t_hashlimit > which are aliases of xt_hashlimit, but we have aliases along with > other

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

Hey all, It's not possible to depend directly on xt_hashlimit, because we don't use any symbols in it. Instead, Netfilter forces us to go through helper function, which load xt_hashtable dynamically. This works fine on most systems, where the kernel calls out to modprobe at runtime in order to

[LEDE-DEV] per-cpu IRQ stack on MIPS

Hey folks, You might considering backporting this patchset to the LEDE/OpenWRT kernel: http://www.spinics.net/lists/mips/msg65937.html It prevents crashes when lots of different networking drivers are stacked on top of eachother, like gre+l2tp+somethingelse. Jason

Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt

On Wed, Nov 16, 2016 at 8:35 PM, Felix Fietkau wrote: > It's in my staging tree and will make it to the main repo soon. Good to hear. Thanks. ___ Lede-dev mailing list Lede-dev@lists.infradead.org

Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt

Hi Felix, Patchwork was changed to "accepted" -- http://patchwork.ozlabs.org/patch/694517/ -- but this hasn't shown up in the actual LEDE repo. What's up? Jason ___ Lede-dev mailing list Lede-dev@lists.infradead.org

[LEDE-DEV] [PATCH] kernel: enable pcrypt

This is a powerful API for parallel crypto from which many other modules can benefit. It only winds up being turned on on SMP systems, which means this adds 0 bytes to the kernel on tiny machines, while only adding a small bit to SMP systems for big performance improvements. Signed-off-by: Jason

Re: [LEDE-DEV] [PATCH] kernel: expose configuration for padata

On Fri, Nov 11, 2016 at 5:06 PM, Baptiste Jonglez wrote: > Looks good to me, I didn't see an increase in kernel size when selecting > this option on ar71xx (I looked at the size of > "build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/linux-4.4.30/vmlinuz")

[LEDE-DEV] [PATCH] kernel: expose configuration for padata

. There as already precedent for this behavior, with CONFIG_KERNEL_RELAY, on which several packages depend. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- config/Config-kernel.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index d

[LEDE-DEV] [PATCH] wireguard: select parallel encryption engine

On non SMP systems, this doesn't wind up doing anything or adding any code at all. On SMP systems, this adds a little bit of code, and makes encryption use all cores. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/wireguard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 de