* Re: [PATCH bpf-next v4 3/7] selftests/bpf: add MPTCP test base
From: Geliang Tang @ 2022-05-17 5:28 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Mat Martineau, Networking, bpf, Nicolas Rybowski,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
MPTCP Upstream, Matthieu Baerts, Geliang Tang
In-Reply-To: <20220517011827.6pk2ao23tb4xjuap@kafai-mbp.dhcp.thefacebook.com>
Martin KaFai Lau <kafai@fb.com> 于2022年5月17日周二 09:18写道：
>
> On Fri, May 13, 2022 at 03:48:23PM -0700, Mat Martineau wrote:
> [ ... ]
>
> > @@ -265,7 +282,7 @@ int connect_to_fd_opts(int server_fd, const struct network_helper_opts *opts)
> > }
> >
> > addr_in = (struct sockaddr_in *)&addr;
> > - fd = socket(addr_in->sin_family, type, 0);
> > + fd = socket(addr_in->sin_family, type, opts->protocol);
> ops->protocol is the same as the server_fd's protocol ?
>
> Can that be learned from getsockopt(server_fd, SOL_SOCKET, SO_PROTOCOL, ....) ?
> Then the ops->protocol additions and related changes are not needed.
Yes, I will update this in v5.
>
> connect_to_fd_opts() has already obtained the SO_TYPE in similar way.
>
> > if (fd < 0) {
> > log_err("Failed to create client socket");
> > return -1;
> > @@ -298,6 +315,16 @@ int connect_to_fd(int server_fd, int timeout_ms)
> > return connect_to_fd_opts(server_fd, &opts);
> > }
> >
> > +int connect_to_mptcp_fd(int server_fd, int timeout_ms)
> > +{
> > + struct network_helper_opts opts = {
> > + .timeout_ms = timeout_ms,
> > + .protocol = IPPROTO_MPTCP,
> > + };
> > +
> > + return connect_to_fd_opts(server_fd, &opts);
> > +}
> > +
> > int connect_fd_to_fd(int client_fd, int server_fd, int timeout_ms)
> > {
> > struct sockaddr_storage addr;
> > diff --git a/tools/testing/selftests/bpf/network_helpers.h b/tools/testing/selftests/bpf/network_helpers.h
> > index a4b3b2f9877b..e0feb115b2ae 100644
> > --- a/tools/testing/selftests/bpf/network_helpers.h
> > +++ b/tools/testing/selftests/bpf/network_helpers.h
> > @@ -21,6 +21,7 @@ struct network_helper_opts {
> > const char *cc;
> > int timeout_ms;
> > bool must_fail;
> > + int protocol;
> > };
> >
> > /* ipv4 test vector */
> > @@ -42,11 +43,14 @@ extern struct ipv6_packet pkt_v6;
> > int settimeo(int fd, int timeout_ms);
> > int start_server(int family, int type, const char *addr, __u16 port,
> > int timeout_ms);
> > +int start_mptcp_server(int family, const char *addr, __u16 port,
> > + int timeout_ms);
> > int *start_reuseport_server(int family, int type, const char *addr_str,
> > __u16 port, int timeout_ms,
> > unsigned int nr_listens);
> > void free_fds(int *fds, unsigned int nr_close_fds);
> > int connect_to_fd(int server_fd, int timeout_ms);
> > +int connect_to_mptcp_fd(int server_fd, int timeout_ms);
> > int connect_to_fd_opts(int server_fd, const struct network_helper_opts *opts);
> > int connect_fd_to_fd(int client_fd, int server_fd, int timeout_ms);
> > int fastopen_connect(int server_fd, const char *data, unsigned int data_len,
>
^ permalink raw reply
* Re: [PATCH 2/2] octeon_ep: Fix irq releasing in the error handling path of octep_request_irqs()
From: Dan Carpenter @ 2022-05-17 5:28 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Veerasenareddy Burru, Abhijit Ayarekar, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Satananda Burla,
linux-kernel, kernel-janitors, netdev
In-Reply-To: <a1b6f082fff4e68007914577961113bc452c8030.1652629833.git.christophe.jaillet@wanadoo.fr>
On Sun, May 15, 2022 at 05:56:45PM +0200, Christophe JAILLET wrote:
> For the error handling to work as expected, the index in the
> 'oct->msix_entries' array must be tweaked because, when the irq are
> requested there is:
> msix_entry = &oct->msix_entries[i + num_non_ioq_msix];
>
> So in the error handling path, 'i + num_non_ioq_msix' should be used
> instead of 'i'.
>
> The 2nd argument of free_irq() also needs to be adjusted.
>
> Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> I think that the wording above is awful, but I'm sure you get it.
> Feel free to rephrase everything to have it more readable.
> ---
> drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> index 6b60a03574a0..4dcae805422b 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> @@ -257,10 +257,12 @@ static int octep_request_irqs(struct octep_device *oct)
>
> return 0;
> ioq_irq_err:
> + i += num_non_ioq_msix;
> while (i > num_non_ioq_msix) {
This makes my mind hurt so badly. Can we not just have two variables
for the two different loops instead of re-using i?
> --i;
> irq_set_affinity_hint(oct->msix_entries[i].vector, NULL);
> - free_irq(oct->msix_entries[i].vector, oct->ioq_vector[i]);
> + free_irq(oct->msix_entries[i].vector,
> + oct->ioq_vector[i - num_non_ioq_msix]);
> }
ioq_irq_err:
while (--j >= 0) {
ioq_vector = oct->ioq_vector[j];
msix_entry = &oct->msix_entries[j + num_non_ioq_msix];
irq_set_affinity_hint(msix_entry->vector, NULL);
free_irq(msix_entry->vector, ioq_vector);
}
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH bpf-next v4 4/7] selftests/bpf: test bpf_skc_to_mptcp_sock
From: Geliang Tang @ 2022-05-17 5:29 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Geliang Tang, Mat Martineau, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, MPTCP Upstream, Matthieu Baerts
In-Reply-To: <20220517012055.loesbaunau2bxbt5@kafai-mbp.dhcp.thefacebook.com>
Martin KaFai Lau <kafai@fb.com> 于2022年5月17日周二 09:21写道：
>
> On Fri, May 13, 2022 at 03:48:24PM -0700, Mat Martineau wrote:
> [ ... ]
> > diff --git a/tools/testing/selftests/bpf/progs/mptcp_sock.c b/tools/testing/selftests/bpf/progs/mptcp_sock.c
> > index bc09dba0b078..3feb7ff578e2 100644
> > --- a/tools/testing/selftests/bpf/progs/mptcp_sock.c
> > +++ b/tools/testing/selftests/bpf/progs/mptcp_sock.c
> > @@ -7,6 +7,7 @@
> > #include "bpf_tcp_helpers.h"
> >
> > char _license[] SEC("license") = "GPL";
> > +extern bool CONFIG_MPTCP __kconfig;
> >
> > struct mptcp_storage {
> > __u32 invoked;
> > @@ -24,6 +25,7 @@ SEC("sockops")
> > int _sockops(struct bpf_sock_ops *ctx)
> > {
> > struct mptcp_storage *storage;
> > + struct mptcp_sock *msk;
> > int op = (int)ctx->op;
> > struct tcp_sock *tsk;
> > struct bpf_sock *sk;
> > @@ -41,11 +43,24 @@ int _sockops(struct bpf_sock_ops *ctx)
> > return 1;
> >
> > is_mptcp = bpf_core_field_exists(tsk->is_mptcp) ? tsk->is_mptcp : 0;
> > - storage = bpf_sk_storage_get(&socket_storage_map, sk, 0,
> > - BPF_SK_STORAGE_GET_F_CREATE);
> > - if (!storage)
> > - return 1;
> > + if (!is_mptcp) {
> > + storage = bpf_sk_storage_get(&socket_storage_map, sk, 0,
> > + BPF_SK_STORAGE_GET_F_CREATE);
> > + if (!storage)
> > + return 1;
> > + } else {
> > + if (!CONFIG_MPTCP)
> hmm... how is it possible ? The above just tested "!is_mptcp".
Will drop this in v5, thanks.
>
> > + return 1;
> > +
> > + msk = bpf_skc_to_mptcp_sock(sk);
> > + if (!msk)
> > + return 1;
> >
> > + storage = bpf_sk_storage_get(&socket_storage_map, msk, 0,
> > + BPF_SK_STORAGE_GET_F_CREATE);
> > + if (!storage)
> > + return 1;
> > + }
> > storage->invoked++;
> > storage->is_mptcp = is_mptcp;
> >
> > --
> > 2.36.1
> >
>
^ permalink raw reply
* Re: [PATCH bpf-next v4 3/7] selftests/bpf: add MPTCP test base
From: Geliang Tang @ 2022-05-17 5:30 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Mat Martineau, Networking, bpf, Nicolas Rybowski,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
MPTCP Upstream, Matthieu Baerts, Geliang Tang
In-Reply-To: <CAEf4Bzbn8DSwxt7WdWhNmfAP_NU8gmnJmFzSzO2kt=ZNSt1gUQ@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> 于2022年5月17日周二 06:43写道：
>
> On Fri, May 13, 2022 at 3:48 PM Mat Martineau
> <mathew.j.martineau@linux.intel.com> wrote:
> >
> > From: Nicolas Rybowski <nicolas.rybowski@tessares.net>
> >
> > This patch adds a base for MPTCP specific tests.
> >
> > It is currently limited to the is_mptcp field in case of plain TCP
> > connection because there is no easy way to get the subflow sk from a msk
> > in userspace. This implies that we cannot lookup the sk_storage attached
> > to the subflow sk in the sockops program.
> >
> > v4:
> > - add copyright 2022 (Andrii)
> > - use ASSERT_* instead of CHECK_FAIL (Andrii)
> > - drop SEC("version") (Andrii)
> > - use is_mptcp in tcp_sock, instead of bpf_tcp_sock (Martin & Andrii)
> >
> > Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> > Co-developed-by: Geliang Tang <geliang.tang@suse.com>
> > Signed-off-by: Geliang Tang <geliang.tang@suse.com>
> > Signed-off-by: Nicolas Rybowski <nicolas.rybowski@tessares.net>
> > Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> > ---
> > MAINTAINERS | 1 +
> > tools/testing/selftests/bpf/bpf_tcp_helpers.h | 1 +
> > tools/testing/selftests/bpf/config | 1 +
> > tools/testing/selftests/bpf/network_helpers.c | 43 ++++--
> > tools/testing/selftests/bpf/network_helpers.h | 4 +
> > .../testing/selftests/bpf/prog_tests/mptcp.c | 136 ++++++++++++++++++
> > .../testing/selftests/bpf/progs/mptcp_sock.c | 53 +++++++
> > 7 files changed, 231 insertions(+), 8 deletions(-)
> > create mode 100644 tools/testing/selftests/bpf/prog_tests/mptcp.c
> > create mode 100644 tools/testing/selftests/bpf/progs/mptcp_sock.c
> >
>
> Seems like bpf_core_field_exists() works fine for your use case and CI
> is green. See some selftest-specific issues below, though.
>
> [...]
>
> > +static int run_test(int cgroup_fd, int server_fd, bool is_mptcp)
> > +{
> > + int client_fd, prog_fd, map_fd, err;
> > + struct bpf_program *prog;
> > + struct bpf_object *obj;
> > + struct bpf_map *map;
> > +
> > + obj = bpf_object__open("./mptcp_sock.o");
> > + if (libbpf_get_error(obj))
> > + return -EIO;
> > +
> > + err = bpf_object__load(obj);
> > + if (!ASSERT_OK(err, "bpf_object__load"))
> > + goto out;
> > +
> > + prog = bpf_object__find_program_by_name(obj, "_sockops");
>
> can you please use BPF skeleton instead of doing these lookups by
> name? See other tests that are including .skel.h headers for example
Sure, I will update this in v5.
>
> > + if (!ASSERT_OK_PTR(prog, "bpf_object__find_program_by_name")) {
> > + err = -EIO;
> > + goto out;
> > + }
> > +
>
> [...]
>
> > +void test_base(void)
> > +{
> > + int server_fd, cgroup_fd;
> > +
> > + cgroup_fd = test__join_cgroup("/mptcp");
> > + if (CHECK_FAIL(cgroup_fd < 0))
> > + return;
> > +
> > + /* without MPTCP */
> > + server_fd = start_server(AF_INET, SOCK_STREAM, NULL, 0, 0);
> > + if (CHECK_FAIL(server_fd < 0))
> > + goto with_mptcp;
> > +
> > + CHECK_FAIL(run_test(cgroup_fd, server_fd, false));
>
> please don't add new uses of CHECK_FAIL()
>
> > +
> > + close(server_fd);
> > +
>
> [...]
>
^ permalink raw reply
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
From: Marc Kleine-Budde @ 2022-05-17 6:08 UTC (permalink / raw)
To: Vincent MAILHOL
Cc: Oliver Hartkopp, linux-can, linux-kernel, Max Staudt, netdev
In-Reply-To: <CAMZ6RqKZMHXB7rQ70GrXcVE7x7kytAAGfE+MOpSgWgWgp0gD2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
On 17.05.2022 10:50:16, Vincent MAILHOL wrote:
> > would it probably make sense to
> > introduce a new can-skb module that could be used by all CAN
> > virtual/software interfaces?
> >
> > Or some other split-up ... any idea?
>
> My concern is: what would be the merrit? If we do not split, the users
> of slcan and v(x)can would have to load the can-dev module which will
> be slightly bloated for their use, but is this really an issue?
If you use modprobe all required modules are loaded automatically.
> I do
> not see how this can become a performance bottleneck, so what is the
> problem?
> I could also argue that most of the devices do not depend on
> rx-offload.o. So should we also split this one out of can-dev on the
> same basis and add another module dependency?
We can add a non user visible Kconfig symbol for rx-offload and let the
drivers that need it do a "select" on it. If selected the rx-offload
would be compiled into to can-dev module.
> The benefit (not having to load a bloated module for three drivers)
> does not outweigh the added complexity: all hardware modules will have
> one additional modprobe dependency on the tiny can-skb module.
>
> But as said above, I am not fully opposed to the split, I am just
> strongly divided. If we go for the split, creating a can-skb module is
> the natural and only option I see.
> If the above argument does not convince you, I will send a v3 with that split.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net 0/2] selftests: net: add missing tests to Makefile
From: Hangbin Liu @ 2022-05-17 6:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, David S. Miller, Paolo Abeni, Shuah Khan, linux-kselftest
In-Reply-To: <20220429175604.249bb2fb@kernel.org>
On Fri, Apr 29, 2022 at 05:56:04PM -0700, Jakub Kicinski wrote:
> On Thu, 28 Apr 2022 12:45:09 +0800 Hangbin Liu wrote:
> > I think there need a way to notify the developer when they created a new
> > file in selftests folder. Maybe a bot like bluez.test.bot or kernel
> > test robot could help do that?
>
> Our netdev patch checks are here:
>
> https://github.com/kuba-moo/nipa/tree/master/tests/patch
>
> in case you're willing to code it up and post a PR.
Hi Jakub,
I checked the tools and write a draft patch. But I have a question before post
the PR. AFAIK, This bot is only used for checking patches and adding status in
patchwork. But it doesn't support sending a reply to developer, right?
For the selftest reminder, I think it would be good to let developer know
via email if the file is missing in Makefile. What do you think?
Here is the draft patch:
diff --git a/tests/patch/check_selftest/check_selftest.sh b/tests/patch/check_selftest/check_selftest.sh
new file mode 100755
index 0000000..ad7c608
--- /dev/null
+++ b/tests/patch/check_selftest/check_selftest.sh
@@ -0,0 +1,28 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+rt=0
+if ! git show --name-status --oneline | \
+ grep -P '^A\ttools/testing/selftests/net/' | \
+ grep '\.sh$'; then
+ echo "No new net selftests script" >&$DESC_FD
+ exit 0
+fi
+
+files=$(git show --name-status --oneline | grep -P '^A\ttools/testing/selftests/net/' | grep '\.sh$' | sed 's@A\ttools/testing/selftests/net/@@')
+for file in $files; do
+ if echo $file | grep forwarding; then
+ file=$(echo $file | sed 's/forwarding\///')
+ if ! grep -P "[\t| ]$file" tools/testing/selftests/net/forwarding/Makefile;then
+ echo "new test $file not in selftests/net/forwarding/Makefile" >&$DESC_FD
+ rc=1
+ fi
+ else
+ if ! grep -P "[\t| ]$file" tools/testing/selftests/net/Makefile;then
+ echo "new test $file not in selftests/net/Makefile" >&$DESC_FD
+ rc=1
+ fi
+ fi
+done
+
+exit $rc
diff --git a/tests/patch/check_selftest/info.json b/tests/patch/check_selftest/info.json
new file mode 100644
index 0000000..615779f
--- /dev/null
+++ b/tests/patch/check_selftest/info.json
@@ -0,0 +1,3 @@
+{
+ "run": ["check_selftest.sh"]
+}
--
2.35.1
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH] igb: skip phy status check where unavailable
From: G, GurucharanX @ 2022-05-17 6:23 UTC (permalink / raw)
To: Kevin Mitchell
Cc: intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org,
Takuma Ueba, Jeff Kirsher, netdev@vger.kernel.org, Jakub Kicinski,
Paolo Abeni, David S. Miller
In-Reply-To: <20220429235554.13290-1-kevmitch@arista.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Kevin Mitchell
> Sent: Saturday, April 30, 2022 5:26 AM
> Cc: kevmitch@arista.com; intel-wired-lan@lists.osuosl.org; linux-
> kernel@vger.kernel.org; Takuma Ueba <t.ueba11@gmail.com>; Jeff Kirsher
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; Jakub Kicinski
> <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller
> <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH] igb: skip phy status check where
> unavailable
>
> igb_read_phy_reg() will silently return, leaving phy_data untouched, if
> hw->ops.read_reg isn't set. Depending on the uninitialized value of
> phy_data, this led to the phy status check either succeeding immediately or
> looping continuously for 2 seconds before emitting a noisy err-level timeout.
> This message went out to the console even though there was no actual
> problem.
>
> Instead, first check if there is read_reg function pointer. If not, proceed
> without trying to check the phy status register.
>
> Fixes: b72f3f72005d ("igb: When GbE link up, wait for Remote receiver status
> condition")
> Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net v2] NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
From: Krzysztof Kozlowski @ 2022-05-17 6:25 UTC (permalink / raw)
To: Duoming Zhou, linux-kernel, kuba
Cc: davem, edumazet, pabeni, gregkh, alexander.deucher, broonie,
netdev
In-Reply-To: <20220517012530.75714-1-duoming@zju.edu.cn>
On 17/05/2022 03:25, Duoming Zhou wrote:
> There are sleep in atomic context bugs when the request to secure
> element of st-nci is timeout. The root cause is that nci_skb_alloc
> with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is
> a timer handler. The call paths that could trigger bugs are shown below:
>
> (interrupt context 1)
> st_nci_se_wt_timeout
> nci_hci_send_event
> nci_hci_send_data
> nci_skb_alloc(..., GFP_KERNEL) //may sleep
>
> (interrupt context 2)
> st_nci_se_wt_timeout
> nci_hci_send_event
> nci_hci_send_data
> nci_send_data
> nci_queue_tx_data_frags
> nci_skb_alloc(..., GFP_KERNEL) //may sleep
>
> This patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to
> GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC
> flag makes memory allocation operation could be used in atomic context.
>
> Fixes: ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in v2:
> - Change the Fixes tag to commit st_nci_se_wt_timeout was added.
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
https://elixir.bootlin.com/linux/v5.13/source/Documentation/process/submitting-patches.rst#L543
If a tag was not added on purpose, please state why and what changed.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] mediatek/mt76: cleanup the code a bit
From: Bernard Zhao @ 2022-05-17 6:29 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Kalle Valo, David S. Miller, Jakub Kicinski,
Paolo Abeni, Matthias Brugger, Bernard Zhao, linux-wireless,
netdev, linux-arm-kernel, linux-mediatek, linux-kernel
Cc: zhaojunkui2008
Function mt76_register_debugfs just call mt76_register_debugfs_fops
with NULL op parameter.
This change is to cleanup the code a bit, elete the meaningless
mt76_register_debugfs, and all call mt76_register_debugfs_fops.
Signed-off-by: Bernard Zhao <bernard@vivo.com>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ----
drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c | 3 ++-
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 882fb5d2517f..7967ac210c9b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -927,10 +927,6 @@ int mt76_register_phy(struct mt76_phy *phy, bool vht,
struct dentry *mt76_register_debugfs_fops(struct mt76_phy *phy,
const struct file_operations *ops);
-static inline struct dentry *mt76_register_debugfs(struct mt76_dev *dev)
-{
- return mt76_register_debugfs_fops(&dev->phy, NULL);
-}
int mt76_queues_read(struct seq_file *s, void *data);
void mt76_seq_puts_array(struct seq_file *file, const char *str,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
index f52165dff422..6bfe28c82f4e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
@@ -96,8 +96,9 @@ DEFINE_SHOW_ATTRIBUTE(mt7603_ampdu_stat);
void mt7603_init_debugfs(struct mt7603_dev *dev)
{
struct dentry *dir;
+ struct mt76_dev *pdev = &dev->mt76;
- dir = mt76_register_debugfs(&dev->mt76);
+ dir = mt76_register_debugfs_fops(&pdev->phy, NULL);
if (!dir)
return;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
index c4fe1c436aaa..346501d7d622 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
@@ -117,8 +117,9 @@ DEFINE_DEBUGFS_ATTRIBUTE(fops_edcca, mt76_edcca_get, mt76_edcca_set,
void mt76x02_init_debugfs(struct mt76x02_dev *dev)
{
struct dentry *dir;
+ struct mt76_dev *pdev = &dev->mt76;
- dir = mt76_register_debugfs(&dev->mt76);
+ dir = mt76_register_debugfs_fops(&pdev->phy, NULL);
if (!dir)
return;
--
2.33.1
^ permalink raw reply related
* RE: [EXT] Re: [BUG] Layerscape CAAM+kTLS+io_uring
From: Gaurav Jain @ 2022-05-17 6:30 UTC (permalink / raw)
To: Steffen Trumtrar, Jakub Kicinski
Cc: Marc Kleine-Budde, linux-crypto@vger.kernel.org,
io-uring@vger.kernel.org, kernel@pengutronix.de, Horia Geanta,
Pankaj Gupta, Jens Axboe, Pavel Begunkov, Boris Pismenny,
John Fastabend, Daniel Borkmann, netdev@vger.kernel.org
In-Reply-To: <87sfp9vlig.fsf@pengutronix.de>
Hello Steffen
> -----Original Message-----
> From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Sent: Monday, May 16, 2022 3:36 PM
> To: Jakub Kicinski <kuba@kernel.org>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>; linux-crypto@vger.kernel.org;
> io-uring@vger.kernel.org; kernel@pengutronix.de; Horia Geanta
> <horia.geanta@nxp.com>; Pankaj Gupta <pankaj.gupta@nxp.com>; Gaurav Jain
> <gaurav.jain@nxp.com>; Jens Axboe <axboe@kernel.dk>; Pavel Begunkov
> <asml.silence@gmail.com>; Boris Pismenny <borisp@nvidia.com>; John
> Fastabend <john.fastabend@gmail.com>; Daniel Borkmann
> <daniel@iogearbox.net>; netdev@vger.kernel.org
> Subject: [EXT] Re: [BUG] Layerscape CAAM+kTLS+io_uring
>
> Caution: EXT Email
>
> Jakub Kicinski <kuba@kernel.org> writes:
>
> > On Thu, 5 May 2022 21:20:46 +0200 Marc Kleine-Budde wrote:
> >> Hello,
> >>
> >> no one seems to care about this problem. :/
> >>
> >> Maybe too many components are involved, I'm the respective
> >> maintainers on Cc.
> >>
> >> Cc += the CAAM maintainers
> >> Cc += the io_uring maintainers
> >> Cc += the kTLS maintainers
> >>
> >> On 27.04.2022 10:20:40, Steffen Trumtrar wrote:
> >> > Hi all,
> >> >
> >> > I have a Layerscape-1046a based board where I'm trying to use a
> >> > combination of liburing (v2.0) with splice, kTLS and CAAM (kernel
> >> > v5.17). The problem I see is that on shutdown the last bytes are
> >> > missing. It looks like io_uring is not waiting for all completions
> >> > from the CAAM driver.
> >> >
> >> > With ARM-ASM instead of the CAAM, the setup works fine.
> >>
> >> What's the difference between the CAAM and ARM-ASM crypto? Without
> >> looking into the code I think the CAAM is asynchron while ARM-ASM is
> >> synchron. Is this worth investigating?
> >
> > Sounds like
> > 20ffc7adf53a ("net/tls: missing received data after fast remote
> > close")
>
> That fixes something in tls_sw. I have a kernel that includes this patch. So this
> sounds right, but can't be it, right?
>
To understand more on problem, can you share how you are offloading ktls to CAAM?
Gaurav
>
> Best regards,
> Steffen
>
> --
> Pengutronix e.K. | Dipl.-Inform. Steffen Trumtrar |
> Steuerwalder Str. 21 |
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pe
> ngutronix.de%2F&data=05%7C01%7Cgaurav.jain%40nxp.com%7Cc225fa4
> 3da7f4a43f16b08da3723dc4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C637882924400875890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=fI1BHNZIT5RlpjEdEMXVkv1WaHcvgTlZOcaC0LRojac%3D&
> reserved=0 |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686| Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH net-next v2] net: wwan: t7xx: fix GFP_KERNEL usage in spin_lock context
From: Ziyang Xuan @ 2022-05-17 6:48 UTC (permalink / raw)
To: chandrashekar.devegowda, linuxwwan, chiranjeevi.rapolu,
haijun.liu, m.chetan.kumar, ricardo.martinez, loic.poulain,
ryazanov.s.a, johannes, davem, edumazet, kuba, pabeni, netdev
t7xx_cldma_clear_rxq() call t7xx_cldma_alloc_and_map_skb() in spin_lock
context, But __dev_alloc_skb() in t7xx_cldma_alloc_and_map_skb() uses
GFP_KERNEL, that will introduce scheduling factor in spin_lock context.
Because t7xx_cldma_clear_rxq() is called after stopping CLDMA, so we can
remove the spin_lock from t7xx_cldma_clear_rxq().
Fixes: 39d439047f1d ("net: wwan: t7xx: Add control DMA interface")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
---
drivers/net/wwan/t7xx/t7xx_hif_cldma.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wwan/t7xx/t7xx_hif_cldma.c b/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
index 46066dcd2607..7493285a9606 100644
--- a/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
+++ b/drivers/net/wwan/t7xx/t7xx_hif_cldma.c
@@ -782,10 +782,12 @@ static int t7xx_cldma_clear_rxq(struct cldma_ctrl *md_ctrl, int qnum)
struct cldma_queue *rxq = &md_ctrl->rxq[qnum];
struct cldma_request *req;
struct cldma_gpd *gpd;
- unsigned long flags;
int ret = 0;
- spin_lock_irqsave(&rxq->ring_lock, flags);
+ /* CLDMA has been stopped. There is not any CLDMA IRQ, holding
+ * ring_lock is not needed. Thus we can use functions that may
+ * introduce scheduling.
+ */
t7xx_cldma_q_reset(rxq);
list_for_each_entry(req, &rxq->tr_ring->gpd_ring, entry) {
gpd = req->gpd;
@@ -808,7 +810,6 @@ static int t7xx_cldma_clear_rxq(struct cldma_ctrl *md_ctrl, int qnum)
t7xx_cldma_gpd_set_data_ptr(req->gpd, req->mapped_buff);
}
- spin_unlock_irqrestore(&rxq->ring_lock, flags);
return ret;
}
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH v2 0/5] TUN/VirtioNet USO features support.
From: Jason Wang @ 2022-05-17 6:32 UTC (permalink / raw)
To: Andrew Melnychenko
Cc: davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni, mst, netdev,
linux-kernel, virtualization, Yan Vugenfirer, Yuri Benditovich
In-Reply-To: <20220512112347.18717-1-andrew@daynix.com>
On Thu, May 12, 2022 at 7:33 PM Andrew Melnychenko <andrew@daynix.com> wrote:
>
> Added new offloads for TUN devices TUN_F_USO4 and TUN_F_USO6.
> Technically they enable NETIF_F_GSO_UDP_L4
> (and only if USO4 & USO6 are set simultaneously).
> It allows to transmission of large UDP packets.
>
> Different features USO4 and USO6 are required for qemu where Windows guests can
> enable disable USO receives for IPv4 and IPv6 separately.
> On the other side, Linux can't really differentiate USO4 and USO6, for now.
> For now, to enable USO for TUN it requires enabling USO4 and USO6 together.
> In the future, there would be a mechanism to control UDP_L4 GSO separately.
>
> Test it WIP Qemu https://github.com/daynix/qemu/tree/Dev_USOv2
>
> New types for VirtioNet already on mailing:
> https://lists.oasis-open.org/archives/virtio-comment/202110/msg00010.html
>
> Also, there is a known issue with transmitting packages between two guests.
Could you explain this more? It looks like a bug. (Or any pointer to
the discussion)
Thanks
> Without hacks with skb's GSO - packages are still segmented on the host's postrouting.
>
> Andrew (5):
> uapi/linux/if_tun.h: Added new offload types for USO4/6.
> driver/net/tun: Added features for USO.
> uapi/linux/virtio_net.h: Added USO types.
> linux/virtio_net.h: Support USO offload in vnet header.
> drivers/net/virtio_net.c: Added USO support.
>
> drivers/net/tap.c | 10 ++++++++--
> drivers/net/tun.c | 8 +++++++-
> drivers/net/virtio_net.c | 19 +++++++++++++++----
> include/linux/virtio_net.h | 9 +++++++++
> include/uapi/linux/if_tun.h | 2 ++
> include/uapi/linux/virtio_net.h | 4 ++++
> 6 files changed, 45 insertions(+), 7 deletions(-)
>
> --
> 2.35.1
>
^ permalink raw reply
* Re: [PATCH net v2] NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
From: duoming @ 2022-05-17 6:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, kuba, davem, edumazet, pabeni, gregkh,
alexander.deucher, broonie, netdev
In-Reply-To: <4889a6cd-ef96-595e-a117-2965aab97a54@linaro.org>
Hello,
On Tue, 17 May 2022 08:25:04 +0200 Krzysztof wrote:
> On 17/05/2022 03:25, Duoming Zhou wrote:
> > There are sleep in atomic context bugs when the request to secure
> > element of st-nci is timeout. The root cause is that nci_skb_alloc
> > with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is
> > a timer handler. The call paths that could trigger bugs are shown below:
> >
> > (interrupt context 1)
> > st_nci_se_wt_timeout
> > nci_hci_send_event
> > nci_hci_send_data
> > nci_skb_alloc(..., GFP_KERNEL) //may sleep
> >
> > (interrupt context 2)
> > st_nci_se_wt_timeout
> > nci_hci_send_event
> > nci_hci_send_data
> > nci_send_data
> > nci_queue_tx_data_frags
> > nci_skb_alloc(..., GFP_KERNEL) //may sleep
> >
> > This patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to
> > GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC
> > flag makes memory allocation operation could be used in atomic context.
> >
> > Fixes: ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci")
> > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> > ---
> > Changes in v2:
> > - Change the Fixes tag to commit st_nci_se_wt_timeout was added.
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> https://elixir.bootlin.com/linux/v5.13/source/Documentation/process/submitting-patches.rst#L543
>
> If a tag was not added on purpose, please state why and what changed.
Thank you very much, I will read the documentation carefully.
I'm sorry, I forgot the Reviewed-by tag.
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Duoming Zhou
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: add out-of-band tagging protocol
From: Maxime Chevallier @ 2022-05-17 6:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, Rob Herring, netdev, linux-kernel, devicetree,
thomas.petazzoni, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Vladimir Oltean, Luka Perkov,
Robert Marko
In-Reply-To: <20220516122048.70e238a2@kernel.org>
Hello Jakub,
On Mon, 16 May 2022 12:20:48 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Sat, 14 May 2022 17:06:53 +0200 Maxime Chevallier wrote:
> > This tagging protocol is designed for the situation where the link
> > between the MAC and the Switch is designed such that the Destination
> > Port, which is usually embedded in some part of the Ethernet
> > Header, is sent out-of-band, and isn't present at all in the
> > Ethernet frame.
> >
> > This can happen when the MAC and Switch are tightly integrated on an
> > SoC, as is the case with the Qualcomm IPQ4019 for example, where
> > the DSA tag is inserted directly into the DMA descriptors. In that
> > case, the MAC driver is responsible for sending the tag to the
> > switch using the out-of-band medium. To do so, the MAC driver needs
> > to have the information of the destination port for that skb.
> >
> > This out-of-band tagging protocol is using the very beggining of
> > the skb headroom to store the tag. The drawback of this approch is
> > that the headroom isn't initialized upon allocating it, therefore
> > we have a chance that the garbage data that lies there at
> > allocation time actually ressembles a valid oob tag. This is only
> > problematic if we are sending/receiving traffic on the master port,
> > which isn't a valid DSA use-case from the beggining. When dealing
> > from traffic to/from a slave port, then the oob tag will be
> > initialized properly by the tagger or the mac driver through the
> > use of the dsa_oob_tag_push() call.
> >
> > Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>
> This must had been asked on v1 but there's no trace of it in the
> current submission afaict...
No you're correct, this wasn't explained.
> If the tag is passed in the descriptor how is this not a pure
> switchdev driver? The explanation must be preserved somehow.
The main reason is that although the MAC and switch are rightly coupled
on that platform, the switch is actually a QC8K that can live on it's
own, as an external switch. Here, it's just a slightly modified version
of this IP.
The same goes for the MAC IP, but so far we don't support any other
platform that have the MAC as a standalone controller. As far as we can
tell, platforms that have this MAC also include a QCA8K, but the
datasheet also mentions other modes (like outputing RGMII).
Is this valid to have it as a standalone ethernet driver in that
situation ?
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 1/3] selftests: mptcp: fix a mp_fail test warning
From: Matthieu Baerts @ 2022-05-17 7:01 UTC (permalink / raw)
To: Jakub Kicinski, Mat Martineau
Cc: netdev, Geliang Tang, davem, pabeni, edumazet, mptcp
In-Reply-To: <20220516131346.1f1f95d9@kernel.org>
Hi Jakub,
Thank you for the review and for having applied the patches!
On 16/05/2022 22:13, Jakub Kicinski wrote:
> On Fri, 13 May 2022 17:21:13 -0700 Mat Martineau wrote:
>> tc -n $ns2 -j -s action show action pedit index 100 | \
>> + grep "packets" | \
>> sed 's/.*"packets":\([0-9]\+\),.*/\1/'
>
> sed can do the grepping for you:
>
> sed -n 's/.*"packets":\([0-9]\+\),.*/\1/p'
Yes, thank you, that would have been shorter!
> But really grepping JSON output seems weird. Why not use jq?
We started to use 'jq' because we originally had to extract a few values
from this command. At the end, we only needed to extract the number of
packets and we didn't want all MPTCP tests to depend on 'jq' just for that.
But because 'jq' is already needed for a few other selftests, next time
we need to parse a JSON, we should use 'jq'!
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
^ permalink raw reply
* Re: [PATCH bpf v2 1/4] bpf_trace: check size for overflow in bpf_kprobe_multi_link_attach
From: Yonghong Song @ 2022-05-17 7:01 UTC (permalink / raw)
To: Eugene Syromiatnikov, Jiri Olsa, Masami Hiramatsu, Steven Rostedt,
Ingo Molnar, Alexei Starovoitov, Daniel Borkmann
Cc: Andrii Nakryiko, Martin KaFai Lau, Song Liu, John Fastabend,
KP Singh, netdev, bpf, linux-kernel, Shuah Khan, linux-kselftest
In-Reply-To: <20220516230455.GA25103@asgard.redhat.com>
On 5/16/22 4:04 PM, Eugene Syromiatnikov wrote:
> Check that size would not overflow before calculation (and return
> -EOVERFLOW if it will), to prevent potential out-of-bounds write
> with the following copy_from_user. Add the same check
> to kprobe_multi_resolve_syms in case it will be called from elsewhere
> in the future.
>
> Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link")
> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
> ---
> kernel/trace/bpf_trace.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index d8553f4..f1d4e68 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -2352,12 +2352,15 @@ static int
> kprobe_multi_resolve_syms(const void __user *usyms, u32 cnt,
> unsigned long *addrs)
> {
> - unsigned long addr, size;
> + unsigned long addr, sym_size;
> + u32 size;
> const char __user **syms;
> int err = -ENOMEM;
> unsigned int i;
> char *func;
>
> + if (check_mul_overflow(cnt, (u32)sizeof(*syms), &size))
> + return -EOVERFLOW;
> size = cnt * sizeof(*syms);
The statement 'size = cnt * sizeof(*syms)' can be removed right?
Here, the 'size' will be computed properly with check_mul_overflow()
if 0 is returned.
> syms = kvzalloc(size, GFP_KERNEL);
> if (!syms)
> @@ -2382,9 +2385,9 @@ kprobe_multi_resolve_syms(const void __user *usyms, u32 cnt,
> addr = kallsyms_lookup_name(func);
> if (!addr)
> goto error;
> - if (!kallsyms_lookup_size_offset(addr, &size, NULL))
> + if (!kallsyms_lookup_size_offset(addr, &sym_size, NULL))
> goto error;
> - addr = ftrace_location_range(addr, addr + size - 1);
> + addr = ftrace_location_range(addr, addr + sym_size - 1);
> if (!addr)
> goto error;
> addrs[i] = addr;
> @@ -2429,6 +2432,8 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> if (!cnt)
> return -EINVAL;
>
> + if (check_mul_overflow(cnt, (u32)sizeof(*addrs), &size))
> + return -EOVERFLOW;
> size = cnt * sizeof(*addrs);
Same here, 'size = ...' is not needed.
> addrs = kvmalloc(size, GFP_KERNEL);
> if (!addrs)
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: add out-of-band tagging protocol
From: Maxime Chevallier @ 2022-05-17 7:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: davem@davemloft.net, Rob Herring, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
thomas.petazzoni@bootlin.com, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, Russell King,
linux-arm-kernel@lists.infradead.org, Luka Perkov, Robert Marko
In-Reply-To: <20220514224002.vvmd43lnjkbsw2g3@skbuf>
Hi Vlad,
On Sat, 14 May 2022 22:40:03 +0000
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> On Sat, May 14, 2022 at 05:06:53PM +0200, Maxime Chevallier wrote:
> > This tagging protocol is designed for the situation where the link
> > between the MAC and the Switch is designed such that the Destination
> > Port, which is usually embedded in some part of the Ethernet
> > Header, is sent out-of-band, and isn't present at all in the
> > Ethernet frame.
> >
> > This can happen when the MAC and Switch are tightly integrated on an
> > SoC, as is the case with the Qualcomm IPQ4019 for example, where
> > the DSA tag is inserted directly into the DMA descriptors. In that
> > case, the MAC driver is responsible for sending the tag to the
> > switch using the out-of-band medium. To do so, the MAC driver needs
> > to have the information of the destination port for that skb.
> >
> > This out-of-band tagging protocol is using the very beggining of
> > the skb headroom to store the tag. The drawback of this approch is
> > that the headroom isn't initialized upon allocating it, therefore
> > we have a chance that the garbage data that lies there at
> > allocation time actually ressembles a valid oob tag. This is only
> > problematic if we are sending/receiving traffic on the master port,
> > which isn't a valid DSA use-case from the beggining. When dealing
> > from traffic to/from a slave port, then the oob tag will be
> > initialized properly by the tagger or the mac driver through the
> > use of the dsa_oob_tag_push() call.
> >
> > Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> > ---
>
> Why put the DSA pseudo-header at skb->head rather than push it using
> skb_push()? I thought you were going to check for the presence of a
> DSA header using something like skb->mac_len == ETH_HLEN + tag len,
> but right now it sounds like treating garbage in the headroom as a
> valid DSA tag is indeed a potential problem. If you can't sort that
> out using information from the header offsets alone, maybe an skb
> extension is required?
Indeed, I thought of that, the main reason is that pushing/poping in
itself is not enough, you also have to move the whole mac_header to
leave room for the tag, and then re-set it in it's original location.
There's nothing wrong with this, but it looked a bit cumbersome just to
insert a dummy tag that gets removed rightaway. Does that make sense ?
But yes I would really like to get a way to know wether the tag is
there or not, I'll dig a bit more to see if I can find a way to get
this info from the various skb offsets in a reliable way.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
From: Vincent MAILHOL @ 2022-05-17 7:04 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Oliver Hartkopp, linux-can, linux-kernel, Max Staudt, netdev
In-Reply-To: <20220517060821.akuqbqxro34tj7x6@pengutronix.de>
On Tue. 17 May 2022 at 15:08, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 17.05.2022 10:50:16, Vincent MAILHOL wrote:
> > > would it probably make sense to
> > > introduce a new can-skb module that could be used by all CAN
> > > virtual/software interfaces?
> > >
> > > Or some other split-up ... any idea?
> >
> > My concern is: what would be the merrit? If we do not split, the users
> > of slcan and v(x)can would have to load the can-dev module which will
> > be slightly bloated for their use, but is this really an issue?
>
> If you use modprobe all required modules are loaded automatically.
Yes, this, now I know. In the past, when I started developing
etas_es58x as an out of tree module (which I inserted using insmod),
it took me a little time to figure out the dependencies tree and which
module I actually had to modprobe separately.
> > I do
> > not see how this can become a performance bottleneck, so what is the
> > problem?
> > I could also argue that most of the devices do not depend on
> > rx-offload.o. So should we also split this one out of can-dev on the
> > same basis and add another module dependency?
>
> We can add a non user visible Kconfig symbol for rx-offload and let the
> drivers that need it do a "select" on it. If selected the rx-offload
> would be compiled into to can-dev module.
Yes, and this remark also applies to can-skb I think.
So slcan, v(x)can and can-dev will select can-skb, and some of the
hardware drivers (still have to figure out the list) will select
can-rx-offload (other dependencies will stay as it is today).
I think that splitting the current can-dev into can-skb + can-dev +
can-rx-offload is enough. Please let me know if you see a need for
more.
> > The benefit (not having to load a bloated module for three drivers)
> > does not outweigh the added complexity: all hardware modules will have
> > one additional modprobe dependency on the tiny can-skb module.
> >
> > But as said above, I am not fully opposed to the split, I am just
> > strongly divided. If we go for the split, creating a can-skb module is
> > the natural and only option I see.
> > If the above argument does not convince you, I will send a v3 with that split.
If both you and Oliver prefer the split, then split it would be!
Because this topic is related to Kbuild, there is actually one thing
which bothered me but which I never asked: why are all the CAN devices
under "Networking support" and not "Device Drivers" in menuconfig like
everything else? Would it make sense to move our devices under the
"Device Drivers" section? I can do it while working on the v3.
^ permalink raw reply
* [PATCH net v2 0/2] amt: fix several bugs in gateway mode
From: Taehee Yoo @ 2022-05-17 7:05 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, netdev; +Cc: ap420073
This patchset fixes bugs in amt module.
First patch fixes amt gateway mode's status stuck.
amt gateway and relay established so these two mode manage status.
But gateway stuck to change its own status if a relay doesn't send
responses.
Second patch fixes a memory leak.
an amt gateway skips some handling of advertisement message.
So, a memory leak would occur.
v2:
- Separate patch
- Add patch cover-letter
Taehee Yoo (2):
amt: fix gateway mode stuck
amt: do not skip remaining handling of advertisement message
drivers/net/amt.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net v2 1/2] amt: fix gateway mode stuck
From: Taehee Yoo @ 2022-05-17 7:05 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, netdev; +Cc: ap420073
In-Reply-To: <20220517070527.10591-1-ap420073@gmail.com>
If a gateway can not receive any response to requests from a relay,
gateway resets status from SENT_REQUEST to INIT and variable about a
relay as well. And then it should start the full establish step
from sending a discovery message and receiving advertisement message.
But, after failure in amt_req_work() it continues sending a request
message step with flushed(invalid) relay information and sets SENT_REQUEST.
So, a gateway can't be established with a relay.
In order to avoid this situation, it stops sending the request message
step if it fails.
Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
v2:
- Separate patch.
drivers/net/amt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/amt.c b/drivers/net/amt.c
index 10455c9b9da0..2b4ce3869f08 100644
--- a/drivers/net/amt.c
+++ b/drivers/net/amt.c
@@ -943,7 +943,7 @@ static void amt_req_work(struct work_struct *work)
if (amt->status < AMT_STATUS_RECEIVED_ADVERTISEMENT)
goto out;
- if (amt->req_cnt++ > AMT_MAX_REQ_COUNT) {
+ if (amt->req_cnt > AMT_MAX_REQ_COUNT) {
netdev_dbg(amt->dev, "Gateway is not ready");
amt->qi = AMT_INIT_REQ_TIMEOUT;
amt->ready4 = false;
@@ -951,13 +951,15 @@ static void amt_req_work(struct work_struct *work)
amt->remote_ip = 0;
__amt_update_gw_status(amt, AMT_STATUS_INIT, false);
amt->req_cnt = 0;
+ goto out;
}
spin_unlock_bh(&amt->lock);
amt_send_request(amt, false);
amt_send_request(amt, true);
- amt_update_gw_status(amt, AMT_STATUS_SENT_REQUEST, true);
spin_lock_bh(&amt->lock);
+ __amt_update_gw_status(amt, AMT_STATUS_SENT_REQUEST, true);
+ amt->req_cnt++;
out:
exp = min_t(u32, (1 * (1 << amt->req_cnt)), AMT_MAX_REQ_TIMEOUT);
mod_delayed_work(amt_wq, &amt->req_wq, msecs_to_jiffies(exp * 1000));
--
2.17.1
^ permalink raw reply related
* [PATCH net v2 2/2] amt: do not skip remaining handling of advertisement message
From: Taehee Yoo @ 2022-05-17 7:05 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, netdev; +Cc: ap420073
In-Reply-To: <20220517070527.10591-1-ap420073@gmail.com>
When a gateway receives an advertisement message, it extracts relay
information and then it should be deleted.
But the advertisement handler doesn't do that.
So, after amt_advertisement_handler(), that message should not be skipped
remaining handling.
Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
v2:
- Separate patch
drivers/net/amt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/amt.c b/drivers/net/amt.c
index 2b4ce3869f08..6ce2ecd07640 100644
--- a/drivers/net/amt.c
+++ b/drivers/net/amt.c
@@ -2698,9 +2698,10 @@ static int amt_rcv(struct sock *sk, struct sk_buff *skb)
err = true;
goto drop;
}
- if (amt_advertisement_handler(amt, skb))
+ err = amt_advertisement_handler(amt, skb);
+ if (err)
amt->dev->stats.rx_dropped++;
- goto out;
+ break;
case AMT_MSG_MULTICAST_DATA:
if (iph->saddr != amt->remote_ip) {
netdev_dbg(amt->dev, "Invalid Relay IP\n");
--
2.17.1
^ permalink raw reply related
* Re: [External] Re: [PATCH bpf-next] selftests/bpf: fix some bugs in map_lookup_percpu_elem testcase
From: Feng Zhou @ 2022-05-17 7:05 UTC (permalink / raw)
To: Yonghong Song, ast, daniel, andrii, kafai, songliubraving,
john.fastabend, kpsingh, rostedt, mingo, jolsa, davemarchevsky,
joannekoong, geliang.tang
Cc: netdev, bpf, linux-kernel, duanxiongchun, songmuchun,
wangdongdong.6, cong.wang, zhouchengming, yosryahmed
In-Reply-To: <80ab09cf-6072-a75a-082d-2721f6f907ef@fb.com>
在 2022/5/17 上午11:09, Yonghong Song 写道:
>
>
> On 5/15/22 7:24 PM, Feng zhou wrote:
>> From: Feng Zhou <zhoufeng.zf@bytedance.com>
>>
>> comments from Andrii Nakryiko, details in here:
>> https://lore.kernel.org/lkml/20220511093854.411-1-zhoufeng.zf@bytedance.com/T/
>>
>>
>> use /* */ instead of //
>> use libbpf_num_possible_cpus() instead of sysconf(_SC_NPROCESSORS_ONLN)
>> use 8 bytes for value size
>> fix memory leak
>> use ASSERT_EQ instead of ASSERT_OK
>> add bpf_loop to fetch values on each possible CPU
>>
>> Fixes: ed7c13776e20c74486b0939a3c1de984c5efb6aa ("selftests/bpf: add
>> test case for bpf_map_lookup_percpu_elem")
>> Signed-off-by: Feng Zhou <zhoufeng.zf@bytedance.com>
>
> LGTM with a few nits below.
> Acked-by: Yonghong Song <yhs@fb.com>
>
Ok, will do. Thanks.
>> ---
>> .../bpf/prog_tests/map_lookup_percpu_elem.c | 49 +++++++++------
>> .../bpf/progs/test_map_lookup_percpu_elem.c | 61 ++++++++++++-------
>> 2 files changed, 70 insertions(+), 40 deletions(-)
>>
>> diff --git
>> a/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c
>> b/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c
>> index 58b24c2112b0..89ca170f1c25 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/map_lookup_percpu_elem.c
>> @@ -1,30 +1,39 @@
>> -// SPDX-License-Identifier: GPL-2.0
>> -// Copyright (c) 2022 Bytedance
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (c) 2022 Bytedance */
>> #include <test_progs.h>
>
> The above empty line is unnecessary.
>
>> #include "test_map_lookup_percpu_elem.skel.h"
>> -#define TEST_VALUE 1
>> -
>> void test_map_lookup_percpu_elem(void)
>> {
>> struct test_map_lookup_percpu_elem *skel;
>> - int key = 0, ret;
>> - int nr_cpus = sysconf(_SC_NPROCESSORS_ONLN);
>> - int *buf;
>> + __u64 key = 0, sum;
>> + int ret, i;
>> + int nr_cpus = libbpf_num_possible_cpus();
>> + __u64 *buf;
>> - buf = (int *)malloc(nr_cpus*sizeof(int));
>> + buf = (__u64 *)malloc(nr_cpus*sizeof(__u64));
>> if (!ASSERT_OK_PTR(buf, "malloc"))
>> return;
>> - memset(buf, 0, nr_cpus*sizeof(int));
>> - buf[0] = TEST_VALUE;
>> - skel = test_map_lookup_percpu_elem__open_and_load();
>> - if (!ASSERT_OK_PTR(skel,
>> "test_map_lookup_percpu_elem__open_and_load"))
>> - return;
>> + for (i=0; i<nr_cpus; i++)
>> + buf[i] = i;
>> + sum = (nr_cpus-1)*nr_cpus/2;
>> +
>> + skel = test_map_lookup_percpu_elem__open();
>> + if (!ASSERT_OK_PTR(skel, "test_map_lookup_percpu_elem__open"))
>> + goto exit;
>> +
>> + skel->rodata->nr_cpus = nr_cpus;
>> +
>> + ret = test_map_lookup_percpu_elem__load(skel);
>> + if (!ASSERT_OK(ret, "test_map_lookup_percpu_elem__load"))
>> + goto cleanup;
>> +
>> ret = test_map_lookup_percpu_elem__attach(skel);
>> - ASSERT_OK(ret, "test_map_lookup_percpu_elem__attach");
>> + if (!ASSERT_OK(ret, "test_map_lookup_percpu_elem__attach"))
>> + goto cleanup;
>> ret =
>> bpf_map_update_elem(bpf_map__fd(skel->maps.percpu_array_map), &key,
>> buf, 0);
>> ASSERT_OK(ret, "percpu_array_map update");
>> @@ -37,10 +46,14 @@ void test_map_lookup_percpu_elem(void)
>> syscall(__NR_getuid);
>> - ret = skel->bss->percpu_array_elem_val == TEST_VALUE &&
>> - skel->bss->percpu_hash_elem_val == TEST_VALUE &&
>> - skel->bss->percpu_lru_hash_elem_val == TEST_VALUE;
>> - ASSERT_OK(!ret, "bpf_map_lookup_percpu_elem success");
>> + test_map_lookup_percpu_elem__detach(skel);
>> +
>> + ASSERT_EQ(skel->bss->percpu_array_elem_sum, sum, "percpu_array
>> lookup percpu elem");
>> + ASSERT_EQ(skel->bss->percpu_hash_elem_sum, sum, "percpu_hash
>> lookup percpu elem");
>> + ASSERT_EQ(skel->bss->percpu_lru_hash_elem_sum, sum,
>> "percpu_lru_hash lookup percpu elem");
>> +cleanup:
>> test_map_lookup_percpu_elem__destroy(skel);
>> +exit:
>> + free(buf);
>> }
> [...]
>> +struct read_percpu_elem_ctx {
>> + void *map;
>> + __u64 sum;
>> +};
>> +
>> +static int read_percpu_elem_callback(__u32 index, struct
>> read_percpu_elem_ctx *ctx)
>> +{
>> + __u64 key = 0;
>> + __u64 *value;
>
> Please add an empty line here.
>
>> + value = bpf_map_lookup_percpu_elem(ctx->map, &key, index);
>> + if (value)
>> + ctx->sum += *value;
>> + return 0;
>> +}
>> +
> [...]
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: add out-of-band tagging protocol
From: Maxime Chevallier @ 2022-05-17 7:06 UTC (permalink / raw)
To: Florian Fainelli
Cc: davem, Rob Herring, netdev, linux-kernel, devicetree,
thomas.petazzoni, Andrew Lunn, Heiner Kallweit, Russell King,
linux-arm-kernel, Vladimir Oltean, Luka Perkov, Robert Marko
In-Reply-To: <89c52305-71da-843e-b6c5-77648fb2f4d3@gmail.com>
Hi Florian,
On Sat, 14 May 2022 09:33:44 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi Maxime,
>
> On 5/14/2022 8:06 AM, Maxime Chevallier wrote:
> > This tagging protocol is designed for the situation where the link
> > between the MAC and the Switch is designed such that the Destination
> > Port, which is usually embedded in some part of the Ethernet
> > Header, is sent out-of-band, and isn't present at all in the
> > Ethernet frame.
> >
> > This can happen when the MAC and Switch are tightly integrated on an
> > SoC, as is the case with the Qualcomm IPQ4019 for example, where
> > the DSA tag is inserted directly into the DMA descriptors. In that
> > case, the MAC driver is responsible for sending the tag to the
> > switch using the out-of-band medium. To do so, the MAC driver needs
> > to have the information of the destination port for that skb.
> >
> > This out-of-band tagging protocol is using the very beggining of
> > the skb headroom to store the tag. The drawback of this approch is
> > that the headroom isn't initialized upon allocating it, therefore
> > we have a chance that the garbage data that lies there at
> > allocation time actually ressembles a valid oob tag. This is only
> > problematic if we are sending/receiving traffic on the master port,
> > which isn't a valid DSA use-case from the beggining. When dealing
> > from traffic to/from a slave port, then the oob tag will be
> > initialized properly by the tagger or the mac driver through the
> > use of the dsa_oob_tag_push() call.
>
> What I like about your approach is that you have aligned the way an
> out of band switch tag is communicated to the networking stack the
> same way that an "in-band" switch tag would be communicated. I think
> this is a good way forward to provide the out of band tag and I don't
> think it creates a performance problem because the Ethernet frame is
> hot in the cache (dma_unmap_single()) and we already have an
> "expensive" read of the DMA descriptor in coherent memory anyway.
>
> You could possibly optimize the data flow a bit to limit the amount
> of sk_buff data movement by asking your Ethernet controller to DMA
> into the data buffer N bytes into the beginning of the data buffer.
> That way, if you have reserved say, 2 bytes at the front data buffer
> you can deposit the QCA tag there and you do not need to push,
> process the tag, then pop it, just process and pop. Consider using
> the 2byte stuffing that the Ethernet controller might be adding to
> the beginning of the Ethernet frame to align the IP header on a
> 4-byte boundary to provide the tag in there?
>
> If we want to have a generic out of band tagger like you propose, it
> seems to me that we will need to invent a synthetic DSA tagging
> format which is the largest common denominator of the out of band
> tags that we want to support. We could imagine being more compact in
> the representation for instance by using an u8 for storing a bitmask
> of ports (works for both RX and TX then) and another u8 for various
> packet forwarding reasons.
Thanks, that was my initial idea indeed. Having a generic tagger that
can be re-used would be great IMO. I'll modify the format as you
propose, and also give a try to you approach of DMA'ing 2 bytes forward
so that the tag location is already allocated, that's a nice idea.
> Then we would request the various Ethernet MAC drivers to marshall
> their proprietary tag into the DSA synthetic one on receive, and
> unmarshall it on transmit.
>
> Another approach IMHO which maybe helps the maintainability of the
> code moving forward as well as ensuring that all Ethernet switch
> tagging code lives in one place, is to teach each tagger driver how
> to optimize their data paths to minimize the amount of data movements
> and checksum re-calculations, this is what I had in mind a few years
> ago:
>
> https://lore.kernel.org/lkml/1438322920.20182.144.camel@edumazet-glaptop2.roam.corp.google.com/T/
>
> This might scale a little less well, and maybe this makes too many
> assumptions as to where and how the checksums are calculated on the
> packet contents, but at least, you don't have logic processing the
> same type of switch tag scattered between the Ethernet MAC drivers
> (beyond copying/pushing) and DSA switch taggers.
That would definitely fit well with this tagger, I didn't know about
that series !
Thanks for the review,
Maxime
> I would like to hear other's opinion on this.
^ permalink raw reply
* [PATCH bpf-next v4 0/6] bpf trampoline for arm64
From: Xu Kuohai @ 2022-05-17 7:18 UTC (permalink / raw)
To: bpf, linux-arm-kernel, linux-kernel, netdev, linux-kselftest
Cc: Catalin Marinas, Will Deacon, Steven Rostedt, Ingo Molnar,
Daniel Borkmann, Alexei Starovoitov, Zi Shen Lim, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Thomas Gleixner, Borislav Petkov, Dave Hansen, x86, hpa,
Shuah Khan, Jakub Kicinski, Jesper Dangaard Brouer, Mark Rutland,
Pasha Tatashin, Ard Biesheuvel, Daniel Kiss, Steven Price,
Sudeep Holla, Marc Zyngier, Peter Collingbourne, Mark Brown,
Delyan Kratunov, Kumar Kartikeya Dwivedi
Add bpf trampoline support for arm64. Most of the logic is the same as
x86.
Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump),
result:
#9 /1 bpf_cookie/kprobe:OK
#9 /2 bpf_cookie/multi_kprobe_link_api:FAIL
#9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL
#9 /4 bpf_cookie/uprobe:OK
#9 /5 bpf_cookie/tracepoint:OK
#9 /6 bpf_cookie/perf_event:OK
#9 /7 bpf_cookie/trampoline:OK
#9 /8 bpf_cookie/lsm:OK
#9 bpf_cookie:FAIL
#18 /1 bpf_tcp_ca/dctcp:OK
#18 /2 bpf_tcp_ca/cubic:OK
#18 /3 bpf_tcp_ca/invalid_license:OK
#18 /4 bpf_tcp_ca/dctcp_fallback:OK
#18 /5 bpf_tcp_ca/rel_setsockopt:OK
#18 bpf_tcp_ca:OK
#51 /1 dummy_st_ops/dummy_st_ops_attach:OK
#51 /2 dummy_st_ops/dummy_init_ret_value:OK
#51 /3 dummy_st_ops/dummy_init_ptr_arg:OK
#51 /4 dummy_st_ops/dummy_multiple_args:OK
#51 dummy_st_ops:OK
#55 fentry_fexit:OK
#56 fentry_test:OK
#57 /1 fexit_bpf2bpf/target_no_callees:OK
#57 /2 fexit_bpf2bpf/target_yes_callees:OK
#57 /3 fexit_bpf2bpf/func_replace:OK
#57 /4 fexit_bpf2bpf/func_replace_verify:OK
#57 /5 fexit_bpf2bpf/func_sockmap_update:OK
#57 /6 fexit_bpf2bpf/func_replace_return_code:OK
#57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK
#57 /8 fexit_bpf2bpf/func_replace_multi:OK
#57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK
#57 fexit_bpf2bpf:OK
#58 fexit_sleep:OK
#59 fexit_stress:OK
#60 fexit_test:OK
#67 get_func_args_test:OK
#68 get_func_ip_test:OK
#104 modify_return:OK
#237 xdp_bpf2bpf:OK
bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api
failed due to lack of multi_kprobe on arm64.
v4:
- Run the test cases on raspberry pi 4b
- Rebase and add cookie to trampoline
- As Steve suggested, move trace_direct_tramp() back to entry-ftrace.S to
avoid messing up generic code with architecture specific code
- As Jakub suggested, merge patch 4 and patch 5 of v3 to provide full function
in one patch
- As Mark suggested, add a comment for the use of aarch64_insn_patch_text_nosync()
- Do not generate trampoline for long jump to avoid triggering ftrace_bug
- Round stack size to multiples of 16B to avoid SPAlignmentFault
- Use callee saved register x20 to reduce the use of mov_i64
- Add missing BTI J instructions
- Trivial spelling and code sytle fixes
v3: https://lore.kernel.org/bpf/20220424154028.1698685-1-xukuohai@huawei.com/
- Append test results for bpf_tcp_ca, dummy_st_ops, fexit_bpf2bpf,
xdp_bpf2bpf
- Support to poke bpf progs
- Fix return value of arch_prepare_bpf_trampoline() to the total number
of bytes instead of number of instructions
- Do not check whether CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled in
arch_prepare_bpf_trampoline, since the trampoline may be hooked to a bpf
prog
- Restrict bpf_arch_text_poke() to poke bpf text only, as kernel functions
are poked by ftrace
- Rewrite trace_direct_tramp() in inline assembly in trace_selftest.c
to avoid messing entry-ftrace.S
- isolate arch_ftrace_set_direct_caller() with macro
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS to avoid compile error
when this macro is disabled
- Some trivial code sytle fixes
v2: https://lore.kernel.org/bpf/20220414162220.1985095-1-xukuohai@huawei.com/
- Add Song's ACK
- Change the multi-line comment in is_valid_bpf_tramp_flags() into net
style (patch 3)
- Fix a deadloop issue in ftrace selftest (patch 2)
- Replace pt_regs->x0 with pt_regs->orig_x0 in patch 1 commit message
- Replace "bpf trampoline" with "custom trampoline" in patch 1, as
ftrace direct call is not only used by bpf trampoline.
v1: https://lore.kernel.org/bpf/20220413054959.1053668-1-xukuohai@huawei.com/
Xu Kuohai (6):
arm64: ftrace: Add ftrace direct call support
ftrace: Fix deadloop caused by direct call in ftrace selftest
bpf: Move is_valid_bpf_tramp_flags() to the public trampoline code
bpf, arm64: Impelment bpf_arch_text_poke() for arm64
bpf, arm64: bpf trampoline for arm64
selftests/bpf: Fix trivial typo in fentry_fexit.c
arch/arm64/Kconfig | 2 +
arch/arm64/include/asm/ftrace.h | 22 +
arch/arm64/kernel/asm-offsets.c | 1 +
arch/arm64/kernel/entry-ftrace.S | 28 +-
arch/arm64/net/bpf_jit.h | 1 +
arch/arm64/net/bpf_jit_comp.c | 523 +++++++++++++++++-
arch/x86/net/bpf_jit_comp.c | 20 -
include/linux/bpf.h | 6 +
kernel/bpf/bpf_struct_ops.c | 4 +-
kernel/bpf/trampoline.c | 34 +-
kernel/trace/trace_selftest.c | 2 +
.../selftests/bpf/prog_tests/fentry_fexit.c | 4 +-
12 files changed, 603 insertions(+), 44 deletions(-)
--
2.30.2
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] intel/i40e: delete if NULL check before dev_kfree_skb
From: G, GurucharanX @ 2022-05-17 7:07 UTC (permalink / raw)
To: Bernard Zhao, Brandeburg, Jesse, Nguyen, Anthony L,
David S. Miller, Jakub Kicinski, Paolo Abeni,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: bernard@vivo.com
In-Reply-To: <20220511065451.655335-1-zhaojunkui2008@126.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Bernard Zhao
> Sent: Wednesday, May 11, 2022 12:25 PM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; David S. Miller <davem@davemloft.net>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>;
> intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: bernard@vivo.com; Bernard Zhao <zhaojunkui2008@126.com>
> Subject: [Intel-wired-lan] [PATCH] intel/i40e: delete if NULL check before
> dev_kfree_skb
>
> dev_kfree_skb check if the input parameter NULL and do the right
> thing, there is no need to check again.
> This change is to cleanup the code a bit.
>
> Signed-off-by: Bernard Zhao <zhaojunkui2008@126.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ 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