Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 27 Sep 2022 11:27:10 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
        Rui Sousa <rui.sousa@nxp.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        UNGLinuxDriver@microchip.com,
        Horatiu Vultur <horatiu.vultur@microchip.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Michael Walle <michael@walle.cc>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Maxim Kochetkov <fido_max@inbox.ru>,
        Colin Foster <colin.foster@in-advantage.com>,
        Richie Pearn <richard.pearn@nxp.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        Giuseppe Cavallaro <peppe.cavallaro@st.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        Jose Abreu <joabreu@synopsys.com>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Gerhard Engleder <gerhard@engleder-embedded.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net-next 01/12] net/sched: taprio: allow user input
 of per-tc max SDU
Message-ID: <20220927112710.5fc7720f@kernel.org>
In-Reply-To: <20220927150921.ffjdliwljccusxad@skbuf>
References: <20220923163310.3192733-1-vladimir.oltean@nxp.com>
        <20220923163310.3192733-2-vladimir.oltean@nxp.com>
        <20220926133829.6bb62b8a@kernel.org>
        <20220927150921.ffjdliwljccusxad@skbuf>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 27 Sep 2022 18:09:21 +0300 Vladimir Oltean wrote:
> On Mon, Sep 26, 2022 at 01:38:29PM -0700, Jakub Kicinski wrote:
> > On Fri, 23 Sep 2022 19:32:59 +0300 Vladimir Oltean wrote:  
> > > +	if (!tb[TCA_TAPRIO_TC_ENTRY_INDEX]) {
> > > +		NL_SET_ERR_MSG_MOD(extack, "TC entry index missing");  
> > 
> > NL_SET_ERR_ATTR_MISS() ?
> >   
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]);
> > > +	if (tc >= TC_QOPT_MAX_QUEUE) {
> > > +		NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range");  
> > 
> > NLA_POLICY_MAX()
> > 
> > Are you not using those on purpose? :(  
> 
> I don't exactly see it as being super user friendly to leave it to the
> policy validator (or to use NL_SET_ERR_ATTR_MISS()) because all that
> will be reported back to user space will be the offset to the original
> attribute in the nlmsghdr, which is pretty hard to retrieve and
> re-interpret (at least in the iproute2 tc source code, I can't seem to
> find a way to stringify it or something like that). For the NLA_POLICY_MAX(),
> all I'll get now is an uninformative "Error: integer out of range."
> What integer?  What range?

I know, that's what I expected you'd say :(
You'd need a reverse parser which is a PITA to do unless you have
clearly specified bindings.

> I don't understand what is the gain of removing extack message strings
> and just pointing to the netlink attribute via NLMSGERR_ATTR_OFFS? Could
> I at least use the NL_SET_ERR_ATTR_MISS() helper *and* set a custom message?
> That's for the missing nlattr. Regarding the range checking in the
> policy, I'd like a custom message there as well, but the NLA_POLICY_MAX()
> doesn't provide one. However, I see that struct nla_policy has a const
> char *reject_message for NLA_REJECT types. Would it be an abuse to move
> this outside of the union and allow U32 policies and such to also
> provide it?

I'd rather you kept the code as is than make precedent for adding both
string and machine readable. If we do that people will try to stay on
the safe side and always add both.

The machine readable format is carries all the information you need.
It's just the user space is not clever enough to read it which is,
well, solvable.