From patchwork Fri Jul 31 13:45:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andy Shevchenko X-Patchwork-Id: 502555 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 318631402F4 for ; Fri, 31 Jul 2015 23:46:08 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=VBtM0yt3; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751992AbbGaNph (ORCPT ); Fri, 31 Jul 2015 09:45:37 -0400 Received: from mail-yk0-f178.google.com ([209.85.160.178]:32991 "EHLO mail-yk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbbGaNpg convert rfc822-to-8bit (ORCPT ); Fri, 31 Jul 2015 09:45:36 -0400 Received: by ykdv124 with SMTP id v124so18660151ykd.0; Fri, 31 Jul 2015 06:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/5UeqJIu/2x4Pf2Nl5vX0kqevLq5MJMMP6JQ6v4PNf8=; b=VBtM0yt3DFClBExLh19IWaRFWaNT6MB7SqaMPyLoy/YJg7AVErpW+yKSaKP2uVflOS zY9nmUNtrG99DpQ1+4UQqRQJjgcj/thx3uyntb4GnDlROh2rzhbn0HHDdwSRMMEGZ+cx +xLJ42fg8XRzndBx4n1KU2zchMOk+wz5jPsuCWwdw8/hU0+Rw8hJrBQRpgpYJrCNnXlv f9lJHaAzq9+vjHhap43l0LBmeRGyQmb7dHXnKecwFQoPr4D9M1RNWS+OzTO0ptB5Hfyj nqT+laCPcMsDGAQu4a56vdG52L4nGOg/tCmWo+WFfq1G0hxvm+o9Vm+PNzsEqwMGebSd +q4Q== MIME-Version: 1.0 X-Received: by 10.170.155.133 with SMTP id w127mr3358901ykc.44.1438350335760; Fri, 31 Jul 2015 06:45:35 -0700 (PDT) Received: by 10.37.210.151 with HTTP; Fri, 31 Jul 2015 06:45:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 16:45:35 +0300 Message-ID: Subject: Re: Null pointer dereference in UDP4 core on AVR32 ATNGW100 From: Andy Shevchenko To: netdev , "linux-kernel@vger.kernel.org" Cc: "David S. Miller" , Nicolas Ferre , Eric Dumazet , David Held , Hans-Christian Egtvedt Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jul 31, 2015 at 4:25 PM, Andy Shevchenko wrote: > Hi! > > Got few weeks ago an old AVR32 board (ATNGW100). > It has ethernet cards supported by macb driver. > > Bring it mostly back to work with recent kernel from linux-next. Now, > when I start networking on it, I got in few seconds kernel panic. Seems the hack fixes this (still playing with network connected). # uname -a Linux buildroot 4.2.0-rc4-next-20150731+ #164 Fri Jul 31 16:37:20 EEST 2015 avr32 GNU/Linux udp_table.mask; > > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > ptbr = 91e42000 pgd = 91e4b000 > Oops: Kernel access of bad area, sig: 11 [#1] > FRAME_POINTER chip: 0x01f:0x1e82 rev 2 > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc4-next-20150729+ #102 > task: 903532dc ti: 90350000 task.ti: 90350000 > PC is at __udp4_lib_rcv+0x300/0x660 > LR is at 0x15da8a2f > pc : [<90233a84>] lr : [<15da8a2f>] Not tainted > 0sp : 90351b5c r12: 00000000 r11: 91cd4450 > r10: 00000000 r9 : 0000004c r8 : 00000000 > r7 : 90351c80 r6 : 91db5c80 r5 : 91e4e540 r4 : 11f6a114 > r3 : 00000000 r2 : 91e6b224 r1 : 0000008a r0 : 00000000 > Flags: qvnZc > Mode bits: hjmde....g > CPU Mode: Interrupt level 0 > Stack: (0x90351b5c to 0x90352000) > … > Call trace: > [<90233df0>] udp_rcv+0xc/0x14 > [<90215220>] ip_local_deliver_finish+0xac/0x15c > [<902150ca>] ip_local_deliver+0x76/0x84 > [<90214d32>] ip_rcv_finish+0x23a/0x250 > [<90215004>] ip_rcv+0x2bc/0x30c > [<901f5ee4>] __netif_receive_skb_core+0x548/0x570 > [<901f5f52>] __netif_receive_skb+0x46/0x50 > [<901f5f8e>] netif_receive_skb_internal+0x32/0x3c > [<901f5fa0>] netif_receive_skb_sk+0x8/0xc > [<901cf358>] macb_rx+0x1b0/0x1d8 > [<901cf4d8>] macb_poll+0x38/0xa4 > [<901faf9c>] net_rx_action+0x84/0x1b4 > [<90021e46>] __do_softirq+0x5a/0x150 > [<90021f86>] irq_exit+0x26/0x58 > [<9001a520>] do_IRQ+0x34/0x44 > [<90019428>] irq_level0+0x18/0x5c > [<900355a4>] default_idle_call+0x1c/0x20 > [<9003563e>] cpu_startup_entry+0x66/0xa8 > [<902a16a4>] rest_init+0x48/0x70 > [<900007fc>] start_kernel+0x290/0x2dc > > Long time bisecting and reading assembly points to the > > commit 2dc41cff7545d55c6294525c811594576f8e119c > Author: David Held > Date: Tue Jul 15 23:28:32 2014 -0400 > > udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver. > > I don't know yet neither the package exactly makes this (tried to > debug print, but bug disappears) nor should be network card driver > fixed, or even compiler / binutils problems (using it from buildroot, > which is gcc 4.2.2). Would like to hear opinions what the root cause > might be and what ways we have to fix it. I'm also wondering if any > other architecture with same network card has the issue. > > P.S. > Since buildroot is not supporting anymore avr32 I use the version just > before this removal. (Nicolas, does Atmel care about that?) > > -- > With Best Regards, > Andy Shevchenko --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1665,6 +1665,10 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb, unsigned int hash2 = 0, hash2_any = 0, use_hash2 = (hslot->count > 10); bool inner_flushed = false; +#ifdef CONFIG_AVR32 + use_hash2 = 0; +#endif + if (use_hash2) { hash2_any = udp4_portaddr_hash(net, htonl(INADDR_ANY), hnum) &