* Re: [PATCH v2 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-08-27 12:52 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, Jason A. Donenfeld,
Greg KH
In-Reply-To: <20180824213849.23647-18-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 42510 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc1 next-20180827]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180827-073051
config: um-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um
All error/warnings (new ones prefixed by >>):
In file included from lib/zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/chacha20/chacha20-x86_64-glue.h:27:13: warning: 'chacha20_use_avx512vl' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512vl __ro_after_init;
^~~~~~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:26:13: warning: 'chacha20_use_avx512' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:25:13: warning: 'chacha20_use_avx2' defined but not used [-Wunused-variable]
static bool chacha20_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib/zinc/chacha20/chacha20-x86_64-glue.h:24:13: warning: 'chacha20_use_ssse3' defined but not used [-Wunused-variable]
static bool chacha20_use_ssse3 __ro_after_init;
^~~~~~~~~~~~~~~~~~
--
In file included from lib/zinc/poly1305/poly1305-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/poly1305/poly1305-x86_64-glue.h:28:13: warning: 'poly1305_use_avx512' defined but not used [-Wunused-variable]
static bool poly1305_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib/zinc/poly1305/poly1305-x86_64-glue.h:27:13: warning: 'poly1305_use_avx2' defined but not used [-Wunused-variable]
static bool poly1305_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib/zinc/poly1305/poly1305-x86_64-glue.h:26:13: warning: 'poly1305_use_avx' defined but not used [-Wunused-variable]
static bool poly1305_use_avx __ro_after_init;
^~~~~~~~~~~~~~~~
--
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:49:41: error: 'NBUGINTS' undeclared here (not in a function)
extern const char * const x86_bug_flags[NBUGINTS*32];
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:196:24: error: 'X86_FEATURE_ALWAYS' undeclared (first use in this function)
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
arch/x86/include/asm/cpufeature.h:196:24: note: each undeclared identifier is reported only once for each function it appears in
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h: In function 'inv_eltfp25519_1w_adx':
>> lib/zinc/curve25519/curve25519-x86_64.h:1543:2: error: implicit declaration of function 'memzero_explicit' [-Werror=implicit-function-declaration]
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h: In function 'curve25519_adx':
>> lib/zinc/curve25519/curve25519-x86_64.h:1706:2: error: implicit declaration of function 'memcpy'; did you mean 'pte_copy'? [-Werror=implicit-function-declaration]
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
pte_copy
In file included from <command-line>:0:0:
lib/zinc/curve25519/curve25519-x86_64-glue.h: At top level:
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:12:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_bmi2 __ro_after_init;
^~~~~~~~~~~~~~~
lib/zinc/curve25519/curve25519-x86_64-glue.h:13:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_adx __ro_after_init;
^~~~~~~~~~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:15:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'curve25519_fpu_init'
void __init curve25519_fpu_init(void)
^~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
lib/zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_arch':
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:23:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:26:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
lib/zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_base_arch':
lib/zinc/curve25519/curve25519-x86_64-glue.h:35:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib/zinc/curve25519/curve25519-x86_64-glue.h:38:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
In file included from arch/x86/include/asm/string.h:5:0,
from include/linux/string.h:20,
from lib/zinc/curve25519/curve25519.c:9:
arch/x86/include/asm/string_64.h: At top level:
>> arch/x86/include/asm/string_64.h:32:14: error: conflicting types for 'memcpy'
extern void *memcpy(void *to, const void *from, size_t len);
^~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h:1706:2: note: previous implicit declaration of 'memcpy' was here
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
In file included from lib/zinc/curve25519/curve25519.c:9:0:
>> include/linux/string.h:216:6: warning: conflicting types for 'memzero_explicit'
void memzero_explicit(void *s, size_t count);
^~~~~~~~~~~~~~~~
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64.h:1543:2: note: previous implicit declaration of 'memzero_explicit' was here
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from lib/zinc/blake2s/blake2s-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib/zinc/blake2s/blake2s-x86_64-glue.h:20:13: warning: 'blake2s_use_avx512' defined but not used [-Wunused-variable]
static bool blake2s_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~
lib/zinc/blake2s/blake2s-x86_64-glue.h:19:13: warning: 'blake2s_use_avx' defined but not used [-Wunused-variable]
static bool blake2s_use_avx __ro_after_init;
^~~~~~~~~~~~~~~
--
In file included from lib//zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib//zinc/chacha20/chacha20-x86_64-glue.h:27:13: warning: 'chacha20_use_avx512vl' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512vl __ro_after_init;
^~~~~~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:26:13: warning: 'chacha20_use_avx512' defined but not used [-Wunused-variable]
static bool chacha20_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:25:13: warning: 'chacha20_use_avx2' defined but not used [-Wunused-variable]
static bool chacha20_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib//zinc/chacha20/chacha20-x86_64-glue.h:24:13: warning: 'chacha20_use_ssse3' defined but not used [-Wunused-variable]
static bool chacha20_use_ssse3 __ro_after_init;
^~~~~~~~~~~~~~~~~~
--
In file included from lib//zinc/poly1305/poly1305-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from <command-line>:0:0:
At top level:
lib//zinc/poly1305/poly1305-x86_64-glue.h:28:13: warning: 'poly1305_use_avx512' defined but not used [-Wunused-variable]
static bool poly1305_use_avx512 __ro_after_init;
^~~~~~~~~~~~~~~~~~~
lib//zinc/poly1305/poly1305-x86_64-glue.h:27:13: warning: 'poly1305_use_avx2' defined but not used [-Wunused-variable]
static bool poly1305_use_avx2 __ro_after_init;
^~~~~~~~~~~~~~~~~
lib//zinc/poly1305/poly1305-x86_64-glue.h:26:13: warning: 'poly1305_use_avx' defined but not used [-Wunused-variable]
static bool poly1305_use_avx __ro_after_init;
^~~~~~~~~~~~~~~~
--
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:49:41: error: 'NBUGINTS' undeclared here (not in a function)
extern const char * const x86_bug_flags[NBUGINTS*32];
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:196:24: error: 'X86_FEATURE_ALWAYS' undeclared (first use in this function)
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
arch/x86/include/asm/cpufeature.h:196:24: note: each undeclared identifier is reported only once for each function it appears in
[always] "i" (X86_FEATURE_ALWAYS),
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h: In function 'inv_eltfp25519_1w_adx':
lib//zinc/curve25519/curve25519-x86_64.h:1543:2: error: implicit declaration of function 'memzero_explicit' [-Werror=implicit-function-declaration]
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h: In function 'curve25519_adx':
lib//zinc/curve25519/curve25519-x86_64.h:1706:2: error: implicit declaration of function 'memcpy'; did you mean 'pte_copy'? [-Werror=implicit-function-declaration]
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
pte_copy
In file included from <command-line>:0:0:
lib//zinc/curve25519/curve25519-x86_64-glue.h: At top level:
lib//zinc/curve25519/curve25519-x86_64-glue.h:12:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_bmi2 __ro_after_init;
^~~~~~~~~~~~~~~
lib//zinc/curve25519/curve25519-x86_64-glue.h:13:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__ro_after_init'
static bool curve25519_use_adx __ro_after_init;
^~~~~~~~~~~~~~~
lib//zinc/curve25519/curve25519-x86_64-glue.h:15:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'curve25519_fpu_init'
void __init curve25519_fpu_init(void)
^~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
lib//zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_arch':
lib//zinc/curve25519/curve25519-x86_64-glue.h:23:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h:26:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_base_arch':
lib//zinc/curve25519/curve25519-x86_64-glue.h:35:6: error: 'curve25519_use_adx' undeclared (first use in this function); did you mean 'curve25519_adx'?
if (curve25519_use_adx) {
^~~~~~~~~~~~~~~~~~
curve25519_adx
lib//zinc/curve25519/curve25519-x86_64-glue.h:38:13: error: 'curve25519_use_bmi2' undeclared (first use in this function); did you mean 'curve25519_use_adx'?
} else if (curve25519_use_bmi2) {
^~~~~~~~~~~~~~~~~~~
curve25519_use_adx
In file included from arch/x86/include/asm/string.h:5:0,
from include/linux/string.h:20,
from lib//zinc/curve25519/curve25519.c:9:
arch/x86/include/asm/string_64.h: At top level:
>> arch/x86/include/asm/string_64.h:32:14: error: conflicting types for 'memcpy'
extern void *memcpy(void *to, const void *from, size_t len);
^~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h:1706:2: note: previous implicit declaration of 'memcpy' was here
memcpy(m.private, private_key, sizeof(m.private));
^~~~~~
In file included from lib//zinc/curve25519/curve25519.c:9:0:
>> include/linux/string.h:216:6: warning: conflicting types for 'memzero_explicit'
void memzero_explicit(void *s, size_t count);
^~~~~~~~~~~~~~~~
In file included from lib//zinc/curve25519/curve25519-x86_64-glue.h:10:0,
from <command-line>:0:
lib//zinc/curve25519/curve25519-x86_64.h:1543:2: note: previous implicit declaration of 'memzero_explicit' was here
memzero_explicit(&m, sizeof(m));
^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
..
vim +/memzero_explicit +1543 lib/zinc/curve25519/curve25519-x86_64.h
468c57c7 Jason A. Donenfeld 2018-08-24 1498
468c57c7 Jason A. Donenfeld 2018-08-24 1499 static void inv_eltfp25519_1w_adx(u64 *const c, const u64 *const a)
468c57c7 Jason A. Donenfeld 2018-08-24 1500 {
468c57c7 Jason A. Donenfeld 2018-08-24 1501 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1502 eltfp25519_1w_buffer buffer;
468c57c7 Jason A. Donenfeld 2018-08-24 1503 eltfp25519_1w x0, x1, x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1504 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1505 u64 *T[4];
468c57c7 Jason A. Donenfeld 2018-08-24 1506
468c57c7 Jason A. Donenfeld 2018-08-24 1507 T[0] = m.x0;
468c57c7 Jason A. Donenfeld 2018-08-24 1508 T[1] = c; /* x^(-1) */
468c57c7 Jason A. Donenfeld 2018-08-24 1509 T[2] = m.x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1510 T[3] = m.x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1511
468c57c7 Jason A. Donenfeld 2018-08-24 1512 copy_eltfp25519_1w(T[1], a);
468c57c7 Jason A. Donenfeld 2018-08-24 1513 sqrn_eltfp25519_1w_adx(T[1], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1514 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1515 sqrn_eltfp25519_1w_adx(T[2], 2);
468c57c7 Jason A. Donenfeld 2018-08-24 1516 mul_eltfp25519_1w_adx(T[0], a, T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1517 mul_eltfp25519_1w_adx(T[1], T[1], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1518 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1519 sqrn_eltfp25519_1w_adx(T[2], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1520 mul_eltfp25519_1w_adx(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1521 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1522 sqrn_eltfp25519_1w_adx(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1523 mul_eltfp25519_1w_adx(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1524 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1525 sqrn_eltfp25519_1w_adx(T[2], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1526 mul_eltfp25519_1w_adx(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1527 copy_eltfp25519_1w(T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1528 sqrn_eltfp25519_1w_adx(T[3], 20);
468c57c7 Jason A. Donenfeld 2018-08-24 1529 mul_eltfp25519_1w_adx(T[3], T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1530 sqrn_eltfp25519_1w_adx(T[3], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1531 mul_eltfp25519_1w_adx(T[3], T[3], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1532 copy_eltfp25519_1w(T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1533 sqrn_eltfp25519_1w_adx(T[0], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1534 mul_eltfp25519_1w_adx(T[0], T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1535 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1536 sqrn_eltfp25519_1w_adx(T[2], 100);
468c57c7 Jason A. Donenfeld 2018-08-24 1537 mul_eltfp25519_1w_adx(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1538 sqrn_eltfp25519_1w_adx(T[2], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1539 mul_eltfp25519_1w_adx(T[2], T[2], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1540 sqrn_eltfp25519_1w_adx(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1541 mul_eltfp25519_1w_adx(T[1], T[1], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1542
468c57c7 Jason A. Donenfeld 2018-08-24 @1543 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1544 }
468c57c7 Jason A. Donenfeld 2018-08-24 1545
468c57c7 Jason A. Donenfeld 2018-08-24 1546 static void inv_eltfp25519_1w_bmi2(u64 *const c, const u64 *const a)
468c57c7 Jason A. Donenfeld 2018-08-24 1547 {
468c57c7 Jason A. Donenfeld 2018-08-24 1548 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1549 eltfp25519_1w_buffer buffer;
468c57c7 Jason A. Donenfeld 2018-08-24 1550 eltfp25519_1w x0, x1, x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1551 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1552 u64 *T[5];
468c57c7 Jason A. Donenfeld 2018-08-24 1553
468c57c7 Jason A. Donenfeld 2018-08-24 1554 T[0] = m.x0;
468c57c7 Jason A. Donenfeld 2018-08-24 1555 T[1] = c; /* x^(-1) */
468c57c7 Jason A. Donenfeld 2018-08-24 1556 T[2] = m.x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1557 T[3] = m.x2;
468c57c7 Jason A. Donenfeld 2018-08-24 1558
468c57c7 Jason A. Donenfeld 2018-08-24 1559 copy_eltfp25519_1w(T[1], a);
468c57c7 Jason A. Donenfeld 2018-08-24 1560 sqrn_eltfp25519_1w_bmi2(T[1], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1561 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1562 sqrn_eltfp25519_1w_bmi2(T[2], 2);
468c57c7 Jason A. Donenfeld 2018-08-24 1563 mul_eltfp25519_1w_bmi2(T[0], a, T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1564 mul_eltfp25519_1w_bmi2(T[1], T[1], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1565 copy_eltfp25519_1w(T[2], T[1]);
468c57c7 Jason A. Donenfeld 2018-08-24 1566 sqrn_eltfp25519_1w_bmi2(T[2], 1);
468c57c7 Jason A. Donenfeld 2018-08-24 1567 mul_eltfp25519_1w_bmi2(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1568 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1569 sqrn_eltfp25519_1w_bmi2(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1570 mul_eltfp25519_1w_bmi2(T[0], T[0], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1571 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1572 sqrn_eltfp25519_1w_bmi2(T[2], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1573 mul_eltfp25519_1w_bmi2(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1574 copy_eltfp25519_1w(T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1575 sqrn_eltfp25519_1w_bmi2(T[3], 20);
468c57c7 Jason A. Donenfeld 2018-08-24 1576 mul_eltfp25519_1w_bmi2(T[3], T[3], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1577 sqrn_eltfp25519_1w_bmi2(T[3], 10);
468c57c7 Jason A. Donenfeld 2018-08-24 1578 mul_eltfp25519_1w_bmi2(T[3], T[3], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1579 copy_eltfp25519_1w(T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1580 sqrn_eltfp25519_1w_bmi2(T[0], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1581 mul_eltfp25519_1w_bmi2(T[0], T[0], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1582 copy_eltfp25519_1w(T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1583 sqrn_eltfp25519_1w_bmi2(T[2], 100);
468c57c7 Jason A. Donenfeld 2018-08-24 1584 mul_eltfp25519_1w_bmi2(T[2], T[2], T[0]);
468c57c7 Jason A. Donenfeld 2018-08-24 1585 sqrn_eltfp25519_1w_bmi2(T[2], 50);
468c57c7 Jason A. Donenfeld 2018-08-24 1586 mul_eltfp25519_1w_bmi2(T[2], T[2], T[3]);
468c57c7 Jason A. Donenfeld 2018-08-24 1587 sqrn_eltfp25519_1w_bmi2(T[2], 5);
468c57c7 Jason A. Donenfeld 2018-08-24 1588 mul_eltfp25519_1w_bmi2(T[1], T[1], T[2]);
468c57c7 Jason A. Donenfeld 2018-08-24 1589
468c57c7 Jason A. Donenfeld 2018-08-24 1590 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1591 }
468c57c7 Jason A. Donenfeld 2018-08-24 1592
468c57c7 Jason A. Donenfeld 2018-08-24 1593 /* Given c, a 256-bit number, fred_eltfp25519_1w updates c
468c57c7 Jason A. Donenfeld 2018-08-24 1594 * with a number such that 0 <= C < 2**255-19.
468c57c7 Jason A. Donenfeld 2018-08-24 1595 */
468c57c7 Jason A. Donenfeld 2018-08-24 1596 static __always_inline void fred_eltfp25519_1w(u64 *const c)
468c57c7 Jason A. Donenfeld 2018-08-24 1597 {
468c57c7 Jason A. Donenfeld 2018-08-24 1598 u64 tmp0 = 38, tmp1 = 19;
468c57c7 Jason A. Donenfeld 2018-08-24 1599 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1600 "btrq $63, %3 ;" /* Put bit 255 in carry flag and clear */
468c57c7 Jason A. Donenfeld 2018-08-24 1601 "cmovncl %k5, %k4 ;" /* c[255] ? 38 : 19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1602
468c57c7 Jason A. Donenfeld 2018-08-24 1603 /* Add either 19 or 38 to c */
468c57c7 Jason A. Donenfeld 2018-08-24 1604 "addq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1605 "adcq $0, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1606 "adcq $0, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1607 "adcq $0, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1608
468c57c7 Jason A. Donenfeld 2018-08-24 1609 /* Test for bit 255 again; only triggered on overflow modulo 2^255-19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1610 "movl $0, %k4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1611 "cmovnsl %k5, %k4 ;" /* c[255] ? 0 : 19 */
468c57c7 Jason A. Donenfeld 2018-08-24 1612 "btrq $63, %3 ;" /* Clear bit 255 */
468c57c7 Jason A. Donenfeld 2018-08-24 1613
468c57c7 Jason A. Donenfeld 2018-08-24 1614 /* Subtract 19 if necessary */
468c57c7 Jason A. Donenfeld 2018-08-24 1615 "subq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1616 "sbbq $0, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1617 "sbbq $0, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1618 "sbbq $0, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1619
468c57c7 Jason A. Donenfeld 2018-08-24 1620 : "+r"(c[0]), "+r"(c[1]), "+r"(c[2]), "+r"(c[3]), "+r"(tmp0), "+r"(tmp1)
468c57c7 Jason A. Donenfeld 2018-08-24 1621 :
468c57c7 Jason A. Donenfeld 2018-08-24 1622 : "memory", "cc");
468c57c7 Jason A. Donenfeld 2018-08-24 1623 }
468c57c7 Jason A. Donenfeld 2018-08-24 1624
468c57c7 Jason A. Donenfeld 2018-08-24 1625 static __always_inline void cswap(u8 bit, u64 *const px, u64 *const py)
468c57c7 Jason A. Donenfeld 2018-08-24 1626 {
468c57c7 Jason A. Donenfeld 2018-08-24 1627 u64 temp;
468c57c7 Jason A. Donenfeld 2018-08-24 1628 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1629 "test %9, %9 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1630 "movq %0, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1631 "cmovnzq %4, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1632 "cmovnzq %8, %4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1633 "movq %1, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1634 "cmovnzq %5, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1635 "cmovnzq %8, %5 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1636 "movq %2, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1637 "cmovnzq %6, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1638 "cmovnzq %8, %6 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1639 "movq %3, %8 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1640 "cmovnzq %7, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1641 "cmovnzq %8, %7 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1642 : "+r"(px[0]), "+r"(px[1]), "+r"(px[2]), "+r"(px[3]),
468c57c7 Jason A. Donenfeld 2018-08-24 1643 "+r"(py[0]), "+r"(py[1]), "+r"(py[2]), "+r"(py[3]),
468c57c7 Jason A. Donenfeld 2018-08-24 1644 "=r"(temp)
468c57c7 Jason A. Donenfeld 2018-08-24 1645 : "r"(bit)
468c57c7 Jason A. Donenfeld 2018-08-24 1646 : "cc"
468c57c7 Jason A. Donenfeld 2018-08-24 1647 );
468c57c7 Jason A. Donenfeld 2018-08-24 1648 }
468c57c7 Jason A. Donenfeld 2018-08-24 1649
468c57c7 Jason A. Donenfeld 2018-08-24 1650 static __always_inline void cselect(u8 bit, u64 *const px, const u64 *const py)
468c57c7 Jason A. Donenfeld 2018-08-24 1651 {
468c57c7 Jason A. Donenfeld 2018-08-24 1652 asm volatile(
468c57c7 Jason A. Donenfeld 2018-08-24 1653 "test %4, %4 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1654 "cmovnzq %5, %0 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1655 "cmovnzq %6, %1 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1656 "cmovnzq %7, %2 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1657 "cmovnzq %8, %3 ;"
468c57c7 Jason A. Donenfeld 2018-08-24 1658 : "+r"(px[0]), "+r"(px[1]), "+r"(px[2]), "+r"(px[3])
468c57c7 Jason A. Donenfeld 2018-08-24 1659 : "r"(bit), "rm"(py[0]), "rm"(py[1]), "rm"(py[2]), "rm"(py[3])
468c57c7 Jason A. Donenfeld 2018-08-24 1660 : "cc"
468c57c7 Jason A. Donenfeld 2018-08-24 1661 );
468c57c7 Jason A. Donenfeld 2018-08-24 1662 }
468c57c7 Jason A. Donenfeld 2018-08-24 1663
468c57c7 Jason A. Donenfeld 2018-08-24 1664 static __always_inline void clamp_secret(u8 secret[CURVE25519_POINT_SIZE])
468c57c7 Jason A. Donenfeld 2018-08-24 1665 {
468c57c7 Jason A. Donenfeld 2018-08-24 1666 secret[0] &= 248;
468c57c7 Jason A. Donenfeld 2018-08-24 1667 secret[31] &= 127;
468c57c7 Jason A. Donenfeld 2018-08-24 1668 secret[31] |= 64;
468c57c7 Jason A. Donenfeld 2018-08-24 1669 }
468c57c7 Jason A. Donenfeld 2018-08-24 1670
468c57c7 Jason A. Donenfeld 2018-08-24 1671 static void curve25519_adx(u8 shared[CURVE25519_POINT_SIZE], const u8 private_key[CURVE25519_POINT_SIZE], const u8 session_key[CURVE25519_POINT_SIZE])
468c57c7 Jason A. Donenfeld 2018-08-24 1672 {
468c57c7 Jason A. Donenfeld 2018-08-24 1673 struct {
468c57c7 Jason A. Donenfeld 2018-08-24 1674 u64 buffer[4 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1675 u64 coordinates[4 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1676 u64 workspace[6 * NUM_WORDS_ELTFP25519];
468c57c7 Jason A. Donenfeld 2018-08-24 1677 u8 session[CURVE25519_POINT_SIZE];
468c57c7 Jason A. Donenfeld 2018-08-24 1678 u8 private[CURVE25519_POINT_SIZE];
468c57c7 Jason A. Donenfeld 2018-08-24 1679 } __aligned(32) m;
468c57c7 Jason A. Donenfeld 2018-08-24 1680
468c57c7 Jason A. Donenfeld 2018-08-24 1681 int i = 0, j = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1682 u64 prev = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1683 u64 *const X1 = (u64 *)m.session;
468c57c7 Jason A. Donenfeld 2018-08-24 1684 u64 *const key = (u64 *)m.private;
468c57c7 Jason A. Donenfeld 2018-08-24 1685 u64 *const Px = m.coordinates + 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1686 u64 *const Pz = m.coordinates + 4;
468c57c7 Jason A. Donenfeld 2018-08-24 1687 u64 *const Qx = m.coordinates + 8;
468c57c7 Jason A. Donenfeld 2018-08-24 1688 u64 *const Qz = m.coordinates + 12;
468c57c7 Jason A. Donenfeld 2018-08-24 1689 u64 *const X2 = Qx;
468c57c7 Jason A. Donenfeld 2018-08-24 1690 u64 *const Z2 = Qz;
468c57c7 Jason A. Donenfeld 2018-08-24 1691 u64 *const X3 = Px;
468c57c7 Jason A. Donenfeld 2018-08-24 1692 u64 *const Z3 = Pz;
468c57c7 Jason A. Donenfeld 2018-08-24 1693 u64 *const X2Z2 = Qx;
468c57c7 Jason A. Donenfeld 2018-08-24 1694 u64 *const X3Z3 = Px;
468c57c7 Jason A. Donenfeld 2018-08-24 1695
468c57c7 Jason A. Donenfeld 2018-08-24 1696 u64 *const A = m.workspace + 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1697 u64 *const B = m.workspace + 4;
468c57c7 Jason A. Donenfeld 2018-08-24 1698 u64 *const D = m.workspace + 8;
468c57c7 Jason A. Donenfeld 2018-08-24 1699 u64 *const C = m.workspace + 12;
468c57c7 Jason A. Donenfeld 2018-08-24 1700 u64 *const DA = m.workspace + 16;
468c57c7 Jason A. Donenfeld 2018-08-24 1701 u64 *const CB = m.workspace + 20;
468c57c7 Jason A. Donenfeld 2018-08-24 1702 u64 *const AB = A;
468c57c7 Jason A. Donenfeld 2018-08-24 1703 u64 *const DC = D;
468c57c7 Jason A. Donenfeld 2018-08-24 1704 u64 *const DACB = DA;
468c57c7 Jason A. Donenfeld 2018-08-24 1705
468c57c7 Jason A. Donenfeld 2018-08-24 @1706 memcpy(m.private, private_key, sizeof(m.private));
468c57c7 Jason A. Donenfeld 2018-08-24 1707 memcpy(m.session, session_key, sizeof(m.session));
468c57c7 Jason A. Donenfeld 2018-08-24 1708
468c57c7 Jason A. Donenfeld 2018-08-24 1709 clamp_secret(m.private);
468c57c7 Jason A. Donenfeld 2018-08-24 1710
468c57c7 Jason A. Donenfeld 2018-08-24 1711 /* As in the draft:
468c57c7 Jason A. Donenfeld 2018-08-24 1712 * When receiving such an array, implementations of curve25519
468c57c7 Jason A. Donenfeld 2018-08-24 1713 * MUST mask the most-significant bit in the final byte. This
468c57c7 Jason A. Donenfeld 2018-08-24 1714 * is done to preserve compatibility with point formats which
468c57c7 Jason A. Donenfeld 2018-08-24 1715 * reserve the sign bit for use in other protocols and to
468c57c7 Jason A. Donenfeld 2018-08-24 1716 * increase resistance to implementation fingerprinting
468c57c7 Jason A. Donenfeld 2018-08-24 1717 */
468c57c7 Jason A. Donenfeld 2018-08-24 1718 m.session[CURVE25519_POINT_SIZE - 1] &= (1 << (255 % 8)) - 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1719
468c57c7 Jason A. Donenfeld 2018-08-24 1720 copy_eltfp25519_1w(Px, X1);
468c57c7 Jason A. Donenfeld 2018-08-24 1721 setzero_eltfp25519_1w(Pz);
468c57c7 Jason A. Donenfeld 2018-08-24 1722 setzero_eltfp25519_1w(Qx);
468c57c7 Jason A. Donenfeld 2018-08-24 1723 setzero_eltfp25519_1w(Qz);
468c57c7 Jason A. Donenfeld 2018-08-24 1724
468c57c7 Jason A. Donenfeld 2018-08-24 1725 Pz[0] = 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1726 Qx[0] = 1;
468c57c7 Jason A. Donenfeld 2018-08-24 1727
468c57c7 Jason A. Donenfeld 2018-08-24 1728 /* main-loop */
468c57c7 Jason A. Donenfeld 2018-08-24 1729 prev = 0;
468c57c7 Jason A. Donenfeld 2018-08-24 1730 j = 62;
468c57c7 Jason A. Donenfeld 2018-08-24 1731 for (i = 3; i >= 0; --i) {
468c57c7 Jason A. Donenfeld 2018-08-24 1732 while (j >= 0) {
468c57c7 Jason A. Donenfeld 2018-08-24 1733 u64 bit = (key[i] >> j) & 0x1;
468c57c7 Jason A. Donenfeld 2018-08-24 1734 u64 swap = bit ^ prev;
468c57c7 Jason A. Donenfeld 2018-08-24 1735 prev = bit;
468c57c7 Jason A. Donenfeld 2018-08-24 1736
468c57c7 Jason A. Donenfeld 2018-08-24 1737 add_eltfp25519_1w_adx(A, X2, Z2); /* A = (X2+Z2) */
468c57c7 Jason A. Donenfeld 2018-08-24 1738 sub_eltfp25519_1w(B, X2, Z2); /* B = (X2-Z2) */
468c57c7 Jason A. Donenfeld 2018-08-24 1739 add_eltfp25519_1w_adx(C, X3, Z3); /* C = (X3+Z3) */
468c57c7 Jason A. Donenfeld 2018-08-24 1740 sub_eltfp25519_1w(D, X3, Z3); /* D = (X3-Z3) */
468c57c7 Jason A. Donenfeld 2018-08-24 1741 mul_eltfp25519_2w_adx(DACB, AB, DC); /* [DA|CB] = [A|B]*[D|C] */
468c57c7 Jason A. Donenfeld 2018-08-24 1742
468c57c7 Jason A. Donenfeld 2018-08-24 1743 cselect(swap, A, C);
468c57c7 Jason A. Donenfeld 2018-08-24 1744 cselect(swap, B, D);
468c57c7 Jason A. Donenfeld 2018-08-24 1745
468c57c7 Jason A. Donenfeld 2018-08-24 1746 sqr_eltfp25519_2w_adx(AB); /* [AA|BB] = [A^2|B^2] */
468c57c7 Jason A. Donenfeld 2018-08-24 1747 add_eltfp25519_1w_adx(X3, DA, CB); /* X3 = (DA+CB) */
468c57c7 Jason A. Donenfeld 2018-08-24 1748 sub_eltfp25519_1w(Z3, DA, CB); /* Z3 = (DA-CB) */
468c57c7 Jason A. Donenfeld 2018-08-24 1749 sqr_eltfp25519_2w_adx(X3Z3); /* [X3|Z3] = [(DA+CB)|(DA+CB)]^2 */
468c57c7 Jason A. Donenfeld 2018-08-24 1750
468c57c7 Jason A. Donenfeld 2018-08-24 1751 copy_eltfp25519_1w(X2, B); /* X2 = B^2 */
468c57c7 Jason A. Donenfeld 2018-08-24 1752 sub_eltfp25519_1w(Z2, A, B); /* Z2 = E = AA-BB */
468c57c7 Jason A. Donenfeld 2018-08-24 1753
468c57c7 Jason A. Donenfeld 2018-08-24 1754 mul_a24_eltfp25519_1w(B, Z2); /* B = a24*E */
468c57c7 Jason A. Donenfeld 2018-08-24 1755 add_eltfp25519_1w_adx(B, B, X2); /* B = a24*E+B */
468c57c7 Jason A. Donenfeld 2018-08-24 1756 mul_eltfp25519_2w_adx(X2Z2, X2Z2, AB); /* [X2|Z2] = [B|E]*[A|a24*E+B] */
468c57c7 Jason A. Donenfeld 2018-08-24 1757 mul_eltfp25519_1w_adx(Z3, Z3, X1); /* Z3 = Z3*X1 */
468c57c7 Jason A. Donenfeld 2018-08-24 1758 --j;
468c57c7 Jason A. Donenfeld 2018-08-24 1759 }
468c57c7 Jason A. Donenfeld 2018-08-24 1760 j = 63;
468c57c7 Jason A. Donenfeld 2018-08-24 1761 }
468c57c7 Jason A. Donenfeld 2018-08-24 1762
468c57c7 Jason A. Donenfeld 2018-08-24 1763 inv_eltfp25519_1w_adx(A, Qz);
468c57c7 Jason A. Donenfeld 2018-08-24 1764 mul_eltfp25519_1w_adx((u64 *)shared, Qx, A);
468c57c7 Jason A. Donenfeld 2018-08-24 1765 fred_eltfp25519_1w((u64 *)shared);
468c57c7 Jason A. Donenfeld 2018-08-24 1766
468c57c7 Jason A. Donenfeld 2018-08-24 1767 memzero_explicit(&m, sizeof(m));
468c57c7 Jason A. Donenfeld 2018-08-24 1768 }
468c57c7 Jason A. Donenfeld 2018-08-24 1769
:::::: The code at line 1543 was first introduced by commit
:::::: 468c57c74ac7091c9c04ab2acccf68fe300cd9bc zinc: Curve25519 x86_64 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
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20207 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-08-27 12:55 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Chris Paterson, Wolfgang Grandegger, Marc Kleine-Budde,
Rob Herring, Mark Rutland, David S. Miller,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Biju Das,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <TY1PR01MB177055864EEAD487C2917860C0360@TY1PR01MB1770.jpnprd01.prod.outlook.com>
On Fri, Aug 24, 2018 at 08:31:42AM +0000, Fabrizio Castro wrote:
> Hello Simon,
>
> Thank you for the feedback!
>
> > >
> > > In theory CAN could be broken if renesas,can-clock-select is set to 0x1
> > > (clkp2) in the DT, as this value will be written to the CAN Clock Select
> > > Register. However if the documentation is followed there will be no
> > > problems.
> > >
> > > We should probably update the driver to fix this though, which will be a
> > > change specific to all RZ/G2 devices, so perhaps we should also be adding
> > > a "renesas,rzg-gen2-can" family compatible string as well? (to driver and
> > > documentation)
> >
> > Yes, I think that sounds reasonable.
> >
> > But in that case we should pre-emptively not use renesas,rcar-gen3-can for
> > RZ/G2.
>
> What do you think about the following:
> https://patchwork.kernel.org/patch/10573795/
> https://patchwork.kernel.org/patch/10573791/
> https://patchwork.kernel.org/patch/10573805/
I think that is the right approach.
^ permalink raw reply
* Re: [PATCH v2 01/29] nvmem: add support for cell lookups
From: Bartosz Golaszewski @ 2018-08-27 13:37 UTC (permalink / raw)
To: Boris Brezillon
Cc: Andrew Lunn, linux-doc, Sekhar Nori, Bartosz Golaszewski,
Srinivas Kandagatla, linux-i2c, Mauro Carvalho Chehab,
Rob Herring, Florian Fainelli, Kevin Hilman, Richard Weinberger,
Russell King, Marek Vasut, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, "ope
In-Reply-To: <20180827110055.122988d0@bbrezillon>
2018-08-27 11:00 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> On Mon, 27 Aug 2018 10:56:29 +0200
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
>> 2018-08-25 8:27 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
>> > On Fri, 24 Aug 2018 17:27:40 +0200
>> > Andrew Lunn <andrew@lunn.ch> wrote:
>> >
>> >> On Fri, Aug 24, 2018 at 05:08:48PM +0200, Boris Brezillon wrote:
>> >> > Hi Bartosz,
>> >> >
>> >> > On Fri, 10 Aug 2018 10:04:58 +0200
>> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> >> >
>> >> > > +struct nvmem_cell_lookup {
>> >> > > + struct nvmem_cell_info info;
>> >> > > + struct list_head list;
>> >> > > + const char *nvmem_name;
>> >> > > +};
>> >> >
>> >> > Hm, maybe I don't get it right, but this looks suspicious. Usually the
>> >> > consumer lookup table is here to attach device specific names to
>> >> > external resources.
>> >> >
>> >> > So what I'd expect here is:
>> >> >
>> >> > struct nvmem_cell_lookup {
>> >> > /* The nvmem device name. */
>> >> > const char *nvmem_name;
>> >> >
>> >> > /* The nvmem cell name */
>> >> > const char *nvmem_cell_name;
>> >> >
>> >> > /*
>> >> > * The local resource name. Basically what you have in the
>> >> > * nvmem-cell-names prop.
>> >> > */
>> >> > const char *conid;
>> >> > };
>> >> >
>> >> > struct nvmem_cell_lookup_table {
>> >> > struct list_head list;
>> >> >
>> >> > /* ID of the consumer device. */
>> >> > const char *devid;
>> >> >
>> >> > /* Array of cell lookup entries. */
>> >> > unsigned int ncells;
>> >> > const struct nvmem_cell_lookup *cells;
>> >> > };
>> >> >
>> >> > Looks like your nvmem_cell_lookup is more something used to attach cells
>> >> > to an nvmem device, which is NVMEM provider's responsibility not the
>> >> > consumer one.
>> >>
>> >> Hi Boris
>> >>
>> >> There are cases where there is not a clear providier/consumer split. I
>> >> have an x86 platform, with a few at24 EEPROMs on it. It uses an off
>> >> the shelf Komtron module, placed on a custom carrier board. One of the
>> >> EEPROMs contains the hardware variant information. Once i know the
>> >> variant, i need to instantiate other I2C, SPI, MDIO devices, all using
>> >> platform devices, since this is x86, no DT available.
>> >>
>> >> So the first thing my x86 platform device does is instantiate the
>> >> first i2c device for the AT24. Once the EEPROM pops into existence, i
>> >> need to add nvmem cells onto it. So at that point, the x86 platform
>> >> driver is playing the provider role. Once the cells are added, i can
>> >> then use nvmem consumer interfaces to get the contents of the cell,
>> >> run a checksum, and instantiate the other devices.
>> >>
>> >> I wish the embedded world was all DT, but the reality is that it is
>> >> not :-(
>> >
>> > Actually, I'm not questioning the need for this feature (being able to
>> > attach NVMEM cells to an NVMEM device on a platform that does not use
>> > DT). What I'm saying is that this functionality is provider related,
>> > not consumer related. Also, I wonder if defining such NVMEM cells
>> > shouldn't go through the provider driver instead of being passed
>> > directly to the NVMEM layer, because nvmem_config already have a fields
>> > to pass cells at registration time, plus, the name of the NVMEM cell
>> > device is sometimes created dynamically and can be hard to guess at
>> > platform_device registration time.
>> >
>>
>> In my use case the provider is at24 EEPROM driver. This is where the
>> nvmem_config lives but I can't image a correct and clean way of
>> passing this cell config to the driver from board files without using
>> new ugly fields in platform_data which this very series is trying to
>> remove. This is why this cell config should live in machine code.
>
> Okay.
>
>>
>> > I also think non-DT consumers will need a way to reference exiting
>> > NVMEM cells, but this consumer-oriented nvmem cell lookup table should
>> > look like the gpio or pwm lookup table (basically what I proposed in my
>> > previous email).
>>
>> How about introducing two new interfaces to nvmem: one for defining
>> nvmem cells from machine code and the second for connecting these
>> cells with devices?
>
> Yes, that's basically what I was suggesting: move what you've done in
> nvmem-provider.h (maybe rename some of the structs to make it clear
> that this is about defining cells not referencing existing ones), and
> add a new consumer interface (based on what other subsystems do) in
> nvmem-consumer.h.
>
> This way you have both things clearly separated, and if a driver is
> both a consumer and a provider you'll just have to include both headers.
>
> Regards,
>
> Boris
I didn't notice it before but there's a global list of nvmem cells
with each cell referencing its owner nvmem device. I'm wondering if
this isn't some kind of inversion of ownership. Shouldn't each nvmem
device have a separate list of nvmem cells owned by it? What happens
if we have two nvmem providers with the same names for cells? I'm
asking because dev_id based lookup doesn't make sense if internally
nvmem_cell_get_from_list() doesn't care about any device names (takes
only the cell_id as argument).
This doesn't cause any trouble now since there are no users defining
cells in nvmem_config - there are only DT users - but this must be
clarified before I can advance with correctly implementing nvmem
lookups.
BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
instance even if the cell for this node was already added to the nvmem
device.
Bart
^ permalink raw reply
* Re: [PATCH] net: mvpp2: avoid bouncing buffers
From: Brian Brooks @ 2018-08-27 13:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Miller, antoine.tenart, maxime.chevallier, ymarkman,
stefanc, netdev, linux-kernel, bjorn.topel, brian.brooks
In-Reply-To: <20180820062326.GA22222@infradead.org>
On 08/19 23:23:26, Christoph Hellwig wrote:
> On Sun, Aug 19, 2018 at 07:55:05PM -0700, David Miller wrote:
> > From: Brian Brooks <brian.brooks@linaro.org>
> > Date: Sun, 19 Aug 2018 21:47:30 -0500
> >
> > > @@ -5126,6 +5126,12 @@ static int mvpp2_probe(struct platform_device *pdev)
> > > }
> > >
> > > if (priv->hw_version == MVPP22) {
> > > + /* Platform code may have set dev->dma_mask to point
> > > + * to dev->coherent_dma_mask, but we want to ensure
> > > + * they take different values due to comment below.
> > > + */
> > > + pdev->dev.dma_mask = &priv->dma_mask;
> >
> > The platform code might be doing this exactly because it cannot support
> > different coherent and streaming DMA masks.
> >
> > Well, in any case, the platform code is doing it for a reason and
> > overriding this in a "driver" of all places seems totally
> > inappropriate and at best a layering violation.
> >
> > I would rather you fix this in a way that involves well defined APIs
> > that set the DMA masks or whatever to the values that you need, rather
> > than going behind the platform code's back and changing the DMA mask
> > pointer like this.
>
> Agreed. What platform do you see this issue on?
This is Armada 8040 SoC with PPv2 net device on chip. MACCHIATObin board.
Both DT and ACPI have the following snippet:
/*
* Set default coherent_dma_mask to 32 bit. Drivers are expected to
* setup the correct supported mask.
*/
if (!dev->coherent_dma_mask)
dev->coherent_dma_mask = DMA_BIT_MASK(32);
/*
* Set it to coherent_dma_mask by default if the architecture
* code has not set it.
*/
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
Some architectures code setup DMA masks, but it does not seem appropriate
to add mvpp2 specific code in arch/arm64. The mvpp2 driver appeared to be
the least invasive place to resolve the limitation of this net device.
Another DMA API could be added to allocate storage for the streaming
mask to ensure masks can take on separate values when the existing DMA
APIs are used by the driver to set those values. But, this would be the
only driver using such API. Would that be how to handle this?
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: Michael S. Tsirkin @ 2018-08-27 14:00 UTC (permalink / raw)
To: Tiwei Bie
Cc: jasowang, virtualization, linux-kernel, netdev, virtio-dev, wexu,
jfreimann
In-Reply-To: <20180711022711.7090-1-tiwei.bie@intel.com>
Are there still plans to test the performance with vost pmd?
vhost doesn't seem to show a performance gain ...
On Wed, Jul 11, 2018 at 10:27:06AM +0800, Tiwei Bie wrote:
> Hello everyone,
>
> This patch set implements packed ring support in virtio driver.
>
> Some functional tests have been done with Jason's
> packed ring implementation in vhost:
>
> https://lkml.org/lkml/2018/7/3/33
>
> Both of ping and netperf worked as expected.
>
> v1 -> v2:
> - Use READ_ONCE() to read event off_wrap and flags together (Jason);
> - Add comments related to ccw (Jason);
>
> RFC (v6) -> v1:
> - Avoid extra virtio_wmb() in virtqueue_enable_cb_delayed_packed()
> when event idx is off (Jason);
> - Fix bufs calculation in virtqueue_enable_cb_delayed_packed() (Jason);
> - Test the state of the desc at used_idx instead of last_used_idx
> in virtqueue_enable_cb_delayed_packed() (Jason);
> - Save wrap counter (as part of queue state) in the return value
> of virtqueue_enable_cb_prepare_packed();
> - Refine the packed ring definitions in uapi;
> - Rebase on the net-next tree;
>
> RFC v5 -> RFC v6:
> - Avoid tracking addr/len/flags when DMA API isn't used (MST/Jason);
> - Define wrap counter as bool (Jason);
> - Use ALIGN() in vring_init_packed() (Jason);
> - Avoid using pointer to track `next` in detach_buf_packed() (Jason);
> - Add comments for barriers (Jason);
> - Don't enable RING_PACKED on ccw for now (noticed by Jason);
> - Refine the memory barrier in virtqueue_poll();
> - Add a missing memory barrier in virtqueue_enable_cb_delayed_packed();
> - Remove the hacks in virtqueue_enable_cb_prepare_packed();
>
> RFC v4 -> RFC v5:
> - Save DMA addr, etc in desc state (Jason);
> - Track used wrap counter;
>
> RFC v3 -> RFC v4:
> - Make ID allocation support out-of-order (Jason);
> - Various fixes for EVENT_IDX support;
>
> RFC v2 -> RFC v3:
> - Split into small patches (Jason);
> - Add helper virtqueue_use_indirect() (Jason);
> - Just set id for the last descriptor of a list (Jason);
> - Calculate the prev in virtqueue_add_packed() (Jason);
> - Fix/improve desc suppression code (Jason/MST);
> - Refine the code layout for XXX_split/packed and wrappers (MST);
> - Fix the comments and API in uapi (MST);
> - Remove the BUG_ON() for indirect (Jason);
> - Some other refinements and bug fixes;
>
> RFC v1 -> RFC v2:
> - Add indirect descriptor support - compile test only;
> - Add event suppression supprt - compile test only;
> - Move vring_packed_init() out of uapi (Jason, MST);
> - Merge two loops into one in virtqueue_add_packed() (Jason);
> - Split vring_unmap_one() for packed ring and split ring (Jason);
> - Avoid using '%' operator (Jason);
> - Rename free_head -> next_avail_idx (Jason);
> - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
> - Some other refinements and bug fixes;
>
> Thanks!
>
> Tiwei Bie (5):
> virtio: add packed ring definitions
> virtio_ring: support creating packed ring
> virtio_ring: add packed ring support
> virtio_ring: add event idx support in packed ring
> virtio_ring: enable packed ring
>
> drivers/s390/virtio/virtio_ccw.c | 14 +
> drivers/virtio/virtio_ring.c | 1365 ++++++++++++++++++++++------
> include/linux/virtio_ring.h | 8 +-
> include/uapi/linux/virtio_config.h | 3 +
> include/uapi/linux/virtio_ring.h | 43 +
> 5 files changed, 1157 insertions(+), 276 deletions(-)
>
> --
> 2.18.0
^ permalink raw reply
* Re: [PATCH v2 01/29] nvmem: add support for cell lookups
From: Boris Brezillon @ 2018-08-27 14:01 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andrew Lunn, linux-doc, Sekhar Nori, Bartosz Golaszewski,
Srinivas Kandagatla, linux-i2c, Mauro Carvalho Chehab,
Rob Herring, Florian Fainelli, Kevin Hilman, Richard Weinberger,
Russell King, Marek Vasut, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, "ope
In-Reply-To: <CAMRc=MfpZJUEAhM4OoLbmJcnX3rTJk8fvdiL6=9BjNkVcsf=SA@mail.gmail.com>
On Mon, 27 Aug 2018 15:37:23 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2018-08-27 11:00 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> > On Mon, 27 Aug 2018 10:56:29 +0200
> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> >> 2018-08-25 8:27 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> >> > On Fri, 24 Aug 2018 17:27:40 +0200
> >> > Andrew Lunn <andrew@lunn.ch> wrote:
> >> >
> >> >> On Fri, Aug 24, 2018 at 05:08:48PM +0200, Boris Brezillon wrote:
> >> >> > Hi Bartosz,
> >> >> >
> >> >> > On Fri, 10 Aug 2018 10:04:58 +0200
> >> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >> >> >
> >> >> > > +struct nvmem_cell_lookup {
> >> >> > > + struct nvmem_cell_info info;
> >> >> > > + struct list_head list;
> >> >> > > + const char *nvmem_name;
> >> >> > > +};
> >> >> >
> >> >> > Hm, maybe I don't get it right, but this looks suspicious. Usually the
> >> >> > consumer lookup table is here to attach device specific names to
> >> >> > external resources.
> >> >> >
> >> >> > So what I'd expect here is:
> >> >> >
> >> >> > struct nvmem_cell_lookup {
> >> >> > /* The nvmem device name. */
> >> >> > const char *nvmem_name;
> >> >> >
> >> >> > /* The nvmem cell name */
> >> >> > const char *nvmem_cell_name;
> >> >> >
> >> >> > /*
> >> >> > * The local resource name. Basically what you have in the
> >> >> > * nvmem-cell-names prop.
> >> >> > */
> >> >> > const char *conid;
> >> >> > };
> >> >> >
> >> >> > struct nvmem_cell_lookup_table {
> >> >> > struct list_head list;
> >> >> >
> >> >> > /* ID of the consumer device. */
> >> >> > const char *devid;
> >> >> >
> >> >> > /* Array of cell lookup entries. */
> >> >> > unsigned int ncells;
> >> >> > const struct nvmem_cell_lookup *cells;
> >> >> > };
> >> >> >
> >> >> > Looks like your nvmem_cell_lookup is more something used to attach cells
> >> >> > to an nvmem device, which is NVMEM provider's responsibility not the
> >> >> > consumer one.
> >> >>
> >> >> Hi Boris
> >> >>
> >> >> There are cases where there is not a clear providier/consumer split. I
> >> >> have an x86 platform, with a few at24 EEPROMs on it. It uses an off
> >> >> the shelf Komtron module, placed on a custom carrier board. One of the
> >> >> EEPROMs contains the hardware variant information. Once i know the
> >> >> variant, i need to instantiate other I2C, SPI, MDIO devices, all using
> >> >> platform devices, since this is x86, no DT available.
> >> >>
> >> >> So the first thing my x86 platform device does is instantiate the
> >> >> first i2c device for the AT24. Once the EEPROM pops into existence, i
> >> >> need to add nvmem cells onto it. So at that point, the x86 platform
> >> >> driver is playing the provider role. Once the cells are added, i can
> >> >> then use nvmem consumer interfaces to get the contents of the cell,
> >> >> run a checksum, and instantiate the other devices.
> >> >>
> >> >> I wish the embedded world was all DT, but the reality is that it is
> >> >> not :-(
> >> >
> >> > Actually, I'm not questioning the need for this feature (being able to
> >> > attach NVMEM cells to an NVMEM device on a platform that does not use
> >> > DT). What I'm saying is that this functionality is provider related,
> >> > not consumer related. Also, I wonder if defining such NVMEM cells
> >> > shouldn't go through the provider driver instead of being passed
> >> > directly to the NVMEM layer, because nvmem_config already have a fields
> >> > to pass cells at registration time, plus, the name of the NVMEM cell
> >> > device is sometimes created dynamically and can be hard to guess at
> >> > platform_device registration time.
> >> >
> >>
> >> In my use case the provider is at24 EEPROM driver. This is where the
> >> nvmem_config lives but I can't image a correct and clean way of
> >> passing this cell config to the driver from board files without using
> >> new ugly fields in platform_data which this very series is trying to
> >> remove. This is why this cell config should live in machine code.
> >
> > Okay.
> >
> >>
> >> > I also think non-DT consumers will need a way to reference exiting
> >> > NVMEM cells, but this consumer-oriented nvmem cell lookup table should
> >> > look like the gpio or pwm lookup table (basically what I proposed in my
> >> > previous email).
> >>
> >> How about introducing two new interfaces to nvmem: one for defining
> >> nvmem cells from machine code and the second for connecting these
> >> cells with devices?
> >
> > Yes, that's basically what I was suggesting: move what you've done in
> > nvmem-provider.h (maybe rename some of the structs to make it clear
> > that this is about defining cells not referencing existing ones), and
> > add a new consumer interface (based on what other subsystems do) in
> > nvmem-consumer.h.
> >
> > This way you have both things clearly separated, and if a driver is
> > both a consumer and a provider you'll just have to include both headers.
> >
> > Regards,
> >
> > Boris
>
> I didn't notice it before but there's a global list of nvmem cells
> with each cell referencing its owner nvmem device. I'm wondering if
> this isn't some kind of inversion of ownership. Shouldn't each nvmem
> device have a separate list of nvmem cells owned by it? What happens
> if we have two nvmem providers with the same names for cells? I'm
> asking because dev_id based lookup doesn't make sense if internally
> nvmem_cell_get_from_list() doesn't care about any device names (takes
> only the cell_id as argument).
>
> This doesn't cause any trouble now since there are no users defining
> cells in nvmem_config - there are only DT users - but this must be
> clarified before I can advance with correctly implementing nvmem
> lookups.
>
> BTW: of_nvmem_cell_get() seems to always allocate an nvmem_cell
> instance even if the cell for this node was already added to the nvmem
> device.
Yep, don't know if it's done on purpose or not, but it's weird. I'd
expect cells to be instantiated at NVMEM registration time (and stored
in a list attached to the device) and then, anytime someone calls
nvmem_cell_get(), you would search in this list for a match.
^ permalink raw reply
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Kees Cook @ 2018-08-27 14:08 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Al Viro, LKML, Cong Wang, Jiri Pirko, David S. Miller,
Network Development
In-Reply-To: <d68f13e6-339a-2a40-9c0d-7549cd9aabb3@mojatatu.com>
On Mon, Aug 27, 2018 at 4:46 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 2018-08-26 5:56 p.m., Kees Cook wrote:
>>
>> On Sun, Aug 26, 2018 at 10:30 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>>
>>> We should add an nla_policy later.
>>
>>
>> What's the right way to do that for cases like this?
>
>
> Meant something like attached which you alluded-to in your comments
> would give an upper bound (Max allowed keys is 128).
The problem is that policy doesn't parse the contents: "nkeys"
determines the size, so we have to both validate minimum size (to be
sure the location of "nkeys" is valid) and check that the size is at
least nkeys * struct long. I don't think there is a way to do this
with the existing policy language.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH net] sctp: hold transport before accessing its asoc in sctp_transport_get_next
From: Xin Long @ 2018-08-27 10:38 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
As Marcelo noticed, in sctp_transport_get_next, it is iterating over
transports but then also accessing the association directly, without
checking any refcnts before that, which can cause an use-after-free
Read.
So fix it by holding transport before accessing the association. With
that, sctp_transport_hold calls can be removed in the later places.
Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/proc.c | 4 ----
net/sctp/socket.c | 22 +++++++++++++++-------
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index ef5c9a8..4d6f1c8 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -264,8 +264,6 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
}
transport = (struct sctp_transport *)v;
- if (!sctp_transport_hold(transport))
- return 0;
assoc = transport->asoc;
epb = &assoc->base;
sk = epb->sk;
@@ -322,8 +320,6 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
}
transport = (struct sctp_transport *)v;
- if (!sctp_transport_hold(transport))
- return 0;
assoc = transport->asoc;
list_for_each_entry_rcu(tsp, &assoc->peer.transport_addr_list,
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index e96b15a..aa76586 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5005,9 +5005,14 @@ struct sctp_transport *sctp_transport_get_next(struct net *net,
break;
}
+ if (!sctp_transport_hold(t))
+ continue;
+
if (net_eq(sock_net(t->asoc->base.sk), net) &&
t->asoc->peer.primary_path == t)
break;
+
+ sctp_transport_put(t);
}
return t;
@@ -5017,13 +5022,18 @@ struct sctp_transport *sctp_transport_get_idx(struct net *net,
struct rhashtable_iter *iter,
int pos)
{
- void *obj = SEQ_START_TOKEN;
+ struct sctp_transport *t;
- while (pos && (obj = sctp_transport_get_next(net, iter)) &&
- !IS_ERR(obj))
- pos--;
+ if (!pos)
+ return SEQ_START_TOKEN;
- return obj;
+ while ((t = sctp_transport_get_next(net, iter)) && !IS_ERR(t)) {
+ if (!--pos)
+ break;
+ sctp_transport_put(t);
+ }
+
+ return t;
}
int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
@@ -5082,8 +5092,6 @@ int sctp_for_each_transport(int (*cb)(struct sctp_transport *, void *),
tsp = sctp_transport_get_idx(net, &hti, *pos + 1);
for (; !IS_ERR_OR_NULL(tsp); tsp = sctp_transport_get_next(net, &hti)) {
- if (!sctp_transport_hold(tsp))
- continue;
ret = cb(tsp, p);
if (ret)
break;
--
2.1.0
^ permalink raw reply related
* [PATCH net] sctp: remove useless start_fail from sctp_ht_iter in proc
From: Xin Long @ 2018-08-27 10:40 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
After changing rhashtable_walk_start to return void, start_fail would
never be set other value than 0, and the checking for start_fail is
pointless, so remove it.
Fixes: 97a6ec4ac021 ("rhashtable: Change rhashtable_walk_start to return void")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/proc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 4d6f1c8..a644292 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -215,7 +215,6 @@ static const struct seq_operations sctp_eps_ops = {
struct sctp_ht_iter {
struct seq_net_private p;
struct rhashtable_iter hti;
- int start_fail;
};
static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
@@ -224,7 +223,6 @@ static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
sctp_transport_walk_start(&iter->hti);
- iter->start_fail = 0;
return sctp_transport_get_idx(seq_file_net(seq), &iter->hti, *pos);
}
@@ -232,8 +230,6 @@ static void sctp_transport_seq_stop(struct seq_file *seq, void *v)
{
struct sctp_ht_iter *iter = seq->private;
- if (iter->start_fail)
- return;
sctp_transport_walk_stop(&iter->hti);
}
--
2.1.0
^ permalink raw reply related
* [PATCH net] erspan: set erspan_ver to 1 by default when adding an erspan dev
From: Xin Long @ 2018-08-27 10:41 UTC (permalink / raw)
To: network dev; +Cc: davem, William Tu
After erspan_ver is introudced, if erspan_ver is not set in iproute, its
value will be left 0 by default. Since Commit 02f99df1875c ("erspan: fix
invalid erspan version."), it has broken the traffic due to the version
check in erspan_xmit if users are not aware of 'erspan_ver' param, like
using an old version of iproute.
To fix this compatibility problem, it sets erspan_ver to 1 by default
when adding an erspan dev in erspan_setup. Note that we can't do it in
ipgre_netlink_parms, as this function is also used by ipgre_changelink.
Fixes: 02f99df1875c ("erspan: fix invalid erspan version.")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv4/ip_gre.c | 3 +++
net/ipv6/ip6_gre.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 51a5d06..ae714ae 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1508,11 +1508,14 @@ static int ipgre_fill_info(struct sk_buff *skb, const struct net_device *dev)
static void erspan_setup(struct net_device *dev)
{
+ struct ip_tunnel *t = netdev_priv(dev);
+
ether_setup(dev);
dev->netdev_ops = &erspan_netdev_ops;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
ip_tunnel_setup(dev, erspan_net_id);
+ t->erspan_ver = 1;
}
static const struct nla_policy ipgre_policy[IFLA_GRE_MAX + 1] = {
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 18a3794..e493b04 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1778,6 +1778,7 @@ static void ip6gre_netlink_parms(struct nlattr *data[],
if (data[IFLA_GRE_COLLECT_METADATA])
parms->collect_md = true;
+ parms->erspan_ver = 1;
if (data[IFLA_GRE_ERSPAN_VER])
parms->erspan_ver = nla_get_u8(data[IFLA_GRE_ERSPAN_VER]);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Jamal Hadi Salim @ 2018-08-27 11:46 UTC (permalink / raw)
To: Kees Cook
Cc: Al Viro, LKML, Cong Wang, Jiri Pirko, David S. Miller,
Network Development
In-Reply-To: <CAGXu5jJZ-BfJPA+m1BOuVVQxPb8SXpSRo+F2cVTF62C9JTyRXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
On 2018-08-26 5:56 p.m., Kees Cook wrote:
> On Sun, Aug 26, 2018 at 10:30 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> We should add an nla_policy later.
>
> What's the right way to do that for cases like this?
Meant something like attached which you alluded-to in your comments
would give an upper bound (Max allowed keys is 128).
cheers,
jamal
[-- Attachment #2: patchlet --]
[-- Type: text/plain, Size: 706 bytes --]
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index d5d2a6dc3921..cb7a3fa0e728 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -761,7 +761,9 @@ static const struct nla_policy u32_policy[TCA_U32_MAX + 1] = {
[TCA_U32_HASH] = { .type = NLA_U32 },
[TCA_U32_LINK] = { .type = NLA_U32 },
[TCA_U32_DIVISOR] = { .type = NLA_U32 },
- [TCA_U32_SEL] = { .len = sizeof(struct tc_u32_sel) },
+ [TCA_U32_SEL] = { .type = NLA_BINARY,
+ .len = (sizeof(struct tc_u32_sel) +
+ (128*sizeof(struct tc_u32_key)) },
[TCA_U32_INDEV] = { .type = NLA_STRING, .len = IFNAMSIZ },
[TCA_U32_MARK] = { .len = sizeof(struct tc_u32_mark) },
[TCA_U32_FLAGS] = { .type = NLA_U32 },
^ permalink raw reply related
* [PATCH] net: mvpp2: initialize port of_node pointer
From: Baruch Siach @ 2018-08-27 12:12 UTC (permalink / raw)
To: Maxime Chevallier, Antoine Tenart
Cc: netdev, Russell King, Ori Shem-Tov, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Baruch Siach
Without a valid of_node in struct device we can't find the mvpp2 port
device by its DT node. Specifically, this breaks
of_find_net_device_by_node().
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 32d785b616e1..28500417843e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4803,6 +4803,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
dev->min_mtu = ETH_MIN_MTU;
/* 9704 == 9728 - 20 and rounding to 8 */
dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
+ dev->dev.of_node = port_node;
/* Phylink isn't used w/ ACPI as of now */
if (port_node) {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Geert Uytterhoeven @ 2018-08-27 12:28 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux-Renesas
In-Reply-To: <1535029653-7418-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Thu, Aug 23, 2018 at 3:08 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch fixes this problem and also allows for architectures
> missing some of the clocks (e.g. RZ/G2) to behave as expected.
I think the fix for the second issue is not needed (see my reply to the other
patch).
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> ---
>
> This patch applies on linux-can-next-for-4.19-20180727
>
> drivers/net/can/rcar/rcar_can.c | 43 +++++++++++++++++++++++++++++++++--------
> 1 file changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
> index 11662f4..fbd9284 100644
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -21,9 +21,13 @@
> #include <linux/clk.h>
> #include <linux/can/platform/rcar_can.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
>
> #define RCAR_CAN_DRV_NAME "rcar_can"
>
> +#define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> + BIT(CLKR_CLKEXT))
> +
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> * mailbox 56 - 59 - Tx FIFO mailboxes
> @@ -745,10 +749,12 @@ static int rcar_can_probe(struct platform_device *pdev)
> u32 clock_select = CLKR_CLKP1;
> int err = -ENODEV;
> int irq;
> + uintptr_t allowed_clks = RCAR_SUPPORTED_CLOCKS;
>
> if (pdev->dev.of_node) {
> of_property_read_u32(pdev->dev.of_node,
> "renesas,can-clock-select", &clock_select);
> + allowed_clks = (uintptr_t)of_device_get_match_data(&pdev->dev);
> } else {
> pdata = dev_get_platdata(&pdev->dev);
> if (!pdata) {
> @@ -789,7 +795,7 @@ static int rcar_can_probe(struct platform_device *pdev)
> goto fail_clk;
> }
>
> - if (clock_select >= ARRAY_SIZE(clock_names)) {
> + if (!(BIT(clock_select) & allowed_clks)) {
Hence you can just use RCAR_SUPPORTED_CLOCKS directly,
or better, just check clock_names[clock_select] != NULL, ...
> err = -EINVAL;
> dev_err(&pdev->dev, "invalid CAN clock selected\n");
> goto fail_clk;
> @@ -899,13 +905,34 @@ static int __maybe_unused rcar_can_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(rcar_can_pm_ops, rcar_can_suspend, rcar_can_resume);
>
> static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
> - { .compatible = "renesas,can-r8a7778" },
> - { .compatible = "renesas,can-r8a7779" },
> - { .compatible = "renesas,can-r8a7790" },
> - { .compatible = "renesas,can-r8a7791" },
> - { .compatible = "renesas,rcar-gen1-can" },
> - { .compatible = "renesas,rcar-gen2-can" },
> - { .compatible = "renesas,rcar-gen3-can" },
> + {
> + .compatible = "renesas,can-r8a7778",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7779",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7790",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,can-r8a7791",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen1-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen2-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> + {
> + .compatible = "renesas,rcar-gen3-can",
> + .data = (void *)RCAR_SUPPORTED_CLOCKS,
> + },
> { }
... and all of the above can dropped.
> };
> MODULE_DEVICE_TABLE(of, rcar_can_of_table);
BTW, why does the custom "renesas,can-clock-select" exist?
If guess the standard "assigned-clock-parents" wasn't suitable because there's
no actual defined clock for which you can change the parent?
Why do you need manual selection? Can't the driver just pick the most suitable
available clock, like other drivers (e.g. sh-sci) do?
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH 2/3][can-next] can: rcar_can: Add RZ/G2 support
From: Geert Uytterhoeven @ 2018-08-27 12:30 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, Linux-Renesas
In-Reply-To: <1535029653-7418-3-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
(Usually the DT patch goes before the driver patch)
On Thu, Aug 23, 2018 at 3:08 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> RZ/G2 devices don't have clkp2, therefore this commit adds a
> generic compatible string for them to allow for proper checking
> during probe.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Thanks for your patch!
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -27,6 +27,7 @@
>
> #define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> BIT(CLKR_CLKEXT))
> +#define RZG2_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKEXT))
>
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> @@ -933,6 +934,10 @@ static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
> .compatible = "renesas,rcar-gen3-can",
> .data = (void *)RCAR_SUPPORTED_CLOCKS,
> },
> + {
> + .compatible = "renesas,rzg-gen2-can",
> + .data = (void *)RZG2_SUPPORTED_CLOCKS,
> + },
> { }
I think this patch is not needed, cfr. my reply to the
first^H^H^H^H^Hthird patch
in your series.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
From: Marc Kleine-Budde @ 2018-08-27 10:08 UTC (permalink / raw)
To: Eugeniu Rosca, Simon Horman, Kieran Bingham, Sergei Shtylyov,
Wolfgang Grandegger, David S . Miller, Rob Herring, Mark Rutland,
linux-can, netdev, devicetree, Magnus Damm, linux-renesas-soc
Cc: Eugeniu Rosca
In-Reply-To: <20180820144910.13210-1-erosca@de.adit-jv.com>
[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]
On 08/20/2018 04:49 PM, Eugeniu Rosca wrote:
> From: Eugeniu Rosca <rosca.eugeniu@gmail.com>
>
> Document the support for rcar_can on R8A77965 SoC devices.
> Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
> "assigned-clock-rates" properties (thanks, Sergei).
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Added to linux-can.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 1/2] net/ibm/emac: wrong emac_calc_base call was used by typo
From: Ivan Mikhaylov @ 2018-08-27 16:43 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Christian Lamparter, linux-kernel
__emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
by copy-paste mistake for emac4syn.
Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192 rx/tx fifo size")
Signed-off-by: Ivan Mikhaylov <ivan@de.ibm.com>
---
drivers/net/ethernet/ibm/emac/core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 354c098..3726646 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -494,9 +494,6 @@ static u32 __emac_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_s
case 16384:
ret |= EMAC_MR1_RFS_16K;
break;
- case 8192:
- ret |= EMAC4_MR1_RFS_8K;
- break;
case 4096:
ret |= EMAC_MR1_RFS_4K;
break;
@@ -537,6 +534,9 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
case 16384:
ret |= EMAC4_MR1_RFS_16K;
break;
+ case 8192:
+ ret |= EMAC4_MR1_RFS_8K;
+ break;
case 4096:
ret |= EMAC4_MR1_RFS_4K;
break;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Russell King - ARM Linux @ 2018-08-27 16:50 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180517082939.14598-3-antoine.tenart@bootlin.com>
On Thu, May 17, 2018 at 10:29:31AM +0200, Antoine Tenart wrote:
> +static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> + struct mvpp2_port *port = netdev_priv(dev);
> +
> + /* Check for invalid configuration */
> + if (state->interface == PHY_INTERFACE_MODE_10GKR && port->gop_id != 0) {
> + netdev_err(dev, "Invalid mode on %s\n", dev->name);
> + return;
> + }
> +
> + netif_tx_stop_all_queues(port->dev);
> + if (!port->has_phy)
> + netif_carrier_off(port->dev);
...
> + /* If the port already was up, make sure it's still in the same state */
> + if (state->link || !port->has_phy) {
> + mvpp2_port_enable(port);
> +
> + mvpp2_egress_enable(port);
> + mvpp2_ingress_enable(port);
> + if (!port->has_phy)
> + netif_carrier_on(dev);
> + netif_tx_wake_all_queues(dev);
> + }
I'm guessing that the above is what is classed as "small fixes"
in the cover letter for this series - as such I didn't look closely
at this patch, but I should have, because this is not a "small fix".
I don't find the above code in previous patches, and I don't find
any description about why this has changed.
I'm on record for having said (many times) that drivers that are
converted to phylink should _not_ mess with the net device carrier
state themselves, but should leave it to phylink to manage.
The above appears to cause a problem when testing on a singleshot
mcbin board - as a direct result of the above, I find that _all_
the network devices apparently have link, including those which
have no SFP inserted into the cage. This results in debian jessie
hanging at boot for over 1 minute while systemd tries to bring up
all network devices.
The same should be true of the doubleshot board's 1G cage - which
is the same as the singleshot in every respect, and the singleshot
exhibits this problem there as well. I haven't actually tested
this on the doubleshot though.
Have you identified a case where mac_config() is called with the
link up for which a major reconfiguration is required? mac_config()
will get called for small reconfigurations such as changing the
pause parameters (which should _not_ require the queues to be
restarted) but the link should always be down for major
reconfigurations such sa changing the PHY interface mode.
mac_config() can also be called when nothing has changed - if we've
decided to re-run the link state resolve, it can be called with the
same parameters as previously, especially now that we have polling
of a GPIO for link state monitoring. With your code above, this will
cause mvpp2 to down/up the carrier state every second.
Note that state->link here is the _future_ state of the link, which
may change state before the mac_link_up()/down() functions have been
called - turning the carrier on/off like this will prevent these
callbacks being made, and the link state being printed by phylink.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH net] sctp: hold transport before accessing its asoc in sctp_transport_get_next
From: Neil Horman @ 2018-08-27 13:08 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <607dd2950d09fc83404d670a73099523087d4963.1535366311.git.lucien.xin@gmail.com>
On Mon, Aug 27, 2018 at 06:38:31PM +0800, Xin Long wrote:
> As Marcelo noticed, in sctp_transport_get_next, it is iterating over
> transports but then also accessing the association directly, without
> checking any refcnts before that, which can cause an use-after-free
> Read.
>
> So fix it by holding transport before accessing the association. With
> that, sctp_transport_hold calls can be removed in the later places.
>
> Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
> Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/proc.c | 4 ----
> net/sctp/socket.c | 22 +++++++++++++++-------
> 2 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index ef5c9a8..4d6f1c8 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -264,8 +264,6 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
> }
>
> transport = (struct sctp_transport *)v;
> - if (!sctp_transport_hold(transport))
> - return 0;
> assoc = transport->asoc;
> epb = &assoc->base;
> sk = epb->sk;
> @@ -322,8 +320,6 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
> }
>
> transport = (struct sctp_transport *)v;
> - if (!sctp_transport_hold(transport))
> - return 0;
> assoc = transport->asoc;
>
> list_for_each_entry_rcu(tsp, &assoc->peer.transport_addr_list,
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index e96b15a..aa76586 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -5005,9 +5005,14 @@ struct sctp_transport *sctp_transport_get_next(struct net *net,
> break;
> }
>
> + if (!sctp_transport_hold(t))
> + continue;
> +
> if (net_eq(sock_net(t->asoc->base.sk), net) &&
> t->asoc->peer.primary_path == t)
> break;
> +
> + sctp_transport_put(t);
> }
>
> return t;
> @@ -5017,13 +5022,18 @@ struct sctp_transport *sctp_transport_get_idx(struct net *net,
> struct rhashtable_iter *iter,
> int pos)
> {
> - void *obj = SEQ_START_TOKEN;
> + struct sctp_transport *t;
>
> - while (pos && (obj = sctp_transport_get_next(net, iter)) &&
> - !IS_ERR(obj))
> - pos--;
> + if (!pos)
> + return SEQ_START_TOKEN;
>
> - return obj;
> + while ((t = sctp_transport_get_next(net, iter)) && !IS_ERR(t)) {
> + if (!--pos)
> + break;
> + sctp_transport_put(t);
> + }
> +
> + return t;
> }
>
> int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
> @@ -5082,8 +5092,6 @@ int sctp_for_each_transport(int (*cb)(struct sctp_transport *, void *),
>
> tsp = sctp_transport_get_idx(net, &hti, *pos + 1);
> for (; !IS_ERR_OR_NULL(tsp); tsp = sctp_transport_get_next(net, &hti)) {
> - if (!sctp_transport_hold(tsp))
> - continue;
> ret = cb(tsp, p);
> if (ret)
> break;
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Additionally, its not germaine to this particular fix, but why are we still
using that pos variable in sctp_transport_get_idx? With the conversion to
rhashtables, it doesn't seem particularly useful anymore.
Neil
^ permalink raw reply
* Re: [PATCH net] sctp: remove useless start_fail from sctp_ht_iter in proc
From: Neil Horman @ 2018-08-27 13:13 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <265533f54ceb4684bb8323c9601a743eed409527.1535366418.git.lucien.xin@gmail.com>
On Mon, Aug 27, 2018 at 06:40:18PM +0800, Xin Long wrote:
> After changing rhashtable_walk_start to return void, start_fail would
> never be set other value than 0, and the checking for start_fail is
> pointless, so remove it.
>
> Fixes: 97a6ec4ac021 ("rhashtable: Change rhashtable_walk_start to return void")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/proc.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 4d6f1c8..a644292 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -215,7 +215,6 @@ static const struct seq_operations sctp_eps_ops = {
> struct sctp_ht_iter {
> struct seq_net_private p;
> struct rhashtable_iter hti;
> - int start_fail;
> };
>
> static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
> @@ -224,7 +223,6 @@ static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
>
> sctp_transport_walk_start(&iter->hti);
>
> - iter->start_fail = 0;
> return sctp_transport_get_idx(seq_file_net(seq), &iter->hti, *pos);
> }
>
> @@ -232,8 +230,6 @@ static void sctp_transport_seq_stop(struct seq_file *seq, void *v)
> {
> struct sctp_ht_iter *iter = seq->private;
>
> - if (iter->start_fail)
> - return;
> sctp_transport_walk_stop(&iter->hti);
> }
>
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net] sctp: hold transport before accessing its asoc in sctp_transport_get_next
From: Marcelo Ricardo Leitner @ 2018-08-27 13:28 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <607dd2950d09fc83404d670a73099523087d4963.1535366311.git.lucien.xin@gmail.com>
On Mon, Aug 27, 2018 at 06:38:31PM +0800, Xin Long wrote:
> As Marcelo noticed, in sctp_transport_get_next, it is iterating over
> transports but then also accessing the association directly, without
> checking any refcnts before that, which can cause an use-after-free
> Read.
>
> So fix it by holding transport before accessing the association. With
> that, sctp_transport_hold calls can be removed in the later places.
>
> Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
> Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/proc.c | 4 ----
> net/sctp/socket.c | 22 +++++++++++++++-------
> 2 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index ef5c9a8..4d6f1c8 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -264,8 +264,6 @@ static int sctp_assocs_seq_show(struct seq_file *seq, void *v)
> }
>
> transport = (struct sctp_transport *)v;
> - if (!sctp_transport_hold(transport))
> - return 0;
> assoc = transport->asoc;
> epb = &assoc->base;
> sk = epb->sk;
> @@ -322,8 +320,6 @@ static int sctp_remaddr_seq_show(struct seq_file *seq, void *v)
> }
>
> transport = (struct sctp_transport *)v;
> - if (!sctp_transport_hold(transport))
> - return 0;
> assoc = transport->asoc;
>
> list_for_each_entry_rcu(tsp, &assoc->peer.transport_addr_list,
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index e96b15a..aa76586 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -5005,9 +5005,14 @@ struct sctp_transport *sctp_transport_get_next(struct net *net,
> break;
> }
>
> + if (!sctp_transport_hold(t))
> + continue;
> +
> if (net_eq(sock_net(t->asoc->base.sk), net) &&
> t->asoc->peer.primary_path == t)
> break;
> +
> + sctp_transport_put(t);
> }
>
> return t;
> @@ -5017,13 +5022,18 @@ struct sctp_transport *sctp_transport_get_idx(struct net *net,
> struct rhashtable_iter *iter,
> int pos)
> {
> - void *obj = SEQ_START_TOKEN;
> + struct sctp_transport *t;
>
> - while (pos && (obj = sctp_transport_get_next(net, iter)) &&
> - !IS_ERR(obj))
> - pos--;
> + if (!pos)
> + return SEQ_START_TOKEN;
>
> - return obj;
> + while ((t = sctp_transport_get_next(net, iter)) && !IS_ERR(t)) {
> + if (!--pos)
> + break;
> + sctp_transport_put(t);
> + }
> +
> + return t;
> }
>
> int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
> @@ -5082,8 +5092,6 @@ int sctp_for_each_transport(int (*cb)(struct sctp_transport *, void *),
>
> tsp = sctp_transport_get_idx(net, &hti, *pos + 1);
> for (; !IS_ERR_OR_NULL(tsp); tsp = sctp_transport_get_next(net, &hti)) {
> - if (!sctp_transport_hold(tsp))
> - continue;
> ret = cb(tsp, p);
> if (ret)
> break;
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH net] sctp: remove useless start_fail from sctp_ht_iter in proc
From: Marcelo Ricardo Leitner @ 2018-08-27 13:30 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <265533f54ceb4684bb8323c9601a743eed409527.1535366418.git.lucien.xin@gmail.com>
On Mon, Aug 27, 2018 at 06:40:18PM +0800, Xin Long wrote:
> After changing rhashtable_walk_start to return void, start_fail would
> never be set other value than 0, and the checking for start_fail is
> pointless, so remove it.
>
> Fixes: 97a6ec4ac021 ("rhashtable: Change rhashtable_walk_start to return void")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/proc.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 4d6f1c8..a644292 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -215,7 +215,6 @@ static const struct seq_operations sctp_eps_ops = {
> struct sctp_ht_iter {
> struct seq_net_private p;
> struct rhashtable_iter hti;
> - int start_fail;
> };
>
> static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
> @@ -224,7 +223,6 @@ static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
>
> sctp_transport_walk_start(&iter->hti);
>
> - iter->start_fail = 0;
> return sctp_transport_get_idx(seq_file_net(seq), &iter->hti, *pos);
> }
>
> @@ -232,8 +230,6 @@ static void sctp_transport_seq_stop(struct seq_file *seq, void *v)
> {
> struct sctp_ht_iter *iter = seq->private;
>
> - if (iter->start_fail)
> - return;
> sctp_transport_walk_stop(&iter->hti);
> }
>
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH] net: mvpp2: initialize port of_node pointer
From: Andrew Lunn @ 2018-08-27 13:47 UTC (permalink / raw)
To: Baruch Siach
Cc: Maxime Chevallier, Antoine Tenart, netdev, Russell King,
Ori Shem-Tov, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <96a50db3fefc2f1be9ecb6bf8ca91c71508e8eb1.1535371973.git.baruch@tkos.co.il>
On Mon, Aug 27, 2018 at 03:12:53PM +0300, Baruch Siach wrote:
> Without a valid of_node in struct device we can't find the mvpp2 port
> device by its DT node. Specifically, this breaks
> of_find_net_device_by_node().
Hi Baruch
We need to be a little bit careful here. I've seen this done wrongly
before, breaking DSA support. Is you intention to use DSA? Can you
quote a section of DT, and indicate which node is port_node.
Thanks
Andrew
^ permalink raw reply
* Re: WARNING in format_decode (2)
From: Steven Rostedt @ 2018-08-27 17:46 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, mingo, syzkaller-bugs, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <000000000000e12d4105746dcb0d@google.com>
On Mon, 27 Aug 2018 10:10:04 -0700
syzbot <syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 2ad0d5269970 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b8efba400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=79e695838ce7a210
> dashboard link: https://syzkaller.appspot.com/bug?extid=1ec5c5ec949c4adaa0c4
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1626f761400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1ec5c5ec949c4adaa0c4@syzkaller.appspotmail.com
>
> ** **
> ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> **********************************************************
> ------------[ cut here ]------------
> Please remove unsupported %WARNING: CPU: 0 PID: 6453 at lib/vsprintf.c:2149 format_decode+0x8fc/0xaf0
> lib/vsprintf.c:2149
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 6453 Comm: syz-executor7 Not tainted 4.18.0+ #190
> 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+0x1c9/0x2b4 lib/dump_stack.c:113
> panic+0x238/0x4e7 kernel/panic.c:184
> __warn.cold.8+0x163/0x1ba kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
> RIP: 0010:format_decode+0x8fc/0xaf0 lib/vsprintf.c:2149
> Code: e8 59 59 c9 fa 41 c6 04 24 12 e9 94 fd ff ff e8 4a 59 c9 fa 0f be f3
> 48 c7 c7 60 bc 89 87 c6 05 28 aa d2 01 01 e8 e4 e9 93 fa <0f> 0b 4d 8b 7d
> c0 e9 56 fe ff ff 48 8b bd 68 ff ff ff e8 cd 4f 08
> RSP: 0018:ffff8801b6b27688 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff816422b1 RDI: ffff8801b6b27378
> RBP: ffff8801b6b27730 R08: ffff8801b69a0040 R09: 0000000000000006
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b6b277a8
> R13: ffff8801b6b27708 R14: 0000000000000000 R15: ffff8801b6b27b04
> vsnprintf+0x185/0x1b60 lib/vsprintf.c:2245
> vscnprintf+0x2d/0x80 lib/vsprintf.c:2396
> __trace_array_vprintk.part.60+0xc7/0x330 kernel/trace/trace.c:2990
> __trace_array_vprintk kernel/trace/trace.c:3021 [inline]
> trace_array_vprintk kernel/trace/trace.c:3021 [inline]
> trace_vprintk+0x5f/0x90 kernel/trace/trace.c:3059
> __trace_printk+0xce/0x120 kernel/trace/trace_printk.c:237
> ____bpf_trace_printk kernel/trace/bpf_trace.c:274 [inline]
Looks like a bug in the bpf trace printk code.
-- Steve
> bpf_trace_printk+0xb16/0xc30 kernel/trace/bpf_trace.c:166
> bpf_prog_e51deac1441bc083+0x94a/0x1000
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> 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: KASAN: invalid-free in p9stat_free
From: Dmitry Vyukov @ 2018-08-27 14:25 UTC (permalink / raw)
To: Dominique Martinet
Cc: syzbot, David Miller, Eric Van Hensbergen, LKML, Latchesar Ionkov,
netdev, syzkaller-bugs, v9fs-developer
In-Reply-To: <20180827052412.GA26294@nautica>
On Sun, Aug 26, 2018 at 10:24 PM, Dominique Martinet
<asmadeus@codewreck.org> wrote:
> syzbot wrote on Sun, Aug 26, 2018:
>> HEAD commit: e27bc174c9c6 Add linux-next specific files for 20180824
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=15dc19a6400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=28446088176757ea
>> dashboard link: https://syzkaller.appspot.com/bug?extid=d4252148d198410b864f
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15f8efba400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1178256a400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> ==================================================================
>> BUG: KASAN: double-free or invalid-free in p9stat_free+0x35/0x100
>> net/9p/protocol.c:48
>
> That looks straight-forward enough, p9pdu_vreadf does p9stat_free on
> error then v9fs_dir_readdir does the same ; there is nothing else that
> could return an error without going through the first free so we could
> just remove the later one...
>
> There are a couple other users of the 'S' pdu read (that reads the stat
> struct and frees it on error), so it's probably best to keep the current
> behaviour as far as this is concerned, what we could do though is make
> the free function idempotent (write NULLs in the freed fields), but I do
> not see this being done often, do you know what the policy is about
> this kind of pattern nowadays?
Hi Dominique,
kfree and then null pointer is pretty common, try to run:
find -name "*.c" -exec grep -A 1 "kfree(" {} \; | grep -B 1 " = NULL;"
Leaving dangling pointers behind is not the best idea.
And from what I remember a bunch of similar double frees were fixed by
nulling the pointer after the first kfree.
> The struct is cleanly zeroed before being read so there is no risk of
> double-frees between iterations so zeroing pointers is not strictly
> required, but it does make things safer in general.
^ permalink raw reply
* Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL
From: Roman Mashak @ 2018-08-27 14:26 UTC (permalink / raw)
To: Kees Cook
Cc: Jamal Hadi Salim, Al Viro, LKML, Cong Wang, Jiri Pirko,
David S. Miller, Network Development
In-Reply-To: <CAGXu5jJD++hegH4j0ajZNejg8mgcHjqVyjveWj9BFaXwRCV_dQ@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Mon, Aug 27, 2018 at 4:46 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 2018-08-26 5:56 p.m., Kees Cook wrote:
>>>
>>> On Sun, Aug 26, 2018 at 10:30 AM, Jamal Hadi Salim <jhs@mojatatu.com>
>>> wrote:
>>>>
>>>> We should add an nla_policy later.
>>>
>>>
>>> What's the right way to do that for cases like this?
>>
>>
>> Meant something like attached which you alluded-to in your comments
>> would give an upper bound (Max allowed keys is 128).
>
> The problem is that policy doesn't parse the contents: "nkeys"
> determines the size, so we have to both validate minimum size (to be
> sure the location of "nkeys" is valid) and check that the size is at
> least nkeys * struct long. I don't think there is a way to do this
> with the existing policy language.
While at these changes, could you also add and export in UAPI max
allowed keys count, which is currently 128? For example,
TCA_U32_NKEYS_MAX in pkt_cls.h
^ 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