Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7599411pxb; Thu, 18 Feb 2021 14:44:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJwiTO/17G03Hpud4aEN5Wtj9jhC4sHUjfcfbyTCNByYa7qgS0jptnbAh47By7NxpiERcN9e X-Received: by 2002:a05:6402:3133:: with SMTP id dd19mr6111523edb.337.1613688280884; Thu, 18 Feb 2021 14:44:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613688280; cv=none; d=google.com; s=arc-20160816; b=mKpZbwlLgi/c77QdWcGFwy15J4mmEyxZas6tfOgUXgua+LPSSZCSWXSUjoSz05l8+T ic7qBd4CaxOSTxFRdYRv6PTTKWqssh39YbiiAEBew7OBoRHi5avwiv6vghh8+9qylOux vyT44zuivK3vafpMPBs4l3yBzyhvNOtVzn+2TVxiTXO9eNYlSBULSBJxJaPaCOeQROg5 /pNNefF3s4pTDtP06gNZomFrkN2vMPpGplwTrJO/e1GNJP4rZ/JNXT79nVfVlrt6aWWF BedDlad+VhI5r+g8Wuq5vOhBQ17MCM0/CJwO5/Vml25VwjuNdeCwN1mlfoc1hkqGJmzP oriQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=6oo3mNH6xM9RyfYe8Tkd1cr7rZ1Rfcxv3Jxjzl+xm50=; b=QIdIWFk1J7Ilf5iq2hFanrmdFn0aL3Pmj2NLaEpn7fhRbZL7i+A0jTnCZVvGUSu0yM Hxi1eyZohAv8nYT/TnrdLbUm1GYUOhwzpZLPDdQZN1XjEZWtxI8hntxVeM5VnJo3V8+1 /1Y5vKOef2VdIHf5cR2rXZ0opOhTq3BWu8mgTZBKhbA33KXvf3Tk7xDwHwNHGNqVkDqi FFvPoX/o4J+m3MJCbfpLa50MTWkw7gftwD68g2m3U7+5iJMNQ9amCEZPNdf2kBDEIzUZ zhRabfQ/BTUhdfyLlKlK5D6tOFFhrV+9qIVhK1YJHfun1rHAsXGcSLMimtl/oEN5kED7 5DbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f12si4197489edd.7.2021.02.18.14.44.17; Thu, 18 Feb 2021 14:44:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229894AbhBRWmp (ORCPT + 99 others); Thu, 18 Feb 2021 17:42:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229787AbhBRWmo (ORCPT ); Thu, 18 Feb 2021 17:42:44 -0500 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10230C061574; Thu, 18 Feb 2021 14:42:04 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1lCrzk-0000sB-40; Thu, 18 Feb 2021 23:42:00 +0100 Date: Thu, 18 Feb 2021 23:42:00 +0100 From: Florian Westphal To: Richard Guy Briggs Cc: Florian Westphal , Phil Sutter , LKML , Linux-Audit Mailing List , netfilter-devel@vger.kernel.org, twoerner@redhat.com, Eric Paris , tgraf@infradead.org Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events Message-ID: <20210218224200.GF22944@breakpoint.cc> References: <20210211151606.GX3158@orbyte.nwl.cc> <20210211202628.GP2015948@madcap2.tricolour.ca> <20210211220930.GC2766@breakpoint.cc> <20210217234131.GN3141668@madcap2.tricolour.ca> <20210218082207.GJ2766@breakpoint.cc> <20210218124211.GO3141668@madcap2.tricolour.ca> <20210218125248.GB22944@breakpoint.cc> <20210218212001.GQ3141668@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210218212001.GQ3141668@madcap2.tricolour.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Richard Guy Briggs wrote: > > If they appear in a batch tehy will be ignored, if the batch consists of > > such non-modifying ops only then nf_tables_commit() returns early > > because the transaction list is empty (nothing to do/change). > > Ok, one little inconvenient question: what about GETOBJ_RESET? That > looks like a hybrid that modifies kernel table counters and reports > synchronously. That could be a special case call in > nf_tables_dump_obj() and nf_tables_getobj(). Will that cause a storm > per commit? No, since they can't be part of a commit (they don't implement the 'call_batch' function). I'm not sure GETOBJ_RESET should be reported in the first place: RESET only affects expr internal state, and that state changes all the time anyway in response to network traffic.