[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6817bc6-17bf-ee29-4910-9c287bbc6646@solarflare.com>
Date: Mon, 9 Mar 2020 22:40:05 +0000
From: Edward Cree <ecree@...arflare.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Paul Blakey <paulb@...lanox.com>
CC: Saeed Mahameed <saeedm@...lanox.com>,
Oz Shlomo <ozsh@...lanox.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Vlad Buslov <vladbu@...lanox.com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>
Subject: Re: [PATCH net-next ct-offload v2 05/13] net/sched: act_ct: Enable
hardware offload of flow table entires
On 09/03/2020 22:19, Marcelo Ricardo Leitner wrote:
> On Mon, Mar 09, 2020 at 09:25:49PM +0000, Edward Cree wrote:
>> This doesn't seem to apply to net-next (34a568a244be); the label after
>> the __module_get() is 'out_unlock', not 'take_ref'. Is there a missing
>> prerequisite patch? Or am I just failing to drive 'git am' correctly?
> That's a mid-air collision with Eric's
> [PATCH net-next] net/sched: act_ct: fix lockdep splat in tcf_ct_flow_table_get
> That went in in between v1 and v2 here.
>
> Marcelo
Thanks.
Unfortunately, although going back to that commit's parentmakes this
patch apply, #6 still doesn't, and I don't particularly feel like
playing whack-a-mole. Paul, could you either specify the base from
which you generated this series, or stick the branch somewhere that
can be pulled from, please? I'd like to build it so that I can
start experimenting with driver code to interface with it.
TiA,
-ed
Powered by blists - more mailing lists