* Re: [B.A.T.M.A.N.] [RFC v4 00/19] batman-adv: netlink restructuring, part 2
From: Linus Lüssing @ 2019-02-06 19:08 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Cc: netdev, Jiri Pirko
In-Reply-To: <3348534.ntHJrxh9jc@sven-edge>
On Wed, Feb 06, 2019 at 07:20:25PM +0100, Sven Eckelmann wrote:
> On Tuesday, 5 February 2019 20.24.10 CET Linus Lüssing wrote:
> [...]
> > Another thought, if all this is too vague for now...
>
> Yes, it is to vague for the integration in netlink :D
>
> > what about
> > ommiting the BATADV_ATTR_MULTICAST_(MODE)_ENABLED for now and use
> > a reverse logic instead? Like
> > BATADV_ATTR_MULTICAST_FORCEFLOOD_ENABLED, defaulting to false.
>
> Would be fine for me. But it is rather odd to map this to the batctl
> multicast_mode. But the name is explaining quite well what it does
> and you can later rewrite the batctl part.
Ok, will rewrite the batctl part later then. And probably keep "batctl
mm" as a (hidden?) option for compatibility reasons?
Regards, Linus
^ permalink raw reply
* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: Eric Dumazet @ 2019-02-06 19:08 UTC (permalink / raw)
To: David Ahern, Hangbin Liu, netdev; +Cc: Stefano Brivio, David Miller
In-Reply-To: <9b7585c2-bab6-1c6c-7bab-9542406acf1a@gmail.com>
On 02/06/2019 10:54 AM, David Ahern wrote:
> On 2/6/19 4:51 AM, Hangbin Liu wrote:
>> When we add a new GENEVE device with IPv6 remote, checking only for
>> IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in kernel
>> cmd(ipv6.disable=1), which will cause a NULL pointer dereference.
>>
>> Reported-by: Jianlin Shi <jishi@redhat.com>
>> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>> ---
>> drivers/net/geneve.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>> index 58bbba8582b0..0658715581e3 100644
>> --- a/drivers/net/geneve.c
>> +++ b/drivers/net/geneve.c
>> @@ -1512,6 +1512,10 @@ static void geneve_link_config(struct net_device *dev,
>> }
>> #if IS_ENABLED(CONFIG_IPV6)
>> case AF_INET6: {
>> + struct inet6_dev *idev = in6_dev_get(dev);
>> + if (!idev)
>> + break;
>
> Since you don't need an idev reference rcu_access_pointer should be
> enough to say v6 is enabled on this device. ie., add a helper to check
> that rcu_access_pointer(dev->ip6_ptr) is non-NULL
>
I guess RTNL is held at this point, so we can use a lockdep enabled
accessor : __in6_dev_get()
^ permalink raw reply
* Re: [PATCH net-next v4 05/12] mlxsw: Implement ndo_get_port_parent_id()
From: Ido Schimmel @ 2019-02-06 19:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190206174546.23597-6-f.fainelli@gmail.com>
On Wed, Feb 06, 2019 at 09:45:39AM -0800, Florian Fainelli wrote:
> mlxsw implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
> of switchdev_ops eventually, ease that migration by implementing a
> ndo_get_port_parent_id() function which returns what
> switchdev_port_attr_get() would do.
>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: Stefano Brivio @ 2019-02-06 19:04 UTC (permalink / raw)
To: David Ahern; +Cc: Hangbin Liu, netdev, David Miller
In-Reply-To: <9b7585c2-bab6-1c6c-7bab-9542406acf1a@gmail.com>
On Wed, 6 Feb 2019 10:54:01 -0800
David Ahern <dsahern@gmail.com> wrote:
> On 2/6/19 4:51 AM, Hangbin Liu wrote:
> > When we add a new GENEVE device with IPv6 remote, checking only for
> > IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in kernel
> > cmd(ipv6.disable=1), which will cause a NULL pointer dereference.
> >
> > Reported-by: Jianlin Shi <jishi@redhat.com>
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > drivers/net/geneve.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> > index 58bbba8582b0..0658715581e3 100644
> > --- a/drivers/net/geneve.c
> > +++ b/drivers/net/geneve.c
> > @@ -1512,6 +1512,10 @@ static void geneve_link_config(struct net_device *dev,
> > }
> > #if IS_ENABLED(CONFIG_IPV6)
> > case AF_INET6: {
> > + struct inet6_dev *idev = in6_dev_get(dev);
> > + if (!idev)
> > + break;
>
> Since you don't need an idev reference rcu_access_pointer should be
> enough to say v6 is enabled on this device. ie., add a helper to check
> that rcu_access_pointer(dev->ip6_ptr) is non-NULL
I guess if (__in6_dev_get(dev)) is already good, no? This is called
under RTNL.
--
Stefano
^ permalink raw reply
* Re: [PATCH net] rxrpc: bad unlock balance in rxrpc_recvmsg
From: David Miller @ 2019-02-06 19:02 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, dhowells, syzkaller
In-Reply-To: <20190206.105548.67944335090885136.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Feb 2019 10:55:48 -0800 (PST)
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 4 Feb 2019 08:36:06 -0800
>
>> When either "goto wait_interrupted;" or "goto wait_error;"
>> paths are taken, socket lock has already been released.
>>
>> This patch fixes following syzbot splat :
> ...
>> Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: David Howells <dhowells@redhat.com>
>> Reported-by: syzbot <syzkaller@googlegroups.com>
>
> Series applied, thanks Eric.
Of course, I meant:
Patch applied and queued up for -stable.
Sometimes I guess I am on autopilot :-)
^ permalink raw reply
* Re: [PATCH net] rxrpc: bad unlock balance in rxrpc_recvmsg
From: David Miller @ 2019-02-06 18:55 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, dhowells, syzkaller
In-Reply-To: <20190204163606.236419-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 4 Feb 2019 08:36:06 -0800
> When either "goto wait_interrupted;" or "goto wait_error;"
> paths are taken, socket lock has already been released.
>
> This patch fixes following syzbot splat :
...
> Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Howells <dhowells@redhat.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net 1/2] geneve: should not call rt6_lookup() when ipv6 was disabled
From: David Ahern @ 2019-02-06 18:54 UTC (permalink / raw)
To: Hangbin Liu, netdev; +Cc: Stefano Brivio, David Miller
In-Reply-To: <20190206125111.5286-2-liuhangbin@gmail.com>
On 2/6/19 4:51 AM, Hangbin Liu wrote:
> When we add a new GENEVE device with IPv6 remote, checking only for
> IS_ENABLED(CONFIG_IPV6) is not enough as we may disable IPv6 in kernel
> cmd(ipv6.disable=1), which will cause a NULL pointer dereference.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> drivers/net/geneve.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index 58bbba8582b0..0658715581e3 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -1512,6 +1512,10 @@ static void geneve_link_config(struct net_device *dev,
> }
> #if IS_ENABLED(CONFIG_IPV6)
> case AF_INET6: {
> + struct inet6_dev *idev = in6_dev_get(dev);
> + if (!idev)
> + break;
Since you don't need an idev reference rcu_access_pointer should be
enough to say v6 is enabled on this device. ie., add a helper to check
that rcu_access_pointer(dev->ip6_ptr) is non-NULL
^ permalink raw reply
* [PATCH iproute2] tc: avoid problems with hard coded rate string length
From: Stephen Hemminger @ 2019-02-06 18:51 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
The parse_percent_rate function assumed the buffer was 20 characters.
Better to pass length in case the size ever changes.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
tc/tc_util.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index 1377b536e72f..4e289ae9c2ad 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -190,7 +190,8 @@ static const struct rate_suffix {
{ NULL }
};
-static int parse_percent_rate(char *rate, const char *str, const char *dev)
+static int parse_percent_rate(char *rate, size_t len,
+ const char *str, const char *dev)
{
long dev_mbit;
int ret;
@@ -221,8 +222,8 @@ static int parse_percent_rate(char *rate, const char *str, const char *dev)
rate_mbit = perc * dev_mbit;
- ret = snprintf(rate, 20, "%lf", rate_mbit);
- if (ret <= 0 || ret >= 20) {
+ ret = snprintf(rate, len, "%lf", rate_mbit);
+ if (ret <= 0 || ret >= len) {
fprintf(stderr, "Unable to parse calculated rate\n");
return -1;
}
@@ -239,7 +240,7 @@ int get_percent_rate(unsigned int *rate, const char *str, const char *dev)
{
char r_str[20];
- if (parse_percent_rate(r_str, str, dev))
+ if (parse_percent_rate(r_str, sizeof(r_str), str, dev))
return -1;
return get_rate(rate, r_str);
@@ -249,7 +250,7 @@ int get_percent_rate64(__u64 *rate, const char *str, const char *dev)
{
char r_str[20];
- if (parse_percent_rate(r_str, str, dev))
+ if (parse_percent_rate(r_str, sizeof(r_str), str, dev))
return -1;
return get_rate64(rate, r_str);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Using rates in bits when limits are specified in %
From: Stephen Hemminger @ 2019-02-06 18:51 UTC (permalink / raw)
To: Marcos Antonio Moraes; +Cc: netdev
In-Reply-To: <20190206180913.19381-1-marcos.antonio@digirati.com.br>
On Wed, 6 Feb 2019 16:09:13 -0200
Marcos Antonio Moraes <marcos.antonio@digirati.com.br> wrote:
> As /sys/class/net/<iface>/speed indicates a value in Mbits/sec, the
> transformation is necessary to create the correct limitations.
Not sure, if this is correct or not could you give an example?
This patch needs a signed-off-by and a a Fixes tag.
Also please put iproute2 in subject line:
[PATCH iproute2] tc: use bits not mbits/sec in rate percent.
Also, please rebase since I just found a memory leak in this function.
^ permalink raw reply
* Re: [PATCH net-next 0/4] dpaa2-eth: Driver updates
From: David Miller @ 2019-02-06 18:50 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei, brouer, ilias.apalodimas
In-Reply-To: <1549299625-28399-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Date: Mon, 4 Feb 2019 17:00:34 +0000
> First patch moves the driver to a page-per-frame memory model.
> The others are minor tweaks and optimizations.
Series applied, thanks.
^ permalink raw reply
* Re: [BUG] kernel panic 4.14.95 in kmem_cache_alloc / build_skb
From: Eric Dumazet @ 2019-02-06 18:48 UTC (permalink / raw)
To: Frank Wunderlich, netdev
In-Reply-To: <trinity-9b22aadc-4955-4b89-8975-e7497ee92f4c-1549474599369@3c-app-gmx-bs23>
On 02/06/2019 09:36 AM, Frank Wunderlich wrote:
> Hi,
>
> linux-net-mailinglist for reporting bugs seems not existing anymore and i have not found out the right one..."scripts/get_maintainer.pl -f ./include/linux/skbuff.h" shows only linux-kernel as mailing list which is not specific for network, so sorry, if i'm in the wrong mailinglist.
>
> i've recently noticed panics on my bananapi-r2 with kernel 4.14.95, but can't locate them in detail...all is pointing to kmem_cache_alloc and build_skb, but over complete different ways. so i guess it's network-related
>
> i currently don't know what is triggering this crashes, so i cannot reproduce them on my test-machine :(
>
> it's not only an oops...the machine stays still and have to be resettet, sometimes after an half hour running
>
> i had kernel 4.14.78 running before, so i think it's a change between these 2 Kernel-versions and no OS-related (debian-stretch) or Hardware-issue
>
> currently i test with 4.14.90, if it has same behaviour...at the moment it seems stable...
>
> i cannot test it with another kernel-branch (4.19+), because i need to test it on my productive machine till i find a way to reproduce it....maybe you can see a hint in stacktrace to guide me...at the moment crash occours unexpectely
>
> i looked through git-tree but did not found anything related
>
> regards Frank
>
> here my 3 recorded crash-logs...maybe you can point me in the right direction (reproduce/debug/fix):
Make sure to try 4.14.98, as I am guessing this has been fixed by :
dc489ad6a2f2fcebdaecb7b8532e0d02d272ac6a Fix "net: ipv4: do not handle duplicate fragments as overlapping"
^ permalink raw reply
* [PATCH iproute2] tc: fix memory leak in error path
From: Stephen Hemminger @ 2019-02-06 18:44 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
If value passed to parse_percent was not valid, it would
leak the dynamic allocation from sscanf.
Fixes: 927e3cfb52b5 ("tc: B.W limits can now be specified in %.")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
tc/tc_util.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index ab717890bb2a..1377b536e72f 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -195,7 +195,7 @@ static int parse_percent_rate(char *rate, const char *str, const char *dev)
long dev_mbit;
int ret;
double perc, rate_mbit;
- char *str_perc;
+ char *str_perc = NULL;
if (!dev[0]) {
fprintf(stderr, "No device specified; specify device to rate limit by percentage\n");
@@ -230,6 +230,7 @@ static int parse_percent_rate(char *rate, const char *str, const char *dev)
return 0;
malf:
+ free(str_perc);
fprintf(stderr, "Specified rate value could not be read or is malformed\n");
return -1;
}
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] net: phy: consider latched link-down status in polling mode
From: Heiner Kallweit @ 2019-02-06 18:39 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller
Cc: netdev@vger.kernel.org, Russell King - ARM Linux
The link status value latches link-down events. To get the current
status we read the register twice in genphy_update_link(). There's
a potential risk that we miss a link-down event in polling mode.
This may cause issues if the user e.g. connects his machine to a
different network.
On the other hand reading the latched value may cause issues in
interrupt mode. Following scenario:
- After boot link goes up
- phy_start() is called triggering an aneg restart, hence link goes
down and link-down info is latched.
- After aneg has finished link goes up and triggers an interrupt.
Interrupt handler reads link status, means it reads the latched
"link is down" info. But there won't be another interrupt as long
as link stays up, therefore phylib will never recognize that link
is up.
Deal with both scenarios by reading the register twice in interrupt
mode only.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 10 ++++++++--
drivers/net/phy/phy_device.c | 13 +++++++++----
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index c92d0fb7e..449f0f986 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -134,9 +134,15 @@ int genphy_c45_read_link(struct phy_device *phydev, u32 mmd_mask)
mmd_mask &= ~BIT(devad);
/* The link state is latched low so that momentary link
- * drops can be detected. Do not double-read the status
- * register if the link is down.
+ * drops can be detected. Do not double-read the status
+ * in polling mode to detect such short link drops.
*/
+ if (!phy_polling_mode(phydev)) {
+ val = phy_read_mmd(phydev, devad, MDIO_STAT1);
+ if (val < 0)
+ return val;
+ }
+
val = phy_read_mmd(phydev, devad, MDIO_STAT1);
if (val < 0)
return val;
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 891e0178b..d490cd2a8 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1729,10 +1729,15 @@ int genphy_update_link(struct phy_device *phydev)
{
int status;
- /* Do a fake read */
- status = phy_read(phydev, MII_BMSR);
- if (status < 0)
- return status;
+ /* The link state is latched low so that momentary link
+ * drops can be detected. Do not double-read the status
+ * in polling mode to detect such short link drops.
+ */
+ if (!phy_polling_mode(phydev)) {
+ status = phy_read(phydev, MII_BMSR);
+ if (status < 0)
+ return status;
+ }
/* Read link and autonegotiation status */
status = phy_read(phydev, MII_BMSR);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 00/12 net-next,v7] add flow_rule infrastructure
From: David Miller @ 2019-02-06 18:39 UTC (permalink / raw)
To: pablo
Cc: netdev, thomas.lendacky, f.fainelli, ariel.elior, michael.chan,
santosh, madalin.bucur, yisen.zhuang, salil.mehta,
jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch, jakub.kicinski,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ganeshgr, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
julia.lawall, john.fastabend, netfilter-devel, cphealy
In-Reply-To: <20190202115054.4880-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sat, 2 Feb 2019 12:50:42 +0100
> This patchset, as is, allows us to reuse the driver codebase to
> configure ACL hardware offloads for the ethtool_rxnfc and the TC flower
> interfaces. A few clients for this infrastructure are presented, such as
> the bcm_sf2 and the qede drivers, for reference. Moreover all of the
> existing drivers in the tree are converted to use this infrastructure.
>
> This patchset is re-using the existing flow dissector infrastructure
> that was introduced by Jiri Pirko et al. so the amount of abstractions
> that this patchset adds are minimal. Well, just a few wrapper structures
> for the selector side of the rules. And, in order to express actions,
> this patchset exposes an action API that is based on the existing TC
> action infrastructure and what existing drivers already support on that
> front.
>
> v7: This patchset is a rebase on top of the net-next tree, after
> addressing questions and feedback from driver developers in the
> last batch.
Ok, I've thought long and hard about this.
Applied to net-next, let's see where this goes.
I'll push this out after my build testing completes.
Thanks!
^ permalink raw reply
* Re: [PATCH net] net: dsa: mv88e6xxx: Fix counting of ATU violations
From: Vivien Didelot @ 2019-02-06 18:28 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <20190205230258.20543-1-andrew@lunn.ch>
Hi Andrew,
On Wed, 6 Feb 2019 00:02:58 +0100, Andrew Lunn <andrew@lunn.ch> wrote:
> The ATU port vector contains a bit per port of the switch. The code
> wrongly used it as a port number, and incremented a port counter. This
> resulted in the wrong interfaces counter being incremented, and
> potentially going off the end of the array of ports.
>
> Fix this by using the source port ID for the violation, which really
> is a port number.
>
> Reported-by: Chris Healy <Chris.Healy@zii.aero>
> Tested-by: Chris Healy <Chris.Healy@zii.aero>
> Fixes: 65f60e4582bd ("net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Hey I guess you forgot to Cc me on this one. FWIW:
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* [PATCH net-next] net: phy: fixed_phy: Fix fixed_phy not checking GPIO
From: Moritz Fischer @ 2019-02-06 18:10 UTC (permalink / raw)
To: netdev; +Cc: andrew, f.fainelli, hkallweit1, davem, Moritz Fischer
Fix fixed_phy not checking GPIO if no link_update callback
is registered.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
Hi all,
I've been trying to figure out where exactly this broke,
it must've been somewhere when the file was refactored
in connection with phylink?
Unfortunately I couldn't tell exactly so I don't have a
'Fixes' tag.
Should this also go be queued up for stable/5.0 if it is indeed
a bug?
Thanks,
Moritz
---
drivers/net/phy/fixed_phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index f136a23c1a35..d810f914aaa4 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -85,11 +85,11 @@ static int fixed_mdio_read(struct mii_bus *bus, int phy_addr, int reg_num)
s = read_seqcount_begin(&fp->seqcount);
fp->status.link = !fp->no_carrier;
/* Issue callback if user registered it. */
- if (fp->link_update) {
+ if (fp->link_update)
fp->link_update(fp->phydev->attached_dev,
&fp->status);
- fixed_phy_update(fp);
- }
+ /* Check the GPIO for change in status */
+ fixed_phy_update(fp);
state = fp->status;
} while (read_seqcount_retry(&fp->seqcount, s));
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v3 11/12] net: dsa: Implement ndo_get_port_parent_id()
From: Vivien Didelot @ 2019-02-06 18:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, Florian Fainelli, David S. Miller, Ido Schimmel,
open list, open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-12-f.fainelli@gmail.com>
Hi Florian,
On Tue, 5 Feb 2019 15:53:25 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> DSA implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
> of switchdev_ops eventually, ease that migration by implementing a
> ndo_get_port_parent_id() function which returns what
> switchdev_port_attr_get() would do.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> net/dsa/slave.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 91de3a663226..70395a0ae52e 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -362,18 +362,23 @@ static int dsa_slave_port_obj_del(struct net_device *dev,
> return err;
> }
>
> -static int dsa_slave_port_attr_get(struct net_device *dev,
> - struct switchdev_attr *attr)
> +static int dsa_slave_get_port_parent_id(struct net_device *dev,
> + struct netdev_phys_item_id *ppid)
> {
> struct dsa_port *dp = dsa_slave_to_port(dev);
> struct dsa_switch *ds = dp->ds;
> struct dsa_switch_tree *dst = ds->dst;
>
> + ppid->id_len = sizeof(dst->index);
> + memcpy(&ppid->id, &dst->index, ppid->id_len);
> +
> + return 0;
> +}
Finally this will give us a way to distinguish two ports with the same switch
and port IDs on a system with two disjoint switch trees, thanks!
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [RFC v4 00/19] batman-adv: netlink restructuring, part 2
From: Sven Eckelmann @ 2019-02-06 18:20 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: Linus Lüssing, netdev, Jiri Pirko
In-Reply-To: <20190205192409.GF777@otheros>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On Tuesday, 5 February 2019 20.24.10 CET Linus Lüssing wrote:
[...]
> Another thought, if all this is too vague for now...
Yes, it is to vague for the integration in netlink :D
> what about
> ommiting the BATADV_ATTR_MULTICAST_(MODE)_ENABLED for now and use
> a reverse logic instead? Like
> BATADV_ATTR_MULTICAST_FORCEFLOOD_ENABLED, defaulting to false.
Would be fine for me. But it is rather odd to map this to the batctl
multicast_mode. But the name is explaining quite well what it does
and you can later rewrite the batctl part.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net] net: ipv4: use a dedicated counter for icmp_v4 redirect packets
From: Lorenzo Bianconi @ 2019-02-06 18:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <cover.1549476789.git.lorenzo.bianconi@redhat.com>
According to the algorithm described in the comment block at the
beginning of ip_rt_send_redirect, the host should try to send
'ip_rt_redirect_number' ICMP redirect packets with an exponential
backoff and then stop sending them at all assuming that the destination
ignores redirects.
If the device has previously sent some ICMP error packets that are
rate-limited (e.g TTL expired) and continues to receive traffic,
the redirect packets will never be transmitted. This happens since
peer->rate_tokens will be typically greater than 'ip_rt_redirect_number'
and so it will never be reset even if the redirect silence timeout
(ip_rt_redirect_silence) has elapsed without receiving any packet
requiring redirects.
Fix it by using a dedicated counter for the number of ICMP redirect
packets that has been sent by the host
I have not been able to identify a given commit that introduced the
issue since ip_rt_send_redirect implements the same rate-limiting
algorithm from commit 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
include/net/inetpeer.h | 1 +
net/ipv4/inetpeer.c | 1 +
net/ipv4/route.c | 7 +++++--
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 00b5e7825508..74ff688568a0 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -39,6 +39,7 @@ struct inet_peer {
u32 metrics[RTAX_MAX];
u32 rate_tokens; /* rate limiting for ICMP */
+ u32 n_redirects;
unsigned long rate_last;
/*
* Once inet_peer is queued for deletion (refcnt == 0), following field
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index d757b9642d0d..be778599bfed 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -216,6 +216,7 @@ struct inet_peer *inet_getpeer(struct inet_peer_base *base,
atomic_set(&p->rid, 0);
p->metrics[RTAX_LOCK-1] = INETPEER_METRICS_NEW;
p->rate_tokens = 0;
+ p->n_redirects = 0;
/* 60*HZ is arbitrary, but chosen enough high so that the first
* calculation of tokens is at its maximum.
*/
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index ce92f73cf104..5163b64f8fb3 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -887,13 +887,15 @@ void ip_rt_send_redirect(struct sk_buff *skb)
/* No redirected packets during ip_rt_redirect_silence;
* reset the algorithm.
*/
- if (time_after(jiffies, peer->rate_last + ip_rt_redirect_silence))
+ if (time_after(jiffies, peer->rate_last + ip_rt_redirect_silence)) {
peer->rate_tokens = 0;
+ peer->n_redirects = 0;
+ }
/* Too many ignored redirects; do not send anything
* set dst.rate_last to the last seen redirected packet.
*/
- if (peer->rate_tokens >= ip_rt_redirect_number) {
+ if (peer->n_redirects >= ip_rt_redirect_number) {
peer->rate_last = jiffies;
goto out_put_peer;
}
@@ -910,6 +912,7 @@ void ip_rt_send_redirect(struct sk_buff *skb)
icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);
peer->rate_last = jiffies;
++peer->rate_tokens;
+ ++peer->n_redirects;
#ifdef CONFIG_IP_ROUTE_VERBOSE
if (log_martians &&
peer->rate_tokens == ip_rt_redirect_number)
--
2.20.1
^ permalink raw reply related
* [PATCH] Using rates in bits when limits are specified in %
From: Marcos Antonio Moraes @ 2019-02-06 18:09 UTC (permalink / raw)
To: netdev; +Cc: Marcos Antonio Moraes
As /sys/class/net/<iface>/speed indicates a value in Mbits/sec, the
transformation is necessary to create the correct limitations.
---
tc/tc_util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index ab717890..b82142ab 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -194,7 +194,7 @@ static int parse_percent_rate(char *rate, const char *str, const char *dev)
{
long dev_mbit;
int ret;
- double perc, rate_mbit;
+ double perc, rate_bit;
char *str_perc;
if (!dev[0]) {
@@ -219,9 +219,9 @@ static int parse_percent_rate(char *rate, const char *str, const char *dev)
return -1;
}
- rate_mbit = perc * dev_mbit;
+ rate_bit = perc * dev_mbit * 1000 * 1000;
- ret = snprintf(rate, 20, "%lf", rate_mbit);
+ ret = snprintf(rate, 20, "%lf", rate_bit);
if (ret <= 0 || ret >= 20) {
fprintf(stderr, "Unable to parse calculated rate\n");
return -1;
--
2.17.1
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-06 18:04 UTC (permalink / raw)
To: Emiliano Ingrassia, Martin Blumenstingl
Cc: Gpeppe.cavallaro, alexandre.torgue, linux-amlogic, netdev
In-Reply-To: <20190206103645.GA2482@ingrassia.epigenesys.com>
Hi,
yes i did reach 900MBits . maybe it was kernel 4.14 or 4.17. The 3.x
series was also ok.
I will pull latest 4.17 and test. If this doesnt work i go for 4.14
regards,
Simon
Am 06.02.2019 um 11:36 schrieb Emiliano Ingrassia:
> Hi Martin, Hi Simon,
>
> On Mon, Feb 04, 2019 at 03:34:41PM +0100, Martin Blumenstingl wrote:
>> On Thu, Jan 17, 2019 at 10:23 PM Simon Huelck <simonmail@gmx.de> wrote:
>> [...]
>>>>> I got problems with my ODROID c2 running on 4.19.16 ( and some releases
>>>>> earlier ). the stmmac / dwmac driver doesnt provide the 800M/900M
>>>>> performance that i was used to earlier.
>>>>>
> Simon, did you ever reach 1 Gbps full duplex speed?
> If yes, what was the kernel version did you use?
>
>>>>> Now im stuck near 550M/600M in the same environment. but what really
>>>>> confuses me that duplex does hurt even more.
>>>> interesting that you see this on the Odroid-C2 as well.
>>>> previously I have only observed it on an Odroid-C1
>>>>
>>>>> PC --- VLAN3 --> switch --VLAN3--> ODROID
>>>>>
>>>>> NAS <-- VLAN1 -- switch <-- VLAN1-- ODROID
>>>>>
>>>>>
>>>>> this means when im doing a iperf from PC to NAS, that my ODROID has load
>>>>> on RX/TX same time (duplex). this shouldnt be an issue , all is 1GBits
>>>>> FD. And in the past that wasnt an issue.
>> +Cc Emiliano who has seen a similar duplex issue on his Odroid-C1: [0]
>> (please note that all kernels prior to v5.1 with the pending patches
>> from [1] applied are only receiving data on RXD0 and RXD1 but not on
>> RXD2 and RXD3)
>>
>> Emiliano, can you confirm the duplex issue observed by Simon is
>> similar to the one you see on your Odroid-C1?
>>
> It could be but, if I understand correctly, Simon is limited in
> speed also in half duplex transmission (~550/600 Mbps), while we can
> reach at least 900 Mbps.
>
>>>>>
>>>>> Now what happens:
>>>>>
>>>>> - benchmark between PC - ODROID is roughly 550M
>>>>>
>>>>> - benchmark between NAS - ODROID is roughly 550M
>>>>>
>>>>> - benchmark between PC - NAS is only around 300M
>>>>>
>>>>>
>>>>> and like i said i was easliy able to hit 800 or even 900M to my NAS
>>>>> earlier. I applied some .dtb fixes for interrupt levels for the
>>>>> meson-gx.dtsi and meson-gxbb-odroid-c2.dtb, which will be mainlined ,
>>>>> but the effect stayed identical.
>>>> good that you have the interrupt patches already applied
>>>> I believe it don't fix any performance issues - it's a fix for the
>>>> Ethernet controller seemingly getting "stuck" (not processing data
>>>> anymore). however, that already rules out one potential issue
>>>>
>>>>> are you aware of this problem ? Earlier kernel versions were all
>>>>> perfectly fine and i stepped ( self compiled) kernel through all major
>>>>> releases since odroid c2 was mainlined.
>> Guiseppe, Alexandre: what kind of data do you need from us if we see
>> the speeds drop (in both directions) when we send and receive at the
>> same time?
>>
>> [...]
>>> the problem is that i dont have these kernel sources anymore :-(. but i
>>> can provide some testing and numbers. maybe i dig if i got these kernel
>>> configs somewhere around but i did not change much during migrating
>> do you remember the kernel version where it worked fine?
>>
>>> im using a zyxel gs1900-8 switch and a qnap ts231p , and as i said i
>>> didnt change my setup. i was able to hit 100MByte/s from my NAS , so
>>> close to the benchmarks of 900MBit/s
>> I typically only do small transfers or I have traffic only in one direction.
>> thus it's likely that I missed this in my own tests
>>
>>
>> Regards
>> Martin
>>
>>
>> [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009679.html
>> [1] https://patchwork.kernel.org/cover/10744905/
> Regards,
>
> Emiliano
^ permalink raw reply
* Re: [PATCH] mlx4_ib: Increase the timeout for CM cache
From: jackm @ 2019-02-06 18:02 UTC (permalink / raw)
To: Håkon Bugge
Cc: Jason Gunthorpe, netdev, OFED mailing list, rds-devel,
linux-kernel
In-Reply-To: <FF460501-80BA-44B9-AD59-84F64A338D67@oracle.com>
On Wed, 6 Feb 2019 16:40:14 +0100
Håkon Bugge <haakon.bugge@oracle.com> wrote:
> Jack,
>
> A major contributor to the long processing time in the PF driver
> proxying QP1 packets is:
>
> create_pv_resources
> -> ib_create_cq(ctx->ib_dev, mlx4_ib_tunnel_comp_handler,
> NULL, ctx, cq_size, 0);
>
> That is, comp_vector is zero.
>
> Due to commit 6ba1eb776461 ("IB/mlx4: Scatter CQs to different EQs"),
> the zero comp_vector has the intent of let the mlx4_core driver
> select the least used vector.
>
> But, in mlx4_ib_create_cq(), we have:
>
> pr_info("eq_table: %p\n", dev->eq_table);
> if (dev->eq_table) {
> vector = dev->eq_table[mlx4_choose_vector(dev->dev,
> vector, ibdev->num_comp_vectors)];
> }
>
> cq->vector = vector;
>
> and dev->eq_table is NULL, so all the CQs for the proxy QPs get
> comp_vector zero.
>
> I have to make some reservations, as this analysis is based on uek4,
> but I think the code here is equal upstream, but need to double check.
>
>
> Thxs, Håkon
>
Hi Hakon and Jason,
I was ill today (bad cold, took antihistamines all day, which knocked
me out).
I'll get to this tomorrow.
-Jack
^ permalink raw reply
* [PATCH v2 1/3] net/macb: bindings doc/trivial: fix documentation for sama5d3 10/100 interface
From: Nicolas Ferre @ 2019-02-06 17:56 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches, linux-arm-kernel,
David S . Miller, Rob Herring
Cc: linux-kernel, netdev, devicetree, Nicolas Ferre
This removes a line left while adding the correct compatibility string for
sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/macb.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 3e17ac1d5d58..f5c414b10e27 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -3,8 +3,7 @@
Required properties:
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
- Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
- available on sama5d3 SoCs.
+ Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/3] net: macb: add sam9x60-macb compatibility string
From: Nicolas Ferre @ 2019-02-06 17:56 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches, linux-arm-kernel,
David S . Miller, Rob Herring
Cc: linux-kernel, netdev, devicetree, Nicolas Ferre
In-Reply-To: <20190206175610.26773-1-nicolas.ferre@microchip.com>
Add a new compatibility string for this product. It's using
at91sam9260-macb layout but has a newer hardware revision: it's safer
to use its own string.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
v2: applies on top of next-20190206
drivers/net/ethernet/cadence/macb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2b2882615e8b..eaabe8c278ec 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3943,6 +3943,7 @@ static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,np4-macb", .data = &np4_config },
{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
{ .compatible = "cdns,gem", .data = &pc302gem_config },
+ { .compatible = "cdns,sam9x60-macb", .data = &at91sam9260_config },
{ .compatible = "atmel,sama5d2-gem", .data = &sama5d2_config },
{ .compatible = "atmel,sama5d3-gem", .data = &sama5d3_config },
{ .compatible = "atmel,sama5d3-macb", .data = &sama5d3macb_config },
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/3] net/macb: bindings doc: add sam9x60 binding
From: Nicolas Ferre @ 2019-02-06 17:56 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches, linux-arm-kernel,
David S . Miller, Rob Herring
Cc: linux-kernel, netdev, devicetree, Nicolas Ferre
In-Reply-To: <20190206175610.26773-1-nicolas.ferre@microchip.com>
Add the compatibility sting documentation for sam9x60 10/100 interface.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Hi Rob,
Your tag is missing for this patch.
Documentation/devicetree/bindings/net/macb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index f5c414b10e27..174f292d8a3e 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
+ Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC.
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
--
2.17.1
^ 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