* Re: [PATCH net] udp6: fix socket leak on early demux
From: David Miller @ 2017-07-29 21:19 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, CFSworks, mh+netdev, subashab
In-Reply-To: <714e32ad7eb21b0b791ecc314cfcc16765c96cd9.1501159497.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 27 Jul 2017 14:45:09 +0200
> When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> sk reference is retrieved and used, but the relevant reference
> count is leaked and the socket destructor is never called.
> Beyond leaking the sk memory, if there are pending UDP packets
> in the receive queue, even the related accounted memory is leaked.
>
> In the long run, this will cause persistent forward allocation errors
> and no UDP skbs (both ipv4 and ipv6) will be able to reach the
> user-space.
>
> Fix this by explicitly accessing the early demux reference before
> the lookup, and properly decreasing the socket reference count
> after usage.
>
> Also drop the skb_steal_sock() in __udp6_lib_lookup_skb(), and
> the now obsoleted comment about "socket cache".
>
> The newly added code is derived from the current ipv4 code for the
> similar path.
>
> v1 -> v2:
> fixed the __udp6_lib_rcv() return code for resubmission,
> as suggested by Eric
>
> Reported-by: Sam Edwards <CFSworks@gmail.com>
> Reported-by: Marc Haber <mh+netdev@zugschlus.de>
> Fixes: 5425077d73e0 ("net: ipv6: Add early demux handler for UDP unicast")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_re: add MAY_USE_DEVLINK dependency
From: David Miller @ 2017-07-29 21:18 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev, selvin.xavier, devesh.sharma, arnd, michael.chan
In-Reply-To: <20170727102951.26964-1-sathya.perla@broadcom.com>
From: Sathya Perla <sathya.perla@broadcom.com>
Date: Thu, 27 Jul 2017 06:29:51 -0400
> bnxt_en depends on MAY_USE_DEVLINK; this is used to force bnxt_en
> to be =m when DEVLINK is =m.
>
> Now, bnxt_re selects bnxt_en. Unless bnxt_re also explicitly calls
> out dependency on MAY_USE_DEVLINK, Kconfig does not force bnxt_re
> to be =m when DEVLINK is =m, causing the following error:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function
> `bnxt_dl_register':
> bnxt_vfr.c:(.text+0x1440): undefined reference to `devlink_alloc'
> bnxt_vfr.c:(.text+0x14c0): undefined reference to `devlink_register'
> bnxt_vfr.c:(.text+0x14e0): undefined reference to `devlink_free'
> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function
> `bnxt_dl_unregister':
> bnxt_vfr.c:(.text+0x1534): undefined reference to `devlink_unregister'
> bnxt_vfr.c:(.text+0x153c): undefined reference to `devlink_free'
>
> Fix this by adding MAY_USE_DEVLINK dependency in bnxt_re.
>
> Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors")
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sathya Perla <sathya.perla@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: thunderx: Fix BGX transmit stall due to underflow
From: David Miller @ 2017-07-29 21:18 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham
In-Reply-To: <1501140184-25625-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Thu, 27 Jul 2017 12:53:04 +0530
> From: Sunil Goutham <sgoutham@cavium.com>
>
> For SGMII/RGMII/QSGMII interfaces when physical link goes down
> while traffic is high is resulting in underflow condition being set
> on that specific BGX's LMAC. Which assets a backpresure and VNIC stops
> transmitting packets.
>
> This is due to BGX being disabled in link status change callback while
> packet is in transit. This patch fixes this issue by not disabling BGX
> but instead just disables packet Rx and Tx.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2 net] Revert "vhost: cache used event for better performance"
From: David Miller @ 2017-07-29 21:16 UTC (permalink / raw)
To: jasowang; +Cc: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1501125725-24529-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 27 Jul 2017 11:22:05 +0800
> This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
> was reported to break vhost_net. We want to cache used event and use
> it to check for notification. The assumption was that guest won't move
> the event idx back, but this could happen in fact when 16 bit index
> wraps around after 64K entries.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bpf: testing: fix devmap tests
From: David Miller @ 2017-07-29 21:13 UTC (permalink / raw)
To: john.fastabend; +Cc: netdev, jakub.kicinski, daniel
In-Reply-To: <5979355D.60807@gmail.com>
From: John Fastabend <john.fastabend@gmail.com>
Date: Wed, 26 Jul 2017 17:35:41 -0700
> On 07/26/2017 05:32 PM, John Fastabend wrote:
>> Apparently through one of my revisions of the initial patches
>> series I lost the devmap test. We can add more testing later but
>> for now lets fix the simple one we have.
>>
>> Fixes: 546ac1ffb70d "bpf: add devmap, a map for storing net device references"
>> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> ---
>
> Forgot prefix, this is for net-next. Sorry about that.
It's ok.
Aplpied, thanks John.
^ permalink raw reply
* Re: [PATCH 0/6] net: moxa: Fix style issues
From: David Miller @ 2017-07-29 21:02 UTC (permalink / raw)
To: sz.lin
Cc: jarod, jonas.jensen, edumazet, bhumirks, tklauser, netdev,
linux-kernel
In-Reply-To: <20170729104239.14999-1-sz.lin@moxa.com>
From: SZ Lin <sz.lin@moxa.com>
Date: Sat, 29 Jul 2017 18:42:33 +0800
> This patch set fixs the WARNINGs found by the checkpatch.pl tool
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure
From: Tom Herbert @ 2017-07-29 20:19 UTC (permalink / raw)
To: Christoph Paasch
Cc: Dave Watson, Ilya Lesokhin, Aviad Yehezkel, Boris Pismenny,
Liran Liss, Matan Barak, David Miller,
Linux Kernel Network Developers, Herbert Xu,
Linux Crypto Mailing List, Hannes Frederic Sowa, Eric Dumazet,
Alexei Starovoitov, Nikos Mavrogiannopoulos,
Fridolín Pokorný
In-Reply-To: <20170617001455.GB82626@Chimay.local>
On Fri, Jun 16, 2017 at 5:14 PM, Christoph Paasch
<christoph.paasch@gmail.com> wrote:
> Hello,
>
> On 14/06/17 - 11:37:14, Dave Watson wrote:
>> Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
>> sockets. Based on a similar infrastructure in tcp_cong. The idea is that any
>> ULP can add its own logic by changing the TCP proto_ops structure to its own
>> methods.
>>
>> Example usage:
>>
>> setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
>>
>> modules will call:
>> tcp_register_ulp(&tcp_tls_ulp_ops);
>>
>> to register/unregister their ulp, with an init function and name.
>>
>> A list of registered ulps will be returned by tcp_get_available_ulp, which is
>> hooked up to /proc. Example:
>>
>> $ cat /proc/sys/net/ipv4/tcp_available_ulp
>> tls
>>
>> There is currently no functionality to remove or chain ULPs, but
>> it should be possible to add these in the future if needed.
>>
>> Signed-off-by: Boris Pismenny <borisp@mellanox.com>
>> Signed-off-by: Dave Watson <davejwatson@fb.com>
>> ---
>> include/net/inet_connection_sock.h | 4 ++
>> include/net/tcp.h | 25 +++++++
>> include/uapi/linux/tcp.h | 1 +
>> net/ipv4/Makefile | 2 +-
>> net/ipv4/sysctl_net_ipv4.c | 25 +++++++
>> net/ipv4/tcp.c | 28 ++++++++
>> net/ipv4/tcp_ipv4.c | 2 +
>> net/ipv4/tcp_ulp.c | 134 +++++++++++++++++++++++++++++++++++++
>> 8 files changed, 220 insertions(+), 1 deletion(-)
>> create mode 100644 net/ipv4/tcp_ulp.c
>
> I know I'm pretty late to the game (and maybe this has already been
> discussed but I couldn't find anything in the archives), but I am wondering
> what the take is on potential races of the setsockopt() vs other system-calls.
>
> For example one might race the setsockopt() with a sendmsg() and the sendmsg
> might end up blocking on the lock_sock in tcp_sendmsg, waiting for
> tcp_set_ulp() to finish changing sk_prot. When the setsockopt() finishes, we
> are then inside tcp_sendmsg() coming directly from sendmsg(), while we
> should have been in the ULP's sendmsg.
>
> It seems like TLS-ULP is resilient to this (or at least, won't cause a panic),
> but there might be more exotic users of ULP in the future, that change other
> callbacks and then things might go wrong.
Christoph,
I noticed this also. I think the easiest answer would be to just
assume the caller understands the race condition and can synchronize
itself. Other than that we'd probably have wake up everyone blocking
on the socket without something like EAGAIN so they're forced to retry
the operation. But even that might not easily yield an obvious point
at which the socket can be safely changed.
Tom
>
>
> Thoughts?
>
>
> Thanks,
> Christoph
>
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
From: Julia Lawall @ 2017-07-29 20:18 UTC (permalink / raw)
To: Florian Westphal
Cc: David S. Miller, bhumirks, kernel-janitors, Pablo Neira Ayuso,
Jozsef Kadlecsik, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20170729200343.GH28392@breakpoint.cc>
On Sat, 29 Jul 2017, Florian Westphal wrote:
> Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> > When a nf_conntrack_l3/4proto parameter is not on the left hand side
> > of an assignment, its address is not taken, and it is not passed to a
> > function that may modify its fields, then it can be declared as const.
> >
> > This change is useful from a documentation point of view, and can
> > possibly facilitate making some nf_conntrack_l3/4proto structures const
> > subsequently.
> >
> > Done with the help of Coccinelle.
> >
> > Some spacing adjusted to fit within 80 characters.
>
> Acked-by: Florian Westphal <fw@strlen.de>
>
> Thanks Julia.
>
> I think we can indeed constify these completely after making
> 'nla_size' set at compile time.
>
> I'll send a simple attempt to make it so for l3proto soon.
There is another issue with respect to nf_ct_l3proto_unregister. This
calls nf_ct_iterate_destroy with l3proto as the second argument. This
function has signature:
void
nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data)
The void * is not const. Maybe it could be.
julia
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Florian Fainelli @ 2017-07-29 20:15 UTC (permalink / raw)
To: Mason, Mans Rullgard; +Cc: Marc Gonzalez, David S. Miller, netdev, Linux ARM
In-Reply-To: <bfc5678a-0536-7964-0d45-8f6b104e2f1a@free.fr>
On 07/29/2017 05:44 AM, Mason wrote:
> On 29/07/2017 14:05, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I'll take this opportunity to change flow control to
>>> off by default (it breaks several 100 Mbps switches).
>>
>> I was told to have it on by default. This is what most other drivers
>> do too. If you have faulty switches, that's your problem.
>
> Or maybe the fault is in the HW implementation, and
> it is the board's fault that the connection is hosed.
If there really is a linkage with pause frames then it's a pretty binary
thing at the electrical interface level, either the (RG)MII connection
works, or or it does not, but pause frames are normal frames as far as
the electrical interface is concerned. Their special handling is at the
MAC level, see below.
>
> How many switches did you test the driver on?
>
> We tested 4 switches, and DHCP failed on 3 of them.
> Disabling pause frames "fixed" that.
OK, so it is this problem that you reported about before? Pause frames
are tricky in that receiving pause frames means you should backpressure
your transmitter and sending pause frames happens when your receiver
cannot keep up. It is somewhat conceivable that your HW implementation
is bogus and that you can get the HW in a state where it gets
permanently backpressured for instance? And then only a full re-init
would get you out of this stuck state presumably? Are there significant
differences at the DMA/Ethernet controller level between Tango 3 (is
that the one Mans worked on?) and Tango 4 for instance that could
explain a behavioral difference?
Some Ethernet NICs allow you to actually observe pause frames (AFAIR a
few Intel ones do) so you could conceivably set up a bridge with such a
NIC and snoop traffic between your tango4 board and your switch and see
what happens.
>
> I could spend weeks testing dozens of switches, but
> I have to prioritize. Ethernet flow control is simply
> not an important feature in the market the SoC is
> intended for.
--
Florian
^ permalink raw reply
* Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure
From: Tom Herbert @ 2017-07-29 20:12 UTC (permalink / raw)
To: Dave Watson
Cc: Ilya Lesokhin, Aviad Yehezkel, Boris Pismenny, Liran Liss,
Matan Barak, David Miller, Linux Kernel Network Developers,
Herbert Xu, Linux Crypto Mailing List, Hannes Frederic Sowa,
Eric Dumazet, Alexei Starovoitov, Nikos Mavrogiannopoulos,
Fridolín Pokorný
In-Reply-To: <20170614183714.GA80310@davejwatson-mba.dhcp.thefacebook.com>
On Wed, Jun 14, 2017 at 11:37 AM, Dave Watson <davejwatson@fb.com> wrote:
> Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
> sockets. Based on a similar infrastructure in tcp_cong. The idea is that any
> ULP can add its own logic by changing the TCP proto_ops structure to its own
> methods.
>
> Example usage:
>
> setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
>
Hi Dave,
Thanks for this work. I think this functionality is going to have many uses!
One question: is there a good reason why the ULP infrastructure should
just be for TCP sockets. For example, I'd really like to be able
something like:
setsockopt(sock, SOL_SOCKET, SO_ULP, &ulp_param, sizeof(ulp_param));
Where ulp_param is a structure containing the ULP name as well as some
ULP specific parameters that are passed to init_ulp. ulp_init could
determine whether the socket family is appropriate for the ULP being
requested.
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
From: Florian Westphal @ 2017-07-29 20:03 UTC (permalink / raw)
To: Julia Lawall
Cc: David S. Miller, bhumirks, kernel-janitors, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <1501356197-26490-2-git-send-email-Julia.Lawall@lip6.fr>
Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> When a nf_conntrack_l3/4proto parameter is not on the left hand side
> of an assignment, its address is not taken, and it is not passed to a
> function that may modify its fields, then it can be declared as const.
>
> This change is useful from a documentation point of view, and can
> possibly facilitate making some nf_conntrack_l3/4proto structures const
> subsequently.
>
> Done with the help of Coccinelle.
>
> Some spacing adjusted to fit within 80 characters.
Acked-by: Florian Westphal <fw@strlen.de>
Thanks Julia.
I think we can indeed constify these completely after making
'nla_size' set at compile time.
I'll send a simple attempt to make it so for l3proto soon.
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset
From: Thomas Petazzoni @ 2017-07-29 19:54 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: Corentin Labbe, Alexandre Torgue, netdev, stable
In-Reply-To: <930a1375-b148-a2c9-7a45-cbc75121866f@st.com>
Hello Giuseppe,
On Wed, 28 Jun 2017 16:40:51 +0200, Giuseppe CAVALLARO wrote:
> I do not want to change a critical reset function shared among
> different platforms where
> this problem has never met but you are right that we have to find a
> way to proceed in order
> to finalize your work. Let me elaborate your initial patch and I try
> to give you a proposal asap.
> In my mind, we should have a dedicated spear_dma_reset for your case
> that should be used on
> SPEAr platform driver (or by using st,spear600-gmac compatibility).
> Also your patch did not consider the RMII and (R)GMII cases.
Have you had the chance to cook a different proposal? Alternatively, do
you have some specific hints to give me to make a new proposal that
would be acceptable for you ?
Thanks a lot,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
From: Julia Lawall @ 2017-07-29 19:23 UTC (permalink / raw)
To: David S. Miller
Cc: bhumirks, kernel-janitors, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <1501356197-26490-1-git-send-email-Julia.Lawall@lip6.fr>
When a nf_conntrack_l3/4proto parameter is not on the left hand side
of an assignment, its address is not taken, and it is not passed to a
function that may modify its fields, then it can be declared as const.
This change is useful from a documentation point of view, and can
possibly facilitate making some nf_conntrack_l3/4proto structures const
subsequently.
Done with the help of Coccinelle.
Some spacing adjusted to fit within 80 characters.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
include/net/netfilter/nf_conntrack_l3proto.h | 6 +++---
include/net/netfilter/nf_conntrack_l4proto.h | 8 ++++----
include/net/netfilter/nf_conntrack_timeout.h | 2 +-
net/netfilter/nf_conntrack_core.c | 8 ++++----
net/netfilter/nf_conntrack_netlink.c | 6 +++---
net/netfilter/nf_conntrack_proto.c | 20 ++++++++++----------
net/netfilter/nfnetlink_cttimeout.c | 2 +-
7 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_l3proto.h b/include/net/netfilter/nf_conntrack_l3proto.h
index 6d14b36..4782b15 100644
--- a/include/net/netfilter/nf_conntrack_l3proto.h
+++ b/include/net/netfilter/nf_conntrack_l3proto.h
@@ -76,17 +76,17 @@ struct nf_conntrack_l3proto {
#ifdef CONFIG_SYSCTL
/* Protocol pernet registration. */
int nf_ct_l3proto_pernet_register(struct net *net,
- struct nf_conntrack_l3proto *proto);
+ const struct nf_conntrack_l3proto *proto);
#else
static inline int nf_ct_l3proto_pernet_register(struct net *n,
- struct nf_conntrack_l3proto *p)
+ const struct nf_conntrack_l3proto *p)
{
return 0;
}
#endif
void nf_ct_l3proto_pernet_unregister(struct net *net,
- struct nf_conntrack_l3proto *proto);
+ const struct nf_conntrack_l3proto *proto);
/* Protocol global registration. */
int nf_ct_l3proto_register(struct nf_conntrack_l3proto *proto);
diff --git a/include/net/netfilter/nf_conntrack_l4proto.h b/include/net/netfilter/nf_conntrack_l4proto.h
index 7032e04..72589b7 100644
--- a/include/net/netfilter/nf_conntrack_l4proto.h
+++ b/include/net/netfilter/nf_conntrack_l4proto.h
@@ -125,13 +125,13 @@ struct nf_conntrack_l4proto *__nf_ct_l4proto_find(u_int16_t l3proto,
struct nf_conntrack_l4proto *nf_ct_l4proto_find_get(u_int16_t l3proto,
u_int8_t l4proto);
-void nf_ct_l4proto_put(struct nf_conntrack_l4proto *p);
+void nf_ct_l4proto_put(const struct nf_conntrack_l4proto *p);
/* Protocol pernet registration. */
int nf_ct_l4proto_pernet_register_one(struct net *net,
- struct nf_conntrack_l4proto *proto);
+ const struct nf_conntrack_l4proto *proto);
void nf_ct_l4proto_pernet_unregister_one(struct net *net,
- struct nf_conntrack_l4proto *proto);
+ const struct nf_conntrack_l4proto *proto);
int nf_ct_l4proto_pernet_register(struct net *net,
struct nf_conntrack_l4proto *proto[],
unsigned int num_proto);
@@ -141,7 +141,7 @@ void nf_ct_l4proto_pernet_unregister(struct net *net,
/* Protocol global registration. */
int nf_ct_l4proto_register_one(struct nf_conntrack_l4proto *proto);
-void nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *proto);
+void nf_ct_l4proto_unregister_one(const struct nf_conntrack_l4proto *proto);
int nf_ct_l4proto_register(struct nf_conntrack_l4proto *proto[],
unsigned int num_proto);
void nf_ct_l4proto_unregister(struct nf_conntrack_l4proto *proto[],
diff --git a/include/net/netfilter/nf_conntrack_timeout.h b/include/net/netfilter/nf_conntrack_timeout.h
index d40b893..b222957 100644
--- a/include/net/netfilter/nf_conntrack_timeout.h
+++ b/include/net/netfilter/nf_conntrack_timeout.h
@@ -68,7 +68,7 @@ struct nf_conn_timeout *nf_ct_timeout_ext_add(struct nf_conn *ct,
static inline unsigned int *
nf_ct_timeout_lookup(struct net *net, struct nf_conn *ct,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
struct nf_conn_timeout *timeout_ext;
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 51390fe..ed4e04e 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1183,8 +1183,8 @@ void nf_conntrack_free(struct nf_conn *ct)
static noinline struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
const struct nf_conntrack_tuple *tuple,
- struct nf_conntrack_l3proto *l3proto,
- struct nf_conntrack_l4proto *l4proto,
+ const struct nf_conntrack_l3proto *l3proto,
+ const struct nf_conntrack_l4proto *l4proto,
struct sk_buff *skb,
unsigned int dataoff, u32 hash)
{
@@ -1295,8 +1295,8 @@ void nf_conntrack_free(struct nf_conn *ct)
unsigned int dataoff,
u_int16_t l3num,
u_int8_t protonum,
- struct nf_conntrack_l3proto *l3proto,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l3proto *l3proto,
+ const struct nf_conntrack_l4proto *l4proto)
{
const struct nf_conntrack_zone *zone;
struct nf_conntrack_tuple tuple;
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 7999e70..5d08602 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -61,8 +61,8 @@
static char __initdata version[] = "0.93";
static int ctnetlink_dump_tuples_proto(struct sk_buff *skb,
- const struct nf_conntrack_tuple *tuple,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_tuple *tuple,
+ const struct nf_conntrack_l4proto *l4proto)
{
int ret = 0;
struct nlattr *nest_parms;
@@ -86,7 +86,7 @@ static int ctnetlink_dump_tuples_proto(struct sk_buff *skb,
static int ctnetlink_dump_tuples_ip(struct sk_buff *skb,
const struct nf_conntrack_tuple *tuple,
- struct nf_conntrack_l3proto *l3proto)
+ const struct nf_conntrack_l3proto *l3proto)
{
int ret = 0;
struct nlattr *nest_parms;
diff --git a/net/netfilter/nf_conntrack_proto.c b/net/netfilter/nf_conntrack_proto.c
index 1dcad22..390799a 100644
--- a/net/netfilter/nf_conntrack_proto.c
+++ b/net/netfilter/nf_conntrack_proto.c
@@ -188,7 +188,7 @@ struct nf_conntrack_l4proto *
}
EXPORT_SYMBOL_GPL(nf_ct_l4proto_find_get);
-void nf_ct_l4proto_put(struct nf_conntrack_l4proto *p)
+void nf_ct_l4proto_put(const struct nf_conntrack_l4proto *p)
{
module_put(p->me);
}
@@ -242,7 +242,7 @@ int nf_ct_l3proto_register(struct nf_conntrack_l3proto *proto)
extern unsigned int nf_conntrack_default_on;
int nf_ct_l3proto_pernet_register(struct net *net,
- struct nf_conntrack_l3proto *proto)
+ const struct nf_conntrack_l3proto *proto)
{
if (nf_conntrack_default_on == 0)
return 0;
@@ -271,7 +271,7 @@ void nf_ct_l3proto_unregister(struct nf_conntrack_l3proto *proto)
EXPORT_SYMBOL_GPL(nf_ct_l3proto_unregister);
void nf_ct_l3proto_pernet_unregister(struct net *net,
- struct nf_conntrack_l3proto *proto)
+ const struct nf_conntrack_l3proto *proto)
{
/*
* nf_conntrack_default_on *might* have registered hooks.
@@ -286,7 +286,7 @@ void nf_ct_l3proto_pernet_unregister(struct net *net,
EXPORT_SYMBOL_GPL(nf_ct_l3proto_pernet_unregister);
static struct nf_proto_net *nf_ct_l4proto_net(struct net *net,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
if (l4proto->get_net_proto) {
/* statically built-in protocols use static per-net */
@@ -301,7 +301,7 @@ static struct nf_proto_net *nf_ct_l4proto_net(struct net *net,
static
int nf_ct_l4proto_register_sysctl(struct net *net,
struct nf_proto_net *pn,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
int err = 0;
@@ -325,7 +325,7 @@ int nf_ct_l4proto_register_sysctl(struct net *net,
static
void nf_ct_l4proto_unregister_sysctl(struct net *net,
struct nf_proto_net *pn,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
#ifdef CONFIG_SYSCTL
if (pn->ctl_table_header != NULL)
@@ -395,7 +395,7 @@ int nf_ct_l4proto_register_one(struct nf_conntrack_l4proto *l4proto)
EXPORT_SYMBOL_GPL(nf_ct_l4proto_register_one);
int nf_ct_l4proto_pernet_register_one(struct net *net,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
int ret = 0;
struct nf_proto_net *pn = NULL;
@@ -420,7 +420,7 @@ int nf_ct_l4proto_pernet_register_one(struct net *net,
}
EXPORT_SYMBOL_GPL(nf_ct_l4proto_pernet_register_one);
-static void __nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *l4proto)
+static void __nf_ct_l4proto_unregister_one(const struct nf_conntrack_l4proto *l4proto)
{
BUG_ON(l4proto->l3proto >= ARRAY_SIZE(nf_ct_protos));
@@ -433,7 +433,7 @@ static void __nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *l4proto)
&nf_conntrack_l4proto_generic);
}
-void nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *l4proto)
+void nf_ct_l4proto_unregister_one(const struct nf_conntrack_l4proto *l4proto)
{
mutex_lock(&nf_ct_proto_mutex);
__nf_ct_l4proto_unregister_one(l4proto);
@@ -444,7 +444,7 @@ void nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *l4proto)
EXPORT_SYMBOL_GPL(nf_ct_l4proto_unregister_one);
void nf_ct_l4proto_pernet_unregister_one(struct net *net,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
struct nf_proto_net *pn = nf_ct_l4proto_net(net, l4proto);
diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
index 400e9ae..ca760b9 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -401,7 +401,7 @@ static int cttimeout_default_set(struct net *net, struct sock *ctnl,
static int
cttimeout_default_fill_info(struct net *net, struct sk_buff *skb, u32 portid,
u32 seq, u32 type, int event,
- struct nf_conntrack_l4proto *l4proto)
+ const struct nf_conntrack_l4proto *l4proto)
{
struct nlmsghdr *nlh;
struct nfgenmsg *nfmsg;
^ permalink raw reply related
* [PATCH 0/1] constify nf_conntrack_l3/4proto parameters
From: Julia Lawall @ 2017-07-29 19:23 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: bhumirks, kernel-janitors, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel
When a nf_conntrack_l3/4proto parameter is not on the left hand side
of an assignment, its address is not taken, and it is not passed to a
function that may modify its fields, then it can be declared as const.
This change is useful from a documentation point of view, and can
possibly facilitate making some nf_conntrack_l4proto structures const
subsequently.
Done with the help of Coccinelle. The following semantic patch shows
the nf_conntrack_l4proto case.
// <smpl>
virtual update_results
virtual after_start
@initialize:ocaml@
@@
let unsafe = Hashtbl.create 101
let is_unsafe f = Hashtbl.mem unsafe f
let changed = ref false
(* The next three rules relate to the fact that we do not know the type of
void * variables. Fortunately this is only needed on the first iteration,
but it still means that the whole kernel will end up being considered. *)
@has depends on !after_start@
identifier f,l4proto;
position p;
@@
f(...,struct nf_conntrack_l4proto *l4proto,...) { ... }
@others depends on !after_start@
position p != has.p;
identifier f,x;
@@
f(...,void *x,...) { ... }
@script:ocaml@
f << others.f;
@@
changed := true;
Hashtbl.add unsafe f ()
@fpb depends on !update_results disable optional_qualifier exists@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto,fld;
identifier bad : script:ocaml() { is_unsafe(bad) };
assignment operator aop;
expression e;
local idexpression fp;
@@
f(...,struct nf_conntrack_l4proto *l4proto,...)
{
<+...
(
(<+...l4proto...+>) aop e
|
&(<+...l4proto...+>)
|
bad(...,l4proto,...)
|
fp(...,l4proto,...)
|
(<+...e->fld...+>)(...,l4proto,...)
)
...+> }
@script:ocaml@
f << fpb.f;
@@
changed := true;
Hashtbl.add unsafe f ()
@finalize:ocaml depends on !update_results@
tbls << merge.unsafe;
c << merge.changed;
@@
List.iter
(fun t ->
Hashtbl.iter
(fun k v ->
if not (Hashtbl.mem unsafe k) then Hashtbl.add unsafe k ()) t)
tbls;
let changed = List.exists (fun x -> !x) c in
let it = new iteration() in
it#add_virtual_rule After_start;
(if not changed
then it#add_virtual_rule Update_results);
it#register()
@depends on update_results disable optional_qualifier@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto;
@@
f(...,
+ const
struct nf_conntrack_l4proto *l4proto,...) { ... }
@depends on update_results disable optional_qualifier@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto;
type T;
@@
T f(...,
+ const
struct nf_conntrack_l4proto *l4proto,...);
// </smpl>
---
include/net/netfilter/nf_conntrack_l3proto.h | 6 +++---
include/net/netfilter/nf_conntrack_l4proto.h | 8 ++++----
include/net/netfilter/nf_conntrack_timeout.h | 2 +-
net/netfilter/nf_conntrack_core.c | 8 ++++----
net/netfilter/nf_conntrack_netlink.c | 6 +++---
net/netfilter/nf_conntrack_proto.c | 20 ++++++++++----------
net/netfilter/nfnetlink_cttimeout.c | 2 +-
7 files changed, 26 insertions(+), 26 deletions(-)
^ permalink raw reply
* [PATCH] mv643xx_eth: fix of_irq_to_resource() error check
From: Sergei Shtylyov @ 2017-07-29 19:18 UTC (permalink / raw)
To: Sebastian Hesselbarth, netdev; +Cc: Thomas Petazzoni, Sergei Shtylyov
[-- Attachment #1: mv643xx_eth-fix-of_irq_to_resource-error-check.patch --]
[-- Type: text/plain, Size: 1023 bytes --]
of_irq_to_resource() has recently been fixed to return negative error #'s
along with 0 in case of failure, however the Marvell MV643xx Ethernet
driver still only regards 0 as invalid IRQ -- fix it up.
Fixes: 7a4228bbff76 ("of: irq: use of_irq_get() in of_irq_to_resource()")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/drivers/net/ethernet/marvell/mv643xx_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ net/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2734,7 +2734,7 @@ static int mv643xx_eth_shared_of_add_por
ppd.shared = pdev;
memset(&res, 0, sizeof(res));
- if (!of_irq_to_resource(pnp, 0, &res)) {
+ if (of_irq_to_resource(pnp, 0, &res) <= 0) {
dev_err(&pdev->dev, "missing interrupt on %s\n", pnp->name);
return -EINVAL;
}
^ permalink raw reply
* Re: [pull request][net V2 00/14] Mellanox, mlx5 fixes 2017-07-27
From: David Miller @ 2017-07-29 18:29 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170727135617.18559-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 27 Jul 2017 16:56:03 +0300
> This series contains some misc fixes to the mlx5 driver.
>
> Please pull and let me know if there's any problem.
>
> V1->V2:
> - removed redundant braces
>
> for -stable:
...
> I hope this is not too much, but most of the patches do apply cleanly on -stable.
Pulled and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net v2] team: use a larger struct for mac address
From: David Miller @ 2017-07-29 18:26 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, andreyknvl, jiri
In-Reply-To: <20170726222207.5922-2-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 26 Jul 2017 15:22:07 -0700
> IPv6 tunnels use sizeof(struct in6_addr) as dev->addr_len,
> but in many places especially bonding, we use struct sockaddr
> to copy and set mac addr, this could lead to stack out-of-bounds
> access.
>
> Fix it by using a larger address storage like bonding.
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net v2] net: check dev->addr_len for dev_set_mac_address()
From: David Miller @ 2017-07-29 18:25 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, andreyknvl, jiri
In-Reply-To: <20170726222207.5922-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 26 Jul 2017 15:22:06 -0700
> Historically, dev_ifsioc() uses struct sockaddr as mac
> address definition, this is why dev_set_mac_address()
> accepts a struct sockaddr pointer as input but now we
> have various types of mac addresse whose lengths
> are up to MAX_ADDR_LEN, longer than struct sockaddr,
> and saved in dev->addr_len.
>
> It is too late to fix dev_ifsioc() due to API
> compatibility, so just reject those larger than
> sizeof(struct sockaddr), otherwise we would read
> and use some random bytes from kernel stack.
>
> Fortunately, only a few IPv6 tunnel devices have addr_len
> larger than sizeof(struct sockaddr) and they don't support
> ndo_set_mac_addr(). But with team driver, in lb mode, they
> can still be enslaved to a team master and make its mac addr
> length as the same.
>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net/smc: get rid of unsafe_global_rkey
From: David Miller @ 2017-07-29 18:23 UTC (permalink / raw)
To: ubraun
Cc: hch, netdev, linux-rdma, linux-s390, jwi, schwidefsky,
heiko.carstens, raspl
In-Reply-To: <20170728115622.17247-1-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Fri, 28 Jul 2017 13:56:12 +0200
> The smc code uses the unsafe_global_rkey, exposing all memory for
> remote reads and writes once a connection is established.
> Here is now a patch series to get rid of unsafe_global_rkey usage.
> Main idea is to switch to SG-logic and separate memory regions for RMBs.
Series applied, thanks.
^ permalink raw reply
* [PATCH] net-next: stmmac: dwmac-sun8i: fix of_table.cocci warnings
From: Julia Lawall @ 2017-07-29 15:54 UTC (permalink / raw)
To: Corentin Labbe
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, icenowy-h8G6r0blFSE,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe,
kbuild-all-JC7UmRfGjtg
Make sure (of/i2c/platform)_device_id tables are NULL terminated
Generated by: scripts/coccinelle/misc/of_table.cocci
Fixes: d5dbe1976d52 ("net-next: stmmac: dwmac-sun8i: choose internal PHY via compatible")
CC: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Fengguang Wu <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
url: https://github.com/0day-ci/linux/commits/Corentin-Labbe/dt-bindings-net-add-compatible-for-internal-sun8i-h3-sun8i-v3s-PHYs/20170729-174950
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
dwmac-sun8i.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -892,6 +892,7 @@ static int sun8i_dwmac_probe(struct plat
static const struct of_device_id internal_phys[] = {
{ .compatible = "allwinner,sun8i-h3-ephy" },
{ .compatible = "allwinner,sun8i-v3s-ephy" },
+ {},
};
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v1 5/5] wave: Added basic version of TCP Wave
From: Stephen Hemminger @ 2017-07-29 15:32 UTC (permalink / raw)
To: Natale Patriciello
Cc: David S . Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, Ahmed Said,
Francesco Zampognaro, Cesare Roseti
In-Reply-To: <20170728195919.10099-6-natale.patriciello@gmail.com>
On Fri, 28 Jul 2017 21:59:19 +0200
Natale Patriciello <natale.patriciello@gmail.com> wrote:
> +
> +#define WAVE_DEBUG 1
> +
> +#ifdef WAVE_DEBUG
> + #define DBG(msg ...) printk(KERN_DEBUG "WAVE_DEBUG: " msg)
> +#else
> + static inline void DBG(const char *msg, ...) { }
> +#endif
> +
Don't reinvent your own debug macros.
Use standard pr_debug instead.
+
+ if (ca->history != 0)
+ kfree(ca->history);
First, off the comparison should be with NULL not 0.
Secondly, kfree already does the right thing with kfree(NULL).
+ /* Usually the burst end is also reflected in the rs->delivered
+ * variable. If this is not the case, and such variable is
+ * behind just for 1 segment, then do this experimental thing
+ * to re-allineate the burst with the rs->delivered variable.
+ * In the majority of cases, we went out of allineation because
+ * of a tail loss probe. */
Put the last */ in column with other parts of block.
* of a tail loss probe.
*/
^ permalink raw reply
* Re: [PATCH] ss: Enclose IPv6 address in brackets
From: Stephen Hemminger @ 2017-07-29 15:26 UTC (permalink / raw)
To: Florian Lehner; +Cc: netdev
In-Reply-To: <fc81757c-8dbb-dbed-7a24-7011cb8bb9e0@der-flo.net>
On Sat, 29 Jul 2017 14:29:10 +0200
Florian Lehner <dev@der-flo.net> wrote:
> This patch adds support for RFC2732 IPv6 address format with brackets
> for the tool ss. So output for ss changes from
> 2a00:1450:400a:804::200e:443 to [2a00:1450:400a:804::200e]:443 for IPv6
> addresses with attached port number.
>
> Signed-off-by: Lehner Florian <dev@der-flo.net>
> ---
This is the right solution but it might break someone parsing the output of ss
command. Will apply it anyway unless someone has an objection.
^ permalink raw reply
* Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open
From: Florian Fainelli @ 2017-07-29 15:18 UTC (permalink / raw)
To: Mason, Mans Rullgard; +Cc: Marc Gonzalez, David S. Miller, netdev, Linux ARM
In-Reply-To: <f04a0cba-6c09-e9e4-f2d1-d8b2a7e276c9@free.fr>
On 07/29/2017 05:02 AM, Mason wrote:
> On 29/07/2017 13:24, Måns Rullgård wrote:
>
>> Until you figure out why it's getting stuck, we can't be sure
>> it isn't caused by something that could trigger at any time.
> Would you take a look at it, if I can reproduce on tango4?
>
> I have identified a 100% reproducible flaw.
> I have proposed a work-around that brings this down to 0
> (tested 1000 cycles of link up / ping / link down).
Can you also try to get help from your HW resources to eventually help
you find out what is going on here? If anybody has access to that it
would be you.
>
> In my opinion, upstream should consider this work-around
> for inclusion. I'd like to hear David's and Florian's
> opinion on the topic. It's always a pain to maintain
> out-of-tree patches.
I have to agree with Mans here that the commit message explanation is
not good enough to understand how the RX path is hosed after a call to
ndo_stop() it would be good, both for you and for the people maintaining
this driver to understand what happens exactly so the fix is correct,
understood and maintainable. The patch itself looks reasonable with the
limited description given, but it's the description itself that needs
changing. BTW, this should probably come with a Fixes: tag to identify
which commit (presumably the one introducing the driver) is being fixed.
--
Florian
^ permalink raw reply
* Re: [PATCH net] ipv6: no need to return rt->dst.error if it is not null entry.
From: David Ahern @ 2017-07-29 14:41 UTC (permalink / raw)
To: Roopa Prabhu, David Miller; +Cc: Cong Wang, Hangbin Liu, network dev
In-Reply-To: <CAJieiUiqFTAuPpUZF1_v7fbfGPiqdj+wagKwUKbvtfUJognT1w@mail.gmail.com>
On 7/28/17 1:52 PM, Roopa Prabhu wrote:
> On Fri, Jul 28, 2017 at 10:39 AM, David Ahern <dsahern@gmail.com> wrote:
>> IPv4 does not have the notion of null_entry or prohibit route entries
>> which makes IPv4 and IPv6 inconsistent - something we really need to be
>> avoiding from a user experience.
>>
>> We have the following cases:
>>
>> # ip -4 rule add to 172.16.60.0/24 prohibit
>> # ip -4 route add prohibit 172.16.50.0/24
>> # ip -6 rule add to 6000::/120 prohibit
>> # ip -6 route add prohibit 5000::/120
>>
>>
>> Behavior before Roopa's patch set:
>> Rule match:
>> # ip ro get 172.16.60.1
>> RTNETLINK answers: Permission denied
>>
>> # ip -6 ro get 6000::1
>> prohibit 6000::1 from :: dev lo proto kernel src 2001:db8::3 metric
>> 4294967295 error -13 pref medium
>>
>> Route match:
>> # ip ro get 172.16.50.1
>> RTNETLINK answers: Permission denied
>>
>> # ip -6 ro get 5000::1
>> prohibit 5000::1 from :: dev lo table red src 2001:db8::3 metric
>> 1024 error -13 pref medium
>>
>>
>> Behavior after Roopa's patch set:
>> Rule match:
>> # ip ro get 172.16.60.1
>> RTNETLINK answers: Permission denied
>>
>> # ip -6 ro get 6000::1
>> RTNETLINK answers: Permission denied
>>
>> Route match:
>> # ip ro get 172.16.50.1
>> RTNETLINK answers: Permission denied
>>
>> # ip -6 ro get 5000::1
>> RTNETLINK answers: Permission denied
>>
>>
>> So Roopa's fibmatch patches brings consistency between IPv4 and IPv6 at
>> the cost of breaking backwards compatibility for IPv6 when the prohibit
>> or blackhole routes are hit.
>>
>> If that is not acceptable, then let's wrap the change in 'if (fibmatch)'
>> so that when fibmatch is requested we have consistency between IPv4 and
>> IPv6 when it is set.
>
>
> David, Thanks for listing all the cases and options.
>
> for the route match fibmatch case, if a prohibit route entry exists
> (added by user), I was hoping fibmatch can return that entry...
>
> # ip -6 ro get fibmatch 5000::1
> prohibit 5000::1 from :: dev lo
>
> because the semantics of fibmatch is to return the matching route
> entry if exists.
> I am assuming that is possible with appropriate checks around the
> dst.error check for fibmatch. what do you say ?
> I need to verify if this can work for ipv4 the same way.
>
Routes such as prohibit, blackhole and unreachable cause
fib_table_lookup to return an error (see the fib_props reference in
fib_table_lookup) and the IPv4 code does not generate an rtable for
them. IMO it does not make sense to complicate the general IPv4 lookup
code to create an rtable for these 'special' routes just for the
fibmatch getroute case. Furthermore, I think consistency between IPv4
and IPv6 is important from a programmability perspective which is what
we have now.
DaveM: as I outlined above, Roopa's fibmatch patches caused a change in
user behavior in IPv6 getroute for prohibit, blackhole and unreachable
route entries. Opinions on whether we should limit that new behavior to
just the fibmatch lookup in which case a patch is needed or take the new
behavior and consistency in which case nothing is needed?
^ permalink raw reply
* Re: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: Neal Cardwell @ 2017-07-29 14:04 UTC (permalink / raw)
To: maowenan
Cc: Netdev, David Miller, Yuchung Cheng, Nandita Dukkipati,
weiyongjun (A), Chenweilong, Wangkefeng (Kevin)
In-Reply-To: <F95AC9340317A84688A5F0DF0246F3F2029326B6@DGGEMI512-MBX.china.huawei.com>
On Fri, Jul 28, 2017 at 9:39 PM, maowenan <maowenan@huawei.com> wrote:
> [Mao Wenan]ok, We have reproduced this issue with packetdrill yesterday,
> there is no the same issue when TLP send new data packet, RTO will be fired and
> retransmit packet.
That's great to hear that you were able to reproduce this with
packetdrill. Would you be able to share the packetdrill scripts that
reproduce your issues? I would like to make sure our proposed patch
addresses your scenarios as well.
thanks,
neal
^ 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