* [PATCH bpf-next v4 1/2] bpf: setup socket family and addresses in bpf_prog_test_run_skb
From: Dmitry Yakunin @ 2020-08-02 18:26 UTC (permalink / raw)
To: alexei.starovoitov, daniel, netdev, bpf; +Cc: sdf
In-Reply-To: <20200802182638.77377-1-zeil@yandex-team.ru>
Now it's impossible to test all branches of cgroup_skb bpf program which
accesses skb->family and skb->{local,remote}_ip{4,6} fields because they
are zeroed during socket allocation. This commit fills socket family and
addresses from related fields in constructed skb.
v2:
- fix build without CONFIG_IPV6 (kernel test robot <lkp@intel.com>)
Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
---
net/bpf/test_run.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index b03c469..2521b27 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -449,6 +449,23 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
skb->protocol = eth_type_trans(skb, current->nsproxy->net_ns->loopback_dev);
skb_reset_network_header(skb);
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ sk->sk_family = AF_INET;
+ sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
+ sk->sk_daddr = ip_hdr(skb)->daddr;
+ break;
+#if IS_ENABLED(CONFIG_IPV6)
+ case htons(ETH_P_IPV6):
+ sk->sk_family = AF_INET6;
+ sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
+ sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
+ break;
+#endif
+ default:
+ break;
+ }
+
if (is_l2)
__skb_push(skb, hh_len);
if (is_direct_pkt_access)
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next v4 0/2] bpf: cgroup skb improvements for bpf_prog_test_run
From: Dmitry Yakunin @ 2020-08-02 18:26 UTC (permalink / raw)
To: alexei.starovoitov, daniel, netdev, bpf; +Cc: sdf
This patchset contains some improvements for testing cgroup/skb programs
through BPF_PROG_TEST_RUN command.
v2:
- fix build without CONFIG_CGROUP_BPF (kernel test robot <lkp@intel.com>)
v3:
- fix build without CONFIG_IPV6 (kernel test robot <lkp@intel.com>)
v4:
- remove cgroup storage related commits for future rework (Daniel Borkmann)
Dmitry Yakunin (2):
bpf: setup socket family and addresses in bpf_prog_test_run_skb
bpf: allow to specify ifindex for skb in bpf_prog_test_run_skb
net/bpf/test_run.c | 39 ++++++++++++++++++++++--
tools/testing/selftests/bpf/prog_tests/skb_ctx.c | 5 +++
2 files changed, 42 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH bpf-next] tools build: propagate build failures from tools/build/Makefile.build
From: Andrii Nakryiko @ 2020-08-02 18:22 UTC (permalink / raw)
To: Jiri Olsa
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Jiri Olsa, Arnaldo Carvalho de Melo
In-Reply-To: <20200802161106.GA127459@krava>
On Sun, Aug 2, 2020 at 9:11 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Thu, Jul 30, 2020 at 07:42:44PM -0700, Andrii Nakryiko wrote:
> > The '&&' command seems to have a bad effect when $(cmd_$(1)) exits with
> > non-zero effect: the command failure is masked (despite `set -e`) and all but
> > the first command of $(dep-cmd) is executed (successfully, as they are mostly
> > printfs), thus overall returning 0 in the end.
>
> nice, thanks for digging into this,
> any idea why is the failure masked?
Two things.
1. In make, assume you have command f = a in one function and g = b; c
in another. If you write f && g, you end up with (a && b); c, right?
2. Try this shell script:
set -ex
false && true
true
It will return success. It won't execute the first true command, as
expected, but won't terminate the shell as you'd expect from set -e.
So basically, having a "logical operator" in a sequence of commands
negates the effect of `set -e`. Intuitively I'd expect that from ||,
but seems like && does that as well. if [] has similar effect -- any
failing command in an if check doesn't trigger an early termination of
a script.
>
> Acked-by: Jiri Olsa <jolsa@redhat.com>
>
> jirka
>
> >
> > This means in practice that despite compilation errors, tools's build Makefile
> > will return success. We see this very reliably with libbpf's Makefile, which
> > doesn't get compilation error propagated properly. This in turns causes issues
> > with selftests build, as well as bpftool and other projects that rely on
> > building libbpf.
> >
> > The fix is simple: don't use &&. Given `set -e`, we don't need to chain
> > commands with &&. The shell will exit on first failure, giving desired
> > behavior and propagating error properly.
> >
> > Cc: Jiri Olsa <jolsa@kernel.org>
> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Fixes: 275e2d95591e ("tools build: Move dependency copy into function")
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> >
> > I'm sending this against bpf-next tree, given libbpf is affected enough for me
> > to debug this fun problem that no one seemed to notice (or care, at least) in
> > almost 5 years. If there is a better kernel tree, please let me know.
> >
> > tools/build/Build.include | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/build/Build.include b/tools/build/Build.include
> > index 9ec01f4454f9..585486e40995 100644
> > --- a/tools/build/Build.include
> > +++ b/tools/build/Build.include
> > @@ -74,7 +74,8 @@ dep-cmd = $(if $(wildcard $(fixdep)),
> > # dependencies in the cmd file
> > if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \
> > @set -e; \
> > - $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
> > + $(echo-cmd) $(cmd_$(1)); \
> > + $(dep-cmd))
> >
> > # if_changed - execute command if any prerequisite is newer than
> > # target, or command line has changed
> > --
> > 2.24.1
> >
>
^ permalink raw reply
* Re: Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards
From: Ben Hutchings @ 2020-08-02 17:49 UTC (permalink / raw)
To: Thorsten Glaser, 966459; +Cc: netdev
In-Reply-To: <159596111771.2639.6929056987566441726.reportbug@tglase-nb.lan.tarent.de>
[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]
[The previous message is archived at <https://bugs.debian.org/966459>.]
On Tue, 2020-07-28 at 20:31 +0200, Thorsten Glaser wrote:
> Package: src:linux
> Version: 5.7.6-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: tg@mirbsd.de
>
> I’m using setsockopt to set the traffic class on sending and receive
> it in control messages on receiving, for both IPv4 and IPv6.
>
> The relevant documentation is the ip(7) manpage and, because the ipv6(7)
> manpage doesn’t contain it, RFC3542.
ip(7) also doesn't document IP_PKTOPIONS.
[...]
> Same in net/ipv4/ip_sockglue.c…
>
> int tos = inet->rcv_tos;
> put_cmsg(&msg, SOL_IP, IP_TOS, sizeof(tos), &tos);
> … in one place, but…
>
> put_cmsg(msg, SOL_IP, IP_TOS, 1, &ip_hdr(skb)->tos);
>
> … in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!).
Those are two different APIs though: recvmsg() for datagram sockets, vs
getsockopt(... IP_PKTOPTIONS ...) for stream sockets. They obviously
ought to be consistent, but mistakes happen.
[...]
> tl;dr: Receiving traffic class values from IP traffic is broken on
> big endian platforms.
Some user-space that uses getsockopt(... IP_PKTOPTIONS ...) for stream
sockets might be broken.
I searched for 'cmsg_type.*IP_TOS' on codesearch.debian.net, and found
only two instances where it was used in conjunction with IP_PKTOPTIONS.
libzorpll reads only the first byte (so is broken on big-endian):
https://sources.debian.org/src/libzorpll/7.0.1.0%7Ealpha1-1.1/src/io.cc/#L239
squid reads an int and then truncates it to a byte (so is fine):
https://sources.debian.org/src/squid/4.12-1/src/ip/QosConfig.cc/#L41
> I place the following suggestion for discussion, to achieve maximum
> portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where
> the first and fourth byte are, identically, traffic class, second and
> third 0.
[...]
I see no point in changing the IPv6 behaviour: it seems to be
consistent with itself and with the standard, so only risks breaking
user-space that works today.
As for IPv4, changing the format of the IP_TOS field in the
IP_PKTOPIONS value looks like it would work for the two users found in
Debian.
But you should know that the highest priority for Linux API
compatibility is to avoid breaking currently working user-space. That
means that ugly and inconsistent APIs won't get fixed if it causes a
regression for the programs people actually use. If the API never
worked like it was supposed to on some architectures, that's not a
regression, and is lower priority.
Ben.
--
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add support to flash firmware config image
From: Rahul Lakkireddy @ 2020-08-02 17:12 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Ganji Aravind, netdev, davem, vishal
In-Reply-To: <20200801212202.7e4f3be2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Saturday, August 08/01/20, 2020 at 21:22:02 -0700, Jakub Kicinski wrote:
> On Sat, 1 Aug 2020 02:47:38 +0530 Rahul Lakkireddy wrote:
> > I thought /lib/firmware is where firmware related files need to be
> > placed and ethtool --flash needs to be used to program them to
> > their respective locations on adapter's flash.
>
> Our goal is to provide solid, common interfaces for Linux users to rely
> on. Not give way to vendor specific "solutions" like uploading ini files
> to perform device configuration.
>
> > Note that we don't have devlink support in our driver yet. And,
> > we're a bit confused here on why this already existing ethtool
> > feature needs to be duplicated to devlink.
>
> To be clear - I'm suggesting the creation of a more targeted APIs
> to control the settings you have encoded _inside_ the ini file.
> Not a new interface for an whole sale config upload.
>
> Worst case scenario - if the settings are really device specific
> you can try to use devlink device parameters.
The config file contains very low-level firmware and device specific
params and most of them are dependent on the type of Chelsio NIC.
The params are mostly device dependent register-value pairs.
We don't see users messing around with the params on their own
without consultation. The users only need some mechanism to flash
the custom config file shared by us on to their adapter. After
device restart, the firmware will automatically pick up the flashed
config file and redistribute the resources, as per their requested
use-case.
We're already foreseeing very long awkward list (more than 50 params)
for mapping the config file to devlink-dev params and are hoping this
is fine. Here's a sample on how it would look.
hw_sge_reg_1008=0x40800
hw_sge_reg_100c=0x22222222
hw_sge_reg_10a0=0x01040810
hw_tp_reg_7d04=0x00010000
hw_tp_reg_7dc0=0x0e2f8849
and so on.
Thanks,
Rahul
^ permalink raw reply
* Re: [PATCH] ethtool: Add QSFP-DD support
From: Andrew Lunn @ 2020-08-02 16:55 UTC (permalink / raw)
To: Adrian Pop; +Cc: netdev, linville, davem, kuba, jiri, vadimp, mlxsw, idosch
In-Reply-To: <20200731084725.7804-1-popadrian1996@gmail.com>
On Fri, Jul 31, 2020 at 11:47:25AM +0300, Adrian Pop wrote:
> The Common Management Interface Specification (CMIS) for QSFP-DD shares
> some similarities with other form factors such as QSFP or SFP, but due to
> the fact that the module memory map is different, the current ethtool
> version is not able to provide relevant information about an interface.
>
> This patch adds QSFP-DD support to ethtool. The changes are similar to
> the ones already existing in qsfp.c, but customized to use the memory
> addresses and logic as defined in the specifications document.
>
> Page 0x00 (lower and higher memory) are always implemented, so the ethtool
> expects at least 256 bytes if the identifier matches the one for QSFP-DD.
> For optical connected cables, additional pages are usually available (the
> contain module defined thresholds or lane diagnostic information). In
> this case, ethtool expects to receive 768 bytes in the following format:
>
> +----------+----------+----------+----------+----------+----------+
> | Page | Page | Page | Page | Page | Page |
> | 0x00 | 0x00 | 0x01 | 0x02 | 0x10 | 0x11 |
> | (lower) | (higher) | (higher) | (higher) | (higher) | (higher) |
> | 128B | 128B | 128B | 128B | 128B | 128B |
> +----------+----------+----------+----------+----------+----------
Hi Adrian
Didn't we discuss that page 3 might be useful? I would prefer not to
document that pages 0x10 and 0x11 would follow page 2 until we have a
driver which does actually provide pages 0x10 and 0x11.
Andrew
^ permalink raw reply
* Re: [PATCH v2 4/4 net-next] net: mdio device: use flexible sleeping in reset function
From: Andrew Lunn @ 2020-08-02 16:48 UTC (permalink / raw)
To: Bruno Thomsen
Cc: netdev, Fabio Estevam, Florian Fainelli, Russell King - ARM Linux,
Heiner Kallweit, Lars Alex Pedersen, Bruno Thomsen
In-Reply-To: <20200730195749.4922-5-bruno.thomsen@gmail.com>
On Thu, Jul 30, 2020 at 09:57:49PM +0200, Bruno Thomsen wrote:
> MDIO device reset assert and deassert length was created by
> usleep_range() but that does not ensure optimal handling of
> all the different values from device tree properties.
> By switching to the new flexible sleeping helper function,
> fsleep(), the correct delay function is called depending on
> delay length, e.g. udelay(), usleep_range() or msleep().
>
> Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/4 net-next] net: mdiobus: add reset-post-delay-us handling
From: Andrew Lunn @ 2020-08-02 16:47 UTC (permalink / raw)
To: Bruno Thomsen
Cc: netdev, Fabio Estevam, Florian Fainelli, Russell King - ARM Linux,
Heiner Kallweit, Lars Alex Pedersen, Bruno Thomsen
In-Reply-To: <20200730195749.4922-4-bruno.thomsen@gmail.com>
On Thu, Jul 30, 2020 at 09:57:48PM +0200, Bruno Thomsen wrote:
> Load new "reset-post-delay-us" value from MDIO properties,
> and if configured to a greater then zero delay do a
> flexible sleeping delay after MDIO bus reset deassert.
> This allows devices to exit reset state before start
> bus communication.
>
> Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/4 net-next] net: mdiobus: use flexible sleeping for reset-delay-us
From: Andrew Lunn @ 2020-08-02 16:46 UTC (permalink / raw)
To: Bruno Thomsen
Cc: netdev, Fabio Estevam, Florian Fainelli, Russell King - ARM Linux,
Heiner Kallweit, Lars Alex Pedersen, Bruno Thomsen
In-Reply-To: <20200730195749.4922-3-bruno.thomsen@gmail.com>
On Thu, Jul 30, 2020 at 09:57:47PM +0200, Bruno Thomsen wrote:
> MDIO bus reset pulse width is created by using udelay()
> and that function might not be optimal depending on
> device tree value. By switching to the new fsleep() helper
> the correct delay function is called depending on
> delay length, e.g. udelay(), usleep_range() or msleep().
>
> Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/4 net-next] dt-bindings: net: mdio: add reset-post-delay-us property
From: Andrew Lunn @ 2020-08-02 16:46 UTC (permalink / raw)
To: Bruno Thomsen
Cc: netdev, Fabio Estevam, Florian Fainelli, Russell King - ARM Linux,
Heiner Kallweit, Lars Alex Pedersen, Bruno Thomsen
In-Reply-To: <20200730195749.4922-2-bruno.thomsen@gmail.com>
On Thu, Jul 30, 2020 at 09:57:46PM +0200, Bruno Thomsen wrote:
> Add "reset-post-delay-us" parameter to MDIO bus properties,
> so it's possible to add a delay after reset deassert.
> This is optional in case external hardware slows down
> release of the reset signal.
>
> Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] brcmfmac: check ndev pointer
From: trix @ 2020-08-02 16:18 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, kvalo, davem, kuba, rafal, tklauser
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel, Tom Rix
From: Tom Rix <trix@redhat.com>
Clang static analysis reports this error
brcmfmac/core.c:490:4: warning: Dereference of null pointer
(*ifp)->ndev->stats.rx_errors++;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this block of code
if (ret || !(*ifp) || !(*ifp)->ndev) {
if (ret != -ENODATA && *ifp)
(*ifp)->ndev->stats.rx_errors++;
brcmu_pkt_buf_free_skb(skb);
return -ENODATA;
}
(*ifp)->ndev being NULL is caught as an error
But then it is used to report the error.
So add a check before using it.
Fixes: 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device")
Signed-off-by: Tom Rix <trix@redhat.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index f89010a81ffb..aa9ced3c86fb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -486,7 +486,7 @@ static int brcmf_rx_hdrpull(struct brcmf_pub *drvr, struct sk_buff *skb,
ret = brcmf_proto_hdrpull(drvr, true, skb, ifp);
if (ret || !(*ifp) || !(*ifp)->ndev) {
- if (ret != -ENODATA && *ifp)
+ if (ret != -ENODATA && *ifp && (*ifp)->ndev)
(*ifp)->ndev->stats.rx_errors++;
brcmu_pkt_buf_free_skb(skb);
return -ENODATA;
--
2.18.1
^ permalink raw reply related
* Re: [PATCH bpf-next] tools build: propagate build failures from tools/build/Makefile.build
From: Jiri Olsa @ 2020-08-02 16:11 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team, Jiri Olsa,
Arnaldo Carvalho de Melo
In-Reply-To: <20200731024244.872574-1-andriin@fb.com>
On Thu, Jul 30, 2020 at 07:42:44PM -0700, Andrii Nakryiko wrote:
> The '&&' command seems to have a bad effect when $(cmd_$(1)) exits with
> non-zero effect: the command failure is masked (despite `set -e`) and all but
> the first command of $(dep-cmd) is executed (successfully, as they are mostly
> printfs), thus overall returning 0 in the end.
nice, thanks for digging into this,
any idea why is the failure masked?
Acked-by: Jiri Olsa <jolsa@redhat.com>
jirka
>
> This means in practice that despite compilation errors, tools's build Makefile
> will return success. We see this very reliably with libbpf's Makefile, which
> doesn't get compilation error propagated properly. This in turns causes issues
> with selftests build, as well as bpftool and other projects that rely on
> building libbpf.
>
> The fix is simple: don't use &&. Given `set -e`, we don't need to chain
> commands with &&. The shell will exit on first failure, giving desired
> behavior and propagating error properly.
>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Fixes: 275e2d95591e ("tools build: Move dependency copy into function")
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
>
> I'm sending this against bpf-next tree, given libbpf is affected enough for me
> to debug this fun problem that no one seemed to notice (or care, at least) in
> almost 5 years. If there is a better kernel tree, please let me know.
>
> tools/build/Build.include | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/build/Build.include b/tools/build/Build.include
> index 9ec01f4454f9..585486e40995 100644
> --- a/tools/build/Build.include
> +++ b/tools/build/Build.include
> @@ -74,7 +74,8 @@ dep-cmd = $(if $(wildcard $(fixdep)),
> # dependencies in the cmd file
> if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)), \
> @set -e; \
> - $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
> + $(echo-cmd) $(cmd_$(1)); \
> + $(dep-cmd))
>
> # if_changed - execute command if any prerequisite is newer than
> # target, or command line has changed
> --
> 2.24.1
>
^ permalink raw reply
* [PATCH] net: sfc: fix possible buffer overflow caused by bad DMA value in efx_siena_sriov_vfdi()
From: Jia-Ju Bai @ 2020-08-02 15:39 UTC (permalink / raw)
To: linux-net-drivers, ecree, mhabets, davem, kuba
Cc: netdev, linux-kernel, Jia-Ju Bai
In efx_siena_sriov_vfdi():
req = vf->buf.addr;
Because "vf->buf.addr" is mapped to coherent DMA (allocated in
efx_nic_alloc_buffer()), "req" is also mapped to DMA.
Then "req->op" is accessed in this function:
if (req->op < VFDI_OP_LIMIT && vfdi_ops[req->op] != NULL) {
rc = vfdi_ops[req->op](vf);
Because "req" is mapped to DMA, its data can be modified at any time by
malicious or malfunctioning hardware. In this case, the check
"if (req->op < VFDI_OP_LIMIT)" can be passed, and then "req->op" can be
modified to cause buffer overflow when the driver accesses
"vfdi_ops[req->op]".
To fix this problem, "req->op" is assigned to a local variable, and then
the driver accesses this variable instead of "req->op".
Signed-off-by: Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
---
drivers/net/ethernet/sfc/siena_sriov.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/siena_sriov.c b/drivers/net/ethernet/sfc/siena_sriov.c
index 83dcfcae3d4b..21a8482cbb3b 100644
--- a/drivers/net/ethernet/sfc/siena_sriov.c
+++ b/drivers/net/ethernet/sfc/siena_sriov.c
@@ -875,6 +875,7 @@ static void efx_siena_sriov_vfdi(struct work_struct *work)
struct vfdi_req *req = vf->buf.addr;
struct efx_memcpy_req copy[2];
int rc;
+ u32 op = req->op;
/* Copy this page into the local address space */
memset(copy, '\0', sizeof(copy));
@@ -894,17 +895,17 @@ static void efx_siena_sriov_vfdi(struct work_struct *work)
return;
}
- if (req->op < VFDI_OP_LIMIT && vfdi_ops[req->op] != NULL) {
- rc = vfdi_ops[req->op](vf);
+ if (op < VFDI_OP_LIMIT && vfdi_ops[op] != NULL) {
+ rc = vfdi_ops[op](vf);
if (rc == 0) {
netif_dbg(efx, hw, efx->net_dev,
"vfdi request %d from %s ok\n",
- req->op, vf->pci_name);
+ op, vf->pci_name);
}
} else {
netif_dbg(efx, hw, efx->net_dev,
"ERROR: Unrecognised request %d from VF %s addr "
- "%llx\n", req->op, vf->pci_name,
+ "%llx\n", op, vf->pci_name,
(unsigned long long)vf->req_addr);
rc = VFDI_RC_EOPNOTSUPP;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] brcmfmac: Set timeout value when configuring power save
From: Kalle Valo @ 2020-08-02 15:32 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-kernel, Nicolas Saenz Julienne, Arend van Spriel,
Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
David S. Miller, Jakub Kicinski, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20200721112302.22718-1-nsaenzjulienne@suse.de>
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote:
> Set the timeout value as per cfg80211's set_power_mgmt() request. If the
> requested value value is left undefined we set it to 2 seconds, the
> maximum supported value.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Patch applied to wireless-drivers-next.git, thanks.
3dc05ffb0443 brcmfmac: Set timeout value when configuring power save
--
https://patchwork.kernel.org/patch/11675499/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next] brcm80211: fix possible memleak in brcmf_proto_msgbuf_attach
From: Kalle Valo @ 2020-08-02 15:29 UTC (permalink / raw)
To: Wang Yufen
Cc: netdev, linux-kernel, brcm80211-dev-list, linux-wireless, davem,
kuba, franky.lin, wright.feng, Wang Yufen
In-Reply-To: <1595237765-66238-1-git-send-email-wangyufen@huawei.com>
Wang Yufen <wangyufen@huawei.com> wrote:
> When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL,
> we should destroy the workqueue.
>
> Fixes: 05491d2ccf20 ("brcm80211: move under broadcom vendor directory")
Moving the driver to another directory cannot have caused this bug, so I'm
removing the fixes tag. Please check your commit logs, don't just blindly copy
what git-blame says.
--
https://patchwork.kernel.org/patch/11673291/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net] wl1251: fix always return 0 error
From: Kalle Valo @ 2020-08-02 15:25 UTC (permalink / raw)
To: Wang Hai
Cc: davem, kuba, david.gnedt, linville, pavel, pali, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20200730073939.33704-1-wanghai38@huawei.com>
Wang Hai <wanghai38@huawei.com> wrote:
> wl1251_event_ps_report() should not always return 0 because
> wl1251_ps_set_mode() may fail. Change it to return 'ret'.
>
> Fixes: f7ad1eed4d4b ("wl1251: retry power save entry")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Wang Hai <wanghai38@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
20e6421344b5 wl1251: fix always return 0 error
--
https://patchwork.kernel.org/patch/11692427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v1] airo: use generic power management
From: Kalle Valo @ 2020-08-02 15:24 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
David S. Miller, Jakub Kicinski, Dan Carpenter, Vaibhav Gupta,
linux-wireless, netdev, linux-kernel, linux-kernel-mentees,
Shuah Khan
In-Reply-To: <20200728114128.1218310-1-vaibhavgupta40@gmail.com>
Vaibhav Gupta <vaibhavgupta40@gmail.com> wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
>
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable to take the unnecessary load from the driver.
> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions, as through
> the generic framework PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
c3ab1804b168 airo: use generic power management
--
https://patchwork.kernel.org/patch/11688983/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 7/9] intersil: fix wiki website url
From: Kalle Valo @ 2020-08-02 15:23 UTC (permalink / raw)
To: Flavio Suligoi
Cc: David S . Miller, Jakub Kicinski, Gustavo A . R . Silva,
Cong Wang, linux-wireless, netdev, linux-kernel, Flavio Suligoi
In-Reply-To: <20200723135254.594984-1-f.suligoi@asem.it>
Flavio Suligoi <f.suligoi@asem.it> wrote:
> In some Intersil files, the wiki url is still the old
> "wireless.kernel.org" instead of the new
> "wireless.wiki.kernel.org"
>
> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Patch applied to wireless-drivers-next.git, thanks.
4dd9e7e08bc3 intersil: fix wiki website url
--
https://patchwork.kernel.org/patch/11681025/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net] qtnfmac: Missing platform_device_unregister() on error in qtnf_core_mac_alloc()
From: Kalle Valo @ 2020-08-02 15:20 UTC (permalink / raw)
To: Wang Hai
Cc: imitsyanko, geomatsi, davem, kuba, mst, mkarpenko, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20200730064910.37589-1-wanghai38@huawei.com>
Wang Hai <wanghai38@huawei.com> wrote:
> Add the missing platform_device_unregister() before return from
> qtnf_core_mac_alloc() in the error handling case.
>
> Fixes: 616f5701f4ab ("qtnfmac: assign each wiphy to its own virtual platform device")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Wang Hai <wanghai38@huawei.com>
> Reviewed-by: Sergey Matyukevich <geomatsi@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
141bc9abbbff qtnfmac: Missing platform_device_unregister() on error in qtnf_core_mac_alloc()
--
https://patchwork.kernel.org/patch/11692387/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] ipw2100: Use GFP_KERNEL instead of GFP_ATOMIC in some memory allocation
From: Kalle Valo @ 2020-08-02 15:19 UTC (permalink / raw)
To: Christophe JAILLET
Cc: stas.yakovlev, davem, kuba, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <20200722101701.26126-1-christophe.jaillet@wanadoo.fr>
Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> The call chain is:
> ipw2100_pci_init_one (the probe function)
> --> ipw2100_queues_allocate
> --> ipw2100_tx_allocate
>
> No lock is taken in the between.
> So it is safe to use GFP_KERNEL in 'ipw2100_tx_allocate()'.
>
> BTW, 'ipw2100_queues_allocate()' also calls 'ipw2100_msg_allocate()' which
> already allocates some memory using GFP_KERNEL.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
2 patches applied to wireless-drivers-next.git, thanks.
9130559cf8db ipw2100: Use GFP_KERNEL instead of GFP_ATOMIC in some memory allocation
e52525c0c320 ipw2x00: switch from 'pci_' to 'dma_' API
--
https://patchwork.kernel.org/patch/11678101/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: memory leak in veth_dev_init
From: syzbot @ 2020-08-02 15:19 UTC (permalink / raw)
To: andriin, ast, bpf, daniel, davem, hawk, john.fastabend, kafai,
kpsingh, kuba, linux-kernel, netdev, songliubraving,
syzkaller-bugs, yhs
In-Reply-To: <0000000000000a730805aab5e470@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=156db214900000
kernel config: https://syzkaller.appspot.com/x/.config?x=a1b8ff4a33e73cad
dashboard link: https://syzkaller.appspot.com/bug?extid=59ef240dd8f0ed7598a8
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=100102a4900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172fcacc900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+59ef240dd8f0ed7598a8@syzkaller.appspotmail.com
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff888128d25800 (size 1024):
comm "syz-executor493", pid 6464, jiffies 4294944570 (age 14.450s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000ee9fd51f>] kmalloc_array include/linux/slab.h:597 [inline]
[<00000000ee9fd51f>] kcalloc include/linux/slab.h:608 [inline]
[<00000000ee9fd51f>] veth_alloc_queues drivers/net/veth.c:1018 [inline]
[<00000000ee9fd51f>] veth_dev_init+0x7b/0x120 drivers/net/veth.c:1045
[<00000000ea2b9ca8>] register_netdevice+0x143/0x760 net/core/dev.c:9444
[<0000000054f736e0>] veth_newlink+0x282/0x460 drivers/net/veth.c:1393
[<0000000048b625cf>] __rtnl_newlink+0x8f0/0xbc0 net/core/rtnetlink.c:3339
[<00000000c7111fa7>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3398
[<000000003c581d51>] rtnetlink_rcv_msg+0x17e/0x460 net/core/rtnetlink.c:5461
[<0000000044c6a9c9>] netlink_rcv_skb+0x5b/0x180 net/netlink/af_netlink.c:2469
[<00000000c5e8a749>] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
[<00000000c5e8a749>] netlink_unicast+0x2b6/0x3c0 net/netlink/af_netlink.c:1329
[<000000000417c80d>] netlink_sendmsg+0x2ba/0x570 net/netlink/af_netlink.c:1918
[<000000000bc3c36b>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<000000000bc3c36b>] sock_sendmsg+0x4c/0x60 net/socket.c:672
[<0000000041ecdda4>] ____sys_sendmsg+0x2c4/0x2f0 net/socket.c:2352
[<0000000013875e8e>] ___sys_sendmsg+0x81/0xc0 net/socket.c:2406
[<00000000ab05eaa1>] __sys_sendmsg+0x77/0xe0 net/socket.c:2439
[<00000000475b439b>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:384
[<00000000dbda4b6d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888119669c00 (size 1024):
comm "syz-executor493", pid 6496, jiffies 4294945171 (age 8.440s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000ee9fd51f>] kmalloc_array include/linux/slab.h:597 [inline]
[<00000000ee9fd51f>] kcalloc include/linux/slab.h:608 [inline]
[<00000000ee9fd51f>] veth_alloc_queues drivers/net/veth.c:1018 [inline]
[<00000000ee9fd51f>] veth_dev_init+0x7b/0x120 drivers/net/veth.c:1045
[<00000000ea2b9ca8>] register_netdevice+0x143/0x760 net/core/dev.c:9444
[<0000000054f736e0>] veth_newlink+0x282/0x460 drivers/net/veth.c:1393
[<0000000048b625cf>] __rtnl_newlink+0x8f0/0xbc0 net/core/rtnetlink.c:3339
[<00000000c7111fa7>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3398
[<000000003c581d51>] rtnetlink_rcv_msg+0x17e/0x460 net/core/rtnetlink.c:5461
[<0000000044c6a9c9>] netlink_rcv_skb+0x5b/0x180 net/netlink/af_netlink.c:2469
[<00000000c5e8a749>] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
[<00000000c5e8a749>] netlink_unicast+0x2b6/0x3c0 net/netlink/af_netlink.c:1329
[<000000000417c80d>] netlink_sendmsg+0x2ba/0x570 net/netlink/af_netlink.c:1918
[<000000000bc3c36b>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<000000000bc3c36b>] sock_sendmsg+0x4c/0x60 net/socket.c:672
[<0000000041ecdda4>] ____sys_sendmsg+0x2c4/0x2f0 net/socket.c:2352
[<0000000013875e8e>] ___sys_sendmsg+0x81/0xc0 net/socket.c:2406
[<00000000ab05eaa1>] __sys_sendmsg+0x77/0xe0 net/socket.c:2439
[<00000000475b439b>] do_syscall_64+0x4c/0xe0 arch/x86/entry/common.c:384
[<00000000dbda4b6d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* Re: [PATCH v3 3/9] net: dsa: mv88e6xxx: Use generic helper function
From: Richard Cochran @ 2020-08-02 15:18 UTC (permalink / raw)
To: Kurt Kanzenbach
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
Jakub Kicinski, Jiri Pirko, Ido Schimmel, Heiner Kallweit,
Russell King, Grygorii Strashko, Ivan Khoronzhuk, Samuel Zou,
netdev, Petr Machata
In-Reply-To: <20200730080048.32553-4-kurt@linutronix.de>
On Thu, Jul 30, 2020 at 10:00:42AM +0200, Kurt Kanzenbach wrote:
> In order to reduce code duplication between ptp drivers, generic helper
> functions were introduced. Use them.
>
> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Tested-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH v1] hostap: use generic power management
From: Kalle Valo @ 2020-08-02 15:18 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
David S. Miller, Jouni Malinen, Vaibhav Gupta, linux-wireless,
netdev, linux-kernel, linux-kernel-mentees, Shuah Khan
In-Reply-To: <20200721150547.371763-1-vaibhavgupta40@gmail.com>
Vaibhav Gupta <vaibhavgupta40@gmail.com> wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
>
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable to take the unnecessary load from the driver.
> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions as through
> the generic framework, PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
99aaa1aafa5c hostap: use generic power management
--
https://patchwork.kernel.org/patch/11675851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 2/9] ptp: Add generic ptp message type function
From: Richard Cochran @ 2020-08-02 15:18 UTC (permalink / raw)
To: Kurt Kanzenbach
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller,
Jakub Kicinski, Jiri Pirko, Ido Schimmel, Heiner Kallweit,
Russell King, Grygorii Strashko, Ivan Khoronzhuk, Samuel Zou,
netdev, Petr Machata
In-Reply-To: <20200730080048.32553-3-kurt@linutronix.de>
On Thu, Jul 30, 2020 at 10:00:41AM +0200, Kurt Kanzenbach wrote:
> The message type is located at different offsets within the ptp header depending
> on the ptp version (v1 or v2). Therefore, drivers which also deal with ptp v1
> have some code for it.
>
> Extract this into a helper function for drivers to be used.
>
> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
CodingStyle nit below...
> ---
> include/linux/ptp_classify.h | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/linux/ptp_classify.h b/include/linux/ptp_classify.h
> index 26fd38a4bd67..f4dd42fddc0c 100644
> --- a/include/linux/ptp_classify.h
> +++ b/include/linux/ptp_classify.h
> @@ -90,6 +90,30 @@ unsigned int ptp_classify_raw(const struct sk_buff *skb);
> */
> struct ptp_header *ptp_parse_header(struct sk_buff *skb, unsigned int type);
>
> +/**
> + * ptp_get_msgtype - Extract ptp message type from given header
> + * @hdr: ptp header
> + * @type: type of the packet (see ptp_classify_raw())
> + *
> + * This function returns the message type for a given ptp header. It takes care
> + * of the different ptp header versions (v1 or v2).
> + *
> + * Return: The message type
> + */
> +static inline u8 ptp_get_msgtype(const struct ptp_header *hdr,
> + unsigned int type)
> +{
> + u8 msgtype;
> +
> + if (unlikely(type & PTP_CLASS_V1))
> + /* msg type is located at the control field for ptp v1 */
> + msgtype = hdr->control;
With the comment, it looks like two statements, and so please use
if (...) {
/**/
...
} else {
...
}
here.
> + else
> + msgtype = hdr->tsmt & 0x0f;
> +
> + return msgtype;
> +}
> +
> void __init ptp_classifier_init(void);
> #else
> static inline void ptp_classifier_init(void)
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH for v5.9] b43legacy: Replace HTTP links with HTTPS ones
From: Kalle Valo @ 2020-08-02 15:17 UTC (permalink / raw)
To: Alexander A. Klimov
Cc: Larry.Finger, davem, kuba, linux-wireless, b43-dev, netdev,
linux-kernel, Alexander A. Klimov
In-Reply-To: <20200719111124.58167-1-grandmaster@al2klimov.de>
"Alexander A. Klimov" <grandmaster@al2klimov.de> wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Patch applied to wireless-drivers-next.git, thanks.
140c6026167b b43legacy: Replace HTTP links with HTTPS ones
--
https://patchwork.kernel.org/patch/11672427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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