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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D96BDC43334 for ; Thu, 23 Jun 2022 16:36:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231160AbiFWQgV (ORCPT ); Thu, 23 Jun 2022 12:36:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230512AbiFWQgU (ORCPT ); Thu, 23 Jun 2022 12:36:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F350242A1D for ; Thu, 23 Jun 2022 09:36:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8F4F261F4A for ; Thu, 23 Jun 2022 16:36:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8720FC3411B; Thu, 23 Jun 2022 16:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656002178; bh=RsDPzFgvYNRLpz/ox6kaO3NMlEjwDu8rxRGI+7CXLso=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kD5ldIdeuF6tWq7GXi2RQkLNudcGysU7LlwH0GYg8PlBKg2KGa3J3MM+3gRUe9lal Fx/iWyX9l0Fr/sk2434dsdQMYp4dP6DDDP918GjBJGyWgDPkxEyU68cbvZaVnyBeqT HrnvmO875stIKFL9D46yVTQ+wvoBVPAzrswaf9pcz1aoHxRmf1N8IewifGY6mmr3sR FUy4e79tX/sSmdyldXzx+wRHUDok3rlpMerovwWf5hbBLCPtXU2doG3hM849nahTbD JmefSy29JKCvk+wCNlXFsYe4h0VYH/WFpE97vG61Q9mzkHocUJF87r334Y0BzW/kPG yoY0ZEAmfi/ZQ== Date: Thu, 23 Jun 2022 09:36:09 -0700 From: Jakub Kicinski To: David Ahern Cc: Ismael Luceno , "David S. Miller" , Paolo Abeni , "netdev@vger.kernel.org" Subject: Re: Netlink NLM_F_DUMP_INTR flag lost Message-ID: <20220623093609.1b104859@kernel.org> In-Reply-To: References: <20220615171113.7d93af3e@pirotess> <20220615090044.54229e73@kernel.org> <20220616171016.56d4ec9c@pirotess> <20220616171612.66638e54@kernel.org> <20220617150110.6366d5bf@pirotess> <20220622131218.1ed6f531@pirotess> <20220622165547.71846773@kernel.org> <20220623090352.69bf416c@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 23 Jun 2022 10:17:17 -0600 David Ahern wrote: > > Yup, the question for me is what's the risk / benefit of sending > > the empty message vs putting the _DUMP_INTR on the next family. > > I'm leaning towards putting it on the next family and treating > > the entire dump as interrupted, do you reckon that's suboptimal? > > I think it is going to be misleading; the INTR flag needs to be set on > the dump that is affected. Right, it's a bit of a philosophical discussion but dump is delineated but NLMSG_DONE. PF_UNSPEC dump is a single dump, not a group of multiple independent per-family dumps. If we think of a nlmsg as a representation of an object having an empty one is awkward. What if someone does a dump to just count objects? Too speculative? I guess one can argue either way, no empty messages is a weaker promise and hopefully lower risk, hence my preference. Do you feel strongly for the message? Do we flip a coin? :) > All of the dumps should be checking the consistency at the end of the > dump - regardless of any remaining entries on a particular round (e.g., > I mentioned this what the nexthop dump does). Worst case then is DONE > and INTR are set on the same message with no data, but it tells > explicitly the set of data affected. Okay, perhaps we should put a WARN_ON_ONCE(seq && seq != prev_seq) in rtnl_dump_all() then, to catch those who get it wrong.