* Re: [PATCH net-next v4 20/20] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-15 23:48 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <201809160701.EQDrNg4f%fengguang.wu@intel.com>
Hi Mr. Ro Bot,
Looks like this is related to stack frames with KASAN. I've fixed this for v5.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc
From: kbuild test robot @ 2018-09-15 23:39 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, linux-crypto, davem, gregkh,
Jason A. Donenfeld, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <20180914162240.7925-18-Jason@zx2c4.com>
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180916-043623
config: arm64-defconfig
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
GCC_VERSION=7.2.0 make.cross ARCH=arm64 defconfig
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> fs/sysfs/Kconfig:1:error: recursive dependency detected!
>> fs/sysfs/Kconfig:1: symbol SYSFS is selected by CONFIGFS_FS
>> fs/configfs/Kconfig:1: symbol CONFIGFS_FS is selected by ACPI_CONFIGFS
>> drivers/acpi/Kconfig:542: symbol ACPI_CONFIGFS depends on ACPI
drivers/acpi/Kconfig:9: symbol ACPI depends on ARCH_SUPPORTS_ACPI
drivers/acpi/Kconfig:6: symbol ARCH_SUPPORTS_ACPI is selected by EFI
arch/arm64/Kconfig:1253: symbol EFI depends on KERNEL_MODE_NEON
arch/arm64/Kconfig:262: symbol KERNEL_MODE_NEON is implied by ZINC_ARCH_ARM
lib/zinc/Kconfig:42: symbol ZINC_ARCH_ARM depends on ZINC
>> lib/zinc/Kconfig:1: symbol ZINC is selected by ZINC_POLY1305
>> lib/zinc/Kconfig:9: symbol ZINC_POLY1305 is selected by CRYPTO_POLY1305
>> crypto/Kconfig:656: symbol CRYPTO_POLY1305 depends on CRYPTO
>> crypto/Kconfig:16: symbol CRYPTO is selected by IP_SCTP
>> net/sctp/Kconfig:5: symbol IP_SCTP is selected by DLM
>> fs/dlm/Kconfig:1: symbol DLM depends on SYSFS
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
vim +1 lib/zinc/Kconfig
32bbe22e Jason A. Donenfeld 2018-09-14 @1 config ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 2 tristate
32bbe22e Jason A. Donenfeld 2018-09-14 3
35f45248 Jason A. Donenfeld 2018-09-14 4 config ZINC_CHACHA20
35f45248 Jason A. Donenfeld 2018-09-14 5 bool
35f45248 Jason A. Donenfeld 2018-09-14 6 select ZINC
35f45248 Jason A. Donenfeld 2018-09-14 7 select CRYPTO_ALGAPI
35f45248 Jason A. Donenfeld 2018-09-14 8
0a36c146 Jason A. Donenfeld 2018-09-14 @9 config ZINC_POLY1305
0a36c146 Jason A. Donenfeld 2018-09-14 10 bool
0a36c146 Jason A. Donenfeld 2018-09-14 11 select ZINC
0a36c146 Jason A. Donenfeld 2018-09-14 12
1b5dbb86 Jason A. Donenfeld 2018-09-14 13 config ZINC_CHACHA20POLY1305
1b5dbb86 Jason A. Donenfeld 2018-09-14 14 bool
1b5dbb86 Jason A. Donenfeld 2018-09-14 15 select ZINC
1b5dbb86 Jason A. Donenfeld 2018-09-14 16 select ZINC_CHACHA20
1b5dbb86 Jason A. Donenfeld 2018-09-14 17 select ZINC_POLY1305
1b5dbb86 Jason A. Donenfeld 2018-09-14 18 select CRYPTO_BLKCIPHER
1b5dbb86 Jason A. Donenfeld 2018-09-14 19
a740374c Jason A. Donenfeld 2018-09-14 20 config ZINC_BLAKE2S
a740374c Jason A. Donenfeld 2018-09-14 21 bool
a740374c Jason A. Donenfeld 2018-09-14 22 select ZINC
a740374c Jason A. Donenfeld 2018-09-14 23
cec5aa7c Jason A. Donenfeld 2018-09-14 24 config ZINC_CURVE25519
cec5aa7c Jason A. Donenfeld 2018-09-14 25 bool
cec5aa7c Jason A. Donenfeld 2018-09-14 26 select ZINC
cec5aa7c Jason A. Donenfeld 2018-09-14 27 select CONFIG_CRYPTO
cec5aa7c Jason A. Donenfeld 2018-09-14 28
32bbe22e Jason A. Donenfeld 2018-09-14 29 config ZINC_DEBUG
32bbe22e Jason A. Donenfeld 2018-09-14 30 bool "Zinc cryptography library debugging and self-tests"
32bbe22e Jason A. Donenfeld 2018-09-14 31 depends on ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 32 help
32bbe22e Jason A. Donenfeld 2018-09-14 33 This builds a series of self-tests for the Zinc crypto library, which
32bbe22e Jason A. Donenfeld 2018-09-14 34 help diagnose any cryptographic algorithm implementation issues that
32bbe22e Jason A. Donenfeld 2018-09-14 35 might be at the root cause of potential bugs. It also adds various
32bbe22e Jason A. Donenfeld 2018-09-14 36 debugging traps.
32bbe22e Jason A. Donenfeld 2018-09-14 37
32bbe22e Jason A. Donenfeld 2018-09-14 38 Unless you're developing and testing cryptographic routines, or are
32bbe22e Jason A. Donenfeld 2018-09-14 39 especially paranoid about correctness on your hardware, you may say
32bbe22e Jason A. Donenfeld 2018-09-14 40 N here.
32bbe22e Jason A. Donenfeld 2018-09-14 41
32bbe22e Jason A. Donenfeld 2018-09-14 @42 config ZINC_ARCH_ARM
32bbe22e Jason A. Donenfeld 2018-09-14 43 def_bool y
32bbe22e Jason A. Donenfeld 2018-09-14 44 depends on ARM
32bbe22e Jason A. Donenfeld 2018-09-14 45 depends on ZINC
32bbe22e Jason A. Donenfeld 2018-09-14 46 imply VFP
32bbe22e Jason A. Donenfeld 2018-09-14 47 imply VFPv3 if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 48 imply NEON if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if CPU_V7
32bbe22e Jason A. Donenfeld 2018-09-14 50
:::::: The code at line 1 was first introduced by commit
:::::: 32bbe22ec6fddc21b70274aab7d2830d69d51578 zinc: introduce minimal cryptography library
:::::: TO: Jason A. Donenfeld <Jason@zx2c4.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* внимания
From: администратор @ 2018-09-15 11:35 UTC (permalink / raw)
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже:
имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:
Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен!
Приносим извинения за неудобства.
Проверочный код: EN: 87431`09875
Почты технической поддержки © 2018
спасибо
системы администратор
^ permalink raw reply
* Re: [PATCH net-next v4 20/20] net: WireGuard secure network tunnel
From: Jason A. Donenfeld @ 2018-09-15 23:14 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <201809160630.4PzV0pYM%fengguang.wu@intel.com>
Hi Mr. Ro Bot,
On Sun, Sep 16, 2018 at 12:19 AM kbuild test robot <lkp@intel.com> wrote:
> drivers/net/wireguard/send.c: In function 'packet_encrypt_worker':
> >> drivers/net/wireguard/send.c:320:1: warning: the frame size of 1136 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> }
Thanks, fixed for v5.
Jason
^ permalink raw reply
* Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc
From: kbuild test robot @ 2018-09-15 23:02 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, linux-crypto, davem, gregkh,
Jason A. Donenfeld, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <20180914162240.7925-18-Jason@zx2c4.com>
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180916-043623
config: arm64-defconfig
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
GCC_VERSION=7.2.0 make.cross ARCH=arm64 defconfig
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
fs/sysfs/Kconfig:1:error: recursive dependency detected!
fs/sysfs/Kconfig:1: symbol SYSFS is selected by CONFIGFS_FS
fs/configfs/Kconfig:1: symbol CONFIGFS_FS is selected by ACPI_CONFIGFS
drivers/acpi/Kconfig:542: symbol ACPI_CONFIGFS depends on ACPI
>> drivers/acpi/Kconfig:9: symbol ACPI depends on ARCH_SUPPORTS_ACPI
>> drivers/acpi/Kconfig:6: symbol ARCH_SUPPORTS_ACPI is selected by EFI
>> arch/arm64/Kconfig:1253: symbol EFI depends on KERNEL_MODE_NEON
>> arch/arm64/Kconfig:262: symbol KERNEL_MODE_NEON is implied by ZINC_ARCH_ARM
>> lib/zinc/Kconfig:42: symbol ZINC_ARCH_ARM depends on ZINC
lib/zinc/Kconfig:1: symbol ZINC is selected by ZINC_POLY1305
lib/zinc/Kconfig:9: symbol ZINC_POLY1305 is selected by CRYPTO_POLY1305
crypto/Kconfig:656: symbol CRYPTO_POLY1305 depends on CRYPTO
crypto/Kconfig:16: symbol CRYPTO is selected by IP_SCTP
net/sctp/Kconfig:5: symbol IP_SCTP is selected by DLM
fs/dlm/Kconfig:1: symbol DLM depends on SYSFS
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
vim +9 drivers/acpi/Kconfig
^1da177e4 Linus Torvalds 2005-04-16 5
f5d707ede Arnd Bergmann 2018-08-21 @6 config ARCH_SUPPORTS_ACPI
f5d707ede Arnd Bergmann 2018-08-21 7 bool
f5d707ede Arnd Bergmann 2018-08-21 8
3f2c48c9b Jan Engelhardt 2007-07-03 @9 menuconfig ACPI
355ee5eb6 Frans Pop 2007-10-29 10 bool "ACPI (Advanced Configuration and Power Interface) Support"
2c870e611 Arnd Bergmann 2018-07-24 11 depends on ARCH_SUPPORTS_ACPI
1300124f6 Adrian Bunk 2006-03-28 12 depends on PCI
243b66e76 Len Brown 2007-02-15 13 select PNP
2c870e611 Arnd Bergmann 2018-07-24 14 default y if X86
1c48aa36e Bjorn Helgaas 2009-02-19 15 help
^1da177e4 Linus Torvalds 2005-04-16 16 Advanced Configuration and Power Interface (ACPI) support for
1c48aa36e Bjorn Helgaas 2009-02-19 17 Linux requires an ACPI-compliant platform (hardware/firmware),
^1da177e4 Linus Torvalds 2005-04-16 18 and assumes the presence of OS-directed configuration and power
^1da177e4 Linus Torvalds 2005-04-16 19 management (OSPM) software. This option will enlarge your
^1da177e4 Linus Torvalds 2005-04-16 20 kernel by about 70K.
^1da177e4 Linus Torvalds 2005-04-16 21
^1da177e4 Linus Torvalds 2005-04-16 22 Linux ACPI provides a robust functional replacement for several
^1da177e4 Linus Torvalds 2005-04-16 23 legacy configuration and power management interfaces, including
^1da177e4 Linus Torvalds 2005-04-16 24 the Plug-and-Play BIOS specification (PnP BIOS), the
^1da177e4 Linus Torvalds 2005-04-16 25 MultiProcessor Specification (MPS), and the Advanced Power
^1da177e4 Linus Torvalds 2005-04-16 26 Management (APM) specification. If both ACPI and APM support
1c48aa36e Bjorn Helgaas 2009-02-19 27 are configured, ACPI is used.
^1da177e4 Linus Torvalds 2005-04-16 28
1c48aa36e Bjorn Helgaas 2009-02-19 29 The project home page for the Linux ACPI subsystem is here:
aaf3d29fe Rafael J. Wysocki 2013-10-10 30 <https://01.org/linux-acpi>
^1da177e4 Linus Torvalds 2005-04-16 31
^1da177e4 Linus Torvalds 2005-04-16 32 Linux support for ACPI is based on Intel Corporation's ACPI
1c48aa36e Bjorn Helgaas 2009-02-19 33 Component Architecture (ACPI CA). For more information on the
1c48aa36e Bjorn Helgaas 2009-02-19 34 ACPI CA, see:
1c48aa36e Bjorn Helgaas 2009-02-19 35 <http://acpica.org/>
^1da177e4 Linus Torvalds 2005-04-16 36
c7f5220d0 Hanjun Guo 2014-04-08 37 ACPI is an open industry specification originally co-developed by
c7f5220d0 Hanjun Guo 2014-04-08 38 Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba. Currently,
c7f5220d0 Hanjun Guo 2014-04-08 39 it is developed by the ACPI Specification Working Group (ASWG) under
c7f5220d0 Hanjun Guo 2014-04-08 40 the UEFI Forum and any UEFI member can join the ASWG and contribute
c7f5220d0 Hanjun Guo 2014-04-08 41 to the ACPI specification.
1c48aa36e Bjorn Helgaas 2009-02-19 42 The specification is available at:
^1da177e4 Linus Torvalds 2005-04-16 43 <http://www.acpi.info>
c7f5220d0 Hanjun Guo 2014-04-08 44 <http://www.uefi.org/acpi/specs>
^1da177e4 Linus Torvalds 2005-04-16 45
:::::: The code at line 9 was first introduced by commit
:::::: 3f2c48c9b48423d1411695da066d525cca2a27db ACPI: Use menuconfig objects
:::::: TO: Jan Engelhardt <jengelh@linux01.gwdg.de>
:::::: CC: Len Brown <len.brown@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v4 20/20] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-09-15 23:01 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, linux-crypto, davem, gregkh,
Jason A. Donenfeld
In-Reply-To: <20180914162240.7925-21-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180916-043623
config: x86_64-randconfig-b0-09160521 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from lib/zinc/curve25519/curve25519.c:45:0:
lib/zinc/curve25519/curve25519-hacl64.h: In function 'curve25519_generic':
>> lib/zinc/curve25519/curve25519-hacl64.h:785:1: warning: the frame size of 13216 bytes is larger than 8192 bytes [-Wframe-larger-than=]
}
^
vim +785 lib/zinc/curve25519/curve25519-hacl64.h
cec5aa7c Jason A. Donenfeld 2018-09-14 755
cec5aa7c Jason A. Donenfeld 2018-09-14 756 static void curve25519_generic(u8 mypublic[CURVE25519_POINT_SIZE],
cec5aa7c Jason A. Donenfeld 2018-09-14 757 const u8 secret[CURVE25519_POINT_SIZE],
cec5aa7c Jason A. Donenfeld 2018-09-14 758 const u8 basepoint[CURVE25519_POINT_SIZE])
cec5aa7c Jason A. Donenfeld 2018-09-14 759 {
cec5aa7c Jason A. Donenfeld 2018-09-14 760 u64 buf0[10] __aligned(32) = { 0 };
cec5aa7c Jason A. Donenfeld 2018-09-14 761 u64 *x0 = buf0;
cec5aa7c Jason A. Donenfeld 2018-09-14 762 u64 *z = buf0 + 5;
cec5aa7c Jason A. Donenfeld 2018-09-14 763 u64 *q;
cec5aa7c Jason A. Donenfeld 2018-09-14 764 format_fexpand(x0, basepoint);
cec5aa7c Jason A. Donenfeld 2018-09-14 765 z[0] = 1;
cec5aa7c Jason A. Donenfeld 2018-09-14 766 q = buf0;
cec5aa7c Jason A. Donenfeld 2018-09-14 767 {
cec5aa7c Jason A. Donenfeld 2018-09-14 768 u8 e[32] __aligned(32) = { 0 };
cec5aa7c Jason A. Donenfeld 2018-09-14 769 u8 *scalar;
cec5aa7c Jason A. Donenfeld 2018-09-14 770 memcpy(e, secret, 32);
cec5aa7c Jason A. Donenfeld 2018-09-14 771 normalize_secret(e);
cec5aa7c Jason A. Donenfeld 2018-09-14 772 scalar = e;
cec5aa7c Jason A. Donenfeld 2018-09-14 773 {
cec5aa7c Jason A. Donenfeld 2018-09-14 774 u64 buf[15] = { 0 };
cec5aa7c Jason A. Donenfeld 2018-09-14 775 u64 *nq = buf;
cec5aa7c Jason A. Donenfeld 2018-09-14 776 u64 *x = nq;
cec5aa7c Jason A. Donenfeld 2018-09-14 777 x[0] = 1;
cec5aa7c Jason A. Donenfeld 2018-09-14 778 ladder_cmult(nq, scalar, q);
cec5aa7c Jason A. Donenfeld 2018-09-14 779 format_scalar_of_point(mypublic, nq);
cec5aa7c Jason A. Donenfeld 2018-09-14 780 memzero_explicit(buf, sizeof(buf));
cec5aa7c Jason A. Donenfeld 2018-09-14 781 }
cec5aa7c Jason A. Donenfeld 2018-09-14 782 memzero_explicit(e, sizeof(e));
cec5aa7c Jason A. Donenfeld 2018-09-14 783 }
cec5aa7c Jason A. Donenfeld 2018-09-14 784 memzero_explicit(buf0, sizeof(buf0));
cec5aa7c Jason A. Donenfeld 2018-09-14 @785 }
:::::: The code at line 785 was first introduced by commit
:::::: cec5aa7cd396d909f8555d2df80d3e1a0f94688b zinc: Curve25519 generic C implementations and selftest
:::::: TO: Jason A. Donenfeld <Jason@zx2c4.com>
:::::: CC: 0day robot <lkp@intel.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: 30997 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 20/20] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-09-15 22:17 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, linux-crypto, davem, gregkh,
Jason A. Donenfeld
In-Reply-To: <20180914162240.7925-21-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180916-043623
config: powerpc-canyonlands_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.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.2.0 make.cross ARCH=powerpc
All warnings (new ones prefixed by >>):
drivers/net/wireguard/send.c: In function 'packet_encrypt_worker':
>> drivers/net/wireguard/send.c:320:1: warning: the frame size of 1136 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
--
drivers/net/wireguard/receive.c: In function 'packet_decrypt_worker':
>> drivers/net/wireguard/receive.c:520:1: warning: the frame size of 1136 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
vim +320 drivers/net/wireguard/send.c
294
295 void packet_encrypt_worker(struct work_struct *work)
296 {
297 struct crypt_queue *queue =
298 container_of(work, struct multicore_worker, work)->ptr;
299 struct sk_buff *first, *skb, *next;
300 simd_context_t simd_context = simd_get();
301
302 while ((first = ptr_ring_consume_bh(&queue->ring)) != NULL) {
303 enum packet_state state = PACKET_STATE_CRYPTED;
304
305 skb_walk_null_queue_safe (first, skb, next) {
306 if (likely(skb_encrypt(skb, PACKET_CB(first)->keypair,
307 simd_context)))
308 skb_reset(skb);
309 else {
310 state = PACKET_STATE_DEAD;
311 break;
312 }
313 }
314 queue_enqueue_per_peer(&PACKET_PEER(first)->tx_queue, first,
315 state);
316
317 simd_context = simd_relax(simd_context);
318 }
319 simd_put(simd_context);
> 320 }
321
---
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: 14899 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/7] dt-bindings: net: vsc8531: add two additional LED modes for VSC8584
From: Florian Fainelli @ 2018-09-15 21:34 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem, andrew
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni, antoine.tenart
In-Reply-To: <f54f6cda7f505d99531e33626f8d4e6f1dc084ec.1536916714.git-series.quentin.schulz@bootlin.com>
On 09/14/18 02:44, Quentin Schulz wrote:
> The VSC8584 (and most likely other PHYs in the same generation) has two
> additional LED modes that can be picked, so let's add them.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: phy: mscc: shorten `x != 0` condition to `x`
From: Florian Fainelli @ 2018-09-15 20:53 UTC (permalink / raw)
To: Quentin Schulz, davem, andrew
Cc: allan.nielsen, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <2efac3971c41837fec6001018c1275d81286512a.1536913944.git-series.quentin.schulz@bootlin.com>
On 9/14/2018 1:33 AM, Quentin Schulz wrote:
> `if (x != 0)` is basically a more verbose version of `if (x)` so let's
> use the latter so it's consistent throughout the whole driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: phy: mscc: remove unneeded parenthesis
From: Florian Fainelli @ 2018-09-15 20:52 UTC (permalink / raw)
To: Quentin Schulz, davem, andrew
Cc: allan.nielsen, linux-kernel, netdev, thomas.petazzoni
In-Reply-To: <e3a1a9940e18c69ecf9aaecc3e2d9bf2a180a939.1536913944.git-series.quentin.schulz@bootlin.com>
On 9/14/2018 1:33 AM, Quentin Schulz wrote:
> The == operator precedes the || operator, so we can remove the
> parenthesis around (a == b) || (c == d).
>
> The condition is rather explicit and short so removing the parenthesis
> definitely does not make it harder to read.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH v2 net] net: aquantia: memory corruption on jumbo frames
From: Igor Russkikh @ 2018-09-15 15:03 UTC (permalink / raw)
To: David S . Miller; +Cc: Nikita Danilov, netdev, Igor Russkikh, Friedemann Gerold
From: Friedemann Gerold <f.gerold@b-c-s.de>
This patch fixes skb_shared area, which will be corrupted
upon reception of 4K jumbo packets.
Originally build_skb usage purpose was to reuse page for skb to eliminate
needs of extra fragments. But that logic does not take into account that
skb_shared_info should be reserved at the end of skb data area.
In case packet data consumes all the page (4K), skb_shinfo location
overflows the page. As a consequence, __build_skb zeroed shinfo data above
the allocated page, corrupting next page.
The issue is rarely seen in real life because jumbo are normally larger
than 4K and that causes another code path to trigger.
But it 100% reproducible with simple scapy packet, like:
sendp(IP(dst="192.168.100.3") / TCP(dport=443) \
/ Raw(RandString(size=(4096-40))), iface="enp1s0")
Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
Reported-by: Friedemann Gerold <f.gerold@b-c-s.de>
Reported-by: Michael Rauch <michael@rauch.be>
Signed-off-by: Friedemann Gerold <f.gerold@b-c-s.de>
Tested-by: Nikita Danilov <nikita.danilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 +++++++++++++-----------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
index b5f1f62e8e25..d1e1a0ba8615 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
@@ -225,9 +225,10 @@ int aq_ring_rx_clean(struct aq_ring_s *self,
}
/* for single fragment packets use build_skb() */
- if (buff->is_eop) {
+ if (buff->is_eop &&
+ buff->len <= AQ_CFG_RX_FRAME_MAX - AQ_SKB_ALIGN) {
skb = build_skb(page_address(buff->page),
- buff->len + AQ_SKB_ALIGN);
+ AQ_CFG_RX_FRAME_MAX);
if (unlikely(!skb)) {
err = -ENOMEM;
goto err_exit;
@@ -247,18 +248,21 @@ int aq_ring_rx_clean(struct aq_ring_s *self,
buff->len - ETH_HLEN,
SKB_TRUESIZE(buff->len - ETH_HLEN));
- for (i = 1U, next_ = buff->next,
- buff_ = &self->buff_ring[next_]; true;
- next_ = buff_->next,
- buff_ = &self->buff_ring[next_], ++i) {
- skb_add_rx_frag(skb, i, buff_->page, 0,
- buff_->len,
- SKB_TRUESIZE(buff->len -
- ETH_HLEN));
- buff_->is_cleaned = 1;
-
- if (buff_->is_eop)
- break;
+ if (!buff->is_eop) {
+ for (i = 1U, next_ = buff->next,
+ buff_ = &self->buff_ring[next_];
+ true; next_ = buff_->next,
+ buff_ = &self->buff_ring[next_], ++i) {
+ skb_add_rx_frag(skb, i,
+ buff_->page, 0,
+ buff_->len,
+ SKB_TRUESIZE(buff->len -
+ ETH_HLEN));
+ buff_->is_cleaned = 1;
+
+ if (buff_->is_eop)
+ break;
+ }
}
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] net: aquantia: memory corruption on jumbo frames
From: Igor Russkikh @ 2018-09-15 14:26 UTC (permalink / raw)
To: netdev, David S . Miller
In-Reply-To: <1ca2f3ebdd82d78b7ccbd86acd7ce9245316b42a.1536994993.git.igor.russkikh@aquantia.com>
> This patch fixes skb_shared area, which will be corrupted
> upon reception of 4K jumbo packets.
>
Hi David, please discard this patch as it wrongly specifies the original issue reporter and patch author.
I'm fixing it now and will resend.
Sorry for this.
BR, Igor
^ permalink raw reply
* Re: [PATCH net-next v3 01/17] asm: simd context helper API
From: Jason A. Donenfeld @ 2018-09-15 20:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: kevin, Andrew Lutomirski, LKML, Netdev, David Miller,
Greg Kroah-Hartman, Thomas Gleixner, Samuel Neves, linux-arch
In-Reply-To: <61B4DFD6-9BB5-4B81-BD0E-ACF112EA8AF7@amacapital.net>
On Sat, Sep 15, 2018 at 9:58 PM Andy Lutomirski <luto@amacapital.net> wrote:
> I have no strong opinion, except that, if you paint the bikeshed “pass by value”, then simd_get and simd_relax should probably have warn_unused_result set.
Good idea.
^ permalink raw reply
* Re: [PATCH net-next v3 01/17] asm: simd context helper API
From: Andy Lutomirski @ 2018-09-15 19:58 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kevin, Andrew Lutomirski, LKML, Netdev, David Miller,
Greg Kroah-Hartman, Thomas Gleixner, Samuel Neves, linux-arch
In-Reply-To: <CAHmME9rMg_2eHBnfP6j9Y3O7-At90HF=ToTWeFL_Qc4nGURORg@mail.gmail.com>
> On Sep 13, 2018, at 6:52 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
>> On Thu, Sep 13, 2018 at 7:03 AM Kevin Easton <kevin@guarana.org> wrote:
>> Yes. It's also how most get/put APIs already work in the kernel, eg
>> kref_get/put (mostly because they tend to be 'getting/putting' an
>> already-initialized object, though).
>
> Right; in this case the object wouldn't be initialized yet, which
> might defeat the purpose, since one advantage of the & way you
> mentioned is _put modifies the context.
>
> Andy - any opinions on this? The tl;dr is:
>
> 1) what we have now:
>
> simd_context_t simd_context = simd_get();
> for (item in items) {
> do_something(item);
> simd_context = simd_relax(simd_context);
> }
> simd_put();
>
> 2) what kevin is proposing:
>
> simd_context_t simd_context;
>
> simd_get(&simd_context);
> for (item in items) {
> do_something(item);
> simd_relax(&simd_context);
> }
> simd_put(&simd_context);
>
> I can see pros and cons of each approach.
I have no strong opinion, except that, if you paint the bikeshed “pass by value”, then simd_get and simd_relax should probably have warn_unused_result set.
^ permalink raw reply
* [PATCH net] net: aquantia: memory corruption on jumbo frames
From: Igor Russkikh @ 2018-09-15 14:20 UTC (permalink / raw)
To: netdev; +Cc: Igor Russkikh, Michael Rauch
From: Michael Rauch <michael@rauch.be>
This patch fixes skb_shared area, which will be corrupted
upon reception of 4K jumbo packets.
Originally build_skb usage purpose was to reuse page for skb to eliminate
needs of extra fragments. But that logic does not take into account that
skb_shared_info should be reserved at the end of skb data area.
In case packet data consumes all the page (4K), skb_shinfo location
overflows the page. As a consequence, __build_skb zeroed shinfo data above
the allocated page, corrupting next page.
The issue is rarely seen in real life because jumbo are normally larger
than 4K and that causes another code path to trigger.
But it 100% reproducible with simple scapy packet, like:
sendp(IP(dst="192.168.100.3") / TCP(dport=443) \
/ Raw(RandString(size=(4096-40))), iface="enp1s0")
Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
Reported-by: Michael Rauch <michael@rauch.be>
Tested-by: Michael Rauch <michael@rauch.be>
Signed-off-by: Michael Rauch <michael@rauch.be>
Tested-by: Nikita Danilov <nikita.danilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 +++++++++++++-----------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
index b5f1f62e8e25..d1e1a0ba8615 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
@@ -225,9 +225,10 @@ int aq_ring_rx_clean(struct aq_ring_s *self,
}
/* for single fragment packets use build_skb() */
- if (buff->is_eop) {
+ if (buff->is_eop &&
+ buff->len <= AQ_CFG_RX_FRAME_MAX - AQ_SKB_ALIGN) {
skb = build_skb(page_address(buff->page),
- buff->len + AQ_SKB_ALIGN);
+ AQ_CFG_RX_FRAME_MAX);
if (unlikely(!skb)) {
err = -ENOMEM;
goto err_exit;
@@ -247,18 +248,21 @@ int aq_ring_rx_clean(struct aq_ring_s *self,
buff->len - ETH_HLEN,
SKB_TRUESIZE(buff->len - ETH_HLEN));
- for (i = 1U, next_ = buff->next,
- buff_ = &self->buff_ring[next_]; true;
- next_ = buff_->next,
- buff_ = &self->buff_ring[next_], ++i) {
- skb_add_rx_frag(skb, i, buff_->page, 0,
- buff_->len,
- SKB_TRUESIZE(buff->len -
- ETH_HLEN));
- buff_->is_cleaned = 1;
-
- if (buff_->is_eop)
- break;
+ if (!buff->is_eop) {
+ for (i = 1U, next_ = buff->next,
+ buff_ = &self->buff_ring[next_];
+ true; next_ = buff_->next,
+ buff_ = &self->buff_ring[next_], ++i) {
+ skb_add_rx_frag(skb, i,
+ buff_->page, 0,
+ buff_->len,
+ SKB_TRUESIZE(buff->len -
+ ETH_HLEN));
+ buff_->is_cleaned = 1;
+
+ if (buff_->is_eop)
+ break;
+ }
}
}
--
2.7.4
^ permalink raw reply related
* KMSAN: uninit-value in bond_start_xmit (2)
From: syzbot @ 2018-09-15 12:53 UTC (permalink / raw)
To: andy, davem, j.vosburgh, linux-kernel, netdev, syzkaller-bugs,
vfalico
Hello,
syzbot found the following crash on:
HEAD commit: 401f0ab26c43 kmsan: unpoison pages in do_read_cache_page()
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=17b808ae400000
kernel config: https://syzkaller.appspot.com/x/.config?x=6be230b6f0ad3490
dashboard link: https://syzkaller.appspot.com/bug?extid=e5be16aa39ad6e755391
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=124d16da400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=175f06be400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e5be16aa39ad6e755391@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in bond_xmit_roundrobin
drivers/net/bonding/bond_main.c:3858 [inline]
BUG: KMSAN: uninit-value in __bond_start_xmit
drivers/net/bonding/bond_main.c:4136 [inline]
BUG: KMSAN: uninit-value in bond_start_xmit+0x1ab8/0x2b90
drivers/net/bonding/bond_main.c:4170
CPU: 0 PID: 4319 Comm: syz-executor658 Not tainted 4.19.0-rc3+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x14b/0x190 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
bond_xmit_roundrobin drivers/net/bonding/bond_main.c:3858 [inline]
__bond_start_xmit drivers/net/bonding/bond_main.c:4136 [inline]
bond_start_xmit+0x1ab8/0x2b90 drivers/net/bonding/bond_main.c:4170
__netdev_start_xmit include/linux/netdevice.h:4287 [inline]
netdev_start_xmit include/linux/netdevice.h:4296 [inline]
xmit_one net/core/dev.c:3216 [inline]
dev_hard_start_xmit+0x5df/0xc20 net/core/dev.c:3232
__dev_queue_xmit+0x2f35/0x3ab0 net/core/dev.c:3802
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3835
packet_snd net/packet/af_packet.c:2925 [inline]
packet_sendmsg+0x80ff/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x4410f9
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 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffcc15c2468 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004410f9
RDX: 0000000000000000 RSI: 0000000020001940 RDI: 0000000000000004
RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
R10: 0000000000000100 R11: 0000000000000217 R12: 0000000000402060
R13: 00000000004020f0 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2718 [inline]
__kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
alloc_skb_with_frags+0x1d0/0xac0 net/core/skbuff.c:5276
sock_alloc_send_pskb+0xb47/0x1170 net/core/sock.c:2082
packet_alloc_skb net/packet/af_packet.c:2779 [inline]
packet_snd net/packet/af_packet.c:2870 [inline]
packet_sendmsg+0x6599/0x8c60 net/packet/af_packet.c:2950
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* RE: [net-next PATCH] tls: async support causes out-of-bounds access in crypto APIs
From: Vakul Garg @ 2018-09-15 12:13 UTC (permalink / raw)
To: John Fastabend, davejwatson@fb.com
Cc: doronrk@fb.com, netdev@vger.kernel.org,
alexei.starovoitov@gmail.com, daniel@iogearbox.net,
davem@davemloft.net
In-Reply-To: <20180914200146.6302.50472.stgit@john-Precision-Tower-5810>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of John Fastabend
> Sent: Saturday, September 15, 2018 1:32 AM
> To: Vakul Garg <vakul.garg@nxp.com>; davejwatson@fb.com
> Cc: doronrk@fb.com; netdev@vger.kernel.org;
> alexei.starovoitov@gmail.com; daniel@iogearbox.net;
> davem@davemloft.net
> Subject: [net-next PATCH] tls: async support causes out-of-bounds access in
> crypto APIs
>
> When async support was added it needed to access the sk from the async
> callback to report errors up the stack. The patch tried to use space after the
> aead request struct by directly setting the reqsize field in aead_request. This
> is an internal field that should not be used outside the crypto APIs. It is used
> by the crypto code to define extra space for private structures used in the
> crypto context. Users of the API then use crypto_aead_reqsize() and add the
> returned amount of bytes to the end of the request memory allocation
> before posting the request to encrypt/decrypt APIs.
>
> So this breaks (with general protection fault and KASAN error, if
> enabled) because the request sent to decrypt is shorter than required causing
> the crypto API out-of-bounds errors. Also it seems unlikely the sk is even valid
> by the time it gets to the callback because of memset in crypto layer.
>
> Anyways, fix this by holding the sk in the skb->sk field when the callback is set
> up and because the skb is already passed through to the callback handler via
> void* we can access it in the handler. Then in the handler we need to be
> careful to NULL the pointer again before kfree_skb. I added comments on
> both the setup (in tls_do_decryption) and when we clear it from the crypto
> callback handler tls_decrypt_done(). After this selftests pass again and fixes
> KASAN errors/warnings.
>
> Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls
> records")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> include/net/tls.h | 4 ----
> net/tls/tls_sw.c | 39 +++++++++++++++++++++++----------------
> 2 files changed, 23 insertions(+), 20 deletions(-)
>
> diff --git a/include/net/tls.h b/include/net/tls.h index cd0a65b..8630d28
> 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -128,10 +128,6 @@ struct tls_sw_context_rx {
> bool async_notify;
> };
>
> -struct decrypt_req_ctx {
> - struct sock *sk;
> -};
> -
> struct tls_record_info {
> struct list_head list;
> u32 end_seq;
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index be4f2e9..cef69b6 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -122,25 +122,32 @@ static int skb_nsg(struct sk_buff *skb, int offset,
> int len) static void tls_decrypt_done(struct crypto_async_request *req, int
> err) {
> struct aead_request *aead_req = (struct aead_request *)req;
> - struct decrypt_req_ctx *req_ctx =
> - (struct decrypt_req_ctx *)(aead_req + 1);
> -
> struct scatterlist *sgout = aead_req->dst;
> -
> - struct tls_context *tls_ctx = tls_get_ctx(req_ctx->sk);
> - struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
> - int pending = atomic_dec_return(&ctx->decrypt_pending);
> + struct tls_sw_context_rx *ctx;
> + struct tls_context *tls_ctx;
> struct scatterlist *sg;
> + struct sk_buff *skb;
> unsigned int pages;
> + int pending;
> +
> + skb = (struct sk_buff *)req->data;
> + tls_ctx = tls_get_ctx(skb->sk);
> + ctx = tls_sw_ctx_rx(tls_ctx);
> + pending = atomic_dec_return(&ctx->decrypt_pending);
>
> /* Propagate if there was an err */
> if (err) {
> ctx->async_wait.err = err;
> - tls_err_abort(req_ctx->sk, err);
> + tls_err_abort(skb->sk, err);
> }
>
> + /* After using skb->sk to propagate sk through crypto async callback
> + * we need to NULL it again.
> + */
> + skb->sk = NULL;
> +
> /* Release the skb, pages and memory allocated for crypto req */
> - kfree_skb(req->data);
> + kfree_skb(skb);
>
> /* Skip the first S/G entry as it points to AAD */
> for_each_sg(sg_next(sgout), sg, UINT_MAX, pages) { @@ -175,11
> +182,13 @@ static int tls_do_decryption(struct sock *sk,
> (u8 *)iv_recv);
>
> if (async) {
> - struct decrypt_req_ctx *req_ctx;
> -
> - req_ctx = (struct decrypt_req_ctx *)(aead_req + 1);
> - req_ctx->sk = sk;
> -
> + /* Using skb->sk to push sk through to crypto async callback
> + * handler. This allows propagating errors up to the socket
> + * if needed. It _must_ be cleared in the async handler
> + * before kfree_skb is called. We _know_ skb->sk is NULL
> + * because it is a clone from strparser.
> + */
> + skb->sk = sk;
> aead_request_set_callback(aead_req,
>
> CRYPTO_TFM_REQ_MAY_BACKLOG,
> tls_decrypt_done, skb);
> @@ -1455,8 +1464,6 @@ int tls_set_sw_offload(struct sock *sk, struct
> tls_context *ctx, int tx)
> goto free_aead;
>
> if (sw_ctx_rx) {
> - (*aead)->reqsize = sizeof(struct decrypt_req_ctx);
> -
> /* Set up strparser */
> memset(&cb, 0, sizeof(cb));
> cb.rcv_msg = tls_queue;
Reviewed-by: Vakul Garg <Vakul.garg@nxp.com>
^ permalink raw reply
* RE: [PATCH net-next v2] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-09-15 12:11 UTC (permalink / raw)
To: John Fastabend, netdev@vger.kernel.org
Cc: borisp@mellanox.com, aviadye@mellanox.com, davejwatson@fb.com,
davem@davemloft.net
In-Reply-To: <e36c42e9-17ed-6f9b-809a-5f1a0cb1d9de@gmail.com>
> -----Original Message-----
> From: John Fastabend <john.fastabend@gmail.com>
> Sent: Saturday, September 15, 2018 1:10 AM
> To: Vakul Garg <vakul.garg@nxp.com>; netdev@vger.kernel.org
> Cc: borisp@mellanox.com; aviadye@mellanox.com; davejwatson@fb.com;
> davem@davemloft.net
> Subject: Re: [PATCH net-next v2] net/tls: Add support for async decryption of
> tls records
>
> On 08/29/2018 02:56 AM, Vakul Garg wrote:
> > When tls records are decrypted using asynchronous acclerators such as
> > NXP CAAM engine, the crypto apis return -EINPROGRESS. Presently, on
> > getting -EINPROGRESS, the tls record processing stops till the time
> > the crypto accelerator finishes off and returns the result. This
> > incurs a context switch and is not an efficient way of accessing the
> > crypto accelerators. Crypto accelerators work efficient when they are
> > queued with multiple crypto jobs without having to wait for the
> > previous ones to complete.
> >
> > The patch submits multiple crypto requests without having to wait for
> > for previous ones to complete. This has been implemented for records
> > which are decrypted in zero-copy mode. At the end of recvmsg(), we
> > wait for all the asynchronous decryption requests to complete.
> >
> > The references to records which have been sent for async decryption
> > are dropped. For cases where record decryption is not possible in
> > zero-copy mode, asynchronous decryption is not used and we wait for
> > decryption crypto api to complete.
> >
> > For crypto requests executing in async fashion, the memory for
> > aead_request, sglists and skb etc is freed from the decryption
> > completion handler. The decryption completion handler wakesup the
> > sleeping user context when recvmsg() flags that it has done sending
> > all the decryption requests and there are no more decryption requests
> > pending to be completed.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > Reviewed-by: Dave Watson <davejwatson@fb.com>
> > ---
>
> [...]
>
>
> > @@ -1271,6 +1377,8 @@ int tls_set_sw_offload(struct sock *sk, struct
> tls_context *ctx, int tx)
> > goto free_aead;
> >
> > if (sw_ctx_rx) {
> > + (*aead)->reqsize = sizeof(struct decrypt_req_ctx);
> > +
>
> This is not valid and may cause GPF or best case only a KASAN warning.
> 'reqsize' should probably not be mangled outside the internal crypto APIs but
> the real reason is the reqsize is used to determine how much space is needed
> at the end of the aead_request for crypto private ctx use in encrypt/decrypt.
> After this patch when we submit an aead_request the crypto layer will think it
> has room for its private structs at the end but now only 8B will be there and
> crypto layer will happily memset some arbitrary memory for you amongst
> other things.
>
> Anyways testing a fix now will post shortly.
I am aware that the space in question after aead_request is used internally
by cryptoapi. My plan was to inflate this space by an extra sizeof(struct decrypt_req_ctx).
(*aead)->reqsize += sizeof(struct decrypt_req_ctx);
Somehow, I missed it.
But your piece of change look a better solution.
Thanks for submitting the fix.
>
> Thanks,
> John
^ permalink raw reply
* [PATCH net-next 5/5] net: dsa: tag_gswip: Add gswip to dsa_tag_protocol_to_str()
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
In-Reply-To: <20180915120849.24630-1-hauke@hauke-m.de>
The gswip tag was missing in the dsa_tag_protocol_to_str() function, add it.
Fixes: 7969119293f5 ("net: dsa: Add Lantiq / Intel GSWIP tag support")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
net/dsa/dsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 5f73e96cc9e6..a69c1790bbfc 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -88,6 +88,9 @@ const char *dsa_tag_protocol_to_str(const struct dsa_device_ops *ops)
#ifdef CONFIG_NET_DSA_TAG_EDSA
[DSA_TAG_PROTO_EDSA] = "edsa",
#endif
+#ifdef CONFIG_NET_DSA_TAG_GSWIP
+ [DSA_TAG_PROTO_GSWIP] = "gswip",
+#endif
#ifdef CONFIG_NET_DSA_TAG_KSZ
[DSA_TAG_PROTO_KSZ] = "ksz",
#endif
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 3/5] net: lantiq: lantiq_xrx200: Move clock prepare to probe function
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
In-Reply-To: <20180915120849.24630-1-hauke@hauke-m.de>
The switch and the MAC are in one IP core and they use the same clock
signal from the clock generation unit.
Currently the clock architecture in the lantiq SoC code does not allow
to easily share the same clocks, this has to be fixed by switching to
the common clock framework.
As a workaround the clock of the switch and MAC should be activated when
the MAC gets probed and only disabled when the MAC gets removed. This
way it is ensured that the clock is always enabled when the switch or
MAC is used. The switch can not be used without the MAC.
This fixes a data bus error when rebooting the system and deactivating
the switch and mac and later accessing some registers in the cleanup
while the clocks are disabled.
Fixes: fe1a56420cf2 ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/ethernet/lantiq_xrx200.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_xrx200.c b/drivers/net/ethernet/lantiq_xrx200.c
index c8b6d908f0cc..14b20ce0dd43 100644
--- a/drivers/net/ethernet/lantiq_xrx200.c
+++ b/drivers/net/ethernet/lantiq_xrx200.c
@@ -115,12 +115,6 @@ static void xrx200_flush_dma(struct xrx200_chan *ch)
static int xrx200_open(struct net_device *net_dev)
{
struct xrx200_priv *priv = netdev_priv(net_dev);
- int err;
-
- /* enable clock gate */
- err = clk_prepare_enable(priv->clk);
- if (err)
- return err;
napi_enable(&priv->chan_tx.napi);
ltq_dma_open(&priv->chan_tx.dma);
@@ -155,8 +149,6 @@ static int xrx200_close(struct net_device *net_dev)
napi_disable(&priv->chan_tx.napi);
ltq_dma_close(&priv->chan_tx.dma);
- clk_disable_unprepare(priv->clk);
-
return 0;
}
@@ -497,6 +489,11 @@ static int xrx200_probe(struct platform_device *pdev)
if (err)
return err;
+ /* enable clock gate */
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ goto err_uninit_dma;
+
/* set IPG to 12 */
xrx200_pmac_mask(priv, PMAC_RX_IPG_MASK, 0xb, PMAC_RX_IPG);
@@ -514,9 +511,12 @@ static int xrx200_probe(struct platform_device *pdev)
err = register_netdev(net_dev);
if (err)
- goto err_uninit_dma;
+ goto err_unprepare_clk;
return err;
+err_unprepare_clk:
+ clk_disable_unprepare(priv->clk);
+
err_uninit_dma:
xrx200_hw_cleanup(priv);
@@ -536,6 +536,9 @@ static int xrx200_remove(struct platform_device *pdev)
/* remove the actual device */
unregister_netdev(net_dev);
+ /* release the clock */
+ clk_disable_unprepare(priv->clk);
+
/* shut down hardware */
xrx200_hw_cleanup(priv);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/5] dt-bindings: net: dsa: lantiq,xrx200-gswip: Fix minor style fixes
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
In-Reply-To: <20180915120849.24630-1-hauke@hauke-m.de>
* Use one compatible line per line in the documentation
* Remove SoC revision depended compatible lines, we can detect that in
the driver
* Use lower case letters in hex addresses
* Fix the size of the address ranges in the example, this now matches
the sizes used by the SoC. The old ones will also work, this just adds
some empty address space.
* Change the reg size of the gphy-fw node
Fixes: 86ce2bc73c7a ("dt-bindings: net: dsa: Add lantiq, xrx200-gswip DT bindings")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: devicetree@vger.kernel.org
---
.../devicetree/bindings/net/dsa/lantiq-gswip.txt | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
index a089f5856778..886cbe8ffb38 100644
--- a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
+++ b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
@@ -22,9 +22,9 @@ required and optional properties.
Required properties for GPHY firmware loading:
-- compatible : "lantiq,gphy-fw" and "lantiq,xrx200-gphy-fw",
- "lantiq,xrx200a1x-gphy-fw", "lantiq,xrx200a2x-gphy-fw",
- "lantiq,xrx300-gphy-fw", or "lantiq,xrx330-gphy-fw"
+- compatible : "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw"
+ "lantiq,xrx300-gphy-fw", "lantiq,gphy-fw"
+ "lantiq,xrx330-gphy-fw", "lantiq,gphy-fw"
for the loading of the firmware into the embedded
GPHY core of the SoC.
- lantiq,rcu : reference to the rcu syscon
@@ -41,13 +41,13 @@ Example:
Ethernet switch on the VRX200 SoC:
-gswip: gswip@E108000 {
+switch@e108000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-gswip";
- reg = < 0xE108000 0x3000 /* switch */
- 0xE10B100 0x70 /* mdio */
- 0xE10B1D8 0x30 /* mii */
+ reg = < 0xe108000 0x3100 /* switch */
+ 0xe10b100 0xd8 /* mdio */
+ 0xe10b1d8 0x130 /* mii */
>;
dsa,member = <0 0>;
@@ -97,7 +97,7 @@ gswip: gswip@E108000 {
};
};
- mdio@0 {
+ mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-mdio";
@@ -123,6 +123,8 @@ gswip: gswip@E108000 {
gphy-fw {
compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw";
lantiq,rcu = <&rcu0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
gphy@20 {
reg = <0x20>;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 4/5] net: dsa: lantiq_gswip: Minor code style improvements
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
In-Reply-To: <20180915120849.24630-1-hauke@hauke-m.de>
Use one code block when returning because the interface type is
unsupported and also check if some unsupported port gets configured.
In addition fix a double the and use dsa_is_cpu_port() instated of
manually getting the CPU port.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/dsa/lantiq_gswip.c | 38 ++++++++++++++++++--------------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 9c28d0b2fcdb..4e3732b5790f 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -615,32 +615,24 @@ static void gswip_phylink_validate(struct dsa_switch *ds, int port,
if (!phy_interface_mode_is_rgmii(state->interface) &&
state->interface != PHY_INTERFACE_MODE_MII &&
state->interface != PHY_INTERFACE_MODE_REVMII &&
- state->interface != PHY_INTERFACE_MODE_RMII) {
- bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
- dev_err(ds->dev,
- "Unsupported interface: %d\n", state->interface);
- return;
- }
+ state->interface != PHY_INTERFACE_MODE_RMII)
+ goto unsupported;
break;
case 2:
case 3:
case 4:
- if (state->interface != PHY_INTERFACE_MODE_INTERNAL) {
- bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
- dev_err(ds->dev,
- "Unsupported interface: %d\n", state->interface);
- return;
- }
+ if (state->interface != PHY_INTERFACE_MODE_INTERNAL)
+ goto unsupported;
break;
case 5:
if (!phy_interface_mode_is_rgmii(state->interface) &&
- state->interface != PHY_INTERFACE_MODE_INTERNAL) {
- bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
- dev_err(ds->dev,
- "Unsupported interface: %d\n", state->interface);
- return;
- }
+ state->interface != PHY_INTERFACE_MODE_INTERNAL)
+ goto unsupported;
break;
+ default:
+ bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+ dev_err(ds->dev, "Unsupported port: %i\n", port);
+ return;
}
/* Allow all the expected bits */
@@ -667,6 +659,12 @@ static void gswip_phylink_validate(struct dsa_switch *ds, int port,
__ETHTOOL_LINK_MODE_MASK_NBITS);
bitmap_and(state->advertising, state->advertising, mask,
__ETHTOOL_LINK_MODE_MASK_NBITS);
+ return;
+
+unsupported:
+ bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+ dev_err(ds->dev, "Unsupported interface: %d\n", state->interface);
+ return;
}
static void gswip_phylink_mac_config(struct dsa_switch *ds, int port,
@@ -970,7 +968,7 @@ static int gswip_gphy_fw_list(struct gswip_priv *priv,
int err;
int i = 0;
- /* The The VRX200 rev 1.1 uses the GSWIP 2.0 and needs the older
+ /* The VRX200 rev 1.1 uses the GSWIP 2.0 and needs the older
* GPHY firmware. The VRX200 rev 1.2 uses the GSWIP 2.1 and also
* needs a different GPHY firmware.
*/
@@ -1097,7 +1095,7 @@ static int gswip_probe(struct platform_device *pdev)
dev_err(dev, "dsa switch register failed: %i\n", err);
goto mdio_bus;
}
- if (priv->ds->dst->cpu_dp->index != priv->hw_info->cpu_port) {
+ if (!dsa_is_cpu_port(priv->ds, priv->hw_info->cpu_port)) {
dev_err(dev, "wrong CPU port defined, HW only supports port: %i",
priv->hw_info->cpu_port);
err = -EINVAL;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 1/5] dt-bindings: net: lantiq,xrx200-net: Use lower case in hex
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
In-Reply-To: <20180915120849.24630-1-hauke@hauke-m.de>
Use lower case letters in the addresses of the device tree binding.
In addition replace eth with ethernet and fix the size of the reg
element in the example. The additional range does not contain any
registers but is used for the IP block on the this SoC.
Fixes: 839790e88a3c ("dt-bindings: net: Add lantiq, xrx200-net DT bindings")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt
index 8a2fe5200cdc..5ff5e68bbbb6 100644
--- a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt
+++ b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt
@@ -11,11 +11,11 @@ Required properties:
Example:
-eth0: eth@E10B308 {
+ethernet@e10b308 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "lantiq,xrx200-net";
- reg = <0xE10B308 0x30>;
+ reg = <0xe10b308 0xcf8>;
interrupts = <73>, <72>;
interrupt-names = "tx", "rx";
};
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 0/5] net: lantiq: Minor fixes for vrx200 and gswip
From: Hauke Mehrtens @ 2018-09-15 12:08 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens, devicetree, Hauke Mehrtens
These are mostly minor fixes to problems addresses in the latests round
of the review of the original series adding these driver, which were not
applied before the patches got merged into net-next.
In addition it fixes a data bus error on poweroff.
Hauke Mehrtens (5):
dt-bindings: net: lantiq,xrx200-net: Use lower case in hex
dt-bindings: net: dsa: lantiq,xrx200-gswip: Fix minor style fixes
net: lantiq: lantiq_xrx200: Move clock prepare to probe function
net: dsa: lantiq_gswip: Minor code style improvements
net: dsa: tag_gswip: Add gswip to dsa_tag_protocol_to_str()
.../devicetree/bindings/net/dsa/lantiq-gswip.txt | 18 +++++-----
.../devicetree/bindings/net/lantiq,xrx200-net.txt | 4 +--
drivers/net/dsa/lantiq_gswip.c | 38 ++++++++++------------
drivers/net/ethernet/lantiq_xrx200.c | 21 +++++++-----
net/dsa/dsa.c | 3 ++
5 files changed, 45 insertions(+), 39 deletions(-)
--
2.11.0
^ permalink raw reply
* URGENT UPDATES.................
From: Fatou Bobo Wann @ 2018-09-15 11:05 UTC (permalink / raw)
In-Reply-To: <493893948.2187709.1537009507959.ref@mail.yahoo.com>
Dear Friend,
With due respect to your person and much sincerity of purpose.I wrote you two days ago expecting that you would reply as regards the urgency of this proposal that i passed to you.Anyway, I don't know if you did receive it or not that is the reason I am re-sending it.I have a business proposal which I will like to handle with you. $35 million USD is involves. But be rest assured that everything is legal and risk free as I have concluded all the arrangements and the legal papers that will back the transaction up. Kindly indicate your interest as to enable me tell you more detail of the proposal.
Waiting for your urgent response.
Yours Faithfully,
Mrs.Fatou Bobo Wann
^ 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