* [PATCH bpf-next 03/11] samples: bpf: makefile: use --target from cross-compile
From: Ivan Khoronzhuk @ 2019-09-10 10:38 UTC (permalink / raw)
To: ast, daniel, yhs, davem, jakub.kicinski, hawk, john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux, Ivan Khoronzhuk
In-Reply-To: <20190910103830.20794-1-ivan.khoronzhuk@linaro.org>
For cross compiling the target triple can be inherited from
cross-compile prefix as it's done in CLANG_FLAGS from kernel makefile.
So copy-paste this decision from kernel Makefile.
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 43dee90dffa4..b59e77e2250e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -195,7 +195,7 @@ BTF_PAHOLE ?= pahole
# Detect that we're cross compiling and use the cross compiler
ifdef CROSS_COMPILE
HOSTCC = $(CROSS_COMPILE)gcc
-CLANG_ARCH_ARGS = -target $(ARCH)
+CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%))
endif
# Don't evaluate probes and warnings if we need to run make recursively
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 02/11] samples: bpf: makefile: fix cookie_uid_helper_example obj build
From: Ivan Khoronzhuk @ 2019-09-10 10:38 UTC (permalink / raw)
To: ast, daniel, yhs, davem, jakub.kicinski, hawk, john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux, Ivan Khoronzhuk
In-Reply-To: <20190910103830.20794-1-ivan.khoronzhuk@linaro.org>
Don't list userspace "cookie_uid_helper_example" object in list for
bpf objects.
per_socket_stats_example-opjs is used to list additional dependencies
for user space binary from hostprogs-y list. Kbuild system creates
rules for objects listed this way anyway and no need to worry about
this. Despite on it, the samples bpf uses logic that hostporgs-y are
build for userspace with includes needed for this, but "always"
target, if it's not in hostprog-y list, uses CLANG-bpf rule and is
intended to create bpf obj but not arch obj and uses only kernel
includes for that. So correct it, as it breaks cross-compiling at
least.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
samples/bpf/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index f50ca852c2a8..43dee90dffa4 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -145,7 +145,6 @@ always += sampleip_kern.o
always += lwt_len_hist_kern.o
always += xdp_tx_iptunnel_kern.o
always += test_map_in_map_kern.o
-always += cookie_uid_helper_example.o
always += tcp_synrto_kern.o
always += tcp_rwnd_kern.o
always += tcp_bufs_kern.o
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 01/11] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Ivan Khoronzhuk @ 2019-09-10 10:38 UTC (permalink / raw)
To: ast, daniel, yhs, davem, jakub.kicinski, hawk, john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux, Ivan Khoronzhuk
In-Reply-To: <20190910103830.20794-1-ivan.khoronzhuk@linaro.org>
echo should be replaced on echo -e to handle \n correctly, but instead,
replace it on 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; }" | \
$(HOSTCC) $(KBUILD_HOSTCFLAGS) -x c - -o /dev/null 2>/dev/null && \
echo okay)
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 00/11] samples: bpf: improve/fix cross-compilation
From: Ivan Khoronzhuk @ 2019-09-10 10:38 UTC (permalink / raw)
To: ast, daniel, yhs, davem, jakub.kicinski, hawk, john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux, Ivan Khoronzhuk
This series contains mainly fixes/improvements for cross-compilation
but not only, tested for arm, arm64, but intended for any arch.
Also verified on native build (not cross compilation) for x86_64
and arm.
Initial RFC link:
https://lkml.org/lkml/2019/8/29/1665
Prev. version:
https://www.spinics.net/lists/netdev/msg597823.html
Besides the patches given here, the RFC also contains couple patches
related to llvm clang
arm: include: asm: swab: mask rev16 instruction for clang
arm: include: asm: unified: mask .syntax unified for clang
They are necessarily to verify arm build.
The change touches not only cross-compilation and can have impact on
other archs and build environments, so might be good idea to verify
it in order to add appropriate changes, some warn options could be
tuned also.
All is tasted on x86-64 with clang installed (has to be built containing
targets for arm, arm64..., see llvm -v, usually it's present already)
Instructions to test native on x86_64
=================================================
Native build on x86_64 is done in usual way and shouldn't have difference
except HOSTCC is now printed as CC wile building the samples.
Instructions to test cross compilation on arm64
=================================================
#Toolchain used for test:
gcc version 8.3.0
(GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))
# Get some arm64 FS, containing at least libelf
I've used sdk for TI am65x got here:
http://downloads.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/\
ti-processor-sdk-linux-am65xx-evm-06.00.00.07-Linux-x86-Install.bin
# Install this binary to some dir, say "sdk".
# Configure kernel (use defconfig as no matter), but clean everything
# before.
make ARCH=arm64 -C tools/ clean
make ARCH=arm64 -C samples/bpf clean
make ARCH=arm64 clean
make ARCH=arm64 defconfig
# The kernel version used in sdk doesn't correspond to checked one,
# but for this verification only headers need to be syched,
# so install them:
make ARCH=arm64 headers_install
# or on SDK if need keep them in sync (not necessarily to verify):
make ARCH=arm64 INSTALL_HDR_PATH=/../sdk/\
ti-processor-sdk-linux-am65xx-evm-06.00.00.07/linux-devkit/sysroots/\
aarch64-linux/usr headers_install
# Build samples
make samples/bpf/ ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-"\
SYSROOT="/../sdk/ti-processor-sdk-linux-am65xx-evm-06.00.00.07/\
linux-devkit/sysroots/aarch64-linux"
Instructions to test cross compilation on arm
=================================================
#Toolchains used for test:
arm-linux-gnueabihf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
or
arm-linux-gnueabihf-gcc
(GNU Toolchain for the A-profile Architecture 8.3-2019.03 \
(arm-rel-8.36)) 8.3.0
# Get some FS, I've used sdk for TI am52xx got here:
http://downloads.ti.com/processor-sdk-linux/esd/AM57X/05_03_00_07/exports/\
ti-processor-sdk-linux-am57xx-evm-05.03.00.07-Linux-x86-Install.bin
# Install this binary to some dir, say "sdk".
# Configure kernel, but clean everything before.
make ARCH=arm -C tools/ clean
make ARCH=arm -C samples/bpf clean
make ARCH=arm clean
make ARCH=arm omap2plus_defconfig
# The kernel version used in sdk doesn't correspond to checked one, but
headers only should be synched, so install them:
make ARCH=arm64 headers_install
# or on SDK if need keep them in sync (not necessarily):
make ARCH=arm INSTALL_HDR_PATH=/../sdk/\
ti-processor-sdk-linux-am57xx-evm-05.03.00.07/linux-devkit/sysroots/\
armv7ahf-neon-linux-gnueabi/usr headers_install
# Build samples
make samples/bpf/ ARCH=arm CROSS_COMPILE="arm-linux-gnueabihf-"\
SYSROOT="/../sdk/ti-processor-sdk-linux-am57xx-evm-05.03\
.00.07/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi"
Based on bpf-next/master
v2..v1:
- restructured patches order
- split "samples: bpf: Makefile: base progs build on Makefile.progs"
to make change more readable. It added couple nice extra patches.
- removed redundant patch:
"samples: bpf: Makefile: remove target for native build"
- added fix:
"samples: bpf: makefile: fix cookie_uid_helper_example obj build"
- limited -D option filter only for arm
- improved comments
- added couple instructions to verify cross compilation for arm and
arm64 arches based on TI am57xx and am65xx sdks.
- corrected include a little order
Ivan Khoronzhuk (11):
samples: bpf: makefile: fix HDR_PROBE "echo"
samples: bpf: makefile: fix cookie_uid_helper_example obj build
samples: bpf: makefile: use --target from cross-compile
samples: bpf: use own EXTRA_CFLAGS for clang commands
samples: bpf: makefile: use D vars from KBUILD_CFLAGS to handle
headers
samples: bpf: makefile: drop unnecessarily inclusion for bpf_load
samples: bpf: add makefile.prog for separate CC build
samples: bpf: makefile: base progs build on makefile.progs
samples: bpf: makefile: use CC environment for HDR_PROBE
libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf
targets
samples: bpf: makefile: add sysroot support
samples/bpf/Makefile | 172 ++++++++++++++++++++++----------------
samples/bpf/Makefile.prog | 77 +++++++++++++++++
samples/bpf/README.rst | 10 +++
tools/lib/bpf/Makefile | 11 ++-
4 files changed, 194 insertions(+), 76 deletions(-)
create mode 100644 samples/bpf/Makefile.prog
--
2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next 01/11] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Sergei Shtylyov @ 2019-09-10 10:46 UTC (permalink / raw)
To: Ivan Khoronzhuk, ast, daniel, yhs, davem, jakub.kicinski, hawk,
john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux
In-Reply-To: <20190910103830.20794-2-ivan.khoronzhuk@linaro.org>
Hello!
On 10.09.2019 13:38, Ivan Khoronzhuk wrote:
> echo should be replaced on echo -e to handle \n correctly, but instead,
s/on/with/?
> replace it on printf as some systems can't handle echo -e.
Likewise?
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
[...]
MBR, Sergei
^ permalink raw reply
* Re: ❌ FAIL: Stable queue: queue-5.2
From: Sasha Levin @ 2019-09-10 10:52 UTC (permalink / raw)
To: Hangbin Liu
Cc: Greg KH, CKI Project, Linux Stable maillist, netdev, Jan Stancek,
Xiumei Mu, David Howells, linux-afs
In-Reply-To: <20190910094025.GM22496@dhcp-12-139.nay.redhat.com>
On Tue, Sep 10, 2019 at 05:40:25PM +0800, Hangbin Liu wrote:
>On Tue, Sep 10, 2019 at 05:30:21PM +0800, Hangbin Liu wrote:
>> Xiumei Mu also forwarded me a mail. It looks Sasha has fixed something.
>> But I don't know the details.
>
>Oh, I checked that thread. It's the same issue. So Sasha should has fixed it. I
>just wonder the commit id now.
That was fixed by upstream commit
b00df840fb4004b7087940ac5f68801562d0d2de.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH] ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()'
From: Christophe JAILLET @ 2019-09-10 11:29 UTC (permalink / raw)
To: davem, kuznet, yoshfuji
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
The '.exit' functions from 'pernet_operations' structure should be marked
as __net_exit, not __net_init.
Fixes: d862e5461423 ("net: ipv6: Implement /proc/net/icmp6.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Untested, but using __net_exit looks consistent with other
pernet_operations.exit use case.
---
net/ipv6/ping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 87d2d8c1db7c..98ac32b49d8c 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -223,7 +223,7 @@ static int __net_init ping_v6_proc_init_net(struct net *net)
return 0;
}
-static void __net_init ping_v6_proc_exit_net(struct net *net)
+static void __net_exit ping_v6_proc_exit_net(struct net *net)
{
remove_proc_entry("icmp6", net->proc_net);
}
--
2.20.1
^ permalink raw reply related
* Re: ❌ FAIL: Stable queue: queue-5.2
From: Hangbin Liu @ 2019-09-10 11:39 UTC (permalink / raw)
To: Sasha Levin; +Cc: Greg KH, netdev, Jan Stancek, Xiumei Mu, David Howells
In-Reply-To: <20190910105223.GG2012@sasha-vm>
On Tue, Sep 10, 2019 at 06:52:23AM -0400, Sasha Levin wrote:
> On Tue, Sep 10, 2019 at 05:40:25PM +0800, Hangbin Liu wrote:
> > On Tue, Sep 10, 2019 at 05:30:21PM +0800, Hangbin Liu wrote:
> > > Xiumei Mu also forwarded me a mail. It looks Sasha has fixed something.
> > > But I don't know the details.
> >
> > Oh, I checked that thread. It's the same issue. So Sasha should has fixed it. I
> > just wonder the commit id now.
>
> That was fixed by upstream commit
> b00df840fb4004b7087940ac5f68801562d0d2de.
Got it, thanks for this info.
^ permalink raw reply
* Re: [PATCH v3 1/2] ethtool: implement Energy Detect Powerdown support via phy-tunable
From: Ardelean, Alexandru @ 2019-09-10 12:07 UTC (permalink / raw)
To: mkubecek@suse.cz, netdev@vger.kernel.org
Cc: andrew@lunn.ch, davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
robh+dt@kernel.org
In-Reply-To: <20190910080014.GC24779@unicorn.suse.cz>
On Tue, 2019-09-10 at 10:00 +0200, Michal Kubecek wrote:
> [External]
>
> On Mon, Sep 09, 2019 at 04:12:50PM +0300, Alexandru Ardelean wrote:
> > The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like
> > this feature is common across other PHYs (like EEE), and defining
> > `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long.
> >
> > The way EDPD works, is that the RX block is put to a lower power mode,
> > except for link-pulse detection circuits. The TX block is also put to low
> > power mode, but the PHY wakes-up periodically to send link pulses, to avoid
> > lock-ups in case the other side is also in EDPD mode.
> >
> > Currently, there are 2 PHY drivers that look like they could use this new
> > PHY tunable feature: the `adin` && `micrel` PHYs.
> >
> > The ADIN's datasheet mentions that TX pulses are at intervals of 1 second
> > default each, and they can be disabled. For the Micrel KSZ9031 PHY, the
> > datasheet does not mention whether they can be disabled, but mentions that
> > they can modified.
> >
> > The way this change is structured, is similar to the PHY tunable downshift
> > control:
> > * a `ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL` value is exposed to cover a default
> > TX interval; some PHYs could specify a certain value that makes sense
> > * `ETHTOOL_PHY_EDPD_NO_TX` would disable TX when EDPD is enabled
> > * `ETHTOOL_PHY_EDPD_DISABLE` will disable EDPD
> >
> > This should allow PHYs to:
> > * enable EDPD and not enable TX pulses (interval would be 0)
> > * enable EDPD and configure TX pulse interval; note that TX interval units
> > would be PHY specific; we could consider `seconds` as units, but it could
> > happen that some PHYs would be prefer milliseconds as a unit;
> > a maximum of 65533 units should be sufficient
>
> Sorry for missing the discussion on previous version but I don't really
> like the idea of leaving the choice of units to PHY. Both for manual
> setting and system configuration, it would be IMHO much more convenient
> to have the interpretation universal for all NICs.
>
I was also a bit uncertain/undecided here about letting PHYs decide units.
And I also wasn't sure what to propose.
Not proposing a unit now, would have allowed us to decide later based on what PHYs implement (generally) in the future.
I know that may make me look a bit lazy [for not proposing units in ethtool], but tbh it's more of lack-of-experience
with ethtool (or these APIs) evolve over time.
> Seconds as units seem too coarse and maximum of ~18 hours way too big.
> Milliseconds would be more practical from granularity point of view,
> would maximum of ~65 seconds be sufficient?
I think 65 seconds is more than enough.
I feel that, if you plug-in an eth cable and don't have a link in a minute, then it's not great (no matter how much of a
power-saver you are).
Actually, voicing out these units makes it simpler for a decision to go in favor for milliseconds.
So: thank you :)
Alex
>
> Michal Kubecek
>
> > * disable EDPD
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
^ permalink raw reply
* Re: [PATCH net-next 11/11] net: aquantia: add support for PIN funcs
From: kbuild test robot @ 2019-09-10 13:03 UTC (permalink / raw)
To: Igor Russkikh
Cc: kbuild-all, netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov, Igor Russkikh, Nikita Danilov
In-Reply-To: <b3eeb5dd7d38dab79ded5f4b7cca2a84505c8fac.1568034880.git.igor.russkikh@aquantia.com>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
Hi Igor,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Igor-Russkikh/net-aquantia-PTP-support-for-AQC-devices/20190909-233041
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ERROR: "__udivdi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
>> ERROR: "__umoddi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
ERROR: "__divdi3" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 69589 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
From: Jason Wang @ 2019-09-10 13:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <20190910055744-mutt-send-email-mst@kernel.org>
On 2019/9/10 下午6:01, Michael S. Tsirkin wrote:
>> +#ifndef _LINUX_VIRTIO_MDEV_H
>> +#define _LINUX_VIRTIO_MDEV_H
>> +
>> +#include <linux/interrupt.h>
>> +#include <linux/vringh.h>
>> +#include <uapi/linux/virtio_net.h>
>> +
>> +/*
>> + * Ioctls
>> + */
> Pls add a bit more content here. It's redundant to state these
> are ioctls. Much better to document what does each one do.
Ok.
>
>> +
>> +struct virtio_mdev_callback {
>> + irqreturn_t (*callback)(void *);
>> + void *private;
>> +};
>> +
>> +#define VIRTIO_MDEV 0xAF
>> +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
>> + struct virtio_mdev_callback)
>> +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
>> + struct virtio_mdev_callback)
> Function pointer in an ioctl parameter? How does this ever make sense?
I admit this is hacky (casting).
> And can't we use a couple of registers for this, and avoid ioctls?
Yes, how about something like interrupt numbers for each virtqueue and
config?
>
>> +
>> +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
>> +
>> +/*
>> + * Control registers
>> + */
>> +
>> +/* Magic value ("virt" string) - Read Only */
>> +#define VIRTIO_MDEV_MAGIC_VALUE 0x000
>> +
>> +/* Virtio device version - Read Only */
>> +#define VIRTIO_MDEV_VERSION 0x004
>> +
>> +/* Virtio device ID - Read Only */
>> +#define VIRTIO_MDEV_DEVICE_ID 0x008
>> +
>> +/* Virtio vendor ID - Read Only */
>> +#define VIRTIO_MDEV_VENDOR_ID 0x00c
>> +
>> +/* Bitmask of the features supported by the device (host)
>> + * (32 bits per set) - Read Only */
>> +#define VIRTIO_MDEV_DEVICE_FEATURES 0x010
>> +
>> +/* Device (host) features set selector - Write Only */
>> +#define VIRTIO_MDEV_DEVICE_FEATURES_SEL 0x014
>> +
>> +/* Bitmask of features activated by the driver (guest)
>> + * (32 bits per set) - Write Only */
>> +#define VIRTIO_MDEV_DRIVER_FEATURES 0x020
>> +
>> +/* Activated features set selector - Write Only */
>> +#define VIRTIO_MDEV_DRIVER_FEATURES_SEL 0x024
>> +
>> +/* Queue selector - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_SEL 0x030
>> +
>> +/* Maximum size of the currently selected queue - Read Only */
>> +#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034
>> +
>> +/* Queue size for the currently selected queue - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_NUM 0x038
>> +
>> +/* Ready bit for the currently selected queue - Read Write */
>> +#define VIRTIO_MDEV_QUEUE_READY 0x044
> Is this same as started?
Do you mean "status"?
>
>> +
>> +/* Alignment of virtqueue - Read Only */
>> +#define VIRTIO_MDEV_QUEUE_ALIGN 0x048
>> +
>> +/* Queue notifier - Write Only */
>> +#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050
>> +
>> +/* Device status register - Read Write */
>> +#define VIRTIO_MDEV_STATUS 0x060
>> +
>> +/* Selected queue's Descriptor Table address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080
>> +#define VIRTIO_MDEV_QUEUE_DESC_HIGH 0x084
>> +
>> +/* Selected queue's Available Ring address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_AVAIL_LOW 0x090
>> +#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094
>> +
>> +/* Selected queue's Used Ring address, 64 bits in two halves */
>> +#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0
>> +#define VIRTIO_MDEV_QUEUE_USED_HIGH 0x0a4
>> +
>> +/* Configuration atomicity value */
>> +#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc
>> +
>> +/* The config space is defined by each driver as
>> + * the per-driver configuration space - Read Write */
>> +#define VIRTIO_MDEV_CONFIG 0x100
> Mixing device and generic config space is what virtio pci did,
> caused lots of problems with extensions.
> It would be better to reserve much more space.
I see, will do this.
Thanks
>
>
>> +
>> +#endif
>> +
>> +
>> +/* Ready bit for the currently selected queue - Read Write */
>> --
>> 2.19.1
^ permalink raw reply
* [PATCH net-next v2 0/3] add ksz9567 with I2C support to ksz9477 driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
Resurrect KSZ9477 I2C driver support patch originally sent to the list
by Tristram Ha and resolve outstanding issues. It now works as similarly to
the ksz9477 SPI driver as possible, using the same regmap macros.
Add support for ksz9567 to the ksz9477 driver (tested on a board with
ksz9567 connected via I2C).
Remove NET_DSA_TAG_KSZ_COMMON since it's not needed.
Changes since v1:
Put ksz9477_i2c.c includes in alphabetical order.
Added Reviewed-Bys.
George McCollister (2):
net: dsa: microchip: add ksz9567 to ksz9477 driver
net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
Tristram Ha (1):
net: dsa: microchip: add KSZ9477 I2C driver
drivers/net/dsa/microchip/Kconfig | 7 +++
drivers/net/dsa/microchip/Makefile | 1 +
drivers/net/dsa/microchip/ksz9477.c | 9 +++
drivers/net/dsa/microchip/ksz9477_i2c.c | 101 ++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
drivers/net/dsa/microchip/ksz_common.h | 2 +
net/dsa/Kconfig | 9 +--
net/dsa/Makefile | 2 +-
8 files changed, 124 insertions(+), 8 deletions(-)
create mode 100644 drivers/net/dsa/microchip/ksz9477_i2c.c
--
2.11.0
^ permalink raw reply
* [PATCH net-next v2 1/3] net: dsa: microchip: add KSZ9477 I2C driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
From: Tristram Ha <Tristram.Ha@microchip.com>
Add KSZ9477 I2C driver support. The code ksz9477.c and ksz_common.c are
used together to generate the I2C driver.
Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
[george.mccollister@gmail.com: bring up to date, use ksz_common regmap macros]
Signed-off-by: George McCollister <george.mccollister@gmail.com>
---
Changes since v1:
- Adjust order of includes so they are in alphabetical order.
drivers/net/dsa/microchip/Kconfig | 7 +++
drivers/net/dsa/microchip/Makefile | 1 +
drivers/net/dsa/microchip/ksz9477_i2c.c | 100 ++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz_common.h | 2 +
4 files changed, 110 insertions(+)
create mode 100644 drivers/net/dsa/microchip/ksz9477_i2c.c
diff --git a/drivers/net/dsa/microchip/Kconfig b/drivers/net/dsa/microchip/Kconfig
index e1c23d1e91e6..1d7870c6df3c 100644
--- a/drivers/net/dsa/microchip/Kconfig
+++ b/drivers/net/dsa/microchip/Kconfig
@@ -9,6 +9,13 @@ menuconfig NET_DSA_MICROCHIP_KSZ9477
help
This driver adds support for Microchip KSZ9477 switch chips.
+config NET_DSA_MICROCHIP_KSZ9477_I2C
+ tristate "KSZ9477 series I2C connected switch driver"
+ depends on NET_DSA_MICROCHIP_KSZ9477 && I2C
+ select REGMAP_I2C
+ help
+ Select to enable support for registering switches configured through I2C.
+
config NET_DSA_MICROCHIP_KSZ9477_SPI
tristate "KSZ9477 series SPI connected switch driver"
depends on NET_DSA_MICROCHIP_KSZ9477 && SPI
diff --git a/drivers/net/dsa/microchip/Makefile b/drivers/net/dsa/microchip/Makefile
index e3d799b95d7d..929caa81e782 100644
--- a/drivers/net/dsa/microchip/Makefile
+++ b/drivers/net/dsa/microchip/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON) += ksz_common.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477) += ksz9477.o
+obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477_I2C) += ksz9477_i2c.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI) += ksz9477_spi.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ8795) += ksz8795.o
obj-$(CONFIG_NET_DSA_MICROCHIP_KSZ8795_SPI) += ksz8795_spi.o
diff --git a/drivers/net/dsa/microchip/ksz9477_i2c.c b/drivers/net/dsa/microchip/ksz9477_i2c.c
new file mode 100644
index 000000000000..79867cc2474b
--- /dev/null
+++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip KSZ9477 series register access through I2C
+ *
+ * Copyright (C) 2018-2019 Microchip Technology Inc.
+ */
+
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#include "ksz_common.h"
+
+KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
+
+static int ksz9477_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *i2c_id)
+{
+ struct ksz_device *dev;
+ int i, ret;
+
+ dev = ksz_switch_alloc(&i2c->dev, i2c);
+ if (!dev)
+ return -ENOMEM;
+
+ for (i = 0; i < ARRAY_SIZE(ksz9477_regmap_config); i++) {
+ dev->regmap[i] = devm_regmap_init_i2c(i2c,
+ &ksz9477_regmap_config[i]);
+ if (IS_ERR(dev->regmap[i])) {
+ ret = PTR_ERR(dev->regmap[i]);
+ dev_err(&i2c->dev,
+ "Failed to initialize regmap%i: %d\n",
+ ksz9477_regmap_config[i].val_bits, ret);
+ return ret;
+ }
+ }
+
+ if (i2c->dev.platform_data)
+ dev->pdata = i2c->dev.platform_data;
+
+ ret = ksz9477_switch_register(dev);
+
+ /* Main DSA driver may not be started yet. */
+ if (ret)
+ return ret;
+
+ i2c_set_clientdata(i2c, dev);
+
+ return 0;
+}
+
+static int ksz9477_i2c_remove(struct i2c_client *i2c)
+{
+ struct ksz_device *dev = i2c_get_clientdata(i2c);
+
+ ksz_switch_remove(dev);
+
+ return 0;
+}
+
+static void ksz9477_i2c_shutdown(struct i2c_client *i2c)
+{
+ struct ksz_device *dev = i2c_get_clientdata(i2c);
+
+ if (dev && dev->dev_ops->shutdown)
+ dev->dev_ops->shutdown(dev);
+}
+
+static const struct i2c_device_id ksz9477_i2c_id[] = {
+ { "ksz9477-switch", 0 },
+ {},
+};
+
+MODULE_DEVICE_TABLE(i2c, ksz9477_i2c_id);
+
+static const struct of_device_id ksz9477_dt_ids[] = {
+ { .compatible = "microchip,ksz9477" },
+ { .compatible = "microchip,ksz9897" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
+
+static struct i2c_driver ksz9477_i2c_driver = {
+ .driver = {
+ .name = "ksz9477-switch",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ksz9477_dt_ids),
+ },
+ .probe = ksz9477_i2c_probe,
+ .remove = ksz9477_i2c_remove,
+ .shutdown = ksz9477_i2c_shutdown,
+ .id_table = ksz9477_i2c_id,
+};
+
+module_i2c_driver(ksz9477_i2c_driver);
+
+MODULE_AUTHOR("Tristram Ha <Tristram.Ha@microchip.com>");
+MODULE_DESCRIPTION("Microchip KSZ9477 Series Switch I2C access Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 13d027baaa8b..a24d8e61fbe7 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -294,6 +294,8 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
#define KSZ_SPI_OP_RD 3
#define KSZ_SPI_OP_WR 2
+#define swabnot_used(x) 0
+
#define KSZ_SPI_OP_FLAG_MASK(opcode, swp, regbits, regpad) \
swab##swp((opcode) << ((regbits) + (regpad)))
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 2/3] net: dsa: microchip: add ksz9567 to ksz9477 driver
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
ksz9567 is already in the device tree binding documentation.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v1:
- Added Reviewed-by.
drivers/net/dsa/microchip/ksz9477.c | 9 +++++++++
drivers/net/dsa/microchip/ksz9477_i2c.c | 1 +
drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 187be42de5f1..50ffc63d6231 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -1529,6 +1529,15 @@ static const struct ksz_chip_data ksz9477_switch_chips[] = {
.cpu_ports = 0x07, /* can be configured as cpu port */
.port_cnt = 3, /* total port count */
},
+ {
+ .chip_id = 0x00956700,
+ .dev_name = "KSZ9567",
+ .num_vlans = 4096,
+ .num_alus = 4096,
+ .num_statics = 16,
+ .cpu_ports = 0x7F, /* can be configured as cpu port */
+ .port_cnt = 7, /* total physical port count */
+ },
};
static int ksz9477_switch_init(struct ksz_device *dev)
diff --git a/drivers/net/dsa/microchip/ksz9477_i2c.c b/drivers/net/dsa/microchip/ksz9477_i2c.c
index 79867cc2474b..0b1e01f0873d 100644
--- a/drivers/net/dsa/microchip/ksz9477_i2c.c
+++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
@@ -77,6 +77,7 @@ MODULE_DEVICE_TABLE(i2c, ksz9477_i2c_id);
static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9477" },
{ .compatible = "microchip,ksz9897" },
+ { .compatible = "microchip,ksz9567" },
{},
};
MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
diff --git a/drivers/net/dsa/microchip/ksz9477_spi.c b/drivers/net/dsa/microchip/ksz9477_spi.c
index 2e402e4d866f..f4198d6f72be 100644
--- a/drivers/net/dsa/microchip/ksz9477_spi.c
+++ b/drivers/net/dsa/microchip/ksz9477_spi.c
@@ -81,6 +81,7 @@ static const struct of_device_id ksz9477_dt_ids[] = {
{ .compatible = "microchip,ksz9893" },
{ .compatible = "microchip,ksz9563" },
{ .compatible = "microchip,ksz8563" },
+ { .compatible = "microchip,ksz9567" },
{},
};
MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 3/3] net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
From: George McCollister @ 2019-09-10 13:18 UTC (permalink / raw)
To: netdev
Cc: Woojung Huh, Andrew Lunn, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel, George McCollister
In-Reply-To: <20190910131836.114058-1-george.mccollister@gmail.com>
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
NET_DSA_TAG_KSZ. Update the description to mention the three switch
families it supports. No functional change.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes since v1:
- Added Reviewed-by.
net/dsa/Kconfig | 9 ++-------
net/dsa/Makefile | 2 +-
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 2f69d4b53d46..29e2bd5cc5af 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -73,16 +73,11 @@ config NET_DSA_TAG_MTK
Say Y or M if you want to enable support for tagging frames for
Mediatek switches.
-config NET_DSA_TAG_KSZ_COMMON
- tristate
- default n
-
config NET_DSA_TAG_KSZ
- tristate "Tag driver for Microchip 9893 family of switches"
- select NET_DSA_TAG_KSZ_COMMON
+ tristate "Tag driver for Microchip 8795/9477/9893 families of switches"
help
Say Y if you want to enable support for tagging frames for the
- Microchip 9893 family of switches.
+ Microchip 8795/9477/9893 families of switches.
config NET_DSA_TAG_QCA
tristate "Tag driver for Qualcomm Atheros QCA8K switches"
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index c342f54715ba..2c6d286f0511 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_NET_DSA_TAG_BRCM_COMMON) += tag_brcm.o
obj-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o
obj-$(CONFIG_NET_DSA_TAG_EDSA) += tag_edsa.o
obj-$(CONFIG_NET_DSA_TAG_GSWIP) += tag_gswip.o
-obj-$(CONFIG_NET_DSA_TAG_KSZ_COMMON) += tag_ksz.o
+obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
obj-$(CONFIG_NET_DSA_TAG_QCA) += tag_qca.o
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: David Laight @ 2019-09-10 13:19 UTC (permalink / raw)
To: 'Xin Long', network dev, linux-sctp@vger.kernel.org
Cc: Marcelo Ricardo Leitner, Neil Horman, davem@davemloft.net
In-Reply-To: <604e6ac718c29aa5b1a8c4b164a126b82bc42a2f.1568015756.git.lucien.xin@gmail.com>
From: Xin Long
> Sent: 09 September 2019 08:57
> Section 7.2 of rfc7829: "Peer Address Thresholds (SCTP_PEER_ADDR_THLDS)
> Socket Option" extends 'struct sctp_paddrthlds' with 'spt_pathcpthld'
> added to allow a user to change ps_retrans per sock/asoc/transport, as
> other 2 paddrthlds: pf_retrans, pathmaxrxt.
>
> Note that ps_retrans is not allowed to be greater than pf_retrans.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/uapi/linux/sctp.h | 1 +
> net/sctp/socket.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index a15cc28..dfd81e1 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -1069,6 +1069,7 @@ struct sctp_paddrthlds {
> struct sockaddr_storage spt_address;
> __u16 spt_pathmaxrxt;
> __u16 spt_pathpfthld;
> + __u16 spt_pathcpthld;
> };
>
> /*
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5e2098b..5b9774d 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3954,6 +3954,9 @@ static int sctp_setsockopt_paddr_thresholds(struct sock *sk,
This code does:
if (optlen < sizeof(struct sctp_paddrthlds))
return -EINVAL;
So adding an extra field breaks existing application binaries
that use this option.
I've not checked the other patches or similar fubar.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [RFC PATCH 4/4] docs: Sample driver to demonstrate how to implement virtio-mdev framework
From: Jason Wang @ 2019-09-10 13:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <20190910060531-mutt-send-email-mst@kernel.org>
On 2019/9/10 下午6:15, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 04:19:35PM +0800, Jason Wang wrote:
>> This sample driver creates mdev device that simulate virtio net device
>> over virtio mdev transport. The device is implemented through vringh
>> and workqueue.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> samples/Kconfig | 7 +
>> samples/vfio-mdev/Makefile | 1 +
>> samples/vfio-mdev/mvnet.c | 766 +++++++++++++++++++++++++++++++++++++
>> 3 files changed, 774 insertions(+)
>> create mode 100644 samples/vfio-mdev/mvnet.c
> So for a POC, this is a bit too rough to be able to judge
> whether the approach is workable.
> Can you get it a bit more into shape esp wrt UAPI?
Will do, actually I'm not 100% sure it need to go through UAPI.
Technically we can expose them for userspace but do we want something
simpler e.g vhost? Then we can make it as an internal API without caring
about UAPI stuffs like compatibility etc.
Except for UAPI, another other thing that can help you to judge this
approach? E.g we can make the device more reasonable rather than a
simple loopback device, e.g implementing a pair network device. But it
might be too complex for just a sample.
>
>> diff --git a/samples/Kconfig b/samples/Kconfig
>> index c8dacb4dda80..a1a1ca2c00b7 100644
>> --- a/samples/Kconfig
>> +++ b/samples/Kconfig
>> @@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
>> mediated device. It is a simple framebuffer and supports
>> the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
>>
>> +config SAMPLE_VIRTIO_MDEV_NET
>> + tristate "Build virtio mdev net example mediated device sample code -- loadable modules only"
>> + depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
>> + help
>> + Build a networking sample device for use as a virtio
>> + mediated device.
>> +
>> config SAMPLE_VFIO_MDEV_MDPY_FB
>> tristate "Build VFIO mdpy example guest fbdev driver -- loadable module only"
>> depends on FB && m
>> diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
>> index 10d179c4fdeb..f34af90ed0a0 100644
>> --- a/samples/vfio-mdev/Makefile
>> +++ b/samples/vfio-mdev/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
>> obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
>> +obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
>> diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
>> new file mode 100644
>> index 000000000000..da295b41955e
>> --- /dev/null
>> +++ b/samples/vfio-mdev/mvnet.c
>> @@ -0,0 +1,766 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Mediated virtual virtio-net device driver.
>> + *
>> + * Copyright (c) 2019, Red Hat Inc. All rights reserved.
>> + * Author: Jason Wang <jasowang@redhat.com>
>> + *
>> + * Sample driver
>
> Documentation on how to use this?
Will add.
>
>
>> that creates mdev device that simulates ethernet
>> + * device virtio mdev transport.
>
> Well not exactly. What it seems to do is short-circuit
> RX and TX rings.
Yes, a loopback device.
>
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/device.h>
>> +#include <linux/kernel.h>
>> +#include <linux/fs.h>
>> +#include <linux/poll.h>
>> +#include <linux/slab.h>
>> +#include <linux/sched.h>
>> +#include <linux/wait.h>
>> +#include <linux/uuid.h>
>> +#include <linux/iommu.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/file.h>
>> +#include <linux/etherdevice.h>
>> +#include <linux/mdev.h>
>> +#include <uapi/linux/virtio_mdev.h>
>> +
>> +#define VERSION_STRING "0.1"
>> +#define DRIVER_AUTHOR "NVIDIA Corporation"
>> +
>> +#define MVNET_CLASS_NAME "mvnet"
>> +
>> +#define MVNET_NAME "mvnet"
>> +
>> +/*
>> + * Global Structures
>> + */
>> +
>> +static struct mvnet_dev {
>> + struct class *vd_class;
>> + struct idr vd_idr;
>> + struct device dev;
>> +} mvnet_dev;
>> +
>> +struct mvnet_virtqueue {
>> + struct vringh vring;
>> + struct vringh_kiov iov;
>> + unsigned short head;
>> + bool ready;
>> + u32 desc_addr_lo;
>> + u32 desc_addr_hi;
>> + u32 device_addr_lo;
>> + u32 device_addr_hi;
>> + u32 driver_addr_lo;
>> + u32 driver_addr_hi;
>> + u64 desc_addr;
>> + u64 device_addr;
>> + u64 driver_addr;
>> + void *private;
>> + irqreturn_t (*cb)(void *);
>> +};
>> +
>> +#define MVNET_QUEUE_ALIGN PAGE_SIZE
>> +#define MVNET_QUEUE_MAX 256
>> +#define MVNET_MAGIC_VALUE ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)
>> +#define MVNET_VERSION 0x1 /* Implies virtio 1.0 */
>> +#define MVNET_DEVICE_ID 0x1 /* network card */
>> +#define MVNET_VENDOR_ID 0 /* is this correct ? */
>> +#define MVNET_DEVICE_FEATURES VIRTIO_F_VERSION_1
>> +
>> +u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
>> + (1ULL << VIRTIO_F_VERSION_1) |
>> + (1ULL << VIRTIO_F_IOMMU_PLATFORM) ;
>> +
>> +/* State of each mdev device */
>> +struct mvnet_state {
>> + struct mvnet_virtqueue vqs[2];
>> + struct work_struct work;
>> + spinlock_t lock;
>> + struct mdev_device *mdev;
>> + struct virtio_net_config config;
>> + struct virtio_mdev_callback *cbs;
>> + void *buffer;
>> + u32 queue_sel;
>> + u32 driver_features_sel;
>> + u32 driver_features[2];
>> + u32 device_features_sel;
>> + u32 status;
>> + u32 generation;
>> + u32 num;
>> + struct list_head next;
>> +};
>> +
>> +static struct mutex mdev_list_lock;
>> +static struct list_head mdev_devices_list;
>> +
>> +static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned idx)
>> +{
>> + struct mvnet_virtqueue *vq = &mvnet->vqs[idx];
>> + int ret;
>> +
>> + vq->desc_addr = (u64)vq->desc_addr_hi << 32 | vq->desc_addr_lo;
>> + vq->device_addr = (u64)vq->device_addr_hi << 32 | vq->device_addr_lo;
>> + vq->driver_addr = (u64)vq->driver_addr_hi << 32 | vq->driver_addr_lo;
>> +
>> + ret = vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
>> + false, (struct vring_desc *)vq->desc_addr,
>> + (struct vring_avail *)vq->driver_addr,
>> + (struct vring_used *)vq->device_addr);
>> +}
>> +
>> +static ssize_t mvnet_read_config(struct mdev_device *mdev,
>> + u32 *val, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct mvnet_virtqueue *vq;
>> + u32 queue_sel;
>> +
>> + if (!mdev || !val)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + queue_sel = mvnet->queue_sel;
>> + vq = &mvnet->vqs[queue_sel];
>> +
>> + switch (pos) {
>> + case VIRTIO_MDEV_MAGIC_VALUE:
>> + *val = MVNET_MAGIC_VALUE;
>> + break;
>> + case VIRTIO_MDEV_VERSION:
>> + *val = MVNET_VERSION;
>> + break;
>> + case VIRTIO_MDEV_DEVICE_ID:
>> + *val = MVNET_DEVICE_ID;
>> + break;
>> + case VIRTIO_MDEV_VENDOR_ID:
>> + *val = MVNET_VENDOR_ID;
>> + break;
>> + case VIRTIO_MDEV_DEVICE_FEATURES:
>> + if (mvnet->device_features_sel)
>> + *val = mvnet_features >> 32;
>> + else
>> + *val = mvnet_features;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NUM_MAX:
>> + *val = MVNET_QUEUE_MAX;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_READY:
>> + *val = vq->ready;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_ALIGN:
>> + *val = MVNET_QUEUE_ALIGN;
>> + break;
>> + case VIRTIO_MDEV_STATUS:
>> + *val = mvnet->status;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_LOW:
>> + *val = vq->desc_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_HIGH:
>> + *val = vq->desc_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_LOW:
>> + *val = vq->driver_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_HIGH:
>> + *val = vq->driver_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_LOW:
>> + *val = vq->device_addr_lo;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_HIGH:
>> + *val = vq->device_addr_hi;
>> + break;
>> + case VIRTIO_MDEV_CONFIG_GENERATION:
>> + *val = 1;
>> + break;
>> + default:
>> + pr_err("Unsupported mdev read offset at 0x%x\n", pos);
>> + break;
>> + }
>> +
>> + return 4;
>> +}
>> +
>> +static ssize_t mvnet_read_net_config(struct mdev_device *mdev,
>> + char *buf, size_t count, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet = mdev_get_drvdata(mdev);
>> +
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + if (pos + count > sizeof(mvnet->config))
>> + return -EINVAL;
>> +
>> + memcpy(buf, &mvnet->config + (unsigned)pos, count);
>> +
>> + return count;
>> +}
>> +
>> +static void mvnet_vq_reset(struct mvnet_virtqueue *vq)
>> +{
>> + vq->ready = 0;
>> + vq->desc_addr_lo = vq->desc_addr_hi = 0;
>> + vq->device_addr_lo = vq->device_addr_hi = 0;
>> + vq->driver_addr_lo = vq->driver_addr_hi = 0;
>> + vq->desc_addr = 0;
>> + vq->driver_addr = 0;
>> + vq->device_addr = 0;
>> + vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
>> + false, 0, 0, 0);
>> +}
>> +
>> +static void mvnet_reset(struct mvnet_state *mvnet)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < 2; i++)
>> + mvnet_vq_reset(&mvnet->vqs[i]);
>> +
>> + mvnet->queue_sel = 0;
>> + mvnet->driver_features_sel = 0;
>> + mvnet->device_features_sel = 0;
>> + mvnet->status = 0;
>> + ++mvnet->generation;
>> +}
>> +
>> +static ssize_t mvnet_write_config(struct mdev_device *mdev,
>> + u32 *val, loff_t pos)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct mvnet_virtqueue *vq;
>> + u32 queue_sel;
>> +
>> + if (!mdev || !val)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet) {
>> + pr_err("%s mvnet not found\n", __func__);
>> + return -EINVAL;
>> + }
>> +
>> + queue_sel = mvnet->queue_sel;
>> + vq = &mvnet->vqs[queue_sel];
>> +
>> + switch (pos) {
>> + case VIRTIO_MDEV_DEVICE_FEATURES_SEL:
>> + mvnet->device_features_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_DRIVER_FEATURES:
>> + mvnet->driver_features[mvnet->driver_features_sel] = *val;
>> + break;
>> + case VIRTIO_MDEV_DRIVER_FEATURES_SEL:
>> + mvnet->driver_features_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_SEL:
>> + mvnet->queue_sel = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NUM:
>> + mvnet->num = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_READY:
>> + vq->ready = *val;
>> + if (vq->ready) {
>> + spin_lock(&mvnet->lock);
>> + mvnet_queue_ready(mvnet, queue_sel);
>> + spin_unlock(&mvnet->lock);
>> + }
>> + break;
>> + case VIRTIO_MDEV_QUEUE_NOTIFY:
>> + if (vq->ready)
>> + schedule_work(&mvnet->work);
>> + break;
>> + case VIRTIO_MDEV_STATUS:
>> + mvnet->status = *val;
>> + if (*val == 0) {
>> + spin_lock(&mvnet->lock);
>> + mvnet_reset(mvnet);
>> + spin_unlock(&mvnet->lock);
>> + }
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_LOW:
>> + vq->desc_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_DESC_HIGH:
>> + vq->desc_addr_hi = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_LOW:
>> + vq->driver_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_AVAIL_HIGH:
>> + vq->driver_addr_hi = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_LOW:
>> + vq->device_addr_lo = *val;
>> + break;
>> + case VIRTIO_MDEV_QUEUE_USED_HIGH:
>> + vq->device_addr_hi = *val;
>> + break;
>> + default:
>> + pr_err("Unsupported write offset! 0x%x\n", pos);
>> + break;
>> + }
>> + spin_unlock(&mvnet->lock);
>> +
>> + return 4;
>> +}
>> +
>> +static void mvnet_work(struct work_struct *work)
>> +{
>> + struct mvnet_state *mvnet = container_of(work, struct
>> + mvnet_state, work);
>> + struct mvnet_virtqueue *txq = &mvnet->vqs[1];
>> + struct mvnet_virtqueue *rxq = &mvnet->vqs[0];
>> + size_t read, write, total_write;
>> + unsigned long flags;
>> + int err;
>> + int pkts = 0;
>> +
>> + spin_lock(&mvnet->lock);
>> +
>> + if (!txq->ready || !rxq->ready)
>> + goto out;
>> +
>> + while (true) {
>> + total_write = 0;
>> + err = vringh_getdesc_kern(&txq->vring, &txq->iov, NULL,
>> + &txq->head, GFP_KERNEL);
>> + if (err <= 0)
>> + break;
>> +
>> + err = vringh_getdesc_kern(&rxq->vring, NULL, &rxq->iov,
>> + &rxq->head, GFP_KERNEL);
>
> GFP_KERNEL under a spin_lock will cause deadlocks.
Will fix.
>
>
>> + if (err <= 0) {
>> + vringh_complete_kern(&txq->vring, txq->head, 0);
>> + break;
>> + }
>> +
>> + while (true) {
>> + read = vringh_iov_pull_kern(&txq->iov, mvnet->buffer,
>> + PAGE_SIZE);
>> + if (read <= 0)
>> + break;
>> +
>> + write = vringh_iov_push_kern(&rxq->iov, mvnet->buffer,
>> + read);
>> + if (write <= 0)
>> + break;
>> +
>> + total_write += write;
>> + }
>> +
>> + /* Make sure data is wrote before advancing index */
>> + smp_wmb();
>> +
>> + vringh_complete_kern(&txq->vring, txq->head, 0);
>> + vringh_complete_kern(&rxq->vring, rxq->head, total_write);
>> +
>> + /* Make sure used is visible before rasing the
>> + interrupt */
>> + smp_wmb();
>> +
>> + local_bh_disable();
>> + if (txq->cb)
>> + txq->cb(txq->private);
>> + if (rxq->cb)
>> + rxq->cb(rxq->private);
>> + local_bh_enable();
>> +
>> + pkts ++;
> coding style problem
Will fix.
>
>> + if (pkts > 4) {
>> + schedule_work(&mvnet->work);
>> + goto out;
>> + }
>> + }
>> +
>> +out:
>> + spin_unlock(&mvnet->lock);
>> +}
>> +
>> +static dma_addr_t mvnet_map_page(struct device *dev, struct page *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + /* Vringh can only use VA */
>> + return page_address(page) + offset;
>> +}
>> +
>> +static void mvnet_unmap_page(struct device *dev, dma_addr_t dma_addr,
>> + size_t size, enum dma_data_direction dir,
>> + unsigned long attrs)
>> +{
>> + return ;
>> +}
>> +
>> +static void *mvnet_alloc_coherent(struct device *dev, size_t size,
>> + dma_addr_t *dma_addr, gfp_t flag,
>> + unsigned long attrs)
>> +{
>> + void *ret = kmalloc(size, flag);
>> +
>> + if (ret == NULL)
> !ret is nicer
Yes.
>
>> + *dma_addr = DMA_MAPPING_ERROR;
>> + else
>> + *dma_addr = ret;
> Not sure how does this build ... don't we need a cast?
It builds but will fix for sure.
>
>> +
>> + return ret;
>> +}
>> +
>> +static void mvnet_free_coherent(struct device *dev, size_t size,
>> + void *vaddr, dma_addr_t dma_addr,
>> + unsigned long attrs)
>> +{
>> + kfree(dma_addr);
>> +}
>> +
>> +static const struct dma_map_ops mvnet_dma_ops = {
>> + .map_page = mvnet_map_page,
>> + .unmap_page = mvnet_unmap_page,
>> + .alloc = mvnet_alloc_coherent,
>> + .free = mvnet_free_coherent,
>> +};
>> +
>> +static int mvnet_create(struct kobject *kobj, struct mdev_device *mdev)
>> +{
>> + struct mvnet_state *mvnet;
>> + struct virtio_net_config *config;
>> +
>> + if (!mdev)
>> + return -EINVAL;
>> +
>> + mvnet = kzalloc(sizeof(struct mvnet_state), GFP_KERNEL);
>> + if (mvnet == NULL)
>> + return -ENOMEM;
>> +
>> + mvnet->buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
>> + if (!mvnet->buffer) {
>> + kfree(mvnet);
>> + return -ENOMEM;
>> + }
>> +
>> + config = &mvnet->config;
>> + config->mtu = 1500;
>> + config->status = VIRTIO_NET_S_LINK_UP;
>> + eth_random_addr(config->mac);
>> +
>> + INIT_WORK(&mvnet->work, mvnet_work);
>> +
>> + spin_lock_init(&mvnet->lock);
>> + mvnet->mdev = mdev;
>> + mdev_set_drvdata(mdev, mvnet);
>> +
>> + mutex_lock(&mdev_list_lock);
>> + list_add(&mvnet->next, &mdev_devices_list);
>> + mutex_unlock(&mdev_list_lock);
>> +
>> + mdev_set_dma_ops(mdev, &mvnet_dma_ops);
>> +
>> + return 0;
>> +}
>> +
>> +static int mvnet_remove(struct mdev_device *mdev)
>> +{
>> + struct mvnet_state *mds, *tmp_mds;
>> + struct mvnet_state *mvnet = mdev_get_drvdata(mdev);
>> + int ret = -EINVAL;
>> +
>> + mutex_lock(&mdev_list_lock);
>> + list_for_each_entry_safe(mds, tmp_mds, &mdev_devices_list, next) {
>> + if (mvnet == mds) {
>> + list_del(&mvnet->next);
>> + mdev_set_drvdata(mdev, NULL);
>> + kfree(mvnet->buffer);
>> + kfree(mvnet);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&mdev_list_lock);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t mvnet_read(struct mdev_device *mdev, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + ssize_t ret;
>> +
>> + if (*ppos < VIRTIO_MDEV_CONFIG) {
>> + if (count == 4)
>> + ret = mvnet_read_config(mdev, (u32 *)buf, *ppos);
>> + else
>> + ret = -EINVAL;
>> + *ppos += 4;
>> + } else if (*ppos < VIRTIO_MDEV_CONFIG + sizeof(struct virtio_net_config)) {
>> + ret = mvnet_read_net_config(mdev, buf, count,
>> + *ppos - VIRTIO_MDEV_CONFIG);
>> + *ppos += count;
>> + } else {
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t mvnet_write(struct mdev_device *mdev, const char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + int ret;
>> +
>> + if (*ppos < VIRTIO_MDEV_CONFIG) {
>> + if (count == 4)
>> + ret = mvnet_write_config(mdev, (u32 *)buf, *ppos);
>> + else
>> + ret = -EINVAL;
>> + *ppos += 4;
>> + } else {
>> + /* No writable net config */
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static long mvnet_ioctl(struct mdev_device *mdev, unsigned int cmd,
>> + unsigned long arg)
>> +{
>> + int ret = 0;
>> + struct mvnet_state *mvnet;
>> + struct virtio_mdev_callback *cb;
>> +
>> + if (!mdev)
>> + return -EINVAL;
>> +
>> + mvnet = mdev_get_drvdata(mdev);
>> + if (!mvnet)
>> + return -ENODEV;
>> +
>> + spin_lock(&mvnet->lock);
>> +
>> + switch (cmd) {
>> + case VIRTIO_MDEV_SET_VQ_CALLBACK:
>> + cb = (struct virtio_mdev_callback *)arg;
>> + mvnet->vqs[mvnet->queue_sel].cb = cb->callback;
>> + mvnet->vqs[mvnet->queue_sel].private = cb->private;
>> + break;
>> + case VIRTIO_MDEV_SET_CONFIG_CALLBACK:
>> + break;
> success, but nothing happens.
Because the device never raise any config interrupt.
>
>> + default:
>> + pr_err("Not supportted ioctl cmd 0x%x\n", cmd);
>> + ret = -ENOTTY;
>> + break;
>> + }
>> +
>> + spin_unlock(&mvnet->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int mvnet_open(struct mdev_device *mdev)
>> +{
>> + pr_info("%s\n", __func__);
>> + return 0;
>> +}
>> +
>> +static void mvnet_close(struct mdev_device *mdev)
>> +{
>> + pr_info("%s\n", __func__);
>> +}
>> +
>> +static ssize_t
>> +sample_mvnet_dev_show(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + return sprintf(buf, "This is phy device\n");
>
> what's this?
Will remove, copy&paste error from mtty.c.
>
>> +}
>> +
>> +static DEVICE_ATTR_RO(sample_mvnet_dev);
>> +
>> +static struct attribute *mvnet_dev_attrs[] = {
>> + &dev_attr_sample_mvnet_dev.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group mvnet_dev_group = {
>> + .name = "mvnet_dev",
>> + .attrs = mvnet_dev_attrs,
>> +};
>> +
>> +static const struct attribute_group *mvnet_dev_groups[] = {
>> + &mvnet_dev_group,
>> + NULL,
>> +};
>> +
>> +static ssize_t
>> +sample_mdev_dev_show(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + if (mdev_from_dev(dev))
>> + return sprintf(buf, "This is MDEV %s\n", dev_name(dev));
>> +
>> + return sprintf(buf, "\n");
>> +}
>> +
>> +static DEVICE_ATTR_RO(sample_mdev_dev);
>> +
>> +static struct attribute *mdev_dev_attrs[] = {
>> + &dev_attr_sample_mdev_dev.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group mdev_dev_group = {
>> + .name = "vendor",
>> + .attrs = mdev_dev_attrs,
>> +};
>> +
>> +static const struct attribute_group *mdev_dev_groups[] = {
>> + &mdev_dev_group,
>> + NULL,
>> +};
>> +
>> +#define MVNET_STRING_LEN 16
>> +
>> +static ssize_t
>> +name_show(struct kobject *kobj, struct device *dev, char *buf)
>> +{
>> + char name[MVNET_STRING_LEN];
>> + const char *name_str = "virtio-net";
>> +
>> + snprintf(name, MVNET_STRING_LEN, "%s", dev_driver_string(dev));
>> + if (!strcmp(kobj->name, name))
>> + return sprintf(buf, "%s\n", name_str);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(name);
>> +
>> +static ssize_t
>> +available_instances_show(struct kobject *kobj, struct device *dev, char *buf)
>> +{
>> + return sprintf(buf, "%d\n", INT_MAX);
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(available_instances);
>
> ?
It used to demonstrate how many available instances that could be
created for this device. We don't have such limitation for software.
Thanks
>
>> +
>> +static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
>> + char *buf)
>> +{
>> + return sprintf(buf, "%s\n", VIRTIO_MDEV_DEVICE_API_STRING);
>> +}
>> +
>> +static MDEV_TYPE_ATTR_RO(device_api);
>> +
>> +static struct attribute *mdev_types_attrs[] = {
>> + &mdev_type_attr_name.attr,
>> + &mdev_type_attr_device_api.attr,
>> + &mdev_type_attr_available_instances.attr,
>> + NULL,
>> +};
>> +
>> +static struct attribute_group mdev_type_group = {
>> + .name = "",
>> + .attrs = mdev_types_attrs,
>> +};
>> +
>> +static struct attribute_group *mdev_type_groups[] = {
>> + &mdev_type_group,
>> + NULL,
>> +};
>> +
>> +static const struct mdev_parent_ops mdev_fops = {
>> + .owner = THIS_MODULE,
>> + .dev_attr_groups = mvnet_dev_groups,
>> + .mdev_attr_groups = mdev_dev_groups,
>> + .supported_type_groups = mdev_type_groups,
>> + .create = mvnet_create,
>> + .remove = mvnet_remove,
>> + .open = mvnet_open,
>> + .release = mvnet_close,
>> + .read = mvnet_read,
>> + .write = mvnet_write,
>> + .ioctl = mvnet_ioctl,
>> +};
>> +
>> +static void mvnet_device_release(struct device *dev)
>> +{
>> + dev_dbg(dev, "mvnet: released\n");
>> +}
>> +
>> +static int __init mvnet_dev_init(void)
>> +{
>> + int ret = 0;
>> +
>> + pr_info("mvnet_dev: %s\n", __func__);
>> +
>> + memset(&mvnet_dev, 0, sizeof(mvnet_dev));
>> +
>> + idr_init(&mvnet_dev.vd_idr);
>> +
>> + mvnet_dev.vd_class = class_create(THIS_MODULE, MVNET_CLASS_NAME);
>> +
>> + if (IS_ERR(mvnet_dev.vd_class)) {
>> + pr_err("Error: failed to register mvnet_dev class\n");
>> + ret = PTR_ERR(mvnet_dev.vd_class);
>> + goto failed1;
>> + }
>> +
>> + mvnet_dev.dev.class = mvnet_dev.vd_class;
>> + mvnet_dev.dev.release = mvnet_device_release;
>> + dev_set_name(&mvnet_dev.dev, "%s", MVNET_NAME);
>> +
>> + ret = device_register(&mvnet_dev.dev);
>> + if (ret)
>> + goto failed2;
>> +
>> + ret = mdev_register_device(&mvnet_dev.dev, &mdev_fops);
>> + if (ret)
>> + goto failed3;
>> +
>> + mutex_init(&mdev_list_lock);
>> + INIT_LIST_HEAD(&mdev_devices_list);
>> +
>> + goto all_done;
>> +
>> +failed3:
>> +
>> + device_unregister(&mvnet_dev.dev);
>> +failed2:
>> + class_destroy(mvnet_dev.vd_class);
>> +
>> +failed1:
>> +all_done:
>> + return ret;
>> +}
>> +
>> +static void __exit mvnet_dev_exit(void)
>> +{
>> + mvnet_dev.dev.bus = NULL;
>> + mdev_unregister_device(&mvnet_dev.dev);
>> +
>> + device_unregister(&mvnet_dev.dev);
>> + idr_destroy(&mvnet_dev.vd_idr);
>> + class_destroy(mvnet_dev.vd_class);
>> + mvnet_dev.vd_class = NULL;
>> + pr_info("mvnet_dev: Unloaded!\n");
>> +}
>> +
>> +module_init(mvnet_dev_init)
>> +module_exit(mvnet_dev_exit)
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_INFO(supported, "Test driver that simulate serial port over PCI");
>> +MODULE_VERSION(VERSION_STRING);
>> +MODULE_AUTHOR(DRIVER_AUTHOR);
>> --
>> 2.19.1
^ permalink raw reply
* Re: [PATCH] ath9k: Remove unneeded variable to store return value
From: Kalle Valo @ 2019-09-10 13:26 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, linux-wireless, zhongjiang, netdev, linux-kernel
In-Reply-To: <1567579428-16377-1-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> ath9k_reg_rmw_single do not need return value to cope with different
> cases. And change functon return type to void.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
45f09a1c5b85 ath9k: Remove unneeded variable to store return value
--
https://patchwork.kernel.org/patch/11129449/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k_htc: release allocated buffer if timed out
From: Kalle Valo @ 2019-09-10 13:29 UTC (permalink / raw)
To: Navid Emamdoost
In-Reply-To: <20190906182604.9282-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> In htc_config_pipe_credits, htc_setup_complete, and htc_connect_service
> if time out happens, the allocated buffer needs to be released.
> Otherwise there will be memory leak.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
853acf7caf10 ath9k_htc: release allocated buffer if timed out
--
https://patchwork.kernel.org/patch/11135781/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: release allocated buffer if timed out
From: Kalle Valo @ 2019-09-10 13:32 UTC (permalink / raw)
To: Navid Emamdoost
In-Reply-To: <20190906185931.19288-1-navid.emamdoost@gmail.com>
Navid Emamdoost <navid.emamdoost@gmail.com> wrote:
> In ath9k_wmi_cmd, the allocated network buffer needs to be released
> if timeout happens. Otherwise memory will be leaked.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
728c1e2a05e4 ath9k: release allocated buffer if timed out
--
https://patchwork.kernel.org/patch/11135843/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH 3/4] virtio: introudce a mdev based transport
From: Michael S. Tsirkin @ 2019-09-10 13:52 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, virtualization, netdev, linux-kernel, kwankhede,
alex.williamson, cohuck, tiwei.bie, maxime.coquelin,
cunming.liang, zhihong.wang, rob.miller, idos, xiao.w.wang,
haotian.wang
In-Reply-To: <572ffc34-3081-8503-d3cc-192edc9b5311@redhat.com>
On Tue, Sep 10, 2019 at 09:13:02PM +0800, Jason Wang wrote:
>
> On 2019/9/10 下午6:01, Michael S. Tsirkin wrote:
> > > +#ifndef _LINUX_VIRTIO_MDEV_H
> > > +#define _LINUX_VIRTIO_MDEV_H
> > > +
> > > +#include <linux/interrupt.h>
> > > +#include <linux/vringh.h>
> > > +#include <uapi/linux/virtio_net.h>
> > > +
> > > +/*
> > > + * Ioctls
> > > + */
> > Pls add a bit more content here. It's redundant to state these
> > are ioctls. Much better to document what does each one do.
>
>
> Ok.
>
>
> >
> > > +
> > > +struct virtio_mdev_callback {
> > > + irqreturn_t (*callback)(void *);
> > > + void *private;
> > > +};
> > > +
> > > +#define VIRTIO_MDEV 0xAF
> > > +#define VIRTIO_MDEV_SET_VQ_CALLBACK _IOW(VIRTIO_MDEV, 0x00, \
> > > + struct virtio_mdev_callback)
> > > +#define VIRTIO_MDEV_SET_CONFIG_CALLBACK _IOW(VIRTIO_MDEV, 0x01, \
> > > + struct virtio_mdev_callback)
> > Function pointer in an ioctl parameter? How does this ever make sense?
>
>
> I admit this is hacky (casting).
>
>
> > And can't we use a couple of registers for this, and avoid ioctls?
>
>
> Yes, how about something like interrupt numbers for each virtqueue and
> config?
Should we just reuse VIRTIO_PCI_COMMON_Q_XXX then?
>
> >
> > > +
> > > +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
> > > +
> > > +/*
> > > + * Control registers
> > > + */
> > > +
> > > +/* Magic value ("virt" string) - Read Only */
> > > +#define VIRTIO_MDEV_MAGIC_VALUE 0x000
> > > +
> > > +/* Virtio device version - Read Only */
> > > +#define VIRTIO_MDEV_VERSION 0x004
> > > +
> > > +/* Virtio device ID - Read Only */
> > > +#define VIRTIO_MDEV_DEVICE_ID 0x008
> > > +
> > > +/* Virtio vendor ID - Read Only */
> > > +#define VIRTIO_MDEV_VENDOR_ID 0x00c
> > > +
> > > +/* Bitmask of the features supported by the device (host)
> > > + * (32 bits per set) - Read Only */
> > > +#define VIRTIO_MDEV_DEVICE_FEATURES 0x010
> > > +
> > > +/* Device (host) features set selector - Write Only */
> > > +#define VIRTIO_MDEV_DEVICE_FEATURES_SEL 0x014
> > > +
> > > +/* Bitmask of features activated by the driver (guest)
> > > + * (32 bits per set) - Write Only */
> > > +#define VIRTIO_MDEV_DRIVER_FEATURES 0x020
> > > +
> > > +/* Activated features set selector - Write Only */
> > > +#define VIRTIO_MDEV_DRIVER_FEATURES_SEL 0x024
> > > +
> > > +/* Queue selector - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_SEL 0x030
> > > +
> > > +/* Maximum size of the currently selected queue - Read Only */
> > > +#define VIRTIO_MDEV_QUEUE_NUM_MAX 0x034
> > > +
> > > +/* Queue size for the currently selected queue - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_NUM 0x038
> > > +
> > > +/* Ready bit for the currently selected queue - Read Write */
> > > +#define VIRTIO_MDEV_QUEUE_READY 0x044
> > Is this same as started?
>
>
> Do you mean "status"?
I really meant "enabled", didn't remember the correct name.
As in: VIRTIO_PCI_COMMON_Q_ENABLE
>
> >
> > > +
> > > +/* Alignment of virtqueue - Read Only */
> > > +#define VIRTIO_MDEV_QUEUE_ALIGN 0x048
> > > +
> > > +/* Queue notifier - Write Only */
> > > +#define VIRTIO_MDEV_QUEUE_NOTIFY 0x050
> > > +
> > > +/* Device status register - Read Write */
> > > +#define VIRTIO_MDEV_STATUS 0x060
> > > +
> > > +/* Selected queue's Descriptor Table address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_DESC_LOW 0x080
> > > +#define VIRTIO_MDEV_QUEUE_DESC_HIGH 0x084
> > > +
> > > +/* Selected queue's Available Ring address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_AVAIL_LOW 0x090
> > > +#define VIRTIO_MDEV_QUEUE_AVAIL_HIGH 0x094
> > > +
> > > +/* Selected queue's Used Ring address, 64 bits in two halves */
> > > +#define VIRTIO_MDEV_QUEUE_USED_LOW 0x0a0
> > > +#define VIRTIO_MDEV_QUEUE_USED_HIGH 0x0a4
> > > +
> > > +/* Configuration atomicity value */
> > > +#define VIRTIO_MDEV_CONFIG_GENERATION 0x0fc
> > > +
> > > +/* The config space is defined by each driver as
> > > + * the per-driver configuration space - Read Write */
> > > +#define VIRTIO_MDEV_CONFIG 0x100
> > Mixing device and generic config space is what virtio pci did,
> > caused lots of problems with extensions.
> > It would be better to reserve much more space.
>
>
> I see, will do this.
>
> Thanks
>
>
> >
> >
> > > +
> > > +#endif
> > > +
> > > +
> > > +/* Ready bit for the currently selected queue - Read Write */
> > > --
> > > 2.19.1
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Thierry Reding @ 2019-09-10 13:54 UTC (permalink / raw)
To: Jose Abreu
Cc: David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Jon Hunter, Bitan Biswas, netdev@vger.kernel.org,
linux-tegra@vger.kernel.org
In-Reply-To: <BN8PR12MB3266850280A788D41C277B08D3B60@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
On Tue, Sep 10, 2019 at 08:32:38AM +0000, Jose Abreu wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Sep/09/2019, 20:11:27 (UTC+00:00)
>
> > On Mon, Sep 09, 2019 at 04:07:04PM +0000, Jose Abreu wrote:
> > > From: Thierry Reding <thierry.reding@gmail.com>
> > > Date: Sep/09/2019, 16:25:45 (UTC+00:00)
> > >
> > > > @@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
> > > > int fixed_burst;
> > > > int mixed_burst;
> > > > bool aal;
> > > > + bool eame;
> > >
> > > bools should not be used in struct's, please change to int.
> >
> > Huh? Since when? "aal" right above it is also bool. Can you provide a
> > specific rationale for why we shouldn't use bool in structs?
>
> Please see https://lkml.org/lkml/2017/11/21/384.
The context is slightly different here. stmmac_dma_cfg exists once for
each of these ethernet devices in the system, and I would assume that in
the vast majority of cases there's exactly one such device in the system
so the potential size increase is very small. On the other hand, there
are potentially very many struct sched_dl_entity, so the size impact is
multiplied.
Anyway, if you insist I'll rewrite this to use an unsigned int bitfield.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: dsa: microchip: add KSZ9477 I2C driver
From: Andrew Lunn @ 2019-09-10 14:03 UTC (permalink / raw)
To: George McCollister
Cc: netdev, Woojung Huh, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-2-george.mccollister@gmail.com>
Hi George
> +KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
> +
> @@ -294,6 +294,8 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
> #define KSZ_SPI_OP_RD 3
> #define KSZ_SPI_OP_WR 2
>
> +#define swabnot_used(x) 0
> +
> #define KSZ_SPI_OP_FLAG_MASK(opcode, swp, regbits, regpad) \
> swab##swp((opcode) << ((regbits) + (regpad)))
There seems to be quite a lot of macro magic here which is not
obvious. Can this be simplified or made more obvious?
Andrew
^ permalink raw reply
* Re: VRF Issue Since kernel 5
From: Gowen @ 2019-09-10 14:22 UTC (permalink / raw)
To: Alexis Bauvin; +Cc: netdev@vger.kernel.org
In-Reply-To: <CWLP265MB1554989CAA2DB59B6862A6A2FDB70@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
Hi Alexis,
I enabled the target TRACE and found that the packet is passing through the security table - which I thought was for SELinux only. As far as I can tell the config is working, is being seen by iptables nut for some reason is not getting accepted by the local process - which isn't right surely. Debugs below from TRACE for the 91.0.0.0/8 subnet for the updates
Sep 10 13:50:37 NETM06 kernel: [442740.425992] TRACE: raw:PREROUTING:policy:2 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426045] TRACE: filter:INPUT:rule:1 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426060] TRACE: security:INPUT:rule:1 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Sep 10 13:50:37 NETM06 kernel: [442740.426108] TRACE: security:INPUT:policy:2 IN=mgmt-vrf OUT= MAC=00:22:48:07:cc:ad:74:83:ef:a9:ca:c1:08:00 SRC=91.189.88.24 DST=10.24.12.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=40164 SEQ=2210516855 ACK=3954601288 WINDOW=28960 RES=0x00 ACK SYN URGP=0 OPT (0204058A0402080AD622157697AC236D01030307)
Admin@NETM06:~$ sudo iptables -L PREROUTING -t raw -n -v
Chain PREROUTING (policy ACCEPT 56061 packets, 5260K bytes)
pkts bytes target prot opt in out source destination
296 16480 TRACE tcp -- mgmt-vrf * 91.0.0.0/8 0.0.0.0/0 ctstate RELATED,ESTABLISHED tcp spt:80
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 330 18260 ACCEPT tcp -- mgmt-vrf * 91.0.0.0/8 0.0.0.0/0 ctstate RELATED,ESTABLISHED tcp spt:80
Admin@NETM06:~$ sudo iptables -L -t security -n -v --line-numbers
Chain INPUT (policy ACCEPT 4190 packets, 371K bytes)
num pkts bytes target prot opt in out source destination
1 248 13980 LOG all -- * * 91.0.0.0/8 0.0.0.0/0 LOG flags 0 level 4 prefix "LOG-SECURITY"
From: Gowen
Sent: 09 September 2019 20:43
To: Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: RE: VRF Issue Since kernel 5
Hi alexis,
I did this earlier today and no change.
I’ll look at trying to see if the return traffic is hitting the INPUT table tomorrow with some conntrack rules and see if it hits any of those rules. If not then do you have any hints/techniques I can use to find the source of the issue?
Gareth
-----Original Message-----
From: Alexis Bauvin <abauvin@online.net>
Sent: 09 September 2019 13:02
To: Gowen <gowen@potatocomputing.co.uk>
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
Hi,
I guess all routing from the management VRF itself is working correctly (i.e. cURLing an IP from this VRF or digging any DNS), and it is your route leakage that’s at fault.
Could you try swapping the local and l3mdev rules?
`ip rule del pref 0; ip rule add from all lookup local pref 1001`
I faced security issues and behavioral weirdnesses from the default kernel rule ordering regarding the default vrf.
Alexis
> Le 9 sept. 2019 à 12:53, Gowen <gowen@potatocomputing.co.uk> a écrit :
>
> Hi Alexis,
>
> Admin@NETM06:~$ sysctl net.ipv4.tcp_l3mdev_accept
> net.ipv4.tcp_l3mdev_accept = 1
>
> Admin@NETM06:~$ sudo ip vrf exec mgmt-vrf curl kernel.org
> curl: (6) Could not resolve host: kernel.org
>
> the failure to resolve is the same with all DNS lookups from any
> process I've run
>
> The route is there from the guide I originally used, I can't remember
> the purpose but I know I don't need it - I've removed it now and no
> change
>
> Admin@NETM06:~$ ip rule show
> 0: from all lookup local
> 1000: from all lookup [l3mdev-table]
> 32766: from all lookup main
> 32767: from all lookup default
>
> I could switch the VRFs over, but this is a test-box and i have prod boxes on this as well so not so keen on that if I can avoid it.
>
> From what I can speculate, because the TCP return traffic is met with an RST, it looks like it may be something to do with iptables - but even if I set the policy to ACCEPT and flush all the rules, the behaviour remains the same.
>
> Is it possible that the TCP stack isn't aware of the session (as is mapped to wrong VRF internally or something to that effect) and is therefore sending the RST?
>
> Gareth
> From: Alexis Bauvin <abauvin@online.net>
> Sent: 09 September 2019 10:28
> To: Gowen <gowen@potatocomputing.co.uk>
> Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
> Subject: Re: VRF Issue Since kernel 5
>
> Hi,
>
> There has been some changes regarding VRF isolation in Linux 5 IIRC,
> namely proper isolation of the default VRF.
>
> Some things you may try:
>
> - looking at the l3mdev_accept sysctls (e.g.
> `net.ipv4.tcp_l3mdev_accept`)
> - querying stuff from the management vrf through `ip vrf exec vrf-mgmt <stuff>`
> e.g. `ip vrf exec vrf-mgmt curl kernel.org`
> `ip vrf exec vrf-mgmt dig @1.1.1.1 kernel.org`
> - reversing your logic: default VRF is your management one, the other one is for your
> other boxes
>
> Also, your `unreachable default metric 4278198272` route looks odd to me.
>
> What are your routing rules? (`ip rule`)
>
> Alexis
>
> > Le 9 sept. 2019 à 09:46, Gowen <gowen@potatocomputing.co.uk> a écrit :
> >
> > Hi there,
> >
> > Dave A said this was the mailer to send this to:
> >
> >
> > I’ve been using my management interface in a VRF for several months now and it’s worked perfectly – I’ve been able to update/upgrade the packages just fine and iptables works excellently with it – exactly as I needed.
> >
> >
> > Since Kernel 5 though I am no longer able to update – but the issue
> > is quite a curious one as some traffic appears to be fine (DNS
> > lookups use VRF correctly) but others don’t (updating/upgrading the
> > packages)
> >
> >
> > I have on this device 2 interfaces:
> > Eth0 for management – inbound SSH, DNS, updates/upgrades
> > Eth1 for managing other boxes (ansible using SSH)
> >
> >
> > Link and addr info shown below:
> >
> >
> > Admin@NETM06:~$ ip link show
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master mgmt-vrf state UP mode DEFAULT group default qlen 1000
> > link/ether 00:22:48:07:cc:ad brd ff:ff:ff:ff:ff:ff
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
> > link/ether 00:22:48:07:c9:6c brd ff:ff:ff:ff:ff:ff
> > 4: mgmt-vrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > link/ether 8a:f6:26:65:02:5a brd ff:ff:ff:ff:ff:ff
> >
> >
> > Admin@NETM06:~$ ip addr
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> > valid_lft forever preferred_lft forever
> > inet6 ::1/128 scope host
> > valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master mgmt-vrf state UP group default qlen 1000
> > link/ether 00:22:48:07:cc:ad brd ff:ff:ff:ff:ff:ff
> > inet 10.24.12.10/24 brd 10.24.12.255 scope global eth0
> > valid_lft forever preferred_lft forever
> > inet6 fe80::222:48ff:fe07:ccad/64 scope link
> > valid_lft forever preferred_lft forever
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> > link/ether 00:22:48:07:c9:6c brd ff:ff:ff:ff:ff:ff
> > inet 10.24.12.9/24 brd 10.24.12.255 scope global eth1
> > valid_lft forever preferred_lft forever
> > inet6 fe80::222:48ff:fe07:c96c/64 scope link
> > valid_lft forever preferred_lft forever
> > 4: mgmt-vrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP group default qlen 1000
> > link/ether 8a:f6:26:65:02:5a brd ff:ff:ff:ff:ff:ff
> >
> >
> >
> > the production traffic is all in the 10.0.0.0/8 network (eth1 global
> > VRF) except for a few subnets (DNS) which are routed out eth0
> > (mgmt-vrf)
> >
> >
> > Admin@NETM06:~$ ip route show
> > default via 10.24.12.1 dev eth0
> > 10.0.0.0/8 via 10.24.12.1 dev eth1
> > 10.24.12.0/24 dev eth1 proto kernel scope link src 10.24.12.9
> > 10.24.65.0/24 via 10.24.12.1 dev eth0
> > 10.25.65.0/24 via 10.24.12.1 dev eth0
> > 10.26.0.0/21 via 10.24.12.1 dev eth0
> > 10.26.64.0/21 via 10.24.12.1 dev eth0
> >
> >
> > Admin@NETM06:~$ ip route show vrf mgmt-vrf default via 10.24.12.1
> > dev eth0 unreachable default metric 4278198272
> > 10.24.12.0/24 dev eth0 proto kernel scope link src 10.24.12.10
> > 10.24.65.0/24 via 10.24.12.1 dev eth0
> > 10.25.65.0/24 via 10.24.12.1 dev eth0
> > 10.26.0.0/21 via 10.24.12.1 dev eth0
> > 10.26.64.0/21 via 10.24.12.1 dev eth0
> >
> >
> >
> > The strange activity occurs when I enter the command “sudo apt update” as I can resolve the DNS request (10.24.65.203 or 10.24.64.203, verified with tcpdump) out eth0 but for the actual update traffic there is no activity:
> >
> >
> > sudo tcpdump -i eth0 '(host 10.24.65.203 or host 10.25.65.203) and
> > port 53' -n <OUTPUT OMITTED FOR BREVITY>
> > 10:06:05.268735 IP 10.24.12.10.39963 > 10.24.65.203.53: 48798+ [1au]
> > A? security.ubuntu.com. (48) <OUTPUT OMITTED FOR BREVITY>
> > 10:06:05.284403 IP 10.24.65.203.53 > 10.24.12.10.39963: 48798 13/0/1
> > A 91.189.91.23, A 91.189.88.24, A 91.189.91.26, A 91.189.88.162, A
> > 91.189.88.149, A 91.189.91.24, A 91.189.88.173, A 91.189.88.177, A
> > 91.189.88.31, A 91.189.91.14, A 91.189.88.176, A 91.189.88.175, A
> > 91.189.88.174 (256)
> >
> >
> >
> > You can see that the update traffic is returned but is not accepted
> > by the stack and a RST is sent
> >
> >
> > Admin@NETM06:~$ sudo tcpdump -i eth0 '(not host 168.63.129.16 and
> > port 80)' -n
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> > decode listening on eth0, link-type EN10MB (Ethernet), capture size
> > 262144 bytes
> > 10:17:12.690658 IP 10.24.12.10.40216 > 91.189.88.175.80: Flags [S],
> > seq 2279624826, win 64240, options [mss 1460,sackOK,TS val
> > 2029365856 ecr 0,nop,wscale 7], length 0
> > 10:17:12.691929 IP 10.24.12.10.52362 > 91.189.95.83.80: Flags [S], seq 1465797256, win 64240, options [mss 1460,sackOK,TS val 3833463674 ecr 0,nop,wscale 7], length 0
> > 10:17:12.696270 IP 91.189.88.175.80 > 10.24.12.10.40216: Flags [S.], seq 968450722, ack 2279624827, win 28960, options [mss 1418,sackOK,TS val 81957103 ecr 2029365856,nop,wscale 7], length 0
> > 10:17:12.696301 IP 10.24.12.10.40216 > 91.189.88.175.80: Flags [R], seq 2279624827, win 0, length 0
> > 10:17:12.697884 IP 91.189.95.83.80 > 10.24.12.10.52362: Flags [S.], seq 4148330738, ack 1465797257, win 28960, options [mss 1418,sackOK,TS val 2257624414 ecr 3833463674,nop,wscale 8], length 0
> > 10:17:12.697909 IP 10.24.12.10.52362 > 91.189.95.83.80: Flags [R],
> > seq 1465797257, win 0, length 0
> >
> >
> >
> >
> > I can emulate the DNS lookup using netcat in the vrf:
> >
> >
> > sudo ip vrf exec mgmt-vrf nc -u 10.24.65.203 53
> >
> >
> > then interactively enter the binary for a www.google.co.uk request:
> >
> >
> > 0035624be394010000010000000000010377777706676f6f676c6502636f02756b00
> > 000100010000290200000000000000
> >
> >
> > This returns as expected:
> >
> >
> > 00624be394010000010000000000010377777706676f6f676c6502636f02756b0000
> > 0100010000290200000000000000
> >
> >
> > I can run:
> >
> >
> > Admin@NETM06:~$ host www.google.co.uk
www.google.co.uk has address
> > 172.217.169.3 www.google.co.uk has IPv6 address
> > 2a00:1450:4009:80d::2003
> >
> >
> > but I get a timeout for:
> >
> >
> > sudo ip vrf exec mgmt-vrf host www.google.co.uk ;; connection timed
> > out; no servers could be reached
> >
> >
> >
> > However I can take a repo address and vrf exec to it on port 80:
> >
> >
> > Admin@NETM06:~$ sudo ip vrf exec mgmt-vrf nc 91.189.91.23 80 hello
> > HTTP/1.1 400 Bad Request
> > <OUTPUT OMITTED>
> >
> > My iptables rule:
> >
> >
> > sudo iptables -Z
> > Admin@NETM06:~$ sudo iptables -L -v
> > Chain INPUT (policy DROP 16 packets, 3592 bytes)
> > pkts bytes target prot opt in out source destination
> > 44 2360 ACCEPT tcp -- any any anywhere anywhere tcp spt:http ctstate RELATED,ESTABLISHED
> > 83 10243 ACCEPT udp -- any any anywhere anywhere udp spt:domain ctstate RELATED,ESTABLISHED
> >
> >
> >
> > I cannot find out why the update isn’t working. Any help greatly
> > appreciated
> >
> >
> > Kind Regards,
> >
> >
> > Gareth
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net-next tree
From: Stephen Rothwell @ 2019-09-10 14:37 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Quentin Monnet, Alexei Starovoitov
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hi all,
In commit
ed4a3983cd3e ("tools: bpftool: fix argument for p_err() in BTF do_dump()")
Fixes tag
Fixes: c93cc69004dt ("bpftool: add ability to dump BTF types")
has these problem(s):
- missing space between the SHA1 and the subject
Presumably:
Fixes: c93cc69004df ("bpftool: add ability to dump BTF types")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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