Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2084867yba; Sat, 27 Apr 2019 14:06:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqxrzKKz+1SN797sfj2xPnZxyQ8cbMb+E68roYLf71ik7F5nkSQnChat3KVs1OB7qXiDeyqI X-Received: by 2002:a62:5f84:: with SMTP id t126mr54711085pfb.185.1556399187537; Sat, 27 Apr 2019 14:06:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556399187; cv=none; d=google.com; s=arc-20160816; b=UW/gLYpkbN9NAdyeWhZbXEwKiPTyQurLPZN525CvFcYthOXcz+YDxLr/eah0TsTnJu pgdn1sxeUuvAlVWNOFEKtqy0SBz7zfzzYzfFEBCASKfms3zQo4ZAV9nvXxrAKMJuBzah ZJBut7R5pIa3vrMyh1BY5Qke2knNwOcilQ6VeACMYTw6rztyd/8KjlRcuKwDo6ZYhLO+ Bl4uxhDUjDi3wiOiXgI0EBCh+1u5gUsGQh7+bgqty3X0SYFElxwgRELyT/riscqzwP66 RaWDac9TVZcIsDy/KbGIJt4bf3k3NjdVgdVAVqYpQa0mF6XN30WkIjnG37LAi6bQ18BS mQBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=P7H3Gkb04leykVSXWTob7WB7io0x0fDNaLnL65kkB+k=; b=PxEHeoU2GfaalbsJtEEo//aAtqpJVCQtwQVInyCAH7VFBJct3j6sxQNZnpZEcO11mA Ya5Al0ggZV9hS94QZv6X+IGWeu70InCaW0tYnv7FY9rVWuR8eGvmztalQ7V1fOeYYoDr dGhDvt1Mtbf0yA21kBvDJH/+/egloscWhCd/tmyrTeZjD4La9weHYeaRUu7skG4db72H hAMEybjn96k7h0zSumBIU5Y2nC9S0T3pQdxIOFMwTagHSf14r1cfGrXiDrL+v6/zbzuX DDN4YULh9kwVrbM3g2XUMMWUKZCO8Lsqu5tFB51jcvuoiGOLiH/mKrwNNSKwHmsOaAHV O0AQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d22si6041598plr.387.2019.04.27.14.06.11; Sat, 27 Apr 2019 14:06:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726480AbfD0VEH (ORCPT + 99 others); Sat, 27 Apr 2019 17:04:07 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:57356 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726088AbfD0VEH (ORCPT ); Sat, 27 Apr 2019 17:04:07 -0400 Received: from localhost (unknown [12.154.31.190]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 9F97614CF438B; Sat, 27 Apr 2019 14:04:05 -0700 (PDT) Date: Sat, 27 Apr 2019 17:04:02 -0400 (EDT) Message-Id: <20190427.170402.1871506886672225679.davem@davemloft.net> To: mkubecek@suse.cz Cc: netdev@vger.kernel.org, dsahern@gmail.com, johannes.berg@intel.com, jiri@mellanox.com, pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de, netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 0/3] make nla_nest_start() add NLA_F_NESTED flag From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sat, 27 Apr 2019 14:04:06 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michal Kubecek Date: Fri, 26 Apr 2019 11:13:03 +0200 (CEST) > One of the comments in recent review of the ethtool netlink series pointed > out that proposed ethnl_nest_start() helper which adds NLA_F_NESTED to > second argument of nla_nest_start() is not really specific to ethtool > netlink code. That is hard to argue with as closer inspection revealed that > exactly the same helper already exists in ipset code (except it's a macro > rather than an inline function). > > Another observation was that even if NLA_F_NESTED flag was introduced in > 2007, only few netlink based interfaces set it in kernel generated messages > and even many recently added APIs omit it. That is unfortunate as without > the flag, message parsers not familiar with attribute semantics cannot > recognize nested attributes and do not see message structure; this affects > e.g. wireshark dissector or mnl_nlmsg_fprintf() from libmnl. > > This is why I'm suggesting to rename existing nla_nest_start() to different > name (nla_nest_start_noflag) and reintroduce nla_nest_start() as a wrapper > adding NLA_F_NESTED flag. This is implemented in first patch which is > mostly generated by spatch. Second patch drops ipset helper macros which > lose their purpose. Third patch cleans up minor coding style issues found > by checkpatch.pl in first patch. > > We could leave nla_nest_start() untouched and simply add a wrapper adding > NLA_F_NESTED but that would probably preserve the state when even most new > code doesn't set the flag. Series applied, thank you.