All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Jann Horn <jannh@google.com>
Subject: Re: [PATCH RFC 0/4] fs: port files to rcuref_long_t
Date: Sat, 5 Oct 2024 23:01:00 +0100	[thread overview]
Message-ID: <20241005220100.GA4017910@ZenIV> (raw)
In-Reply-To: <CAHk-=wj7=Ynmk9+Fm860NqHu5q119AiN4YNXNJPt=6Q=Y=w3HA@mail.gmail.com>

On Sat, Oct 05, 2024 at 02:42:25PM -0700, Linus Torvalds wrote:

> Also, honestly, the only reason the file counting is using a "long" is
> because the code does *NOT* do overflow checking. But once you start
> looking at the sign and do conditional increments, you can actually
> just make the whole refcount be a "int" instead, and make "struct
> file" potentially smaller.

I wouldn't bet on that.  You *can* get over 2G references on 64bit box
with arseloads of memory, and we have no way to make fget() et.al.
fail when refcount gets that high - no valid error to return and
a serious DoS potential if we start doing that.

Overflow on leaks is one thing, a huge pile of real references is a
different story, and yes, we can get that.  And boxen with 1Tb RAM
are not as exotic these days as they used to be...

  reply	other threads:[~2024-10-05 22:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-05 19:16 [PATCH RFC 0/4] fs: port files to rcuref_long_t Christian Brauner
2024-10-05 19:16 ` [PATCH RFC 1/4] fs: protect backing files with rcu Christian Brauner
2024-10-05 19:16 ` [PATCH RFC 2/4] types: add rcuref_long_t Christian Brauner
2024-10-05 19:16 ` [PATCH RFC 3/4] rcuref: add rcuref_long_*() helpers Christian Brauner
2024-10-05 19:16 ` [PATCH RFC 4/4] fs: port files to rcuref_long_t Christian Brauner
2024-10-05 21:42 ` [PATCH RFC 0/4] " Linus Torvalds
2024-10-05 22:01   ` Al Viro [this message]
2024-10-05 22:14     ` Linus Torvalds
2024-10-05 22:28       ` Al Viro
2024-10-05 22:43         ` Linus Torvalds
2024-10-05 22:51           ` Al Viro
2024-10-06  9:55           ` Christian Brauner
2024-10-05 22:01   ` Linus Torvalds
2024-10-06 10:21     ` Christian Brauner
2024-10-06 18:09       ` Linus Torvalds
2024-10-07  7:37         ` Christian Brauner
2024-10-06  9:48   ` Christian Brauner

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=20241005220100.GA4017910@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=jannh@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.