On 2021-03-15 15:51, Alex Elder wrote:
Version 6 is the same as version 5, but has been rebased on updated
net-next/master. With any luck, the patches I'm sending out this
time won't contain garbage.
Version 5 of this series responds to a suggestion made by Alexander
Duyck, to determine the off
sysctl's are not free and in this case you want to add a second one to
pick and choose which data in the message you want the kernel to act
on.
Why can't the userspace daemon remove the route and add the one it
prefers? Or add another route with a metric that makes it the preferred
route making
On 2021-03-10 14:33, subas...@codeaurora.org wrote:
On 2021-03-10 12:28, David Ahern wrote:
On 3/10/21 11:49 AM, Subash Abhinov Kasiviswanathan wrote:
Added new procfs flag to toggle the automatic addition of prefix
routes on a per device basis. The new flag is accept_ra_prefix_route.
A value
On 2021-03-10 12:28, David Ahern wrote:
On 3/10/21 11:49 AM, Subash Abhinov Kasiviswanathan wrote:
Added new procfs flag to toggle the automatic addition of prefix
routes on a per device basis. The new flag is accept_ra_prefix_route.
A value of 0 for the flag maybe used in some forwarding scena
On 2021-03-04 15:34, Alex Elder wrote:
This series converts data structures defined in
so they use integral field values with bitfield masks rather than
rely on C bit-fields.
I first proposed doing something like this long ago when my confusion
about this code (and the memory layout it was supp
On 2021-02-22 09:55, Sharath Chandra Vurukala wrote:
This series introduces the MAPv5 packet format.
Patch 0 documents the MAPv5.
Patch 1 introduces the Mapv5 and the Inline checksum offload for RX.
Patch 2 introduces the Mapv5 and the Inline checksum offload for TX.
A new checksum header forma
On 2021-02-12 12:06, Alex Elder wrote:
On 2/12/21 12:51 PM, Jakub Kicinski wrote:
On Fri, 12 Feb 2021 08:01:15 -0600 Alex Elder wrote:
On 2/11/21 8:04 PM, Jakub Kicinski wrote:
On Fri, 12 Feb 2021 03:05:23 +0530 Sharath Chandra Vurukala wrote:
+/* MAP CSUM headers */
+struct rmnet_map_v5_csum
On 2021-02-12 07:01, Alex Elder wrote:
On 2/11/21 8:04 PM, Jakub Kicinski wrote:
On Fri, 12 Feb 2021 03:05:23 +0530 Sharath Chandra Vurukala wrote:
+/* MAP CSUM headers */
+struct rmnet_map_v5_csum_header {
+ u8 next_hdr:1;
+ u8 header_type:7;
+ u8 hw_reserved:5;
+ u8
On 2021-02-02 09:16, Loic Poulain wrote:
There is no guarantee that rmnet rx_handler is only fed with linear
skbs, but current rmnet implementation does not check that, leading
to crash in case of non linear skbs processed as linear ones.
Fix that by ensuring skb linearization before processing.
What about just returning an error on NETDEV_PRECHANGEMTU notification
to prevent real device MTU change while virtual rmnet devices are
linked? Not sure there is a more proper and thread safe way to manager
that otherwise.
Can't you copy what vlan devices do? That'd seem like a reasonable and
On 2020-12-03 10:40, Loic Poulain wrote:
A submitted qmap/rmnet packet size can not be larger than the linked
interface (real_dev) MTU. This patch ensures that the rmnet virtual
iface MTU is configured according real device capability.
Signed-off-by: Loic Poulain
---
drivers/net/ethernet/qualc
On 2020-07-02 11:07, Taehee Yoo wrote:
There are two problems in rmnet module that they occur the leak of
a lower interface.
The symptom is the same, which is the leak of a lower interface.
But there are two different real problems.
This patchset is to fix these real problems.
1. Do not allow to
Issue was reported yesterday and is under investigation.
http://marc.info/?l=linux-netdev&m=148014004331663&w=2
Thanks !
Hi Dmitry
Can you try the patch below with your reproducer? I haven't seen similar
crashes reported after this (or even with Eric's patch).
https://patchwork.ozlabs.o
Oh well, this wont work, since sk->sk_destruct will be called from RCU
callback.
Grabbing the mutex should not be done from netlink_sock_destruct() but
from netlink_release()
Maybe this patch would be better :
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 62bea4591054..
We are seeing a crash due to gen_lock mutex being acquired in RCU
context.
Crash is seen on a 4.4 based kernel ARM64 device. This occurred in a
regression rack, so unfortunately I don't have steps for a reproducer.
It looks like freeing socket in RCU was brought in through commit
21e4902aea80ef3
This would be a bug in the caller.
Can you give us the complete stack trace leading to the problem you
had ?
Thanks !
Thanks Eric for the clarification. In that case, the bug is in the
IDLETIMER target in Android kernel.
https://android.googlesource.com/kernel/common/+/android-4.4/net/netfil
I need to do some additional testing next week (taking PTO the next 2
days), but this should fix your problem. Can you confirm? This is
better than a sysctl to handle the known use cases, but it does not
handle a combination of the 2 known use cases (e.g., throw your use
case into a VRF).
diff --
I can't explain the iptables output but from a FIB lookup perspective
it is using table 8 per the FIB rules, the xfrm is hit and packets
shift to 192.168.77.1 and go out what you have as eth0.
Take a look at:
perf record -e fib:* -a -g
perf script
And then run tcpdump on both eth0 and eth1.
Please don't try to workaround a bug with a sysctl.
If we have a bug here, we should fix it. Choosing
between bug A and bug B with a sysctl is not what
we are doing ;)
Sure, this was just a quick hack.
Can you give an example of your use case -- e.g., commands for others
(me) to reproduce?
H
On 2016-06-12 20:30, subas...@codeaurora.org wrote:
The suggested change would extend the usable range of positive numbers
by one bit only. As many systems are 64 bit this does not seem forward
looking.
I would prefer to have a routine that can handle 64 bit integers with
limits (let's call it p
The suggested change would extend the usable range of positive numbers
by one bit only. As many systems are 64 bit this does not seem forward
looking.
I would prefer to have a routine that can handle 64 bit integers with
limits (let's call it proc_doint64vec_minmax) which uses fields extra1
and e
On 2016-05-16 20:29, Lorenzo Colitti wrote:
On Tue, May 17, 2016 at 11:24 AM, David Ahern
wrote:
As I mentioned we can print the unsupported once or per socket matched
and
with the socket params. e.g.,
+ } else if (errno == EOPNOTSUPP) {
+ printf("Operation
On 2016-04-04 10:31, Alexander Duyck wrote:
RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes
other
than fragmentation and reassembly. Currently we are looking at this
field
as a way of identifying what frames can be aggregated and which cannot
for
GRO. While this is valid
I am observing a crash originating from XFRM framework on a 3.18 ARM64
kernel.
get_rps_cpus tries to dereference the skb->dev fields but it appears
that
the device is freed from the poison pattern.
The following is the crash call stack -
55428.227024: <2> [] get_rps_cpu+0x94/0x2f0
55428.22
> Hmm, if it was 4.1.X like in original reporter case, I might have thought
> something like commit 0a1f59620068 ("ipv6: Initialize rt6_info properly
> in ip6_blackhole_route()") ... any chance on reproducing this on a latest
> kernel?
>
Unfortunately, I haven't encountered a similar crash on newe
On , Daniel Borkmann wrote:
Hi Andrew,
thanks for the report!
( Making the trace a bit more readable ... )
[41358.475254]BUG:unable to handle kernel NULL pointer dereference at
(null)
[41358.475333]IP:[]rtnetlink_put_metrics+0x50/0x180
[...]
CallTrace:
[41358.476522][]?__nla_reserve+0x23/0xe
A rcu stall with the following backtrace was seen on a system with
forwarding, optimistic_dad and use_optimistic set. To reproduce,
set these flags and allow ipv6 autoconf.
This occurs because the device write_lock is acquired while already
holding the read_lock. Back trace below -
INFO: rcu_pree
> On Mon, 2016-02-01 at 11:37 -0800, Eric Dumazet wrote:
>
>> I would rather try :
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 38eeddedfc21..d6b7ab07f914 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -3538,6 +3538,7 @@ static void addrconf_dad_begi
A rcu stall with the following backtrace was seen on a system with
forwarding, optimistic_dad and use_optimistic set. To reproduce,
set these flags and then start ipv6 autoconf.
This occurs because the device write_lock is acquired while already
holding the read_lock. Back trace below -
INFO: rcu
>>
>> The call gic_handle_irq() sounds like a hardware IRQ func/context.
>>
>> The flush_backlog() call is due to the device is being unregistered.
>>
Yes, this is the ARM interrupt controller. It appeared as if wifi was
getting torn down around this.
>> I'm surprised to see kfree_skb() being cal
We are seeing a Kernel address sanitizer (KASan) out of bounds warning
during a stability test. The call stack is as follows -
<3>BUG: KASan: out of bounds on stack in
csum_partial_copy_fromiovecend+0xac/0x36c at addr ffc019537d38
<3>Read of size 8 by task Thread-208/7505
<0>page:ffbac23d4
Fix the following typo
- unchainged -> unchanged
Signed-off-by: Subash Abhinov Kasiviswanathan
---
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 488ba6c..44d1384 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -49
> Actually we do increment refcnt, for every socket found in ehash.
>
> Carefully read again __inet_lookup_established()
>
> This code is generic for ESTABLISH and TIME-WAIT sockets
>
> If you found a code that performed the lookup without taking the refcnt,
> please point me at it, this would be a
>> //Initialize time wait socket and setup timer
>> inet_twsk_alloc() tw_refcnt = 0
>> __inet_twsk_hashdance() tw_refcnt = 3
>> inet_twsk_schedule() tw_refcnt = 4
>> inet_twsk_put() tw_refcnt = 3
>>
>> //Receive packet 1 in timewait state
>> tcp_timewait_state_process() -> inet_twsk_schedule tw_ref
I am seeing an issue with the reference count of time wait sockets which
leads to freeing of active timer object. This occurs in some data stress
test setups, so I am unable to determine the exact step when it occured.
However, I logged the refcount and was able to find out the code path
which lead
Fix an issue where __nf_ct_ext_find() could return null to nat in
nf_nat_masquerade_ipv4() and could be dereferenced.
This was detected by static analysis software.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 2 ++
1 file changed, 2 insertions
When NAPI_STATE_SCHED state is not set, enqueue_to_backlog()
will queue an IPI and add the backlog queue to the poll list. A packet
added by RPS onto the core could also add the NAPI backlog struct to the
poll list. This double addition to the list causes a crash -
2920.540304: <2> list_add doub
37 matches
Mail list logo
