[PATCH 0/2] nvme: make SMART / Health Status AENs reach hwmon alarms

[PATCH 0/2] nvme: make SMART / Health Status AENs reach hwmon alarms

[Guixin Liu]

The NVMe hwmon support exposes the temperature alarm as a plain sysfs
attribute, so monitoring tools have to poll temp1_alarm to learn about
a critical temperature or spare-block condition. The device does send a
SMART / Health Status asynchronous event when its health status
changes, but the host never subscribes to it, and the completion path
silently drops the event.

This series wires the event through:

  Patch 1 defines the missing OAES bit in the uapi header.
  Patch 2 subscribes to the event and wakes pollers on temp1_alarm.

The alarm read fetches the SMART log on demand, so the completion path
only queues a work item to call sysfs_notify() — nvme-pci completes
asynchronous events from interrupt context, where sysfs_notify() cannot
sleep.

Testing: verified end to end against QEMU's nvme emulation (with a
one-line local patch reporting OAES bit 1, matching an NVMe 2.0
device): injecting smart_critical_warning over QMP delivers the AEN,
poll(2) on temp1_alarm wakes immediately with EPOLLERR|EPOLLPRI and
reads alarm=1; clearing the warning produces no event and no spurious
wake; re-injecting the bit wakes again.

Guixin Liu (2):
  nvme: define the SMART / Health Status async event bit
  nvme-hwmon: notify hwmon alarms on the SMART / Health Status AEN

 drivers/nvme/host/core.c  |  8 ++++++--
 drivers/nvme/host/hwmon.c | 30 ++++++++++++++++++++++++++++++
 drivers/nvme/host/nvme.h  |  5 +++++
 include/linux/nvme.h      |  2 ++
 4 files changed, 43 insertions(+), 2 deletions(-)

Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>

-- 
2.43.7

[PATCH 1/2] nvme: define the SMART / Health Status async event bit

[Guixin Liu]

NVMe 2.x requires controllers to support the SMART / Health Status
asynchronous event (OAES bit 1), but the only event bits the header
defines are namespace attribute, firmware activation, ANA change and
discovery change. Define the missing bit so the host can subscribe to
the event.

Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
---
 include/linux/nvme.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/nvme.h b/include/linux/nvme.h
index 6248711784b37..2b4f8e269d12d 100644
--- a/include/linux/nvme.h
+++ b/include/linux/nvme.h
@@ -867,6 +867,7 @@ enum {
 };
 
 enum {
+	NVME_AEN_BIT_SMART		= 1,
 	NVME_AEN_BIT_NS_ATTR		= 8,
 	NVME_AEN_BIT_FW_ACT		= 9,
 	NVME_AEN_BIT_ANA_CHANGE		= 11,
@@ -874,6 +875,7 @@ enum {
 };
 
 enum {
+	NVME_AEN_CFG_SMART		= 1 << NVME_AEN_BIT_SMART,
 	NVME_AEN_CFG_NS_ATTR		= 1 << NVME_AEN_BIT_NS_ATTR,
 	NVME_AEN_CFG_FW_ACT		= 1 << NVME_AEN_BIT_FW_ACT,
 	NVME_AEN_CFG_ANA_CHANGE		= 1 << NVME_AEN_BIT_ANA_CHANGE,
-- 
2.43.7

Re: [PATCH 1/2] nvme: define the SMART / Health Status async event bit

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] nvme: NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART use wrong
  OAES/CFG bit
--

commit be7079eb32755ede896d21f96ed7d1785a179279
Author: Guixin Liu <kanie@linux.alibaba.com>

nvme: define the SMART / Health Status async event bit

This commit adds NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART definitions to
include/linux/nvme.h.

> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
> index 6248711784b37..2b4f8e269d12d 100644
> --- a/include/linux/nvme.h
> +++ b/include/linux/nvme.h
> @@ -867,6 +867,7 @@ enum {
>  };
>  
>  enum {
> +	NVME_AEN_BIT_SMART		= 1,
>  	NVME_AEN_BIT_NS_ATTR		= 8,
>  	NVME_AEN_BIT_FW_ACT		= 9,
>  	NVME_AEN_BIT_ANA_CHANGE		= 11,
> @@ -874,6 +875,7 @@ enum {
>  };
>  
>  enum {
> +	NVME_AEN_CFG_SMART		= 1 << NVME_AEN_BIT_SMART,
>  	NVME_AEN_CFG_NS_ATTR		= 1 << NVME_AEN_BIT_NS_ATTR,
>  	NVME_AEN_CFG_FW_ACT		= 1 << NVME_AEN_BIT_FW_ACT,
>  	NVME_AEN_CFG_ANA_CHANGE		= 1 << NVME_AEN_BIT_ANA_CHANGE,

[Severity: Medium]
Do NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART match the NVMe specification
for Identify Controller OAES and NVME_FEAT_ASYNC_EVENT?

The value 1 is the Asynchronous Event Type (NVME_AER_SMART = 1) reported
in CQE DW0 bits 2:0, not an OAES or Asynchronous Event Configuration bit.
In the NVMe Base Specification, SMART / Health Critical Warning events are
mandatory, so bits 7:0 of OAES are reserved and zero on compliant
controllers. Checking ctrl->oaes & NVME_AEN_CFG_SMART will therefore find
the bit cleared and never subscribe to the event.

In the NVME_FEAT_ASYNC_EVENT feature (CDW11), bits 7:0 are individual
Critical Warning bitmasks corresponding to byte 0 of struct nvme_smart_log,
already defined right above in include/linux/nvme.h as
NVME_SMART_CRIT_SPARE through NVME_SMART_CRIT_VOLATILE_MEMORY (and used by
NVMET_AEN_CFG_ALL in drivers/nvme/target/nvmet.h). Passing 1 << 1 to Set
Features only enables NVME_SMART_CRIT_TEMPERATURE and leaves spare,
reliability, media, and volatile memory warnings disabled.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109120207.1352165-1-kanie@linux.alibaba.com?part=1

Re: [PATCH 1/2] nvme: define the SMART / Health Status async event bit

[Guixin Liu]

在 2026/11/9 20:09, sashiko-bot@kernel.org 写道:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Medium] nvme: NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART use wrong
>   OAES/CFG bit
> --
>
> commit be7079eb32755ede896d21f96ed7d1785a179279
> Author: Guixin Liu <kanie@linux.alibaba.com>
>
> nvme: define the SMART / Health Status async event bit
>
> This commit adds NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART definitions to
> include/linux/nvme.h.
>
>> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
>> index 6248711784b37..2b4f8e269d12d 100644
>> --- a/include/linux/nvme.h
>> +++ b/include/linux/nvme.h
>> @@ -867,6 +867,7 @@ enum {
>>  };
>>  
>>  enum {
>> +	NVME_AEN_BIT_SMART		= 1,
>>  	NVME_AEN_BIT_NS_ATTR		= 8,
>>  	NVME_AEN_BIT_FW_ACT		= 9,
>>  	NVME_AEN_BIT_ANA_CHANGE		= 11,
>> @@ -874,6 +875,7 @@ enum {
>>  };
>>  
>>  enum {
>> +	NVME_AEN_CFG_SMART		= 1 << NVME_AEN_BIT_SMART,
>>  	NVME_AEN_CFG_NS_ATTR		= 1 << NVME_AEN_BIT_NS_ATTR,
>>  	NVME_AEN_CFG_FW_ACT		= 1 << NVME_AEN_BIT_FW_ACT,
>>  	NVME_AEN_CFG_ANA_CHANGE		= 1 << NVME_AEN_BIT_ANA_CHANGE,
> [Severity: Medium]
> Do NVME_AEN_BIT_SMART and NVME_AEN_CFG_SMART match the NVMe specification
> for Identify Controller OAES and NVME_FEAT_ASYNC_EVENT?
>
> The value 1 is the Asynchronous Event Type (NVME_AER_SMART = 1) reported
> in CQE DW0 bits 2:0, not an OAES or Asynchronous Event Configuration bit.
> In the NVMe Base Specification, SMART / Health Critical Warning events are
> mandatory, so bits 7:0 of OAES are reserved and zero on compliant
> controllers. Checking ctrl->oaes & NVME_AEN_CFG_SMART will therefore find
> the bit cleared and never subscribe to the event.
>
> In the NVME_FEAT_ASYNC_EVENT feature (CDW11), bits 7:0 are individual
> Critical Warning bitmasks corresponding to byte 0 of struct nvme_smart_log,
> already defined right above in include/linux/nvme.h as
> NVME_SMART_CRIT_SPARE through NVME_SMART_CRIT_VOLATILE_MEMORY (and used by
> NVMET_AEN_CFG_ALL in drivers/nvme/target/nvmet.h). Passing 1 << 1 to Set
> Features only enables NVME_SMART_CRIT_TEMPERATURE and leaves spare,
> reliability, media, and volatile memory warnings disabled.
Sashiko is right, this is a big mistake, Will fix in v2.

Please ignore this version.
>

[PATCH 2/2] nvme-hwmon: notify hwmon alarms on the SMART / Health Status AEN

[Guixin Liu]

The NVMe hwmon support exposes the temperature alarm as a plain sysfs
attribute, so monitoring tools have to poll temp1_alarm to learn about
a critical temperature or spare-block condition. The device does send
a SMART / Health Status asynchronous event when its health status
changes, but the host never subscribes to it, and the completion path
silently drops the event.

Subscribe to the SMART / Health Status event, and when it arrives,
wake up pollers on temp1_alarm. The alarm read fetches the SMART log
on demand, so no log refresh is needed in the completion path; the
notify is deferred to a work item because nvme-pci completes
asynchronous events from interrupt context, where sysfs_notify()
cannot sleep.

Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
---
 drivers/nvme/host/core.c  |  8 ++++++--
 drivers/nvme/host/hwmon.c | 30 ++++++++++++++++++++++++++++++
 drivers/nvme/host/nvme.h  |  5 +++++
 3 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index cd0df9b038063..47dc9eb3ae595 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1784,7 +1784,7 @@ int nvme_set_queue_count(struct nvme_ctrl *ctrl, int *count)
 EXPORT_SYMBOL_GPL(nvme_set_queue_count);
 
 #define NVME_AEN_SUPPORTED \
-	(NVME_AEN_CFG_NS_ATTR | NVME_AEN_CFG_FW_ACT | \
+	(NVME_AEN_CFG_SMART | NVME_AEN_CFG_NS_ATTR | NVME_AEN_CFG_FW_ACT | \
 	 NVME_AEN_CFG_ANA_CHANGE | NVME_AEN_CFG_DISC_CHANGE)
 
 static void nvme_enable_aen(struct nvme_ctrl *ctrl)
@@ -5009,8 +5009,12 @@ void nvme_complete_async_event(struct nvme_ctrl *ctrl, __le16 status,
 			nvme_handle_aer_persistent_error(ctrl);
 			return;
 		}
-		fallthrough;
+		ctrl->aen_result = result;
+		break;
 	case NVME_AER_SMART:
+		nvme_hwmon_smart_event(ctrl);
+		ctrl->aen_result = result;
+		break;
 	case NVME_AER_CSS:
 	case NVME_AER_VS:
 		ctrl->aen_result = result;
diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c
index 406203d8b9adb..564d5cae8001b 100644
--- a/drivers/nvme/host/hwmon.c
+++ b/drivers/nvme/host/hwmon.c
@@ -5,6 +5,7 @@
  */
 
 #include <linux/hwmon.h>
+#include <linux/sysfs.h>
 #include <linux/units.h>
 #include <linux/unaligned.h>
 
@@ -14,6 +15,7 @@ struct nvme_hwmon_data {
 	struct nvme_ctrl *ctrl;
 	struct nvme_smart_log *log;
 	struct mutex read_lock;
+	struct work_struct smart_work;
 };
 
 static int nvme_get_temp_thresh(struct nvme_ctrl *ctrl, int sensor, bool under,
@@ -223,6 +225,32 @@ static const struct hwmon_chip_info nvme_hwmon_chip_info = {
 	.info	= nvme_hwmon_info,
 };
 
+/*
+ * Called from the admin completion path on a SMART / Health Status AEN.
+ * The completion context can be a hardirq, so only queue the work here;
+ * the notify itself is done in process context.  No log refresh is
+ * needed: userspace re-reads temp1_alarm, which fetches the SMART log
+ * on demand.
+ */
+void nvme_hwmon_smart_event(struct nvme_ctrl *ctrl)
+{
+	struct nvme_hwmon_data *data;
+
+	if (!ctrl->hwmon_device)
+		return;
+
+	data = dev_get_drvdata(ctrl->hwmon_device);
+	queue_work(nvme_wq, &data->smart_work);
+}
+
+static void nvme_hwmon_smart_notify(struct work_struct *work)
+{
+	struct nvme_hwmon_data *data =
+		container_of(work, struct nvme_hwmon_data, smart_work);
+
+	sysfs_notify(&data->ctrl->hwmon_device->kobj, NULL, "temp1_alarm");
+}
+
 int nvme_hwmon_init(struct nvme_ctrl *ctrl)
 {
 	struct device *dev = ctrl->device;
@@ -242,6 +270,7 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl)
 
 	data->ctrl = ctrl;
 	mutex_init(&data->read_lock);
+	INIT_WORK(&data->smart_work, nvme_hwmon_smart_notify);
 
 	err = nvme_hwmon_get_smart_log(data);
 	if (err) {
@@ -273,6 +302,7 @@ void nvme_hwmon_exit(struct nvme_ctrl *ctrl)
 		struct nvme_hwmon_data *data =
 			dev_get_drvdata(ctrl->hwmon_device);
 
+		cancel_work_sync(&data->smart_work);
 		hwmon_device_unregister(ctrl->hwmon_device);
 		ctrl->hwmon_device = NULL;
 		kfree(data->log);
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 2543e52d6358a..df8a94c907655 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -1276,6 +1276,7 @@ static inline struct nvme_ns *nvme_get_ns_from_dev(struct device *dev)
 #ifdef CONFIG_NVME_HWMON
 int nvme_hwmon_init(struct nvme_ctrl *ctrl);
 void nvme_hwmon_exit(struct nvme_ctrl *ctrl);
+void nvme_hwmon_smart_event(struct nvme_ctrl *ctrl);
 #else
 static inline int nvme_hwmon_init(struct nvme_ctrl *ctrl)
 {
@@ -1285,6 +1286,10 @@ static inline int nvme_hwmon_init(struct nvme_ctrl *ctrl)
 static inline void nvme_hwmon_exit(struct nvme_ctrl *ctrl)
 {
 }
+
+static inline void nvme_hwmon_smart_event(struct nvme_ctrl *ctrl)
+{
+}
 #endif
 
 static inline void nvme_start_request(struct request *rq)
-- 
2.43.7

Re: [PATCH 2/2] nvme-hwmon: notify hwmon alarms on the SMART / Health Status AEN

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] nvme: nvme_enable_aen() masks NVME_AEN_CFG_SMART with
  ctrl->oaes
- [High] nvme: nvme_complete_async_event() requeues AER without clearing
  SMART log
- [Medium] nvme-hwmon: nvme_hwmon_smart_notify() bypasses
  hwmon_notify_event()
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Critical] nvme: use-after-free in nvme_handle_aen_notice() [1]
--

commit 33552d2b2131791945c267787b8393f1a3c9f467
Author: Guixin Liu <kanie@linux.alibaba.com>

nvme-hwmon: notify hwmon alarms on the SMART / Health Status AEN

This commit subscribes to the NVMe SMART / Health Status asynchronous
event and schedules a work item on completion to notify sysfs pollers on
temp1_alarm.

> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index a7a4d09644c13..ef488d3ac081f 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1784,7 +1784,7 @@ int nvme_set_queue_count(struct nvme_ctrl *ctrl, int *count)
>  EXPORT_SYMBOL_GPL(nvme_set_queue_count);
>  
>  #define NVME_AEN_SUPPORTED \
> -	(NVME_AEN_CFG_NS_ATTR | NVME_AEN_CFG_FW_ACT | \
> +	(NVME_AEN_CFG_SMART | NVME_AEN_CFG_NS_ATTR | NVME_AEN_CFG_FW_ACT | \
>  	 NVME_AEN_CFG_ANA_CHANGE | NVME_AEN_CFG_DISC_CHANGE)
>  
>  static void nvme_enable_aen(struct nvme_ctrl *ctrl)

[Severity: High]
Does adding NVME_AEN_CFG_SMART to NVME_AEN_SUPPORTED actually enable SMART
asynchronous events in nvme_enable_aen()?

nvme_enable_aen() masks NVME_AEN_SUPPORTED against ctrl->oaes:

drivers/nvme/host/core.c:nvme_enable_aen() {
	u32 result, supported_aens = ctrl->oaes & NVME_AEN_SUPPORTED;
	int status;

	if (!supported_aens)
		return;
    ...
}

ctrl->oaes comes from the Identify Controller OAES field, where bits 7:0
are reserved and zero on compliant controllers (see NVMET_AEN_CFG_OPTIONAL
vs NVMET_AEN_CFG_ALL in drivers/nvme/target/nvmet.h).  In Set Features for
NVME_FEAT_ASYNC_EVENT, bits 7:0 are the mandatory SMART warning bitmask
(NVME_SMART_CRIT_SPARE, NVME_SMART_CRIT_TEMPERATURE, etc.), so masking
with ctrl->oaes clears NVME_AEN_CFG_SMART and never enables the event.

> @@ -4993,8 +4993,12 @@ void nvme_complete_async_event(struct nvme_ctrl *ctrl, __le16 status,
>  			nvme_handle_aer_persistent_error(ctrl);
>  			return;
>  		}
> -		fallthrough;
> +		ctrl->aen_result = result;
> +		break;
>  	case NVME_AER_SMART:
> +		nvme_hwmon_smart_event(ctrl);
> +		ctrl->aen_result = result;
> +		break;
>  	case NVME_AER_CSS:
>  	case NVME_AER_VS:
>  		ctrl->aen_result = result;

[Severity: High]
Does completing NVME_AER_SMART with requeue = true re-arm the Asynchronous
Event Request before the SMART / Health Information log page is read?

Per the NVMe specification, an asynchronous event remains latched on the
controller until host software reads the corresponding log page
(NVME_LOG_SMART) with RAE cleared.  Other AEN handlers such as
nvme_fw_act_work() read their log page before queueing
ctrl->async_event_work, whereas here ctrl->async_event_work resubmits the
AER immediately while nvme_hwmon_smart_notify() only calls sysfs_notify().
Before userspace wakes up and reads temp1_alarm (or if nothing polls
temp1_alarm, or CONFIG_NVME_HWMON is disabled), the new AER completes
immediately with the same uncleared event in a tight loop.

[Severity: Critical]
This problem wasn't introduced by this patch, but can a late
NVME_AER_NOTICE_ANA completion in nvme_complete_async_event() cause a
use-after-free [1] on ctrl during controller teardown?

CPU0                              CPU1
nvme_remove_ctrl()
  ...
  nvme_stop_ctrl()
    nvme_mpath_stop()
      cancel_work_sync(&ctrl->ana_work)
                                  nvme_complete_async_event()
                                    nvme_handle_aen_notice()
                                      queue_work(nvme_wq, &ctrl->ana_work)
  nvme_uninit_ctrl()
  nvme_put_ctrl() -> kfree(ctrl)
                                  nvme_ana_work()
                                    /* dereferences freed ctrl */
                                    <-- use-after-free

nvme_handle_aen_notice() checks ctrl->ana_log_buf but does not verify that
the controller is still live before queueing ctrl->ana_work, allowing the
work item to run after the controller has been freed.

> diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c
> index 406203d8b9adb..564d5cae8001b 100644
> --- a/drivers/nvme/host/hwmon.c
> +++ b/drivers/nvme/host/hwmon.c

[ ... ]

> @@ -223,6 +225,32 @@ static const struct hwmon_chip_info nvme_hwmon_chip_info = {
>  	.info	= nvme_hwmon_info,
>  };
>  
> +/*
> + * Called from the admin completion path on a SMART / Health Status AEN.
> + * The completion context can be a hardirq, so only queue the work here;
> + * the notify itself is done in process context.  No log refresh is
> + * needed: userspace re-reads temp1_alarm, which fetches the SMART log
> + * on demand.
> + */
> +void nvme_hwmon_smart_event(struct nvme_ctrl *ctrl)
> +{
> +	struct nvme_hwmon_data *data;
> +
> +	if (!ctrl->hwmon_device)
> +		return;
> +
> +	data = dev_get_drvdata(ctrl->hwmon_device);
> +	queue_work(nvme_wq, &data->smart_work);
> +}
> +
> +static void nvme_hwmon_smart_notify(struct work_struct *work)
> +{
> +	struct nvme_hwmon_data *data =
> +		container_of(work, struct nvme_hwmon_data, smart_work);
> +
> +	sysfs_notify(&data->ctrl->hwmon_device->kobj, NULL, "temp1_alarm");
> +}

[Severity: Medium]
Should nvme_hwmon_smart_notify() call hwmon_notify_event() instead of
calling sysfs_notify() directly?

hwmon_notify_event(data->ctrl->hwmon_device, hwmon_temp, hwmon_temp_alarm,
0) notifies the sysfs attribute, emits the standard hwmon KOBJ_CHANGE
uevent, and calls hwmon_thermal_notify() to update the thermal zone
registered via HWMON_C_REGISTER_TZ.  Also, the commit message notes that
polling temp1_alarm reports spare-block conditions, but nvme_hwmon_read()
only checks NVME_SMART_CRIT_TEMPERATURE for temp1_alarm and never checks
NVME_SMART_CRIT_SPARE.

[1] https://sashiko.dev/#/bug/linux-216101c0-b2a4-4615-97e0-5cfa127dc568

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109120207.1352165-1-kanie@linux.alibaba.com?part=2