Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751659AbdG1EFG (ORCPT ); Fri, 28 Jul 2017 00:05:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44542 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750785AbdG1EFF (ORCPT ); Fri, 28 Jul 2017 00:05:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CFF82C08EA9E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mst@redhat.com Date: Fri, 28 Jul 2017 07:05:03 +0300 From: "Michael S. Tsirkin" To: Jason Wang Cc: Jakub Kicinski , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 3/3] tap: XDP support Message-ID: <20170728070329-mutt-send-email-mst@kernel.org> References: <1501147533-12368-1-git-send-email-jasowang@redhat.com> <1501147533-12368-4-git-send-email-jasowang@redhat.com> <20170727201338.65d56b2a@cakuba.netronome.com> <7d1cb7bf-43c1-3993-be00-04e4676dd917@redhat.com> <20170728064603-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 28 Jul 2017 04:05:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 835 Lines: 24 On Fri, Jul 28, 2017 at 11:50:45AM +0800, Jason Wang wrote: > > > On 2017年07月28日 11:46, Michael S. Tsirkin wrote: > > On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote: > > > > > + old_prog = rtnl_dereference(tun->xdp_prog); > > > > > + if (old_prog) > > > > > + bpf_prog_put(old_prog); > > > > > + rcu_assign_pointer(tun->xdp_prog, prog); > > > > Is this OK? Could this lead to the program getting freed and then > > > > datapath accessing a stale pointer? I mean in the scenario where the > > > > process gets pre-empted between the bpf_prog_put() and > > > > rcu_assign_pointer()? > > > Will call bpf_prog_put() after rcu_assign_pointer(). > > I suspect you need to sync RCU or something before that. > > __bpf_prog_put() will do call_rcu(), so looks like it was ok. > > Thanks True - I missed that. -- MST