From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AB2CC31E5B for ; Mon, 17 Jun 2019 16:00:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4E4B7208C4 for ; Mon, 17 Jun 2019 16:00:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726151AbfFQQAc (ORCPT ); Mon, 17 Jun 2019 12:00:32 -0400 Received: from orbyte.nwl.cc ([151.80.46.58]:33416 "EHLO orbyte.nwl.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbfFQQAc (ORCPT ); Mon, 17 Jun 2019 12:00:32 -0400 Received: from n0-1 by orbyte.nwl.cc with local (Exim 4.91) (envelope-from ) id 1hcu3a-0001fq-CA; Mon, 17 Jun 2019 18:00:30 +0200 Date: Mon, 17 Jun 2019 18:00:30 +0200 From: Phil Sutter To: Pablo Neira Ayuso Cc: netfilter-devel@vger.kernel.org, fw@strlen.de Subject: Re: [PATCH nft 2/5] tests: shell: cannot use handle for non-existing rule in kernel Message-ID: <20190617160030.GS31548@orbyte.nwl.cc> Mail-Followup-To: Phil Sutter , Pablo Neira Ayuso , netfilter-devel@vger.kernel.org, fw@strlen.de References: <20190617122518.10486-1-pablo@netfilter.org> <20190617122518.10486-2-pablo@netfilter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190617122518.10486-2-pablo@netfilter.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Hi, On Mon, Jun 17, 2019 at 02:25:15PM +0200, Pablo Neira Ayuso wrote: > This test invokes the 'replace rule ... handle 2' command. However, > there are no rules in the kernel, therefore it always fails. This guesses the previously inserted rule's handle. Does this start failing with your flags conversion in place? My initial implementation of intra-transaction rule references made this handle guessing impossible, but your single point cache fetching still allowed for it (hence why I dropped my patch with a similar change). Cheers, Phil