From patchwork Mon Jun 7 09:48:40 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 54842 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 4BBC8B7D1F for ; Mon, 7 Jun 2010 19:48:57 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753380Ab0FGJsw (ORCPT ); Mon, 7 Jun 2010 05:48:52 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:64236 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871Ab0FGJsu (ORCPT ); Mon, 7 Jun 2010 05:48:50 -0400 Received: by fxm8 with SMTP id 8so1895556fxm.19 for ; Mon, 07 Jun 2010 02:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=rhbfMq4i/wAyI5WGgINgvoIktMxDc4b27CBI6AMyU5U=; b=f+ppXWF6aXm+RAupE2qUfEhOCSdOlQWbCIuTRJhWQzuyeFnGWwLzNOwK6AqYa2FLDD PyVyX3X5oJUsX1K+OVFi9pc202jAB78Z9dYyR9t/zYNNwGKO9DeLKhmthUbvGxumLUum 8XwWkk8CHBTcPNXG5PwPUX42G9OYB/n96ArwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=OZQA8TlIY8gkGgQZutmopQgY4Qcdd5j/AhoDi7HHeLL7uPm6TL0laKYygU7af1ZgLf lpd1Ot0hS5n+cvuebOmHSnLMFx/vig5JA/qCvZhseIG1q4iio23KsDxc/Yc+/pNDBX63 m/O1MwrwP/Oa+DdmPFEd8fOMG7n66sjrblryE= Received: by 10.223.92.152 with SMTP id r24mr14862170fam.74.1275904124231; Mon, 07 Jun 2010 02:48:44 -0700 (PDT) Received: from [127.0.0.1] ([85.17.35.125]) by mx.google.com with ESMTPS id 2sm19480968faf.15.2010.06.07.02.48.42 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 02:48:43 -0700 (PDT) Subject: Re: [Bugme-new] [Bug 16120] New: Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null) From: Eric Dumazet To: Andrew Morton , David Miller Cc: netdev@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org, alex.vizor@gmail.com, Patrick McHardy In-Reply-To: <1275730457.5238.14.camel@edumazet-laptop> References: <20100604161737.25c7940a.akpm@linux-foundation.org> <1275729426.5238.6.camel@edumazet-laptop> <1275730457.5238.14.camel@edumazet-laptop> Date: Mon, 07 Jun 2010 11:48:40 +0200 Message-ID: <1275904120.2545.40.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Le samedi 05 juin 2010 à 11:34 +0200, Eric Dumazet a écrit : > Le samedi 05 juin 2010 à 11:17 +0200, Eric Dumazet a écrit : > > Le vendredi 04 juin 2010 à 16:17 -0700, Andrew Morton a écrit : > > > (switched to email. Please respond via emailed reply-to-all, not via the > > > bugzilla web interface). > > > > > > On Fri, 4 Jun 2010 09:25:58 GMT > > > bugzilla-daemon@bugzilla.kernel.org wrote: > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=16120 > > > > > > > > Summary: Oops: 0000 [#1] SMP, unable to handle kernel NULL > > > > pointer dereference at (null) > > > > Product: Platform Specific/Hardware > > > > Version: 2.5 > > > > Kernel Version: 2.6.35-rc1 > > > > Platform: All > > > > OS/Version: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: high > > > > Priority: P1 > > > > Component: x86-64 > > > > AssignedTo: platform_x86_64@kernel-bugs.osdl.org > > > > ReportedBy: alex.vizor@gmail.com > > > > Regression: Yes > > > > > > > > > > > > Created an attachment (id=26647) > > > > --> (https://bugzilla.kernel.org/attachment.cgi?id=26647) id) > > > > > > 2.6.35-rc1 kernel log > > > > > > > > It happens randomly, almost a week I used 2.6.35-rc1 and don't have any > > > > problems. But since last day it happened twice. > > > > > > > > I attached kernel log, please inform me if I can help in investigation. > > > > > > > > > > ip6mr_sk_done() oopsed. > > > > Only thing I found a first glance is a typo but this should not be the > > root of the problem. > > > I was able to reproduce the problem here, and following patch solves it. (I see David already committed first patch about macro typo) Thanks ! [PATCH net-2.6] ipmr: dont corrupt lists ipmr_rules_exit() and ip6mr_rules_exit() free a list of items, but forget to properly remove these items from list. List head is not changed and still points to freed memory. This can trigger a fault later when icmpv6_sk_exit() is called. Fix is to either reinit list, or use list_del() to properly remove items from list before freeing them. bugzilla report : https://bugzilla.kernel.org/show_bug.cgi?id=16120 Introduced by commit d1db275dd3f6e4 (ipv6: ip6mr: support multiple tables) and commit f0ad0860d01e (ipv4: ipmr: support multiple tables) Reported-by: Alex Zhavnerchik Signed-off-by: Eric Dumazet CC: Patrick McHardy --- net/ipv4/ipmr.c | 4 +++- net/ipv6/ip6mr.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index 856123f..757f25e 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -267,8 +267,10 @@ static void __net_exit ipmr_rules_exit(struct net *net) { struct mr_table *mrt, *next; - list_for_each_entry_safe(mrt, next, &net->ipv4.mr_tables, list) + list_for_each_entry_safe(mrt, next, &net->ipv4.mr_tables, list) { + list_del(&mrt->list); kfree(mrt); + } fib_rules_unregister(net->ipv4.mr_rules_ops); } #else diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c index 89c0b07..66078da 100644 --- a/net/ipv6/ip6mr.c +++ b/net/ipv6/ip6mr.c @@ -254,8 +254,10 @@ static void __net_exit ip6mr_rules_exit(struct net *net) { struct mr6_table *mrt, *next; - list_for_each_entry_safe(mrt, next, &net->ipv6.mr6_tables, list) + list_for_each_entry_safe(mrt, next, &net->ipv6.mr6_tables, list) { + list_del(&mrt->list); ip6mr_free_table(mrt); + } fib_rules_unregister(net->ipv6.mr6_rules_ops); } #else