Re: INFO: rcu detected stall in vprintk_func

2018-04-01 Thread Sergey Senozhatsky 
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, >sk, MSG_DONTWAIT,
 frag_len + LLCP_HEADER_SIZE, );
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

2018-04-01 Thread Sergey Senozhatsky 
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

2018-04-01 Thread Sergey Senozhatsky 
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, >sk, MSG_DONTWAIT,
 frag_len + LLCP_HEADER_SIZE, );
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

2017-12-06 Thread Sergey Senozhatsky 
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

2017-12-06 Thread Sergey Senozhatsky 
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

2017-12-05 Thread Sergey Senozhatsky 
On (12/05/17 17:59), Linus Torvalds wrote:
[..]
> On Tue, Dec 5, 2017 at 5:36 PM, Sergey Senozhatsky
> <sergey.senozhatsky.w...@gmail.com> 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", );
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

2017-12-05 Thread Sergey Senozhatsky 
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

2017-11-30 Thread Sergey Senozhatsky 
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

2017-11-30 Thread Sergey Senozhatsky 
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

2017-11-08 Thread Sergey Senozhatsky 
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

2017-07-26 Thread Sergey Senozhatsky 
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

2017-07-26 Thread Sergey Senozhatsky 
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)

2016-10-14 Thread Sergey Senozhatsky 
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)

2016-10-13 Thread Sergey Senozhatsky 
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 
<ieee80211_aes_ccm_decrypt+0x56>
8146d239:   b8 ea ff ff ff  mov$0xffea,%eax
8146d23e:   e9 1a 02 00 00  jmpq   8146d45d 
<ieee80211_aes_ccm_decrypt+0x270>
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 
<ieee80211_aes_ccm_decrypt+0xdb>
8146d2be:   48 b9 00 00 00 80 ffmovabs $0x77ff8000,%rcx

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

2016-10-13 Thread Sergey Senozhatsky 
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=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
> > > > t/?h=x86/vmap_stack=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)

2016-10-13 Thread Sergey Senozhatsky 
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=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack=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)

2016-10-13 Thread Sergey Senozhatsky 
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=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack=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)

2016-10-12 Thread Sergey Senozhatsky 
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)

2016-10-10 Thread Sergey Senozhatsky 
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([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)

2016-10-10 Thread Sergey Senozhatsky 
Hello,

current -git kills my system. adding

if (!virt_addr_valid([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'

2016-10-05 Thread Sergey Senozhatsky 
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

2016-10-03 Thread Sergey Senozhatsky 
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

2016-09-27 Thread Sergey Senozhatsky 
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(, RCU_INITIALIZER((typeof(p))_r_a_p__v)); \
   ^
net/netfilter/core.c:96:3: note: in expansion of macro

Re: [linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage

2016-05-14 Thread Sergey Senozhatsky 
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:  (&(>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:  (&(>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: Microcode SW error dete

[linux-next: May 13] intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage

2016-05-14 Thread Sergey Senozhatsky 
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:  (&(>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:  (&(>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

2015-12-11 Thread Sergey Senozhatsky 
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

2015-12-11 Thread Sergey Senozhatsky 
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

2015-12-11 Thread Sergey Senozhatsky 
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:  (&(>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:  (&(>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

[PATCH 2/3] net/ceph: do not define list_entry_next

2015-11-18 Thread Sergey Senozhatsky 
Cosmetic.

Do not define list_entry_next() and use list_next_entry()
from list.h.

Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
---
 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(>page->lru, >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(>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: [PATCH 2/3] net/ceph: do not define list_entry_next

2015-11-18 Thread Sergey Senozhatsky 
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

[-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6

2015-10-26 Thread Sergey Senozhatsky 
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: [linuxwifi] [-next] WARNING at iwl_mvm_time_event_send_add+0x72/0x1b6

2015-10-26 Thread Sergey Senozhatsky 
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 i915 l

[linux-next] oops in ip_route_input_noref

2015-09-16 Thread Sergey Senozhatsky 
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

Re: [linux-next] oops in ip_route_input_noref

2015-09-16 Thread Sergey Senozhatsky 
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

Re: [PATCH net-next v2] net: Initialize table in fib result

2015-09-16 Thread Sergey Senozhatsky 
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 <sergey.senozhatsky.w...@gmail.com>

works for me, thanks

Tested-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>

-ss

> Reported-by: Richard Alpe <richard.a...@ericsson.com>
> Reported-by: Fabio Estevam <feste...@gmail.com>
> Tested-by: Fabio Estevam <fabio.este...@freescale.com>
> Signed-off-by: David Ahern <d...@cumulusnetworks.com>
> ---
> 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

[-next] fib_dump_info() suspicious RCU usage

2015-06-26 Thread Sergey Senozhatsky 
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: [81453305] 
rtnl_lock+0x17/0x19
[   60.605054]  #1:  ((inetaddr_chain).rwsem){.+.+.+}, at: [8105c327] 
__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]  [8150a542] dump_stack+0x4c/0x6e
[   60.605081]  [8107a8b3] ? up+0x39/0x3e
[   60.605084]  [8107cb74] lockdep_rcu_suspicious+0xf7/0x100
[   60.605088]  [814b63c3] fib_dump_info+0x227/0x3e2
[   60.605090]  [814b6624] rtmsg_fib+0xa6/0x116
[   60.605093]  [814b978f] fib_table_insert+0x316/0x355
[   60.605095]  [814b362e] fib_magic+0xb7/0xc7
[   60.605098]  [814b4803] fib_add_ifaddr+0xb1/0x13b
[   60.605100]  [814b4d09] fib_inetaddr_event+0x36/0x90
[   60.605102]  [8105c086] notifier_call_chain+0x4c/0x71
[   60.605104]  [8105c340] __blocking_notifier_call_chain+0x4e/0x6a
[   60.605106]  [8105c370] blocking_notifier_call_chain+0x14/0x16
[   60.605108]  [814a7f50] __inet_insert_ifa+0x1a5/0x1b3
[   60.605110]  [814a894d] inet_rtm_newaddr+0x350/0x35f
[   60.605113]  [81457866] rtnetlink_rcv_msg+0x17b/0x18a
[   60.605115]  [8107e7c3] ? trace_hardirqs_on+0xd/0xf
[   60.605118]  [8146965f] ? netlink_deliver_tap+0x1cb/0x1f7
[   60.605120]  [814576eb] ? rtnl_newlink+0x72a/0x72a
[   60.605122]  [8146d299] netlink_rcv_skb+0x48/0x8a
[   60.605124]  [81455724] rtnetlink_rcv+0x26/0x2d
[   60.605126]  [8146cb53] netlink_unicast+0xc6/0x145
[   60.605128]  [8146d144] netlink_sendmsg+0x4c9/0x4e0
[   60.605131]  [81247a09] ? import_iovec+0x67/0x89
[   60.605134]  [8142adaf] sock_sendmsg+0x14/0x1f
[   60.605136]  [8142b38d] ___sys_sendmsg+0x16a/0x1f1
[   60.605140]  [81119923] ? handle_mm_fault+0x9dd/0xe17
[   60.605142]  [81119923] ? handle_mm_fault+0x9dd/0xe17
[   60.605144]  [81119923] ? handle_mm_fault+0x9dd/0xe17
[   60.605146]  [8107bcbc] ? __lock_is_held+0x3c/0x57
[   60.605149]  [81158da8] ? __fget_light+0x50/0x75
[   60.605151]  [8142c1e0] __sys_sendmsg+0x42/0x63
[   60.605154]  [8142c20f] SyS_sendmsg+0xe/0x10
[   60.605156]  [81510fd7] 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