* [PATCH net-next] net: ipv6: send unsolicited NA if enabled for all interfaces
From: David Ahern @ 2017-04-19 19:05 UTC (permalink / raw)
To: netdev; +Cc: hannes, David Ahern
When arp_notify is set to 1 for either a specific interface or for 'all'
interfaces, gratuitous arp requests are sent. Since ndisc_notify is the
ipv6 equivalent to arp_notify, it should follow the same semantics.
Commit 4a6e3c5def13 sends the NA on admin up. The final piece is checking
devconf_all->ndisc_notify in addition to the per device setting. Add it.
Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer address change")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/ndisc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index b23822e64228..d310dc41209a 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1753,7 +1753,8 @@ static int ndisc_netdev_event(struct notifier_block *this, unsigned long event,
idev = in6_dev_get(dev);
if (!idev)
break;
- if (idev->cnf.ndisc_notify)
+ if (idev->cnf.ndisc_notify ||
+ net->ipv6.devconf_all->ndisc_notify)
ndisc_send_unsol_na(dev);
in6_dev_put(idev);
break;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] sh_eth: unmap DMA buffers when freeing rings
From: Sergei Shtylyov @ 2017-04-19 19:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-renesas-soc, horms
In-Reply-To: <20170417.161051.805859402797991771.davem@redhat.com>
On 04/17/2017 11:10 PM, David Miller wrote:
>> The DMA API debugging (when enabled) causes:
>>
>> WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519 add_dma_entry+0xe0/0x12c
>> DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d
>>
>> to be printed after repeated initialization of the Ether device, e.g.
>> suspend/resume or 'ifconfig' up/down. This is because DMA buffers mapped
>> using dma_map_single() in sh_eth_ring_format() and sh_eth_start_xmit() are
>> never unmapped. Resolve this problem by unmapping the buffers when freeing
>> the descriptor rings; in order to do it right, we'd have to add an extra
>> parameter to sh_eth_txfree() (we rename this function to sh_eth_tx_free(),
>> while at it).
>>
>> Based on the commit a47b70ea86bd ("ravb: unmap descriptors when freeing
>> rings").
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Applied, thanks.
Please don;t forget to send it to -stable.
The bug seems to be there from the very beginning.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] sh_eth: unmap DMA buffers when freeing rings
From: Sergei Shtylyov @ 2017-04-19 19:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-renesas-soc, horms
In-Reply-To: <20170417.161051.805859402797991771.davem@redhat.com>
On 04/17/2017 11:10 PM, David Miller wrote:
>> The DMA API debugging (when enabled) causes:
>>
>> WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519 add_dma_entry+0xe0/0x12c
>> DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d
>>
>> to be printed after repeated initialization of the Ether device, e.g.
>> suspend/resume or 'ifconfig' up/down. This is because DMA buffers mapped
>> using dma_map_single() in sh_eth_ring_format() and sh_eth_start_xmit() are
>> never unmapped. Resolve this problem by unmapping the buffers when freeing
>> the descriptor rings; in order to do it right, we'd have to add an extra
>> parameter to sh_eth_txfree() (we rename this function to sh_eth_tx_free(),
>> while at it).
>>
>> Based on the commit a47b70ea86bd ("ravb: unmap descriptors when freeing
>> rings").
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Applied, thanks.
Please don't forget to send this to -stable.
The bug seems to be there from the very beginning.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: send unsolicited NA if enabled for all interfaces
From: Sergei Shtylyov @ 2017-04-19 19:30 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: hannes
In-Reply-To: <1492628736-26696-1-git-send-email-dsa@cumulusnetworks.com>
Hello!
On 04/19/2017 10:05 PM, David Ahern wrote:
> When arp_notify is set to 1 for either a specific interface or for 'all'
> interfaces, gratuitous arp requests are sent. Since ndisc_notify is the
> ipv6 equivalent to arp_notify, it should follow the same semantics.
> Commit 4a6e3c5def13 sends the NA on admin up. The final piece is checking
Need to also specify the commit summary line enclosed into (""), just like
below.
> devconf_all->ndisc_notify in addition to the per device setting. Add it.
>
> Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer address change")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201
From: Bjørn Mork @ 2017-04-19 19:39 UTC (permalink / raw)
To: Aleksander Morgado
Cc: Daniele Palmas, netdev@vger.kernel.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAAP7ucL0KLCxVSaO4Vf0LH=T7vRCtm5R2p9VFov+5V0OJF8Xcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Aleksander Morgado <aleksander-Dvg4H30XQSRVIjRurl1/8g@public.gmane.org> writes:
> On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>>> as a side note in latest kernels I had troubles with qmi devices
>>> (e.g. I/O error when using qmicli).
>>>
>>> I found your suggestion in libqmi mailing list to revert commit
>>>
>>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>>> cdc-wdm: fix "out-of-sync" due to missing notifications
>>
>> I guess a revert of that commit should be done then..
>>
>> I have been stalling because I have been hoping to replace it with a
>> better fix instead of a plain revert. I believe there are several issues
>> playing badly together here. That commit was _expected_ to cause
>> spurious EPIPE errors, which would be translated to EIO if they were
>> propagated. But they should be filtered out rightaway, in theory. This
>> works for me. I can see the EPIPEs with debugging, but I have never
>> seen any EIO from read.
>>
>> And there is the problem: I am unable to reproduce this problem. I have
>> previously tested this back and forth with several MDM9200 and MDM9235
>> generation modems in QMI mode, as well as in MBIM mode. And also with a
>> number of other MBIM modems. Aleksander reported that he could
>> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
>> not with any MDM9x00 or MDM9x35 modem. So I have now tried any way I
>> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
>> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>>
>> But unfortunately the testing is still without "success". It plain
>> works for me, every time, using ModemManager, qmicli with or without
>> proxy, or uqmi.
>>
>> Would you mind describing in detail how you trigger the EIOs? What
>> software and command sequence are you using? Does it reliably reproduce
>> the issue, or do you have to try several times? What modem chipset and
>> firmware is used?
>
> Reliably, as in the second command I sent already showed the issue :/
> I meant to try to debug this issue myself a while ago, but got busy
> with other stuff, as usual... This is with a Sierra Wireless MC7304
> running SWI9X15C_05.05.67.00. If you want, I can give you SSH access
> to a system with this modem plugged in, or I can even send you a spare
> MC7354, whatever you prefer.
I don't think another modem would help. The EM7305 should be the same
as an.MC7304 or MC7354 in this regard.
And the ssh access would only help if I knew what to look for. I think
you can do this just as well as me...
> I'm just running --dms-get-operating-mode multiple times, and getting
> errors frequently:
>
> aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
> /dev/cdc-wdm3 --dms-get-operating-mode
> [/dev/cdc-wdm3] Operating mode retrieved:
> Mode: 'online'
> HW restricted: 'no'
>
> aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
> /dev/cdc-wdm3 --dms-get-operating-mode
> [19 abr 2017, 20:25:36] -Warning ** Error reading from istream: Error
> reading from file descriptor: Input/output error
> ^[[A^Ccancelling the operation...
> error: couldn't create client for the 'dms' service: Operation was cancelled
Lucky you :)
I upgraded the EM7305 to SWI9X15C_05.05.67.00 and tried again. No
difference. I ran
for i in `seq 1 1000`; do qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode; done
without a single error. I guess I'll go for the revert.
But I think we need to do something about commit c1da59dad0eb as
well. It can end up calling usb_submit_urb(desc->response, GFP_KERNEL)
from an URB callback. And making the rerr update conditional doesn't
seem right either. It changes the meaning of rerr from "last status" to
"first error", which means that any error will mask a later success
until userspace reads the error. That's fishy.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
From: Joe Perches @ 2017-04-19 19:41 UTC (permalink / raw)
To: Matthias Kaehlcke, Pablo Neira Ayuso, Jozsef Kadlecsik,
David S . Miller
Cc: netfilter-devel, coreteam, netdev, linux-kernel, Grant Grundler,
Greg Hackmann, Michael Davidson
In-Reply-To: <20170419183920.21936-1-mka@chromium.org>
On Wed, 2017-04-19 at 11:39 -0700, Matthias Kaehlcke wrote:
> Not all parameters passed to ctnetlink_parse_tuple() and
> ctnetlink_exp_dump_tuple() match the enum type in the signatures of these
> functions.
Maybe that should be changed/fixed.
> Since this is intended change the argument type of to be an int
> value.
u32 is not int, it's unsigned int
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> net/netfilter/nf_conntrack_netlink.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> index dc7dfd68fafe..775eb5d9165b 100644
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -1006,9 +1006,8 @@ static const struct nla_policy tuple_nla_policy[CTA_TUPLE_MAX+1] = {
>
> static int
> ctnetlink_parse_tuple(const struct nlattr * const cda[],
> - struct nf_conntrack_tuple *tuple,
> - enum ctattr_type type, u_int8_t l3num,
> - struct nf_conntrack_zone *zone)
> + struct nf_conntrack_tuple *tuple, u32 type,
> + u_int8_t l3num, struct nf_conntrack_zone *zone)
> {
> struct nlattr *tb[CTA_TUPLE_MAX+1];
> int err;
> @@ -2443,7 +2442,7 @@ static struct nfnl_ct_hook ctnetlink_glue_hook = {
>
> static int ctnetlink_exp_dump_tuple(struct sk_buff *skb,
> const struct nf_conntrack_tuple *tuple,
> - enum ctattr_expect type)
> + u32 type)
> {
> struct nlattr *nest_parms;
>
^ permalink raw reply
* [PATCH net v3] bridge: ebtables: fix reception of frames DNAT-ed to bridge device/port
From: Linus Lüssing @ 2017-04-19 19:47 UTC (permalink / raw)
To: netdev
Cc: bridge, linux-kernel, coreteam, netfilter-devel, Jozsef Kadlecsik,
David S . Miller, Pablo Neira Ayuso
When trying to redirect bridged frames to the bridge device itself or
a bridge port (brouting) via the dnat target then this currently fails:
The ethernet destination of the frame is dnat'ed to the MAC address of
the bridge device or port just fine. However, the IP code drops it in
the beginning of ip_input.c/ip_rcv() as the dnat target left
the skb->pkt_type as PACKET_OTHERHOST.
Fixing this by resetting skb->pkt_type to an appropriate type after
dnat'ing.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
Changelog v3:
- moved pkt_type fixup into ebtable dnat code
-> v1/v2 only fixed it for prerouting/dnat so far, now tested
and verified that v3 fixes it for brouting/dnat, too
- updated commit message
Changelog v2:
- refrain from altering pkt_type for multicast packets
with a unicast destination MAC
---
net/bridge/netfilter/ebt_dnat.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/net/bridge/netfilter/ebt_dnat.c b/net/bridge/netfilter/ebt_dnat.c
index 4e0b0c3..21acb53 100644
--- a/net/bridge/netfilter/ebt_dnat.c
+++ b/net/bridge/netfilter/ebt_dnat.c
@@ -9,6 +9,7 @@
*/
#include <linux/module.h>
#include <net/sock.h>
+#include "../br_private.h"
#include <linux/netfilter.h>
#include <linux/netfilter/x_tables.h>
#include <linux/netfilter_bridge/ebtables.h>
@@ -18,11 +19,32 @@ static unsigned int
ebt_dnat_tg(struct sk_buff *skb, const struct xt_action_param *par)
{
const struct ebt_nat_info *info = par->targinfo;
+ struct net_device *dev;
if (!skb_make_writable(skb, 0))
return EBT_DROP;
ether_addr_copy(eth_hdr(skb)->h_dest, info->mac);
+
+ if (is_multicast_ether_addr(info->mac)) {
+ if (is_broadcast_ether_addr(info->mac))
+ skb->pkt_type = PACKET_BROADCAST;
+ else
+ skb->pkt_type = PACKET_MULTICAST;
+ } else {
+ rcu_read_lock();
+ if (xt_hooknum(par) != NF_BR_BROUTING)
+ dev = br_port_get_rcu(xt_in(par))->br->dev;
+ else
+ dev = xt_in(par);
+
+ if (ether_addr_equal(info->mac, dev->dev_addr))
+ skb->pkt_type = PACKET_HOST;
+ else
+ skb->pkt_type = PACKET_OTHERHOST;
+ rcu_read_unlock();
+ }
+
return info->target;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
From: Matthias Kaehlcke @ 2017-04-19 19:59 UTC (permalink / raw)
To: Joe Perches
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, David S . Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Grant Grundler,
Greg Hackmann, Michael Davidson
In-Reply-To: <1492630870.30293.3.camel@perches.com>
El Wed, Apr 19, 2017 at 12:41:10PM -0700 Joe Perches ha dit:
> On Wed, 2017-04-19 at 11:39 -0700, Matthias Kaehlcke wrote:
> > Not all parameters passed to ctnetlink_parse_tuple() and
> > ctnetlink_exp_dump_tuple() match the enum type in the signatures of these
> > functions.
>
> Maybe that should be changed/fixed.
Please see the previous discussion at
http://www.spinics.net/lists/netfilter-devel/msg47540.html
> > Since this is intended change the argument type of to be an int
> > value.
>
> u32 is not int, it's unsigned int
I would argue that an unsigned int is an int(eger) and considered it
an unnecessary detail for the commit message to be explicit. I can
change it if others deem it incorrect.
Cheers
Matthias
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > net/netfilter/nf_conntrack_netlink.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> > index dc7dfd68fafe..775eb5d9165b 100644
> > --- a/net/netfilter/nf_conntrack_netlink.c
> > +++ b/net/netfilter/nf_conntrack_netlink.c
> > @@ -1006,9 +1006,8 @@ static const struct nla_policy tuple_nla_policy[CTA_TUPLE_MAX+1] = {
> >
> > static int
> > ctnetlink_parse_tuple(const struct nlattr * const cda[],
> > - struct nf_conntrack_tuple *tuple,
> > - enum ctattr_type type, u_int8_t l3num,
> > - struct nf_conntrack_zone *zone)
> > + struct nf_conntrack_tuple *tuple, u32 type,
> > + u_int8_t l3num, struct nf_conntrack_zone *zone)
> > {
> > struct nlattr *tb[CTA_TUPLE_MAX+1];
> > int err;
> > @@ -2443,7 +2442,7 @@ static struct nfnl_ct_hook ctnetlink_glue_hook = {
> >
> > static int ctnetlink_exp_dump_tuple(struct sk_buff *skb,
> > const struct nf_conntrack_tuple *tuple,
> > - enum ctattr_expect type)
> > + u32 type)
> > {
> > struct nlattr *nest_parms;
> >
^ permalink raw reply
* Re: XDP question: best API for returning/setting egress port?
From: Andy Gospodarek @ 2017-04-19 20:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, Alexei Starovoitov,
netdev@vger.kernel.org, xdp-newbies@vger.kernel.org,
John Fastabend
In-Reply-To: <20170418215856.5fda7127@redhat.com>
On Tue, Apr 18, 2017 at 09:58:56PM +0200, Jesper Dangaard Brouer wrote:
>
> As I argued in NetConf presentation[1] (from slide #9) we need a port
> mapping table (instead of using ifindex'es). Both for supporting
> other "port" types than net_devices (think sockets), and for
> sandboxing what XDP can bypass.
>
> I want to create a new XDP action called XDP_REDIRECT, that instruct
> XDP to send the xdp_buff to another "port" (get translated into a
> net_device, or something else depending on internal port type).
>
> Looking at the userspace/eBPF interface, I'm wondering what is the
> best API for "returning" this port number from eBPF?
>
> The options I see is:
>
> 1) Split-up the u32 action code, and e.g let the high-16-bit be the
> port number and lower-16bit the (existing) action verdict.
>
> Pros: Simple API
> Cons: Number of ports limited to 64K
Practically speaking this may be seem reserving 64k for the port number
might be enough space, but I would also like to see a new return option
for flags so I start to get concerned about space. Daniel also
hightlights the fact that encoding the port in the action may does not
leave room for flags and could get confusing.
One unfortunate side-effect of dropping or transmitting frames with XDP
is that we lose the opportunity to statistically sample in netfilter
since the frames were dropped so early and I'd like to bring that back
with a call to parse flags and possibly call psample_sample_packet()
after the xdp action. Packet sampling cannot simply be an action
since there are times when a frame should be dropped but should also be
sampled, so it seems logical to add this as a flag.
>
> 2) Extend both xdp_buff + xdp_md to contain a (u32) port number, allow
> eBPF to update xdp_md->port.
>
> Pros: Larger number of ports.
> Cons: This require some ebpf translation steps between xdp_buff <-> xdp_md.
> (see xdp_convert_ctx_access)
I think I would lean towards this based on the fact that I'd like to see
a flags field added to the u32 return (maybe the top 8 bits) as
mentioned above.
So if we follow down this path and add a 'dest' field to xdp_buff and
xdp_md like this:
struct xdp_buff {
void *data;
void *data_end;
void *data_hard_start;
__u32 dest;
};
struct xdp_md {
__u32 data;
__u32 data_end;
__u32 dest;
};
and then lookup this dest in a table we have the option to make that
dest an ifindex/socket/other.
I did also look at JohnF's patch and I do like the simplicity of the redirect
action and new ndo_xdp_xmit and how it moves towards a way to transmit the
frame. The downside is that it presumes an ifindex, so it might not be ideal
we want the lookup to return something other than an ifindex.
Before aligning on a direction for the return values from exiting xdp
call, it seems like we should also think about the tx side and how that
would be handled. If we are ultimately going to need a new netdev op to
handle the redirect then what may be the issue with not providing the
destination port the return code and the option proposed by JohnF looks
good to me with maybe a small tweak to not presume ifindex in some manner.
JohnF, any test results with this you can share? Presumably you tested with
virtio-net, right?
>
> 3) Extend only xdp_buff and create bpf_helper that set port in xdp_buff.
>
> Pros: Hides impl details, and allows helper to give eBPF code feedback
> (on e.g. if port doesn't exist any longer)
> Cons: Helper function call likely slower?
>
>
> (Cc'ed xdp-newbies as end-users might have an opinion on UAPI?)
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>
> [1] http://people.netfilter.org/hawk/presentations/NetConf2017/xdp_work_ahead_NetConf_April_2017.pdf
^ permalink raw reply
* Re: [PATCH] ieee802154: don't select COMMON_CLK
From: Marcel Holtmann @ 2017-04-19 20:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexander Aring, Stefan Schmidt, Harry Morris, linux-wpan, netdev,
linux-kernel
In-Reply-To: <20170419173233.3726121-1-arnd@arndb.de>
Hi Arnd,
> A device driver must not select the COMMON_CLK subsystem, as that conflicts
> with platforms that provide a legacy implementation of the clk API:
>
> drivers/clk/clk.o: In function `clk_enable':
> clk.c:(.text.clk_enable+0x0): multiple definition of `clk_enable'
> arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_enable+0x0): first defined here
> drivers/clk/clk.o: In function `clk_round_rate':
> clk.c:(.text.clk_round_rate+0x0): multiple definition of `clk_round_rate'
> arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_round_rate+0x0): first defined here
> drivers/clk/clk.o: In function `clk_get_parent':
> clk.c:(.text.clk_get_parent+0x0): multiple definition of `clk_get_parent'
> arch/arm/mach-sa1100/clock.o:clock.c:(.text.clk_get_parent+0x0): first defined here
> drivers/clk/clk.o: In function `clk_get_rate':
> clk.c:(.text.clk_get_rate+0x0): multiple definition of `clk_get_rate'
>
> This changes the 'select' into 'depends on', as all other similar drivers do.
>
> Fixes: d931acd575d6 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ieee802154/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [patch] socket.7: Document SO_INCOMING_CPU
From: Eric Dumazet @ 2017-04-19 20:13 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Francois Saint-Jacques, linux-man-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <326b99c3-cc86-3abd-1069-2b3a52d9ba47-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, 2017-04-19 at 20:48 +0200, Michael Kerrisk (man-pages) wrote:
> Hi Eric,
>
> [reodering for clarity]
>
> >> On 02/19/2017 09:55 PM, Michael Kerrisk (man-pages) wrote:
> >>> [CC += Eric, so that he might review]
> >>>
> >>> Hello Francois,
> >>>
> >>> On 02/18/2017 05:06 AM, Francois Saint-Jacques wrote:
> >>>> This socket option is undocumented. Applies on the latest version
> >>>> (man-pages-4.09-511).
> >>>>
> >>>> diff --git a/man7/socket.7 b/man7/socket.7
> >>>> index 3efd7a5d8..1a3ffa253 100644
> >>>> --- a/man7/socket.7
> >>>> +++ b/man7/socket.7
> >>>> @@ -490,6 +490,26 @@ flag on a socket
> >>>> operation.
> >>>> Expects an integer boolean flag.
> >>>> .TP
> >>>> +.BR SO_INCOMING_CPU " (getsockopt since Linux 3.19, setsockopt since
> >>>> Linux 4.4)"
> >>>> +.\" getsocktop 2c8c56e15df3d4c2af3d656e44feb18789f75837
> >>>> +.\" setsocktop 70da268b569d32a9fddeea85dc18043de9d89f89
> >>>> +Sets or gets the cpu affinity of a socket. Expects an integer flag.
> >>>> +.sp
> >>>> +.in +4n
> >>>> +.nf
> >>>> +int cpu = 1;
> >>>> +socklen_t len = sizeof(cpu);
> >>>> +setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
> >>>> +.fi
> >>>> +.in
> >>>> +.sp
> >>>> +The typical use case is one listener per RX queue, as the associated listener
> >>>> +should only accept flows handled in softirq by the same cpu. This provides
> >>>> +optimal NUMA behavior and keep cpu caches hot.
> >>>> +.TP
> >>>> .B SO_KEEPALIVE
> >>>> Enable sending of keep-alive messages on connection-oriented sockets.
> >>>> Expects an integer boolean flag.
> >>>
> >>> Thank you! Patch applied.
> >>>
> >>> I have tried to enhance the description somewhat. I'm not sure whether
> >>> what I've written is quite correct (or whether it should be further
> >>> extended). Eric, could you please take a look at the following, and let
> >>> me know if anything needs fixing:
> >>>
> >>> SO_INCOMING_CPU (gettable since Linux 3.19, settable since Linux
> >>> 4.4)
> >>> Sets or gets the CPU affinity of a socket. Expects an
> >>> integer flag.
> >>>
> >>> int cpu = 1;
> >>> socklen_t len = sizeof(cpu);
> >>> setsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
> >>>
> >>> Because all of the packets for a single stream (i.e., all
> >>> packets for the same 4-tuple) arrive on the single RX queue
> >>> that is associated with a particular CPU, the typical use
> >>> case is to employ one listening process per RX queue, with
> >>> the incoming flow being handled by a listener on the same
> >>> CPU that is handling the RX queue. This provides optimal
> >>> NUMA behavior and keeps CPU caches hot.
>
> > Hi Michael
> >
> > Sorry for the delay.
>
> Thanks for the reply, but I think you are assuming I know more than
> I do. I'd like you to elaborate a little please. See below.
>
> > Note that setting the option is not supported if SO_REUSEPORT is used.
>
> Please define "not supported". Does this yield an API diagnostic?
> If so, what is it?
>
> > Socket will be selected from an array, either by a hash or BPF program
> > that has no access to this information.
>
> Sorry -- I'm lost here. How does this comment relate to the proposed
> man page text above?
Simply that :
If an application uses both SO_INCOMING_CPU and SO_REUSEPORT, then
SO_REUSEPORT logic, selecting the socket to receive the packet, ignores
SO_INCOMING_CPU setting.
This does not need to be documented, because it is an implementation
detail/bug that could be changed, if someone cares enough.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net] net/mlx5e: Race between mlx5e_update_stats() and getting the stats
From: Eric Dumazet @ 2017-04-19 20:24 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Saeed Mahameed, kernel-team
In-Reply-To: <20170419182936.788220-1-kafai@fb.com>
On Wed, 2017-04-19 at 11:29 -0700, Martin KaFai Lau wrote:
> We have observed a sudden spike in rx/tx_packets and rx/tx_bytes
> reported under /proc/net/dev. It seems there is a race in
> mlx5e_update_stats() and some of the get-stats functions (the
> one that we hit is the mlx5e_get_stats() which is called
> by ndo_get_stats64()).
>
> In particular, the very first thing mlx5e_update_sw_counters()
> does is 'memset(s, 0, sizeof(*s))'. For example, if mlx5e_get_stats()
> is unlucky at one point, rx_bytes and rx_packets could be 0. One second
> later, a normal (and much bigger than 0) value will be reported.
>
> This patch is not meant to be a proper fix. It merely tries
> to show what I have suspected and start the discussion.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Cc: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 7 +++++--
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 +++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> index a004a5a1a4c2..d24916f720bb 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> @@ -313,7 +313,6 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
> mutex_lock(&priv->state_lock);
> if (test_bit(MLX5E_STATE_OPENED, &priv->state))
> mlx5e_update_stats(priv);
> - mutex_unlock(&priv->state_lock);
>
> for (i = 0; i < NUM_SW_COUNTERS; i++)
> data[idx++] = MLX5E_READ_CTR64_CPU(&priv->stats.sw,
> @@ -378,8 +377,10 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
> data[idx++] = MLX5E_READ_CTR64_CPU(mlx5_priv->pme_stats.error_counters,
> mlx5e_pme_error_desc, i);
>
> - if (!test_bit(MLX5E_STATE_OPENED, &priv->state))
> + if (!test_bit(MLX5E_STATE_OPENED, &priv->state)) {
> + mutex_unlock(&priv->state_lock);
> return;
> + }
>
> /* per channel counters */
> for (i = 0; i < priv->params.num_channels; i++)
> @@ -393,6 +394,8 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
> for (j = 0; j < NUM_SQ_STATS; j++)
> data[idx++] = MLX5E_READ_CTR64_CPU(&priv->channel[i]->sq[tc].stats,
> sq_stats_desc, j);
> +
> + mutex_unlock(&priv->state_lock);
> }
>
> static u32 mlx5e_rx_wqes_to_packets(struct mlx5e_priv *priv, int rq_wq_type,
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 66c133757a5e..a4c100bea541 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -2748,6 +2748,8 @@ mlx5e_get_stats(struct net_device *dev, struct rtnl_link_stats64 *stats)
> struct mlx5e_vport_stats *vstats = &priv->stats.vport;
> struct mlx5e_pport_stats *pstats = &priv->stats.pport;
>
> + mutex_lock(&priv->state_lock);
> +
We can not sleep from ndo_get_stats() ( look at bonding driver )
What about the following ?
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 66c133757a5ee8daae122e93322306b1c5c44336..b9fea146a0ca18498a8dfa5698dca7dea06e3c5e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -174,7 +174,7 @@ static void mlx5e_tx_timeout_work(struct work_struct *work)
static void mlx5e_update_sw_counters(struct mlx5e_priv *priv)
{
- struct mlx5e_sw_stats *s = &priv->stats.sw;
+ struct mlx5e_sw_stats temp, *s = &temp;
struct mlx5e_rq_stats *rq_stats;
struct mlx5e_sq_stats *sq_stats;
u64 tx_offload_none = 0;
@@ -229,6 +229,8 @@ static void mlx5e_update_sw_counters(struct mlx5e_priv *priv)
s->link_down_events_phy = MLX5_GET(ppcnt_reg,
priv->stats.pport.phy_counters,
counter_set.phys_layer_cntrs.link_down_events);
+ /* A bit racy (depending on memcpy() sanity...) , we probably should use a spinlock */
+ memcpy(&priv->stats.sw, s, sizeof(*s));
}
static void mlx5e_update_vport_counters(struct mlx5e_priv *priv)
^ permalink raw reply related
* Re: [PATCH v4 net-next RFC] net: Generic XDP
From: Andy Gospodarek @ 2017-04-19 20:25 UTC (permalink / raw)
To: John Fastabend
Cc: Alexei Starovoitov, David Miller, michael.chan, netdev,
xdp-newbies
In-Reply-To: <58F7A21B.9060309@gmail.com>
On Wed, Apr 19, 2017 at 10:44:59AM -0700, John Fastabend wrote:
> On 17-04-19 10:17 AM, Alexei Starovoitov wrote:
> > On Wed, Apr 19, 2017 at 10:29:03AM -0400, Andy Gospodarek wrote:
> >>
> >> I ran this on top of a card that uses the bnxt_en driver on a desktop
> >> class system with an i7-6700 CPU @ 3.40GHz, sending a single stream of
> >> UDP traffic with flow control disabled and saw the following (all stats
> >> in Million PPS).
> >>
> >> xdp1 xdp2 xdp_tx_tunnel
> >> Generic XDP 7.8 5.5 (1.3 actual) 4.6 (1.1 actual)
> >> Optimized XDP 11.7 9.7 4.6
> >
> > Nice! Thanks for testing.
> >
> >> One thing to note is that the Generic XDP case shows some different
> >> results for reported by the application vs actual (seen on the wire). I
> >> did not debug where the drops are happening and what counter needs to be
> >> incremented to note this -- I'll add that to my TODO list. The
> >> Optimized XDP case does not have a difference in reported vs actual
> >> frames on the wire.
> >
> > The missed packets are probably due to xmit queue being full.
> > We need 'xdp_tx_full' counter in:
> > + if (free_skb) {
> > + trace_xdp_exception(dev, xdp_prog, XDP_TX);
> > + kfree_skb(skb);
> > + }
> > like in-driver xdp does.
> > It's surprising that tx becomes full so often. May be bnxt specific behavior?
>
> hmm as a data point I get better numbers than 1.3Mpps running through the qdisc
> layer with pktgen so seems like something is wrong with the driver perhaps? If
I get ~6.5Mpps on a single core with pktgen, so inconclusive for now....
> I get a chance I'll take a look with my setup here, although it likely wont be
> until the weekend. I don't think it needs to slow down dropping the RFC tag
> and getting the patch applied though.
>
> >
> >> I agree with all those who have asserted that this is great tool for
> >> those that want to get started with XDP but do not have hardware, so I'd
> >> say it's ready to have the 'RFC' tag dropped. Thanks for pushing this
> >> forward, Dave! :-)
> >
> > +1
> >
> >
>
^ permalink raw reply
* Re: [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-19 20:47 UTC (permalink / raw)
To: Adam Ford
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Johan Hedberg,
Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer, netdev,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAHCN7xLNcD1rmifEOyPhG2rpB_C81hsyzV9W2q6kCQkKa69sZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 17, 2017 at 3:11 PM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730. I
> have the Bluetooth set to 3000000 baud in pdata quirks. Looking at
> the binding, I don't see an option to set the baudrate. Is there (or
> will there) be a way to set the baud rate of the Bluetooth?
If you read hci_ti_probe, you will see it is already there. The
default is 3Mbps and the DT can override that with "max-speed". The
intent is that 3Mbps is the max the device can do and max-speed is
only for board or host limitations. Though I just checked the
datasheet on the 1835 and it can go up to 4364kbps. No datasheets for
wl1283, so I have no idea what the max is.
>> +static int hci_ti_probe(struct serdev_device *serdev)
>> +{
>> + struct hci_uart *hu;
>> + struct ll_device *lldev;
>> + u32 max_speed = 3000000;
[...]
>> + of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
>> + hci_uart_set_speeds(hu, 115200, max_speed);
^ permalink raw reply
* RE: [PATCH net-next] i40evf: hide unused variable
From: Keller, Jacob E @ 2017-04-19 20:47 UTC (permalink / raw)
To: Arnd Bergmann, Kirsher, Jeffrey T
Cc: Pujari, Bimmy, Duyck, Alexander H, Williams, Mitch A, Brady, Alan,
Joe Perches, Singhai, Anjali, Brandeburg, Jesse, Banala, Preethi,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170419173008.3648215-1-arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Wednesday, April 19, 2017 10:30 AM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>; Pujari, Bimmy
> <bimmy.pujari@intel.com>; Duyck, Alexander H
> <alexander.h.duyck@intel.com>; Williams, Mitch A
> <mitch.a.williams@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Brady,
> Alan <alan.brady@intel.com>; Joe Perches <joe@perches.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Brandeburg, Jesse <jesse.brandeburg@intel.com>;
> Banala, Preethi <preethi.banala@intel.com>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH net-next] i40evf: hide unused variable
>
> On architectures with larger pages, we get a warning about an unused variable:
>
> drivers/net/ethernet/intel/i40evf/i40evf_main.c: In function
> 'i40evf_configure_rx':
> drivers/net/ethernet/intel/i40evf/i40evf_main.c:690:21: error: unused variable
> 'netdev' [-Werror=unused-variable]
>
> This moves the declaration into the #ifdef to avoid the warning.
>
Makes sense.
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
> Fixes: dab86afdbbd1 ("i40e/i40evf: Change the way we limit the maximum frame
> size for Rx")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> index 12a930e879af..1bb13c864edd 100644
> --- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> +++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> @@ -687,13 +687,14 @@ static void i40evf_configure_tx(struct i40evf_adapter
> *adapter)
> static void i40evf_configure_rx(struct i40evf_adapter *adapter)
> {
> unsigned int rx_buf_len = I40E_RXBUFFER_2048;
> - struct net_device *netdev = adapter->netdev;
> struct i40e_hw *hw = &adapter->hw;
> int i;
>
> /* Legacy Rx will always default to a 2048 buffer size. */
> #if (PAGE_SIZE < 8192)
> if (!(adapter->flags & I40EVF_FLAG_LEGACY_RX)) {
> + struct net_device *netdev = adapter->netdev;
> +
> /* For jumbo frames on systems with 4K pages we have to use
> * an order 1 page, so we might as well increase the size
> * of our Rx buffer to make better use of the available space
> --
> 2.9.0
^ permalink raw reply
* [PATCH 1/1] netvsc: Deal with rescinded channels correctly
From: kys @ 2017-04-19 20:49 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang,
leann.ogasawara, marcelo.cerri, sthemmin
From: K. Y. Srinivasan <kys@microsoft.com>
We will not be able to send packets over a channel that has been
rescinded. Make necessary adjustments so we can properly cleanup
even when the channel is rescinded. This issue can be trigerred
in the NIC hot-remove path.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 7ab06b3..b5b10fc 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -135,6 +135,13 @@ static void netvsc_destroy_buf(struct hv_device *device)
sizeof(struct nvsp_message),
(unsigned long)revoke_packet,
VM_PKT_DATA_INBAND, 0);
+ /* If the failure is because the channel is rescinded;
+ * ignore the failure since we cannot send on a rescinded
+ * channel. This would allow us to properly cleanup
+ * even when the channel is rescinded.
+ */
+ if (device->channel->rescind)
+ ret = 0;
/*
* If we failed here, we might as well return and
* have a leak rather than continue and a bugchk
@@ -195,6 +202,15 @@ static void netvsc_destroy_buf(struct hv_device *device)
sizeof(struct nvsp_message),
(unsigned long)revoke_packet,
VM_PKT_DATA_INBAND, 0);
+
+ /* If the failure is because the channel is rescinded;
+ * ignore the failure since we cannot send on a rescinded
+ * channel. This would allow us to properly cleanup
+ * even when the channel is rescinded.
+ */
+ if (device->channel->rescind)
+ ret = 0;
+
/* If we failed here, we might as well return and
* have a leak rather than continue and a bugchk
*/
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-19 20:49 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, Johan Hedberg, Wei Xu, Eyal Reizer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:BLUETOOTH DRIVERS, Gustavo Padovan, Marcel Holtmann,
Satish Patel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
netdev
In-Reply-To: <CAHCN7x+G_jbQTDfyPBZ4Er8vz46tEojrWf29Eztq56c9zBnMeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Apr 16, 2017 at 9:09 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Apr 13, 2017 10:04 AM, "Rob Herring" <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35
> ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
>
>
> Would you expect the wl1283 chipset too?
Probably, but I left it out as there's no public information.
> I can help test this if you like after the holiday weekend. I have a board
> with WL1283 and currently using pdata-quirks to support it.
^ permalink raw reply
* RE: [PATCH 1/1] netvsc: Deal with rescinded channels correctly
From: KY Srinivasan @ 2017-04-19 20:52 UTC (permalink / raw)
To: KY Srinivasan, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com,
leann.ogasawara@canonical.comi, marcelo.cerri@canonical.com,
Stephen Hemminger
In-Reply-To: <1492634959-28942-1-git-send-email-kys@exchange.microsoft.com>
> -----Original Message-----
> From: kys@exchange.microsoft.com [mailto:kys@exchange.microsoft.com]
> Sent: Wednesday, April 19, 2017 1:49 PM
> To: davem@davemloft.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com;
> leann.ogasawara@canonical.comi; marcelo.cerri@canonical.com; Stephen
> Hemminger <sthemmin@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>
> Subject: [PATCH 1/1] netvsc: Deal with rescinded channels correctly
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> From: K. Y. Srinivasan <kys@microsoft.com>
>
> We will not be able to send packets over a channel that has been
> rescinded. Make necessary adjustments so we can properly cleanup
> even when the channel is rescinded. This issue can be trigerred
> in the NIC hot-remove path.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Dave,
Please drop this path; I will resend.
K. Y
> ---
> drivers/net/hyperv/netvsc.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 7ab06b3..b5b10fc 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -135,6 +135,13 @@ static void netvsc_destroy_buf(struct hv_device
> *device)
> sizeof(struct nvsp_message),
> (unsigned long)revoke_packet,
> VM_PKT_DATA_INBAND, 0);
> + /* If the failure is because the channel is rescinded;
> + * ignore the failure since we cannot send on a rescinded
> + * channel. This would allow us to properly cleanup
> + * even when the channel is rescinded.
> + */
> + if (device->channel->rescind)
> + ret = 0;
> /*
> * If we failed here, we might as well return and
> * have a leak rather than continue and a bugchk
> @@ -195,6 +202,15 @@ static void netvsc_destroy_buf(struct hv_device
> *device)
> sizeof(struct nvsp_message),
> (unsigned long)revoke_packet,
> VM_PKT_DATA_INBAND, 0);
> +
> + /* If the failure is because the channel is rescinded;
> + * ignore the failure since we cannot send on a rescinded
> + * channel. This would allow us to properly cleanup
> + * even when the channel is rescinded.
> + */
> + if (device->channel->rescind)
> + ret = 0;
> +
> /* If we failed here, we might as well return and
> * have a leak rather than continue and a bugchk
> */
> --
> 1.7.1
^ permalink raw reply
* [PATCH net-next 1/1] netvsc: Deal with rescinded channels correctly
From: kys @ 2017-04-19 20:53 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang,
leann.ogasawara, marcelo.cerri, sthemmin
From: K. Y. Srinivasan <kys@microsoft.com>
We will not be able to send packets over a channel that has been
rescinded. Make necessary adjustments so we can properly cleanup
even when the channel is rescinded. This issue can be trigerred
in the NIC hot-remove path.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 7ab06b3..b5b10fc 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -135,6 +135,13 @@ static void netvsc_destroy_buf(struct hv_device *device)
sizeof(struct nvsp_message),
(unsigned long)revoke_packet,
VM_PKT_DATA_INBAND, 0);
+ /* If the failure is because the channel is rescinded;
+ * ignore the failure since we cannot send on a rescinded
+ * channel. This would allow us to properly cleanup
+ * even when the channel is rescinded.
+ */
+ if (device->channel->rescind)
+ ret = 0;
/*
* If we failed here, we might as well return and
* have a leak rather than continue and a bugchk
@@ -195,6 +202,15 @@ static void netvsc_destroy_buf(struct hv_device *device)
sizeof(struct nvsp_message),
(unsigned long)revoke_packet,
VM_PKT_DATA_INBAND, 0);
+
+ /* If the failure is because the channel is rescinded;
+ * ignore the failure since we cannot send on a rescinded
+ * channel. This would allow us to properly cleanup
+ * even when the channel is rescinded.
+ */
+ if (device->channel->rescind)
+ ret = 0;
+
/* If we failed here, we might as well return and
* have a leak rather than continue and a bugchk
*/
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] bpf: add napi_id read access to __sk_buff
From: Daniel Borkmann @ 2017-04-19 21:01 UTC (permalink / raw)
To: davem; +Cc: edumazet, alexei.starovoitov, netdev, Daniel Borkmann
Add napi_id access to __sk_buff for socket filter program types, tc
program types and other bpf_convert_ctx_access() users. Having access
to skb->napi_id is useful for per RX queue listener siloing, f.e.
in combination with SO_ATTACH_REUSEPORT_EBPF and when busy polling is
used, meaning SO_REUSEPORT enabled listeners can then select the
corresponding socket at SYN time already [1]. The skb is marked via
skb_mark_napi_id() early in the receive path (e.g., napi_gro_receive()).
Currently, sockets can only use SO_INCOMING_NAPI_ID from 6d4339028b35
("net: Introduce SO_INCOMING_NAPI_ID") as a socket option to look up
the NAPI ID associated with the queue for steering, which requires a
prior sk_mark_napi_id() after the socket was looked up.
Semantics for the __sk_buff napi_id access are similar, meaning if
skb->napi_id is < MIN_NAPI_ID (e.g. outgoing packets using sender_cpu),
then an invalid napi_id of 0 is returned to the program, otherwise a
valid non-zero napi_id.
[1] http://netdevconf.org/2.1/slides/apr6/dumazet-BUSY-POLLING-Netdev-2.1.pdf
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/uapi/linux/bpf.h | 1 +
net/core/filter.c | 14 ++++++++++++++
tools/include/uapi/linux/bpf.h | 1 +
tools/testing/selftests/bpf/test_verifier.c | 3 +++
4 files changed, 19 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 1e062bb..e553529 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -603,6 +603,7 @@ struct __sk_buff {
__u32 tc_classid;
__u32 data;
__u32 data_end;
+ __u32 napi_id;
};
struct bpf_tunnel_key {
diff --git a/net/core/filter.c b/net/core/filter.c
index 19be954..70ff8c0 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -53,6 +53,7 @@
#include <net/dst_metadata.h>
#include <net/dst.h>
#include <net/sock_reuseport.h>
+#include <net/busy_poll.h>
/**
* sk_filter_trim_cap - run a packet through a socket filter
@@ -3202,6 +3203,19 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
*insn++ = BPF_MOV64_IMM(si->dst_reg, 0);
#endif
break;
+
+ case offsetof(struct __sk_buff, napi_id):
+#if defined(CONFIG_NET_RX_BUSY_POLL)
+ BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, napi_id) != 4);
+
+ *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->src_reg,
+ offsetof(struct sk_buff, napi_id));
+ *insn++ = BPF_JMP_IMM(BPF_JGE, si->dst_reg, MIN_NAPI_ID, 1);
+ *insn++ = BPF_MOV64_IMM(si->dst_reg, 0);
+#else
+ *insn++ = BPF_MOV64_IMM(si->dst_reg, 0);
+#endif
+ break;
}
return insn - insn_buf;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 1e062bb..e553529 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -603,6 +603,7 @@ struct __sk_buff {
__u32 tc_classid;
__u32 data;
__u32 data_end;
+ __u32 napi_id;
};
struct bpf_tunnel_key {
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index 6178b65..95a8d5f 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -772,6 +772,9 @@ struct test_val {
BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
offsetof(struct __sk_buff, vlan_tci)),
BPF_JMP_IMM(BPF_JGE, BPF_REG_0, 0, 0),
+ BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
+ offsetof(struct __sk_buff, napi_id)),
+ BPF_JMP_IMM(BPF_JGE, BPF_REG_0, 0, 0),
BPF_EXIT_INSN(),
},
.result = ACCEPT,
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Rob Herring @ 2017-04-19 21:06 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Apr 12, 2017 at 01:13:46PM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> syscon present in allwinner devices.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] net: arc_emac: switch to phy_start()/phy_stop()
From: Florian Fainelli @ 2017-04-19 21:08 UTC (permalink / raw)
To: Alexander Kochetkov, David S. Miller, Philippe Reynes, Peter Chen,
Wei Yongjun, netdev, linux-kernel
In-Reply-To: <1492612195-16601-1-git-send-email-al.kochet@gmail.com>
On 04/19/2017 07:29 AM, Alexander Kochetkov wrote:
> The patch replace phy_start_aneg() with phy_start(). phy_start() call
> phy_start_aneg() as a part of startup sequence and allow recover from
> error (PHY_HALTED) state.
>
> Also added call phy_stop() to arc_emac_remove() to stop PHY state machine
> when MAC is down.
This looks fine. If you wanted to go further, you could move the
phy_connect(), phy_disconnect() calls down to the arc_emac_open()
respectively arc_emac_stop() as this would also allow the PHY device to
be fully suspended when the interface is unused.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
> drivers/net/ethernet/arc/emac_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
> index abc9f2a..188676d 100644
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
> @@ -434,7 +434,7 @@ static int arc_emac_open(struct net_device *ndev)
> /* Enable EMAC */
> arc_reg_or(priv, R_CTRL, EN_MASK);
>
> - phy_start_aneg(ndev->phydev);
> + phy_start(ndev->phydev);
>
> netif_start_queue(ndev);
>
> @@ -556,6 +556,8 @@ static int arc_emac_stop(struct net_device *ndev)
> napi_disable(&priv->napi);
> netif_stop_queue(ndev);
>
> + phy_stop(ndev->phydev);
> +
> /* Disable interrupts */
> arc_reg_clr(priv, R_ENABLE, RXINT_MASK | TXINT_MASK | ERR_MASK);
>
>
--
Florian
^ permalink raw reply
* Re: [Intel-wired-lan] NFS over NAT causes e1000e transmit hangs
From: Florian Fainelli @ 2017-04-19 21:15 UTC (permalink / raw)
To: Neftin, Sasha, Eric Dumazet; +Cc: netdev, intel-wired-lan
In-Reply-To: <f79d2748-849e-acc6-5e5c-2dc82548fa69@intel.com>
On 04/19/2017 01:52 AM, Neftin, Sasha wrote:
> On 4/18/2017 22:05, Florian Fainelli wrote:
>> On 04/18/2017 12:03 PM, Eric Dumazet wrote:
>>> On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote:
>>>> Hi,
>>>>
>>>> I am using NFS over a NAT with two e1000e adapters and with eth1 being
>>>> the LAN interface and eth0 the WAN interface. The kernel is Ubuntu's
>>>> 16.10 kernel: 4.8.0-46-generic. The device doing NAT over NFS is just
>>>> mounting a remote folder and doing normal execution/file accesses. It's
>>>> enough to untar a file from this device onto a NFS share to expose the
>>>> problem.
>>>>
>>>> The transmit hangs look like the ones below, doing a rmmod/insmod does
>>>> not help eliminated the problem, nor does a power cycle. Stopping the
>>>> NFS over NAT definitively does let the adapter recover.
>>> Is this NFS over TCP or UDP ?
>> This is NFS over TCP mounted with the following:
>>
>> type nfs
>> (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=2049,timeo=70,retrans=3,sec=sys,local_lock=none,addr=X.X.X.X)
>>
>>
>> Thanks Eric!
>
> Please, try disable TCP segmentation offload: ethtool -K <adapter> tso off.
I am not able to reproduce the hangs with TSO turned off. Is there a
specific patch you would want me to try?
--
Florian
^ permalink raw reply
* Re: [PATCH] net: arc_emac: switch to phy_start()/phy_stop()
From: Alexander Kochetkov @ 2017-04-19 21:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S. Miller, Philippe Reynes, Peter Chen, Wei Yongjun, netdev,
linux-kernel
In-Reply-To: <5ed9e534-d134-2ba1-0276-0bc8bd949eb1@gmail.com>
> 20 апр. 2017 г., в 0:08, Florian Fainelli <f.fainelli@gmail.com> написал(а):
>
> This looks fine. If you wanted to go further, you could move the
> phy_connect(), phy_disconnect() calls down to the arc_emac_open()
> respectively arc_emac_stop() as this would also allow the PHY device to
> be fully suspended when the interface is unused.
I’ve checked patch phy_connect() is called from arc_emac_open() and
phy_disconnect() is called from arc_emac_stop().
So, I’ve made mistake in the commit message.
Thank you for review.
>
> 19 апр. 2017 г., в 21:22, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> написал(а):
>
> On 04/19/2017 05:29 PM, Alexander Kochetkov wrote:
>
>> The patch replace phy_start_aneg() with phy_start(). phy_start() call
>
> Replaces.
>
>> phy_start_aneg() as a part of startup sequence and allow recover from
>> error (PHY_HALTED) state.
>>
>> Also added call phy_stop() to arc_emac_remove() to stop PHY state machine
>
> To arc_emac_stop() maybe?
>
Sergei, thanks for spell and gramma checking.
Regards,
Alexander.
^ permalink raw reply
* [PATCH net] net: ipv6: RTF_PCPU should not be settable from userspace
From: David Ahern @ 2017-04-19 21:19 UTC (permalink / raw)
To: netdev; +Cc: kafai, andreyknvl, David Ahern
Andrey reported a fault in the IPv6 route code:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 1 PID: 4035 Comm: a.out Not tainted 4.11.0-rc7+ #250
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880069809600 task.stack: ffff880062dc8000
RIP: 0010:ip6_rt_cache_alloc+0xa6/0x560 net/ipv6/route.c:975
RSP: 0018:ffff880062dced30 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff8800670561c0 RCX: 0000000000000006
RDX: 0000000000000003 RSI: ffff880062dcfb28 RDI: 0000000000000018
RBP: ffff880062dced68 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff880062dcfb28 R14: dffffc0000000000 R15: 0000000000000000
FS: 00007feebe37e7c0(0000) GS:ffff88006cb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000205a0fe4 CR3: 000000006b5c9000 CR4: 00000000000006e0
Call Trace:
ip6_pol_route+0x1512/0x1f20 net/ipv6/route.c:1128
ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212
...
Andrey's syzkaller program passes rtmsg.rtmsg_flags with the RTF_PCPU bit
set. Flags passed to the kernel are blindly copied to the allocated
rt6_info by ip6_route_info_create making a newly inserted route appear
as though it is a per-cpu route. ip6_rt_cache_alloc sees the flag set
and expects rt->dst.from to be set - which it is not since it is not
really a per-cpu copy. The subsequent call to __ip6_dst_alloc then
generates the fault.
Fix by checking for the flag and failing with EINVAL.
Fixes: d52d3997f843f ("ipv6: Create percpu rt6_info")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
include/uapi/linux/ipv6_route.h | 2 +-
net/ipv6/route.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/ipv6_route.h b/include/uapi/linux/ipv6_route.h
index 85bbb1799df3..d496c02e14bc 100644
--- a/include/uapi/linux/ipv6_route.h
+++ b/include/uapi/linux/ipv6_route.h
@@ -35,7 +35,7 @@
#define RTF_PREF(pref) ((pref) << 27)
#define RTF_PREF_MASK 0x18000000
-#define RTF_PCPU 0x40000000
+#define RTF_PCPU 0x40000000 /* read-only: can not be set by user */
#define RTF_LOCAL 0x80000000
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 4ba7c49872ff..a1bf426c959b 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1854,6 +1854,10 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg)
int addr_type;
int err = -EINVAL;
+ /* RTF_PCPU is an internal flag; can not be set by userspace */
+ if (cfg->fc_flags & RTF_PCPU)
+ goto out;
+
if (cfg->fc_dst_len > 128 || cfg->fc_src_len > 128)
goto out;
#ifndef CONFIG_IPV6_SUBTREES
--
2.9.3
^ permalink raw reply related
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