All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: corbet@lwn.net, keescook@chromium.org,
	gregkh@linuxfoundation.org, peterz@infradead.org,
	rafael@kernel.org, lenb@kernel.org, james.morse@arm.com,
	tony.luck@intel.com, bp@alien8.de, minyard@acm.org,
	arnd@arndb.de, mchehab@kernel.org, rric@kernel.org,
	valentina.manea.m@gmail.com, shuah@kernel.org,
	zohar@linux.ibm.com, dmitry.kasatkin@gmail.com,
	jmorris@namei.org, serge@hallyn.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-acpi@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	linux-edac@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH 00/13] Introduce seqnum_ops
Date: Tue, 10 Nov 2020 15:42:11 -0700	[thread overview]
Message-ID: <c58fde16-4bd1-0e1e-94ce-a15c359f9f91@linuxfoundation.org> (raw)
In-Reply-To: <20201110204414.GA204624@rowland.harvard.edu>

On 11/10/20 1:44 PM, Alan Stern wrote:
> On Tue, Nov 10, 2020 at 12:53:26PM -0700, Shuah Khan wrote:
>> There are a number of atomic_t usages in the kernel where atomic_t api
>> is used strictly for counting sequence numbers and other statistical
>> counters and not for managing object lifetime.
>>
>> The purpose of these Sequence Number Ops is to clearly differentiate
>> atomic_t counter usages from atomic_t usages that guard object lifetimes,
>> hence prone to overflow and underflow errors.
>>
>> The atomic_t api provides a wide range of atomic operations as a base
>> api to implement atomic counters, bitops, spinlock interfaces. The usages
>> also evolved into being used for resource lifetimes and state management.
>> The refcount_t api was introduced to address resource lifetime problems
>> related to atomic_t wrapping. There is a large overlap between the
>> atomic_t api used for resource lifetimes and just counters, stats, and
>> sequence numbers. It has become difficult to differentiate between the
>> atomic_t usages that should be converted to refcount_t and the ones that
>> can be left alone. Introducing seqnum_ops to wrap the usages that are
>> stats, counters, sequence numbers makes it easier for tools that scan
>> for underflow and overflow on atomic_t usages to detect overflow and
>> underflows to scan just the cases that are prone to errors.
>>
>> Sequence Number api provides interfaces for simple atomic_t counter usages
>> that just count, and don't guard resource lifetimes. The seqnum_ops are
>> built on top of atomic_t api, providing a smaller subset of atomic_t
>> interfaces necessary to support atomic_t usages as simple counters.
>> This api has init/set/inc/dec/read and doesn't support any other atomic_t
>> ops with the intent to restrict the use of these interfaces as simple
>> counting usages.
>>
>> Sequence Numbers 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. Overflowing to INT_MIN is consistent
>> with the atomic_t api, which it is built on top of.
> 
> If Sequence Numbers are subject to wraparound then they aren't reliable.
> Given that they aren't reliable, why use atomic instructions at all?
> Why not just use plain regular integers with READ_ONCE and WRITE_ONCE?
> 

You still need atomic update for these numbers. The intent is to provide
atomic api for cases where the variable doesn't guard lifetimes and yet
needs atomic instructions.

Several such usages where atomic_t is used for up counting, also use
upper bounds. It is also an option to switch to seqnum64 to avoid
wrap around in case there is a concern.

thanks,
-- Shuah



  reply	other threads:[~2020-11-10 22:42 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 19:53 [PATCH 00/13] Introduce seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 01/13] seqnum_ops: Introduce Sequence Number Ops Shuah Khan
2020-11-10 20:41   ` Greg KH
2020-11-10 20:43     ` Greg KH
2020-11-11  0:18       ` Kees Cook
2020-11-11 19:23         ` Shuah Khan
2020-11-12 12:36           ` Matthew Wilcox
2020-11-12 16:17             ` Shuah Khan
2020-11-12 16:45               ` Greg KH
2020-11-12 16:59                 ` Shuah Khan
2020-11-12 21:27           ` Shuah Khan
2020-11-17 12:27             ` Peter Zijlstra
2020-11-10 21:03   ` Matthew Wilcox
2020-11-10 22:58     ` Shuah Khan
2020-11-11  0:20       ` Kees Cook
2020-11-11 15:42         ` Shuah Khan
2020-11-11  8:23   ` Peter Zijlstra
2020-11-11 15:56     ` Shuah Khan
2020-11-11 16:04       ` Peter Zijlstra
2020-11-11 17:34         ` Shuah Khan
2020-11-11 17:50           ` Peter Zijlstra
2020-11-11 18:28             ` Shuah Khan
2020-11-11 20:15               ` Peter Zijlstra
2020-11-12 13:29                 ` Greg KH
2020-11-10 19:53 ` [PATCH 02/13] selftests:lib:test_seqnum_ops: add new test for seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 03/13] drivers/acpi: convert seqno seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 04/13] drivers/acpi/apei: convert seqno to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 05/13] drivers/base/test/test_async_driver_probe: convert to use seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 06/13] drivers/char/ipmi: convert stats " Shuah Khan
2020-11-10 19:53 ` [PATCH 07/13] drivers/edac: convert pci counters to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 08/13] drivers/oprofile: convert stats to use seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 09/13] drivers/staging/rtl8723bs: " Shuah Khan
2020-11-10 19:53   ` Shuah Khan
2020-11-10 19:53 ` [PATCH 10/13] usb: usbip/vhci: convert seqno to seqnum_ops Shuah Khan
2020-11-10 19:53 ` [PATCH 11/13] drivers/staging/rtl8188eu: convert stats to use seqnum_ops Shuah Khan
2020-11-10 19:53   ` Shuah Khan
2020-11-10 19:53 ` [PATCH 12/13] drivers/staging/unisys/visorhba: " Shuah Khan
2020-11-10 19:53   ` Shuah Khan
2020-11-10 20:42   ` Greg KH
2020-11-10 20:42     ` Greg KH
2020-11-10 21:02     ` Shuah Khan
2020-11-10 21:02       ` Shuah Khan
2020-11-10 19:53 ` [PATCH 13/13] security/integrity/ima: converts stats to seqnum_ops Shuah Khan
2020-11-11  8:51   ` kernel test robot
2020-11-11  8:51     ` kernel test robot
2020-11-10 20:44 ` [PATCH 00/13] Introduce seqnum_ops Alan Stern
2020-11-10 22:42   ` Shuah Khan [this message]
2020-11-11  4:33 ` Matthew Wilcox
2020-11-11 16:03   ` Shuah Khan
2020-11-11 16:41     ` Matthew Wilcox

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=c58fde16-4bd1-0e1e-94ce-a15c359f9f91@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=minyard@acm.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rric@kernel.org \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tony.luck@intel.com \
    --cc=valentina.manea.m@gmail.com \
    --cc=zohar@linux.ibm.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.