[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2fe15f90-2e33-d018-0d5d-cabe3846ed98@linuxfoundation.org>
Date: Fri, 5 Feb 2021 13:03:18 -0700
From: Shuah Khan <skhan@...uxfoundation.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: corbet@....net, peterz@...radead.org, keescook@...omium.org,
rafael@...nel.org, lenb@...nel.org, james.morse@....com,
tony.luck@...el.com, bp@...en8.de, devel@...verdev.osuosl.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v3 1/7] seqnum_ops: Introduce Sequence Number Ops
On 2/5/21 2:58 AM, Greg KH wrote:
> On Wed, Feb 03, 2021 at 11:11:57AM -0700, Shuah Khan wrote:
>> +static inline u32 seqnum32_inc(struct seqnum32 *seq)
>> +{
>> + atomic_t val = ATOMIC_INIT(seq->seqnum);
>> +
>> + seq->seqnum = (u32) atomic_inc_return(&val);
>> + if (seq->seqnum >= UINT_MAX)
>> + pr_info("Sequence Number overflow %u detected\n",
>> + seq->seqnum);
>> + return seq->seqnum;
>
> As Peter points out, this is doing doing what you think it is doing :(
>
> Why do you not just have seq->seqnum be a real atomic variable? Trying
> to switch to/from one like this does not work as there is no
> "atomic-ness" happening here at all.
>
Yes. This is sloppy on my part. As Peter and Rafael also pointed. I have
to start paying more attention to my inner voice.
thanks,
-- Shuah
Powered by blists - more mailing lists