* Re: [PATCH 2/6] mdev: introduce device specific ops
From: kbuild test robot @ 2019-09-23 15:20 UTC (permalink / raw)
To: Jason Wang
Cc: kbuild-all, kvm, linux-s390, linux-kernel, dri-devel, intel-gfx,
intel-gvt-dev, kwankhede, alex.williamson, mst, tiwei.bie, sebott,
airlied, Jason Wang, heiko.carstens, virtualization, rob.miller,
lulu, eperezma, pasic, borntraeger, haotian.wang, zhi.a.wang,
farman, idos, gor, cunming.liang, rodrigo.vivi, xiao.w.wang,
freude, parav, zhihong.wang, akrowiak, netdev, cohuck, oberpar,
maxime.coquelin, lingshan.zhu
In-Reply-To: <20190923130331.29324-3-jasowang@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 11306 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Jason-Wang/mdev-based-hardware-virtio-offloading-support/20190923-210738
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from include/linux/vfio_mdev.h:10:0,
from <command-line>:0:
>> include/linux/mdev.h:25:34: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration
int mdev_set_iommu_device(struct device *dev, struct device *iommu_device);
^~~~~~
>> include/linux/mdev.h:62:27: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
int (*create)(struct kobject *kobj, struct mdev_device *mdev);
^~~~~~~
>> include/linux/mdev.h:69:19: error: field 'attr' has incomplete type
struct attribute attr;
^~~~
include/linux/mdev.h:70:25: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf);
^~~~~~~
include/linux/mdev.h:71:26: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
ssize_t (*store)(struct kobject *kobj, struct device *dev,
^~~~~~~
>> include/linux/mdev.h:98:23: error: field 'driver' has incomplete type
struct device_driver driver;
^~~~~~
>> include/linux/mdev.h:106:7: error: unknown type name 'guid_t'
const guid_t *mdev_uuid(struct mdev_device *mdev);
^~~~~~
In file included from <command-line>:0:0:
>> include/linux/vfio_mdev.h:50:47: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration
int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
^~~~~~~~~~~~~~
vim +/attr +69 include/linux/mdev.h
7b96953bc640b6 Kirti Wankhede 2016-11-17 14
8ac13175cbe985 Lu Baolu 2019-04-12 15 /*
8ac13175cbe985 Lu Baolu 2019-04-12 16 * Called by the parent device driver to set the device which represents
8ac13175cbe985 Lu Baolu 2019-04-12 17 * this mdev in iommu protection scope. By default, the iommu device is
8ac13175cbe985 Lu Baolu 2019-04-12 18 * NULL, that indicates using vendor defined isolation.
8ac13175cbe985 Lu Baolu 2019-04-12 19 *
8ac13175cbe985 Lu Baolu 2019-04-12 20 * @dev: the mediated device that iommu will isolate.
8ac13175cbe985 Lu Baolu 2019-04-12 21 * @iommu_device: a pci device which represents the iommu for @dev.
8ac13175cbe985 Lu Baolu 2019-04-12 22 *
8ac13175cbe985 Lu Baolu 2019-04-12 23 * Return 0 for success, otherwise negative error value.
8ac13175cbe985 Lu Baolu 2019-04-12 24 */
8ac13175cbe985 Lu Baolu 2019-04-12 @25 int mdev_set_iommu_device(struct device *dev, struct device *iommu_device);
8ac13175cbe985 Lu Baolu 2019-04-12 26
8ac13175cbe985 Lu Baolu 2019-04-12 27 struct device *mdev_get_iommu_device(struct device *dev);
8ac13175cbe985 Lu Baolu 2019-04-12 28
7b96953bc640b6 Kirti Wankhede 2016-11-17 29 /**
42930553a7c11f Alex Williamson 2016-12-30 30 * struct mdev_parent_ops - Structure to be registered for each parent device to
7b96953bc640b6 Kirti Wankhede 2016-11-17 31 * register the device to mdev module.
7b96953bc640b6 Kirti Wankhede 2016-11-17 32 *
7b96953bc640b6 Kirti Wankhede 2016-11-17 33 * @owner: The module owner.
7b96953bc640b6 Kirti Wankhede 2016-11-17 34 * @dev_attr_groups: Attributes of the parent device.
7b96953bc640b6 Kirti Wankhede 2016-11-17 35 * @mdev_attr_groups: Attributes of the mediated device.
7b96953bc640b6 Kirti Wankhede 2016-11-17 36 * @supported_type_groups: Attributes to define supported types. It is mandatory
7b96953bc640b6 Kirti Wankhede 2016-11-17 37 * to provide supported types.
7b96953bc640b6 Kirti Wankhede 2016-11-17 38 * @create: Called to allocate basic resources in parent device's
7b96953bc640b6 Kirti Wankhede 2016-11-17 39 * driver for a particular mediated device. It is
7b96953bc640b6 Kirti Wankhede 2016-11-17 40 * mandatory to provide create ops.
7b96953bc640b6 Kirti Wankhede 2016-11-17 41 * @kobj: kobject of type for which 'create' is called.
7b96953bc640b6 Kirti Wankhede 2016-11-17 42 * @mdev: mdev_device structure on of mediated device
7b96953bc640b6 Kirti Wankhede 2016-11-17 43 * that is being created
7b96953bc640b6 Kirti Wankhede 2016-11-17 44 * Returns integer: success (0) or error (< 0)
7b96953bc640b6 Kirti Wankhede 2016-11-17 45 * @remove: Called to free resources in parent device's driver for a
7b96953bc640b6 Kirti Wankhede 2016-11-17 46 * a mediated device. It is mandatory to provide 'remove'
7b96953bc640b6 Kirti Wankhede 2016-11-17 47 * ops.
7b96953bc640b6 Kirti Wankhede 2016-11-17 48 * @mdev: mdev_device device structure which is being
7b96953bc640b6 Kirti Wankhede 2016-11-17 49 * destroyed
7b96953bc640b6 Kirti Wankhede 2016-11-17 50 * Returns integer: success (0) or error (< 0)
0baad8a6f6fefa Jason Wang 2019-09-23 51 * @device_ops: Device specific emulation callback.
0baad8a6f6fefa Jason Wang 2019-09-23 52 *
7b96953bc640b6 Kirti Wankhede 2016-11-17 53 * Parent device that support mediated device should be registered with mdev
42930553a7c11f Alex Williamson 2016-12-30 54 * module with mdev_parent_ops structure.
7b96953bc640b6 Kirti Wankhede 2016-11-17 55 **/
42930553a7c11f Alex Williamson 2016-12-30 56 struct mdev_parent_ops {
7b96953bc640b6 Kirti Wankhede 2016-11-17 57 struct module *owner;
7b96953bc640b6 Kirti Wankhede 2016-11-17 58 const struct attribute_group **dev_attr_groups;
7b96953bc640b6 Kirti Wankhede 2016-11-17 59 const struct attribute_group **mdev_attr_groups;
7b96953bc640b6 Kirti Wankhede 2016-11-17 60 struct attribute_group **supported_type_groups;
7b96953bc640b6 Kirti Wankhede 2016-11-17 61
7b96953bc640b6 Kirti Wankhede 2016-11-17 @62 int (*create)(struct kobject *kobj, struct mdev_device *mdev);
7b96953bc640b6 Kirti Wankhede 2016-11-17 63 int (*remove)(struct mdev_device *mdev);
0baad8a6f6fefa Jason Wang 2019-09-23 64 const void *device_ops;
7b96953bc640b6 Kirti Wankhede 2016-11-17 65 };
7b96953bc640b6 Kirti Wankhede 2016-11-17 66
7b96953bc640b6 Kirti Wankhede 2016-11-17 67 /* interface for exporting mdev supported type attributes */
7b96953bc640b6 Kirti Wankhede 2016-11-17 68 struct mdev_type_attribute {
7b96953bc640b6 Kirti Wankhede 2016-11-17 @69 struct attribute attr;
7b96953bc640b6 Kirti Wankhede 2016-11-17 @70 ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf);
7b96953bc640b6 Kirti Wankhede 2016-11-17 71 ssize_t (*store)(struct kobject *kobj, struct device *dev,
7b96953bc640b6 Kirti Wankhede 2016-11-17 72 const char *buf, size_t count);
7b96953bc640b6 Kirti Wankhede 2016-11-17 73 };
7b96953bc640b6 Kirti Wankhede 2016-11-17 74
7b96953bc640b6 Kirti Wankhede 2016-11-17 75 #define MDEV_TYPE_ATTR(_name, _mode, _show, _store) \
7b96953bc640b6 Kirti Wankhede 2016-11-17 76 struct mdev_type_attribute mdev_type_attr_##_name = \
7b96953bc640b6 Kirti Wankhede 2016-11-17 77 __ATTR(_name, _mode, _show, _store)
7b96953bc640b6 Kirti Wankhede 2016-11-17 78 #define MDEV_TYPE_ATTR_RW(_name) \
7b96953bc640b6 Kirti Wankhede 2016-11-17 79 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_RW(_name)
7b96953bc640b6 Kirti Wankhede 2016-11-17 80 #define MDEV_TYPE_ATTR_RO(_name) \
7b96953bc640b6 Kirti Wankhede 2016-11-17 81 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_RO(_name)
7b96953bc640b6 Kirti Wankhede 2016-11-17 82 #define MDEV_TYPE_ATTR_WO(_name) \
7b96953bc640b6 Kirti Wankhede 2016-11-17 83 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_WO(_name)
7b96953bc640b6 Kirti Wankhede 2016-11-17 84
7b96953bc640b6 Kirti Wankhede 2016-11-17 85 /**
7b96953bc640b6 Kirti Wankhede 2016-11-17 86 * struct mdev_driver - Mediated device driver
7b96953bc640b6 Kirti Wankhede 2016-11-17 87 * @name: driver name
7b96953bc640b6 Kirti Wankhede 2016-11-17 88 * @probe: called when new device created
7b96953bc640b6 Kirti Wankhede 2016-11-17 89 * @remove: called when device removed
7b96953bc640b6 Kirti Wankhede 2016-11-17 90 * @driver: device driver structure
6294ee8e0b5153 Jason Wang 2019-09-23 91 * @id_table: the ids serviced by this driver.
7b96953bc640b6 Kirti Wankhede 2016-11-17 92 *
7b96953bc640b6 Kirti Wankhede 2016-11-17 93 **/
7b96953bc640b6 Kirti Wankhede 2016-11-17 94 struct mdev_driver {
7b96953bc640b6 Kirti Wankhede 2016-11-17 95 const char *name;
7b96953bc640b6 Kirti Wankhede 2016-11-17 96 int (*probe)(struct device *dev);
7b96953bc640b6 Kirti Wankhede 2016-11-17 97 void (*remove)(struct device *dev);
7b96953bc640b6 Kirti Wankhede 2016-11-17 @98 struct device_driver driver;
6294ee8e0b5153 Jason Wang 2019-09-23 99 const struct mdev_class_id *id_table;
7b96953bc640b6 Kirti Wankhede 2016-11-17 100 };
7b96953bc640b6 Kirti Wankhede 2016-11-17 101
7b96953bc640b6 Kirti Wankhede 2016-11-17 102 #define to_mdev_driver(drv) container_of(drv, struct mdev_driver, driver)
7b96953bc640b6 Kirti Wankhede 2016-11-17 103
50732af3b65691 Parav Pandit 2019-04-30 104 void *mdev_get_drvdata(struct mdev_device *mdev);
50732af3b65691 Parav Pandit 2019-04-30 105 void mdev_set_drvdata(struct mdev_device *mdev, void *data);
50732af3b65691 Parav Pandit 2019-04-30 @106 const guid_t *mdev_uuid(struct mdev_device *mdev);
7b96953bc640b6 Kirti Wankhede 2016-11-17 107
:::::: The code at line 69 was first introduced by commit
:::::: 7b96953bc640b6b25665fe17ffca4b668b371f14 vfio: Mediated device Core driver
:::::: TO: Kirti Wankhede <kwankhede@nvidia.com>
:::::: CC: Alex Williamson <alex.williamson@redhat.com>
---
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: 54846 bytes --]
^ permalink raw reply
* Re: [PATCH] ipv6: Properly check reference count flag before taking reference
From: Jason A. Donenfeld @ 2019-09-23 15:24 UTC (permalink / raw)
To: Petr Vorel; +Cc: Netdev, LKML, stable
In-Reply-To: <20190923150600.GA27191@dell5510>
Apparently even with this (certainly correct) patch attached, users
are still experiencing problems. Bug hunting continues, and I'll
report back if I figure something out.
^ permalink raw reply
* s390 EAGAIN on send{msg,to}()/recvmsg() on small MTU and big packet size
From: Petr Vorel @ 2019-09-23 15:25 UTC (permalink / raw)
To: linux-s390; +Cc: Michal Kubecek, netdev, linux-kernel
Hi,
I've found a bug on s390 on small MTU combined with big packet size, using ping
(of course both within valid ranges, e.g. MTU 552 and packet size 61245).
Below is full reproducer on netns.
I tested it on vanilla: v5.3-rc8 and v4.16.
I reproduced it on current iputils master which uses sendto()/recvmsg() and on
older version which uses sendmsg()/recvmsg().
As I'm not aware of any s390 specific socket code in kernel I suspect big endian or something else.
This bug was find with LTP/if-mtu-change.sh.
REPRODUCER:
LTP_NS="ip netns exec ltp_ns"
ip net add ltp_ns
ip li add name ltp_ns_veth1 type veth peer name ltp_ns_veth2
ip li set dev ltp_ns_veth1 netns ltp_ns
$LTP_NS ip li set lo up
ip xfrm policy flush
ip xfrm state flush
ip link set ltp_ns_veth2 down
ip route flush dev ltp_ns_veth2
ip addr flush dev ltp_ns_veth2
ip link set ltp_ns_veth2 up
ip addr add 10.0.0.2/24 dev ltp_ns_veth2
$LTP_NS ip xfrm policy flush
$LTP_NS ip xfrm state flush
$LTP_NS ip link set ltp_ns_veth1 down
$LTP_NS ip route flush dev ltp_ns_veth1
$LTP_NS ip addr flush dev ltp_ns_veth1
$LTP_NS ip link set ltp_ns_veth1 up
$LTP_NS ip addr add 10.0.0.1/24 dev ltp_ns_veth1
i=552; ip link set dev ltp_ns_veth2 mtu $i; $LTP_NS ip link set dev ltp_ns_veth1 mtu $i # it's enough to set just one of them
ping -I 10.0.0.2 -c 1 10.0.0.1 -s 61245 # fail
ping -I 10.0.0.2 -c 1 10.0.0.1 -s 61244 # ok
FAIL (iputils-s20121221 from package, using sendmsg())
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=74, ws_col=273, ws_xpixel=1911, ws_ypixel=1050}) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, msg_iov(1)=[{"\10\0\253_\241\373\0\1\0\0\0\0]wf\330\0\0\0\0\0\6\375\201\20\21\22\23\24\25\26\27"..., 61253}], msg_controllen=0, msg_flags=0}, 0) = 61253
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3fff887b588, 0) = -1 EINTR (Interrupted system call)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
OK (iputils-s20121221 from package, using sendmsg())
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=74, ws_col=273, ws_xpixel=1911, ws_ypixel=1050}) = 0
sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, msg_iov(1)=[{"\10\0\3u\242\266\0\1\0\0\0\0]wgd\0\0\0\0\0\6\340%\20\21\22\23\24\25\26\27"..., 61252}], msg_controllen=0, msg_flags=0}, 0) = 61252
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, msg_iov(1)=[{"E\0\357X2\277\0\0@\1D\343\n\0\0\1\n\0\0\2\0\0\vu\242\266\0\1\0\0\0\0"..., 61380}], msg_controllen=32, [{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /*
SCM_??? */, ...}], msg_flags=0}, 0) = 61272
write(1, "61252 bytes from 10.0.0.1: icmp_"..., 5961252 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.442 ms
) = 59
FAIL (current iputils master, using sendto())
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=74, ws_col=273, ws_xpixel=1911, ws_ypixel=1050}) = 0
sendto(3, "\10\0\2=\313\315\0\1\0\0\0\0]vH;\0\0\0\0\0\7\233o\20\21\22\23\24\25\26\27"..., 61253, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, 16) = 61253
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, 0x3ffe7e7b388, 0) = -1 EINTR (Interrupted system call)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
OK (current iputils master, using sendto())
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=74, ws_col=273, ws_xpixel=1911, ws_ypixel=1050}) = 0
sendto(3, "\10\0y\4\313\365\0\1\0\0\0\0]vHw\0\0\0\0\0\4`G\20\21\22\23\24\25\26\27"..., 61252, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, 16) = 61252
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={10, 0}}, NULL) = 0
recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.0.1")}, msg_iov(1)=[{"E\0\357Xc$\0\0@\1\24~\n\0\0\1\n\0\0\2\0\0\201\4\313\365\0\1\0\0\0\0"..., 61380}], msg_controllen=32, [{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /*
SCM_??? */, ...}], msg_flags=0}, 0) = 61272
write(1, "61252 bytes from 10.0.0.1: icmp_"..., 59) = 59
Kind regards,
Petr
^ permalink raw reply
* Re: [PATCH net v2 0/3] net/smc: move some definitions to UAPI
From: Ursula Braun @ 2019-09-23 15:27 UTC (permalink / raw)
To: Eugene Syromiatnikov, netdev; +Cc: David S. Miller, linux-kernel, Karsten Graul
In-Reply-To: <cover.1568993930.git.esyr@redhat.com>
On 9/20/19 5:41 PM, Eugene Syromiatnikov wrote:
> Hello.
>
> As of now, it's a bit difficult to use SMC protocol, as significant part
> of definitions related to it are defined in private headers and are not
> part of UAPI. The following commits move some definitions to UAPI,
> making them readily available to the user space.
>
> Changes since v1[1]:
> * Patch "provide fallback diagnostic codes in UAPI" is updated
> in accordance with the updated set of diagnostic codes.
>
> [1] https://lkml.org/lkml/2018/10/7/177
>
Thanks Eugene, your patches look good. They will be part of our next SMC
patch submission for the net-next tree.
Regards, Ursula
> Eugene Syromiatnikov (3):
> uapi, net/smc: move protocol constant definitions to UAPI
> uapi, net/smc: provide fallback diagnostic codes in UAPI
> uapi, net/smc: provide socket state constants in UAPI
>
> include/uapi/linux/smc.h | 32 +++++++++++++++++++++++++++++++-
> include/uapi/linux/smc_diag.h | 17 +++++++++++++++++
> net/smc/smc.h | 22 ++--------------------
> net/smc/smc_clc.h | 22 ----------------------
> 4 files changed, 50 insertions(+), 43 deletions(-)
>
^ permalink raw reply
* Re: dsa traffic priorization
From: Florian Fainelli @ 2019-09-23 15:32 UTC (permalink / raw)
To: Jan Lübbe, Sascha Hauer, Jamal Hadi Salim, Cong Wang,
Jiri Pirko
Cc: netdev, Vladimir Oltean, Vivien Didelot, kernel, Andrew Lunn
In-Reply-To: <bc0acd2803c4f513babe6bcc006b95a6297484bc.camel@pengutronix.de>
On 9/23/2019 5:56 AM, Jan Lübbe wrote:
> Adding TC maintainers... (we're trying to find a mainline-acceptable
> way to configure and offload strict port-based priorities in the
> context of DSA/switchdev).
>
> On Thu, 2019-09-19 at 10:12 -0700, Florian Fainelli wrote:
>> On 9/19/19 1:44 AM, Sascha Hauer wrote:
>>> On Wed, Sep 18, 2019 at 10:41:58AM -0700, Florian Fainelli wrote:
>>>> On 9/18/19 7:36 AM, Vladimir Oltean wrote:
>>>>> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>>>>>> The other part of the problem seems to be that the CPU port
>>>>>> has no network device representation in Linux, so there's no
>>>>>> interface to configure the egress limits via tc.
>>>>>> This has been discussed before, but it seems there hasn't
>>>>>> been any consensous regarding how we want to proceed?
>>>>
>>>> You have the DSA master network device which is on the other side of the
>>>> switch,
>>>
>>> You mean the (in my case) i.MX FEC? Everything I do on this device ends
>>> up in the FEC itself and not on the switch, right?
>>
>> Yes, we have a way to overload specific netdevice_ops and ethtool_ops
>> operations in order to use the i.MX FEC network device as configuration
>> entry point, say eth0, but have it operate on the switch, because when
>> the DSA switch got attached to the DSA master, we replaced some of that
>> network device's operations with ones that piggy back into the switch.
>> See net/dsa/master.c for details.
>
> Currently, it overrides
> for ethtool:
> ops->get_sset_count = dsa_master_get_sset_count;
> ops->get_ethtool_stats = dsa_master_get_ethtool_stats;
> ops->get_strings = dsa_master_get_strings;
> ops->get_ethtool_phy_stats = dsa_master_get_ethtool_phy_stats;
> for ndo:
> ops->ndo_get_phys_port_name = dsa_master_get_phys_port_name;
>
> In dsa/slave.c we have for ndo:
> .ndo_setup_tc = dsa_slave_setup_tc,
>
> So we would override ndo_setup_tc from dsa as well, maybe falling back
> to the original ndo_setup_tc provided by the ethernet driver if we the
> switch HW cannot handle a TC configuration?
There are two simple cases:
- the switch provides a ndo_setup_tc() implementation (not just
dsa_slave_setup_tc, the callbacks behind are also provided), but the DSA
master does not, you can use the DSA switch implementation
- the DSA master provides a ndo_setup_tc() implementation, but the DSA
switch does not, then you can use the DSA master implementation
If both are provided then you must make a choice of either using one, or
the other, typically the using the most capable for the specific use
case, or using both.
If your interest is in doing egress configuration on the CPU port, then
maybe using the bridge master device and somehow linking it to the DSA
switch's CPU port might be a better approach. See [1] for how this is
done for instance.
[1]:
https://lists.linuxfoundation.org/pipermail/bridge/2016-November/010112.html
>
> That would allow us to configure and offload a CPU-port-specific TC
> policy under the control of DSA. Is this interface reasonable?
>
> Im not sure if the existing TC filters and qdiscs can match on bridge-
> specific information (like the ingress port) yet, so this might require
> extensions to TC filters as well...
bridge ports are net_device instances, so as long as this paradigm is
maintained, it should work.
--
Florian
^ permalink raw reply
* Re: [PATCH 2/6] mdev: introduce device specific ops
From: Michael S. Tsirkin @ 2019-09-23 15:36 UTC (permalink / raw)
To: kbuild test robot
Cc: Jason Wang, kbuild-all, kvm, linux-s390, linux-kernel, dri-devel,
intel-gfx, intel-gvt-dev, kwankhede, alex.williamson, tiwei.bie,
sebott, airlied, heiko.carstens, virtualization, rob.miller, lulu,
eperezma, pasic, borntraeger, haotian.wang, zhi.a.wang, farman,
idos, gor, cunming.liang, rodrigo.vivi, xiao.w.wang, freude,
parav, zhihong.wang, akrowiak, netdev, cohuck, oberpar,
maxime.coquelin, lingshan.zhu
In-Reply-To: <201909232342.R079Gsby%lkp@intel.com>
On Mon, Sep 23, 2019 at 11:20:12PM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190920]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Jason-Wang/mdev-based-hardware-virtio-offloading-support/20190923-210738
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=ia64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All error/warnings (new ones prefixed by >>):
Looks like a bunch of includes missing. I guess they happen to
be pulled in on some platforms but not others - ideally
headers should be self contained though, pulling in
all their dependencies.
> In file included from include/linux/vfio_mdev.h:10:0,
> from <command-line>:0:
> >> include/linux/mdev.h:25:34: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration
> int mdev_set_iommu_device(struct device *dev, struct device *iommu_device);
> ^~~~~~
> >> include/linux/mdev.h:62:27: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
> int (*create)(struct kobject *kobj, struct mdev_device *mdev);
> ^~~~~~~
> >> include/linux/mdev.h:69:19: error: field 'attr' has incomplete type
> struct attribute attr;
> ^~~~
> include/linux/mdev.h:70:25: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
> ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf);
> ^~~~~~~
> include/linux/mdev.h:71:26: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration
> ssize_t (*store)(struct kobject *kobj, struct device *dev,
> ^~~~~~~
> >> include/linux/mdev.h:98:23: error: field 'driver' has incomplete type
> struct device_driver driver;
> ^~~~~~
> >> include/linux/mdev.h:106:7: error: unknown type name 'guid_t'
> const guid_t *mdev_uuid(struct mdev_device *mdev);
> ^~~~~~
> In file included from <command-line>:0:0:
> >> include/linux/vfio_mdev.h:50:47: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration
> int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> ^~~~~~~~~~~~~~
>
> vim +/attr +69 include/linux/mdev.h
>
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 14
> 8ac13175cbe985 Lu Baolu 2019-04-12 15 /*
> 8ac13175cbe985 Lu Baolu 2019-04-12 16 * Called by the parent device driver to set the device which represents
> 8ac13175cbe985 Lu Baolu 2019-04-12 17 * this mdev in iommu protection scope. By default, the iommu device is
> 8ac13175cbe985 Lu Baolu 2019-04-12 18 * NULL, that indicates using vendor defined isolation.
> 8ac13175cbe985 Lu Baolu 2019-04-12 19 *
> 8ac13175cbe985 Lu Baolu 2019-04-12 20 * @dev: the mediated device that iommu will isolate.
> 8ac13175cbe985 Lu Baolu 2019-04-12 21 * @iommu_device: a pci device which represents the iommu for @dev.
> 8ac13175cbe985 Lu Baolu 2019-04-12 22 *
> 8ac13175cbe985 Lu Baolu 2019-04-12 23 * Return 0 for success, otherwise negative error value.
> 8ac13175cbe985 Lu Baolu 2019-04-12 24 */
> 8ac13175cbe985 Lu Baolu 2019-04-12 @25 int mdev_set_iommu_device(struct device *dev, struct device *iommu_device);
> 8ac13175cbe985 Lu Baolu 2019-04-12 26
> 8ac13175cbe985 Lu Baolu 2019-04-12 27 struct device *mdev_get_iommu_device(struct device *dev);
> 8ac13175cbe985 Lu Baolu 2019-04-12 28
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 29 /**
> 42930553a7c11f Alex Williamson 2016-12-30 30 * struct mdev_parent_ops - Structure to be registered for each parent device to
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 31 * register the device to mdev module.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 32 *
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 33 * @owner: The module owner.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 34 * @dev_attr_groups: Attributes of the parent device.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 35 * @mdev_attr_groups: Attributes of the mediated device.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 36 * @supported_type_groups: Attributes to define supported types. It is mandatory
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 37 * to provide supported types.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 38 * @create: Called to allocate basic resources in parent device's
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 39 * driver for a particular mediated device. It is
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 40 * mandatory to provide create ops.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 41 * @kobj: kobject of type for which 'create' is called.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 42 * @mdev: mdev_device structure on of mediated device
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 43 * that is being created
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 44 * Returns integer: success (0) or error (< 0)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 45 * @remove: Called to free resources in parent device's driver for a
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 46 * a mediated device. It is mandatory to provide 'remove'
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 47 * ops.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 48 * @mdev: mdev_device device structure which is being
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 49 * destroyed
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 50 * Returns integer: success (0) or error (< 0)
> 0baad8a6f6fefa Jason Wang 2019-09-23 51 * @device_ops: Device specific emulation callback.
> 0baad8a6f6fefa Jason Wang 2019-09-23 52 *
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 53 * Parent device that support mediated device should be registered with mdev
> 42930553a7c11f Alex Williamson 2016-12-30 54 * module with mdev_parent_ops structure.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 55 **/
> 42930553a7c11f Alex Williamson 2016-12-30 56 struct mdev_parent_ops {
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 57 struct module *owner;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 58 const struct attribute_group **dev_attr_groups;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 59 const struct attribute_group **mdev_attr_groups;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 60 struct attribute_group **supported_type_groups;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 61
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 @62 int (*create)(struct kobject *kobj, struct mdev_device *mdev);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 63 int (*remove)(struct mdev_device *mdev);
> 0baad8a6f6fefa Jason Wang 2019-09-23 64 const void *device_ops;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 65 };
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 66
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 67 /* interface for exporting mdev supported type attributes */
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 68 struct mdev_type_attribute {
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 @69 struct attribute attr;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 @70 ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 71 ssize_t (*store)(struct kobject *kobj, struct device *dev,
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 72 const char *buf, size_t count);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 73 };
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 74
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 75 #define MDEV_TYPE_ATTR(_name, _mode, _show, _store) \
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 76 struct mdev_type_attribute mdev_type_attr_##_name = \
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 77 __ATTR(_name, _mode, _show, _store)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 78 #define MDEV_TYPE_ATTR_RW(_name) \
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 79 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_RW(_name)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 80 #define MDEV_TYPE_ATTR_RO(_name) \
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 81 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_RO(_name)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 82 #define MDEV_TYPE_ATTR_WO(_name) \
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 83 struct mdev_type_attribute mdev_type_attr_##_name = __ATTR_WO(_name)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 84
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 85 /**
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 86 * struct mdev_driver - Mediated device driver
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 87 * @name: driver name
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 88 * @probe: called when new device created
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 89 * @remove: called when device removed
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 90 * @driver: device driver structure
> 6294ee8e0b5153 Jason Wang 2019-09-23 91 * @id_table: the ids serviced by this driver.
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 92 *
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 93 **/
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 94 struct mdev_driver {
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 95 const char *name;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 96 int (*probe)(struct device *dev);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 97 void (*remove)(struct device *dev);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 @98 struct device_driver driver;
> 6294ee8e0b5153 Jason Wang 2019-09-23 99 const struct mdev_class_id *id_table;
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 100 };
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 101
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 102 #define to_mdev_driver(drv) container_of(drv, struct mdev_driver, driver)
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 103
> 50732af3b65691 Parav Pandit 2019-04-30 104 void *mdev_get_drvdata(struct mdev_device *mdev);
> 50732af3b65691 Parav Pandit 2019-04-30 105 void mdev_set_drvdata(struct mdev_device *mdev, void *data);
> 50732af3b65691 Parav Pandit 2019-04-30 @106 const guid_t *mdev_uuid(struct mdev_device *mdev);
> 7b96953bc640b6 Kirti Wankhede 2016-11-17 107
>
> :::::: The code at line 69 was first introduced by commit
> :::::: 7b96953bc640b6b25665fe17ffca4b668b371f14 vfio: Mediated device Core driver
>
> :::::: TO: Kirti Wankhede <kwankhede@nvidia.com>
> :::::: CC: Alex Williamson <alex.williamson@redhat.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: test_progs: fix client/server race in tcp_rtt
From: Stanislav Fomichev @ 2019-09-23 15:38 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Stanislav Fomichev, Networking, bpf, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAEf4BzYFQhPKoDG7kq=_B5caL-0Af2duL_Uz5v3oVw=BKQ430w@mail.gmail.com>
On 09/22, Andrii Nakryiko wrote:
> On Sun, Sep 22, 2019 at 12:10 PM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > This is the same problem I found earlier in test_sockopt_inherit:
> > there is a race between server thread doing accept() and client
> > thread doing connect(). Let's explicitly synchronize them via
> > pthread conditional variable.
> >
> > Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 16 +++++++++++++++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > index fdc0b3614a9e..e64058906bcd 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > @@ -203,6 +203,9 @@ static int start_server(void)
> > return fd;
> > }
> >
> > +static pthread_mutex_t server_started_mtx = PTHREAD_MUTEX_INITIALIZER;
> > +static pthread_cond_t server_started = PTHREAD_COND_INITIALIZER;
> > +
> > static void *server_thread(void *arg)
> > {
> > struct sockaddr_storage addr;
> > @@ -215,6 +218,10 @@ static void *server_thread(void *arg)
> > return NULL;
> > }
> >
> > + pthread_mutex_lock(&server_started_mtx);
> > + pthread_cond_signal(&server_started);
> > + pthread_mutex_unlock(&server_started_mtx);
> > +
> > client_fd = accept(fd, (struct sockaddr *)&addr, &len);
> > if (CHECK_FAIL(client_fd < 0)) {
> > perror("Failed to accept client");
> > @@ -248,7 +255,14 @@ void test_tcp_rtt(void)
> > if (CHECK_FAIL(server_fd < 0))
> > goto close_cgroup_fd;
> >
> > - pthread_create(&tid, NULL, server_thread, (void *)&server_fd);
> > + if (CHECK_FAIL(pthread_create(&tid, NULL, server_thread,
> > + (void *)&server_fd)))
> > + goto close_cgroup_fd;
> > +
> > + pthread_mutex_lock(&server_started_mtx);
> > + pthread_cond_wait(&server_started, &server_started_mtx);
> > + pthread_mutex_unlock(&server_started_mtx);
>
>
> If the server fails to listen, then we'll never get a signal, right?
> Let's use timedwait instead to avoid test getting stuck forever in
> such cases?
Good point. How about I do the same thing I do in sockopt_inherit tests:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c#n73
err = listen()
pthread_cond_signal()
if (CHECK_FAIL(err)) {
return;
}
Should fix the problem of getting stuck forever without any timeouts.
I'll send a v2 later today.
> > +
> > CHECK_FAIL(run_test(cgroup_fd, server_fd));
> > close(server_fd);
> > close_cgroup_fd:
> > --
> > 2.23.0.351.gc4317032e6-goog
> >
^ permalink raw reply
* Re: [PATCH net] net: sched: fix possible crash in tcf_action_destroy()
From: Eric Dumazet @ 2019-09-23 15:44 UTC (permalink / raw)
To: Jakub Kicinski, Cong Wang, Eric Dumazet
Cc: Eric Dumazet, David S . Miller, netdev, syzbot, Vlad Buslov,
Jiri Pirko
In-Reply-To: <20190921190800.3f19fe23@cakuba.netronome.com>
On 9/21/19 7:08 PM, Jakub Kicinski wrote:
> On Wed, 18 Sep 2019 14:37:21 -0700, Cong Wang wrote:
>> On Wed, Sep 18, 2019 at 12:57 PM 'Eric Dumazet' via syzkaller
>> <syzkaller@googlegroups.com> wrote:
>>>
>>> If the allocation done in tcf_exts_init() failed,
>>> we end up with a NULL pointer in exts->actions.
>> ...
>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>> index efd3cfb80a2ad775dc8ab3c4900bd73d52c7aaad..9aef93300f1c11791acbb9262dfe77996872eafe 100644
>>> --- a/net/sched/cls_api.c
>>> +++ b/net/sched/cls_api.c
>>> @@ -3027,8 +3027,10 @@ static int tc_dump_chain(struct sk_buff *skb, struct netlink_callback *cb)
>>> void tcf_exts_destroy(struct tcf_exts *exts)
>>> {
>>> #ifdef CONFIG_NET_CLS_ACT
>>> - tcf_action_destroy(exts->actions, TCA_ACT_UNBIND);
>>> - kfree(exts->actions);
>>> + if (exts->actions) {
>>
>> I think it is _slightly_ better to check exts->nr_actions!=0 here,
>> as it would help exts->actions!=NULL&& exts->nr_actions==0
>> cases too.
>>
>> What do you think?
>
> Alternatively, since tcf_exts_destroy() now takes NULL, and so
> obviously does kfree() - perhaps tcf_action_destroy() should
> return early if actions are NULL?
>
I do not have any preference really, this is slow path and was trying to
fix a crash.
tcf_action_destroy() makes me nervous, since it seems to be able to break its loop
in case __tcf_idr_release() returns an error. This means that some actions will
never be release.
^ permalink raw reply
* Re: [PATCH 5/6] vringh: fix copy direction of vringh_iov_push_kern()
From: Alex Williamson @ 2019-09-23 15:45 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, linux-s390, linux-kernel, dri-devel, intel-gfx,
intel-gvt-dev, kwankhede, mst, tiwei.bie, virtualization, netdev,
cohuck, maxime.coquelin, cunming.liang, zhihong.wang, rob.miller,
xiao.w.wang, haotian.wang, zhenyuw, zhi.a.wang, jani.nikula,
joonas.lahtinen, rodrigo.vivi, airlied, daniel, farman, pasic,
sebott, oberpar, heiko.carstens, gor, borntraeger, akrowiak,
freude, lingshan.zhu, idos, eperezma, lulu, parav
In-Reply-To: <20190923130331.29324-6-jasowang@redhat.com>
On Mon, 23 Sep 2019 21:03:30 +0800
Jason Wang <jasowang@redhat.com> wrote:
> We want to copy from iov to buf, so the direction was wrong.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/vringh.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Why is this included in the series? Seems like an unrelated fix being
held up within a proposal for a new feature. Thanks,
Alex
> diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> index 08ad0d1f0476..a0a2d74967ef 100644
> --- a/drivers/vhost/vringh.c
> +++ b/drivers/vhost/vringh.c
> @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len)
> return 0;
> }
>
> +static inline int kern_xfer(void *dst, void *src, size_t len)
> +{
> + memcpy(dst, src, len);
> + return 0;
> +}
> +
> /**
> * vringh_init_kern - initialize a vringh for a kernelspace vring.
> * @vrh: the vringh to initialize.
> @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern);
> ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov,
> const void *src, size_t len)
> {
> - return vringh_iov_xfer(wiov, (void *)src, len, xfer_kern);
> + return vringh_iov_xfer(wiov, (void *)src, len, kern_xfer);
> }
> EXPORT_SYMBOL(vringh_iov_push_kern);
>
^ permalink raw reply
* general protection fault in xsk_map_update_elem
From: syzbot @ 2019-09-23 15:49 UTC (permalink / raw)
To: ast, bjorn.topel, bpf, daniel, davem, hawk, jakub.kicinski,
john.fastabend, jonathan.lemon, kafai, linux-kernel,
magnus.karlsson, netdev, songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: b41dae06 Merge tag 'xfs-5.4-merge-7' of git://git.kernel.o..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=130b25ad600000
kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132
dashboard link: https://syzkaller.appspot.com/bug?extid=491c1b7565ba9069ecae
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=155a0c29600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172bf6d9600000
The bug was bisected to:
commit 0402acd683c678874df6bdbc23530ca07ea19353
Author: Björn Töpel <bjorn.topel@intel.com>
Date: Thu Aug 15 09:30:13 2019 +0000
xsk: remove AF_XDP socket from map when the socket is released
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10d4a823600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=12d4a823600000
console output: https://syzkaller.appspot.com/x/log.txt?x=14d4a823600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+491c1b7565ba9069ecae@syzkaller.appspotmail.com
Fixes: 0402acd683c6 ("xsk: remove AF_XDP socket from map when the socket is
released")
RDX: 0000000000000020 RSI: 0000000020000100 RDI: 0000000000000002
RBP: 0000000000000005 R08: 0000000000000001 R09: 00007ffef4500033
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ff0
R13: 0000000000402080 R14: 0000000000000000 R15: 0000000000000000
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8878 Comm: syz-executor835 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_add include/linux/list.h:64 [inline]
RIP: 0010:list_add_tail include/linux/list.h:93 [inline]
RIP: 0010:xsk_map_sock_add kernel/bpf/xskmap.c:62 [inline]
RIP: 0010:xsk_map_update_elem+0x79c/0xac0 kernel/bpf/xskmap.c:265
Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 ef 02 00 00 4c 89 e2 4d 89
a7 d8 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 c0 02 00 00 49 8d 7c 24 08 49 8d 87 d0 05 00 00
RSP: 0018:ffff88809a517bb8 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88809ccc49d0 RCX: ffffffff81868070
RDX: 0000000000000000 RSI: ffffffff81868085 RDI: 0000000000000001
RBP: ffff88809a517c78 R08: ffff8880a10d2000 R09: ffffed10134a2f65
R10: ffffed10134a2f64 R11: 0000000000000003 R12: 0000000000000000
R13: ffff88809ccc49e0 R14: ffff888089db5580 R15: ffff88809ccc4400
FS: 0000555555df2880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 00000000985e5000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
map_update_elem+0xc82/0x10b0 kernel/bpf/syscall.c:966
__do_sys_bpf+0x8b5/0x3350 kernel/bpf/syscall.c:2854
__se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2825
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440709
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffef4503478 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007ffef4503480 RCX: 0000000000440709
RDX: 0000000000000020 RSI: 0000000020000100 RDI: 0000000000000002
RBP: 0000000000000005 R08: 0000000000000001 R09: 00007ffef4500033
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ff0
R13: 0000000000402080 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace a95b9b926f856077 ]---
RIP: 0010:__list_add include/linux/list.h:64 [inline]
RIP: 0010:list_add_tail include/linux/list.h:93 [inline]
RIP: 0010:xsk_map_sock_add kernel/bpf/xskmap.c:62 [inline]
RIP: 0010:xsk_map_update_elem+0x79c/0xac0 kernel/bpf/xskmap.c:265
Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 ef 02 00 00 4c 89 e2 4d 89
a7 d8 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 c0 02 00 00 49 8d 7c 24 08 49 8d 87 d0 05 00 00
RSP: 0018:ffff88809a517bb8 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88809ccc49d0 RCX: ffffffff81868070
RDX: 0000000000000000 RSI: ffffffff81868085 RDI: 0000000000000001
RBP: ffff88809a517c78 R08: ffff8880a10d2000 R09: ffffed10134a2f65
R10: ffffed10134a2f64 R11: 0000000000000003 R12: 0000000000000000
R13: ffff88809ccc49e0 R14: ffff888089db5580 R15: ffff88809ccc4400
FS: 0000555555df2880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 00000000985e5000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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
* Re: [PATCH 4.19-stable 0/7] mlx5 checksum fixes for 4.19
From: David Miller @ 2019-09-23 15:51 UTC (permalink / raw)
To: saeedm; +Cc: gregkh, netdev, stable
In-Reply-To: <20190923123917.16817-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 23 Sep 2019 12:39:57 +0000
> This series includes some upstream patches aimed to fix multiple checksum
> issues with mlx5 driver in 4.19-stable kernels.
>
> Since the patches didn't apply cleanly to 4.19 back when they were
> submitted for the first time around 5.1 kernel release to the netdev
> mailing list, i couldn't mark them for -stable 4.19, so now as the issue
> is being reported on 4.19 LTS kernels, I had to do the backporting and
> this submission myself.
>
> This series required some dependency patches and some manual touches
> to apply some of them.
>
> Please apply to 4.19-stable and let me know if there's any problem.
> I tested and the patches apply cleanly and work on top of: v4.19.75
FWIW, I'm fine with this.
^ permalink raw reply
* [PATCH trivial 1/2] net: Fix Kconfig indentation
From: Krzysztof Kozlowski @ 2019-09-23 15:52 UTC (permalink / raw)
To: David S. Miller, Michael Grzeschik, Wolfgang Grandegger,
Marc Kleine-Budde, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, Jiri Kosina, netdev,
linux-kernel, linux-can, linux-rdma, linux-wireless, b.a.t.m.a.n,
netfilter-devel, coreteam, lvs-devel, rds-devel
Cc: Krzysztof Kozlowski
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
net/batman-adv/Kconfig | 10 +--
net/ife/Kconfig | 2 +-
net/ipv4/Kconfig | 4 +-
net/ipv6/netfilter/Kconfig | 16 ++---
net/netfilter/Kconfig | 2 +-
net/netfilter/ipvs/Kconfig | 6 +-
net/rds/Kconfig | 4 +-
net/sched/Kconfig | 144 ++++++++++++++++++-------------------
8 files changed, 94 insertions(+), 94 deletions(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index a3d188dfbe75..d5028af750d5 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -12,11 +12,11 @@ config BATMAN_ADV
depends on NET
select LIBCRC32C
help
- B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
- a routing protocol for multi-hop ad-hoc mesh networks. The
- networks may be wired or wireless. See
- https://www.open-mesh.org/ for more information and user space
- tools.
+ B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
+ a routing protocol for multi-hop ad-hoc mesh networks. The
+ networks may be wired or wireless. See
+ https://www.open-mesh.org/ for more information and user space
+ tools.
config BATMAN_ADV_BATMAN_V
bool "B.A.T.M.A.N. V protocol"
diff --git a/net/ife/Kconfig b/net/ife/Kconfig
index 6cd1f6d18f30..bcf650564db4 100644
--- a/net/ife/Kconfig
+++ b/net/ife/Kconfig
@@ -5,7 +5,7 @@
menuconfig NET_IFE
depends on NET
- tristate "Inter-FE based on IETF ForCES InterFE LFB"
+ tristate "Inter-FE based on IETF ForCES InterFE LFB"
default n
help
Say Y here to add support of IFE encapsulation protocol
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 974de4d20f25..03381f3e12ba 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -492,8 +492,8 @@ config TCP_CONG_WESTWOOD
wired networks and throughput over wireless links.
config TCP_CONG_HTCP
- tristate "H-TCP"
- default m
+ tristate "H-TCP"
+ default m
---help---
H-TCP is a send-side only modifications of the TCP Reno
protocol stack that optimizes the performance of TCP
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index 6120a7800975..69443e9a3aa5 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -170,13 +170,13 @@ config IP6_NF_MATCH_RT
To compile it as a module, choose M here. If unsure, say N.
config IP6_NF_MATCH_SRH
- tristate '"srh" Segment Routing header match support'
- depends on NETFILTER_ADVANCED
- help
- srh matching allows you to match packets based on the segment
+ tristate '"srh" Segment Routing header match support'
+ depends on NETFILTER_ADVANCED
+ help
+ srh matching allows you to match packets based on the segment
routing header of the packet.
- To compile it as a module, choose M here. If unsure, say N.
+ To compile it as a module, choose M here. If unsure, say N.
# The targets
config IP6_NF_TARGET_HL
@@ -249,10 +249,10 @@ config IP6_NF_SECURITY
depends on SECURITY
depends on NETFILTER_ADVANCED
help
- This option adds a `security' table to iptables, for use
- with Mandatory Access Control (MAC) policy.
+ This option adds a `security' table to iptables, for use
+ with Mandatory Access Control (MAC) policy.
- If unsure, say N.
+ If unsure, say N.
config IP6_NF_NAT
tristate "ip6tables NAT support"
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 34ec7afec116..91efae88e8c2 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -697,7 +697,7 @@ config NF_FLOW_TABLE_INET
tristate "Netfilter flow table mixed IPv4/IPv6 module"
depends on NF_FLOW_TABLE
help
- This option adds the flow table mixed IPv4/IPv6 support.
+ This option adds the flow table mixed IPv4/IPv6 support.
To compile it as a module, choose M here.
diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
index f6f1a0d5c47d..5b672e05d758 100644
--- a/net/netfilter/ipvs/Kconfig
+++ b/net/netfilter/ipvs/Kconfig
@@ -135,7 +135,7 @@ config IP_VS_WRR
module, choose M here. If unsure, say N.
config IP_VS_LC
- tristate "least-connection scheduling"
+ tristate "least-connection scheduling"
---help---
The least-connection scheduling algorithm directs network
connections to the server with the least number of active
@@ -145,7 +145,7 @@ config IP_VS_LC
module, choose M here. If unsure, say N.
config IP_VS_WLC
- tristate "weighted least-connection scheduling"
+ tristate "weighted least-connection scheduling"
---help---
The weighted least-connection scheduling algorithm directs network
connections to the server with the least active connections
@@ -333,7 +333,7 @@ config IP_VS_NFCT
config IP_VS_PE_SIP
tristate "SIP persistence engine"
- depends on IP_VS_PROTO_UDP
+ depends on IP_VS_PROTO_UDP
depends on NF_CONNTRACK_SIP
---help---
Allow persistence based on the SIP Call-ID
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 38ea7f0f2699..c64e154bc18f 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -23,6 +23,6 @@ config RDS_TCP
This transport does not support RDMA operations.
config RDS_DEBUG
- bool "RDS debugging messages"
+ bool "RDS debugging messages"
depends on RDS
- default n
+ default n
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index b3faafeafab9..5b044ae6dc1e 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -324,7 +324,7 @@ config NET_SCH_CAKE
tristate "Common Applications Kept Enhanced (CAKE)"
help
Say Y here if you want to use the Common Applications Kept Enhanced
- (CAKE) queue management algorithm.
+ (CAKE) queue management algorithm.
To compile this driver as a module, choose M here: the module
will be called sch_cake.
@@ -730,8 +730,8 @@ config NET_CLS_ACT
config NET_ACT_POLICE
tristate "Traffic Policing"
- depends on NET_CLS_ACT
- ---help---
+ depends on NET_CLS_ACT
+ ---help---
Say Y here if you want to do traffic policing, i.e. strict
bandwidth limiting. This action replaces the existing policing
module.
@@ -740,9 +740,9 @@ config NET_ACT_POLICE
module will be called act_police.
config NET_ACT_GACT
- tristate "Generic actions"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Generic actions"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to take generic actions such as dropping and
accepting packets.
@@ -750,15 +750,15 @@ config NET_ACT_GACT
module will be called act_gact.
config GACT_PROB
- bool "Probability support"
- depends on NET_ACT_GACT
- ---help---
+ bool "Probability support"
+ depends on NET_ACT_GACT
+ ---help---
Say Y here to use the generic action randomly or deterministically.
config NET_ACT_MIRRED
- tristate "Redirecting and Mirroring"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Redirecting and Mirroring"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to allow packets to be mirrored or redirected to
other devices.
@@ -766,10 +766,10 @@ config NET_ACT_MIRRED
module will be called act_mirred.
config NET_ACT_SAMPLE
- tristate "Traffic Sampling"
- depends on NET_CLS_ACT
- select PSAMPLE
- ---help---
+ tristate "Traffic Sampling"
+ depends on NET_CLS_ACT
+ select PSAMPLE
+ ---help---
Say Y here to allow packet sampling tc action. The packet sample
action consists of statistically choosing packets and sampling
them using the psample module.
@@ -778,9 +778,9 @@ config NET_ACT_SAMPLE
module will be called act_sample.
config NET_ACT_IPT
- tristate "IPtables targets"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
- ---help---
+ tristate "IPtables targets"
+ depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ ---help---
Say Y here to be able to invoke iptables targets after successful
classification.
@@ -788,9 +788,9 @@ config NET_ACT_IPT
module will be called act_ipt.
config NET_ACT_NAT
- tristate "Stateless NAT"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Stateless NAT"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to do stateless NAT on IPv4 packets. You should use
netfilter for NAT unless you know what you are doing.
@@ -798,18 +798,18 @@ config NET_ACT_NAT
module will be called act_nat.
config NET_ACT_PEDIT
- tristate "Packet Editing"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Packet Editing"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here if you want to mangle the content of packets.
To compile this code as a module, choose M here: the
module will be called act_pedit.
config NET_ACT_SIMP
- tristate "Simple Example (Debug)"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Simple Example (Debug)"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to add a simple action for demonstration purposes.
It is meant as an example and for debugging purposes. It will
print a configured policy string followed by the packet count
@@ -821,9 +821,9 @@ config NET_ACT_SIMP
module will be called act_simple.
config NET_ACT_SKBEDIT
- tristate "SKB Editing"
- depends on NET_CLS_ACT
- ---help---
+ tristate "SKB Editing"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to change skb priority or queue_mapping settings.
If unsure, say N.
@@ -832,10 +832,10 @@ config NET_ACT_SKBEDIT
module will be called act_skbedit.
config NET_ACT_CSUM
- tristate "Checksum Updating"
- depends on NET_CLS_ACT && INET
- select LIBCRC32C
- ---help---
+ tristate "Checksum Updating"
+ depends on NET_CLS_ACT && INET
+ select LIBCRC32C
+ ---help---
Say Y here to update some common checksum after some direct
packet alterations.
@@ -854,9 +854,9 @@ config NET_ACT_MPLS
module will be called act_mpls.
config NET_ACT_VLAN
- tristate "Vlan manipulation"
- depends on NET_CLS_ACT
- ---help---
+ tristate "Vlan manipulation"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to push or pop vlan headers.
If unsure, say N.
@@ -865,9 +865,9 @@ config NET_ACT_VLAN
module will be called act_vlan.
config NET_ACT_BPF
- tristate "BPF based action"
- depends on NET_CLS_ACT
- ---help---
+ tristate "BPF based action"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to execute BPF code on packets. The BPF code will decide
if the packet should be dropped or not.
@@ -877,10 +877,10 @@ config NET_ACT_BPF
module will be called act_bpf.
config NET_ACT_CONNMARK
- tristate "Netfilter Connection Mark Retriever"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
- depends on NF_CONNTRACK && NF_CONNTRACK_MARK
- ---help---
+ tristate "Netfilter Connection Mark Retriever"
+ depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ depends on NF_CONNTRACK && NF_CONNTRACK_MARK
+ ---help---
Say Y here to allow retrieving of conn mark
If unsure, say N.
@@ -889,10 +889,10 @@ config NET_ACT_CONNMARK
module will be called act_connmark.
config NET_ACT_CTINFO
- tristate "Netfilter Connection Mark Actions"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
- depends on NF_CONNTRACK && NF_CONNTRACK_MARK
- help
+ tristate "Netfilter Connection Mark Actions"
+ depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ depends on NF_CONNTRACK && NF_CONNTRACK_MARK
+ help
Say Y here to allow transfer of a connmark stored information.
Current actions transfer connmark stored DSCP into
ipv4/v6 diffserv and/or to transfer connmark to packet
@@ -906,21 +906,21 @@ config NET_ACT_CTINFO
module will be called act_ctinfo.
config NET_ACT_SKBMOD
- tristate "skb data modification action"
- depends on NET_CLS_ACT
- ---help---
- Say Y here to allow modification of skb data
+ tristate "skb data modification action"
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here to allow modification of skb data
- If unsure, say N.
+ If unsure, say N.
- To compile this code as a module, choose M here: the
- module will be called act_skbmod.
+ To compile this code as a module, choose M here: the
+ module will be called act_skbmod.
config NET_ACT_IFE
- tristate "Inter-FE action based on IETF ForCES InterFE LFB"
- depends on NET_CLS_ACT
- select NET_IFE
- ---help---
+ tristate "Inter-FE action based on IETF ForCES InterFE LFB"
+ depends on NET_CLS_ACT
+ select NET_IFE
+ ---help---
Say Y here to allow for sourcing and terminating metadata
For details refer to netdev01 paper:
"Distributing Linux Traffic Control Classifier-Action Subsystem"
@@ -930,9 +930,9 @@ config NET_ACT_IFE
module will be called act_ife.
config NET_ACT_TUNNEL_KEY
- tristate "IP tunnel metadata manipulation"
- depends on NET_CLS_ACT
- ---help---
+ tristate "IP tunnel metadata manipulation"
+ depends on NET_CLS_ACT
+ ---help---
Say Y here to set/release ip tunnel metadata.
If unsure, say N.
@@ -941,9 +941,9 @@ config NET_ACT_TUNNEL_KEY
module will be called act_tunnel_key.
config NET_ACT_CT
- tristate "connection tracking tc action"
- depends on NET_CLS_ACT && NF_CONNTRACK && NF_NAT
- help
+ tristate "connection tracking tc action"
+ depends on NET_CLS_ACT && NF_CONNTRACK && NF_NAT
+ help
Say Y here to allow sending the packets to conntrack module.
If unsure, say N.
@@ -952,16 +952,16 @@ config NET_ACT_CT
module will be called act_ct.
config NET_IFE_SKBMARK
- tristate "Support to encoding decoding skb mark on IFE action"
- depends on NET_ACT_IFE
+ tristate "Support to encoding decoding skb mark on IFE action"
+ depends on NET_ACT_IFE
config NET_IFE_SKBPRIO
- tristate "Support to encoding decoding skb prio on IFE action"
- depends on NET_ACT_IFE
+ tristate "Support to encoding decoding skb prio on IFE action"
+ depends on NET_ACT_IFE
config NET_IFE_SKBTCINDEX
- tristate "Support to encoding decoding skb tcindex on IFE action"
- depends on NET_ACT_IFE
+ tristate "Support to encoding decoding skb tcindex on IFE action"
+ depends on NET_ACT_IFE
config NET_TC_SKB_EXT
bool "TC recirculation support"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] sch_netem: fix a divide by zero in tabledist()
From: Eric Dumazet @ 2019-09-23 15:52 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet
Cc: David S . Miller, netdev, Eric Dumazet, syzbot
In-Reply-To: <20190920191516.073d88b6@cakuba.netronome.com>
On 9/20/19 7:15 PM, Jakub Kicinski wrote:
> On Wed, 18 Sep 2019 08:05:39 -0700, Eric Dumazet wrote:
>> syzbot managed to crash the kernel in tabledist() loading
>> an empty distribution table.
>>
>> t = dist->table[rnd % dist->size];
>>
>> Simply return an error when such load is attempted.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Reported-by: syzbot <syzkaller@googlegroups.com>
>
> Applied, queued, thank you!
>
Note that another divide by zero seems possible in the same function,
if sigma = 0x8000000
2*sigma becomes zero, and we have yet another issue in :
if (dist == NULL)
return ((rnd % (2 * sigma)) + mu) - sigma;
^ permalink raw reply
* [PATCH trivial 2/2] drivers: net: Fix Kconfig indentation
From: Krzysztof Kozlowski @ 2019-09-23 15:52 UTC (permalink / raw)
To: David S. Miller, Michael Grzeschik, Wolfgang Grandegger,
Marc Kleine-Budde, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, Jiri Kosina, netdev,
linux-kernel, linux-can, linux-rdma, linux-wireless, b.a.t.m.a.n,
netfilter-devel, coreteam, lvs-devel, rds-devel
Cc: Krzysztof Kozlowski
In-Reply-To: <20190923155243.6997-1-krzk@kernel.org>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/net/Kconfig | 2 +-
drivers/net/arcnet/Kconfig | 26 ++--
drivers/net/can/usb/Kconfig | 8 +-
drivers/net/ethernet/allwinner/Kconfig | 10 +-
drivers/net/ethernet/emulex/benet/Kconfig | 2 +-
.../net/ethernet/mellanox/mlx5/core/Kconfig | 36 +++---
drivers/net/ethernet/nxp/Kconfig | 8 +-
drivers/net/ethernet/pensando/Kconfig | 4 +-
drivers/net/phy/Kconfig | 6 +-
drivers/net/wireless/ath/Kconfig | 2 +-
drivers/net/wireless/ath/ar5523/Kconfig | 4 +-
drivers/net/wireless/ath/ath6kl/Kconfig | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
drivers/net/wireless/ath/carl9170/Kconfig | 6 +-
drivers/net/wireless/atmel/Kconfig | 32 ++---
drivers/net/wireless/intel/ipw2x00/Kconfig | 116 +++++++++---------
drivers/net/wireless/intel/iwlegacy/Kconfig | 6 +-
drivers/net/wireless/intel/iwlwifi/Kconfig | 6 +-
drivers/net/wireless/ralink/rt2x00/Kconfig | 24 ++--
19 files changed, 151 insertions(+), 151 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 48e209e55843..df1c7989e13d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -487,7 +487,7 @@ config FUJITSU_ES
depends on ACPI
help
This driver provides support for Extended Socket network device
- on Extended Partitioning of FUJITSU PRIMEQUEST 2000 E2 series.
+ on Extended Partitioning of FUJITSU PRIMEQUEST 2000 E2 series.
config THUNDERBOLT_NET
tristate "Networking over Thunderbolt cable"
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index faeb4419b205..27551bf3d7e4 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -56,19 +56,19 @@ config ARCNET_CAP
tristate "Enable CAP mode packet interface"
help
ARCnet "cap mode" packet encapsulation. Used to get the hardware
- acknowledge back to userspace. After the initial protocol byte every
- packet is stuffed with an extra 4 byte "cookie" which doesn't
- actually appear on the network. After transmit the driver will send
- back a packet with protocol byte 0 containing the status of the
- transmission:
- 0=no hardware acknowledge
- 1=excessive nak
- 2=transmission accepted by the receiver hardware
-
- Received packets are also stuffed with the extra 4 bytes but it will
- be random data.
-
- Cap only listens to protocol 1-8.
+ acknowledge back to userspace. After the initial protocol byte every
+ packet is stuffed with an extra 4 byte "cookie" which doesn't
+ actually appear on the network. After transmit the driver will send
+ back a packet with protocol byte 0 containing the status of the
+ transmission:
+ 0=no hardware acknowledge
+ 1=excessive nak
+ 2=transmission accepted by the receiver hardware
+
+ Received packets are also stuffed with the extra 4 bytes but it will
+ be random data.
+
+ Cap only listens to protocol 1-8.
config ARCNET_COM90xx
tristate "ARCnet COM90xx (normal) chipset driver"
diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
index 4b3d0ddcda79..b412f7ba4f89 100644
--- a/drivers/net/can/usb/Kconfig
+++ b/drivers/net/can/usb/Kconfig
@@ -15,10 +15,10 @@ config CAN_EMS_USB
from EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
config CAN_ESD_USB2
- tristate "ESD USB/2 CAN/USB interface"
- ---help---
- This driver supports the CAN-USB/2 interface
- from esd electronic system design gmbh (http://www.esd.eu).
+ tristate "ESD USB/2 CAN/USB interface"
+ ---help---
+ This driver supports the CAN-USB/2 interface
+ from esd electronic system design gmbh (http://www.esd.eu).
config CAN_GS_USB
tristate "Geschwister Schneider UG interfaces"
diff --git a/drivers/net/ethernet/allwinner/Kconfig b/drivers/net/ethernet/allwinner/Kconfig
index a5e2bcbf2722..264a482ec31d 100644
--- a/drivers/net/ethernet/allwinner/Kconfig
+++ b/drivers/net/ethernet/allwinner/Kconfig
@@ -21,17 +21,17 @@ config NET_VENDOR_ALLWINNER
if NET_VENDOR_ALLWINNER
config SUN4I_EMAC
- tristate "Allwinner A10 EMAC support"
+ tristate "Allwinner A10 EMAC support"
depends on ARCH_SUNXI
depends on OF
select CRC32
select MII
select PHYLIB
select MDIO_SUN4I
- ---help---
- Support for Allwinner A10 EMAC ethernet driver.
+ ---help---
+ Support for Allwinner A10 EMAC ethernet driver.
- To compile this driver as a module, choose M here. The module
- will be called sun4i-emac.
+ To compile this driver as a module, choose M here. The module
+ will be called sun4i-emac.
endif # NET_VENDOR_ALLWINNER
diff --git a/drivers/net/ethernet/emulex/benet/Kconfig b/drivers/net/ethernet/emulex/benet/Kconfig
index e8c7eb842dbe..17d300ea9955 100644
--- a/drivers/net/ethernet/emulex/benet/Kconfig
+++ b/drivers/net/ethernet/emulex/benet/Kconfig
@@ -48,5 +48,5 @@ config BE2NET_SKYHAWK
chipsets. (e.g. OneConnect OCe14xxx)
comment "WARNING: be2net is useless without any enabled chip"
- depends on BE2NET_BE2=n && BE2NET_BE3=n && BE2NET_LANCER=n && \
+ depends on BE2NET_BE2=n && BE2NET_BE3=n && BE2NET_LANCER=n && \
BE2NET_SKYHAWK=n && BE2NET
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index 0dba272a5b2f..a1f20b205299 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -20,15 +20,15 @@ config MLX5_ACCEL
bool
config MLX5_FPGA
- bool "Mellanox Technologies Innova support"
- depends on MLX5_CORE
+ bool "Mellanox Technologies Innova support"
+ depends on MLX5_CORE
select MLX5_ACCEL
- ---help---
- Build support for the Innova family of network cards by Mellanox
- Technologies. Innova network cards are comprised of a ConnectX chip
- and an FPGA chip on one board. If you select this option, the
- mlx5_core driver will include the Innova FPGA core and allow building
- sandbox-specific client drivers.
+ ---help---
+ Build support for the Innova family of network cards by Mellanox
+ Technologies. Innova network cards are comprised of a ConnectX chip
+ and an FPGA chip on one board. If you select this option, the
+ mlx5_core driver will include the Innova FPGA core and allow building
+ sandbox-specific client drivers.
config MLX5_CORE_EN
bool "Mellanox 5th generation network adapters (ConnectX series) Ethernet support"
@@ -58,14 +58,14 @@ config MLX5_EN_RXNFC
API.
config MLX5_MPFS
- bool "Mellanox Technologies MLX5 MPFS support"
- depends on MLX5_CORE_EN
+ bool "Mellanox Technologies MLX5 MPFS support"
+ depends on MLX5_CORE_EN
default y
- ---help---
+ ---help---
Mellanox Technologies Ethernet Multi-Physical Function Switch (MPFS)
- support in ConnectX NIC. MPFs is required for when multi-PF configuration
- is enabled to allow passing user configured unicast MAC addresses to the
- requesting PF.
+ support in ConnectX NIC. MPFs is required for when multi-PF configuration
+ is enabled to allow passing user configured unicast MAC addresses to the
+ requesting PF.
config MLX5_ESWITCH
bool "Mellanox Technologies MLX5 SRIOV E-Switch support"
@@ -73,10 +73,10 @@ config MLX5_ESWITCH
default y
---help---
Mellanox Technologies Ethernet SRIOV E-Switch support in ConnectX NIC.
- E-Switch provides internal SRIOV packet steering and switching for the
- enabled VFs and PF in two available modes:
- Legacy SRIOV mode (L2 mac vlan steering based).
- Switchdev mode (eswitch offloads).
+ E-Switch provides internal SRIOV packet steering and switching for the
+ enabled VFs and PF in two available modes:
+ Legacy SRIOV mode (L2 mac vlan steering based).
+ Switchdev mode (eswitch offloads).
config MLX5_CORE_EN_DCB
bool "Data Center Bridging (DCB) Support"
diff --git a/drivers/net/ethernet/nxp/Kconfig b/drivers/net/ethernet/nxp/Kconfig
index 418afb84c84b..ee83a71c2509 100644
--- a/drivers/net/ethernet/nxp/Kconfig
+++ b/drivers/net/ethernet/nxp/Kconfig
@@ -1,9 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config LPC_ENET
- tristate "NXP ethernet MAC on LPC devices"
- depends on ARCH_LPC32XX || COMPILE_TEST
- select PHYLIB
- help
+ tristate "NXP ethernet MAC on LPC devices"
+ depends on ARCH_LPC32XX || COMPILE_TEST
+ select PHYLIB
+ help
Say Y or M here if you want to use the NXP ethernet MAC included on
some NXP LPC devices. You can safely enable this option for LPC32xx
SoC. Also available as a module.
diff --git a/drivers/net/ethernet/pensando/Kconfig b/drivers/net/ethernet/pensando/Kconfig
index 5ea570be8379..bd0583e409df 100644
--- a/drivers/net/ethernet/pensando/Kconfig
+++ b/drivers/net/ethernet/pensando/Kconfig
@@ -26,7 +26,7 @@ config IONIC
found in
<file:Documentation/networking/device_drivers/pensando/ionic.rst>.
- To compile this driver as a module, choose M here. The module
- will be called ionic.
+ To compile this driver as a module, choose M here. The module
+ will be called ionic.
endif # NET_VENDOR_PENSANDO
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 03be30cde552..fe602648b99f 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -460,9 +460,9 @@ config RENESAS_PHY
Supports the Renesas PHYs uPD60620 and uPD60620A.
config ROCKCHIP_PHY
- tristate "Driver for Rockchip Ethernet PHYs"
- ---help---
- Currently supports the integrated Ethernet PHY.
+ tristate "Driver for Rockchip Ethernet PHYs"
+ ---help---
+ Currently supports the integrated Ethernet PHY.
config SMSC_PHY
tristate "SMSC PHYs"
diff --git a/drivers/net/wireless/ath/Kconfig b/drivers/net/wireless/ath/Kconfig
index d98d6ac90f3d..56616d988c96 100644
--- a/drivers/net/wireless/ath/Kconfig
+++ b/drivers/net/wireless/ath/Kconfig
@@ -34,7 +34,7 @@ config ATH_TRACEPOINTS
depends on ATH_DEBUG
depends on EVENT_TRACING
---help---
- This option enables tracepoints for atheros wireless drivers.
+ This option enables tracepoints for atheros wireless drivers.
Currently, ath9k makes use of this facility.
config ATH_REG_DYNAMIC_USER_REG_HINTS
diff --git a/drivers/net/wireless/ath/ar5523/Kconfig b/drivers/net/wireless/ath/ar5523/Kconfig
index 41d3c9a48b08..65b39c7d035d 100644
--- a/drivers/net/wireless/ath/ar5523/Kconfig
+++ b/drivers/net/wireless/ath/ar5523/Kconfig
@@ -5,5 +5,5 @@ config AR5523
select ATH_COMMON
select FW_LOADER
---help---
- This module add support for AR5523 based USB dongles such as D-Link
- DWL-G132, Netgear WPN111 and many more.
+ This module add support for AR5523 based USB dongles such as D-Link
+ DWL-G132, Netgear WPN111 and many more.
diff --git a/drivers/net/wireless/ath/ath6kl/Kconfig b/drivers/net/wireless/ath/ath6kl/Kconfig
index dcf8ca0dcc52..62c22fdcca38 100644
--- a/drivers/net/wireless/ath/ath6kl/Kconfig
+++ b/drivers/net/wireless/ath/ath6kl/Kconfig
@@ -2,7 +2,7 @@
config ATH6KL
tristate "Atheros mobile chipsets support"
depends on CFG80211
- ---help---
+ ---help---
This module adds core support for wireless adapters based on
Atheros AR6003 and AR6004 chipsets. You still need separate
bus drivers for USB and SDIO to be able to use real devices.
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 2d1247f61297..c99f42284465 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -148,7 +148,7 @@ config ATH9K_CHANNEL_CONTEXT
depends on ATH9K
default n
---help---
- This option enables channel context support in ath9k, which is needed
+ This option enables channel context support in ath9k, which is needed
for multi-channel concurrency. Enable this if P2P PowerSave support
is required.
diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
index 757eb765e17c..b1bce7aad399 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -41,9 +41,9 @@ config CARL9170_WPC
default y
config CARL9170_HWRNG
- bool "Random number generator"
- depends on CARL9170 && (HW_RANDOM = y || HW_RANDOM = CARL9170)
- default n
+ bool "Random number generator"
+ depends on CARL9170 && (HW_RANDOM = y || HW_RANDOM = CARL9170)
+ default n
help
Provides a hardware random number generator to the kernel.
diff --git a/drivers/net/wireless/atmel/Kconfig b/drivers/net/wireless/atmel/Kconfig
index 809bdf331848..4c0556b3a5ba 100644
--- a/drivers/net/wireless/atmel/Kconfig
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -20,22 +20,22 @@ config ATMEL
select FW_LOADER
select CRC32
---help---
- A driver 802.11b wireless cards based on the Atmel fast-vnet
- chips. This driver supports standard Linux wireless extensions.
+ A driver 802.11b wireless cards based on the Atmel fast-vnet
+ chips. This driver supports standard Linux wireless extensions.
- Many cards based on this chipset do not have flash memory
- and need their firmware loaded at start-up. If yours is
- one of these, you will need to provide a firmware image
- to be loaded into the card by the driver. The Atmel
- firmware package can be downloaded from
- <http://www.thekelleys.org.uk/atmel>
+ Many cards based on this chipset do not have flash memory
+ and need their firmware loaded at start-up. If yours is
+ one of these, you will need to provide a firmware image
+ to be loaded into the card by the driver. The Atmel
+ firmware package can be downloaded from
+ <http://www.thekelleys.org.uk/atmel>
config PCI_ATMEL
tristate "Atmel at76c506 PCI cards"
depends on ATMEL && PCI
---help---
- Enable support for PCI and mini-PCI cards containing the
- Atmel at76c506 chip.
+ Enable support for PCI and mini-PCI cards containing the
+ Atmel at76c506 chip.
config PCMCIA_ATMEL
tristate "Atmel at76c502/at76c504 PCMCIA cards"
@@ -48,11 +48,11 @@ config PCMCIA_ATMEL
Atmel at76c502 and at76c504 chips.
config AT76C50X_USB
- tristate "Atmel at76c503/at76c505/at76c505a USB cards"
- depends on MAC80211 && USB
- select FW_LOADER
- ---help---
- Enable support for USB Wireless devices using Atmel at76c503,
- at76c505 or at76c505a chips.
+ tristate "Atmel at76c503/at76c505/at76c505a USB cards"
+ depends on MAC80211 && USB
+ select FW_LOADER
+ ---help---
+ Enable support for USB Wireless devices using Atmel at76c503,
+ at76c505 or at76c505a chips.
endif # WLAN_VENDOR_ATMEL
diff --git a/drivers/net/wireless/intel/ipw2x00/Kconfig b/drivers/net/wireless/intel/ipw2x00/Kconfig
index 5d2878a73732..ab17903ba9f8 100644
--- a/drivers/net/wireless/intel/ipw2x00/Kconfig
+++ b/drivers/net/wireless/intel/ipw2x00/Kconfig
@@ -13,37 +13,37 @@ config IPW2100
select LIB80211
select LIBIPW
---help---
- A driver for the Intel PRO/Wireless 2100 Network
+ A driver for the Intel PRO/Wireless 2100 Network
Connection 802.11b wireless network adapter.
- See <file:Documentation/networking/device_drivers/intel/ipw2100.txt>
+ See <file:Documentation/networking/device_drivers/intel/ipw2100.txt>
for information on the capabilities currently enabled in this driver
and for tips for debugging issues and problems.
In order to use this driver, you will need a firmware image for it.
- You can obtain the firmware from
- <http://ipw2100.sf.net/>. Once you have the firmware image, you
+ You can obtain the firmware from
+ <http://ipw2100.sf.net/>. Once you have the firmware image, you
will need to place it in /lib/firmware.
- You will also very likely need the Wireless Tools in order to
- configure your card:
+ You will also very likely need the Wireless Tools in order to
+ configure your card:
- <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
+ <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
+
+ It is recommended that you compile this driver as a module (M)
+ rather than built-in (Y). This driver requires firmware at device
+ initialization time, and when built-in this typically happens
+ before the filesystem is accessible (hence firmware will be
+ unavailable and initialization will fail). If you do choose to build
+ this driver into your kernel image, you can avoid this problem by
+ including the firmware and a firmware loader in an initramfs.
- It is recommended that you compile this driver as a module (M)
- rather than built-in (Y). This driver requires firmware at device
- initialization time, and when built-in this typically happens
- before the filesystem is accessible (hence firmware will be
- unavailable and initialization will fail). If you do choose to build
- this driver into your kernel image, you can avoid this problem by
- including the firmware and a firmware loader in an initramfs.
-
config IPW2100_MONITOR
- bool "Enable promiscuous mode"
- depends on IPW2100
- ---help---
+ bool "Enable promiscuous mode"
+ depends on IPW2100
+ ---help---
Enables promiscuous/monitor mode support for the ipw2100 driver.
- With this feature compiled into the driver, you can switch to
+ With this feature compiled into the driver, you can switch to
promiscuous mode via the Wireless Tool's Monitor mode. While in this
mode, no packets can be sent.
@@ -51,17 +51,17 @@ config IPW2100_DEBUG
bool "Enable full debugging output in IPW2100 module."
depends on IPW2100
---help---
- This option will enable debug tracing output for the IPW2100.
+ This option will enable debug tracing output for the IPW2100.
- This will result in the kernel module being ~60k larger. You can
- control which debug output is sent to the kernel log by setting the
- value in
+ This will result in the kernel module being ~60k larger. You can
+ control which debug output is sent to the kernel log by setting the
+ value in
/sys/bus/pci/drivers/ipw2100/debug_level
This entry will only exist if this option is enabled.
- If you are not trying to debug or develop the IPW2100 driver, you
+ If you are not trying to debug or develop the IPW2100 driver, you
most likely want to say N here.
config IPW2200
@@ -75,37 +75,37 @@ config IPW2200
select LIB80211
select LIBIPW
---help---
- A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network
- Connection adapters.
+ A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network
+ Connection adapters.
- See <file:Documentation/networking/device_drivers/intel/ipw2200.txt>
+ See <file:Documentation/networking/device_drivers/intel/ipw2200.txt>
for information on the capabilities currently enabled in this
driver and for tips for debugging issues and problems.
In order to use this driver, you will need a firmware image for it.
- You can obtain the firmware from
- <http://ipw2200.sf.net/>. See the above referenced README.ipw2200
+ You can obtain the firmware from
+ <http://ipw2200.sf.net/>. See the above referenced README.ipw2200
for information on where to install the firmware images.
- You will also very likely need the Wireless Tools in order to
- configure your card:
+ You will also very likely need the Wireless Tools in order to
+ configure your card:
- <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
+ <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
- It is recommended that you compile this driver as a module (M)
- rather than built-in (Y). This driver requires firmware at device
- initialization time, and when built-in this typically happens
- before the filesystem is accessible (hence firmware will be
- unavailable and initialization will fail). If you do choose to build
- this driver into your kernel image, you can avoid this problem by
- including the firmware and a firmware loader in an initramfs.
+ It is recommended that you compile this driver as a module (M)
+ rather than built-in (Y). This driver requires firmware at device
+ initialization time, and when built-in this typically happens
+ before the filesystem is accessible (hence firmware will be
+ unavailable and initialization will fail). If you do choose to build
+ this driver into your kernel image, you can avoid this problem by
+ including the firmware and a firmware loader in an initramfs.
config IPW2200_MONITOR
- bool "Enable promiscuous mode"
- depends on IPW2200
- ---help---
+ bool "Enable promiscuous mode"
+ depends on IPW2200
+ ---help---
Enables promiscuous/monitor mode support for the ipw2200 driver.
- With this feature compiled into the driver, you can switch to
+ With this feature compiled into the driver, you can switch to
promiscuous mode via the Wireless Tool's Monitor mode. While in this
mode, no packets can be sent.
@@ -118,28 +118,28 @@ config IPW2200_PROMISCUOUS
depends on IPW2200_MONITOR
select IPW2200_RADIOTAP
---help---
- Enables the creation of a second interface prefixed 'rtap'.
- This second interface will provide every received in radiotap
+ Enables the creation of a second interface prefixed 'rtap'.
+ This second interface will provide every received in radiotap
format.
- This is useful for performing wireless network analysis while
- maintaining an active association.
+ This is useful for performing wireless network analysis while
+ maintaining an active association.
+
+ Example usage:
- Example usage:
+ % modprobe ipw2200 rtap_iface=1
+ % ifconfig rtap0 up
+ % tethereal -i rtap0
- % modprobe ipw2200 rtap_iface=1
- % ifconfig rtap0 up
- % tethereal -i rtap0
+ If you do not specify 'rtap_iface=1' as a module parameter then
+ the rtap interface will not be created and you will need to turn
+ it on via sysfs:
- If you do not specify 'rtap_iface=1' as a module parameter then
- the rtap interface will not be created and you will need to turn
- it on via sysfs:
-
- % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
+ % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
config IPW2200_QOS
- bool "Enable QoS support"
- depends on IPW2200
+ bool "Enable QoS support"
+ depends on IPW2200
config IPW2200_DEBUG
bool "Enable full debugging output in IPW2200 module."
diff --git a/drivers/net/wireless/intel/iwlegacy/Kconfig b/drivers/net/wireless/intel/iwlegacy/Kconfig
index e329fd7b09c0..100f55858b13 100644
--- a/drivers/net/wireless/intel/iwlegacy/Kconfig
+++ b/drivers/net/wireless/intel/iwlegacy/Kconfig
@@ -91,9 +91,9 @@ config IWLEGACY_DEBUG
any problems you may encounter.
config IWLEGACY_DEBUGFS
- bool "iwlegacy (iwl 3945/4965) debugfs support"
- depends on IWLEGACY && MAC80211_DEBUGFS
- ---help---
+ bool "iwlegacy (iwl 3945/4965) debugfs support"
+ depends on IWLEGACY && MAC80211_DEBUGFS
+ ---help---
Enable creation of debugfs files for the iwlegacy drivers. This
is a low-impact option that allows getting insight into the
driver's state at runtime.
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 7dbc0d38bb3b..091d621ad25f 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -119,9 +119,9 @@ config IWLWIFI_DEBUG
any problems you may encounter.
config IWLWIFI_DEBUGFS
- bool "iwlwifi debugfs support"
- depends on MAC80211_DEBUGFS
- ---help---
+ bool "iwlwifi debugfs support"
+ depends on MAC80211_DEBUGFS
+ ---help---
Enable creation of debugfs files for the iwlwifi drivers. This
is a low-impact option that allows getting insight into the
driver's state at runtime.
diff --git a/drivers/net/wireless/ralink/rt2x00/Kconfig b/drivers/net/wireless/ralink/rt2x00/Kconfig
index 858f8aa3e616..f8a9244ce012 100644
--- a/drivers/net/wireless/ralink/rt2x00/Kconfig
+++ b/drivers/net/wireless/ralink/rt2x00/Kconfig
@@ -98,17 +98,17 @@ config RT2800PCI_RT53XX
bool "rt2800pci - Include support for rt53xx devices (EXPERIMENTAL)"
default y
---help---
- This adds support for rt53xx wireless chipset family to the
- rt2800pci driver.
- Supported chips: RT5390
+ This adds support for rt53xx wireless chipset family to the
+ rt2800pci driver.
+ Supported chips: RT5390
config RT2800PCI_RT3290
bool "rt2800pci - Include support for rt3290 devices (EXPERIMENTAL)"
default y
---help---
- This adds support for rt3290 wireless chipset family to the
- rt2800pci driver.
- Supported chips: RT3290
+ This adds support for rt3290 wireless chipset family to the
+ rt2800pci driver.
+ Supported chips: RT3290
endif
config RT2500USB
@@ -176,16 +176,16 @@ config RT2800USB_RT3573
config RT2800USB_RT53XX
bool "rt2800usb - Include support for rt53xx devices (EXPERIMENTAL)"
---help---
- This adds support for rt53xx wireless chipset family to the
- rt2800usb driver.
- Supported chips: RT5370
+ This adds support for rt53xx wireless chipset family to the
+ rt2800usb driver.
+ Supported chips: RT5370
config RT2800USB_RT55XX
bool "rt2800usb - Include support for rt55xx devices (EXPERIMENTAL)"
---help---
- This adds support for rt55xx wireless chipset family to the
- rt2800usb driver.
- Supported chips: RT5572
+ This adds support for rt55xx wireless chipset family to the
+ rt2800usb driver.
+ Supported chips: RT5572
config RT2800USB_UNKNOWN
bool "rt2800usb - Include support for unknown (USB) devices"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] sch_netem: fix a divide by zero in tabledist()
From: Eric Dumazet @ 2019-09-23 15:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jakub Kicinski, David S . Miller, netdev, syzbot
In-Reply-To: <722331f3-55f8-868f-0f52-60e17e28e862@gmail.com>
On Mon, Sep 23, 2019 at 8:53 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 9/20/19 7:15 PM, Jakub Kicinski wrote:
> > On Wed, 18 Sep 2019 08:05:39 -0700, Eric Dumazet wrote:
> >> syzbot managed to crash the kernel in tabledist() loading
> >> an empty distribution table.
> >>
> >> t = dist->table[rnd % dist->size];
> >>
> >> Simply return an error when such load is attempted.
> >>
> >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> >> Signed-off-by: Eric Dumazet <edumazet@google.com>
> >> Reported-by: syzbot <syzkaller@googlegroups.com>
> >
> > Applied, queued, thank you!
> >
>
> Note that another divide by zero seems possible in the same function,
> if sigma = 0x8000000
I meant 0x80000000 here (aka 2^31 )
>
>
> 2*sigma becomes zero, and we have yet another issue in :
>
> if (dist == NULL)
> return ((rnd % (2 * sigma)) + mu) - sigma;
>
>
^ permalink raw reply
* Re: [PATCH 5/6] vringh: fix copy direction of vringh_iov_push_kern()
From: Michael S. Tsirkin @ 2019-09-23 16:00 UTC (permalink / raw)
To: Alex Williamson
Cc: Jason Wang, kvm, linux-s390, linux-kernel, dri-devel, intel-gfx,
intel-gvt-dev, kwankhede, tiwei.bie, virtualization, netdev,
cohuck, maxime.coquelin, cunming.liang, zhihong.wang, rob.miller,
xiao.w.wang, haotian.wang, zhenyuw, zhi.a.wang, jani.nikula,
joonas.lahtinen, rodrigo.vivi, airlied, daniel, farman, pasic,
sebott, oberpar, heiko.carstens, gor, borntraeger, akrowiak,
freude, lingshan.zhu, idos, eperezma, lulu, parav
In-Reply-To: <20190923094559.765da494@x1.home>
On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote:
> On Mon, 23 Sep 2019 21:03:30 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
> > We want to copy from iov to buf, so the direction was wrong.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> > drivers/vhost/vringh.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
>
>
> Why is this included in the series? Seems like an unrelated fix being
> held up within a proposal for a new feature. Thanks,
>
> Alex
It's better to have it as patch 1/6, but it's a dependency of the
example driver in the series. I can reorder when I apply.
> > diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> > index 08ad0d1f0476..a0a2d74967ef 100644
> > --- a/drivers/vhost/vringh.c
> > +++ b/drivers/vhost/vringh.c
> > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t len)
> > return 0;
> > }
> >
> > +static inline int kern_xfer(void *dst, void *src, size_t len)
> > +{
> > + memcpy(dst, src, len);
> > + return 0;
> > +}
> > +
> > /**
> > * vringh_init_kern - initialize a vringh for a kernelspace vring.
> > * @vrh: the vringh to initialize.
> > @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern);
> > ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov,
> > const void *src, size_t len)
> > {
> > - return vringh_iov_xfer(wiov, (void *)src, len, xfer_kern);
> > + return vringh_iov_xfer(wiov, (void *)src, len, kern_xfer);
> > }
> > EXPORT_SYMBOL(vringh_iov_push_kern);
> >
^ permalink raw reply
* Re: [PATCH] drivers/net/fjes: fix a potential NULL pointer dereference
From: Allen @ 2019-09-23 16:04 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem, linux-kernel
In-Reply-To: <20190921184009.32edfa43@cakuba.netronome.com>
>
> If I'm looking at this right you are jumping to err_free_netdev without
> setting the err variable. It must had been set to 0 from the return of
> fjes_sw_init(). This means we will free the netdev, and return 0. This
> means probe will not fail and driver's remove function will be run
> at some point. fjes_remove it will try to free the netdev again.
Good catch. Here's a quick diff what I should have done,
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1236,9 +1236,21 @@ static int fjes_probe(struct platform_device
*plat_dev)
adapter->force_reset = false;
adapter->open_guard = false;
+ /* Re-initialize err to -ENOMEM to handle workqueue allocation
failures,
+ and we don't return 0 on failure.
+ */
+ err = -ENOMEM;
+
adapter->txrx_wq = alloc_workqueue(DRV_NAME "/txrx",
WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->txrx_wq))
+ goto err_free_netdev;
+
adapter->control_wq = alloc_workqueue(DRV_NAME "/control",
WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->control_wq)) {
+ destroy_workqueue(adapter->txrx_wq);
+ goto err_free_netdev;
+ }
> Looks like there's another existing bug here in that the work queues
> are not free when something fails in fjes_probe, just the netdev.
I shall look into it and send out a separate fix.
> Once you untangle that, and before you post a v2, could you please try
> to identify which commit introduced the regression and provide an
> appropriate "Fixes" tag?
>
Fixes: f2edc4e1b078("net: fjes: fjes_main: Remove create_workqueue")
- Allen
^ permalink raw reply
* Re: [PATCH 1/6] mdev: class id support
From: Alex Williamson @ 2019-09-23 16:05 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, linux-s390, linux-kernel, dri-devel, intel-gfx,
intel-gvt-dev, kwankhede, mst, tiwei.bie, virtualization, netdev,
cohuck, maxime.coquelin, cunming.liang, zhihong.wang, rob.miller,
xiao.w.wang, haotian.wang, zhenyuw, zhi.a.wang, jani.nikula,
joonas.lahtinen, rodrigo.vivi, airlied, daniel, farman, pasic,
sebott, oberpar, heiko.carstens, gor, borntraeger, akrowiak,
freude, lingshan.zhu, idos, eperezma, lulu, parav
In-Reply-To: <20190923130331.29324-2-jasowang@redhat.com>
On Mon, 23 Sep 2019 21:03:26 +0800
Jason Wang <jasowang@redhat.com> wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> class id support in bus match method to pair the mdev device and mdev
> driver correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev
> parent with the match method for mdev bus.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 7 +++++--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> drivers/s390/cio/vfio_ccw_ops.c | 2 +-
> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
> drivers/vfio/mdev/mdev_core.c | 14 ++++++++++++--
> drivers/vfio/mdev/mdev_driver.c | 14 ++++++++++++++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 ++++++
> include/linux/mdev.h | 7 ++++++-
> include/linux/mod_devicetable.h | 8 ++++++++
> samples/vfio-mdev/mbochs.c | 2 +-
> samples/vfio-mdev/mdpy.c | 2 +-
> samples/vfio-mdev/mtty.c | 2 +-
> 13 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..0e052072e1d8 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
> * @probe: called when new device created
> * @remove: called when device removed
> * @driver: device driver structure
> + * @id_table: the ids serviced by this driver.
> */
> struct mdev_driver {
> const char *name;
> int (*probe) (struct device *dev);
> void (*remove) (struct device *dev);
> struct device_driver driver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function calls
> @@ -116,7 +118,7 @@ to register and unregister itself with the core driver:
> * Register::
>
> extern int mdev_register_driver(struct mdev_driver *drv,
> - struct module *owner);
> + struct module *owner);
>
> * Unregister::
>
> @@ -163,7 +165,8 @@ A driver should use the mdev_parent_ops structure in the function call to
> register itself with the mdev core driver::
>
> extern int mdev_register_device(struct device *dev,
> - const struct mdev_parent_ops *ops);
> + const struct mdev_parent_ops *ops,
> + u8 class_id);
>
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 23aa3e50cbf8..19d51a35f019 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1625,7 +1625,7 @@ static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops)
> return -EFAULT;
> intel_vgpu_ops.supported_type_groups = kvm_vgpu_type_groups;
>
> - return mdev_register_device(dev, &intel_vgpu_ops);
> + return mdev_register_vfio_device(dev, &intel_vgpu_ops);
> }
>
> static void kvmgt_host_exit(struct device *dev)
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index f0d71ab77c50..246ff0f80944 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -588,7 +588,7 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
>
> int vfio_ccw_mdev_reg(struct subchannel *sch)
> {
> - return mdev_register_device(&sch->dev, &vfio_ccw_mdev_ops);
> + return mdev_register_vfio_device(&sch->dev, &vfio_ccw_mdev_ops);
> }
>
> void vfio_ccw_mdev_unreg(struct subchannel *sch)
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 5c0f53c6dde7..7487fc39d2c5 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1295,7 +1295,8 @@ int vfio_ap_mdev_register(void)
> {
> atomic_set(&matrix_dev->available_instances, MAX_ZDEV_ENTRIES_EXT);
>
> - return mdev_register_device(&matrix_dev->device, &vfio_ap_matrix_ops);
> + return mdev_register_vfio_device(&matrix_dev->device,
> + &vfio_ap_matrix_ops);
> }
>
> void vfio_ap_mdev_unregister(void)
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..a02c256a3514 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -135,11 +135,14 @@ static int mdev_device_remove_cb(struct device *dev, void *data)
> * mdev_register_device : Register a device
> * @dev: device structure representing parent device.
> * @ops: Parent device operation structure to be registered.
> + * @id: device id.
> *
> * Add device to list of registered parent devices.
> * Returns a negative value on error, otherwise 0.
> */
> -int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
> +int mdev_register_device(struct device *dev,
> + const struct mdev_parent_ops *ops,
> + u8 class_id)
> {
> int ret;
> struct mdev_parent *parent;
> @@ -175,6 +178,7 @@ int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
>
> parent->dev = dev;
> parent->ops = ops;
> + parent->class_id = class_id;
>
I don't think we want to tie the class_id to the parent. mdev parent
devices can create various types of devices, some might be virtio, some
might be vfio. I think the cover letter even suggests that's a
direction these virtio devices might be headed. It seems the class
should be on the resulting device itself. That also suggests that at
the parent we cannot have a single device_ops, the ops used will depend
on the type of device created. Perhaps that means we need vfio_ops
alongside virtio_ops, rather than a common device_ops. Thanks,
Alex
> if (!mdev_bus_compat_class) {
> mdev_bus_compat_class = class_compat_register("mdev_bus");
> @@ -208,7 +212,13 @@ int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
> put_device(dev);
> return ret;
> }
> -EXPORT_SYMBOL(mdev_register_device);
> +
> +int mdev_register_vfio_device(struct device *dev,
> + const struct mdev_parent_ops *ops)
> +{
> + return mdev_register_device(dev, ops, MDEV_ID_VFIO);
> +}
> +EXPORT_SYMBOL(mdev_register_vfio_device);
>
> /*
> * mdev_unregister_device : Unregister a parent device
> diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c
> index 0d3223aee20b..b70bbebc9dd3 100644
> --- a/drivers/vfio/mdev/mdev_driver.c
> +++ b/drivers/vfio/mdev/mdev_driver.c
> @@ -69,8 +69,22 @@ static int mdev_remove(struct device *dev)
> return 0;
> }
>
> +static int mdev_match(struct device *dev, struct device_driver *drv)
> +{
> + unsigned int i;
> + struct mdev_device *mdev = to_mdev_device(dev);
> + struct mdev_driver *mdrv = to_mdev_driver(drv);
> + const struct mdev_class_id *ids = mdrv->id_table;
> +
> + for (i = 0; ids[i].id; i++)
> + if (ids[i].id == mdev->parent->class_id)
> + return 1;
> + return 0;
> +}
> +
> struct bus_type mdev_bus_type = {
> .name = "mdev",
> + .match = mdev_match,
> .probe = mdev_probe,
> .remove = mdev_remove,
> };
> diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
> index 7d922950caaf..e58b07c866b1 100644
> --- a/drivers/vfio/mdev/mdev_private.h
> +++ b/drivers/vfio/mdev/mdev_private.h
> @@ -22,6 +22,7 @@ struct mdev_parent {
> struct list_head type_list;
> /* Synchronize device creation/removal with parent unregistration */
> struct rw_semaphore unreg_sem;
> + u8 class_id;
> };
>
> struct mdev_device {
> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
> index 30964a4e0a28..fd2a4d9a3f26 100644
> --- a/drivers/vfio/mdev/vfio_mdev.c
> +++ b/drivers/vfio/mdev/vfio_mdev.c
> @@ -120,10 +120,16 @@ static void vfio_mdev_remove(struct device *dev)
> vfio_del_group_dev(dev);
> }
>
> +static struct mdev_class_id id_table[] = {
> + { MDEV_ID_VFIO },
> + { 0 },
> +};
> +
> static struct mdev_driver vfio_mdev_driver = {
> .name = "vfio_mdev",
> .probe = vfio_mdev_probe,
> .remove = vfio_mdev_remove,
> + .id_table = id_table,
> };
>
> static int __init vfio_mdev_init(void)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 0ce30ca78db0..3ebae310f599 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -118,6 +118,7 @@ struct mdev_type_attribute mdev_type_attr_##_name = \
> * @probe: called when new device created
> * @remove: called when device removed
> * @driver: device driver structure
> + * @id_table: the ids serviced by this driver.
> *
> **/
> struct mdev_driver {
> @@ -125,6 +126,7 @@ struct mdev_driver {
> int (*probe)(struct device *dev);
> void (*remove)(struct device *dev);
> struct device_driver driver;
> + const struct mdev_class_id *id_table;
> };
>
> #define to_mdev_driver(drv) container_of(drv, struct mdev_driver, driver)
> @@ -135,7 +137,8 @@ const guid_t *mdev_uuid(struct mdev_device *mdev);
>
> extern struct bus_type mdev_bus_type;
>
> -int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops);
> +int mdev_register_vfio_device(struct device *dev,
> + const struct mdev_parent_ops *ops);
> void mdev_unregister_device(struct device *dev);
>
> int mdev_register_driver(struct mdev_driver *drv, struct module *owner);
> @@ -145,4 +148,6 @@ struct device *mdev_parent_dev(struct mdev_device *mdev);
> struct device *mdev_dev(struct mdev_device *mdev);
> struct mdev_device *mdev_from_dev(struct device *dev);
>
> +#define MDEV_ID_VFIO 1 /* VFIO device */
> +
> #endif /* MDEV_H */
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 5714fd35a83c..f32c6e44fb1a 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -821,4 +821,12 @@ struct wmi_device_id {
> const void *context;
> };
>
> +/**
> + * struct mdev_class_id - MDEV device class identifier
> + * @id: Used to identify a specific class of device, e.g vfio-mdev device.
> + */
> +struct mdev_class_id {
> + __u16 id;
> +};
> +
> #endif /* LINUX_MOD_DEVICETABLE_H */
> diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
> index ac5c8c17b1ff..71a4469be85d 100644
> --- a/samples/vfio-mdev/mbochs.c
> +++ b/samples/vfio-mdev/mbochs.c
> @@ -1468,7 +1468,7 @@ static int __init mbochs_dev_init(void)
> if (ret)
> goto failed2;
>
> - ret = mdev_register_device(&mbochs_dev, &mdev_fops);
> + ret = mdev_register_vfio_device(&mbochs_dev, &mdev_fops);
> if (ret)
> goto failed3;
>
> diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
> index cc86bf6566e4..d3029dd27d91 100644
> --- a/samples/vfio-mdev/mdpy.c
> +++ b/samples/vfio-mdev/mdpy.c
> @@ -775,7 +775,7 @@ static int __init mdpy_dev_init(void)
> if (ret)
> goto failed2;
>
> - ret = mdev_register_device(&mdpy_dev, &mdev_fops);
> + ret = mdev_register_vfio_device(&mdpy_dev, &mdev_fops);
> if (ret)
> goto failed3;
>
> diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> index 92e770a06ea2..744c88a6b22c 100644
> --- a/samples/vfio-mdev/mtty.c
> +++ b/samples/vfio-mdev/mtty.c
> @@ -1468,7 +1468,7 @@ static int __init mtty_dev_init(void)
> if (ret)
> goto failed2;
>
> - ret = mdev_register_device(&mtty_dev.dev, &mdev_fops);
> + ret = mdev_register_vfio_device(&mtty_dev.dev, &mdev_fops);
> if (ret)
> goto failed3;
>
^ permalink raw reply
* Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
From: Matt Cover @ 2019-09-23 16:31 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, davem, ast, daniel, kafai, songliubraving,
yhs, Eric Dumazet, Stanislav Fomichev, Matthew Cover, mail,
pabeni, Nicolas Dichtel, wangli39, lifei.shirley, tglx, netdev,
linux-kernel, bpf
In-Reply-To: <b96ecf36-8f13-4a52-5355-7d88ec9e4a98@redhat.com>
On Sun, Sep 22, 2019 at 10:16 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2019/9/23 上午11:18, Matt Cover wrote:
> > On Sun, Sep 22, 2019 at 7:34 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> On 2019/9/23 上午9:15, Matt Cover wrote:
> >>> On Sun, Sep 22, 2019 at 5:51 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> On 2019/9/23 上午6:30, Matt Cover wrote:
> >>>>> On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>> On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote:
> >>>>>>> On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>>> On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> >>>>>>>>> Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
> >>>>>>>>> to fallback to tun_automq_select_queue() for tx queue selection.
> >>>>>>>>>
> >>>>>>>>> Compilation of this exact patch was tested.
> >>>>>>>>>
> >>>>>>>>> For functional testing 3 additional printk()s were added.
> >>>>>>>>>
> >>>>>>>>> Functional testing results (on 2 txq tap device):
> >>>>>>>>>
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] ========== tun no prog ==========
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] ========== tun prog -1 ==========
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] ========== tun prog 0 ==========
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] ========== tun prog 1 ==========
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] ========== tun prog 2 ==========
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
> >>>>>>>>> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
> >>>>>>>> Could you add a bit more motivation data here?
> >>>>>>> Thank you for these questions Michael.
> >>>>>>>
> >>>>>>> I'll plan on adding the below information to the
> >>>>>>> commit message and submitting a v2 of this patch
> >>>>>>> when net-next reopens. In the meantime, it would
> >>>>>>> be very helpful to know if these answers address
> >>>>>>> some of your concerns.
> >>>>>>>
> >>>>>>>> 1. why is this a good idea
> >>>>>>> This change allows TUNSETSTEERINGEBPF progs to
> >>>>>>> do any of the following.
> >>>>>>> 1. implement queue selection for a subset of
> >>>>>>> traffic (e.g. special queue selection logic
> >>>>>>> for ipv4, but return negative and use the
> >>>>>>> default automq logic for ipv6)
> >>>>>>> 2. determine there isn't sufficient information
> >>>>>>> to do proper queue selection; return
> >>>>>>> negative and use the default automq logic
> >>>>>>> for the unknown
> >>>>>>> 3. implement a noop prog (e.g. do
> >>>>>>> bpf_trace_printk() then return negative and
> >>>>>>> use the default automq logic for everything)
> >>>>>>>
> >>>>>>>> 2. how do we know existing userspace does not rely on existing behaviour
> >>>>>>> Prior to this change a negative return from a
> >>>>>>> TUNSETSTEERINGEBPF prog would have been cast
> >>>>>>> into a u16 and traversed netdev_cap_txqueue().
> >>>>>>>
> >>>>>>> In most cases netdev_cap_txqueue() would have
> >>>>>>> found this value to exceed real_num_tx_queues
> >>>>>>> and queue_index would be updated to 0.
> >>>>>>>
> >>>>>>> It is possible that a TUNSETSTEERINGEBPF prog
> >>>>>>> return a negative value which when cast into a
> >>>>>>> u16 results in a positive queue_index less than
> >>>>>>> real_num_tx_queues. For example, on x86_64, a
> >>>>>>> return value of -65535 results in a queue_index
> >>>>>>> of 1; which is a valid queue for any multiqueue
> >>>>>>> device.
> >>>>>>>
> >>>>>>> It seems unlikely, however as stated above is
> >>>>>>> unfortunately possible, that existing
> >>>>>>> TUNSETSTEERINGEBPF programs would choose to
> >>>>>>> return a negative value rather than return the
> >>>>>>> positive value which holds the same meaning.
> >>>>>>>
> >>>>>>> It seems more likely that future
> >>>>>>> TUNSETSTEERINGEBPF programs would leverage a
> >>>>>>> negative return and potentially be loaded into
> >>>>>>> a kernel with the old behavior.
> >>>>>> OK if we are returning a special
> >>>>>> value, shouldn't we limit it? How about a special
> >>>>>> value with this meaning?
> >>>>>> If we are changing an ABI let's at least make it
> >>>>>> extensible.
> >>>>>>
> >>>>> A special value with this meaning sounds
> >>>>> good to me. I'll plan on adding a define
> >>>>> set to -1 to cause the fallback to automq.
> >>>> Can it really return -1?
> >>>>
> >>>> I see:
> >>>>
> >>>> static inline u32 bpf_prog_run_clear_cb(const struct bpf_prog *prog,
> >>>> struct sk_buff *skb)
> >>>> ...
> >>>>
> >>>>
> >>>>> The way I was initially viewing the old
> >>>>> behavior was that returning negative was
> >>>>> undefined; it happened to have the
> >>>>> outcomes I walked through, but not
> >>>>> necessarily by design.
> >>>> Having such fallback may bring extra troubles, it requires the eBPF
> >>>> program know the existence of the behavior which is not a part of kernel
> >>>> ABI actually. And then some eBPF program may start to rely on that which
> >>>> is pretty dangerous. Note, one important consideration is to have
> >>>> macvtap support where does not have any stuffs like automq.
> >>>>
> >>>> Thanks
> >>>>
> >>> How about we call this TUN_SSE_ABORT
> >>> instead of TUN_SSE_DO_AUTOMQ?
> >>>
> >>> TUN_SSE_ABORT could be documented as
> >>> falling back to the default queue
> >>> selection method in either space
> >>> (presumably macvtap has some queue
> >>> selection method when there is no prog).
> >>
> >> This looks like a more complex API, we don't want userspace to differ
> >> macvtap from tap too much.
> >>
> >> Thanks
> >>
> > This is barely more complex and provides
> > similar to what is done in many places.
> > For xdp, an XDP_PASS enacts what the
> > kernel would do if there was no bpf prog.
> > For tc cls in da mode, TC_ACT_OK enacts
> > what the kernel would do if there was
> > no bpf prog. For xt_bpf, false enacts
> > what the kernel would do if there was
> > no bpf prog (as long as negation
> > isn't in play in the rule, I believe).
>
>
> I think this is simply because you can't implement e.g
> XDP_PASS/TC_ACT_OK through eBPF itself which is not the case of steering
> prog here.
>
>
> >
> > I know that this is somewhat of an
> > oversimplification and that each of
> > these also means something else in
> > the respective hookpoint, but I standby
> > seeing value in this change.
> >
> > macvtap must have some default (i.e the
> > action which it takes when no prog is
> > loaded), even if that is just use queue
> > 0. We can provide the same TUN_SSE_ABORT
> > in userspace which does the same thing;
> > enacts the default when returned. Any
> > differences left between tap and macvtap
> > would be in what the default is, not in
> > these changes. And that difference already
> > exists today.
>
>
> I think it's better to safe to just drop the packet instead of trying to
> workaround it.
>
This patch aside, dropping the packet here
seems like the wrong choice. Loading a
prog at this hookpoint "configures"
steering. The action of configuring
steering should not result in dropped
packets.
Suboptimal delivery is generally preferable
to no delivery. Leaving the behavior as-is
(i.e. relying on netdev_cap_txqueue()) or
making any return which doesn't fit in a
u16 simply use queue 0 would be highly
preferable to dropping the packet.
> Thanks
>
>
> >
> >>>>> In order to keep the new behavior
> >>>>> extensible, how should we state that a
> >>>>> negative return other than -1 is
> >>>>> undefined and therefore subject to
> >>>>> change. Is something like this
> >>>>> sufficient?
> >>>>>
> >>>>> Documentation/networking/tc-actions-env-rules.txt
> >>>>>
> >>>>> Additionally, what should the new
> >>>>> behavior implement when a negative other
> >>>>> than -1 is returned? I would like to have
> >>>>> it do the same thing as -1 for now, but
> >>>>> with the understanding that this behavior
> >>>>> is undefined. Does this sound reasonable?
> >>>>>
> >>>>>>>> 3. why doesn't userspace need a way to figure out whether it runs on a kernel with and
> >>>>>>>> without this patch
> >>>>>>> There may be some value in exposing this fact
> >>>>>>> to the ebpf prog loader. What is the standard
> >>>>>>> practice here, a define?
> >>>>>> We'll need something at runtime - people move binaries between kernels
> >>>>>> without rebuilding then. An ioctl is one option.
> >>>>>> A sysfs attribute is another, an ethtool flag yet another.
> >>>>>> A combination of these is possible.
> >>>>>>
> >>>>>> And if we are doing this anyway, maybe let userspace select
> >>>>>> the new behaviour? This way we can stay compatible with old
> >>>>>> userspace...
> >>>>>>
> >>>>> Understood. I'll look into adding an
> >>>>> ioctl to activate the new behavior. And
> >>>>> perhaps a method of checking which is
> >>>>> behavior is currently active (in case we
> >>>>> ever want to change the default, say
> >>>>> after some suitably long transition
> >>>>> period).
> >>>>>
> >>>>>>>> thanks,
> >>>>>>>> MST
> >>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>> drivers/net/tun.c | 20 +++++++++++---------
> >>>>>>>>> 1 file changed, 11 insertions(+), 9 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >>>>>>>>> index aab0be4..173d159 100644
> >>>>>>>>> --- a/drivers/net/tun.c
> >>>>>>>>> +++ b/drivers/net/tun.c
> >>>>>>>>> @@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> >>>>>>>>> return txq;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> -static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> >>>>>>>>> +static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> >>>>>>>>> {
> >>>>>>>>> struct tun_prog *prog;
> >>>>>>>>> u32 numqueues;
> >>>>>>>>> - u16 ret = 0;
> >>>>>>>>> + int ret = -1;
> >>>>>>>>>
> >>>>>>>>> numqueues = READ_ONCE(tun->numqueues);
> >>>>>>>>> if (!numqueues)
> >>>>>>>>> return 0;
> >>>>>>>>>
> >>>>>>>>> + rcu_read_lock();
> >>>>>>>>> prog = rcu_dereference(tun->steering_prog);
> >>>>>>>>> if (prog)
> >>>>>>>>> ret = bpf_prog_run_clear_cb(prog->prog, skb);
> >>>>>>>>> + rcu_read_unlock();
> >>>>>>>>>
> >>>>>>>>> - return ret % numqueues;
> >>>>>>>>> + if (ret >= 0)
> >>>>>>>>> + ret %= numqueues;
> >>>>>>>>> +
> >>>>>>>>> + return ret;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
> >>>>>>>>> struct net_device *sb_dev)
> >>>>>>>>> {
> >>>>>>>>> struct tun_struct *tun = netdev_priv(dev);
> >>>>>>>>> - u16 ret;
> >>>>>>>>> + int ret;
> >>>>>>>>>
> >>>>>>>>> - rcu_read_lock();
> >>>>>>>>> - if (rcu_dereference(tun->steering_prog))
> >>>>>>>>> - ret = tun_ebpf_select_queue(tun, skb);
> >>>>>>>>> - else
> >>>>>>>>> + ret = tun_ebpf_select_queue(tun, skb);
> >>>>>>>>> + if (ret < 0)
> >>>>>>>>> ret = tun_automq_select_queue(tun, skb);
> >>>>>>>>> - rcu_read_unlock();
> >>>>>>>>>
> >>>>>>>>> return ret;
> >>>>>>>>> }
> >>>>>>>>> --
> >>>>>>>>> 1.8.3.1
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: test_progs: fix client/server race in tcp_rtt
From: Andrii Nakryiko @ 2019-09-23 16:41 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Stanislav Fomichev, Networking, bpf, David S. Miller,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190923153819.GA21441@mini-arch>
On Mon, Sep 23, 2019 at 8:38 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
>
> On 09/22, Andrii Nakryiko wrote:
> > On Sun, Sep 22, 2019 at 12:10 PM Stanislav Fomichev <sdf@google.com> wrote:
> > >
> > > This is the same problem I found earlier in test_sockopt_inherit:
> > > there is a race between server thread doing accept() and client
> > > thread doing connect(). Let's explicitly synchronize them via
> > > pthread conditional variable.
> > >
> > > Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > ---
> > > tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 16 +++++++++++++++-
> > > 1 file changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > > index fdc0b3614a9e..e64058906bcd 100644
> > > --- a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > > +++ b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> > > @@ -203,6 +203,9 @@ static int start_server(void)
> > > return fd;
> > > }
> > >
> > > +static pthread_mutex_t server_started_mtx = PTHREAD_MUTEX_INITIALIZER;
> > > +static pthread_cond_t server_started = PTHREAD_COND_INITIALIZER;
> > > +
> > > static void *server_thread(void *arg)
> > > {
> > > struct sockaddr_storage addr;
> > > @@ -215,6 +218,10 @@ static void *server_thread(void *arg)
> > > return NULL;
> > > }
> > >
> > > + pthread_mutex_lock(&server_started_mtx);
> > > + pthread_cond_signal(&server_started);
> > > + pthread_mutex_unlock(&server_started_mtx);
> > > +
> > > client_fd = accept(fd, (struct sockaddr *)&addr, &len);
> > > if (CHECK_FAIL(client_fd < 0)) {
> > > perror("Failed to accept client");
> > > @@ -248,7 +255,14 @@ void test_tcp_rtt(void)
> > > if (CHECK_FAIL(server_fd < 0))
> > > goto close_cgroup_fd;
> > >
> > > - pthread_create(&tid, NULL, server_thread, (void *)&server_fd);
> > > + if (CHECK_FAIL(pthread_create(&tid, NULL, server_thread,
> > > + (void *)&server_fd)))
> > > + goto close_cgroup_fd;
> > > +
> > > + pthread_mutex_lock(&server_started_mtx);
> > > + pthread_cond_wait(&server_started, &server_started_mtx);
> > > + pthread_mutex_unlock(&server_started_mtx);
> >
> >
> > If the server fails to listen, then we'll never get a signal, right?
> > Let's use timedwait instead to avoid test getting stuck forever in
> > such cases?
> Good point. How about I do the same thing I do in sockopt_inherit tests:
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c#n73
>
> err = listen()
> pthread_cond_signal()
> if (CHECK_FAIL(err)) {
> return;
> }
>
> Should fix the problem of getting stuck forever without any timeouts.
> I'll send a v2 later today.
Sounds good.
>
> > > +
> > > CHECK_FAIL(run_test(cgroup_fd, server_fd));
> > > close(server_fd);
> > > close_cgroup_fd:
> > > --
> > > 2.23.0.351.gc4317032e6-goog
> > >
^ permalink raw reply
* Re: CONFIG_NET_TC_SKB_EXT
From: Paul Blakey @ 2019-09-23 16:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Pravin Shelar, Daniel Borkmann, Vlad Buslov, David Miller,
netdev@vger.kernel.org, Jiri Pirko, Cong Wang, Jamal Hadi Salim,
Simon Horman, Or Gerlitz
In-Reply-To: <20190922144715.37f71fbf@cakuba.netronome.com>
On 9/23/2019 12:47 AM, Jakub Kicinski wrote:
> On Sun, 22 Sep 2019 14:51:44 +0300, Paul Blakey wrote:
>> The skb extension is currently used for miss path of software offloading OvS rules with recirculation to tc.
>> However, we are also preparing patches to support the hardware side of things.
>>
>> After the userspace OvS patches to support connection tracking, we'll have two users for
>> tc multi chain rules, one from those actually using tc and those translated from OvS rules.
>>
>> With both of these use cases, there is similar issue of 'miss', from hardware to tc and tc to OvS and the skb
>> extension will serve to recover from both.
>>
>> Consider, for example, the following multi chain tc rules:
>>
>> tc filter add dev1 ... chain 0 flower dst_mac aa:bb:cc:dd:ee:ff action pedit munge ex set mac dst 02:a0:98:4e:8f:d1 pipe action goto chain 1
>> tc filter add dev1 ... chain 1 flower ip_dst 1.1.1.1 action mirred egress redirect dev2
>> tc filter add dev1 ... chain 1 flower ip_dst 2.2.2.2 action mirred egress redirect dev2
>>
>> It's possible we offload the first two rules, but fail to offload the third rule, because of some hardware failure (e.g unsupported match or action).
>> If a packet with (dst_mac=aa:bb:cc:dd:ee:ff) and (dst ip=2.2.2.2) arrives,
>> we execute the goto chain 1 in hardware (and the pedit), and continue in chain 1, where we miss.
>>
>> Currently we re-start the processing in tc from chain 0, even though we already did part of the processing in hardware.
>> The match on the dst_mac will fail as we already modified it, and we won't execute the third rule action.
>> In addition, if we did manage to execute any software tc rules, the packet will be counted twice.
>>
>> We'll re-use this extension to solve this issue that currently exists by letting drivers tell tc on which chain to start the classification.
>>
>> Regarding the config, we suggest changing the default to N and letting users decide to enable it, see attached patch.
> Partial offloads are very hard. Could we possibly take a page out of
> routing offload's book and do a all or nothing offload in presence of
> multiple chains?
Hi,
Routing is a narrow scenario which this approach might work, but the
other way of offloading everything or nothing has it's disadvantages too.
Even following this approach in tc only is challenging for some
scenarios, consider the following tc rules:
tc filter add dev1 ... chain 0 flower <match1> action goto chain 1
tc filter add dev1 ... chain 0 flower <match2> action goto chain 1
tc filter add dev1 ... chain 0 flower <match3> action goto chain 1
..
..
tc filter add dev1 ... chain 0 flower ip_dst <match1000> action goto chain 1
tc filter add dev1 ... chain 1 flower ip_proto tcp action tunnel_key set dst_ip 8.8.8.8 action mirred egress redirect dev2
Now, you could offload 1000 'merged' rules that do the equivalent of:
tc filter add dev1 ... chain 0 flower <match1> ip_proto tcp action tunnel_key set dst_ip 8.8.8.8 action mirred egress redirect dev2
tc filter add dev1 ... chain 0 flower <match2> ip_proto tcp action tunnel_key set dst_ip 8.8.8.8 action mirred egress redirect dev2
...
tc filter add dev1 ... chain 0 flower <match1000> ip_proto tcp action tunnel_key set dst_ip 8.8.8.8 action mirred egress redirect dev2
And each of this hardware rule will update the correct software action counter, so the first hardware rule updates both the chain 1 rule counter and
chain 0 match1 rule counter.
This will work, but now you take dependencies on each of the children rules, so if you delete the chain 1 rule, you need
to invalidate all the 1000 hardware rules. And what about route updates or neigh updates for the encap header dst_ip 8.8.8.8?
Any change to that, and you update all the 1000 rules with the new mac address (hardware encapsulation needs to set outer mac address not supplied but tunnel key).
What if we had a depth of 10 chains?
You'd also have to keep track of what fields were originally on the packet, and not a match resulting from a modifications,
See the following set of rules:
tc filter add dev1 ... chain 0 prio 1 flower src_mac <mac1> action pedit munge ex set dst mac <mac2> pipe action goto chain 1
tc filter add dev1 ... chain 0 prio 2 flower dst_mac <mac2> action goto chain 1
tc filter add dev1 ... chain 1 prio 1 flower dst_mac <mac3> action <action3>
tc filter add dev1 ... chain 1 prio 2 flower src_mac <mac1> action <action4>
How would you offload that at the time of adding this rules, and not tracing the actual packet route?
can you tell that the third rule won't be hit? Will you flatten all possible routes and offload that?
Now take what other datapath (ovs, bridges, netfilter) blocks besides tc can do, or actions like ct that need software backing (unless you merge the ct table) and add them to the mix.
A single point of unsupported match/action between those, and we won't be able to offload the entire path, we might
even spend a lot of resources (trying to merge) before we even know it can't be offloaded, instead of doing what we can support.
>> ------------------------------------------------------------
>>
>> Subject: [PATCH net-next] net/sched: Set default of CONFIG_NET_TC_SKB_EXT to N
>>
>> This a new feature, it is prefered that it defaults to N.
>>
>> Fixes: 95a7233c452a ('net: openvswitch: Set OvS recirc_id from tc chain index')
>> Signed-off-by: Paul Blakey<paulb@mellanox.com>
>> ---
>> net/sched/Kconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
>> index b3faafe..4bb10b7 100644
>> --- a/net/sched/Kconfig
>> +++ b/net/sched/Kconfig
>> @@ -966,7 +966,6 @@ config NET_IFE_SKBTCINDEX
>> config NET_TC_SKB_EXT
>> bool "TC recirculation support"
>> depends on NET_CLS_ACT
>> - default y if NET_CLS_ACT
>> select SKB_EXTENSIONS
>>
>> help
> - Linus suggested we hide this option from user and autoselect if
> possible.
> - As Daniel said all distros will enable this.
> - If correctness is really our concern, giving users an option to
> select whether they want something to behave correctly seems like
> a hack of lowest kind. Perhaps it's time to add a CONFIG for TC
> offload in general? That's a meaningful set of functionality.
As I understand, Linus prefers this new feature to be default N and
that's the what the attached patch.
The changes to the OVS datapath (static key and DP_SET command) with the
userspace probe will ensure the correctness when the extension is disabled,
patch that I've yet to send is here:
https://www.spinics.net/lists/netdev/msg594175.html
This was going to be a part OvS userspace connection tracking offload
patches to OvS userspace.
Paul.
^ permalink raw reply
* Re: CONFIG_NET_TC_SKB_EXT
From: Edward Cree @ 2019-09-23 17:17 UTC (permalink / raw)
To: Paul Blakey, Jakub Kicinski
Cc: Pravin Shelar, Daniel Borkmann, Vlad Buslov, David Miller,
netdev@vger.kernel.org, Jiri Pirko, Cong Wang, Jamal Hadi Salim,
Simon Horman, Or Gerlitz
In-Reply-To: <68c6668c-f316-2ceb-31b0-8197d22990ae@mellanox.com>
On 23/09/2019 17:56, Paul Blakey wrote:
> Even following this approach in tc only is challenging for some
> scenarios, consider the following tc rules:
>
> tc filter add dev1 ... chain 0 flower <match1> action goto chain 1
> tc filter add dev1 ... chain 0 flower <match2> action goto chain 1
> tc filter add dev1 ... chain 0 flower <match3> action goto chain 1
> ..
> ..
> tc filter add dev1 ... chain 0 flower ip_dst <match1000> action goto chain 1
>
> tc filter add dev1 ... chain 1 flower ip_proto tcp action tunnel_key set dst_ip 8.8.8.8 action mirred egress redirect dev2
This one is easy, if a packet gets to the end of a chain without matching any rules then it just gets delivered to the uplink (PF), and software TC starts over from the beginning of chain 0. AFAICT this is the natural hardware behaviour for any design of offload, and it's inherently all-or-nothing.
> You'd also have to keep track of what fields were originally on the packet, and not a match resulting from a modifications,
> See the following set of rules:
> tc filter add dev1 ... chain 0 prio 1 flower src_mac <mac1> action pedit munge ex set dst mac <mac2> pipe action goto chain 1
> tc filter add dev1 ... chain 0 prio 2 flower dst_mac <mac2> action goto chain 1
> tc filter add dev1 ... chain 1 prio 1 flower dst_mac <mac3> action <action3>
> tc filter add dev1 ... chain 1 prio 2 flower src_mac <mac1> action <action4>
This one is slightly harder in that you have to either essentially 'gather up' actions as you go and only 'commit' them at the end of your processing pipeline (in which case you have to deal with the data hazard you cleverly included in your example), or keep a copy of the original packet around. But I don't see the data-hazard case as having any realistic use-cases (does anyone actually put actions other than ct before a goto chain?) and it's easy enough to detect it in SW at rule-insertion time.
FWIW I think the only way this infra will ever be used is: chain 0 rules match <blah> action ct zone <n> goto chain <m>; chain <m> rules match ct_state +xyz <blah> action <actually do stuff to packet>. This can be supported with a hardware pipeline with three tables in series in a fairly natural way — and since all the actions that modify the packet (rather than just directing subsequent matching) are at the end, the natural miss behaviour is deliver-unmodified.
I tried to explain this back on your [v3] net: openvswitch: Set OvS recirc_id from tc chain index, but you seemed set on your approach so I didn't persist. Now it looks like maybe I should have...
^ permalink raw reply
* Re: [PATCH trivial 1/2] net: Fix Kconfig indentation
From: Sven Eckelmann @ 2019-09-23 17:56 UTC (permalink / raw)
To: b.a.t.m.a.n
Cc: Krzysztof Kozlowski, David S. Miller, Michael Grzeschik,
Wolfgang Grandegger, Marc Kleine-Budde, Andrew Lunn,
Florian Fainelli, Heiner Kallweit, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, Jiri Kosina, netdev, linux-kernel, linux-can,
linux-rdma, linux-wireless, netfilter-devel, coreteam, lvs-devel,
rds-devel
In-Reply-To: <20190923155243.6997-1-krzk@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Monday, 23 September 2019 17:52:42 CEST Krzysztof Kozlowski wrote:
> --- a/net/batman-adv/Kconfig
> +++ b/net/batman-adv/Kconfig
> @@ -12,11 +12,11 @@ config BATMAN_ADV
> depends on NET
> select LIBCRC32C
> help
> - B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
> - a routing protocol for multi-hop ad-hoc mesh networks. The
> - networks may be wired or wireless. See
> - https://www.open-mesh.org/ for more information and user space
> - tools.
> + B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
> + a routing protocol for multi-hop ad-hoc mesh networks. The
> + networks may be wired or wireless. See
> + https://www.open-mesh.org/ for more information and user space
> + tools.
>
> config BATMAN_ADV_BATMAN_V
> bool "B.A.T.M.A.N. V protocol"
Acked-by: Sven Eckelmann <sven@narfation.org>
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* general protection fault in finish_writeback_work
From: syzbot @ 2019-09-23 18:26 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel, netdev, syzkaller-bugs, viro
Hello,
syzbot found the following crash on:
HEAD commit: 24ccb0ab qede: qede_fp: simplify a bit 'qede_rx_build_skb()'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=11a5b229600000
kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132
dashboard link: https://syzkaller.appspot.com/bug?extid=828abc56e48ada4b0195
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+828abc56e48ada4b0195@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8777 Comm: kworker/u4:5 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: writeback wb_workfn (flush-8:0)
RIP: 0010:__lock_acquire+0x1265/0x4e70 kernel/locking/lockdep.c:3828
Code: 00 0f 85 0e 26 00 00 48 81 c4 e8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f
85 dd 2a 00 00 49 81 3e a0 25 06 8a 0f 84 4e ee ff
RSP: 0018:ffff88806930f938 EFLAGS: 00010007
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 03fffe22022b47e2 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88806930fa48 R08: 0000000000000001 R09: 0000000000000001
R10: fffffbfff138cf90 R11: ffff8880693002c0 R12: 1ffff110115a3f15
R13: 0000000000000000 R14: 1ffff110115a3f15 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2136820ea0 CR3: 000000008ab86000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
__wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122
__wake_up+0xe/0x10 kernel/sched/wait.c:142
finish_writeback_work.isra.0+0xf6/0x120 fs/fs-writeback.c:168
wb_do_writeback fs/fs-writeback.c:2030 [inline]
wb_workfn+0x34f/0x11e0 fs/fs-writeback.c:2070
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace b7a1091622454beb ]---
RIP: 0010:__lock_acquire+0x1265/0x4e70 kernel/locking/lockdep.c:3828
Code: 00 0f 85 0e 26 00 00 48 81 c4 e8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f
85 dd 2a 00 00 49 81 3e a0 25 06 8a 0f 84 4e ee ff
RSP: 0018:ffff88806930f938 EFLAGS: 00010007
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 03fffe22022b47e2 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88806930fa48 R08: 0000000000000001 R09: 0000000000000001
R10: fffffbfff138cf90 R11: ffff8880693002c0 R12: 1ffff110115a3f15
R13: 0000000000000000 R14: 1ffff110115a3f15 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2136820ea0 CR3: 000000008ab86000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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.
^ permalink raw reply
* DSA driver kernel extension for dsa mv88e6190 switch
From: Zoran Stojsavljevic @ 2019-09-23 18:38 UTC (permalink / raw)
To: netdev
Hello Community,
We have interesting problem to solve using our HW platform. And I hope
somebody has the similar example, and some patches, which need to be
applied to the kernel (directory .../drivers/net/dsa/) to make this
application to work.
We have the configuration problem with the Marvell 88E6190 switch.
What the our problem is... Is the switch is NOT configured with the
EEPROM (24C512), which does not exist on the board. It is put in
autoconfig by HW straps (NOCPU mode). Once the MDIO command, issued to
probe the switch and read the make of it, the switch jumps out of the
autoconfig mode. There are some commands issued from the DSA to
configure the switch (to apply to switch TXC and RXC RGMII delays -
RGMII-ID mode), but this is not enough to make it work properly.
Once the configuration is not properly applied (NOT configured via
EEPROM 24C512). We have problems when the Linux booting phase comes to
LIBPHY. Since switch should be transparent to the PHYs at that time,
but my best guess, it is not!
Once LIBPHY starts writing to the switch (since MDIO commands are not
reaching PHYs), switch blocks. Exists from auto config mode and
refuses to respond (my best guess). So no ping possible on the
MV88E61890 MACs and through after Linux boots.
If we physically cut the MDIO line and put the switch in autoconfig
mode, then switch stays in autoconfig mode (by HW straps), but then it
is impossible to do RGMII TxC and RxC clock skew, since i.MX6 has the
silicon bug which does NOT allow this skew to be applied to i.MX6 (1.5
ns skew MUST be applied to the both clocks). If this done from the
DSA, (having MDIO fully in effect), the switch goes out of autoconfig
and does not finish the proper config.
I have here three questions, I hope there are some educated suggestions?
[1] Does this, what I wrote here, sound resonable (Google has very
little on it)?
[2] Does this problem with MV88E6190 switch could be solved
introducing some MV88E6190 configuration via RGMII mode in U-Boot
(setting the switch in U-boot and letting kernel do what it does, at
the end everything works seamlessly)?
[3] Does anybody have pointer to some similar patches for the DSA
driver addendum (NO U-boot involved), how to properly deal with this
problem and fully configure the switch from Linux DSA driver (chip.c
as switch config, and port.c files)??
Any advice is appreciated!
Thank you in advance,
Zoran
_______
^ 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