linux-kernel - Re: [PATCH 2/2] scsi: ufs: Add support for critical health notification

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] [day] [month] [year] [list]

Message-ID: <a451e938-5385-4ab0-b063-b962b10f3458@roeck-us.net>
Date: Mon, 3 Feb 2025 09:44:09 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Avri Altman <Avri.Altman@....com>,
 "Martin K . Petersen" <martin.petersen@...cle.com>
Cc: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Bart Van Assche <bvanassche@....org>
Subject: Re: [PATCH 2/2] scsi: ufs: Add support for critical health
 notification

On 2/3/25 09:25, Avri Altman wrote:
>> On 2/3/25 07:27, Avri Altman wrote:
>>> The UFS 4.1 standard, released on January 8, 2025, introduces several
>>> new features, including a new exception event: HEALTH_CRITICAL. This
>>> event notifies the host of a device's critical health condition,
>>> indicating that the device is approaching the end of its lifetime
>>> based on the number of program/erase cycles performed.
>>>
>>> We utilize the hwmon (hardware monitoring) subsystem to propagate this
>>> information via the chip alarm channel.
>>>
>>
>> That is outside the scope of the hardware monitoring subsystem, the
>> "alarms" attribute is deprecated and must not be used in new drivers, and it
>> isn't actually implemented by this code.
> OK.  Thanks for letting me know.
> Do you see any other path I can take within the hwmon,
> To let the upper stack / HAL know that the ufs device is reaching its EOL ?
> Or should I look elsewhere?
> 

Again, this is not a hardware monitoring attribute. Normally I'd assume
that information like this is reported, for example, via smartctl or
whatever similar mechanism is available for ufs devices.

Just to give an example: smartctl reports for one of the nvme drives
in my system:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        39 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    10,835,485 [5.54 TB]
Data Units Written:                 4,931,062 [2.52 TB]
Host Read Commands:                 149,936,032
Host Write Commands:                36,799,659
Controller Busy Time:               318
Power Cycles:                       12
Power On Hours:                     326
Unsafe Shutdowns:                   4
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               39 Celsius
Temperature Sensor 2:               41 Celsius

Per your logic, all of that could be declared to be "hardware monitoring".
That simply doesn't make sense. All that information is reported by smartctl,
and it can and should be monitored using smartd or a similar tool. There is
no need to invent a new mechanism to do the same. If smartmontools don't
support ufs, such support should be added there, and not be pressed into
some unrelated kernel subsystem.

Thanks,
Guenter