From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754649AbdKAN7v (ORCPT ); Wed, 1 Nov 2017 09:59:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48208 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751853AbdKAN7t (ORCPT ); Wed, 1 Nov 2017 09:59:49 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A7C5D7E38A Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mst@redhat.com Date: Wed, 1 Nov 2017 15:59:48 +0200 From: "Michael S. Tsirkin" To: Jason Wang Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, willemdebruijn.kernel@gmail.com, tom@herbertland.com Subject: Re: [PATCH net-next V2 3/3] tun: add eBPF based queue selection method Message-ID: <20171101150458-mutt-send-email-mst@kernel.org> References: <1509445938-4345-1-git-send-email-jasowang@redhat.com> <1509445938-4345-4-git-send-email-jasowang@redhat.com> <20171031184002-mutt-send-email-mst@kernel.org> <43c86606-2911-768d-704f-8b25e04cb47b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43c86606-2911-768d-704f-8b25e04cb47b@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 01 Nov 2017 13:59:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 01, 2017 at 09:02:03PM +0800, Jason Wang wrote: > > > On 2017年11月01日 00:45, Michael S. Tsirkin wrote: > > > +static void __tun_set_steering_ebpf(struct tun_struct *tun, > > > + struct bpf_prog *new) > > > +{ > > > + struct bpf_prog *old; > > > + > > > + old = rtnl_dereference(tun->steering_prog); > > > + rcu_assign_pointer(tun->steering_prog, new); > > > + > > > + if (old) { > > > + synchronize_net(); > > > + bpf_prog_destroy(old); > > > + } > > > +} > > > + > > Is this really called under rtnl? > > Yes it is __tun_chr_ioctl() will call rtnl_lock(). Is the call from tun_free_netdev under rtnl too? > > If no then rtnl_dereference > > is wrong. If yes I'm not sure you can call synchronize_net > > under rtnl. > > > > Are you worrying about the long wait? Looking at synchronize_net(), it does: > > void synchronize_net(void) > { >     might_sleep(); >     if (rtnl_is_locked()) >         synchronize_rcu_expedited(); >     else >         synchronize_rcu(); > } > EXPORT_SYMBOL(synchronize_net); > > Thanks Not the wait - expedited is not a good thing to allow unpriveledged userspace to do, it interrupts all VMs running on the same box. We could use a callback though the docs warn userspace can use that to cause a DOS and needs to be limited. -- MST