* Re: [PATCH net-next v2 4/5] bonding: fix LACP PDU not sent on slave port sometimes
From: Sergei Shtylyov @ 2015-01-26 12:04 UTC (permalink / raw)
To: Jonathan Toppins, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
Cc: netdev, Satish Ashok, Andy Gospodarek
In-Reply-To: <1422253021-3798-5-git-send-email-jtoppins@cumulusnetworks.com>
Hello.
On 1/26/2015 9:17 AM, Jonathan Toppins wrote:
> From: Satish Ashok <sashok@cumulusnetworks.com>
> When a slave is added to a bond and it is not in full duplex mode,
> AD_PORT_LACP_ENABLED flag is cleared, due to this LACP PDU is not sent
s/is not/not being/.
> on slave. When the duplex is changed to full, the flag needs to be set
> to send LACP PDU.
> Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
> Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
> Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com>
> Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
> ---
> drivers/net/bonding/bond_3ad.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index e3c96b2..cfc4a9c 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -2219,8 +2219,10 @@ static int bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave,
> switch (lacpdu->subtype) {
> case AD_TYPE_LACPDU:
> ret = RX_HANDLER_CONSUMED;
> - netdev_dbg(slave->bond->dev, "Received LACPDU on port %d\n",
> - port->actor_port_number);
> + netdev_dbg(slave->bond->dev,
> + "Received LACPDU on port %d slave %s\n",
> + port->actor_port_number,
> + slave->dev->name);
> /* Protect against concurrent state machines */
> spin_lock(&slave->bond->mode_lock);
> ad_rx_machine(lacpdu, port);
> @@ -2312,7 +2314,10 @@ void bond_3ad_adapter_duplex_changed(struct slave *slave)
> port->actor_admin_port_key &= ~AD_DUPLEX_KEY_MASKS;
> port->actor_oper_port_key = port->actor_admin_port_key |=
> __get_duplex(port);
> - netdev_dbg(slave->bond->dev, "Port %d changed duplex\n", port->actor_port_number);
> + netdev_dbg(slave->bond->dev, "Port %d slave %s changed duplex\n",
> + port->actor_port_number, slave->dev->name);
The above 2 changes seem unrelated/undocumented in the change log...
[...]
WBR, Sergei
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jamal Hadi Salim @ 2015-01-26 12:26 UTC (permalink / raw)
To: Simon Horman
Cc: John Fastabend, Thomas Graf, Jiri Pirko, Pablo Neira Ayuso,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150126082602.GB8408@vergenet.net>
On 01/26/15 03:26, Simon Horman wrote:
> On Sat, Jan 24, 2015 at 08:01:52AM -0500, Jamal Hadi Salim wrote:
>
> [snip]
>
>> Lets discuss at the meeting. I am just skimming these emails (the
>> conference is chewing a lot of my time so i will mostly be absent).
>> Sorry if i am not responding to some things.
>
> Is "the meeting" the Hardware Offloading BoF at Netdev 1.0?
> For the benefit of others: https://www.netdev01.org/sessions/10
>
Yes, that is the plan. Sorry - the statement was addressed at the usual
suspects who probably understood the context.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix slab corruption from use after free on INIT collisions
From: Neil Horman @ 2015-01-26 12:33 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, vyasevich, netdev, linux-sctp
In-Reply-To: <1421947614-31407-1-git-send-email-dborkman@redhat.com>
On Thu, Jan 22, 2015 at 06:26:54PM +0100, Daniel Borkmann wrote:
> When hitting an INIT collision case during the 4WHS with AUTH enabled, as
> already described in detail in commit 1be9a950c646 ("net: sctp: inherit
> auth_capable on INIT collisions"), it can happen that we occasionally
> still remotely trigger the following panic on server side which seems to
> have been uncovered after the fix from commit 1be9a950c646 ...
>
> [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230
> [ 533.940559] PGD 5030f2067 PUD 0
> [ 533.957104] Oops: 0000 [#1] SMP
> [ 533.974283] Modules linked in: sctp mlx4_en [...]
> [ 534.939704] Call Trace:
> [ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0
> [ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0
> [ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170
> [ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0
> [ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50
> [ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]
> [ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0
> [ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> ... or depending on the the application, for example this one:
>
> [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0
> [ 1370.054568] PGD 633c94067 PUD 0
> [ 1370.070446] Oops: 0000 [#1] SMP
> [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
> [ 1370.963431] Call Trace:
> [ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960
> [ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960
> [ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170
> [ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130
> [ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> With slab debugging enabled, we can see that the poison has been overwritten:
>
> [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten
> [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
> [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
> [ 669.826424] __slab_alloc+0x4bf/0x566
> [ 669.826433] __kmalloc+0x280/0x310
> [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp]
> [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
> [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
> [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...]
> [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
> [ 669.826635] __slab_free+0x39/0x2a8
> [ 669.826643] kfree+0x1d6/0x230
> [ 669.826650] kzfree+0x31/0x40
> [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp]
> [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp]
> [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp]
>
> Since this only triggers in some collision-cases with AUTH, the problem at
> heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
> when having refcnt 1, once directly in sctp_assoc_update() and yet again
> from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
> the already kzfree'd memory, which is also consistent with the observation
> of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
> at a later point in time when poison is checked on new allocation).
>
> Reference counting of auth keys revisited:
>
> Shared keys for AUTH chunks are being stored in endpoints and associations
> in endpoint_shared_keys list. On endpoint creation, a null key is being
> added; on association creation, all endpoint shared keys are being cached
> and thus cloned over to the association. struct sctp_shared_key only holds
> a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
> keeps track of users internally through refcounting. Naturally, on assoc
> or enpoint destruction, sctp_shared_key are being destroyed directly and
> the reference on sctp_auth_bytes dropped.
>
> User space can add keys to either list via setsockopt(2) through struct
> sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
> adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
> with refcount 1 and in case of replacement drops the reference on the old
> sctp_auth_bytes. A key can be set active from user space through setsockopt()
> on the id via sctp_auth_set_active_key(), which iterates through either
> endpoint_shared_keys and in case of an assoc, invokes (one of various places)
> sctp_auth_asoc_init_active_key().
>
> sctp_auth_asoc_init_active_key() computes the actual secret from local's
> and peer's random, hmac and shared key parameters and returns a new key
> directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
> the reference if there was a previous one. The secret, which where we
> eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
> intitial refcount of 1, which also stays unchanged eventually in
> sctp_assoc_update(). This key is later being used for crypto layer to
> set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
>
> To close the loop: asoc->asoc_shared_key is freshly allocated secret
> material and independant of the sctp_shared_key management keeping track
> of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
> ("net: sctp: fix memory leak in auth key management") is independant of
> this bug here since it concerns a different layer (though same structures
> being used eventually). asoc->asoc_shared_key is reference dropped correctly
> on assoc destruction in sctp_association_free() and when active keys are
> being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
> of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
> to remove that sctp_auth_key_put() from there which fixes these panics.
>
> Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/associola.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index f791edd..26d06db 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1182,7 +1182,6 @@ void sctp_assoc_update(struct sctp_association *asoc,
> asoc->peer.peer_hmacs = new->peer.peer_hmacs;
> new->peer.peer_hmacs = NULL;
>
> - sctp_auth_key_put(asoc->asoc_shared_key);
> sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC);
> }
>
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Altera TSE (altera_tse) net_rx_action WARNING - polling bug in altera_tse_main.c?
From: Vlastimil Šetka @ 2015-01-26 12:39 UTC (permalink / raw)
To: vbridger, netdev
Hello,
I am using Altera TSE kernel driver (altera_tse module) on Altera
socfpga platform (Cyclone V SoC with ARM Cortex-A9) and I probably
discovered a bug in it. I have two TSE controllers instantiated in FPGA
- my FPGA HW design is based on this tutorial:
http://www.rocketboards.org/foswiki/Projects/AlteraSoCTripleSpeedEthernetDesignExample
The kernel version is 3.10.37-ltsi with RT patch, from
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=7ea94617cfae6a62ee963adc1ae340196dbe2b34
with backported some altera_tse fixes from current 3.19-rc5.
I was not able to get TSE ethernets working on vanilla 3.19-rc5,
probably because of some changes around interrupts and devicetree, but
it's another story.
After some time (minutes to hours) of exhaustive traffic generated by
iperf through altera_tse ethernet, I can see a kernel warning on console
like this:
------------[ cut here ]------------
WARNING: at net/core/dev.c:4255 net_rx_action+0x268/0x28c()
Modules linked in: gpio_altera altera_sysid altera_tse
CPU: 0 PID: 5885 Comm: irq/75-eth2 Not tainted
3.10.37-ltsi-rt37-vs-2-1-00062-g861955e #1
[<800166c4>] (unwind_backtrace+0x0/0x100) from [<80012edc>]
(show_stack+0x20/0x24)
[<80012edc>] (show_stack+0x20/0x24) from [<80503404>] (dump_stack+0x24/0x28)
[<80503404>] (dump_stack+0x24/0x28) from [<8002303c>]
(warn_slowpath_common+0x64/0x7c)
[<8002303c>] (warn_slowpath_common+0x64/0x7c) from [<80023110>]
(warn_slowpath_null+0x2c/0x34)
[<80023110>] (warn_slowpath_null+0x2c/0x34) from [<80404d48>]
(net_rx_action+0x268/0x28c)
[<80404d48>] (net_rx_action+0x268/0x28c) from [<8002bd18>]
(do_current_softirqs+0x1e4/0x388)
[<8002bd18>] (do_current_softirqs+0x1e4/0x388) from [<8002bf34>]
(local_bh_enable+0x78/0x90)
[<8002bf34>] (local_bh_enable+0x78/0x90) from [<80086c9c>]
(irq_forced_thread_fn+0x50/0x74)
[<80086c9c>] (irq_forced_thread_fn+0x50/0x74) from [<80086fbc>]
(irq_thread+0x16c/0x1c8)
[<80086fbc>] (irq_thread+0x16c/0x1c8) from [<80048104>] (kthread+0xb4/0xb8)
[<80048104>] (kthread+0xb4/0xb8) from [<8000e718>] (ret_from_fork+0x14/0x20)
---[ end trace 0000000000000002 ]---
The warning point is:
WARN_ON_ONCE(work > weight);
at
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=net/core/dev.c;h=2193b5dc276ad6aa54adb1ee15ef3de625915fcd;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l4255
After a warning, interface is still working without problems.
I am not much familiar with Linux network stack and device drivers. But
I probably found a root cause in:
# drivers/net/ethernet/altera/altera_tse_main.c.
#
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=drivers/net/ethernet/altera/altera_tse_main.c;h=07c0b193c55722d18ff2723f0a7e137671746ba1;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l368
static int tse_rx(struct altera_tse_private *priv, int limit)
the `limit` parameter is not used anywhere in the function! When
`tse_rx` is called from `tse_poll` it can return more frames than limit,
which in the end triggers the kernel warning as I think:
# drivers/net/ethernet/altera/altera_tse_main.c
#
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=drivers/net/ethernet/altera/altera_tse_main.c;h=07c0b193c55722d18ff2723f0a7e137671746ba1;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l488
static int tse_poll(struct napi_struct *napi, int budget)
{
...
txcomplete = tse_tx_complete(priv);
rxcomplete = tse_rx(priv, budget);
if (rxcomplete >= budget || txcomplete > 0)
return rxcomplete;
Condition `if (rxcomplete >= budget || txcomplete > 0) return
rxcomplete;` is also very weird for me. I am not sure if it's buggy, but
I think it should be at least commented how it works.
Vlastimil Setka
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Sun Paul @ 2015-01-26 13:17 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Daniel Borkmann, Michael Tuexen, Vlad Yasevich, linux-sctp,
netdev, linux-kernel
In-Reply-To: <54C62912.3040401@gmail.com>
When an ABORT is sent to side-A, side-A INIT a new connection again.
On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
>> request to side-B, and side-B return the response, but side-A keep
>> re-transmit the same request to side-B, why side-B needed to send a
>> ABORT to side-A?
>
>
> That happens on data transfers. When A pushes data to B, A has to retry it
> until B finally acknowledges it and A receive this signal. If the ack from B
> gets dropped, A has no way to know if a) the ack was lost or b) its initial
> message never actually made it to A, thus it retransmits. If it reaches a
> limit, it gives up..
>
>> If it is used in order to reestablish the connection, shoudn't it
>> should be side-A to send ABORT instead?
>
>
> Meant to reestablish it? Not really.. just to keep both sides in sync, as A
> has given up by then.
>
> Marcelo
>
>> - PS
>>
>> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>>> ...
>>>>
>>>>
>>>> Yepp. It might not reach the peer or it might. If it does it helps
>>>> to keep the states in sync. If it doesn't it sometimes helps in
>>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>>> doesn't harm and is useful in some cases...
>>>
>>>
>>>
>>> Ok, as the TCB is destroyed in any case, should be fine then.
>>>
>>> Thanks,
>>> Daniel
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-26 13:30 UTC (permalink / raw)
To: Sun Paul
Cc: Marcelo Ricardo Leitner, Michael Tuexen, Vlad Yasevich,
linux-sctp, netdev, linux-kernel
In-Reply-To: <CAFXGftJNZ48Qe4DLgf5TPBvNCnUH8wxon9+b3_i_GWVYqnphhg@mail.gmail.com>
On 01/26/2015 02:17 PM, Sun Paul wrote:
> When an ABORT is sent to side-A, side-A INIT a new connection again.
Even if the ABORT is not being sent, the peer (the one who would send
his ABORT) closes the TCB from his side silently then. Any messages that
would afterwards arrive on this dead connection would be answered with
an oob ABORT just as well. I'm still missing the bigger picture on your
use-case scenario here, I guess ... why is the recommended rtx limit not
sufficient?
^ permalink raw reply
* Fw: [Bug 91471] New: add and removing macvlan link caused this dump trace
From: Stephen Hemminger @ 2015-01-26 13:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 16 Jan 2015 19:16:28 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 91471] New: add and removing macvlan link caused this dump trace
https://bugzilla.kernel.org/show_bug.cgi?id=91471
Bug ID: 91471
Summary: add and removing macvlan link caused this dump trace
Product: Networking
Version: 2.5
Kernel Version: 3.13.0-32-generic
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: ray.qiu@gmail.com
Regression: No
It can be consistently reproduced.
- Bring up a docker container
- Create an ip link with type macvlan
- Move it to another netns for a container
- Bring it up and assign ip address
- Then, remove the link from the container and terminate the container.
- Repeat the process again will cause this crash dump.
------------[ cut here ]------------
[ 2307.593973] kernel BUG at /build/buildd/linux-3.13.0/net/core/dev.c:6437!
[ 2307.594461] invalid opcode: 0000 [#1] SMP
[ 2307.594883] Modules linked in: veth macvlan openvswitch gre vxlan ip_tunnel
libcrc32c xt_addrtype xt_conntrack ipt_MASQUERADE iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge stp llc aufs
iptable_filter ip_tables x_tables hid_generic ppdev coretemp kvm_intel kvm
crct10dif_pclmul crc32_pclmul btusb ghash_clmulni_intel bluetooth vmw_balloon
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_ens1371
serio_raw snd_ac97_codec ac97_bus gameport snd_rawmidi snd_seq_device snd_pcm
usbhid hid snd_page_alloc snd_timer snd soundcore vmwgfx ttm shpchp drm
i2c_piix4 vmw_vmci parport_pc mac_hid lp parport psmouse ahci libahci e1000
mptspi mptscsih floppy mptbase vmw_pvscsi vmxnet3
[ 2307.598952] CPU: 0 PID: 6778 Comm: ip Tainted: G W
3.13.0-32-generic #57-Ubuntu
[ 2307.599433] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 2307.600419] task: ffff8801353d5fc0 ti: ffff8801352f2000 task.ti:
ffff8801352f2000
[ 2307.600955] RIP: 0010:[<ffffffff8162447f>] [<ffffffff8162447f>]
free_netdev+0xff/0x110
[ 2307.601475] RSP: 0018:ffff8801352f38d8 EFLAGS: 00010293
[ 2307.602000] RAX: 0000000000000001 RBX: ffff8800b6bdb018 RCX:
0000000000000254
[ 2307.602498] RDX: 0000000000000001 RSI: 0000000000000282 RDI:
0000000000000282
[ 2307.602988] RBP: ffff8801352f38f0 R08: 00018608fffffee0 R09:
ffffff90ffffffb0
[ 2307.603477] R10: ffffff90ffffffb0 R11: 00001398ffffffd0 R12:
ffff8800b6bdb060
[ 2307.603967] R13: ffff8800b6bdb000 R14: ffff8801352f3900 R15:
ffffffffa0485000
[ 2307.604455] FS: 00007f0e72cff740(0000) GS:ffff880138400000(0000)
knlGS:0000000000000000
[ 2307.604947] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2307.605433] CR2: 00007fff9b91fe60 CR3: 0000000134b11000 CR4:
00000000001407f0
[ 2307.606043] Stack:
[ 2307.606578] 00000000ffffffef ffffffff81cda240 ffff8801352f3920
ffff8801352f3ae8
[ 2307.607259] ffffffff81632848 0000000000000000 ffff8800ba35c648
0000000000000000
[ 2307.607815] ffffffff8163240e ffffffff81cda240 ffff8800ba35c610
ffff8800b6bdb000
[ 2307.608444] Call Trace:
[ 2307.608982] [<ffffffff81632848>] rtnl_newlink+0x578/0x5d0
[ 2307.609809] [<ffffffff8163240e>] ? rtnl_newlink+0x13e/0x5d0
[ 2307.610858] [<ffffffff8162f0b9>] rtnetlink_rcv_msg+0x99/0x260
[ 2307.611868] [<ffffffff81610e7e>] ? __alloc_skb+0x7e/0x2b0
[ 2307.612922] [<ffffffff8162f020>] ? rtnetlink_rcv+0x30/0x30
[ 2307.613920] [<ffffffff8164d659>] netlink_rcv_skb+0xa9/0xc0
[ 2307.614987] [<ffffffff8162f018>] rtnetlink_rcv+0x28/0x30
[ 2307.615974] [<ffffffff8164cc85>] netlink_unicast+0xd5/0x1b0
[ 2307.616948] [<ffffffff8164d05f>] netlink_sendmsg+0x2ff/0x740
[ 2307.617957] [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
[ 2307.619037] [<ffffffff811b1356>] ? __mem_cgroup_commit_charge+0x156/0x3d0
[ 2307.620042] [<ffffffff816076de>] ? move_addr_to_kernel.part.16+0x1e/0x60
[ 2307.620963] [<ffffffff816082a1>] ? move_addr_to_kernel+0x21/0x30
[ 2307.621874] [<ffffffff81608273>] ___sys_sendmsg+0x3c3/0x3d0
[ 2307.622691] [<ffffffff81727c64>] ? __do_page_fault+0x204/0x560
[ 2307.623572] [<ffffffff8111155c>] ? acct_account_cputime+0x1c/0x20
[ 2307.624061] [<ffffffff8109d7db>] ? account_user_time+0x8b/0xa0
[ 2307.624472] [<ffffffff81608972>] __sys_sendmsg+0x42/0x80
[ 2307.624864] [<ffffffff816089c2>] SyS_sendmsg+0x12/0x20
[ 2307.625265] [<ffffffff8172c87f>] tracesys+0xe1/0xe6
[ 2307.625628] Code: a7 e6 ff 5b 41 5c 41 5d 5d c3 66 90 e8 2b 3a b6 ff e9 53
ff ff ff 66 0f 1f 44 00 00 4c 89 ef e8 b8 fe ff ff 5b 41 5c 41 5d 5d c3 <0f> 0b
66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[ 2307.626779] RIP [<ffffffff8162447f>] free_netdev+0xff/0x110
[ 2307.627392] RSP <ffff8801352f38d8>
[ 2307.629586] ---[ end trace 9c2a19ae6ba1d1f6 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 91491] New: trie_leaf_remove
From: Stephen Hemminger @ 2015-01-26 13:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 17 Jan 2015 13:30:29 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 91491] New: trie_leaf_remove
https://bugzilla.kernel.org/show_bug.cgi?id=91491
Bug ID: 91491
Summary: trie_leaf_remove
Product: Networking
Version: 2.5
Kernel Version: 3.14-2-amd64 #1 Debian 3.14.15-2.1khz
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: blocking
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: komur@bilkent.edu.tr
Regression: No
[690122.777855] BUG: unable to handle kernel paging request at ffff88b40504020c
[690122.777870] IP: [<ffffffff81454e7f>] trie_leaf_remove+0x1f/0xa0
[690122.777881] PGD 0
[690122.777886] Oops: 0000 [#1] SMP
[690122.777893] Modules linked in: bonding loop xt_CLASSIFY xt_TCPMSS
iptable_mangle xt_u32 ipt_REJECT xt_tcpudp xt_recent iptable_filter ip_tables
x_tables x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel
snd_hda_codec_hdmi kvm crc32_pclmul crc32c_intel snd_hda_intel snd_hda_codec
snd_hwdep ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd aes_x86_64
soundcore lrw joydev gf128mul iTCO_wdt glue_helper iTCO_vendor_support
ablk_helper cryptd evdev mxm_wmi psmouse sb_edac pcspkr serio_raw edac_core
tpm_tis i2c_i801 tpm nuvoton_cir rc_core wmi button mei_me lpc_ich mei shpchp
mfd_core processor thermal_sys hid_generic usbhid hid ext4 crc16 mbcache jbd2
sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci
libahci libata ehci_pci igb xhci_hcd scsi_mod i2c_algo_bit
[690122.778005] ehci_hcd i2c_core dca usbcore ptp pps_core usb_common
[690122.778005] CPU: 6 PID: 1557 Comm: zebra Not tainted 3.14-2-amd64 #1 Debian
3.14.15-2.1khz
[690122.778005] Hardware name: /DX79SI, BIOS
SIX7910J.86A.0525.2012.0709.1221 07/09/2012
[690122.778005] task: ffff880224960390 ti: ffff880225464000 task.ti:
ffff880225464000
[690122.778005] RIP: 0010:[<ffffffff81454e7f>] [<ffffffff81454e7f>]
trie_leaf_remove+0x1f/0xa0
[690122.778005] RSP: 0018:ffff880225465a58 EFLAGS: 00010286
[690122.778005] RAX: 0000000000000000 RBX: ffff88b405040200 RCX:
ffff8800baa153e8
[690122.778005] RDX: ffffffff818412c0 RSI: ffff8800baa153e8 RDI:
ffff88022505ab60
[690122.778005] RBP: ffff8800baa153e8 R08: 0000000000000000 R09:
0000000000000001
[690122.778005] R10: 0000000000000400 R11: ffff8800c9ebbc80 R12:
ffff88022505ab60
[690122.778005] R13: ffff88022505ab40 R14: ffff8800c9607998 R15:
ffff8800c2c39cd8
[690122.778005] FS: 00007fd6e82c8700(0000) GS:ffff88022fcc0000(0000)
knlGS:0000000000000000
[690122.778005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[690122.778005] CR2: ffff88b40504020c CR3: 00000002228c1000 CR4:
00000000000407e0
[690122.778005] Stack:
[690122.778005] ffff8800c9607980 ffff880225465ad8 0000000000000018
ffffffff81455a70
[690122.778005] ffffffff00000000 ffff8800baa153e8 0000000000000000
ffff88022505ab60
[690122.778005] ffff8800c9607980 ffffffff81889180 ffff8800ca0b5bc0
0000000000000009
[690122.778005] Call Trace:
[690122.778005] [<ffffffff81455a70>] ? fib_table_delete+0x280/0x2d0
[690122.778005] [<ffffffff8144f75e>] ? inet_rtm_delroute+0x3e/0x50
[690122.778005] [<ffffffff813ed7ba>] ? rtnetlink_rcv_msg+0x8a/0x250
[690122.778005] [<ffffffff813d01e3>] ? __alloc_skb+0x43/0x2a0
[690122.778005] [<ffffffff813ed730>] ? rtnetlink_rcv+0x30/0x30
[690122.778005] [<ffffffff8140b5c9>] ? netlink_rcv_skb+0xa9/0xc0
[690122.778005] [<ffffffff813ed71f>] ? rtnetlink_rcv+0x1f/0x30
[690122.778005] [<ffffffff8140abc8>] ? netlink_unicast+0xe8/0x1f0
[690122.778005] [<ffffffff8140afec>] ? netlink_sendmsg+0x31c/0x740
[690122.778005] [<ffffffff813c7c96>] ? sock_sendmsg+0x86/0xc0
[690122.778005] [<ffffffff8119ab20>] ? poll_select_copy_remaining+0x130/0x130
[690122.778005] [<ffffffff813c7a24>] ? move_addr_to_kernel.part.18+0x14/0x60
[690122.778005] [<ffffffff813c83e3>] ? ___sys_sendmsg+0x373/0x380
[690122.778005] [<ffffffff8108871f>] ? update_rq_clock.part.85+0xf/0x30
[690122.778005] [<ffffffff8108e294>] ? task_sched_runtime+0x54/0xa0
[690122.778005] [<ffffffff8109273d>] ? cputime_adjust+0x1d/0x120
[690122.778005] [<ffffffff81092da5>] ? thread_group_cputime_adjusted+0x35/0x40
[690122.778005] [<ffffffff8105d329>] ? mmput+0x9/0x120
[690122.778005] [<ffffffff813c8a59>] ? __sys_sendmsg+0x39/0x70
[690122.778005] [<ffffffff814d30bd>] ? system_call_fast_compare_end+0x10/0x15
[690122.778005] Code: 00 45 31 ff eb c2 0f 0b 0f 1f 40 00 41 54 49 89 fc 55 48
89 f5 53 48 8b 1e 48 83 e3 fe f6 05 02 93 45 00 04 75 60 48 85 db 74 51 <0f> b6
4b 0c 31 f6 0f b6 43 0d 8b 55 08 80 f9 1f 77 0d d3 e2 b9
[690122.778005] RIP [<ffffffff81454e7f>] trie_leaf_remove+0x1f/0xa0
[690122.778005] RSP <ffff880225465a58>
[690122.778005] CR2: ffff88b40504020c
[690122.778005] ---[ end trace 5b32f2333bf1a5eb ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* NetDev 0.1 conference post-CFP deadline weekly update
From: Richard Guy Briggs @ 2015-01-26 13:35 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Cc: info, speakers, attendees
Fellow netheads:
New Sponsors (All listed at: https://www.netdev01.org/sponsors)
=============
We are pleased to announce a sixth sponsor:
CENGN http://www.cengn.ca/
Hotel earlybird special rates have expired as of this past Friday.
There are lots of big and small hotels in Ottawa, but they will fill up
fast as Winterlude approaches, so book something soon. There may be
some possibilities to billet locally, but don't leave it last minute.
The call for proposal deadline was this past Saturday, so expect a
schedule to be published this week.
Here is the post-CFP deadline update of the activity so far in NetDev
0.1 you may have missed if you aren't following the RSS feed or twitter:
Confirmed keynote speaker:
==========================
David S. Miller - The Current State of Linux kernel Networking.
Accepted talks: (All listed: https://www.netdev01.org/sessions )
==========================
The case for eliminating inconsistencies between Linux kernel IPv4/IPv6 API
https://www.netdev01.org/sessions/25
Roopa Prabhu
Networking in Containers and Container Clusters
https://www.netdev01.org/sessions/27
Victor Marmol
ipvlan
https://www.netdev01.org/sessions/28
Mahesh Bandewar
BIRD Internet Routing Daemon
https://www.netdev01.org/sessions/29
Ondrej Zajicek
Cooperative networking virtualization for the industrial server applications
https://www.netdev01.org/news/46
Vasiliy Tolstoy, Sergey Kovalev
Accepted Tutorials (All listed: https://www.netdev01.org/sessions )
===================
Hardware Accelerating Linux Network Functions
https://www.netdev01.org/sessions/24
Roopa Prabhu, Toshiaki Makita
nftables tutorial
https://www.netdev01.org/sessions/30
Pablo Neira Ayuso, Patrick McHardy
Accepted BoFs:
===================
Netfilter BoF
https://www.netdev01.org/sessions/26
Pete Bohmann, David Gervais, Josh Hunt
All of the accepted proposals are new work. A couple of proposals have been
returned for rework prior to acceptance. There are a few proposals
currently making their way through the technical committee vetting
process. The committee has so far been very impressed with the quality
of proposals submitted.
More coming in future updates.
If you've gotten this far reading - please go and register.
Registration https://onlineregistrations.ca/netdev01/
$100/day, or $350 for 4 days (Cdn dollars, reel cheep at the moment).
(online reg closes Feb 12th). Again:
Registering earlier rather than later helps us plan properly for numbers
of attendees, ensuring venue sizes and supplies are appropriate without
wasting resources.
Sponsors:
=========
NetDev 0.1 would like to gratefully acknowledge all our sponsors:
https://netdev01.org/sponsors
CENGN http://www.cengn.ca/
Google https://www.google.ca
Qualcomm https://www.qualcomm.com/
Verizon http://www.verizon.com/
Cumulus Networks http://cumulusnetworks.com/
Mojatatu Networks http://mojatatu.com/
Important Dates:
==========================
December 2, 2014 Call for Papers opens
December 10, 2014 Registration opens
January 23, 2015 Hotel discount rates deadline
January 24, 2015 Call for sessions deadline
February 12, 2015 On-line registration closes
February 14-17, 2015 Conference days
-------------------------------------------------------------------------------
THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada
https://netdev01.org/
Contact: info@netdev01.info
Main site: https://www.netdev01.org/
Announcement: https://www.netdev01.org/announce
CFP: https://www.netdev01.org/cfp
Travel/hotel/weather/clothing: https://www.netdev01.org/travel
RSS feed: https://netdev01.org/atom
Follow us on Twitter: @netdev01 https://twitter.com/netdev01
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Neil Horman @ 2015-01-26 13:47 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Daniel Borkmann, Sun Paul, linux-sctp, netdev, linux-kernel,
tuexen
In-Reply-To: <54C2935F.2000105@gmail.com>
On Fri, Jan 23, 2015 at 01:30:55PM -0500, Vlad Yasevich wrote:
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> > On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> >>> On 01/23/2015 11:25 AM, Sun Paul wrote:
> >>> ...
> >>>> I would like to check the behave in LKSCTP.
> >>>>
> >>>> we are running DIAMETER message over SCTP, and we have set the
> >>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> >>>>
> >>>> We noticed that when remote peer have retry to send the same request
> >>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> >>>> "association exceeded its max_retrans count".
> >>>>
> >>>> We would like to know whether this is the correct behavior? is there
> >>>> any other option that we can alter in order to avoid the ABORT chunk
> >>>> being sent?
> >>>
> >>> I don't recall the RFC saying to send an ABORT, but let me double
> >>> check in the mean time.
> >>
> >> The RFC is silent on the matter. The abort got added in 3.8 so
> >> it's been there for a while.
> >
> > I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> > exceeded") added the behaviour.
> >
> >>> Hmm, untested, but could you try something like that?
> >>>
> >>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> >>> index fef2acd..5ce198d 100644
> >>> --- a/net/sctp/sm_sideeffect.c
> >>> +++ b/net/sctp/sm_sideeffect.c
> >>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
> >>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> >>> SCTP_ULPEVENT(event));
> >>>
> >>> - if (asoc->overall_error_count >= asoc->max_retrans) {
> >>> + if (asoc->overall_error_count >= asoc->max_retrans &&
> >>> + error != SCTP_ERROR_NO_ERROR) {
> >>> abort = sctp_make_violation_max_retrans(asoc, chunk);
> >>> if (abort)
> >>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >>
> >> This would pretty much stop all ABORTs due to excessive rtx. Might
> >> as well take the code out :).
> >>
> >> I was a bit concerned about this ABORT when it went in.
> >
> > So effectively, if I understand the argument from the commit, the
> > assumption is that the ABORT would never reach the peer anyway, but
> > is a way for tcpdump users to see on the wire that rtx limit has
> > been exceeded and since there's not mentioned anything in the RFC
> > about this, it doesn't break it. Hm.
> >
>
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
>
> -vlad
>
IIRC, BSD is where this patch came from initially.
Neil
> > Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> >
> > Thanks,
> > Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Replace shift operations by BIT macro
From: Varka Bhadram @ 2015-01-26 14:04 UTC (permalink / raw)
To: Mohammad Jamal, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021509-18877-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Jamal,
On Friday 23 January 2015 07:28 PM, Mohammad Jamal wrote:
> This patch replaces the shifting operations by BIT macro
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index 665a3db..181b349 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -44,9 +44,9 @@
> #define CC2520_FREG_MASK 0x3F
>
> /* status byte values */
> -#define CC2520_STATUS_XOSC32M_STABLE (1 << 7)
> -#define CC2520_STATUS_RSSI_VALID (1 << 6)
> -#define CC2520_STATUS_TX_UNDERFLOW (1 << 3)
> +#define CC2520_STATUS_XOSC32M_STABLE BIT(7)
> +#define CC2520_STATUS_RSSI_VALID BIT(6)
> +#define CC2520_STATUS_TX_UNDERFLOW BIT(3)
>
> /* IEEE-802.15.4 defined constants (2.4 GHz logical channels) */
> #define CC2520_MINCHANNEL 11
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Varka Bhadram @ 2015-01-26 14:05 UTC (permalink / raw)
To: Mohammad Jamal, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021327-18815-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Jamal,
On Friday 23 January 2015 07:25 PM, Mohammad Jamal wrote:
> This patch removes the warnings (space before , ) shown by
> checkpatch.pl
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index a43c8ac..665a3db 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -549,14 +549,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
> if (ret)
> return ret;
>
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Hannes Frederic Sowa @ 2015-01-26 14:11 UTC (permalink / raw)
To: netdev; +Cc: lkundrak
Lubomir Rintel reported that during replacing a route the interface
reference counter isn't correctly decremented.
To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
| [root@rhel7-5 lkundrak]# sh -x lal
| + ip link add dev0 type dummy
| + ip link set dev0 up
| + ip link add dev1 type dummy
| + ip link set dev1 up
| + ip addr add 2001:db8:8086::2/64 dev dev0
| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
| + ip link del dev0 type dummy
| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
|
| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
During replacement of a rt6_info we must walk all parent nodes and check
if the to be replaced rt6_info got propagated. If so, replace it with
an alive one.
Reported-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/ip6_fib.c | 45 ++++++++++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 53775ee..263ef41 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -661,6 +661,29 @@ static int fib6_commit_metrics(struct dst_entry *dst, struct mx6_config *mxc)
return 0;
}
+static void fib6_purge_rt(struct rt6_info *rt, struct fib6_node *fn,
+ struct net *net)
+{
+ if (atomic_read(&rt->rt6i_ref) != 1) {
+ /* This route is used as dummy address holder in some split
+ * nodes. It is not leaked, but it still holds other resources,
+ * which must be released in time. So, scan ascendant nodes
+ * and replace dummy references to this route with references
+ * to still alive ones.
+ */
+ while (fn) {
+ if (!(fn->fn_flags & RTN_RTINFO) && fn->leaf == rt) {
+ fn->leaf = fib6_find_prefix(net, fn);
+ atomic_inc(&fn->leaf->rt6i_ref);
+ rt6_release(rt);
+ }
+ fn = fn->parent;
+ }
+ /* No more references are possible at this point. */
+ BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
+ }
+}
+
/*
* Insert routing information in a node.
*/
@@ -808,11 +831,12 @@ add:
rt->dst.rt6_next = iter->dst.rt6_next;
atomic_inc(&rt->rt6i_ref);
inet6_rt_notify(RTM_NEWROUTE, rt, info);
- rt6_release(iter);
if (!(fn->fn_flags & RTN_RTINFO)) {
info->nl_net->ipv6.rt6_stats->fib_route_nodes++;
fn->fn_flags |= RTN_RTINFO;
}
+ fib6_purge_rt(iter, fn, info->nl_net);
+ rt6_release(iter);
}
return 0;
@@ -1323,24 +1347,7 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
fn = fib6_repair_tree(net, fn);
}
- if (atomic_read(&rt->rt6i_ref) != 1) {
- /* This route is used as dummy address holder in some split
- * nodes. It is not leaked, but it still holds other resources,
- * which must be released in time. So, scan ascendant nodes
- * and replace dummy references to this route with references
- * to still alive ones.
- */
- while (fn) {
- if (!(fn->fn_flags & RTN_RTINFO) && fn->leaf == rt) {
- fn->leaf = fib6_find_prefix(net, fn);
- atomic_inc(&fn->leaf->rt6i_ref);
- rt6_release(rt);
- }
- fn = fn->parent;
- }
- /* No more references are possible at this point. */
- BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
- }
+ fib6_purge_rt(rt, fn, net);
inet6_rt_notify(RTM_DELROUTE, rt, info);
rt6_release(rt);
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] vxlan: advertise link netns in fdb messages
From: Nicolas Dichtel @ 2015-01-26 13:10 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
Previous commit is based on a wrong assumption, fdb messages are always sent
into the netns where the interface stands (see vxlan_fdb_notify()).
These fdb messages doesn't embed the rtnl attribute IFLA_LINK_NETNSID, thus we
need to add it (useful to interpret NDA_IFINDEX or NDA_DST for example).
Note also that vxlan_nlmsg_size() was not updated.
Fixes: 193523bf9373 ("vxlan: advertise netns of vxlan dev in fdb msg")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Note that NDA_NDM_IFINDEX_NETNSID exists only in net-next, thus it's still
possible to remove it.
drivers/net/vxlan.c | 5 +++--
include/uapi/linux/neighbour.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 19d3664ab9dd..c20a71fdcfa3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -340,8 +340,8 @@ static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan,
ndm->ndm_type = RTN_UNICAST;
if (!net_eq(dev_net(vxlan->dev), vxlan->net) &&
- nla_put_s32(skb, NDA_NDM_IFINDEX_NETNSID,
- peernet2id(vxlan->net, dev_net(vxlan->dev))))
+ nla_put_s32(skb, NDA_LINK_NETNSID,
+ peernet2id(dev_net(vxlan->dev), vxlan->net)))
goto nla_put_failure;
if (send_eth && nla_put(skb, NDA_LLADDR, ETH_ALEN, &fdb->eth_addr))
@@ -384,6 +384,7 @@ static inline size_t vxlan_nlmsg_size(void)
+ nla_total_size(sizeof(__be16)) /* NDA_PORT */
+ nla_total_size(sizeof(__be32)) /* NDA_VNI */
+ nla_total_size(sizeof(__u32)) /* NDA_IFINDEX */
+ + nla_total_size(sizeof(__s32)) /* NDA_LINK_NETNSID */
+ nla_total_size(sizeof(struct nda_cacheinfo));
}
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index 38f236853cc0..3873a35509aa 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -25,7 +25,7 @@ enum {
NDA_VNI,
NDA_IFINDEX,
NDA_MASTER,
- NDA_NDM_IFINDEX_NETNSID,
+ NDA_LINK_NETNSID,
__NDA_MAX
};
--
2.2.2
^ permalink raw reply related
* Re: [PATCH 3/3] net: allwinner: sun4i-emac: fix emac SRAM mapping
From: Jens Kuske @ 2015-01-26 14:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Arnd Bergmann, Lee Jones, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20150125162510.GK8470@lukather>
Hi,
On 25/01/15 17:25, Maxime Ripard wrote:
> Hi Jens,
>
> On Sun, Jan 25, 2015 at 04:49:19PM +0100, Jens Kuske wrote:
>> The EMAC needs SRAM block A3_A4 being mapped to EMAC peripheral to
>> work. This is done by the bootloader most of the time, but U-Boot
>> Falcon Mode, for example, skips emac initialization and SRAM would
>> stay mapped to the CPU.
>
> Thanks for reviving this.
>
>> Signed-off-by: Jens Kuske <jenskuske-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/net/ethernet/allwinner/Kconfig | 1 +
>> drivers/net/ethernet/allwinner/sun4i-emac.c | 18 ++++++++++++++++++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/allwinner/Kconfig b/drivers/net/ethernet/allwinner/Kconfig
>> index d8d95d4..508a288 100644
>> --- a/drivers/net/ethernet/allwinner/Kconfig
>> +++ b/drivers/net/ethernet/allwinner/Kconfig
>> @@ -28,6 +28,7 @@ config SUN4I_EMAC
>> select MII
>> select PHYLIB
>> select MDIO_SUN4I
>> + select MFD_SYSCON
>> ---help---
>> Support for Allwinner A10 EMAC ethernet driver.
>>
>> diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
>> index 1fcd556..86c891d 100644
>> --- a/drivers/net/ethernet/allwinner/sun4i-emac.c
>> +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
>> @@ -18,6 +18,8 @@
>> #include <linux/gpio.h>
>> #include <linux/interrupt.h>
>> #include <linux/irq.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/mfd/syscon/sun4i-sc.h>
>> #include <linux/mii.h>
>> #include <linux/module.h>
>> #include <linux/netdevice.h>
>> @@ -28,6 +30,7 @@
>> #include <linux/of_platform.h>
>> #include <linux/platform_device.h>
>> #include <linux/phy.h>
>> +#include <linux/regmap.h>
>>
>> #include "sun4i-emac.h"
>>
>> @@ -78,6 +81,7 @@ struct emac_board_info {
>>
>> struct phy_device *phy_dev;
>> struct device_node *phy_node;
>> + struct regmap *sc;
>> unsigned int link;
>> unsigned int speed;
>> unsigned int duplex;
>> @@ -862,6 +866,18 @@ static int emac_probe(struct platform_device *pdev)
>> goto out;
>> }
>>
>> + /* Map SRAM_A3_A4 to EMAC */
>> + db->sc = syscon_regmap_lookup_by_compatible(
>> + "allwinner,sun4i-a10-syscon");
>> + if (IS_ERR(db->sc)) {
>> + dev_err(&pdev->dev, "failed to find syscon regmap\n");
>> + ret = PTR_ERR(db->sc);
>> + goto out;
>> + }
>> +
>> + regmap_update_bits(db->sc, SUN4I_SC1, SUN4I_SC1_SRAM_A3_A4_MAP_MASK,
>> + SUN4I_SC1_SRAM_A3_A4_MAP_EMAC);
>> +
>
> I don't think that using a syscon is the right solution here.
>
> All this SRAM mapping thing is mutually exclusive, and will possibly
> impact other drivers as well.
Each single SRAM area can only be mapped to a single peripheral, so as
long as the driver only changes bits related to his own area nothing can
go wrong I believe.
SRAM_C2 looks like it can be mapped do different devices (AE, CE, ACE),
but as far as I understand this, they are all related to the ACE device,
sharing a common register space, and would have to be handled by a
single driver anyway (if that will ever happen without docs)
https://linux-sunxi.org/ACE_Register_guide
> I think this is a more a case for a small driver in drivers/soc that
> would take care of this, and make sure that client drivers don't step
> on each other's toe.
I'm not convinced this is necessary, but what would this driver do
different than a basic regmap? Check if the area is already mapped by
any driver and deny mapping it again by a different driver? Which
different driver, each area is only interesting for a single
device/driver? Except maybe mapping it to CPU as general purpose sram,
but that would need some direct agreement with the driver to steal its
memory anyway.
Jens
^ permalink raw reply
* [PATCH 0/3] Restore UFO support to virtio_net devices
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Oct 30 18:27:12 2014 +0000
drivers/net: Disable UFO through virtio
Turned off UFO support to virtio-net based devices due to issues
with IPv6 fragment id generation for UFO packets. The issue
was that IPv6 UFO/GSO implementation expects the fragment id
to be supplied in skb_shinfo(). However, for packets generated
by the VMs, the fragment id is not supplied which causes all
IPv6 fragments to have the id of 0.
The problem is that turning off UFO support on tap/macvtap
as well as virtio devices caused issues with migrations.
Migrations would fail when moving a vm from a kernel supporting
expecting UFO to work to the newer kernels that disabled UFO.
This series provides a partial solution to address the migration
issue. The series reserves a bit in the skb and sets the bit
with the ipv6 fragment id has been generated for the packet.
UFO/GSO code then checks the bit to see if the fragment id
is already present or if a new fragment id needs to be generated.
This solution allows host-originated UFO packets to keep a
better randomized fragment id, as well as generating a randomized
id for VM generated traffic (solving the fragment id 0 issue).
Vladislav Yasevich (3):
ipv6: Select fragment id during UFO/GSO segmentation if not set.
Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
packets"
Revert "drivers/net: Disable UFO through virtio"
drivers/net/macvtap.c | 16 ++++++++--------
drivers/net/tun.c | 25 +++++++++----------------
drivers/net/virtio_net.c | 24 ++++++++++--------------
include/linux/skbuff.h | 3 ++-
include/net/ipv6.h | 2 ++
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/output_core.c | 9 ++++++++-
net/ipv6/udp_offload.c | 10 +++++++++-
8 files changed, 50 insertions(+), 43 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
If the IPv6 fragment id has not been set and we perform
fragmentation due to UFO, select a new fragment id.
When we store the fragment id into skb_shinfo, set the bit
in the skb so we can re-use the selected id.
This preserves the behavior of UFO packets generated on the
host and solves the issue of id generation for packet sockets
and tap/macvtap devices.
This patch moves ipv6_select_ident() back in to the header file.
It also provides the helper function that sets skb_shinfo() frag
id and sets the bit.
It also makes sure that we select the fragment id when doing
just gso validation, since it's possible for the packet to
come from an untrusted source (VM) and be forwarded through
a UFO enabled device which will expect the fragment id.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
include/linux/skbuff.h | 3 ++-
include/net/ipv6.h | 2 ++
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/output_core.c | 9 ++++++++-
net/ipv6/udp_offload.c | 10 +++++++++-
5 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 85ab7d7..3ad5203 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -605,7 +605,8 @@ struct sk_buff {
__u8 ipvs_property:1;
__u8 inner_protocol_type:1;
__u8 remcsum_offload:1;
- /* 3 or 5 bit hole */
+ __u8 ufo_fragid_set:1;
+ /* 2 or 4 bit hole */
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 4292929..ca6137b 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -671,7 +671,9 @@ static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_add
return __ipv6_addr_diff(a1, a2, sizeof(struct in6_addr));
}
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
void ipv6_proxy_select_ident(struct sk_buff *skb);
+void ipv6_skb_set_fragid(struct sk_buff *skb, __be32 frag_id);
int ip6_dst_hoplimit(struct dst_entry *dst);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ce69a12..b940b3f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -537,7 +537,7 @@ static void ip6_copy_metadata(struct sk_buff *to, struct sk_buff *from)
skb_copy_secmark(to, from);
}
-static void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
+void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt)
{
static u32 ip6_idents_hashrnd __read_mostly;
u32 hash, id;
@@ -1092,7 +1092,7 @@ static inline int ip6_ufo_append_data(struct sock *sk,
sizeof(struct frag_hdr)) & ~7;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
ipv6_select_ident(&fhdr, rt);
- skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
+ ipv6_skb_set_fragid(skb, fhdr.identification);
append:
return skb_append_datato_frags(sk, skb, getfrag, from,
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
index 97f41a3..68f879b 100644
--- a/net/ipv6/output_core.c
+++ b/net/ipv6/output_core.c
@@ -38,10 +38,17 @@ void ipv6_proxy_select_ident(struct sk_buff *skb)
hash = __ipv6_addr_jhash(&addrs[0], hash);
id = ip_idents_reserve(hash, 1);
- skb_shinfo(skb)->ip6_frag_id = htonl(id);
+ ipv6_skb_set_fragid(skb, htonl(id));
}
EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
+void ipv6_skb_set_fragid(struct sk_buff *skb, __be32 frag_id)
+{
+ skb_shinfo(skb)->ip6_frag_id = frag_id;
+ skb->ufo_fragid_set = 1;
+}
+EXPORT_SYMBOL_GPL(ipv6_skb_set_fragid);
+
int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
{
u16 offset = sizeof(struct ipv6hdr);
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index b6aa8ed..7cda88d 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -52,6 +52,10 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss);
+ /* Set the IPv6 fragment id if not set yet */
+ if (!skb->ufo_fragid_set)
+ ipv6_proxy_select_ident(skb);
+
segs = NULL;
goto out;
}
@@ -108,7 +112,11 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
fptr->nexthdr = nexthdr;
fptr->reserved = 0;
- fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ if (!skb->ufo_fragid_set)
+ fptr->identification = skb_shinfo(skb)->ip6_frag_id;
+ else
+ ipv6_select_ident(fptr,
+ (struct rt6_info *)skb_dst(skb));
/* Fragment the skb. ipv6 header and the remaining fields of the
* fragment header are updated in ipv6_gso_segment()
--
1.9.3
^ permalink raw reply related
* [PATCH 3/3] Revert "drivers/net: Disable UFO through virtio"
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: edumazet, mst, ben, virtualization
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4.
Now that UFO functionality can correctly track the fragment
id has been selected and select a fragment id if necessary,
we can re-enable UFO on tap/macvap and virtio devices.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 13 ++++++++-----
drivers/net/tun.c | 19 ++++++++-----------
drivers/net/virtio_net.c | 24 ++++++++++--------------
3 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0b86e46..919f4fc 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -80,7 +80,7 @@ static struct cdev macvtap_cdev;
static const struct proto_ops macvtap_socket_ops;
#define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
- NETIF_F_TSO6)
+ NETIF_F_TSO6 | NETIF_F_UFO)
#define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
@@ -585,8 +585,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
- current->comm);
gso_type = SKB_GSO_UDP;
break;
default:
@@ -633,6 +631,8 @@ static void macvtap_skb_to_vnet_hdr(struct macvtap_queue *q,
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ vnet_hdr->gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (sinfo->gso_type & SKB_GSO_TCP_ECN)
@@ -962,6 +962,9 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
if (arg & TUN_F_TSO6)
feature_mask |= NETIF_F_TSO6;
}
+
+ if (arg & TUN_F_UFO)
+ feature_mask |= NETIF_F_UFO;
}
/* tun/tap driver inverts the usage for TSO offloads, where
@@ -972,7 +975,7 @@ static int set_offload(struct macvtap_queue *q, unsigned long arg)
* When user space turns off TSO, we turn off GSO/LRO so that
* user-space will not receive TSO frames.
*/
- if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6))
+ if (feature_mask & (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_UFO))
features |= RX_OFFLOADS;
else
features &= ~RX_OFFLOADS;
@@ -1087,7 +1090,7 @@ static long macvtap_ioctl(struct file *file, unsigned int cmd,
case TUNSETOFFLOAD:
/* let the user check for future flags */
if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
- TUN_F_TSO_ECN))
+ TUN_F_TSO_ECN | TUN_F_UFO))
return -EINVAL;
rtnl_lock();
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 5ca42b7..10f9e40 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -186,7 +186,7 @@ struct tun_struct {
struct net_device *dev;
netdev_features_t set_features;
#define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
- NETIF_F_TSO6)
+ NETIF_F_TSO6|NETIF_F_UFO)
int vnet_hdr_sz;
int sndbuf;
@@ -1176,18 +1176,8 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(tun->dev,
- "%s: using disabled UFO feature; please fix this program\n",
- current->comm);
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
default:
tun->dev->stats.rx_frame_errors++;
kfree_skb(skb);
@@ -1294,6 +1284,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (sinfo->gso_type & SKB_GSO_TCPV6)
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (sinfo->gso_type & SKB_GSO_UDP)
+ gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else {
pr_err("unexpected GSO type: "
"0x%x, gso_size %d, hdr_len %d\n",
@@ -1742,6 +1734,11 @@ static int set_offload(struct tun_struct *tun, unsigned long arg)
features |= NETIF_F_TSO6;
arg &= ~(TUN_F_TSO4|TUN_F_TSO6);
}
+
+ if (arg & TUN_F_UFO) {
+ features |= NETIF_F_UFO;
+ arg &= ~TUN_F_UFO;
+ }
}
/* This gives the user a way to test for new features in future by
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5ca9771..059fdf1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -490,17 +490,8 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_UDP:
- {
- static bool warned;
-
- if (!warned) {
- warned = true;
- netdev_warn(dev,
- "host using disabled UFO feature; please fix it\n");
- }
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
break;
- }
case VIRTIO_NET_HDR_GSO_TCPV6:
skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
break;
@@ -888,6 +879,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
+ else if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_UDP;
else
BUG();
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCP_ECN)
@@ -1748,7 +1741,7 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
- dev->hw_features |= NETIF_F_TSO
+ dev->hw_features |= NETIF_F_TSO | NETIF_F_UFO
| NETIF_F_TSO_ECN | NETIF_F_TSO6;
}
/* Individual feature bits: what can host handle? */
@@ -1758,9 +1751,11 @@ static int virtnet_probe(struct virtio_device *vdev)
dev->hw_features |= NETIF_F_TSO6;
if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_ECN))
dev->hw_features |= NETIF_F_TSO_ECN;
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UFO))
+ dev->hw_features |= NETIF_F_UFO;
if (gso)
- dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
+ dev->features |= dev->hw_features & (NETIF_F_ALL_TSO|NETIF_F_UFO);
/* (!csum && gso) case will be fixed by register_netdev() */
}
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
@@ -1798,7 +1793,8 @@ static int virtnet_probe(struct virtio_device *vdev)
/* If we can receive ANY GSO packets, we must allocate large ones. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) ||
- virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN))
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN) ||
+ virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UFO))
vi->big_packets = true;
if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
@@ -1994,9 +1990,9 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_NET_F_CSUM, VIRTIO_NET_F_GUEST_CSUM,
VIRTIO_NET_F_GSO, VIRTIO_NET_F_MAC,
- VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_TSO6,
+ VIRTIO_NET_F_HOST_TSO4, VIRTIO_NET_F_HOST_UFO, VIRTIO_NET_F_HOST_TSO6,
VIRTIO_NET_F_HOST_ECN, VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_ECN,
+ VIRTIO_NET_F_GUEST_ECN, VIRTIO_NET_F_GUEST_UFO,
VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN,
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] net: macb: allow deffered probe of the driver
From: Nicolas Ferre @ 2015-01-26 14:37 UTC (permalink / raw)
To: Nicolae Rosia, netdev@vger.kernel.org
In-Reply-To: <1421947441.717.4.camel@uti.ro>
Le 22/01/2015 18:31, Nicolae Rosia a écrit :
> The driver is trying to acquire clocks which maybe
> are not available yet. Allow the driver to request
> deffered probe by providing a probe function and
> registering it with module_platform_driver. [1]
> This patch is based on 3.19-rc5.
Do you have a use case for this need?
> [1] https://lkml.org/lkml/2013/9/23/118
>
> Signed-off-by: Nicolae Rosia <nicolae.rosia@certsign.ro>
But anyway, it's not harmful:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index 3767271..4dfcd66 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2148,7 +2148,7 @@ static void macb_probe_queues(void __iomem *mem,
> (*num_queues)++;
> }
>
> -static int __init macb_probe(struct platform_device *pdev)
> +static int macb_probe(struct platform_device *pdev)
> {
> struct macb_platform_data *pdata;
> struct resource *regs;
> @@ -2386,7 +2386,7 @@ err_out:
> return err;
> }
>
> -static int __exit macb_remove(struct platform_device *pdev)
> +static int macb_remove(struct platform_device *pdev)
> {
> struct net_device *dev;
> struct macb *bp;
> @@ -2449,7 +2449,8 @@ static int macb_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
>
> static struct platform_driver macb_driver = {
> - .remove = __exit_p(macb_remove),
> + .probe = macb_probe,
> + .remove = macb_remove,
> .driver = {
> .name = "macb",
> .of_match_table = of_match_ptr(macb_dt_ids),
> @@ -2457,7 +2458,7 @@ static struct platform_driver macb_driver = {
> },
> };
>
> -module_platform_driver_probe(macb_driver, macb_probe);
> +module_platform_driver(macb_driver);
>
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/3] Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets"
From: Vladislav Yasevich @ 2015-01-26 14:37 UTC (permalink / raw)
To: netdev; +Cc: virtualization, mst, ben, edumazet, Vladislav Yasevich
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
This reverts commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7.
Now that GSO layer can track if fragment id has been selected
and can allocate on if necessary, we don't need to do this in
tap and macvtap. This reverts most of the code and only keeps
the new ipv6 fragment id generation function that is still needed.
It also solves this issues for packet sockets which were
missed before.
Fixes: 3d0ad09412ff (drivers/net: Disable UFO through virtio)
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
drivers/net/macvtap.c | 3 ---
drivers/net/tun.c | 6 +-----
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7df2217..0b86e46 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -17,7 +17,6 @@
#include <linux/fs.h>
#include <linux/uio.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/rtnetlink.h>
#include <net/sock.h>
@@ -589,8 +588,6 @@ static int macvtap_skb_from_vnet_hdr(struct macvtap_queue *q,
pr_warn_once("macvtap: %s: using disabled UFO feature; please fix this program\n",
current->comm);
gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
default:
return -EINVAL;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..5ca42b7 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -65,7 +65,6 @@
#include <linux/nsproxy.h>
#include <linux/virtio_net.h>
#include <linux/rcupdate.h>
-#include <net/ipv6.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
@@ -1167,8 +1166,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- skb_reset_network_header(skb);
-
if (gso.gso_type != VIRTIO_NET_HDR_GSO_NONE) {
pr_debug("GSO!\n");
switch (gso.gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
@@ -1189,8 +1186,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
current->comm);
}
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
- if (skb->protocol == htons(ETH_P_IPV6))
- ipv6_proxy_select_ident(skb);
break;
}
default:
@@ -1221,6 +1216,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
}
+ skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
rxhash = skb_get_hash(skb);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Dan Williams @ 2015-01-26 15:03 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: David Miller, netdev, Vadim Kochan
In-Reply-To: <54C519B3.9050905@codeaurora.org>
On Sun, 2015-01-25 at 09:28 -0700, Harout Hedeshian wrote:
> On 01/25/2015 12:21 AM, Vadim Kochan wrote:
> > On Sat, Jan 24, 2015 at 11:14:32PM -0800, David Miller wrote:
> >> From: Harout Hedeshian <harouth@codeaurora.org>
> >> Date: Tue, 20 Jan 2015 10:06:05 -0700
> >>
> >>> The kernel forcefully applies MTU values received in router
> >>> advertisements provided the new MTU is less than the current. This
> >>> behavior is undesirable when the user space is managing the MTU.
> > Instead
> >>> a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> >>> can control whether or not RA provided MTU updates should be applied.
> > The
> >>> default behavior is unchanged; user space must explicitly set this
> > flag
> >>> to 0 for RA MTUs to be ignored.
> >>>
> >>> Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
> >> Under what circumstances would userland ignore a router advertized
> >> MTU, and are the RFCs ok with this?
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Hi,
> >
> > I don't know if it make sense but I had the same use case when was
> > working on supporting IPv6 infrastructure for home gateway.
> > One of the provider had requirements to have ability set force IPv6 MTU
> > value via TR parameters and disable update it via RA.
> Hi David,
>
> We are optionally allowing the kernel shift this responsibility to the
> userland. The idea would be that the kernel would ignore it, not so much
> the userland. Just like Vadim, we may not want to use the MTU value
> which comes from the network. Instead, we get an MTU value from the
> cellular modem via configuration message, and that is the MTU we use.
Are you talking about an ethernet interface exposed by the modem, or a
separate network interface connected to a normal LAN? In the modem
case, why would the network-provided RA's MTU be incorrect, but the
modem's MTU be correct? If the normal LAN case, why would the modem's
MTU be correct for a different network that is broadcasting its own RAs?
Just curious...
Dan
> In any case, none of the RFCs state that the kernel must update the MTU
> and that the userland cannot. In fact, there is no mention of
> kernel/user space at all in the RFC for this particular RA message. What
> if someone wants to listen to these RA messages from userland and update
> the MTU? Surely, that won't violate the RFC. In such a case, the kernel
> is unnecessarily forcing policy on the user space.
>
> RFC4861 section 4.6.4 defines the MTU update option (RA option 5) for RA
> messages. I don't see any language where the receiver "MUST" apply this
> option. It merely states that the MTU value in the RA is "The
> recommended MTU for the link." The description goes on to point out why
> this option can be used by the router, but does not specifically enforce
> it. The only receive action specifically enforced by the RFC is that
> "This option MUST be silently ignored for other Neighbor Discovery
> messages."
>
> The risk of not applying the MTU updates is that packet may get dropped
> if path MTU discovery is disabled or broken on the network. HOWEVER,
> anyone explicitly setting accept_ra_mtu to 0 is already taking
> responsibility for enforcing the correct MTU. Since this patch by
> default does not change the kernel behavior, I don't see it breaking for
> users who are unaware of this option.
>
>
> Thanks,
> Harout
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: macb: allow deffered probe of the driver
From: Nicolae Rosia @ 2015-01-26 15:21 UTC (permalink / raw)
To: nicolas.ferre@atmel.com; +Cc: netdev@vger.kernel.org, michal.simek@xilinx.com
In-Reply-To: <54C6510C.8050002@atmel.com>
On Mon, 2015-01-26 at 15:37 +0100, Nicolas Ferre wrote:
> Do you have a use case for this need?
On my setup (Zynq Platform), the required clocks are
provided by a module which is loaded after this driver,
hence, the clock is not available at initialization time.
> But anyway, it's not harmful:
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thank you.
Best regards,
Nicolae Rosia
^ permalink raw reply
* Re: [PATCH 0/3] Restore UFO support to virtio_net devices
From: Michael S. Tsirkin @ 2015-01-26 15:28 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, virtualization, ben, edumazet, Vladislav Yasevich,
David Miller
In-Reply-To: <1422283026-27832-1-git-send-email-vyasevic@redhat.com>
On Mon, Jan 26, 2015 at 09:37:03AM -0500, Vladislav Yasevich wrote:
> commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date: Thu Oct 30 18:27:12 2014 +0000
>
> drivers/net: Disable UFO through virtio
>
> Turned off UFO support to virtio-net based devices due to issues
> with IPv6 fragment id generation for UFO packets. The issue
> was that IPv6 UFO/GSO implementation expects the fragment id
> to be supplied in skb_shinfo(). However, for packets generated
> by the VMs, the fragment id is not supplied which causes all
> IPv6 fragments to have the id of 0.
>
> The problem is that turning off UFO support on tap/macvtap
> as well as virtio devices caused issues with migrations.
> Migrations would fail when moving a vm from a kernel supporting
> expecting UFO to work to the newer kernels that disabled UFO.
>
> This series provides a partial solution to address the migration
> issue. The series reserves a bit in the skb and sets the bit
> with the ipv6 fragment id has been generated for the packet.
> UFO/GSO code then checks the bit to see if the fragment id
> is already present or if a new fragment id needs to be generated.
> This solution allows host-originated UFO packets to keep a
> better randomized fragment id, as well as generating a randomized
> id for VM generated traffic (solving the fragment id 0 issue).
>
> Vladislav Yasevich (3):
> ipv6: Select fragment id during UFO/GSO segmentation if not set.
> Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
> packets"
> Revert "drivers/net: Disable UFO through virtio"
>
> drivers/net/macvtap.c | 16 ++++++++--------
> drivers/net/tun.c | 25 +++++++++----------------
> drivers/net/virtio_net.c | 24 ++++++++++--------------
> include/linux/skbuff.h | 3 ++-
> include/net/ipv6.h | 2 ++
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/output_core.c | 9 ++++++++-
> net/ipv6/udp_offload.c | 10 +++++++++-
> 8 files changed, 50 insertions(+), 43 deletions(-)
Should also help a lot to put UDP performance where it was.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> --
> 1.9.3
^ permalink raw reply
* Re: [PATCH 0/3] Restore UFO support to virtio_net devices
From: Michael S. Tsirkin @ 2015-01-26 15:32 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: netdev, virtualization, edumazet, ben, David Miller
In-Reply-To: <20150126152842.GA5130@redhat.com>
On Mon, Jan 26, 2015 at 05:28:42PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 26, 2015 at 09:37:03AM -0500, Vladislav Yasevich wrote:
> > commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4
> > Author: Ben Hutchings <ben@decadent.org.uk>
> > Date: Thu Oct 30 18:27:12 2014 +0000
> >
> > drivers/net: Disable UFO through virtio
> >
> > Turned off UFO support to virtio-net based devices due to issues
> > with IPv6 fragment id generation for UFO packets. The issue
> > was that IPv6 UFO/GSO implementation expects the fragment id
> > to be supplied in skb_shinfo(). However, for packets generated
> > by the VMs, the fragment id is not supplied which causes all
> > IPv6 fragments to have the id of 0.
> >
> > The problem is that turning off UFO support on tap/macvtap
> > as well as virtio devices caused issues with migrations.
> > Migrations would fail when moving a vm from a kernel supporting
> > expecting UFO to work to the newer kernels that disabled UFO.
> >
> > This series provides a partial solution to address the migration
> > issue. The series reserves a bit in the skb and sets the bit
> > with the ipv6 fragment id has been generated for the packet.
> > UFO/GSO code then checks the bit to see if the fragment id
> > is already present or if a new fragment id needs to be generated.
> > This solution allows host-originated UFO packets to keep a
> > better randomized fragment id, as well as generating a randomized
> > id for VM generated traffic (solving the fragment id 0 issue).
> >
> > Vladislav Yasevich (3):
> > ipv6: Select fragment id during UFO/GSO segmentation if not set.
> > Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO
> > packets"
> > Revert "drivers/net: Disable UFO through virtio"
> >
> > drivers/net/macvtap.c | 16 ++++++++--------
> > drivers/net/tun.c | 25 +++++++++----------------
> > drivers/net/virtio_net.c | 24 ++++++++++--------------
> > include/linux/skbuff.h | 3 ++-
> > include/net/ipv6.h | 2 ++
> > net/ipv6/ip6_output.c | 4 ++--
> > net/ipv6/output_core.c | 9 ++++++++-
> > net/ipv6/udp_offload.c | 10 +++++++++-
> > 8 files changed, 50 insertions(+), 43 deletions(-)
>
> Should also help a lot to put UDP performance where it was.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
BTW these might also be a good stable candidate.
>
> > --
> > 1.9.3
^ permalink raw reply
* Re: [PATCH net] ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too
From: Lubomir Rintel @ 2015-01-26 15:36 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <131075b1c8770c414675094c292d394316e8cd17.1422281427.git.hannes@stressinduktion.org>
On Mon, 2015-01-26 at 15:11 +0100, Hannes Frederic Sowa wrote:
> Lubomir Rintel reported that during replacing a route the interface
> reference counter isn't correctly decremented.
>
> To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
> | [root@rhel7-5 lkundrak]# sh -x lal
> | + ip link add dev0 type dummy
> | + ip link set dev0 up
> | + ip link add dev1 type dummy
> | + ip link set dev1 up
> | + ip addr add 2001:db8:8086::2/64 dev dev0
> | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
> | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
> | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
> | + ip link del dev0 type dummy
> | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
> |
> | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
> | kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
>
> During replacement of a rt6_info we must walk all parent nodes and check
> if the to be replaced rt6_info got propagated. If so, replace it with
> an alive one.
>
> Reported-by: Lubomir Rintel <lkundrak@v3.sk>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> net/ipv6/ip6_fib.c | 45 ++++++++++++++++++++++++++-------------------
> 1 file changed, 26 insertions(+), 19 deletions(-)
Tested-by: Lubomir Rintel <lkundrak@v3.sk>
Thank you!
Lubo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox