Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
IronPort-SDR: Z0cQldfI4hvPrS8jXVdeYzbuKe2MEoUBcfo7vWwtz69Oc2nbygsbgqnxaXJQaQqPm0cw09MGxx
 bkFVlHO98BT7OTpm4AleReB0RSeAJhEEPUcN3Rl5Idgbsw9BmuzSZYVWQqlSKVn6N0NiKdj/V+
 odEzfi2y3Q7mgm0Ia2uxbESnUOelXCxqg15aGSxPR6c/c88wGLE6mVvPDU+c2GN02D5xHN//Ef
 CZ5f1kgh/dB4RQi+Rq/G5Y9OC6ECgnMHgOLjyFdUckVAp5VtQ3AgO5RaWrgKIkFkRFrpEwIoOc
 VFXe1VX1tIdfdtt6cYSxdjda
IronPort-SDR: +HlS3DEebCCQFXhLTnXSHlPbs7NMqdgFg16LjREpf7ODNMniOJwrCPIaf7ZGBdgtfUQg0/ZoKf
 4+IrcRptwt76uIyfvmgZqJKfXXAHu8g3Fdlz4WW0DR5qFANmRYopICMz8u1j4sYUlBJQMU8u57
 0ysOm+XlCqSUUzIvjn5JhHsO5Lwvhf6fpDc37U9yU2zmWPVvGWYM2ycCQY+FdXsLNHScmduTCY
 796RPUHI8Yu9nwpklg3euwRDFl48bGm93ChfTi1ucqUmzxzs76gl6gctEtN/iBPkn63Znwyq/V
 jjk=
WDCIronportException: Internal
Message-ID: <84bb2d37-4097-5122-7e88-33bd9bc7ed61@opensource.wdc.com>
Date:   Tue, 7 Jun 2022 09:42:21 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.1
Subject: Re: [RESEND PATCH] scsi: ufs: sysfs: support writing boot_lun attr
Content-Language: en-US
To:     Bart Van Assche <bvanassche@acm.org>,
        Avri Altman <Avri.Altman@wdc.com>,
        Caleb Connolly <caleb.connolly@linaro.org>,
        "a5b6@riseup.net" <a5b6@riseup.net>,
        Alim Akhtar <alim.akhtar@samsung.com>,
        "James E . J . Bottomley" <jejb@linux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc:     "~postmarketos/upstreaming@lists.sr.ht" 
        <~postmarketos/upstreaming@lists.sr.ht>,
        "phone-devel@vger.kernel.org" <phone-devel@vger.kernel.org>
References: <20220525164013.93748-1-a5b6@riseup.net>
 <DM6PR04MB65750969ACD36EEEB48374DFFCD69@DM6PR04MB6575.namprd04.prod.outlook.com>
 <8d25171a-5d86-9acc-0f94-1a3c6efdb360@riseup.net>
 <DM6PR04MB65752422396C86EAD4591701FCD89@DM6PR04MB6575.namprd04.prod.outlook.com>
 <a7f46ad1-6d9e-a38e-31cc-29fddfa2b496@linaro.org>
 <DM6PR04MB65751A3B1D0BA4467CADDA93FCDF9@DM6PR04MB6575.namprd04.prod.outlook.com>
 <a4746c67-fa74-8af1-3f2d-7853e9fae8a6@acm.org>
 <3c400db6-d251-c4bd-b019-b9dc1d807212@opensource.wdc.com>
 <2677b02e-b2a3-7c79-2e62-acf1acbc8ff0@acm.org>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital Research
In-Reply-To: <2677b02e-b2a3-7c79-2e62-acf1acbc8ff0@acm.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/06/06 22:16, Bart Van Assche wrote:
> On 6/5/22 19:48, Damien Le Moal wrote:
>> On 6/5/22 12:55, Bart Van Assche wrote:
>>> On 6/1/22 10:05, Avri Altman wrote:
>>>> As a design rule, sysfs attribute files should not be used to make
>>>> persistent modifications to a device configuration. This rule applies
>>>> to all subsystems and ufs is no different.
>>>
>>> Hmm ... where does that rule come from? I can't find it in
>>> Documentation/admin-guide/sysfs-rules.rst. Did I perhaps overlook something?
>>
>> I am not aware of any writable sysfs attribute file that can be used to
>> make persistent device configuration changes, at least in storage area.
>> I know of plenty that do change a device setting, but without saving this
>> setting to maintain it across power cycles. Do you know of any such
>> attribute ? I was under the impression that sysfs should not be used to
>> persistently reconfigure a device...
> 
> I don't think the above is sufficient as an argument to reject a new 
> patch that introduces a sysfs attribute that changes the device 
> configuration.

It depends if we can guarantee that the write access to the sysfs file is done
with the same security checks as for a passthrough command issued from user
space. I have not checked.

I would also argue that this particular feature is related to the boot device
management, which is not something we do in the kernel. There is no sysfs
interface to set the bootable flag of a partition on a disk, right ? That is
very similar to me. The kernel should not bother about that kind of interface.
User application tools can deal with that.

> 
> Thanks,
> 
> Bart.
> 


-- 
Damien Le Moal
Western Digital Research