* [PATCH -next] net: cris: make eth_v10.c explicitly non-modular
From: Paul Gortmaker @ 2016-10-31 19:32 UTC (permalink / raw)
To: netdev
Cc: Paul Gortmaker, David S. Miller, Mikael Starvik, Jesper Nilsson,
linux-cris-kernel
The Makefile/Kconfig currently controlling compilation of this code is:
drivers/net/cris/Makefile:obj-$(CONFIG_ETRAX_ARCH_V10) += eth_v10.o
arch/cris/Kconfig:config ETRAX_ARCH_V10
arch/cris/Kconfig: bool
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
There was a one line wrapper for the int init function, which made no
sense; hence we just put the device_initcall on the true init function
itself and delete the pointless wrapper. In doing that we get rid of
the following compile warning:
WARNING: drivers/net/built-in.o(.text+0x1e28): Section mismatch in
reference from the function etrax_init_module() to the function
.init.text:etrax_ethernet_init()
We don't replace module.h with init.h since the file already has that.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: netdev@vger.kernel.org
Cc: linux-cris-kernel@axis.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/cris/eth_v10.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
index 221f5f011ff9..b37be25f7459 100644
--- a/drivers/net/cris/eth_v10.c
+++ b/drivers/net/cris/eth_v10.c
@@ -7,9 +7,6 @@
*
*/
-
-#include <linux/module.h>
-
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/types.h>
@@ -412,6 +409,7 @@ etrax_ethernet_init(void)
led_next_time = jiffies;
return 0;
}
+device_initcall(etrax_ethernet_init)
/* set MAC address of the interface. called from the core after a
* SIOCSIFADDR ioctl, and from the bootup above.
@@ -1715,11 +1713,6 @@ e100_netpoll(struct net_device* netdev)
}
#endif
-static int
-etrax_init_module(void)
-{
- return etrax_ethernet_init();
-}
static int __init
e100_boot_setup(char* str)
@@ -1742,5 +1735,3 @@ e100_boot_setup(char* str)
}
__setup("etrax100_eth=", e100_boot_setup);
-
-module_init(etrax_init_module);
--
2.8.4
^ permalink raw reply related
* Re: [PATCH 12/15] ptp: use permission-specific DEVICE_ATTR variants
From: David Miller @ 2016-10-31 19:32 UTC (permalink / raw)
To: Julia.Lawall; +Cc: richardcochran, kernel-janitors, netdev, linux-kernel
In-Reply-To: <1477769829-22230-13-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 29 Oct 2016 21:37:06 +0200
> Use DEVICE_ATTR_RO for read only attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Also applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH 15/15] solos-pci: use permission-specific DEVICE_ATTR variants
From: David Miller @ 2016-10-31 19:32 UTC (permalink / raw)
To: Julia.Lawall
Cc: 3chas3, kernel-janitors, linux-atm-general, netdev, linux-kernel
In-Reply-To: <1477769829-22230-16-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 29 Oct 2016 21:37:09 +0200
> Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
> source code, improves readbility, and reduces the chance of
> inconsistencies.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] unix: escape all null bytes in abstract unix domain socket
From: David Miller @ 2016-10-31 19:31 UTC (permalink / raw)
To: iboukris; +Cc: stephen, netdev, linux-kernel
In-Reply-To: <1477768820-1295-2-git-send-email-iboukris@gmail.com>
From: Isaac Boukris <iboukris@gmail.com>
Date: Sat, 29 Oct 2016 22:20:20 +0300
> Abstract unix domain socket may embed null characters,
> these should be translated to '@' when printed out to
> proc the same way the null prefix is currently being
> translated.
>
> This helps for tools such as netstat, lsof and the proc
> based implementation in ss to show all the significant
> bytes of the name (instead of getting cut at the first
> null occurrence).
>
> Signed-off-by: Isaac Boukris <iboukris@gmail.com>
...
> @@ -2805,14 +2805,19 @@ static int unix_seq_show(struct seq_file *seq, void *v)
>
> i = 0;
> len = u->addr->len - sizeof(short);
> - if (!UNIX_ABSTRACT(s))
> + if (!UNIX_ABSTRACT(s)) {
> len--;
> - else {
> + for ( ; i < len; i++)
> + seq_putc(seq,
> + u->addr->name->sun_path[i]);
> + } else {
> seq_putc(seq, '@');
> i++;
> + for ( ; i < len; i++)
> + seq_putc(seq,
> + u->addr->name->sun_path[i] ?:
> + '@');
> }
> - for ( ; i < len; i++)
> - seq_putc(seq, u->addr->name->sun_path[i]);
I think this patch is simpler if you just do the "@" translation
unconditionally, if it'll never trigger for the !UNIX_ABSTRACT case
that is perfectly fine.
^ permalink raw reply
* Re: [PATCH net] net: mangle zero checksum in skb_checksum_help()
From: David Miller @ 2016-10-31 19:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, willemb
In-Reply-To: <1477764156.7065.282.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 29 Oct 2016 11:02:36 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Sending zero checksum is ok for TCP, but not for UDP.
>
> UDPv6 receiver should by default drop a frame with a 0 checksum,
> and UDPv4 would not verify the checksum and might accept a corrupted
> packet.
>
> Simply replace such checksum by 0xffff, regardless of transport.
>
> This error was caught on SIT tunnels, but seems generic.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bpf, inode: add support for symlinks and fix mtime/ctime
From: David Miller @ 2016-10-31 19:28 UTC (permalink / raw)
To: daniel; +Cc: netdev, ast, tgraf
In-Reply-To: <f94e5717c5c494ac054365dee59bf71624702a4a.1477700084.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 29 Oct 2016 02:30:46 +0200
> While commit bb35a6ef7da4 ("bpf, inode: allow for rename and link ops")
> added support for hard links that can be used for prog and map nodes,
> this work adds simple symlink support, which can be used f.e. for
> directories also when unpriviledged and works with cmdline tooling that
> understands S_IFLNK anyway. Since the switch in e27f4a942a0e ("bpf: Use
> mount_nodev not mount_ns to mount the bpf filesystem"), there can be
> various mount instances with mount_nodev() and thus hierarchy can be
> flattened to facilitate object sharing. Thus, we can keep bpf tooling
> also working by repointing paths.
>
> Most of the functionality can be used from vfs library operations. The
> symlink is stored in the inode itself, that is in i_link, which is
> sufficient in our case as opposed to storing it in the page cache.
> While at it, I noticed that bpf_mkdir() and bpf_mkobj() don't update
> the directories mtime and ctime, so add a common helper for it called
> bpf_dentry_finalize() that takes care of it for all cases now.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH net] net: clear sk_err_soft in sk_clone_lock()
From: David Miller @ 2016-10-31 19:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, soheil
In-Reply-To: <1477687224.7065.261.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 28 Oct 2016 13:40:24 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> At accept() time, it is possible the parent has a non zero
> sk_err_soft, leftover from a prior error.
>
> Make sure we do not leave this value in the child, as it
> makes future getsockopt(SO_ERROR) calls quite unreliable.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Tom Herbert @ 2016-10-31 19:25 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Linux Kernel Network Developers, LKML, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <8760oa9egg.fsf@redhat.com>
On Sun, Oct 30, 2016 at 6:03 AM, Jakub Sitnicki <jkbs@redhat.com> wrote:
> On Fri, Oct 28, 2016 at 02:25 PM GMT, Tom Herbert wrote:
>> On Fri, Oct 28, 2016 at 1:32 AM, Jakub Sitnicki <jkbs@redhat.com> wrote:
>>> On Thu, Oct 27, 2016 at 10:35 PM GMT, Tom Herbert wrote:
>>>> On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki <jkbs@redhat.com> wrote:
>>>>> Same as for the transmit path, let's do our best to ensure that received
>>>>> ICMP errors that may be subject to forwarding will be routed the same
>>>>> path as flow that triggered the error, if it was going in the opposite
>>>>> direction.
>>>>>
>>>> Unfortunately our ability to do this is generally quite limited. This
>>>> patch will select the route for multipath, but I don't believe sets
>>>> the same link in LAG and definitely can't help switches doing ECMP to
>>>> route the ICMP packet in the same way as the flow would be. Did you
>>>> see a problem that warrants solving this case?
>>>
>>> The motivation here is to bring IPv6 ECMP routing on par with IPv4 to
>>> enable its wider use, targeting anycast services. Forwarding ICMP errors
>>> back to the source host, at the L3 layer, is what we thought would be a
>>> step forward.
>>>
>>> Similar to change in IPv4 routing introduced in commit 79a131592dbb
>>> ("ipv4: ICMP packet inspection for multipath", [1]) we do our best at
>>> L3, leaving any potential problems with LAG at lower layer (L2)
>>> unaddressed.
>>>
>> ICMP will almost certainly take a different path in the network than
>> TCP or UDP due to ECMP. If we ever get proper flow label support for
>> ECMP then that could solve the problem if all the devices do a hash
>> just on <srcIP, destIP, FlowLabel>.
>
> Sorry for my late reply, I have been traveling.
>
> I think that either I am missing something here, or the proposed changes
> address just the problem that you have described.
>
> Yes, if we compute the hash that drives the route choice over the IP
> header of the ICMP error, then there is no guarantee it will travel back
> to the sender of the offending packet that triggered the error.
>
> That is why, we look at the offending packet carried by an ICMP error
> and hash over its fields, instead. We need, however, to take care of two
> things:
>
> 1) swap the source with the destination address, because we are
> forwarding the ICMP error in the opposite direction than the
> offending packet was going (see icmpv6_multipath_hash() introduced in
> patch 4/5); and
>
> 2) ensure the flow labels used in both directions are the same (either
> reflected by one side, or fixed, e.g. not used and set to 0), so that
> the 4-tuple we hash over when forwarding, <src addr, dst addr, flow
> label, next hdr>, is the same both ways, modulo the order of
> addresses.
>
>> If this patch is being done to be compatible with IPv4 I guess that's
>> okay, but it would be false advertisement to say this makes ICMP
>> follow the same path as the flow being targeted in an error.
>> Fortunately, I doubt anyone can have a dependency on this for ICMP.
>
> I wouldn't want to propose anything that would be useless. If you think
> that this is the case here, I would very much like to understand what
> and why cannot work in practice.
>
The normal hash for TCP or UDP using ECMP is over <protocol, srcIP,
dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be
done over <protocol, srcIP, dstIP>. There really is no way to ensure
that an ICMP packet will follow the same path as TCP or any other
protocol. Fortunately, this is really isn't so terrible. The Internet
has worked this way ever since routers started using ports as input to
ECMP and that hasn't caused any major meltdown.
Tom
> Thanks for reviewing this series,
> Jakub
^ permalink raw reply
* Re: XDP question - how much can BPF change in xdp_buff?
From: John Fastabend @ 2016-10-31 19:22 UTC (permalink / raw)
To: David Miller, Yuval.Mintz; +Cc: netdev
In-Reply-To: <20161031.145734.1243544464767231445.davem@davemloft.net>
On 16-10-31 11:57 AM, David Miller wrote:
> From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
> Date: Mon, 31 Oct 2016 18:31:30 +0000
>
>> So I've [finally] started looking into implementing XDP
>> for qede, and there's one thing I feel like I'm missing in
>> regard to XDP_TX - what's the guarantee/requirement
>> that the bpf program isn't going to transmute some fields
>> of the rx packet in a way that would prevent the forwarding?
>>
>> E.g., can a BPF change the TCP payload of an incoming packet
>> without correcting its TCP checksum, and then expect the
>> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
>>
>> [Looked at samples/bpf/xdp2_kern.c which manipulates the
>> UDP header; so I'm not certain what prevents it from doing
>> the same when checksum modifications would be required]
>
> My understanding is that the eBPF program would be responsible
> for updating the checksum if it mangles the packet in such a
> way that such a fixup would be required.
>
For XDP we will probably need to add support for at minimum the
following helpers,
bpf_l3_csum_replace
bpf_l4_csum_replace
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next v3]ldmvsw: tx queue stuck in stopped state after LDC reset
From: David Miller @ 2016-10-31 19:20 UTC (permalink / raw)
To: Aaron.Young; +Cc: netdev, sowmini.varadhan
In-Reply-To: <b8d6abc7188e5cac885905854067444cb89a5f3b.1477678860.git.Aaron.Young@oracle.com>
From: Aaron Young <Aaron.Young@oracle.com>
Date: Fri, 28 Oct 2016 14:26:19 -0400
> From: Aaron Young <aaron.young@oracle.com>
>
> The following patch fixes an issue with the ldmvsw driver where
> the network connection of a guest domain becomes non-functional after
> the guest domain has panic'd and rebooted.
>
> The root cause was determined to be from the following series of
> events:
>
> 1. Guest domain panics - resulting in the guest no longer processing
> network packets (from ldmvsw driver)
> 2. The ldmvsw driver (in the control domain) eventually exerts flow
> control due to no more available tx drings and stops the tx queue
> for the guest domain
> 3. The LDC of the network connection for the guest is reset when
> the guest domain reboots after the panic.
> 4. The LDC reset event is received by the ldmvsw driver and the ldmvsw
> responds by clearing the tx queue for the guest.
> 5. ldmvsw waits indefinitely for a DATA ACK from the guest - which is
> the normal method to re-enable the tx queue. But the ACK never comes
> because the tx queue was cleared due to the LDC reset.
>
> To fix this issue, in addition to clearing the tx queue, re-enable the
> tx queue on a LDC reset. This prevents the ldmvsw from getting caught in
> this deadlocked state of waiting for a DATA ACK which will never come.
>
> Signed-off-by: Aaron Young <Aaron.Young@oracle.com>
> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] dctcp: avoid bogus doubling of cwnd after loss
From: David Miller @ 2016-10-31 19:18 UTC (permalink / raw)
To: fw; +Cc: netdev, daniel, brakmo, agshew, glenn.judd
In-Reply-To: <1477672991-19181-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 28 Oct 2016 18:43:11 +0200
> If a congestion control module doesn't provide .undo_cwnd function,
> tcp_undo_cwnd_reduction() will set cwnd to
>
> tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh << 1);
>
> ... which makes sense for reno (it sets ssthresh to half the current cwnd),
> but it makes no sense for dctcp, which sets ssthresh based on the current
> congestion estimate.
>
> This can cause severe growth of cwnd (eventually overflowing u32).
>
> Fix this by saving last cwnd on loss and restore cwnd based on that,
> similar to cubic and other algorithms.
>
> Fixes: e3118e8359bb7c ("net: tcp: add DCTCP congestion control algorithm")
> Cc: Lawrence Brakmo <brakmo@fb.com>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Glenn Judd <glenn.judd@morganstanley.com>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: David Miller @ 2016-10-31 19:15 UTC (permalink / raw)
To: jkbs; +Cc: tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <8760oa9egg.fsf@redhat.com>
From: Jakub Sitnicki <jkbs@redhat.com>
Date: Sun, 30 Oct 2016 14:03:11 +0100
> 2) ensure the flow labels used in both directions are the same (either
> reflected by one side, or fixed, e.g. not used and set to 0), so that
> the 4-tuple we hash over when forwarding, <src addr, dst addr, flow
> label, next hdr>, is the same both ways, modulo the order of
> addresses.
Even Linux, by default, does not do reflection.
See the flowlabel_consistency sysctl, which we set by default to '1'.
I think we need to think a lot more about how systems actually set and
use flowlabels.
Also, one issue I also had with this series was adding a new member
to the flow label. Is it possible to implement this like the ipv4
side did, by simply passing a new parameter around to the necessary
functions?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: set SK_MEM_QUANTUM to 4096
From: Eric Dumazet @ 2016-10-31 19:08 UTC (permalink / raw)
To: Neal Cardwell; +Cc: David Miller, netdev, Yuchung Cheng
In-Reply-To: <CADVnQym2dWf8R7Gvx2c03nuiWFLHKrEZM8zOUbF6JFesSRuiCw@mail.gmail.com>
On Mon, 2016-10-31 at 15:01 -0400, Neal Cardwell wrote:
> On Mon, Oct 31, 2016 at 2:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Systems with large pages (64KB pages for example) do not always have
> > huge quantity of memory.
> >
> > A big SK_MEM_QUANTUM value leads to fewer interactions with the
> > global counters (like tcp_memory_allocated) but might trigger
> > memory pressure much faster, thus suboptimal TCP performance
> > since windows are lowered to ridiculous values.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
>
> Thanks, Eric!
Please disregard this patch, I need to change sk_prot_mem_limits() as
well, since tcp_mem[] and udp_mem[] are given in page units.
^ permalink raw reply
* Re: [RFC PATCH v2 2/5] net: phy: Add Meson GXL Internal PHY driver
From: Andrew Lunn @ 2016-10-31 19:05 UTC (permalink / raw)
To: Neil Armstrong
Cc: f.fainelli, khilman, carlo, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477932987-27871-3-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:24PM +0100, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/net/phy/Kconfig | 5 +++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 87 insertions(+)
> create mode 100644 drivers/net/phy/meson-gxl.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 2651c8d..09342b6 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -226,6 +226,11 @@ config DP83867_PHY
> ---help---
> Currently supports the DP83867 PHY.
>
> +config MESON_GXL_PHY
> + tristate "Amlogic Meson GXL Internal PHY"
> + ---help---
> + Currently has a driver for the Amlogic Meson GXL Internal PHY
> +
Hi Neil
Please keep them in alphabetic order. This goes after Marvell.
> config FIXED_PHY
> tristate "MDIO Bus/PHY emulation with fixed speed/link PHYs"
> depends on PHYLIB
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index e58667d..1511b3e 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_MARVELL_PHY) += marvell.o
> obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
> obj-$(CONFIG_MICREL_PHY) += micrel.o
> obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
> +obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
> obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
Again, alphabetic order.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: set SK_MEM_QUANTUM to 4096
From: Neal Cardwell @ 2016-10-31 19:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yuchung Cheng
In-Reply-To: <1477940320.7065.312.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, Oct 31, 2016 at 2:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
>
> Systems with large pages (64KB pages for example) do not always have
> huge quantity of memory.
>
> A big SK_MEM_QUANTUM value leads to fewer interactions with the
> global counters (like tcp_memory_allocated) but might trigger
> memory pressure much faster, thus suboptimal TCP performance
> since windows are lowered to ridiculous values.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Eric!
neal
^ permalink raw reply
* Re: [net-next PATCH v2 0/4] Add support for XPS when using DCB
From: David Miller @ 2016-10-31 19:01 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, intel-wired-lan, john.r.fastabend, tom
In-Reply-To: <20161028154126.67826.76735.stgit@ahduyck-blue-test.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 28 Oct 2016 11:42:45 -0400
> This patch series enables proper isolation between traffic classes when
> using XPS while DCB is enabled. Previously enabling XPS would cause the
> traffic to be potentially pulled from one traffic class into another on
> egress. This change essentially multiplies the XPS map by the number of
> traffic classes and allows us to do a lookup per traffic class for a given
> CPU.
>
> To guarantee the isolation I invalidate the XPS map for any queues that are
> moved from one traffic class to another, or if we change the number of
> traffic classes.
>
> v2: Added sysfs to display traffic class
> Replaced do/while with for loop
> Cleaned up several other for for loops throughout the patch
Series applied, thanks Alex.
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Andrew Lunn @ 2016-10-31 18:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: f.fainelli, khilman, carlo, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Nice.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next] net: set SK_MEM_QUANTUM to 4096
From: Eric Dumazet @ 2016-10-31 18:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng
From: Eric Dumazet <edumazet@google.com>
Systems with large pages (64KB pages for example) do not always have
huge quantity of memory.
A big SK_MEM_QUANTUM value leads to fewer interactions with the
global counters (like tcp_memory_allocated) but might trigger
memory pressure much faster, thus suboptimal TCP performance
since windows are lowered to ridiculous values.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index f13ac87a8015cb18c5d3fe5fdcf2d6a0592428f4..d3409bb514e7f08b9cf183b7405d876bec18d732 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1281,7 +1281,10 @@ int __sk_mem_schedule(struct sock *sk, int size, int kind);
void __sk_mem_reduce_allocated(struct sock *sk, int amount);
void __sk_mem_reclaim(struct sock *sk, int amount);
-#define SK_MEM_QUANTUM ((int)PAGE_SIZE)
+/* We used to have PAGE_SIZE here, but systems with 64KB pages
+ * do not necessarily have 16x time more memory than 4KB ones.
+ */
+#define SK_MEM_QUANTUM 4096
#define SK_MEM_QUANTUM_SHIFT ilog2(SK_MEM_QUANTUM)
#define SK_MEM_SEND 0
#define SK_MEM_RECV 1
^ permalink raw reply related
* Re: XDP question - how much can BPF change in xdp_buff?
From: David Miller @ 2016-10-31 18:57 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <BY2PR07MB23090DE460B0AE6AA23CD7368DAE0@BY2PR07MB2309.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Mon, 31 Oct 2016 18:31:30 +0000
> So I've [finally] started looking into implementing XDP
> for qede, and there's one thing I feel like I'm missing in
> regard to XDP_TX - what's the guarantee/requirement
> that the bpf program isn't going to transmute some fields
> of the rx packet in a way that would prevent the forwarding?
>
> E.g., can a BPF change the TCP payload of an incoming packet
> without correcting its TCP checksum, and then expect the
> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
>
> [Looked at samples/bpf/xdp2_kern.c which manipulates the
> UDP header; so I'm not certain what prevents it from doing
> the same when checksum modifications would be required]
My understanding is that the eBPF program would be responsible
for updating the checksum if it mangles the packet in such a
way that such a fixup would be required.
^ permalink raw reply
* Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
From: David Miller @ 2016-10-31 18:51 UTC (permalink / raw)
To: ville.syrjala; +Cc: felipe.balbi, linux-usb, stable, oneukum, netdev
In-Reply-To: <20161028163332.GL4617@intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri, 28 Oct 2016 19:33:32 +0300
> On Fri, Oct 28, 2016 at 01:16:13PM +0300, Felipe Balbi wrote:
>> Yeah, I'm guessing we're gonna need some help from networking folks. The
>> only thing we did since v4.7 was actually respect req->no_interrupt flag
>> coming from u_ether itself. No idea why that causes so much trouble for
>> u_ether.
>>
>> BTW, Instead of reverting so many patches, you can just remove
>> throttling:
>>
>> diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
>> index f4a640216913..119a2e5848e8 100644
>> --- a/drivers/usb/gadget/function/u_ether.c
>> +++ b/drivers/usb/gadget/function/u_ether.c
>> @@ -589,14 +589,6 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
>>
>> req->length = length;
>>
>> - /* throttle high/super speed IRQ rate back slightly */
>> - if (gadget_is_dualspeed(dev->gadget))
>> - req->no_interrupt = (((dev->gadget->speed == USB_SPEED_HIGH ||
>> - dev->gadget->speed == USB_SPEED_SUPER)) &&
>> - !list_empty(&dev->tx_reqs))
>> - ? ((atomic_read(&dev->tx_qlen) % dev->qmult) != 0)
>> - : 0;
>> -
>> retval = usb_ep_queue(in, req, GFP_ATOMIC);
>> switch (retval) {
>> default:
>
> Ah cool. That indeed fixes the problem for me.
>
>>
>> I'm adding netdev and couple other folks to the loop.
>>
>> Just to summarize, USB peripheral controller now actually throttles
>> interrupt when requested to do so and that causes lags for USB
>> networking gadgets.
>>
>> Without throttle we, potentially, call netif_wake_queue() more
>> frequently than with throttling. I'm wondering if something changed in
>> NET layer within the past few years but the USB networking gadgets ended
>> up being forgotten.
>>
>> Anyway, if anybody has any hints, I'd be glad to hear about them.
This throttling mechanism seems to have the same problem we've seen in
the past with some ethernet drivers trying to do TX mitigation in
software.
If I understand correctly, the interrupt bit for TX completions is set
only periodically.
However, the networking stack has a hard requirement that all SKBs
which are transmitted must have their completion signalled in a finite
amount of time. This is because, until the SKB is freed by the
driver, it holds onto socket, netfilter, and other subsystem
resources.
So, for example, if your scheme is that only every 8th TX packet will
generate an interrupt you run into problems if you suddenly have 7
pending TX packets and no more traffic is generated for a long time.
Those 7 packets will sit in the TX queue indefinitely, and this is the
situation which drivers must avoid.
Therefore, for devices with per-TX-queue-entry interrupt bit schemes,
it's not easy to take advantage of this facility. The safest thing to
do is to interrupt for every queue entry.
For the time being, this revert is the way to go and it should be
submitted formally, with proper commit message and signoffs, via
whatever tree this gadget driver's changes should be submitted via.
It might be possible to elide TX queue entry interrupts using the
skb->xmit_more state. Basically, if the TX queue is not full and
skb->xmit_more is set, you can skip the interrupt indication bit
in the descriptor.
Thanks.
^ permalink raw reply
* [PATCH net-next 1/3] tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h
From: Joe Stringer @ 2016-10-31 18:39 UTC (permalink / raw)
To: netdev; +Cc: wangnan0, ast
In-Reply-To: <20161031183917.9938-1-joe@ovn.org>
The tools version of this header is out of date; update it to the latest
version from the kernel headers.
Signed-off-by: Joe Stringer <joe@ovn.org>
---
tools/include/uapi/linux/bpf.h | 51 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9e5fc168c8a3..f09c70b97eca 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -95,6 +95,7 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SCHED_ACT,
BPF_PROG_TYPE_TRACEPOINT,
BPF_PROG_TYPE_XDP,
+ BPF_PROG_TYPE_PERF_EVENT,
};
#define BPF_PSEUDO_MAP_FD 1
@@ -375,6 +376,56 @@ enum bpf_func_id {
*/
BPF_FUNC_probe_write_user,
+ /**
+ * bpf_current_task_under_cgroup(map, index) - Check cgroup2 membership of current task
+ * @map: pointer to bpf_map in BPF_MAP_TYPE_CGROUP_ARRAY type
+ * @index: index of the cgroup in the bpf_map
+ * Return:
+ * == 0 current failed the cgroup2 descendant test
+ * == 1 current succeeded the cgroup2 descendant test
+ * < 0 error
+ */
+ BPF_FUNC_current_task_under_cgroup,
+
+ /**
+ * bpf_skb_change_tail(skb, len, flags)
+ * The helper will resize the skb to the given new size,
+ * to be used f.e. with control messages.
+ * @skb: pointer to skb
+ * @len: new skb length
+ * @flags: reserved
+ * Return: 0 on success or negative error
+ */
+ BPF_FUNC_skb_change_tail,
+
+ /**
+ * bpf_skb_pull_data(skb, len)
+ * The helper will pull in non-linear data in case the
+ * skb is non-linear and not all of len are part of the
+ * linear section. Only needed for read/write with direct
+ * packet access.
+ * @skb: pointer to skb
+ * @len: len to make read/writeable
+ * Return: 0 on success or negative error
+ */
+ BPF_FUNC_skb_pull_data,
+
+ /**
+ * bpf_csum_update(skb, csum)
+ * Adds csum into skb->csum in case of CHECKSUM_COMPLETE.
+ * @skb: pointer to skb
+ * @csum: csum to add
+ * Return: csum on success or negative error
+ */
+ BPF_FUNC_csum_update,
+
+ /**
+ * bpf_set_hash_invalid(skb)
+ * Invalidate current skb>hash.
+ * @skb: pointer to skb
+ */
+ BPF_FUNC_set_hash_invalid,
+
__BPF_FUNC_MAX_ID,
};
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/3] tools lib bpf: Synchronize implementations
From: Joe Stringer @ 2016-10-31 18:39 UTC (permalink / raw)
To: netdev; +Cc: wangnan0, ast
Update tools/lib/bpf to provide more functionality and improve interoperation
with other tools that generate and use eBPF code.
The kernel uapi headers are a bit newer than the version in the tools/
directory; synchronize those.
samples/bpf/libbpf* has a bit more functionality than tools/lib/bpf, so extend
tools/lib/bpf/bpf* with these functions to bring them into parity.
tools/lib/bpf cannot read ELFs that tc can read, and vice versa. Update the
map definition to be the same as in tc so the ELFs may be interchangeable
(at least for now; I don't have a long-term plan in mind to ensure this always
works).
Joe Stringer (3):
tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h
tools lib bpf: Sync with samples/bpf/libbpf
tools lib bpf: Sync bpf_map_def with tc
tools/include/uapi/linux/bpf.h | 51 ++++++++++
tools/lib/bpf/bpf.c | 139 ++++++++++++++++++++++-----
tools/lib/bpf/bpf.h | 208 +++++++++++++++++++++++++++++++++++++++--
tools/lib/bpf/libbpf.c | 3 +-
tools/lib/bpf/libbpf.h | 11 ++-
5 files changed, 375 insertions(+), 37 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next 3/3] tools lib bpf: Sync bpf_map_def with tc
From: Joe Stringer @ 2016-10-31 18:39 UTC (permalink / raw)
To: netdev; +Cc: wangnan0, ast, daniel
In-Reply-To: <20161031183917.9938-1-joe@ovn.org>
TC uses a slightly different map layout in its ELFs. Update libbpf to
use the same definition so that ELFs may be built using libbpf and
loaded using tc.
Signed-off-by: Joe Stringer <joe@ovn.org>
---
tools/lib/bpf/libbpf.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index dd7a513efb10..ea70c2744f8c 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -181,10 +181,13 @@ bool bpf_program__is_kprobe(struct bpf_program *prog);
* and will be treated as an error due to -Werror.
*/
struct bpf_map_def {
- unsigned int type;
- unsigned int key_size;
- unsigned int value_size;
- unsigned int max_entries;
+ uint32_t type;
+ uint32_t key_size;
+ uint32_t value_size;
+ uint32_t max_entries;
+ uint32_t flags;
+ uint32_t id;
+ uint32_t pinning;
};
/*
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 2/3] tools lib bpf: Sync with samples/bpf/libbpf
From: Joe Stringer @ 2016-10-31 18:39 UTC (permalink / raw)
To: netdev; +Cc: wangnan0, ast, daniel
In-Reply-To: <20161031183917.9938-1-joe@ovn.org>
Extend the tools/ version of libbpf to include all of the functionality
provided in the samples/bpf version.
Signed-off-by: Joe Stringer <joe@ovn.org>
---
tools/lib/bpf/bpf.c | 139 +++++++++++++++++++++++++++------
tools/lib/bpf/bpf.h | 208 +++++++++++++++++++++++++++++++++++++++++++++++--
tools/lib/bpf/libbpf.c | 3 +-
3 files changed, 317 insertions(+), 33 deletions(-)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 4212ed62235b..34b0511b3baa 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -20,10 +20,17 @@
*/
#include <stdlib.h>
-#include <memory.h>
+#include <stdio.h>
#include <unistd.h>
#include <asm/unistd.h>
+#include <string.h>
+#include <linux/netlink.h>
#include <linux/bpf.h>
+#include <errno.h>
+#include <net/ethernet.h>
+#include <net/if.h>
+#include <linux/if_packet.h>
+#include <arpa/inet.h>
#include "bpf.h"
/*
@@ -53,24 +60,71 @@ static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
return syscall(__NR_bpf, cmd, attr, size);
}
-int bpf_create_map(enum bpf_map_type map_type, int key_size,
- int value_size, int max_entries)
+int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
+ int max_entries, int map_flags)
{
- union bpf_attr attr;
+ union bpf_attr attr = {
+ .map_type = map_type,
+ .key_size = key_size,
+ .value_size = value_size,
+ .max_entries = max_entries,
+ .map_flags = map_flags,
+ };
- memset(&attr, '\0', sizeof(attr));
+ return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
+}
- attr.map_type = map_type;
- attr.key_size = key_size;
- attr.value_size = value_size;
- attr.max_entries = max_entries;
+int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ .flags = flags,
+ };
- return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
+ return sys_bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
+}
+
+int bpf_lookup_elem(int fd, void *key, void *value)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ };
+
+ return sys_bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
+}
+
+int bpf_delete_elem(int fd, void *key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ };
+
+ return sys_bpf(BPF_MAP_DELETE_ELEM, &attr, sizeof(attr));
}
-int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
- size_t insns_cnt, char *license,
- u32 kern_version, char *log_buf, size_t log_buf_sz)
+int bpf_get_next_key(int fd, void *key, void *next_key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .next_key = ptr_to_u64(next_key),
+ };
+
+ return sys_bpf(BPF_MAP_GET_NEXT_KEY, &attr, sizeof(attr));
+}
+
+#define ROUND_UP(x, n) (((x) + (n) - 1u) & ~((n) - 1u))
+
+
+int bpf_load_program(enum bpf_prog_type type,
+ const struct bpf_insn *insns, int insns_cnt,
+ const char *license, int kern_version,
+ char *log_buf, size_t log_buf_sz)
{
int fd;
union bpf_attr attr;
@@ -78,8 +132,8 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
bzero(&attr, sizeof(attr));
attr.prog_type = type;
attr.insn_cnt = (__u32)insns_cnt;
- attr.insns = ptr_to_u64(insns);
- attr.license = ptr_to_u64(license);
+ attr.insns = ptr_to_u64((void *)insns);
+ attr.license = ptr_to_u64((void *)license);
attr.log_buf = ptr_to_u64(NULL);
attr.log_size = 0;
attr.log_level = 0;
@@ -97,16 +151,53 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
return sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
}
-int bpf_map_update_elem(int fd, void *key, void *value,
- u64 flags)
+int bpf_obj_pin(int fd, const char *pathname)
{
- union bpf_attr attr;
+ union bpf_attr attr = {
+ .pathname = ptr_to_u64((void *)pathname),
+ .bpf_fd = fd,
+ };
- bzero(&attr, sizeof(attr));
- attr.map_fd = fd;
- attr.key = ptr_to_u64(key);
- attr.value = ptr_to_u64(value);
- attr.flags = flags;
+ return sys_bpf(BPF_OBJ_PIN, &attr, sizeof(attr));
+}
- return sys_bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
+int bpf_obj_get(const char *pathname)
+{
+ union bpf_attr attr = {
+ .pathname = ptr_to_u64((void *)pathname),
+ };
+
+ return sys_bpf(BPF_OBJ_GET, &attr, sizeof(attr));
+}
+
+int open_raw_sock(const char *name)
+{
+ struct sockaddr_ll sll;
+ int sock;
+
+ sock = socket(PF_PACKET, SOCK_RAW | SOCK_NONBLOCK | SOCK_CLOEXEC,
+ htons(ETH_P_ALL));
+ if (sock < 0) {
+ printf("cannot create raw socket\n");
+ return -1;
+ }
+
+ memset(&sll, 0, sizeof(sll));
+ sll.sll_family = AF_PACKET;
+ sll.sll_ifindex = if_nametoindex(name);
+ sll.sll_protocol = htons(ETH_P_ALL);
+ if (bind(sock, (struct sockaddr *)&sll, sizeof(sll)) < 0) {
+ printf("bind to %s: %s\n", name, strerror(errno));
+ close(sock);
+ return -1;
+ }
+
+ return sock;
+}
+
+int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
+ int group_fd, unsigned long flags)
+{
+ return syscall(__NR_perf_event_open, attr, pid, cpu,
+ group_fd, flags);
}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index e8ba54087497..227edb23c022 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -23,16 +23,208 @@
#include <linux/bpf.h>
+struct bpf_insn;
+
int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
- int max_entries);
+ int max_entries, int map_flags);
+int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags);
+int bpf_lookup_elem(int fd, void *key, void *value);
+int bpf_delete_elem(int fd, void *key);
+int bpf_get_next_key(int fd, void *key, void *next_key);
+
+int bpf_load_program(enum bpf_prog_type prog_type,
+ const struct bpf_insn *insns, int insn_len,
+ const char *license, int kern_version,
+ char *log_buf, size_t log_buf_sz);
+
+int bpf_obj_pin(int fd, const char *pathname);
+int bpf_obj_get(const char *pathname);
-/* Recommend log buffer size */
#define BPF_LOG_BUF_SIZE 65536
-int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
- size_t insns_cnt, char *license,
- u32 kern_version, char *log_buf,
- size_t log_buf_sz);
-int bpf_map_update_elem(int fd, void *key, void *value,
- u64 flags);
+/* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
+
+#define BPF_ALU64_REG(OP, DST, SRC) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU64 | BPF_OP(OP) | BPF_X, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = 0 })
+
+#define BPF_ALU32_REG(OP, DST, SRC) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU | BPF_OP(OP) | BPF_X, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = 0 })
+
+/* ALU ops on immediates, bpf_add|sub|...: dst_reg += imm32 */
+
+#define BPF_ALU64_IMM(OP, DST, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU64 | BPF_OP(OP) | BPF_K, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = IMM })
+
+#define BPF_ALU32_IMM(OP, DST, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU | BPF_OP(OP) | BPF_K, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = IMM })
+
+/* Short form of mov, dst_reg = src_reg */
+
+#define BPF_MOV64_REG(DST, SRC) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU64 | BPF_MOV | BPF_X, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = 0 })
+
+#define BPF_MOV32_REG(DST, SRC) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU | BPF_MOV | BPF_X, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = 0 })
+
+/* Short form of mov, dst_reg = imm32 */
+
+#define BPF_MOV64_IMM(DST, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU64 | BPF_MOV | BPF_K, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = IMM })
+
+#define BPF_MOV32_IMM(DST, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_ALU | BPF_MOV | BPF_K, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = IMM })
+
+/* BPF_LD_IMM64 macro encodes single 'load 64-bit immediate' insn */
+#define BPF_LD_IMM64(DST, IMM) \
+ BPF_LD_IMM64_RAW(DST, 0, IMM)
+
+#define BPF_LD_IMM64_RAW(DST, SRC, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_LD | BPF_DW | BPF_IMM, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = 0, \
+ .imm = (__u32) (IMM) }), \
+ ((struct bpf_insn) { \
+ .code = 0, /* zero is reserved opcode */ \
+ .dst_reg = 0, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = ((__u64) (IMM)) >> 32 })
+
+#ifndef BPF_PSEUDO_MAP_FD
+# define BPF_PSEUDO_MAP_FD 1
+#endif
+
+/* pseudo BPF_LD_IMM64 insn used to refer to process-local map_fd */
+#define BPF_LD_MAP_FD(DST, MAP_FD) \
+ BPF_LD_IMM64_RAW(DST, BPF_PSEUDO_MAP_FD, MAP_FD)
+
+
+/* Direct packet access, R0 = *(uint *) (skb->data + imm32) */
+
+#define BPF_LD_ABS(SIZE, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_LD | BPF_SIZE(SIZE) | BPF_ABS, \
+ .dst_reg = 0, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = IMM })
+
+/* Memory load, dst_reg = *(uint *) (src_reg + off16) */
+
+#define BPF_LDX_MEM(SIZE, DST, SRC, OFF) \
+ ((struct bpf_insn) { \
+ .code = BPF_LDX | BPF_SIZE(SIZE) | BPF_MEM, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = OFF, \
+ .imm = 0 })
+
+/* Memory store, *(uint *) (dst_reg + off16) = src_reg */
+
+#define BPF_STX_MEM(SIZE, DST, SRC, OFF) \
+ ((struct bpf_insn) { \
+ .code = BPF_STX | BPF_SIZE(SIZE) | BPF_MEM, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = OFF, \
+ .imm = 0 })
+
+/* Memory store, *(uint *) (dst_reg + off16) = imm32 */
+
+#define BPF_ST_MEM(SIZE, DST, OFF, IMM) \
+ ((struct bpf_insn) { \
+ .code = BPF_ST | BPF_SIZE(SIZE) | BPF_MEM, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = OFF, \
+ .imm = IMM })
+
+/* Conditional jumps against registers, if (dst_reg 'op' src_reg) goto pc + off16 */
+
+#define BPF_JMP_REG(OP, DST, SRC, OFF) \
+ ((struct bpf_insn) { \
+ .code = BPF_JMP | BPF_OP(OP) | BPF_X, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = OFF, \
+ .imm = 0 })
+
+/* Conditional jumps against immediates, if (dst_reg 'op' imm32) goto pc + off16 */
+
+#define BPF_JMP_IMM(OP, DST, IMM, OFF) \
+ ((struct bpf_insn) { \
+ .code = BPF_JMP | BPF_OP(OP) | BPF_K, \
+ .dst_reg = DST, \
+ .src_reg = 0, \
+ .off = OFF, \
+ .imm = IMM })
+
+/* Raw code statement block */
+
+#define BPF_RAW_INSN(CODE, DST, SRC, OFF, IMM) \
+ ((struct bpf_insn) { \
+ .code = CODE, \
+ .dst_reg = DST, \
+ .src_reg = SRC, \
+ .off = OFF, \
+ .imm = IMM })
+
+/* Program exit */
+
+#define BPF_EXIT_INSN() \
+ ((struct bpf_insn) { \
+ .code = BPF_JMP | BPF_EXIT, \
+ .dst_reg = 0, \
+ .src_reg = 0, \
+ .off = 0, \
+ .imm = 0 })
+
+/* create RAW socket and bind to interface 'name' */
+int open_raw_sock(const char *name);
+
+struct perf_event_attr;
+int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
+ int group_fd, unsigned long flags);
#endif
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index f3c667417a13..19d70e9ee280 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -796,7 +796,8 @@ bpf_object__create_maps(struct bpf_object *obj)
*pfd = bpf_create_map(def->type,
def->key_size,
def->value_size,
- def->max_entries);
+ def->max_entries,
+ 0);
if (*pfd < 0) {
size_t j;
int err = *pfd;
--
2.9.3
^ permalink raw reply related
* Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep
From: Eric Dumazet @ 2016-10-31 18:40 UTC (permalink / raw)
To: Cong Wang
Cc: Andrey Konovalov, Peter Zijlstra, Gerrit Renker, David S. Miller,
dccp, netdev, LKML, Dmitry Vyukov, Eric Dumazet
In-Reply-To: <CAM_iQpWs1YvrZQF8JTzWR0u0V4t4f3b71WStStGWqDd7agHN_w@mail.gmail.com>
On Mon, 2016-10-31 at 11:00 -0700, Cong Wang wrote:
> On Sun, Oct 30, 2016 at 6:20 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Sun, 2016-10-30 at 05:41 +0100, Andrey Konovalov wrote:
> >> Sorry, the warning is still there.
> >>
> >> I'm not sure adding sched_annotate_sleep() does anything, since it's
> >> defined as (in case CONFIG_DEBUG_ATOMIC_SLEEP is not set):
> >> # define sched_annotate_sleep() do { } while (0)
> >
> > Thanks again for testing.
> >
> > But you do have CONFIG_DEBUG_ATOMIC_SLEEP set, which triggers a check in
> > __might_sleep() :
> >
> > WARN_ONCE(current->state != TASK_RUNNING && current->task_state_change,
> >
> > Relevant commit is 00845eb968ead28007338b2bb852b8beef816583
> > ("sched: don't cause task state changes in nested sleep debugging")
> >
> > Another relevant commit was 26cabd31259ba43f68026ce3f62b78094124333f
> > ("sched, net: Clean up sk_wait_event() vs. might_sleep()")
> >
> > Before release_sock() could process the backlog in process context, only
> > lock_sock() could trigger the issue, so my fix at that time was commit
> > cb7cf8a33ff73cf638481d1edf883d8968f934f8 ("inet: Clean up
> > inet_csk_wait_for_connect() vs. might_sleep()")
> >
>
> Thanks for the context, but isn't the original warning reported by Andrey is
> from inet_wait_for_connect()? You seem only patch some dccp function
> which is why it is still there?
>
> It should be the following, no?
>
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 9648c97..bbd8159 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -544,6 +544,7 @@ static long inet_wait_for_connect(struct sock *sk,
> long timeo, int writebias)
> * without closing the socket.
> */
> while ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> + sched_annotate_sleep();
> release_sock(sk);
> timeo = schedule_timeout(timeo);
> lock_sock(sk);
Yes, this would be one of the locations needing this.
^ 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