* [PATCH net] ipv4: Add ICMPv6 support when parse route ipproto
From: Hangbin Liu @ 2019-02-25 7:47 UTC (permalink / raw)
To: netdev; +Cc: Roopa Prabhu, David S . Miller, Hangbin Liu
For ip rules, we need to use 'ipproto ipv6-icmp' to match ICMPv6 headers.
But for ip -6 route, currently we only support tcp, udp and icmp.
Add ICMPv6 support so we can match ipv6-icmp rules for route lookup.
Reported-by: Jianlin Shi <jishi@redhat.com>
Fixes: eacb9384a3fe ("ipv6: support sport, dport and ip_proto in RTM_GETROUTE")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/netlink.c b/net/ipv4/netlink.c
index f86bb4f06609..95601237521f 100644
--- a/net/ipv4/netlink.c
+++ b/net/ipv4/netlink.c
@@ -3,6 +3,7 @@
#include <linux/types.h>
#include <net/net_namespace.h>
#include <net/netlink.h>
+#include <linux/in6.h>
#include <net/ip.h>
int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
@@ -14,6 +15,7 @@ int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
case IPPROTO_TCP:
case IPPROTO_UDP:
case IPPROTO_ICMP:
+ case IPPROTO_ICMPV6:
return 0;
default:
NL_SET_ERR_MSG(extack, "Unsupported ip proto");
--
2.19.2
^ permalink raw reply related
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-02-25 8:00 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jian Shen,
Peng Li, Huazhong Tan
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Hi all,
In commit
a638b1d8cc87 ("net: hns3: fix get VF RSS issue")
Fixes tag
Fixes: 374ad291762a ("net: hns3: net: hns3: Add RSS general configuration support for VF")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h (%s)'
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] sit: use ipv6_mod_enabled to check if ipv6 is disabled
From: Hangbin Liu @ 2019-02-25 8:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stefano Brivio, David S . Miller, David Ahern
In-Reply-To: <7c0f5c9c-d918-de27-643d-416509576be4@gmail.com>
On Sun, Feb 24, 2019 at 08:24:51PM -0800, Eric Dumazet wrote:
>
>
> On 02/24/2019 08:12 PM, Hangbin Liu wrote:
> > ipv6_mod_enabled() is more safe and gentle to check if ipv6 is disabled
> > at running time.
> >
>
>
> Why is it better exactly ?
>
> IPv6 can be enabled on the host, but disabled per device
>
> /proc/sys/net/ipv6/conf/{name}/disable_ipv6
Sorry, it looks I didn't make it clear in the commit description.
This issue only occurs when IPv6 is disabled at boot time as there is
no IPv6 route entry. Disable ipv6 on specific interface is not affected.
So check ipv6_mod_enabled() is enough and we don't need to worry about
the rcu_read_lock or the dev status.
Should I update the commit description?
Thanks
Hangbin
>
>
> > Fixes: 173656accaf5 ("sit: check if IPv6 enabled before calling ip6_err_gen_icmpv6_unreach()")
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > net/ipv6/sit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index e8a1dabef803..eea1f19985a7 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -546,7 +546,7 @@ static int ipip6_err(struct sk_buff *skb, u32 info)
> > }
> >
> > err = 0;
> > - if (__in6_dev_get(skb->dev) &&
> > + if (ipv6_mod_enabled() &&
> > !ip6_err_gen_icmpv6_unreach(skb, iph->ihl * 4, type, data_len))
> > goto out;
> >
> >
^ permalink raw reply
* RE: [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Parshuram Raju Thombare @ 2019-02-25 8:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre@microchip.com, davem@davemloft.net,
netdev@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <20190223152304.GD10693@lunn.ch>
>> >On Fri, Feb 22, 2019 at 08:12:42PM +0000, Parshuram Thombare wrote:
>> >> This patch modify MDIO read/write functions to support
>> >> communication with C45 PHY in Cadence ethernet controller driver.
>> >
>> >Hi Parshuram
>> >
>> >Are all versions of the MDIO controller capable of doing C45?
>> >
>> > Andrew
>> Now driver support c22 and c45 PHY.
>> Are you suggesting to add check for C45 PHY using is_c45 in phydev ?
>
>You are unconditionally supporting C45. Are there versions of the hardware which
>don't actually support C45? You have this endless loop:
There is controller which don't support C45. I will add check for that using is_c45.
>
>+ /* wait for end of transfer */
>+ while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
>+ cpu_relax();
>
>If there is hardware which does not support C45, will this loop forever?
>
> Andrew
Yes, this bit is supposed to be set. I will add timeout here.
Regards,
Parshuram Thombare
^ permalink raw reply
* RE: [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
From: Parshuram Raju Thombare @ 2019-02-25 8:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre@microchip.com, davem@davemloft.net,
netdev@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <20190223152540.GE10693@lunn.ch>
>On Fri, Feb 22, 2019 at 08:12:42PM +0000, Parshuram Thombare wrote:
>> This patch modify MDIO read/write functions to support communication
>> with C45 PHY in Cadence ethernet controller driver.
>>
>> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>> ---
>> drivers/net/ethernet/cadence/macb.h | 15 +++++--
>> drivers/net/ethernet/cadence/macb_main.c | 61
>++++++++++++++++++++++++-----
>> 2 files changed, 61 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.h
>> b/drivers/net/ethernet/cadence/macb.h
>> index bed4ded..59c23e0 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -636,10 +636,17 @@
>> #define GEM_CLK_DIV96 5
>>
>> /* Constants for MAN register */
>> -#define MACB_MAN_SOF 1
>> -#define MACB_MAN_WRITE 1
>> -#define MACB_MAN_READ 2
>> -#define MACB_MAN_CODE 2
>> +#define MACB_MAN_C22_SOF 1
>> +#define MACB_MAN_C22_WRITE 1
>> +#define MACB_MAN_C22_READ 2
>> +#define MACB_MAN_C22_CODE 2
>> +
>> +#define MACB_MAN_C45_SOF 0
>> +#define MACB_MAN_C45_ADDR 0
>> +#define MACB_MAN_C45_WRITE 1
>> +#define MACB_MAN_C45_POST_READ_INCR 2
>> +#define MACB_MAN_C45_READ 3
>> +#define MACB_MAN_C45_CODE 2
>>
>> /* Capability mask bits */
>> #define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x00000001
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index 4f4f8e5..2494abf 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -323,11 +323,30 @@ static int macb_mdio_read(struct mii_bus *bus, int
>mii_id, int regnum)
>> struct macb *bp = bus->priv;
>> int value;
>>
>> - macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_SOF)
>> - | MACB_BF(RW, MACB_MAN_READ)
>> - | MACB_BF(PHYA, mii_id)
>> - | MACB_BF(REGA, regnum)
>> - | MACB_BF(CODE, MACB_MAN_CODE)));
>> + if (regnum & MII_ADDR_C45) {
>> + macb_writel(bp, MAN, (MACB_BF(SOF, MACB_MAN_C45_SOF)
>> + | MACB_BF(RW, MACB_MAN_C45_ADDR)
>> + | MACB_BF(PHYA, mii_id)
>> + | MACB_BF(REGA, (regnum >> 16) & 0x1F)
>> + | MACB_BF(DATA, regnum & 0xFFFF)
>> + | MACB_BF(CODE, MACB_MAN_C45_CODE)));
>> +
>> + /* wait for end of transfer */
>> + while (!MACB_BFEXT(IDLE, macb_readl(bp, NSR)))
>> + cpu_relax();
>
>You need a timeout here, and anywhere you wait for the hardware to complete.
>Try to make use of readx_poll_timeout() variants.
>
> Andrew
Yes, I will add timeout here.
Regards,
Parshuram Thombare
^ permalink raw reply
* RE: [PATCH 0/3] Cover letter: Add support for high speed MAC in Cadence controller driver
From: Parshuram Raju Thombare @ 2019-02-25 8:22 UTC (permalink / raw)
To: Florian Fainelli, nicolas.ferre@microchip.com,
davem@davemloft.net, netdev@vger.kernel.org, andrew@lunn.ch,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <a64e8266-a235-9999-708d-1a80051b5d4e@gmail.com>
>Hi,
>
>Le 2/22/19 à 12:11 PM, Parshuram Thombare a écrit :
>> Hello !
>>
>> This patch series contain changes to support high speed MAC and PCS in
>> Cadence ethernet controller driver.
>
>From patch submission perspective, your cover letter and individual patches do
>not appear as a reply to this cover letter which makes the threading broken in
>most mail clients. If you used git format-patch --cover-letter, this is handled
>transparently for you by git send-email.
>
Hi Florian,
I will make sure to do it correctly from next patch set.
>>
>> Here is the list of patches.
>> [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
>> This patch add support for PCS (for SGMII interface) and 2.5Gbps
>> MAC in Cadence ethernet controller driver.
>> [PATCH 2/3] net: ethernet: add c45 PHY support in MDIO read/write functions.
>> This patch modify MDIO read/write functions to support
>> communication with C45 PHY in Cadence ethernet controller driver.
>> [PATCH 3/3] net: ethernet: add support for high speed mac and usxgmii pcs
>> This patch add support for (10G) high speed mac, usxgmii pcs
>> and usxgmii interface in Cadence ethernet controller driver.
>>
>> Regards,
>> Parshuram Thombare
>>
>> Parshuram Thombare (3):
>> net: ethernet: add support for PCS and 2.5G speed
>> net: ethernet: add c45 PHY support in MDIO read/write functions.
>> net: ethernet: add support for high speed mac and usxgmii pcs
>>
>> drivers/net/ethernet/cadence/macb.h | 68 ++++++-
>> drivers/net/ethernet/cadence/macb_main.c | 309
>+++++++++++++++++++++++++----
>> include/linux/phy.h | 3 +
>> 3 files changed, 333 insertions(+), 47 deletions(-)
>>
>
>
>--
>Florian
Regards,
Parshuram Thombare
^ permalink raw reply
* Re: INFO: task hung in rtnetlink_rcv_msg
From: Jesper Dangaard Brouer @ 2019-02-25 8:39 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Joe Perches, syzbot, ast, christian, davem,
dsahern, hawk, idosch, john.fastabend, kafai, ktkhai,
linux-kernel, netdev, petrm, roopa, songliubraving,
syzkaller-bugs, xdp-newbies, yhs, brouer
In-Reply-To: <279c5bae-0b18-b03a-2858-4749e18afa26@iogearbox.net>
On Sat, 23 Feb 2019 01:47:00 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 02/22/2019 10:45 PM, Jakub Kicinski wrote:
> > On Fri, 22 Feb 2019 12:14:57 -0800, Joe Perches wrote:
> >> On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
> >>> Hi!
> >>>
> >>> Seems like something funny is going on with get_maintainer.pl since XDP
> >>> entry got added. We seem to have been CCed on:
> >>
> >> I suggest removing the MAINTAINERS line with
> >>
> >> K: xdp
> >>
> >> as xdp is a pretty generic file/patch content
> >> regex match for the K: type
> >>
> >> $ git grep --name-only xdp | wc -l
> >> 236
I'm unsure how K: works, but you grep definitely selects some wrong files.
I tried with "xdp_":
git grep --name-only xdp_
That does catch all the driver that have XDP support, which is the
point of the exercise (to catch drivers).
It does contain a couple of false-positives:
drivers/net/ethernet/neterion/vxge/vxge-traffic.c
drivers/thunderbolt/tb_msgs.h
drivers/thunderbolt/xdomain.c
sound/soc/codecs/rt5670.c
Via the pattern '[^a-z]xdp_' I'm only left with the thunderbolt
false-positive, as it have a data struct's called tb_xdp_*.
> >> Rather more files than desired.
> >>
> >> The N: match is dubious too.
> >>
> >> It's generally better to have specific lists of
> >> maintained file patterns rather than using the
> >> K: and N: pattern matches.
> >>
> >> ---
> >> MAINTAINERS | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index d7ad97b235ec..aa703e2cb882 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -16970,7 +16970,6 @@ F: include/net/xdp.h
> >> F: kernel/bpf/devmap.c
> >> F: kernel/bpf/cpumap.c
> >> F: include/trace/events/xdp.h
> >> -K: xdp
> >> N: xdp
> >>
> >> XDP SOCKETS (AF_XDP)
> >
> > Thanks for the explanation, at least now I know why it happens! :)
> > I'll leave it to Daniel to decide if we really need it removed,
> > so far the false positives weren't overwhelming, just surprising.
>
> No strong opinion. I've seen this K+N pattern in a number of places
> in the maintainers file. I'm fine either way if it gets too noisy. :)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net v2] af_packet: fix raw sockets over 6in4 tunnel
From: Nicolas Dichtel @ 2019-02-25 8:55 UTC (permalink / raw)
To: Willem de Bruijn, David Miller
Cc: Sasha Levin, Network Development, Willem de Bruijn,
Maxim Mikityanskiy
In-Reply-To: <CAF=yD-LDWfdOZoGzZmTUSNVeKVzcWf9KGbiW4yHV0S0gR_bPzA@mail.gmail.com>
Le 23/02/2019 à 00:53, Willem de Bruijn a écrit :
> On Fri, Feb 22, 2019 at 2:50 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
>> Date: Wed, 20 Feb 2019 13:39:23 -0500
>>
>>> On Mon, Feb 18, 2019 at 1:50 PM Sasha Levin <sashal@kernel.org> wrote:
>>>> Should this go to -stable as well? The patch it fixes is in 4.20.
>>>
>>> I believe so. It was also backported to 4.19 stable.
>>
>> It's queued up now.
>
> Thanks David!
>
Thanks all and sorry for the late reply, I was off last week.
Regards,
Nicolas
^ permalink raw reply
* RE: [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
From: Parshuram Raju Thombare @ 2019-02-25 9:11 UTC (permalink / raw)
To: Florian Fainelli, nicolas.ferre@microchip.com,
davem@davemloft.net, netdev@vger.kernel.org, andrew@lunn.ch,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Piotr Sroka, Jan Kotas
In-Reply-To: <673edcd1-9ea5-9efe-1f66-3f8ea8d3f092@gmail.com>
>Le 2/22/19 à 12:12 PM, Parshuram Thombare a écrit :
>> This patch add support for PCS (for SGMII interface) and 2.5Gbps MAC
>> in Cadence ethernet controller driver.
>
>At a high level you don't seem to be making use of PHYLINK so which 2.5Gbps
>interfaces do you actually support?
>
New ethernet controller have MAC which support 2.5G speed.
Also there is addition of PCS and SGMII interface.
>>
>> Signed-off-by: Parshuram Thombare <pthombar@cadence.com>
>> ---
>
>[snip]
>
>> @@ -361,26 +361,50 @@ static int macb_mdio_write(struct mii_bus *bus, int
>mii_id, int regnum,
>> * macb_set_tx_clk() - Set a clock to a new frequency
>> * @clk Pointer to the clock to change
>> * @rate New frequency in Hz
>> + * @interafce Phy interface
>
>Typo: @interface and this is an unrelated change.
>
>> * @dev Pointer to the struct net_device
>> */
>> -static void macb_set_tx_clk(struct clk *clk, int speed, struct
>> net_device *dev)
>> +static void macb_set_tx_clk(struct clk *clk, int speed,
>> + phy_interface_t interface, struct net_device *dev)
>> {
>> long ferr, rate, rate_rounded;
>>
>> if (!clk)
>> return;
>>
>> - switch (speed) {
>> - case SPEED_10:
>> + if (interface == PHY_INTERFACE_MODE_GMII ||
>> + interface == PHY_INTERFACE_MODE_MII) {
>> + switch (speed) {
>> + case SPEED_10:> rate = 2500000;
>
>You need to add one tab to align rate and break.
Do you mean a tab each for rate and break lines ?
All switch statements are aligned at a tab. I am not sure how does case and rate got on same line.
>
>> break;
>> - case SPEED_100:
>> + case SPEED_100:
>> rate = 25000000;
>> break;
>> - case SPEED_1000:
>> + case SPEED_1000:
>> rate = 125000000;
>> break;
>> - default:
>> + default:
>> + return;
>> + }
>> + } else if (interface == PHY_INTERFACE_MODE_SGMII) {
>> + switch (speed) {
>> + case SPEED_10:
>> + rate = 1250000;
>> + break;
>> + case SPEED_100:
>> + rate = 12500000;
>> + break;
>> + case SPEED_1000:
>> + rate = 125000000;
>> + break;
>> + case SPEED_2500:
>> + rate = 312500000;
>> + break;
>> + default:
>> + return;
>
>The indentation is broken here and you can greatly simplify this with a simple
>function that returns speed * 1250 and does an initial check for unsupported
>speeds.
>
I ran checkpatch.pl and all indentation issues were cleared. But I think having function
is better option, I will make that change.
>> + }
>> + } else {
>> return;
>> }
>>
>> @@ -410,30 +434,49 @@ static void macb_handle_link_change(struct
>> net_device *dev)
>>
>> spin_lock_irqsave(&bp->lock, flags);
>>
>> - if (phydev->link) {
>> - if ((bp->speed != phydev->speed) ||
>> - (bp->duplex != phydev->duplex)) {
>> - u32 reg;
>> -
>> - reg = macb_readl(bp, NCFGR);
>> - reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
>> - if (macb_is_gem(bp))
>> - reg &= ~GEM_BIT(GBE);
>> + if (phydev->link && (bp->speed != phydev->speed ||
>> + bp->duplex != phydev->duplex)) {
>> + u32 reg;
>>
>> - if (phydev->duplex)
>> - reg |= MACB_BIT(FD);
>> + reg = macb_readl(bp, NCFGR);
>> + reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
>> + if (macb_is_gem(bp))
>> + reg &= ~GEM_BIT(GBE);
>> + if (phydev->duplex)
>> + reg |= MACB_BIT(FD);
>> + macb_or_gem_writel(bp, NCFGR, reg);
>> +
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
>> + (phydev->speed == SPEED_1000 ||
>> + phydev->speed == SPEED_2500)) {
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
>> + reg = gem_readl(bp, NCR) &
>> + ~GEM_BIT(TWO_PT_FIVE_GIG);
>> + gem_writel(bp, NCR, reg);
>> + }
>
>If you are making correct use of the capabilities then there is no point in re-
>checking them here. If you allowed the MAC to advertise 2.5Gbps then it is de-
>facto SGMII capable.
PHY_INTERFACE_MODE_SGMII is selected only on the basis of presence of PCS.
This additional check is to make sure PHY also support 1G/2.5G.
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED
>&&
>> + phydev->speed == SPEED_2500)
>> + gem_writel(bp, NCR, gem_readl(bp, NCR) |
>> + GEM_BIT(TWO_PT_FIVE_GIG));
>> + } else if (phydev->speed == SPEED_1000) {
>> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> + } else {
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
>{
>> + reg = gem_readl(bp, NCFGR);
>> + reg &= ~(GEM_BIT(SGMIIEN) |
>GEM_BIT(PCSSEL));
>> + gem_writel(bp, NCFGR, reg);
>> + }
>> if (phydev->speed == SPEED_100)
>> - reg |= MACB_BIT(SPD);
>> - if (phydev->speed == SPEED_1000 &&
>> - bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> - reg |= GEM_BIT(GBE);
>> -
>> - macb_or_gem_writel(bp, NCFGR, reg);
>> -
>> - bp->speed = phydev->speed;
>> - bp->duplex = phydev->duplex;
>> - status_change = 1;
>> + macb_writel(bp, NCFGR, MACB_BIT(SPD) |
>> + macb_readl(bp, NCFGR));
>> }
>
>There is a lot of repetition while setting the GBE bit which always set based on
>speed == 1000 irrespective of the mode, so take that part out of the if () else if ()
>else () clauses.
>
Ok, I will change it.
>> +
>> + bp->speed = phydev->speed;
>> + bp->duplex = phydev->duplex;
>> + status_change = 1;
>> }
>>
>> if (phydev->link != bp->link) {
>> @@ -453,7 +496,8 @@ static void macb_handle_link_change(struct net_device
>*dev)
>> /* Update the TX clock rate if and only if the link is
>> * up and there has been a link change.
>> */
>> - macb_set_tx_clk(bp->tx_clk, phydev->speed, dev);
>> + macb_set_tx_clk(bp->tx_clk, phydev->speed,
>> + bp->phy_interface, dev);
>>
>> netif_carrier_on(dev);
>> netdev_info(dev, "link up (%d/%s)\n", @@ -543,10
>+587,16 @@ static
>> int macb_mii_probe(struct net_device *dev)
>> }
>>
>> /* mask with MAC supported features */
>> - if (macb_is_gem(bp) && bp->caps &
>MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> - phy_set_max_speed(phydev, SPEED_1000);
>> - else
>> - phy_set_max_speed(phydev, SPEED_100);
>> + if (macb_is_gem(bp)) {
>
>You have changed the previous logic that also checked for
>MACB_CAPS_GIGABIT_MODE_AVAILABLE, why?
My understanding is all GEM (ID >= 0x2) support GIGABIT mode.
Was there any other reason for this check ?
>> + linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
>> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
>> +
> linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
>> + phydev->supported);
>> + } else {
>> + linkmode_copy(phydev->supported, PHY_BASIC_FEATURES);
>> + }
>> +
>> + linkmode_copy(phydev->advertising, phydev->supported);
>>
>> if (bp->caps & MACB_CAPS_NO_GIGABIT_HALF)
>> phy_remove_link_mode(phydev,
>> @@ -2217,8 +2267,6 @@ static void macb_init_hw(struct macb *bp)
>> macb_set_hwaddr(bp);
>>
>> config = macb_mdc_clk_div(bp);
>> - if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
>> - config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL);
>> config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data
>aligned */
>> config |= MACB_BIT(PAE); /* PAuse Enable */
>> config |= MACB_BIT(DRFCS); /* Discard Rx FCS */
>> @@ -3255,6 +3303,23 @@ static void macb_configure_caps(struct macb *bp,
>> dcfg = gem_readl(bp, DCFG1);
>> if (GEM_BFEXT(IRQCOR, dcfg) == 0)
>> bp->caps |= MACB_CAPS_ISR_CLEAR_ON_WRITE;
>> + if (GEM_BFEXT(NO_PCS, dcfg) == 0)
>> + bp->caps |= MACB_CAPS_PCS;
>> + switch (MACB_BFEXT(IDNUM, macb_readl(bp, MID))) {
>> + case MACB_GEM7016_IDNUM:
>> + case MACB_GEM7017_IDNUM:
>> + case MACB_GEM7017A_IDNUM:
>> + case MACB_GEM7020_IDNUM:
>> + case MACB_GEM7021_IDNUM:
>> + case MACB_GEM7021A_IDNUM:
>> + case MACB_GEM7022_IDNUM:
>> + if (bp->caps & MACB_CAPS_PCS)
>> + bp->caps |= MACB_CAPS_TWO_PT_FIVE_GIG_SPEED;
>> + break;
>> +
>> + default:
>> + break;
>> + }
>> dcfg = gem_readl(bp, DCFG2);
>> if ((dcfg & (GEM_BIT(RX_PKT_BUFF) | GEM_BIT(TX_PKT_BUFF)))
>== 0)
>> bp->caps |= MACB_CAPS_FIFO_MODE;
>> @@ -4110,7 +4175,28 @@ static int macb_probe(struct platform_device
>*pdev)
>> else
>> bp->phy_interface = PHY_INTERFACE_MODE_MII;
>> } else {
>> + switch (err) {
>> + case PHY_INTERFACE_MODE_SGMII:
>> + if (bp->caps & MACB_CAPS_PCS) {
>> + bp->phy_interface = PHY_INTERFACE_MODE_SGMII;
>> + break;
>> + }
>
>If SGMII was selected on a version of the IP that does not support it, then falling
>back to GMII or MII does not sound correct, this is a hard error that must be
>handled as such.
>--
>Florian
My intention was to continue (instead of failing) with whatever functionality is available.
Can we have some error message and continue with what is available ?
Regards,
Parshuram Thombare
^ permalink raw reply
* [PATCH] net: phy: dp83867: add soft reset delay
From: Max Uvarov @ 2019-02-25 9:15 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, andrew, Max Uvarov
Similar to dp83640 delay after soft reset
is needed to set up registers correctly.
Signed-off-by: Max Uvarov <muvarov@gmail.com>
---
drivers/net/phy/dp83867.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index ac8ba642d616..e1ec36c51511 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
+#include <linux/delay.h>
#include <dt-bindings/net/ti-dp83867.h>
@@ -347,6 +348,8 @@ static int dp83867_phy_reset(struct phy_device *phydev)
if (err < 0)
return err;
+ usleep_range(10, 20);
+
return dp83867_config_init(phydev);
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] tcp: detect use sendpage for slab-based objects
From: Vasily Averin @ 2019-02-25 9:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <CANn89iL-Pm2mC8kSapvDJd8TKB5hwEuBaRJ-PK9oJJb5w4eycA@mail.gmail.com>
On 2/22/19 7:39 PM, Eric Dumazet wrote:
> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>> Eric, could you please elaborate once again why tcp_sendpage() should not handle slab objects?
>
> Simply because SLAB has its own way to manage objects from a page, and
> does not care
> about the underlying page having its refcount elevated.
>
> ptr = kmalloc(xx)
> ... < here you can attempt cheating and add one to the underlying page>
> kfree(ptr); // SLAB does not care of page count, it will effectively
> put ptr in the free list.
>
> ptr2 = kmalloc(xx); //
>
> ptr2 can be the same than ptr (object was kfreed() earlier)
>
> This means that some other stuff will happily reuse the piece of
> memory that you wanted to use for zero-copy.
>
> This is a serious bug IMO, since this would allow for data corruption.
Thank you for explanation, however I still have some doubts.
Yes, it's strange to use sendpage if we want to send some small 8-bytes-long slab based object,
it's better to use sendmsg instead.
Yes, using of sendpage for slab-based objects can require special attention
to guarantee that slab object will not be freed until end of IO.
However IMO this should be guaranteed if caller uses sendmsg instead of sendpage.
Btw, as far as I understand in my example XFS did it correctly, submitted slab objects was kept in use
and seems they should be freed after end of IO, via end_io callback.
At least I did not found any bugs in sendpage callers.
And most important, it seems for me switch from sendpage to sendmsg doe not resolve the problem completely:
tcp_sendmsg_locked() under some conditions can merge neighbours slab-based tcp fragments,
so local tcp_recvmsg() can trigger BUG_ON in this case too.
Am I missed something probably?
>> There is known restriction: sendpage should not be called for pages with counter=0,
>> because internal put_page() releases the page. All sendpage callers I know have such check.
>>
>> However why they should add one check for PageSlab?
>>
>> Let me explain the problem once again:
>> I do not see any bugs neither in tcp nor in any sendpage callers,
>> there is false alert on receiving side that crashes correctly worked host.
>
> This is not a false alert, but a very fundamental issue.
>
> We can not mix kmalloc() and page fragments, this simply is buggy.
^ permalink raw reply
* Re: 32-bit Amlogic SoCs: avoid using Ethernet MAC addresses
From: Piero @ 2019-02-25 9:25 UTC (permalink / raw)
To: Martin Blumenstingl; +Cc: linux.amoon, linux-amlogic, netdev
In-Reply-To: <CAFBinCDRKJS-RXgVBDo2gjp_bU8Wmbhr+HGXNad4vCFyrvN_HA@mail.gmail.com>
Hi,
in my experience using armbian (so a different distribution) on
odroidc1 I see the mac is changing every time I do a new install but
it is kept constant between reboots: so it looks like something that
can be handled somewhere above the hardware-kernel layer.
*Ciao
Piero
Il giorno dom 24 feb 2019 alle ore 21:55 Martin Blumenstingl
<martin.blumenstingl@googlemail.com> ha scritto:
>
> I have seen Anand's your question in [0]:
> > only issue is I have is the each time their is random MAC address so I
> > get new IP from dhcp server.
> > How can I avoid this. I have tried to enable eFuse driver but with no success.
>
> u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
> pass it (via the .dtb) to the kernel.
> This requires an ethernet0 alias in the mainline .dts though, see [1]
> for and example.
>
> I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
> if it doesn't then there's a nvmem-cells binding for all Ethernet
> controllers: [2] (please note that the function implementing this
> binding was recently renamed: [3])
> as far as I can tell the stmmac driver doesn't support the nvmem-cells
> based binding yet
>
> Anand, if you want to work on this: feel free to do so!
> I have the SDHC MMC driver and a discussion about the power-domain
> drivers on my TODO-list, so I'm pretty busy at the moment.
>
>
> Regards
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2019-February/010464.html
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c36209c46c4d162202b65eed2e66962ad8c3c1
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9217e566bdee4583d0a9ea4879c8f5e004886eac
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afa64a72b862a7a9d04f8d07fba632eaf06b23f8
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
Stupid is as stupid does.
Forrest Gump
^ permalink raw reply
* [PATCH] xfrm: correctly check policy index in verify_newpolicy_info
From: Yue Haibing @ 2019-02-25 9:27 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
Call Trace:
<IRQ> [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
<IRQ> [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
[<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
[<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
[<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
[<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
[<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
[<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
[<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
[<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
[<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
[<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
[<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
[<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
[<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
[<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
<EOI> [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
[<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
[<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
[<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
[<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
[<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
[<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
[<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
[<ffffffff8113e119>] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245
xfrm_add_policy calls verify_newpolicy_info to check user's policy info,
but it doest check policy index correcly, if the policy index(ex. 6) is great
than XFRM_POLICY_MAX which is 3 for now, the validation check will be bypassed.
It will trigger out of bounds access.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/xfrm/xfrm_user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a131f9f..c2de950 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1424,7 +1424,8 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p)
ret = verify_policy_dir(p->dir);
if (ret)
return ret;
- if (p->index && ((p->index & XFRM_POLICY_MAX) != p->dir))
+ if (p->index && (p->index > XFRM_POLICY_MAX &&
+ (p->index & XFRM_POLICY_MAX) != p->dir))
return -EINVAL;
return 0;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] tcp: detect use sendpage for slab-based objects
From: Vasily Averin @ 2019-02-25 9:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <56220566-0811-eabe-53f2-9fa625a58bbd@virtuozzo.com>
On 2/25/19 12:15 PM, Vasily Averin wrote:
> On 2/22/19 7:39 PM, Eric Dumazet wrote:
>> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>
>>> Eric, could you please elaborate once again why tcp_sendpage() should not handle slab objects?
>>
>> Simply because SLAB has its own way to manage objects from a page, and
>> does not care
>> about the underlying page having its refcount elevated.
>>
>> ptr = kmalloc(xx)
>> ... < here you can attempt cheating and add one to the underlying page>
>> kfree(ptr); // SLAB does not care of page count, it will effectively
>> put ptr in the free list.
>>
>> ptr2 = kmalloc(xx); //
>>
>> ptr2 can be the same than ptr (object was kfreed() earlier)
>>
>> This means that some other stuff will happily reuse the piece of
>> memory that you wanted to use for zero-copy.
>>
>> This is a serious bug IMO, since this would allow for data corruption.
>
> Thank you for explanation, however I still have some doubts.
>
> Yes, it's strange to use sendpage if we want to send some small 8-bytes-long slab based object,
> it's better to use sendmsg instead.
>
> Yes, using of sendpage for slab-based objects can require special attention
> to guarantee that slab object will not be freed until end of IO.
> However IMO this should be guaranteed if caller uses sendmsg instead of sendpage.
> Btw, as far as I understand in my example XFS did it correctly, submitted slab objects was kept in use
> and seems they should be freed after end of IO, via end_io callback.
> At least I did not found any bugs in sendpage callers.
>
> And most important, it seems for me switch from sendpage to sendmsg doe not resolve the problem completely:
> tcp_sendmsg_locked() under some conditions can merge neighbours slab-based tcp fragments,
> so local tcp_recvmsg() can trigger BUG_ON in this case too.
>
> Am I missed something probably?
Seems I missed that skb_copy_to_page_nocache() in tcp_sendpage_locked copies data from original slab object,
and merges fragments with copied data.
^ permalink raw reply
* Re: [PATCH] xfrm: correctly check policy index in verify_newpolicy_info
From: YueHaibing @ 2019-02-25 9:35 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20190225092704.26796-1-yuehaibing@huawei.com>
Pls ignore this, sorry
On 2019/2/25 17:27, Yue Haibing wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> UBSAN report this:
>
> UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
> index 6 is out of range for type 'unsigned int [6]'
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> 0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
> 0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
> ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
> Call Trace:
> <IRQ> [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
> <IRQ> [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
> [<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
> [<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
> [<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
> [<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
> [<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
> [<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
> [<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
> [<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
> [<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
> [<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
> [<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
> [<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
> [<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
> [<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
> <EOI> [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
> [<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
> [<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
> [<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
> [<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
> [<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
> [<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
> [<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
> [<ffffffff8113e119>] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245
>
> xfrm_add_policy calls verify_newpolicy_info to check user's policy info,
> but it doest check policy index correcly, if the policy index(ex. 6) is great
> than XFRM_POLICY_MAX which is 3 for now, the validation check will be bypassed.
> It will trigger out of bounds access.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> net/xfrm/xfrm_user.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index a131f9f..c2de950 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -1424,7 +1424,8 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p)
> ret = verify_policy_dir(p->dir);
> if (ret)
> return ret;
> - if (p->index && ((p->index & XFRM_POLICY_MAX) != p->dir))
> + if (p->index && (p->index > XFRM_POLICY_MAX &&
> + (p->index & XFRM_POLICY_MAX) != p->dir))
> return -EINVAL;
>
> return 0;
>
^ permalink raw reply
* [PATCH net-next] tcp: remove unused parameter of tcp_sacktag_bsearch()
From: Taehee Yoo @ 2019-02-25 9:42 UTC (permalink / raw)
To: davem, edumazet, netdev; +Cc: Taehee Yoo
parameter state in the tcp_sacktag_bsearch() is not used.
So, it can be removed.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
net/ipv4/tcp_input.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7a027dec649b..6ac274249961 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1574,9 +1574,7 @@ static struct sk_buff *tcp_sacktag_walk(struct sk_buff *skb, struct sock *sk,
return skb;
}
-static struct sk_buff *tcp_sacktag_bsearch(struct sock *sk,
- struct tcp_sacktag_state *state,
- u32 seq)
+static struct sk_buff *tcp_sacktag_bsearch(struct sock *sk, u32 seq)
{
struct rb_node *parent, **p = &sk->tcp_rtx_queue.rb_node;
struct sk_buff *skb;
@@ -1598,13 +1596,12 @@ static struct sk_buff *tcp_sacktag_bsearch(struct sock *sk,
}
static struct sk_buff *tcp_sacktag_skip(struct sk_buff *skb, struct sock *sk,
- struct tcp_sacktag_state *state,
u32 skip_to_seq)
{
if (skb && after(TCP_SKB_CB(skb)->seq, skip_to_seq))
return skb;
- return tcp_sacktag_bsearch(sk, state, skip_to_seq);
+ return tcp_sacktag_bsearch(sk, skip_to_seq);
}
static struct sk_buff *tcp_maybe_skipping_dsack(struct sk_buff *skb,
@@ -1617,7 +1614,7 @@ static struct sk_buff *tcp_maybe_skipping_dsack(struct sk_buff *skb,
return skb;
if (before(next_dup->start_seq, skip_to_seq)) {
- skb = tcp_sacktag_skip(skb, sk, state, next_dup->start_seq);
+ skb = tcp_sacktag_skip(skb, sk, next_dup->start_seq);
skb = tcp_sacktag_walk(skb, sk, NULL, state,
next_dup->start_seq, next_dup->end_seq,
1);
@@ -1758,8 +1755,7 @@ tcp_sacktag_write_queue(struct sock *sk, const struct sk_buff *ack_skb,
/* Head todo? */
if (before(start_seq, cache->start_seq)) {
- skb = tcp_sacktag_skip(skb, sk, state,
- start_seq);
+ skb = tcp_sacktag_skip(skb, sk, start_seq);
skb = tcp_sacktag_walk(skb, sk, next_dup,
state,
start_seq,
@@ -1785,7 +1781,7 @@ tcp_sacktag_write_queue(struct sock *sk, const struct sk_buff *ack_skb,
goto walk;
}
- skb = tcp_sacktag_skip(skb, sk, state, cache->end_seq);
+ skb = tcp_sacktag_skip(skb, sk, cache->end_seq);
/* Check overlap against next cached too (past this one already) */
cache++;
continue;
@@ -1796,7 +1792,7 @@ tcp_sacktag_write_queue(struct sock *sk, const struct sk_buff *ack_skb,
if (!skb)
break;
}
- skb = tcp_sacktag_skip(skb, sk, state, start_seq);
+ skb = tcp_sacktag_skip(skb, sk, start_seq);
walk:
skb = tcp_sacktag_walk(skb, sk, next_dup, state,
--
2.17.1
^ permalink raw reply related
* RE: [PATCH net] staging: fsl-dpaa2: ethsw: Add missing netdevice check
From: Ioana Ciornei @ 2019-02-25 9:43 UTC (permalink / raw)
To: Florian Fainelli, netdev@vger.kernel.org
Cc: Ioana Ciocoi Radulescu, Greg Kroah-Hartman,
open list:DPAA2 ETHERNET SWITCH DRIVER,
open list:STAGING SUBSYSTEM
In-Reply-To: <c9bd0756-2824-a2c2-24ad-a69dc41d9ac3@gmail.com>
> Subject: Re: [PATCH net] staging: fsl-dpaa2: ethsw: Add missing netdevice check
>
> Le 2/23/19 à 12:45 AM, Ioana Ciornei a écrit :
> >
> >> Subject: [PATCH net] staging: fsl-dpaa2: ethsw: Add missing netdevice
> >> check
> >>
> >> port_switchdev_event() does not check that the target network device
> >> is actually backed by the ethsw driver, this could be problematic in
> >> a stacked environment case.
> >>
> >
> > Just FYI, I sent a patch set containing a similar patch verifying if the netdev is
> backed by the ethsw:
> > https://lkml.org/lkml/2019/2/6/216
> >
> > I sent the entire patch set against the staging tree.
>
> Thank you. BTW do you have any plans for moving this driver out of staging? It
> looks pretty good to me to get promoted in tree, provided that you also have all
> the dependencies in place etc.
Driver dependencies such as the fsl-mc bus or the dpio driver are out of staging but not all the TODO items are yet implemented (most notably support for control traffic).
Do you think maybe we can move it now and submit directly to the netdev tree the other features?
Ioana C
^ permalink raw reply
* Re: [PATCH net-next 7/8] net: switchdev: Replace port attr set SDO with a notification
From: Ido Schimmel @ 2019-02-25 9:49 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <daaa3bb6-78b1-7c19-e2fd-6ec03d56201d@gmail.com>
On Sun, Feb 24, 2019 at 08:47:27AM -0800, Florian Fainelli wrote:
> Le 2/23/19 à 2:32 AM, Ido Schimmel a écrit :
> > On Fri, Feb 22, 2019 at 03:59:25PM -0800, Florian Fainelli wrote:
> >> - if (attr->flags & SWITCHDEV_F_NO_RECURSE)
> >> + if (attr & SWITCHDEV_F_DEFER)
> >> + rc = call_switchdev_blocking_notifiers(nt, dev,
> >> + &attr_info.info, NULL);
> >> + else
> >> + rc = call_switchdev_notifiers(nt, dev, &attr_info.info, NULL);
> >
> > I don't believe this is needed. You're calling this function from
> > switchdev_port_attr_set_now() which is always called from process
> > context. switchdev_port_attr_set() takes care of that. Similar to
> > switchdev_port_obj_add().
>
> Except for net/bridge/br_switchdev.c when we check the bridge port's
> flags support with PRE_BRIDGE_FLAGS. In that case we are executing from
> the caller (atomic) context and we can't defer otherwise that trumps the
> whole idea of being able to do a quick check and return that to the
> caller that we cannot support specific flags. How would you recommend
> approaching that?
In this case you can invoke call_switchdev_notifiers() directly from
br_switchdev_set_port_flag(). Eventually switchdev_port_attr_set() will
be gone and bridge code will invoke the notifiers directly.
^ permalink raw reply
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Toke Høiland-Jørgensen @ 2019-02-25 9:50 UTC (permalink / raw)
To: YueHaibing, QCA ath9k Development, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
In-Reply-To: <20190225033246.127410-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> writes:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
> variable 'acq' set but not used [-Wunused-but-set-variable]
>
> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
> and airtime APIs"). Also remove related variables.
Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
compiler warning for it. Anyway, nice catch :)
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
-Toke
^ permalink raw reply
* [PATCH v2] xfrm: correctly check policy index in verify_newpolicy_info
From: Yue Haibing @ 2019-02-25 9:56 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
UBSAN report this:
UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
Call Trace:
<IRQ> [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
<IRQ> [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
[<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
[<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
[<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
[<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
[<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
[<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
[<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
[<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
[<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
[<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
[<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
[<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
[<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
[<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
<EOI> [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
[<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
[<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
[<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
[<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
[<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
[<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
[<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
[<ffffffff8113e119>] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245
xfrm_add_policy calls verify_newpolicy_info to check user's policy info,
but it does not check policy index correcly, if the policy index(ex. 6) is great
than or equal to the twice of XFRM_POLICY_MAX (XFRM_POLICY_MAX = 3), it may pass
the check. Then __xfrm_policy_unlink use the index to access array policy_count
whose size is XFRM_POLICY_MAX * 2, triggering out of bounds access.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: respin the patch
---
net/xfrm/xfrm_user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a131f9f..60adacf 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1424,7 +1424,8 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p)
ret = verify_policy_dir(p->dir);
if (ret)
return ret;
- if (p->index && ((p->index & XFRM_POLICY_MAX) != p->dir))
+ if (p->index && ((p->index >= XFRM_POLICY_MAX * 2) ||
+ (p->index & XFRM_POLICY_MAX) != p->dir))
return -EINVAL;
return 0;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Kalle Valo @ 2019-02-25 10:03 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: YueHaibing, QCA ath9k Development, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <87lg24urgq.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> YueHaibing <yuehaibing@huawei.com> writes:
>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
>> variable 'acq' set but not used [-Wunused-but-set-variable]
>>
>> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
>> and airtime APIs"). Also remove related variables.
>
> Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
> compiler warning for it.
I think the warning is not enabled by default and you need to use W=1
Makefile variable to enable it.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 bpf-next 4/9] bpf: add bpf helper bpf_skb_ecn_set_ce
From: Daniel Borkmann @ 2019-02-25 10:10 UTC (permalink / raw)
To: Martin Lau
Cc: Lawrence Brakmo, netdev, Alexei Starovoitov, Eric Dumazet,
Kernel Team
In-Reply-To: <20190223073031.utnow4seviqyfqta@kafai-mbp.dhcp.thefacebook.com>
On 02/23/2019 08:30 AM, Martin Lau wrote:
> On Sat, Feb 23, 2019 at 02:14:26AM +0100, Daniel Borkmann wrote:
>> On 02/23/2019 02:06 AM, brakmo wrote:
>>> This patch adds a new bpf helper BPF_FUNC_skb_ecn_set_ce
>>> "int bpf_skb_ecn_set_ce(struct sk_buff *skb)". It is added to
>>> BPF_PROG_TYPE_CGROUP_SKB typed bpf_prog which currently can
>>> be attached to the ingress and egress path. The helper is needed
>>> because his type of bpf_prog cannot modify the skb directly.
>>>
>>> This helper is used to set the ECN field of ECN capable IP packets to ce
>>> (congestion encountered) in the IPv6 or IPv4 header of the skb. It can be
>>> used by a bpf_prog to manage egress or ingress network bandwdith limit
>>> per cgroupv2 by inducing an ECN response in the TCP sender.
>>> This works best when using DCTCP.
>>>
>>> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
>>> ---
>>> include/uapi/linux/bpf.h | 10 +++++++++-
>>> net/core/filter.c | 14 ++++++++++++++
>>> 2 files changed, 23 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>> index 95b5058fa945..fc646f3eaf9b 100644
>>> --- a/include/uapi/linux/bpf.h
>>> +++ b/include/uapi/linux/bpf.h
>>> @@ -2365,6 +2365,13 @@ union bpf_attr {
>>> * Make a tcp_sock enter CWR state.
>>> * Return
>>> * 0 on success, or a negative error in case of failure.
>>> + *
>>> + * int bpf_skb_ecn_set_ce(struct sk_buf *skb)
>>> + * Description
>>> + * Sets ECN of IP header to ce (congestion encountered) if
>>> + * current value is ect (ECN capable). Works with IPv6 and IPv4.
>>> + * Return
>>> + * 1 if set, 0 if not set.
>>> */
>>> #define __BPF_FUNC_MAPPER(FN) \
>>> FN(unspec), \
>>> @@ -2464,7 +2471,8 @@ union bpf_attr {
>>> FN(spin_unlock), \
>>> FN(sk_fullsock), \
>>> FN(tcp_sock), \
>>> - FN(tcp_enter_cwr),
>>> + FN(tcp_enter_cwr), \
>>> + FN(skb_ecn_set_ce),
>>>
>>> /* integer value in 'imm' field of BPF_CALL instruction selects which helper
>>> * function eBPF program intends to call
>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>> index ca57ef25279c..955369c6ed30 100644
>>> --- a/net/core/filter.c
>>> +++ b/net/core/filter.c
>>> @@ -5444,6 +5444,18 @@ static const struct bpf_func_proto bpf_tcp_enter_cwr_proto = {
>>> .ret_type = RET_INTEGER,
>>> .arg1_type = ARG_PTR_TO_TCP_SOCK,
>>> };
>>> +
>>> +BPF_CALL_1(bpf_skb_ecn_set_ce, struct sk_buff *, skb)
>>> +{
>>> + return INET_ECN_set_ce(skb);
>>
>> Hm, but as mentioned last time, don't we have to ensure here that skb
>> is writable (aka skb->data private to us before writing into it)?
> INET_ECN_set_ce(skb) is also called from a few net/sched/sch_*.c
> but I don't see how they ensure if a skb is writable.
>
> May be I have missed something there that can also be borrowed and
> reused here?
My understanding is that before doing any writes into skb, we should make
sure the data area is private to us (and offset in linear data). In tc BPF
(ingress, egress) we use bpf_try_make_writable() helper for this, others
like act_{pedit,skbmod} or ovs have similar logic before writing into skb,
note that in all these cases it's mostly about generic writes, so location
could also be L4, for example.
Difference of above helper compared to net/sched/sch_*.c instances could
be that it's i) for the qdisc case it's only on egress INET_ECN_set_ce()
and that there may be a convention that qdiscs specifically may mangle
it whereas the helper could be called on ingress and egress and confuse
other subsystems since they won't see original or race by seeing partially
updated (invalid) packet.
Eric, have a chance to clarify? Perhaps then would make sense to disallow
the helper in cgroup ingress path.
^ permalink raw reply
* [PATCH net-next v2 0/7] net: sched: pie: align PIE implementation with RFC 8033
From: Leslie Monis @ 2019-02-25 10:20 UTC (permalink / raw)
To: jhs; +Cc: netdev, dave, Leslie Monis
The current implementation of the PIE queuing discipline is according to the
IETF draft [http://tools.ietf.org/html/draft-pan-aqm-pie-00] and the paper
[PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem].
However, a lot of necessary modifications and enhancements have been proposed
in RFC 8033, which have not yet been incorporated in the source code of Linux.
This patch series helps in achieving the same.
Performance tests carried out using Flent [https://flent.org/]
Changes from v1 to v2:
- Excluded the patch setting PIE dynamically active/inactive as the test
results were unsatisfactory
- Fixed a scaling issue when adding more auto-tuning cases which caused
local variables to underflow
- Changed the long if/else chain to a loop as suggested by Stephen
- Changed the position of the accu_prob variable in the pie_vars
structure as recommended by Stephen
Mohit P. Tahiliani (7):
net: sched: pie: change value of QUEUE_THRESHOLD
net: sched: pie: change default value of pie_params->target
net: sched: pie: change default value of pie_params->tupdate
net: sched: pie: change initial value of pie_vars->burst_time
net: sched: pie: add more cases to auto-tune alpha and beta
net: sched: pie: add derandomization mechanism
net: sched: pie: update references
include/uapi/linux/pkt_sched.h | 2 +-
net/sched/sch_pie.c | 107 ++++++++++++++++++++-------------
2 files changed, 66 insertions(+), 43 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net-next v2 1/7] net: sched: pie: change value of QUEUE_THRESHOLD
From: Leslie Monis @ 2019-02-25 10:20 UTC (permalink / raw)
To: jhs
Cc: netdev, dave, Mohit P. Tahiliani, Dhaval Khandla,
Hrishikesh Hiraskar, Manish Kumar B, Sachin D . Patil,
Leslie Monis
In-Reply-To: <20190225102051.12268-1-lesliemonis@gmail.com>
From: "Mohit P. Tahiliani" <tahiliani@nitk.edu.in>
RFC 8033 recommends a value of 16384 bytes for the queue
threshold.
Signed-off-by: Mohit P. Tahiliani <tahiliani@nitk.edu.in>
Signed-off-by: Dhaval Khandla <dhavaljkhandla26@gmail.com>
Signed-off-by: Hrishikesh Hiraskar <hrishihiraskar@gmail.com>
Signed-off-by: Manish Kumar B <bmanish15597@gmail.com>
Signed-off-by: Sachin D. Patil <sdp.sachin@gmail.com>
Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
---
net/sched/sch_pie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index d1429371592f..7778eff6cdb7 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -31,7 +31,7 @@
#include <net/pkt_sched.h>
#include <net/inet_ecn.h>
-#define QUEUE_THRESHOLD 10000
+#define QUEUE_THRESHOLD 16384
#define DQCOUNT_INVALID -1
#define MAX_PROB 0xffffffff
#define PIE_SCALE 8
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/7] net: sched: pie: change default value of pie_params->target
From: Leslie Monis @ 2019-02-25 10:20 UTC (permalink / raw)
To: jhs
Cc: netdev, dave, Mohit P. Tahiliani, Dhaval Khandla,
Hrishikesh Hiraskar, Manish Kumar B, Sachin D . Patil,
Leslie Monis
In-Reply-To: <20190225102051.12268-1-lesliemonis@gmail.com>
From: "Mohit P. Tahiliani" <tahiliani@nitk.edu.in>
RFC 8033 suggests a default value of 15 milliseconds for the
target queue delay.
Signed-off-by: Mohit P. Tahiliani <tahiliani@nitk.edu.in>
Signed-off-by: Dhaval Khandla <dhavaljkhandla26@gmail.com>
Signed-off-by: Hrishikesh Hiraskar <hrishihiraskar@gmail.com>
Signed-off-by: Manish Kumar B <bmanish15597@gmail.com>
Signed-off-by: Sachin D. Patil <sdp.sachin@gmail.com>
Signed-off-by: Leslie Monis <lesliemonis@gmail.com>
---
net/sched/sch_pie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c
index 7778eff6cdb7..91af9bf19852 100644
--- a/net/sched/sch_pie.c
+++ b/net/sched/sch_pie.c
@@ -83,7 +83,7 @@ static void pie_params_init(struct pie_params *params)
params->beta = 20;
params->tupdate = usecs_to_jiffies(30 * USEC_PER_MSEC); /* 30 ms */
params->limit = 1000; /* default of 1000 packets */
- params->target = PSCHED_NS2TICKS(20 * NSEC_PER_MSEC); /* 20 ms */
+ params->target = PSCHED_NS2TICKS(15 * NSEC_PER_MSEC); /* 15 ms */
params->ecn = false;
params->bytemode = false;
}
--
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