* Re: [PATCH net-next v1] net: gso: Add GSO support for NSH (Network Service Header)
From: Jiri Benc @ 2017-08-24 14:13 UTC (permalink / raw)
To: Yi Yang; +Cc: netdev, simon.horman
In-Reply-To: <1503567376-64933-1-git-send-email-yi.y.yang@intel.com>
On Thu, 24 Aug 2017 17:36:16 +0800, Yi Yang wrote:
> include/net/nsh.h | 307 ++++++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/if_ether.h | 1 +
> net/Kconfig | 1 +
> net/Makefile | 1 +
> net/nsh/Kconfig | 10 ++
> net/nsh/Makefile | 4 +
> net/nsh/nsh_gso.c | 116 ++++++++++++++++
Please consider making this a patchset, with a patch adding the NSH
structures and helper functions, a patch adding GSO and a patch adding
OVS support. That way, everything can be reviewed together, yet the
patches are reasonably contained.
> +config NET_NSH_GSO
> + bool "NSH GSO support"
> + depends on INET
> + default y
> + ---help---
> + This allows segmentation of GSO packet that have had NSH header pushed onto them and thus become NSH GSO packets.
Seems you're missing a newline here.
> +static struct sk_buff *nsh_gso_segment(struct sk_buff *skb,
> + netdev_features_t features)
> +{
> + struct sk_buff *segs = ERR_PTR(-EINVAL);
> + __be16 protocol = skb->protocol;
> + __be16 inner_proto;
> + u16 mac_offset = skb->mac_header;
> + u16 mac_len = skb->mac_len;
> + struct nsh_hdr *nsh;
> + unsigned int nsh_hlen;
> + const struct net_offload *ops;
> + struct sk_buff *(*gso_inner_segment)(struct sk_buff *skb,
> + netdev_features_t features);
> +
> + skb_reset_network_header(skb);
> + nsh = (struct nsh_hdr *)skb_network_header(skb);
> + nsh_hlen = nsh_hdr_len(nsh);
> + if (unlikely(!pskb_may_pull(skb, nsh_hlen)))
> + goto out;
You have to reload nsh after this.
> +
> + __skb_pull(skb, nsh_hlen);
> +
> + skb_reset_mac_header(skb);
> + skb_reset_mac_len(skb);
> +
> + rcu_read_lock();
> + switch (nsh->next_proto) {
> + case NSH_P_ETHERNET:
> + inner_proto = htons(ETH_P_TEB);
> + gso_inner_segment = skb_mac_gso_segment;
> + break;
> + case NSH_P_IPV4:
> + inner_proto = htons(ETH_P_IP);
> + ops = rcu_dereference(inet_offloads[inner_proto]);
> + if (!ops || !ops->callbacks.gso_segment)
> + goto out;
> + gso_inner_segment = ops->callbacks.gso_segment;
> + break;
> + case NSH_P_IPV6:
> + inner_proto = htons(ETH_P_IPV6);
> + ops = rcu_dereference(inet6_offloads[inner_proto]);
> + if (!ops || !ops->callbacks.gso_segment)
> + goto out;
> + gso_inner_segment = ops->callbacks.gso_segment;
> + break;
> + case NSH_P_NSH:
> + inner_proto = htons(ETH_P_NSH);
> + gso_inner_segment = nsh_gso_segment;
This doesn't look correct. Recursive call to nsh_gso_segment will reset
mac header, causing skb_segment not to copy the previous NSH header(s)
to the new segments.
> + break;
> + default:
> + skb_gso_error_unwind(skb, protocol, nsh_hlen, mac_offset,
> + mac_len);
> + goto out;
> + }
> +
> + skb->protocol = inner_proto;
> + segs = gso_inner_segment(skb, features);
> + if (IS_ERR_OR_NULL(segs)) {
> + skb_gso_error_unwind(skb, protocol, nsh_hlen, mac_offset,
> + mac_len);
> + goto out;
> + }
> +
> + do {
> + skb->mac_len = mac_len;
> + skb->protocol = protocol;
> +
> + skb_reset_inner_network_header(skb);
This looks superfluous.
> +
> + __skb_push(skb, nsh_hlen);
> +
> + skb_reset_mac_header(skb);
> + skb_set_network_header(skb, mac_len);
> + } while ((skb = skb->next));
> +
> +out:
> + rcu_read_unlock();
> + return segs;
> +}
> +
> +static struct packet_offload nsh_offload __read_mostly = {
> + .type = cpu_to_be16(ETH_P_NSH),
> + .priority = 15,
> + .callbacks = {
> + .gso_segment = nsh_gso_segment,
> + },
> +};
> +
> +static int __init nsh_gso_init(void)
> +{
> + dev_add_offload(&nsh_offload);
> +
> + return 0;
> +}
> +
> +fs_initcall(nsh_gso_init);
device_initcall should be enough. I doubt we'll be doing NFS over
NSH ;-)
Jiri
^ permalink raw reply
* Re: [PATCH net-next 07/13] net: mvpp2: improve the link management function
From: Antoine Tenart @ 2017-08-24 14:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824140625.GH8022@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
Hi Andrew,
On Thu, Aug 24, 2017 at 04:06:25PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:17AM +0200, Antoine Tenart wrote:
> > @@ -5753,14 +5753,24 @@ static void mvpp2_link_event(struct net_device *dev)
> > port->link = phydev->link;
> >
> > if (phydev->link) {
> > + mvpp2_interrupts_enable(port);
> > + mvpp2_port_enable(port);
> > +
> > mvpp2_egress_enable(port);
> > mvpp2_ingress_enable(port);
> > + netif_carrier_on(dev);
>
> Have you seen cases where it is required to change the carrier state?
> The phy state machine should be doing this. e.g. when autoneg has
> completed, force link configuration, the link goes down etc.
I don't think I saw a case where this was needed. And if phylib already
handle this I think it should be removed from here as the
mvpp2_link_event only is called by phylib.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net v1 0/3] tipc: buffer reassignment fixes
From: Parthasarathy Bhuvaragan @ 2017-08-24 14:31 UTC (permalink / raw)
To: davem; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
This series contains fixes for buffer reassignments and a context imbalance.
Parthasarathy Bhuvaragan (3):
tipc: perform skb_linearize() before parsing the inner header
tipc: reassign pointers after skb reallocation / linearization
tipc: context imbalance at node read unlock
net/tipc/msg.c | 7 +++++--
net/tipc/node.c | 4 +++-
2 files changed, 8 insertions(+), 3 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH net v1 1/3] tipc: perform skb_linearize() before parsing the inner header
From: Parthasarathy Bhuvaragan @ 2017-08-24 14:31 UTC (permalink / raw)
To: davem; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1503585084-14079-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
In tipc_rcv(), we linearize only the header and usually the packets
are consumed as the nodes permit direct reception. However, if the
skb contains tunnelled message due to fail over or synchronization
we parse it in tipc_node_check_state() without performing
linearization. This will cause link disturbances if the skb was
non linear.
In this commit, we perform linearization for the above messages.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/node.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 9b4dcb6a16b5..b113a52f8914 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1557,6 +1557,8 @@ void tipc_rcv(struct net *net, struct sk_buff *skb, struct tipc_bearer *b)
/* Check/update node state before receiving */
if (unlikely(skb)) {
+ if (unlikely(skb_linearize(skb)))
+ goto discard;
tipc_node_write_lock(n);
if (tipc_node_check_state(n, skb, bearer_id, &xmitq)) {
if (le->link) {
--
2.1.4
^ permalink raw reply related
* [PATCH net v1 2/3] tipc: reassign pointers after skb reallocation / linearization
From: Parthasarathy Bhuvaragan @ 2017-08-24 14:31 UTC (permalink / raw)
To: davem; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1503585084-14079-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
In tipc_msg_reverse(), we assign skb attributes to local pointers
in stack at startup. This is followed by skb_linearize() and for
cloned buffers we perform skb relocation using pskb_expand_head().
Both these methods may update the skb attributes and thus making
the pointers incorrect.
In this commit, we fix this error by ensuring that the pointers
are re-assigned after any of these skb operations.
Fixes: 29042e19f2c60 ("tipc: let function tipc_msg_reverse() expand header
when needed")
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/msg.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index dcd90e6fa7c3..6ef379f004ac 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -479,13 +479,14 @@ bool tipc_msg_make_bundle(struct sk_buff **skb, struct tipc_msg *msg,
bool tipc_msg_reverse(u32 own_node, struct sk_buff **skb, int err)
{
struct sk_buff *_skb = *skb;
- struct tipc_msg *hdr = buf_msg(_skb);
+ struct tipc_msg *hdr;
struct tipc_msg ohdr;
- int dlen = min_t(uint, msg_data_sz(hdr), MAX_FORWARD_SIZE);
+ int dlen;
if (skb_linearize(_skb))
goto exit;
hdr = buf_msg(_skb);
+ dlen = min_t(uint, msg_data_sz(hdr), MAX_FORWARD_SIZE);
if (msg_dest_droppable(hdr))
goto exit;
if (msg_errcode(hdr))
@@ -511,6 +512,8 @@ bool tipc_msg_reverse(u32 own_node, struct sk_buff **skb, int err)
pskb_expand_head(_skb, BUF_HEADROOM, BUF_TAILROOM, GFP_ATOMIC))
goto exit;
+ /* reassign after skb header modifications */
+ hdr = buf_msg(_skb);
/* Now reverse the concerned fields */
msg_set_errcode(hdr, err);
msg_set_non_seq(hdr, 0);
--
2.1.4
^ permalink raw reply related
* [PATCH net v1 3/3] tipc: context imbalance at node read unlock
From: Parthasarathy Bhuvaragan @ 2017-08-24 14:31 UTC (permalink / raw)
To: davem; +Cc: netdev, tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1503585084-14079-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
If we fail to find a valid bearer in tipc_node_get_linkname(),
node_read_unlock() is called without holding the node read lock.
This commit fixes this error.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
net/tipc/node.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/node.c b/net/tipc/node.c
index b113a52f8914..7dd22330a6b4 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1126,8 +1126,8 @@ int tipc_node_get_linkname(struct net *net, u32 bearer_id, u32 addr,
strncpy(linkname, tipc_link_name(link), len);
err = 0;
}
-exit:
tipc_node_read_unlock(node);
+exit:
tipc_node_put(node);
return err;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/5] netfilter: ipt_CLUSTERIP: fix use-after-free of proc entry
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
From: Sabrina Dubroca <sd@queasysnail.net>
When we delete a netns with a CLUSTERIP rule, clusterip_net_exit() is
called first, removing /proc/net/ipt_CLUSTERIP.
Then clusterip_config_entry_put() is called from clusterip_tg_destroy(),
and tries to remove its entry under /proc/net/ipt_CLUSTERIP/.
Fix this by checking that the parent directory of the entry to remove
hasn't already been deleted.
The following triggers a KASAN splat (stealing the reproducer from
202f59afd441, thanks to Jianlin Shi and Xin Long):
ip netns add test
ip link add veth0_in type veth peer name veth0_out
ip link set veth0_in netns test
ip netns exec test ip link set lo up
ip netns exec test ip link set veth0_in up
ip netns exec test iptables -I INPUT -d 1.2.3.4 -i veth0_in -j \
CLUSTERIP --new --clustermac 89:d4:47:eb:9a:fa --total-nodes 3 \
--local-node 1 --hashmode sourceip-sourceport
ip netns del test
Fixes: ce4ff76c15a8 ("netfilter: ipt_CLUSTERIP: make proc directory per net namespace")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 7d72decb80f9..efaa04dcc80e 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -117,7 +117,8 @@ clusterip_config_entry_put(struct net *net, struct clusterip_config *c)
* functions are also incrementing the refcount on their own,
* so it's safe to remove the entry even if it's in use. */
#ifdef CONFIG_PROC_FS
- proc_remove(c->pde);
+ if (cn->procdir)
+ proc_remove(c->pde);
#endif
return;
}
@@ -815,6 +816,7 @@ static void clusterip_net_exit(struct net *net)
#ifdef CONFIG_PROC_FS
struct clusterip_net *cn = net_generic(net, clusterip_net_id);
proc_remove(cn->procdir);
+ cn->procdir = NULL;
#endif
nf_unregister_net_hook(net, &cip_arp_ops);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] netfilter: nft_compat: check extension hook mask only if set
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
If the x_tables extension comes with no hook mask, skip this validation.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_compat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c
index f5a7cb68694e..b89f4f65b2a0 100644
--- a/net/netfilter/nft_compat.c
+++ b/net/netfilter/nft_compat.c
@@ -305,7 +305,7 @@ static int nft_target_validate(const struct nft_ctx *ctx,
const struct nf_hook_ops *ops = &basechain->ops[0];
hook_mask = 1 << ops->hooknum;
- if (!(hook_mask & target->hooks))
+ if (target->hooks && !(hook_mask & target->hooks))
return -EINVAL;
ret = nft_compat_chain_validate_dependency(target->table,
@@ -484,7 +484,7 @@ static int nft_match_validate(const struct nft_ctx *ctx,
const struct nf_hook_ops *ops = &basechain->ops[0];
hook_mask = 1 << ops->hooknum;
- if (!(hook_mask & match->hooks))
+ if (match->hooks && !(hook_mask & match->hooks))
return -EINVAL;
ret = nft_compat_chain_validate_dependency(match->table,
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] netfilter: x_tables: Fix use-after-free in ipt_do_table.
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
From: Taehee Yoo <ap420073@gmail.com>
If verdict is NF_STOLEN in the SYNPROXY target,
the skb is consumed.
However, ipt_do_table() always tries to get ip header from the skb.
So that, KASAN triggers the use-after-free message.
We can reproduce this message using below command.
# iptables -I INPUT -p tcp -j SYNPROXY --mss 1460
[ 193.542265] BUG: KASAN: use-after-free in ipt_do_table+0x1405/0x1c10
[ ... ]
[ 193.578603] Call Trace:
[ 193.581590] <IRQ>
[ 193.584107] dump_stack+0x68/0xa0
[ 193.588168] print_address_description+0x78/0x290
[ 193.593828] ? ipt_do_table+0x1405/0x1c10
[ 193.598690] kasan_report+0x230/0x340
[ 193.603194] __asan_report_load2_noabort+0x19/0x20
[ 193.608950] ipt_do_table+0x1405/0x1c10
[ 193.613591] ? rcu_read_lock_held+0xae/0xd0
[ 193.618631] ? ip_route_input_rcu+0x27d7/0x4270
[ 193.624348] ? ipt_do_table+0xb68/0x1c10
[ 193.629124] ? do_add_counters+0x620/0x620
[ 193.634234] ? iptable_filter_net_init+0x60/0x60
[ ... ]
After this patch, only when verdict is XT_CONTINUE,
ipt_do_table() tries to get ip header.
Also arpt_do_table() is modified because it has same bug.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/arp_tables.c | 10 +++++-----
net/ipv4/netfilter/ip_tables.c | 9 +++++----
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 0bc3c3d73e61..9e9d9afd18f7 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -268,14 +268,14 @@ unsigned int arpt_do_table(struct sk_buff *skb,
acpar.targinfo = t->data;
verdict = t->u.kernel.target->target(skb, &acpar);
- /* Target might have changed stuff. */
- arp = arp_hdr(skb);
-
- if (verdict == XT_CONTINUE)
+ if (verdict == XT_CONTINUE) {
+ /* Target might have changed stuff. */
+ arp = arp_hdr(skb);
e = arpt_next_entry(e);
- else
+ } else {
/* Verdict */
break;
+ }
} while (!acpar.hotdrop);
xt_write_recseq_end(addend);
local_bh_enable();
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 2a55a40211cb..622ed2887cd5 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -352,13 +352,14 @@ ipt_do_table(struct sk_buff *skb,
acpar.targinfo = t->data;
verdict = t->u.kernel.target->target(skb, &acpar);
- /* Target might have changed stuff. */
- ip = ip_hdr(skb);
- if (verdict == XT_CONTINUE)
+ if (verdict == XT_CONTINUE) {
+ /* Target might have changed stuff. */
+ ip = ip_hdr(skb);
e = ipt_next_entry(e);
- else
+ } else {
/* Verdict */
break;
+ }
} while (!acpar.hotdrop);
xt_write_recseq_end(addend);
--
2.1.4
^ permalink raw reply related
* [PATCH 0/5] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter fixes for your net tree,
they are:
1) Fix use after free of struct proc_dir_entry in ipt_CLUSTERIP, patch
from Sabrina Dubroca.
2) Fix spurious EINVAL errors from iptables over nft compatibility layer.
3) Reload pointer to ip header only if there is non-terminal verdict,
ie. XT_CONTINUE, otherwise invalid memory access may happen, patch
from Taehee Yoo.
4) Fix interaction between SYNPROXY and NAT, SYNPROXY adds sequence
adjustment already, however from nf_nat_setup() assumes there's not.
Patch from Xin Long.
5) Fix burst arithmetics in nft_limit as Joe Stringer mentioned during
NFWS in Faro. Patch from Andy Zhou.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 073dd5ad34b1d3aaadaa7e5e8cbe576d9545f163:
netfilter: fix netfilter_net_init() return (2017-07-18 14:50:28 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to c26844eda9d4fdbd266660e3b3de2d0270e3a1ed:
netfilter: nf_tables: Fix nft limit burst handling (2017-08-24 16:23:17 +0200)
----------------------------------------------------------------
Pablo Neira Ayuso (1):
netfilter: nft_compat: check extension hook mask only if set
Sabrina Dubroca (1):
netfilter: ipt_CLUSTERIP: fix use-after-free of proc entry
Taehee Yoo (1):
netfilter: x_tables: Fix use-after-free in ipt_do_table.
Xin Long (1):
netfilter: check for seqadj ext existence before adding it in nf_nat_setup_info
andy zhou (1):
netfilter: nf_tables: Fix nft limit burst handling
net/ipv4/netfilter/arp_tables.c | 10 +++++-----
net/ipv4/netfilter/ip_tables.c | 9 +++++----
net/ipv4/netfilter/ipt_CLUSTERIP.c | 4 +++-
net/netfilter/nf_nat_core.c | 2 +-
net/netfilter/nft_compat.c | 4 ++--
net/netfilter/nft_limit.c | 25 ++++++++++++++-----------
6 files changed, 30 insertions(+), 24 deletions(-)
^ permalink raw reply
* [PATCH 4/5] netfilter: check for seqadj ext existence before adding it in nf_nat_setup_info
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
From: Xin Long <lucien.xin@gmail.com>
Commit 4440a2ab3b9f ("netfilter: synproxy: Check oom when adding synproxy
and seqadj ct extensions") wanted to drop the packet when it fails to add
seqadj ext due to no memory by checking if nfct_seqadj_ext_add returns
NULL.
But that nfct_seqadj_ext_add returns NULL can also happen when seqadj ext
already exists in a nf_conn. It will cause that userspace protocol doesn't
work when both dnat and snat are configured.
Li Shuang found this issue in the case:
Topo:
ftp client router ftp server
10.167.131.2 <-> 10.167.131.254 10.167.141.254 <-> 10.167.141.1
Rules:
# iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 21 -j \
DNAT --to-destination 10.167.141.1
# iptables -t nat -A POSTROUTING -o eth2 -p tcp -m tcp --dport 21 -j \
SNAT --to-source 10.167.141.254
In router, when both dnat and snat are added, nf_nat_setup_info will be
called twice. The packet can be dropped at the 2nd time for DNAT due to
seqadj ext is already added at the 1st time for SNAT.
This patch is to fix it by checking for seqadj ext existence before adding
it, so that the packet will not be dropped if seqadj ext already exists.
Note that as Florian mentioned, as a long term, we should review ext_add()
behaviour, it's better to return a pointer to the existing ext instead.
Fixes: 4440a2ab3b9f ("netfilter: synproxy: Check oom when adding synproxy and seqadj ct extensions")
Reported-by: Li Shuang <shuali@redhat.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index eb541786ccb7..b1d3740ae36a 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -441,7 +441,7 @@ nf_nat_setup_info(struct nf_conn *ct,
else
ct->status |= IPS_DST_NAT;
- if (nfct_help(ct))
+ if (nfct_help(ct) && !nfct_seqadj(ct))
if (!nfct_seqadj_ext_add(ct))
return NF_DROP;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 5/5] netfilter: nf_tables: Fix nft limit burst handling
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
From: andy zhou <azhou@ovn.org>
Current implementation treats the burst configuration the same as
rate configuration. This can cause the per packet cost to be lower
than configured. In effect, this bug causes the token bucket to be
refilled at a higher rate than what user has specified.
This patch changes the implementation so that the token bucket size
is controlled by "rate + burst", while maintain the token bucket
refill rate the same as user specified.
Fixes: 96518518cc41 ("netfilter: add nftables")
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_limit.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/netfilter/nft_limit.c b/net/netfilter/nft_limit.c
index 18dd57a52651..14538b1d4d11 100644
--- a/net/netfilter/nft_limit.c
+++ b/net/netfilter/nft_limit.c
@@ -65,19 +65,23 @@ static int nft_limit_init(struct nft_limit *limit,
limit->nsecs = unit * NSEC_PER_SEC;
if (limit->rate == 0 || limit->nsecs < unit)
return -EOVERFLOW;
- limit->tokens = limit->tokens_max = limit->nsecs;
-
- if (tb[NFTA_LIMIT_BURST]) {
- u64 rate;
+ if (tb[NFTA_LIMIT_BURST])
limit->burst = ntohl(nla_get_be32(tb[NFTA_LIMIT_BURST]));
+ else
+ limit->burst = 0;
+
+ if (limit->rate + limit->burst < limit->rate)
+ return -EOVERFLOW;
- rate = limit->rate + limit->burst;
- if (rate < limit->rate)
- return -EOVERFLOW;
+ /* The token bucket size limits the number of tokens can be
+ * accumulated. tokens_max specifies the bucket size.
+ * tokens_max = unit * (rate + burst) / rate.
+ */
+ limit->tokens = div_u64(limit->nsecs * (limit->rate + limit->burst),
+ limit->rate);
+ limit->tokens_max = limit->tokens;
- limit->rate = rate;
- }
if (tb[NFTA_LIMIT_FLAGS]) {
u32 flags = ntohl(nla_get_be32(tb[NFTA_LIMIT_FLAGS]));
@@ -95,9 +99,8 @@ static int nft_limit_dump(struct sk_buff *skb, const struct nft_limit *limit,
{
u32 flags = limit->invert ? NFT_LIMIT_F_INV : 0;
u64 secs = div_u64(limit->nsecs, NSEC_PER_SEC);
- u64 rate = limit->rate - limit->burst;
- if (nla_put_be64(skb, NFTA_LIMIT_RATE, cpu_to_be64(rate),
+ if (nla_put_be64(skb, NFTA_LIMIT_RATE, cpu_to_be64(limit->rate),
NFTA_LIMIT_PAD) ||
nla_put_be64(skb, NFTA_LIMIT_UNIT, cpu_to_be64(secs),
NFTA_LIMIT_PAD) ||
--
2.1.4
^ permalink raw reply related
* Re: [V3 PATCH net-next 0/5] xdp: more work on xdp tracepoints
From: John Fastabend @ 2017-08-24 14:46 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: Daniel Borkmann
In-Reply-To: <150357074701.26663.4047992776649697788.stgit@firesoul>
On 08/24/2017 03:32 AM, Jesper Dangaard Brouer wrote:
> More work on streamlining and performance optimizing the tracepoints
> for XDP.
>
> I've created a simple xdp_monitor application that uses this
> tracepoint, and prints statistics. Available at github:
>
> https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_kern.c
> https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_user.c
>
> The improvement over tracepoint with strcpy: 9810372 - 8428762 = +1381610 pps faster
> - (1/9810372 - 1/8428762)*10^9 = -16.7 nanosec
> - 100-(8428762/9810372*100) = strcpy-trace is 14.08% slower
> - 981037/8428762*100 = removing strcpy made it 11.64% faster
>
> V3: Fix merge conflict with commit e4a8e817d3cb ("bpf: misc xdp redirect cleanups")
> V2: Change trace_xdp_redirect() to align with args of trace_xdp_exception()
>
> ---
Series looks good to me. Thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Andrew Lunn @ 2017-08-24 14:56 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170824083823.16826-10-antoine.tenart@free-electrons.com>
On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> This patch adds logic to reconfigure the comphy/gop when the link status
> change at runtime. This is very useful on boards such as the mcbin which
> have SFP and Ethernet ports connected to the same MAC port: depending on
> what the user connects the driver will automatically reconfigure the
> link mode.
Hi Antoine
I would expect each of these external Ethernet ports to have its own
Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
connect to the other Ethernet PHY when you change external Ethernet
port?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Fix MTU limitation
From: Andrew Lunn @ 2017-08-24 15:19 UTC (permalink / raw)
To: Aviad Krawczyk; +Cc: davem, linux-kernel, netdev, zhaochen6
In-Reply-To: <1503580885-35180-1-git-send-email-aviad.krawczyk@huawei.com>
On Thu, Aug 24, 2017 at 09:21:25PM +0800, Aviad Krawczyk wrote:
> Fix the hw MTU limitation by setting min/max_mtu
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
> ---
> drivers/net/ethernet/huawei/hinic/hinic_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> index ae7ad48..7a14963 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> @@ -980,6 +980,9 @@ static int nic_dev_init(struct pci_dev *pdev)
> hinic_hwdev_cb_register(nic_dev->hwdev, HINIC_MGMT_MSG_CMD_LINK_STATUS,
> nic_dev, link_status_event_handler);
>
> + netdev->min_mtu = ETH_MIN_MTU;
You don't need to set the min_mtu. See:
http://elixir.free-electrons.com/linux/latest/source/net/ethernet/eth.c#L354
Andrew
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 15:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824145609.GJ8022@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Hi Andrew,
On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and Ethernet ports connected to the same MAC port: depending on
> > what the user connects the driver will automatically reconfigure the
> > link mode.
>
> I would expect each of these external Ethernet ports to have its own
> Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> connect to the other Ethernet PHY when you change external Ethernet
> port?
That's the other way around. The engines outputs (say GoP#) are
connected to the comphy inputs. In the SoC. Then there's a single output
of this comphy lane to the board. So when switching modes, you do not
have to connect to a different Ethernet PHY, it's the same.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
From: Stefan Hajnoczi @ 2017-08-24 15:53 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michal Kubecek, joe@perches.com, olaf@aepfle.de,
Stephen Hemminger, jasowang@redhat.com, netdev@vger.kernel.org,
Haiyang Zhang, Dave Scott, linux-kernel@vger.kernel.org,
apw@canonical.com, Jorgen Hansen, Rolf Neugebauer, Marcelo Cerri,
devel@linuxdriverproject.org, Vitaly Kuznetsov,
davem@davemloft.net, George Zhang, Dan Carpenter
In-Reply-To: <PS1P15301MB0011D3F00204245172E8150EBF840@PS1P15301MB0011.APCP153.PROD.OUTLOOK.COM>
On Tue, Aug 22, 2017 at 09:40:01PM +0000, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > On Fri, Aug 18, 2017 at 10:23:54PM +0000, Dexuan Cui wrote:
> > > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > > +{
> > > > > + static const u32 valid_cids[] = {
> > > > > + VMADDR_CID_ANY,
> > > >
> > > > Is this for loopback?
> > >
> > > No, we don't support lookback in Linux VM, at least for now.
> > > In our Linux implementation, Linux VM can only connect to the host, and
> > > here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> > > the same as VMADDR_CID_HOST.
> >
> > VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> > connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
>
> Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since
> we don't support loopback mode.
>
> > > > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF)
> > > > is
> > > > > + * reserved as ephemeral ports, which are used as the host's ports
> > > > > + * when the host initiates connections.
> > > > > + */
> > > > > + if (port > MAX_HOST_LISTEN_PORT)
> > > > > + return false;
> > > >
> > > > Without this if statement the guest will attempt to connect. I guess
> > > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > > connection attempt will fail.
> > >
> > > You're correct.
> > > To use the vsock common infrastructure, we have to map Hyper-V's
> > > GUID <VM_ID, Service_ID> to int <cid, port>, and hence we must limit
> > > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > > we can only use half of the whole 32-bit port space for listen().
> > > This is detailed in the long comments starting at about Line 100.
> > >
> > > > ...but hardcode this knowledge into the guest driver?
> > > I'd like the guest's connect() to fail immediately here.
> > > IMO this is better than a connect timeout. :-)
> >
> > Thanks for explaining. Perhaps the comment could be updated:
> >
> > /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> > * reserved as ephemeral ports, which are used as the host's ports when
> > * the host initiates connections.
> > *
> > * Perform this check in the guest so an immediate error is produced
> > * instead of a timeout.
> > */
> >
> > Stefan
>
> Thank you, Stefan!
> Please see the below for the updated version of the function:
>
> static bool hvs_stream_allow(u32 cid, u32 port)
> {
> /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> * reserved as ephemeral ports, which are used as the host's ports
> * when the host initiates connections.
> *
> * Perform this check in the guest so an immediate error is produced
> * instead of a timeout.
> */
> if (port > MAX_HOST_LISTEN_PORT)
> return false;
>
> if (cid == VMADDR_CID_HOST)
> return true;
>
> return false;
> }
>
> I'll send a v2 of the patch later today.
Great, thanks!
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Andrew Lunn @ 2017-08-24 16:01 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170824155241.GF28443@kwain>
On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> Hi Andrew,
>
> On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > change at runtime. This is very useful on boards such as the mcbin which
> > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > what the user connects the driver will automatically reconfigure the
> > > link mode.
> >
> > I would expect each of these external Ethernet ports to have its own
> > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > connect to the other Ethernet PHY when you change external Ethernet
> > port?
>
> That's the other way around. The engines outputs (say GoP#) are
> connected to the comphy inputs. In the SoC. Then there's a single output
> of this comphy lane to the board. So when switching modes, you do not
> have to connect to a different Ethernet PHY, it's the same.
Hi Antoine
I think there is a mixup here between generic PHY and Ethernet PHY.
When you swap from the copper RJ45 to the fibre SFP, the phylib needs
to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
driving the SFP module, which is probably a fixed-phy.
I actually think this is why you have the carrier_on/off calls in the
link modify callback.
Imagine phylib is using the copper Ethernet PHY, but the MAC is using
the SFP port. Somebody pulls out the copper cable, phylib says the
link is down, turns the carrier off and calls the callback. Not good,
since your SFP cable is still plugged in... Ethtool is
returning/setting stuff in the Copper Ethernet PHY, when in fact you
intend to be setting SFP settings.
Andrew
^ permalink raw reply
* [PATCH net] virtio_net: be drop monitor friend
From: Eric Dumazet @ 2017-08-24 16:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Michael S. Tsirkin, Jason Wang
From: Eric Dumazet <edumazet@google.com>
This change is needed to not fool drop monitor.
(perf record ... -e skb:kfree_skb )
Packets were properly sent and are consumed after TX completion.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 98f17b05c68b..b06169ea60dc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1058,7 +1058,7 @@ static void free_old_xmit_skbs(struct send_queue *sq)
bytes += skb->len;
packets++;
- dev_kfree_skb_any(skb);
+ dev_consume_skb_any(skb);
}
/* Avoid overhead when no packets have been processed
^ permalink raw reply related
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 16:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824160124.GA18700@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
On Thu, Aug 24, 2017 at 06:01:24PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> > On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > > change at runtime. This is very useful on boards such as the mcbin which
> > > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > > what the user connects the driver will automatically reconfigure the
> > > > link mode.
> > >
> > > I would expect each of these external Ethernet ports to have its own
> > > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > > connect to the other Ethernet PHY when you change external Ethernet
> > > port?
> >
> > That's the other way around. The engines outputs (say GoP#) are
> > connected to the comphy inputs. In the SoC. Then there's a single output
> > of this comphy lane to the board. So when switching modes, you do not
> > have to connect to a different Ethernet PHY, it's the same.
>
> I think there is a mixup here between generic PHY and Ethernet PHY.
>
> When you swap from the copper RJ45 to the fibre SFP, the phylib needs
> to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
> driving the SFP module, which is probably a fixed-phy.
Or on the mcbin the Alaska X 88X3310 which can operate from 10G to 10M.
This PHY changes its interface mode depending on what speed is
negotiated.
> I actually think this is why you have the carrier_on/off calls in the
> link modify callback.
Well, I still do not know if these calls are *really* needed. At least
in our case.
> Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> the SFP port. Somebody pulls out the copper cable, phylib says the
> link is down, turns the carrier off and calls the callback. Not good,
> since your SFP cable is still plugged in... Ethtool is
> returning/setting stuff in the Copper Ethernet PHY, when in fact you
> intend to be setting SFP settings.
I see what could be the issue but I do not understand one aspect though:
how could we switch from one PHY to another, as there's only one output
between the SoC (and so a given GoP#) and the board. So if a given PHY
can handle multiple modes I see, but in the other case a muxing
somewhere would be needed? Or did I miss something?
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_nat_h323: fix logical-not-parentheses warning
From: Nick Desaulniers @ 2017-08-24 16:25 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Matthias Kaehlcke, Lorenzo Colitti, Nick Desaulniers,
Jozsef Kadlecsik, Florian Westphal, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <CAKwvOdmw+bnN-nKeKbE8WJJ8Enc4PCeC3KD5KpaSVOT4+ycDKQ@mail.gmail.com>
bumping for review (resending, had gmail set to html mode)
On Mon, Aug 14, 2017 at 10:36 AM, Nick Desaulniers
<ndesaulniers@google.com> wrote:
> Minor nit for the commit message that can get fixed up when being merged:
>
> On Fri, Aug 11, 2017 at 11:16 AM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
>
>> if (x)
>> return
>> ...
>>
>> rather than:
>>
>> if (!x == 0)
>
> should remove the `!`, ex:
>
> if (x == 0)
>
>> ...
>> else
>> return
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [patch net-next 00/12] mlxsw: Add IPv4 host dpipe table
From: David Miller @ 2017-08-24 16:33 UTC (permalink / raw)
To: jiri; +Cc: netdev, arkadis, idosch, mlxsw
In-Reply-To: <20170824064010.1646-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 24 Aug 2017 08:39:58 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Arkadi says:
>
> This patchset adds IPv4 host dpipe table support. This will provide the
> ability to observe the hardware offloaded IPv4 neighbors.
Looks really nice, series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] net: stmmac: Delete dead code for MDIO registration
From: David Miller @ 2017-08-24 16:34 UTC (permalink / raw)
To: romain.perier
Cc: f.fainelli, peppe.cavallaro, alexandre.torgue, andrew, netdev,
linux-kernel
In-Reply-To: <10e0ebf9-b412-8547-d0d7-01a958edbcd9@collabora.com>
From: Romain Perier <romain.perier@collabora.com>
Date: Thu, 24 Aug 2017 08:49:18 +0200
> Le 23/08/2017 à 18:46, Florian Fainelli a écrit :
>> On 08/23/2017 01:50 AM, Romain Perier wrote:
>>> This code is no longer used, the logging function was changed by commit
>>> fbca164776e4 ("net: stmmac: Use the right logging functi"). It was
>>> previously showing information about the type if the IRQ, if it's polled,
>>> ignored or a normal interrupt. As we don't want information loss, I have
>>> moved this code to phy_attached_print().
>>>
>>> Fixes: fbca164776e4 ("net: stmmac: Use the right logging functi")
>> For future submissions, do not truncate the commit subject that you are
>> referencing.
>
> Even if it exceeds 72 characters ?
Yes, always.
^ permalink raw reply
* Re: [PATCH net-next v4] net: stmmac: Delete dead code for MDIO registration
From: David Miller @ 2017-08-24 16:36 UTC (permalink / raw)
To: romain.perier
Cc: peppe.cavallaro, alexandre.torgue, andrew, f.fainelli, netdev,
linux-kernel
In-Reply-To: <20170824070317.10265-1-romain.perier@collabora.com>
From: Romain Perier <romain.perier@collabora.com>
Date: Thu, 24 Aug 2017 09:03:17 +0200
> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging functi").
You're truncating the commit header text here too, please fix this.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Fix MTU limitation
From: Aviad Krawczyk @ 2017-08-24 16:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: davem, linux-kernel, netdev, zhaochen6
In-Reply-To: <20170824151958.GL8022@lunn.ch>
On 8/24/2017 6:19 PM, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 09:21:25PM +0800, Aviad Krawczyk wrote:
>> Fix the hw MTU limitation by setting min/max_mtu
>>
>> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
>> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
>> ---
>> drivers/net/ethernet/huawei/hinic/hinic_main.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> index ae7ad48..7a14963 100644
>> --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> @@ -980,6 +980,9 @@ static int nic_dev_init(struct pci_dev *pdev)
>> hinic_hwdev_cb_register(nic_dev->hwdev, HINIC_MGMT_MSG_CMD_LINK_STATUS,
>> nic_dev, link_status_event_handler);
>>
>> + netdev->min_mtu = ETH_MIN_MTU;
>
> You don't need to set the min_mtu. See:
>
> http://elixir.free-electrons.com/linux/latest/source/net/ethernet/eth.c#L354
>
> Andrew
>
> .
>
Thanks for paying attention to this unuseful line, I don't need to set min mtu.
I added it by mistake, the target was to change the MTU limitation.
I will send the patch soon without this line(in few days, after we will test it)
^ 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