* [PATCH net v2] bonding/802.3ad: fix link_failure_count tracking
From: Jarod Wilson @ 2018-11-04 19:59 UTC (permalink / raw)
To: linux-kernel
Cc: Jarod Wilson, Mahesh Bandewar, David S . Miller, netdev, stable
In-Reply-To: <20181101212240.26768-1-jarod@redhat.com>
Commit 4d2c0cda07448ea6980f00102dc3964eb25e241c set slave->link to
BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
were read, to fix a problem with slaves getting into weird states, but
in the process, broke tracking of link failures, as going straight to
BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
!link_state was already true, we never incremented commit, and never got
a chance to call bond_miimon_commit(), where slave->link_failure_count
would be incremented. I believe the simple fix here is to mark the slave
as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
_FAIL to either _UP or _DOWN, and in the latter case, we now get proper
incrementing of link_failure_count again.
Fixes: 4d2c0cda0744 ("bonding: speed/duplex update at NETDEV_UP event")
CC: Mahesh Bandewar <maheshb@google.com>
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: stable@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
v2: fix Fixes line
drivers/net/bonding/bond_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ffa37adb7681..333387f1f1fe 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3112,13 +3112,13 @@ static int bond_slave_netdev_event(unsigned long event,
case NETDEV_CHANGE:
/* For 802.3ad mode only:
* Getting invalid Speed/Duplex values here will put slave
- * in weird state. So mark it as link-down for the time
+ * in weird state. So mark it as link-fail for the time
* being and let link-monitoring (miimon) set it right when
* correct speeds/duplex are available.
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD)
- slave->link = BOND_LINK_DOWN;
+ slave->link = BOND_LINK_FAIL;
if (BOND_MODE(bond) == BOND_MODE_8023AD)
bond_3ad_adapter_speed_duplex_changed(slave);
--
2.16.1
^ permalink raw reply related
* Re: [PATCH] bonding:avoid repeated display of same link status change
From: Michal Kubecek @ 2018-11-04 19:41 UTC (permalink / raw)
To: David Miller
Cc: mk.singh, netdev, eric.dumazet, j.vosburgh, vfalico, andy,
linux-kernel
In-Reply-To: <20181102.233138.738200505012734856.davem@davemloft.net>
On Fri, Nov 02, 2018 at 11:31:38PM -0700, David Miller wrote:
> From: mk.singh@oracle.com
> Date: Wed, 31 Oct 2018 16:27:28 +0530
>
> > - if (slave->delay) {
> > + if (slave->delay &&
> > + !atomic64_read(&bond->rtnl_needed)) {
> ...
> > + !atomic64_read(&bond->rtnl_needed)) {
> ...
> > + atomic64_set(&bond->rtnl_needed, 1);
> ...
> > + atomic64_set(&bond->rtnl_needed, 0);
> ...
> > @@ -229,6 +229,7 @@ struct bonding {
> > struct dentry *debug_dir;
> > #endif /* CONFIG_DEBUG_FS */
> > struct rtnl_link_stats64 bond_stats;
> > + atomic64_t rtnl_needed;
>
> There is nothing "atomic" about a value that is only set and read.
>
> And using a full 64-bit value for something taking on only '0' and
> '1' is unnecessary as well.
Part of the misunderstanding is caused by the fact that this is actually
a v4 but not marked as such:
v1: https://patchwork.ozlabs.org/patch/955789/
v2: https://patchwork.ozlabs.org/patch/970421/
v3: https://patchwork.ozlabs.org/patch/988241/
When commenting v3, I didn't know about the v2 discussion where Eric
Dumazet NACKed the patch because of potential conflict issues:
https://patchwork.ozlabs.org/patch/970421/#1992397
https://patchwork.ozlabs.org/patch/988241/#2017317
On the other hand, there is no need for atomic64_t. Simple atomic_t
(with explaining comment) would suffice. On architectures allowing
atomic read/write for 32-bit integers, there would be no performance
penalty. On architectures not allowing it, atomic_read() and
atomic_set() are implemented to be safe.
Michal Kubecek
^ permalink raw reply
* Re: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Shawn Guo @ 2018-11-04 8:45 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Andrew Lunn, Florian Fainelli, Leo Li, netdev@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <HE1PR0402MB3323371C130088B2A26F1627F1F60@HE1PR0402MB3323.eurprd04.prod.outlook.com>
On Wed, Oct 24, 2018 at 01:18:32PM +0000, Pankaj Bansal wrote:
> Hi All,
>
> As per the device tree ePappr https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
> section 2.2.1
>
> Each node in the device tree is named according to the following convention:
> node-name@unit-address
>
> The node-name shall start with a lower or uppercase character and should describe the general class of device.
> The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree.
>
> I am having a hard time following this convention when defining mdio-mux nodes for LX2160AQDS.
> The mdio-mux in LX2160AQDS is controlled by same register in fpga. Only some bits are different for the two buses' mux.
> How to differentiate between the node names for two buses' muxes?
>
> For now I have made their names as mdio-mux@54_f8 and mdio-mux@54_07.
> The first number is register address and second number indicates the bit mask that is used to select the bits from that register for a bus.
No. DTC will report warnings against that, because unit-address has to
match 'reg' property. I would suggest mdio-mux-1@54, mdio-mux-2@54 etc.
Shawn
>
> Any better alternatives?
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Pankaj Bansal
> Sent: Wednesday, October 24, 2018 6:35 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Subject: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
>
> The two external MDIO buses used to communicate with phy devices that
> are external to SOC are muxed in LX2160AQDS board.
>
> These buses can be routed to any one of the eight IO slots on LX2160AQDS
> board depending on value in fpga register 0x54.
>
> Additionally the external MDIO1 is used to communicate to the onboard
> RGMII phy devices.
>
> The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is controlled by
> bits 0-3 of fpga register.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> ---
>
> Notes:
> This patch depends on below patches:
> [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=369563
> [2] https://patchwork.kernel.org/patch/10645287/
>
> This patch is used by below patches:
> [1]https://patchwork.ozlabs.org/project/netdev/list/?series=69426&state=%2A&archive=both
>
> .../boot/dts/freescale/fsl-lx2160a-qds.dts | 115 +++++++++++++++++
> .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 ++++
> 2 files changed, 137 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index 99a22abbe725..4b282bf6c36a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -46,6 +46,121 @@
> &i2c0 {
> status = "okay";
>
> + fpga@66 {
> + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> + reg = <0x66>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio-mux@54_f8 {
> + mdio-parent-bus = <&emdio1>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0xf8>; /* EMI1_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@40 {
> + reg = <0x40>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c0 {
> + reg = <0xc0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c8 {
> + reg = <0xc8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d0 {
> + reg = <0xd0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d8 {
> + reg = <0xd8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e0 {
> + reg = <0xe0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e8 {
> + reg = <0xe8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f0 {
> + reg = <0xf0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f8 {
> + reg = <0xf8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + mdio-mux@54_07 {
> + mdio-parent-bus = <&emdio2>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0x07>; /* EMI2_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@1 {
> + reg = <0x01>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@2 {
> + reg = <0x02>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@3 {
> + reg = <0x03>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@4 {
> + reg = <0x04>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@5 {
> + reg = <0x05>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@6 {
> + reg = <0x06>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@7 {
> + reg = <0x07>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + };
> +
> i2c-mux@77 {
> compatible = "nxp,pca9547";
> reg = <0x77>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 56f846c55812..e16b1643595b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -761,5 +761,27 @@
> <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> dma-coherent;
> };
> +
> + /* TODO: WRIOP (CCSR?) */
> + emdio1: mdio@0x8B96000 { /* WRIOP0: 0x8B8_0000, E-MDIO1: 0x1_6000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B96000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + /* Not necessary on the QDS, but needed on the RDB*/
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + emdio2: mdio@0x8B97000 { /* WRIOP0: 0x8B8_0000, E-MDIO2: 0x1_7000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B97000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Joe Perches @ 2018-11-04 17:15 UTC (permalink / raw)
To: Toralf Förster, netdev, Kees Cook; +Cc: Linux Kernel
In-Reply-To: <0cfb892c-b358-4bd6-f7c9-071a0039bc71@gmx.de>
On Sun, 2018-11-04 at 17:14 +0100, Toralf Förster wrote:
> compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
>
>
> net/core/rtnetlink.c: In function ‘rtnl_newlink’:
> net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
>
> with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
>
This was introduce by a desire to eliminate variable length array
declarations by
commit ccf8dbcd062a930e64741c939ca784d15316aa0c
Author: Kees Cook <
keescook@chromium.org>
Date: Wed May 30 15:20:52 2018 -0700
rtnetlink: Remove VLA usage
It does make the stack use here unfortunately obviously large, but
it could have been this large, just unreported.
Perhaps no obvious solution here as an alloc instead of stack use
may be costly.
^ permalink raw reply
* may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Toralf Förster @ 2018-11-04 16:14 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel
compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
net/core/rtnetlink.c: In function ‘rtnl_newlink’:
net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
--
Toralf
PGP C4EACDDE 0076E94E
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-11-04 5:43 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <973f5f0e-fc25-7a99-70b5-3b53f7c69fca@tomt.net>
On 31.10.2018 05:08, Andre Tomt wrote:
> On 30.10.2018 12:04, Andre Tomt wrote:
>> On 30.10.2018 11:58, Andre Tomt wrote:
>>> On 27.10.2018 23:41, Andre Tomt wrote:
>>>> On 26.10.2018 13:45, Andre Tomt wrote:
>>>>> On 25.10.2018 19:38, Eric Dumazet wrote:
>>>>>>
>>>>>>
>>>>>> On 10/24/2018 12:41 PM, Andre Tomt wrote:
>>>>>>>
>>>>>>> It eventually showed up again with mlx4, on 4.18.16 + fix and
>>>>>>> also on 4.19. I still do not have a useful packet capture.
>>>>>>>
>>>>>>> It is running a torrent client serving up various linux
>>>>>>> distributions.
>>>>>>>
>>>>>>
>>>>>> Have you also applied this fix ?
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
>>>>>>
>>>>>>
>>>>>
>>>>> No. I've applied it now to 4.19 and will report back if anything
>>>>> shows up.
>>>>
>>>> Just hit it on the simpler server; no VRF, no tunnels, no
>>>> nat/conntrack. Only a basic stateless nftables ruleset and a vlan
>>>> netdev (unlikely to be the one triggering this I guess; it has only
>>>> v4 traffic).
>>>
>>> I'm currently testing 4.19 with the recomended commit added, plus
>>> these to sort out some GRO issues (on a hunch, unsure if related):
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=a8305bff685252e80b7c60f4f5e7dd2e63e38218
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=992cba7e276d438ac8b0a8c17b147b37c8c286f7
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=ece23711dd956cd5053c9cb03e9fe0668f9c8894
>>>
>>>
>>> and I *think* it is behaving better now? it's not conclusive as it
>>> could take a while to trip in this environment but some of the test
>>> servers have not shown anything bad in almost 24h.
>>
>> Sorry, s/some of the/none of the
>
> I think it is fairly safe to say 4.19 + mlx4 + these 4 commits is OK. At
> least for my workload. Servers are now 51-61 hours in, no splats. I also
> added ntp pool traffic to one of them to make things a little more
> exciting.
>
> Not sure what is needed for 4.18, I dont have the mental bandwidth to
> test that right now. Also no idea about the similar looking mlx5 splats
> reported elsewhere.
As expected conntrack/nat + vlan + forwarding still splats.
sch_cake, IFB and VRF was removed from this setup.
Here is a conntrack splat without IFB/VRF/Cake inteference:
> [34458.506346] wanib: hw csum failure
> [34458.506371] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-1 #1
> [34458.506374] Hardware name: Supermicro Super Server/X10SDV-4C-TLN2F, BIOS 2.0 06/13/2018
> [34458.506377] Call Trace:
> [34458.506381] <IRQ>
> [34458.506388] dump_stack+0x5c/0x80
> [34458.506392] __skb_checksum_complete+0xac/0xc0
> [34458.506402] icmp_error+0x1c8/0x1f0 [nf_conntrack]
> [34458.506406] ? skb_copy_bits+0x13d/0x220
> [34458.506411] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
> [34458.506416] ? ___pskb_trim+0x192/0x330
> [34458.506421] nf_hook_slow+0x43/0xc0
> [34458.506426] ip_rcv+0x90/0xb0
> [34458.506430] ? ip_rcv_finish_core.isra.0+0x310/0x310
> [34458.506435] __netif_receive_skb_one_core+0x42/0x50
> [34458.506438] netif_receive_skb_internal+0x24/0xb0
> [34458.506441] napi_gro_frags+0x177/0x210
> [34458.506446] mlx4_en_process_rx_cq+0x8df/0xb50 [mlx4_en]
> [34458.506459] ? mlx4_eq_int+0x38f/0xcb0 [mlx4_core]
> [34458.506463] mlx4_en_poll_rx_cq+0x55/0xf0 [mlx4_en]
> [34458.506466] net_rx_action+0xe1/0x2c0
> [34458.506469] __do_softirq+0xe7/0x2d3
> [34458.506475] irq_exit+0x96/0xd0
> [34458.506478] do_IRQ+0x85/0xd0
> [34458.506483] common_interrupt+0xf/0xf
> [34458.506486] </IRQ>
> [34458.506491] RIP: 0010:cpuidle_enter_state+0xb9/0x320
> [34458.506495] Code: e8 3c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 5e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
> [34458.506497] RSP: 0018:ffff978d41943ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
> [34458.506500] RAX: ffff8d8f6fa60fc0 RBX: 00001f56ff07af28 RCX: 000000000000001f
> [34458.506501] RDX: 00001f56ff07af28 RSI: 000000003a2e90d6 RDI: 0000000000000000
> [34458.506503] RBP: ffff8d8f6fa698c0 R08: 0000000000000002 R09: 0000000000020840
> [34458.506504] R10: 0004ea58f2899595 R11: ffff8d8f6fa601e8 R12: 0000000000000001
> [34458.506505] R13: ffffffff8a0ac638 R14: 0000000000000001 R15: 0000000000000000
> [34458.506509] ? cpuidle_enter_state+0x94/0x320
> [34458.506512] do_idle+0x1e4/0x220
> [34458.506515] cpu_startup_entry+0x5f/0x70
> [34458.506519] start_secondary+0x185/0x1a0
> [34458.506521] secondary_startup_64+0xa4/0xb0
Stateless filtered non-forwarding host still looks like it has been
fixed (the udp6_gro_* splats are still all gone). Also seems fine when
moving the traffic over a vlan device. These fixes went into 4.19.1-rc1
(checksum_complete + unlink gro packets on overflow fixes)
^ permalink raw reply
* Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
From: Aleksa Sarai @ 2018-11-04 11:59 UTC (permalink / raw)
To: Steven Rostedt
Cc: Naveen N. Rao, Anil S Keshavamurthy, David S. Miller,
Masami Hiramatsu, Jonathan Corbet, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Brendan Gregg, Christian Brauner, Aleksa Sarai, netdev, linux-doc,
linux-kernel
In-Reply-To: <20181103070253.ajrqzs5xu2vf5stu@yavin>
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On 2018-11-03, Aleksa Sarai <cyphar@cyphar.com> wrote:
> This is actually a general bug in ftrace as well, because (for
> instance) while the unwinder calls into ftrace_graph_ret_addr() while
> walking up the stack this isn't used to correct regs->ip in
> perf_callchain_kernel(). I think this is the cause of the bug in
> ftrace-graph (if you switch to the "frame" unwinder you might be able
> to see it more clearly) -- but when trying to fix it I'm having
> trouble figuring out what retp should be (stack_addr(regs) doesn't
> give the right result for some reason).
@Steven, @Masami: Can you verify whether this is an actual bug? The
snippet is like (arch/x86/events/core.c):
void
perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)
{
/* ... */
if (perf_callchain_store(entry, regs->ip))
return;
/* rest of unwind code */
}
And it seems to me that there's an ftrace_graph_ret_addr missing here
(though I was having trouble figuring out what the right retp would be
in this context -- both stack_addr(regs) and ®s->sp appear to be
wrong when I was trying to get this to work with kretprobes -- while my
patch worked with all other kretprobe_trampoline cases in the unwinder).
The same issue is present in __save_stack_trace
(arch/x86/kernel/stacktrace.c). This is likely the only reason that --
as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
with the refactor both of you are discussing).
Thanks.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Update
From: Dr Kannan @ 2018-11-03 16:26 UTC (permalink / raw)
To: Recipients
Hello dear
Greetings to you,I am Dr.Kannan, a personal account manager to Late Engr. Richard Hernandez, who died with his family in the missing Malaysian Air crash
of 2014. His account with us is in intestate with no claim his fixed deposit of U$D 7 Million.
I have been mandated by the Bank Management as his personal account officer, to present his relative or next of kin.
I have searched through notary register of his country here all to no avail, so I wish to present you to the Bank as his only relative and next of kin.
kindly contact me for more details, terms and condition shall be clarified upon your response. There is no risk whatsoever to this transaction as I have all papers and documents to pose of you the inheritance to this.
I wait for your prompt response.
My regards,
Dr. Kannan.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum: Fix IP2ME CPU policer configuration
From: David Miller @ 2018-11-04 2:32 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, shalomt, mlxsw
In-Reply-To: <20181102194840.31107-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Fri, 2 Nov 2018 19:49:15 +0000
> From: Shalom Toledo <shalomt@mellanox.com>
>
> The CPU policer used to police packets being trapped via a local route
> (IP2ME) was incorrectly configured to police based on bytes per second
> instead of packets per second.
>
> Change the policer to police based on packets per second and avoid
> packet loss under certain circumstances.
>
> Fixes: 9148e7cf73ce ("mlxsw: spectrum: Add policers for trap groups")
> Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net] sctp: define SCTP_SS_DEFAULT for Stream schedulers
From: David Miller @ 2018-11-04 2:41 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <4986625e9c58cccdfbb6c809a82c77a83b57a541.1541224891.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 3 Nov 2018 14:01:31 +0800
> According to rfc8260#section-4.3.2, SCTP_SS_DEFAULT is required to
> defined as SCTP_SS_FCFS or SCTP_SS_RR.
>
> SCTP_SS_FCFS is used for SCTP_SS_DEFAULT's value in this patch.
>
> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Also applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: fix strchange_flags name for Stream Change Event
From: David Miller @ 2018-11-04 2:39 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <34b8e0475a841d258c2165b5a46a72c373e52976.1541224785.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 3 Nov 2018 13:59:45 +0800
> As defined in rfc6525#section-6.1.3, SCTP_STREAM_CHANGE_DENIED
> and SCTP_STREAM_CHANGE_FAILED should be used instead of
> SCTP_ASSOC_CHANGE_DENIED and SCTP_ASSOC_CHANGE_FAILED.
>
> To keep the compatibility, fix it by adding two macros.
>
> Fixes: b444153fb5a6 ("sctp: add support for generating add stream change event notification")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net-sysfs: fix formatting of tx_timeout attribute
From: David Miller @ 2018-11-04 2:31 UTC (permalink / raw)
To: jwi; +Cc: netdev
In-Reply-To: <20181102183317.2017-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 2 Nov 2018 19:33:17 +0100
> Add a missing newline.
>
> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
> ---
> net/core/net-sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index bd67c4d0fcfd..ef06409d768e 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -1039,7 +1039,7 @@ static ssize_t tx_timeout_show(struct netdev_queue *queue, char *buf)
> trans_timeout = queue->trans_timeout;
> spin_unlock_irq(&queue->_xmit_lock);
>
> - return sprintf(buf, "%lu", trans_timeout);
> + return sprintf(buf, "%lu\n", trans_timeout);
Maybe use 'fmt_ulong' instead?
^ permalink raw reply
* Re: [PATCH] qed: fix link config error handling
From: David Miller @ 2018-11-04 2:27 UTC (permalink / raw)
To: arnd
Cc: Ariel.Elior, everest-linux-l2, sudarsana.kalluru, Tomer.Tayar,
denis.bolotin, Rahul.Verma, netdev, linux-kernel
In-Reply-To: <20181102153632.1646632-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 2 Nov 2018 16:36:24 +0100
> gcc-8 notices that qed_mcp_get_transceiver_data() may fail to
> return a result to the caller:
>
> drivers/net/ethernet/qlogic/qed/qed_mcp.c: In function 'qed_mcp_trans_speed_mask':
> drivers/net/ethernet/qlogic/qed/qed_mcp.c:1955:2: error: 'transceiver_type' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> When an error is returned by qed_mcp_get_transceiver_data(), we
> should propagate that to the caller of qed_mcp_trans_speed_mask()
> rather than continuing with uninitialized data.
>
> Fixes: c56a8be7e7aa ("qed: Add supported link and advertise link to display in ethtool.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH] net/mlx5e: Temp software stats variable is not required
From: David Miller @ 2018-11-04 2:36 UTC (permalink / raw)
To: saeedm; +Cc: netdev, arnd, akpm, jgg, eric.dumazet, eranbe, leonro
In-Reply-To: <20181103015422.22978-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 2 Nov 2018 18:54:22 -0700
> +static void mlx5e_fold_sw_stats(struct mlx5e_priv *priv, struct rtnl_link_stats64 *s)
> +{
> + int i;
> +
> + /* not required ? */
> + memset(s, 0, sizeof(*s));
Why wouldn't this be required?
I can see that perhaps you can only zero out the statistics that are used in
the ndo_get_stats64() code path, but that's different.
^ permalink raw reply
* Re: pull-request: bpf 2018-11-03
From: David Miller @ 2018-11-04 2:34 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20181103004703.6007-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 3 Nov 2018 01:47:03 +0100
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix BPF prog kallsyms and bpf_prog_get_info_by_fd() jited address export
> to not use page start but actual start instead to work correctly with
> profiling e.g. finding hot instructions from stack traces. Also fix latter
> with regards to dumping address and jited len for !multi prog, from Song.
>
> 2) Fix bpf_prog_get_info_by_fd() for !root to zero info.nr_jited_func_lens
> instead of leaving the user provided length, from Daniel.
>
> 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 v2 net 0/3] net: bql: better deal with GSO
From: David Miller @ 2018-11-04 0:26 UTC (permalink / raw)
To: edumazet; +Cc: netdev, tariqt, willemb, eric.dumazet
In-Reply-To: <CANn89iLJcc4o7ftTL3Sb0GEd3tYvexKn-tHyDWzqEo2Pk1ECRA@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 3 Nov 2018 16:00:39 -0700
> On Sat, Nov 3, 2018 at 3:40 PM David Miller <davem@davemloft.net> wrote:
>
>> Series applied, but I wonder how many other commonly used drivers we
>> should update the same way mlx4 is here?
>
> I can provide patches but can not test them, so probably we should get
> Tested-by tags before applying them.
Ok, agreed.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-04 0:24 UTC (permalink / raw)
To: David Ahern, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <f6188534-38d7-fc3e-189d-443a76bcb47d@gmail.com>
n
W dniu 03.11.2018 o 18:32, David Ahern pisze:
> On 11/1/18 11:30 AM, Paweł Staszewski wrote:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/xdp_fwd_kern.c
>>>>>
>>>>>
>>>> I can try some tests on same hw but testlab configuration - will give it
>>>> a try :)
>>>>
>>> That version does not work with VLANs. I have patches for it but it
>>> needs a bit more work before sending out. Perhaps I can get back to it
>>> next week.
>>>
>> Will be nice - next week i will be able to replace network controller
>> and install separate two 100Gbit nics into two pciex x16 slots - so can
>> test without hitting pcie bandwidth limits.
>>
>>
> Does your setup have any other device types besides physical ports with
> VLANs (e.g., any macvlans or bonds)?
>
>
no.
just
phy(mlnx)->vlans only config
And today again after allpy patch for page allocator - reached again
64/64 Gbit/s
with only 50-60% cpu load
today no slowpath hit for netwoking :)
But again dropped pckt at 64GbitRX and 64TX ....
And as it should not be pcie express limit -i think something more is
going on there - and hard to catch - cause perf top doestn chenged
besides there is no queued slowpath hit now
I ordered now also intel cards to compare - but 3 weeks eta
Faster - cause 3 days - i will have mellanox connectx 5 - so can
separate traffic to two different x16 pcie busses
^ permalink raw reply
* [PATCH] e1000e: Change watchdog task to be delayed work
From: Robert Eshleman @ 2018-11-04 0:17 UTC (permalink / raw)
Cc: Robert Eshleman, Jeff Kirsher, David S. Miller, intel-wired-lan,
netdev, linux-kernel
This completes a pending TODO to use queue_delayed_work() instead of
schedule_work().
Signed-off-by: Robert Eshleman <bobbyeshleman@gmail.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 16a73bd..a387b21 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -39,6 +39,8 @@ static int debug = -1;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+struct workqueue_struct *e1000e_workqueue;
+
static const struct e1000_info *e1000_info_tbl[] = {
[board_82571] = &e1000_82571_info,
[board_82572] = &e1000_82572_info,
@@ -5137,9 +5139,9 @@ static void e1000_watchdog(struct timer_list *t)
struct e1000_adapter *adapter = from_timer(adapter, t, watchdog_timer);
/* Do the rest outside of interrupt context */
- schedule_work(&adapter->watchdog_task);
+ struct delayed_work *dwork = to_delayed_work(&adapter->watchdog_task);
- /* TODO: make this use queue_delayed_work() */
+ queue_delayed_work(e1000e_workqueue, dwork, 1);
}
static void e1000_watchdog_task(struct work_struct *work)
@@ -7572,6 +7574,13 @@ static int __init e1000_init_module(void)
e1000e_driver_version);
pr_info("Copyright(c) 1999 - 2015 Intel Corporation.\n");
+ e1000e_workqueue = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0,
+ e1000e_driver_name);
+ if (!e1000e_workqueue) {
+ pr_err("%s: Failed to create workqueue\n", e1000e_driver_name);
+ return -ENOMEM;
+ }
+
return pci_register_driver(&e1000_driver);
}
module_init(e1000_init_module);
@@ -7585,6 +7594,7 @@ module_init(e1000_init_module);
static void __exit e1000_exit_module(void)
{
pci_unregister_driver(&e1000_driver);
+ destroy_workqueue(e1000e_workqueue);
}
module_exit(e1000_exit_module);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net 0/3] net: bql: better deal with GSO
From: Eric Dumazet @ 2018-11-03 23:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tariq Toukan, Willem de Bruijn, Eric Dumazet
In-Reply-To: <20181103.154028.1864906755289829872.davem@davemloft.net>
On Sat, Nov 3, 2018 at 3:40 PM David Miller <davem@davemloft.net> wrote:
> Series applied, but I wonder how many other commonly used drivers we
> should update the same way mlx4 is here?
I can provide patches but can not test them, so probably we should get
Tested-by tags before applying them.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: hns3: Fix for out-of-bounds access when setting pfc back pressure
From: David Miller @ 2018-11-03 22:42 UTC (permalink / raw)
To: linyunsheng
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, john.garry, linuxarm,
salil.mehta, lipeng321, netdev, linux-kernel
In-Reply-To: <1541074363-98630-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Thu, 1 Nov 2018 20:12:43 +0800
> The vport should be initialized to hdev->vport for each bp group,
> otherwise it will cause out-of-bounds access and bp setting not
> correct problem.
...
> Fixes: 67bf2541f4b9 ("net: hns3: Fixes the back pressure setting when sriov is enabled")
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net 0/3] net: bql: better deal with GSO
From: David Miller @ 2018-11-03 22:40 UTC (permalink / raw)
To: edumazet; +Cc: netdev, tariqt, willemb, eric.dumazet
In-Reply-To: <20181031153914.132127-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 31 Oct 2018 08:39:11 -0700
> While BQL bulk dequeue works well for TSO packets, it is
> not very efficient as soon as GSO is involved.
>
> On a GSO only workload (UDP or TCP), this patch series
> can save about 8 % of cpu cycles on a 40Gbit mlx4 NIC,
> by keeping optimal batching, and avoiding expensive
> doorbells, qdisc requeues and reschedules.
>
> This patch series :
>
> - Add __netdev_tx_sent_queue() so that drivers
> can implement efficient BQL and xmit_more support.
>
> - Implement a work around in dev_hard_start_xmit()
> for drivers not using __netdev_tx_sent_queue()
>
> - changes mlx4 to use __netdev_tx_sent_queue()
>
> v2: Tariq and Willem feedback addressed.
> added __netdev_tx_sent_queue() (Willem suggestion)
Series applied, but I wonder how many other commonly used drivers we
should update the same way mlx4 is here?
^ permalink raw reply
* Re: [PATCH v2] libertas: return errno from lbs_add_card()
From: Pavel Machek @ 2018-11-03 19:43 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Kalle Valo, David S. Miller, libertas-dev, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20181007003327.2806010-1-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
On Sun 2018-10-07 02:33:27, Lubomir Rintel wrote:
> This makes the error handling somewhat cleaner -- lbs_add_card() does no
> logner throw away the errno and lets its callers propagate it.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net 0/6] s390/qeth: fixes 2018-11-02
From: David Miller @ 2018-11-03 17:44 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20181102180413.53020-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 2 Nov 2018 19:04:07 +0100
> please apply one round of qeth fixes for -net.
>
> Patch 1 is rather large and removes a use-after-free hazard from many of our
> debug trace entries.
> Patch 2 is yet another fix-up for the L3 subdriver's new IP address management
> code.
> Patch 3 and 4 resolve some fallout from the recent changes wrt how/when qeth
> allocates its net_device.
> Patch 5 makes sure we don't set reserved bits when building HW commands from
> user-provided data.
> And finally, patch 6 allows ethtool to play nice with new HW.
Series applied.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: David Ahern @ 2018-11-03 17:32 UTC (permalink / raw)
To: Paweł Staszewski, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <a63df254-3791-cd5c-ddfc-6c9b8d38c559@itcare.pl>
On 11/1/18 11:30 AM, Paweł Staszewski wrote:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/xdp_fwd_kern.c
>>>>
>>>>
>>> I can try some tests on same hw but testlab configuration - will give it
>>> a try :)
>>>
>> That version does not work with VLANs. I have patches for it but it
>> needs a bit more work before sending out. Perhaps I can get back to it
>> next week.
>>
> Will be nice - next week i will be able to replace network controller
> and install separate two 100Gbit nics into two pciex x16 slots - so can
> test without hitting pcie bandwidth limits.
>
>
Does your setup have any other device types besides physical ports with
VLANs (e.g., any macvlans or bonds)?
^ permalink raw reply
* Re: [PATCH] openvswitch: fix linking without CONFIG_NF_CONNTRACK_LABELS
From: David Miller @ 2018-11-04 2:29 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: dev-yBygre7rU0TnMu66kgdUjQ,
eswierk-FilZDy9cOaHkQYj/0HfcvtBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA, fw-HFFVJYpyMKqzQB+pC5nmwQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Julia.Lawall-L2FTfq7BK8M,
gfree.wind-GveOkT2v/s5BDgjK7y7TUQ, thierry-EDrxZYgYwg/bB1ukUYwELw,
fbl-H+wXaHxf7aLQT0dZR+AlfA, pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <20181102153705.1664786-1-arnd-r2nGTMty4D4@public.gmane.org>
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Date: Fri, 2 Nov 2018 16:36:55 +0100
> When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler
> fails to optimize out a dead code path, which leads to a link failure:
>
> net/openvswitch/conntrack.o: In function `ovs_ct_set_labels':
> conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace'
>
> In this configuration, we can take a shortcut, and completely
> remove the contrack label code. This may also help the regular
> optimization.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Applied, thanks Arnd.
^ 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