Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters

From: Kees Cook <keescook@chromium.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: rafael@kernel.org, linux-kselftest@vger.kernel.org,
	joel@joelfernandes.org, rric@kernel.org, shuah@kernel.org,
	devel@driverdev.osuosl.org, minyard@acm.org, corbet@lwn.net,
	surenb@google.com, linux-doc@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, tkjos@android.com,
	arnd@arndb.de, bp@alien8.de,
	openipmi-developer@lists.sourceforge.net, mchehab@kernel.org,
	maco@android.com, christian@brauner.io,
	linux-edac@vger.kernel.org, tony.luck@intel.com,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	arve@android.com, james.morse@arm.com, hridya@google.com,
	johannes@sipsolutions.net
Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
Date: Sat, 26 Sep 2020 09:33:17 -0700	[thread overview]
Message-ID: <202009260930.9252966D@keescook> (raw)
In-Reply-To: <7d8f86ab-4333-afa1-6523-e42ae5c7d9b2@linuxfoundation.org>

On Fri, Sep 25, 2020 at 06:13:37PM -0600, Shuah Khan wrote:
> On 9/25/20 5:52 PM, Kees Cook wrote:
> > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote:
> > > -- Addressed Kees's comments:
> > >     1. Non-atomic counters renamed to counter_simple32 and counter_simple64
> > >        to clearly indicate size.
> > >     2. Added warning for counter_simple* usage and it should be used only
> > >        when there is no need for atomicity.
> > >     3. Renamed counter_atomic to counter_atomic32 to clearly indicate size.
> > >     4. Renamed counter_atomic_long to counter_atomic64 and it now uses
> > >        atomic64_t ops and indicates size.
> > >     5. Test updated for the API renames.
> > >     6. Added helper functions for test results printing
> > >     7. Verified that the test module compiles in kunit env. and test
> > >        module can be loaded to run the test.
> > 
> > Thanks for all of this!
> > 
> > >     8. Updated Documentation to reflect the intent to make the API
> > >        restricted so it can never be used to guard object lifetimes
> > >        and state management. I left _return ops for now, inc_return
> > >        is necessary for now as per the discussion we had on this topic.
> > 
> > I still *really* do not want dec_return() to exist. That is asking for
> > trouble. I'd prefer inc_return() not exist either, but I can live with
> > it. ;)
> > 
> 
> Thanks. I am equally concerned about adding anything that can be used to
> guard object lifetimes. So I will make sure this set won't expand and
> plan to remove dec_return() if we don't find any usages.

I would like it much stronger than "if". dec_return() needs to be just
dec() and read(). It will not be less efficient (since they're both
inlines), but it _will_ create a case where the atomicity cannot be used
for ref counting. My point is that anything that _requires_ dec_return()
(or, frankly, inc_return()) is _not_ "just" a statistical counter. It
may not be a refcounter, but it relies on the inc/dec atomicity for some
reason beyond counting in once place and reporting it in another.

-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel