On 2016-11-10 04:07, Jason A. Donenfeld wrote:
> The padata API is a powerful framework for doing parallel jobs inside
> the kernel, on which various modules in the package feed can depend,
> such as WireGuard. There is no item text, so that it does not show up
> in menuconfig, as this is only supp
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 A
Hi Jason,
On Mon, Nov 14, 2016 at 11:28 AM, John Huttley wrote:
> RFE: when the module loads and prints its test at startup, please print its
> version and compile flags as well.
>
I second that! There is not (yet) a notion of VERSION in the code,
better not wait till 1.0 to put it :-)
One can
On 11/13/16 4:28 PM, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors the v4 logic
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors th
On Nov 14, 2016 17:19, "David Ahern" wrote:
>
> LGTM
>
> Acked-by: David Ahern
Great.
@DaveM: can we get this in 4.9 and in stable?
Thanks,
Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard
On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>> This puts the IPv6 routing functions in parity with the IPv4 routing
>> functions. Namely, we now check in v6 that if a flowi6 requests an
>> saddr, the returned dst actually corresponds
On 14.11.2016 17:55, David Ahern wrote:
> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>>
On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
> On 14.11.2016 17:55, David Ahern wrote:
>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
This puts the IPv6 routing functions in parity with the IPv4 routing
functions. Nam
On 14.11.2016 18:17, David Ahern wrote:
> On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
>> On 14.11.2016 17:55, David Ahern wrote:
>>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in pa
On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote:
> I just also quickly read up on the history (sorry was travelling last
> week) and wonder if you ever saw a user space facing bug or if this is
> basically some difference you saw while writing out of tree code?
I checked the
On Mon, Nov 14, 2016, at 18:48, David Ahern wrote:
> On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote:
> > I just also quickly read up on the history (sorry was travelling last
> > week) and wonder if you ever saw a user space facing bug or if this is
> > basically some difference you s
Hey Hannes, David,
On Mon, Nov 14, 2016 at 7:33 PM, Hannes Frederic Sowa
wrote:
> I meant to say, we don't require the IPv6 "API" to behave in a similar
> way like the IPv4 one. We do this function pointer trick to allow
> _in-kernel_ tree modules to use the function dynamically, even the
> kerne
13 matches
Mail list logo
