Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Thu, 19 Oct 2023 15:42:02 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Paolo Abeni <pabeni@redhat.com>
Cc:     Gerhard Engleder <gerhard@engleder-embedded.com>,
        Lai Peter Jun Ann <jun.ann.lai@intel.com>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2 1/1] taprio: Add boundary check for
 sched-entry values
Message-ID: <20231019124202.fldo2cc5s6w4hrxz@skbuf>
References: <1697599707-3546-1-git-send-email-jun.ann.lai@intel.com>
 <27912b49-eb1a-4100-a260-03299e8efdd4@engleder-embedded.com>
 <bca0aca50914367fffccf33b2f2ac880808d6cd9.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bca0aca50914367fffccf33b2f2ac880808d6cd9.camel@redhat.com>
Precedence: bulk

On Thu, Oct 19, 2023 at 12:35:30PM +0200, Paolo Abeni wrote:
> On Wed, 2023-10-18 at 19:56 +0200, Gerhard Engleder wrote:
> > On 18.10.23 05:28, Lai Peter Jun Ann wrote:
> > > Adds boundary checks for the gatemask provided against the number of
> > > traffic class defined for each sched-entry.
> > > 
> > > Without this check, the user would not know that the gatemask provided is
> > > invalid and the driver has already truncated the gatemask provided to
> > > match the number of traffic class defined.
> > > 
> > > Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
> > > Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>
> > > Signed-off-by: Lai Peter Jun Ann <jun.ann.lai@intel.com>
> > > ---
> > >   net/sched/sch_taprio.c | 8 ++++++++
> > >   1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > > index 1cb5e41..44b9e21 100644
> > > --- a/net/sched/sch_taprio.c
> > > +++ b/net/sched/sch_taprio.c
> > > @@ -102,6 +102,7 @@ struct taprio_sched {
> > >   	u32 max_sdu[TC_MAX_QUEUE]; /* save info from the user */
> > >   	u32 fp[TC_QOPT_MAX_QUEUE]; /* only for dump and offloading */
> > >   	u32 txtime_delay;
> > > +	u8 num_tc;

To the patch: I would oppose introducing an "u8 num_tc" to struct
taprio_sched for one purpose only. It is a duplication of
netdev->num_tc, the only problem is that it hasn't yet been set, which
can be solved with a bit of code reorganization.

> > >   };
> > >   
> > >   struct __tc_taprio_qopt_offload {
> > > @@ -1063,6 +1064,11 @@ static int fill_sched_entry(struct taprio_sched *q, struct nlattr **tb,
> > >   		return -EINVAL;
> > >   	}
> > >   
> > > +	if (entry->gate_mask >= q->num_tc) {
> > 
> > As far as I know within gate_mask every bit represents a traffic class.
> > So for 3 traffic classes at gate_mask of 0x7 is valid but this check
> > fails with 0x7 >= 3.
> 
> Additionally whatever check we put in place previously just ignored by
> the existing code, could break the existing user-space: we can't accept
> such change. 

I agree, and I would oppose erroring out.

I used to have this patch which simply masks off the excess bits,
calling netdev_warn() - which can be transformed into a warning netlink
extack - instead.
https://patchwork.kernel.org/project/netdevbpf/patch/20230130173145.475943-15-vladimir.oltean@nxp.com/

I didn't have a strong motivation for the patch, and I dropped it.
If Lai Peter Jun Ann can come with the motivation, we can go with that
approach.