linux-kernel - Re: [PATCH v1] can: netlink: report the CAN controller mode supported flags

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] [day] [month] [year] [list]

Message-ID: <CAMZ6RqKm+nLPd2oHgNebeDh2hSOMVnV7cJn12FM6NLpVaOz2iA@mail.gmail.com>
Date:   Sat, 9 Oct 2021 14:37:06 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can <linux-can@...r.kernel.org>
Cc:     netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] can: netlink: report the CAN controller mode supported flags

On Sun. 3 Oct 2021 at 13:40, Vincent Mailhol <mailhol.vincent@...adoo.fr> wrote:
> This patch introduces a method for the user to check both the
> supported and the static capabilities.
>
> Currently, the CAN netlink interface provides no easy ways to check
> the capabilities of a given controller. The only method from the
> command line is to try each CAN_CTRLMODE_ individually to check
> whether the netlink interface returns an -EOPNOTSUPP error or not
> (alternatively, one may find it easier to directly check the source
> code of the driver instead...)
>
> It appears that, currently, the struct can_ctrlmode::mask field is
> only used in one direction: from the userland to the kernel. So we can
> just reuse this field in the other direction (from the kernel to
> userland). But, because the semantic is different, we use a union to
> give this field a proper name: supported.
>
> Below table explains how the two fields can_ctrlmode::supported and
> can_ctrlmode::flags, when masked with any of the CAN_CTRLMODE_* bit
> flags, allow us to identify both the supported and the static
> capabilities:
>
>  supported &    flags &         Controller capabilities
>  CAN_CTRLMODE_* CAN_CTRLMODE_*
>  ------------------------------------------------------------------------
>  false          false           Feature not supported (always disabled)
>  false          true            Static feature (always enabled)
>  true           false           Feature supported but disabled
>  true           true            Feature supported and enabled
>
> N.B.: This patch relies on the fact that a given CAN_CTRLMODE_*
> feature can not be set for both can_priv::ctrlmode_supported and
> can_priv::ctrlmode_static at the same time. c.f. comments in struct
> can_priv [1]. Else, there would be no way to distinguish which
> features were statically enabled.

Actually, can_priv::ctrlmode_static can be derived from the other
ctrlmode fields. I will send a v2 in which I will add a patch to
replace that field with an inline function.

Yours sincerely,
Vincent Mailhol