Hey Linus,
My email server has been firewalled from vger.kernel.org until today,
so I didn't see the original until this v2 was sent today. My
apologies. I'll review this first thing on Monday.
Jason
On Thu, Dec 10, 2020 at 9:56 AM Antonio Quartulli wrote:
>
> The definition of IS_ERR() already applies the unlikely() notation
> when checking the error status of the passed pointer. For this
> reason there is no need to have the same notation outside of
> IS_ERR() itself.
>
> Clean up code by re
Hmm, on first glance, I'm not sure I'm seeing the bug:
On Sun, Dec 20, 2020 at 5:54 PM syzbot
wrote:
> UBSAN: object-size-mismatch in ./include/linux/skbuff.h:2021:28
> member access within address 85889cc2 with insufficient space
> for an object of type 'struct sk_buff'
> __skb_queue_be
Hi Dmitry,
On Mon, Dec 21, 2020 at 10:14 AM Dmitry Vyukov wrote:
> Hi Jason,
>
> Thanks for looking into this.
>
> Reading clang docs for ubsan:
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
> -fsanitize=object-size: An attempt to potentially use bytes which the
> optimizer can
Hi Yang,
On Tue, Dec 1, 2020 at 10:31 AM Yang Yingliang wrote:
>
> After commit cf124db566e6 ("net: Fix inconsistent teardown and..."),
> priv_destruct() doesn't call free_netdev() in driver, we use
> dev->needs_free_netdev to indicate whether free_netdev() should be
> called on release path.
> T
of ll header,
>* exported to higher levels.
>*
> @@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> net_device *dev,
> if (!net_eq(dev_net(dev), sock_net(sk)))
> goto drop;
>
> - if (dev->header_ops) {
> + if (dev_has_header(dev)) {
> if (sk->sk_type != SOCK_DGRAM)
> skb_push(skb, skb->data - skb_mac_header(skb));
> else if (skb->pkt_type == PACKET_OUTGOING) {
Thanks for fixing this. Patch seems correct to me.
Acked-by: Jason A. Donenfeld
g churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
For the wireguard test harness change:
Acked-by: Jason A. Donenfeld
Note that this requires
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
And that commit should be backported to every kernel ever, since the
bug is so old.
On Tue, Nov 10, 2020 at 6:20 PM Greg KH wrote:
>
> On Tue, Nov 10, 2020 at 01:29:41PM +0100, Jason A. Donenfeld wrote:
> > Note that this requires
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
> >
Nack.
This API is meant to take simple integers, so that programmers can use
atomic64_t with it and have safe nonces. I'm also interested in
preserving the API's ability to safely encrypt more than 4 gigs of
data at once. Passing a buffer also encourages people to use
randomized nonces, which isn'
On Tue, Nov 17, 2020 at 9:32 AM Ard Biesheuvel wrote:
> If you are going back to the drawing board with in-kernel acceleration
> for OpenVPN
As far as I can tell, they're mostly after compatibility with their
existing userspace stuff. Otherwise, if they were going back to the
drawing board, they
we no longer need to track test_num in counter_test.c.
> But deleting the /*1*/ test_num comments means git (with the default
> threshold) no longer recognizes that the file was moved.
>
> Signed-off-by: Daniel Latypov
> Cc: Jason A. Donenfeld
> Cc: David Miller
> Cc:
e on it to help with that.
Thanks,
Jason
Jason A. Donenfeld (2):
wireguard: selftests: check that route_me_harder packets use the right
sk
netfilter: use actual socket sk rather than skb sk when routing harder
include/linux/netfilter_ipv4.h | 2 +-
include/linux/n
ant condition inside our test suite, since wireguard was where
the bug was discovered.
Reported-by: Chen Minqiang
Signed-off-by: Jason A. Donenfeld
---
tools/testing/selftests/wireguard/netns.sh | 8
tools/testing/selftests/wireguard/qemu/kernel.config | 2 ++
2 files changed,
e of __ip_queue_xmit().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jason A. Donenfeld
---
include/linux/netfilter_ipv4.h | 2 +-
include/linux/netfilter_ipv6.h | 10 +-
net/ipv4/netfilter.c | 8 +---
net/ipv4/netfilter/iptable_mangle
On Thu, Oct 29, 2020 at 1:01 PM Jason A. Donenfeld wrote:
>
> As a historical note, this code goes all the way back to Rusty in
> 2.3.14, where it looked like this:
Grrr, typo. 2.3.15.
As a historical note, this code goes all the way back to Rusty in
2.3.14, where it looked like this:
#ifdef CONFIG_NETFILTER
/* To preserve the cute illusion that a locally-generated packet can
be mangled before routing, we actually reroute if a hook altered
the packet. -RR */
static int route
On Fri, Oct 30, 2020 at 8:23 PM Pablo Neira Ayuso wrote:
>
> On Thu, Oct 29, 2020 at 03:56:04AM +0100, Jason A. Donenfeld wrote:
> > Hi Pablo,
> >
> > This series fixes a bug in the route_me_harder family of functions with
> > regards to tunnel interfaces. The first
struct net_device *dev)
> --
> 2.29.2
Looks fine to me.
Reviewed-by: Jason A. Donenfeld
Hi Catalin,
On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas wrote:
> Adding Jason and Ard. It may be a use-after-free in the wireguard
> driver.
Thanks for sending this my way. Note: to my knowledge, Ard doesn't
work on wireguard.
> > hlist_add_head include/linux/list.h:883 [inline]
> > enque
On Tue, Feb 16, 2021 at 6:46 PM Jason A. Donenfeld wrote:
>
> Hi Catalin,
>
> On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas
> wrote:
> > Adding Jason and Ard. It may be a use-after-free in the wireguard
> > driver.
>
> Thanks for sending this my way. Note: to
Hi Netdev & Willem,
I've received a report of stack corruption -- via the stack protector
check -- in icmp_send. I was sent a vmcore, and was able to extract
the OOPS from there. However, I've been unable to produce the bug and
I don't see where it'd be in the code. That might point to a more
sini
Hi Willem,
On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
wrote:
> A vmlinux image might help. I couldn't find one for this kernel.
https://data.zx2c4.com/icmp_send-crash-e03b4a42-706a-43bf-bc40-1f15966b3216.tar.xz
has .debs with vmlinuz in there, which you can extract to vmlinux, as
well as
On 2/18/21, Willem de Bruijn wrote:
> On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>>
>> Hi Willem,
>>
>> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
>> wrote:
>> > A vmlinux image might help. I couldn't find one for this kerne
:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 6 +-
include/net/icmp.h | 6 +-
net/ipv4/icmp.c| 2 ++
net/ipv6/ip6_icmp.c| 2
Hi Willem,
On Thu, Feb 18, 2021 at 3:57 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 7:31 AM Jason A. Donenfeld wrote:
> >
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, assuming
>
> Indeed that also casts skb->cb, to read IP6CB(sk
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 26 --
include/linux/ipv6.h | 1 -
include/net/icmp.h | 6 +-
net/ipv4/icmp.c|
On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
wrote:
> Thanks for respinning.
>
> Making ipv4 and ipv6 more aligned is a good goal, but more for
> net-next than bug fixes that need to be backported to many stable
> branches.
>
> Beyond that, I'm not sure this fixes additional cases vs the previ
On Thu, Feb 18, 2021 at 8:08 PM Jakub Kicinski wrote:
>
> On Thu, 18 Feb 2021 13:30:53 +0100 Jason A. Donenfeld wrote:
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, assuming
> > the skb to have come directly from the inet layer. But when the packet
&
On Thu, Feb 18, 2021 at 9:16 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld wrote:
> >
> > On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
> > wrote:
> > > Thanks for respinning.
> > >
> > > Making ipv4
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- Fix build errors with CONFIG_IPV6=m
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 26 --
include/linux/ipv6.h | 1 -
include/net
On Thu, Feb 18, 2021 at 9:37 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 3:25 PM Jason A. Donenfeld wrote:
> >
> > On Thu, Feb 18, 2021 at 9:16 PM Willem de Bruijn
> > wrote:
> > >
> > > On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld
&
On Thu, Feb 18, 2021 at 11:06 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 3:39 PM Jason A. Donenfeld wrote:
> >
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, casting
>
> Again, if respinning, please briefly describe the specific bugg
: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port
MTUs")
Reported-by: SinYu
Cc: Willem de Bruijn
Cc: David L Stevens
Cc: David S. Miller
Link:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by:
Jason
Antonio Quartulli (1):
wireguard: avoid double unlikely() notation when using IS_ERR()
Jann Horn (1):
wireguard: socket: remove bogus __be32 annotation
Jason A. Donenfeld (5):
wireguard: selftests: test multiple parallel streams
wireguard: peer: put frequently used members above cac
: Antonio Quartulli
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 2 +-
drivers/net/wireguard/socket.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireguard/
different endianness.
Since then, this assignment was already split up into separate statements;
just the cast survived.
Signed-off-by: Jann Horn
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/socket.c | 4 ++--
: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/peer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireguard/peer.h b/drivers/net/wireguard/peer.h
index 23af40922997..aaff8de6e34b 10
net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index cd51a2afa28e..8502e1b083ff 100644
-
uture planned work, this is a useful regression to avoid.
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
tools/testing/selftests/wireguard/netns.sh | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 12 ++---
drivers/net/wireguard/device.h | 15 +++---
drivers/net/wireguard/peer.c | 28 ---
drivers/net/wireguard/peer.h
The condition here was incorrect: a non-neon fallback implementation is
available on arm32 when NEON is not supported.
Reported-by: Ilya Lipnitskiy
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/Kconfig | 2 +-
1 file
: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port
MTUs")
Reported-by: SinYu
Reviewed-by: Willem de Bruijn
Link:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
Changes v4-
e
imperative to have these all converted. So this commit goes through the
remaining cases that I could find and does a boring translation to the
ndo variety.
Cc: Willem de Bruijn
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/ip_tunnel.c | 5 ++---
net/ipv4/ip_vti.c | 6 +++---
net/ip
On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 25, 2021 at 6:46 PM Jason A. Donenfeld wrote:
> >
> > There were a few remaining tunnel drivers that didn't receive the prior
> > conversion to icmp{,v6}_ndo_send. Knowing now that this could
On Sat, Feb 27, 2021 at 12:29 AM Willem de Bruijn
wrote:
>
> On Fri, Feb 26, 2021 at 5:39 PM Jason A. Donenfeld wrote:
> >
> > On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
> > wrote:
> > >
> > > On Thu, Feb 25, 2021 at 6:46 PM Jason A. Donenfeld
c: David Ahern
Cc: Jakub Kicinski
Cc: Steffen Klassert
Fixes: 803381f9f117 ("Merge branch
'icmp-account-for-NAT-when-sending-icmps-from-ndo-layer'")
Signed-off-by: Jason A. Donenfeld
---
v1->v2:
- Expanded Cc list and justification.
- No code changes.
net/ipv4/ip_
Hi Hangbin,
On Wed, Apr 7, 2021 at 5:39 AM Hangbin Liu wrote:
>
> As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> FIPS certified, the WireGuard module should be disabled in FIPS mode.
I'm not sure this makes so much sense to do _in wireguard_. If you
feel like the FI
On Thu, Apr 8, 2021 at 7:55 AM Simo Sorce wrote:
> > I'm not sure this makes so much sense to do _in wireguard_. If you
> > feel like the FIPS-allergic part is actually blake, 25519, chacha, and
> > poly1305, then wouldn't it make most sense to disable _those_ modules
> > instead? And then the var
Hi Hangbin,
On Thu, Apr 8, 2021 at 8:41 PM Hangbin Liu wrote:
> I agree that the best way is to disable the crypto modules in FIPS mode.
> But the code in lib/crypto looks not the same with crypto/. For modules
> in crypto, there is an alg_test() to check if the crytpo is FIPS allowed
> when do r
On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:
> On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:
> > Since it's just a normal module library, you can simply do this in the
> > module_init function, rather than deep within registration
> >
On Fri, Apr 9, 2021 at 2:08 AM Hangbin Liu wrote:
> After offline discussion with Herbert, here is
> what he said:
>
> """
> This is not a problem in RHEL8 because the Crypto API RNG replaces /dev/random
> in FIPS mode.
> """
So far as I can see, this isn't the case in the kernel sources I'm
read
On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce wrote:
> > depends on m || !CRYPTO_FIPS
> >
> > but I am a bit concerned that the rather intricate kconfig
> > dependencies between the generic and arch-optimized versions of those
> > drivers get complicated even further.
>
> Actually this is the opposi
Hey Linus,
Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive
notifications for:
On 3/17/21, Toke Høiland-Jørgensen wrote:
> Cong Wang writes:
>
>> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>>>
>>> I thought pfifo was supposed to be "lockless" and this change
>>> re-introduces a lock between producer and consumer, no?
>>
>> It has never been truly lockless, it us
On Thu, Mar 18, 2021 at 1:33 AM Yunsheng Lin wrote:
> > That offer definitely still stands. Generalization sounds like a lot of fun.
> >
> > Keep in mind though that it's an eventually consistent queue, not an
> > immediately consistent one, so that might not match all use cases. It
> > works with
://lore.kernel.org/wireguard/m5wzvk5--...@tuta.io/
Reported-by: Thomas Ptacek
Reported-by: Adhipati Blambangan
Cc: David Ahern
Cc: Toke Høiland-Jørgensen
Cc: Jakub Kicinski
Cc: Alexei Starovoitov
Signed-off-by: Jason A. Donenfeld
---
I had originally dropped this patch, but the issue kept c
On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski wrote:
> > I had originally dropped this patch, but the issue kept coming up in
> > user reports, so here's a v4 of it. Testing of it is still rather slim,
> > but hopefully that will change in the coming days.
>
> Here an alternative patch, untested
e user is primarily concerned
with transformations to layer 3 and beyond.
[1] https://lore.kernel.org/wireguard/m5wzvk5--...@tuta.io/
Reported-by: Thomas Ptacek
Reported-by: Adhipati Blambangan
Cc: David Ahern
Cc: Toke Høiland-Jørgensen
Cc: Jakub Kicinski
Cc: Alexei Starovoitov
Signed-of
On 8/14/20, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Fri, 14 Aug 2020 09:30:48 +0200
>
>> @@ -4676,6 +4688,7 @@ static u32 netif_receive_generic_xdp(struct sk_buff
>> *skb,
>> (orig_bcast != is_multicast_ether_addr_64bits(eth->h_
On 8/14/20, Jakub Kicinski wrote:
> On Fri, 14 Aug 2020 08:56:48 +0200 Jason A. Donenfeld wrote:
>> On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski wrote:
>> > > I had originally dropped this patch, but the issue kept coming up in
>> > > user reports, so here
eric XDP to handle if eth header was mangled")
Cc: Jesper Dangaard Brouer
Cc: David S. Miller
Signed-off-by: Jason A. Donenfeld
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7df6c9617321..151f1651439f 100644
--- a/net/core/de
Jesper Dangaard Brouer
Cc: John Fastabend
Cc: Daniel Borkmann
Cc: David S. Miller
Signed-off-by: Jason A. Donenfeld
---
I had originally dropped this patch, but the issue kept coming up in
user reports, so here's a v4 of it. Testing of it is still rather slim,
but hopefully that will chan
On Fri, Aug 14, 2020 at 11:27 PM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Fri, 14 Aug 2020 23:04:56 +0200
>
> > What? No. It comes up repeatedly because people want to reuse their
> > XDP processing logic with layer 3 devices.
>
> XDP i
On 8/17/20, Jesper Dangaard Brouer wrote:
> On Sun, 16 Aug 2020 15:29:37 -0700 (PDT)
> David Miller wrote:
>
>> From: "Jason A. Donenfeld"
>> Date: Sat, 15 Aug 2020 09:29:30 +0200
>>
>> > When an XDP program changes the ethernet header protocol fie
On Thu, Aug 20, 2020 at 1:22 AM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Sat, 15 Aug 2020 09:41:02 +0200
>
> > A user reported that packets from wireguard were possibly ignored by XDP
> > [1]. Another user reported that modifying packets from
On Wed, Aug 19, 2020 at 8:42 PM syzbot
wrote:
>
> syzbot has bisected this issue to:
>
> commit e7096c131e5161fa3b8e52a650d7719d2857adfd
> Author: Jason A. Donenfeld
> Date: Sun Dec 8 23:27:34 2019 +
>
> net: WireGuard secure network tunnel
&
On 8/20/20, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Thu, 20 Aug 2020 11:13:49 +0200
>
>> It seems like if an eBPF program pushes on a VLAN tag or changes the
>> protocol or does any other modification, it will be treated in exactly
>> the s
Hey Netdev,
A UDP skb comes in via the encap_rcv interface. I do a lot of wild
things to the bytes in the skb -- change where the head starts, modify
a few fragments, decrypt some stuff, trim off some things at the end,
etc. In other words, I'm decapsulating the skb in a pretty intense
way. I bene
Hi,
I'm back now and catching up with a lot of things. A few people have
mentioned to me that wg-quick(8), a bash script that makes a bunch of
iproute2 invocations, appears to be broken on 5.1. I've distilled the
behavior change down to the following.
Behavior on 5.0:
+ ip link add wg0 type dumm
On Fri, May 17, 2019 at 5:21 PM David Ahern wrote:
>
> On 5/17/19 8:17 AM, Michal Kubecek wrote:
> > AFAIK the purpose of 'ip route get' always was to let the user check
> > the result of a route lookup, i.e. "what route would be used if I sent
> > a packet to an address". To be honest I would hav
On Fri, May 17, 2019 at 7:39 PM David Ahern wrote:
> Not sure why Jason is not seeing that. Really odd that he hits the error
> AND does not get a message back since it requires an updated ip command
> to set the strict checking flag and that command understands extack.
> Perhaps no libmnl?
Right
On Fri, May 17, 2019 at 10:19 PM Jason A. Donenfeld wrote:
>
> On Fri, May 17, 2019 at 7:39 PM David Ahern wrote:
> > Not sure why Jason is not seeing that. Really odd that he hits the error
> > AND does not get a message back since it requires an updated ip command
>
Hi Dave,
That seems wise. Thanks for the advice. A more sophisticated way of
approaching this would be for the kernel to also send a bitmap of
which attributes are "critical" and only warn (or even error) of
_those_ are not understood. But that seems needlessly complex, and so
I think I'll go with
Dave - this very likely should be queued up for stable.
Jason
's no chance at all of hitting the dump() function
through any indirect paths.
In testing this with several different pieces of tricky code to trigger
these issues, this commit fixes all avenues that I'm aware of.
Signed-off-by: Jason A. Donenfeld
Cc: Johannes Berg
---
net/netlink/af
Hi Johannes,
Yes, indeed, and I think that's actually a good thing. It means that
the starts aren't ever called in parallel, which could be useful if
drivers have any ordering requirements. The change doesn't negatively
effect any existing drivers. I'll resubmit with a larger commit
message explai
ome out of this logic.
In testing this with several different pieces of tricky code to trigger
these issues, this commit fixes all avenues that I'm aware of.
Signed-off-by: Jason A. Donenfeld
Cc: Johannes Berg
---
net/netlink/af_netlink.c | 13 +++--
1 file changed, 7 insertions(
On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg wrote:
>
> Reviewed-by: Johannes Berg
Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.
Mobile phone right now, so not able to write patch, but you probably
should be using crypto_memneq for comparing those two keys, not
memcmp.
Jason
On Tue, Oct 17, 2017 at 7:46 AM, Johannes Berg
wrote:
> If it's not equal, you execute so much code
> beneath, going to the driver etc., that I'd think this particular time
> is in the noise.
Usually presumptions like this get you in trouble when some crafty
academic has a smart idea about that n
Otherwise we risk leaking information via timing side channel.
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld
---
net/mac80211/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/k
Hey Roopa,
On a kernel with a minimal networking config,
CONFIG_IP_MULTIPLE_TABLES appears to be broken for certain rules after
f9d4b0c1e9695e3de7af3768205bacc27312320c.
Try, for example, running:
$ ip -4 rule add table main suppress_prefixlength 0
It returns with EEXIST.
Perhaps the reason is
Two rules with different values of suppress_prefix or suppress_ifgroup
are not the same. This fixes an -EEXIST when running:
$ ip -4 rule add table main suppress_prefixlength 0
Signed-off-by: Jason A. Donenfeld
Fixes: f9d4b0c1e969 ("fib_rules: move common handling of newrule delrule
Two rules with different values of suppress_prefix or suppress_ifgroup
are not the same. This fixes an -EEXIST when running:
$ ip -4 rule add table main suppress_prefixlength 0
Signed-off-by: Jason A. Donenfeld
Fixes: f9d4b0c1e969 ("fib_rules: move common handling of newrule delrule
Thanks!
Jason
On Tue, Sep 19, 2017 at 10:40 PM, Cong Wang wrote:
> By "notification" I assume you mean netlink notification.
Yes, netlink notification.
> The question is why does the process in A still care about
> the device sitting in B?
>
> Also, the process should be able to receive a last notification
>
On Wed, Sep 20, 2017 at 8:29 PM, Cong Wang wrote:
> Sounds like we should set NETIF_F_NETNS_LOCAL for tun
> device.
Absolutely do not do this under any circumstances. This would be a
regression and would break API compatibility. As I wrote in my first
email, it's already possible to sleep-loop fo
noring it. This
patch thus returns early and does not call dumpit() when start() fails.
Signed-off-by: Jason A. Donenfeld
Cc: sta...@vger.kernel.org
---
net/netlink/af_netlink.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/n
On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld wrote:
> - if (cb->start)
> - cb->start(cb);
> + if (cb->start) {
> + ret = cb->start(cb);
> + if (ret)
I need to sock_put(sk); before returning. I'
On Wed, Sep 27, 2017 at 3:05 PM, Johannes Berg
wrote:
> I guess you could change it to
>
> if (cb->start)
> ret = cb->start(cb);
> if (!ret)
> ret = netlink_dump(sk);
Very clean. I'll do it like that. I'll wait a bit longer before
submitting v2, but beyond that, seems sane to you?
noring it. This
patch thus returns early and does not call dumpit() when start() fails.
Signed-off-by: Jason A. Donenfeld
Cc: Johannes Berg
---
net/netlink/af_netlink.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
On Thu, Sep 28, 2017 at 12:41:44AM +0200, Jason A. Donenfeld wrote:
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 327807731b44..94c11cf0459d 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2270,10 +2270,13 @@ int __net
Hi guys,
One handy aspect of Netlink is that it's backwards compatible. This
means that you can run old userspace utilities on new kernels, even if
the new kernel supports new features and netlink attributes. The wire
format is stable enough that the data marshaled can be extended
without breaking
On Mon, Oct 2, 2017 at 11:32 AM, Nicolas Dichtel
wrote:
> 1. Move the process to netns B, open the netlink socket and move back the
> process to netns A. The socket will remain in netns B and you will receive all
> netlink messages related to netns B.
>
> 2. Assign a nsid to netns B in netns A and
Hey Michael,
Thanks for your work on ptr_ring.h. I'm interested in using it, but in
a multi-producer, multi-consumer context. I realize it's been designed
for a single-producer, single-consumer context, and thus uses a
spinlock. I'm wondering if you'd be happy to receive patches that
implement thi
On Tue, Jul 31, 2018 at 1:22 PM Stephen Hemminger
wrote:
>
> On Tue, 31 Jul 2018 21:11:02 +0200
> "Jason A. Donenfeld" wrote:
>
> > +static int walk_by_peer(struct allowedips_node __rcu *top, u8 bits, struct
> > allowedips_cursor *cursor, struct wireguard_peer
On Tue, Aug 21, 2018 at 4:54 PM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Tue, 21 Aug 2018 16:41:50 -0700
>
> > Is 100 in fact acceptable for new code? 120? 180? What's the
> > generally accepted limit these days?
>
> Please keep it
Hi Eric,
On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
> I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if
> you've actually read through the asm from the OpenSSL implementations, but the
> generated .S files actually do lose a lot of semantic information that wa
Hey Martin,
Thanks for running these and pointing this out. I've replicated the
results with tcrypt and fixed some issues, and the next patch series
should be a lot closer to what you'd expect, instead of the regression
you noticed. Most of the slowdown happened as a result of over-eager
XSAVEs, w
1 - 100 of 521 matches
Mail list logo
