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
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
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
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
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,
> .h
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 __b
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:
> >
> >
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 w
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
And this one is the last one - 3/3.
-ss
Yikes... This is actually - 2/3
-ss
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
\
__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(+
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
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
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
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
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
> > > llc
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
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 forwa
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 e
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);
>
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 *
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 he
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
> > > "" i
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 worr
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
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
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
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
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: [] ieee8021
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
>
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/c
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
> >
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
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 -
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_decry
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/c
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
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
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] ---
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 susp
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
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 r
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/m
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
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
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
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]()
Module
, 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
> R
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]
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
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 RC
53 matches
Mail list logo
