* Re: Unexpected behaviour of suppress_prefixlength 0
From: Matthias Peter Walther @ 2016-10-24 10:47 UTC (permalink / raw)
To: netdev
In-Reply-To: <64ccbd98-7717-8ca8-06c8-946a9370f4af@uni-muenster.de>
I'm not sure, if this was the right list to ask for this?
It seems to me, that this list is for patches only...
On 21.10.2016 00:00, Matthias Peter Walther wrote:
> Hello,
>
> I'm Matthias and I'm new to this list. I just signed up, to ask the
> following question.
>
> I have a configuration like this:
>
> root@des1 ~ # ip rule
> 0: from all lookup local
> 32765: from all iif lo lookup ffnet suppress_prefixlength 0
> 32766: from all lookup main
> 32767: from all lookup default
> (ffnet is table 42)
> root@des1 ~ # ip r s
> default via 5.9.86.151 dev eth0
> 5.9.86.151 dev eth0 proto kernel scope link src 5.9.86.144
> root@des1 ~ # ip r s t 42
> blackhole default
>
> I have the default routing table, and a routing table number 42. I
> could use an ip rule filtering by destination ip, but I wanted to try
> suppress_prefixlength.
>
> Let's say I want to ping 8.8.8.8. What I expect is, that the package
> is put into routing table 42 by the ip rule 32765. As there is no more
> specific route for 8.8.8.8 than the default route in table 42, I
> expect the suppress_prefixlength 0 option to put it back to the
> default routing table and then to be send out through eth0.
>
> Instead this configuration takes the whole machine offline:
>
> root@des1 ~ # ping 8.8.8.8
> connect: Invalid argument
>
> When I delete the ip rule 32765 containing the suppress_prefixlength,
> the machine is back online.
>
> Do I not understand the suppress_prefixlength-feature correctly or is
> this a bug? I tested with Kernel 4.7 and 4.6, both show the same
> behaviour as described above.
>
> Thanks for any replies in advance.
>
> Regards,
> Matthias
^ permalink raw reply
* [PATCH 0/2] at803x: don't power-down SGMII link
From: Zefir Kurtisi @ 2016-10-24 10:40 UTC (permalink / raw)
To: netdev; +Cc: timur, andrew, f.fainelli
In a device where the ar8031 operates in SGMII mode, we
observed that after a suspend-resume cycle in very rare
cases the copper side autonegotiation secceeds but the
SGMII side fails to come up.
As a work-around, a patch was provided that on suspend and
resume powers the SGMII link down and up along with the
copper side. This fixed the observed failure, but
introduced a regression Timur Tabi observed: once the SGMII
is powered down, the PHY is inaccessible by the CPU and
with that e.g. can't be re-initialized after suspend.
Since the original issue could not be reproduced by others,
this series provides an alternative handling:
* the first patch reverts the prvious fix that powers down
SGMII
* the second patch adds double-checking for the observed
failure condition
Zefir Kurtisi (2):
Revert "at803x: fix suspend/resume for SGMII link"
at803x: double check SGMII side autoneg
drivers/net/phy/at803x.c | 65 +++++++++++++++++++++++++++++-------------------
1 file changed, 39 insertions(+), 26 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] at803x: double check SGMII side autoneg
From: Zefir Kurtisi @ 2016-10-24 10:40 UTC (permalink / raw)
To: netdev; +Cc: timur, andrew, f.fainelli
In-Reply-To: <1477305654-11328-1-git-send-email-zefir.kurtisi@neratec.com>
In SGMII mode, we observed an autonegotiation issue
after power-down-up cycles where the copper side
reports successful link establishment but the
SGMII side's link is down.
This happened in a setup where the at8031 is
connected over SGMII to a eTSEC (fsl gianfar),
but so far could not be reproduced with other
Ethernet device / driver combinations.
This commit adds a wrapper function for at8031
that in case of operating in SGMII mode double
checks SGMII link state when generic aneg_done()
succeeds. It prints a warning on failure but
intentionally does not try to recover from this
state. As a result, if you ever see a warning
'803x_aneg_done: SGMII link is not ok' you will
end up having an Ethernet link up but won't get
any data through. This should not happen, if it
does, please contact the module maintainer.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/phy/at803x.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index cf74d10..a52b560 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -42,10 +42,18 @@
#define AT803X_MMD_ACCESS_CONTROL 0x0D
#define AT803X_MMD_ACCESS_CONTROL_DATA 0x0E
#define AT803X_FUNC_DATA 0x4003
+#define AT803X_REG_CHIP_CONFIG 0x1f
+#define AT803X_BT_BX_REG_SEL 0x8000
#define AT803X_DEBUG_ADDR 0x1D
#define AT803X_DEBUG_DATA 0x1E
+#define AT803X_MODE_CFG_MASK 0x0F
+#define AT803X_MODE_CFG_SGMII 0x01
+
+#define AT803X_PSSR 0x11 /*PHY-Specific Status Register*/
+#define AT803X_PSSR_MR_AN_COMPLETE 0x0200
+
#define AT803X_DEBUG_REG_0 0x00
#define AT803X_DEBUG_RX_CLK_DLY_EN BIT(15)
@@ -355,6 +363,36 @@ static void at803x_link_change_notify(struct phy_device *phydev)
}
}
+static int at803x_aneg_done(struct phy_device *phydev)
+{
+ int ccr;
+
+ int aneg_done = genphy_aneg_done(phydev);
+ if (aneg_done != BMSR_ANEGCOMPLETE)
+ return aneg_done;
+
+ /*
+ * in SGMII mode, if copper side autoneg is successful,
+ * also check SGMII side autoneg result
+ */
+ ccr = phy_read(phydev, AT803X_REG_CHIP_CONFIG);
+ if ((ccr & AT803X_MODE_CFG_MASK) != AT803X_MODE_CFG_SGMII)
+ return aneg_done;
+
+ /* switch to SGMII/fiber page */
+ phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr & ~AT803X_BT_BX_REG_SEL);
+
+ /* check if the SGMII link is OK. */
+ if (!(phy_read(phydev, AT803X_PSSR) & AT803X_PSSR_MR_AN_COMPLETE)) {
+ pr_warn("803x_aneg_done: SGMII link is not ok\n");
+ aneg_done = 0;
+ }
+ /* switch back to copper page */
+ phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
+
+ return aneg_done;
+}
+
static struct phy_driver at803x_driver[] = {
{
/* ATHEROS 8035 */
@@ -406,6 +444,7 @@ static struct phy_driver at803x_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
+ .aneg_done = at803x_aneg_done,
.ack_interrupt = &at803x_ack_interrupt,
.config_intr = &at803x_config_intr,
} };
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] Revert "at803x: fix suspend/resume for SGMII link"
From: Zefir Kurtisi @ 2016-10-24 10:40 UTC (permalink / raw)
To: netdev; +Cc: timur, andrew, f.fainelli
In-Reply-To: <1477305654-11328-1-git-send-email-zefir.kurtisi@neratec.com>
This reverts commit 98267311fe3b334ae7c107fa0e2413adcf3ba735.
Suspending the SGMII alongside the copper side
made the at803x inaccessable while powered down,
e.g. it can't be re-probed after suspend.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/phy/at803x.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index f279a89..cf74d10 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -52,9 +52,6 @@
#define AT803X_DEBUG_REG_5 0x05
#define AT803X_DEBUG_TX_CLK_DLY_EN BIT(8)
-#define AT803X_REG_CHIP_CONFIG 0x1f
-#define AT803X_BT_BX_REG_SEL 0x8000
-
#define ATH8030_PHY_ID 0x004dd076
#define ATH8031_PHY_ID 0x004dd074
#define ATH8035_PHY_ID 0x004dd072
@@ -209,7 +206,6 @@ static int at803x_suspend(struct phy_device *phydev)
{
int value;
int wol_enabled;
- int ccr;
mutex_lock(&phydev->lock);
@@ -225,16 +221,6 @@ static int at803x_suspend(struct phy_device *phydev)
phy_write(phydev, MII_BMCR, value);
- if (phydev->interface != PHY_INTERFACE_MODE_SGMII)
- goto done;
-
- /* also power-down SGMII interface */
- ccr = phy_read(phydev, AT803X_REG_CHIP_CONFIG);
- phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr & ~AT803X_BT_BX_REG_SEL);
- phy_write(phydev, MII_BMCR, phy_read(phydev, MII_BMCR) | BMCR_PDOWN);
- phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
-
-done:
mutex_unlock(&phydev->lock);
return 0;
@@ -243,7 +229,6 @@ static int at803x_suspend(struct phy_device *phydev)
static int at803x_resume(struct phy_device *phydev)
{
int value;
- int ccr;
mutex_lock(&phydev->lock);
@@ -251,17 +236,6 @@ static int at803x_resume(struct phy_device *phydev)
value &= ~(BMCR_PDOWN | BMCR_ISOLATE);
phy_write(phydev, MII_BMCR, value);
- if (phydev->interface != PHY_INTERFACE_MODE_SGMII)
- goto done;
-
- /* also power-up SGMII interface */
- ccr = phy_read(phydev, AT803X_REG_CHIP_CONFIG);
- phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr & ~AT803X_BT_BX_REG_SEL);
- value = phy_read(phydev, MII_BMCR) & ~(BMCR_PDOWN | BMCR_ISOLATE);
- phy_write(phydev, MII_BMCR, value);
- phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
-
-done:
mutex_unlock(&phydev->lock);
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-10-24 9:43 UTC (permalink / raw)
To: Jakub Sitnicki, netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1477301332-23954-6-git-send-email-jkbs@redhat.com>
On 24.10.2016 11:28, Jakub Sitnicki wrote:
> Same as for the transmit path, let's do our best to ensure that received
> ICMP errors that may be subject to forwarding will be routed the same
> path as flow that triggered the error, if it was going in the opposite
> direction.
>
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH net-next 4/5] ipv6: Compute multipath hash for sent ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-10-24 9:40 UTC (permalink / raw)
To: Jakub Sitnicki, netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet
In-Reply-To: <1477301332-23954-5-git-send-email-jkbs@redhat.com>
On 24.10.2016 11:28, Jakub Sitnicki wrote:
> Improve debuggability with tools like traceroute and make PMTUD work in
> setups that make use of ECMP routing by sending ICMP errors down the
> same path as the offending packet would travel, if it was going in the
> opposite direction.
>
> There is a caveat, flows in both directions need use the same
> label. Otherwise packets from flow in the opposite direction and ICMP
> errors will not be routed over the same ECMP link.
>
> Export the function for calculating the multipath hash so that we can
> use it also on receive side, when forwarding ICMP errors.
>
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH net-next 3/5] ipv6: Use multipath hash from flow info if available
From: Hannes Frederic Sowa @ 2016-10-24 9:40 UTC (permalink / raw)
To: Jakub Sitnicki, netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1477301332-23954-4-git-send-email-jkbs@redhat.com>
On 24.10.2016 11:28, Jakub Sitnicki wrote:
> Allow our callers to influence the choice of ECMP link by honoring the
> hash passed together with the flow info. This will allow for special
> treatment of ICMP errors which we would like to route over the same link
> as the IP datagram that triggered the error.
>
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: Extend struct flowi6 with multipath hash
From: Hannes Frederic Sowa @ 2016-10-24 9:39 UTC (permalink / raw)
To: Jakub Sitnicki, netdev; +Cc: linux-kernel, David S. Miller
In-Reply-To: <1477301332-23954-3-git-send-email-jkbs@redhat.com>
On 24.10.2016 11:28, Jakub Sitnicki wrote:
> Allow for functions that fill out the IPv6 flow info to also pass a hash
> computed over the skb contents. The hash value will drive the multipath
> routing decisions.
>
> This is intended for special treatment of ICMPv6 errors, where we would
> like to make a routing decision based on the flow identifying the
> offending IPv6 datagram that triggered the error, rather than the flow
> of the ICMP error itself.
>
> Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* [PATCH net-next 3/5] ipv6: Use multipath hash from flow info if available
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1477301332-23954-1-git-send-email-jkbs@redhat.com>
Allow our callers to influence the choice of ECMP link by honoring the
hash passed together with the flow info. This will allow for special
treatment of ICMP errors which we would like to route over the same link
as the IP datagram that triggered the error.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
net/ipv6/route.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0514b35..1184c2b 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -430,9 +430,11 @@ static struct rt6_info *rt6_multipath_select(struct rt6_info *match,
int strict)
{
struct rt6_info *sibling, *next_sibling;
+ unsigned int hash;
int route_choosen;
- route_choosen = get_hash_from_flowi6(fl6) % (match->rt6i_nsiblings + 1);
+ hash = fl6->mp_hash ? : get_hash_from_flowi6(fl6);
+ route_choosen = hash % (match->rt6i_nsiblings + 1);
/* Don't change the route, if route_choosen == 0
* (siblings does not include ourself)
*/
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1477301332-23954-1-git-send-email-jkbs@redhat.com>
Same as for the transmit path, let's do our best to ensure that received
ICMP errors that may be subject to forwarding will be routed the same
path as flow that triggered the error, if it was going in the opposite
direction.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
net/ipv6/route.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 1184c2b..c0f38ea 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1150,6 +1150,30 @@ struct dst_entry *ip6_route_input_lookup(struct net *net,
}
EXPORT_SYMBOL_GPL(ip6_route_input_lookup);
+static u32 ip6_multipath_icmp_hash(const struct sk_buff *skb)
+{
+ const struct icmp6hdr *icmph = icmp6_hdr(skb);
+ const struct ipv6hdr *inner_iph;
+ struct ipv6hdr _inner_iph;
+
+ if (icmph->icmp6_type != ICMPV6_DEST_UNREACH &&
+ icmph->icmp6_type != ICMPV6_PKT_TOOBIG &&
+ icmph->icmp6_type != ICMPV6_TIME_EXCEED &&
+ icmph->icmp6_type != ICMPV6_PARAMPROB)
+ goto standard_hash;
+
+ inner_iph = skb_header_pointer(
+ skb, skb_transport_offset(skb) + sizeof(*icmph),
+ sizeof(_inner_iph), &_inner_iph);
+ if (!inner_iph)
+ goto standard_hash;
+
+ return icmpv6_multipath_hash(inner_iph);
+
+standard_hash:
+ return 0; /* compute it later, if needed */
+}
+
void ip6_route_input(struct sk_buff *skb)
{
const struct ipv6hdr *iph = ipv6_hdr(skb);
@@ -1168,6 +1192,8 @@ void ip6_route_input(struct sk_buff *skb)
tun_info = skb_tunnel_info(skb);
if (tun_info && !(tun_info->mode & IP_TUNNEL_INFO_TX))
fl6.flowi6_tun_key.tun_id = tun_info->key.tun_id;
+ if (unlikely(fl6.flowi6_proto == IPPROTO_ICMPV6))
+ fl6.mp_hash = ip6_multipath_icmp_hash(skb);
skb_dst_drop(skb);
skb_dst_set(skb, ip6_route_input_lookup(net, skb->dev, &fl6, flags));
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 4/5] ipv6: Compute multipath hash for sent ICMP errors from offending packet
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet
In-Reply-To: <1477301332-23954-1-git-send-email-jkbs@redhat.com>
Improve debuggability with tools like traceroute and make PMTUD work in
setups that make use of ECMP routing by sending ICMP errors down the
same path as the offending packet would travel, if it was going in the
opposite direction.
There is a caveat, flows in both directions need use the same
label. Otherwise packets from flow in the opposite direction and ICMP
errors will not be routed over the same ECMP link.
Export the function for calculating the multipath hash so that we can
use it also on receive side, when forwarding ICMP errors.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
include/linux/icmpv6.h | 2 ++
net/ipv6/icmp.c | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/include/linux/icmpv6.h b/include/linux/icmpv6.h
index 57086e9..6282e03 100644
--- a/include/linux/icmpv6.h
+++ b/include/linux/icmpv6.h
@@ -45,4 +45,6 @@ extern void icmpv6_flow_init(struct sock *sk,
const struct in6_addr *saddr,
const struct in6_addr *daddr,
int oif);
+struct ipv6hdr;
+extern u32 icmpv6_multipath_hash(const struct ipv6hdr *iph);
#endif
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index bd59c34..ab376b3d1 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -385,6 +385,26 @@ static struct dst_entry *icmpv6_route_lookup(struct net *net,
return ERR_PTR(err);
}
+u32 icmpv6_multipath_hash(const struct ipv6hdr *iph)
+{
+ struct flowi6 fl6;
+
+ /* Calculate the multipath hash from the offending IP datagram that
+ * triggered the ICMP error. The source and destination addresses are
+ * swapped as we do our best to route the ICMP message together with the
+ * flow it belongs to. However, flows in both directions have to have
+ * the same label (e.g. by using flow label reflection) for it to
+ * happen.
+ */
+ memset(&fl6, 0, sizeof(fl6));
+ fl6.daddr = iph->saddr;
+ fl6.saddr = iph->daddr;
+ fl6.flowlabel = ip6_flowinfo(iph);
+ fl6.flowi6_proto = iph->nexthdr;
+
+ return get_hash_from_flowi6(&fl6);
+}
+
/*
* Send an ICMP message in response to a packet in error
*/
@@ -484,6 +504,7 @@ static void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info,
fl6.flowi6_oif = iif;
fl6.fl6_icmp_type = type;
fl6.fl6_icmp_code = code;
+ fl6.mp_hash = icmpv6_multipath_hash(hdr);
security_skb_classify_flow(skb, flowi6_to_flowi(&fl6));
sk = icmpv6_xmit_lock(net);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/5] net: Extend struct flowi6 with multipath hash
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David S. Miller
In-Reply-To: <1477301332-23954-1-git-send-email-jkbs@redhat.com>
Allow for functions that fill out the IPv6 flow info to also pass a hash
computed over the skb contents. The hash value will drive the multipath
routing decisions.
This is intended for special treatment of ICMPv6 errors, where we would
like to make a routing decision based on the flow identifying the
offending IPv6 datagram that triggered the error, rather than the flow
of the ICMP error itself.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
include/net/flow.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/flow.h b/include/net/flow.h
index 035aa77..73ee3aa 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -143,6 +143,7 @@ struct flowi6 {
#define fl6_ipsec_spi uli.spi
#define fl6_mh_type uli.mht.type
#define fl6_gre_key uli.gre_key
+ __u32 mp_hash;
} __attribute__((__aligned__(BITS_PER_LONG/8)));
struct flowidn {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/5] ipv6: Fold rt6_info_hash_nhsfn() into its only caller
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1477301332-23954-1-git-send-email-jkbs@redhat.com>
Commit 644d0e656958 ("ipv6 Use get_hash_from_flowi6 for rt6 hash") has
turned rt6_info_hash_nhsfn() into a one-liner, so it no longer makes
sense to keep it around.
Also the accompanying documentation comment has become outdated, so just
remove it altogether.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/route.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index bdbc38e..0514b35 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -425,16 +425,6 @@ static bool rt6_check_expired(const struct rt6_info *rt)
return false;
}
-/* Multipath route selection:
- * Hash based function using packet header and flowlabel.
- * Adapted from fib_info_hashfn()
- */
-static int rt6_info_hash_nhsfn(unsigned int candidate_count,
- const struct flowi6 *fl6)
-{
- return get_hash_from_flowi6(fl6) % candidate_count;
-}
-
static struct rt6_info *rt6_multipath_select(struct rt6_info *match,
struct flowi6 *fl6, int oif,
int strict)
@@ -442,7 +432,7 @@ static struct rt6_info *rt6_multipath_select(struct rt6_info *match,
struct rt6_info *sibling, *next_sibling;
int route_choosen;
- route_choosen = rt6_info_hash_nhsfn(match->rt6i_nsiblings + 1, fl6);
+ route_choosen = get_hash_from_flowi6(fl6) % (match->rt6i_nsiblings + 1);
/* Don't change the route, if route_choosen == 0
* (siblings does not include ourself)
*/
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/5] Route ICMPv6 errors with the flow when ECMP in use
From: Jakub Sitnicki @ 2016-10-24 9:28 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The motivation for this series is to route ICMPv6 error messages
together with the flow they belong to when multipath routing is in
use. It intends to bring the ECMP routing in IPv6 stack on par with
IPv4.
This enables the use of tools that rely on ICMP error messages such as
traceroute and makes PMTU discovery work both ways. However, for it to
work IPv6 flow labels have to be same in both directions
(i.e. reflected) or need to be chosen in a manner that ensures that
the flow going in the opposite direction would actually be routed to a
given path.
Changes have been tested in a virtual setup with a topology as below:
Re1 --- Hs1
/
Hc --- Ri --- Rc
\
Re1 --- Hs2
Hc - client host
HsX - server host
Rc - core router
ReX - edge router
Ri - intermediate router
To test the changes, traceroute in UDP mode to the client host, with
flow label set, has been run from one of the server hosts. Full test
is available at [1].
-Jakub
[1] https://github.com/jsitnicki/tools/blob/master/net/tests/ecmp/test-ecmp-icmpv6-error-routing.sh
Jakub Sitnicki (5):
ipv6: Fold rt6_info_hash_nhsfn() into its only caller
net: Extend struct flowi6 with multipath hash
ipv6: Use multipath hash from flow info if available
ipv6: Compute multipath hash for sent ICMP errors from offending
packet
ipv6: Compute multipath hash for forwarded ICMP errors from offending
packet
include/linux/icmpv6.h | 2 ++
include/net/flow.h | 1 +
net/ipv6/icmp.c | 21 +++++++++++++++++++++
net/ipv6/route.c | 40 +++++++++++++++++++++++++++++-----------
4 files changed, 53 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] net: fec: hard phy reset on open
From: Manfred Schlaegl @ 2016-10-24 9:25 UTC (permalink / raw)
To: Fugang Duan; +Cc: netdev, linux-kernel
We have seen some problems with auto negotiation on i.MX6 using LAN8720,
after interface down/up.
In our configuration, the ptp clock is used externally as reference
clock for the phy. Some phys (e.g. LAN8720) needs a stable clock while
and after hard reset.
Before this patch, the driver disabled the clock on close but did no
hard reset on open, after enabling the clocks again.
A solution that prevents disabling the clocks on close was considered,
but discarded because of bad power saving behavior.
This patch saves the reset dt properties on probe and does a reset on
every open after clocks where enabled, to make sure the clock is stable
while and after hard reset.
Tested on i.MX6 and i.MX28, both using LAN8720.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
---
drivers/net/ethernet/freescale/fec.h | 4 ++
drivers/net/ethernet/freescale/fec_main.c | 77 +++++++++++++++++--------------
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index c865135..379e619 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -498,6 +498,10 @@ struct fec_enet_private {
struct clk *clk_enet_out;
struct clk *clk_ptp;
+ int phy_reset;
+ bool phy_reset_active_high;
+ int phy_reset_msec;
+
bool ptp_clk_on;
struct mutex ptp_clk_mutex;
unsigned int num_tx_queues;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 48a033e..8cc1ec5 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2802,6 +2802,22 @@ static int fec_enet_alloc_buffers(struct net_device *ndev)
return 0;
}
+static void fec_reset_phy(struct fec_enet_private *fep)
+{
+ if (!gpio_is_valid(fep->phy_reset))
+ return;
+
+ gpio_set_value_cansleep(fep->phy_reset, !!fep->phy_reset_active_high);
+
+ if (fep->phy_reset_msec > 20)
+ msleep(fep->phy_reset_msec);
+ else
+ usleep_range(fep->phy_reset_msec * 1000,
+ fep->phy_reset_msec * 1000 + 1000);
+
+ gpio_set_value_cansleep(fep->phy_reset, !fep->phy_reset_active_high);
+}
+
static int
fec_enet_open(struct net_device *ndev)
{
@@ -2817,6 +2833,8 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto clk_enable;
+ fec_reset_phy(fep);
+
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
*/
@@ -3183,52 +3201,39 @@ static int fec_enet_init(struct net_device *ndev)
return 0;
}
-#ifdef CONFIG_OF
-static void fec_reset_phy(struct platform_device *pdev)
+static int
+fec_get_reset_phy(struct platform_device *pdev, int *msec, int *phy_reset,
+ bool *active_high)
{
- int err, phy_reset;
- bool active_high = false;
- int msec = 1;
+ int err;
struct device_node *np = pdev->dev.of_node;
- if (!np)
- return;
+ if (!np || !of_device_is_available(np))
+ return 0;
- of_property_read_u32(np, "phy-reset-duration", &msec);
+ of_property_read_u32(np, "phy-reset-duration", msec);
/* A sane reset duration should not be longer than 1s */
- if (msec > 1000)
- msec = 1;
+ if (*msec > 1000)
+ *msec = 1;
- phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
- if (!gpio_is_valid(phy_reset))
- return;
+ *phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
+ if (!gpio_is_valid(*phy_reset))
+ return 0;
- active_high = of_property_read_bool(np, "phy-reset-active-high");
+ *active_high = of_property_read_bool(np, "phy-reset-active-high");
- err = devm_gpio_request_one(&pdev->dev, phy_reset,
- active_high ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- "phy-reset");
+ err = devm_gpio_request_one(&pdev->dev, *phy_reset,
+ *active_high ?
+ GPIOF_OUT_INIT_HIGH :
+ GPIOF_OUT_INIT_LOW,
+ "phy-reset");
if (err) {
dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
- return;
+ return err;
}
- if (msec > 20)
- msleep(msec);
- else
- usleep_range(msec * 1000, msec * 1000 + 1000);
-
- gpio_set_value_cansleep(phy_reset, !active_high);
-}
-#else /* CONFIG_OF */
-static void fec_reset_phy(struct platform_device *pdev)
-{
- /*
- * In case of platform probe, the reset has been done
- * by machine code.
- */
+ return 0;
}
-#endif /* CONFIG_OF */
static void
fec_enet_get_queue_num(struct platform_device *pdev, int *num_tx, int *num_rx)
@@ -3409,7 +3414,10 @@ fec_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
- fec_reset_phy(pdev);
+ ret = fec_get_reset_phy(pdev, &fep->phy_reset_msec, &fep->phy_reset,
+ &fep->phy_reset_active_high);
+ if (ret)
+ goto failed_reset;
if (fep->bufdesc_ex)
fec_ptp_init(pdev);
@@ -3467,6 +3475,7 @@ fec_probe(struct platform_device *pdev)
failed_mii_init:
failed_irq:
failed_init:
+failed_reset:
fec_ptp_stop(pdev);
if (fep->reg_phy)
regulator_disable(fep->reg_phy);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle
From: Daniel Borkmann @ 2016-10-24 9:03 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jamal Hadi Salim, davem, netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <20161024084858.GD2781@nanopsycho>
On 10/24/2016 10:48 AM, Jiri Pirko wrote:
> Mon, Oct 24, 2016 at 12:30:44AM CEST, daniel@iogearbox.net wrote:
>> On 10/23/2016 05:35 PM, Jamal Hadi Salim wrote:
>>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> An actual commit message would be good especially if it's a fix
>> for -net tree plus stable. Thanks.
>
> Also a "Fixes:" tag would be nice to have :)
This kernel address leakage dates back to history tree:
Fixes: 4e54c4816bfe ("[NET]: Add tc extensions infrastructure.")
>>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>> ---
>>> net/sched/cls_api.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>> index 2ee29a3..2b2a797 100644
>>> --- a/net/sched/cls_api.c
>>> +++ b/net/sched/cls_api.c
>>> @@ -345,7 +345,8 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
>>> if (err == 0) {
>>> struct tcf_proto *next = rtnl_dereference(tp->next);
>>>
>>> - tfilter_notify(net, skb, n, tp, fh,
>>> + tfilter_notify(net, skb, n, tp,
>>> + t->tcm_handle,
>>> RTM_DELTFILTER, false);
>>> if (tcf_destroy(tp, false))
>>> RCU_INIT_POINTER(*back, next);
>>>
>>
^ permalink raw reply
* Re: [PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle
From: Jiri Pirko @ 2016-10-24 8:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jamal Hadi Salim, davem, netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <580D3A14.5010705@iogearbox.net>
Mon, Oct 24, 2016 at 12:30:44AM CEST, daniel@iogearbox.net wrote:
>On 10/23/2016 05:35 PM, Jamal Hadi Salim wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>
>An actual commit message would be good especially if it's a fix
>for -net tree plus stable. Thanks.
Also a "Fixes:" tag would be nice to have :)
>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> ---
>> net/sched/cls_api.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>> index 2ee29a3..2b2a797 100644
>> --- a/net/sched/cls_api.c
>> +++ b/net/sched/cls_api.c
>> @@ -345,7 +345,8 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
>> if (err == 0) {
>> struct tcf_proto *next = rtnl_dereference(tp->next);
>>
>> - tfilter_notify(net, skb, n, tp, fh,
>> + tfilter_notify(net, skb, n, tp,
>> + t->tcm_handle,
>> RTM_DELTFILTER, false);
>> if (tcf_destroy(tp, false))
>> RCU_INIT_POINTER(*back, next);
>>
>
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: stm32f429: remove Ethernet wake on Lan support
From: Alexandre TORGUE @ 2016-10-24 8:40 UTC (permalink / raw)
To: peppe.cavallaro, Maxime Coquelin, arnd, robh
Cc: netdev, linux-arm-kernel, devicetree
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue@st.com>
This patch removes WoL (Wake on Lan) support as it is not yet
fully supported and tested.
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 6350117b..ad0bc6a 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -377,8 +377,8 @@
compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
reg = <0x40028000 0x8000>;
reg-names = "stmmaceth";
- interrupts = <61>, <62>;
- interrupt-names = "macirq", "eth_wake_irq";
+ interrupts = <61>;
+ interrupt-names = "macirq";
clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
st,syscon = <&syscfg 0x4>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: stm32f429: Fix Ethernet node on Eval Board
From: Alexandre TORGUE @ 2016-10-24 8:40 UTC (permalink / raw)
To: peppe.cavallaro-qxv4g6HH51o, Maxime Coquelin, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
"phy-handle" entry is mandatory when mdio subnode is used in
Ethernet node.
Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index fa30bf1..a11b108 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -99,7 +99,7 @@
pinctrl-0 = <ðernet_mii>;
pinctrl-names = "default";
phy-mode = "mii";
-
+ phy-handle = <&phy1>;
mdio0 {
#address-cells = <1>;
#size-cells = <0>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: stm32f429: Align Ethernet node with new bindings properties
From: Alexandre TORGUE @ 2016-10-24 8:40 UTC (permalink / raw)
To: peppe.cavallaro-qxv4g6HH51o, Maxime Coquelin, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477298406-22805-1-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
This patch aligns clocks names and node reference according to new
stm32-dwmac glue binding. It also renames Ethernet pinctrl phandle
(indeed there is no need to add 0 as Ethernet instance as there is only
one IP in SOC).
Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 13c7cd2..fa30bf1 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -94,11 +94,12 @@
clock-frequency = <25000000>;
};
-ðernet0 {
+&mac {
status = "okay";
- pinctrl-0 = <ðernet0_mii>;
+ pinctrl-0 = <ðernet_mii>;
pinctrl-names = "default";
- phy-mode = "mii-id";
+ phy-mode = "mii";
+
mdio0 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 336ee4f..6350117b 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -313,7 +313,7 @@
};
};
- ethernet0_mii: mii@0 {
+ ethernet_mii: mii@0 {
pins {
pinmux = <STM32F429_PG13_FUNC_ETH_MII_TXD0_ETH_RMII_TXD0>,
<STM32F429_PG14_FUNC_ETH_MII_TXD1_ETH_RMII_TXD1>,
@@ -373,13 +373,13 @@
st,mem2mem;
};
- ethernet0: dwmac@40028000 {
+ mac: ethernet@40028000 {
compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
reg = <0x40028000 0x8000>;
reg-names = "stmmaceth";
interrupts = <61>, <62>;
interrupt-names = "macirq", "eth_wake_irq";
- clock-names = "stmmaceth", "tx-clk", "rx-clk";
+ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
st,syscon = <&syscfg 0x4>;
snps,pbl = <8>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/3] STM32F429: Add Ethernet fixes
From: Alexandre TORGUE @ 2016-10-24 8:40 UTC (permalink / raw)
To: peppe.cavallaro-qxv4g6HH51o, Maxime Coquelin, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
This v2 to avoid build issue when only patch 1 (of first series)
was build.
This series adds several fixes for Ethernet for stm32f429 MCU.
First patch has already been reviewed some months ago when
stm32 Ethernet glue has been pushed (I added in this series to keep
history). Fixes are:
-Change DT to be compliant to stm32 ethernet glue binding
-Add phy-handle to correctly use mdio subnode
-Remove WoL support
changes since v1:
-squash patch1 and patch2.
Regards
Alex
Alexandre TORGUE (3):
ARM: dts: stm32f429: Align Ethernet node with new bindings properties
ARM: dts: stm32f429: Fix Ethernet node on Eval Board
ARM: dts: stm32f429: remove Ethernet wake on Lan support
arch/arm/boot/dts/stm32429i-eval.dts | 7 ++++---
arch/arm/boot/dts/stm32f429.dtsi | 10 +++++-----
2 files changed, 9 insertions(+), 8 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] flow_dissector: fix vlan tag handling
From: Jiri Pirko @ 2016-10-24 8:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tom Herbert, David S. Miller, Alexander Duyck, Jiri Pirko,
Hadar Hen Zion, Gao Feng, Amir Vadai,
Linux Kernel Network Developers, LKML, Linus Torvalds
In-Reply-To: <3590200.oN5tv3ZPpc@wuerfel>
Sat, Oct 22, 2016 at 10:30:08PM CEST, arnd@arndb.de wrote:
>gcc warns about an uninitialized pointer dereference in the vlan
>priority handling:
>
>net/core/flow_dissector.c: In function '__skb_flow_dissect':
>net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
>As pointed out by Jiri Pirko, the variable is never actually used
>without being initialized first as the only way it end up uninitialized
>is with skb_vlan_tag_present(skb)==true, and that means it does not
>get accessed.
>
>However, the warning hints at some related issues that I'm addressing
>here:
>
>- the second check for the vlan tag is different from the first one
> that tests the skb for being NULL first, causing both the warning
> and a possible NULL pointer dereference that was not entirely fixed.
>- The same patch that introduced the NULL pointer check dropped an
> earlier optimization that skipped the repeated check of the
> protocol type
>- The local '_vlan' variable is referenced through the 'vlan' pointer
> but the variable has gone out of scope by the time that it is
> accessed, causing undefined behavior as the stack may have been
> overwritten.
>
>Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
>in a local variable allows the compiler to further optimize the
>later check. With those changes, the warning also disappears.
>
>Fixes: 3805a938a6c2 ("flow_dissector: Check skb for VLAN only if skb specified.")
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>---
>
>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>index 44e6ba9d3a6b..17be1b66cc41 100644
>--- a/net/core/flow_dissector.c
>+++ b/net/core/flow_dissector.c
>@@ -246,13 +246,10 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> case htons(ETH_P_8021AD):
> case htons(ETH_P_8021Q): {
> const struct vlan_hdr *vlan;
>+ struct vlan_hdr _vlan;
>+ bool vlan_tag_present = (skb && skb_vlan_tag_present(skb));
Drop the unnecessary "()"
>
>- if (skb && skb_vlan_tag_present(skb))
>- proto = skb->protocol;
This does not look correct. I believe that you need to set proto for
further processing.
>-
>- if (eth_type_vlan(proto)) {
>- struct vlan_hdr _vlan;
>-
>+ if (!vlan_tag_present || eth_type_vlan(skb->protocol)) {
> vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
> data, hlen, &_vlan);
> if (!vlan)
>@@ -270,7 +267,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> FLOW_DISSECTOR_KEY_VLAN,
> target_container);
>
>- if (skb_vlan_tag_present(skb)) {
>+ if (vlan_tag_present) {
> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
> key_vlan->vlan_priority =
> (skb_vlan_tag_get_prio(skb) >> VLAN_PRIO_SHIFT);
>
^ permalink raw reply
* Re: [PATCH 0/4] STM32F429: Add Ethernet fixes
From: Alexandre Torgue @ 2016-10-24 7:30 UTC (permalink / raw)
To: David Miller
Cc: peppe.cavallaro-qxv4g6HH51o,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161020.144140.1794871934594140769.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi David,
On 10/20/2016 08:41 PM, David Miller wrote:
> From: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> Date: Thu, 20 Oct 2016 17:21:22 +0200
>
>> This series adds several fixes for Ethernet for stm32f429 MCU.
>> First 2 patches have already been reviewed some months ago when
>> stm32 Ethernet glue has been pushed (I added in this series to keep
>> history). Fixes are:
>> -Change DT to be compliant to stm32 ethernet glue binding
>> -Add phy-handle to correctly use mdio subnode
>> -Remove WoL support
>
> I'm assuming this will be merged via the ARM tree.
Yes, I will take it in my next pull request (if no issues).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH kernel v3] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)
From: Alexey Kardashevskiy @ 2016-10-24 7:04 UTC (permalink / raw)
To: linux-kernel
Cc: Alexey Kardashevskiy, linux-pci, Alexander Duyck, Netdev,
Santosh Raspatur
There is at least one Chelsio 10Gb card which uses VPD area to store
some custom blocks (example below). However pci_vpd_size() returns
the length of the first block only assuming that there can be only
one VPD "End Tag" and VFIO blocks access beyond that offset
(since 4e1a63555) which leads to the situation when the guest "cxgb3"
driver fails to probe the device. The host system does not have this
problem as the drives accesses the config space directly without
pci_read_vpd()/...
This adds a quirk to override the VPD size to a bigger value.
The maximum size is taken from EEPROMSIZE in
drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag
as the cxgb3 driver does as the driver supports writing to EEPROM/VPD
and when it writes, it only checks for 8192 bytes boundary. The quirk
is registerted for all devices supported by the cxgb3 driver.
This adds a quirk to the PCI layer (not to the cxgb3 driver) as
the cxgb3 driver itself accesses VPD directly and the problem only exists
with the vfio-pci driver (when cxgb3 is not running on the host and
may not be even loaded) which blocks accesses beyond the first block
of VPD data. However vfio-pci itself does not have quirks mechanism so
we add it to PCI.
This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]
This is what I parsed from its vpd:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
0000 Large item 42 bytes; name 0x2 Identifier String
b'10 Gigabit Ethernet-SR PCI Express Adapter'
002d Large item 74 bytes; name 0x10
#00 [EC] len=7: b'D76809 '
#0a [FN] len=7: b'46K7897'
#14 [PN] len=7: b'46K7897'
#1e [MN] len=4: b'1037'
#25 [FC] len=4: b'5769'
#2c [SN] len=12: b'YL102035603V'
#3b [NA] len=12: b'00145E992ED1'
007a Small item 1 bytes; name 0xf End Tag
0c00 Large item 16 bytes; name 0x2 Identifier String
b'S310E-SR-X '
0c13 Large item 234 bytes; name 0x10
#00 [PN] len=16: b'TBD '
#13 [EC] len=16: b'110107730D2 '
#26 [SN] len=16: b'97YL102035603V '
#39 [NA] len=12: b'00145E992ED1'
#48 [V0] len=6: b'175000'
#51 [V1] len=6: b'266666'
#5a [V2] len=6: b'266666'
#63 [V3] len=6: b'2000 '
#6c [V4] len=2: b'1 '
#71 [V5] len=6: b'c2 '
#7a [V6] len=6: b'0 '
#83 [V7] len=2: b'1 '
#88 [V8] len=2: b'0 '
#8d [V9] len=2: b'0 '
#92 [VA] len=2: b'0 '
#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0d00 Large item 252 bytes; name 0x11
#00 [VC] len=16: b'122310_1222 dp '
#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
#26 [VE] len=16: b'122310_1353 fp '
#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0dff Small item 0 bytes; name 0xf End Tag
10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v3:
* unconditionally set VPD size to 8192
v2:
* used pci_set_vpd_size() helper
* added explicit list of IDs from cxgb3 driver
* added a note in the commit log why the quirk is not in cxgb3
---
drivers/pci/quirks.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c232729..bc7c541 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3255,6 +3255,25 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
quirk_thunderbolt_hotplug_msi);
+static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
+{
+ pci_set_vpd_size(dev, 8192);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+
#ifdef CONFIG_ACPI
/*
* Apple: Shutdown Cactus Ridge Thunderbolt controller.
--
2.5.0.rc3
^ permalink raw reply related
* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Xin Long @ 2016-10-24 6:30 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <2fa21505-59c2-fb8b-6e89-11fccc953d25@mojatatu.com>
[1]
>> This patch doesn't ignore all the ENOMEN cases, only after msg is
>> enqueued in out queue/send queue, in the lower layer, when alloc
>> new skb and copy data from old skb, if it fails to alloc new skb, sctp
>> will ignore this ENOMEM, as this msg will be taken care by retransmit
>> mechanism, it's reasonable and also safe, user can't feel that.
>>
>
> Yes, that part i got.
>
[2]
>> But for the cases before enqueue, like in sctp_sendmsg,
>> sctp_datamsg_from_user may return ENOMEM, this err will return
>> back to user, and can't be ignored.
>>
>
> The hard part is distinguishing between the above case and real
> failure.
> I am assuming in the case above user is _not_ required to send
> again. But in the general case they are required to send again.
> Correct?
in case [1], user can't see the ENOMEM, ENOMEM is more like
a internal err.
in case [2], user will got the ENOMEM, they should resend this msg,
It's the the general case mentioned-above
>
>> So I don't really think we should change something in manpage, what
>> do you think ? maybe a little explanation there is also nice, :)
>
>
> Yes, that would help. In particular it should be clear what user space
> is expected to do. While this is about sctp - I am assuming equivalent
> behavior for all callers of sendxxx() regardless of protocol.
here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb
also may fail to alloc skb, but it doesn't return any err to user, just like
sctp_packet_transmit. That's why I don't think we should change something
in manpage, as here sctp is consistent with tcp now.
make sense ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox