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: <CAE=gft5Vk3neDkyvmVf4CkBQQPVK=wXp=5jJ8n0uaosEwWUOAg@mail.gmail.com>
Date:   Mon, 4 Jun 2018 07:59:14 -0700
From:   Evan Green <evgreen@...omium.org>
To:     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 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).

-Evan