| Message ID | 9e2c6cccabc96fe1e5304e2fa2dfdad28ca5ac9c.1600816121.git.skhan@linuxfoundation.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
On Wed, Sep 23, 2020 at 3:44 AM Shuah Khan <skhan@linuxfoundation.org> wrote: > > counter_atomic is introduced to be used when a variable is used as > a simple counter and doesn't guard object lifetimes. This clearly > differentiates atomic_t usages that guard object lifetimes. > > counter_atomic variables will wrap around to 0 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. > > Convert it to use counter_atomic. > > This conversion doesn't change the oveflow wrap around behavior. > > Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Both this change and the next patch are fine by me. Thanks! > --- > drivers/acpi/acpi_extlog.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c > index f138e12b7b82..23b696b7eb14 100644 > --- a/drivers/acpi/acpi_extlog.c > +++ b/drivers/acpi/acpi_extlog.c > @@ -12,6 +12,7 @@ > #include <linux/ratelimit.h> > #include <linux/edac.h> > #include <linux/ras.h> > +#include <linux/counters.h> > #include <asm/cpu.h> > #include <asm/mce.h> > > @@ -93,7 +94,7 @@ static struct acpi_hest_generic_status *extlog_elog_entry_check(int cpu, int ban > static void __print_extlog_rcd(const char *pfx, > struct acpi_hest_generic_status *estatus, int cpu) > { > - static atomic_t seqno; > + static struct counter_atomic seqno; > unsigned int curr_seqno; > char pfx_seq[64]; > > @@ -103,7 +104,7 @@ static void __print_extlog_rcd(const char *pfx, > else > pfx = KERN_ERR; > } > - curr_seqno = atomic_inc_return(&seqno); > + curr_seqno = counter_atomic_inc_return(&seqno); > snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}", pfx, curr_seqno); > printk("%s""Hardware error detected on CPU%d\n", pfx_seq, cpu); > cper_estatus_print(pfx_seq, estatus); > -- > 2.25.1 >
On 9/24/20 5:13 AM, Rafael J. Wysocki wrote: > On Wed, Sep 23, 2020 at 3:44 AM Shuah Khan <skhan@linuxfoundation.org> wrote: >> >> counter_atomic is introduced to be used when a variable is used as >> a simple counter and doesn't guard object lifetimes. This clearly >> differentiates atomic_t usages that guard object lifetimes. >> >> counter_atomic variables will wrap around to 0 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. >> >> Convert it to use counter_atomic. >> >> This conversion doesn't change the oveflow wrap around behavior. I see typo here. Will fix it. >> >> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> > > Both this change and the next patch are fine by me. > Thanks Rafael. Okay to add your Acked-by? thanks, -- Shuah
On Thu, Sep 24, 2020 at 5:08 PM Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 9/24/20 5:13 AM, Rafael J. Wysocki wrote: > > On Wed, Sep 23, 2020 at 3:44 AM Shuah Khan <skhan@linuxfoundation.org> wrote: > >> > >> counter_atomic is introduced to be used when a variable is used as > >> a simple counter and doesn't guard object lifetimes. This clearly > >> differentiates atomic_t usages that guard object lifetimes. > >> > >> counter_atomic variables will wrap around to 0 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. > >> > >> Convert it to use counter_atomic. > >> > >> This conversion doesn't change the oveflow wrap around behavior. > > I see typo here. Will fix it. > > >> > >> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> > > > > Both this change and the next patch are fine by me. > > > > Thanks Rafael. Okay to add your Acked-by? Sure. Thanks!
diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c index f138e12b7b82..23b696b7eb14 100644 --- a/drivers/acpi/acpi_extlog.c +++ b/drivers/acpi/acpi_extlog.c @@ -12,6 +12,7 @@ #include <linux/ratelimit.h> #include <linux/edac.h> #include <linux/ras.h> +#include <linux/counters.h> #include <asm/cpu.h> #include <asm/mce.h> @@ -93,7 +94,7 @@ static struct acpi_hest_generic_status *extlog_elog_entry_check(int cpu, int ban static void __print_extlog_rcd(const char *pfx, struct acpi_hest_generic_status *estatus, int cpu) { - static atomic_t seqno; + static struct counter_atomic seqno; unsigned int curr_seqno; char pfx_seq[64]; @@ -103,7 +104,7 @@ static void __print_extlog_rcd(const char *pfx, else pfx = KERN_ERR; } - curr_seqno = atomic_inc_return(&seqno); + curr_seqno = counter_atomic_inc_return(&seqno); snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}", pfx, curr_seqno); printk("%s""Hardware error detected on CPU%d\n", pfx_seq, cpu); cper_estatus_print(pfx_seq, estatus);
counter_atomic is introduced to be used when a variable is used as a simple counter and doesn't guard object lifetimes. This clearly differentiates atomic_t usages that guard object lifetimes. counter_atomic variables will wrap around to 0 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. Convert it to use counter_atomic. This conversion doesn't change the oveflow wrap around behavior. Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> --- drivers/acpi/acpi_extlog.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)