Since, ksym_search added with verification logic for symbols existence,
it could return NULL when the kernel symbols are not loaded.
This commit will add NULL check logic after ksym_search.
Signed-off-by: Daniel T. Lee
---
samples/bpf/offwaketime_user.c | 5 +
samples/bpf/sampleip_user.c
Currently, ksym_search located at trace_helpers won't check symbols are
existing or not.
In ksym_search, when symbol is not found, it will return &syms[0](_stext).
But when the kernel symbols are not loaded, it will return NULL, which is
not a desired action.
This commit will add verification log
Same reasons than the ones explained in commit 4179cb5a4c92
("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
netif_rx_ni() or napi_gro_frags() must be called under a strict contract.
At device dismantle phase, core networking clears IFF_UP
and flush_all_backlogs() is called after rcu
Hi Leandro,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Leandro-Dorileo/net-sched-taprio-cbs-Fix-using-invalid-link-speed/20190315-092958
config: mips-allyesconfig (attached as .config)
compiler:
> -Original Message-
> From: Samudrala, Sridhar
> Sent: Thursday, March 14, 2019 9:16 PM
> To: Parav Pandit ; Jakub Kicinski
>
> Cc: Jiri Pirko ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on de
On 3/14/2019 6:28 PM, Parav Pandit wrote:
-Original Message-
From: Jakub Kicinski
Sent: Thursday, March 14, 2019 6:39 PM
To: Parav Pandit
Cc: Jiri Pirko ; da...@davemloft.net;
netdev@vger.kernel.org; oss-driv...@netronome.com
Subject: Re: [PATCH net-next v2 4/7] devlink: allow sub
> -Original Message-
> From: Parav Pandit
> Sent: Thursday, March 14, 2019 8:29 PM
> To: 'Jakub Kicinski'
> Cc: Jiri Pirko ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
> ports
>
> -Original Message-
> From: Jakub Kicinski
> Sent: Thursday, March 14, 2019 6:39 PM
> To: Parav Pandit
> Cc: Jiri Pirko ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
> ports
>
>
This helper is useful if a bpf tc filter sets skb->tstamp.
Signed-off-by: Peter Oskolkov
---
net/core/filter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 647c63a7b25b..c6d016d9c4b8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -5
On Thu, 14 Mar 2019 22:35:36 +, Parav Pandit wrote:
> > > Then instances of flavour pci_vf are going to appear in the same
> > > devlink instance. Those are the switch ports:
> > > pci/:05:00.0/10002: type eth netdev enp5s0npf0pf0s0
> > > flavour pci_vf pf 0 vf 0
> >
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Stefan Assmann
> Sent: Tuesday, March 12, 2019 4:18 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; da...@davemloft.net; sassm...@kpanic.de
> Subject: [Intel-wired
Hi Jakub,
> -Original Message-
> From: netdev-ow...@vger.kernel.org On
> Behalf Of Jakub Kicinski
> Sent: Thursday, March 14, 2019 5:10 PM
> To: Jiri Pirko
> Cc: da...@davemloft.net; netdev@vger.kernel.org; oss-
> driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allo
On Mon, Mar 11, 2019 at 2:51 PM Daniel Borkmann wrote:
>
> This work adds BPF loader support for global data sections
> to libbpf. This allows to write BPF programs in more natural
> C-like way by being able to define global variables and const
> data.
>
> Back at LPC 2018 [0] we presented a first
On Thu, 14 Mar 2019 08:38:40 +0100, Jiri Pirko wrote:
> Wed, Mar 13, 2019 at 05:55:55PM CET, jakub.kicin...@netronome.com wrote:
> >On Wed, 13 Mar 2019 17:22:43 +0100, Jiri Pirko wrote:
> >> Wed, Mar 13, 2019 at 05:17:31PM CET, jakub.kicin...@netronome.com wrote:
> >> >On Wed, 13 Mar 2019 07:07
> >> Thanks for the additional info and for testing 4.20.15.
> >> To rule out that the issue is caused by a regression in network or
> >> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> >> it on top of 5.0?
> >> Meanwhile I'll look at the changes in the driver between 4.20 an
"Tilmans, Olivier (Nokia - BE/Antwerp)"
writes:
>> I noticed that there's an IPR disclosure filed at the IETF[0] claiming a
>> patent on the algorithm. I'm curious if you know whether Nokia has an
>> official position on the use of that patent in this implementation if it
>> becomes part of the k
On Thu, Mar 14, 2019 at 12:38:38PM +, Quentin Monnet wrote:
> Hi,
> This set is an update to the documentation for the BPF helper functions in
> the UAPI header bpf.h, used to generate the bpf-helpers(7) man page.
>
> First patch contains fixes to the current documentation. The second patch
>
On Mon, Mar 11, 2019 at 2:51 PM Daniel Borkmann wrote:
>
> From: Joe Stringer
>
> Adjust the code for relocations slightly with no functional changes,
> so that upcoming patches that will introduce support for relocations
> into the .data, .rodata and .bss sections can be added independent
> of t
On Mon, Mar 11, 2019 at 10:39:37AM -0700, Andrii Nakryiko wrote:
>
> There is a GCC extension that allows to forward-declare enums:
> https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete-Enums
>
> Kernel actually has examples of using this (see patch description
> regrading irqchip
TL;DR:
The nexthop changes are finally ready for consideration for inclusion
into the networking stack. The patch count currently stands at 86
including tests. The majority of those are refactoring the existing code
base with the last 16 implementing the nexthop feature and selftests.
The first 27
This set fixes miscalculations based on invalid link speed values.
Changes in v2:
+ fixed pr_info() format both on cbs and taprio patches;
Leandro Dorileo (2):
net/sched: taprio: fix picos_per_byte miscalculation
net/sched: cbs: fix port_rate miscalculation
net/sched/sch_cbs.c| 91
The Time Aware Priority Scheduler is heavily dependent to link speed,
it relies on it to calculate transmission bytes per cycle, we can't
properly calculate the so called budget if the device has failed
to report the link speed.
In that case we can't dequeue packets assuming a wrong budget.
This p
The Credit Based Shaper heavily depends on link speed to calculate
the scheduling credits, we can't properly calculate the credits if the
device has failed to report the link speed.
In that case we can't dequeue packets assuming a wrong port rate that will
result into an inconsistent credit distri
On Mon, Mar 11, 2019 at 2:51 PM Daniel Borkmann wrote:
>
> Trivial addition to allow '.' aside from '_' as "special" characters
> in the object name. Used to allow for substrings in maps from loader
> side such as ".bss", ".data", ".rodata", but could also be useful for
> other purposes.
>
> Signe
On Mon, Mar 11, 2019 at 4:06 PM Alexei Starovoitov
wrote:
>
> On Mon, Mar 11, 2019 at 10:51:18PM +0100, Daniel Borkmann wrote:
> > This work adds two new map creation flags BPF_F_RDONLY_PROG
> > and BPF_F_WRONLY_PROG in order to allow for read-only or
> > write-only BPF maps from a BPF program sid
On Mon, Mar 11, 2019 at 2:51 PM Daniel Borkmann wrote:
>
> This work adds two new map creation flags BPF_F_RDONLY_PROG
> and BPF_F_WRONLY_PROG in order to allow for read-only or
> write-only BPF maps from a BPF program side.
>
> Today we have BPF_F_RDONLY and BPF_F_WRONLY, but this only
> applies
On 3/13/19 10:38 PM, Martin Lau wrote:
> On Wed, Mar 13, 2019 at 12:20:27PM -0700, Alexei Starovoitov wrote:
>> On Tue, Mar 12, 2019 at 10:23:01AM -0700, Martin KaFai Lau wrote:
>>> This set addresses issue about accessing invalid
>>> ptr returned from bpf_tcp_sock() and bpf_sk_fullsock()
>>> after
On Mon, Feb 25, 2019 at 05:44:34PM +0200, Tariq Toukan wrote:
> From: Aya Levin
>
> Introduce 50Gbps per lane link modes and 200Gbps speed, update print
> functions and initialization functions accordingly.
> In addition, update related man page accordingly.
>
> Signed-off-by: Aya Levin
> Signe
On Thu, Feb 14, 2019 at 11:15:36AM -0500, Vivien Didelot wrote:
> Add pretty dump for the port registers of the "fec" kernel driver. Only
> offsets exposed by the driver are dumped by ethtool.
>
> Both register dump versions are supported, version 2 which corresponds
> to the kernel compilation te
On Fri, Mar 01, 2019 at 12:15:27AM -0800, Jeff Kirsher wrote:
> From: Nicholas Nunley
>
> Move option parsing code into find_option function.
>
> No behavior changes.
>
> Based on patch by Kan Liang
>
> Signed-off-by: Nicholas Nunley
Series queued for next release -- thanks!
John
--
John
On Wed, Feb 27, 2019 at 02:49:04PM +0100, Michal Kubecek wrote:
> ETHTOOL_LINK_MODE_1baseR_FEC_BIT link mode is listed in
> ethtool_link_mode_bit_indices array but doesn't have its name assigned in
> the table in dump_link_caps() (so that it's not shown in "ethtool "
> output) and is not listed
On Thu, Mar 14, 2019 at 07:33:16PM +0100, Michal Kubecek wrote:
> One of the warnings gcc issues when building ethtool with -Wall seems to
> point to an actual problem:
>
> qsfp.c: In function 'sff8636_show_dom':
> qsfp.c:709:57: warning: comparison is always false due to limited range of
> data
One of the warnings gcc issues when building ethtool with -Wall seems to
point to an actual problem:
qsfp.c: In function 'sff8636_show_dom':
qsfp.c:709:57: warning: comparison is always false due to limited range of data
type [-Wtype-limits]
if ((sd.sfp_temp[MCURR] == 0x0) || (sd.sfp_temp[MCURR
On Mon, Mar 11, 2019 at 2:51 PM Daniel Borkmann wrote:
>
> This generic extension to BPF maps allows for directly loading an
> address residing inside a BPF map value as a single BPF ldimm64
> instruction.
>
> The idea is similar to what BPF_PSEUDO_MAP_FD does today, which
> is a special src_reg f
On 14.03.2019 16:10, VDR User wrote:
>> Thanks for the additional info and for testing 4.20.15.
>> To rule out that the issue is caused by a regression in network or
>> some other subsystem: Can you take the r8169.c from 4.20.15 and test
>> it on top of 5.0?
>> Meanwhile I'll look at the changes in
2019-03-14, 10:51:49 -0700, Eric Dumazet wrote:
>
>
> On 03/14/2019 10:40 AM, Sabrina Dubroca wrote:
> > 2019-03-14, 07:56:10 -0700, Eric Dumazet wrote:
> >>
> >>
> >> On 03/14/2019 07:15 AM, Sabrina Dubroca wrote:
> >>> 2019-03-14, 05:58:03 -0700, Eric Dumazet wrote:
>
>
> On 03/1
On 03/14/2019 10:40 AM, Sabrina Dubroca wrote:
> 2019-03-14, 07:56:10 -0700, Eric Dumazet wrote:
>>
>>
>> On 03/14/2019 07:15 AM, Sabrina Dubroca wrote:
>>> 2019-03-14, 05:58:03 -0700, Eric Dumazet wrote:
On 03/14/2019 03:15 AM, Sabrina Dubroca wrote:
> Commit 745e20f1b626 ("n
2019-03-14, 07:56:10 -0700, Eric Dumazet wrote:
>
>
> On 03/14/2019 07:15 AM, Sabrina Dubroca wrote:
> > 2019-03-14, 05:58:03 -0700, Eric Dumazet wrote:
> >>
> >>
> >> On 03/14/2019 03:15 AM, Sabrina Dubroca wrote:
> >>> Commit 745e20f1b626 ("net: add a recursion limit in xmit path")
> >>> introd
> I noticed that there's an IPR disclosure filed at the IETF[0] claiming a
> patent on the algorithm. I'm curious if you know whether Nokia has an
> official position on the use of that patent in this implementation if it
> becomes part of the kernel? :)
Hi Toke,
My understanding is that the GPLv
hi, My name is Veronica Ali, I sent an email message to you long ago
but I did not receive any answer from you. This is the reason, I write
you back to know if you receive my email message or not. Kindly reply
me so that I will resend to you the email message.
Regards.
Veronica Ali
Olga Albisser writes:
> DUALPI2 provides extremely low latency & loss to traffic that uses a
> scalable congestion controller (e.g. L4S, DCTCP) without degrading the
> performance of 'classic' traffic (e.g. Reno, Cubic etc.). It is intended
> to be the reference implementation of the IETF's DualQ
Hi Leandro,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Leandro-Dorileo/net-sched-taprio-fix-picos_per_byte-miscalculation/20190314-231519
config: sparc64-allmodconfig (attached as .config
Hi Leandro,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Leandro-Dorileo/net-sched-taprio-fix-picos_per_byte-miscalculation/20190314-231519
config: alpha-allyesconfig (attached as .config
Hi Leandro,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Leandro-Dorileo/net-sched-taprio-fix-picos_per_byte-miscalculation/20190314-231519
config: riscv-allyesconfig (attached as .config
On 2019/3/14 22:57, Greg KH wrote:
On Thu, Mar 14, 2019 at 10:41:57PM +0800, Jason Yan wrote:
On 2019/3/13 0:22, Greg KH wrote:
On Tue, Mar 12, 2019 at 10:58:39PM +0800, Jason Yan wrote:
On 2019/3/12 19:52, Greg KH wrote:
On Mon, Mar 11, 2019 at 05:18:33PM +0800, Jason Yan wrote:
Hi,
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy s
> Thanks for the additional info and for testing 4.20.15.
> To rule out that the issue is caused by a regression in network or
> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> it on top of 5.0?
> Meanwhile I'll look at the changes in the driver between 4.20 and 5.0.
Sure, n
On Thu, Mar 14, 2019 at 10:41:57PM +0800, Jason Yan wrote:
>
>
> On 2019/3/13 0:22, Greg KH wrote:
> > On Tue, Mar 12, 2019 at 10:58:39PM +0800, Jason Yan wrote:
> > >
> > >
> > > On 2019/3/12 19:52, Greg KH wrote:
> > > > On Mon, Mar 11, 2019 at 05:18:33PM +0800, Jason Yan wrote:
> > > > > Hi,
On 03/14/2019 07:15 AM, Sabrina Dubroca wrote:
> 2019-03-14, 05:58:03 -0700, Eric Dumazet wrote:
>>
>>
>> On 03/14/2019 03:15 AM, Sabrina Dubroca wrote:
>>> Commit 745e20f1b626 ("net: add a recursion limit in xmit path")
>>> introduced a recursion limit, but it only applies to devices without a
On 2019/3/13 0:22, Greg KH wrote:
On Tue, Mar 12, 2019 at 10:58:39PM +0800, Jason Yan wrote:
On 2019/3/12 19:52, Greg KH wrote:
On Mon, Mar 11, 2019 at 05:18:33PM +0800, Jason Yan wrote:
Hi, Daniel & Greg
This patch (979d63d50c0c bpf: prevent out of bounds speculation on pointer
arithmet
2019-03-14, 05:58:03 -0700, Eric Dumazet wrote:
>
>
> On 03/14/2019 03:15 AM, Sabrina Dubroca wrote:
> > Commit 745e20f1b626 ("net: add a recursion limit in xmit path")
> > introduced a recursion limit, but it only applies to devices without a
> > queue. Virtual devices with a queue (either becau
Adds missing sphinx documentation to the
socket.c's functions. Also fixes some whitespaces.
I also changed the style of older documentation as an
effort to have an uniform documentation style.
Signed-off-by: Pedro Tammela
---
Changes in v2:
- Fixed some mixed tab and spaces
- Added missing sig
Hello,
I'm trying to setup an Intel 82599-based card to have a few Virtual Functions
enabled on boot, even if the OS doesn't modify SR-IOV settings.
Is there any way to that? Can such settings be set in the card's EEPROM?
Thank you,
Marek S.
On 03/14/2019 03:15 AM, Sabrina Dubroca wrote:
> Commit 745e20f1b626 ("net: add a recursion limit in xmit path")
> introduced a recursion limit, but it only applies to devices without a
> queue. Virtual devices with a queue (either because they don't have
> the IFF_NO_QUEUE flag, or because the
Add documentation for the BPF spinlock-related helpers to the doc in
bpf.h. I added the constraints and restrictions coming with the use of
spinlocks for BPF: not all of it is directly related to the use of the
helper, but I thought it would be nice for users to find them in the man
page.
This lis
Synchronise the bpf.h header under tools, to report the latest fixes and
additions to the documentation for the BPF helpers.
Signed-off-by: Quentin Monnet
Reviewed-by: Jakub Kicinski
---
tools/include/uapi/linux/bpf.h | 183 +++--
1 file changed, 120 insertio
Hi,
This set is an update to the documentation for the BPF helper functions in
the UAPI header bpf.h, used to generate the bpf-helpers(7) man page.
First patch contains fixes to the current documentation. The second patch
adds documentation for the two helpers bpf_spin_lock() and
bpf_spin_unlock()
Another round of minor fixes for the documentation of the BPF helpers
located in the UAPI bpf.h header file. Changes include:
- Moving around description of some helpers, to keep the descriptions in
the same order as helpers are declared (bpf_map_push_elem(), leftover
from commit 90b1023f68c7
On Thu, Mar 14, 2019 at 03:51:59PM +0800, Xin Long wrote:
> On Thu, Mar 14, 2019 at 9:23 AM Marcelo Ricardo Leitner
> wrote:
> >
> > On Wed, Mar 13, 2019 at 01:06:21PM -0300, Marcelo Ricardo Leitner wrote:
> > > On Mon, Mar 11, 2019 at 08:09:19PM -0700, David Miller wrote:
> > > >
> > > > This pat
Make sure that returning a struct sock_common * reference invokes
the reference tracking machinery in the verifier.
Signed-off-by: Lorenz Bauer
---
.../selftests/bpf/verifier/ref_tracking.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/tools/testing/selftests/bpf/v
Add tests which verify that the new helpers work for both IPv4 and
IPv6, by forcing SYN cookies to always on. Use a new network namespace
to avoid clobbering the global SYN cookie settings.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/.gitignore| 1 +
tools/testing/selft
Using bpf_skc_lookup_tcp it's possible to ascertain whether a packet
belongs to a known connection. However, there is one corner case: no
sockets are created if SYN cookies are active. This means that the final
ACK in the 3WHS is misclassified.
Using the helper, we can look up the listening socket
Pull definitions for bpf_skc_lookup_tcp and bpf_sk_check_syncookie.
Signed-off-by: Lorenz Bauer
---
tools/include/uapi/linux/bpf.h | 36 +-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.
Make the BPF_SK_LOOKUP macro take a helper function, to ease
writing tests for new helpers.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/test_verifier.c | 6 +-
.../selftests/bpf/verifier/ref_tracking.c | 78 +--
tools/testing/selftests/bpf/verifier/unpriv.c
It's currently not possible to access timewait or request sockets
from eBPF, since there is no way to return a PTR_TO_SOCK_COMMON
from a helper. Introduce RET_PTR_TO_SOCK_COMMON to enable this
behaviour.
Signed-off-by: Lorenz Bauer
---
include/linux/bpf.h | 1 +
kernel/bpf/verifier.c | 4
So far, the verifier only acquires reference tracking state for
RET_PTR_TO_SOCKET_OR_NULL. Instead of extending this for every
new return type which desires these semantics, acquire reference
tracking state iff the called helper is an acquire function.
Signed-off-by: Lorenz Bauer
---
kernel/bpf/
Allow looking up a sock_common. This gives eBPF programs
access to timewait and request sockets.
Signed-off-by: Lorenz Bauer
---
include/uapi/linux/bpf.h | 20 ++-
kernel/bpf/verifier.c| 3 +-
net/core/filter.c| 113 +++
3 files changed, 124
This series adds the necessary helpers to determine wheter a given
(encapsulated) TCP packet belongs to a connection known to the network stack.
* bpf_skc_lookup_tcp gives access to request and timewait sockets
* bpf_tcp_check_syncookie identifies the final 3WHS ACK when syncookies
are enabled
Commit 745e20f1b626 ("net: add a recursion limit in xmit path")
introduced a recursion limit, but it only applies to devices without a
queue. Virtual devices with a queue (either because they don't have
the IFF_NO_QUEUE flag, or because the administrator added one) can
still cause an unbounded recu
My Name is Johann Reimann, I have a concealed business for you
On Thu, Mar 14, 2019 at 9:23 AM Marcelo Ricardo Leitner
wrote:
>
> On Wed, Mar 13, 2019 at 01:06:21PM -0300, Marcelo Ricardo Leitner wrote:
> > On Mon, Mar 11, 2019 at 08:09:19PM -0700, David Miller wrote:
> > >
> > > This patch series eliminates the explicit reference to the skb list
> > > implem
Wed, Mar 13, 2019 at 05:55:55PM CET, jakub.kicin...@netronome.com wrote:
>On Wed, 13 Mar 2019 17:22:43 +0100, Jiri Pirko wrote:
>> Wed, Mar 13, 2019 at 05:17:31PM CET, jakub.kicin...@netronome.com wrote:
>> >On Wed, 13 Mar 2019 07:07:01 +0100, Jiri Pirko wrote:
>> >> Tue, Mar 12, 2019 at 09:56:28
72 matches
Mail list logo
