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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CO1PR11MB51708FDE2087EE1F382AD14CD97D9@CO1PR11MB5170.namprd11.prod.outlook.com>
Date:   Wed, 22 Dec 2021 04:37:29 +0000
From:   "Chen, Mike Ximing" <mike.ximing.chen@...el.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
Subject: RE: [RFC PATCH v12 00/17] dlb: introduce DLB device driver



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, December 21, 2021 4:41 AM
> To: Chen, Mike Ximing <mike.ximing.chen@...el.com>
> Cc: linux-kernel@...r.kernel.org; arnd@...db.de; gregkh@...uxfoundation.org; Williams, Dan J
> <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.
> 
Hi Andrew,
As I explained in my other response, DLB is not a network accelerator and DLB
driver is not a part of network stack. We would obviously prefer to resolve the
atomic update and resource reset at tear-down Issues within the configfs
framework if possible. But I will take a look at the netlink implementations.

Thanks for the suggestion
Mike