Re: RFC: wg syncpeers wg0 wireguard.conf

[Lonnie Abelbeck]

> On Jun 14, 2019, at 1:09 PM, Jason A. Donenfeld  wrote:
> 
> I'm leaning toward Steven's suggestion of nixing addconf and making
> setconf behave like syncconf.

But wouldn't the current 'setconf' (overwrite existing) always be faster than a 
combo 'setconf/syncconf' (sync with existing) ?

I have this nagging feeling that both 'setconf' and 'syncconf' should exist, if 
not for efficiencies but for unforeseen reasons related to the different 
functionalities: Start 'setconf' and Reload 'syncconf'.

Lonnie

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: RFC: wg syncpeers wg0 wireguard.conf

[Jason A. Donenfeld]

Hey Lonnie,

If your changes are user-facing, it's probably not a good idea to
create confusion by introducing distro-specific subcommands.

I'm leaning toward Steven's suggestion of nixing addconf and making
setconf behave like syncconf. But two hurdles remain:

- walk_remove_by_peer is very inefficient. That *must* be to be
improved for this to be feasible. There's some interesting algorithms
programming in allowedips.c to be tackled for that. Maybe
node->peer_list can be used. (CC'ing Ivan in case he wants to put his
mind to work on that.)
- A decision needs to be made on consistency: do we want to read back
the end result and compare it? Or will that kind of looping logic lead
to other types of DoS or latency spikes?

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: RFC: wg syncpeers wg0 wireguard.conf

[Marc Fawzi]

<<
I'm very much in favour of this (updating `setconf` to use this new
syncronisation approach), if anything it feels more logical and is how I
initially (wrongly) assumed `setconf` behaved when starting out with
WireGuard a while back.
>>

+1 ... it's better to keep the same command if its definition can be
expanded (fewer things to remember and less mental clutter)

p.s. does this overlap with similar planned in wg-dynamic?



On Tue, Jun 11, 2019 at 5:23 PM Steven Honson  wrote:

> On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote:
> > The other thing I was wondering is: aside from performance and races
> > as described above, why not just make this the functionality of
> > `setconf`? Then there's be no need to introduce a new subcommand. In
> > otherwords, the idea would be to make `setconf` not destroy existing
> > peers if we're going to be re-adding them again.
>
> I'm very much in favour of this (updating `setconf` to use this new
> syncronisation approach), if anything it feels more logical and is how I
> initially (wrongly) assumed `setconf` behaved when starting out with
> WireGuard a while back.
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: RFC: wg syncpeers wg0 wireguard.conf

[Jason A. Donenfeld]

On Fri, Jun 14, 2019 at 8:01 PM Marc Fawzi  wrote:
> p.s. does this overlap with similar planned in wg-dynamic?

No, the topics have no similarities.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard Bug?

[Jason A. Donenfeld]

Hey Ryan,

If you still have a reliable test rig for the bug, would you try
running with you kernel compiled with the attached patch?

Jason
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d8a2084b88db..3860c09d6ac1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1454,6 +1454,9 @@ bool queue_work_on(int cpu, struct workqueue_struct *wq,
 
 	local_irq_save(flags);
 
+	/* Pair with the smp_wmb() in set_work_pool_and_clear_pending. */
+	smp_rmb();
+
 	if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) {
 		__queue_work(cpu, wq, work);
 		ret = true;
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard