* [PATCH nf v3] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack
From: fgao @ 2016-09-22 2:22 UTC (permalink / raw)
To: pablo, kaber, netfilter-devel, netdev; +Cc: gfree.wind, Gao Feng
From: Gao Feng <fgao@ikuai8.com>
It is valid that the TCP RST packet which does not set ack flag, and bytes
of ack number are zero. But current seqadj codes would adjust the "0" ack
to invalid ack number. Actually seqadj need to check the ack flag before
adjust it for these RST packets.
The following is my test case
client is 10.26.98.245, and add one iptable rule:
iptables -I INPUT -p tcp --sport 12345 -m connbytes --connbytes 2:
--connbytes-dir reply --connbytes-mode packets -j REJECT --reject-with
tcp-reset
This iptables rule could generate on TCP RST without ack flag.
server:10.172.135.55
Enable the synproxy with seqadjust by the following iptables rules
iptables -t raw -A PREROUTING -i eth0 -p tcp -d 10.172.135.55 --dport 12345
-m tcp --syn -j CT --notrack
iptables -A INPUT -i eth0 -p tcp -d 10.172.135.55 --dport 12345 -m conntrack
--ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7
--mss 1460
iptables -A OUTPUT -o eth0 -p tcp -s 10.172.135.55 --sport 12345 -m conntrack
--ctstate INVALID,UNTRACKED -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -j ACCEPT
The following is my test result.
1. packet trace on client
root@routers:/tmp# tcpdump -i eth0 tcp port 12345 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [S], seq 3695959829,
win 29200, options [mss 1460,sackOK,TS val 452367884 ecr 0,nop,wscale 7],
length 0
IP 10.172.135.55.12345 > 10.26.98.245.45154: Flags [S.], seq 546723266,
ack 3695959830, win 0, options [mss 1460,sackOK,TS val 15643479 ecr 452367884,
nop,wscale 7], length 0
IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [.], ack 1, win 229,
options [nop,nop,TS val 452367885 ecr 15643479], length 0
IP 10.172.135.55.12345 > 10.26.98.245.45154: Flags [.], ack 1, win 226,
options [nop,nop,TS val 15643479 ecr 452367885], length 0
IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [R], seq 3695959830,
win 0, length 0
2. seqadj log on server
[62873.867319] Adjusting sequence number from 602341895->546723267,
ack from 3695959830->3695959830
[62873.867644] Adjusting sequence number from 602341895->546723267,
ack from 3695959830->3695959830
[62873.869040] Adjusting sequence number from 3695959830->3695959830,
ack from 0->55618628
To summarize, it is clear that the seqadj codes adjust the 0 ack when receive
one TCP RST packet without ack.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
v3: Add the reproduce steps and packet trace
v2: Regenerate because the first patch is removed
v1: Initial patch
net/netfilter/nf_conntrack_seqadj.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c
index dff0f0c..3bd9c7e 100644
--- a/net/netfilter/nf_conntrack_seqadj.c
+++ b/net/netfilter/nf_conntrack_seqadj.c
@@ -179,30 +179,34 @@ int nf_ct_seq_adjust(struct sk_buff *skb,
tcph = (void *)skb->data + protoff;
spin_lock_bh(&ct->lock);
+
if (after(ntohl(tcph->seq), this_way->correction_pos))
seqoff = this_way->offset_after;
else
seqoff = this_way->offset_before;
- if (after(ntohl(tcph->ack_seq) - other_way->offset_before,
- other_way->correction_pos))
- ackoff = other_way->offset_after;
- else
- ackoff = other_way->offset_before;
-
newseq = htonl(ntohl(tcph->seq) + seqoff);
- newack = htonl(ntohl(tcph->ack_seq) - ackoff);
-
inet_proto_csum_replace4(&tcph->check, skb, tcph->seq, newseq, false);
- inet_proto_csum_replace4(&tcph->check, skb, tcph->ack_seq, newack,
- false);
-
- pr_debug("Adjusting sequence number from %u->%u, ack from %u->%u\n",
- ntohl(tcph->seq), ntohl(newseq), ntohl(tcph->ack_seq),
- ntohl(newack));
+ pr_debug("Adjusting sequence number from %u->%u\n",
+ ntohl(tcph->seq), ntohl(newseq));
tcph->seq = newseq;
- tcph->ack_seq = newack;
+
+ if (likely(tcph->ack)) {
+ if (after(ntohl(tcph->ack_seq) - other_way->offset_before,
+ other_way->correction_pos))
+ ackoff = other_way->offset_after;
+ else
+ ackoff = other_way->offset_before;
+
+ newack = htonl(ntohl(tcph->ack_seq) - ackoff);
+ inet_proto_csum_replace4(&tcph->check, skb, tcph->ack_seq,
+ newack, false);
+
+ pr_debug("Adjusting ack number from %u->%u\n",
+ ntohl(tcph->ack_seq), ntohl(newack));
+ tcph->ack_seq = newack;
+ }
res = nf_ct_sack_adjust(skb, protoff, tcph, ct, ctinfo);
spin_unlock_bh(&ct->lock);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module
From: sean.wang @ 2016-09-22 2:33 UTC (permalink / raw)
To: john, davem
Cc: nbd, netdev, linux-kernel, linux-mediatek, andrew, f.fainelli,
keyhaede, objelf, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
By default, GMAC0 is connected to built-in switch called
MT7530 through the proprietary interface called Turbo RGMII
(TRGMII). TRGMII also supports well for RGMII as generic external
PHY uses but requires some slight changes to the setup of TRGMII
and doesn't have well support on current driver.
So this patchset
1) provides the slight changes of the setup for RGMII can work
through TRGMII
2) adds additional setting "trgmii" as PHY_INTERFACE_MODE_TRGMII
about phy-mode on device tree to make GMAC0 distinguish which
mode it runs
3) changes dynamically source clock, TX/RX delay and interface
mode on TRGMII for adapting various link
Changes since v1:
- fixed the style of comment which doesn't have a space at
the beginning and end of comment lines
- add support for phy-mode "trgmii" as PHY_INTERFACE_MODE_TRGMII
into linux/phy.h
- enhance the Documentation about device tree binding for trgmii
which is applicable only for GMAC0 which uses fixed-link
Sean Wang (3):
net: ethernet: mediatek: add extension of phy-mode for TRGMII
net: ethernet: mediatek: add support for GMAC0 connecting with
external PHY through TRGMII
net: ethernet: mediatek: add the dts property to set if TRGMII
supported on GMAC0
.../devicetree/bindings/net/mediatek-net.txt | 5 +++-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 34 +++++++++++++++++++++-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 34 +++++++++++++++++++++-
include/linux/phy.h | 3 ++
4 files changed, 73 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next v2 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII
From: sean.wang @ 2016-09-22 2:33 UTC (permalink / raw)
To: john, davem
Cc: nbd, netdev, linux-kernel, linux-mediatek, andrew, f.fainelli,
keyhaede, objelf, Sean Wang
In-Reply-To: <1474511636-11644-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
adds PHY-mode "trgmii" as an extension for the operation
mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII.
and adds a variable trgmii inside mtk_mac as the indication
to make the difference between the MAC connected to internal
switch or connected to external PHY by the given configuration
on the board and then to perform the corresponding setup on
TRGMII hardware module.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 ++
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 3 +++
include/linux/phy.h | 3 +++
3 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ca6b501..827f4bd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -244,6 +244,8 @@ static int mtk_phy_connect(struct mtk_mac *mac)
return -ENODEV;
switch (of_get_phy_mode(np)) {
+ case PHY_INTERFACE_MODE_TRGMII:
+ mac->trgmii = true;
case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_ID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 7c5e534..e3b9525 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -529,6 +529,8 @@ struct mtk_eth {
* @hw: Backpointer to our main datastruture
* @hw_stats: Packet statistics counter
* @phy_dev: The attached PHY if available
+ * @trgmii Indicate if the MAC uses TRGMII connected to internal
+ switch
*/
struct mtk_mac {
int id;
@@ -539,6 +541,7 @@ struct mtk_mac {
struct phy_device *phy_dev;
__be32 hwlro_ip[MTK_MAX_LRO_IP_CNT];
int hwlro_ip_cnt;
+ bool trgmii;
};
/* the struct describing the SoC. these are declared in the soc_xyz.c files */
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2d24b28..e25f183 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -80,6 +80,7 @@ typedef enum {
PHY_INTERFACE_MODE_XGMII,
PHY_INTERFACE_MODE_MOCA,
PHY_INTERFACE_MODE_QSGMII,
+ PHY_INTERFACE_MODE_TRGMII,
PHY_INTERFACE_MODE_MAX,
} phy_interface_t;
@@ -123,6 +124,8 @@ static inline const char *phy_modes(phy_interface_t interface)
return "moca";
case PHY_INTERFACE_MODE_QSGMII:
return "qsgmii";
+ case PHY_INTERFACE_MODE_TRGMII:
+ return "trgmii";
default:
return "unknown";
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII
From: sean.wang @ 2016-09-22 2:33 UTC (permalink / raw)
To: john, davem
Cc: nbd, netdev, linux-kernel, linux-mediatek, andrew, f.fainelli,
keyhaede, objelf, Sean Wang
In-Reply-To: <1474511636-11644-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Changing dynamically source clock, TX/RX delay and interface mode
used by TRGMII hardware module inside PHY capability polling routine
for adapting to the various speed of RGMII used by external PHY for
GMAC0.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 32 ++++++++++++++++++++++++++++-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 31 +++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 827f4bd..73c7904 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -52,7 +52,7 @@ static const struct mtk_ethtool_stats {
};
static const char * const mtk_clks_source_name[] = {
- "ethif", "esw", "gp1", "gp2"
+ "ethif", "esw", "gp1", "gp2", "trgpll"
};
void mtk_w32(struct mtk_eth *eth, u32 val, unsigned reg)
@@ -135,6 +135,33 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
return _mtk_mdio_read(eth, phy_addr, phy_reg);
}
+static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, int speed)
+{
+ u32 val;
+ int ret;
+
+ val = (speed == SPEED_1000) ?
+ INTF_MODE_RGMII_1000 : INTF_MODE_RGMII_10_100;
+ mtk_w32(eth, val, INTF_MODE);
+
+ regmap_update_bits(eth->ethsys, ETHSYS_CLKCFG0,
+ ETHSYS_TRGMII_CLK_SEL362_5,
+ ETHSYS_TRGMII_CLK_SEL362_5);
+
+ val = (speed == SPEED_1000) ? 250000000 : 500000000;
+ ret = clk_set_rate(eth->clks[MTK_CLK_TRGPLL], val);
+ if (ret)
+ dev_err(eth->dev, "Failed to set trgmii pll: %d\n", ret);
+
+ val = (speed == SPEED_1000) ?
+ RCK_CTRL_RGMII_1000 : RCK_CTRL_RGMII_10_100;
+ mtk_w32(eth, val, TRGMII_RCK_CTRL);
+
+ val = (speed == SPEED_1000) ?
+ TCK_CTRL_RGMII_1000 : TCK_CTRL_RGMII_10_100;
+ mtk_w32(eth, val, TRGMII_TCK_CTRL);
+}
+
static void mtk_phy_link_adjust(struct net_device *dev)
{
struct mtk_mac *mac = netdev_priv(dev);
@@ -157,6 +184,9 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
};
+ if (mac->id == 0 && !mac->trgmii)
+ mtk_gmac0_rgmii_adjust(mac->hw, mac->phy_dev->speed);
+
if (mac->phy_dev->link)
mcr |= MAC_MCR_FORCE_LINK;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index e3b9525..e521156 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -313,6 +313,30 @@
MAC_MCR_FORCE_TX_FC | MAC_MCR_SPEED_1000 | \
MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_LINK)
+/* TRGMII RXC control register */
+#define TRGMII_RCK_CTRL 0x10300
+#define DQSI0(x) ((x << 0) & GENMASK(6, 0))
+#define DQSI1(x) ((x << 8) & GENMASK(14, 8))
+#define RXCTL_DMWTLAT(x) ((x << 16) & GENMASK(18, 16))
+#define RXC_DQSISEL BIT(30)
+#define RCK_CTRL_RGMII_1000 (RXC_DQSISEL | RXCTL_DMWTLAT(2) | DQSI1(16))
+#define RCK_CTRL_RGMII_10_100 RXCTL_DMWTLAT(2)
+
+/* TRGMII RXC control register */
+#define TRGMII_TCK_CTRL 0x10340
+#define TXCTL_DMWTLAT(x) ((x << 16) & GENMASK(18, 16))
+#define TXC_INV BIT(30)
+#define TCK_CTRL_RGMII_1000 TXCTL_DMWTLAT(2)
+#define TCK_CTRL_RGMII_10_100 (TXC_INV | TXCTL_DMWTLAT(2))
+
+/* TRGMII Interface mode register */
+#define INTF_MODE 0x10390
+#define TRGMII_INTF_DIS BIT(0)
+#define TRGMII_MODE BIT(1)
+#define TRGMII_CENTRAL_ALIGNED BIT(2)
+#define INTF_MODE_RGMII_1000 (TRGMII_MODE | TRGMII_CENTRAL_ALIGNED)
+#define INTF_MODE_RGMII_10_100 0
+
/* GPIO port control registers for GMAC 2*/
#define GPIO_OD33_CTRL8 0x4c0
#define GPIO_BIAS_CTRL 0xed0
@@ -323,7 +347,11 @@
#define SYSCFG0_GE_MASK 0x3
#define SYSCFG0_GE_MODE(x, y) (x << (12 + (y * 2)))
-/*ethernet reset control register*/
+/* ethernet subsystem clock register */
+#define ETHSYS_CLKCFG0 0x2c
+#define ETHSYS_TRGMII_CLK_SEL362_5 BIT(11)
+
+/* ethernet reset control register */
#define ETHSYS_RSTCTRL 0x34
#define RSTCTRL_FE BIT(6)
#define RSTCTRL_PPE BIT(31)
@@ -389,6 +417,7 @@ enum mtk_clks_map {
MTK_CLK_ESW,
MTK_CLK_GP1,
MTK_CLK_GP2,
+ MTK_CLK_TRGPLL,
MTK_CLK_MAX
};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0
From: sean.wang-NuS5LvNUpcJWk0Htik3J/w @ 2016-09-22 2:33 UTC (permalink / raw)
To: john-Pj+rj9U5foFAfugRpC6u6w, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: andrew-g2DYL2Zd6BY, nbd-p3rKhJxN3npAfugRpC6u6w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
Sean Wang, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
objelf-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1474511636-11644-1-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add the dts property for the capability if TRGMII supported on GAMC0
Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 6103e55..7111278 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -31,7 +31,10 @@ Optional properties:
Required properties:
- compatible: Should be "mediatek,eth-mac"
- reg: The number of the MAC
-- phy-handle: see ethernet.txt file in the same directory.
+- phy-handle: see ethernet.txt file in the same directory and
+ the phy-mode "trgmii" required being provided when reg
+ is equal to 0 and the MAC uses fixed-link to connect
+ with inernal switch such as MT7530.
Example:
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module
From: Florian Fainelli @ 2016-09-22 3:17 UTC (permalink / raw)
To: sean.wang, john, davem
Cc: nbd, netdev, linux-kernel, linux-mediatek, andrew, keyhaede,
objelf
In-Reply-To: <1474511636-11644-1-git-send-email-sean.wang@mediatek.com>
Le 21/09/2016 à 19:33, sean.wang@mediatek.com a écrit :
> From: Sean Wang <sean.wang@mediatek.com>
>
> By default, GMAC0 is connected to built-in switch called
> MT7530 through the proprietary interface called Turbo RGMII
> (TRGMII). TRGMII also supports well for RGMII as generic external
> PHY uses but requires some slight changes to the setup of TRGMII
> and doesn't have well support on current driver.
>
> So this patchset
> 1) provides the slight changes of the setup for RGMII can work
> through TRGMII
> 2) adds additional setting "trgmii" as PHY_INTERFACE_MODE_TRGMII
> about phy-mode on device tree to make GMAC0 distinguish which
> mode it runs
> 3) changes dynamically source clock, TX/RX delay and interface
> mode on TRGMII for adapting various link
>
> Changes since v1:
> - fixed the style of comment which doesn't have a space at
> the beginning and end of comment lines
> - add support for phy-mode "trgmii" as PHY_INTERFACE_MODE_TRGMII
> into linux/phy.h
> - enhance the Documentation about device tree binding for trgmii
> which is applicable only for GMAC0 which uses fixed-link
Looks good to me:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Sean!
--
Florian
^ permalink raw reply
* [PATCH] net: VRF: Fix receiving multicast traffic
From: Mark Tomlinson @ 2016-09-22 4:13 UTC (permalink / raw)
To: netdev, dsa; +Cc: Mark Tomlinson
The previous patch to ensure that the original iif was used when
checking for forwarding also meant that this same interface was used to
determine whether multicast packets should be received or not. This was
incorrect, and would cause multicast packets to be dropped.
The fix here is to use skb->dev when checking multicast addresses.
skb->dev has been set to the l3mdev by this point, so the check will be
against that, rather than the ingress interface.
Fixes: "net:VRF: Pass original iif to ip_route_input()"
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a1f2830..75e1de6 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1971,7 +1971,7 @@ int ip_route_input_noref(struct sk_buff *skb, __be32 daddr, __be32 saddr,
route cache entry is created eventually.
*/
if (ipv4_is_multicast(daddr)) {
- struct in_device *in_dev = __in_dev_get_rcu(dev);
+ struct in_device *in_dev = __in_dev_get_rcu(skb->dev);
if (in_dev) {
int our = ip_check_mc_rcu(in_dev, daddr, saddr,
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker
From: kbuild test robot @ 2016-09-22 4:34 UTC (permalink / raw)
To: David Howells; +Cc: kbuild-all, netdev, dhowells, linux-afs, linux-kernel
In-Reply-To: <147450476978.14691.9512799255128693593.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "__aeabi_uldivmod" [net/rxrpc/af-rxrpc.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28256 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker
From: kbuild test robot @ 2016-09-22 4:56 UTC (permalink / raw)
To: David Howells; +Cc: kbuild-all, netdev, dhowells, linux-afs, linux-kernel
In-Reply-To: <147450476978.14691.9512799255128693593.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: i386-randconfig-h0-09220655 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/built-in.o: In function `rxrpc_peer_add_rtt':
>> (.text+0x239e99): undefined reference to `__udivdi3'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29865 bytes --]
^ permalink raw reply
* Re: [patch net-next 1/6] fib: introduce FIB notification infrastructure
From: Ido Schimmel @ 2016-09-22 5:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, idosch, eladr, yotamg, nogahf, ogerlitz, roopa,
nikolay, linville, andy, f.fainelli, dsa, jhs, vivien.didelot,
andrew, ivecera, kaber, john
In-Reply-To: <1474458794-5512-2-git-send-email-jiri@resnulli.us>
On Wed, Sep 21, 2016 at 01:53:09PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> This allows to pass information about added/deleted FIB entries/rules to
> whoever is interested. This is done in a very similar way as devinet
> notifies address additions/removals.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
[...]
> #include <linux/slab.h>
> #include <linux/export.h>
> #include <linux/vmalloc.h>
> +#include <linux/notifier.h>
> #include <net/net_namespace.h>
> #include <net/ip.h>
> #include <net/protocol.h>
> @@ -84,6 +85,44 @@
> #include <trace/events/fib.h>
> #include "fib_lookup.h"
>
> +static BLOCKING_NOTIFIER_HEAD(fib_chain);
> +
> +int register_fib_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&fib_chain, nb);
> +}
> +EXPORT_SYMBOL(register_fib_notifier);
If we remove and insert the switch driver, then the existing FIB entries
should be replayed when we register our notification block. Otherwise,
all of these entries will be missing from the switch's tables. I believe
it should be handled like register_netdevice_notifier(), where
"registration and up events are replayed".
^ permalink raw reply
* Re: [patch net-next 2/6] fib: introduce FIB info offload flag helpers
From: Ido Schimmel @ 2016-09-22 5:14 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, idosch, eladr, yotamg, nogahf, ogerlitz, roopa,
nikolay, linville, andy, f.fainelli, dsa, jhs, vivien.didelot,
andrew, ivecera, kaber, john
In-Reply-To: <1474458794-5512-3-git-send-email-jiri@resnulli.us>
On Wed, Sep 21, 2016 at 01:53:10PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> These helpers are to be used in case someone offloads the FIB entry. The
> result is that if the entry is offloaded to at least one device, the
> offload flag is set.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks
^ permalink raw reply
* Re: [PATCH nf v3] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack
From: Eric Dumazet @ 2016-09-22 5:20 UTC (permalink / raw)
To: fgao; +Cc: pablo, kaber, netfilter-devel, netdev, gfree.wind
In-Reply-To: <1474510965-2049-1-git-send-email-fgao@ikuai8.com>
On Thu, 2016-09-22 at 10:22 +0800, fgao@ikuai8.com wrote:
> From: Gao Feng <fgao@ikuai8.com>
>
> It is valid that the TCP RST packet which does not set ack flag, and bytes
> of ack number are zero. But current seqadj codes would adjust the "0" ack
> to invalid ack number. Actually seqadj need to check the ack flag before
> adjust it for these RST packets.
>
> The following is my test case
>
> client is 10.26.98.245, and add one iptable rule:
> iptables -I INPUT -p tcp --sport 12345 -m connbytes --connbytes 2:
> --connbytes-dir reply --connbytes-mode packets -j REJECT --reject-with
> tcp-reset
> This iptables rule could generate on TCP RST without ack flag.
>
> server:10.172.135.55
> Enable the synproxy with seqadjust by the following iptables rules
> iptables -t raw -A PREROUTING -i eth0 -p tcp -d 10.172.135.55 --dport 12345
> -m tcp --syn -j CT --notrack
>
> iptables -A INPUT -i eth0 -p tcp -d 10.172.135.55 --dport 12345 -m conntrack
> --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7
> --mss 1460
> iptables -A OUTPUT -o eth0 -p tcp -s 10.172.135.55 --sport 12345 -m conntrack
> --ctstate INVALID,UNTRACKED -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -j ACCEPT
>
> The following is my test result.
>
> 1. packet trace on client
> root@routers:/tmp# tcpdump -i eth0 tcp port 12345 -n
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [S], seq 3695959829,
> win 29200, options [mss 1460,sackOK,TS val 452367884 ecr 0,nop,wscale 7],
> length 0
> IP 10.172.135.55.12345 > 10.26.98.245.45154: Flags [S.], seq 546723266,
> ack 3695959830, win 0, options [mss 1460,sackOK,TS val 15643479 ecr 452367884,
> nop,wscale 7], length 0
> IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [.], ack 1, win 229,
> options [nop,nop,TS val 452367885 ecr 15643479], length 0
> IP 10.172.135.55.12345 > 10.26.98.245.45154: Flags [.], ack 1, win 226,
> options [nop,nop,TS val 15643479 ecr 452367885], length 0
> IP 10.26.98.245.45154 > 10.172.135.55.12345: Flags [R], seq 3695959830,
> win 0, length 0
>
> 2. seqadj log on server
> [62873.867319] Adjusting sequence number from 602341895->546723267,
> ack from 3695959830->3695959830
> [62873.867644] Adjusting sequence number from 602341895->546723267,
> ack from 3695959830->3695959830
> [62873.869040] Adjusting sequence number from 3695959830->3695959830,
> ack from 0->55618628
>
> To summarize, it is clear that the seqadj codes adjust the 0 ack when receive
> one TCP RST packet without ack.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
> ---
> v3: Add the reproduce steps and packet trace
> v2: Regenerate because the first patch is removed
> v1: Initial patch
>
> net/netfilter/nf_conntrack_seqadj.c | 34 +++++++++++++++++++---------------
> 1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c
> index dff0f0c..3bd9c7e 100644
> --- a/net/netfilter/nf_conntrack_seqadj.c
> +++ b/net/netfilter/nf_conntrack_seqadj.c
> @@ -179,30 +179,34 @@ int nf_ct_seq_adjust(struct sk_buff *skb,
>
> tcph = (void *)skb->data + protoff;
> spin_lock_bh(&ct->lock);
> +
Please do not add style change during a bug fix.
> if (after(ntohl(tcph->seq), this_way->correction_pos))
> seqoff = this_way->offset_after;
> else
> seqoff = this_way->offset_before;
>
> - if (after(ntohl(tcph->ack_seq) - other_way->offset_before,
> - other_way->correction_pos))
> - ackoff = other_way->offset_after;
> - else
> - ackoff = other_way->offset_before;
> -
> newseq = htonl(ntohl(tcph->seq) + seqoff);
> - newack = htonl(ntohl(tcph->ack_seq) - ackoff);
> -
> inet_proto_csum_replace4(&tcph->check, skb, tcph->seq, newseq, false);
> - inet_proto_csum_replace4(&tcph->check, skb, tcph->ack_seq, newack,
> - false);
> -
> - pr_debug("Adjusting sequence number from %u->%u, ack from %u->%u\n",
> - ntohl(tcph->seq), ntohl(newseq), ntohl(tcph->ack_seq),
> - ntohl(newack));
>
> + pr_debug("Adjusting sequence number from %u->%u\n",
> + ntohl(tcph->seq), ntohl(newseq));
> tcph->seq = newseq;
> - tcph->ack_seq = newack;
> +
> + if (likely(tcph->ack)) {
> + if (after(ntohl(tcph->ack_seq) - other_way->offset_before,
> + other_way->correction_pos))
> + ackoff = other_way->offset_after;
> + else
> + ackoff = other_way->offset_before;
> +
> + newack = htonl(ntohl(tcph->ack_seq) - ackoff);
> + inet_proto_csum_replace4(&tcph->check, skb, tcph->ack_seq,
> + newack, false);
> +
> + pr_debug("Adjusting ack number from %u->%u\n",
> + ntohl(tcph->ack_seq), ntohl(newack));
> + tcph->ack_seq = newack;
> + }
>
If tcph->ack is not set, why are we calling nf_ct_sack_adjust() ?
> res = nf_ct_sack_adjust(skb, protoff, tcph, ct, ctinfo);
> spin_unlock_bh(&ct->lock);
^ permalink raw reply
* Re: [PATCH net-next 9/9] rxrpc: Reduce the number of ACK-Requests sent
From: kbuild test robot @ 2016-09-22 5:24 UTC (permalink / raw)
To: David Howells; +Cc: kbuild-all, netdev, dhowells, linux-afs, linux-kernel
In-Reply-To: <147450481095.14691.12793864306697245558.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
Hi David,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "__aeabi_ldivmod" [net/rxrpc/af-rxrpc.ko] undefined!
ERROR: "__aeabi_uldivmod" [net/rxrpc/af-rxrpc.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28256 bytes --]
^ permalink raw reply
* Re: [PATCH] net: explicitly whitelist sysctls for unpriv namespaces
From: David Miller @ 2016-09-22 5:30 UTC (permalink / raw)
To: jann; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1474232300-8423-1-git-send-email-jann@thejh.net>
From: Jann Horn <jann@thejh.net>
Date: Sun, 18 Sep 2016 22:58:20 +0200
> There were two net sysctls that could be written from unprivileged net
> namespaces, but weren't actually namespaced.
>
> To fix the existing issues and prevent stuff this from happening again in
> the future, explicitly whitelist permitted sysctls.
>
> Note: The current whitelist is "allow everything that was previously
> accessible and that doesn't obviously modify global state".
>
> On my system, this patch just removes the write permissions for
> ipv4/netfilter/ip_conntrack_max, which would have been usable for a local
> DoS. With a different config, the ipv4/vs/debug_level sysctl would also be
> affected.
>
> Maximum impact of this seems to be local DoS, and it's a fairly large
> commit, so I'm sending this publicly directly.
>
> An alternative (and much smaller) fix would be to just change the
> permissions of the two files in question to be 0444 in non-privileged
> namespaces, but I believe that this solution is slightly less error-prone.
> If you think I should switch to the simple fix, let me know.
>
> Signed-off-by: Jann Horn <jann@thejh.net>
I think this is fine for net-next and will apply it there.
But for 'net' and 'stable', please also submit the simpler fix.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: explicitly whitelist sysctls for unpriv namespaces
From: David Miller @ 2016-09-22 5:31 UTC (permalink / raw)
To: jann; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1474232300-8423-1-git-send-email-jann@thejh.net>
From: Jann Horn <jann@thejh.net>
Date: Sun, 18 Sep 2016 22:58:20 +0200
> There were two net sysctls that could be written from unprivileged net
> namespaces, but weren't actually namespaced.
>
> To fix the existing issues and prevent stuff this from happening again in
> the future, explicitly whitelist permitted sysctls.
>
> Note: The current whitelist is "allow everything that was previously
> accessible and that doesn't obviously modify global state".
>
> On my system, this patch just removes the write permissions for
> ipv4/netfilter/ip_conntrack_max, which would have been usable for a local
> DoS. With a different config, the ipv4/vs/debug_level sysctl would also be
> affected.
>
> Maximum impact of this seems to be local DoS, and it's a fairly large
> commit, so I'm sending this publicly directly.
>
> An alternative (and much smaller) fix would be to just change the
> permissions of the two files in question to be 0444 in non-privileged
> namespaces, but I believe that this solution is slightly less error-prone.
> If you think I should switch to the simple fix, let me know.
>
> Signed-off-by: Jann Horn <jann@thejh.net>
And actually this patch dosn't apply cleanly to net-next, please
respin.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] act_vlan: Introduce TCA_VLAN_ACT_MODIFY vlan action
From: David Miller @ 2016-09-22 5:34 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: jiri, jhs, netdev
In-Reply-To: <1474301470-17965-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Mon, 19 Sep 2016 19:11:08 +0300
> TCA_VLAN_ACT_MODIFY allows one to change an existing tag.
>
> It accepts same attributes as TCA_VLAN_ACT_PUSH (protocol, id,
> priority).
> If packet is vlan tagged, then the tag gets overwritten according to
> user specified attributes.
>
> For example, this allows user to replace a tag's vid while preserving
> its priority bits (as opposed to "action vlan pop pipe action vlan push").
Series applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/2] net: skbuff: Remove errornous length validation in skb_vlan_pop()
From: David Miller @ 2016-09-22 5:36 UTC (permalink / raw)
To: shmulik.ladkani
Cc: jiri, daniel, pshelar, eric.dumazet, netdev, shmulik.ladkani
In-Reply-To: <1474364917-31710-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Date: Tue, 20 Sep 2016 12:48:36 +0300
> In 93515d53b1
> "net: move vlan pop/push functions into common code"
> skb_vlan_pop was moved from its private location in openvswitch to
> skbuff common code.
>
> In case skb has non hw-accel vlan tag, the original 'pop_vlan()' assured
> that skb->len is sufficient (if skb->len < VLAN_ETH_HLEN then pop was
> considered a no-op).
>
> This validation was moved as is into the new common 'skb_vlan_pop'.
>
> Alas, in its original location (openvswitch), there was a guarantee that
> 'data' points to the mac_header, therefore the 'skb->len < VLAN_ETH_HLEN'
> condition made sense.
> However there's no such guarantee in the generic 'skb_vlan_pop'.
>
> For short packets received in rx path going through 'skb_vlan_pop',
> this causes 'skb_vlan_pop' to fail pop-ing a valid vlan hdr (in the non
> hw-accel case) or to fail moving next tag into hw-accel tag.
>
> Remove the 'skb->len < VLAN_ETH_HLEN' condition entirely:
> It is superfluous since inner '__skb_vlan_pop' already verifies there
> are VLAN_ETH_HLEN writable bytes at the mac_header.
>
> Note this presents a slight change to skb_vlan_pop() users:
> In case total length is smaller than VLAN_ETH_HLEN, skb_vlan_pop() now
> returns an error, as opposed to previous "no-op" behavior.
> Existing callers (e.g. tc act vlan, ovs) usually drop the packet if
> 'skb_vlan_pop' fails.
>
> Fixes: 93515d53b1 ("net: move vlan pop/push functions into common code")
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: skbuff: Coding: Use eth_type_vlan() instead of open coding it
From: David Miller @ 2016-09-22 5:36 UTC (permalink / raw)
To: shmulik.ladkani
Cc: jiri, daniel, pshelar, eric.dumazet, netdev, shmulik.ladkani
In-Reply-To: <1474364917-31710-2-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Date: Tue, 20 Sep 2016 12:48:37 +0300
> Fix 'skb_vlan_pop' to use eth_type_vlan instead of directly comparing
> skb->protocol to ETH_P_8021Q or ETH_P_8021AD.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show
From: hejianet @ 2016-09-22 5:38 UTC (permalink / raw)
To: Marcelo
Cc: netdev, linux-sctp, linux-kernel, davem, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich,
Neil Horman, Steffen Klassert, Herbert Xu
In-Reply-To: <20160921182438.GG9323@localhost.localdomain>
On 9/22/16 2:24 AM, Marcelo wrote:
> On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote:
>> Hi Marcelo
>>
>> sorry for the late, just came back from a vacation.
> Hi, no problem. Hope your batteries are recharged now :-)
>
>> On 9/14/16 7:55 PM, Marcelo wrote:
>>> Hi Jia,
>>>
>>> On Wed, Sep 14, 2016 at 01:58:42PM +0800, hejianet wrote:
>>>> Hi Marcelo
>>>>
>>>>
>>>> On 9/13/16 2:57 AM, Marcelo wrote:
>>>>> On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
>>>>>> This is to use the generic interface snmp_get_cpu_field{,64}_batch to
>>>>>> aggregate the data by going through all the items of each cpu sequentially.
>>>>>> Then snmp_seq_show and netstat_seq_show are split into 2 parts to avoid build
>>>>>> warning "the frame size" larger than 1024 on s390.
>>>>> Yeah about that, did you test it with stack overflow detection?
>>>>> These arrays can be quite large.
>>>>>
>>>>> One more below..
>>>> Do you think it is acceptable if the stack usage is a little larger than 1024?
>>>> e.g. 1120
>>>> I can't find any other way to reduce the stack usage except use "static" before
>>>> unsigned long buff[TCP_MIB_MAX]
>>>>
>>>> PS. sizeof buff is about TCP_MIB_MAX(116)*8=928
>>>> B.R.
>>> That's pretty much the question. Linux has the option on some archs to
>>> run with 4Kb (4KSTACKS option), so this function alone would be using
>>> 25% of it in this last case. While on x86_64, it uses 16Kb (6538b8ea886e
>>> ("x86_64: expand kernel stack to 16K")).
>>>
>>> Adding static to it is not an option as it actually makes the variable
>>> shared amongst the CPUs (and then you have concurrency issues), plus the
>>> fact that it's always allocated, even while not in use.
>>>
>>> Others here certainly know better than me if it's okay to make such
>>> usage of the stach.
>> What about this patch instead?
>> It is a trade-off. I split the aggregation process into 2 parts, it will
>> increase the cache miss a little bit, but it can reduce the stack usage.
>> After this, stack usage is 672bytes
>> objdump -d vmlinux | ./scripts/checkstack.pl ppc64 | grep seq_show
>> 0xc0000000007f7cc0 netstat_seq_show_tcpext.isra.3 [vmlinux]:672
>>
>> diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
>> index c6ee8a2..cc41590 100644
>> --- a/net/ipv4/proc.c
>> +++ b/net/ipv4/proc.c
>> @@ -486,22 +486,37 @@ static const struct file_operations snmp_seq_fops = {
>> */
>> static int netstat_seq_show_tcpext(struct seq_file *seq, void *v)
>> {
>> - int i;
>> - unsigned long buff[LINUX_MIB_MAX];
>> + int i, c;
>> + unsigned long buff[LINUX_MIB_MAX/2 + 1];
>> struct net *net = seq->private;
>>
>> - memset(buff, 0, sizeof(unsigned long) * LINUX_MIB_MAX);
>> + memset(buff, 0, sizeof(unsigned long) * (LINUX_MIB_MAX/2 + 1));
>>
>> seq_puts(seq, "TcpExt:");
>> for (i = 0; snmp4_net_list[i].name; i++)
>> seq_printf(seq, " %s", snmp4_net_list[i].name);
>>
>> seq_puts(seq, "\nTcpExt:");
>> - snmp_get_cpu_field_batch(buff, snmp4_net_list,
>> - net->mib.net_statistics);
>> - for (i = 0; snmp4_net_list[i].name; i++)
>> + for_each_possible_cpu(c) {
>> + for (i = 0; i < LINUX_MIB_MAX/2; i++)
>> + buff[i] += snmp_get_cpu_field(
>> + net->mib.net_statistics,
>> + c, snmp4_net_list[i].entry);
>> + }
>> + for (i = 0; i < LINUX_MIB_MAX/2; i++)
>> seq_printf(seq, " %lu", buff[i]);
>>
>> + memset(buff, 0, sizeof(unsigned long) * (LINUX_MIB_MAX/2 + 1));
>> + for_each_possible_cpu(c) {
>> + for (i = LINUX_MIB_MAX/2; snmp4_net_list[i].name; i++)
>> + buff[i - LINUX_MIB_MAX/2] += snmp_get_cpu_field(
>> + net->mib.net_statistics,
>> + c,
>> + snmp4_net_list[i].entry);
>> + }
>> + for (i = LINUX_MIB_MAX/2; snmp4_net_list[i].name; i++)
>> + seq_printf(seq, " %lu", buff[i - LINUX_MIB_MAX/2]);
>> +
>> return 0;
>> }
> Yep, it halves the stack usage, but it doesn't look good heh
>
> But well, you may try to post the patchset (with or without this last
> change, you pick) officially and see how it goes. As you're posting as
> RFC, it's not being evaluated as seriously.
Thanks for the suggestion, I will remove it in future patch version
>
> FWIW, I tested your patches, using your test and /proc/net/snmp file on
> a x86_64 box, Intel(R) Xeon(R) CPU E5-2643 v3.
>
> Before the patches:
>
> Performance counter stats for './test /proc/net/snmp':
>
> 5.225 cache-misses
> 12.708.673.785 L1-dcache-loads
> 1.288.450.174 L1-dcache-load-misses # 10,14% of all L1-dcache hits
> 1.271.857.028 LLC-loads
> 4.122 LLC-load-misses # 0,00% of all LL-cache hits
>
> 9,174936524 seconds time elapsed
>
> After:
>
> Performance counter stats for './test /proc/net/snmp':
>
> 2.865 cache-misses
> 30.203.883.807 L1-dcache-loads
> 1.215.774.643 L1-dcache-load-misses # 4,03% of all L1-dcache hits
> 1.181.662.831 LLC-loads
> 2.685 LLC-load-misses # 0,00% of all LL-cache hits
>
> 13,374445056 seconds time elapsed
>
> Numbers were steady across multiple runs.
>
> Marcelo
Yes, I guess your X86 machine doesn't have the large cpu number as mine (cpu#=160).
The cache misses rate difference btw before and after this patch will be more
significant if the cpu number is large.
B.R.
Jia
>
>>>>>> +static int netstat_seq_show_ipext(struct seq_file *seq, void *v)
>>>>>> +{
>>>>>> + int i;
>>>>>> + u64 buff64[IPSTATS_MIB_MAX];
>>>>>> + struct net *net = seq->private;
>>>>>> seq_puts(seq, "\nIpExt:");
>>>>>> for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
>>>>>> seq_printf(seq, " %s", snmp4_ipextstats_list[i].name);
>>>>>> seq_puts(seq, "\nIpExt:");
>>>>> You're missing a memset() call here.
>>> Not sure if you missed this one or not..
>> indeed, thanks
>> B.R.
>> Jia
>>> Thanks,
>>> Marcelo
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] cxgb4: add support for offloading TC u32 filters
From: David Miller @ 2016-09-22 5:40 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, hariprasad, leedom, nirranjan, indranil
In-Reply-To: <cover.1474029677.git.rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Tue, 20 Sep 2016 17:13:05 +0530
> This series of patches add support to offload TC u32 filters onto
> Chelsio NICs.
>
> Patch 1 moves current common filter code to separate files
> in order to provide a common api for performing packet classification
> and filtering in Chelsio NICs.
>
> Patch 2 enables filters for normal NIC configuration and implements
> common api for setting and deleting filters.
>
> Patches 3-5 add support for TC u32 offload via ndo_setup_tc.
Series applied.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_core: Fix to clean devlink resources
From: David Miller @ 2016-09-22 5:41 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, kamalh
In-Reply-To: <1474372531-27120-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 20 Sep 2016 14:55:31 +0300
> From: Kamal Heib <kamalh@mellanox.com>
>
> This patch cleans devlink resources by calling devlink_port_unregister()
> to avoid the following issues:
>
> - Kernel panic when triggering reset flow.
> - Memory leak due to unfreed resources in mlx4_init_port_info().
>
> Fixes: 09d4d087cd48 ("mlx4: Implement devlink interface")
> Signed-off-by: Kamal Heib <kamalh@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> Please push it to -stable >= 4.6 as well. Thanks.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] cxgb4: fix signed wrap around when decrementing index idx
From: David Miller @ 2016-09-22 5:49 UTC (permalink / raw)
To: colin.king; +Cc: hariprasad, netdev, linux-kernel
In-Reply-To: <20160920144846.21765-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 20 Sep 2016 15:48:45 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Change predecrement compare to post decrement compare to avoid an
> unsigned integer wrap-around comparison when decrementing idx in
> the while loop.
>
> For example, when idx is zero, the current situation will
> predecrement idx in the while loop, wrapping idx to the maximum
> signed integer and cause out of bounds reads on rxq_info->msix_tbl[idx].
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
This doesn't apply cleanly to the 'net' tree, please respin.
^ permalink raw reply
* Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()
From: David Miller @ 2016-09-22 5:52 UTC (permalink / raw)
To: jbenc; +Cc: sowmini.varadhan, netdev, hannes, aduyck, daniel, pabeni
In-Reply-To: <20160920190929.57ddaeb0@griffin>
From: Jiri Benc <jbenc@redhat.com>
Date: Tue, 20 Sep 2016 19:09:29 +0200
> But the point stands, we have much greater problems here than VXLAN.
> And I don't think that wrapping all IP address accesses into
> get/put_unaligned all around the stack is the solution.
Right, and I don't like marking things as packed either.
We need something that really solves the problem. We can't
change the existing protocols, but we can perhaps change the
geometry of the SKB when we deal with such protocols.
For example, we can memmove() to align the headers at skb->data and
then for the skb->data portion past the headers we insert a frag
pointing to it at the front of the frag list.
So we "memmove" down, creating a gap, and then past the gap
is the post-header area which gets inserted into the head of
the SKB's fraglist.
That will align all of the subsequent headers and avoid the
unaligned accesses after the vxlan header.
Alternatively we can do Alexander Duyck's trick, by pushing
the headers into the frag list, forcing a pull and realignment
by the next protocol layer.
This is so much better than the little hacks sprinkled all
over the problem and tackles the fundamental issue.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: mediatek: fix missing changes merged for conflicts overlapping commits
From: David Miller @ 2016-09-22 6:05 UTC (permalink / raw)
To: sean.wang; +Cc: john, nbd, netdev, linux-mediatek, keyhaede, objelf
In-Reply-To: <1474386804-11728-1-git-send-email-sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Tue, 20 Sep 2016 23:53:24 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> add the missing commits about
> 1)
> Commit d3bd1ce4db8e843dce421e2f8f123e5251a9c7d3
> ("remove redundant free_irq for devm_request_ir allocated irq")
> 2)
> Commit 7c6b0d76fa02213393815e3b6d5e4a415bf3f0e2
> ("fix logic unbalance between probe and remove")
>
> during merge for conflicts overlapping commits by
> Commit b20b378d49926b82c0a131492fa8842156e0e8a9
> ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Applied, thanks for fixing this up for me.
^ permalink raw reply
* Re: [PATCH] net: fec: set mac address unconditionally
From: Uwe Kleine-König @ 2016-09-22 6:08 UTC (permalink / raw)
To: Gavin Schenk; +Cc: fugang.duan, netdev, kernel
In-Reply-To: <1474464655-126940-1-git-send-email-g.schenk@eckelmann.de>
Hello,
just a few nitpicks:
On Wed, Sep 21, 2016 at 03:30:55PM +0200, Gavin Schenk wrote:
> Fixes: 9638d19e4816 ("net: fec: add netif status check before set mac address")
This line belongs to in the S-o-B area below.
> If the mac address origin is not dt, you can only safe assign a
s/safe/safely/
> mac address after "link up" of the device. If the link is down the
> clocks are disabled and because of issues assigning registers when
> clocks are down the new mac address is discarded on some soc's. This fix
s/down/off/; s/is discarded/cannot be written in .ndo_set_mac_address()/
> sets the mac address unconditionally in fec_restart(...) and ensures
> consistens between fec registers and the network layer.
s/consistens/consistency/
Other than that:
Acked-by: Uwe Kleine-König <u.kleine-koenig@eckelmann.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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