* Re: [PATCH net-next v2 1/1] net: dsa: fix fixed-link port registration
From: Marek Behun @ 2019-08-11 16:21 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Andrew Lunn, netdev, Sebastian Reichel,
Vivien Didelot, Florian Fainelli, David S . Miller
In-Reply-To: <CA+h21hoOZQ79rj0SLZGLnkSjrKD3aLNos0GcnRjre-Ls=Tq=4w@mail.gmail.com>
On Sun, 11 Aug 2019 18:16:11 +0300
Vladimir Oltean <olteanv@gmail.com> wrote:
> The DSA fixed-link port functionality *has* been converted to phylink.
> See:
> - https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0e27921816ad9
> - https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=7fb5a711545d7d25fe9726a9ad277474dd83bd06
>
/o\ my bad. I did not realize that I was working on 5.2 :(. Sorry.
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:31 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arm-kernel, Fabio Estevam, netdev, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
Hi Russell
The timeout is quite short,
#define FEC_MII_TIMEOUT 30000 /* us */
Looking at the Vybrid datasheet, there does not appear to be any way
to determine if the hardware is busy other than waiting for the
interrupt. There is no 'busy' bit which gets cleared on completion.
So about the only option is to make the timeout bigger.
Andrew
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:44 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arm-kernel, Fabio Estevam, netdev, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
Hi Russell
At the bus level, MDIO cannot fail. The bits get clocked out, and the
bits get clocked in. There is no way for the PHY to stretch the clock
as I2C slaves can. There is nothing like the USB NACK, try again
later.
If something fails, it fails at a higher level, which means it is a
driver issue. In this case, the interrupt got delayed, after the timer
interrupt.
The FEC is also quite unusual in using an interrupt. Most MDIO drivers
poll. And if time gets 'stretched' because the system is too busy,
generally, the right thing happens anyway.
So i don't think it is phylib job to work around this issue.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: fix RGMII-ID port setup
From: Andrew Lunn @ 2019-08-11 16:51 UTC (permalink / raw)
To: Marek Behun
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811181445.71048d2c@nic.cz>
> what if we added a phy_mode member to struct mv88e6xxx_port, and either
> set it to PHY_INTERFACE_MODE_NA in mv88e6xxx_setup, or implemented
> methods for converting the switch register values to
> PHY_INTERFACE_MODE_* values.
We should read the switch registers. I think you can set the defaults
using strapping pins. And in general, the driver always reads state
from the hardware rather than caching it.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: fixed_phy: set is_gigabit_capable member when needed
From: Heiner Kallweit @ 2019-08-11 16:59 UTC (permalink / raw)
To: Marek Behun, Andrew Lunn
Cc: netdev, Sebastian Reichel, Vivien Didelot, Florian Fainelli,
David S . Miller
In-Reply-To: <20190811180815.024870da@nic.cz>
On 11.08.2019 18:08, Marek Behun wrote:
> On Sun, 11 Aug 2019 17:40:01 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>> On Sun, Aug 11, 2019 at 05:08:12PM +0200, Marek Behún wrote:
>>> The fixed_phy driver does not set the phydev->is_gigabit_capable member
>>> when the fixed_phy is gigabit capable.
>>
>> Neither does any other PHY driver. It should be possible to tell if a
>> PHY supports 1G by looking at register values. If this does not work
>> for fixed_link, it means we are missing something in the emulation.
>> That is what we should be fixing.
>>
>> Also, this change has nothing to do the lp_advertise, what you
>> previously said the problem was. At the moment, i don't get the
>> feeling you have really dug all the way down and really understand the
>> root causes.
>>
>> Andrew
>
> Andrew,
> is_gigabit_capable is otherwise set only in the phy_probe function.
> This function is not called at all for the DSA cpu port fixed_link phy.
> Why is that? But I guess it is not important anymore, if CPU and DSA
> were converted to phylink in net-next. I shall test it and let you know.
> In any case, sorry for the spam.
> Marek
>
A fixed phy should be bound to the genphy driver, but that happens later
in phy_attach_direct(). Maybe the fixed phy device of a CPU port gets
never attached to a net device? This would explain why phy_probe()
doesn't get called.
Following idea: We could swphy let return PHY ID 0xffffffff
(instead of current value 0x00000000). Then the fixed phy device would
be bound to the genphy driver immediately at device registration time.
As a consequence phy_probe() would call genphy_read_abilities() that
sets supported modes properly. This should allow to remove the manual
adding of supported modes in dsa_port_fixed_link_register_of().
One more thing regarding genphy_read_abilities() and fixed phys in general:
swphy sets bit BMSR_ESTATEN, then genphy_read_abilities() reads
MII_ESTATUS to check if and which 1Gbps modes are supported.
MII_ESTATUS however isn't defined in swphy. We're just fortunate
that therefore the default value 0xffff is returned and both
1Gbps modes seem to be supported.
Last but not least I think the calls to genphy_config_init() and
genphy_read_status() in dsa_port_fixed_link_register_of() are
both not needed and could be removed.
Heiner
^ permalink raw reply
* Re: [PATCH net v3] net: dsa: Check existence of .port_mdb_add callback before calling it
From: Vivien Didelot @ 2019-08-11 18:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Chen-Yu Tsai,
netdev, linux-kernel
In-Reply-To: <20190811141825.11566-1-wens@kernel.org>
Hi Chen-Yu,
On Sun, 11 Aug 2019 22:18:25 +0800, Chen-Yu Tsai <wens@kernel.org> wrote:
> From: Chen-Yu Tsai <wens@csie.org>
>
> The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
> for drivers to handle multicast database entries. When adding an entry, the
> framework goes through a prepare phase, then a commit phase. Drivers not
> providing these callbacks should be detected in the prepare phase.
>
> DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
> function directly with no prepare phase or no switchdev trans object,
> and the framework ends up calling an undefined .port_mdb_add callback.
> This results in a NULL pointer dereference, as shown in the log below.
>
> The other functions seem to be properly guarded. Do the same for
> .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
>
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = (ptrval)
> [00000000] *pgd=00000000
> Internal error: Oops: 80000005 [#1] SMP ARM
> Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211
> CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a #1
> Hardware name: Allwinner sun7i (A20) Family
> Workqueue: events switchdev_deferred_process_work
> PC is at 0x0
> LR is at dsa_switch_event+0x570/0x620
> pc : [<00000000>] lr : [<c08533ec>] psr: 80070013
> sp : ee871db8 ip : 00000000 fp : ee98d0a4
> r10: 0000000c r9 : 00000008 r8 : ee89f710
> r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
> r3 : 00000000 r2 : ee89f710 r1 : 00000008 r0 : ee98d040
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 6deb406a DAC: 00000051
> Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
> Stack: (0xee871db8 to 0xee872000)
> 1da0: ee871e14 103ace2d
> 1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
> 1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
> 1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
> 1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
> 1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
> 1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
> 1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
> 1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
> 1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
> 1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
> 1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
> 1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
> 1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
> 1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
> 1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
> 1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> [<c014bdfc>] (notifier_call_chain) from [<c014bef0>] (raw_notifier_call_chain+0x18/0x20)
> [<c014bef0>] (raw_notifier_call_chain) from [<c08509a8>] (dsa_port_mdb_add+0x48/0x74)
> [<c08509a8>] (dsa_port_mdb_add) from [<c087e248>] (__switchdev_handle_port_obj_add+0x54/0xd4)
> [<c087e248>] (__switchdev_handle_port_obj_add) from [<c087e2d0>] (switchdev_handle_port_obj_add+0x8/0x14)
> [<c087e2d0>] (switchdev_handle_port_obj_add) from [<c08523c4>] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
> [<c08523c4>] (dsa_slave_switchdev_blocking_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> [<c014bdfc>] (notifier_call_chain) from [<c014c500>] (blocking_notifier_call_chain+0x50/0x68)
> [<c014c500>] (blocking_notifier_call_chain) from [<c087dfb4>] (switchdev_port_obj_notify+0x44/0xa8)
> [<c087dfb4>] (switchdev_port_obj_notify) from [<c087e0a8>] (switchdev_port_obj_add_now+0x90/0x104)
> [<c087e0a8>] (switchdev_port_obj_add_now) from [<c087e130>] (switchdev_port_obj_add_deferred+0x14/0x5c)
> [<c087e130>] (switchdev_port_obj_add_deferred) from [<c087de4c>] (switchdev_deferred_process+0x64/0x104)
> [<c087de4c>] (switchdev_deferred_process) from [<c087def8>] (switchdev_deferred_process_work+0xc/0x14)
> [<c087def8>] (switchdev_deferred_process_work) from [<c01447dc>] (process_one_work+0x218/0x50c)
> [<c01447dc>] (process_one_work) from [<c0145b84>] (worker_thread+0x44/0x5bc)
> [<c0145b84>] (worker_thread) from [<c014a6f8>] (kthread+0x148/0x150)
> [<c014a6f8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xee871fb0 to 0xee871ff8)
> 1fa0: 00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: bad PC value
> ---[ end trace 1292c61abd17b130 ]---
>
> [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> corresponds to
>
> $ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
>
> linux/net/dsa/switch.c:156
> linux/net/dsa/switch.c:178
> linux/net/dsa/switch.c:328
>
> Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Thanks for your patience,
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] drop_monitor: Capture dropped packets and metadata
From: David Miller @ 2019-08-11 18:57 UTC (permalink / raw)
To: idosch
Cc: netdev, nhorman, jiri, toke, dsahern, roopa, nikolay,
jakub.kicinski, andy, f.fainelli, andrew, vivien.didelot, mlxsw,
idosch
In-Reply-To: <20190811073555.27068-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 11 Aug 2019 10:35:45 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> So far drop monitor supported only one mode of operation in which a
> summary of recent packet drops is periodically sent to user space as a
> netlink event. The event only includes the drop location (program
> counter) and number of drops in the last interval.
>
> While this mode of operation allows one to understand if the system is
> dropping packets, it is not sufficient if a more detailed analysis is
> required. Both the packet itself and related metadata are missing.
>
> This patchset extends drop monitor with another mode of operation where
> the packet - potentially truncated - and metadata (e.g., drop location,
> timestamp, netdev) are sent to user space as a netlink event. Thanks to
> the extensible nature of netlink, more metadata can be added in the
> future.
...
Series applied.
^ permalink raw reply
* pull-request: bpf 2019-08-11
From: Daniel Borkmann @ 2019-08-11 19:58 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev, bpf
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) x64 JIT code generation fix for backward-jumps to 1st insn, from Alexei.
2) Fix buggy multi-closing of BTF file descriptor in libbpf, from Andrii.
3) Fix libbpf_num_possible_cpus() to make it thread safe, from Takshak.
4) Fix bpftool to dump an error if pinning fails, from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 0a062ba725cdad3b167782179ee914a8402a0184:
Merge tag 'mlx5-fixes-2019-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2019-07-26 14:26:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 4f7aafd78aeaf18a4f6dea9415df60e745c9dfa7:
Merge branch 'bpf-bpftool-pinning-error-msg' (2019-08-09 17:38:53 +0200)
----------------------------------------------------------------
Alexei Starovoitov (2):
bpf: fix x64 JIT code generation for jmp to 1st insn
selftests/bpf: tests for jmp to 1st insn
Andrii Nakryiko (2):
libbpf: fix erroneous multi-closing of BTF FD
libbpf: set BTF FD for prog only when there is supported .BTF.ext data
Daniel Borkmann (1):
Merge branch 'bpf-bpftool-pinning-error-msg'
Jakub Kicinski (2):
tools: bpftool: fix error message (prog -> object)
tools: bpftool: add error message on pin failure
Takshak Chahande (1):
libbpf : make libbpf_num_possible_cpus function thread safe
arch/x86/net/bpf_jit_comp.c | 9 ++++----
tools/bpf/bpftool/common.c | 8 +++++--
tools/lib/bpf/libbpf.c | 33 +++++++++++++++------------
tools/testing/selftests/bpf/verifier/loops1.c | 28 +++++++++++++++++++++++
4 files changed, 57 insertions(+), 21 deletions(-)
^ permalink raw reply
* [PATCH] net: ixgbe: fix memory leaks
From: Wenwen Wang @ 2019-08-11 20:07 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list
In ixgbe_configure_clsu32(), 'jump', 'input', and 'mask' are allocated
through kzalloc() respectively in a for loop body. Then,
ixgbe_clsu32_build_input() is invoked to build the input. If this process
fails, next iteration of the for loop will be executed. However, the
allocated 'jump', 'input', and 'mask' are not deallocated on this execution
path, leading to memory leaks.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712..6b7ea87 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9490,6 +9490,10 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
jump->mat = nexthdr[i].jump;
adapter->jump_tables[link_uhtid] = jump;
break;
+ } else {
+ kfree(mask);
+ kfree(input);
+ kfree(jump);
}
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v3] tipc: initialise addr_trail_end when setting node addresses
From: Chris Packham @ 2019-08-11 20:18 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, Chris Packham
We set the field 'addr_trial_end' to 'jiffies', instead of the current
value 0, at the moment the node address is initialized. This guarantees
we don't inadvertently enter an address trial period when the node
address is explicitly set by the user.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
---
Notes:
Changes in v3:
- Reword commit message as suggested
- Include acl from Jon
Changes in v2:
- move setting to tipc_set_node_addr() as suggested
- reword commit message
net/tipc/addr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/addr.c b/net/tipc/addr.c
index b88d48d00913..0f1eaed1bd1b 100644
--- a/net/tipc/addr.c
+++ b/net/tipc/addr.c
@@ -75,6 +75,7 @@ void tipc_set_node_addr(struct net *net, u32 addr)
tipc_set_node_id(net, node_id);
}
tn->trial_addr = addr;
+ tn->addr_trial_end = jiffies;
pr_info("32-bit node address hash set to %x\n", addr);
}
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] net: ixgbe: fix memory leaks
From: Alexander Duyck @ 2019-08-11 20:22 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list, Amritha Nambiar
In-Reply-To: <1565554067-4994-1-git-send-email-wenwen@cs.uga.edu>
On Sun, Aug 11, 2019 at 1:08 PM Wenwen Wang <wenwen@cs.uga.edu> wrote:
>
> In ixgbe_configure_clsu32(), 'jump', 'input', and 'mask' are allocated
> through kzalloc() respectively in a for loop body. Then,
> ixgbe_clsu32_build_input() is invoked to build the input. If this process
> fails, next iteration of the for loop will be executed. However, the
> allocated 'jump', 'input', and 'mask' are not deallocated on this execution
> path, leading to memory leaks.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index cbaf712..6b7ea87 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9490,6 +9490,10 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
> jump->mat = nexthdr[i].jump;
> adapter->jump_tables[link_uhtid] = jump;
> break;
> + } else {
> + kfree(mask);
> + kfree(input);
> + kfree(jump);
> }
> }
> return 0;
So I think this fix is still missing a good chunk of the exception
handling it should have. Specifically we will end up failing and then
trying to allocate for the next rule. It seems like we should probably
stop trying to program rules and unwind the work we have already done.
Also it would probably make sense to return an error if we are unable
to program one of the rules into the hardware. Otherwise things will
fail and the user will never know why.
^ permalink raw reply
* Re: [PATCH] dpaa2-ethsw: move the DPAA2 Ethernet Switch driver out of staging
From: Ioana Ciornei @ 2019-08-11 21:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem@davemloft.net, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
f.fainelli@gmail.com, Ioana Ciocoi Radulescu
In-Reply-To: <20190811032235.GK30120@lunn.ch>
On 8/11/19 6:22 AM, Andrew Lunn wrote:
> Hi Ioana
>
>> >> + struct ethsw_port_priv *port_priv = netdev_priv(netdev);
>> >> + struct ethsw_core *ethsw = port_priv->ethsw_data;
>> >> + int i, err;
>> >> +
>> >> + for (i = 0; i < ethsw->sw_attr.num_ifs; i++)
>> >> + if (ethsw->ports[i]->bridge_dev &&
>> >> + (ethsw->ports[i]->bridge_dev != upper_dev)) {
>> >> + netdev_err(netdev,
>> >> + "Another switch port is connected to %s\n",
>> >> + ethsw->ports[i]->bridge_dev->name);
>> >> + return -EINVAL;
>> >> + }
>> >
>> > Am i reading this correct? You only support a single bridge? The
>> > error message is not very informative. Also, i think you should be
>> > returning EOPNOTSUPP, indicating the offload is not possible. Linux
>> > will then do it in software. If it could actually receive/transmit the
>> > frames....
>> >
>>
>> Yes, we only support a single bridge.
>
> That is a pretty severe restriction for a device of this class. Some
> of the very simple switches DSA support have a similar restriction,
> but in general, most do support multiple bridges.
>
Let me make a distinction here: we do no support multiple bridges on the
same DPSW object but we do support multiple DPSW objects, each with its
bridge.
> Are there any plans to fix this?
>
We had some internal discussions on this, the hardware could support
this kind of further partitioning the switch object but, at the moment,
the firmware doesn't.
> Thanks
> Andrew
>
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-11 21:33 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
Hi all,
In commit
e1fea322fc6d ("net sched: update skbedit action for batched events operations")
Fixes tag
Fixes: ca9b0e27e ("pkt_action: add new action skbedit")
has these problem(s):
- SHA1 should be at least 12 digits long
This Can be fixed for the future by setting core.abbrev to 12 (or
more) or (for git v2.11 or later) just making sure it is not set
(or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: pull-request: bpf 2019-08-11
From: David Miller @ 2019-08-11 21:49 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, bpf
In-Reply-To: <20190811195834.3430-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 11 Aug 2019 21:58:34 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) x64 JIT code generation fix for backward-jumps to 1st insn, from Alexei.
>
> 2) Fix buggy multi-closing of BTF file descriptor in libbpf, from Andrii.
>
> 3) Fix libbpf_num_possible_cpus() to make it thread safe, from Takshak.
>
> 4) Fix bpftool to dump an error if pinning fails, from Jakub.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: Michal Kubecek @ 2019-08-11 22:10 UTC (permalink / raw)
To: netdev
Cc: Roopa Prabhu, Jiri Pirko, David Miller, Jakub Kicinski,
Stephen Hemminger, David Ahern, dcbw, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <CAJieiUi3n2kKGBVogHBJOd1q+fUjm8ik+xKvDTOxodnZjmH2WQ@mail.gmail.com>
On Sat, Aug 10, 2019 at 12:39:31PM -0700, Roopa Prabhu wrote:
> On Sat, Aug 10, 2019 at 8:50 AM Michal Kubecek <mkubecek@suse.cz> wrote:
> >
> > On Sat, Aug 10, 2019 at 06:46:57AM -0700, Roopa Prabhu wrote:
> > > On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek <mkubecek@suse.cz> wrote:
> > > >
> > > > On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > > > > to that point, I am also not sure why we have a new API For multiple
> > > > > names. I mean why support more than two names (existing old name and
> > > > > a new name to remove the length limitation) ?
> > > >
> > > > One use case is to allow "predictable names" from udev/systemd to work
> > > > the way do for e.g. block devices, see
> > > >
> > > > http://lkml.kernel.org/r/20190628162716.GF29149@unicorn.suse.cz
> > > >
> > >
> > > thanks for the link. don't know the details about alternate block
> > > device names. Does user-space generate multiple and assign them to a
> > > kernel object as proposed in this series ?. is there a limit to number
> > > of names ?. my understanding of 'predictable names' was still a single
> > > name but predictable structure to the name.
> >
> > It is a single name but IMHO mostly because we can only have one name.
> > For block devices, udev uses symlinks to create multiple aliases based
> > on different naming schemes, e.g.
> >
> > mike@lion:~> find -L /dev/disk/ -samefile /dev/sda2 -exec ls -l {} +
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-0ATA_WDC_WD30EFRX-68A_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-1ATA_WDC_WD30EFRX-68AX9N0_WD-WMC1T3114933-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/scsi-350014ee6589cfea0-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-id/wwn-0x50014ee6589cfea0-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-partlabel/root2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-partuuid/71affb47-a93b-40fd-8986-d2e227e1b39d -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-path/pci-0000:00:11.0-ata-1-part2 -> ../../sda2
> > lrwxrwxrwx 1 root root 10 srp 5 21:47 /dev/disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0-part2 -> ../../sda2
> >
> > Few years ago, udev even dropped support for renaming block and
> > character devices (NAME="...") so that it now keeps kernel name and only
> > creates symlinks to it. Recent versions only allow NAME="..." for
> > network devices.
>
> ok thanks for the details. This looks like names that are structured
> on hardware info which could fall into devlinks scope and they point
> to a single name.
> We should think about keeping them under devlink (by-id, by-mac etc).
> It already can recognize network interfaces by id.
Not all of them are hardware based, there are also links based on
filesystem label or UUID. But my point is rather that udev creates
multiple links so that any of them can be used in any place where
a block device is to be identified.
As network devices can have only one name, udev drops kernel provided
name completely and replaces it with name following one naming scheme.
Thus we have to know which naming scheme is going to be used and make
sure it does not change. With multiple alternative names, we could also
have all udev provided names at once (and also the original one from
kernel).
Michal
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/4] bpf: export bpf_map_inc_not_zero
From: Yonghong Song @ 2019-08-11 23:53 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-2-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Rename existing bpf_map_inc_not_zero to __bpf_map_inc_not_zero to
> indicate that it's caller's responsibility to do proper locking.
> Create and export bpf_map_inc_not_zero wrapper that properly
> locks map_idr_lock. Will be used in the next commit to
> hold a map while cloning a socket.
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/4] bpf: support cloning sk storage on accept()
From: Yonghong Song @ 2019-08-11 23:54 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-3-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Add new helper bpf_sk_storage_clone which optionally clones sk storage
> and call it from sk_clone_lock.
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next v2 4/4] selftests/bpf: add sockopt clone/inheritance test
From: Yonghong Song @ 2019-08-11 23:54 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
Martin Lau
In-Reply-To: <20190809161038.186678-5-sdf@google.com>
On 8/9/19 9:10 AM, Stanislav Fomichev wrote:
> Add a test that calls setsockopt on the listener socket which triggers
> BPF program. This BPF program writes to the sk storage and sets
> clone flag. Make sure that sk storage is cloned for a newly
> accepted connection.
>
> We have two cloned maps in the tests to make sure we hit both cases
> in bpf_sk_storage_clone: first element (sk_storage_alloc) and
> non-first element(s) (selem_link_map).
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* linux-next: manual merge of the afs tree with the net tree
From: Stephen Rothwell @ 2019-08-12 0:17 UTC (permalink / raw)
To: David Howells, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
Hi all,
Today's linux-next merge of the afs tree got conflicts in:
net/rxrpc/input.c
between commits:
730c5fd42c1e ("rxrpc: Fix local endpoint refcounting")
e8c3af6bb33a ("rxrpc: Don't bother generating maxSkew in the ACK packet")
from the net tree and commits:
5c2833938bf5 ("rxrpc: Fix local endpoint refcounting")
49bbdebb23f2 ("rxrpc: Don't bother generating maxSkew in the ACK packet")
from the afs tree.
I fixed it up (I just used the latter versions) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [v4,1/4] tools: bpftool: add net attach command to attach XDP on interface
From: Y Song @ 2019-08-12 0:26 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <20190809133248.19788-2-danieltimlee@gmail.com>
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee <danieltimlee@gmail.com> wrote:
>
> By this commit, using `bpftool net attach`, user can attach XDP prog on
> interface. New type of enum 'net_attach_type' has been made, as stated at
> cover-letter, the meaning of 'attach' is, prog will be attached on interface.
>
> With 'overwrite' option at argument, attached XDP program could be replaced.
> Added new helper 'net_parse_dev' to parse the network device at argument.
>
> BPF prog will be attached through libbpf 'bpf_set_link_xdp_fd'.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> tools/bpf/bpftool/net.c | 136 +++++++++++++++++++++++++++++++++++++---
> 1 file changed, 129 insertions(+), 7 deletions(-)
>
> diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> index 67e99c56bc88..74cc346c36cd 100644
> --- a/tools/bpf/bpftool/net.c
> +++ b/tools/bpf/bpftool/net.c
> @@ -55,6 +55,35 @@ struct bpf_attach_info {
> __u32 flow_dissector_id;
> };
>
> +enum net_attach_type {
> + NET_ATTACH_TYPE_XDP,
> + NET_ATTACH_TYPE_XDP_GENERIC,
> + NET_ATTACH_TYPE_XDP_DRIVER,
> + NET_ATTACH_TYPE_XDP_OFFLOAD,
> +};
> +
> +static const char * const attach_type_strings[] = {
> + [NET_ATTACH_TYPE_XDP] = "xdp",
> + [NET_ATTACH_TYPE_XDP_GENERIC] = "xdpgeneric",
> + [NET_ATTACH_TYPE_XDP_DRIVER] = "xdpdrv",
> + [NET_ATTACH_TYPE_XDP_OFFLOAD] = "xdpoffload",
> +};
> +
> +const size_t net_attach_type_size = ARRAY_SIZE(attach_type_strings);
> +
> +static enum net_attach_type parse_attach_type(const char *str)
> +{
> + enum net_attach_type type;
> +
> + for (type = 0; type < net_attach_type_size; type++) {
> + if (attach_type_strings[type] &&
> + is_prefix(str, attach_type_strings[type]))
> + return type;
> + }
> +
> + return net_attach_type_size;
> +}
> +
> static int dump_link_nlmsg(void *cookie, void *msg, struct nlattr **tb)
> {
> struct bpf_netdev_t *netinfo = cookie;
> @@ -223,6 +252,97 @@ static int query_flow_dissector(struct bpf_attach_info *attach_info)
> return 0;
> }
>
> +static int net_parse_dev(int *argc, char ***argv)
> +{
> + int ifindex;
> +
> + if (is_prefix(**argv, "dev")) {
> + NEXT_ARGP();
> +
> + ifindex = if_nametoindex(**argv);
> + if (!ifindex)
> + p_err("invalid devname %s", **argv);
> +
> + NEXT_ARGP();
> + } else {
> + p_err("expected 'dev', got: '%s'?", **argv);
> + return -1;
> + }
> +
> + return ifindex;
> +}
> +
> +static int do_attach_detach_xdp(int progfd, enum net_attach_type attach_type,
> + int ifindex, bool overwrite)
> +{
> + __u32 flags = 0;
> +
> + if (!overwrite)
> + flags = XDP_FLAGS_UPDATE_IF_NOEXIST;
> + if (attach_type == NET_ATTACH_TYPE_XDP_GENERIC)
> + flags |= XDP_FLAGS_SKB_MODE;
> + if (attach_type == NET_ATTACH_TYPE_XDP_DRIVER)
> + flags |= XDP_FLAGS_DRV_MODE;
> + if (attach_type == NET_ATTACH_TYPE_XDP_OFFLOAD)
> + flags |= XDP_FLAGS_HW_MODE;
> +
> + return bpf_set_link_xdp_fd(ifindex, progfd, flags);
> +}
> +
> +static int do_attach(int argc, char **argv)
> +{
> + enum net_attach_type attach_type;
> + int progfd, ifindex, err = 0;
> + bool overwrite = false;
> +
> + /* parse attach args */
> + if (!REQ_ARGS(5))
> + return -EINVAL;
> +
> + attach_type = parse_attach_type(*argv);
> + if (attach_type == net_attach_type_size) {
> + p_err("invalid net attach/detach type: %s", *argv);
> + return -EINVAL;
> + }
> + NEXT_ARG();
> +
> + progfd = prog_parse_fd(&argc, &argv);
> + if (progfd < 0)
> + return -EINVAL;
> +
> + ifindex = net_parse_dev(&argc, &argv);
> + if (ifindex < 1) {
> + close(progfd);
> + return -EINVAL;
> + }
> +
> + if (argc) {
> + if (is_prefix(*argv, "overwrite")) {
> + overwrite = true;
> + } else {
> + p_err("expected 'overwrite', got: '%s'?", *argv);
> + close(progfd);
> + return -EINVAL;
> + }
> + }
> +
> + /* attach xdp prog */
> + if (is_prefix("xdp", attach_type_strings[attach_type]))
> + err = do_attach_detach_xdp(progfd, attach_type, ifindex,
> + overwrite);
> +
> + if (err < 0) {
> + p_err("interface %s attach failed: %s",
> + attach_type_strings[attach_type], strerror(errno));
> + return err;
> + }
I tried the below example,
-bash-4.4$ sudo ./bpftool net attach x pinned /sys/fs/bpf/xdp_example
dev v1
-bash-4.4$ sudo ./bpftool net attach x pinned /sys/fs/bpf/xdp_example dev v1
Kernel error message: XDP program already attached
Error: interface xdp attach failed: Success
-bash-4.4$
It printed out "Success" as errno here is 0.
The errno is encoded in variable err. Function bpf_set_link_xdp_fd()
uses netlink interface to do setting. The syscall may be find (errno = 0)
but the netlink msg may contain error code, which is returned with err.
So the above strerror(errno) should be strerror(-err).
libbpf API libbpf_strerror_r() accepts positive or negative err code which
you could use as well here.
With this issue fixed. You can add:
Acked-by: Yonghong Song <yhs@fb.com>
> +
> + if (json_output)
> + jsonw_null(json_wtr);
> +
> + return 0;
> +}
> +
[...]
^ permalink raw reply
* Re: [v4,2/4] tools: bpftool: add net detach command to detach XDP on interface
From: Y Song @ 2019-08-12 0:29 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <20190809133248.19788-3-danieltimlee@gmail.com>
On Fri, Aug 9, 2019 at 6:35 AM Daniel T. Lee <danieltimlee@gmail.com> wrote:
>
> By this commit, using `bpftool net detach`, the attached XDP prog can
> be detached. Detaching the BPF prog will be done through libbpf
> 'bpf_set_link_xdp_fd' with the progfd set to -1.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
> ---
> tools/bpf/bpftool/net.c | 42 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> index 74cc346c36cd..ef1e576c6dba 100644
> --- a/tools/bpf/bpftool/net.c
> +++ b/tools/bpf/bpftool/net.c
> @@ -343,6 +343,43 @@ static int do_attach(int argc, char **argv)
> return 0;
> }
>
> +static int do_detach(int argc, char **argv)
> +{
> + enum net_attach_type attach_type;
> + int progfd, ifindex, err = 0;
> +
> + /* parse detach args */
> + if (!REQ_ARGS(3))
> + return -EINVAL;
> +
> + attach_type = parse_attach_type(*argv);
> + if (attach_type == net_attach_type_size) {
> + p_err("invalid net attach/detach type: %s", *argv);
> + return -EINVAL;
> + }
> + NEXT_ARG();
> +
> + ifindex = net_parse_dev(&argc, &argv);
> + if (ifindex < 1)
> + return -EINVAL;
> +
> + /* detach xdp prog */
> + progfd = -1;
> + if (is_prefix("xdp", attach_type_strings[attach_type]))
> + err = do_attach_detach_xdp(progfd, attach_type, ifindex, NULL);
> +
> + if (err < 0) {
> + p_err("interface %s detach failed: %s",
> + attach_type_strings[attach_type], strerror(errno));
> + return err;
> + }
Similar to previous patch, here we should use "strerror(-err)".
With this fixed, you can add my ack:
Acked-by: Yonghong Song <yhs@fb.com>
> +
> + if (json_output)
> + jsonw_null(json_wtr);
> +
> + return 0;
> +}
> +
[...]
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: David Ahern @ 2019-08-12 1:34 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, David Miller, Jakub Kicinski,
Stephen Hemminger, dcbw, Michal Kubecek, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <20190810063047.GC2344@nanopsycho.orion>
On 8/10/19 12:30 AM, Jiri Pirko wrote:
> Could you please write me an example message of add/remove?
altnames are for existing netdevs, yes? existing netdevs have an id and
a name - 2 existing references for identifying the existing netdev for
which an altname will be added. Even using the altname as the main
'handle' for a setlink change, I see no reason why the GETLINK api can
not take an the IFLA_ALT_IFNAME and return the full details of the
device if the altname is unique.
So, what do the new RTM commands give you that you can not do with
RTM_*LINK?
^ permalink raw reply
* Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
From: David Ahern @ 2019-08-12 1:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: Roopa Prabhu, netdev, David Miller, Jakub Kicinski,
Stephen Hemminger, dcbw, Michal Kubecek, Andrew Lunn, parav,
Saeed Mahameed, mlxsw
In-Reply-To: <b0a9ec0d-c00b-7aaf-46d4-c74d18498698@gmail.com>
On 8/11/19 7:34 PM, David Ahern wrote:
> On 8/10/19 12:30 AM, Jiri Pirko wrote:
>> Could you please write me an example message of add/remove?
>
> altnames are for existing netdevs, yes? existing netdevs have an id and
> a name - 2 existing references for identifying the existing netdev for
> which an altname will be added. Even using the altname as the main
> 'handle' for a setlink change, I see no reason why the GETLINK api can
> not take an the IFLA_ALT_IFNAME and return the full details of the
> device if the altname is unique.
>
> So, what do the new RTM commands give you that you can not do with
> RTM_*LINK?
>
To put this another way, the ALT_NAME is an attribute of an object - a
LINK. It is *not* a separate object which requires its own set of
commands for manipulating.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-08-12 2:21 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Huy Nguyen,
Vlad Buslov, Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
between commit:
93b3586e070b ("net/mlx5: Support inner header match criteria for non decap flow action")
from the net tree and commit:
226f2ca3075a ("net/mlx5e: Change flow flags type to unsigned long")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index deeb65da99f3,5be3da621499..000000000000
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@@ -1839,18 -2057,15 +2061,20 @@@ static int parse_cls_flower(struct mlx5
struct mlx5_core_dev *dev = priv->mdev;
struct mlx5_eswitch *esw = dev->priv.eswitch;
struct mlx5e_rep_priv *rpriv = priv->ppriv;
- u8 match_level, tunnel_match_level = MLX5_MATCH_NONE;
struct mlx5_eswitch_rep *rep;
+ bool is_eswitch_flow;
int err;
- err = __parse_cls_flower(priv, spec, f, filter_dev, &match_level, &tunnel_match_level);
+ inner_match_level = MLX5_MATCH_NONE;
+ outer_match_level = MLX5_MATCH_NONE;
+
+ err = __parse_cls_flower(priv, spec, f, filter_dev, &inner_match_level,
+ &outer_match_level);
+ non_tunnel_match_level = (inner_match_level == MLX5_MATCH_NONE) ?
+ outer_match_level : inner_match_level;
- if (!err && (flow->flags & MLX5E_TC_FLOW_ESWITCH)) {
+ is_eswitch_flow = mlx5e_is_eswitch_flow(flow);
+ if (!err && is_eswitch_flow) {
rep = rpriv->rep;
if (rep->vport != MLX5_VPORT_UPLINK &&
(esw->offloads.inline_mode != MLX5_INLINE_MODE_NONE &&
@@@ -1864,11 -2079,11 +2088,11 @@@
}
}
- if (flow->flags & MLX5E_TC_FLOW_ESWITCH) {
+ if (is_eswitch_flow) {
- flow->esw_attr->match_level = match_level;
- flow->esw_attr->tunnel_match_level = tunnel_match_level;
+ flow->esw_attr->inner_match_level = inner_match_level;
+ flow->esw_attr->outer_match_level = outer_match_level;
} else {
- flow->nic_attr->match_level = match_level;
+ flow->nic_attr->match_level = non_tunnel_match_level;
}
return err;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: Jason Wang @ 2019-08-12 2:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <20190810134948-mutt-send-email-mst@kernel.org>
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
>> Hi all:
>>
>> This series try to fix several issues introduced by meta data
>> accelreation series. Please review.
>>
>> Changes from V4:
>> - switch to use spinlock synchronize MMU notifier with accessors
>>
>> Changes from V3:
>> - remove the unnecessary patch
>>
>> Changes from V2:
>> - use seqlck helper to synchronize MMU notifier with vhost worker
>>
>> Changes from V1:
>> - try not use RCU to syncrhonize MMU notifier with vhost worker
>> - set dirty pages after no readers
>> - return -EAGAIN only when we find the range is overlapped with
>> metadata
>>
>> Jason Wang (9):
>> vhost: don't set uaddr for invalid address
>> vhost: validate MMU notifier registration
>> vhost: fix vhost map leak
>> vhost: reset invalidate_count in vhost_set_vring_num_addr()
>> vhost: mark dirty pages during map uninit
>> vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
>> vhost: do not use RCU to synchronize MMU notifier with worker
>> vhost: correctly set dirty pages in MMU notifiers callback
>> vhost: do not return -EAGAIN for non blocking invalidation too early
>>
>> drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
>> drivers/vhost/vhost.h | 6 +-
>> 2 files changed, 122 insertions(+), 86 deletions(-)
> This generally looks more solid.
>
> But this amounts to a significant overhaul of the code.
>
> At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
> for this release, and then re-apply a corrected version
> for the next one?
If possible, consider we've actually disabled the feature. How about
just queued those patches for next release?
Thanks
>
>> --
>> 2.18.1
^ 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