@@ -41,6 +41,7 @@
#include <linux/uuid.h>
#include <linux/ras.h>
#include <linux/task_work.h>
+#include <linux/seqnum_ops.h>
#include <acpi/actbl1.h>
#include <acpi/ghes.h>
@@ -625,7 +626,7 @@ static void __ghes_print_estatus(const char *pfx,
const struct acpi_hest_generic *generic,
const struct acpi_hest_generic_status *estatus)
{
- static atomic_t seqno;
+ static struct seqnum32 seqno = SEQNUM_INIT(0);
unsigned int curr_seqno;
char pfx_seq[64];
@@ -636,7 +637,8 @@ static void __ghes_print_estatus(const char *pfx,
else
pfx = KERN_ERR;
}
- curr_seqno = atomic_inc_return(&seqno);
+ seqnum32_inc(&seqno);
+ curr_seqno = seqnum32_read(&seqno);
snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}" HW_ERR, pfx, curr_seqno);
printk("%s""Hardware error from APEI Generic Hardware Error Source: %d\n",
pfx_seq, generic->header.source_id);
seqnum_ops api is introduced to be used when a variable is used as a sequence/stat counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. seqnum32 variables wrap around to INT_MIN when it overflows and should not be used to guard resource lifetimes, device usage and open counts that control state changes, and pm states. seqno is a sequence number counter for logging. This counter gets incremented. Unsure if there is a chance of this overflowing. It doesn't look like overflowing causes any problems since it is used to tag the log messages and nothing more. This conversion doesn't change the overflow wrap around behavior. Convert it to use seqnum_ops. This conversion replaces inc_return() with _inc() followed by _read(). Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> --- drivers/acpi/apei/ghes.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)