* Re: [PATCH iproute2] vxlan: show correct ttl inherit info
From: Hangbin Liu @ 2018-09-27 14:07 UTC (permalink / raw)
To: Phil Sutter, netdev, Stephen Hemminger, David Ahern
In-Reply-To: <20180927092745.GV14666@orbyte.nwl.cc>
On Thu, Sep 27, 2018 at 11:27:45AM +0200, Phil Sutter wrote:
> Hi Hangbin,
>
> On Thu, Sep 27, 2018 at 03:28:36PM +0800, Hangbin Liu wrote:
> > We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
> > Otherwise show the ttl number, or auto when it is 0.
> >
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > ip/iplink_vxlan.c | 16 ++++++++++------
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
> > index 831f39a..7fc0e2b 100644
> > --- a/ip/iplink_vxlan.c
> > +++ b/ip/iplink_vxlan.c
> > @@ -145,7 +145,7 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
> > NEXT_ARG();
> > check_duparg(&attrs, IFLA_VXLAN_TTL, "ttl", *argv);
> > if (strcmp(*argv, "inherit") == 0) {
> > - addattr_l(n, 1024, IFLA_VXLAN_TTL_INHERIT, NULL, 0);
> > + addattr(n, 1024, IFLA_VXLAN_TTL_INHERIT);
>
> So for VXLAN, the attribute is just added but with a zero value. Looking
> at respective kernel code, this seems fine. Now I wonder why for Geneve,
> you set the value to 1 and when displaying explicitly check whether the
> attribute is there *and* non-zero. OK, looks like Geneve driver always
> exports IFLA_GENEVE_TTL_INHERIT. Oddly, I can't find where VXLAN driver
> in kernel does export the IFLA_VXLAN_TTL_INHERIT attribute. Am I missing
> something?
Hi Phil,
The vxlan ttl inherit exportation is just fixed by
net commit 8fd78069874 ("vxlan: fill ttl inherit info") yesterday.
> Do you know why handling of the attributes in both drivers differ?
That's because I set IFLA_VXLAN_TTL_INHERIT type to NLA_FLAG. But when fix
the geneve issue, I forgot this and set IFLA_GENEVE_TTL_INHERIT type to
NLA_U8... :(
I noticed this when post the iproute2 patch. But I thought this should have
no much influence, so I just leave it as it is.
If you think we'd better have a same behaver. We can drop the geneve iproute2
patch and post a fix to net kernel tree.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net-next 0/7] rtnetlink: add RTM_GETADDR2
From: David Ahern @ 2018-09-27 20:24 UTC (permalink / raw)
To: Christian Brauner, jbenc, davem, stephen, netdev, linux-kernel
In-Reply-To: <20180927175857.3511-1-christian@brauner.io>
On 9/27/18 11:58 AM, Christian Brauner wrote:
> Various userspace programs (e.g. iproute2) have sent RTM_GETADDR
> requests with struct ifinfomsg. This is wrong and should have been
> struct ifaddrmsg all along as mandated by the manpages. However, dump
> requests so far didn't parse the netlink message that was sent and
> succeeded even when a wrong struct was passed along.
...
> The correct solution at this point seems to me to introduce a new
> RTM_GETADDR2 request. This way we can parse the message and fail hard if
> the struct is not struct ifaddrmsg and can safely extend it in the
> future. Userspace tools that rely on the buggy RTM_GETADDR API will
> still keep working without even having to see any log messages and new
> userspace tools that want to make user of new features can make use of
> the new RTM_GETADDR2 requests.
First, I think this is the wrong precedent when all we need is a single
bit flag that userspace can use to tell the kernel "I have a clue and I
am passing in the proper header for this dump request".
Second, you are not addressing the problems of the past by requiring the
proper header and checking values passed in it.
I have another idea. I'll send an RFC patch soon.
^ permalink raw reply
* Re: [RFC PATCH iproute2-next V2] System specification exception API
From: Eran Ben Elisha @ 2018-09-27 14:02 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, Jakub Kicinski, Jiri Pirko, Stephen Hemminger,
Andrew Lunn, Tobin C. Harding, Ariel Almog, Tal Alon
In-Reply-To: <20180927124736.GB2209@nanopsycho.orion>
On 9/27/2018 3:47 PM, Jiri Pirko wrote:
> Wed, Sep 26, 2018 at 01:52:58PM CEST, eranbe@mellanox.com wrote:
>> The exception spec is targeted for Real Time Alerting, in order to know when
>> something bad had happened to a PCI device
>> - Provide alert debug information
>> - Self healing
>> - If problem needs vendor support, provide a way to gather all needed debugging
>> information.
>>
>> The exception mechanism contains condition checkers which sense for malfunction. Upon a condition hit,
>> actions such as logs and correction can be taken.
>>
>> The condition checkers are divided into the following groups
>> - Hardware - a checker which is triggered by the device due to
>> malfunction.
>> - Software - a checker which is triggered by the software due to
>> malfunction.
>
> What do you mean by a "software malfunction", a "FW malfunction"?
> Also, I don't see this 2 groups in the man.
Software malfunction can be a Transmit error (caused by bad send request).
FW/HW malfunction can be any catastrophic error report (the ones that
should be exposed to driver).
The comment here was to highlight that we can support different kinds of
condition groups.
If for a specific condition, we will need to highlight it is SW/HW, we
can concatenate it to its name.
Eran
>
>
>> Both groups of condition checkers can be triggered due to error event or due to a periodic check.
>>
>> Actions are the way to handle those events. Action can be in one of the
>> following groups:
>> - Dump - SW trace, SW dump, HW trace, HW dump
>> - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>> Actions can be performed by SW or HW.
>>
>> User is allowed to enable or disable condition checkers and its action mapping.
>>
>> This RFC man page patch describes the suggested API of devlink-exception in order
>> to control conditions and actions.
>>
>> V2:
>> * Renaming terms:
>> health -> exception
>> sensor -> condition
>> * Remove reinit command and merge with action command.
>> * Consmetics in grammer.
>>
>> Eran Ben Elisha (1):
>> man: Add devlink exception man page
>>
>> man/man8/devlink-exception.8 | 158 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 158 insertions(+)
>> create mode 100644 man/man8/devlink-exception.8
>>
>> --
>> 1.8.3.1
>>
^ permalink raw reply
* [PATCH v2 net-next 2/2] dt-bindings: net: add support for Microchip KSZ9131 Ethernet PHY
From: Yuiko Oshino @ 2018-09-27 20:16 UTC (permalink / raw)
To: davem, robh+dt, devicetree, f.fainelli, andrew
Cc: linux-kernel, mark.rutland, m.felsch, Markus.Niebel, netdev,
UNGLinuxDriver
Add support for Microchip Technology KSZ9131 10/100/1000 Ethernet PHY
Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com>
---
.../devicetree/bindings/net/micrel-ksz90x1.txt | 29 +++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index e22d8cf..d23d14a 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -1,4 +1,4 @@
-Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
+Micrel/Microchip KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY
Some boards require special tuning values, particularly when it comes
to clock delays. You can specify clock delay values in the PHY OF
@@ -64,6 +64,33 @@ KSZ9031:
Attention: The link partner must be configurable as slave otherwise
no link will be established.
+KSZ9131:
+
+ All skew control options are specified in picoseconds. The minimum
+ value is 0, and the maximum is property-dependent. The increment
+ step is 100ps. The default value is the neutral setting, so setting
+ rxc-skew-ps=<0> actually results in -700 picoseconds adjustment.
+
+ Optional properties:
+
+ Maximum value of 2400, default value 700:
+
+ - rxc-skew-ps : Skew control of RX clock pad
+ - txc-skew-ps : Skew control of TX clock pad
+
+ Maximum value of 1500, default value 700:
+
+ - rxdv-skew-ps : Skew control of RX CTL pad
+ - txen-skew-ps : Skew control of TX CTL pad
+ - rxd0-skew-ps : Skew control of RX data 0 pad
+ - rxd1-skew-ps : Skew control of RX data 1 pad
+ - rxd2-skew-ps : Skew control of RX data 2 pad
+ - rxd3-skew-ps : Skew control of RX data 3 pad
+ - txd0-skew-ps : Skew control of TX data 0 pad
+ - txd1-skew-ps : Skew control of TX data 1 pad
+ - txd2-skew-ps : Skew control of TX data 2 pad
+ - txd3-skew-ps : Skew control of TX data 3 pad
+
Examples:
mdio {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
From: Willem de Bruijn @ 2018-09-27 13:53 UTC (permalink / raw)
To: Jason Wang
Cc: Florian Fainelli, Network Development, David Miller, caleb.raitto,
Michael S. Tsirkin, Jon Olson (Google Drive), Willem de Bruijn
In-Reply-To: <841d0fc6-d9a2-84d0-f794-7a7b2019fa17@redhat.com>
On Thu, Sep 27, 2018 at 4:51 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2018年09月14日 12:46, Willem de Bruijn wrote:
> >> I'm not sure I get this. If we don't enable tx napi, we tend to delay TX
> >> interrupt if we found the ring is about to full to avoid interrupt
> >> storm, so we're probably ok in this case.
> > I'm only concerned about the transition state when converting from
> > napi to no-napi when the queue is stopped and tx interrupt disabled.
> >
> > With napi mode the interrupt is only disabled if napi is scheduled,
> > in which case it will eventually reenable the interrupt. But when
> > switching to no-napi mode in this state no progress will be made.
> >
> > But it seems this cannot happen. When converting to no-napi
> > mode, set_coalesce waits for napi to complete in napi_disable.
> > So the interrupt should always start enabled when transitioning
> > into no-napi mode.
>
> An update, I meet a hang in napi_disalbe(). But it's hard to be
> reproduced. I tend to choose a easy way like V1 that only allow the
> switching when device is down.
I agree.
> I will post the patch after a vacation. (or you can post if it was
> urgent for you).
If you have time to review and add your signed-off-by, I can post it.
It's a pretty small diff at this point.
But no rush, we can also wait until after your vacation.
I also need to look at a patch to toggle LRO using ethtool, btw.
^ permalink raw reply
* [PATCH ethtool] ethtool: Fix uninitialized variable use at qsfp dump
From: Eran Ben Elisha @ 2018-09-27 13:48 UTC (permalink / raw)
To: netdev, John W. Linville
Cc: Chris Preimesberger, Andrew Lunn, Neil Horman,
Vidya Sagar Ravipati, Eran Ben Elisha
Struct sff_diags can be used uninitialized at sff8636_show_dom, this
caused the tool to show unreported fields (supports_alarms) by the lower
level driver.
Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
---
qsfp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qsfp.c b/qsfp.c
index 32e195d12dc0..d196aa1753de 100644
--- a/qsfp.c
+++ b/qsfp.c
@@ -671,7 +671,7 @@ static void sff8636_dom_parse(const __u8 *id, struct sff_diags *sd)
static void sff8636_show_dom(const __u8 *id, __u32 eeprom_len)
{
- struct sff_diags sd;
+ struct sff_diags sd = {0};
char *rx_power_string = NULL;
char power_string[MAX_DESC_SIZE];
int i;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Li Yang @ 2018-09-27 20:03 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Netdev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Roy Pledge, madalin.bucur, David Miller, Shawn Guo, robin.murphy,
bharat.bhushan
In-Reply-To: <20180926132247.10971-9-laurentiu.tudor@nxp.com>
On Wed, Sep 26, 2018 at 8:26 AM <laurentiu.tudor@nxp.com> wrote:
>
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> Add a couple of new APIs to check the probing status of the required
> cpu bound qman and bman portals:
> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
> They return the following values.
> * 1 if qman/bman portals were all probed correctly
> * 0 if qman/bman portals were not yet probed
> * -1 if probing of qman/bman portals failed
> Drivers that use qman/bman portal driver services are required to use
> these APIs before calling any functions exported by these drivers or
> otherwise they will crash the kernel.
> First user will be the dpaa1 ethernet driver, coming in a subsequent
> patch.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> drivers/soc/fsl/qbman/bman_portal.c | 10 ++++++++++
> drivers/soc/fsl/qbman/qman_portal.c | 10 ++++++++++
> include/soc/fsl/bman.h | 8 ++++++++
> include/soc/fsl/qman.h | 9 +++++++++
> 4 files changed, 37 insertions(+)
>
> diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
> index f9edd28894fd..8048d35de8a2 100644
> --- a/drivers/soc/fsl/qbman/bman_portal.c
> +++ b/drivers/soc/fsl/qbman/bman_portal.c
> @@ -32,6 +32,7 @@
>
> static struct bman_portal *affine_bportals[NR_CPUS];
> static struct cpumask portal_cpus;
> +static int __bman_portals_probed;
> /* protect bman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(bman_lock);
>
> @@ -85,6 +86,12 @@ static int bman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int bman_portals_probed(void)
> +{
> + return __bman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(bman_portals_probed);
> +
> static int bman_portal_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -148,6 +155,7 @@ static int bman_portal_probe(struct platform_device *pdev)
> spin_lock(&bman_lock);
> cpu = cpumask_next_zero(-1, &portal_cpus);
> if (cpu >= nr_cpu_ids) {
> + __bman_portals_probed = 1;
What if the last CPU is not used for portals? Is there a hard
requirement that all CPUs need to be used for portal? What happens if
the last CPU is offline?
> /* unassigned portal, skip init */
> spin_unlock(&bman_lock);
> return 0;
> @@ -173,6 +181,8 @@ static int bman_portal_probe(struct platform_device *pdev)
> err_ioremap2:
> memunmap(pcfg->addr_virt_ce);
> err_ioremap1:
> + __bman_portals_probed = 1;
> +
There are other error paths that not covered.
> return -ENXIO;
> }
>
> diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
> index eef93cab84f1..1b2fc981c269 100644
> --- a/drivers/soc/fsl/qbman/qman_portal.c
> +++ b/drivers/soc/fsl/qbman/qman_portal.c
> @@ -39,6 +39,7 @@ EXPORT_SYMBOL(qman_dma_portal);
> #define CONFIG_FSL_DPA_PIRQ_FAST 1
>
> static struct cpumask portal_cpus;
> +static int __qman_portals_probed;
> /* protect qman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(qman_lock);
>
> @@ -219,6 +220,12 @@ static int qman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int qman_portals_probed(void)
> +{
> + return __qman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(qman_portals_probed);
> +
> static int qman_portal_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -306,6 +313,7 @@ static int qman_portal_probe(struct platform_device *pdev)
> spin_lock(&qman_lock);
> cpu = cpumask_next_zero(-1, &portal_cpus);
> if (cpu >= nr_cpu_ids) {
> + __qman_portals_probed = 1;
Ditto.
> /* unassigned portal, skip init */
> spin_unlock(&qman_lock);
> return 0;
> @@ -336,6 +344,8 @@ static int qman_portal_probe(struct platform_device *pdev)
> err_ioremap2:
> memunmap(pcfg->addr_virt_ce);
> err_ioremap1:
> + __qman_portals_probed = -1;
> +
Ditto.
> return -ENXIO;
> }
>
> diff --git a/include/soc/fsl/bman.h b/include/soc/fsl/bman.h
> index 5b99cb2ea5ef..173e4049d963 100644
> --- a/include/soc/fsl/bman.h
> +++ b/include/soc/fsl/bman.h
> @@ -133,5 +133,13 @@ int bman_acquire(struct bman_pool *pool, struct bm_buffer *bufs, u8 num);
> * failed to probe or 0 if the bman driver did not probed yet.
> */
> int bman_is_probed(void);
> +/**
> + * bman_portals_probed - Check if all cpu bound bman portals are probed
> + *
> + * Returns 1 if all the required cpu bound bman portals successfully probed,
> + * -1 if probe errors appeared or 0 if the bman portals did not yet finished
> + * probing.
> + */
> +int bman_portals_probed(void);
>
> #endif /* __FSL_BMAN_H */
> diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
> index 597783b8a3a0..7732e48081eb 100644
> --- a/include/soc/fsl/qman.h
> +++ b/include/soc/fsl/qman.h
> @@ -1194,4 +1194,13 @@ int qman_release_cgrid(u32 id);
> */
> int qman_is_probed(void);
>
> +/**
> + * qman_portals_probed - Check if all cpu bound qman portals are probed
> + *
> + * Returns 1 if all the required cpu bound qman portals successfully probed,
> + * -1 if probe errors appeared or 0 if the qman portals did not yet finished
> + * probing.
> + */
> +int qman_portals_probed(void);
> +
> #endif /* __FSL_QMAN_H */
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH net-next] selftests: forwarding: test for bridge sticky flag
From: Nikolay Aleksandrov @ 2018-09-27 13:35 UTC (permalink / raw)
To: netdev; +Cc: roopa, Nikolay Aleksandrov
In-Reply-To: <20180927133513.14175-1-nikolay@cumulusnetworks.com>
This test adds an fdb entry with the sticky flag and sends traffic from
a different port with the same mac as a source address expecting the entry
to not change ports if the flag is operating correctly.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
.../selftests/net/forwarding/bridge_sticky_fdb.sh | 69 ++++++++++++++++++++++
1 file changed, 69 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/bridge_sticky_fdb.sh
diff --git a/tools/testing/selftests/net/forwarding/bridge_sticky_fdb.sh b/tools/testing/selftests/net/forwarding/bridge_sticky_fdb.sh
new file mode 100755
index 000000000000..1f8ef0eff862
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/bridge_sticky_fdb.sh
@@ -0,0 +1,69 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+ALL_TESTS="sticky"
+NUM_NETIFS=4
+TEST_MAC=de:ad:be:ef:13:37
+source lib.sh
+
+switch_create()
+{
+ ip link add dev br0 type bridge
+
+ ip link set dev $swp1 master br0
+ ip link set dev $swp2 master br0
+
+ ip link set dev br0 up
+ ip link set dev $h1 up
+ ip link set dev $swp1 up
+ ip link set dev $h2 up
+ ip link set dev $swp2 up
+}
+
+switch_destroy()
+{
+ ip link set dev $swp2 down
+ ip link set dev $h2 down
+ ip link set dev $swp1 down
+ ip link set dev $h1 down
+
+ ip link del dev br0
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+ h2=${NETIFS[p3]}
+ swp2=${NETIFS[p4]}
+
+ switch_create
+}
+
+cleanup()
+{
+ pre_cleanup
+ switch_destroy
+}
+
+sticky()
+{
+ bridge fdb add $TEST_MAC dev $swp1 master static sticky
+ check_err $? "Could not add fdb entry"
+ bridge fdb del $TEST_MAC dev $swp1 vlan 1 master static sticky
+ $MZ $h2 -c 1 -a $TEST_MAC -t arp "request" -q
+ bridge -j fdb show br br0 brport $swp1\
+ | jq -e ".[] | select(.mac == \"$TEST_MAC\")" &> /dev/null
+ check_err $? "Did not find FDB record when should"
+
+ log_test "Sticky fdb entry"
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+exit $EXIT_STATUS
--
2.11.0
^ permalink raw reply related
* [PATCH iproute2 net-next] bridge: fdb: add support for sticky flag
From: Nikolay Aleksandrov @ 2018-09-27 13:35 UTC (permalink / raw)
To: netdev; +Cc: roopa, Nikolay Aleksandrov, David Ahern
Add support for the new sticky flag that can be set on fdbs and update the
man page.
CC: David Ahern <dsahern@gmail.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
bridge/fdb.c | 9 +++++++--
man/man8/bridge.8 | 6 +++++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index 4dbc894ceab9..828fdab264cb 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -37,8 +37,8 @@ static void usage(void)
fprintf(stderr,
"Usage: bridge fdb { add | append | del | replace } ADDR dev DEV\n"
" [ self ] [ master ] [ use ] [ router ] [ extern_learn ]\n"
- " [ local | static | dynamic ] [ dst IPADDR ] [ vlan VID ]\n"
- " [ port PORT] [ vni VNI ] [ via DEV ]\n"
+ " [ sticky ] [ local | static | dynamic ] [ dst IPADDR ]\n"
+ " [ vlan VID ] [ port PORT] [ vni VNI ] [ via DEV ]\n"
" bridge fdb [ show [ br BRDEV ] [ brport DEV ] [ vlan VID ] [ state STATE ] ]\n");
exit(-1);
}
@@ -101,6 +101,9 @@ static void fdb_print_flags(FILE *fp, unsigned int flags)
if (flags & NTF_MASTER)
print_string(PRINT_ANY, NULL, "%s ", "master");
+ if (flags & NTF_STICKY)
+ print_string(PRINT_ANY, NULL, "%s ", "sticky");
+
close_json_array(PRINT_JSON, NULL);
}
@@ -414,6 +417,8 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
req.ndm.ndm_flags |= NTF_USE;
} else if (matches(*argv, "extern_learn") == 0) {
req.ndm.ndm_flags |= NTF_EXT_LEARNED;
+ } else if (matches(*argv, "sticky") == 0) {
+ req.ndm.ndm_flags |= NTF_STICKY;
} else {
if (strcmp(*argv, "to") == 0)
NEXT_ARG();
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 53cd3d0a3d93..c0415bc646df 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -63,7 +63,7 @@ bridge \- show / manipulate bridge addresses and devices
.B dev
.IR DEV " { "
.BR local " | " static " | " dynamic " } [ "
-.BR self " ] [ " master " ] [ " router " ] [ " use " ] [ " extern_learn " ] [ "
+.BR self " ] [ " master " ] [ " router " ] [ " use " ] [ " extern_learn " ] [ " sticky " ] [ "
.B dst
.IR IPADDR " ] [ "
.B vni
@@ -448,6 +448,10 @@ indicate to the kernel that an entry was hardware or user-space
controller learnt dynamic entry. Kernel will not age such an entry.
.sp
+.B sticky
+- this entry will not change its port due to learning.
+.sp
+
.in -8
The next command line parameters apply only
when the specified device
--
2.11.0
^ permalink raw reply related
* [PATCH net-next] net: nixge: Address compiler warnings when building for i386
From: Moritz Fischer @ 2018-09-27 19:48 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, keescook, davem, moritz.fischer, f.fainelli,
alex.williams, Moritz Fischer, Arnd Bergmann
Address compiler warning reported by kbuild autobuilders
when building for i386 as a result of dma_addr_t size on
different architectures.
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
Fixes: 7e8d5755be0e ("net: nixge: Add support for 64-bit platforms")
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/ni/nixge.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 74cf52e3fb09..0611f2335b4a 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -127,8 +127,8 @@ struct nixge_hw_dma_bd {
#ifdef CONFIG_PHYS_ADDR_T_64BIT
#define nixge_hw_dma_bd_set_addr(bd, field, addr) \
do { \
- (bd)->field##_lo = lower_32_bits(((u64)addr)); \
- (bd)->field##_hi = upper_32_bits(((u64)addr)); \
+ (bd)->field##_lo = lower_32_bits((addr)); \
+ (bd)->field##_hi = upper_32_bits((addr)); \
} while (0)
#else
#define nixge_hw_dma_bd_set_addr(bd, field, addr) \
@@ -251,7 +251,7 @@ static void nixge_hw_dma_bd_release(struct net_device *ndev)
NIXGE_MAX_JUMBO_FRAME_SIZE,
DMA_FROM_DEVICE);
- skb = (struct sk_buff *)
+ skb = (struct sk_buff *)(uintptr_t)
nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
sw_id_offset);
dev_kfree_skb(skb);
@@ -323,7 +323,7 @@ static int nixge_hw_dma_bd_init(struct net_device *ndev)
if (!skb)
goto out;
- nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
+ nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], (uintptr_t)skb);
phys = dma_map_single(ndev->dev.parent, skb->data,
NIXGE_MAX_JUMBO_FRAME_SIZE,
DMA_FROM_DEVICE);
@@ -601,8 +601,8 @@ static int nixge_recv(struct net_device *ndev, int budget)
tail_p = priv->rx_bd_p + sizeof(*priv->rx_bd_v) *
priv->rx_bd_ci;
- skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p,
- sw_id_offset);
+ skb = (struct sk_buff *)(uintptr_t)
+ nixge_hw_dma_bd_get_addr(cur_p, sw_id_offset);
length = cur_p->status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
if (length > NIXGE_MAX_JUMBO_FRAME_SIZE)
@@ -643,7 +643,7 @@ static int nixge_recv(struct net_device *ndev, int budget)
nixge_hw_dma_bd_set_phys(cur_p, cur_phys);
cur_p->cntrl = NIXGE_MAX_JUMBO_FRAME_SIZE;
cur_p->status = 0;
- nixge_hw_dma_bd_set_offset(cur_p, new_skb);
+ nixge_hw_dma_bd_set_offset(cur_p, (uintptr_t)new_skb);
++priv->rx_bd_ci;
priv->rx_bd_ci %= RX_BD_NUM;
--
2.19.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 2/2] dt-bindings: net: add support for Microchip KSZ9131 Ethernet PHY
From: Andrew Lunn @ 2018-09-27 19:45 UTC (permalink / raw)
To: Yuiko Oshino
Cc: davem, robh+dt, devicetree, f.fainelli, linux-kernel,
mark.rutland, m.felsch, Markus.Niebel, netdev, UNGLinuxDriver
In-Reply-To: <1538079415-6260-1-git-send-email-yuiko.oshino@microchip.com>
On Thu, Sep 27, 2018 at 04:16:55PM -0400, Yuiko Oshino wrote:
> Add support for Microchip Technology KSZ9131 10/100/1000 Ethernet PHY
>
> Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com>
> ---
> .../devicetree/bindings/net/micrel-ksz90x1.txt | 29 +++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> index e22d8cf..d23d14a 100644
> --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> @@ -1,4 +1,4 @@
> -Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
> +Micrel/Microchip KSZ9021/KSZ9031/KSZ9131 Gigabit Ethernet PHY
>
> Some boards require special tuning values, particularly when it comes
> to clock delays. You can specify clock delay values in the PHY OF
> @@ -64,6 +64,33 @@ KSZ9031:
> Attention: The link partner must be configurable as slave otherwise
> no link will be established.
>
> +KSZ9131:
> +
> + All skew control options are specified in picoseconds. The minimum
> + value is 0, and the maximum is property-dependent. The increment
> + step is 100ps. The default value is the neutral setting, so setting
> + rxc-skew-ps=<0> actually results in -700 picoseconds adjustment.
We also have:
KSZ9021:
All skew control options are specified in picoseconds. The minimum
value is 0, the maximum value is 3000, and it is incremented by 200ps
steps.
and
KSZ9031:
All skew control options are specified in picoseconds. The minimum
value is 0, and the maximum is property-dependent. The increment
step is 60ps. The default value is the neutral setting, so setting
rxc-skew-ps=<0> actually results in -900 picoseconds adjustment.
So this is the third meaning of 0.
How about making 0 mean 0. Have the range being -700 to 1800 and -700
to 800? KSZ9031 and KSZ9131 then use the same meaning of 0, with 0
actually meaning 0!
Andrew
^ permalink raw reply
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Eran Ben Elisha @ 2018-09-27 13:25 UTC (permalink / raw)
To: Neil Horman, Chris Preimesberger
Cc: linville@tuxdriver.com, netdev@vger.kernel.org
In-Reply-To: <20180926213436.GA4116@hmswarspite.think-freely.org>
> This is just a drive by guess, but I think this is a driver issue.
>
>
> Issue 1 seems like a red herring, cat doesn't modify output, nor does ethtool
> know if its output is going to a console or a pipe, its all the same. And given
> issue 2 (that the output of the thresholds, etc are spurriously changing and
> wrong), suggests that they are spurriously changing and wrong regardless of what
> cat does.
>
> That said, I think issue two is a problem with the mlx4 driver. Specifically
> that the driver is copying garbage data.
>
> The three ethtool functions at work here are:
> mlx4_en_get_module_info
> mlx4_en_get_module_eeprom
> mlx4_get_module_info
>
> When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> to determine the length of the eeprom, and that value will be either 256 or 512
> bytes. Lets assume that the value is 256 for the sake of argument
>
> Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> from hardware, again, passing in 256 as the size for the first call (theres a
> loop, but it will only get executed once in this scenario)
>
> mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
> return data is of type mlx4_mad_ifc, which has some front matter information and
> a data buffer that is 192 bytes long!
>
> A little further down in the function, size gets restricted if the buffer
> crosses a page boundary, but given that the size is 256 on the first call here,
> and offset is zero on the first call, we're not crossing anything, so size
> remains unchanged.
>
> The output mailbox buffer outmad->data (a 192 byte array), then gets cast to a
> sturt mlx4_cable_info structure, which has its own internal data buffer that is
> only 48 bytes long.
Hi guys,
Thanks for digging into it.
Here are some observations I found:
1. Chris system has CX4 (which is served by mlx5 driver), all analysis
by Neil was done over mlx4 driver (which serves the older generation of
NICs. e.h CX3Pro).
2. In general, MAD commands are limited to 192 bytes of data.
3. CableInfo MAD command info is limited to 48 Bytes.
4. First check that mlx4_get_module_info is having:
if (size > MODULE_INFO_MAX_READ)
size = MODULE_INFO_MAX_READ;
So this is the info that were missing in the analysis. x <= 48 is
also returned by this function. No trash copy or overrun. It is
expected from the caller(also inside mlx4) to recall with new offset in
order to fetch more data.
5. I reviewed mlx5 driver, and it have reading mechanism (small diff:
via MCIA register and not via MAD)
Both drivers read up to 256 bytes. 0-127 (from page 0). and 128-256
(from page 0). Driver is not capable of reading over 256 bytes currently.
looking on qsfp.c parser in ethtool.c (user space), I see an
uninitialized bug issue that have caused bug #1 + #2.
Applied it locally solved the issue (Not showing alarm data, which
should be expected as driver do not fill it).
diff --git a/qsfp.c b/qsfp.c
index 32e195d12dc0..d196aa1753de 100644
--- a/qsfp.c
+++ b/qsfp.c
@@ -671,7 +671,7 @@ static void sff8636_dom_parse(const __u8 *id, struct
sff_diags *sd)
static void sff8636_show_dom(const __u8 *id, __u32 eeprom_len)
{
- struct sff_diags sd;
+ struct sff_diags sd = {0};
char *rx_power_string = NULL;
char power_string[MAX_DESC_SIZE];
int i;
I will soon post a fix for it.
Thanks,
Eran
Thanks,
Eran
>
> The memcpy in this functionthen copies cable_info->data to the buffer that gets
> returned to ethtool, but it copies size bytes (256), even though the source data
> buffer is only 48 bytes long. That 48 byte array is embedded in the larger 192
> byte structure, so there won't be a panic on the overrun, but theres no telling
> what garbage is in the buffer beyond those first 48 bytes. Even if the
> remaining 144 bytes have valid eeprom data, its less than the required 256
> bytes. The additional copy may cause a panic, but if the buffer commonly bumps
> up against other allocated memory, that will go unnoticed.
>
> after the memcpy, mlx4_get_module_info just returns the size of the passed in
> buffer (256), and so the calling function thinks its work is done, and lets the
> kernel send back the buffer with garbage data to ethtool.
>
> I think the mlx4 guys have some work to do here.
>
> My $0.02
> Neil
>
^ permalink raw reply related
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Neil Horman @ 2018-09-27 13:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chris Preimesberger, linville@tuxdriver.com,
netdev@vger.kernel.org
In-Reply-To: <20180926215812.GD1251@lunn.ch>
On Wed, Sep 26, 2018 at 11:58:12PM +0200, Andrew Lunn wrote:
> > When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> > to determine the length of the eeprom, and that value will be either 256 or 512
> > bytes.
>
> So it sounds like QSFP modules using 8636 are not supported. You would
> expect a size to be one of 256, 384, 512 or 640.
>
> > Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> > read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> > from hardware, again, passing in 256 as the size for the first call (theres a
> > loop, but it will only get executed once in this scenario)
> >
> > mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> > eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
> > return data is of type mlx4_mad_ifc, which has some front matter information and
> > a data buffer that is 192 bytes long!
>
> Which suggests all SFP dumps are broken as well, not just QSFP.
>
No, not at all. Each driver that implements a get_eeprom ethtool method, is
capable of doing multiple reads at various offsets, and filling up the user
buffer with real data. The bug here is that the mellanox data structures are
not sized properly vis a vis the amount of eeprom data that user space might
expect, or more specifically that the driver isn't smart enough to do several
small reads to fill up the full sized request buffer
Neil
> Oh dear.
>
> Andrew
>
^ permalink raw reply
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: David Arendt @ 2018-09-27 19:33 UTC (permalink / raw)
To: Heiner Kallweit, Maciej S. Szmigiero, Gabriel C,
Ortwin Glück
Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <968f03ee-a271-242b-d90a-5c70ea72ce3b@gmail.com>
Hi,
Heiner Kallweit's patch seems to resolve the problem. The machine was
under high disk and network io pressure today and networking was
perfectly stable.
Bye,
David Arendt
On 9/25/18 11:03 PM, Heiner Kallweit wrote:
> On 19.09.2018 06:12, David Arendt wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>> I just applied it and the TxConfig register now contains 0x4f000f80.
>> The next day will show if it really solves the problem.
>>
>> Thanks in advance,
>> David Arendt
>>
>> On 9/19/18 12:30 AM, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
>>> On 18.09.2018 12:23, David Arendt wrote:
>>>> Hi,
>>>>
>>>> Today I had the network adapter problems again.
>>>> So the patch doesn't seem to change anything regarding this problem.
>>>> This week my time is unfortunately very limited, but I will try to
>>>> find some time next weekend to look a bit more into the issue.
>>> If the problem is caused by missing TXCFG_AUTO_FIFO bit in TxConfig,
>>> as the register difference would suggest, then you can try applying
>>> the following patch (hack) on top of 4.18.8 that is already patched
>>> with commit f74dd480cf4e:
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -5043,7 +5043,8 @@
>>> {
>>> /* Set DMA burst size and Interframe Gap Time */
>>> RTL_W32(tp, TxConfig, (TX_DMA_BURST << TxDMAShift) |
>>> - (InterFrameGap << TxInterFrameGapShift));
>>> + (InterFrameGap << TxInterFrameGapShift)
>>> + | TXCFG_AUTO_FIFO);
>>> }
>>>
>>> static void rtl_set_rx_max_size(struct rtl8169_private *tp)
>>>
>>> This hack will probably only work properly on RTL_GIGA_MAC_VER_40 or
>>> later NICs.
>>>
>>> Before running any tests please verify with "ethtool -d enp3s0" that
>>> TxConfig register now contains 0x4f000f80, as it did in the old,
>>> working driver version.
>>>
>>> If this does not help then a bisection will most likely be needed.
>>>
>>>> Thanks in advance,
>>>> David Arendt
>>> Maciej
>>
>>
> @Gabriel:
> Thanks for the hint, I wasn't fully aware of this thread.
> @Maciej:
> Thanks for the analysis.
>
> It seems that all chip versions from 34 (= RTL8168E-VL) with the
> exception of version 39 (= RTL8106E, first sub-version) need
> bit TXCFG_AUTO_FIFO.
>
> And indeed, due to reordering of calls this bit is overwritten.
> Following patch moves setting the bit from the chip-specific
> hw_start function to rtl_set_tx_config_registers().
>
> Whoever is hit by the issue and has the option to build a kernel,
> could you please test whether the patch fixes the issue for you?
>
> Thanks, Heiner
>
> ---
> drivers/net/ethernet/realtek/r8169.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index f882be49f..ae8abe900 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -4514,9 +4514,14 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
>
> static void rtl_set_tx_config_registers(struct rtl8169_private *tp)
> {
> - /* Set DMA burst size and Interframe Gap Time */
> - RTL_W32(tp, TxConfig, (TX_DMA_BURST << TxDMAShift) |
> - (InterFrameGap << TxInterFrameGapShift));
> + u32 val = TX_DMA_BURST << TxDMAShift |
> + InterFrameGap << TxInterFrameGapShift;
> +
> + if (tp->mac_version >= RTL_GIGA_MAC_VER_34 &&
> + tp->mac_version != RTL_GIGA_MAC_VER_39)
> + val |= TXCFG_AUTO_FIFO;
> +
> + RTL_W32(tp, TxConfig, val);
> }
>
> static void rtl_set_rx_max_size(struct rtl8169_private *tp)
> @@ -5011,7 +5016,6 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
>
> rtl_disable_clock_request(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
>
> /* Adjust EEE LED frequency */
> @@ -5045,7 +5049,6 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
>
> rtl_disable_clock_request(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
> RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) | PFM_EN);
> RTL_W32(tp, MISC, RTL_R32(tp, MISC) | PWM_EN);
> @@ -5090,8 +5093,6 @@ static void rtl_hw_start_8411(struct rtl8169_private *tp)
>
> static void rtl_hw_start_8168g(struct rtl8169_private *tp)
> {
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x38, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x48, ERIAR_EXGMAC);
> @@ -5189,8 +5190,6 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
> rtl_hw_aspm_clkreq_enable(tp, false);
> rtl_ephy_init(tp, e_info_8168h_1, ARRAY_SIZE(e_info_8168h_1));
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x38, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x48, ERIAR_EXGMAC);
> @@ -5273,8 +5272,6 @@ static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
> {
> rtl8168ep_stop_cmac(tp);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> -
> rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x2f, ERIAR_EXGMAC);
> rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x5f, ERIAR_EXGMAC);
> @@ -5596,7 +5593,6 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
> /* Force LAN exit from ASPM if Rx/Tx are not idle */
> RTL_W32(tp, FuncEvent, RTL_R32(tp, FuncEvent) | 0x002800);
>
> - RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
> RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
>
> rtl_ephy_init(tp, e_info_8402, ARRAY_SIZE(e_info_8402));
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] Add support for Microchip Technology KSZ9131 10/100/1000 Ethernet PHY
From: Florian Fainelli @ 2018-09-27 19:28 UTC (permalink / raw)
To: Yuiko Oshino, davem, robh+dt, devicetree, andrew
Cc: linux-kernel, mark.rutland, m.felsch, Markus.Niebel, netdev,
UNGLinuxDriver
In-Reply-To: <1538079344-6152-1-git-send-email-yuiko.oshino@microchip.com>
On 09/27/2018 01:15 PM, Yuiko Oshino wrote:
> This is the initial driver for Microchip KSZ9131 10/100/1000 Ethernet PHY
>
> v2:
> - Creating a series from two related patches.
When people give you Acked-by or Reviewed-by tags in prior versions, it
is usually a good practice to add them to your next version of the
patch submission. Also, your patches 1 and 2 did not show up as as reply
to this cover letter, while they should, please fix this if you ever
need to submit new patches in the future.
Thank you!
>
> Yuiko Oshino (2):
> net: phy: micrel: add Microchip KSZ9131 inital driver
> dt-bindings: net: add support for Microchip KSZ9131 Ethernet PHY
>
> .../devicetree/bindings/net/micrel-ksz90x1.txt | 29 +++++++++++++++++++-
> drivers/net/phy/micrel.c | 32 ++++++++++++++++++++--
> include/linux/micrel_phy.h | 1 +
> 3 files changed, 58 insertions(+), 4 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: test_bpf: add dummy dev->net for flow_dissector
From: Eric Dumazet @ 2018-09-27 12:58 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: daniel, kernel-team, Willem de Bruijn, Petar Penkov
In-Reply-To: <20180927071533.2290229-1-songliubraving@fb.com>
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
> + dev_net_set(&dev, &net);
This is yet another fake stuff that will break some day, so many other things would
need to be setup properly in a real "struct net"
What about using the current net_ns ?
dev_net_set(&dev, current->nsproxy->net_ns);
This might be &init_net in the context of test_bpf(), so maybe simply use &init_net
to clearly state that test_bpf is not net ns fully ready.
> + RCU_INIT_POINTER(net.flow_dissector_prog, NULL);
This really was not needed. Everything is already zero.
> skb->dev = &dev;
> skb->dev->ifindex = SKB_DEV_IFINDEX;
> skb->dev->type = SKB_DEV_TYPE;
>
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Phil Sutter @ 2018-09-27 12:53 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Stephen Hemminger, David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <CAJ3xEMiasPrGAQkY=uVxCaFG_An1cm+emJCc6jr76=xuLcQ=0Q@mail.gmail.com>
Hi,
On Thu, Sep 27, 2018 at 03:22:41PM +0300, Or Gerlitz wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> ip_flags nofirstfrag action drop && echo "success" || echo "failed"
>
> RTNETLINK answers: Operation not supported
> success
Hmm, I can't reproduce this. My HEAD is at the commit you mentioned:
| % sudo ./tc/tc filter add dev d0 protocol ip parent ffff: flower skip_sw ip_flags nofirstfrag action drop
| RTNETLINK answers: Operation not supported
| We have an error talking to the kernel, -1
| % echo $?
| 2
Are you sure you tested the right binary?
Cheers, Phil
^ permalink raw reply
* Re: [RFC PATCH iproute2-next V2] System specification exception API
From: Jiri Pirko @ 2018-09-27 12:47 UTC (permalink / raw)
To: Eran Ben Elisha
Cc: netdev, Jakub Kicinski, Jiri Pirko, Stephen Hemminger,
Andrew Lunn, Tobin C. Harding, Ariel Almog, Tal Alon
In-Reply-To: <1537962779-8910-1-git-send-email-eranbe@mellanox.com>
Wed, Sep 26, 2018 at 01:52:58PM CEST, eranbe@mellanox.com wrote:
>The exception spec is targeted for Real Time Alerting, in order to know when
>something bad had happened to a PCI device
>- Provide alert debug information
>- Self healing
>- If problem needs vendor support, provide a way to gather all needed debugging
> information.
>
>The exception mechanism contains condition checkers which sense for malfunction. Upon a condition hit,
>actions such as logs and correction can be taken.
>
>The condition checkers are divided into the following groups
>- Hardware - a checker which is triggered by the device due to
> malfunction.
>- Software - a checker which is triggered by the software due to
> malfunction.
What do you mean by a "software malfunction", a "FW malfunction"?
Also, I don't see this 2 groups in the man.
>Both groups of condition checkers can be triggered due to error event or due to a periodic check.
>
>Actions are the way to handle those events. Action can be in one of the
>following groups:
>- Dump - SW trace, SW dump, HW trace, HW dump
>- Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc)
>Actions can be performed by SW or HW.
>
>User is allowed to enable or disable condition checkers and its action mapping.
>
>This RFC man page patch describes the suggested API of devlink-exception in order
>to control conditions and actions.
>
>V2:
>* Renaming terms:
> health -> exception
> sensor -> condition
>* Remove reinit command and merge with action command.
>* Consmetics in grammer.
>
>Eran Ben Elisha (1):
> man: Add devlink exception man page
>
> man/man8/devlink-exception.8 | 158 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 158 insertions(+)
> create mode 100644 man/man8/devlink-exception.8
>
>--
>1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Fix build with B53_SRAB enabled and B53_SERDES=m
From: Florian Fainelli @ 2018-09-27 19:07 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Lunn, Vivien Didelot, David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20180927100244.692546-1-arnd@arndb.de>
On 09/27/2018 03:02 AM, Arnd Bergmann wrote:
> When B53_SERDES is a loadable module, a built-in srab driver still
> cannot reach it, so the previous fix is incomplete:
>
> b53_srab.c:(.text+0x3f4): undefined reference to `b53_serdes_init'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe64): undefined reference to `b53_serdes_link_state'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe74): undefined reference to `b53_serdes_link_set'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xe88): undefined reference to `b53_serdes_an_restart'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xea0): undefined reference to `b53_serdes_phylink_validate'
> drivers/net/dsa/b53/b53_srab.o:(.rodata+0xea4): undefined reference to `b53_serdes_config'
>
> Add a Kconfig dependency that forces srab to also be a module
> in this case, but allow it to be built-in when serdes is
> disabled or built-in.
>
> Fixes: 7a8c7f5c30f9 ("net: dsa: b53: Fix build with B53_SRAB enabled and not B53_SERDES")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
--
Florian
^ permalink raw reply
* Re: re iproute2 - don't return error on success fix
From: Stephen Hemminger @ 2018-09-27 12:39 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Ahern, Linux Netdev List, Roi Dayan
In-Reply-To: <CAJ3xEMiasPrGAQkY=uVxCaFG_An1cm+emJCc6jr76=xuLcQ=0Q@mail.gmail.com>
On Thu, 27 Sep 2018 15:22:41 +0300
Or Gerlitz <gerlitz.or@gmail.com> wrote:
> Something is still broken also after commit b45e300 "libnetlink: don't
> return error on success" - when error is returned, the error code is
> success..
>
> $ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
> ip_flags nofirstfrag action drop && echo "success" || echo "failed"
>
Yes this looks broken. Let me check.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: test_bpf: add dummy dev->net for flow_dissector
From: Eric Dumazet @ 2018-09-27 12:36 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: daniel, kernel-team, Willem de Bruijn, Petar Penkov
In-Reply-To: <20180927071533.2290229-1-songliubraving@fb.com>
On 09/27/2018 12:15 AM, Song Liu wrote:
> Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
> However, this is not true for test_bpf. As a result, test_bpf.ko crashes
> the system with the following stack trace:
>
>
> This patch fixes tes_bpf by adding a dummy struct net to the dummy dev.
>
> Fixes: d0e13a1488ad ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL")
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Petar Penkov <ppenkov@google.com>
> Signed-off-by: Song Liu <songliubraving@fb.com>
Reported-by: Eric Dumazet <edumazet@google.com>
Thanks.
^ permalink raw reply
* re iproute2 - don't return error on success fix
From: Or Gerlitz @ 2018-09-27 12:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Ahern, Linux Netdev List, Roi Dayan
Something is still broken also after commit b45e300 "libnetlink: don't
return error on success" - when error is returned, the error code is
success..
$ tc filter add dev enp33s0f0 protocol ip parent ffff: flower skip_sw
ip_flags nofirstfrag action drop && echo "success" || echo "failed"
RTNETLINK answers: Operation not supported
success
^ permalink raw reply
* [PATCH] dt-bindings: can: rcar_can: Add r8a7744 support
From: Biju Das @ 2018-09-27 12:08 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland
Cc: Biju Das, David S. Miller, linux-can, netdev, devicetree,
Simon Horman, Geert Uytterhoeven, Chris Paterson, Fabrizio Castro,
linux-renesas-soc
Document RZ/G1N (r8a7744) SoC specific bindings.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
---
This patch is tested against linux-next next-20180927
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33..cc43728 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -3,6 +3,7 @@ Renesas R-Car CAN controller Device Tree Bindings
Required properties:
- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
+ "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC.
"renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
"renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
"renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Eric Biggers @ 2018-09-27 18:29 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, linux-crypto, davem, gregkh
In-Reply-To: <20180925145622.29959-1-Jason@zx2c4.com>
On Tue, Sep 25, 2018 at 04:55:59PM +0200, Jason A. Donenfeld wrote:
>
> It is intended that this entire patch series enter the kernel through
> DaveM's net-next tree. Subsequently, WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Why is Herbert Xu's existing crypto tree being circumvented, especially for
future patches (the initial merge isn't quite as important as that's a one-time
event)? I like being able to check out cryptodev to test upcoming crypto
patches. And currently, changes to APIs, algorithms, tests, and implementations
all go through cryptodev, which is convenient for crypto developers.
Apparently, you're proposing that someone adding a new algorithm will now have
to submit the API portion to one maintainer (Herbert Xu) and the implementation
portion to another maintainer (you), and they'll go through separate git trees.
That's inconvenient for developers, and it seems that in practice you and
Herbert will be stepping on each other's toes a lot.
Can you please reach some kind of sane agreement with Herbert so that the
development process isn't fractured into two? Perhaps you could review patches,
but Herbert could still apply them?
I'm also wondering about the criteria for making additions and changes to
"Zinc". You mentioned before that one of the "advantages" of Zinc is that it
doesn't include "cipher modes from 90s cryptographers" -- what does that mean
exactly? You've also indicated before that you don't want people modifying the
Poly1305 implementations as they are too error-prone. Yet apparently it's fine
to change them yourself, e.g. when you added the part that converts the
accumulator from base 26 to base 32. I worry there may be double standards
here, and useful contributions could be blocked or discouraged in the future.
Can you please elaborate on your criteria for contributions to Zinc?
Also, will you allow algorithms that aren't up to modern security standards but
are needed for compatibility reasons, e.g. MD5, SHA-1, and DES? There are
existing standards, APIs, and data formats that use these "legacy" algorithms;
so implementations of them are often still needed, whether we like it or not.
And does it matter who designed the algorithms, e.g. do algorithms from Daniel
Bernstein get effectively a free pass, while algorithms from certain countries,
governments, or organizations are not allowed? E.g. wireless driver developers
may need the SM4 block cipher (which is now supported by the crypto API) as it's
specified in a Chinese wireless standard. Will you allow SM4 in Zinc? Or will
people have to submit some algorithms to Herbert and some to you due to
disagreements about what algorithms should be included?
- Eric
^ permalink raw reply
* [PATCH net-next] net: bridge: explicitly zero is_sticky in fdb_create
From: Nikolay Aleksandrov @ 2018-09-27 12:05 UTC (permalink / raw)
To: netdev; +Cc: roopa, davem, stephen, bridge, Nikolay Aleksandrov
We need to explicitly zero is_sticky when creating a new fdb, otherwise
we might get a stale value for a new entry.
Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_fdb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index a56ed7f2a3a3..74331690a390 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -504,6 +504,7 @@ static struct net_bridge_fdb_entry *fdb_create(struct net_bridge *br,
fdb->added_by_user = 0;
fdb->added_by_external_learn = 0;
fdb->offloaded = 0;
+ fdb->is_sticky = 0;
fdb->updated = fdb->used = jiffies;
if (rhashtable_lookup_insert_fast(&br->fdb_hash_tbl,
&fdb->rhnode,
--
2.11.0
^ permalink raw reply related
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