From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next 2/4] net: sched: introduce per-egress action device callbacks Date: Tue, 10 Oct 2017 17:39:51 +0200 Message-ID: <20171010153951.GI2033@nanopsycho> References: <20171010073016.3682-1-jiri@resnulli.us> <20171010073016.3682-3-jiri@resnulli.us> <063D6719AE5E284EB5DD2968C1650D6DD008ED67@AcuExch.aculab.com> <20171010143152.GG2033@nanopsycho> <063D6719AE5E284EB5DD2968C1650D6DD008F06E@AcuExch.aculab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netdev@vger.kernel.org" , "davem@davemloft.net" , "jhs@mojatatu.com" , "xiyou.wangcong@gmail.com" , "saeedm@mellanox.com" , "matanb@mellanox.com" , "leonro@mellanox.com" , "mlxsw@mellanox.com" To: David Laight Return-path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:48186 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932287AbdJJPjx (ORCPT ); Tue, 10 Oct 2017 11:39:53 -0400 Received: by mail-wm0-f52.google.com with SMTP id i124so6326513wmf.3 for ; Tue, 10 Oct 2017 08:39:53 -0700 (PDT) Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD008F06E@AcuExch.aculab.com> Sender: netdev-owner@vger.kernel.org List-ID: Tue, Oct 10, 2017 at 05:12:34PM CEST, David.Laight@ACULAB.COM wrote: >From: Jiri Pirko >> Sent: 10 October 2017 15:32 >> To: David Laight >> Cc: netdev@vger.kernel.org; davem@davemloft.net; jhs@mojatatu.com; xiyou.wangcong@gmail.com; >> saeedm@mellanox.com; matanb@mellanox.com; leonro@mellanox.com; mlxsw@mellanox.com >> Subject: Re: [patch net-next 2/4] net: sched: introduce per-egress action device callbacks >> >> Tue, Oct 10, 2017 at 03:31:59PM CEST, David.Laight@ACULAB.COM wrote: >> >From: Jiri Pirko >> >> Sent: 10 October 2017 08:30 >> >> Introduce infrastructure that allows drivers to register callbacks that >> >> are called whenever tc would offload inserted rule and specified device >> >> acts as tc action egress device. >> > >> >How does a driver safely unregister a callback? >> >(to avoid a race with the callback being called.) >> > >> >Usually this requires a callback in the context that makes the >> >notification callbacks indicating that no more such callbacks >> >will be made. >> >> rtnl is your answer. It is being held during register/unregister/cb > >Do you mean 'acquired during register/unregister' and 'held across the >callback' ? > >So the unregister sleeps (or spins?) until any callbacks complete? >So the driver mustn't hold any locks (etc) across the unregister that >it acquires in the callback. >That ought to be noted somewhere. You actually have a point. I don't take rtnl for reg/unreg as I suppose to. Will fix. > > David >