* Re: [PATCH iproute2 net-next v4 5/6] tc: etf: Add documentation for skip-skb-check.
From: Patel, Vedang @ 2019-07-18 19:46 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
stephen@networkplumber.org, Gomes, Vinicius, Dorileo, Leandro,
jakub.kicinski@netronome.com, m-karicheri2@ti.com
In-Reply-To: <32e4deac-aaab-c437-1b76-529c16731877@gmail.com>
> On Jul 18, 2019, at 10:36 AM, David Ahern <dsahern@gmail.com> wrote:
>
> On 7/16/19 1:53 PM, Vedang Patel wrote:
>> Document the newly added option (skip-skb-check) on the etf man-page.
>>
>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
>> ---
>> man/man8/tc-etf.8 | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/man/man8/tc-etf.8 b/man/man8/tc-etf.8
>> index 30a12de7d2c7..2e01a591dbaa 100644
>> --- a/man/man8/tc-etf.8
>> +++ b/man/man8/tc-etf.8
>> @@ -106,6 +106,16 @@ referred to as "Launch Time" or "Time-Based Scheduling" by the
>> documentation of network interface controllers.
>> The default is for this option to be disabled.
>>
>> +.TP
>> +skip_skb_check
>
> patch 1 adds skip_sock_check.
>
Yes. I will fix this typo in the next version.
Thanks,
Vedang
>> +.br
>> +.BR etf(8)
>> +currently drops any packet which does not have a socket associated with it or
>> +if the socket does not have SO_TXTIME socket option set. But, this will not
>> +work if the launchtime is set by another entity inside the kernel (e.g. some
>> +other Qdisc). Setting the skip_skb_check will skip checking for a socket
>> +associated with the packet.
>> +
>> .SH EXAMPLES
>>
>> ETF is used to enforce a Quality of Service. It controls when each
^ permalink raw reply
* Re: [PATCH iproute2 net-next v4 1/6] Update kernel headers
From: Patel, Vedang @ 2019-07-18 19:45 UTC (permalink / raw)
To: David Ahern
Cc: netdev@vger.kernel.org, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
Stephen Hemminger, Gomes, Vinicius, Dorileo, Leandro,
Jakub Kicinski, Murali Karicheri
In-Reply-To: <f1a94a8c-ca50-f9db-795f-b5077a2d308e@gmail.com>
> On Jul 18, 2019, at 10:32 AM, David Ahern <dsahern@gmail.com> wrote:
>
> On 7/16/19 1:53 PM, Vedang Patel wrote:
>> The type for txtime-delay parameter will change from s32 to u32. So,
>> make the corresponding change in the ABI file as well.
>>
>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
>> ---
>> include/uapi/linux/pkt_sched.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
>> index 1f623252abe8..18f185299f47 100644
>> --- a/include/uapi/linux/pkt_sched.h
>> +++ b/include/uapi/linux/pkt_sched.h
>> @@ -1174,7 +1174,7 @@ enum {
>> TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME, /* s64 */
>> TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME_EXTENSION, /* s64 */
>> TCA_TAPRIO_ATTR_FLAGS, /* u32 */
>> - TCA_TAPRIO_ATTR_TXTIME_DELAY, /* s32 */
>> + TCA_TAPRIO_ATTR_TXTIME_DELAY, /* u32 */
>> __TCA_TAPRIO_ATTR_MAX,
>> };
>>
>>
>
> kernel uapi headers are synced from the kernel. You will need to make
> this change to the kernel header and it will make its way to iproute2
Okay, I will drop this patch in the next version.
Thanks,
Vedang
^ permalink raw reply
* [PATCH V36 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Matthew Garrett @ 2019-07-18 19:44 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, linux-api, David Howells,
Alexei Starovoitov, Matthew Garrett, netdev, Chun-Yi Lee,
Daniel Borkmann
In-Reply-To: <20190718194415.108476-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
private keys in kernel memory to be leaked. Disable them if the kernel
has been locked down in confidentiality mode.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Matthew Garrett <mjg59@google.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/security.h | 1 +
kernel/trace/bpf_trace.c | 10 ++++++++++
security/lockdown/lockdown.c | 1 +
3 files changed, 12 insertions(+)
diff --git a/include/linux/security.h b/include/linux/security.h
index 987d8427f091..8dd1741a52cd 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -118,6 +118,7 @@ enum lockdown_reason {
LOCKDOWN_INTEGRITY_MAX,
LOCKDOWN_KCORE,
LOCKDOWN_KPROBES,
+ LOCKDOWN_BPF_READ,
LOCKDOWN_CONFIDENTIALITY_MAX,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index ca1255d14576..492a8bfaae98 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -142,8 +142,13 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const void *, unsafe_ptr)
{
int ret;
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (ret < 0)
+ goto out;
+
ret = probe_kernel_read(dst, unsafe_ptr, size);
if (unlikely(ret < 0))
+out:
memset(dst, 0, size);
return ret;
@@ -569,6 +574,10 @@ BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
{
int ret;
+ ret = security_locked_down(LOCKDOWN_BPF_READ);
+ if (ret < 0)
+ goto out;
+
/*
* The strncpy_from_unsafe() call will likely not fill the entire
* buffer, but that's okay in this circumstance as we're probing
@@ -580,6 +589,7 @@ BPF_CALL_3(bpf_probe_read_str, void *, dst, u32, size,
*/
ret = strncpy_from_unsafe(dst, unsafe_ptr, size);
if (unlikely(ret < 0))
+out:
memset(dst, 0, size);
return ret;
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 6b123cbf3748..1b89d3e8e54d 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -33,6 +33,7 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_INTEGRITY_MAX] = "integrity",
[LOCKDOWN_KCORE] = "/proc/kcore access",
[LOCKDOWN_KPROBES] = "use of kprobes",
+ [LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply related
* Re: [PATCH] net: fec: generate warning when using deprecated phy reset
From: Andrew Lunn @ 2019-07-18 19:41 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Fabio Estevam, Lucas Stach, Fugang Duan, David S . Miller, netdev,
linux-kernel
In-Reply-To: <CAGngYiULAjXwwxmUyHxEXhv1WzSeE_wE3idOLSnD5eEaZg3xDw@mail.gmail.com>
On Thu, Jul 18, 2019 at 01:21:36PM -0400, Sven Van Asbroeck wrote:
> Lucas, Fabio,
>
> On Thu, Jul 18, 2019 at 12:52 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > > Not really a fan of this. This will cause existing DTs, which are
> > > provided by the firmware in an ideal world and may not change at the
> > > same rate as the kernel, to generate a warning with new kernels. Not
> > > really helpful from the user experience point of view.
> >
> > I agree. I don't think this warning is useful.
>
> Few users watch the dmesg log, But I totally see your point.
>
> The problem I'm trying to address here is this: when I want to
> reset the fec phy, I go look at existing devicetrees. Nearly
> all of them use phy-reset-gpios, so that's what I'll use. But,
> when I try to upstream the patch, the maintainer will tell me:
> "no, that is deprecated, use this other method".
>
> Is there a good solution you can think of which would point
> the unwary developer to the correct phy reset method?
Hi Sven
One option would be to submit a patch or a patchset changing all
existing device tree files to make use of the core method. Anybody
cut/pasting will then automatically use the correct core way of doing
it.
There is also a move towards using YAML to verify the correctness of
DT files. It should be possible to mark the old property as
deprecated, so there will be a build time warning, not a boot time
warning.
Andrew
^ permalink raw reply
* Re: [PATCH net,v4 0/4] flow_offload fixes
From: David Miller @ 2019-07-18 19:39 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev, jiri, jakub.kicinski, pshelar
In-Reply-To: <20190718175931.13529-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 18 Jul 2019 19:59:27 +0200
> The following patchset contains fixes for the flow_offload infrastructure:
>
> 1) Fix possible build breakage before patch 3/4. Both the flow_offload
> infrastructure and OVS define the flow_stats structure. Patch 3/4 in
> this batch indirectly pulls in the flow_stats definition from
> include/net/flow_offload.h into OVS, leading to structure redefinition
> compile-time errors.
>
> 2) Remove netns parameter from flow_block_cb_alloc(), this is not
> required as Jiri suggests. The flow_block_cb_is_busy() function uses
> the per-driver block list to check for used blocks which was the
> original intention for this parameter.
>
> 3) Rename tc_setup_cb_t to flow_setup_cb_t. This callback is not
> exclusive of tc anymore, this might confuse the reader as Jiri
> suggests, fix this semantic inconsistency.
>
> 4) Fix block sharing feature: Add flow_block structure and use it,
> update flow_block_cb_lookup() to use this flow_block object.
>
> Please, apply, thanks.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.2 226/249] selftests: bpf: fix inlines in test_lwt_seg6local
From: Sasha Levin @ 2019-07-18 19:32 UTC (permalink / raw)
To: Jiri Benc
Cc: linux-kernel, stable, Yonghong Song, Daniel Borkmann,
linux-kselftest, netdev, bpf, clang-built-linux
In-Reply-To: <20190718093654.0a3426f5@redhat.com>
On Thu, Jul 18, 2019 at 09:36:54AM +0200, Jiri Benc wrote:
>On Wed, 17 Jul 2019 19:47:57 -0400, Sasha Levin wrote:
>> It fixes a bug, right?
>
>A bug in selftests. And quite likely, it probably happens only with
>some compiler versions.
>
>I don't think patches only touching tools/testing/selftests/ qualify
>for stable in general. They don't affect the end users.
I'd argue that a bug in your tests is just as (if not even more) worse
than a bug in the code.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] net: fec: generate warning when using deprecated phy reset
From: Sven Van Asbroeck @ 2019-07-18 19:26 UTC (permalink / raw)
To: David Miller
Cc: Fugang Duan, netdev, Linux Kernel Mailing List, Fabio Estevam,
Lucas Stach
In-Reply-To: <20190718.120600.607199310950720839.davem@davemloft.net>
On Thu, Jul 18, 2019 at 3:06 PM David Miller <davem@davemloft.net> wrote:
>
> The device tree documentation in the kernel tree is where information
> like this belongs. Yelling at the user in the kernel logs is not.
Good point, thank you. I'll post a patch which will do exactly that.
^ permalink raw reply
* Re: [PATCH bpf] libbpf: fix missing __WORDSIZE definition
From: Arnaldo Carvalho de Melo @ 2019-07-18 19:14 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, bpf, Networking, Daniel Borkmann,
Alexei Starovoitov, Kernel Team, Jiri Olsa, Namhyung Kim
In-Reply-To: <20190718185619.GL3624@kernel.org>
Em Thu, Jul 18, 2019 at 03:56:19PM -0300, Arnaldo Carvalho de Melo escreveu:
> I'll stop and replace my patch with yours to see if it survives all the
> test builds...
So, Alpine:3.4, the first image for this distro I did when I started
these builds, survives the 6 builds with gcc and clang with your patch:
[perfbuilder@quaco linux-perf-tools-build]$ export PERF_TARBALL=http://192.168.124.1/perf/perf-5.2.0.tar.xz
[perfbuilder@quaco linux-perf-tools-build]$ dm
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0, clang version 3.8.0 (tags/RELEASE_380/final)
[perfbuilder@quaco linux-perf-tools-build]$ grep "+ make" dm.log/alpine\:3.4
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= -C /git/linux/tools/perf O=/tmp/build/perf
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= NO_LIBELF=1 -C /git/linux/tools/perf O=/tmp/build/perf
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= -C /git/linux/tools/perf O=/tmp/build/perf CC=clang
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= NO_LIBELF=1 -C /git/linux/tools/perf O=/tmp/build/perf CC=clang
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= LIBCLANGLLVM=1 -C /git/linux/tools/perf O=/tmp/build/perf CC=clang
+ make ARCH= CROSS_COMPILE= EXTRA_CFLAGS= LIBCLANGLLVM=1 -C /git/linux/tools/perf O=/tmp/build/perf
[perfbuilder@quaco linux-perf-tools-build]$
Probably all the rest will go well, will let you know.
Daniel, do you mind if I carry this one in my perf/core branch? Its
small and shouldn't clash with other patches, I think. It should go
upstream soon:
Andrii, there are these others:
8dfb6ed300bf tools lib bpf: Avoid designated initializers for unnamed union members
80f7f8f21441 tools lib bpf: Avoid using 'link' as it shadows a global definition in some systems
d93fe741e291 tools lib bpf: Fix endianness macro usage for some compilers
If you could take a look at them at my tmp.perf/core branch at:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=tmp.perf/core
I'm force pushing it now to replace my __WORDSIZE patch with yours, the
SHAs should be the 3 above and the one below.
And to build cleanly I had to cherry pick this one:
3091dafc1884 (HEAD -> perf/core) libbpf: fix ptr to u64 conversion warning on 32-bit platforms
Alpine:3.5 just finished:
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822, clang version 3.8.1 (tags/RELEASE_381/final)
- Arnaldo
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: Replace kfree with kvfree
From: David Miller @ 2019-07-18 19:11 UTC (permalink / raw)
To: saeedm; +Cc: hslester96, linux-rdma, netdev, leon, linux-kernel
In-Reply-To: <76783a8ca91cb7d0e454cf699c4984243df0081d.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 18 Jul 2019 18:38:34 +0000
> On Wed, 2019-07-17 at 18:14 +0800, Chuhong Yuan wrote:
>> Variable allocated by kvmalloc should not be freed by kfree.
>> Because it may be allocated by vmalloc.
>> So replace kfree with kvfree here.
>>
>> Fixes: 9b1f298236057 ("net/mlx5: Add support for FW fatal reporter
>> dump")
>> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Dave, i guess this can go to net.
Ok, applied.
^ permalink raw reply
* Re: [PATCH net-next 00/12] mlx5 TLS TX HW offload support
From: David Miller @ 2019-07-18 19:09 UTC (permalink / raw)
To: jakub.kicinski; +Cc: tariqt, netdev, eranbe, saeedm, moshe
In-Reply-To: <20190718100847.52d6314b@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Thu, 18 Jul 2019 10:08:47 -0700
> Yes, certainly. It's documentation and renaming a stat before it makes
> it into an official release.
Agreed.
^ permalink raw reply
* Re: [PATCH] openvswitch: Fix a possible memory leak on dst_cache
From: David Miller @ 2019-07-18 19:08 UTC (permalink / raw)
To: yanhaishuang; +Cc: pshelar, netdev, linux-kernel
In-Reply-To: <1563466028-2531-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Fri, 19 Jul 2019 00:07:08 +0800
> dst_cache should be destroyed when fail to add flow actions.
>
> Fixes: d71785ffc7e7 ("net: add dst_cache to ovs vxlan lwtunnel")
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
OVS folks, please review.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update netsec driver
From: David Miller @ 2019-07-18 19:06 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel
In-Reply-To: <1563460710-28454-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 18 Jul 2019 17:38:30 +0300
> Add myself to maintainers since i provided the XDP and page_pool
> implementation
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fec: generate warning when using deprecated phy reset
From: David Miller @ 2019-07-18 19:06 UTC (permalink / raw)
To: thesven73; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <20190718143428.2392-1-TheSven73@gmail.com>
From: Sven Van Asbroeck <thesven73@gmail.com>
Date: Thu, 18 Jul 2019 10:34:28 -0400
> Allowing the fec to reset its PHY via the phy-reset-gpios
> devicetree property is deprecated. To improve developer
> awareness, generate a warning whenever the deprecated
> property is used.
>
> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
The device tree documentation in the kernel tree is where information
like this belongs. Yelling at the user in the kernel logs is not.
^ permalink raw reply
* Re: [PATCH net] ipv6: Unlink sibling route in case of failure
From: David Miller @ 2019-07-18 19:03 UTC (permalink / raw)
To: dsahern; +Cc: idosch, netdev, alexpe, mlxsw, idosch
In-Reply-To: <f6dacc3e-7b20-2441-dd7d-99d3983bddc3@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 18 Jul 2019 08:21:01 -0600
> On 7/17/19 2:39 PM, Ido Schimmel wrote:
>> From: Ido Schimmel <idosch@mellanox.com>
>>
>> When a route needs to be appended to an existing multipath route,
>> fib6_add_rt2node() first appends it to the siblings list and increments
>> the number of sibling routes on each sibling.
>>
>> Later, the function notifies the route via call_fib6_entry_notifiers().
>> In case the notification is vetoed, the route is not unlinked from the
>> siblings list, which can result in a use-after-free.
>>
>> Fix this by unlinking the route from the siblings list before returning
>> an error.
>>
>> Audited the rest of the call sites from which the FIB notification chain
>> is called and could not find more problems.
>>
>> Fixes: 2233000cba40 ("net/ipv6: Move call_fib6_entry_notifiers up for route adds")
>> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>> Reported-by: Alexander Petrovskiy <alexpe@mellanox.com>
>> ---
>> Dave, this will not apply cleanly to stable trees due to recent changes
>> in net-next. I can prepare another patch for stable if needed.
>> ---
>> net/ipv6/ip6_fib.c | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>
> Thanks for the fix, Ido. I can help with the ports as well.
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
Applied and queued up for -stable.
Since I've done a bunch of ipv6 routing fix backports through David's
refactoring and cleanups, I'll give this one a try too :-) If I run
into problems I'll ask for help.
Thanks.
^ permalink raw reply
* Re: [PATCH] [net-next] netfilter: bridge: make NF_TABLES_BRIDGE tristate
From: Pablo Neira Ayuso @ 2019-07-18 19:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jozsef Kadlecsik, Florian Westphal, Roopa Prabhu,
Nikolay Aleksandrov, David S. Miller, wenxu, netfilter-devel,
coreteam, bridge, netdev, linux-kernel
In-Reply-To: <20190710080835.296696-1-arnd@arndb.de>
On Wed, Jul 10, 2019 at 10:08:20AM +0200, Arnd Bergmann wrote:
> The new nft_meta_bridge code fails to link as built-in when NF_TABLES
> is a loadable module.
>
> net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_get_eval':
> nft_meta_bridge.c:(.text+0x1e8): undefined reference to `nft_meta_get_eval'
> net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_get_init':
> nft_meta_bridge.c:(.text+0x468): undefined reference to `nft_meta_get_init'
> nft_meta_bridge.c:(.text+0x49c): undefined reference to `nft_parse_register'
> nft_meta_bridge.c:(.text+0x4cc): undefined reference to `nft_validate_register_store'
> net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_module_exit':
> nft_meta_bridge.c:(.exit.text+0x14): undefined reference to `nft_unregister_expr'
> net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_module_init':
> nft_meta_bridge.c:(.init.text+0x14): undefined reference to `nft_register_expr'
> net/bridge/netfilter/nft_meta_bridge.o:(.rodata+0x60): undefined reference to `nft_meta_get_dump'
> net/bridge/netfilter/nft_meta_bridge.o:(.rodata+0x88): undefined reference to `nft_meta_set_eval'
>
> This can happen because the NF_TABLES_BRIDGE dependency itself is just a
> 'bool'. Make the symbol a 'tristate' instead so Kconfig can propagate the
> dependencies correctly.
Hm. Something breaks here. Investigating. Looks like bridge support is
gone after this, nft fails to register the filter chain type:
# nft add table bridge x
# nft add chain bridge x y { type filter hook input priority 0\; }
Error: Could not process rule: No such file or directory
^ permalink raw reply
* Re: pull-request: wireless-drivers 2019-07-18
From: David Miller @ 2019-07-18 19:00 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87y30v1lub.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 18 Jul 2019 17:03:24 +0300
> here are first fixes which have accumulated during the merge window.
> This pull request is to net tree for 5.3. Please let me know if there
> are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH bpf] libbpf: fix missing __WORDSIZE definition
From: Arnaldo Carvalho de Melo @ 2019-07-18 18:56 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Arnaldo Carvalho de Melo, Andrii Nakryiko, bpf, Networking,
Daniel Borkmann, Alexei Starovoitov, Kernel Team, Jiri Olsa,
Namhyung Kim
In-Reply-To: <CAEf4BzaPySx-hBwD5Lxo1tD7F_8ejA9qFjC0-ag56cakweqcbA@mail.gmail.com>
Em Thu, Jul 18, 2019 at 11:04:04AM -0700, Andrii Nakryiko escreveu:
> On Thu, Jul 18, 2019 at 10:55 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Thu, Jul 18, 2019 at 10:25:13AM -0700, Andrii Nakryiko escreveu:
> > > hashmap.h depends on __WORDSIZE being defined. It is defined by
> > > glibc/musl in different headers. It's an explicit goal for musl to be
> > > "non-detectable" at compilation time, so instead include glibc header if
> > > glibc is explicitly detected and fall back to musl header otherwise.
> > >
> > > Fixes: e3b924224028 ("libbpf: add resizable non-thread safe internal hashmap")
> > > Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> >
> > I fixed this here differently, as below, I didn't send it because I'm still
> > testing it, so far, with a few other fixes and cherry-picking "libbpf: fix ptr
> > to u64 conversion warning on 32-bit platforms" that is still in the bpf tree
> > and is needed for the cross build containers in my suite that are 32-bit, I
> > have the results below, this builds perf + libbpf (where elfutils is available,
> > which is in most cases, except the uCLibc containers due to missing argp-devel),
> > with gcc and with clang:
> >
> > [perfbuilder@quaco linux-perf-tools-build]$ export PERF_TARBALL=http://192.168.124.1/perf/perf-5.2.0.tar.xz
> > [perfbuilder@quaco linux-perf-tools-build]$ time dm
> > 1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0, clang version 3.8.0 (tags/RELEASE_380/final)
> > 2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822, clang version 3.8.1 (tags/RELEASE_381/final)
> > 3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0, clang version 4.0.0 (tags/RELEASE_400/final)
> > 4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0)
> > 5 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
> > 6 alpine:3.9 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1)
> > 7 alpine:3.10 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0)
> > 8 alpine:edge : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1)
> > 9 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2), clang version 3.6.2 (tags/RELEASE_362/final)
> > 10 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5), clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2)
> > 11 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
> > 12 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
> > 13 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
> > 14 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
> > 15 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), clang version 3.4.2 (tags/RELEASE_34/dot2-final)
> > 16 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 9.1.1 20190628 gcc-9-branch@272773, clang version 8.0.0 (tags/RELEASE_800/final)
> > 17 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u2) 4.9.2, Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
> > 18 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, clang version 3.8.1-24 (tags/RELEASE_381/final)
> > 19 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0, clang version 7.0.1-8 (tags/RELEASE_701/final)
> > 20 debian:experimental : Ok gcc (Debian 8.3.0-19) 8.3.0, clang version 7.0.1-8 (tags/RELEASE_701/final)
> > 21 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 8.3.0-19) 8.3.0
> > 22 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 8.3.0-19) 8.3.0
> > 23 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 8.3.0-7) 8.3.0
> > 24 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 8.3.0-19) 8.3.0
> > 25 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7), clang version 3.4.2 (tags/RELEASE_34/dot2-final)
> > 26 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.5.0 (tags/RELEASE_350/final)
> > 27 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.7.0 (tags/RELEASE_370/final)
> > 28 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1), clang version 3.8.1 (tags/RELEASE_381/final)
> > 29 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
> >
> > I've pushed it to a tmp.perf/core branch in my
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tree, that has
> > these:
> >
> > d5e1f2d60d41 (HEAD -> perf/core, acme.korg/tmp.perf/core) libbpf: fix ptr to u64 conversion warning on 32-bit platforms
> > 7c08fd16f917 tools lib bpf: Avoid designated initializers for unnamed union members
> > 4c9f83c95ad6 tools lib bpf: Avoid using 'link' as it shadows a global definition in some systems
> > bdb07df4a0ad tools lib bpf: Fix endianness macro usage for some compilers
> > 66dbf3caff52 tools lib bpf: Replace __WORDSIZE with BITS_PER_LONG to build on the musl libc
> >
> > Please take a look and check if everything is fine on your side. The HEAD I'll
> > remove if Daniel thinks it should wait that landing via the BPF tree, I just put it
> > there for the test builds.
> >
> > commit 66dbf3caff52be0d004bcb9ac4cea4c19eb75dfc
> > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Date: Thu Jul 18 09:46:28 2019 -0300
> >
> > tools lib bpf: Replace __WORDSIZE with BITS_PER_LONG to build on the musl libc
> >
> > BITS_PER_LONG is more generally available and equivalent to __WORDSIZE,
> > so use it instead to keep it building in systems using the mustl libc
> > where __WORDSIZE is in a different place than in glibc.
> >
> > And do this by explicitely adding the header where this definition is
> > (asm/bitsperlong.h) instead of getting it indirectly.
> >
> > Cc: Adrian Hunter <adrian.hunter@intel.com>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > Cc: Andrii Nakryiko <andriin@fb.com>
> > Cc: Jiri Olsa <jolsa@kernel.org>
> > Cc: Namhyung Kim <namhyung@kernel.org>
> > Fixes: e3b924224028 ("libbpf: add resizable non-thread safe internal hashmap")
> > Link: https://lkml.kernel.org/n/tip-61vydgldzmmz5w2mf6rv3ryl@git.kernel.org
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> >
> > diff --git a/tools/lib/bpf/hashmap.h b/tools/lib/bpf/hashmap.h
> > index 03748a742146..f1f37b574d9c 100644
> > --- a/tools/lib/bpf/hashmap.h
> > +++ b/tools/lib/bpf/hashmap.h
> > @@ -10,12 +10,13 @@
> >
> > #include <stdbool.h>
> > #include <stddef.h>
> > +#include <asm/bitsperlong.h>
>
> Relying on this header is problematic when syncing libbpf into Github
> mirror. There we'll need to re-implement it anyway, and again,
> probably through __WORDSIZE or some other tricks. So if we can do away
> without kernel specific header that would be great.
[acme@quaco perf]$ rpm -qf /usr/include/asm/bitsperlong.h
kernel-headers-5.1.16-300.fc30.x86_64
It is kernel specific, but it comes from a distro package, and one that
is even required to build anything that uses glibc:
[acme@quaco perf]$ rpm -q --whatrequires kernel-headers
glibc-headers-2.29-15.fc30.x86_64
audit-libs-devel-3.0-0.9.20190507gitf58ec40.fc30.x86_64
libnl3-devel-3.4.0-8.fc30.x86_64
[acme@quaco perf]$
[acme@quaco perf]$ rpm -q --whatrequires glibc-headers
glibc-devel-2.29-15.fc30.x86_64
[acme@quaco perf]$
It is available everywhere:
Alpine, for instance:
$ dsh alpine:3.10
/ $ apk info --who-owns /usr/include/asm/bitsperlong.h
/usr/include/asm/bitsperlong.h is owned by linux-headers-4.19.36-r0
/ $
/ $ cat /etc/alpine-release
3.10.0
OpenSuSE:
$ dsh opensuse:42.3
sh-4.3$ grep PRETTY /etc/os-release
PRETTY_NAME="openSUSE Leap 42.3"
sh-4.3$ ls -la /usr/include/asm/bitsperlong.h
-rw-r--r--. 1 root root 258 Jan 15 2016 /usr/include/asm/bitsperlong.h
sh-4.3$ set -o vi
sh-4.3$ rpm -qf /usr/include/asm/bitsperlong.h
linux-glibc-devel-4.4-6.3.1.noarch
sh-4.3$
sh-4.3$ exit
ClearLinux:
$ dsh clearlinux:latest
sh-5.0$ ls -la /usr/include/asm/bitsperlong.h
-rw-r--r-- 2 root root 321 Feb 1 20:26 /usr/include/asm/bitsperlong.h
sh-5.0$
I see what you mean tho, tools/arch and tools/include _have_
bitsperlong.h as well and the perf build is using that... And I checked
and the above don't have BITS_PER_LONG, just some have __BITS_PER_LONG,
etc... /me scratches head, so what we ended up in the tools/include to
solve that was:
#ifdef __SIZEOF_LONG__
#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
#else
#define BITS_PER_LONG __WORDSIZE
#endif
To help in you deciding how you want to fix this:
commit e81fcd43723d32e9c9dbb8e8d66f147b5b84256b
Author: Peter Zijlstra <peterz@infradead.org>
Date: Fri Jul 15 12:38:18 2016 -0300
tools: Simplify BITS_PER_LONG define
Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
reduces the complexity by ditching CONFIG_64BIT, that was being
synthesized from yet another set of defines, which proved fragile,
breaking the build on linux-next for no obvious reasons.
Committer Note:
Except on:
gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
Fallback to __WORDSIZE in that case...
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160715072243.GP30154@twins.programming.kicks-ass.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Using the tools/{include,arch} headers as perf does it is continuing to
build without failures, in addition to the set of containers first
reported:
30 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1), clang version 3.9.1 (tags/RELEASE_391/final)
31 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2), clang version 4.0.1 (tags/RELEASE_401/final)
32 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6), clang version 5.0.2 (tags/RELEASE_502/final)
33 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 6.0.1 (tags/RELEASE_601/final)
34 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 7.0.1 (Fedora 7.0.1-6.fc29)
35 fedora:30 : Ok gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), clang version 8.0.0 (Fedora 8.0.0-1.fc30)
36 fedora:30-x-ARC-glibc : Ok arc-linux-gcc (ARC HS GNU/Linux glibc toolchain 2019.03-rc1) 8.3.1 20190225
37 fedora:30-x-ARC-uClibc : Ok arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
38 fedora:31 : Ok gcc (GCC) 9.1.1 20190605 (Red Hat 9.1.1-2), clang version 8.0.0 (Fedora 8.0.0-3.fc31)
39 fedora:rawhide : Ok gcc (GCC) 9.1.1 20190605 (Red Hat 9.1.1-2), clang version 8.0.0 (Fedora 8.0.0-3.fc31)
40 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0
41 mageia:5 : Ok gcc (GCC) 4.9.2, clang version 3.5.2 (tags/RELEASE_352/final)
42 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0, clang version 3.9.1 (tags/RELEASE_391/final)
I'll stop and replace my patch with yours to see if it survives all the
test builds...
- Arnaldo
> > #include "libbpf_internal.h"
> >
> > static inline size_t hash_bits(size_t h, int bits)
> > {
> > /* shuffle bits and return requested number of upper bits */
> > - return (h * 11400714819323198485llu) >> (__WORDSIZE - bits);
> > + return (h * 11400714819323198485llu) >> (BITS_PER_LONG - bits);
> > }
> >
> > typedef size_t (*hashmap_hash_fn)(const void *key, void *ctx);
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH 2/3] liquidio: Replace vmalloc + memset with vzalloc
From: David Miller @ 2019-07-18 18:55 UTC (permalink / raw)
To: hslester96; +Cc: dchickles, sburla, fmanlunas, netdev, linux-kernel
In-Reply-To: <20190718074542.16329-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Thu, 18 Jul 2019 15:45:42 +0800
> Use vzalloc and vzalloc_node instead of using vmalloc and
> vmalloc_node and then zeroing the allocated memory by
> memset 0.
> This simplifies the code.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.2 226/249] selftests: bpf: fix inlines in test_lwt_seg6local
From: David Miller @ 2019-07-18 18:55 UTC (permalink / raw)
To: jbenc
Cc: sashal, linux-kernel, stable, yhs, daniel, linux-kselftest,
netdev, bpf, clang-built-linux
In-Reply-To: <20190718093654.0a3426f5@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Thu, 18 Jul 2019 09:36:54 +0200
> On Wed, 17 Jul 2019 19:47:57 -0400, Sasha Levin wrote:
>> It fixes a bug, right?
>
> A bug in selftests. And quite likely, it probably happens only with
> some compiler versions.
>
> I don't think patches only touching tools/testing/selftests/ qualify
> for stable in general. They don't affect the end users.
It has a significant impact on automated testing which lots of
individuals and entities perform, therefore I think it very much is
-stable material.
^ permalink raw reply
* Re: [PATCH] udp: Fix typo in net/ipv4/udp.c
From: David Miller @ 2019-07-18 18:52 UTC (permalink / raw)
To: suyj.fnst; +Cc: kuznet, netdev, linux-kernel
In-Reply-To: <1563416363-7036-1-git-send-email-suyj.fnst@cn.fujitsu.com>
From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
Date: Thu, 18 Jul 2019 10:19:23 +0800
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
Several problems with this patch submission:
1) Please always make it clear when you post a new version of a patch
using indications in the Subject line such as "[PATCH v2]" or
similar.
Otherwise I assume it is a different change altogether and not
related to any other patch.
2) The targetted subsystem or tree must be clearly identified in the
subject line, for this you should say "[PATCH net v2]" since you
are targetting my networking bug fix GIT tree.
Thank you.
^ permalink raw reply
* Re: [PATCH bpf] tools/bpf: fix bpftool build with OUTPUT set
From: Jakub Kicinski @ 2019-07-18 18:51 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, lmb, gor, heiko.carstens
In-Reply-To: <20190718142041.83342-1-iii@linux.ibm.com>
On Thu, 18 Jul 2019 16:20:41 +0200, Ilya Leoshkevich wrote:
> Hi Lorenz,
>
> I've been using the following patch for quite some time now.
> Please let me know if it works for you.
>
> Best regards,
> Ilya
>
> ---
>
> When OUTPUT is set, bpftool and libbpf put their objects into the same
> directory, and since some of them have the same names, the collision
> happens.
>
> Fix by invoking libbpf build in a manner similar to $(call descend) -
> descend itself cannot be used, since libbpf is a sibling, and not a
> child, of bpftool.
>
> Also, don't link bpftool with libbpf.a twice.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> tools/bpf/bpftool/Makefile | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index a7afea4dec47..2cbc3c166f44 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -15,23 +15,18 @@ else
> endif
>
> BPF_DIR = $(srctree)/tools/lib/bpf/
> -
> -ifneq ($(OUTPUT),)
> - BPF_PATH = $(OUTPUT)
> -else
> - BPF_PATH = $(BPF_DIR)
> -endif
> -
> -LIBBPF = $(BPF_PATH)libbpf.a
> +BPF_PATH = $(objtree)/tools/lib/bpf
objtree won't be set for simple make in the directory. Perhaps we
should stick to using OUTPUT and srctree?
We should probably make a script with all the ways of calling make
should work. Otherwise we can lose track too easily.
# thru kbuild
make tools/bpf
T=$(mktemp -d)
make tools/bpf OUTPUT=$T
rm -rf $T
# from kernel source tree
make -C tools/bpf/bpftool
T=$(mktemp -d)
make -C tools/bpf/bpftool OUTPUT=$T
rm -rf $T
# from tools
cd tools/
make bpf
T=$(mktemp -d)
make bpf OUTPUT=$T
rm -rf $T
# from bpftool's dir
cd bpf/bpftool
make
T=$(mktemp -d)
make OUTPUT=$T
rm -rf $T
.. add your own.
> +LIBBPF = $(BPF_PATH)/libbpf.a
>
> BPFTOOL_VERSION := $(shell make --no-print-directory -sC ../../.. kernelversion)
>
> $(LIBBPF): FORCE
> - $(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(OUTPUT) $(OUTPUT)libbpf.a
> + $(Q)mkdir -p $(BPF_PATH)
> + $(Q)$(MAKE) $(COMMAND_O) subdir=tools/lib/bpf -C $(BPF_DIR) $(LIBBPF)
>
> $(LIBBPF)-clean:
> $(call QUIET_CLEAN, libbpf)
> - $(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(OUTPUT) clean >/dev/null
> + $(Q)$(MAKE) $(COMMAND_O) subdir=tools/lib/bpf -C $(BPF_DIR) clean >/dev/null
>
> prefix ?= /usr/local
> bash_compdir ?= /usr/share/bash-completion/completions
> @@ -112,7 +107,7 @@ $(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
> $(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
>
> $(OUTPUT)bpftool: $(OBJS) $(LIBBPF)
> - $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
> + $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
>
> $(OUTPUT)%.o: %.c
> $(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
^ permalink raw reply
* Re: [PATCH] net: bcmgenet: use promisc for unsupported filters
From: David Miller @ 2019-07-18 18:46 UTC (permalink / raw)
To: f.fainelli
Cc: justinpopo6, netdev, linux-kernel, bcm-kernel-feedback-list,
opendmb
In-Reply-To: <5f6422b5-e839-1600-6749-048a7e31ea96@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 17 Jul 2019 20:38:47 -0700
>
>
> On 7/17/2019 2:58 PM, justinpopo6@gmail.com wrote:
>> From: Justin Chen <justinpopo6@gmail.com>
>>
>> Currently we silently ignore filters if we cannot meet the filter
>> requirements. This will lead to the MAC dropping packets that are
>> expected to pass. A better solution would be to set the NIC to promisc
>> mode when the required filters cannot be met.
>>
>> Also correct the number of MDF filters supported. It should be 17,
>> not 16.
>>
>> Signed-off-by: Justin Chen <justinpopo6@gmail.com>
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] Signed-off-by: Peter Kosyh <p.kosyh@gmail.com>
From: David Miller @ 2019-07-18 18:44 UTC (permalink / raw)
To: dsa; +Cc: p.kosyh, shrijeet, netdev, linux-kernel
In-Reply-To: <213bada2-fe81-3c14-1506-11abf0f3ca22@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 18 Jul 2019 08:02:45 -0600
> your subject line needs a proper Subject - a one-line summary of the
> change starting with 'vrf:'. See examples from 'git log drivers/net/vrf.c'
Indeed, you really need to fix this even for your second submission as it
had the same exact problem.
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: Replace kfree with kvfree
From: Saeed Mahameed @ 2019-07-18 18:38 UTC (permalink / raw)
To: hslester96@gmail.com
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, leon@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190717101456.17401-1-hslester96@gmail.com>
On Wed, 2019-07-17 at 18:14 +0800, Chuhong Yuan wrote:
> Variable allocated by kvmalloc should not be freed by kfree.
> Because it may be allocated by vmalloc.
> So replace kfree with kvfree here.
>
> Fixes: 9b1f298236057 ("net/mlx5: Add support for FW fatal reporter
> dump")
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Dave, i guess this can go to net.
Thanks,
Saeed.
> ---
> Changes in v2:
> - Add corresponding Fixes tag
>
> drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> index 2fe6923f7ce0..9314777d99e3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct
> devlink_health_reporter *reporter,
> err = devlink_fmsg_arr_pair_nest_end(fmsg);
>
> free_data:
> - kfree(cr_data);
> + kvfree(cr_data);
> return err;
> }
>
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nft_meta: Fix build error
From: Pablo Neira Ayuso @ 2019-07-18 18:30 UTC (permalink / raw)
To: YueHaibing
Cc: davem, kadlec, fw, roopa, nikolay, wenxu, linux-kernel, netdev,
bridge, coreteam, netfilter-devel
In-Reply-To: <20190709070126.29972-1-yuehaibing@huawei.com>
On Tue, Jul 09, 2019 at 03:01:26PM +0800, YueHaibing wrote:
> If NFT_BRIDGE_META is y and NF_TABLES is m, building fails:
>
> net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_get_init':
> nft_meta_bridge.c:(.text+0xd0): undefined reference to `nft_parse_register'
> nft_meta_bridge.c:(.text+0xec): undefined reference to `nft_validate_register_store'
I took this one from Arnd instead:
https://patchwork.ozlabs.org/patch/1130262/
Thanks.
^ 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