From: Sanman Pradhan <psanman@juniper.net>

This series addresses three bugs in the OCC hwmon driver
(drivers/hwmon/occ/):

Patch 1 fixes a possible division by zero in occ_show_power_1()
when update_tag is zero. The power_sensor_1 code path divides the
accumulator by update_tag without checking for zero.
Commit 211186cae14d ("hwmon: (occ) Fix division by zero issue")
addressed this for occ_get_powr_avg() used by power_sensor_2
and power_sensor_a0, but the separate code path in occ_show_power_1()
was not covered. The fix reuses the existing occ_get_powr_avg()
helper which already handles the zero-sample case.

Patch 2 adds a missing trailing newline in occ_show_extended() for
the EXTN_FLAG_SENSOR_ID case.

Patch 3 reorders operations in p9_sbe_occ_remove() so that
occ_shutdown() is called before setting ctx->sbe to NULL. The
current order creates a window where a concurrent sysfs read
could see a NULL sbe pointer before the hwmon device is
unregistered.

Sanman Pradhan (3):
  hwmon: (occ) Fix division by zero in occ_show_power_1()
  hwmon: (occ) Fix missing newline in occ_show_extended()
  hwmon: (occ) Fix potential NULL dereference in p9_sbe_occ_remove()

 drivers/hwmon/occ/common.c | 20 ++++++++++----------
 drivers/hwmon/occ/p9_sbe.c |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.34.1

Hi,

On 3/26/26 15:45, Pradhan, Sanman wrote:
> From: Sanman Pradhan <psanman@juniper.net>
> 
> This series addresses three bugs in the OCC hwmon driver
> (drivers/hwmon/occ/):
> 
> Patch 1 fixes a possible division by zero in occ_show_power_1()
> when update_tag is zero. The power_sensor_1 code path divides the
> accumulator by update_tag without checking for zero.
> Commit 211186cae14d ("hwmon: (occ) Fix division by zero issue")
> addressed this for occ_get_powr_avg() used by power_sensor_2
> and power_sensor_a0, but the separate code path in occ_show_power_1()
> was not covered. The fix reuses the existing occ_get_powr_avg()
> helper which already handles the zero-sample case.
> 
> Patch 2 adds a missing trailing newline in occ_show_extended() for
> the EXTN_FLAG_SENSOR_ID case.
> 
> Patch 3 reorders operations in p9_sbe_occ_remove() so that
> occ_shutdown() is called before setting ctx->sbe to NULL. The
> current order creates a window where a concurrent sysfs read
> could see a NULL sbe pointer before the hwmon device is
> unregistered.
> 
> Sanman Pradhan (3):
>    hwmon: (occ) Fix division by zero in occ_show_power_1()
>    hwmon: (occ) Fix missing newline in occ_show_extended()
>    hwmon: (occ) Fix potential NULL dereference in p9_sbe_occ_remove()
> 
>   drivers/hwmon/occ/common.c | 20 ++++++++++----------
>   drivers/hwmon/occ/p9_sbe.c |  2 +-
>   2 files changed, 11 insertions(+), 11 deletions(-)
> 

Please check

https://sashiko.dev/#/patchset/20260326224510.294619-1-sanman.pradhan%40hpe.com


and either address the problems or explain why they do not apply.

Thanks,
Guenter

From: Sanman Pradhan <psanman@juniper.net>

Thanks, for the review.

The AI feedback seems valid on both counts, but both issues appear to be
pre-existing OCC driver problems rather than something introduced by my
patch.

occ_shutdown() already holds occ->lock across
occ_shutdown_sysfs() and hwmon_device_unregister(), while OCC sysfs
callbacks can enter occ_active() / occ_update_response() and take
the same lock, so the deadlock concern looks real independent of my
reorder in p9_sbe_occ_remove().

Also, the occ_active toggle path appears to have a lifetime problem:
activation allocates occ->attrs and occ->group.attrs with
devm_kcalloc(), while deactivation unregisters the hwmon device but
does not release or reuse those allocations.

Given that, I'll drop patch 3 for now and resend patches 1 and 2
separately, then investigate the OCC teardown/activation issues.

Thank you.

Regards,
Sanman Pradhan

On 3/30/26 09:01, Pradhan, Sanman wrote:
> From: Sanman Pradhan <psanman@juniper.net>
> 
> Thanks, for the review.
> 
> The AI feedback seems valid on both counts, but both issues appear to be
> pre-existing OCC driver problems rather than something introduced by my
> patch.
> 
> occ_shutdown() already holds occ->lock across
> occ_shutdown_sysfs() and hwmon_device_unregister(), while OCC sysfs
> callbacks can enter occ_active() / occ_update_response() and take
> the same lock, so the deadlock concern looks real independent of my
> reorder in p9_sbe_occ_remove().
> 
> Also, the occ_active toggle path appears to have a lifetime problem:
> activation allocates occ->attrs and occ->group.attrs with
> devm_kcalloc(), while deactivation unregisters the hwmon device but
> does not release or reuse those allocations.
> 
> Given that, I'll drop patch 3 for now and resend patches 1 and 2
> separately, then investigate the OCC teardown/activation issues.
> 

Do you plan to make any changes to patch 1 and 2 ? Because if not there
would be no need to resend, and I can just apply them directly.

Thanks,
Guenter

From: Sanman Pradhan <psanman@juniper.net>

No, I don't.

Please go ahead and apply 1 and 2. Thanks

Thank you.

Regards,
Sanman Pradhan

From: Sanman Pradhan <psanman@juniper.net>

ApPlease ignore the previous message about the cover letter.

Thank you.

Regards,
Sanman Pradhan

From: Sanman Pradhan <psanman@juniper.net>

Apologies, the cover letter from this series did not reach the mailing list.
The three patches themselves went through fine.

I can resend the full series as v2 again with the cover letter,
or just note this for context.

Thank you.

Regards,
Sanman Pradhan