* [PATCH v2] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
From: Mateusz Jurczyk @ 2017-06-07 14:14 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: David S. Miller, netfilter-devel, coreteam, linux-decnet-user,
netdev, linux-kernel
In-Reply-To: <20170607131429.30441-1-mjurczyk@google.com>
Verify that the length of the socket buffer is sufficient to cover the
nlmsghdr structure before accessing the nlh->nlmsg_len field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < sizeof(*nlh) expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
Changes in v2:
- Compare skb->len against sizeof(*nlh) instead of sizeof(nlh->nlmsg_len)
to avoid assuming the layout of the nlmsghdr structure. This was
motivated by Eric Dumazet's comment on a related patch submission.
net/decnet/netfilter/dn_rtmsg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/decnet/netfilter/dn_rtmsg.c b/net/decnet/netfilter/dn_rtmsg.c
index 1ed81ac6dd1a..aa8ffecc46a4 100644
--- a/net/decnet/netfilter/dn_rtmsg.c
+++ b/net/decnet/netfilter/dn_rtmsg.c
@@ -102,7 +102,9 @@ static inline void dnrmg_receive_user_skb(struct sk_buff *skb)
{
struct nlmsghdr *nlh = nlmsg_hdr(skb);
- if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len)
+ if (skb->len < sizeof(*nlh) ||
+ nlh->nlmsg_len < sizeof(*nlh) ||
+ skb->len < nlh->nlmsg_len)
return;
if (!netlink_capable(skb, CAP_NET_ADMIN))
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* Re: [PATCH v2 2/2] net: emac: fix and unify emac_mdio functions
From: Andrew Lunn @ 2017-06-07 14:14 UTC (permalink / raw)
To: Christian Lamparter; +Cc: netdev, David S . Miller, Ivan Mikhaylov
In-Reply-To: <dc3b77e7ead819001e09589d1f95eb6c1061f381.1496773338.git.chunkeey@googlemail.com>
On Wed, Jun 07, 2017 at 03:51:16PM +0200, Christian Lamparter wrote:
> emac_mdio_read_link() was not copying the requested phy settings
> back into the emac driver's own phy api. This has caused a link
> speed mismatch issue for the AR8035 as the emac driver kept
> trying to connect with 10/100MBps on a 1GBit/s link.
>
> This patch also unifies shared code between emac_setup_aneg()
> and emac_mdio_setup_forced(). And furthermore it removes
> a chunk of emac_mdio_init_phy(), that was copying the same
> data into itself.
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/2] net: emac: fix reset timeout with AR8035 phy
From: Andrew Lunn @ 2017-06-07 14:13 UTC (permalink / raw)
To: Christian Lamparter
Cc: netdev, David S . Miller, Ivan Mikhaylov, Russell Senior,
Chris Blake
In-Reply-To: <eefbc6df06c83b725c60997fc58cf1c0119334a1.1496773338.git.chunkeey@googlemail.com>
On Wed, Jun 07, 2017 at 03:51:15PM +0200, Christian Lamparter wrote:
> This patch fixes a problem where the AR8035 PHY can't be
> detected on an Cisco Meraki MR24, if the ethernet cable is
> not connected on boot.
>
> Russell Senior provided steps to reproduce the issue:
> |Disconnect ethernet cable, apply power, wait until device has booted,
> |plug in ethernet, check for interfaces, no eth0 is listed.
> |
> |This appears to be a problem during probing of the AR8035 Phy chip.
> |When ethernet has no link, the phy detection fails, and eth0 is not
> |created. Plugging ethernet later has no effect, because there is no
> |interface as far as the kernel is concerned. The relevant part of
> |the boot log looks like this:
> |this is the failing case:
> |
> |[ 0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
> |[ 0.882532] /plb/opb/ethernet@ef600c00: reset timeout
> |[ 0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
> |and the succeeding case:
> |
> |[ 0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
> |[ 0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
> |[ 0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
>
> Based on the comment and the commit message of
> commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT").
> This is because the AR8035 PHY doesn't provide the TX Clock,
> if the ethernet cable is not attached. This causes the reset
> to timeout and the PHY detection code in emac_init_phy() is
> unable to detect the AR8035 PHY. As a result, the emac driver
> bails out early and the user left with no ethernet.
>
> In order to stay compatible with existing configurations, the driver
> tries the current reset approach at first. Only if the first attempt
> timed out, it does perform one more retry with the clock temporarily
> switched to the internal source for just the duration of the reset.
>
> LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
>
> Cc: Chris Blake <chrisrblake93@gmail.com>
> Reported-by: Russell Senior <russell@personaltelco.net>
> Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] udp: try to avoid 2 cache miss on dequeue
From: David Miller @ 2017-06-07 14:10 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet
In-Reply-To: <1496822205.2409.1.camel@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 07 Jun 2017 09:56:45 +0200
> Hi David,
>
> On Tue, 2017-06-06 at 16:23 +0200, Paolo Abeni wrote:
>> when udp_recvmsg() is executed, on x86_64 and other archs, most skb
>> fields are on cold cachelines.
>> If the skb are linear and the kernel don't need to compute the udp
>> csum, only a handful of skb fields are required by udp_recvmsg().
>> Since we already use skb->dev_scratch to cache hot data, and
>> there are 32 bits unused on 64 bit archs, use such field to cache
>> as much data as we can, and try to prefetch on dequeue the relevant
>> fields that are left out.
>>
>> This can save up to 2 cache miss per packet.
>>
>> v1 -> v2:
>> - changed udp_dev_scratch fields types to u{32,16} variant,
>> replaced bitfield with bool
>>
>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>
> Can you please keep on-hold this series a little time? the lkp-robot
> just reported a performance regression on v1 which I have still to
> investigate. I can't look at it really soon, but I expect the same
> should apply to v2.
>
> It sounds quite weird to me, since the bisected patch touches the UDP
> code only and the regression is on apachebench.
Hmmm, DNS lookups?
Thanks for looking into this.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: Clear and enable MIB counters on imx51
From: David Miller @ 2017-06-07 14:07 UTC (permalink / raw)
To: andrew; +Cc: netdev, nikita.yoush, fabio.estevam, cphealy
In-Reply-To: <1496800629-24910-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 7 Jun 2017 03:57:09 +0200
> Both the IMX51 and IMX53 datasheet indicates that the MIB counters
> should be cleared during setup. Otherwise random numbers are returned
> via ethtool -S. Add a quirk and a function to do this.
>
> Tested on an IMX51.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 2/2] net: emac: fix and unify emac_mdio functions
From: Christian Lamparter @ 2017-06-07 13:51 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Ivan Mikhaylov, Andrew Lunn
In-Reply-To: <eefbc6df06c83b725c60997fc58cf1c0119334a1.1496773338.git.chunkeey@googlemail.com>
emac_mdio_read_link() was not copying the requested phy settings
back into the emac driver's own phy api. This has caused a link
speed mismatch issue for the AR8035 as the emac driver kept
trying to connect with 10/100MBps on a 1GBit/s link.
This patch also unifies shared code between emac_setup_aneg()
and emac_mdio_setup_forced(). And furthermore it removes
a chunk of emac_mdio_init_phy(), that was copying the same
data into itself.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
drivers/net/ethernet/ibm/emac/core.c | 41 ++++++++++++++++--------------------
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index b6e871bfb659..259e69a52ec5 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -2478,20 +2478,24 @@ static int emac_mii_bus_reset(struct mii_bus *bus)
return emac_reset(dev);
}
+static int emac_mdio_phy_start_aneg(struct mii_phy *phy,
+ struct phy_device *phy_dev)
+{
+ phy_dev->autoneg = phy->autoneg;
+ phy_dev->speed = phy->speed;
+ phy_dev->duplex = phy->duplex;
+ phy_dev->advertising = phy->advertising;
+ return phy_start_aneg(phy_dev);
+}
+
static int emac_mdio_setup_aneg(struct mii_phy *phy, u32 advertise)
{
struct net_device *ndev = phy->dev;
struct emac_instance *dev = netdev_priv(ndev);
- dev->phy.autoneg = AUTONEG_ENABLE;
- dev->phy.speed = SPEED_1000;
- dev->phy.duplex = DUPLEX_FULL;
- dev->phy.advertising = advertise;
phy->autoneg = AUTONEG_ENABLE;
- phy->speed = dev->phy.speed;
- phy->duplex = dev->phy.duplex;
phy->advertising = advertise;
- return phy_start_aneg(dev->phy_dev);
+ return emac_mdio_phy_start_aneg(phy, dev->phy_dev);
}
static int emac_mdio_setup_forced(struct mii_phy *phy, int speed, int fd)
@@ -2499,13 +2503,10 @@ static int emac_mdio_setup_forced(struct mii_phy *phy, int speed, int fd)
struct net_device *ndev = phy->dev;
struct emac_instance *dev = netdev_priv(ndev);
- dev->phy.autoneg = AUTONEG_DISABLE;
- dev->phy.speed = speed;
- dev->phy.duplex = fd;
phy->autoneg = AUTONEG_DISABLE;
phy->speed = speed;
phy->duplex = fd;
- return phy_start_aneg(dev->phy_dev);
+ return emac_mdio_phy_start_aneg(phy, dev->phy_dev);
}
static int emac_mdio_poll_link(struct mii_phy *phy)
@@ -2527,16 +2528,17 @@ static int emac_mdio_read_link(struct mii_phy *phy)
{
struct net_device *ndev = phy->dev;
struct emac_instance *dev = netdev_priv(ndev);
+ struct phy_device *phy_dev = dev->phy_dev;
int res;
- res = phy_read_status(dev->phy_dev);
+ res = phy_read_status(phy_dev);
if (res)
return res;
- dev->phy.speed = phy->speed;
- dev->phy.duplex = phy->duplex;
- dev->phy.pause = phy->pause;
- dev->phy.asym_pause = phy->asym_pause;
+ phy->speed = phy_dev->speed;
+ phy->duplex = phy_dev->duplex;
+ phy->pause = phy_dev->pause;
+ phy->asym_pause = phy_dev->asym_pause;
return 0;
}
@@ -2546,13 +2548,6 @@ static int emac_mdio_init_phy(struct mii_phy *phy)
struct emac_instance *dev = netdev_priv(ndev);
phy_start(dev->phy_dev);
- dev->phy.autoneg = phy->autoneg;
- dev->phy.speed = phy->speed;
- dev->phy.duplex = phy->duplex;
- dev->phy.advertising = phy->advertising;
- dev->phy.pause = phy->pause;
- dev->phy.asym_pause = phy->asym_pause;
-
return phy_init_hw(dev->phy_dev);
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] net: emac: fix reset timeout with AR8035 phy
From: Christian Lamparter @ 2017-06-07 13:51 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Ivan Mikhaylov, Russell Senior, Andrew Lunn,
Chris Blake
This patch fixes a problem where the AR8035 PHY can't be
detected on an Cisco Meraki MR24, if the ethernet cable is
not connected on boot.
Russell Senior provided steps to reproduce the issue:
|Disconnect ethernet cable, apply power, wait until device has booted,
|plug in ethernet, check for interfaces, no eth0 is listed.
|
|This appears to be a problem during probing of the AR8035 Phy chip.
|When ethernet has no link, the phy detection fails, and eth0 is not
|created. Plugging ethernet later has no effect, because there is no
|interface as far as the kernel is concerned. The relevant part of
|the boot log looks like this:
|this is the failing case:
|
|[ 0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[ 0.882532] /plb/opb/ethernet@ef600c00: reset timeout
|[ 0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
|and the succeeding case:
|
|[ 0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[ 0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
|[ 0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
Based on the comment and the commit message of
commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT").
This is because the AR8035 PHY doesn't provide the TX Clock,
if the ethernet cable is not attached. This causes the reset
to timeout and the PHY detection code in emac_init_phy() is
unable to detect the AR8035 PHY. As a result, the emac driver
bails out early and the user left with no ethernet.
In order to stay compatible with existing configurations, the driver
tries the current reset approach at first. Only if the first attempt
timed out, it does perform one more retry with the clock temporarily
switched to the internal source for just the duration of the reset.
LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
Cc: Chris Blake <chrisrblake93@gmail.com>
Reported-by: Russell Senior <russell@personaltelco.net>
Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
v1 -> v2:
- made it clear, that the clock source is only switched
temporarily.
- fixed missing goto label, if !CONFIG_PPC_DCR_NATIVE
---
drivers/net/ethernet/ibm/emac/core.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 508923f39ccf..b6e871bfb659 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -343,6 +343,7 @@ static int emac_reset(struct emac_instance *dev)
{
struct emac_regs __iomem *p = dev->emacp;
int n = 20;
+ bool __maybe_unused try_internal_clock = false;
DBG(dev, "reset" NL);
@@ -355,6 +356,7 @@ static int emac_reset(struct emac_instance *dev)
}
#ifdef CONFIG_PPC_DCR_NATIVE
+do_retry:
/*
* PPC460EX/GT Embedded Processor Advanced User's Manual
* section 28.10.1 Mode Register 0 (EMACx_MR0) states:
@@ -362,10 +364,19 @@ static int emac_reset(struct emac_instance *dev)
* of the EMAC. If none is present, select the internal clock
* (SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
* After a soft reset, select the external clock.
+ *
+ * The AR8035-A PHY Meraki MR24 does not provide a TX Clk if the
+ * ethernet cable is not attached. This causes the reset to timeout
+ * and the PHY detection code in emac_init_phy() is unable to
+ * communicate and detect the AR8035-A PHY. As a result, the emac
+ * driver bails out early and the user has no ethernet.
+ * In order to stay compatible with existing configurations, the
+ * driver will temporarily switch to the internal clock, after
+ * the first reset fails.
*/
if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
- if (dev->phy_address == 0xffffffff &&
- dev->phy_map == 0xffffffff) {
+ if (try_internal_clock || (dev->phy_address == 0xffffffff &&
+ dev->phy_map == 0xffffffff)) {
/* No PHY: select internal loop clock before reset */
dcri_clrset(SDR0, SDR0_ETH_CFG,
0, SDR0_ETH_CFG_ECS << dev->cell_index);
@@ -383,8 +394,15 @@ static int emac_reset(struct emac_instance *dev)
#ifdef CONFIG_PPC_DCR_NATIVE
if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
- if (dev->phy_address == 0xffffffff &&
- dev->phy_map == 0xffffffff) {
+ if (!n && !try_internal_clock) {
+ /* first attempt has timed out. */
+ n = 20;
+ try_internal_clock = true;
+ goto do_retry;
+ }
+
+ if (try_internal_clock || (dev->phy_address == 0xffffffff &&
+ dev->phy_map == 0xffffffff)) {
/* No PHY: restore external clock source after reset */
dcri_clrset(SDR0, SDR0_ETH_CFG,
SDR0_ETH_CFG_ECS << dev->cell_index, 0);
--
2.11.0
^ permalink raw reply related
* [PATCH v2] netfilter: nfnetlink: Improve input length sanitization in nfnetlink_rcv
From: Mateusz Jurczyk @ 2017-06-07 13:50 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1496841821.736.35.camel@edumazet-glaptop3.roam.corp.google.com>
Verify that the length of the socket buffer is sufficient to cover the
nlmsghdr structure before accessing the nlh->nlmsg_len field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < NLMSG_HDRLEN expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
Changes in v2:
- Compare skb->len against NLMSG_HDRLEN to avoid assuming the layout of
the nlmsghdr structure.
net/netfilter/nfnetlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 80f5ecf2c3d7..1f9667f52be5 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -491,7 +491,8 @@ static void nfnetlink_rcv(struct sk_buff *skb)
{
struct nlmsghdr *nlh = nlmsg_hdr(skb);
- if (nlh->nlmsg_len < NLMSG_HDRLEN ||
+ if (skb->len < NLMSG_HDRLEN ||
+ nlh->nlmsg_len < NLMSG_HDRLEN ||
skb->len < nlh->nlmsg_len)
return;
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* Re: [PATCH net-next] net: fec: Clear and enable MIB counters on imx51
From: Fabio Estevam @ 2017-06-07 13:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, Nikita Yushchenko, Fabio Estevam,
Chris Healy
In-Reply-To: <1496800629-24910-1-git-send-email-andrew@lunn.ch>
On Tue, Jun 6, 2017 at 10:57 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Both the IMX51 and IMX53 datasheet indicates that the MIB counters
> should be cleared during setup. Otherwise random numbers are returned
> via ethtool -S. Add a quirk and a function to do this.
>
> Tested on an IMX51.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Thanks for the fix:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 4/4] net: macb: Add hardware PTP support
From: Richard Cochran @ 2017-06-07 13:28 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller,
nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
andrei.pistirica-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org
In-Reply-To: <BN3PR07MB2516A47C2CFEB58BCFFB2C46C9C80-EldUQEzkDQfxGZiqM5fOI+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Wed, Jun 07, 2017 at 11:13:36AM +0000, Rafal Ozieblo wrote:
> Please look at following call-stack:
>
> 1. macb_interrupt() // spin_lock(&bp->lock) is taken
> 2. macb_tx_interrupt()
> 3. macb_handle_txtstamp()
> 4. skb_tstamp_tx()
> 5. __skb_tstamp_tx()
> 6. skb_may_tx_timestamp()
> 7. read_lock_bh() // second lock is taken
Well, you can always drop the lock, or postpone the call to
skb_tstamp_tx() until after the spin lock is released...
> I know that those are different locks and different types. But this could lead
> to deadlocks. This is the reason of warning I could see.
Can you please post the lockdep splat?
Thanks,
Richard
--
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 net-next 0/3] mlx4 drivers: version update
From: Tariq Toukan @ 2017-06-07 13:26 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-rdma, Eran Ben Elisha, Leon Romanovsky,
Tariq Toukan
Hi Dave,
This patchset contains version updates for the MLX4 drivers:
Core, EN, and IB.
Just like we've done in mlx5, we modify the outdated driver
version (reported in ethtool for example).
This better reflects the current driver state, and removes the
redundant date string.
We are not going to change this frequently or even use it.
I include the IB patch in this series as it has similar subject
and content.
It does not cause any kind of conflict with Doug's tree.
The rdma mailing list is CCed.
Please let me know if I need to submit this differently.
Series generated against net-next commit:
216fe8f021e3 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Thanks,
Tariq.
Tariq Toukan (3):
net/mlx4_core: Bump driver version
net/mlx4_en: Bump driver version
IB/mlx4: Bump driver version
drivers/infiniband/hw/mlx4/main.c | 5 ++---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 +--
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +--
6 files changed, 8 insertions(+), 11 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 2/3] net/mlx4_en: Bump driver version
From: Tariq Toukan @ 2017-06-07 13:26 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-rdma, Eran Ben Elisha, Leon Romanovsky,
Tariq Toukan
In-Reply-To: <1496841975-7728-1-git-send-email-tariqt@mellanox.com>
Remove date and bump version for mlx4_en driver.
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 ++--
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index ffbcb27c05e5..e97fbf327594 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -89,7 +89,7 @@ static int mlx4_en_moderation_update(struct mlx4_en_priv *priv)
struct mlx4_en_dev *mdev = priv->mdev;
strlcpy(drvinfo->driver, DRV_NAME, sizeof(drvinfo->driver));
- strlcpy(drvinfo->version, DRV_VERSION " (" DRV_RELDATE ")",
+ strlcpy(drvinfo->version, DRV_VERSION,
sizeof(drvinfo->version));
snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
"%d.%d.%d",
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_main.c b/drivers/net/ethernet/mellanox/mlx4/en_main.c
index 36a7a54bbb82..d94f981eafc4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_main.c
@@ -46,11 +46,11 @@
MODULE_AUTHOR("Liran Liss, Yevgeny Petrilin");
MODULE_DESCRIPTION("Mellanox ConnectX HCA Ethernet driver");
MODULE_LICENSE("Dual BSD/GPL");
-MODULE_VERSION(DRV_VERSION " ("DRV_RELDATE")");
+MODULE_VERSION(DRV_VERSION);
static const char mlx4_en_version[] =
DRV_NAME ": Mellanox ConnectX HCA Ethernet driver v"
- DRV_VERSION " (" DRV_RELDATE ")\n";
+ DRV_VERSION "\n";
#define MLX4_EN_PARM_INT(X, def_val, desc) \
static unsigned int X = def_val;\
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 39f401aa3047..8c4f63946b14 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -58,8 +58,7 @@
#include "mlx4_stats.h"
#define DRV_NAME "mlx4_en"
-#define DRV_VERSION "2.2-1"
-#define DRV_RELDATE "Feb 2014"
+#define DRV_VERSION "4.0-0"
#define MLX4_EN_MSG_LEVEL (NETIF_MSG_LINK | NETIF_MSG_IFDOWN)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/3] IB/mlx4: Bump driver version
From: Tariq Toukan @ 2017-06-07 13:26 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Eran Ben Elisha, Leon Romanovsky, Tariq Toukan
In-Reply-To: <1496841975-7728-1-git-send-email-tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Remove date and bump version for mlx4_ib driver.
Signed-off-by: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/infiniband/hw/mlx4/main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 521d0def2d9e..75b2f7d4cd95 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -61,8 +61,7 @@
#include <rdma/mlx4-abi.h>
#define DRV_NAME MLX4_IB_DRV_NAME
-#define DRV_VERSION "2.2-1"
-#define DRV_RELDATE "Feb 2014"
+#define DRV_VERSION "4.0-0"
#define MLX4_IB_FLOW_MAX_PRIO 0xFFF
#define MLX4_IB_FLOW_QPN_MASK 0xFFFFFF
@@ -79,7 +78,7 @@
static const char mlx4_ib_version[] =
DRV_NAME ": Mellanox ConnectX InfiniBand driver v"
- DRV_VERSION " (" DRV_RELDATE ")\n";
+ DRV_VERSION "\n";
static void do_slave_init(struct mlx4_ib_dev *ibdev, int slave, int do_init);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next 1/3] net/mlx4_core: Bump driver version
From: Tariq Toukan @ 2017-06-07 13:26 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Eran Ben Elisha, Leon Romanovsky, Tariq Toukan
In-Reply-To: <1496841975-7728-1-git-send-email-tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Remove date and bump version for mlx4_core driver.
Signed-off-by: Tariq Toukan <tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 83aab1e4c8c8..ccae3c6593c4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -119,7 +119,7 @@
static char mlx4_version[] =
DRV_NAME ": Mellanox ConnectX core driver v"
- DRV_VERSION " (" DRV_RELDATE ")\n";
+ DRV_VERSION "\n";
static struct mlx4_profile default_profile = {
.num_qp = 1 << 18,
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index b4f1bc56cc68..6ea2b7a0c34d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -56,8 +56,7 @@
#define DRV_NAME "mlx4_core"
#define PFX DRV_NAME ": "
-#define DRV_VERSION "2.2-1"
-#define DRV_RELDATE "Feb, 2014"
+#define DRV_VERSION "4.0-0"
#define MLX4_FS_UDP_UC_EN (1 << 1)
#define MLX4_FS_TCP_UC_EN (1 << 2)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH] netfilter: nfnetlink: Improve input length sanitization in nfnetlink_rcv
From: Eric Dumazet @ 2017-06-07 13:23 UTC (permalink / raw)
To: Mateusz Jurczyk
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20170607123551.25075-1-mjurczyk@google.com>
On Wed, 2017-06-07 at 14:35 +0200, Mateusz Jurczyk wrote:
> Verify that the length of the socket buffer is sufficient to cover the
> entire nlh->nlmsg_len field before accessing that field for further
> input sanitization. If the client only supplies 1-3 bytes of data in
> sk_buff, then nlh->nlmsg_len remains partially uninitialized and
> contains leftover memory from the corresponding kernel allocation.
> Operating on such data may result in indeterminate evaluation of the
> nlmsg_len < NLMSG_HDRLEN expression.
>
> The bug was discovered by a runtime instrumentation designed to detect
> use of uninitialized memory in the kernel. The patch prevents this and
> other similar tools (e.g. KMSAN) from flagging this behavior in the future.
>
> Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
> ---
> net/netfilter/nfnetlink.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 80f5ecf2c3d7..c634cfca40ec 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -491,7 +491,8 @@ static void nfnetlink_rcv(struct sk_buff *skb)
> {
> struct nlmsghdr *nlh = nlmsg_hdr(skb);
>
> - if (nlh->nlmsg_len < NLMSG_HDRLEN ||
> + if (skb->len < sizeof(nlh->nlmsg_len) ||
This assumes nlmsg_len is first field of the structure.
offsetofend() might be more descriptive, one does not have to check the
structure to make sure the code is correct.
Or simply use the more common form :
if (skb->len < NLMSG_HDRLEN ||
> + nlh->nlmsg_len < NLMSG_HDRLEN ||
> skb->len < nlh->nlmsg_len)
> return;
>
^ permalink raw reply
* [iproute PATCH] iproute: Remove useless check for nexthop keyword when setting RTA_OIF
From: Jakub Sitnicki @ 2017-06-07 13:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
When modifying a route we set the RTA_OIF attribute only if a device was
specified with "dev" or "oif" keyword. But for some unknown reason we
earlier alternatively check also for the presence of "nexthop" keyword,
even though it has no effect. So remove the pointless check.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
ip/iproute.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index b4ca291..4fd36a1 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -1241,16 +1241,14 @@ static int iproute_modify(int cmd, unsigned int flags, int argc, char **argv)
if (!dst_ok)
usage();
- if (d || nhs_ok) {
+ if (d) {
int idx;
- if (d) {
- if ((idx = ll_name_to_index(d)) == 0) {
- fprintf(stderr, "Cannot find device \"%s\"\n", d);
- return -1;
- }
- addattr32(&req.n, sizeof(req), RTA_OIF, idx);
+ if ((idx = ll_name_to_index(d)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", d);
+ return -1;
}
+ addattr32(&req.n, sizeof(req), RTA_OIF, idx);
}
if (mxrta->rta_len > RTA_LENGTH(0)) {
--
2.9.4
^ permalink raw reply related
* [PATCH] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
From: Mateusz Jurczyk @ 2017-06-07 13:14 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: David S. Miller, netfilter-devel, coreteam, linux-decnet-user,
netdev, linux-kernel
Verify that the length of the socket buffer is sufficient to cover the
entire nlh->nlmsg_len field before accessing that field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < sizeof(*nlh) expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
net/decnet/netfilter/dn_rtmsg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/decnet/netfilter/dn_rtmsg.c b/net/decnet/netfilter/dn_rtmsg.c
index 1ed81ac6dd1a..26e020e9d415 100644
--- a/net/decnet/netfilter/dn_rtmsg.c
+++ b/net/decnet/netfilter/dn_rtmsg.c
@@ -102,7 +102,9 @@ static inline void dnrmg_receive_user_skb(struct sk_buff *skb)
{
struct nlmsghdr *nlh = nlmsg_hdr(skb);
- if (nlh->nlmsg_len < sizeof(*nlh) || skb->len < nlh->nlmsg_len)
+ if (skb->len < sizeof(nlh->nlmsg_len) ||
+ nlh->nlmsg_len < sizeof(*nlh) ||
+ skb->len < nlh->nlmsg_len)
return;
if (!netlink_capable(skb, CAP_NET_ADMIN))
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* [PATCH net-next] net: dsa: mv88e6xxx: Have 6161/6123 use EDSA tags
From: Andrew Lunn @ 2017-06-07 13:06 UTC (permalink / raw)
To: David Miller
Cc: netdev, Chris Healy, Vivien Didelot, Nikita Yushchenko,
Andrew Lunn
The mv88e6161 and mv88e6123 are capable of using EDSA tags when
passing frames from the host to the switch and back.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index ea20c4ee30b6..f53bae07387f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3279,7 +3279,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.g1_irqs = 9,
.atu_move_port_mask = 0xf,
.pvt = true,
- .tag_protocol = DSA_TAG_PROTO_DSA,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6165,
.ops = &mv88e6123_ops,
},
@@ -3331,7 +3331,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.g1_irqs = 9,
.atu_move_port_mask = 0xf,
.pvt = true,
- .tag_protocol = DSA_TAG_PROTO_DSA,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6165,
.ops = &mv88e6161_ops,
},
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/2] tcp: md5: add fields to the tcp_md5sig struct to set a key address prefix
From: Eric Dumazet @ 2017-06-07 12:51 UTC (permalink / raw)
To: Ivan Delalande; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20170607061320.GB11691@ycc.fr>
On Wed, 2017-06-07 at 08:13 +0200, Ivan Delalande wrote:
> On Tue, Jun 06, 2017 at 09:08:22PM -0700, Eric Dumazet wrote:
> > On Tue, 2017-06-06 at 17:54 -0700, Ivan Delalande wrote:
> >> diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
> >> index 38a2b07afdff..52ac30aa0652 100644
> >> --- a/include/uapi/linux/tcp.h
> >> +++ b/include/uapi/linux/tcp.h
> >> @@ -234,9 +234,13 @@ enum {
> >> /* for TCP_MD5SIG socket option */
> >> #define TCP_MD5SIG_MAXKEYLEN 80
> >>
> >> +/* tcp_md5sig flags */
> >> +#define TCP_MD5SIG_FLAG_PREFIX 1 /* address prefix length */
> >> +
> >> struct tcp_md5sig {
> >> struct __kernel_sockaddr_storage tcpm_addr; /* address associated */
> >> - __u16 __tcpm_pad1; /* zero */
> >> + __u8 tcpm_flags; /* flags */
> >> + __u8 tcpm_prefixlen; /* address prefix */
> >> __u16 tcpm_keylen; /* key length */
> >> __u32 __tcpm_pad2; /* zero */
> >> __u8 tcpm_key[TCP_MD5SIG_MAXKEYLEN]; /* key (binary) */
> >
> > This will break some applications that maybe did not clear the
> > __tcpm_pad1 field ?
> >
> >
> > You need to find another way to maintain compatibility with old
> > applications.
>
> All right, I thought this was acceptable after seeing a few examples of
> this in commits extending other structures in uapi, but the context and
> use were probably different for those.
>
> We had another version of this patch which steals a bit from tcpm_keylen
> to use as a flag for this feature specifically and with the prefixlen at
> the same place as this patch. So when the flag is set we know we can
> safely interpret this part of the padding field as a prefix as all valid
> calls from older user programs should not have a key length greater than
> 80 bytes.
>
> Would this be better? Programs compiled with the new headers could break
> on older kernels if they don't check the version, I don't know if that's
> a concern.
>
> Or should we just add these two new fields at the end of tcp_md5sig and
> use them only if the value of optlen in the parse function called from
> setsockopt is large enough?
I believe this is the deferrable way to handle this.
But note that old kernels would not send an error back, if an
application tries the new semantic.
^ permalink raw reply
* [PATCH] netfilter: nfnetlink: Improve input length sanitization in nfnetlink_rcv
From: Mateusz Jurczyk @ 2017-06-07 12:35 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
Verify that the length of the socket buffer is sufficient to cover the
entire nlh->nlmsg_len field before accessing that field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < NLMSG_HDRLEN expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
---
net/netfilter/nfnetlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 80f5ecf2c3d7..c634cfca40ec 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -491,7 +491,8 @@ static void nfnetlink_rcv(struct sk_buff *skb)
{
struct nlmsghdr *nlh = nlmsg_hdr(skb);
- if (nlh->nlmsg_len < NLMSG_HDRLEN ||
+ if (skb->len < sizeof(nlh->nlmsg_len) ||
+ nlh->nlmsg_len < NLMSG_HDRLEN ||
skb->len < nlh->nlmsg_len)
return;
--
2.13.1.508.gb3defc5cc-goog
^ permalink raw reply related
* [PATCH iproute] tc: flower: add support for matching on ip tos and ttl
From: Or Gerlitz @ 2017-06-07 12:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Roi Dayan, Paul Blakey, Or Gerlitz
Allow users to set flower classifier filter rules which
include matches for ip tos and ttl.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
man/man8/tc-flower.8 | 17 +++++++++++-
tc/f_flower.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index 7648079..be46f02 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -30,7 +30,11 @@ flower \- flow based traffic control filter
.BR vlan_ethtype " { " ipv4 " | " ipv6 " | "
.IR ETH_TYPE " } | "
.BR ip_proto " { " tcp " | " udp " | " sctp " | " icmp " | " icmpv6 " | "
-.IR IP_PROTO " } | { "
+.IR IP_PROTO " } | "
+.B ip_tos
+.IR MASKED_IP_TOS " | "
+.B ip_ttl
+.IR MASKED_IP_TTL " | { "
.BR dst_ip " | " src_ip " } "
.IR PREFIX " | { "
.BR dst_port " | " src_port " } "
@@ -122,6 +126,17 @@ may be
.BR tcp ", " udp ", " sctp ", " icmp ", " icmpv6
or an unsigned 8bit value in hexadecimal format.
.TP
+.BI ip_tos " MASKED_IP_TOS"
+Match on ipv4 TOS or ipv6 traffic-class - eight bits in hexadecimal format.
+A mask may be optionally provided to limit the bits which are matched. A mask
+is provided by following the value with a slash and then the mask. If the mask
+is missing then a match on all bits is assumed.
+.TP
+.BI ip_ttl " MASKED_IP_TTL"
+Match on ipv4 TTL or ipv6 hop-limit - eight bits value in decimal or hexadecimal format.
+A mask may be optionally provided to limit the bits which are matched. Same
+logic is used for the mask as with matching on ip_tos.
+.TP
.BI dst_ip " PREFIX"
.TQ
.BI src_ip " PREFIX"
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 1b6b46e..5be693a 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -53,6 +53,8 @@ static void explain(void)
" dst_mac MASKED-LLADDR |\n"
" src_mac MASKED-LLADDR |\n"
" ip_proto [tcp | udp | sctp | icmp | icmpv6 | IP-PROTO ] |\n"
+ " ip_tos MASKED-IP_TOS |\n"
+ " ip_ttl MASKED-IP_TTL |\n"
" dst_ip PREFIX |\n"
" src_ip PREFIX |\n"
" dst_port PORT-NUMBER |\n"
@@ -510,6 +512,41 @@ err:
return err;
}
+static int flower_parse_ip_tos_ttl(char *str, int key_type, int mask_type,
+ struct nlmsghdr *n)
+{
+ char *slash;
+ int ret, err = -1;
+ __u8 tos_ttl;
+
+ slash = strchr(str, '/');
+ if (slash)
+ *slash = '\0';
+
+ ret = get_u8(&tos_ttl, str, 10);
+ if (ret < 0)
+ ret = get_u8(&tos_ttl, str, 16);
+ if (ret < 0)
+ goto err;
+
+ addattr8(n, MAX_MSG, key_type, tos_ttl);
+
+ if (slash) {
+ ret = get_u8(&tos_ttl, slash + 1, 16);
+ if (ret < 0)
+ goto err;
+ } else {
+ tos_ttl = 0xff;
+ }
+ addattr8(n, MAX_MSG, mask_type, tos_ttl);
+
+ err = 0;
+err:
+ if (slash)
+ *slash = '/';
+ return err;
+}
+
static int flower_parse_key_id(const char *str, int type, struct nlmsghdr *n)
{
int ret;
@@ -665,6 +702,26 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
fprintf(stderr, "Illegal \"ip_proto\"\n");
return -1;
}
+ } else if (matches(*argv, "ip_tos") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_ip_tos_ttl(*argv,
+ TCA_FLOWER_KEY_IP_TOS,
+ TCA_FLOWER_KEY_IP_TOS_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"ip_tos\"\n");
+ return -1;
+ }
+ } else if (matches(*argv, "ip_ttl") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_ip_tos_ttl(*argv,
+ TCA_FLOWER_KEY_IP_TTL,
+ TCA_FLOWER_KEY_IP_TTL_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"ip_ttl\"\n");
+ return -1;
+ }
} else if (matches(*argv, "dst_ip") == 0) {
NEXT_ARG();
ret = flower_parse_ip_addr(*argv, vlan_ethtype ?
@@ -963,6 +1020,19 @@ static void flower_print_ip_proto(FILE *f, __u8 *p_ip_proto,
*p_ip_proto = ip_proto;
}
+static void flower_print_ip_attr(FILE *f, char *name,
+ struct rtattr *key_attr,
+ struct rtattr *mask_attr)
+{
+ if (!key_attr)
+ return;
+
+ fprintf(f, "\n %s %x", name, rta_getattr_u8(key_attr));
+ if (!mask_attr)
+ return;
+ fprintf(f, "/%x", rta_getattr_u8(mask_attr));
+}
+
static void flower_print_matching_flags(FILE *f, char *name,
enum flower_matching_flags type,
struct rtattr *attr,
@@ -1150,6 +1220,11 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
flower_print_eth_type(f, ð_type, tb[TCA_FLOWER_KEY_ETH_TYPE]);
flower_print_ip_proto(f, &ip_proto, tb[TCA_FLOWER_KEY_IP_PROTO]);
+ flower_print_ip_attr(f, "ip_tos", tb[TCA_FLOWER_KEY_IP_TOS],
+ tb[TCA_FLOWER_KEY_IP_TOS_MASK]);
+ flower_print_ip_attr(f, "ip_ttl", tb[TCA_FLOWER_KEY_IP_TTL],
+ tb[TCA_FLOWER_KEY_IP_TTL_MASK]);
+
flower_print_ip_addr(f, "dst_ip", eth_type,
tb[TCA_FLOWER_KEY_IPV4_DST],
tb[TCA_FLOWER_KEY_IPV4_DST_MASK],
--
2.3.7
^ permalink raw reply related
* Re: [PATCH 7/9] net: mvmdio: add xmdio support
From: Andrew Lunn @ 2017-06-07 12:12 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, jason, gregory.clement, sebastian.hesselbarth, f.fainelli,
thomas.petazzoni, mw, linux, netdev, linux-arm-kernel
In-Reply-To: <20170607083810.30922-8-antoine.tenart@free-electrons.com>
On Wed, Jun 07, 2017 at 10:38:08AM +0200, Antoine Tenart wrote:
> This patch adds the xMDIO interface support in the mvmdio driver. This
> interface is used in Ethernet controllers on Marvell 370, 7k and 8k (as
> of now). The xSMI interface supported by this driver complies with the
> IEEE 802.3 clause 45 (while the SMI interface complies with the clause
> 22). The xSMI interface is used by 10GbE devices.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Hi Antoine
I've only take a quick look, but i don't see anywhere you look at the
register address and see if it has MII_ADDR_C45 to determine if a C45
transaction should be done, or a C22. The MDIO bus can have a mix of
C45 and C22 devices on it, and you need to use the correct transaction
type depending on the target device/address.
Andrew
^ permalink raw reply
* Re: [PATCH net] bpf, arm64: use separate register for state in stxr
From: Will Deacon @ 2017-06-07 11:51 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, ast, zlim.lnx, netdev, linux-arm-kernel
In-Reply-To: <530443d87bd51b3682a1b60ea19b2030d7d21409.1496834547.git.daniel@iogearbox.net>
Hi Daniel,
On Wed, Jun 07, 2017 at 01:45:37PM +0200, Daniel Borkmann wrote:
> Will reported that in BPF_XADD we must use a different register in stxr
> instruction for the status flag due to otherwise CONSTRAINED UNPREDICTABLE
> behavior per architecture. Reference manual says [1]:
>
> If s == t, then one of the following behaviors must occur:
>
> * The instruction is UNDEFINED.
> * The instruction executes as a NOP.
> * The instruction performs the store to the specified address, but
> the value stored is UNKNOWN.
>
> Thus, use a different temporary register for the status flag to fix it.
>
> Disassembly extract from test 226/STX_XADD_DW from test_bpf.ko:
>
> [...]
> 0000003c: c85f7d4b ldxr x11, [x10]
> 00000040: 8b07016b add x11, x11, x7
> 00000044: c80c7d4b stxr w12, x11, [x10]
> 00000048: 35ffffac cbnz w12, 0x0000003c
> [...]
>
> [1] https://static.docs.arm.com/ddi0487/b/DDI0487B_a_armv8_arm.pdf, p.6132
>
> Fixes: 85f68fe89832 ("bpf, arm64: implement jiting of BPF_XADD")
> Reported-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> arch/arm64/net/bpf_jit_comp.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Cheers for fixing this up:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH net] bpf, arm64: use separate register for state in stxr
From: Daniel Borkmann @ 2017-06-07 11:45 UTC (permalink / raw)
To: davem; +Cc: will.deacon, ast, zlim.lnx, netdev, linux-arm-kernel,
Daniel Borkmann
Will reported that in BPF_XADD we must use a different register in stxr
instruction for the status flag due to otherwise CONSTRAINED UNPREDICTABLE
behavior per architecture. Reference manual says [1]:
If s == t, then one of the following behaviors must occur:
* The instruction is UNDEFINED.
* The instruction executes as a NOP.
* The instruction performs the store to the specified address, but
the value stored is UNKNOWN.
Thus, use a different temporary register for the status flag to fix it.
Disassembly extract from test 226/STX_XADD_DW from test_bpf.ko:
[...]
0000003c: c85f7d4b ldxr x11, [x10]
00000040: 8b07016b add x11, x11, x7
00000044: c80c7d4b stxr w12, x11, [x10]
00000048: 35ffffac cbnz w12, 0x0000003c
[...]
[1] https://static.docs.arm.com/ddi0487/b/DDI0487B_a_armv8_arm.pdf, p.6132
Fixes: 85f68fe89832 ("bpf, arm64: implement jiting of BPF_XADD")
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
arch/arm64/net/bpf_jit_comp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 71f9305..c870d6f 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -36,6 +36,7 @@
#define TMP_REG_1 (MAX_BPF_JIT_REG + 0)
#define TMP_REG_2 (MAX_BPF_JIT_REG + 1)
#define TCALL_CNT (MAX_BPF_JIT_REG + 2)
+#define TMP_REG_3 (MAX_BPF_JIT_REG + 3)
/* Map BPF registers to A64 registers */
static const int bpf2a64[] = {
@@ -57,6 +58,7 @@
/* temporary registers for internal BPF JIT */
[TMP_REG_1] = A64_R(10),
[TMP_REG_2] = A64_R(11),
+ [TMP_REG_3] = A64_R(12),
/* tail_call_cnt */
[TCALL_CNT] = A64_R(26),
/* temporary register for blinding constants */
@@ -319,6 +321,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
const u8 src = bpf2a64[insn->src_reg];
const u8 tmp = bpf2a64[TMP_REG_1];
const u8 tmp2 = bpf2a64[TMP_REG_2];
+ const u8 tmp3 = bpf2a64[TMP_REG_3];
const s16 off = insn->off;
const s32 imm = insn->imm;
const int i = insn - ctx->prog->insnsi;
@@ -689,10 +692,10 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
emit(A64_PRFM(tmp, PST, L1, STRM), ctx);
emit(A64_LDXR(isdw, tmp2, tmp), ctx);
emit(A64_ADD(isdw, tmp2, tmp2, src), ctx);
- emit(A64_STXR(isdw, tmp2, tmp, tmp2), ctx);
+ emit(A64_STXR(isdw, tmp2, tmp, tmp3), ctx);
jmp_offset = -3;
check_imm19(jmp_offset);
- emit(A64_CBNZ(0, tmp2, jmp_offset), ctx);
+ emit(A64_CBNZ(0, tmp3, jmp_offset), ctx);
break;
/* R0 = ntohx(*(size *)(((struct sk_buff *)R6)->data + imm)) */
--
1.9.3
^ permalink raw reply related
* EMAIL UPDATE
From: IT Department @ 2017-06-07 11:27 UTC (permalink / raw)
To: netdev
Recently, we have detect some unusual activity on your account and as a result, all email users are urged to update their email account within 24 hours of receiving this e-mail, please click the link http://beam.to/1469 to confirm that your email account is up to date with the institution requirement.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
<JOM JIMAT GO GREEN>
Please Do Not Print If Unnecessary. JOM JIMAT. GO GREEN.
This e-mail and any files transmitted with it (message) is intended only
for the use recepient (s) named and may contain confidential
information. Opinions, conclusion and other information in this
message that do not relate to the official business of PERBADANAN
NASIONAL BERHAD (PNS) or its Group of Companies shall be
understood as neither given or nor endorsed by PNS or any of the
Companies within the Group.
^ 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