* 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
* 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 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 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 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 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: 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
* внимания
From: администратор @ 2018-09-15 11:35 UTC (permalink / raw)
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже:
имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:
Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен!
Приносим извинения за неудобства.
Проверочный код: EN: 87431`09875
Почты технической поддержки © 2018
спасибо
системы администратор
^ 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
* 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 19/20] security/keys: rewrite big_key crypto to use Zinc
From: kbuild test robot @ 2018-09-15 23:52 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, David Howells
In-Reply-To: <20180914162240.7925-20-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 >>):
>> drivers/acpi/Kconfig:9:error: recursive dependency detected!
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_CHACHA20
>> lib/zinc/Kconfig:4: symbol ZINC_CHACHA20 is selected by ZINC_CHACHA20POLY1305
>> lib/zinc/Kconfig:13: symbol ZINC_CHACHA20POLY1305 is selected by BIG_KEYS
>> security/keys/Kconfig:44: symbol BIG_KEYS depends on KEYS
>> security/keys/Kconfig:5: symbol KEYS is selected by FS_ENCRYPTION
>> fs/crypto/Kconfig:1: symbol FS_ENCRYPTION is selected by UBIFS_FS_ENCRYPTION
>> fs/ubifs/Kconfig:65: symbol UBIFS_FS_ENCRYPTION depends on MISC_FILESYSTEMS
>> fs/Kconfig:218: symbol MISC_FILESYSTEMS is selected by ACPI_APEI
>> drivers/acpi/apei/Kconfig:8: symbol ACPI_APEI depends on ACPI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
vim +4 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 4 was first introduced by commit
:::::: 35f45248597b5a2c80f0f4a680344c22c86efe7d zinc: ChaCha20 generic C implementation
:::::: 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
* Re: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
From: Maciej S. Szmigiero @ 2018-09-15 23:54 UTC (permalink / raw)
To: David Arendt; +Cc: linux-kernel, nic_swsd, netdev
In-Reply-To: <4f54989b-9492-420e-374b-d8c9bddf0a7d@prnet.org>
[ I've added Realtek Linux NIC and netdev mailing lists to CC ]
Hi David,
On 15.09.2018 23:23, David Arendt wrote:
> Hi,
>
> just a follow up:
>
> In kernel 4.18.8 the behaviour is different.
>
> The network is not reachable a number of times, but restarting to be
> reachable by itself before it finally is no longer reachable at all.
>
> Here the logging output:
>
> Sep 15 17:44:43 server kernel: NETDEV WATCHDOG: enp3s0 (r8169): transmit
> queue 0 timed out
> Sep 15 17:44:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:10:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:12:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:13:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:14:48 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:20:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:34:19 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:43:43 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 18:46:26 server kernel: r8169 0000:03:00.0 enp3s0: link up
> Sep 15 19:00:24 server kernel: r8169 0000:03:00.0 enp3s0: link up
>
> From 17:44 ro 18:46 the network is recovering automatically. After the
> up from 19:00, the network is no longer reachable without any additional
> message.
>
> If looking at ifconfig, the counter for TX packets is incrementing, the
> counter for RX packets not.
>
> Here again the driver from 4.17.14 is working flawlessly.
Could you please try this patch on top of 4.18.8:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f74dd480cf4e31e12971c58a1d832044db945670
In my case the problem fixed by the above commit was only limited to
bad TX performance but my r8169 NIC models were different from what
you have.
If this does not help then try bisecting the issue
(maybe limited to drivers/net/ethernet/realtek/r8169.c to save time).
If the NIC dies after a heavy load it might be possible to generate
such load quickly by in-kernel pktgen.
If that's not possible then at please least compare NIC register
values displayed by "ethtool -d enp3s0" between working and
non-working kernels.
> Thanks in advance,
> David Arendt
Maciej
>
>
> On 9/4/18 8:19 AM, David Arendt wrote:
>> Hi,
>>
>> When using kernel 4.18.5 the Realtek 8111G network adapter stops
>> responding under high system load.
>>
>> Dmesg is showing no errors.
>>
>> Sometimes an ifconfig enp3s0 down followed by an ifconfig enp3s0 up is
>> enough for the network adapter to restart responding. Sometimes a reboot
>> is necessary.
>>
>> When copying r8169.c from 4.17.14 to the 4.18.5 kernel, networking works
>> perfectly stable on 4.18.5 so the problem seems r8169.c related.
>>
>> Here the output from lshw:
>>
>> *-pci:2
>> description: PCI bridge
>> product: 8 Series/C220 Series Chipset Family PCI Express
>> Root Port #3
>> vendor: Intel Corporation
>> physical id: 1c.2
>> bus info: pci@0000:00:1c.2
>> version: d5
>> width: 32 bits
>> clock: 33MHz
>> capabilities: pci pciexpress msi pm normal_decode
>> bus_master cap_list
>> configuration: driver=pcieport
>> resources: irq:18 ioport:d000(size=4096)
>> memory:f7300000-f73fffff ioport:f2100000(size=1048576)
>> *-network
>> description: Ethernet interface
>> product: RTL8111/8168/8411 PCI Express Gigabit Ethernet
>> Controller
>> vendor: Realtek Semiconductor Co., Ltd.
>> physical id: 0
>> bus info: pci@0000:03:00.0
>> logical name: enp3s0
>> version: 0c
>> serial: <hidden>
>> size: 1Gbit/s
>> capacity: 1Gbit/s
>> width: 64 bits
>> clock: 33MHz
>> capabilities: pm msi pciexpress msix vpd bus_master
>> cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt
>> 1000bt-fd autonegotiation
>> configuration: autonegotiation=on broadcast=yes
>> driver=r8169 driverversion=2.3LK-NAPI duplex=full
>> firmware=rtl8168g-2_0.0.1 02/06/13 latency=0 link=yes multicast=yes
>> port=MII speed=1Gbit/s
>> resources: irq:18 ioport:d000(size=256)
>> memory:f7300000-f7300fff memory:f2100000-f2103fff
>>
>> Thanks in advance for looking into this,
>>
>> David Arendt
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next v4 19/20] security/keys: rewrite big_key crypto to use Zinc
From: Jason A. Donenfeld @ 2018-09-16 0:29 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers, David Howells
In-Reply-To: <201809160738.Z71qdjGu%fengguang.wu@intel.com>
Hey again Ro,
> 32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if CPU_V7
This shouldn't have ever been there anyway. Fixed now for v5.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v4 17/20] crypto: port Poly1305 to Zinc
From: Jason A. Donenfeld @ 2018-09-16 0:31 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <201809160719.qunccnIZ%fengguang.wu@intel.com>
Greetings Mr. Ro Bot,
Another one of your robot friends also caught this, and the offending
code has been removed for v5.
Thanks for botting,
Jason
^ permalink raw reply
* [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support
From: ALeX Kazik @ 2018-09-15 20:40 UTC (permalink / raw)
To: netdev; +Cc: Linux/m68k, Rolf Anders
This adds an option to change the (10 MBit only) "apne" driver to support
the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead.
A new configure option is added as a bool to the apne driver to change the
behaviour to support some new cards instead.
The option can be only enabled if no other 8390 driver is active because the
8390 library is modified when activated.
The patch is initially from http://www.g-mb.de/pcmcia_e.html and adapted by
me from the 2.6 version.
The contained reset fix is required to use a pcmcia card after a reset/reboot,
and is also only activated with new option. (Background, as far as I
understood it: The pcmcia reset line is not connected and after a reset/reboot
the pcmcia card is in an undefined state and needs a manual reset.)
This reset patch is probably useful to all Amiga pcmcia drivers (network and
other) but since I do not own any other card I can't verify that.
Signed-off-by: ALeX Kazik <alex@kazik.de>
Tested-by: ALeX Kazik <alex@kazik.de>
diff -urp linux-4.18.7/drivers/net/ethernet/8390/8390.h linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h
--- linux-4.18.7/drivers/net/ethernet/8390/8390.h 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/8390.h 2018-09-15 14:51:00.000000000 +0200
@@ -222,4 +222,21 @@ struct ei_device {
#define ENTSR_CDH 0x40 /* The collision detect "heartbeat" signal was lost. */
#define ENTSR_OWC 0x80 /* There was an out-of-window collision. */
+/* Change the driver to support word access instead of byte access.
+ * Cards that work with byte access will not work with word access.
+ */
+#ifdef CONFIG_APNE100MBIT
+/* redefine inb to do word accesses */
+#undef inb
+#define inb(x) ((x) & 1 ? inw((x) - 1) & 0xff : inw(x) >> 8)
+#undef inb_p
+#define inb_p(x) inb(x)
+
+/* The following redefinition of outb isn't necessary, but may be faster on
+ * slow processors.
+ */
+#undef outb
+#define outb(x, y) raw_outb(x, (y) + GAYLE_IO + (((y) & 1) ? GAYLE_ODD : 0))
+#endif
+
#endif /* _8390_h */
Only in linux-4.18.7-patched/drivers/net/ethernet/8390/: 8390.h.orig
diff -urp linux-4.18.7/drivers/net/ethernet/8390/Kconfig linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig
--- linux-4.18.7/drivers/net/ethernet/8390/Kconfig 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/Kconfig 2018-09-15 14:34:18.000000000 +0200
@@ -142,6 +142,22 @@ config APNE
To compile this driver as a module, choose M here: the module
will be called apne.
+if APNE
+config APNE100MBIT
+ bool "PCMCIA NE2000 100MBit support"
+ default n
+ depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n
+ depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n
+ depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n
+ depends on XSURF100=n && ZORRO8390=n
+ ---help---
+ This changes the driver to support ONLY 10/100Mbit cards (e.g. Netgear
+ FA411, CNet Singlepoint).
+ Cards that worked with the original version won't with this version.
+
+ Say N, unless you absolutely know what you are doing.
+endif
+
config PCMCIA_PCNET
tristate "NE2000 compatible PCMCIA support"
depends on PCMCIA
diff -urp linux-4.18.7/drivers/net/ethernet/8390/apne.c linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c
--- linux-4.18.7/drivers/net/ethernet/8390/apne.c 2018-09-09 10:32:43.000000000 +0200
+++ linux-4.18.7-patched/drivers/net/ethernet/8390/apne.c 2018-09-15 14:48:27.000000000 +0200
@@ -590,6 +590,16 @@ static int init_pcmcia(void)
#endif
u_long offset;
+#ifdef CONFIG_APNE100MBIT
+ /* reset card (idea taken from CardReset by Artur Pogoda) */
+ {
+ u_char tmp = gayle.intreq;
+
+ gayle.intreq = 0xff; mdelay(1);
+ gayle.intreq = tmp; mdelay(300);
+ }
+#endif
+
pcmcia_reset();
pcmcia_program_voltage(PCMCIA_0V);
pcmcia_access_speed(PCMCIA_SPEED_250NS);
^ permalink raw reply
* Re: [PATCH net-next v3 10/11] phy: add driver for Microsemi Ocelot SerDes muxing
From: Florian Fainelli @ 2018-09-15 21:20 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem, kishon, andrew
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni
In-Reply-To: <cde4ccafdbd948db7ccbb263dd5b1a803e63a83e.1536912834.git-series.quentin.schulz@bootlin.com>
On 09/14/18 01:16, Quentin Schulz wrote:
> The Microsemi Ocelot can mux SerDes lanes (aka macros) to different
> switch ports or even make it act as a PCIe interface.
>
> This adds support for the muxing of the SerDes.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> ---
[snip]
> +
> +struct serdes_macro {
> + u8 idx;
> + /* Not used when in QSGMII or PCIe mode */
> + int port;
u8 port to be consistent with the mux table?
[snip]
> +#define SERDES_MUX(_idx, _port, _mode, _mask, _mux) { \
> + .idx = _idx, \
> + .port = _port, \
> + .mode = _mode, \
> + .mask = _mask, \
> + .mux = _mux, \
> +}
> +
> +static const struct serdes_mux ocelot_serdes_muxes[] = {
> + SERDES_MUX(SERDES1G_0, 0, PHY_MODE_SGMII, 0, 0),
> + SERDES_MUX(SERDES1G_1, 1, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_5_MODE, 0),
> + SERDES_MUX(SERDES1G_1, 5, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE, HSIO_HW_CFG_DEV1G_5_MODE),
Why not go one step further and define a SERDES_MUX_SGMII() macro which
automatically resolves the correct bit definitions to use?
The current macro does not make this particularly easy to read :/
> + SERDES_MUX(SERDES1G_2, 2, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_4_MODE, 0),
> + SERDES_MUX(SERDES1G_2, 4, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_4_MODE, HSIO_HW_CFG_DEV1G_4_MODE),
> + SERDES_MUX(SERDES1G_3, 3, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_6_MODE, 0),
> + SERDES_MUX(SERDES1G_3, 6, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_6_MODE, HSIO_HW_CFG_DEV1G_6_MODE),
> + SERDES_MUX(SERDES1G_4, 4, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_4_MODE | HSIO_HW_CFG_DEV1G_9_MODE, 0),
> + SERDES_MUX(SERDES1G_4, 9, PHY_MODE_SGMII, HSIO_HW_CFG_DEV1G_4_MODE |
> + HSIO_HW_CFG_DEV1G_9_MODE, HSIO_HW_CFG_DEV1G_4_MODE |
> + HSIO_HW_CFG_DEV1G_9_MODE),
> + SERDES_MUX(SERDES1G_5, 5, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE, 0),
> + SERDES_MUX(SERDES1G_5, 10, PHY_MODE_SGMII, HSIO_HW_CFG_PCIE_ENA |
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE,
> + HSIO_HW_CFG_DEV1G_5_MODE | HSIO_HW_CFG_DEV2G5_10_MODE),
> + SERDES_MUX(SERDES6G_0, 4, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 5, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 6, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_0, 7, PHY_MODE_SGMII, HSIO_HW_CFG_QSGMII_ENA, 0),
> + SERDES_MUX(SERDES6G_0, 7, PHY_MODE_QSGMII, HSIO_HW_CFG_QSGMII_ENA,
> + HSIO_HW_CFG_QSGMII_ENA),
> + SERDES_MUX(SERDES6G_1, 8, PHY_MODE_SGMII, 0, 0),
> + SERDES_MUX(SERDES6G_2, 10, PHY_MODE_SGMII, HSIO_HW_CFG_PCIE_ENA |
> + HSIO_HW_CFG_DEV2G5_10_MODE, 0),
> + SERDES_MUX(SERDES6G_2, 10, PHY_MODE_PCIE, HSIO_HW_CFG_PCIE_ENA,
> + HSIO_HW_CFG_PCIE_ENA),
> +};
> +
> +static int serdes_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct serdes_macro *macro = phy_get_drvdata(phy);
> + int ret, i;
unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ocelot_serdes_muxes); i++) {
> + if (macro->idx != ocelot_serdes_muxes[i].idx ||
> + mode != ocelot_serdes_muxes[i].mode)
> + continue;
> +
> + if (mode != PHY_MODE_QSGMII &&
> + macro->port != ocelot_serdes_muxes[i].port)
> + continue;
> +
> + ret = regmap_update_bits(macro->ctrl->regs, HSIO_HW_CFG,
> + ocelot_serdes_muxes[i].mask,
> + ocelot_serdes_muxes[i].mux);
> + if (ret)
> + return ret;
> +
> + if (macro->idx < SERDES1G_MAX)
> + return serdes_init_s1g(macro->ctrl->regs, macro->idx);
> +
> + /* SERDES6G and PCIe not supported yet */
> + return 0;
Would not returning -EOPNOTSUPP be more helpful rather than leaving the
PHY unconfigured (or did the bootloader somehow configure it before for us)?
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct phy_ops serdes_ops = {
> + .set_mode = serdes_set_mode,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *serdes_simple_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct serdes_ctrl *ctrl = dev_get_drvdata(dev);
> + int port, idx, i;
unsigned int port, idx, i;
[snip]
> +
> +static int serdes_probe(struct platform_device *pdev)
> +{
> + struct phy_provider *provider;
> + struct serdes_ctrl *ctrl;
> + int i, ret;
unsigned int i;
> +
> + ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
> + if (!ctrl)
> + return -ENOMEM;
> +
> + ctrl->dev = &pdev->dev;
> + ctrl->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (!ctrl->regs)
> + return -ENODEV;
> +
> + for (i = 0; i <= SERDES_MAX; i++) {
Every other loop you have is using <, is this one off-by-one?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration
From: Florian Fainelli @ 2018-09-15 21:25 UTC (permalink / raw)
To: Quentin Schulz, alexandre.belloni, ralf, paul.burton, jhogan,
robh+dt, mark.rutland, davem, kishon, andrew
Cc: allan.nielsen, linux-mips, devicetree, linux-kernel, netdev,
thomas.petazzoni
In-Reply-To: <00989856964175eafbe1435a70862c2ac66cffc0.1536912834.git-series.quentin.schulz@bootlin.com>
On 09/14/18 01:16, Quentin Schulz wrote:
> Previously, the SerDes muxing was hardcoded to a given mode in the MAC
> controller driver. Now, the SerDes muxing is configured within the
> Device Tree and is enforced in the MAC controller driver so we can have
> a lot of different SerDes configurations.
>
> Make use of the SerDes PHYs in the MAC controller to set up the SerDes
> according to the SerDes<->switch port mapping and the communication mode
> with the Ethernet PHY.
This looks good, just a few comments below:
[snip]
> + err = of_get_phy_mode(portnp);
> + if (err < 0)
> + ocelot->ports[port]->phy_mode = PHY_INTERFACE_MODE_NA;
> + else
> + ocelot->ports[port]->phy_mode = err;
> +
> + switch (ocelot->ports[port]->phy_mode) {
> + case PHY_INTERFACE_MODE_NA:
> + continue;
Would not you want to issue a message indicating that the Device Tree
must be updated here? AFAICT with your patch series, this should no
longer be a condition that you will hit unless you kept the old DTB
around, right?
> + case PHY_INTERFACE_MODE_SGMII:
> + phy_mode = PHY_MODE_SGMII;
> + break;
> + case PHY_INTERFACE_MODE_QSGMII:
> + phy_mode = PHY_MODE_QSGMII;
> + break;
> + default:
> + dev_err(ocelot->dev,
> + "invalid phy mode for port%d, (Q)SGMII only\n",
> + port);
> + return -EINVAL;
> + }
> +
> + serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
> + if (IS_ERR(serdes)) {
> + err = PTR_ERR(serdes);
> + if (err == -EPROBE_DEFER) {
This can be simplified into:
if (err == -EPROBE_DEFER)
dev_dbg();
else
dev_err();
goto err_probe_ports;
> + dev_dbg(ocelot->dev, "deferring probe\n");
> + goto err_probe_ports;
> + }
> +
> + dev_err(ocelot->dev, "missing SerDes phys for port%d\n",
> + port);
> goto err_probe_ports;
> }
> +
> + ocelot->ports[port]->serdes = serdes;
> }
>
> register_netdevice_notifier(&ocelot_netdevice_nb);
>
--
Florian
^ permalink raw reply
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Florian Fainelli @ 2018-09-15 21:31 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <1536961136-30453-8-git-send-email-andrew@lunn.ch>
On 09/14/18 14:38, Andrew Lunn wrote:
> This is one step in allowing phylib to make use of link_mode bitmaps,
> instead of u32 for supported and advertised features. Convert the phy
> drivers to use bitmaps to indicates the features they support. This
> requires some macro magic in order to construct constant bitmaps used
> to initialise the driver structures.
>
> Some new PHY_*_FEATURES are added, to indicate FIBRE is supported, and
> that all media ports are supported. This is done since bitmaps cannot
> be ORed together at compile time.
>
> Within phylib, the features bitmap is currently turned back into a
> u32. The MAC API to phylib needs to be cleaned up before the core of
> phylib can be converted to using bitmaps instead of u32.
Nice!
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATH RFC net-next 8/8] net: phy: Add build warning if assumptions get broken
From: Florian Fainelli @ 2018-09-15 21:31 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <1536961136-30453-9-git-send-email-andrew@lunn.ch>
On 09/14/18 14:38, Andrew Lunn wrote:
> The macro magic to build constant bitmaps of supported PHY features
> breaks when we have more than 63 ETHTOOL_LINK_MODE bits. Make the
> breakage loud, not a subtle bug, when we get to that condition.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: Urgent Please!!
From: Reem Al-Hashimy @ 2018-09-13 13:29 UTC (permalink / raw)
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international cooparation. I got your contact from a certain email database from your country while i was looking for someone to handle a huge financial transaction for me in confidence. Can you receive and invest on behalf of my only son. Please reply to reemhashimy718@gmail.com, for more details if you are interested.
Regards,
Ms. Reem Al-Hashimy
^ permalink raw reply
* Re: [PATH RFC net-next 7/8] net: phy: Replace phy driver features u32 with link_mode bitmap
From: Andrew Lunn @ 2018-09-15 22:30 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <12e5b18f-400f-d4d0-aca3-4e4d8b4bb6a9@gmail.com>
On Sat, Sep 15, 2018 at 02:31:14PM -0700, Florian Fainelli wrote:
>
>
> On 09/14/18 14:38, Andrew Lunn wrote:
> > This is one step in allowing phylib to make use of link_mode bitmaps,
> > instead of u32 for supported and advertised features. Convert the phy
> > drivers to use bitmaps to indicates the features they support. This
> > requires some macro magic in order to construct constant bitmaps used
> > to initialise the driver structures.
> >
> > Some new PHY_*_FEATURES are added, to indicate FIBRE is supported, and
> > that all media ports are supported. This is done since bitmaps cannot
> > be ORed together at compile time.
> >
> > Within phylib, the features bitmap is currently turned back into a
> > u32. The MAC API to phylib needs to be cleaned up before the core of
> > phylib can be converted to using bitmaps instead of u32.
>
> Nice!
Hi Florian
This is the patch i don't like. I'm hoping somebody can think of a
better way to initialise a bitmap.
Andrew
^ permalink raw reply
* [PATCH net-next] selftests/tls: Add MSG_WAITALL in recv() syscall
From: Vakul Garg @ 2018-09-16 4:34 UTC (permalink / raw)
To: netdev
Cc: linux-kselftest, linux-kernel, shuah, davejwatson, davem, doronrk,
Vakul Garg
A number of tls selftests rely upon recv() to return an exact number of
data bytes. When tls record crypto is done using an async accelerator,
it is possible that recv() returns lesser than expected number bytes.
This leads to failure of many test cases. To fix it, MSG_WAITALL has
been used in flags passed to recv() syscall.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
tools/testing/selftests/net/tls.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c
index 07daff076ce0..96fc6fe70293 100644
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@ -121,11 +121,11 @@ TEST_F(tls, send_then_sendfile)
buf = (char *)malloc(st.st_size);
EXPECT_EQ(send(self->fd, test_str, to_send, 0), to_send);
- EXPECT_EQ(recv(self->cfd, recv_buf, to_send, 0), to_send);
+ EXPECT_EQ(recv(self->cfd, recv_buf, to_send, MSG_WAITALL), to_send);
EXPECT_EQ(memcmp(test_str, recv_buf, to_send), 0);
EXPECT_GE(sendfile(self->fd, filefd, 0, st.st_size), 0);
- EXPECT_EQ(recv(self->cfd, buf, st.st_size, 0), st.st_size);
+ EXPECT_EQ(recv(self->cfd, buf, st.st_size, MSG_WAITALL), st.st_size);
}
TEST_F(tls, recv_max)
@@ -160,7 +160,7 @@ TEST_F(tls, msg_more)
EXPECT_EQ(send(self->fd, test_str, send_len, MSG_MORE), send_len);
EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_DONTWAIT), -1);
EXPECT_EQ(send(self->fd, test_str, send_len, 0), send_len);
- EXPECT_EQ(recv(self->cfd, buf, send_len * 2, MSG_DONTWAIT),
+ EXPECT_EQ(recv(self->cfd, buf, send_len * 2, MSG_WAITALL),
send_len * 2);
EXPECT_EQ(memcmp(buf, test_str, send_len), 0);
}
@@ -180,7 +180,7 @@ TEST_F(tls, sendmsg_single)
msg.msg_iov = &vec;
msg.msg_iovlen = 1;
EXPECT_EQ(sendmsg(self->fd, &msg, 0), send_len);
- EXPECT_EQ(recv(self->cfd, buf, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_WAITALL), send_len);
EXPECT_EQ(memcmp(buf, test_str, send_len), 0);
}
@@ -306,7 +306,7 @@ TEST_F(tls, splice_from_pipe2)
EXPECT_GE(splice(p[0], NULL, self->fd, NULL, 8000, 0), 0);
EXPECT_GE(write(p2[1], mem_send + 8000, 8000), 0);
EXPECT_GE(splice(p2[0], NULL, self->fd, NULL, 8000, 0), 0);
- EXPECT_GE(recv(self->cfd, mem_recv, send_len, 0), 0);
+ EXPECT_EQ(recv(self->cfd, mem_recv, send_len, MSG_WAITALL), send_len);
EXPECT_EQ(memcmp(mem_send, mem_recv, send_len), 0);
}
@@ -436,7 +436,7 @@ TEST_F(tls, multiple_send_single_recv)
EXPECT_GE(send(self->fd, send_mem, send_len, 0), 0);
EXPECT_GE(send(self->fd, send_mem, send_len, 0), 0);
memset(recv_mem, 0, total_len);
- EXPECT_EQ(recv(self->cfd, recv_mem, total_len, 0), total_len);
+ EXPECT_EQ(recv(self->cfd, recv_mem, total_len, MSG_WAITALL), total_len);
EXPECT_EQ(memcmp(send_mem, recv_mem, send_len), 0);
EXPECT_EQ(memcmp(send_mem, recv_mem + send_len, send_len), 0);
@@ -537,7 +537,7 @@ TEST_F(tls, pollin)
EXPECT_EQ(poll(&fd, 1, 20), 1);
EXPECT_EQ(fd.revents & POLLIN, 1);
- EXPECT_EQ(recv(self->cfd, buf, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, buf, send_len, MSG_WAITALL), send_len);
/* Test timing out */
EXPECT_EQ(poll(&fd, 1, 20), 0);
}
@@ -555,7 +555,7 @@ TEST_F(tls, poll_wait)
/* Set timeout to inf. secs */
EXPECT_EQ(poll(&fd, 1, -1), 1);
EXPECT_EQ(fd.revents & POLLIN, 1);
- EXPECT_EQ(recv(self->cfd, recv_mem, send_len, 0), send_len);
+ EXPECT_EQ(recv(self->cfd, recv_mem, send_len, MSG_WAITALL), send_len);
}
TEST_F(tls, blocking)
@@ -701,7 +701,7 @@ TEST_F(tls, control_msg)
EXPECT_EQ(recv(self->cfd, buf, send_len, 0), -1);
vec.iov_base = buf;
- EXPECT_EQ(recvmsg(self->cfd, &msg, 0), send_len);
+ EXPECT_EQ(recvmsg(self->cfd, &msg, MSG_WAITALL), send_len);
cmsg = CMSG_FIRSTHDR(&msg);
EXPECT_NE(cmsg, NULL);
EXPECT_EQ(cmsg->cmsg_level, SOL_TLS);
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc
From: Jason A. Donenfeld @ 2018-09-15 23:21 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Eric Biggers
In-Reply-To: <201809160711.HzjdJedZ%fengguang.wu@intel.com>
Hi Mr. Ro Bot,
On Sun, Sep 16, 2018 at 1:14 AM kbuild test robot <lkp@intel.com> wrote:
> crypto/chacha20_zinc.o: In function `crypto_chacha20_crypt':
> >> crypto/chacha20_zinc.c:55: undefined reference to `chacha20'
Looks like my Kconfig change didn't get squashed in as intended. Fixed for v5.
Thanks,
Jason
^ permalink raw reply
* Fw: [Bug 201137] New: using traffic control with sfq cause kernel crash
From: Stephen Hemminger @ 2018-09-15 23:26 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 15 Sep 2018 08:43:09 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 201137] New: using traffic control with sfq cause kernel crash
https://bugzilla.kernel.org/show_bug.cgi?id=201137
Bug ID: 201137
Summary: using traffic control with sfq cause kernel crash
Product: Networking
Version: 2.5
Kernel Version: 4.18.5
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: grafgrimm77@gmx.de
Regression: No
Created attachment 278555
--> https://bugzilla.kernel.org/attachment.cgi?id=278555&action=edit
kernel config
Copying from the machine to an other server (protocol does not matter), causes
a kernel crash when using tc-setting with SFQ.
The machine has a Qualcom Killer NIC: lspci |grep Killer
03:00.0 Ethernet controller: Qualcomm Atheros Killer E220x Gigabit Ethernet
Controller (rev 13)
I use traffic control with SFQ:
tc qdisc add dev enp3s0 root handle 1: sfq
tc qdisc show dev enp3s0
Now I try to copy a big file (124GB, an image of a partition) to another
Linux-Server (same kernel version) to a NFS-Share. It does not matter if it is
a nfs or samba or whatever-share. It also does not matter if I use cp or rsync
command.
The target-share is for example:
grep base /proc/mounts
jaguar.grafnetz:/base /mnt/base nfs4
rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.9,local_lock=none,addr=192.168.0.7
0 0
df shows this nfs-share called base when mounted:
jaguar.grafnetz:/base 11718572032 6012592128 5705979904 52% /mnt/base
Now I use a simpe cp-command:
cp big-fime.dd.image /mnt/base/test_01
The machine crashes after 7833735168 Bytes reached the Target-Server. About 7,9
GB (with G=1000^3).
I can reproduce this crash.
The good thing is: I figured out that no kernel crash happens when I do not
use:
tc qdisc add dev enp3s0 root handle 1: sfq
tc qdisc show dev enp3s0
(So I commented it out from my local start-script and rebootet the system.)
Result: No crash any more. Copying the big file (124GB) completed without a
kernel crash.
Additional Information...
NIC is configured with IPv4:
haswell ~ # ifconfig
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.9 netmask 255.255.255.0 broadcast 192.168.0.255
ether d4:3d:7e:bd:89:44 txqueuelen 1000 (Ethernet)
RX packets 7399483 bytes 511559908 (487.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 91781850 bytes 47176316774 (43.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19
ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000060e4 (24804)
link ifup rx_err tx_err hw wol
Link detected: yes
While copying over the Gigabit-Network, speed is near maximum:
ifstat
enp2s0
KB/s in KB/s out
0.06 0.18
8348.65 31.60
117536.2 435.11
118049.0 435.04
119100.9 434.84
118889.7 435.19
119004.1 444.53
119061.4 440.47
119102.8 444.04
119077.4 444.39
119084.1 432.32
119089.6 439.71
[...]
So, perhaps the sfq-Kernel-module has a bug. I use the vanilla kernel from
kernel.org and sfq is compiled as a module.
/usr/src/linux # grep SFQ .config
CONFIG_NET_SCH_SFQ=m
Perhaps important: the server with the target-share also uses sfq with the same
settings without a problem. It runs stable.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* pull-request: bpf 2018-09-16
From: Daniel Borkmann @ 2018-09-16 0:36 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix end boundary calculation in BTF for the type section, from Martin.
2) Fix and revert subtraction of pointers that was accidentally allowed
for unprivileged programs, from Alexei.
3) Fix bpf_msg_pull_data() helper by using __GFP_COMP in order to avoid
a warning in linearizing sg pages into a single one for large allocs,
from Tushar.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit cc4dfb7f70a344f24c1c71e298deea0771dadcb2:
rds: fix two RCU related problems (2018-09-12 00:09:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 4c3d795cb012a378855543a775408fba1ccff6f2:
bpf: use __GFP_COMP while allocating page (2018-09-12 23:47:28 +0200)
----------------------------------------------------------------
Alexei Starovoitov (1):
bpf/verifier: disallow pointer subtraction
Martin KaFai Lau (1):
bpf: btf: Fix end boundary calculation for type section
Tushar Dave (1):
bpf: use __GFP_COMP while allocating page
kernel/bpf/btf.c | 2 +-
kernel/bpf/verifier.c | 2 +-
net/core/filter.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
^ 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