netdev - Re: [PATCH mlx5-next v1 1/8] net/mlx5: Add forward compatible support for the FTE match data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMipJhe0PdsmR7kshrG-dXSqaLJ5xorwbMZyBvdXy0jA0A@mail.gmail.com>
Date:   Thu, 12 Jul 2018 23:53:54 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Yishai Hadas <yishaih@...lanox.com>
Cc:     Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Leon Romanovsky <leonro@...lanox.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH mlx5-next v1 1/8] net/mlx5: Add forward compatible support
 for the FTE match data

On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@...nel.org> wrote:
> From: Yishai Hadas <yishaih@...lanox.com>
>
> Use the PRM size including the reserved when working with the FTE
> match data.

is this actually a bug fix?

> This comes to support forward compatibility for cases that current
> reserved data will be exposed by the firmware and could be used by an
> application by DEVX without changing the kernel.

something went wrong in the phrasing/wording of "used by an application by DEVX"
I can't follow on that part of the sentence, please try to improve/fix it.

> Also drop some driver checks around the match criteria leaving the work
> for firmware to enable forward compatibility for future bits there.

not following,

OTOH we can always patch the kernel to add new bits for checking, why
remove these checks?

OTOH, suppose today we check that one of four bits is set and now one
added bit #5 and the
kernel doesn't check it, what removing the existing four checks buys you?