From: Shuah Khan <skhan@linuxfoundation.org>
To: Trond Myklebust <trondmy@hammerspace.com>,
"Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>
Cc: "bfields@fieldses.org" <bfields@fieldses.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"chuck.lever@oracle.com" <chuck.lever@oracle.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: rpc_xprt_debugfs_register() - atomic_inc_return() usage
Date: Thu, 21 Jan 2021 11:01:09 -0700 [thread overview]
Message-ID: <5952caee-edb4-e9ec-6621-fb50cfe3384f@linuxfoundation.org> (raw)
In-Reply-To: <020aee05c808b3725db5679967406a918840f86f.camel@hammerspace.com>
On 1/21/21 10:56 AM, Trond Myklebust wrote:
> On Wed, 2021-01-20 at 16:52 -0700, Shuah Khan wrote:
>> Hi Anna and Trond,
>>
>> I came across the following while reviewing atomic_inc_return()
>> usages
>> that cast return value to unsigned
>>
>> rpc_xprt_debugfs_register()'s atomic_inc_return() usage looks a bit
>> odd.
>>
>> - cur_id isn't initialized
>> - id = (unsigned int)atomic_inc_return(&cur_id);
>>
>> Please note that id is int. Is it expected that cur_id could
>> overflow?
>> Is there a maximum limit for this value?
>>
>
> Yes, we do expect cur_id to eventually overflow (once you have created
> 2 billion RPC client instances), however the atomic increment
> operations are expected to handle this correctly according to the
> maintainers (I already asked them in a different context). Furthermore,
> the code itself doesn't care about strict sequentiality. All it wants
> from the counter is uniqueness, with that uniqueness condition actually
> being enforced by the subsequent debugfs_create_file() call.
>
> IOW: I don't think this is a real problem.
>
Great. Thank you for a detailed explanation.
-- Shuah
prev parent reply other threads:[~2021-01-21 18:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 23:52 rpc_xprt_debugfs_register() - atomic_inc_return() usage Shuah Khan
2021-01-21 17:56 ` Trond Myklebust
2021-01-21 18:01 ` Shuah Khan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5952caee-edb4-e9ec-6621-fb50cfe3384f@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=Anna.Schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=trondmy@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.