Re: [PATCH] lib: vsprintf: check for NULL device_node name in device_node_string()
On (21/02/17 13:15), Enrico Weigelt, metux IT consult wrote: > Under rare circumstances it may happen that a device node's name is NULL > (most likely kernel bug in some other place). In such situations anything > but helpful, if the debug printout crashes, and nobody knows what actually > happened here. > > Therefore protect it by an explicit NULL check and print out an extra > warning. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > lib/vsprintf.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index 3b53c73580c5..050a60b88073 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -2013,6 +2013,10 @@ char *device_node_string(char *buf, char *end, struct > device_node *dn, > break; > case 'n': /* name */ > p = fwnode_get_name(of_fwnode_handle(dn)); > + if (!p) { > + pr_warn("device_node without name. Kernel bug > ?\n"); > + p = ""; > + } > precision = str_spec.precision; > str_spec.precision = strchrnul(p, '@') - p; > buf = string(buf, end, p, str_spec); What about other fwnode_get_name() calls in vsprintf? -ss
Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax
On (20/07/21 08:24), Jonathan Corbet wrote: > On Tue, 21 Jul 2020 23:02:46 +0900 > > I'm happy either way. I'll grab it Please go ahead. -ss
Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax
On (20/07/18 13:51), Daniel W. S. Almeida wrote: > From: Daniel W. S. Almeida > > Fix the following warning: > > WARNING: Definition list ends without a blank line; > unexpected unindent. > > By switching to the literal block syntax. > > Signed-off-by: Daniel W. S. Almeida Jonathan, will you route it via the Documentation tree or do you want it to land in the printk tree? -ss
Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax
On (20/07/18 13:51), Daniel W. S. Almeida wrote: > Fix the following warning: > > WARNING: Definition list ends without a blank line; > unexpected unindent. > > By switching to the literal block syntax. > > Signed-off-by: Daniel W. S. Almeida Acked-by: Sergey Senozhatsky -ss
Re: [PATCH v3 bpf-next 0/8] bpf, printk: add BTF-based type printing
On (20/06/23 13:07), Alan Maguire wrote: > struct sk_buff *skb = alloc_skb(64, GFP_KERNEL); > > pr_info("%pT", BTF_PTR_TYPE(skb, "struct sk_buff")); > > ...gives us: > > (struct sk_buff){ > .transport_header = (__u16)65535, > .mac_header = (__u16)65535, > .end = (sk_buff_data_t)192, > .head = (unsigned char *)7524fd8b, > .data = (unsigned char *)7524fd8b, > .truesize = (unsigned int)768, > .users = (refcount_t){ > .refs = (atomic_t){ >.counter = (int)1, > }, > }, > } Hmm. So this can expose the kernel memory layout (IOW do you print out real %px pointers and so on)? If so, then I'd suggest not to use printk. Unprivileged /dev/kmsg or /proc/kmsg reads are really OK thing for printk() log buffer. And if you are going to print pointer hashes instead, .transport_header = (__u16)65535, .mac_header = (__u16)65535, .end = (sk_buff_data_t)192, .head = (unsigned char *)34897918740, // pointer_hash .data = (unsigned char *)23942384983, // pointer hash .truesize = (unsigned int)768, .users = (refcount_t){ .refs = (atomic_t){ .counter = (int)1, }, }, then the value of such printouts becomes a bit unclear to me, sorry. Probably, something like a seq print into a file somewhere in /sys/kernel/debug/foo, from which only privileged processes can read, would be a better approach? My 5 cents. -ss
Re: [PATCHv2 bpf-next 1/3] bpf, tests: tweak endianness selection
On (03/21/19 08:49), Stanislav Fomichev wrote: > On 03/21, Sergey Senozhatsky wrote: > > On (03/20/19 20:24), Alexei Starovoitov wrote: > > > On Wed, Mar 20, 2019 at 09:53:33PM +0900, Sergey Senozhatsky wrote: > > > > Not all compilers have __builtin_bswap16() and __builtin_bswap32(), > > > > thus not all compilers are able to compile the following code: > > > > > > > > (__builtin_constant_p(x) ? \ > > > > ___constant_swab16(x) : __builtin_bswap16(x)) > > > > > > > > That's the reason why bpf_ntohl() doesn't work on GCC < 4.8, for > > > > instance: > > > > > > nack to fixes to support such old compilers. > > > > Fair enough. > What is too old? Documentation/process/changes.rst says that minimum > supported gcc is 4.6, do we lift that requirement for the tests? Hmm, good point, Stanislav. I thought it was gcc 4.9 which introduced asm goto and hence 4.9 is the minimum supported version. But it seems that it was 4.5/4.6, so the min supported gcc version is 4.6. Which means that those bpf defines won't work on some compilers. Alexei, does your NACK still stand? -ss
Re: [PATCHv2 bpf-next 1/3] bpf, tests: tweak endianness selection
On (03/20/19 20:24), Alexei Starovoitov wrote: > On Wed, Mar 20, 2019 at 09:53:33PM +0900, Sergey Senozhatsky wrote: > > Not all compilers have __builtin_bswap16() and __builtin_bswap32(), > > thus not all compilers are able to compile the following code: > > > > (__builtin_constant_p(x) ? \ > > ___constant_swab16(x) : __builtin_bswap16(x)) > > > > That's the reason why bpf_ntohl() doesn't work on GCC < 4.8, for > > instance: > > nack to fixes to support such old compilers. Fair enough. -ss
Re: [PATCHv2 bpf-next 1/3] bpf, tests: tweak endianness selection
On (03/20/19 15:27), Stanislav Fomichev wrote: [..] > > Inside kernel clang compiler header (linux/compiler-clang.h) does not > > define __HAVE_BUILTIN_BSWAP16__. So it will go to the "else" branch in > > the above. So I think it should work with clang + bpf. > Hm, isn't it the opposite of what we want then? I think for llvm+bpf we always > want to use the builtins to make it properly generate > BPF_TO_BE/BPF_TO_LE instructions. Oh, hmm, OK. I see your point now. bpf insn set for variables. -ss
Re: [PATCHv2 bpf-next 1/3] bpf, tests: tweak endianness selection
On (03/20/19 10:13), Stanislav Fomichev wrote: > Tested them locally with the compiler I saw the initial issues with - all > fine, I don't see any errors with the older gcc. Thanks! > One last question I have is: what happens in the llvm+bpf case? Have > you tested that? I think LLVM has all the builtins required, but since > we are relying on the swab.h now (and it relies on > __HAVE_BUILTIN_BSWAP16__), I wonder whether this detection works > correctly on the llvm when targeting bpf. (sidenote: bpf_endian.h can be > used from both userspace and bpf programs). Honestly, I haven't, but I think we should be fine. For !__HAVE_BUILTIN_BSWAP16__ compilers we still do constant folding. swab16/swab32 turn into __builtin_constant_p((__u16)(x)) ? ___constant_swab16(x) : __fswab16(x)) and __builtin_constant_p((__u32)(x)) ? ___constant_swab32(x) : __fswab32(x)) clang/llvm support __builtin_constant_p GCC extension [1]: : Clang supports a number of builtin library functions with the same : syntax as GCC, including things like __builtin_nan, __builtin_constant_p, : __builtin_choose_expr, __builtin_types_compatible_p, : __builtin_assume_aligned, __sync_fetch_and_add, etc. So clang should be able to detect swab on a compile time constant and optimize it. [1] https://clang.llvm.org/docs/LanguageExtensions.html -ss
Re: [PATCHv2 bpf-next 2/3] bpf, tests: drop unused __bpf_constant_foo defines
And this one is the last one - 3/3. -ss
Re: [PATCHv2 bpf-next 3/3] bpf, tests: don't use __bpf_constant_htons()
Yikes... This is actually - 2/3 -ss
[PATCHv2 bpf-next 3/3] bpf, tests: don't use __bpf_constant_htons()
Prefer bpf_htons() instead. Signed-off-by: Sergey Senozhatsky --- tools/testing/selftests/bpf/prog_tests/flow_dissector.c | 4 ++-- tools/testing/selftests/bpf/test_progs.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c index bcbd928c96ab..a194305f98d1 100644 --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c @@ -28,7 +28,7 @@ static struct bpf_flow_keys pkt_v4_flow_keys = { .thoff = sizeof(struct iphdr), .addr_proto = ETH_P_IP, .ip_proto = IPPROTO_TCP, - .n_proto = __bpf_constant_htons(ETH_P_IP), + .n_proto = bpf_htons(ETH_P_IP), }; static struct bpf_flow_keys pkt_v6_flow_keys = { @@ -36,7 +36,7 @@ static struct bpf_flow_keys pkt_v6_flow_keys = { .thoff = sizeof(struct ipv6hdr), .addr_proto = ETH_P_IPV6, .ip_proto = IPPROTO_TCP, - .n_proto = __bpf_constant_htons(ETH_P_IPV6), + .n_proto = bpf_htons(ETH_P_IPV6), }; void test_flow_dissector(void) diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c index 5d10aee9e277..909b339f97f4 100644 --- a/tools/testing/selftests/bpf/test_progs.c +++ b/tools/testing/selftests/bpf/test_progs.c @@ -11,18 +11,18 @@ int error_cnt, pass_cnt; bool jit_enabled; struct ipv4_packet pkt_v4 = { - .eth.h_proto = __bpf_constant_htons(ETH_P_IP), + .eth.h_proto = bpf_htons(ETH_P_IP), .iph.ihl = 5, .iph.protocol = IPPROTO_TCP, - .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES), + .iph.tot_len = bpf_htons(MAGIC_BYTES), .tcp.urg_ptr = 123, .tcp.doff = 5, }; struct ipv6_packet pkt_v6 = { - .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6), + .eth.h_proto = bpf_htons(ETH_P_IPV6), .iph.nexthdr = IPPROTO_TCP, - .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES), + .iph.payload_len = bpf_htons(MAGIC_BYTES), .tcp.urg_ptr = 123, .tcp.doff = 5, }; -- 2.21.0
[PATCHv2 bpf-next 1/3] bpf, tests: tweak endianness selection
Not all compilers have __builtin_bswap16() and __builtin_bswap32(), thus not all compilers are able to compile the following code: (__builtin_constant_p(x) ? \ ___constant_swab16(x) : __builtin_bswap16(x)) That's the reason why bpf_ntohl() doesn't work on GCC < 4.8, for instance: error: implicit declaration of function '__builtin_bswap16' We can use __builtin_bswap16() only if compiler has this built-in, that is, only if __HAVE_BUILTIN_BSWAP16__ is defined. Standard UAPI __swab16()/__swab32() take care of that, and, additionally, handle __builtin_constant_p() cases as well: #ifdef __HAVE_BUILTIN_BSWAP16__ #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) #else #define __swab16(x) \ (__builtin_constant_p((__u16)(x)) ? \ ___constant_swab16(x) : \ __fswab16(x)) #endif So we can tweak selftests/bpf/bpf_endian.h and use UAPI __swab16()/__swab32(). Signed-off-by: Sergey Senozhatsky --- v2: fixed build error, reshuffled patches (Stanislav Fomichev) tools/testing/selftests/bpf/bpf_endian.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/tools/testing/selftests/bpf/bpf_endian.h index b25595ea4a78..1ed268b2002b 100644 --- a/tools/testing/selftests/bpf/bpf_endian.h +++ b/tools/testing/selftests/bpf/bpf_endian.h @@ -20,12 +20,12 @@ * use different targets. */ #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ -# define __bpf_ntohs(x)__builtin_bswap16(x) -# define __bpf_htons(x)__builtin_bswap16(x) +# define __bpf_ntohs(x)__swab16(x) +# define __bpf_htons(x)__swab16(x) # define __bpf_constant_ntohs(x) ___constant_swab16(x) # define __bpf_constant_htons(x) ___constant_swab16(x) -# define __bpf_ntohl(x)__builtin_bswap32(x) -# define __bpf_htonl(x)__builtin_bswap32(x) +# define __bpf_ntohl(x)__swab32(x) +# define __bpf_htonl(x)__swab32(x) # define __bpf_constant_ntohl(x) ___constant_swab32(x) # define __bpf_constant_htonl(x) ___constant_swab32(x) #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ -- 2.21.0
[PATCHv2 bpf-next 2/3] bpf, tests: drop unused __bpf_constant_foo defines
Additionally, simplify bpf_ntohs/bpf_ntohl/bpf_htons/bpf_htonl by switching to UAPI swab(). Signed-off-by: Sergey Senozhatsky --- tools/testing/selftests/bpf/bpf_endian.h | 37 +--- 1 file changed, 8 insertions(+), 29 deletions(-) diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/tools/testing/selftests/bpf/bpf_endian.h index 1ed268b2002b..ba06222963d5 100644 --- a/tools/testing/selftests/bpf/bpf_endian.h +++ b/tools/testing/selftests/bpf/bpf_endian.h @@ -20,38 +20,17 @@ * use different targets. */ #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ -# define __bpf_ntohs(x)__swab16(x) -# define __bpf_htons(x)__swab16(x) -# define __bpf_constant_ntohs(x) ___constant_swab16(x) -# define __bpf_constant_htons(x) ___constant_swab16(x) -# define __bpf_ntohl(x)__swab32(x) -# define __bpf_htonl(x)__swab32(x) -# define __bpf_constant_ntohl(x) ___constant_swab32(x) -# define __bpf_constant_htonl(x) ___constant_swab32(x) +# define bpf_ntohs(x) __swab16(x) +# define bpf_htons(x) __swab16(x) +# define bpf_ntohl(x) __swab32(x) +# define bpf_htonl(x) __swab32(x) #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ -# define __bpf_ntohs(x)(x) -# define __bpf_htons(x)(x) -# define __bpf_constant_ntohs(x) (x) -# define __bpf_constant_htons(x) (x) -# define __bpf_ntohl(x)(x) -# define __bpf_htonl(x)(x) -# define __bpf_constant_ntohl(x) (x) -# define __bpf_constant_htonl(x) (x) +# define bpf_ntohs(x) (x) +# define bpf_htons(x) (x) +# define bpf_ntohl(x) (x) +# define bpf_htonl(x) (x) #else # error "Fix your compiler's __BYTE_ORDER__?!" #endif -#define bpf_htons(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_htons(x) : __bpf_htons(x)) -#define bpf_ntohs(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_ntohs(x) : __bpf_ntohs(x)) -#define bpf_htonl(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_htonl(x) : __bpf_htonl(x)) -#define bpf_ntohl(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_ntohl(x) : __bpf_ntohl(x)) - #endif /* __BPF_ENDIAN__ */ -- 2.21.0
Re: [PATCH] bpf, tests: tweak endianness selection
On (03/19/19 09:01), Stanislav Fomichev wrote: > > diff --git a/tools/testing/selftests/bpf/bpf_endian.h > > b/tools/testing/selftests/bpf/bpf_endian.h > > index b25595ea4a78..ba06222963d5 100644 > > --- a/tools/testing/selftests/bpf/bpf_endian.h > > +++ b/tools/testing/selftests/bpf/bpf_endian.h > > @@ -20,38 +20,17 @@ > > * use different targets. > > */ > > #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ > > -# define __bpf_ntohs(x)__builtin_bswap16(x) > > -# define __bpf_htons(x)__builtin_bswap16(x) > > -# define __bpf_constant_ntohs(x) ___constant_swab16(x) > > -# define __bpf_constant_htons(x) ___constant_swab16(x) > This breaks the build until your next patch is applied (in other > words, breaks bisection). Can we do it in three steps? Bummer! I thought about applying the second patch (flow_dissector.c) first and then the first one (bpf/bpf_endian.h). > Convert to swab (without breaking existing tests), convert the tests, > remove unused __bpf_xyz defines? OK. > Could you also send it as a series (git format-patch --thread)? Those > patches depend on each other. And pls use [PATCH bpf-next] ... subj. Right. I figured out that I also need to patch flow_dissector.c after I sent out bpf/bpf_endian.h patch. Sorry about that, will fix. -ss
[PATCH] bpf, tests: don't use __bpf_constant_htons()
Prefer bpf_htons() instead (since __bpf_constant_htons() was removed). Signed-off-by: Sergey Senozhatsky --- tools/testing/selftests/bpf/prog_tests/flow_dissector.c | 4 ++-- tools/testing/selftests/bpf/test_progs.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c index bcbd928c96ab..a194305f98d1 100644 --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c @@ -28,7 +28,7 @@ static struct bpf_flow_keys pkt_v4_flow_keys = { .thoff = sizeof(struct iphdr), .addr_proto = ETH_P_IP, .ip_proto = IPPROTO_TCP, - .n_proto = __bpf_constant_htons(ETH_P_IP), + .n_proto = bpf_htons(ETH_P_IP), }; static struct bpf_flow_keys pkt_v6_flow_keys = { @@ -36,7 +36,7 @@ static struct bpf_flow_keys pkt_v6_flow_keys = { .thoff = sizeof(struct ipv6hdr), .addr_proto = ETH_P_IPV6, .ip_proto = IPPROTO_TCP, - .n_proto = __bpf_constant_htons(ETH_P_IPV6), + .n_proto = bpf_htons(ETH_P_IPV6), }; void test_flow_dissector(void) diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c index 5d10aee9e277..909b339f97f4 100644 --- a/tools/testing/selftests/bpf/test_progs.c +++ b/tools/testing/selftests/bpf/test_progs.c @@ -11,18 +11,18 @@ int error_cnt, pass_cnt; bool jit_enabled; struct ipv4_packet pkt_v4 = { - .eth.h_proto = __bpf_constant_htons(ETH_P_IP), + .eth.h_proto = bpf_htons(ETH_P_IP), .iph.ihl = 5, .iph.protocol = IPPROTO_TCP, - .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES), + .iph.tot_len = bpf_htons(MAGIC_BYTES), .tcp.urg_ptr = 123, .tcp.doff = 5, }; struct ipv6_packet pkt_v6 = { - .eth.h_proto = __bpf_constant_htons(ETH_P_IPV6), + .eth.h_proto = bpf_htons(ETH_P_IPV6), .iph.nexthdr = IPPROTO_TCP, - .iph.payload_len = __bpf_constant_htons(MAGIC_BYTES), + .iph.payload_len = bpf_htons(MAGIC_BYTES), .tcp.urg_ptr = 123, .tcp.doff = 5, }; -- 2.21.0
[PATCH] bpf, tests: tweak endianness selection
Not all compilers have __builtin_bswap16() and __builtin_bswap32(), thus not all compilers are able to compile the following code (bpf_htons): (__builtin_constant_p(x) ? \ ___constant_swab16(x) : __builtin_bswap16(x)) That's why, for instance, bpf_htons() doesn't work on GCC < 4.8: error: implicit declaration of function '__builtin_bswap16' We can use __builtin_bswap16() only if compiler has this built-in, that is, only if __HAVE_BUILTIN_BSWAP16__ is defined. Standard UAPI __swab16()/__swab32() take care of that, and, additionally, handle __builtin_constant_p() cases as well (if compiler doesn't provide builtin bswap with constants folding): #ifdef __HAVE_BUILTIN_BSWAP16__ #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) #else #define __swab16(x) \ (__builtin_constant_p((__u16)(x)) ? \ ___constant_swab16(x) : \ __fswab16(x)) #endif So we can tweak selftests/bpf/bpf_endian.h and use UAPI __swab16()/__swab32(). Signed-off-by: Sergey Senozhatsky --- tools/testing/selftests/bpf/bpf_endian.h | 37 +--- 1 file changed, 8 insertions(+), 29 deletions(-) diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/tools/testing/selftests/bpf/bpf_endian.h index b25595ea4a78..ba06222963d5 100644 --- a/tools/testing/selftests/bpf/bpf_endian.h +++ b/tools/testing/selftests/bpf/bpf_endian.h @@ -20,38 +20,17 @@ * use different targets. */ #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ -# define __bpf_ntohs(x)__builtin_bswap16(x) -# define __bpf_htons(x)__builtin_bswap16(x) -# define __bpf_constant_ntohs(x) ___constant_swab16(x) -# define __bpf_constant_htons(x) ___constant_swab16(x) -# define __bpf_ntohl(x)__builtin_bswap32(x) -# define __bpf_htonl(x)__builtin_bswap32(x) -# define __bpf_constant_ntohl(x) ___constant_swab32(x) -# define __bpf_constant_htonl(x) ___constant_swab32(x) +# define bpf_ntohs(x) __swab16(x) +# define bpf_htons(x) __swab16(x) +# define bpf_ntohl(x) __swab32(x) +# define bpf_htonl(x) __swab32(x) #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ -# define __bpf_ntohs(x)(x) -# define __bpf_htons(x)(x) -# define __bpf_constant_ntohs(x) (x) -# define __bpf_constant_htons(x) (x) -# define __bpf_ntohl(x)(x) -# define __bpf_htonl(x)(x) -# define __bpf_constant_ntohl(x) (x) -# define __bpf_constant_htonl(x) (x) +# define bpf_ntohs(x) (x) +# define bpf_htons(x) (x) +# define bpf_ntohl(x) (x) +# define bpf_htonl(x) (x) #else # error "Fix your compiler's __BYTE_ORDER__?!" #endif -#define bpf_htons(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_htons(x) : __bpf_htons(x)) -#define bpf_ntohs(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_ntohs(x) : __bpf_ntohs(x)) -#define bpf_htonl(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_htonl(x) : __bpf_htonl(x)) -#define bpf_ntohl(x) \ - (__builtin_constant_p(x) ? \ -__bpf_constant_ntohl(x) : __bpf_ntohl(x)) - #endif /* __BPF_ENDIAN__ */ -- 2.21.0
Re: INFO: rcu detected stall in vprintk_func
On (04/02/18 10:54), Sergey Senozhatsky wrote: > > > If you forward the report, please keep this part and the footer. > > > > > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU [..] > diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c > index ef4026a23e80..a309a27581da 100644 > --- a/net/nfc/llcp_core.c > +++ b/net/nfc/llcp_core.c > @@ -1386,7 +1386,7 @@ static void nfc_llcp_recv_agf(struct nfc_llcp_local > *local, struct sk_buff *skb) > > new_skb = nfc_alloc_recv_skb(pdu_len, GFP_KERNEL); > if (new_skb == NULL) { > - pr_err("Could not allocate PDU\n"); > + pr_err_ratelimited("Could not allocate PDU\n"); > return; > } And of course I ended up patching the wrong function... What I actually meant was: --- diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c index 2ceefa183cee..2f3becb709b8 100644 --- a/net/nfc/llcp_commands.c +++ b/net/nfc/llcp_commands.c @@ -755,7 +755,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 ssap, u8 dsap, pdu = nfc_alloc_send_skb(sock->dev, &sock->sk, MSG_DONTWAIT, frag_len + LLCP_HEADER_SIZE, &err); if (pdu == NULL) { - pr_err("Could not allocate PDU\n"); + pr_err_ratelimited("Could not allocate PDU\n"); continue; }
Re: INFO: rcu detected stall in vprintk_default
On (04/01/18 12:52), Dmitry Vyukov wrote: > > Seems to be the same as: > > #syz dup: INFO: rcu detected stall in vprintk_func > > +nfc maintainers Yes, seems to be the same issue. -ss
Re: INFO: rcu detected stall in vprintk_func
On (04/01/18 12:51), Dmitry Vyukov wrote: [..] > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+3f28bd18291266ec8...@syzkaller.appspotmail.com > > It will help syzbot understand when the bug is fixed. See footer for > > details. > > If you forward the report, please keep this part and the footer. > > > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU > > llcp: nfc_llcp_send_ui_frame: Could not allocate PDU Yes, this thing do { remote_miu = sock->remote_miu > LLCP_MAX_MIU ? local->remote_miu : sock->remote_miu; frag_len = min_t(size_t, remote_miu, remaining_len); pr_debug("Fragment %zd bytes remaining %zd", frag_len, remaining_len); pdu = nfc_alloc_send_skb(sock->dev, &sock->sk, MSG_DONTWAIT, frag_len + LLCP_HEADER_SIZE, &err); if (pdu == NULL) { pr_err("Could not allocate PDU\n"); continue; } is basically do { pr_err("Could not allocate PDU\n"); } while (1) Can cause problems sometimes. But this loop is a bit worrisome even without the printk() call. >From printk() side, we only can do rate limiting here. Would be great if nfc maintainers could take a look and tweak the loop maybe. --- diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c index ef4026a23e80..a309a27581da 100644 --- a/net/nfc/llcp_core.c +++ b/net/nfc/llcp_core.c @@ -1386,7 +1386,7 @@ static void nfc_llcp_recv_agf(struct nfc_llcp_local *local, struct sk_buff *skb) new_skb = nfc_alloc_recv_skb(pdu_len, GFP_KERNEL); if (new_skb == NULL) { - pr_err("Could not allocate PDU\n"); + pr_err_ratelimited("Could not allocate PDU\n"); return; }
Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
On (12/07/17 16:17), Tobin C. Harding wrote: [..] > > hm, indeed. and !CONFIG_KALLSYMS config turns %pS/%ps > > into special_hex_number(). > > But totally misses this :( > > "" would be better returned when !CONFIG_KALLSYMS, right? I guess I'll take back my comment. I assume there are tons of embedded devices that have !CONFIG_KALLSYMS in 'release' builds, yet those devices still warn/oops sometimes; having pointers/hex numbers is really the only way to make any sense out of backtraces... yet it, basically, means that we are leaking kernel pointers. -ss
Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
On (12/06/17 09:32), Geert Uytterhoeven wrote: [..] > >> show_fault_oops(struct pt_regs *regs, unsigned long error_code, > >> unsigned long address) > >> ... > >> printk(KERN_CONT " at %p\n", (void *) address); > >> printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip); > > > > So %pS isn't %p, and shows the symbolic name. > > If the symbolic name is available. > Else it prints the non-hashed pointer value (FTR). hm, indeed. and !CONFIG_KALLSYMS config turns %pS/%ps into special_hex_number(). -ss
Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
On (12/05/17 17:59), Linus Torvalds wrote: [..] > On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky > wrote: > > I see some %p-s being used in _supposedly_ important output, > > like arch/x86/mm/fault.c > > > > show_fault_oops(struct pt_regs *regs, unsigned long error_code, > > unsigned long address) > > ... > > printk(KERN_CONT " at %p\n", (void *) address); > > printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip); > > So %pS isn't %p, and shows the symbolic name. sure, agreed. by "some %p-s being used" I meant the grep result, not just x86 show_fault_oops(). > But yes, that "at %p" should definitely be %px. more %p grepping [filtering out all `%ps %pf %pb' variants] gives a huge number of print outs that potentially can be broken now arch/x86/kernel/kprobes/core.c: printk(KERN_WARNING "Unrecoverable kprobe detected at %p.\n", arch/x86/kernel/kprobes/core.c:"current sp %p does not match saved sp %p\n", arch/x86/kernel/kprobes/core.c: printk(KERN_ERR "Saved registers for jprobe %p\n", jp); arch/x86/kernel/head_32.S: .asciz "Unknown interrupt or fault at: %p %p %p\n" arch/x86/kernel/irq_32.c: printk(KERN_DEBUG "CPU %u irqstacks, hard=%p soft=%p\n", arch/x86/kernel/smpboot.c: pr_debug("Stack at about %p\n", &cpuid); arch/x86/kernel/traps.c:printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is %p..%p)\n", so I'm not in position to suggest the removal of those print outs or to decide if those are important at all, just saying that that "I'm confused by pointer values and can't debug" might be more likely that we thought. > So my gut feel is that those printouts should probably just be > removed. They have some very old historical reasons: we've printed out > the page directory pointers (and followed the page tables) since at > least back in the 1.1.x days. This is from the 1.1.7 patch, back when > mm/memory.c was all about x86: I see, thanks. -ss
Re: [PATCH V11 4/5] vsprintf: add printk specifier %px
Hello, On (12/05/17 13:22), Linus Torvalds wrote: [..] > It's not like those hex numbers were really helping people anyway. > We've turned off most of them on x86 oops reports long ago (and > entirely independently of the pointer hashing). Having stared at a lot > of oopses in my time, the only hex numbers that tend to be really > relevant are (a) the register contents (which aren't %p anyway), and > things like the faulting address (which is not, and never has been, %p > on x86, but might be on some other architecture). I see some %p-s being used in _supposedly_ important output, like arch/x86/mm/fault.c show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long address) ... printk(KERN_CONT " at %p\n", (void *) address); printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip); a quick %p grep gives me the following list: arch/arm/mm/fault.c:pr_alert("pgd = %p\n", mm->pgd); arch/arm64/mm/fault.c: pr_alert("%s pgtable: %luk pages, %u-bit VAs, pgd = %p\n", arch/arm64/mm/fault.c: pr_info_ratelimited("%s[%d]: %s exception: pc=%p sp=%p\n", arch/m68k/mm/fault.c: pr_debug("send_fault_sig: %p,%d,%d\n", siginfo.si_addr, arch/m68k/mm/fault.c: pr_cont(" at virtual address %p\n", siginfo.si_addr); arch/m68k/mm/fault.c: pr_debug("do page fault:\nregs->sr=%#x, regs->pc=%#lx, address=%#lx, %ld, %p\n", arch/microblaze/mm/fault.c: pr_emerg("Page fault in user mode with faulthandler_disabled(), mm = %p\n", arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pgd entry %p: %016Lx\n", arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pmd entry %p: %016Lx\n", arch/mn10300/mm/fault.c:printk(KERN_DEBUG "pte entry %p: %016Lx\n", arch/mn10300/mm/fault.c:printk(KERN_DEBUG "--- do_page_fault(%p,%s:%04lx,%08lx)\n", arch/powerpc/mm/fault.c: " mm=%p\n", arch/sh/mm/fault.c: printk(KERN_ALERT "pgd = %p\n", pgd); arch/unicore32/mm/fault.c: printk(KERN_ALERT "pgd = %p\n", mm->pgd); arch/x86/mm/fault.c:printk(KERN_CONT " at %p\n", (void *) address); arch/x86/mm/fault.c:printk(KERN_ALERT "IP: %pS\n", (void *)regs->ip); arch/x86/mm/fault.c:printk("%s%s[%d]: segfault at %lx ip %p sp %p error %lx", or is it OK to show hashes instead of pgd or pmd pointers? -ss
Re: [PATCH V11 0/5] hash addresses printed with %p
On (11/30/17 19:26), Sergey Senozhatsky wrote: > On (11/30/17 10:23), David Laight wrote: > [..] > > > Maybe I'm being thick, but... if we're rendering these addresses > > > unusable by hashing them, why not just print something like > > > "" in their place? That loses the uniqueness thing but I > > > wonder how valuable that is in practice? > > > > My worry is that is you get a kernel 'oops' print with actual register > > values you have no easy way of tying an address or address+offset to > > the corresponding hash(address) printed elsewhere. > > print the existing hash:pointer mappings in panic()? [if we can do that] by this I meant "when oops_in_progress == 1 then print hash:pointer for %p, not just hash". -ss
Re: [PATCH V11 0/5] hash addresses printed with %p
On (11/30/17 10:23), David Laight wrote: [..] > > Maybe I'm being thick, but... if we're rendering these addresses > > unusable by hashing them, why not just print something like > > "" in their place? That loses the uniqueness thing but I > > wonder how valuable that is in practice? > > My worry is that is you get a kernel 'oops' print with actual register > values you have no easy way of tying an address or address+offset to > the corresponding hash(address) printed elsewhere. print the existing hash:pointer mappings in panic()? [if we can do that] -ss
Re: [PATCH] kallsyms: don't leak address when printing symbol
On (11/08/17 22:35), Steven Rostedt wrote: > On Thu, 9 Nov 2017 12:50:29 +1100 > "Tobin C. Harding" wrote: > > > Currently if a pointer is printed using %p[ssB] and the symbol is not > > found (kallsyms_lookup() fails) then we print the actual address. This > > leaks kernel addresses. We should instead print something _safe_. > > > > Print "" instead of kernel address. > > Ug, ftrace requires this to work as is, as it uses it to print some > addresses that may or may not be a symbol. > > If anything, can this return a success or failure if it were to find a > symbol or not, and then something like ftrace could decide to use %x if > it does not. > > And yes, ftrace leaks kernel addresses all over the place, that's just > the nature of tracing the kernel. > agree, I kinda suspect that that "0x%lx" sometimes can be useful. at least one can tell if the frame is from modules or kernel, and objdump it may be. -ss
Re: linux-next: Tree for Jul 26
Hello, On (07/26/17 13:09), Rosen, Rami wrote: > Hi Sergey, > Paolo Abeni had sent a patch: > https://www.mail-archive.com/netdev@vger.kernel.org/msg179192.html yep, this should do the trick. thanks. -ss
Re: linux-next: Tree for Jul 26
Hello, On (07/26/17 16:12), Stephen Rothwell wrote: > Hi all, > > Changes since 20170725: > > Non-merge commits (relative to Linus' tree): 2358 > 2466 files changed, 86994 insertions(+), 44655 deletions(-) dce4551cb2adb1ac ("udp: preserve head state for IP_CMSG_PASSSEC") causes a build error net/ipv4/udp.c: In function ‘__udp_queue_rcv_skb’: net/ipv4/udp.c:1789:49: error: ‘struct sk_buff’ has no member named ‘sp’; did you mean ‘sk’? if (likely(IPCB(skb)->opt.optlen == 0 && !skb->sp)) ^ -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
On (10/13/16 14:49), Andy Lutomirski wrote: [..] > > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 > > > >> 39) == 130 > > > > Yeah, we already know that in this function the aad variable is on the > > stack, it explicitly is. > > > > The question, though, is why precisely that fails in the crypto code. > > Can you send the Oops report itself? > > > > It's failing before that. With CONFIG_VMAP_STACK=y, the stack may not > be physically contiguous and can't be used for DMA, so putting it in a > scatterlist is bogus in general, and the crypto code mostly wants a > scatterlist. > > There are a couple (faster!) APIs for crypto that don't use > scatterlists, but I don't think AEAD works with them. given that we have a known issue shouldn't VMAP_STACK be disabled for now, or would you rather prefer to mark MAC80211 as incompatible: "depends on CFG80211 && !VMAP_STACK"? -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
On (10/14/16 00:00), Sergey Senozhatsky wrote: > kernel: [] ieee80211_crypto_ccmp_decrypt+0x204/0x298 > kernel: [] ieee80211_rx_handlers+0x7df/0x1c1d > kernel: [] ieee80211_prepare_and_rx_handle+0xdc2/0xe79 > kernel: [] ? ieee80211_rx_napi+0x168/0x7b6 > kernel: [] ieee80211_rx_napi+0x48b/0x7b6 > kernel: [] ? debug_smp_processor_id+0x17/0x19 > kernel: [] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm] > kernel: [] iwl_mvm_rx+0x7e/0x98 [iwlmvm] > kernel: [] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi] > kernel: [] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi] > kernel: [] ? irq_finalize_oneshot+0xd4/0xd4 > kernel: [] irq_thread_fn+0x1d/0x34 > kernel: [] irq_thread+0xe6/0x1bb > kernel: [] ? wake_threads_waitq+0x2c/0x2c > kernel: [] ? irq_thread_dtor+0x95/0x95 > kernel: [] kthread+0xfc/0x104 > kernel: [] ? put_lock_stats.isra.9+0xe/0x20 > kernel: [] ? kthread_create_on_node+0x3f/0x3f > kernel: [] ret_from_fork+0x22/0x30 > kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 > c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 > 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d > kernel: RIP [] ieee80211_aes_ccm_decrypt+0x107/0x27f 8146d1ed : 8146d1ed: e8 9e 67 04 00 callq 814b3990 <__fentry__> 8146d1f2: 55 push %rbp 8146d1f3: 48 89 e5mov%rsp,%rbp 8146d1f6: 41 57 push %r15 8146d1f8: 41 56 push %r14 8146d1fa: 49 89 cemov%rcx,%r14 8146d1fd: 41 55 push %r13 8146d1ff: 41 54 push %r12 8146d201: 53 push %rbx 8146d202: 48 83 c4 80 add$0xff80,%rsp 8146d206: 8b 47 04mov0x4(%rdi),%eax 8146d209: 48 8d 48 50 lea0x50(%rax),%rcx 8146d20d: 48 83 c0 5e add$0x5e,%rax 8146d211: 48 c1 e8 03 shr$0x3,%rax 8146d215: 48 c1 e0 03 shl$0x3,%rax 8146d219: 48 29 c4sub%rax,%rsp 8146d21c: 4c 8d 7c 24 07 lea0x7(%rsp),%r15 8146d221: 49 c1 ef 03 shr$0x3,%r15 8146d225: 4d 85 c0test %r8,%r8 8146d228: 4a 8d 04 fd 00 00 00lea0x0(,%r15,8),%rax 8146d22f: 00 8146d230: 48 89 85 70 ff ff ffmov%rax,-0x90(%rbp) 8146d237: 75 0a jne8146d243 8146d239: b8 ea ff ff ff mov$0xffea,%eax 8146d23e: e9 1a 02 00 00 jmpq 8146d45d 8146d243: 31 c0 xor%eax,%eax 8146d245: 49 89 fcmov%rdi,%r12 8146d248: 49 89 f5mov%rsi,%r13 8146d24b: 4c 89 85 58 ff ff ffmov%r8,-0xa8(%rbp) 8146d252: 4a 8d 3c fd 00 00 00lea0x0(,%r15,8),%rdi 8146d259: 00 8146d25a: be 03 00 00 00 mov$0x3,%esi 8146d25f: 4c 89 cbmov%r9,%rbx 8146d262: 48 89 95 60 ff ff ffmov%rdx,-0xa0(%rbp) 8146d269: f3 aa rep stos %al,%es:(%rdi) 8146d26b: 48 8d 85 78 ff ff fflea-0x88(%rbp),%rax 8146d272: 48 89 c7mov%rax,%rdi 8146d275: 48 89 85 68 ff ff ffmov%rax,-0x98(%rbp) 8146d27c: e8 46 06 dc ff callq 8122d8c7 8146d281: 48 8b 95 60 ff ff ffmov-0xa0(%rbp),%rdx 8146d288: 41 b9 00 00 00 80 mov$0x8000,%r9d 8146d28e: 48 8b 0d 7b cd 39 00mov0x39cd7b(%rip),%rcx # 8180a010 8146d295: 48 8b 85 68 ff ff ffmov-0x98(%rbp),%rax 8146d29c: 4c 8b 85 58 ff ff ffmov-0xa8(%rbp),%r8 8146d2a3: 0f b7 32movzwl (%rdx),%esi 8146d2a6: 48 83 c2 02 add$0x2,%rdx 8146d2aa: 89 d7 mov%edx,%edi 8146d2ac: 81 e7 ff 0f 00 00 and$0xfff,%edi 8146d2b2: 66 c1 c6 08 rol$0x8,%si 8146d2b6: 4c 01 caadd%r9,%rdx 8146d2b9: 0f b7 f6movzwl %si,%esi 8146d2bc: 72 0a jb 8146d2c8 8146d2be: 48 b9 00 00 00 80 ffmovabs $0x77ff8000,%rcx 8146d2c5: 77 00 00 8146d2c8: 48 01 caadd%rcx,%rdx 8146d2c
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
On (10/13/16 15:45), Johannes Berg wrote: > On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi > > > > t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd > > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi > > > > t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8 > > > > > > That truly sounds like something we'd rather avoid in the TX/RX > > > paths though, which should perform well. > > > > didn't fix. > > It couldn't, since the new helpers weren't used in mac80211 in those > patches yet. indeed. I thought they were. > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 > > >> 39) == 130 > > The question, though, is why precisely that fails in the crypto code. > Can you send the Oops report itself? kernel: BUG: unable to handle kernel NULL pointer dereference at (null) kernel: IP: [] ieee80211_aes_ccm_decrypt+0x107/0x27f kernel: PGD 0 kernel: kernel: Oops: [#1] PREEMPT SMP kernel: Modules linked in: nls_iso8859_1 nls_cp437 vfat fat mousedev psmouse serio_raw atkbd libps2 i915 coretemp i2c_algo_bit hwmon crc32c_intel mxm_wmi drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect iwlmvm sysimgblt fb_sys_fops i2c_i801 cfbcopyarea ie31200_edac drm iwlwifi i2c kernel: CPU: 3 PID: 245 Comm: irq/28-iwlwifi Not tainted 4.8.0-next-20161013-dbg-2-ge789862-dirty #112 kernel: task: 88041bf01800 task.stack: c92d kernel: RIP: 0010:[] [] ieee80211_aes_ccm_decrypt+0x107/0x27f kernel: RSP: 0018:c92d3770 EFLAGS: 00010246 kernel: RAX: c92d3930 RBX: 8804133cf606 RCX: 00082000 kernel: RDX: RSI: 0018 RDI: 0a02 kernel: RBP: c92d39b8 R08: 05e4 R09: 000412d3 kernel: R10: 001c R11: 8803e66d2d20 R12: 8804191c2780 kernel: R13: c92d39f0 R14: 8804133cf022 R15: 1925a6ee kernel: FS: () GS:88041ea0() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: CR3: 01805000 CR4: 001406e0 kernel: Stack: kernel: kernel: kernel: kernel: Call Trace: kernel: [] ieee80211_crypto_ccmp_decrypt+0x204/0x298 kernel: [] ieee80211_rx_handlers+0x7df/0x1c1d kernel: [] ieee80211_prepare_and_rx_handle+0xdc2/0xe79 kernel: [] ? ieee80211_rx_napi+0x168/0x7b6 kernel: [] ieee80211_rx_napi+0x48b/0x7b6 kernel: [] ? debug_smp_processor_id+0x17/0x19 kernel: [] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm] kernel: [] iwl_mvm_rx+0x7e/0x98 [iwlmvm] kernel: [] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi] kernel: [] iwl_pcie_irq_handler+0x46f/0x65f [iwlwifi] kernel: [] ? irq_finalize_oneshot+0xd4/0xd4 kernel: [] irq_thread_fn+0x1d/0x34 kernel: [] irq_thread+0xe6/0x1bb kernel: [] ? wake_threads_waitq+0x2c/0x2c kernel: [] ? irq_thread_dtor+0x95/0x95 kernel: [] kthread+0xfc/0x104 kernel: [] ? put_lock_stats.isra.9+0xe/0x20 kernel: [] ? kthread_create_on_node+0x3f/0x3f kernel: [] ret_from_fork+0x22/0x30 kernel: Code: 01 ca 49 89 d1 48 89 d1 48 c1 ea 23 48 8b 14 d5 80 23 63 82 49 c1 e9 0c 48 c1 e9 1b 48 85 d2 74 0a 0f b6 c9 48 c1 e1 04 48 01 ca <48> 8b 12 49 c1 e1 06 b9 00 00 00 80 89 7d 80 89 75 84 48 8b 3d kernel: RIP [] ieee80211_aes_ccm_decrypt+0x107/0x27f kernel: RSP kernel: CR2: kernel: ---[ end trace 3cd1fcd496516f72 ]--- -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
On (10/13/16 22:42), Sergey Senozhatsky wrote: > > On (10/13/16 08:02), Johannes Berg wrote: > > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote: > > > > > In a pinch, I have these patches sitting around: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8 > > > > That truly sounds like something we'd rather avoid in the TX/RX paths > > though, which should perform well. > > didn't fix. > > so I finally had some time to do a better bug-reporter job. > > I added a bunch of printk-s and several virt_addr_valid()-s > to ieee80211_aes_ccm_encrypt(). > > and right befoe the Oops I see the following report from > virt_addr_valid() > > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 >> 39) > == 130 that `(412cba02 >> 39) == 130' part is phys_addr_valid() { (addr >> boot_cpu_data.x86_phys_bits) } -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
On (10/13/16 08:02), Johannes Berg wrote: > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote: > > > In a pinch, I have these patches sitting around: > > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8 > > That truly sounds like something we'd rather avoid in the TX/RX paths > though, which should perform well. didn't fix. so I finally had some time to do a better bug-reporter job. I added a bunch of printk-s and several virt_addr_valid()-s to ieee80211_aes_ccm_encrypt(). and right befoe the Oops I see the following report from virt_addr_valid() FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 >> 39) == 130 which is basically failed '!phys_addr_valid(x)' in __virt_addr_valid() /* carry flag will be set if starting x was >= PAGE_OFFSET */ if ((x > y) || !phys_addr_valid(x)) return false; backtrace [ cut here ] WARNING: CPU: 7 PID: 246 at arch/x86/mm/physaddr.c:68 __virt_addr_valid+0xab/0xed c92cb6f0 8122168c c92cb730 810428d8 00440198 88041bd21022 c92cba02 192596ed 88041932d1e0 c92cba00 Call Trace: [] dump_stack+0x4f/0x65 [] __warn+0xc2/0xdd [] warn_slowpath_null+0x1d/0x1f [] __virt_addr_valid+0xab/0xed [] ieee80211_aes_ccm_decrypt+0x8f/0x2da [] ? debug_smp_processor_id+0x17/0x19 [] ? __put_page+0x3c/0x3f [] ? ccmp_special_blocks.isra.1+0x51/0x12d [] ieee80211_crypto_ccmp_decrypt+0x204/0x298 [] ieee80211_rx_handlers+0x7df/0x1c1d [] ieee80211_prepare_and_rx_handle+0xdc2/0xe79 [] ? ieee80211_rx_napi+0x154/0x7a5 [] ieee80211_rx_napi+0x474/0x7a5 [] iwl_mvm_rx_rx_mpdu+0x6e6/0x751 [iwlmvm] [] iwl_mvm_rx+0x7e/0x98 [iwlmvm] [] iwl_pcie_rx_handle+0x523/0x698 [iwlwifi] [] iwl_pcie_irq_handler+0x45d/0x64d [iwlwifi] [] ? irq_finalize_oneshot+0xd4/0xd4 [] irq_thread_fn+0x1d/0x34 [] irq_thread+0xe6/0x1bb [] ? wake_threads_waitq+0x2c/0x2c [] ? irq_thread_dtor+0x95/0x95 [] kthread+0xfc/0x104 [] ? put_lock_stats.isra.9+0xe/0x20 [] ? kthread_create_on_node+0x3f/0x3f [] ? kthread_create_on_node+0x3f/0x3f [] ? kthread_create_on_node+0x3f/0x3f [] ret_from_fork+0x22/0x30 -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
Hello, On (10/12/16 11:05), Johannes Berg wrote: > Sorry - I meant to look into this yesterday but forgot. > > > Andy, can this be related to CONFIG_VMAP_STACK? > > I think it is. yeah, the system works fine with !CONFIG_VMAP_STACK. > > > current -git kills my system. > > Can you elaborate on how exactly it kills your system? the last time I saw it it was a NULL deref at ieee80211_aes_ccm_decrypt. -ss
Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
Cc Andy Andy, can this be related to CONFIG_VMAP_STACK? On (10/11/16 00:03), Sergey Senozhatsky wrote: > Hello, > > current -git kills my system. adding > > if (!virt_addr_valid(&aad[2])) { > WARN_ON(1); > return -EINVAL; > } > > to ieee80211_aes_ccm_decrypt() given the following backtrace > > WARNING: CPU: 5 PID: 252 at net/mac80211/aes_ccm.c:77 > ieee80211_aes_ccm_decrypt+0xc8/0x197 > CPU: 5 PID: 252 Comm: irq/29-iwlwifi Tainted: GW > 4.8.0-next-20161010-dbg-7-g79797e9-dirty #88 > c9413638 811ff0e3 > c9413678 8103fe91 004d01c8 192826d3 > 88040fc526d8 0008 c9413978 c941397a > Call Trace: > [] dump_stack+0x4f/0x65 > [] __warn+0xc2/0xdd > [] warn_slowpath_null+0x1d/0x1f > [] ieee80211_aes_ccm_decrypt+0xc8/0x197 > [] ? __put_page+0x3c/0x3f > [] ? put_page+0x4a/0x62 > [] ? __pskb_pull_tail+0x1e8/0x279 > [] ? ccmp_special_blocks.isra.5+0x51/0x12d > [] ieee80211_crypto_ccmp_decrypt+0x1ba/0x221 > [] ieee80211_rx_handlers+0x52a/0x19c2 > [] ? start_dl_timer+0xa8/0xb4 > [] ? put_lock_stats.isra.24+0xe/0x20 > [] ? del_timer+0x57/0x61 > [] ieee80211_prepare_and_rx_handle+0xcd6/0xd2a > [] ? local_clock+0x10/0x12 > [] ? __lock_acquire.isra.31+0x202/0x57e > [] ? rcu_read_unlock+0x23/0x23 > [] ? sched_clock_cpu+0x17/0xc6 > [] ieee80211_rx_napi+0x5af/0x698 > [] ? get_lock_stats+0x19/0x50 > [] ? put_lock_stats.isra.24+0xe/0x20 > [] iwl_mvm_rx_rx_mpdu+0x5ab/0x60c [iwlmvm] > [] ? get_lock_stats+0x19/0x50 > [] iwl_mvm_rx+0x45/0x69 [iwlmvm] > [] iwl_pcie_rx_handle+0x478/0x584 [iwlwifi] > [] iwl_pcie_irq_handler+0x39c/0x52d [iwlwifi] > [] ? irq_finalize_oneshot+0xa7/0xa7 > [] irq_thread_fn+0x1d/0x34 > [] irq_thread+0xe6/0x1bb > [] ? wake_threads_waitq+0x2c/0x2c > [] ? irq_thread_dtor+0x95/0x95 > [] kthread+0xc6/0xce > [] ? put_lock_stats.isra.24+0xe/0x20 > [] ? __list_del_entry+0x22/0x22 > [] ret_from_fork+0x22/0x30 > ---[ end trace 94da6d4698b938b2 ]--- -ss
[mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
Hello, current -git kills my system. adding if (!virt_addr_valid(&aad[2])) { WARN_ON(1); return -EINVAL; } to ieee80211_aes_ccm_decrypt() given the following backtrace WARNING: CPU: 5 PID: 252 at net/mac80211/aes_ccm.c:77 ieee80211_aes_ccm_decrypt+0xc8/0x197 CPU: 5 PID: 252 Comm: irq/29-iwlwifi Tainted: GW 4.8.0-next-20161010-dbg-7-g79797e9-dirty #88 c9413638 811ff0e3 c9413678 8103fe91 004d01c8 192826d3 88040fc526d8 0008 c9413978 c941397a Call Trace: [] dump_stack+0x4f/0x65 [] __warn+0xc2/0xdd [] warn_slowpath_null+0x1d/0x1f [] ieee80211_aes_ccm_decrypt+0xc8/0x197 [] ? __put_page+0x3c/0x3f [] ? put_page+0x4a/0x62 [] ? __pskb_pull_tail+0x1e8/0x279 [] ? ccmp_special_blocks.isra.5+0x51/0x12d [] ieee80211_crypto_ccmp_decrypt+0x1ba/0x221 [] ieee80211_rx_handlers+0x52a/0x19c2 [] ? start_dl_timer+0xa8/0xb4 [] ? put_lock_stats.isra.24+0xe/0x20 [] ? del_timer+0x57/0x61 [] ieee80211_prepare_and_rx_handle+0xcd6/0xd2a [] ? local_clock+0x10/0x12 [] ? __lock_acquire.isra.31+0x202/0x57e [] ? rcu_read_unlock+0x23/0x23 [] ? sched_clock_cpu+0x17/0xc6 [] ieee80211_rx_napi+0x5af/0x698 [] ? get_lock_stats+0x19/0x50 [] ? put_lock_stats.isra.24+0xe/0x20 [] iwl_mvm_rx_rx_mpdu+0x5ab/0x60c [iwlmvm] [] ? get_lock_stats+0x19/0x50 [] iwl_mvm_rx+0x45/0x69 [iwlmvm] [] iwl_pcie_rx_handle+0x478/0x584 [iwlwifi] [] iwl_pcie_irq_handler+0x39c/0x52d [iwlwifi] [] ? irq_finalize_oneshot+0xa7/0xa7 [] irq_thread_fn+0x1d/0x34 [] irq_thread+0xe6/0x1bb [] ? wake_threads_waitq+0x2c/0x2c [] ? irq_thread_dtor+0x95/0x95 [] kthread+0xc6/0xce [] ? put_lock_stats.isra.24+0xe/0x20 [] ? __list_del_entry+0x22/0x22 [] ret_from_fork+0x22/0x30 ---[ end trace 94da6d4698b938b2 ]--- -ss
Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'
On (10/06/16 06:11), Eric Dumazet wrote: > On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > > > this commit is now in mainline as > > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > > > net/netfilter/core.c: In function 'nf_set_hooks_head': > > net/netfilter/core.c:96:3: error: 'struct net_device' has no member > > named 'nf_hooks_ingress' > > > > Are the fixes (see below) on the way to mainline too? > > Yes the fixes are already in nf tree and _will_ get pushed. > > Pablo and David are attending netdev 1.2 in Tokyo and have obligations. > > https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/ well, I did my best to avoid it, but the guys didn't even bother to reply. pushing a knowingly broken patch that a) kills the build b) introduces a race c) requires two "Fixes:" followup patches to the main line despite the fact that those problems were discovered at linux-next stage is totally un-cool. -ss
Re: linux-next: Tree for Sep 27
On (09/27/16 19:03), Sergey Senozhatsky wrote: > Hello, > > On (09/27/16 16:40), Stephen Rothwell wrote: > > > > Changes since 20160923: > > > > seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with > single linked list") breaks the build on !CONFIG_NETFILTER_INGRESS systems > accessing ->nf_hooks_ingress > > static void nf_set_hooks_head(struct net *net, const struct nf_hook_ops *reg, > struct nf_hook_entry *entry) > { >switch (reg->pf) { >case NFPROTO_NETDEV: >/* We already checked in nf_register_net_hook() that this is > * used from ingress. > */ >rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); > so I see two commits in linux-next now that fix the commit in question in two patches : commit 7816ec564ec40ae20bb7925f733a181cad0cc491 ("netfilter: accommodate : different kconfig in nf_set_hooks_head") : :When CONFIG_NETFILTER_INGRESS is unset (or no), we need to handle :the request for registration properly by dropping the hook. This :releases the entry during the set. : :Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list") and : commit 5119e4381a90fabd3442bde02707cbd9e5d7367a ("netfilter: Fix potential : null pointer dereference") : :It's possible for nf_hook_entry_head to return NULL. If two :nf_unregister_net_hook calls happen simultaneously with a single hook :entry in the list, both will enter the nf_hook_mutex critical section. :The first will successfully delete the head, but the second will see :this NULL pointer and attempt to dereference. : :This fix ensures that no null pointer dereference could occur when such :a condition happens. : :Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list") do you guys plan to fold those into "e3b37f11e6e4" (a preferred way) or will send it out as 3 separate patches (um, why) ? -ss
Re: linux-next: Tree for Sep 27
Hello, On (09/27/16 16:40), Stephen Rothwell wrote: > > Changes since 20160923: > seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with single linked list") breaks the build on !CONFIG_NETFILTER_INGRESS systems accessing ->nf_hooks_ingress static void nf_set_hooks_head(struct net *net, const struct nf_hook_ops *reg, struct nf_hook_entry *entry) { switch (reg->pf) { case NFPROTO_NETDEV: /* We already checked in nf_register_net_hook() that this is * used from ingress. */ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); log: In file included from ./include/linux/linkage.h:4:0, from ./include/linux/kernel.h:6, from net/netfilter/core.c:10: net/netfilter/core.c: In function ‘nf_set_hooks_head’: net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:322:17: note: in definition of macro ‘WRITE_ONCE’ union { typeof(x) __val; char __c[1]; } __u = \ ^ net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^~ net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:323:30: note: in definition of macro ‘WRITE_ONCE’ { .__val = (__force typeof(x)) (val) }; \ ^ net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^~ net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:323:35: note: in definition of macro ‘WRITE_ONCE’ { .__val = (__force typeof(x)) (val) }; \ ^~~ net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^~ net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:324:22: note: in definition of macro ‘WRITE_ONCE’ __write_once_size(&(x), __u.__c, sizeof(x)); \ ^ net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^~ net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:324:42: note: in definition of macro ‘WRITE_ONCE’ __write_once_size(&(x), __u.__c, sizeof(x)); \ ^ net/netfilter/core.c:96:3: note: in expansion of macro ‘rcu_assign_pointer’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^~ In file included from ./include/linux/linkage.h:4:0, from ./include/linux/kernel.h:6, from net/netfilter/core.c:10: net/netfilter/core.c:96:30: error: ‘struct net_device’ has no member named ‘nf_hooks_ingress’ rcu_assign_pointer(reg->dev->nf_hooks_ingress, entry); ^ ./include/linux/compiler.h:498:19: note: in definition of macro ‘__compiletime_assert’ bool __cond = !(condition);\ ^ ./include/linux/compiler.h:518:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^~~ ./include/linux/compiler.h:521:2: note: in expansion of macro ‘compiletime_assert’ compiletime_assert(__native_word(t),\ ^~ ./include/linux/compiler.h:521:21: note: in expansion of macro ‘__native_word’ compiletime_assert(__native_word(t),\ ^ ./arch/x86/include/asm/barrier.h:64:2: note: in expansion of macro ‘compiletime_assert_atomic_type’ compiletime_assert_atomic_type(*p);\ ^~ ./include/asm-generic/barrier.h:157:33: note: in expansion of macro ‘__smp_store_release’ #define smp_store_release(p, v) __smp_store_release(p, v) ^~~ ./include/linux/rcupdate.h:668:3: note: in expansion of macro ‘smp_store_release’ smp_store_release(&p, RCU_INITIALIZER((typeof(p))_r_a_p__v)); \ ^ net/netfilter/core.c:96:3: note: in expansion of macro ‘rc
Re: [linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage
On (05/15/16 01:31), Sergey Senozhatsky wrote: > [11455.550649] === > [11455.550652] [ INFO: suspicious RCU usage. ] > [11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not > tainted > [11455.550660] --- > [11455.550664] drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious > rcu_dereference_protected() usage! > [11455.550667] >other info that might help us debug this: > > [11455.550671] >rcu_scheduler_active = 1, debug_locks = 0 > [11455.550675] 5 locks held by irq/29-iwlwifi/247: > [11455.550677] #0: (sync_cmd_lockdep_map){..}, at: [] > iwl_pcie_irq_handler+0x0/0x635 [iwlwifi] > [11455.550705] #1: (&(&rxq->lock)->rlock){+.+...}, at: [] > iwl_pcie_rx_handle+0x38/0x5d5 [iwlwifi] > [11455.550725] #2: (rcu_read_lock){..}, at: [] > ieee80211_rx_napi+0x152/0x8e2 [mac80211] > [11455.550768] #3: (&(&local->rx_path_lock)->rlock){+.-...}, at: > [] ieee80211_rx_handlers+0x2e/0x1fe1 [mac80211] > [11455.550804] #4: (rcu_read_lock){..}, at: [] > iwl_mvm_update_tkip_key+0x0/0x162 [iwlmvm] > [11455.550833] [ 5406.034379] iwlwifi :02:00.0: Queue 16 stuck for 1 ms. [ 5406.034385] iwlwifi :02:00.0: Current SW read_ptr 98 write_ptr 125 [ 5406.034431] iwl data: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5406.034454] iwlwifi :02:00.0: FH TRBs(0) = 0x8000300f [ 5406.034475] iwlwifi :02:00.0: FH TRBs(1) = 0xc0110071 [ 5406.034491] iwlwifi :02:00.0: FH TRBs(2) = 0x [ 5406.034505] iwlwifi :02:00.0: FH TRBs(3) = 0x8030001e [ 5406.034520] iwlwifi :02:00.0: FH TRBs(4) = 0x [ 5406.034536] iwlwifi :02:00.0: FH TRBs(5) = 0x [ 5406.034551] iwlwifi :02:00.0: FH TRBs(6) = 0x [ 5406.034566] iwlwifi :02:00.0: FH TRBs(7) = 0x00709087 [ 5406.034625] iwlwifi :02:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x [31,31] [ 5406.034690] iwlwifi :02:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x [0,0] [ 5406.034756] iwlwifi :02:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x [17,17] [ 5406.034821] iwlwifi :02:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x [16,16] [ 5406.034886] iwlwifi :02:00.0: Q 4 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.034944] iwlwifi :02:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035010] iwlwifi :02:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035068] iwlwifi :02:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035133] iwlwifi :02:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035192] iwlwifi :02:00.0: Q 9 is active and mapped to fifo 7 ra_tid 0x [136,136] [ 5406.035257] iwlwifi :02:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035323] iwlwifi :02:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035388] iwlwifi :02:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035446] iwlwifi :02:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035505] iwlwifi :02:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035563] iwlwifi :02:00.0: Q 15 is active and mapped to fifo 5 ra_tid 0x [0,0] [ 5406.035622] iwlwifi :02:00.0: Q 16 is active and mapped to fifo 1 ra_tid 0x [98,125] [ 5406.035687] iwlwifi :02:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035752] iwlwifi :02:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035817] iwlwifi :02:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.035883] iwlwifi :02:00.0: Q 20 is inactive and mapped to fifo 0 ra_tid 0xfffc [0,0] [ 5406.035940] iwlwifi :02:00.0: Q 21 is inactive and mapped to fifo 0 ra_tid 0x0003 [0,0] [ 5406.035999] iwlwifi :02:00.0: Q 22 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036064] iwlwifi :02:00.0: Q 23 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036122] iwlwifi :02:00.0: Q 24 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036188] iwlwifi :02:00.0: Q 25 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036246] iwlwifi :02:00.0: Q 26 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036305] iwlwifi :02:00.0: Q 27 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036370] iwlwifi :02:00.0: Q 28 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036428] iwlwifi :02:00.0: Q 29 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036487] iwlwifi :02:00.0: Q 30 is inactive and mapped to fifo 0 ra_tid 0x [0,0] [ 5406.036555] iwlwifi :02:00.0:
[linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage
Hello, [11455.550649] === [11455.550652] [ INFO: suspicious RCU usage. ] [11455.550657] 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 Not tainted [11455.550660] --- [11455.550664] drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage! [11455.550667] other info that might help us debug this: [11455.550671] rcu_scheduler_active = 1, debug_locks = 0 [11455.550675] 5 locks held by irq/29-iwlwifi/247: [11455.550677] #0: (sync_cmd_lockdep_map){..}, at: [] iwl_pcie_irq_handler+0x0/0x635 [iwlwifi] [11455.550705] #1: (&(&rxq->lock)->rlock){+.+...}, at: [] iwl_pcie_rx_handle+0x38/0x5d5 [iwlwifi] [11455.550725] #2: (rcu_read_lock){..}, at: [] ieee80211_rx_napi+0x152/0x8e2 [mac80211] [11455.550768] #3: (&(&local->rx_path_lock)->rlock){+.-...}, at: [] ieee80211_rx_handlers+0x2e/0x1fe1 [mac80211] [11455.550804] #4: (rcu_read_lock){..}, at: [] iwl_mvm_update_tkip_key+0x0/0x162 [iwlmvm] [11455.550833] stack backtrace: [11455.550840] CPU: 4 PID: 247 Comm: irq/29-iwlwifi Not tainted 4.6.0-rc7-next-20160513-dbg-4-g8de8b92-dirty #655 [11455.550844] 880037ff78e8 81187f9c 88041b7ea980 [11455.550854] 0001 880037ff7918 8106b836 88041bc0e028 [11455.550863] 88041d247878 88041bc0e028 880037ff7938 [11455.550872] Call Trace: [11455.550883] [] dump_stack+0x68/0x92 [11455.550890] [] lockdep_rcu_suspicious+0xf7/0x100 [11455.550911] [] iwl_mvm_get_key_sta.part.0+0x5d/0x80 [iwlmvm] [11455.550930] [] iwl_mvm_update_tkip_key+0xd3/0x162 [iwlmvm] [11455.550945] [] iwl_mvm_mac_update_tkip_key+0x17/0x19 [iwlmvm] [11455.550973] [] ieee80211_tkip_decrypt_data+0x22c/0x24b [mac80211] [11455.550996] [] ieee80211_crypto_tkip_decrypt+0xc5/0x110 [mac80211] [11455.551026] [] ieee80211_rx_handlers+0x9bb/0x1fe1 [mac80211] [11455.551035] [] ? __lock_is_held+0x3c/0x57 [11455.551063] [] ieee80211_prepare_and_rx_handle+0xe89/0xf33 [mac80211] [11455.551071] [] ? debug_smp_processor_id+0x17/0x19 [11455.551098] [] ieee80211_rx_napi+0x4bf/0x8e2 [mac80211] [11455.551119] [] iwl_mvm_rx_rx_mpdu+0x6af/0x754 [iwlmvm] [11455.551134] [] iwl_mvm_rx+0x44/0x6d [iwlmvm] [11455.551147] [] iwl_pcie_rx_handle+0x461/0x5d5 [iwlwifi] [11455.551160] [] iwl_pcie_irq_handler+0x452/0x635 [iwlwifi] [11455.551167] [] ? irq_finalize_oneshot+0xc9/0xc9 [11455.551172] [] irq_thread_fn+0x18/0x2f [11455.551176] [] irq_thread+0x108/0x1b0 [11455.551183] [] ? __schedule+0x48d/0x58f [11455.551188] [] ? wake_threads_waitq+0x28/0x28 [11455.551193] [] ? irq_thread_dtor+0x93/0x93 [11455.551198] [] kthread+0xf3/0xfb [11455.551205] [] ? _raw_spin_unlock_irq+0x27/0x45 [11455.551212] [] ret_from_fork+0x1f/0x40 [11455.551217] [] ? kthread_create_on_node+0x1ca/0x1ca -ss
Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage
On (12/12/15 09:05), Sergey Senozhatsky wrote: > On (12/11/15 14:49), Johannes Berg wrote: > > On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote: > > > > > [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 > > > suspicious rcu_dereference_protected() usage! > > > > > > > Funny, Laura Abbott also reported this bug earlier today :) > > > > I've sent out a fix, you can see it here: > > https://patchwork.ozlabs.org/patch/87/ > > > had to replace 'drivers/net/wireless/iwlwifi/mvm/sta.c' with drivers/net/wireless/intel/iwlwifi/mvm/sta.c' I'll report back if any problems show up. -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage
On (12/11/15 14:49), Johannes Berg wrote: > On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote: > > > [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 > > suspicious rcu_dereference_protected() usage! > > > > Funny, Laura Abbott also reported this bug earlier today :) > > I've sent out a fix, you can see it here: > https://patchwork.ozlabs.org/patch/87/ > Great, thanks! -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage
Hi, linux-next 20151211 [ 6385.246285] === [ 6385.246288] [ INFO: suspicious RCU usage. ] [ 6385.246294] 4.4.0-rc4-next-20151211-dbg-00015-g7b65ef3-dirty #302 Not tainted [ 6385.246296] --- [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 suspicious rcu_dereference_protected() usage! [ 6385.246303] other info that might help us debug this: [ 6385.246308] rcu_scheduler_active = 1, debug_locks = 0 [ 6385.246313] 4 locks held by irq/30-iwlwifi/246: [ 6385.246316] #0: (sync_cmd_lockdep_map){..}, at: [] iwl_pcie_irq_handler+0x5/0xaf4 [iwlwifi] [ 6385.246341] #1: (&(&rxq->lock)->rlock){+.+...}, at: [] iwl_pcie_irq_handler+0x427/0xaf4 [iwlwifi] [ 6385.246356] #2: (rcu_read_lock){..}, at: [] ieee80211_rx_napi+0x139/0x8f2 [mac80211] [ 6385.246408] #3: (&(&local->rx_path_lock)->rlock){+.-...}, at: [] ieee80211_rx_handlers+0x33/0x21c3 [mac80211] [ 6385.246448] stack backtrace: [ 6385.246455] CPU: 0 PID: 246 Comm: irq/30-iwlwifi Not tainted 4.4.0-rc4-next-20151211-dbg-00015-g7b65ef3-dirty #302 [ 6385.246459] 8800c65678e0 811e7d72 88041af55100 [ 6385.246467] 8800c6567910 8107dabe 88041c6d2048 [ 6385.246474] 880416a30a08 88041c6d2048 8800c6567930 a04f5106 [ 6385.246480] Call Trace: [ 6385.246490] [] dump_stack+0x4b/0x63 [ 6385.246497] [] lockdep_rcu_suspicious+0xf7/0x100 [ 6385.246517] [] iwl_mvm_get_key_sta_id.part.0+0x60/0x7f [iwlmvm] [ 6385.246533] [] iwl_mvm_update_tkip_key+0x43/0x22d [iwlmvm] [ 6385.246544] [] iwl_mvm_mac_update_tkip_key+0x1c/0x1e [iwlmvm] [ 6385.246578] [] ieee80211_tkip_decrypt_data+0x22f/0x44e [mac80211] [ 6385.246584] [] ? lock_acquire+0x101/0x188 [ 6385.246611] [] ieee80211_crypto_tkip_decrypt+0xc8/0x113 [mac80211] [ 6385.246645] [] ieee80211_rx_handlers+0xa68/0x21c3 [mac80211] [ 6385.246677] [] ieee80211_prepare_and_rx_handle+0x81f/0x86f [mac80211] [ 6385.246706] [] ? ieee80211_rx_napi+0x139/0x8f2 [mac80211] [ 6385.246711] [] ? __lock_is_held+0x3c/0x57 [ 6385.246748] [] ieee80211_rx_napi+0x640/0x8f2 [mac80211] [ 6385.246767] [] iwl_mvm_rx_rx_mpdu+0x651/0x660 [iwlmvm] [ 6385.246781] [] iwl_mvm_rx+0x58/0x1e6 [iwlmvm] [ 6385.246793] [] iwl_pcie_irq_handler+0x960/0xaf4 [iwlwifi] [ 6385.246800] [] ? __schedule+0x716/0xaf9 [ 6385.246806] [] ? irq_finalize_oneshot+0xd0/0xd0 [ 6385.246812] [] irq_thread_fn+0x1d/0x34 [ 6385.246817] [] irq_thread+0x10d/0x1b5 [ 6385.246823] [] ? wake_threads_waitq+0x2d/0x2d [ 6385.246828] [] ? irq_thread_dtor+0x98/0x98 [ 6385.246833] [] kthread+0xf8/0x100 [ 6385.246840] [] ? kthread_create_on_node+0x1c7/0x1c7 [ 6385.246847] [] ret_from_fork+0x3f/0x70 [ 6385.246852] [] ? kthread_create_on_node+0x1c7/0x1c7 -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] net/ceph: do not define list_entry_next
On (11/18/15 14:13), Ilya Dryomov wrote: [..] > > Someone beat you to it ;) > > https://github.com/ceph/ceph-client/commit/76b4a27faebb369c1c50df01ef08b614a2854fc5 Oh, OK then :) Thanks! -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] net/ceph: do not define list_entry_next
Cosmetic. Do not define list_entry_next() and use list_next_entry() from list.h. Signed-off-by: Sergey Senozhatsky --- net/ceph/messenger.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c index 9981039..77ccca9 100644 --- a/net/ceph/messenger.c +++ b/net/ceph/messenger.c @@ -10,6 +10,7 @@ #include #include #include +#include #ifdef CONFIG_BLOCK #include #endif /* CONFIG_BLOCK */ @@ -23,9 +24,6 @@ #include #include -#define list_entry_next(pos, member) \ - list_entry(pos->member.next, typeof(*pos), member) - /* * Ceph uses the messenger to exchange ceph_msg messages with other * hosts in the system. The messenger provides ordered and reliable @@ -1042,7 +1040,7 @@ static bool ceph_msg_data_pagelist_advance(struct ceph_msg_data_cursor *cursor, /* Move on to the next page */ BUG_ON(list_is_last(&cursor->page->lru, &pagelist->head)); - cursor->page = list_entry_next(cursor->page, lru); + cursor->page = list_next_entry(cursor->page, lru); cursor->last_piece = cursor->resid <= PAGE_SIZE; return true; @@ -1166,7 +1164,7 @@ static bool ceph_msg_data_advance(struct ceph_msg_data_cursor *cursor, if (!cursor->resid && cursor->total_resid) { WARN_ON(!cursor->last_piece); BUG_ON(list_is_last(&cursor->data->links, cursor->data_head)); - cursor->data = list_entry_next(cursor->data, links); + cursor->data = list_next_entry(cursor->data, links); __ceph_msg_data_cursor_init(cursor); new_piece = true; } -- 2.6.2.280.g74301d6 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6
On (10/26/15 07:51), Grumbach, Emmanuel wrote: > > On 10/26/2015 08:41 AM, Sergey Senozhatsky wrote: > >> Hi, > >> > >> linux-next 20151022 > >> > >> > > > > Can be reproduced reliably? > > Seems like a bad race between the end of session protection for the > > authentication and the start of the session protection for the deauth. > > I think I found the hole in the locks in there, but it is going to be > > tricky to solve. > > Not sure if I found the race. Can you please send the complete log? > If you have timestamps, it'd greatly helps... > dmesg output should do. > Hi, not really sure if I can reproduce this one easily. seen once. --- Oct 26 15:20:51 dhclient[399]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 7 Oct 26 15:20:58 dhclient[399]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 17 Oct 26 15:21:09 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 7 Oct 26 15:21:09 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 Oct 26 15:21:09 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:09 kernel: wlp2s0: authenticated Oct 26 15:21:09 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:09 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 (capab=0x11 status=0 aid=24) Oct 26 15:21:09 kernel: wlp2s0: associated Oct 26 15:21:09 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready Oct 26 15:21:09 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:21:12 kernel: wlp2s0: authenticate with 00:04:96:61:e9:f0 Oct 26 15:21:12 kernel: wlp2s0: send auth to 00:04:96:61:e9:f0 (try 1/3) Oct 26 15:21:12 kernel: wlp2s0: authenticated Oct 26 15:21:12 kernel: wlp2s0: associate with 00:04:96:61:e9:f0 (try 1/3) Oct 26 15:21:12 kernel: wlp2s0: RX AssocResp from 00:04:96:61:e9:f0 (capab=0x11 status=0 aid=16) Oct 26 15:21:12 kernel: wlp2s0: associated Oct 26 15:21:12 kernel: wlp2s0: deauthenticating from 00:04:96:61:e9:f0 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:21:16 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 10 Oct 26 15:21:22 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 Oct 26 15:21:22 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:22 kernel: wlp2s0: authenticated Oct 26 15:21:22 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:22 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 (capab=0x11 status=0 aid=25) Oct 26 15:21:22 kernel: wlp2s0: associated Oct 26 15:21:22 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:21:26 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 9 Oct 26 15:21:35 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 12 Oct 26 15:21:47 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 Oct 26 15:21:47 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:47 kernel: wlp2s0: authenticated Oct 26 15:21:47 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) Oct 26 15:21:47 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 (capab=0x11 status=0 aid=25) Oct 26 15:21:47 kernel: wlp2s0: associated Oct 26 15:21:47 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:21:47 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 18 Oct 26 15:22:05 dhclient[539]: DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 5 Oct 26 15:22:10 dhclient[539]: No DHCPOFFERS received. Oct 26 15:22:10 dhclient[539]: No working leases in persistent database - sleeping. Oct 26 15:22:34 kernel: wlp2s0: authenticate with 00:04:96:69:0d:80 Oct 26 15:22:34 kernel: wlp2s0: send auth to 00:04:96:69:0d:80 (try 1/3) Oct 26 15:22:34 kernel: wlp2s0: authenticated Oct 26 15:22:34 kernel: wlp2s0: associate with 00:04:96:69:0d:80 (try 1/3) Oct 26 15:22:34 kernel: wlp2s0: RX AssocResp from 00:04:96:69:0d:80 (capab=0x11 status=0 aid=29) Oct 26 15:22:34 kernel: wlp2s0: associated Oct 26 15:22:34 kernel: wlp2s0: deauthenticating from 00:04:96:69:0d:80 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:22:34 kernel: wlp2s0: authenticate with 00:04:96:61:cd:e0 Oct 26 15:22:34 kernel: wlp2s0: send auth to 00:04:96:61:cd:e0 (try 1/3) Oct 26 15:22:34 kernel: wlp2s0: aborting authentication with 00:04:96:61:cd:e0 by local choice (Reason: 3=DEAUTH_LEAVING) Oct 26 15:22:34 kernel: [ cut here ] Oct 26 15:22:34 kernel: WARNING: CPU: 0 PID: 1006 at drivers/net/wireless/iwlwifi/mvm/time-event.c:513 iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm]() Oct 26 15:22:34 kernel: Modules linked in: mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat serio_raw psmouse atkbd coretemp hwmon i
[-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6
Hi, linux-next 20151022 wlp2s0: aborting authentication with 00:04:96:61:cd:e0 by local choice (Reason: 3=DEAUTH_LEAVING) [ cut here ] WARNING: CPU: 0 PID: 1006 at drivers/net/wireless/iwlwifi/mvm/time-event.c:513 iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm]() Modules linked in: mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat serio_raw psmouse atkbd coretemp hwmon i915 libps2 iwlmvm i2c_algo_bit mac80211 drm_kms_helper cfbfillrect intel_powerclamp syscopyarea cfbimgblt sysfillrect sysimgblt crc32c_intel fb_sys_fops cfbcopyarea iwlwifi drm r8 CPU: 0 PID: 1006 Comm: iwconfig Not tainted 4.3.0-rc6-next-20151022-dbg-2-g4041783-dirty #260 8800c69479c8 811dd4ad 8800c6947a00 8103db4e a04fd261 88041c7cdfc8 88041cc87a20 88041c7ceb28 8800c6947aac 8800c6947a10 Call Trace: [] dump_stack+0x4b/0x63 [] warn_slowpath_common+0x99/0xb2 [] ? iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] [] warn_slowpath_null+0x1a/0x1c [] iwl_mvm_time_event_send_add+0x72/0x1b6 [iwlmvm] [] ? __lock_is_held+0x3c/0x57 [] iwl_mvm_protect_session+0x150/0x219 [iwlmvm] [] ? iwl_mvm_protect_session+0x150/0x219 [iwlmvm] [] ? iwl_mvm_ref_sync+0x37/0x10c [iwlmvm] [] iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] [] ? iwl_mvm_mac_mgd_prepare_tx+0xa4/0xc2 [iwlmvm] [] ieee80211_mgd_deauth+0x14f/0x3b0 [mac80211] [] ? __lock_is_held+0x3c/0x57 [] ieee80211_deauth+0x18/0x1a [mac80211] [] cfg80211_mlme_deauth+0x13c/0x28e [cfg80211] [] cfg80211_disconnect+0xb5/0x2f7 [cfg80211] [] cfg80211_mgd_wext_siwfreq+0xed/0x160 [cfg80211] [] ? cfg80211_wext_freq+0x5f/0x5f [cfg80211] [] cfg80211_wext_siwfreq+0x76/0xf6 [cfg80211] [] ioctl_standard_call+0x66/0x376 [] wext_handle_ioctl+0x102/0x16d [] dev_ioctl+0x6bb/0x6de [] ? handle_mm_fault+0xefc/0x13f9 [] sock_ioctl+0x230/0x23c [] ? sock_ioctl+0x230/0x23c [] do_vfs_ioctl+0x458/0x4dc [] ? retint_user+0x18/0x20 [] ? __fget_light+0x4d/0x71 [] SyS_ioctl+0x43/0x61 [] entry_SYSCALL_64_fastpath+0x12/0x6f ---[ end trace 6a44e7f1588bdae7 ]--- -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] net: Initialize table in fib result
On (09/16/15 10:16), David Ahern wrote: [..] > The root cause is use of res.table uninitialized. > > Thanks to Nikolay for noticing the uninitialized use amongst the maze of > gotos. > > As Nikolay pointed out the second initialization is not required to fix > the oops, but rather to fix a related problem where a valid lookup should > be invalidated before creating the rth entry. > > Fixes: b7503e0cdb5d ("net: Add FIB table id to rtable") > Reported-by: Sergey Senozhatsky works for me, thanks Tested-by: Sergey Senozhatsky -ss > Reported-by: Richard Alpe > Reported-by: Fabio Estevam > Tested-by: Fabio Estevam > Signed-off-by: David Ahern > --- > v2: > - clarification in the commit message regarding the second initialization > > net/ipv4/route.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > index da427a4a33fe..80f7c5b7b832 100644 > --- a/net/ipv4/route.c > +++ b/net/ipv4/route.c > @@ -1712,6 +1712,7 @@ static int ip_route_input_slow(struct sk_buff *skb, > __be32 daddr, __be32 saddr, > goto martian_source; > > res.fi = NULL; > + res.table = NULL; > if (ipv4_is_lbcast(daddr) || (saddr == 0 && daddr == 0)) > goto brd_input; > > @@ -1834,6 +1835,7 @@ out:return err; > RT_CACHE_STAT_INC(in_no_route); > res.type = RTN_UNREACHABLE; > res.fi = NULL; > + res.table = NULL; > goto local_input; > > /* > -- > 2.3.2 (Apple Git-55) > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] oops in ip_route_input_noref
On (09/16/15 07:07), David Ahern wrote: > Hi Sergey: > Hi, sorry for long reply. Baremetal. So grabbing the backtrace is a bit complicated. But it looks very close to what Richard Alpe has posted. in IRQ RIP is at ip_route_input_noref [0.877597] [] arp_process+0x39c/0x690 [0.877597] [] arp_rcv+0x13e/0x170 -ss > Is this with KVM or baremetal? > > -8<- > thanks for the analysis > > >>addr2line -e vmlinux -i 0x8146c0b1 > >>net/ipv4/route.c:1815 > >>net/ipv4/route.c:1905 > >> > >> > >>which seems to be this line ip_route_input_noref()->ip_route_input_slow(): > >>... > >>1813 rth->rt_is_input = 1; > >>1814 if (res.table) > >>1815 rth->rt_table_id = res.table->tb_id; > >>1816 > >>... > >> > >> > >>added by b7503e0cdb5dbec5d201aa69dc14679b5ae8 > >> > >> net: Add FIB table id to rtable > >> > >> Add the FIB table id to rtable to make the information available for > >> IPv4 as it is for IPv6. > >> > >> > >>-ss > > Hi Richard: > > >I to get an Oops in ip_route_input_noref(). It happens occasionally during > >bootup. > >KVM environment using virtio driver. Let me know if you need any additional > >info or > >if you want me to try to bisect it. > > > >Starting network... > >... > >[0.877040] BUG: unable to handle kernel NULL pointer dereference at > >0056 > >[0.877597] IP: [] ip_route_input_noref+0x1a2/0xb00 > > Can you send me your kernel config and qemu command line? KVM with virtio > networking is a primary test vehicle, and I did not encounter this at all. > > Thanks, > David > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[linux-next] oops in ip_route_input_noref
Hi, 4.3.0-rc1-next-20150916 oops after removal of rndis usb device ... 8146c052: 00 8146c053: 0f b6 55 8a movzbl -0x76(%rbp),%edx 8146c057: 49 8b bf e8 01 00 00mov0x1e8(%r15),%rdi 8146c05e: 45 89 d1mov%r10d,%r9d 8146c061: 44 89 f6mov%r14d,%esi 8146c064: 44 88 95 70 ff ff ffmov%r10b,-0x90(%rbp) 8146c06b: 0f 95 c1setne %cl 8146c06e: 81 ce 00 00 00 80 or $0x8000,%esi 8146c074: 41 83 e1 01 and$0x1,%r9d 8146c078: 45 31 c0xor%r8d,%r8d 8146c07b: e8 49 d5 ff ff callq 814695c9 8146c080: 48 85 c0test %rax,%rax 8146c083: 49 89 c5mov%rax,%r13 8146c086: 75 0a jne8146c092 8146c088: bb 97 ff ff ff mov$0xff97,%ebx 8146c08d: e9 06 f8 ff ff jmpq 8146b898 8146c092: 48 c7 40 58 a3 95 46movq $0x814695a3,0x58(%rax) 8146c099: 81 8146c09a: c6 80 a2 00 00 00 01movb $0x1,0xa2(%rax) 8146c0a1: 48 8b 45 98 mov-0x68(%rbp),%rax 8146c0a5: 44 8a 95 70 ff ff ffmov-0x90(%rbp),%r10b 8146c0ac: 48 85 c0test %rax,%rax 8146c0af: 74 0a je 8146c0bb 8146c0b1: 8b 40 10mov0x10(%rax),%eax ^^^ 8146c0b4: 41 89 85 b0 00 00 00mov%eax,0xb0(%r13) 8146c0bb: 65 ff 05 9e 54 ba 7eincl %gs:0x7eba549e(%rip) # 11560 8146c0c2: 80 7d 8a 07 cmpb $0x7,-0x76(%rbp) 8146c0c6: 75 1a jne8146c0e2 8146c0c8: 41 81 a5 9c 00 00 00andl $0x7fff,0x9c(%r13) 8146c0cf: ff ff ff 7f 8146c0d3: f7 db neg%ebx 8146c0d5: 49 c7 45 50 b1 96 46movq $0x814696b1,0x50(%r13) 8146c0dc: 81 8146c0dd: 66 41 89 5d 64 mov%bx,0x64(%r13) 8146c0e2: 45 84 d2test %r10b,%r10b 8146c0e5: 74 29 je 8146c110 8146c0e7: 0f b6 7d 89 movzbl -0x77(%rbp),%edi 8146c0eb: 4c 89 eemov%r13,%rsi 8146c0ee: 48 ff c7inc%rdi 8146c0f1: 48 6b ff 60 imul $0x60,%rdi,%rdi 8146c0f5: 48 03 7d 90 add-0x70(%rbp),%rdi 8146c0f9: e8 10 d1 ff ff callq 8146920e 8146c0fe: 84 c0 test %al,%al 8146c100: 75 0e jne8146c110 8146c102: 66 41 83 4d 60 10 orw$0x10,0x60(%r13) 8146c108: 4c 89 efmov%r13,%rdi 8146c10b: e8 7d cc ff ff callq 81468d8d 8146c110: 4d 89 6c 24 58 mov%r13,0x58(%r12) 8146c115: 31 db xor%ebx,%ebx 8146c117: e9 7c f7 ff ff jmpq 8146b898 8146c11c: bb 8f ff ff ff mov$0xff8f,%ebx 8146c121: c6 45 8a 07 movb $0x7,-0x76(%rbp) 8146c125: 48 c7 45 90 00 00 00movq $0x0,-0x70(%rbp) ... addr2line -e vmlinux -i 0x8146c0b1 net/ipv4/route.c:1815 net/ipv4/route.c:1905 which seems to be this line ip_route_input_noref()->ip_route_input_slow(): ... 1813 rth->rt_is_input = 1; 1814 if (res.table) 1815 rth->rt_table_id = res.table->tb_id; 1816 ... added by b7503e0cdb5dbec5d201aa69dc14679b5ae8 net: Add FIB table id to rtable Add the FIB table id to rtable to make the information available for IPv4 as it is for IPv6. -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[-next] fib_dump_info() suspicious RCU usage
Hello, Since 0eeb075fad736 ('net: ipv4 sysctl option to ignore routes when nexthop link is down') fib_dump_info() and fib_sync_up() are using __in_dev_get_rcu(), which requires (missing) RCU read side protection. [ 60.605034] === [ 60.605035] [ INFO: suspicious RCU usage. ] [ 60.605037] 4.1.0-next-20150626-dbg-00020-g54a6d91-dirty #244 Not tainted [ 60.605038] --- [ 60.605040] include/linux/inetdevice.h:205 suspicious rcu_dereference_check() usage! [ 60.605041] other info that might help us debug this: [ 60.605043] rcu_scheduler_active = 1, debug_locks = 0 [ 60.605045] 2 locks held by ip/403: [ 60.605046] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x19 [ 60.605054] #1: ((inetaddr_chain).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x35/0x6a [ 60.605060] stack backtrace: [ 60.605062] CPU: 2 PID: 403 Comm: ip Not tainted 4.1.0-next-20150626-dbg-00020-g54a6d91-dirty #244 [ 60.605066] 0001 8800b189b728 8150a542 8107a8b3 [ 60.605069] 880037bbea40 8800b189b758 8107cb74 8800379dbd00 [ 60.605071] 8800bec85800 8800bf9e13c0 00ff 8800b189b7d8 [ 60.605074] Call Trace: [ 60.605078] [] dump_stack+0x4c/0x6e [ 60.605081] [] ? up+0x39/0x3e [ 60.605084] [] lockdep_rcu_suspicious+0xf7/0x100 [ 60.605088] [] fib_dump_info+0x227/0x3e2 [ 60.605090] [] rtmsg_fib+0xa6/0x116 [ 60.605093] [] fib_table_insert+0x316/0x355 [ 60.605095] [] fib_magic+0xb7/0xc7 [ 60.605098] [] fib_add_ifaddr+0xb1/0x13b [ 60.605100] [] fib_inetaddr_event+0x36/0x90 [ 60.605102] [] notifier_call_chain+0x4c/0x71 [ 60.605104] [] __blocking_notifier_call_chain+0x4e/0x6a [ 60.605106] [] blocking_notifier_call_chain+0x14/0x16 [ 60.605108] [] __inet_insert_ifa+0x1a5/0x1b3 [ 60.605110] [] inet_rtm_newaddr+0x350/0x35f [ 60.605113] [] rtnetlink_rcv_msg+0x17b/0x18a [ 60.605115] [] ? trace_hardirqs_on+0xd/0xf [ 60.605118] [] ? netlink_deliver_tap+0x1cb/0x1f7 [ 60.605120] [] ? rtnl_newlink+0x72a/0x72a [ 60.605122] [] netlink_rcv_skb+0x48/0x8a [ 60.605124] [] rtnetlink_rcv+0x26/0x2d [ 60.605126] [] netlink_unicast+0xc6/0x145 [ 60.605128] [] netlink_sendmsg+0x4c9/0x4e0 [ 60.605131] [] ? import_iovec+0x67/0x89 [ 60.605134] [] sock_sendmsg+0x14/0x1f [ 60.605136] [] ___sys_sendmsg+0x16a/0x1f1 [ 60.605140] [] ? handle_mm_fault+0x9dd/0xe17 [ 60.605142] [] ? handle_mm_fault+0x9dd/0xe17 [ 60.605144] [] ? handle_mm_fault+0x9dd/0xe17 [ 60.605146] [] ? __lock_is_held+0x3c/0x57 [ 60.605149] [] ? __fget_light+0x50/0x75 [ 60.605151] [] __sys_sendmsg+0x42/0x63 [ 60.605154] [] SyS_sendmsg+0xe/0x10 [ 60.605156] [] entry_SYSCALL_64_fastpath+0x12/0x6f -ss -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html