* Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
From: Jamal Hadi Salim @ 2018-07-25 12:27 UTC (permalink / raw)
To: Paolo Abeni, Cong Wang
Cc: Linux Kernel Network Developers, Jiri Pirko, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David Miller
In-Reply-To: <6a9fd3c8f861c203c7e12a2a2e477796c5e093d5.camel@redhat.com>
On 25/07/18 04:29 AM, Paolo Abeni wrote:
> On Tue, 2018-07-24 at 13:50 -0700, Cong Wang wrote:
[..]
>>> I fail to understand why overlimit is increased in your case
>>> here. I guess you want to increase 'drops' instead.
>>
>> Hmm, actually the current mirred code increases overlimit too.
>> But I still don't think it makes sense.
>
> Yep, I chose to increment 'overlimits' to preserve the current mirred
> semantic.
>
> AFAICS, that was first introduced with:
>
> commit 8919bc13e8d92c5b082c5c0321567383a071f5bc
> Author: Jamal Hadi Salim <jhs@mojatatu.com>
> Date: Mon Aug 15 05:25:40 2011 +0000
>
> net_sched: fix port mirror/redirect stats reporting
>
> Likely increasing 'drops' would be "better", but I'm unsure we can
> change this established behavior without affecting some user.
>
Those changes were there from the beginning (above patch did
not introduce them).
IIRC, the reason was to distinguish between policy intended
drops and drops because of errors.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue
From: Yafang Shao @ 2018-07-25 13:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Eric Dumazet, netdev, LKML
In-Reply-To: <047bc12f-9eb5-e512-10c5-6334c494c77e@gmail.com>
On Wed, Jul 25, 2018 at 9:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 07/25/2018 06:06 AM, Yafang Shao wrote:
>> LINUX_MIB_OFOPRUNED is used to count how many times ofo queue is pruned,
>> but sometimes we want to know how many packets are pruned from this queue,
>> that could help us to track the dropped packets.
>>
>> As LINUX_MIB_OFOPRUNED is a useful event for us, so I introduce a new
>> SNMP counter LINUX_MIB_OFOPRUNEDROP, which could be showed in netstat as
>> OfoPruneDrop.
>
>
> Okay, but why tracking number of skbs that are removed ?
>
Because we want to know why packets were dropped.
If that could be show in netstat, we could easily find that it is
dropped due to ofo prune.
> Skb can contain many segments (because of GRO and TCP coalescing)
>
> So your claim of tracking dropped packets is ill defined.
>
> Also I prefer having net tree being merged into net-next, since your patch would
> add a merge conflict.
>
>
^ permalink raw reply
* Re: [PATCH net-next v3 2/5] net/sched: user-space can't set unknown tcfa_action values
From: Jiri Pirko @ 2018-07-25 12:26 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jamal Hadi Salim, Cong Wang, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller
In-Reply-To: <5710761e4915690523906201bcb30987162a4fd2.1532437050.git.pabeni@redhat.com>
Tue, Jul 24, 2018 at 10:06:40PM CEST, pabeni@redhat.com wrote:
>Currently, when initializing an action, the user-space can specify
>and use arbitrary values for the tcfa_action field. If the value
>is unknown by the kernel, is implicitly threaded as TC_ACT_UNSPEC.
>
>This change explicitly checks for unknown values at action creation
>time, and explicitly convert them to TC_ACT_UNSPEC. No functional
>changes are introduced, but this will allow introducing tcfa_action
>values not exposed to user-space in a later patch.
>
>Note: we can't use the above to hide TC_ACT_REDIRECT from user-space,
>as the latter is already part of uAPI.
>
>Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>---
> include/uapi/linux/pkt_cls.h | 6 ++++--
> net/sched/act_api.c | 10 +++++++++-
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
>diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>index c4262d911596..c8a24861d4c8 100644
>--- a/include/uapi/linux/pkt_cls.h
>+++ b/include/uapi/linux/pkt_cls.h
>@@ -45,6 +45,7 @@ enum {
> * the skb and act like everything
> * is alright.
> */
>+#define TC_ACT_VALUE_MAX TC_ACT_TRAP
>
> /* There is a special kind of actions called "extended actions",
> * which need a value parameter. These have a local opcode located in
>@@ -55,11 +56,12 @@ enum {
> #define __TC_ACT_EXT_SHIFT 28
> #define __TC_ACT_EXT(local) ((local) << __TC_ACT_EXT_SHIFT)
> #define TC_ACT_EXT_VAL_MASK ((1 << __TC_ACT_EXT_SHIFT) - 1)
>-#define TC_ACT_EXT_CMP(combined, opcode) \
>- (((combined) & (~TC_ACT_EXT_VAL_MASK)) == opcode)
>+#define TC_ACT_EXT_OPCODE(combined) ((combined) & (~TC_ACT_EXT_VAL_MASK))
>+#define TC_ACT_EXT_CMP(combined, opcode) (TC_ACT_EXT_OPCODE(combined) == opcode)
>
> #define TC_ACT_JUMP __TC_ACT_EXT(1)
> #define TC_ACT_GOTO_CHAIN __TC_ACT_EXT(2)
>+#define TC_ACT_EXT_OPCODE_MAX TC_ACT_GOTO_CHAIN
>
> /* Action type identifiers*/
> enum {
>diff --git a/net/sched/act_api.c b/net/sched/act_api.c
>index 24b5534967fe..5044f4809b37 100644
>--- a/net/sched/act_api.c
>+++ b/net/sched/act_api.c
>@@ -798,6 +798,7 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> char act_name[IFNAMSIZ];
> struct nlattr *tb[TCA_ACT_MAX + 1];
> struct nlattr *kind;
>+ int opcode;
> int err;
>
> if (name == NULL) {
>@@ -884,7 +885,8 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> if (err != ACT_P_CREATED)
> module_put(a_o->owner);
>
>- if (TC_ACT_EXT_CMP(a->tcfa_action, TC_ACT_GOTO_CHAIN)) {
>+ opcode = TC_ACT_EXT_OPCODE(a->tcfa_action);
>+ if (opcode == TC_ACT_GOTO_CHAIN) {
> err = tcf_action_goto_chain_init(a, tp);
> if (err) {
> struct tc_action *actions[] = { a, NULL };
>@@ -898,6 +900,12 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> if (a->tcfa_action == TC_ACT_REDIRECT) {
> net_warn_ratelimited("TC_ACT_REDIRECT can't be used directly");
> a->tcfa_action = TC_ACT_UNSPEC;
>+ } else if ((!opcode && a->tcfa_action > TC_ACT_VALUE_MAX) ||
>+ (opcode && opcode > TC_ACT_EXT_OPCODE_MAX &&
>+ a->tcfa_action != TC_ACT_UNSPEC)) {
>+ net_warn_ratelimited("invalid %d action value",
>+ a->tcfa_action);
>+ a->tcfa_action = TC_ACT_UNSPEC;
Maybe this could be a separate helper function?
Also, the warn might go along with extack to user too.
Otherwise, this looks fine to me.
> }
>
> return a;
>--
>2.17.1
>
^ permalink raw reply
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Eran Ben Elisha @ 2018-07-25 12:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, Jiri Pirko, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <20180724125135.19121f1f@cakuba.netronome.com>
On 7/24/2018 10:51 PM, Jakub Kicinski wrote:
>>>
>>> The devlink params haven't been upstream even for a full cycle and
>>> already you guys are starting to use them to configure standard
>>> features like queuing.
>>
>> We developed the devlink params in order to support non-standard
>> configuration only. And for non-standard, there are generic and vendor
>> specific options.
>
> I thought it was developed for performing non-standard and possibly
> vendor specific configuration. Look at DEVLINK_PARAM_GENERIC_* for
> examples of well justified generic options for which we have no
> other API. The vendor mlx4 options look fairly vendor specific if you
> ask me, too.
>
> Configuring queuing has an API. The question is it acceptable to enter
> into the risky territory of controlling offloads via devlink parameters
> or would we rather make vendors take the time and effort to model
> things to (a subset) of existing APIs. The HW never fits the APIs
> perfectly.
I understand what you meant here, I would like to highlight that this
mechanism was not meant to handle SRIOV, Representors, etc.
The vendor specific configuration suggested here is to handle a
congestion state in Multi Host environment (which includes PF and
multiple VFs per host), where one host is not aware to the other hosts,
and each is running on its own pci/driver. It is a device working mode
configuration.
This couldn't fit into any existing API, thus creating this vendor
specific unique API is needed.
>
>> The queuing model is a standard. However here we are configuring the
>> outbound PCIe buffers on the receive path from NIC port toward the
>> host(s) in Single / MultiHost environment.
>
> That's why we have PF representors.
>
>> (You can see the driver processing based on this param as part of the RX
>> patch for the marked option here https://patchwork.ozlabs.org/patch/945998/)
>>
>>> I know your HW is not capable of doing full RED offload, it's a
>>> snowflake.
>>
>> The algorithm which is applied here for the drop option is not the core
>> of this feature.
>>
>>> You tell us you're doing custom DCB configuration hacks on
>>> one side (previous argument we had) and custom devlink parameter
>>> configuration hacks on PCIe.
>>>
>>> Perhaps the idea that we're trying to use the existing Linux APIs for
>>> HW configuration only applies to forwarding behaviour.
>>
>> Hopefully I explained above well why it is not related.
>
> Sure ;)
>
^ permalink raw reply
* Re: [PATCH net-next v3 3/5] tc/act: remove unneeded RCU lock in action callback
From: Jiri Pirko @ 2018-07-25 12:32 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jamal Hadi Salim, Cong Wang, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller
In-Reply-To: <b7bda0b303bed5bad1535bd917ea99789cd1db9e.1532437050.git.pabeni@redhat.com>
Tue, Jul 24, 2018 at 10:06:41PM CEST, pabeni@redhat.com wrote:
>Each lockless action currently does its own RCU locking in ->act().
>This is allows using plain RCU accessor, even if the context
>is really RCU BH.
>
>This change drops the per action RCU lock, replace the accessors
>with _bh variant, cleans up a bit the surronding code and documents
s/surronding/surrounding/
>the RCU status in the relevant header.
>No functional nor performance change is intended.
>
>The goal of this patch is clarifying that the RCU critical section
>used by the tc actions extends up to the classifier's caller.
>
>v1 -> v2:
> - preserve rcu lock in act_bpf: it's needed by eBPF helpers,
> as pointed out by Daniel
>
>Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue
From: Eric Dumazet @ 2018-07-25 13:55 UTC (permalink / raw)
To: Yafang Shao, Eric Dumazet; +Cc: David Miller, Eric Dumazet, netdev, LKML
In-Reply-To: <CALOAHbCC=oWgzcA=VhkXq0rVLBa5_TvtbKtTqESGrgxvYTtH6w@mail.gmail.com>
On 07/25/2018 06:40 AM, Yafang Shao wrote:
>
> Because we want to know why packets were dropped.
> If that could be show in netstat, we could easily find that it is
> dropped due to ofo prune.
We have a counter already for these events : LINUX_MIB_OFOPRUNED
You want to add another counter tracking number of _skbs_,
which has no precise value for user,
given each skb can contain a variable number of _packets_.
^ permalink raw reply
* Re: [PATCH net-next 1/2] be2net: Collect the transmit queue data in Tx timeout
From: Suresh Kumar Reddy Reddygari @ 2018-07-25 12:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20180723.112313.949079144194651345.davem@davemloft.net>
On Mon, Jul 23, 2018 at 11:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Suresh Reddy <suresh.reddy@broadcom.com>
> Date: Mon, 23 Jul 2018 10:25:23 -0400
>
>> Driver dumps tx_queue, tx_compl, pending SKBs information in tx_timeout.
>> This debug data used to idenfiy the cause of the time out.
>>
>> Also reset Lancer chip in tx_timeout.
>>
>> Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
>
> The purpose of the tx timeout NDO operation is to do whatever is
> necessary to handle the TX timeout.
>
> Outputting debugging information is useful, but is secondary.
>
> I see that you do reset the Lancer, but that is far from what really
> needs to happen here.
>
> When you get a TX timeout, the hardware is not processing TX ring
> entries, nor signalling completion any longer.
>
> Therefore the only way to get things going again is to reset all of
> the TX side data structure and logic. This means shutting down the TX
> engine, freeing up all of the TX SKBs in the ring, resetting the TX
> ring software state, and then finally reprogramming the head/tail
> pointer registers and re-enabling TX DMA processing.
The current patch does recover from a TX-timeout by resetting the chip itself
that *includes* resetting the TX block. Freeing up TX SKBs and rings and
re-creating/registering them is also being done.
Now, this recovery is not supported in BE3 and Skyhawk NICs but is supported
in Lancer NICs. That's why this patch performs recovery in the case of
Lancer NICs
but only gathers diagnostic information in the case of BE3 and Skyhawk NICs.
Regards,
Suresh.
^ permalink raw reply
* Re: [PATCH net-next] tcp: add SNMP counter for the number of packets pruned from ofo queue
From: Yafang Shao @ 2018-07-25 13:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Eric Dumazet, netdev, LKML
In-Reply-To: <096a8a2f-ea32-2107-b2af-c246450cc3b9@gmail.com>
On Wed, Jul 25, 2018 at 9:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 07/25/2018 06:40 AM, Yafang Shao wrote:
>
>>
>> Because we want to know why packets were dropped.
>> If that could be show in netstat, we could easily find that it is
>> dropped due to ofo prune.
>
>
> We have a counter already for these events : LINUX_MIB_OFOPRUNED
>
> You want to add another counter tracking number of _skbs_,
> which has no precise value for user,
> given each skb can contain a variable number of _packets_.
>
Got it.
But with LINUX_MIB_OFOPRUNED, we only know tcp_prune_ofo_queue is
called, but have no idea how many skbs are dropped.
Thanks
Yafang
^ permalink raw reply
* [PATCH net-next] l2tp: remove ->recv_payload_hook
From: Guillaume Nault @ 2018-07-25 12:53 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
The tunnel reception hook is only used by l2tp_ppp for skipping PPP
framing bytes. This is a session specific operation, but once a PPP
session sets ->recv_payload_hook on its tunnel, all frames received by
the tunnel will enter pppol2tp_recv_payload_hook(), including those
targeted at Ethernet sessions (an L2TPv3 tunnel can multiplex PPP and
Ethernet sessions).
So this mechanism is wrong, and uselessly complex. Let's just move this
functionality to the pppol2tp rx handler and drop ->recv_payload_hook.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
---
net/l2tp/l2tp_core.c | 16 ++++------------
net/l2tp/l2tp_core.h | 3 +--
net/l2tp/l2tp_ip.c | 2 +-
net/l2tp/l2tp_ip6.c | 3 +--
net/l2tp/l2tp_ppp.c | 33 +++++++++++----------------------
5 files changed, 18 insertions(+), 39 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index c8fc0f7f0b4b..d10f4ed52d92 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -619,7 +619,7 @@ static int l2tp_recv_data_seq(struct l2tp_session *session, struct sk_buff *skb)
*/
void l2tp_recv_common(struct l2tp_session *session, struct sk_buff *skb,
unsigned char *ptr, unsigned char *optr, u16 hdrflags,
- int length, int (*payload_hook)(struct sk_buff *skb))
+ int length)
{
struct l2tp_tunnel *tunnel = session->tunnel;
int offset;
@@ -740,13 +740,6 @@ void l2tp_recv_common(struct l2tp_session *session, struct sk_buff *skb,
__skb_pull(skb, offset);
- /* If caller wants to process the payload before we queue the
- * packet, do so now.
- */
- if (payload_hook)
- if ((*payload_hook)(skb))
- goto discard;
-
/* Prepare skb for adding to the session's reorder_q. Hold
* packets for max reorder_timeout or 1 second if not
* reordering.
@@ -800,8 +793,7 @@ static int l2tp_session_queue_purge(struct l2tp_session *session)
* Returns 1 if the packet was not a good data packet and could not be
* forwarded. All such packets are passed up to userspace to deal with.
*/
-static int l2tp_udp_recv_core(struct l2tp_tunnel *tunnel, struct sk_buff *skb,
- int (*payload_hook)(struct sk_buff *skb))
+static int l2tp_udp_recv_core(struct l2tp_tunnel *tunnel, struct sk_buff *skb)
{
struct l2tp_session *session = NULL;
unsigned char *ptr, *optr;
@@ -892,7 +884,7 @@ static int l2tp_udp_recv_core(struct l2tp_tunnel *tunnel, struct sk_buff *skb,
goto error;
}
- l2tp_recv_common(session, skb, ptr, optr, hdrflags, length, payload_hook);
+ l2tp_recv_common(session, skb, ptr, optr, hdrflags, length);
l2tp_session_dec_refcount(session);
return 0;
@@ -921,7 +913,7 @@ int l2tp_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
l2tp_dbg(tunnel, L2TP_MSG_DATA, "%s: received %d bytes\n",
tunnel->name, skb->len);
- if (l2tp_udp_recv_core(tunnel, skb, tunnel->recv_payload_hook))
+ if (l2tp_udp_recv_core(tunnel, skb))
goto pass_up;
return 0;
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index a5c09d3a5698..d85fde793a8c 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -180,7 +180,6 @@ struct l2tp_tunnel {
struct net *l2tp_net; /* the net we belong to */
refcount_t ref_count;
- int (*recv_payload_hook)(struct sk_buff *skb);
void (*old_sk_destruct)(struct sock *);
struct sock *sock; /* Parent socket */
int fd; /* Parent fd, if tunnel socket
@@ -232,7 +231,7 @@ int l2tp_session_delete(struct l2tp_session *session);
void l2tp_session_free(struct l2tp_session *session);
void l2tp_recv_common(struct l2tp_session *session, struct sk_buff *skb,
unsigned char *ptr, unsigned char *optr, u16 hdrflags,
- int length, int (*payload_hook)(struct sk_buff *skb));
+ int length);
int l2tp_udp_encap_recv(struct sock *sk, struct sk_buff *skb);
void l2tp_session_set_header_len(struct l2tp_session *session, int version);
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index a9c05b2bc1b0..0bc39cc20a3f 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -165,7 +165,7 @@ static int l2tp_ip_recv(struct sk_buff *skb)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, ptr, length);
}
- l2tp_recv_common(session, skb, ptr, optr, 0, skb->len, tunnel->recv_payload_hook);
+ l2tp_recv_common(session, skb, ptr, optr, 0, skb->len);
l2tp_session_dec_refcount(session);
return 0;
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index 672e5b753738..42f828cf62fb 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -178,8 +178,7 @@ static int l2tp_ip6_recv(struct sk_buff *skb)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, ptr, length);
}
- l2tp_recv_common(session, skb, ptr, optr, 0, skb->len,
- tunnel->recv_payload_hook);
+ l2tp_recv_common(session, skb, ptr, optr, 0, skb->len);
l2tp_session_dec_refcount(session);
return 0;
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 9ac02c93df98..000c9829304c 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -183,25 +183,6 @@ static inline struct l2tp_session *pppol2tp_sock_to_session(struct sock *sk)
* Receive data handling
*****************************************************************************/
-static int pppol2tp_recv_payload_hook(struct sk_buff *skb)
-{
- /* Skip PPP header, if present. In testing, Microsoft L2TP clients
- * don't send the PPP header (PPP header compression enabled), but
- * other clients can include the header. So we cope with both cases
- * here. The PPP header is always FF03 when using L2TP.
- *
- * Note that skb->data[] isn't dereferenced from a u16 ptr here since
- * the field may be unaligned.
- */
- if (!pskb_may_pull(skb, 2))
- return 1;
-
- if ((skb->data[0] == PPP_ALLSTATIONS) && (skb->data[1] == PPP_UI))
- skb_pull(skb, 2);
-
- return 0;
-}
-
/* Receive message. This is the recvmsg for the PPPoL2TP socket.
*/
static int pppol2tp_recvmsg(struct socket *sock, struct msghdr *msg,
@@ -248,6 +229,17 @@ static void pppol2tp_recv(struct l2tp_session *session, struct sk_buff *skb, int
if (sk == NULL)
goto no_sock;
+ /* If the first two bytes are 0xFF03, consider that it is the PPP's
+ * Address and Control fields and skip them. The L2TP module has always
+ * worked this way, although, in theory, the use of these fields should
+ * be negociated and handled at the PPP layer. These fields are
+ * constant: 0xFF is the All-Stations Address and 0x03 the Unnumbered
+ * Information command with Poll/Final bit set to zero (RFC 1662).
+ */
+ if (pskb_may_pull(skb, 2) && skb->data[0] == PPP_ALLSTATIONS &&
+ skb->data[1] == PPP_UI)
+ skb_pull(skb, 2);
+
if (sk->sk_state & PPPOX_BOUND) {
struct pppox_sock *po;
@@ -763,9 +755,6 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr,
goto end;
}
- if (tunnel->recv_payload_hook == NULL)
- tunnel->recv_payload_hook = pppol2tp_recv_payload_hook;
-
if (tunnel->peer_tunnel_id == 0)
tunnel->peer_tunnel_id = info.peer_tunnel_id;
--
2.18.0
^ permalink raw reply related
* Re: [PATCH net-next v3 1/5] tc/act: user space can't use TC_ACT_REDIRECT directly
From: Paolo Abeni @ 2018-07-25 12:54 UTC (permalink / raw)
To: Jiri Pirko, Jamal Hadi Salim
Cc: netdev, Cong Wang, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger, David S. Miller
In-Reply-To: <20180725115652.GD2164@nanopsycho>
Hi,
On Wed, 2018-07-25 at 13:56 +0200, Jiri Pirko wrote:
> Tue, Jul 24, 2018 at 10:06:39PM CEST, pabeni@redhat.com wrote:
> > Only cls_bpf and act_bpf can safely use such value. If a generic
> > action is configured by user space to return TC_ACT_REDIRECT,
> > the usually visible behavior is passing the skb up the stack - as
> > for unknown action, but, with complex configuration, more random
> > results can be obtained.
> >
> > This patch forcefully converts TC_ACT_REDIRECT to TC_ACT_UNSPEC
> > at action init time, making the kernel behavior more consistent.
> >
> > v1 -> v3: use TC_ACT_UNSPEC instead of a newly definied act value
> >
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> > net/sched/act_api.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> > index 148a89ab789b..24b5534967fe 100644
> > --- a/net/sched/act_api.c
> > +++ b/net/sched/act_api.c
> > @@ -895,6 +895,11 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
> > }
> > }
> >
> > + if (a->tcfa_action == TC_ACT_REDIRECT) {
> > + net_warn_ratelimited("TC_ACT_REDIRECT can't be used directly");
>
> Can't you push this warning through extack?
>
> But, wouldn't it be more appropriate to fail here? User is passing
> invalid configuration....
Jiri, Jamal, thank you for the feedback.
Please allow me to answer both of you here, since you raised similar
concers.
I thought about rejecting the action, but that change of behavior could
break some users, as currently most kind of invalid tcfa_action values
are simply accepted.
If there is consensus about it, I can simply fail.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace
From: David Ahern @ 2018-07-25 14:06 UTC (permalink / raw)
To: Eric W. Biederman, Cong Wang
Cc: David Miller, Linux Kernel Network Developers, nikita.leshchenko,
Roopa Prabhu, Stephen Hemminger, Ido Schimmel, Jiri Pirko,
Saeed Mahameed, Alexander Aring, linux-wpan, NetFilter, LKML
In-Reply-To: <87muufze8w.fsf@xmission.com>
On 7/25/18 6:33 AM, Eric W. Biederman wrote:
> Cong Wang <xiyou.wangcong@gmail.com> writes:
>
>> On Tue, Jul 24, 2018 at 8:14 AM David Ahern <dsahern@gmail.com> wrote:
>>>
>>> On 7/19/18 11:12 AM, Cong Wang wrote:
>>>> On Thu, Jul 19, 2018 at 9:16 AM David Ahern <dsahern@gmail.com> wrote:
>>>>>
>>>>> Chatting with Nikolay about this and he brought up a good corollary - ip
>>>>> fragmentation. It really is a similar problem in that memory is consumed
>>>>> as a result of packets received from an external entity. The ipfrag
>>>>> sysctls are per namespace with a limit that non-init_net namespaces can
>>>>> not set high_thresh > the current value of init_net. Potential memory
>>>>> consumed by fragments scales with the number of namespaces which is the
>>>>> primary concern with making neighbor tables per namespace.
>>>>
>>>> Nothing new, already discussed:
>>>> https://marc.info/?l=linux-netdev&m=140391416215988&w=2
>>>>
>>>> :)
>>>>
>>>
>>> Neighbor tables, bridge fdbs, vxlan fdbs and ip fragments all consume
>>> local memory resources due to received packets. bridge and vxlan fdb's
>>> are fairly straightforward analogs to neighbor entries; they are per
>>> device with no limits on the number of entries. Fragments have memory
>>> limits per namespace. So neighbor tables are the only ones with this
>>> strict limitation and concern on memory consumption.
>>>
>>> I get the impression there is no longer a strong resistance against
>>> moving the tables to per namespace, but deciding what is the right
>>> approach to handle backwards compatibility. Correct? Changing the
>>> accounting is inevitably going to be noticeable to some use case(s), but
>>> with sysctl settings it is a simple runtime update once the user knows
>>> to make the change.
>>
>> This question definitely should go to Eric Biederman who was against
>> my proposal.
>>
>> Let's add Eric into CC.
>
> Given that the entries are per device and the devices are per-namespace,
> semantically neighbours are already kept in a per-namespace manner. So
> this is all about making the code not honoring global resource limits.
> Making the code not honor gc_thresh3.
>
> Skimming through the code today the default for gc_thresh3 is 1024.
> Which means that we limit the neighbour tables to 1024 entries per
> protocol type.
>
> There are some pretty compelling reasons especially with ipv4 to keep
> the subnet size down. Arp storms are a real thing.
>
> I don't know off the top of my head what the reasons for limiting the
> neighbour table sizes. I would be much more comfortable with a patchset
> like this if we did some research and figured out the reasons why
> we have a global limit. Then changed the code to remove those limits.
>
> When the limits are gone. When the code can support large subnets
> without tuning. We we don't have to worry about someone scanning an all
> addresses in an ipv6 subnet and causing a DOS on working machines.
> I think it is completely appropriate to look to see if something per
> network namespace needs to happen.
>
> So please let's address the limits, not the fact that some specific
> corner case ran into them.
>
> If we are going to neuter gc_thresh3 let's go as far as removing it
> entirely. If we are going to make the neighbour table per something
> let's make it per network device. If we can afford the multiple hash
> tables then a hash table per device is better. Perhaps we want to move
> to rhash tables while we look at this, instead of an old hand grown
> version of resizable hash table.
Given the uses cases with increasing number of devices (> 10,000),
per-device tables will have more problems than per namespace - in
reference to your concern in the last paragraph below.
>
> Unless I misread something all your patchset did is reshuffle code and
> data structures so that gc_thresh3 does not apply accross namespaces.
> That does not feel like it really fixes anything. That just lies to
> people.
This patch set fixes the lie that network namespaces provide complete
isolation when in fact one namespace can evict neighbor entries from
another. An arp storm you are concerned about in one namespace impacts
all containers.
It starts by removing the proliferation of open coded references to
arp_tbl and nd_tbl, moving them behind the existing neigh_find_table.
>From there (patches 14-16) it makes the tables per-namespace and hence
makes the gc_thresh parameters which are per-table now
per-table-per-namespace.
So it removes the global thresholds because the global ones are just
wrong given the meaning of a network namespace and provides the more
appropriate per-namespace limits.
>
> Further unless I misread something you are increasing the number of
> timers to 3 per namespace. If I create create a thousand network
> namespaces that feels like it will hurt system performance overall.
It seems to me the timers are per neighbor entry not table. The per
table ones are for proxies.
^ permalink raw reply
* Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
From: Jiri Pirko @ 2018-07-25 12:57 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jamal Hadi Salim, Cong Wang, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller
In-Reply-To: <3c20787be0fd5d64728ffed46ae0a7dff10d7e05.1532437050.git.pabeni@redhat.com>
Tue, Jul 24, 2018 at 10:06:42PM CEST, pabeni@redhat.com wrote:
>This is similar TC_ACT_REDIRECT, but with a slightly different
>semantic:
>- on ingress the mirred skbs are passed to the target device
>network stack without any additional check not scrubbing.
>- the rcu-protected stats provided via the tcf_result struct
> are updated on error conditions.
>
>This new tcfa_action value is not exposed to the user-space
>and can be used only internally by clsact.
>
>v1 -> v2: do not touch TC_ACT_REDIRECT code path, introduce
> a new action type instead
>
>v2 -> v3:
> - rename the new action value TC_ACT_REINJECT, update the
> helper accordingly
> - take care of uncloned reinjected packets in XDP generic
> hook
>
>Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>---
> include/net/pkt_cls.h | 3 +++
> include/net/sch_generic.h | 19 +++++++++++++++++++
> net/core/dev.c | 6 +++++-
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
>diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
>index 2081e4219f81..36ccfe2a303a 100644
>--- a/include/net/pkt_cls.h
>+++ b/include/net/pkt_cls.h
>@@ -7,6 +7,9 @@
> #include <net/sch_generic.h>
> #include <net/act_api.h>
>
>+/* TC action not accessible from user space */
>+#define TC_ACT_REINJECT (TC_ACT_VALUE_MAX + 1)
>+
> /* Basic packet classifier frontend definitions. */
>
> struct tcf_walker {
>diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
>index 056dc1083aa3..95e81a70f549 100644
>--- a/include/net/sch_generic.h
>+++ b/include/net/sch_generic.h
>@@ -235,6 +235,12 @@ struct tcf_result {
> u32 classid;
> };
> const struct tcf_proto *goto_tp;
>+
>+ /* used by the TC_ACT_REINJECT action */
>+ struct {
>+ bool ingress;
>+ struct gnet_stats_queue *qstats;
>+ };
> };
> };
>
>@@ -1091,4 +1097,17 @@ void mini_qdisc_pair_swap(struct mini_Qdisc_pair *miniqp,
> void mini_qdisc_pair_init(struct mini_Qdisc_pair *miniqp, struct Qdisc *qdisc,
> struct mini_Qdisc __rcu **p_miniq);
>
>+static inline void skb_tc_reinject(struct sk_buff *skb, struct tcf_result *res)
>+{
>+ struct gnet_stats_queue *stats = res->qstats;
>+ int ret;
>+
>+ if (res->ingress)
>+ ret = netif_receive_skb(skb);
>+ else
>+ ret = dev_queue_xmit(skb);
Hmm. "reinject" by the name tells me that the packet should be injected
again. By "inject", I understand beginning of the rx path. However, this
does xmit as well :/ It is a bit misleading. Maybe "reinsert" would
sound better?
>+ if (ret && stats)
>+ qstats_overlimit_inc(res->qstats);
>+}
>+
> #endif
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 14a748ee8cc9..826ec74fe1d9 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -4252,7 +4252,7 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
> /* Reinjected packets coming from act_mirred or similar should
> * not get XDP generic processing.
> */
>- if (skb_cloned(skb))
>+ if (skb_cloned(skb) || skb->tc_redirected)
> return XDP_PASS;
>
> /* XDP packets must be linear and must have sufficient headroom
>@@ -4602,6 +4602,10 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
> __skb_push(skb, skb->mac_len);
> skb_do_redirect(skb);
> return NULL;
>+ case TC_ACT_REINJECT:
>+ /* this does not scrub the packet, and updates stats on error */
>+ skb_tc_reinject(skb, &cl_res);
>+ return NULL;
> default:
> break;
> }
>--
>2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next] l2tp: remove ->recv_payload_hook
From: Guillaume Nault @ 2018-07-25 13:00 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
In-Reply-To: <6a20d71b1acf5a81fd80e06120cb40a06fed1c71.1532523126.git.g.nault@alphalink.fr>
On Wed, Jul 25, 2018 at 02:53:33PM +0200, Guillaume Nault wrote:
> The tunnel reception hook is only used by l2tp_ppp for skipping PPP
> framing bytes. This is a session specific operation, but once a PPP
> session sets ->recv_payload_hook on its tunnel, all frames received by
> the tunnel will enter pppol2tp_recv_payload_hook(), including those
> targeted at Ethernet sessions (an L2TPv3 tunnel can multiplex PPP and
> Ethernet sessions).
>
I forgot to mention that this patch is targeted at net-next because, in
practice, the PPP payload hook is unlikely to corrupt valid Ethernet
frames (the destination MAC address would have to beging with ff:03).
^ permalink raw reply
* Re: [PATCH PATCH net-next 08/18] sctp: whitespace fixes
From: Neil Horman @ 2018-07-25 12:59 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem, ericvh, rminnich, lucho, ralf, jreuter, pablo, kadlec, fw,
alex.aring, stefan, kuznet, yoshfuji, johannes, jhs,
xiyou.wangcong, jiri, vyasevich, marcelo.leitner, trond.myklebust,
anna.schumaker, steffen.klassert, herbert, netdev, v9fs-developer,
linux-hams, ceph-devel, linux-decnet-user, netfilter-devel,
coreteam, linux-wpan, linux-s390
In-Reply-To: <20180724192918.31165-9-sthemmin@microsoft.com>
On Tue, Jul 24, 2018 at 12:29:08PM -0700, Stephen Hemminger wrote:
> Remove blank line at EOF and trailing whitespace.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> net/sctp/Kconfig | 4 ++--
> net/sctp/sm_sideeffect.c | 1 -
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
> index c740b189d4ba..950ecf6e7439 100644
> --- a/net/sctp/Kconfig
> +++ b/net/sctp/Kconfig
> @@ -41,8 +41,8 @@ config SCTP_DBG_OBJCNT
> bool "SCTP: Debug object counts"
> depends on PROC_FS
> help
> - If you say Y, this will enable debugging support for counting the
> - type of objects that are currently allocated. This is useful for
> + If you say Y, this will enable debugging support for counting the
> + type of objects that are currently allocated. This is useful for
> identifying memory leaks. This debug information can be viewed by
> 'cat /proc/net/sctp/sctp_dbg_objcnt'
>
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 298112ca8c06..85d393090238 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -1827,4 +1827,3 @@ static int sctp_cmd_interpreter(enum sctp_event event_type,
> error = -ENOMEM;
> goto out;
> }
> -
> --
> 2.18.0
>
> --
> 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
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
From: Jiri Pirko @ 2018-07-25 12:59 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Paolo Abeni, netdev, Cong Wang, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller,
Shmulik Ladkani
In-Reply-To: <2bf4fbfd-abe2-7d3b-a4f8-42805b7760c5@mojatatu.com>
Wed, Jul 25, 2018 at 02:16:12PM CEST, jhs@mojatatu.com wrote:
[...]
>> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
>> index 2081e4219f81..36ccfe2a303a 100644
>> --- a/include/net/pkt_cls.h
>> +++ b/include/net/pkt_cls.h
>> @@ -7,6 +7,9 @@
>> #include <net/sch_generic.h>
>> #include <net/act_api.h>
>> +/* TC action not accessible from user space */
>> +#define TC_ACT_REINJECT (TC_ACT_VALUE_MAX + 1)
>
>Lets say in the future we add a new opcode.
>Will old kernel, new iproute2 (new value) work?
This is safe. See patch #2.
^ permalink raw reply
* Re: [PATCH net-next 0/2] docs: net: Convert netdev-FAQ to RST
From: Jonathan Corbet @ 2018-07-25 14:14 UTC (permalink / raw)
To: Tobin C. Harding; +Cc: David S. Miller, linux-doc, netdev, linux-kernel
In-Reply-To: <20180725032810.GA6067@eros>
On Wed, 25 Jul 2018 13:28:10 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:
> Since I've already botched it can I ask for guidance here. The problem
> is updating the links means making changes that will cause merge
> conflicts if they go through net-dev tree (since most references are in
> Documentation/*.rst). But we can't go through docs tree either since
> that could lead to merge conflicts later as well.
Merge conflicts are a way of life in Documentation/ - everybody messes
with it. They are usually pretty easy to resolve.
I only see a handful of references to netdev-FAQ.txt in the tree; I would
suggest just making the change and being done with it. There shouldn't be
any need to do a more complicated dance than that.
And to answer your other question, yes of course it's fine (and expected)
for this to go through Dave's tree.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH net-next v3 1/5] tc/act: user space can't use TC_ACT_REDIRECT directly
From: Jiri Pirko @ 2018-07-25 13:03 UTC (permalink / raw)
To: Paolo Abeni
Cc: Jamal Hadi Salim, netdev, Cong Wang, Daniel Borkmann,
Marcelo Ricardo Leitner, Eyal Birger, David S. Miller
In-Reply-To: <5d38822b635a18b102810a14883e65479f3841ab.camel@redhat.com>
Wed, Jul 25, 2018 at 02:54:04PM CEST, pabeni@redhat.com wrote:
>Hi,
>
>On Wed, 2018-07-25 at 13:56 +0200, Jiri Pirko wrote:
>> Tue, Jul 24, 2018 at 10:06:39PM CEST, pabeni@redhat.com wrote:
>> > Only cls_bpf and act_bpf can safely use such value. If a generic
>> > action is configured by user space to return TC_ACT_REDIRECT,
>> > the usually visible behavior is passing the skb up the stack - as
>> > for unknown action, but, with complex configuration, more random
>> > results can be obtained.
>> >
>> > This patch forcefully converts TC_ACT_REDIRECT to TC_ACT_UNSPEC
>> > at action init time, making the kernel behavior more consistent.
>> >
>> > v1 -> v3: use TC_ACT_UNSPEC instead of a newly definied act value
>> >
>> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>> > ---
>> > net/sched/act_api.c | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/net/sched/act_api.c b/net/sched/act_api.c
>> > index 148a89ab789b..24b5534967fe 100644
>> > --- a/net/sched/act_api.c
>> > +++ b/net/sched/act_api.c
>> > @@ -895,6 +895,11 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
>> > }
>> > }
>> >
>> > + if (a->tcfa_action == TC_ACT_REDIRECT) {
>> > + net_warn_ratelimited("TC_ACT_REDIRECT can't be used directly");
>>
>> Can't you push this warning through extack?
>>
>> But, wouldn't it be more appropriate to fail here? User is passing
>> invalid configuration....
>
>Jiri, Jamal, thank you for the feedback.
>
>Please allow me to answer both of you here, since you raised similar
>concers.
>
>I thought about rejecting the action, but that change of behavior could
>break some users, as currently most kind of invalid tcfa_action values
>are simply accepted.
>
>If there is consensus about it, I can simply fail.
Well it was obviously wrong to expose TC_ACT_REDIRECT to uapi and it
really has no meaning for anyone to use it throughout its whole history.
I would vote for "fail", yet I admit that I am usually alone in opinion
about similar uapi changes :)
>
>Thanks,
>
>Paolo
>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: prevent PHYs w/o Clause 22 regs from calling genphy_config_aneg
From: Andrew Lunn @ 2018-07-25 14:24 UTC (permalink / raw)
To: Camelia Groza; +Cc: f.fainelli, rmk+kernel, davem, netdev, linux-kernel
In-Reply-To: <1532358375-8146-1-git-send-email-camelia.groza@nxp.com>
On Mon, Jul 23, 2018 at 06:06:15PM +0300, Camelia Groza wrote:
> genphy_config_aneg() should be called only by PHYs that implement
> the Clause 22 register set. Prevent Clause 45 PHYs that don't implement
> the register set from calling the genphy function.
>
> Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] staging: fsl-dpaa2/ethsw: Fix error message
From: Ioana Radulescu @ 2018-07-25 14:29 UTC (permalink / raw)
To: gregkh; +Cc: devel, linux-kernel, netdev, ioana.ciornei
Error message was referencing wrong function, fix it.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index 0d54564e..ecdd3d8 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -179,7 +179,7 @@ static int ethsw_port_set_flood(struct ethsw_port_priv *port_priv, u8 flag)
port_priv->idx, flag);
if (err) {
netdev_err(port_priv->netdev,
- "dpsw_fdb_set_learning_mode err %d\n", err);
+ "dpsw_if_set_flooding err %d\n", err);
return err;
}
port_priv->flood = !!flag;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: sched: cls_api: fix dead code in switch
From: Jiri Pirko @ 2018-07-25 14:31 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jiri Pirko, Jamal Hadi Salim, Cong Wang, David S. Miller, netdev,
linux-kernel
In-Reply-To: <20180725140724.GA23053@embeddedor.com>
Wed, Jul 25, 2018 at 04:07:24PM CEST, gustavo@embeddedor.com wrote:
>Code at line 1850 is unreachable. Fix this by removing the break
>statement above it, so the code for case RTM_GETCHAIN can be
>properly executed.
>
>Addresses-Coverity-ID: 1472050 ("Structurally dead code")
>Fixes: 32a4f5ecd738 ("net: sched: introduce chain object to uapi")
>Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
I'm just writing a selftest to test this path. Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: igmp: make function __ip_mc_inc_group() static
From: Eric Dumazet @ 2018-07-25 13:19 UTC (permalink / raw)
To: Wei Yongjun, Alexey Kuznetsov, Hideaki YOSHIFUJI, Hangbin Liu
Cc: netdev, kernel-janitors
In-Reply-To: <1532498773-188363-1-git-send-email-weiyongjun1@huawei.com>
On 07/24/2018 11:06 PM, Wei Yongjun wrote:
> Fixes the following sparse warnings:
>
> net/ipv4/igmp.c:1391:6: warning:
> symbol '__ip_mc_inc_group' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> net/ipv4/igmp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index 598333b..c9f8d46 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -1388,7 +1388,8 @@ static void ip_mc_hash_remove(struct in_device *in_dev,
> /*
> * A socket has joined a multicast group on device dev.
> */
> -void __ip_mc_inc_group(struct in_device *in_dev, __be32 addr, unsigned int mode)
> +static void __ip_mc_inc_group(struct in_device *in_dev, __be32 addr,
> + unsigned int mode)
> {
> struct ip_mc_list *im;
> #ifdef CONFIG_IP_MULTICAST
>
This should target net tree
Fixes: 6e2059b53f98 ("ipv4/igmp: init group mode as INCLUDE when join source group")
^ permalink raw reply
* Re: [BUG BISECT] NFSv4 client fails on Flush Journal to Persistent Storage
From: Chuck Lever @ 2018-07-25 14:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Trond Myklebust, sudeep.holla@arm.com, Trond Myklebust,
Anna Schumaker, Bruce Fields, Jeff Layton, David S. Miller,
Linux NFS Mailing List, netdev, linux-kernel,
linux-samsung-soc@vger.kernel.org
In-Reply-To: <CAJKOXPfMiaGP9xqPcOQMs+a4RKvhK03v51e5r3GaUiFs0G=61Q@mail.gmail.com>
> On Jul 25, 2018, at 9:27 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 18 June 2018 at 18:20, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> The extra serialization appears to have a reproducible performance
>> impact on RDMA, which no longer takes the reserve_lock when allocating
>> a slot.
>>
>> I could put an xprt_alloc_xid call in xprt_alloc_slot, but that would
>> only work for socket-based transports. Would it be OK if RDMA had its
>> own XID allocation mechanism?
>
> Hi,
>
> On recent next the issue appeared again. My boards with NFSv4 root
> timeout on 80% of boots. This time my NFS server is faster - Pi3 B+
> :).
>
> Is this know? Should I start long bisect or maybe you can point me to
> possible causes?
Hi Krzysztof, I don't know of any recent changes. Bisecting would be
a good place to start.
--
Chuck Lever
^ permalink raw reply
* [PATCH net-next 0/4] net/smc: patches 2018-07-25
From: Ursula Braun @ 2018-07-25 14:35 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
Dave,
here are 4 more patches for SMC: The first one is just a small
code cleanup in preparation for patch 2. Patch 2 switches to the
use of the vlan-gid for VLAN traffic. Patch 3 improves diagnosis
when creating SMC connections. Patch 4 improves synchronization
between local and remote link groups.
Thanks, Ursula
Karsten Graul (2):
net/smc: provide fallback reason code
net/smc: improve delete link processing
Ursula Braun (2):
net/smc: fewer parameters for smc_llc_send_confirm_link()
net/smc: use correct vlan gid of RoCE device
include/uapi/linux/smc_diag.h | 6 +++
net/smc/af_smc.c | 86 ++++++++++++++++++++++---------------------
net/smc/smc.h | 2 +
net/smc/smc_clc.c | 16 ++++----
net/smc/smc_clc.h | 20 ++++++----
net/smc/smc_core.c | 84 +++++++++++++++++++++++-------------------
net/smc/smc_core.h | 9 +++--
net/smc/smc_diag.c | 8 +++-
net/smc/smc_ib.c | 41 ++++++++++++++++++---
net/smc/smc_ib.h | 3 +-
net/smc/smc_llc.c | 50 +++++++++++++------------
net/smc/smc_llc.h | 7 ++--
net/smc/smc_pnet.c | 30 ++++++++++-----
net/smc/smc_pnet.h | 3 +-
net/smc/smc_wr.c | 7 +---
15 files changed, 228 insertions(+), 144 deletions(-)
--
2.16.4
^ permalink raw reply
* Re: [PATCH net-next 1/2] docs: Add rest label the_canonical_path_format
From: Edward Cree @ 2018-07-25 14:36 UTC (permalink / raw)
To: Tobin C. Harding, David S. Miller, Jonathan Corbet
Cc: linux-doc, netdev, linux-kernel
In-Reply-To: <20180725025005.14332-2-me@tobin.cc>
On 25/07/18 03:50, Tobin C. Harding wrote:
> In preparation to convert Documentation/network/netdev-FAQ.rst to
> restructured text format we would like to be able to reference 'the
> canonical patch format' section.
>
> Add rest label: 'the_canonical_path_format'.
Here and in the Subject, 'patch' is typoed as 'path'.
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] act_mirred: use TC_ACT_REINJECT when possible
From: Jiri Pirko @ 2018-07-25 13:30 UTC (permalink / raw)
To: Paolo Abeni
Cc: Cong Wang, Linux Kernel Network Developers, Jamal Hadi Salim,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger,
David Miller
In-Reply-To: <3b2edafe358d1015a143b1fa0cf49b180e962c88.camel@redhat.com>
Wed, Jul 25, 2018 at 12:14:32PM CEST, pabeni@redhat.com wrote:
>On Tue, 2018-07-24 at 14:15 -0700, Cong Wang wrote:
>> On Tue, Jul 24, 2018 at 1:07 PM Paolo Abeni <pabeni@redhat.com> wrote:
>> > +
>> > + /* let's the caller reinject the packet, if possible */
>> > + if (skb_at_tc_ingress(skb)) {
>> > + res->ingress = want_ingress;
>> > + res->qstats = this_cpu_ptr(m->common.cpu_qstats);
>> > + return TC_ACT_REINJECT;
>> > + }
>>
>> Looks good to me, but here we no longer return user-specified
>> return value here, I am sure it is safe for TC_ACT_STOLEN, but
>> I am not sure if it is safe for other values, like TC_ACT_RECLASSIFY.
>
>I can make it safer, using the no clone path only if tcf_action is
>TC_ACT_STOLEN. That will still cover the relevant use-cases.
That is a good idea. Thanks!
>
>Will do that in v4.
>
>Cheers,
>
>Paolo
>
^ 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