* Re: [PATCH v3 bpf-next 05/14] samples: bpf: makefile: use __LINUX_ARM_ARCH__ selector for arm
From: Andrii Nakryiko @ 2019-09-16 20:44 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <20190916105433.11404-6-ivan.khoronzhuk@linaro.org>
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
<ivan.khoronzhuk@linaro.org> wrote:
>
> For arm, -D__LINUX_ARM_ARCH__=X is min version used as instruction
> set selector and is absolutely required while parsing some parts of
> headers. It's present in KBUILD_CFLAGS but not in autoconf.h, so let's
> retrieve it from and add to programs cflags. In another case errors
> like "SMP is not supported" for armv7 and bunch of other errors are
> issued resulting to incorrect final object.
> ---
> samples/bpf/Makefile | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 8ecc5d0c2d5b..d3c8db3df560 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -185,6 +185,16 @@ HOSTLDLIBS_map_perf_test += -lrt
> HOSTLDLIBS_test_overhead += -lrt
> HOSTLDLIBS_xdpsock += -pthread
>
> +ifeq ($(ARCH), arm)
> +# Strip all except -D__LINUX_ARM_ARCH__ option needed to handle linux
> +# headers when arm instruction set identification is requested.
> +ARM_ARCH_SELECTOR = $(shell echo "$(KBUILD_CFLAGS) " | \
> + sed 's/[[:blank:]]/\n/g' | sed '/^-D__LINUX_ARM_ARCH__/!d')
Does the following work exactly like that without shelling out (and
being arguably simpler)?
ARM_ARCH_SELECTOR = $(filter -D__LINUX_ARM_ARCH__%, $(KBUILD_CFLAGS))
> +
> +CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR)
> +KBUILD_HOSTCFLAGS := $(ARM_ARCH_SELECTOR)
Isn't this clearing out previous value of KBUILD_HOSTCFLAGS? Is that
intentional, or it was supposed to be += here?
> +endif
> +
> # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> LLC ?= llc
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v3 11/26] net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-09-16 20:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, Andrew Murray, netdev,
Jose Abreu
In-Reply-To: <20190916204158.6889-1-efremov@linux.com>
Refactor loops to use idiomatic C style and avoid the fencepost error
of using "i < PCI_STD_RESOURCE_END" when "i <= PCI_STD_RESOURCE_END"
is required, e.g., commit 2f686f1d9bee ("PCI: Correct PCI_STD_RESOURCE_END
usage").
To iterate through all possible BARs, loop conditions changed to the
*number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
valid BAR "i <= PCI_STD_RESOURCE_END".
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 386bafe74c3f..fa8604d7b797 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -34,7 +34,7 @@ static int xlgmac_probe(struct pci_dev *pcidev, const struct pci_device_id *id)
return ret;
}
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pcidev, i) == 0)
continue;
ret = pcim_iomap_regions(pcidev, BIT(i), XLGMAC_DRV_NAME);
--
2.21.0
^ permalink raw reply related
* [PATCH v3 12/26] ixgb: use PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-09-16 20:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, Andrew Murray, netdev,
Jeff Kirsher, David S. Miller
In-Reply-To: <20190916204158.6889-1-efremov@linux.com>
To iterate through all possible BARs, loop conditions refactored to the
*number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
valid BAR "i <= BAR_5". This is more idiomatic C style and allows to avoid
the fencepost error.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/intel/ixgb/ixgb.h | 1 -
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb.h b/drivers/net/ethernet/intel/ixgb/ixgb.h
index e85271b68410..681d44cc9784 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb.h
+++ b/drivers/net/ethernet/intel/ixgb/ixgb.h
@@ -42,7 +42,6 @@
#define BAR_0 0
#define BAR_1 1
-#define BAR_5 5
struct ixgb_adapter;
#include "ixgb_hw.h"
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index e5ac2d3fd816..c5bba18eb32a 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -412,7 +412,7 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_ioremap;
}
- for (i = BAR_1; i <= BAR_5; i++) {
+ for (i = BAR_1; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
--
2.21.0
^ permalink raw reply related
* [PATCH v3 13/26] e1000: Use PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-09-16 20:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, linux-kernel, linux-pci, Andrew Murray, netdev,
Jeff Kirsher, David S. Miller
In-Reply-To: <20190916204158.6889-1-efremov@linux.com>
To iterate through all possible BARs, loop conditions refactored to the
*number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
valid BAR "i <= BAR_5". This is more idiomatic C style and allows to avoid
the fencepost error.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/intel/e1000/e1000.h | 1 -
drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000.h b/drivers/net/ethernet/intel/e1000/e1000.h
index c40729b2c184..7fad2f24dcad 100644
--- a/drivers/net/ethernet/intel/e1000/e1000.h
+++ b/drivers/net/ethernet/intel/e1000/e1000.h
@@ -45,7 +45,6 @@
#define BAR_0 0
#define BAR_1 1
-#define BAR_5 5
#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index f703fa58458e..db4fd82036af 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -977,7 +977,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_ioremap;
if (adapter->need_ioport) {
- for (i = BAR_1; i <= BAR_5; i++) {
+ for (i = BAR_1; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 06/14] samples: bpf: makefile: drop unnecessarily inclusion for bpf_load
From: Andrii Nakryiko @ 2019-09-16 20:52 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <20190916105433.11404-7-ivan.khoronzhuk@linaro.org>
On Mon, Sep 16, 2019 at 4:01 AM Ivan Khoronzhuk
<ivan.khoronzhuk@linaro.org> wrote:
>
> Drop inclusion for bpf_load -I$(objtree)/usr/include as it is
> included for all objects anyway, with above line:
> KBUILD_HOSTCFLAGS += -I$(objtree)/usr/include
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
Acked-by: Andrii Nakryiko <andriin@fb.com>
> samples/bpf/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index d3c8db3df560..9d923546e087 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -176,7 +176,7 @@ KBUILD_HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
> KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib/ -I$(srctree)/tools/include
> KBUILD_HOSTCFLAGS += -I$(srctree)/tools/perf
>
> -HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
> +HOSTCFLAGS_bpf_load.o += -Wno-unused-variable
>
> KBUILD_HOSTLDLIBS += $(LIBBPF) -lelf
> HOSTLDLIBS_tracex4 += -lrt
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next 01/14] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Ivan Khoronzhuk @ 2019-09-16 21:22 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzZVTjCybmDgM0VBzv_L-LHtF8LcDyyKSWJm0ZA4jtJKcw@mail.gmail.com>
On Mon, Sep 16, 2019 at 01:13:23PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> echo should be replaced with echo -e to handle '\n' correctly, but
>> instead, replace it with printf as some systems can't handle echo -e.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 1d9be26b4edd..f50ca852c2a8 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -201,7 +201,7 @@ endif
>>
>> # Don't evaluate probes and warnings if we need to run make recursively
>> ifneq ($(src),)
>> -HDR_PROBE := $(shell echo "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
>> +HDR_PROBE := $(shell printf "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
>
>printf change is fine, but I'm confused about \# at the beginning of
>the string. Not sure what was the intent, but it seems like it should
>work with just #include at the beginning.
At least no warns, but looks like should work.
Will try it in next v.
>
>> $(HOSTCC) $(KBUILD_HOSTCFLAGS) -x c - -o /dev/null 2>/dev/null && \
>> echo okay)
>>
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 01/14] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Andreas Schwab @ 2019-09-16 21:35 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Ivan Khoronzhuk, Alexei Starovoitov, Daniel Borkmann,
Yonghong Song, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer, john fastabend, open list, Networking,
bpf, clang-built-linux, sergei.shtylyov
In-Reply-To: <CAEf4BzZVTjCybmDgM0VBzv_L-LHtF8LcDyyKSWJm0ZA4jtJKcw@mail.gmail.com>
On Sep 16 2019, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
> <ivan.khoronzhuk@linaro.org> wrote:
>>
>> echo should be replaced with echo -e to handle '\n' correctly, but
>> instead, replace it with printf as some systems can't handle echo -e.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 1d9be26b4edd..f50ca852c2a8 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -201,7 +201,7 @@ endif
>>
>> # Don't evaluate probes and warnings if we need to run make recursively
>> ifneq ($(src),)
>> -HDR_PROBE := $(shell echo "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
>> +HDR_PROBE := $(shell printf "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
>
> printf change is fine, but I'm confused about \# at the beginning of
> the string.
From the NEWS of make 4.3:
* WARNING: Backward-incompatibility!
Number signs (#) appearing inside a macro reference or function invocation
no longer introduce comments and should not be escaped with backslashes:
thus a call such as:
foo := $(shell echo '#')
is legal. Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
Now this latter will resolve to "\#". If you want to write makefiles
portable to both versions, assign the number sign to a variable:
H := \#
foo := $(shell echo '$H')
This was claimed to be fixed in 3.81, but wasn't, for some reason.
To detect this change search for 'nocomment' in the .FEATURES variable.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Bug report (with fix) for DEC Tulip driver (de2104x.c)
From: Arlie Davis @ 2019-09-16 21:50 UTC (permalink / raw)
To: netdev, linux-parisc
Hello. I'm a developer on GCE, Google's virtual machine platform. As
part of my work, we needed to emulate a DEC Tulip 2104x NIC, so I
implemented a basic virtual device for it.
While doing so, I believe I found a bug in the Linux driver for this
device, in de2104x.c. I see in MAINTAINERS that this is an orphaned
device driver, but I was wondering if the kernel would still accept a
patch for it. Should I submit this patch, and if so, where should I
submit it?
Below is the commit text from my local repo, and the patch diffs
(they're quite short).
Fix a bug in DEC Tulip driver (de2104x.c)
The DEC Tulip Ethernet controller uses a 16-byte transfer descriptor for
both its transmit (tx) and receive (rx) rings. Each descriptor has a
"status" uint32 field (called opts1 in de2104x.c, and called TDES0 /
Status in the DEC hardware specifications) and a "control" field (called
opts2 in de2104x.c and called TDES1 / Control in the DEC
specifications). In the "control" field, bit 30 is the LastSegment bit,
which indicates that this is the last transfer descriptor in a sequence
of descriptors (in case a single Ethernet frame spans more than one
descriptor).
The de2104x driver correctly sets LastSegment, in the de_start_xmit
function. (The code calls it LastFrag, not LastSegment). However, in the
interrupt handler (in function de_tx), the driver incorrectly checks for
this bit in the status field, not the control field. This means that the
driver is reading bits that are undefined in the specification; the
spec does not make any guarantees at all about the contents of bits 29
and bits 30 in the "status" field.
The effect of the bug is that the driver may think that a TX ring entry
is never finished, even though a compliant DEC Tulip hardware device (or
a virtualized device, in a VM) actually did finish sending the Ethernet
frame.
The fix is to read the correct "control" field from the TX descriptor.
DEC Tulip programming specification:
https://web.archive.org/web/20050805091751/http://www.intel.com/design/network/manuals/21140ahm.pdf
See section 4.2.2 for the specs on the transfer descriptor.
Here's my patch that fixes it:
diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c
b/drivers/net/ethernet/dec/tulip/de2104x.c
index f1a2da15dd0a..3a420ceb52e5 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -545,6 +545,7 @@ static void de_tx (struct de_private *de)
while (tx_tail != tx_head) {
struct sk_buff *skb;
u32 status;
+ u32 control;
rmb();
status = le32_to_cpu(de->tx_ring[tx_tail].opts1);
@@ -565,7 +566,8 @@ static void de_tx (struct de_private *de)
pci_unmap_single(de->pdev, de->tx_skb[tx_tail].mapping,
skb->len, PCI_DMA_TODEVICE);
- if (status & LastFrag) {
+ control = le32_to_cpu(de->tx_ring[tx_tail].opts2);
+ if (control & LastFrag) {
if (status & TxError) {
netif_dbg(de, tx_err, de->dev,
"tx err, status 0x%x\n",
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 04/14] samples: bpf: use own EXTRA_CFLAGS for clang commands
From: Ivan Khoronzhuk @ 2019-09-16 22:01 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYJ5Q4rBHGET5z6nPBhh=8qAK7uuCK=Qnsh14FDH-24gA@mail.gmail.com>
On Mon, Sep 16, 2019 at 01:35:21PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 4:01 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> It can overlap with CFLAGS used for libraries built with gcc if
>> not now then in next patches. Correct it here for simplicity.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>
>With GCC BPF front-end recently added, we should probably generalize
>this to something like BPF_EXTRA_CFLAGS or something like that,
>eventually. But for now:
>
>Acked-by: Andrii Nakryiko <andriin@fb.com>
I can replace with BPF_EXTRA_CFLAGS in next v.
>
>> samples/bpf/Makefile | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index b59e77e2250e..8ecc5d0c2d5b 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -218,10 +218,10 @@ BTF_LLVM_PROBE := $(shell echo "int main() { return 0; }" | \
>> /bin/rm -f ./llvm_btf_verify.o)
>>
>> ifneq ($(BTF_LLVM_PROBE),)
>> - EXTRA_CFLAGS += -g
>> + CLANG_EXTRA_CFLAGS += -g
>> else
>> ifneq ($(and $(BTF_LLC_PROBE),$(BTF_PAHOLE_PROBE),$(BTF_OBJCOPY_PROBE)),)
>> - EXTRA_CFLAGS += -g
>> + CLANG_EXTRA_CFLAGS += -g
>> LLC_FLAGS += -mattr=dwarfris
>> DWARF2BTF = y
>> endif
>> @@ -280,8 +280,8 @@ $(obj)/hbm_edt_kern.o: $(src)/hbm.h $(src)/hbm_kern.h
>> # useless for BPF samples.
>> $(obj)/%.o: $(src)/%.c
>> @echo " CLANG-bpf " $@
>> - $(Q)$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
>> - -I$(srctree)/tools/testing/selftests/bpf/ \
>> + $(Q)$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(CLANG_EXTRA_CFLAGS) \
>> + -I$(obj) -I$(srctree)/tools/testing/selftests/bpf/ \
>> -D__KERNEL__ -D__BPF_TRACING__ -Wno-unused-value -Wno-pointer-sign \
>> -D__TARGET_ARCH_$(SRCARCH) -Wno-compare-distinct-pointer-types \
>> -Wno-gnu-variable-sized-type-not-at-end \
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 01/14] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Andrii Nakryiko @ 2019-09-16 22:01 UTC (permalink / raw)
To: Andreas Schwab
Cc: Ivan Khoronzhuk, Alexei Starovoitov, Daniel Borkmann,
Yonghong Song, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer, john fastabend, open list, Networking,
bpf, clang-built-linux, sergei.shtylyov
In-Reply-To: <8736gvexfz.fsf@igel.home>
On Mon, Sep 16, 2019 at 2:35 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Sep 16 2019, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> > On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
> > <ivan.khoronzhuk@linaro.org> wrote:
> >>
> >> echo should be replaced with echo -e to handle '\n' correctly, but
> >> instead, replace it with printf as some systems can't handle echo -e.
> >>
> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> >> ---
> >> samples/bpf/Makefile | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> >> index 1d9be26b4edd..f50ca852c2a8 100644
> >> --- a/samples/bpf/Makefile
> >> +++ b/samples/bpf/Makefile
> >> @@ -201,7 +201,7 @@ endif
> >>
> >> # Don't evaluate probes and warnings if we need to run make recursively
> >> ifneq ($(src),)
> >> -HDR_PROBE := $(shell echo "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
> >> +HDR_PROBE := $(shell printf "\#include <linux/types.h>\n struct list_head { int a; }; int main() { return 0; }" | \
> >
> > printf change is fine, but I'm confused about \# at the beginning of
> > the string.
>
> From the NEWS of make 4.3:
>
> * WARNING: Backward-incompatibility!
> Number signs (#) appearing inside a macro reference or function invocation
> no longer introduce comments and should not be escaped with backslashes:
> thus a call such as:
> foo := $(shell echo '#')
> is legal. Previously the number sign needed to be escaped, for example:
> foo := $(shell echo '\#')
> Now this latter will resolve to "\#". If you want to write makefiles
> portable to both versions, assign the number sign to a variable:
> H := \#
> foo := $(shell echo '$H')
> This was claimed to be fixed in 3.81, but wasn't, for some reason.
> To detect this change search for 'nocomment' in the .FEATURES variable.
>
> Andreas.
Oh, subtle... Thanks for explaining!
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply
* Re: [PATCH v3 bpf-next 05/14] samples: bpf: makefile: use __LINUX_ARM_ARCH__ selector for arm
From: Ivan Khoronzhuk @ 2019-09-16 22:04 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYpCGHxNG-jOjwx5a2NXbvLW4gZH8GD2p7E27v9K3ookg@mail.gmail.com>
On Mon, Sep 16, 2019 at 01:44:23PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> For arm, -D__LINUX_ARM_ARCH__=X is min version used as instruction
>> set selector and is absolutely required while parsing some parts of
>> headers. It's present in KBUILD_CFLAGS but not in autoconf.h, so let's
>> retrieve it from and add to programs cflags. In another case errors
>> like "SMP is not supported" for armv7 and bunch of other errors are
>> issued resulting to incorrect final object.
>> ---
>> samples/bpf/Makefile | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 8ecc5d0c2d5b..d3c8db3df560 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -185,6 +185,16 @@ HOSTLDLIBS_map_perf_test += -lrt
>> HOSTLDLIBS_test_overhead += -lrt
>> HOSTLDLIBS_xdpsock += -pthread
>>
>> +ifeq ($(ARCH), arm)
>> +# Strip all except -D__LINUX_ARM_ARCH__ option needed to handle linux
>> +# headers when arm instruction set identification is requested.
>> +ARM_ARCH_SELECTOR = $(shell echo "$(KBUILD_CFLAGS) " | \
>> + sed 's/[[:blank:]]/\n/g' | sed '/^-D__LINUX_ARM_ARCH__/!d')
>
>Does the following work exactly like that without shelling out (and
>being arguably simpler)?
>
>ARM_ARCH_SELECTOR = $(filter -D__LINUX_ARM_ARCH__%, $(KBUILD_CFLAGS))
>
>> +
>> +CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR)
>> +KBUILD_HOSTCFLAGS := $(ARM_ARCH_SELECTOR)
>
>Isn't this clearing out previous value of KBUILD_HOSTCFLAGS? Is that
>intentional, or it was supposed to be += here?
>
>> +endif
>> +
>> # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
>> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
>> LLC ?= llc
>> --
>> 2.17.1
>>
Just left from previous version filtering all -D options.
Will update in next v., SELECTOR also.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH bpf] bpf: respect CAP_IPC_LOCK in RLIMIT_MEMLOCK check
From: Alexei Starovoitov @ 2019-09-16 22:19 UTC (permalink / raw)
To: Christian Barcenas
Cc: Daniel Borkmann, Alexei Starovoitov, netdev, Martin KaFai Lau,
Song Liu, Yonghong Song, bpf
In-Reply-To: <4f8b455e-aa11-1552-c7f1-06ff63d86542@cbarcenas.com>
On Mon, Sep 16, 2019 at 07:09:06AM -0700, Christian Barcenas wrote:
>
> bpf() is currently the only exception to the above, ie. as far as I can tell
> it is the only code that enforces RLIMIT_MEMLOCK but does not honor
> CAP_IPC_LOCK.
Yes. bpf is not honoring CAP_IPC_LOCK comparing to other places in the kernel,
but we cannot change this anymore. User space already using rlimit as an enforcement.
bpf_rlimit.h hack we use in selftests is not a universal way of loading bpf progs.
If we make such change root user will become unlimited and rlimit enforcement
will break.
^ permalink raw reply
* BUG: sleeping function called from invalid context in tcf_chain0_head_change_cb_del
From: syzbot @ 2019-09-16 23:39 UTC (permalink / raw)
To: ast, daniel, davem, dsahern, f.fainelli, hawk, idosch,
jakub.kicinski, jhs, jiri, jiri, john.fastabend, kafai,
linux-kernel, netdev, nikolay, petrm, roopa, songliubraving,
syzkaller-bugs, vladbu, xdp-newbies, xiyou.wangcong, yhs
Hello,
syzbot found the following crash on:
HEAD commit: 1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe600000
kernel config: https://syzkaller.appspot.com/x/.config?x=ed2b148cd67382ec
dashboard link: https://syzkaller.appspot.com/bug?extid=ac54455281db908c581e
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116c4b11600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ff270d600000
The bug was bisected to:
commit c266f64dbfa2a970a13b0574246c0ddfec492365
Author: Vlad Buslov <vladbu@mellanox.com>
Date: Mon Feb 11 08:55:32 2019 +0000
net: sched: protect block state with mutex
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e7ca65600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=15e7ca65600000
console output: https://syzkaller.appspot.com/x/log.txt?x=11e7ca65600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ac54455281db908c581e@syzkaller.appspotmail.com
Fixes: c266f64dbfa2 ("net: sched: protect block state with mutex")
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:909
in_atomic(): 1, irqs_disabled(): 0, pid: 9297, name: syz-executor942
INFO: lockdep is turned off.
Preemption disabled at:
[<ffffffff8604de24>] spin_lock_bh include/linux/spinlock.h:343 [inline]
[<ffffffff8604de24>] sch_tree_lock include/net/sch_generic.h:570 [inline]
[<ffffffff8604de24>] sfb_change+0x284/0xd30 net/sched/sch_sfb.c:519
CPU: 0 PID: 9297 Comm: syz-executor942 Not tainted 5.3.0-rc8+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
___might_sleep+0x3ff/0x530 kernel/sched/core.c:6608
__might_sleep+0x8f/0x100 kernel/sched/core.c:6561
__mutex_lock_common+0x4e/0x2820 kernel/locking/mutex.c:909
__mutex_lock kernel/locking/mutex.c:1077 [inline]
mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1092
tcf_chain0_head_change_cb_del+0x30/0x390 net/sched/cls_api.c:932
tcf_block_put_ext+0x3d/0x2a0 net/sched/cls_api.c:1502
tcf_block_put+0x6e/0x90 net/sched/cls_api.c:1515
sfb_destroy+0x47/0x70 net/sched/sch_sfb.c:467
qdisc_destroy+0x147/0x4d0 net/sched/sch_generic.c:968
qdisc_put+0x58/0x90 net/sched/sch_generic.c:992
sfb_change+0x52d/0xd30 net/sched/sch_sfb.c:522
qdisc_change net/sched/sch_api.c:1321 [inline]
tc_modify_qdisc+0x184d/0x1ea0 net/sched/sch_api.c:1623
rtnetlink_rcv_msg+0x889/0xd40 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x19e/0x3d0 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x787/0x900 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x993/0xc50 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg net/socket.c:657 [inline]
___sys_sendmsg+0x60d/0x910 net/socket.c:2311
__sys_sendmsg net/socket.c:2356 [inline]
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x17c/0x200 net/socket.c:2363
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447509
Code: e8 5c 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 ab 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f49d6c94db8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000006dcc78 RCX: 0000000000447509
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000007
RBP: 00000000006dcc70 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000246 R12: 00000000006dcc7c
R13: 00007ffc5c2e9dff R14: 00007f49d6c959c0 R15: 000000000000002d
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH v3] net: mdio: switch to using gpiod_get_optional()
From: Dmitry Torokhov @ 2019-09-17 0:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: David S. Miller, Linus Walleij, Andy Shevchenko, netdev,
linux-kernel
The MDIO device reset line is optional and now that gpiod_get_optional()
returns proper value when GPIO support is compiled out, there is no
reason to use fwnode_get_named_gpiod() that I plan to hide away.
Let's switch to using more standard gpiod_get_optional() and
gpiod_set_consumer_name() to keep the nice "PHY reset" label.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
v2 -> v3:
- no longer check for NULL before calling gpiod_set_consumer_name()
as it handles NULL descriptors
- added Andy S's reviewed-by
- did NOT add Andrew's reviewed-by as I am unsure if he's OK with the
latest iteration.
drivers/net/phy/mdio_bus.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index ce940871331e..88c6ef7c7b13 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -42,22 +42,16 @@
static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
{
- struct gpio_desc *gpiod = NULL;
+ int error;
/* Deassert the optional reset signal */
- if (mdiodev->dev.of_node)
- gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
- "reset-gpios", 0, GPIOD_OUT_LOW,
- "PHY reset");
- if (IS_ERR(gpiod)) {
- if (PTR_ERR(gpiod) == -ENOENT || PTR_ERR(gpiod) == -ENOSYS)
- gpiod = NULL;
- else
- return PTR_ERR(gpiod);
- }
-
- mdiodev->reset_gpio = gpiod;
+ mdiodev->reset_gpio = gpiod_get_optional(&mdiodev->dev,
+ "reset", GPIOD_OUT_LOW);
+ error = PTR_ERR_OR_ZERO(mdiodev->reset_gpio);
+ if (error)
+ return error;
+ gpiod_set_consumer_name(mdiodev->reset_gpio, "PHY reset");
return 0;
}
--
2.23.0.237.gc6a4ce50a0-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH 00/11] Add support for software nodes to gpiolib
From: Dmitry Torokhov @ 2019-09-17 0:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Mika Westerberg, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Andrew Lunn, Andrzej Hajda,
Bartosz Golaszewski, Daniel Vetter, David Airlie, David S. Miller,
Florian Fainelli, Heiner Kallweit, Jernej Skrabec, Jonas Karlman,
Laurent Pinchart, Neil Armstrong, Russell King,
open list:DRM PANEL DRIVERS, ACPI Devel Maling List, netdev
In-Reply-To: <CACRpkdb=s67w2DCGubhbLQTtxpWtiW8S1MECMO4cvec=bF6OdA@mail.gmail.com>
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
> On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>
> > If we agree in principle, I would like to have the very first 3 patches
> > in an immutable branch off maybe -rc8 so that it can be pulled into
> > individual subsystems so that patches switching various drivers to
> > fwnode_gpiod_get_index() could be applied.
>
> I think it seems a bit enthusiastic to have non-GPIO subsystems
> pick up these changes this close to the merge window so my plan
> is to merge patches 1.2.3 (1 already merged) and then you could
> massage the other subsystems in v5.4-rc1.
>
> But if other subsystems say "hey we want do fix this in like 3 days"
> then I'm game for an immutable branch as well.
No, if it is still has a chance for -rc1 then I'm good. I was thinking
if it does not go into -rc1 I could convince some of them merge a
targeted immutable branch off -rc8 or 5.3 final and then apply patches
relevant to their subsystems so we do not have to wait till 5.6 to land
everything.
Thanks.
--
Dmitry
^ permalink raw reply
* [RFC v4 1/3] vfio: support getting vfio device from device fd
From: Tiwei Bie @ 2019-09-17 1:02 UTC (permalink / raw)
To: mst, jasowang, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu, tiwei.bie
In-Reply-To: <20190917010204.30376-1-tiwei.bie@intel.com>
This patch introduces the support for getting VFIO device
from VFIO device fd. With this support, it's possible for
vhost to get VFIO device from the group fd and device fd
set by the userspace.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
drivers/vfio/vfio.c | 25 +++++++++++++++++++++++++
include/linux/vfio.h | 4 ++++
2 files changed, 29 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 388597930b64..697fd079bb3f 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -890,6 +890,31 @@ static struct vfio_device *vfio_device_get_from_name(struct vfio_group *group,
return device;
}
+struct vfio_device *vfio_device_get_from_fd(struct vfio_group *group,
+ int device_fd)
+{
+ struct fd f;
+ struct vfio_device *it, *device = ERR_PTR(-ENODEV);
+
+ f = fdget(device_fd);
+ if (!f.file)
+ return ERR_PTR(-EBADF);
+
+ mutex_lock(&group->device_lock);
+ list_for_each_entry(it, &group->device_list, group_next) {
+ if (it == f.file->private_data) {
+ device = it;
+ vfio_device_get(device);
+ break;
+ }
+ }
+ mutex_unlock(&group->device_lock);
+
+ fdput(f);
+ return device;
+}
+EXPORT_SYMBOL_GPL(vfio_device_get_from_fd);
+
/*
* Caller must hold a reference to the vfio_device
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e42a711a2800..e75b24fd7c5c 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -15,6 +15,8 @@
#include <linux/poll.h>
#include <uapi/linux/vfio.h>
+struct vfio_group;
+
/**
* struct vfio_device_ops - VFIO bus driver device callbacks
*
@@ -50,6 +52,8 @@ extern int vfio_add_group_dev(struct device *dev,
extern void *vfio_del_group_dev(struct device *dev);
extern struct vfio_device *vfio_device_get_from_dev(struct device *dev);
+extern struct vfio_device *vfio_device_get_from_fd(struct vfio_group *group,
+ int device_fd);
extern void vfio_device_put(struct vfio_device *device);
extern void *vfio_device_data(struct vfio_device *device);
--
2.17.1
^ permalink raw reply related
* [RFC v4 2/3] vfio: support checking vfio driver by device ops
From: Tiwei Bie @ 2019-09-17 1:02 UTC (permalink / raw)
To: mst, jasowang, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu, tiwei.bie
In-Reply-To: <20190917010204.30376-1-tiwei.bie@intel.com>
This patch introduces the support for checking the VFIO driver
by device ops. And vfio-mdev's device ops is also exported to
make it possible to check whether a VFIO device is based on a
mdev device.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
drivers/vfio/mdev/vfio_mdev.c | 3 ++-
drivers/vfio/vfio.c | 7 +++++++
include/linux/vfio.h | 7 +++++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 30964a4e0a28..e0f31c5a5db2 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -98,7 +98,7 @@ static int vfio_mdev_mmap(void *device_data, struct vm_area_struct *vma)
return parent->ops->mmap(mdev, vma);
}
-static const struct vfio_device_ops vfio_mdev_dev_ops = {
+const struct vfio_device_ops vfio_mdev_dev_ops = {
.name = "vfio-mdev",
.open = vfio_mdev_open,
.release = vfio_mdev_release,
@@ -107,6 +107,7 @@ static const struct vfio_device_ops vfio_mdev_dev_ops = {
.write = vfio_mdev_write,
.mmap = vfio_mdev_mmap,
};
+EXPORT_SYMBOL_GPL(vfio_mdev_dev_ops);
static int vfio_mdev_probe(struct device *dev)
{
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 697fd079bb3f..1145110909e4 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1806,6 +1806,13 @@ long vfio_external_check_extension(struct vfio_group *group, unsigned long arg)
}
EXPORT_SYMBOL_GPL(vfio_external_check_extension);
+bool vfio_device_ops_match(struct vfio_device *device,
+ const struct vfio_device_ops *ops)
+{
+ return device->ops == ops;
+}
+EXPORT_SYMBOL_GPL(vfio_device_ops_match);
+
/**
* Sub-module support
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e75b24fd7c5c..741c5bb567a8 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -56,6 +56,8 @@ extern struct vfio_device *vfio_device_get_from_fd(struct vfio_group *group,
int device_fd);
extern void vfio_device_put(struct vfio_device *device);
extern void *vfio_device_data(struct vfio_device *device);
+extern bool vfio_device_ops_match(struct vfio_device *device,
+ const struct vfio_device_ops *ops);
/**
* struct vfio_iommu_driver_ops - VFIO IOMMU driver callbacks
@@ -199,4 +201,9 @@ extern int vfio_virqfd_enable(void *opaque,
void *data, struct virqfd **pvirqfd, int fd);
extern void vfio_virqfd_disable(struct virqfd **pvirqfd);
+/*
+ * VFIO device ops
+ */
+extern const struct vfio_device_ops vfio_mdev_dev_ops;
+
#endif /* VFIO_H */
--
2.17.1
^ permalink raw reply related
* [RFC v4 0/3] vhost: introduce mdev based hardware backend
From: Tiwei Bie @ 2019-09-17 1:02 UTC (permalink / raw)
To: mst, jasowang, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu, tiwei.bie
This RFC is to demonstrate below ideas,
a) Build vhost-mdev on top of the same abstraction defined in
the virtio-mdev series [1];
b) Introduce /dev/vhost-mdev to do vhost ioctls and support
setting mdev device as backend;
Now the userspace API looks like this:
- Userspace generates a compatible mdev device;
- Userspace opens this mdev device with VFIO API (including
doing IOMMU programming for this mdev device with VFIO's
container/group based interface);
- Userspace opens /dev/vhost-mdev and gets vhost fd;
- Userspace uses vhost ioctls to setup vhost (userspace should
do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device
fd first before doing other vhost ioctls);
Only compile test has been done for this series for now.
RFCv3: https://patchwork.kernel.org/patch/11117785/
[1] https://lkml.org/lkml/2019/9/10/135
Tiwei Bie (3):
vfio: support getting vfio device from device fd
vfio: support checking vfio driver by device ops
vhost: introduce mdev based hardware backend
drivers/vfio/mdev/vfio_mdev.c | 3 +-
drivers/vfio/vfio.c | 32 +++
drivers/vhost/Kconfig | 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
drivers/vhost/vhost.c | 39 ++-
drivers/vhost/vhost.h | 6 +
include/linux/vfio.h | 11 +
include/uapi/linux/vhost.h | 10 +
include/uapi/linux/vhost_types.h | 5 +
10 files changed, 573 insertions(+), 7 deletions(-)
create mode 100644 drivers/vhost/mdev.c
--
2.17.1
^ permalink raw reply
* [RFC v4 3/3] vhost: introduce mdev based hardware backend
From: Tiwei Bie @ 2019-09-17 1:02 UTC (permalink / raw)
To: mst, jasowang, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu, tiwei.bie
In-Reply-To: <20190917010204.30376-1-tiwei.bie@intel.com>
More details about this patch can be found from the cover
letter for now. Only compile test has been done for now.
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
drivers/vhost/Kconfig | 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
drivers/vhost/vhost.c | 39 ++-
drivers/vhost/vhost.h | 6 +
include/uapi/linux/vhost.h | 10 +
include/uapi/linux/vhost_types.h | 5 +
7 files changed, 528 insertions(+), 6 deletions(-)
create mode 100644 drivers/vhost/mdev.c
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 3d03ccbd1adc..ef9783156d2e 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -34,6 +34,15 @@ config VHOST_VSOCK
To compile this driver as a module, choose M here: the module will be called
vhost_vsock.
+config VHOST_MDEV
+ tristate "Mediated device based hardware vhost accelerator"
+ depends on EVENTFD && VFIO && VFIO_MDEV
+ select VHOST
+ default n
+ ---help---
+ Say Y here to enable the vhost_mdev module
+ for use with hardware vhost accelerators
+
config VHOST
tristate
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 6c6df24f770c..ad9c0f8c6d8c 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
obj-$(CONFIG_VHOST_RING) += vringh.o
+obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
+vhost_mdev-y := mdev.o
+
obj-$(CONFIG_VHOST) += vhost.o
diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
new file mode 100644
index 000000000000..8c6597aff45e
--- /dev/null
+++ b/drivers/vhost/mdev.c
@@ -0,0 +1,462 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2019 Intel Corporation.
+ */
+
+#include <linux/compat.h>
+#include <linux/kernel.h>
+#include <linux/miscdevice.h>
+#include <linux/mdev.h>
+#include <linux/module.h>
+#include <linux/vfio.h>
+#include <linux/vhost.h>
+#include <linux/virtio_mdev.h>
+
+#include "vhost.h"
+
+struct vhost_mdev {
+ struct mutex mutex;
+ struct vhost_dev dev;
+ struct vhost_virtqueue *vqs;
+ int nvqs;
+ u64 state;
+ u64 features;
+ u64 acked_features;
+ struct vfio_group *vfio_group;
+ struct vfio_device *vfio_device;
+ struct mdev_device *mdev;
+};
+
+/*
+ * XXX
+ * We assume virtio_mdev.ko exposes below symbols for now, as we
+ * don't have a proper way to access parent ops directly yet.
+ *
+ * virtio_mdev_readl()
+ * virtio_mdev_writel()
+ */
+extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off);
+extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32 val);
+
+static u8 mdev_get_status(struct mdev_device *mdev)
+{
+ return virtio_mdev_readl(mdev, VIRTIO_MDEV_STATUS);
+}
+
+static void mdev_set_status(struct mdev_device *mdev, u8 status)
+{
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_STATUS, status);
+}
+
+static void mdev_add_status(struct mdev_device *mdev, u8 status)
+{
+ status |= mdev_get_status(mdev);
+ mdev_set_status(mdev, status);
+}
+
+static void mdev_reset(struct mdev_device *mdev)
+{
+ mdev_set_status(mdev, 0);
+}
+
+static void handle_vq_kick(struct vhost_work *work)
+{
+ struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
+ poll.work);
+ struct vhost_mdev *m = container_of(vq->dev, struct vhost_mdev, dev);
+
+ virtio_mdev_writel(m->mdev, VIRTIO_MDEV_QUEUE_NOTIFY, vq - m->vqs);
+}
+
+static long vhost_mdev_start_backend(struct vhost_mdev *m)
+{
+ struct mdev_device *mdev = m->mdev;
+ u64 features = m->acked_features;
+ u64 addr;
+ struct vhost_virtqueue *vq;
+ int queue_id;
+
+ features |= 1ULL << VIRTIO_F_IOMMU_PLATFORM;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 1);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
+ (u32)(features >> 32));
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 0);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
+ (u32)features);
+
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_FEATURES_OK);
+ if (!(mdev_get_status(mdev) & VIRTIO_CONFIG_S_FEATURES_OK))
+ return -ENODEV;
+
+ for (queue_id = 0; queue_id < m->nvqs; queue_id++) {
+ vq = &m->vqs[queue_id];
+
+ if (!vq->desc || !vq->avail || !vq->used)
+ break;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_NUM, vq->num);
+
+ if (!vhost_translate_ring_addr(vq, (u64)vq->desc,
+ vhost_get_desc_size(vq, vq->num),
+ &addr))
+ return -EINVAL;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, addr);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_HIGH,
+ (addr >> 32));
+
+ if (!vhost_translate_ring_addr(vq, (u64)vq->avail,
+ vhost_get_avail_size(vq, vq->num),
+ &addr))
+ return -EINVAL;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_AVAIL_LOW, addr);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_AVAIL_HIGH,
+ (addr >> 32));
+
+ if (!vhost_translate_ring_addr(vq, (u64)vq->used,
+ vhost_get_used_size(vq, vq->num),
+ &addr))
+ return -EINVAL;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_USED_LOW, addr);
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_USED_HIGH,
+ (addr >> 32));
+
+ // XXX: we need to support set_vring_base
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_READY, 1);
+ }
+
+ // XXX: we need to setup interrupt as well
+
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER_OK);
+ return 0;
+}
+
+static long vhost_mdev_stop_backend(struct vhost_mdev *m)
+{
+ struct mdev_device *mdev = m->mdev;
+
+ mdev_reset(mdev);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER);
+ return 0;
+}
+
+static long vhost_set_state(struct vhost_mdev *m, u64 __user *statep)
+{
+ u64 state;
+ long r;
+
+ if (copy_from_user(&state, statep, sizeof(state)))
+ return -EFAULT;
+
+ if (state >= VHOST_MDEV_S_MAX)
+ return -EINVAL;
+
+ if (m->state == state)
+ return 0;
+
+ m->state = state;
+
+ switch (m->state) {
+ case VHOST_MDEV_S_RUNNING:
+ r = vhost_mdev_start_backend(m);
+ break;
+ case VHOST_MDEV_S_STOPPED:
+ r = vhost_mdev_stop_backend(m);
+ break;
+ default:
+ r = -EINVAL;
+ break;
+ }
+
+ return r;
+}
+
+static long vhost_get_features(struct vhost_mdev *m, u64 __user *featurep)
+{
+ if (copy_to_user(featurep, &m->features, sizeof(m->features)))
+ return -EFAULT;
+ return 0;
+}
+
+static long vhost_set_features(struct vhost_mdev *m, u64 __user *featurep)
+{
+ u64 features;
+
+ if (copy_from_user(&features, featurep, sizeof(features)))
+ return -EFAULT;
+
+ if (features & ~m->features)
+ return -EINVAL;
+
+ m->acked_features = features;
+
+ return 0;
+}
+
+static long vhost_get_vring_base(struct vhost_mdev *m, void __user *argp)
+{
+ struct vhost_virtqueue *vq;
+ u32 idx;
+ long r;
+
+ r = get_user(idx, (u32 __user *)argp);
+ if (r < 0)
+ return r;
+ if (idx >= m->nvqs)
+ return -ENOBUFS;
+
+ vq = &m->vqs[idx];
+
+ // XXX: we need to support get_vring_base
+ //vq->last_avail_idx = virtio_mdev_readl(b->mdev, ...);
+
+ return vhost_vring_ioctl(&m->dev, VHOST_GET_VRING_BASE, argp);
+}
+
+static void vhost_mdev_release_backend(struct vhost_mdev *m)
+{
+ if (!m->mdev)
+ return;
+
+ if (m->state != VHOST_MDEV_S_STOPPED) {
+ m->state = VHOST_MDEV_S_STOPPED;
+ vhost_mdev_stop_backend(m);
+ }
+
+ vhost_dev_stop(&m->dev);
+ vhost_dev_cleanup(&m->dev);
+
+ kfree(m->dev.vqs);
+ kfree(m->vqs);
+
+ vfio_device_put(m->vfio_device);
+ vfio_group_put_external_user(m->vfio_group);
+
+ m->mdev = NULL;
+}
+
+static long vhost_mdev_set_backend(struct vhost_mdev *m,
+ struct vhost_mdev_backend __user *argp)
+{
+ struct vhost_mdev_backend backend;
+ struct mdev_device *mdev;
+ struct vhost_dev *dev;
+ struct vhost_virtqueue **vqs;
+ struct file *file;
+ struct vfio_device *device;
+ struct vfio_group *group;
+ unsigned long magic;
+ u64 features;
+ int i, nvqs;
+ long r;
+
+ vhost_mdev_release_backend(m);
+
+ if (copy_from_user(&backend, argp, sizeof(backend))) {
+ r = -EFAULT;
+ goto err;
+ }
+
+ file = fget(backend.group_fd);
+ if (!file) {
+ r = -EBADF;
+ goto err;
+ }
+
+ group = vfio_group_get_external_user(file);
+ fput(file);
+ if (IS_ERR(group)) {
+ r = PTR_ERR(group);
+ goto err;
+ }
+
+ device = vfio_device_get_from_fd(group, backend.device_fd);
+ if (!IS_ERR(device)) {
+ r = PTR_ERR(device);
+ goto err_put_group;
+ }
+
+ if (!vfio_device_ops_match(device, &vfio_mdev_dev_ops)) {
+ r = -EINVAL;
+ goto err_put_device;
+ }
+
+ mdev = vfio_device_data(m->vfio_device);
+
+ magic = virtio_mdev_readl(mdev, VIRTIO_MDEV_MAGIC_VALUE);
+ if (magic != ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)) {
+ r = -ENODEV;
+ goto err_put_device;
+ }
+
+ mdev_reset(mdev);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
+ mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER);
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DEVICE_FEATURES_SEL, 1);
+ features = virtio_mdev_readl(mdev, VIRTIO_MDEV_DEVICE_FEATURES);
+ features <<= 32;
+
+ virtio_mdev_writel(mdev, VIRTIO_MDEV_DEVICE_FEATURES_SEL, 0);
+ features |= virtio_mdev_readl(mdev, VIRTIO_MDEV_DEVICE_FEATURES);
+
+ if (!(features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))) {
+ r = -EINVAL;
+ goto err_put_device;
+ }
+
+ m->features = features;
+
+ nvqs = virtio_mdev_readl(mdev, VIRTIO_MDEV_QUEUE_NUM_MAX);
+ m->nvqs = nvqs;
+
+ m->vqs = kmalloc_array(nvqs, sizeof(struct vhost_virtqueue),
+ GFP_KERNEL);
+ if (!m->vqs) {
+ r = -ENOMEM;
+ goto err_put_device;
+ }
+
+ vqs = kmalloc_array(nvqs, sizeof(*vqs), GFP_KERNEL);
+ if (!vqs) {
+ r = -ENOMEM;
+ goto err_free_vqs;
+ }
+
+ dev = &m->dev;
+ for (i = 0; i < nvqs; i++) {
+ vqs[i] = &m->vqs[i];
+ vqs[i]->handle_kick = handle_vq_kick;
+ }
+ vhost_dev_init(dev, vqs, nvqs, 0, 0, 0);
+
+ m->vfio_group = group;
+ m->vfio_device = device;
+ m->mdev = mdev;
+
+ return 0;
+
+err_free_vqs:
+ kfree(m->vqs);
+err_put_device:
+ vfio_device_put(device);
+err_put_group:
+ vfio_group_put_external_user(group);
+err:
+ return r;
+}
+
+static int vhost_mdev_open(struct inode *inode, struct file *f)
+{
+ struct vhost_mdev *m;
+
+ m = kzalloc(sizeof(*m), GFP_KERNEL | __GFP_RETRY_MAYFAIL);
+ if (!m)
+ return -ENOMEM;
+
+ mutex_init(&m->mutex);
+ f->private_data = m;
+
+ return 0;
+}
+
+static int vhost_mdev_release(struct inode *inode, struct file *f)
+{
+ struct vhost_mdev *m = f->private_data;
+
+ vhost_mdev_release_backend(m);
+ mutex_destroy(&m->mutex);
+ kfree(m);
+
+ return 0;
+}
+
+static long vhost_mdev_ioctl(struct file *f, unsigned int cmd,
+ unsigned long arg)
+{
+ void __user *argp = (void __user *)arg;
+ struct vhost_mdev *m = f->private_data;
+ long r;
+
+ mutex_lock(&m->mutex);
+
+ if (cmd == VHOST_MDEV_SET_BACKEND) {
+ r = vhost_mdev_set_backend(m, argp);
+ goto done;
+ }
+
+ if (!m->mdev) {
+ r = -EINVAL;
+ goto done;
+ }
+
+ switch (cmd) {
+ case VHOST_MDEV_SET_STATE:
+ r = vhost_set_state(m, argp);
+ break;
+ case VHOST_GET_FEATURES:
+ r = vhost_get_features(m, argp);
+ break;
+ case VHOST_SET_FEATURES:
+ r = vhost_set_features(m, argp);
+ break;
+ case VHOST_GET_VRING_BASE:
+ r = vhost_get_vring_base(m, argp);
+ break;
+ default:
+ r = vhost_dev_ioctl(&m->dev, cmd, argp);
+ if (r == -ENOIOCTLCMD)
+ r = vhost_vring_ioctl(&m->dev, cmd, argp);
+ }
+
+done:
+ mutex_lock(&m->mutex);
+ return r;
+}
+
+#ifdef CONFIG_COMPAT
+static long vhost_mdev_compat_ioctl(struct file *f, unsigned int ioctl,
+ unsigned long arg)
+{
+ return vhost_mdev_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
+}
+#endif
+
+static const struct file_operations vhost_mdev_fops = {
+ .owner = THIS_MODULE,
+ .release = vhost_mdev_release,
+ .unlocked_ioctl = vhost_mdev_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = vhost_mdev_compat_ioctl,
+#endif
+ .open = vhost_mdev_open,
+ .llseek = noop_llseek,
+};
+
+static struct miscdevice vhost_mdev_misc = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "vhost-mdev",
+ .fops = &vhost_mdev_fops,
+};
+
+static int __init vhost_mdev_init(void)
+{
+ return misc_register(&vhost_mdev_misc);
+}
+module_init(vhost_mdev_init);
+
+static void __exit vhost_mdev_exit(void)
+{
+ misc_deregister(&vhost_mdev_misc);
+}
+module_exit(vhost_mdev_exit);
+
+MODULE_VERSION("0.0.0");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Hardware vhost accelerator abstraction");
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5dc174ac8cac..0f7236a17a56 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -426,8 +426,7 @@ bool vhost_exceeds_weight(struct vhost_virtqueue *vq,
}
EXPORT_SYMBOL_GPL(vhost_exceeds_weight);
-static size_t vhost_get_avail_size(struct vhost_virtqueue *vq,
- unsigned int num)
+size_t vhost_get_avail_size(struct vhost_virtqueue *vq, unsigned int num)
{
size_t event __maybe_unused =
vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
@@ -435,9 +434,9 @@ static size_t vhost_get_avail_size(struct vhost_virtqueue *vq,
return sizeof(*vq->avail) +
sizeof(*vq->avail->ring) * num + event;
}
+EXPORT_SYMBOL_GPL(vhost_get_avail_size);
-static size_t vhost_get_used_size(struct vhost_virtqueue *vq,
- unsigned int num)
+size_t vhost_get_used_size(struct vhost_virtqueue *vq, unsigned int num)
{
size_t event __maybe_unused =
vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
@@ -445,12 +444,13 @@ static size_t vhost_get_used_size(struct vhost_virtqueue *vq,
return sizeof(*vq->used) +
sizeof(*vq->used->ring) * num + event;
}
+EXPORT_SYMBOL_GPL(vhost_get_used_size);
-static size_t vhost_get_desc_size(struct vhost_virtqueue *vq,
- unsigned int num)
+size_t vhost_get_desc_size(struct vhost_virtqueue *vq, unsigned int num)
{
return sizeof(*vq->desc) * num;
}
+EXPORT_SYMBOL_GPL(vhost_get_desc_size);
void vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue **vqs, int nvqs,
@@ -2617,6 +2617,33 @@ struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
}
EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
+bool vhost_translate_ring_addr(struct vhost_virtqueue *vq, u64 ring_addr,
+ u64 len, u64 *addr)
+{
+ struct vhost_umem *umem = vq->umem;
+ struct vhost_umem_node *u;
+
+ if (vhost_overflow(ring_addr, len))
+ return false;
+
+ if (vq->iotlb) {
+ /* Ring address is already IOVA */
+ *addr = ring_addr;
+ return true;
+ }
+
+ /* Ring address is host virtual address. */
+ list_for_each_entry(u, &umem->umem_list, link) {
+ if (u->userspace_addr <= ring_addr &&
+ u->userspace_addr + u->size >= ring_addr + len) {
+ *addr = ring_addr - u->userspace_addr + u->start;
+ return true;
+ }
+ }
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(vhost_translate_ring_addr);
static int __init vhost_init(void)
{
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index e9ed2722b633..294a6bcb6adf 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -189,6 +189,12 @@ long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, void __user *argp);
long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp);
bool vhost_vq_access_ok(struct vhost_virtqueue *vq);
bool vhost_log_access_ok(struct vhost_dev *);
+bool vhost_translate_ring_addr(struct vhost_virtqueue *vq, u64 ring_addr,
+ u64 len, u64 *addr);
+
+size_t vhost_get_avail_size(struct vhost_virtqueue *vq, unsigned int num);
+size_t vhost_get_used_size(struct vhost_virtqueue *vq, unsigned int num);
+size_t vhost_get_desc_size(struct vhost_virtqueue *vq, unsigned int num);
int vhost_get_vq_desc(struct vhost_virtqueue *,
struct iovec iov[], unsigned int iov_count,
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 40d028eed645..7213aedc8506 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -116,4 +116,14 @@
#define VHOST_VSOCK_SET_GUEST_CID _IOW(VHOST_VIRTIO, 0x60, __u64)
#define VHOST_VSOCK_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+/* VHOST_MDEV specific defines */
+
+#define VHOST_MDEV_SET_BACKEND _IOW(VHOST_VIRTIO, 0x70, \
+ struct vhost_mdev_backend)
+#define VHOST_MDEV_SET_STATE _IOW(VHOST_VIRTIO, 0x71, __u64)
+
+#define VHOST_MDEV_S_STOPPED 0
+#define VHOST_MDEV_S_RUNNING 1
+#define VHOST_MDEV_S_MAX 2
+
#endif
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index c907290ff065..f06f0dbb7e51 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -119,6 +119,11 @@ struct vhost_scsi_target {
unsigned short reserved;
};
+struct vhost_mdev_backend {
+ int group_fd;
+ int device_fd;
+};
+
/* Feature bits */
/* Log all write descriptors. Can be changed while device is active. */
#define VHOST_F_LOG_ALL 26
--
2.17.1
^ permalink raw reply related
* Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
From: Jason Wang @ 2019-09-17 1:29 UTC (permalink / raw)
To: Tiwei Bie, mst, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu
In-Reply-To: <20190917010204.30376-1-tiwei.bie@intel.com>
On 2019/9/17 上午9:02, Tiwei Bie wrote:
> This RFC is to demonstrate below ideas,
>
> a) Build vhost-mdev on top of the same abstraction defined in
> the virtio-mdev series [1];
>
> b) Introduce /dev/vhost-mdev to do vhost ioctls and support
> setting mdev device as backend;
>
> Now the userspace API looks like this:
>
> - Userspace generates a compatible mdev device;
>
> - Userspace opens this mdev device with VFIO API (including
> doing IOMMU programming for this mdev device with VFIO's
> container/group based interface);
>
> - Userspace opens /dev/vhost-mdev and gets vhost fd;
>
> - Userspace uses vhost ioctls to setup vhost (userspace should
> do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device
> fd first before doing other vhost ioctls);
>
> Only compile test has been done for this series for now.
>
> RFCv3: https://patchwork.kernel.org/patch/11117785/
>
> [1] https://lkml.org/lkml/2019/9/10/135
Thanks a lot for the patches.
Per Michael request, the API in [1] might need some tweak, I want to
introduce some device specific parent_ops instead of vfio specific one.
This RFC has been posted at https://lkml.org/lkml/2019/9/12/151.
>
> Tiwei Bie (3):
> vfio: support getting vfio device from device fd
> vfio: support checking vfio driver by device ops
> vhost: introduce mdev based hardware backend
>
> drivers/vfio/mdev/vfio_mdev.c | 3 +-
> drivers/vfio/vfio.c | 32 +++
> drivers/vhost/Kconfig | 9 +
> drivers/vhost/Makefile | 3 +
> drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
> drivers/vhost/vhost.c | 39 ++-
> drivers/vhost/vhost.h | 6 +
> include/linux/vfio.h | 11 +
> include/uapi/linux/vhost.h | 10 +
> include/uapi/linux/vhost_types.h | 5 +
> 10 files changed, 573 insertions(+), 7 deletions(-)
> create mode 100644 drivers/vhost/mdev.c
>
^ permalink raw reply
* Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-09-17 1:48 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team, Daniel Drake
In-Reply-To: <a3ac212d-b976-fb16-227f-3246a317c4a2@gmail.com>
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>
> On 8/12/19 10:32 AM, Kalle Valo wrote:
> >> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
> >
> > This is marked as RFC so I'm not sure what's the plan. Should I apply
> > this?
>
> I think it's at a point where it's worth applying - I kinda wish I had
> had time to test it, but I won't be near my stash of USB dongles for a
> little while.
>
> Cheers,
> Jes
>
Gentle ping. Any suggestions for the next step?
Chris
^ permalink raw reply
* Re: BUG: sleeping function called from invalid context in tcf_chain0_head_change_cb_del
From: Cong Wang @ 2019-09-17 1:58 UTC (permalink / raw)
To: syzbot
Cc: Alexei Starovoitov, Daniel Borkmann, David Miller, David Ahern,
Florian Fainelli, hawk, Ido Schimmel, Jakub Kicinski,
Jamal Hadi Salim, Jiri Pirko, Jiri Pirko, John Fastabend,
Martin KaFai Lau, LKML, Linux Kernel Network Developers,
Nikolay Aleksandrov, petrm, Roopa Prabhu, Song Liu,
syzkaller-bugs, Vlad Buslov, xdp-newbies, yhs
In-Reply-To: <00000000000029a3a00592b41c48@google.com>
On Mon, Sep 16, 2019 at 4:39 PM syzbot
<syzbot+ac54455281db908c581e@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ed2b148cd67382ec
> dashboard link: https://syzkaller.appspot.com/bug?extid=ac54455281db908c581e
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116c4b11600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ff270d600000
>
> The bug was bisected to:
>
> commit c266f64dbfa2a970a13b0574246c0ddfec492365
> Author: Vlad Buslov <vladbu@mellanox.com>
> Date: Mon Feb 11 08:55:32 2019 +0000
>
> net: sched: protect block state with mutex
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e7ca65600000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=15e7ca65600000
> console output: https://syzkaller.appspot.com/x/log.txt?x=11e7ca65600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+ac54455281db908c581e@syzkaller.appspotmail.com
> Fixes: c266f64dbfa2 ("net: sched: protect block state with mutex")
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:909
> in_atomic(): 1, irqs_disabled(): 0, pid: 9297, name: syz-executor942
> INFO: lockdep is turned off.
> Preemption disabled at:
> [<ffffffff8604de24>] spin_lock_bh include/linux/spinlock.h:343 [inline]
> [<ffffffff8604de24>] sch_tree_lock include/net/sch_generic.h:570 [inline]
> [<ffffffff8604de24>] sfb_change+0x284/0xd30 net/sched/sch_sfb.c:519
> CPU: 0 PID: 9297 Comm: syz-executor942 Not tainted 5.3.0-rc8+ #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
> ___might_sleep+0x3ff/0x530 kernel/sched/core.c:6608
> __might_sleep+0x8f/0x100 kernel/sched/core.c:6561
> __mutex_lock_common+0x4e/0x2820 kernel/locking/mutex.c:909
> __mutex_lock kernel/locking/mutex.c:1077 [inline]
> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1092
> tcf_chain0_head_change_cb_del+0x30/0x390 net/sched/cls_api.c:932
> tcf_block_put_ext+0x3d/0x2a0 net/sched/cls_api.c:1502
> tcf_block_put+0x6e/0x90 net/sched/cls_api.c:1515
> sfb_destroy+0x47/0x70 net/sched/sch_sfb.c:467
> qdisc_destroy+0x147/0x4d0 net/sched/sch_generic.c:968
> qdisc_put+0x58/0x90 net/sched/sch_generic.c:992
> sfb_change+0x52d/0xd30 net/sched/sch_sfb.c:522
I don't think we have to hold the qdisc tree lock when destroying
the old qdisc. Does the following change make sense?
diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
index 1dff8506a715..726d0fa956b1 100644
--- a/net/sched/sch_sfb.c
+++ b/net/sched/sch_sfb.c
@@ -488,7 +488,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
struct netlink_ext_ack *extack)
{
struct sfb_sched_data *q = qdisc_priv(sch);
- struct Qdisc *child;
+ struct Qdisc *child, *tmp;
struct nlattr *tb[TCA_SFB_MAX + 1];
const struct tc_sfb_qopt *ctl = &sfb_default_ops;
u32 limit;
@@ -519,7 +519,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
sch_tree_lock(sch);
qdisc_tree_flush_backlog(q->qdisc);
- qdisc_put(q->qdisc);
+ tmp = q->qdisc;
q->qdisc = child;
q->rehash_interval = msecs_to_jiffies(ctl->rehash_interval);
@@ -543,6 +543,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
sch_tree_unlock(sch);
+ qdisc_put(tmp);
return 0;
}
What do you think, Vlad?
^ permalink raw reply related
* Re: [PATCH 1/3] ixgbe: Use kzfree() rather than its implementation.
From: Jakub Kicinski @ 2019-09-17 2:43 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, anna.schumaker, trond.myklebust, netdev, linux-kernel
In-Reply-To: <1567564752-6430-2-git-send-email-zhongjiang@huawei.com>
On Wed, 4 Sep 2019 10:39:10 +0800, zhong jiang wrote:
> Use kzfree() instead of memset() + kfree().
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index 31629fc..113f608 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -960,11 +960,9 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> return 0;
>
> err_aead:
> - memset(xs->aead, 0, sizeof(*xs->aead));
> - kfree(xs->aead);
> + kzfree(xs->aead);
> err_xs:
> - memset(xs, 0, sizeof(*xs));
> - kfree(xs);
> + kzfree(xs);
> err_out:
> msgbuf[1] = err;
> return err;
> @@ -1049,8 +1047,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> ixgbe_ipsec_del_sa(xs);
>
> /* remove the xs that was made-up in the add request */
> - memset(xs, 0, sizeof(*xs));
> - kfree(xs);
> + kzfree(xs);
>
> return 0;
> }
All the crypto cases should really be converted to memzero_explicit().
^ permalink raw reply
* Re: [PATCH 2/3] nfp: Drop unnecessary continue in nfp_net_pf_alloc_vnics
From: Jakub Kicinski @ 2019-09-17 2:45 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, kvalo, pkshih, netdev, linux-kernel
In-Reply-To: <1567568784-9669-3-git-send-email-zhongjiang@huawei.com>
On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
> Continue is not needed at the bottom of a loop.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> index 986464d..68db47d 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> @@ -205,10 +205,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf)
> ctrl_bar += NFP_PF_CSR_SLICE_SIZE;
>
> /* Kill the vNIC if app init marked it as invalid */
> - if (nn->port && nn->port->type == NFP_PORT_INVALID) {
> + if (nn->port && nn->port->type == NFP_PORT_INVALID)
> nfp_net_pf_free_vnic(pf, nn);
> - continue;
> - }
Ugh, I already nack at least one patch like this, this continue makes
the _intent_ of the code more clear, the compiler will ignore it anyway.
I guess there's no use in fighting the bots..
> }
>
> if (list_empty(&pf->vnics))
^ permalink raw reply
* Re: [PATCH 2/3] nfp: Drop unnecessary continue in nfp_net_pf_alloc_vnics
From: zhong jiang @ 2019-09-17 3:07 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, kvalo, pkshih, netdev, linux-kernel
In-Reply-To: <20190916194502.0c014667@cakuba.netronome.com>
On 2019/9/17 10:45, Jakub Kicinski wrote:
> On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
>> Continue is not needed at the bottom of a loop.
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> index 986464d..68db47d 100644
>> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
>> @@ -205,10 +205,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf)
>> ctrl_bar += NFP_PF_CSR_SLICE_SIZE;
>>
>> /* Kill the vNIC if app init marked it as invalid */
>> - if (nn->port && nn->port->type == NFP_PORT_INVALID) {
>> + if (nn->port && nn->port->type == NFP_PORT_INVALID)
>> nfp_net_pf_free_vnic(pf, nn);
>> - continue;
>> - }
> Ugh, I already nack at least one patch like this, this continue makes
> the _intent_ of the code more clear, the compiler will ignore it anyway.
Thanks, I miss that information you object to above modification.
Sincerely,
zhong jiang
> I guess there's no use in fighting the bots..
>
>> }
>>
>> if (list_empty(&pf->vnics))
>
> .
>
^ 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