linux-kernel - Re: [RFC PATCH v12 00/17] dlb: introduce DLB device driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <YcGhG8bdUi4WyXAf@lunn.ch>
Date:   Tue, 21 Dec 2021 10:40:43 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Mike Ximing Chen <mike.ximing.chen@...el.com>
Cc:     linux-kernel@...r.kernel.org, arnd@...db.de,
        gregkh@...uxfoundation.org, dan.j.williams@...el.com,
        pierre-louis.bossart@...ux.intel.com, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org
Subject: Re: [RFC PATCH v12 00/17] dlb: introduce DLB device driver

> 1. Before a scheduling domain is created/enabled, a set of parameters are
> passed to the kernel driver via configfs attribute files in an configfs domain
> directory (say $domain) created by user. Each attribute file corresponds to
> a configuration parameter of the domain. After writing to all the attribute
> files, user writes 1 to "create" attribute, which triggers an action (i.e.,
> domain creation) in the kernel driver. Since multiple processes/users can
> access the $domain directory, multiple users can write to the attribute files
> at the same time.  How do we guarantee an atomic update/configuration of a
> domain? In other words, if user A wants to set attributes 1 and 2, how can we
> prevent user B from changing attribute 1 and 2 before user A writes 1 to
> "create"? A configfs directory with individual attribute files seems to not
> be able to provide atomic configuration in this case. One option to solve this
> issue could be write a structured data (with a set of parameters) to a single
> attribute file. This would guarantee the atomic configuration, but may not be
> a conventional configfs operation.

How about throw away configfs and use netlink? Messages are atomic,
and you can add an arbitrary number of attributes to a single netlink
message. It will also make your code more network like, since nothing
else in the network stack uses configfs, as far as i know.

    Andrew