From patchwork Sun May 24 10:52:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Anastasov X-Patchwork-Id: 475966 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 554B01402CC for ; Sun, 24 May 2015 20:53:25 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751170AbbEXKxV (ORCPT ); Sun, 24 May 2015 06:53:21 -0400 Received: from ja.ssi.bg ([178.16.129.10]:46523 "EHLO ja.ssi.bg" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751063AbbEXKxT (ORCPT ); Sun, 24 May 2015 06:53:19 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ja.ssi.bg (8.14.8/8.14.8) with ESMTP id t4OAqZcV009155; Sun, 24 May 2015 13:52:35 +0300 Date: Sun, 24 May 2015 13:52:35 +0300 (EEST) From: Julian Anastasov To: Eric Dumazet cc: "Eric W. Biederman" , David Miller , netdev@vger.kernel.org, "Vittorio G (VittGam)" , security@kernel.org, Greg KH , luto@amacapital.net, Willy Tarreau Subject: Re: [PATCH net] ipv4: Avoid crashing in ip_error In-Reply-To: <1432415349.4060.136.camel@edumazet-glaptop2.roam.corp.google.com> Message-ID: References: <2b6d6ab2d8c35af3be55c82e507f5376@vittgam.net> <20150520025428.GA23304@kroah.com> <06f5f10e9ee831f5a839c6ea24b94f64@vittgam.net> <4cb068397127c2b2baee1f021b014b11@vittgam.net> <6056363be65a2c129551518da94bff20@vittgam.net> <87a8wx97er.fsf@x220.int.ebiederm.org> <20150522040453.GC8530@1wt.eu> <87zj4x6iiz.fsf_-_@x220.int.ebiederm.org> <87oalb2w8l.fsf@x220.int.ebiederm.org> <1432415349.4060.136.camel@edumazet-glaptop2.roam.corp.google.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello, On Sat, 23 May 2015, Eric Dumazet wrote: > > Not sure if that can help but both RCU_INIT_POINTER > > calls in veth_dellink can be before the unregister_netdevice_queue > > ones. May be it will help for the case when veth_dellink is > > called with head=NULL. As result, veth_xmit will free all > > flying skbs to peer that is unregistered first. > > Good point, but note that we never call dellink() method with head==NULL > in current kernels. Can it be a general problem with process_backlog delivering packets even after the ndo_stop call? It can happen even for devices that use napi_disable. synchronize_net simply misses packets processed on another CPU because process_backlog is not always in RCU read section. What about moving flush_backlog before NETDEV_UNREGISTER, it was after NETDEV_UNREGISTER_FINAL. It will work like a synchronize_net call. rollback_registered_many: 1. __dev_close_many: Commit netif_running, ndo_stop 2. on_each_cpu(flush_backlog, dev, 1): may be its place can be additionally tuned... 3. synchronize_net: not needed anymore? 4. call_netdevice_notifiers(NETDEV_UNREGISTER, dev) Compile-tested only: Regards --- Julian Anastasov -- 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/core/dev.c b/net/core/dev.c index c7ba038..e402661 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6034,6 +6036,7 @@ static void rollback_registered_many(struct list_head *head) unlist_netdevice(dev); dev->reg_state = NETREG_UNREGISTERING; + on_each_cpu(flush_backlog, dev, 1); } synchronize_net(); @@ -6657,8 +6660,6 @@ void netdev_run_todo(void) dev->reg_state = NETREG_UNREGISTERED; - on_each_cpu(flush_backlog, dev, 1); - netdev_wait_allrefs(dev); /* paranoia */