linux-kernel - Re: [PATCH 0/7] Enable UFS provisioning via Linux

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: <b844b80f-9f6f-10f7-6dfd-f92d905738e3@intel.com>
Date:   Fri, 8 Jun 2018 15:30:52 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Evan Green <evgreen@...omium.org>, Stanislav.Nijnikov@....com
Cc:     Vinayak Holikatti <vinholikatti@...il.com>,
        jejb@...ux.vnet.ibm.com, martin.petersen@...cle.com,
        linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
        Gwendal Grignou <gwendal@...omium.org>, Alex.Lemberg@....com,
        Avri.Altman@....com
Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux

On 04/06/18 17:59, Evan Green wrote:
> On Sun, Jun 3, 2018 at 3:21 AM Stanislav Nijnikov
> <Stanislav.Nijnikov@....com> wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: linux-scsi-owner@...r.kernel.org <linux-scsi-owner@...r.kernel.org> On Behalf Of Evan Green
>>> Sent: Friday, June 1, 2018 5:44 PM
>>> To: Stanislav Nijnikov <Stanislav.Nijnikov@....com>
>>> Cc: Vinayak Holikatti <vinholikatti@...il.com>; jejb@...ux.vnet.ibm.com; martin.petersen@...cle.com; linux-
>>> kernel@...r.kernel.org; linux-scsi@...r.kernel.org; Gwendal Grignou <gwendal@...omium.org>; Alex Lemberg
>>> <Alex.Lemberg@....com>; Avri Altman <Avri.Altman@....com>
>>> Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux
>>>
>>> Hi Stanislav. Thanks for taking a look. Responses below.
>>>
>>> On Thu, May 31, 2018 at 3:04 AM Stanislav Nijnikov
>>> <Stanislav.Nijnikov@....com> wrote:
>>>>
>>>> Hi Evan,
>>>> I have some generic notes:
>>>> - Why to create new sysfs entries for the configuration descriptor fields if they are just duplication of fields in the device and unit
>>> descriptors? And the sysfs representation of the device and unit descriptors is existing already.
>>>
>>> Well, UFS describes them as different descriptors. I worry that if I
>>> add a bunch of clever logic to hide the config descriptor behind other
>>> descriptors, there might be trouble later if 1) there is a quirky
>>> device that doesn't reflect the values between descriptors quite the
>>> same way or at the same time, or 2) if a later UFS spec adds more
>>> configuration descriptor fields that don't exactly reflect into other
>>> non-config descriptors, the cleverness will look awkward.
>>
>> No additional logic will be required to attach write functionality to the
>> existing entries instead of new defined ones. It will reduce the patch
>> size significantly. And there will be no need for the unit selector
>> mechanism which I'm not sure will be accepted by the SCSI community.
>>
> 
> So this would be modifying the existing sysfs entries so that reads
> still come from the device and unit descriptors, but writes go to
> equivalent fields in the config descriptor? I can explore that
> approach. Alternatively, if the unit selector mechanism is not
> desired, I could dynamically create sysfs directories for each unit in
> the config descriptor, but still bring out the config descriptor
> values as separate entries. (I still worry a bit about smashing the
> descriptors together as the UFS spec called them out as different).

If you use the unit attributes, how do you configure units that do not yet
exist?

Perhaps it is better to represent the configuration descriptors exactly as
they are defined in the specification.  Probably not worth exposing them at
all if the configuration is locked (attribute bConfigDescrLock == 1).

Note also that the 2.1 spec. defines  bConfDescContinue which allows updates
to be grouped and committed together.