archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Hillf Danton <>
Cc: "Eric W. Biederman" <>,
	Linux Kernel Mailing List <>,
	Alexey Gladkov <>
Subject: Re: [GIT PULL] ucount fix for v5.14-rc
Date: Sat, 7 Aug 2021 01:23:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Aug 6, 2021 at 10:03 PM Hillf Danton <> wrote:
> Then the current atomic_add_negative() in consideration over the "risk"
> of count overflow in real workloads can be replaced with the not_zero
> version.

What? No.

The atomic_add_negative() has absolutely nothing to do with not_zero.

The "negative" comes not at all from the count ever being zero, and as
I explained, that isn't even an issue here.

The "negative" is from a large _positive_ count growing so much that
the sign bit gets set. It's basically a "31-bit overflow" thing.


 - not_zero makes no sense for get_ucounts(), because it can't be
zero, because we hold a reference to it

 - atomic_add_negative() is about not letting the counts become too
large, and when they do, we undo the reference (ie the pattern is
"increment ref - but if it then overflows into bit #31, decrement it

and the two have *NOTHING* to do with each other. So your statement
about replacing one with the other makes no sense.

I was trying to explain that in _other_ situations, the
"atomic_inc_not_zero()" kind of pattern is used as a way to allow the
find-vs-last-drop race to be done without locking, but that's not what
the ucounts code does.

ucounts uses the ucounts_lock, and that one is entirely immaterial for
the atomic_add_negative() case, because the "negative" test is
literally about the value being as far away from zero as is _possible_
(and at that point, the lock is most definitely not needed - it's
needed only for the cases where the refcount goes to zero, and to make
sure that a "find" cannot race with that).


  parent reply	other threads:[~2021-08-07  8:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 17:15 [GIT PULL] ucount fix for v5.14-rc Eric W. Biederman
2021-08-05 19:26 ` pr-tracker-bot
     [not found] ` <>
2021-08-06  3:38   ` Eric W. Biederman
     [not found]     ` <>
2021-08-06 17:37       ` Linus Torvalds
     [not found]         ` <>
2021-08-07  8:23           ` Linus Torvalds [this message]
     [not found]             ` <>
2021-08-07 15:10               ` Linus Torvalds
     [not found]                 ` <>
2021-08-08  1:00                   ` Linus Torvalds
     [not found]                     ` <>
2021-08-08  1:45                       ` Linus Torvalds
2021-08-08  2:05                         ` Linus Torvalds

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).