* Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets
From: Eric Dumazet @ 2018-05-10 3:32 UTC (permalink / raw)
To: Jon Maxwell, davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, jmaxwell
In-Reply-To: <20180510020739.8599-1-jmaxwell37@gmail.com>
On 05/09/2018 07:07 PM, Jon Maxwell wrote:
> Aidan McGurn from Openwave Mobility systems reported the following bug:
>
> "Marked routing is broken on customer deployment. Its effects are large
> increase in Uplink retransmissions caused by the client never receiving
> the final ACK to their FINACK - this ACK misses the mark and routes out
> of the incorrect route."
>
> Currently marks are added to sk_buffs for replies when the "fwmark_reflect"
> sysctl is enabled. But not for TIME_WAIT sockets where the original socket had
> sk->sk_mark set via setsockopt(SO_MARK..).
>
> Fix this in IPv4/v6 by adding tw->tw_mark for TIME_WAIT sockets. Copy the the
> original sk->sk_mark in __inet_twsk_hashdance() to the new tw->tw_mark location.
> Then copy this into ctl_sk->sk_mark so that the skb gets sent with the correct
> mark. Do the same for resets. Give the "fwmark_reflect" sysctl precedence over
> sk->sk_mark so that netfilter rules are still honored.
>
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
> ---
> include/net/inet_timewait_sock.h | 1 +
> net/ipv4/ip_output.c | 3 ++-
> net/ipv4/tcp_ipv4.c | 18 ++++++++++++++++--
> net/ipv4/tcp_minisocks.c | 1 +
> net/ipv6/tcp_ipv6.c | 8 +++++++-
> 5 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
> index c7be1ca8e562..659d8ed5a3bc 100644
> --- a/include/net/inet_timewait_sock.h
> +++ b/include/net/inet_timewait_sock.h
> @@ -62,6 +62,7 @@ struct inet_timewait_sock {
> #define tw_dr __tw_common.skc_tw_dr
>
> int tw_timeout;
> + __u32 tw_mark;
> volatile unsigned char tw_substate;
> unsigned char tw_rcv_wscale;
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 95adb171f852..cca4412dc4cb 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1539,6 +1539,7 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
> struct sk_buff *nskb;
> int err;
> int oif;
> + __u32 mark = IP4_REPLY_MARK(net, skb->mark);
>
> if (__ip_options_echo(net, &replyopts.opt.opt, skb, sopt))
> return;
> @@ -1561,7 +1562,7 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
> oif = skb->skb_iif;
>
> flowi4_init_output(&fl4, oif,
> - IP4_REPLY_MARK(net, skb->mark),
> + mark ? (mark) : sk->sk_mark,
You can avoid the declaration of mark variable and simply use here :
IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark,
> RT_TOS(arg->tos),
> RT_SCOPE_UNIVERSE, ip_hdr(skb)->protocol,
> ip_reply_arg_flowi_flags(arg),
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index f70586b50838..fbee36579c83 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -621,6 +621,7 @@ static void tcp_v4_send_reset(const struct sock *sk, struct sk_buff *skb)
> struct sock *sk1 = NULL;
> #endif
> struct net *net;
> + struct sock *ctl_sk;
>
> /* Never send a reset in response to a reset. */
> if (th->rst)
> @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, struct sk_buff *skb)
> arg.tos = ip_hdr(skb)->tos;
> arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL);
> local_bh_disable();
> - ip_send_unicast_reply(*this_cpu_ptr(net->ipv4.tcp_sk),
> + ctl_sk = *this_cpu_ptr(net->ipv4.tcp_sk);
> + if (sk && sk->sk_state == TCP_TIME_WAIT)
> + ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
> + else if (sk && sk_fullsock(sk))
> + ctl_sk->sk_mark = sk->sk_mark;
> + ip_send_unicast_reply(ctl_sk,
> skb, &TCP_SKB_CB(skb)->header.h4.opt,
> ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
> &arg, arg.iov[0].iov_len);
>
> + ctl_sk->sk_mark = 0;
> __TCP_INC_STATS(net, TCP_MIB_OUTSEGS);
> __TCP_INC_STATS(net, TCP_MIB_OUTRSTS);
> local_bh_enable();
> @@ -759,6 +766,7 @@ static void tcp_v4_send_ack(const struct sock *sk,
> } rep;
> struct net *net = sock_net(sk);
> struct ip_reply_arg arg;
> + struct sock *ctl_sk;
>
> memset(&rep.th, 0, sizeof(struct tcphdr));
> memset(&arg, 0, sizeof(arg));
> @@ -809,11 +817,17 @@ static void tcp_v4_send_ack(const struct sock *sk,
> arg.tos = tos;
> arg.uid = sock_net_uid(net, sk_fullsock(sk) ? sk : NULL);
> local_bh_disable();
> - ip_send_unicast_reply(*this_cpu_ptr(net->ipv4.tcp_sk),
> + ctl_sk = *this_cpu_ptr(net->ipv4.tcp_sk);
> + if (sk && sk->sk_state == TCP_TIME_WAIT)
> + ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
> + else if (sk && sk_fullsock(sk))
> + ctl_sk->sk_mark = sk->sk_mark;
> + ip_send_unicast_reply(ctl_sk,
> skb, &TCP_SKB_CB(skb)->header.h4.opt,
> ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
> &arg, arg.iov[0].iov_len);
>
> + ctl_sk->sk_mark = 0;
> __TCP_INC_STATS(net, TCP_MIB_OUTSEGS);
> local_bh_enable();
> }
> diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> index 57b5468b5139..f867658b4b30 100644
> --- a/net/ipv4/tcp_minisocks.c
> +++ b/net/ipv4/tcp_minisocks.c
> @@ -263,6 +263,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
> struct inet_sock *inet = inet_sk(sk);
>
> tw->tw_transparent = inet->transparent;
> + tw->tw_mark = sk->sk_mark;
> tw->tw_rcv_wscale = tp->rx_opt.rcv_wscale;
> tcptw->tw_rcv_nxt = tp->rcv_nxt;
> tcptw->tw_snd_nxt = tp->snd_nxt;
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 6d664d83cd16..a6f876125091 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -803,6 +803,7 @@ static void tcp_v6_send_response(const struct sock *sk, struct sk_buff *skb, u32
> unsigned int tot_len = sizeof(struct tcphdr);
> struct dst_entry *dst;
> __be32 *topt;
> + __u32 mark = IP6_REPLY_MARK(net, skb->mark);
>
> if (tsecr)
> tot_len += TCPOLEN_TSTAMP_ALIGNED;
> @@ -871,11 +872,16 @@ static void tcp_v6_send_response(const struct sock *sk, struct sk_buff *skb, u32
> fl6.flowi6_oif = oif;
> }
>
> - fl6.flowi6_mark = IP6_REPLY_MARK(net, skb->mark);
> + if (sk && sk->sk_state == TCP_TIME_WAIT)
> + ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
> + else if (sk && sk_fullsock(sk))
> + ctl_sk->sk_mark = sk->sk_mark;
Unfortunately IPv6 has a single net->ipv6.tcp_sk, shared by all cpus.
So writing ctl_sk->sk_mark is racy on SMP hosts.
I would suggest using a local variable, and not touch ctl_sk->sk_mark
For consistency, you could do the same for IPv4, even if IPv4 currently uses per-cpu sockets
> + fl6.flowi6_mark = mark ? (mark) : ctl_sk->sk_mark;
> fl6.fl6_dport = t1->dest;
> fl6.fl6_sport = t1->source;
> fl6.flowi6_uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL);
> security_skb_classify_flow(skb, flowi6_to_flowi(&fl6));
> + ctl_sk->sk_mark = 0;
>
> /* Pass a socket to ip6_dst_lookup either it is for RST
> * Underlying function will use this to retrieve the network
>
^ permalink raw reply
* [PATCH net-next] net/core: delete the no need variable description in devlink_resource_register() comment
From: Sun Lianwen @ 2018-05-10 3:28 UTC (permalink / raw)
To: davem; +Cc: netdev
The variable "top_hierarchy" and "reload_required" is not existence in
devlink_resource_register()
Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
---
net/core/devlink.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index ad1317376798..c9596ea1d016 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -3162,9 +3162,6 @@ EXPORT_SYMBOL_GPL(devlink_dpipe_table_unregister);
*
* @devlink: devlink
* @resource_name: resource's name
- * @top_hierarchy: top hierarchy
- * @reload_required: reload is required for new configuration to
- * apply
* @resource_size: resource's size
* @resource_id: resource's id
* @parent_reosurce_id: resource's parent id
--
2.17.0
^ permalink raw reply related
* [PATCH] bpf, doc: clarification for the meaning of 'id'
From: Wang YanQing @ 2018-05-10 3:09 UTC (permalink / raw)
To: daniel; +Cc: ast, corbet, netdev, linux-kernel, linux-doc
For me, as a reader whose mother language isn't English, the
old words bring a little difficulty to catch the meaning, this
patch rewords the subsection in a more clarificatory way.
This patch also add blank lines as separator at two places
to improve readability.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
Documentation/networking/filter.txt | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index 5032e12..e6b4ebb 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -1142,6 +1142,7 @@ into a register from memory, the register's top 56 bits are known zero, while
the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we
then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
0x1ff), because of potential carries.
+
Besides arithmetic, the register state can also be updated by conditional
branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false'
@@ -1150,14 +1151,16 @@ BPF_JSGE) would instead update the signed minimum/maximum values. Information
from the signed and unsigned bounds can be combined; for instance if a value is
first tested < 8 and then tested s> 4, the verifier will conclude that the value
is also > 4 and s< 8, since the bounds prevent crossing the sign boundary.
+
PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all
pointers sharing that same variable offset. This is important for packet range
-checks: after adding some variable to a packet pointer, if you then copy it to
-another register and (say) add a constant 4, both registers will share the same
-'id' but one will have a fixed offset of +4. Then if it is bounds-checked and
-found to be less than a PTR_TO_PACKET_END, the other register is now known to
-have a safe range of at least 4 bytes. See 'Direct packet access', below, for
-more on PTR_TO_PACKET ranges.
+checks: after adding a variable to a packet pointer register A, if you then copy
+it to another register B and then add a constant 4 to A, both registers will
+share the same 'id' but the A will have a fixed offset of +4. Then if A is
+bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is
+now known to have a safe range of at least 4 bytes. See 'Direct packet access',
+below, for more on PTR_TO_PACKET ranges.
+
The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of
the pointer returned from a map lookup. This means that when one copy is
checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
--
1.8.5.6.2.g3d8a54e.dirty
^ permalink raw reply related
* [PATCH net-next] net/core: correct the variable name in dev_ioctl() comment
From: Sun Lianwen @ 2018-05-10 3:01 UTC (permalink / raw)
To: davem; +Cc: netdev
The variable name is not "arg" but "ifr" in dev_ioctl()
Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
---
net/core/dev_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index a04e1e88bf3a..114e29053977 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -378,7 +378,7 @@ EXPORT_SYMBOL(dev_load);
* dev_ioctl - network device ioctl
* @net: the applicable net namespace
* @cmd: command to issue
- * @arg: pointer to a struct ifreq in user space
+ * @ifr: pointer to a struct ifreq in user space
*
* Issue ioctl functions to devices. This is normally called by the
* user space syscall interfaces but can sometimes be useful for
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Michael Chan @ 2018-05-10 2:32 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Or Gerlitz, David Miller, Netdev
In-Reply-To: <20180509181018.4583e577@cakuba.netronome.com>
On Wed, May 9, 2018 at 6:10 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Wed, 9 May 2018 17:22:50 -0700, Michael Chan wrote:
>> On Wed, May 9, 2018 at 4:15 PM, Jakub Kicinski wrote:
>> > On Wed, 9 May 2018 07:21:41 -0400, Michael Chan wrote:
>> >> VF Queue resources are always limited and there is currently no
>> >> infrastructure to allow the admin. on the host to add or reduce queue
>> >> resources for any particular VF. With ever increasing number of VFs
>> >> being supported, it is desirable to allow the admin. to configure queue
>> >> resources differently for the VFs. Some VFs may require more or fewer
>> >> queues due to different bandwidth requirements or different number of
>> >> vCPUs in the VM. This patch adds the infrastructure to do that by
>> >> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
>> >> to the net_device_ops.
>> >>
>> >> Four parameters are exposed for each VF:
>> >>
>> >> o min_tx_queues - Guaranteed or current tx queues assigned to the VF.
>> >
>> > This muxing of semantics may be a little awkward and unnecessary, would
>> > it make sense for struct ifla_vf_info to have a separate fields for
>> > current number of queues and the admin-set guaranteed min?
>>
>> The loose semantics is mainly to allow some flexibility in
>> implementation. Sure, we can tighten the definitions or add
>> additional fields.
>
> I would appreciate that, if others don't disagree. I personally don't
> see the need for flexibility (AKA per-vendor behaviour) here, quite the
> opposite, min/max/current number of queues seems quite self-explanatory.
>
> Or at least don't allow min to mean current? Otherwise the API gets a
> bit asymmetrical :(
Sure, will do.
>
>> > Is there a real world use case for the min value or are you trying to
>> > make the API feature complete?
>>
>> In this proposal, these parameters are mainly viewed as the bounds for
>> the queues that each VF can potentially allocate. The actual number
>> of queues chosen by the VF driver or modified by the VF user can be
>> any number within the bounds.
>
> Perhaps you have misspoken here - these are not allowed bounds, right?
> min is the guarantee that queues will be available, not requirement.
> Similar to bandwidth allocation.
>
> IOW if the bounds are set [4, 16] the VF may still choose to use 1
> queue, event thought that's not within bounds.
Yes, you are absolutely right. The VF can allocate 1 queue. Up to
min is guaranteed. Up to max is not guaranteed.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2018-05-10 2:13 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Heiner Kallweit
[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/realtek/r8169.c
between commit:
3148dedfe79e ("r8169: fix powering up RTL8168h")
from the net tree and commit:
4f447d296982 ("r8169: drop member pll_power_ops from struct rtl8169_private")
from the net-next tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/realtek/r8169.c
index c7aac1fc99e8,6d99b141a7aa..000000000000
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@@ -4980,72 -4767,13 +4767,16 @@@ static void rtl_pll_power_down(struct r
static void rtl_pll_power_up(struct rtl8169_private *tp)
{
- rtl_generic_op(tp, tp->pll_power_ops.up);
-
- /* give MAC/PHY some time to resume */
- msleep(20);
- }
-
- static void rtl_init_pll_power_ops(struct rtl8169_private *tp)
- {
- struct pll_power_ops *ops = &tp->pll_power_ops;
-
switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_07:
- case RTL_GIGA_MAC_VER_08:
- case RTL_GIGA_MAC_VER_09:
- case RTL_GIGA_MAC_VER_10:
- case RTL_GIGA_MAC_VER_16:
- case RTL_GIGA_MAC_VER_29:
- case RTL_GIGA_MAC_VER_30:
- case RTL_GIGA_MAC_VER_37:
- case RTL_GIGA_MAC_VER_39:
- case RTL_GIGA_MAC_VER_43:
- case RTL_GIGA_MAC_VER_47:
- case RTL_GIGA_MAC_VER_48:
- ops->down = r810x_pll_power_down;
- ops->up = r810x_pll_power_up;
- break;
-
- case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_12:
- case RTL_GIGA_MAC_VER_17:
- case RTL_GIGA_MAC_VER_18:
- case RTL_GIGA_MAC_VER_19:
- case RTL_GIGA_MAC_VER_20:
- case RTL_GIGA_MAC_VER_21:
- case RTL_GIGA_MAC_VER_22:
- case RTL_GIGA_MAC_VER_23:
- case RTL_GIGA_MAC_VER_24:
- case RTL_GIGA_MAC_VER_25:
- case RTL_GIGA_MAC_VER_26:
- case RTL_GIGA_MAC_VER_27:
- case RTL_GIGA_MAC_VER_28:
- case RTL_GIGA_MAC_VER_31:
- case RTL_GIGA_MAC_VER_32:
- case RTL_GIGA_MAC_VER_33:
- case RTL_GIGA_MAC_VER_34:
- case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
- case RTL_GIGA_MAC_VER_38:
- case RTL_GIGA_MAC_VER_40:
- case RTL_GIGA_MAC_VER_41:
- case RTL_GIGA_MAC_VER_42:
- case RTL_GIGA_MAC_VER_44:
- case RTL_GIGA_MAC_VER_45:
- case RTL_GIGA_MAC_VER_46:
- case RTL_GIGA_MAC_VER_49:
- case RTL_GIGA_MAC_VER_50:
- case RTL_GIGA_MAC_VER_51:
- ops->down = r8168_pll_power_down;
- ops->up = r8168_pll_power_up;
+ case RTL_GIGA_MAC_VER_01 ... RTL_GIGA_MAC_VER_06:
+ case RTL_GIGA_MAC_VER_13 ... RTL_GIGA_MAC_VER_15:
break;
-
default:
- ops->down = NULL;
- ops->up = NULL;
- break;
+ r8168_pll_power_up(tp);
}
++
++ /* give MAC/PHY some time to resume */
++ msleep(20);
}
static void rtl_init_rxcfg(struct rtl8169_private *tp)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next] tcp: Add mark for TIMEWAIT sockets
From: Jon Maxwell @ 2018-05-10 2:07 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, jmaxwell
Aidan McGurn from Openwave Mobility systems reported the following bug:
"Marked routing is broken on customer deployment. Its effects are large
increase in Uplink retransmissions caused by the client never receiving
the final ACK to their FINACK - this ACK misses the mark and routes out
of the incorrect route."
Currently marks are added to sk_buffs for replies when the "fwmark_reflect"
sysctl is enabled. But not for TIME_WAIT sockets where the original socket had
sk->sk_mark set via setsockopt(SO_MARK..).
Fix this in IPv4/v6 by adding tw->tw_mark for TIME_WAIT sockets. Copy the the
original sk->sk_mark in __inet_twsk_hashdance() to the new tw->tw_mark location.
Then copy this into ctl_sk->sk_mark so that the skb gets sent with the correct
mark. Do the same for resets. Give the "fwmark_reflect" sysctl precedence over
sk->sk_mark so that netfilter rules are still honored.
Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
---
include/net/inet_timewait_sock.h | 1 +
net/ipv4/ip_output.c | 3 ++-
net/ipv4/tcp_ipv4.c | 18 ++++++++++++++++--
net/ipv4/tcp_minisocks.c | 1 +
net/ipv6/tcp_ipv6.c | 8 +++++++-
5 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
index c7be1ca8e562..659d8ed5a3bc 100644
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -62,6 +62,7 @@ struct inet_timewait_sock {
#define tw_dr __tw_common.skc_tw_dr
int tw_timeout;
+ __u32 tw_mark;
volatile unsigned char tw_substate;
unsigned char tw_rcv_wscale;
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 95adb171f852..cca4412dc4cb 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1539,6 +1539,7 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
struct sk_buff *nskb;
int err;
int oif;
+ __u32 mark = IP4_REPLY_MARK(net, skb->mark);
if (__ip_options_echo(net, &replyopts.opt.opt, skb, sopt))
return;
@@ -1561,7 +1562,7 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
oif = skb->skb_iif;
flowi4_init_output(&fl4, oif,
- IP4_REPLY_MARK(net, skb->mark),
+ mark ? (mark) : sk->sk_mark,
RT_TOS(arg->tos),
RT_SCOPE_UNIVERSE, ip_hdr(skb)->protocol,
ip_reply_arg_flowi_flags(arg),
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f70586b50838..fbee36579c83 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -621,6 +621,7 @@ static void tcp_v4_send_reset(const struct sock *sk, struct sk_buff *skb)
struct sock *sk1 = NULL;
#endif
struct net *net;
+ struct sock *ctl_sk;
/* Never send a reset in response to a reset. */
if (th->rst)
@@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, struct sk_buff *skb)
arg.tos = ip_hdr(skb)->tos;
arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL);
local_bh_disable();
- ip_send_unicast_reply(*this_cpu_ptr(net->ipv4.tcp_sk),
+ ctl_sk = *this_cpu_ptr(net->ipv4.tcp_sk);
+ if (sk && sk->sk_state == TCP_TIME_WAIT)
+ ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
+ else if (sk && sk_fullsock(sk))
+ ctl_sk->sk_mark = sk->sk_mark;
+ ip_send_unicast_reply(ctl_sk,
skb, &TCP_SKB_CB(skb)->header.h4.opt,
ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
&arg, arg.iov[0].iov_len);
+ ctl_sk->sk_mark = 0;
__TCP_INC_STATS(net, TCP_MIB_OUTSEGS);
__TCP_INC_STATS(net, TCP_MIB_OUTRSTS);
local_bh_enable();
@@ -759,6 +766,7 @@ static void tcp_v4_send_ack(const struct sock *sk,
} rep;
struct net *net = sock_net(sk);
struct ip_reply_arg arg;
+ struct sock *ctl_sk;
memset(&rep.th, 0, sizeof(struct tcphdr));
memset(&arg, 0, sizeof(arg));
@@ -809,11 +817,17 @@ static void tcp_v4_send_ack(const struct sock *sk,
arg.tos = tos;
arg.uid = sock_net_uid(net, sk_fullsock(sk) ? sk : NULL);
local_bh_disable();
- ip_send_unicast_reply(*this_cpu_ptr(net->ipv4.tcp_sk),
+ ctl_sk = *this_cpu_ptr(net->ipv4.tcp_sk);
+ if (sk && sk->sk_state == TCP_TIME_WAIT)
+ ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
+ else if (sk && sk_fullsock(sk))
+ ctl_sk->sk_mark = sk->sk_mark;
+ ip_send_unicast_reply(ctl_sk,
skb, &TCP_SKB_CB(skb)->header.h4.opt,
ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
&arg, arg.iov[0].iov_len);
+ ctl_sk->sk_mark = 0;
__TCP_INC_STATS(net, TCP_MIB_OUTSEGS);
local_bh_enable();
}
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 57b5468b5139..f867658b4b30 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -263,6 +263,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
struct inet_sock *inet = inet_sk(sk);
tw->tw_transparent = inet->transparent;
+ tw->tw_mark = sk->sk_mark;
tw->tw_rcv_wscale = tp->rx_opt.rcv_wscale;
tcptw->tw_rcv_nxt = tp->rcv_nxt;
tcptw->tw_snd_nxt = tp->snd_nxt;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 6d664d83cd16..a6f876125091 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -803,6 +803,7 @@ static void tcp_v6_send_response(const struct sock *sk, struct sk_buff *skb, u32
unsigned int tot_len = sizeof(struct tcphdr);
struct dst_entry *dst;
__be32 *topt;
+ __u32 mark = IP6_REPLY_MARK(net, skb->mark);
if (tsecr)
tot_len += TCPOLEN_TSTAMP_ALIGNED;
@@ -871,11 +872,16 @@ static void tcp_v6_send_response(const struct sock *sk, struct sk_buff *skb, u32
fl6.flowi6_oif = oif;
}
- fl6.flowi6_mark = IP6_REPLY_MARK(net, skb->mark);
+ if (sk && sk->sk_state == TCP_TIME_WAIT)
+ ctl_sk->sk_mark = inet_twsk(sk)->tw_mark;
+ else if (sk && sk_fullsock(sk))
+ ctl_sk->sk_mark = sk->sk_mark;
+ fl6.flowi6_mark = mark ? (mark) : ctl_sk->sk_mark;
fl6.fl6_dport = t1->dest;
fl6.fl6_sport = t1->source;
fl6.flowi6_uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL);
security_skb_classify_flow(skb, flowi6_to_flowi(&fl6));
+ ctl_sk->sk_mark = 0;
/* Pass a socket to ip6_dst_lookup either it is for RST
* Underlying function will use this to retrieve the network
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net] macmace: Set platform device coherent_dma_mask
From: Finn Thain @ 2018-05-10 1:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, linux-m68k, netdev, Linux Kernel Mailing List,
Christoph Hellwig
In-Reply-To: <CAMuHMdU1XBqt7hwEW6JTas64ZNGCGCMr5HMZwuLo0O-ZBCOWyA@mail.gmail.com>
On Thu, 3 May 2018, Geert Uytterhoeven wrote:
>
> Perhaps you can add a new helper
> (platform_device_register_simple_dma()?) that takes the DMA mask, too?
Would there be enough potential callers in future to justify that API?
It seems that there haven't been many in the past. I found four users of
platform_device_register_simple() which might benefit. Mostly these call
dma_set_coherent_mask() in the platform driver probe routine.
drivers/gpu/drm/etnaviv/etnaviv_drv.c
drivers/gpu/drm/exynos/exynos_drm_drv.c
drivers/gpu/drm/omapdrm/omap_drv.c
drivers/parport/parport_pc.c
(Am I missing any others?)
To actually hoist the dma mask setup out of existing platform drivers
would have implications for every device that matches with those drivers.
That's a bit risky since I can't test those devices -- that's assuming I
could identify them all; sometimes platform device matching is not well
defined at build time (see loongson_sysconf.ecname).
So far, it looks like macmace and macsonic would be the only callers of
this new API call.
What's worse, if you do pass a dma_mask in struct platform_device_info,
you end up with this problem in platform_device_register_full():
if (pdevinfo->dma_mask) {
/*
* This memory isn't freed when the device is put,
* I don't have a nice idea for that though. Conceptually
* dma_mask in struct device should not be a pointer.
* See http://thread.gmane.org/gmane.linux.kernel.pci/9081
*/
pdev->dev.dma_mask =
kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
Most of the platform drivers that call dma_coerce_mask_and_coherent() are
using pdev->of_match_table, not platform_device_register_simple(). Many of
them have a comment like this:
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
* Once we have dma capability bindings this can go away.
*/
> With people setting the mask to kill the WARNING splat, this may become
> more common.
Since the commit which introduced the WARNING, only commits f61e64310b75
("m68k: set dma and coherent masks for platform FEC ethernets") and
7bcfab202ca7 ("powerpc/macio: set a proper dma_coherent_mask") seem to be
aimed at squelching that WARNING.
(Am I missing any others?)
So far, this is not looking like a common problem, and I'm having trouble
finding some way to improve on my original patches.
--
^ permalink raw reply
* Re: [PATCH net] macmace: Set platform device coherent_dma_mask
From: Finn Thain @ 2018-05-10 1:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, David S. Miller, linux-m68k, netdev,
Linux Kernel Mailing List
In-Reply-To: <20180503085120.GA14574@lst.de>
On Thu, 3 May 2018, Christoph Hellwig wrote:
> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
> > Perhaps you can add a new helper
> > (platform_device_register_simple_dma()?) that takes the DMA mask, too?
> > With people setting the mask to kill the WARNING splat, this may
> > become more common.
> >
> > struct platform_device_info already has a dma_mask field, but
> > platform_device_register_resndata() explicitly sets it to zero.
>
> Yes, that would be useful. The other assumption could be that platform
> devices always allow an all-0xff dma mask.
Could that have unintended side effects? The mask is presently unset by
default, and my worry would be that changing it may cause some drivers to
behave differently.
A quick grep turns up this in drivers/spi/spi-au1550.c for example,
if (pdev->dev.dma_mask == NULL)
dev_warn(&pdev->dev, "no dma mask\n");
else
hw->usedma = 1;
Also, if pdev.dev.dma_mask is to get a default value, shouldn't it use the
same default as dma_get_mask, to avoid unintended side effects?
static inline u64 dma_get_mask(struct device *dev)
{
if (dev && dev->dma_mask && *dev->dma_mask)
return *dev->dma_mask;
return DMA_BIT_MASK(32);
}
--
^ permalink raw reply
* Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Jakub Kicinski @ 2018-05-10 1:10 UTC (permalink / raw)
To: Michael Chan; +Cc: Or Gerlitz, David Miller, Netdev
In-Reply-To: <CACKFLik6Mcd3YL8hUGG=uFV6QkBbnj3rskg08GezQrWKK5TBMA@mail.gmail.com>
On Wed, 9 May 2018 17:22:50 -0700, Michael Chan wrote:
> On Wed, May 9, 2018 at 4:15 PM, Jakub Kicinski wrote:
> > On Wed, 9 May 2018 07:21:41 -0400, Michael Chan wrote:
> >> VF Queue resources are always limited and there is currently no
> >> infrastructure to allow the admin. on the host to add or reduce queue
> >> resources for any particular VF. With ever increasing number of VFs
> >> being supported, it is desirable to allow the admin. to configure queue
> >> resources differently for the VFs. Some VFs may require more or fewer
> >> queues due to different bandwidth requirements or different number of
> >> vCPUs in the VM. This patch adds the infrastructure to do that by
> >> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
> >> to the net_device_ops.
> >>
> >> Four parameters are exposed for each VF:
> >>
> >> o min_tx_queues - Guaranteed or current tx queues assigned to the VF.
> >
> > This muxing of semantics may be a little awkward and unnecessary, would
> > it make sense for struct ifla_vf_info to have a separate fields for
> > current number of queues and the admin-set guaranteed min?
>
> The loose semantics is mainly to allow some flexibility in
> implementation. Sure, we can tighten the definitions or add
> additional fields.
I would appreciate that, if others don't disagree. I personally don't
see the need for flexibility (AKA per-vendor behaviour) here, quite the
opposite, min/max/current number of queues seems quite self-explanatory.
Or at least don't allow min to mean current? Otherwise the API gets a
bit asymmetrical :(
> > Is there a real world use case for the min value or are you trying to
> > make the API feature complete?
>
> In this proposal, these parameters are mainly viewed as the bounds for
> the queues that each VF can potentially allocate. The actual number
> of queues chosen by the VF driver or modified by the VF user can be
> any number within the bounds.
Perhaps you have misspoken here - these are not allowed bounds, right?
min is the guarantee that queues will be available, not requirement.
Similar to bandwidth allocation.
IOW if the bounds are set [4, 16] the VF may still choose to use 1
queue, event thought that's not within bounds.
> We currently need to have min and max parameters to support the
> different modes we use to distribute the queue resources to the VFs.
> In one mode, for example, resources are statically divided and each VF
> has a small number of guaranteed queues (min = max). In a different
> mode, we allow more flexible resource allocation with each VF having a
> small number of guaranteed queues but a higher number of
> non-guaranteed queues (min < max). Some VFs may be able to allocate
> queues much higher than min when resources are still available, while
> others may only be able to allocate min queues when resources are used
> up.
>
> With min and max exposed, the PF user can properly tweak the resources
> for each VF described above.
Right, I was just looking for a real world scenario where this
flexibility is going to be used - mainly because the switchdev model I
described below won't allow it. I'm not sure users will leave a
portion of queues to be allocated by chance.
> >> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
> >> available to the VF.
> >>
> >> o min_rx_queues - Guaranteed or current rx queues assigned to the VF.
> >>
> >> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
> >> available to the VF.
> >>
> >> The "ip link set" command will subsequently be patched to support the new
> >> operation to set the above parameters.
> >>
> >> After the admin. makes a change to the above parameters, the corresponding
> >> VF will have a new range of channels to set using ethtool -L.
> >>
> >> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> >
> > In switchdev mode we can use number of queues on the representor as a
> > proxy for max number of queues allowed for the ASIC port. This works
> > better when representors are muxed in the first place than when they
> > have actual queues backing them. WDYT about such scheme, Or? A very
> > pleasant side-effect is that one can configure qdiscs and get stats
> > per-HW queue.
>
> This is an interesting approach. But it doesn't have the min and max
> for each VF, and also only works in switchdev mode.
It allows controlling all ports of the switch with the same, existing
and well known API (incl. PFs). But sadly I don't think we are at the
point where switchdev-mode solutions are considered an alternative, so
I'm only mentioning it to broaden the discussion :) I'm not opposed to
your patches :)
^ permalink raw reply
* Proposal
From: Zeliha Omer Faruk @ 2018-05-10 0:39 UTC (permalink / raw)
--
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Michael Chan @ 2018-05-10 0:22 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Or Gerlitz, David Miller, Netdev
In-Reply-To: <20180509161509.373f8c1b@cakuba.netronome.com>
On Wed, May 9, 2018 at 4:15 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Wed, 9 May 2018 07:21:41 -0400, Michael Chan wrote:
>> VF Queue resources are always limited and there is currently no
>> infrastructure to allow the admin. on the host to add or reduce queue
>> resources for any particular VF. With ever increasing number of VFs
>> being supported, it is desirable to allow the admin. to configure queue
>> resources differently for the VFs. Some VFs may require more or fewer
>> queues due to different bandwidth requirements or different number of
>> vCPUs in the VM. This patch adds the infrastructure to do that by
>> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
>> to the net_device_ops.
>>
>> Four parameters are exposed for each VF:
>>
>> o min_tx_queues - Guaranteed or current tx queues assigned to the VF.
>
> This muxing of semantics may be a little awkward and unnecessary, would
> it make sense for struct ifla_vf_info to have a separate fields for
> current number of queues and the admin-set guaranteed min?
The loose semantics is mainly to allow some flexibility in
implementation. Sure, we can tighten the definitions or add
additional fields.
>
> Is there a real world use case for the min value or are you trying to
> make the API feature complete?
In this proposal, these parameters are mainly viewed as the bounds for
the queues that each VF can potentially allocate. The actual number
of queues chosen by the VF driver or modified by the VF user can be
any number within the bounds.
We currently need to have min and max parameters to support the
different modes we use to distribute the queue resources to the VFs.
In one mode, for example, resources are statically divided and each VF
has a small number of guaranteed queues (min = max). In a different
mode, we allow more flexible resource allocation with each VF having a
small number of guaranteed queues but a higher number of
non-guaranteed queues (min < max). Some VFs may be able to allocate
queues much higher than min when resources are still available, while
others may only be able to allocate min queues when resources are used
up.
With min and max exposed, the PF user can properly tweak the resources
for each VF described above.
>
>> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
>> available to the VF.
>>
>> o min_rx_queues - Guaranteed or current rx queues assigned to the VF.
>>
>> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
>> available to the VF.
>>
>> The "ip link set" command will subsequently be patched to support the new
>> operation to set the above parameters.
>>
>> After the admin. makes a change to the above parameters, the corresponding
>> VF will have a new range of channels to set using ethtool -L.
>>
>> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
>
> In switchdev mode we can use number of queues on the representor as a
> proxy for max number of queues allowed for the ASIC port. This works
> better when representors are muxed in the first place than when they
> have actual queues backing them. WDYT about such scheme, Or? A very
> pleasant side-effect is that one can configure qdiscs and get stats
> per-HW queue.
This is an interesting approach. But it doesn't have the min and max
for each VF, and also only works in switchdev mode.
^ permalink raw reply
* [PATCH net 2/2] bonding: send learning packets for vlans on slave
From: Debabrata Banerjee @ 2018-05-09 23:32 UTC (permalink / raw)
To: David S . Miller, netdev, Vlad Yasevich
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, dbanerje
In-Reply-To: <20180509233211.28207-1-dbanerje@akamai.com>
There was a regression at some point from the intended functionality of
commit f60c3704e87d ("bonding: Fix alb mode to only use first level
vlans.")
Given the return value vlan_get_encap_level() we need to store the nest
level of the bond device, and then compare the vlan's encap level to
this. Without this, this check always fails and learning packets are
never sent.
In addition, this same commit caused a regression in the behavior of
balance_alb, which requires learning packets be sent for all interfaces
using the slave's mac in order to load balance properly. For vlan's
that have not set a user mac, we can send after checking one bit.
Otherwise we need send the set mac, albeit defeating rx load balancing
for that vlan.
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
drivers/net/bonding/bond_alb.c | 13 ++++++++-----
drivers/net/bonding/bond_main.c | 2 ++
include/net/bonding.h | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 3f6faa657360..5eb0df2e5464 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -943,6 +943,10 @@ static void alb_send_lp_vid(struct slave *slave, u8 mac_addr[],
skb->priority = TC_PRIO_CONTROL;
skb->dev = slave->dev;
+ netdev_dbg(slave->bond->dev,
+ "Send learning packet: dev %s mac %pM vlan %d\n",
+ slave->dev->name, mac_addr, vid);
+
if (vid)
__vlan_hwaccel_put_tag(skb, vlan_proto, vid);
@@ -965,14 +969,13 @@ static int alb_upper_dev_walk(struct net_device *upper, void *_data)
u8 *mac_addr = data->mac_addr;
struct bond_vlan_tag *tags;
- if (is_vlan_dev(upper) && vlan_get_encap_level(upper) == 0) {
- if (strict_match &&
- ether_addr_equal_64bits(mac_addr,
- upper->dev_addr)) {
+ if (is_vlan_dev(upper) &&
+ bond->nest_level == vlan_get_encap_level(upper) - 1) {
+ if (upper->addr_assign_type == NET_ADDR_STOLEN) {
alb_send_lp_vid(slave, mac_addr,
vlan_dev_vlan_proto(upper),
vlan_dev_vlan_id(upper));
- } else if (!strict_match) {
+ } else {
alb_send_lp_vid(slave, upper->dev_addr,
vlan_dev_vlan_proto(upper),
vlan_dev_vlan_id(upper));
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 718e4914e3a0..1f1e97b26f95 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1738,6 +1738,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
if (bond_mode_uses_xmit_hash(bond))
bond_update_slave_arr(bond, NULL);
+ bond->nest_level = dev_get_nest_level(bond_dev);
+
netdev_info(bond_dev, "Enslaving %s as %s interface with %s link\n",
slave_dev->name,
bond_is_active_slave(new_slave) ? "an active" : "a backup",
diff --git a/include/net/bonding.h b/include/net/bonding.h
index f801fc940b29..b52235158836 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -198,6 +198,7 @@ struct bonding {
struct slave __rcu *primary_slave;
struct bond_up_slave __rcu *slave_arr; /* Array of usable slaves */
bool force_primary;
+ u32 nest_level;
s32 slave_cnt; /* never change this value outside the attach/detach wrappers */
int (*recv_probe)(const struct sk_buff *, struct bonding *,
struct slave *);
--
2.17.0
^ permalink raw reply related
* Proposal
From: Zeliha Omer Faruk @ 2018-05-09 23:57 UTC (permalink / raw)
--
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* [PATCH net 1/2] bonding: do not allow rlb updates to invalid mac
From: Debabrata Banerjee @ 2018-05-09 23:32 UTC (permalink / raw)
To: David S . Miller, netdev, Vlad Yasevich
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, dbanerje
In-Reply-To: <20180509233211.28207-1-dbanerje@akamai.com>
Make sure multicast, broadcast, and zero mac's cannot be the output of rlb
updates, which should all be directed arps. Receive load balancing will be
collapsed if any of these happen, as the switch will broadcast.
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
drivers/net/bonding/bond_alb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 1ed9529e7bd1..3f6faa657360 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -450,7 +450,7 @@ static void rlb_update_client(struct rlb_client_info *client_info)
{
int i;
- if (!client_info->slave)
+ if (!client_info->slave || !is_valid_ether_addr(client_info->mac_dst))
return;
for (i = 0; i < RLB_ARP_BURST_SIZE; i++) {
--
2.17.0
^ permalink raw reply related
* [PATCH net 0/2] bonding: bug fixes and regressions
From: Debabrata Banerjee @ 2018-05-09 23:32 UTC (permalink / raw)
To: David S . Miller, netdev, Vlad Yasevich
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, dbanerje
Fixes to bonding driver for balance-alb mode, suitable for stable.
Debabrata Banerjee (2):
bonding: do not allow rlb updates to invalid mac
bonding: send learning packets for vlans on slave
drivers/net/bonding/bond_alb.c | 15 +++++++++------
drivers/net/bonding/bond_main.c | 2 ++
include/net/bonding.h | 1 +
3 files changed, 12 insertions(+), 6 deletions(-)
--
2.17.0
^ permalink raw reply
* Re: linux-next: Tree for May 9 (mlx5)
From: Saeed Mahameed @ 2018-05-09 23:21 UTC (permalink / raw)
To: sfr@canb.auug.org.au, rdunlap@infradead.org, Israel Rukshin,
linux-next@vger.kernel.org, Max Gurtovoy
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Leon Romanovsky, Matan Barak
In-Reply-To: <826ab15b-f2bc-0c5d-8d5e-6466badcd3e0@infradead.org>
On Wed, 2018-05-09 at 08:31 -0700, Randy Dunlap wrote:
> On 05/09/2018 04:21 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20180508:
> >
>
> on x86_64:
> # CONFIG_SMP is not set
>
> In file included from
> ../drivers/net/ethernet/mellanox/mlx5/core/main.c:43:0:
> ../include/linux/mlx5/driver.h: In function
> 'mlx5_get_vector_affinity_hint':
> ../include/linux/mlx5/driver.h:1299:13: error: 'struct irq_desc' has
> no member named 'affinity_hint'
> return desc->affinity_hint;
> ^
>
>
Hi Stephen,
Israel and Max are working on a solution, will provide it ASAP.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH] net/mlx5: Fix mlx5_get_vector_affinity function
From: Saeed Mahameed @ 2018-05-09 23:19 UTC (permalink / raw)
To: linux@roeck-us.net, tglx@linutronix.de
Cc: netdev@vger.kernel.org, Max Gurtovoy, Israel Rukshin,
linux-rdma@vger.kernel.org, Matan Barak, dledford@redhat.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20180509221906.GA7548@roeck-us.net>
On Wed, 2018-05-09 at 15:19 -0700, Guenter Roeck wrote:
> On Sun, May 06, 2018 at 09:33:26AM +0200, Thomas Gleixner wrote:
> > On Sat, 5 May 2018, Guenter Roeck wrote:
> >
> > > On Thu, Apr 12, 2018 at 09:49:11AM +0000, Israel Rukshin wrote:
> > > > Adding the vector offset when calling to mlx5_vector2eqn() is
> > > > wrong.
> > > > This is because mlx5_vector2eqn() checks if EQ index is equal
> > > > to vector number
> > > > and the fact that the internal completion vectors that mlx5
> > > > allocates
> > > > don't get an EQ index.
> > > >
> > > > The second problem here is that using effective_affinity_mask
> > > > gives the same
> > > > CPU for different vectors.
> > > > This leads to unmapped queues when calling it from
> > > > blk_mq_rdma_map_queues().
> > > > This doesn't happen when using affinity_hint mask.
> > > >
> > >
> > > Except that affinity_hint is only defined if SMP is enabled.
> > > Without:
> > >
> > > include/linux/mlx5/driver.h: In function
> > > ‘mlx5_get_vector_affinity_hint’:
> > > include/linux/mlx5/driver.h:1299:13: error:
> > > ‘struct irq_desc’ has no member named ‘affinity_hint’
> > >
> > > Note that this is the only use of affinity_hint outside
> > > kernel/irq.
> > > Don't other drivers have similar problems ?
> >
> > Aside of that.
> >
> > > > static inline const struct cpumask *
> > > > -mlx5_get_vector_affinity(struct mlx5_core_dev *dev, int
> > > > vector)
> > > > +mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int
> > > > vector)
> > > > {
> > > > - const struct cpumask *mask;
> > > > struct irq_desc *desc;
> > > > unsigned int irq;
> > > > int eqn;
> > > > int err;
> > > >
> > > > - err = mlx5_vector2eqn(dev, MLX5_EQ_VEC_COMP_BASE +
> > > > vector, &eqn, &irq);
> > > > + err = mlx5_vector2eqn(dev, vector, &eqn, &irq);
> > > > if (err)
> > > > return NULL;
> > > >
> > > > desc = irq_to_desc(irq);
> > > > -#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK
> > > > - mask = irq_data_get_effective_affinity_mask(&desc-
> > > > >irq_data);
> > > > -#else
> > > > - mask = desc->irq_common_data.affinity;
> > > > -#endif
> > > > - return mask;
> > > > + return desc->affinity_hint;
> >
> > NAK.
> >
>
> The offending patch is upstream, breaking non-SMP test builds, and I
> have
> not seen any feedback from the submitter. Any suggestion how to
> proceed ?
>
> Guenter
>
> >
>
Hi Guenter and Thomas,
Max and Israel are handling this internally to find a solution that
provides the needed functionality for rdma and addresses your comments.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Jakub Kicinski @ 2018-05-09 23:15 UTC (permalink / raw)
To: Michael Chan, Or Gerlitz; +Cc: davem, netdev
In-Reply-To: <1525864903-32619-2-git-send-email-michael.chan@broadcom.com>
On Wed, 9 May 2018 07:21:41 -0400, Michael Chan wrote:
> VF Queue resources are always limited and there is currently no
> infrastructure to allow the admin. on the host to add or reduce queue
> resources for any particular VF. With ever increasing number of VFs
> being supported, it is desirable to allow the admin. to configure queue
> resources differently for the VFs. Some VFs may require more or fewer
> queues due to different bandwidth requirements or different number of
> vCPUs in the VM. This patch adds the infrastructure to do that by
> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
> to the net_device_ops.
>
> Four parameters are exposed for each VF:
>
> o min_tx_queues - Guaranteed or current tx queues assigned to the VF.
This muxing of semantics may be a little awkward and unnecessary, would
it make sense for struct ifla_vf_info to have a separate fields for
current number of queues and the admin-set guaranteed min?
Is there a real world use case for the min value or are you trying to
make the API feature complete?
> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
> available to the VF.
>
> o min_rx_queues - Guaranteed or current rx queues assigned to the VF.
>
> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
> available to the VF.
>
> The "ip link set" command will subsequently be patched to support the new
> operation to set the above parameters.
>
> After the admin. makes a change to the above parameters, the corresponding
> VF will have a new range of channels to set using ethtool -L.
>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
In switchdev mode we can use number of queues on the representor as a
proxy for max number of queues allowed for the ASIC port. This works
better when representors are muxed in the first place than when they
have actual queues backing them. WDYT about such scheme, Or? A very
pleasant side-effect is that one can configure qdiscs and get stats
per-HW queue.
^ permalink raw reply
* Proposal
From: Zeliha Omer Faruk @ 2018-05-09 23:04 UTC (permalink / raw)
--
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* Re: [PATCH v6 05/13] firmware_loader: enhance Kconfig documentation over FW_LOADER
From: Kees Cook @ 2018-05-09 23:01 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Andrew Morton, Josh Triplett, maco, Andy Gross,
David Brown, bjorn.andersson, Tom Gundersen, wagi, Hans de Goede,
Andres Rodriguez, Mimi Zohar, Jakub Kicinski, Shuah Khan,
Martin Fuzzey, David Howells, pali.rohar, Takashi Iwai,
Kalle Valo, Arend van Spriel, Rafał Miłecki,
Nicolas Broeking
In-Reply-To: <20180509205544.GW27853@wotan.suse.de>
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
>> On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>> > + This used to be the default firmware loading facility, and udev used
>> > + to listen for uvents to load firmware for the kernel. The firmware
>> > + loading facility functionality in udev has been removed, as such it
>> > + can no longer be relied upon as a fallback mechanism. Linux no longer
>> > + relies on or uses a fallback mechanism in userspace. If you need to
>> > + rely on one refer to the permissively licensed firmwared:
>>
>> Typo: firmware
>
> Thanks fixed all typos except this one, this one is meant to be firmwared as
> that is the name of the project, the url is below.
>
>>
>> > +
>> > + https://github.com/teg/firmwared
Oh! Yes, hah. :) Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: sync tools bpf.h uapi header
From: Daniel Borkmann @ 2018-05-09 22:59 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov; +Cc: David S . Miller, netdev
In-Reply-To: <20180509020459.6564-1-bhole_prashant_q7@lab.ntt.co.jp>
On 05/09/2018 04:04 AM, Prashant Bhole wrote:
> sync the header from include/uapi/linux/bpf.h which was updated to add
> fib lookup helper function. This fixes selftests/bpf build failure
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
> tools/include/uapi/linux/bpf.h | 84 +++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 83 insertions(+), 1 deletion(-)
This doesn't apply cleanly to bpf-next, please respin.
^ permalink raw reply
* Re: [PATCH v4 0/2] selftests/bpf
From: Daniel Borkmann @ 2018-05-09 22:56 UTC (permalink / raw)
To: Sirio Balmelli; +Cc: netdev
In-Reply-To: <20180508133544.6kwfglryatxkzatp@vm4>
On 05/08/2018 03:35 PM, Sirio Balmelli wrote:
> Review of v3 patch much appreciated.
>
> Respun the series to omit the Makefile include, will work on
> a separate patch for that;
> replied to the v3 thread with queries specific to the include issue.
>
> best,
>
> Sirio
>
> Sirio Balmelli (2):
> selftests/bpf: add architecture-agnostic headers
> selftests/bpf: ignore build products
>
> tools/bpf/bpftool/.gitignore | 3 +++
> tools/include/uapi/asm/bitsperlong.h | 18 ++++++++++++++++++
> tools/include/uapi/asm/errno.h | 17 +++++++++++++++++
> tools/testing/selftests/bpf/.gitignore | 1 +
> 4 files changed, 39 insertions(+)
> create mode 100644 tools/bpf/bpftool/.gitignore
> create mode 100644 tools/include/uapi/asm/bitsperlong.h
> create mode 100644 tools/include/uapi/asm/errno.h
Applied to bpf-next, thanks Sirio!
^ permalink raw reply
* Re: [PATCH bpf-next v5 3/4] bpf: selftest additions for SOCKHASH
From: Daniel Borkmann @ 2018-05-09 22:53 UTC (permalink / raw)
To: John Fastabend, borkmann, ast; +Cc: netdev
In-Reply-To: <1525562710-11603-4-git-send-email-john.fastabend@gmail.com>
Hi John,
On 05/06/2018 01:25 AM, John Fastabend wrote:
> This runs existing SOCKMAP tests with SOCKHASH map type. To do this
> we push programs into include file and build two BPF programs. One
> for SOCKHASH and one for SOCKMAP.
>
> We then run the entire test suite with each type.
>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> Acked-by: David S. Miller <davem@davemloft.net>
[...]
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 9d76218..28316f1 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -33,7 +33,7 @@ TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test
> sample_map_ret0.o test_tcpbpf_kern.o test_stacktrace_build_id.o \
> sockmap_tcp_msg_prog.o connect4_prog.o connect6_prog.o test_adjust_tail.o \
> test_btf_haskv.o test_btf_nokv.o test_sockmap_kern.o test_tunnel_kern.o \
> - test_get_stack_rawtp.o
> + test_get_stack_rawtp.o test_sockmap_kern.o test_sockhash_kern.o
>
> # Order correspond to 'make run_tests' order
> TEST_PROGS := test_kmod.sh \
> diff --git a/tools/testing/selftests/bpf/test_sockhash_kern.c b/tools/testing/selftests/bpf/test_sockhash_kern.c
> new file mode 100644
> index 0000000..3bf4ad4
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/test_sockhash_kern.c
> @@ -0,0 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 Covalent IO, Inc. http://covalent.io
> +#define TEST_MAP_TYPE BPF_MAP_TYPE_SOCKHASH
> +#include "./test_sockmap_kern.h"
> diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c
> index 29c022d..df7afc7 100644
> --- a/tools/testing/selftests/bpf/test_sockmap.c
> +++ b/tools/testing/selftests/bpf/test_sockmap.c
> @@ -47,7 +47,8 @@
> #define S1_PORT 10000
> #define S2_PORT 10001
>
> -#define BPF_FILENAME "test_sockmap_kern.o"
> +#define BPF_SOCKMAP_FILENAME "test_sockmap_kern.o"
> +#define BPF_SOCKHASH_FILENAME "test_sockmap_kern.o"
Is this testing the right thing? Shouldn't above BPF_SOCKHASH_FILENAME say "test_sockhash_kern.o"
in order to select the correct BPF prog for hashmap? Seems here we're testing sock/arraymap twice.
> #define CG_PATH "/sockmap"
>
[...]
> +static int test_suite(void)
> +{
> + int err;
> +
> + err = __test_suite(BPF_SOCKMAP_FILENAME);
> + if (err)
> + goto out;
> + err = __test_suite(BPF_SOCKHASH_FILENAME);
> +out:
> + return err;
> +}
> +
Thanks,
Daniel
^ permalink raw reply
* Re: libbpf backward compatibility (was: [PATCH bpf-next v5 09/10] bpf: btf: Add BTF support to libbpf)
From: Jakub Kicinski @ 2018-05-09 22:20 UTC (permalink / raw)
To: Martin KaFai Lau, Alexei Starovoitov, Daniel Borkmann,
Andrey Ignatov
Cc: netdev, kernel-team, David Beckett
In-Reply-To: <20180509151712.7d6826f7@cakuba.netronome.com>
On Wed, 9 May 2018 15:17:12 -0700, Jakub Kicinski wrote:
> On Wed, 18 Apr 2018 15:56:05 -0700, Martin KaFai Lau wrote:
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index 39f6a0d64a3b..01bda076310f 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -26,6 +26,20 @@
> > #include <linux/bpf.h>
> > #include <stddef.h>
> >
> > +struct bpf_create_map_attr {
> > + const char *name;
> > + enum bpf_map_type map_type;
> > + __u32 map_flags;
> > + __u32 key_size;
> > + __u32 value_size;
> > + __u32 max_entries;
> > + __u32 numa_node;
> > + __u32 btf_fd;
> > + __u32 btf_key_id;
> > + __u32 btf_value_id;
> > +};
> > +
> > +int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr);
> > int bpf_create_map_node(enum bpf_map_type map_type, const char *name,
> > int key_size, int value_size, int max_entries,
> > __u32 map_flags, int node);
> > @@ -87,4 +101,6 @@ int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len);
> > int bpf_prog_query(int target_fd, enum bpf_attach_type type, __u32 query_flags,
> > __u32 *attach_flags, __u32 *prog_ids, __u32 *prog_cnt);
> > int bpf_raw_tracepoint_open(const char *name, int prog_fd);
> > +int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf, __u32 log_buf_size,
> > + bool do_log);
> > #endif
>
> Does libbpf have to provide backward compatibility? Are the function
> prototypes not supposed to change?
>
> Recently a number of *_xattr functions were added, these are nice for
> limiting the number of parameters passed to functions, but they don't
> buy us anything in terms of extensibility unless we can grow the
> structures. Should structure size be passed in as one of parameters?
Or is the backward compatibility not at the binary level so we can grow
the structures at will?
^ 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