* 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
* Re: [PATCH 1/3] ixgbe: Use kzfree() rather than its implementation.
From: zhong jiang @ 2019-09-17 3:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, anna.schumaker, trond.myklebust, netdev, linux-kernel
In-Reply-To: <20190916194319.712d81cc@cakuba.netronome.com>
On 2019/9/17 10:43, Jakub Kicinski wrote:
> 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().
It's better to do that. I will repost it in v2.
Thanks,
zhong jiang
^ permalink raw reply
* Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
From: Jason Wang @ 2019-09-17 3:32 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.
Have a hard thought on the architecture:
1) Create a vhost char device and pass vfio mdev device fd to it as a
backend and translate vhost-mdev ioctl to virtio mdev transport (e.g
read/write). DMA was done through the VFIO DMA mapping on the container
that is attached.
We have two more choices:
2) Use vfio-mdev but do not create vhost-mdev device, instead, just
implement vhost ioctl on vfio_device_ops, and translate them into
virtio-mdev transport or just pass ioctl to parent.
3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe
still try to add dev to vfio group and talk to parent with device
specific ops
So I have some questions:
1) Compared to method 2, what's the advantage of creating a new vhost
char device? I guess it's for keep the API compatibility?
2) For method 2, is there any easy way for user/admin to distinguish e.g
ordinary vfio-mdev for vhost from ordinary vfio-mdev? I saw you
introduce ops matching helper but it's not friendly to management.
3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
assumes the parameter comes from userspace, it prevents support kernel
virtio drivers.
4) So comes the idea of method 3, since it register a new vhost-mdev
driver, we can use device specific ops instead of VFIO ones, then we can
have a common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
What's your thoughts?
Thanks
>
> 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
>
^ permalink raw reply
* [PATCH v2] ixgbe: Use memset_explicit directly in crypto cases
From: zhong jiang @ 2019-09-17 3:45 UTC (permalink / raw)
To: jakub.kicinski, davem
Cc: anna.schumaker, trond.myklebust, netdev, linux-kernel, zhongjiang
It's better to use memset_explicit() to replace memset() in crypto cases.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 31629fc..7e4f32f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -960,10 +960,10 @@ 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));
+ memzero_explicit(xs->aead, sizeof(*xs->aead));
kfree(xs->aead);
err_xs:
- memset(xs, 0, sizeof(*xs));
+ memzero_explicit(xs, sizeof(*xs));
kfree(xs);
err_out:
msgbuf[1] = err;
@@ -1049,7 +1049,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));
+ memzero_explicit(xs, sizeof(*xs));
kfree(xs);
return 0;
--
1.7.12.4
^ permalink raw reply related
* Re: [bpf-next,v3] samples: bpf: add max_pckt_size option at xdp_adjust_tail
From: Andrii Nakryiko @ 2019-09-17 4:04 UTC (permalink / raw)
To: Daniel T. Lee; +Cc: Daniel Borkmann, Alexei Starovoitov, Networking, bpf
In-Reply-To: <20190911190218.22628-1-danieltimlee@gmail.com>
On Wed, Sep 11, 2019 at 2:33 PM Daniel T. Lee <danieltimlee@gmail.com> wrote:
>
> Currently, at xdp_adjust_tail_kern.c, MAX_PCKT_SIZE is limited
> to 600. To make this size flexible, a new map 'pcktsz' is added.
>
> By updating new packet size to this map from the userland,
> xdp_adjust_tail_kern.o will use this value as a new max_pckt_size.
>
> If no '-P <MAX_PCKT_SIZE>' option is used, the size of maximum packet
> will be 600 as a default.
>
> Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
>
> ---
> Changes in v2:
> - Change the helper to fetch map from 'bpf_map__next' to
> 'bpf_object__find_map_fd_by_name'.
>
> samples/bpf/xdp_adjust_tail_kern.c | 23 +++++++++++++++++++----
> samples/bpf/xdp_adjust_tail_user.c | 28 ++++++++++++++++++++++------
> 2 files changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/samples/bpf/xdp_adjust_tail_kern.c b/samples/bpf/xdp_adjust_tail_kern.c
> index 411fdb21f8bc..d6d84ffe6a7a 100644
> --- a/samples/bpf/xdp_adjust_tail_kern.c
> +++ b/samples/bpf/xdp_adjust_tail_kern.c
> @@ -25,6 +25,13 @@
> #define ICMP_TOOBIG_SIZE 98
> #define ICMP_TOOBIG_PAYLOAD_SIZE 92
>
> +struct bpf_map_def SEC("maps") pcktsz = {
> + .type = BPF_MAP_TYPE_ARRAY,
> + .key_size = sizeof(__u32),
> + .value_size = sizeof(__u32),
> + .max_entries = 1,
> +};
> +
Hey Daniel,
This looks like an ideal use case for global variables on BPF side. I
think it's much cleaner and will make BPF side of things simpler.
Would you mind giving global data a spin instead of adding this map?
> struct bpf_map_def SEC("maps") icmpcnt = {
> .type = BPF_MAP_TYPE_ARRAY,
> .key_size = sizeof(__u32),
> @@ -64,7 +71,8 @@ static __always_inline void ipv4_csum(void *data_start, int data_size,
> *csum = csum_fold_helper(*csum);
> }
>
[...]
^ permalink raw reply
* Re: [PATCH bpf v2] libbpf: Remove getsockopt() check for XDP_OPTIONS
From: Andrii Nakryiko @ 2019-09-17 4:12 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Alexei Starovoitov, Daniel Borkmann, Networking, bpf,
Björn Töpel, Yonghong Song
In-Reply-To: <20190916123342.49928-1-toke@redhat.com>
On Mon, Sep 16, 2019 at 6:05 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> The xsk_socket__create() function fails and returns an error if it cannot
> get the XDP_OPTIONS through getsockopt(). However, support for XDP_OPTIONS
> was not added until kernel 5.3, so this means that creating XSK sockets
> always fails on older kernels.
>
> Since the option is just used to set the zero-copy flag in the xsk struct,
> and that flag is not really used for anything yet, just remove the
> getsockopt() call until a proper use for it is introduced.
>
> Suggested-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
> v2:
> - Remove the call entirely.
>
> tools/lib/bpf/xsk.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
Who doesn't like removal of code?.. :)
Acked-by: Andrii Nakryiko <andriin@fb.com>
[...]
^ permalink raw reply
* Re: [PATCH] netfilter: bridge: drop a broken include
From: Pablo Neira Ayuso @ 2019-09-17 5:09 UTC (permalink / raw)
To: Jeremy Sowden
Cc: Adam Borowski, Jozsef Kadlecsik, Florian Westphal, Roopa Prabhu,
Nikolay Aleksandrov, netfilter-devel, coreteam, netdev
In-Reply-To: <20190916130811.GA29776@azazel.net>
Hi Jeremy,
On Mon, Sep 16, 2019 at 02:08:12PM +0100, Jeremy Sowden wrote:
> On 2019-09-16, at 02:05:16 +0200, Adam Borowski wrote:
> > This caused a build failure if CONFIG_NF_CONNTRACK_BRIDGE is set but
> > CONFIG_NF_TABLES=n -- and appears to be unused anyway.
[...]
> There are already changes in the net-next tree that will fix it.
If the fix needs to go to -stable 5.3 kernel release, then you have to
point to the particular commit ID of this patch to fix this one.
net-next contains 5.4-rc material. I'd appreciate also if you can help
identify the patch with a Fixes: tag.
Thanks.
^ permalink raw reply
* Fw: [Bug 204879] New: "invalid inflight", WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509 tcp_send_loss_probe.cold.42+0x20/0x2d
From: Stephen Hemminger @ 2019-09-17 6:09 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 16 Sep 2019 20:28:15 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 204879] New: "invalid inflight", WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509 tcp_send_loss_probe.cold.42+0x20/0x2d
https://bugzilla.kernel.org/show_bug.cgi?id=204879
Bug ID: 204879
Summary: "invalid inflight", WARNING: CPU: 1 PID: 5103 at
net/ipv4/tcp_output.c:2509
tcp_send_loss_probe.cold.42+0x20/0x2d
Product: Networking
Version: 2.5
Kernel Version: 4.14.143
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: rm+bko@romanrm.net
Regression: No
After upgrading my kernel version from 4.14.121 to 4.14.143, on every boot I
now get the following warning.
Moreover, eventually (in a few hours) the server appears to lock-up. However I
can't say for sure if the lock-up is related, or what messages appear during
that time, as this is a remote system with no IPMI or the like. There's nothing
in disk-based logs. I'll try netconsole later if this continues to repeat.
For now, any ideas about this particular backtrace? Thanks
[ 35.587989] invalid inflight: 1 state 1 cwnd 14 mss 1428
[ 35.588004] ------------[ cut here ]------------
[ 35.588009] WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509
tcp_send_loss_probe.cold.42+0x20/0x2d
[ 35.588011] Modules linked in: wireguard ip6_udp_tunnel udp_tunnel
xt_comment xt_u32 xt_connlimit ip6t_MASQUERADE nf_nat_masquerade_ipv6 xt_TCPMSS
xt_nat xt_mark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_tcpudp xt_set
ip_set_hash_net ip_set nfnetlink xt_multiport xt_limit xt_length xt_conntrack
ip6t_rpfilter ipt_rpfilter ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_raw ip6table_mangle iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw iptable_mangle
ip6table_filter ip6_tables iptable_filter ip_tables x_tables
cpufreq_conservative cpufreq_powersave cpufreq_userspace tcp_bbr sch_fq
tcp_illinois intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc
aesni_intel
[ 35.588042] aes_x86_64 crypto_simd glue_helper cryptd snd_hda_codec_hdmi
intel_cstate snd_hda_codec_realtek snd_hda_codec_generic intel_uncore
snd_hda_intel i915 video iTCO_wdt intel_rapl_perf iTCO_vendor_support
snd_hda_codec drm_kms_helper evdev snd_hda_core pcspkr snd_hwdep snd_pcm
snd_timer pcc_cpufreq mei_me mei drm sg snd shpchp lpc_ich button i2c_algo_bit
serio_raw mfd_core soundcore ext4 crc16 mbcache jbd2 fscrypto btrfs
zstd_decompress zstd_compress xxhash sata_nv dm_crypt raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic
raid0 raid1 md_mod dm_mirror dm_region_hash dm_log dm_mod ata_piix sd_mod
xhci_pci xhci_hcd crc32c_intel ahci libahci i2c_i801 ehci_pci libata psmouse
ehci_hcd scsi_mod e1000e ptp usbcore pps_core
[ 35.588086] CPU: 1 PID: 5103 Comm: xmrig Not tainted 4.14.144-rm1+ #64
[ 35.588088] Hardware name: /DH67BL, BIOS BLH6710H.86A.0160.2012.1204.1156
12/04/2012
[ 35.588090] task: ffff8e0c0578bb80 task.stack: ffffa6a349524000
[ 35.588093] RIP: 0010:tcp_send_loss_probe.cold.42+0x20/0x2d
[ 35.588095] RSP: 0000:ffff8e0c1f283e70 EFLAGS: 00010246
[ 35.588097] RAX: 000000000000002c RBX: ffff8e0c0b932a80 RCX:
0000000000000000
[ 35.588099] RDX: 0000000000000000 RSI: ffff8e0c1f296738 RDI:
ffff8e0c1f296738
[ 35.588101] RBP: ffff8e0c0b932bd8 R08: 0000000000000000 R09:
0000000000000275
[ 35.588103] R10: ffff8e0c0e911280 R11: 0000000000000000 R12:
ffff8e0c0b932bd8
[ 35.588105] R13: ffffffff827d46b0 R14: ffff8e0c0b932a80 R15:
ffff8e0c1f283ef0
[ 35.588107] FS: 00007f71de376700(0000) GS:ffff8e0c1f280000(0000)
knlGS:0000000000000000
[ 35.588110] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.588112] CR2: 000055f0f061c000 CR3: 0000000409d0e001 CR4:
00000000000606e0
[ 35.588114] Call Trace:
[ 35.588116] <IRQ>
[ 35.588120] tcp_write_timer_handler+0xce/0x210
[ 35.588123] tcp_write_timer+0x77/0x90
[ 35.588126] call_timer_fn+0x30/0x130
[ 35.588129] run_timer_softirq+0x3d3/0x410
[ 35.588133] ? timerqueue_add+0x52/0x80
[ 35.588136] ? enqueue_hrtimer+0x36/0x80
[ 35.588140] __do_softirq+0xdb/0x2d5
[ 35.588142] ? hrtimer_interrupt+0x113/0x1d0
[ 35.588147] irq_exit+0xbc/0xd0
[ 35.588150] smp_apic_timer_interrupt+0x78/0x140
[ 35.588152] apic_timer_interrupt+0x85/0x90
[ 35.588154] </IRQ>
[ 35.588156] RIP: 0033:0x7f71ddb3b16f
[ 35.588158] RSP: 002b:81244f1f4aebe662 EFLAGS: 00000206 ORIG_RAX:
ffffffffffffff10
[ 35.588161] RAX: 000000005590220e RBX: 000000004520e100 RCX:
00007f71dd513600
[ 35.588163] RDX: 000000005476b198 RSI: 8219664b28bc2fe0 RDI:
00000000555b6ee0
[ 35.588165] RBP: 0000000092e54880 R08: 000000000007be43 R09:
00000000ce690f4f
[ 35.588166] R10: 00000000001f6970 R11: 00007f71dd400000 R12:
80ee3d8c155f6970
[ 35.588168] R13: 4b3017ab1f4489c9 R14: 3854bb60406a6bea R15:
eb98349c9e84f39a
[ 35.588171] Code: 00 c6 83 7b 04 00 00 00 5b 5d c3 0f b6 53 12 8b 8b 2c 06
00 00 41 89 c0 48 c7 c7 90 e3 06 83 c6 05 39 64 b1 00 01 e8 cd a3 b0 ff <0f> 0b
e9 1f ee ff ff 90 90 90 90 90 90 66 66 66 66 90 48 8b 47
[ 35.588193] ---[ end trace 7c7f3665018c9e60 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ 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