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
Subject: Re: [PATCH] fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
Date: Sun, 4 Aug 2024 05:17:33 +0100	[thread overview]
Message-ID: <20240804041733.GC5334@ZenIV> (raw)
In-Reply-To: <20240804034739.GB5334@ZenIV>

BTW, the current description I've got next to struct fdtable definition:

/*
 * fdtable's capacity is stored in ->max_fds; it is set when instance is
 * created and never changed after that.  It is always a positive multiple
 * of BITS_PER_LONG (i.e. no less than BITS_PER_LONG).  It can't exceed
 * MAX_INT - userland often stores descriptors as int, treating anything
 * negative as an error, so the numbers past MAX_INT are definitely
 * not usable as descriptors.
 *
 * if fdt->max_fds is equal to N, fdt can hold descriptors in range 0..N-1.
 *
 * ->fd points to an N-element array of file pointers.  If descriptor #k is
 * open, ->fd[k] points to the file associated it; otherwise it's NULL.
 *
 * both ->open_fds and ->close_on_exec point to N-bit bitmaps.
 * Since N is a multiple of BITS_PER_LONG, those are arrays of unsigned long
 * with N / BITS_PER_LONG elements and all bits are in use.
 * Bit #k in ->open_fds is set iff descriptor #k has been claimed.
 * In that case the corresponding bit in ->close_on_exec determines whether
 * it should be closed on execve().  If descriptor is *not* claimed, the
 * value of corresponding bit in ->close_on_exec is undetermined.
 *
 * ->full_fds_bits points to a N/BITS_PER_LONG-bit bitmap, i.e. to an array of
 * unsigned long with BITS_TO_LONGS(N / BITS_PER_LONG) elements.  Note that
 * N is *not* promised to be a multiple of BITS_PER_LONG^2, so there may be
 * unused bits in the last word.  Its contents is a function of ->open_fds -
 * bit #k is set in it iff all bits stored in ->open_fds[k] are set (i.e. if
 * ->open_fds[k] == ~0ul).  All unused bits in the last word must be clear.
 * That bitmap is used for cheaper search for unclaimed descriptors.
 *
 * Note that all of those are pointers - arrays themselves are elsewhere.
 * The whole thing is reached from a files_struct instance; the reason
 * we do not keep those pointers in files_struct itself is that on resize
 * we want to flip all of them at once *and* we want the readers to be
 * able to work locklessly.  This is a device for switching all of those
 * in one store operation.  Freeing the replaced instance is RCU-delayed;
 * ->rcu is used to do that.
 */

  reply	other threads:[~2024-08-04  4:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-03 22:50 [PATCH] fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE Al Viro
2024-08-03 23:06 ` Al Viro
2024-08-03 23:51 ` Linus Torvalds
2024-08-04  0:05   ` Linus Torvalds
2024-08-04  0:34   ` Al Viro
2024-08-04  3:42     ` Linus Torvalds
2024-08-04  3:47     ` Al Viro
2024-08-04  4:17       ` Al Viro [this message]
2024-08-04 15:18       ` Linus Torvalds
2024-08-04 21:13         ` Al Viro
2024-08-05 23:44           ` Al Viro
2024-08-06  0:04             ` Linus Torvalds
2024-08-06  1:02               ` Al Viro
2024-08-06  8:41                 ` Christian Brauner
2024-08-06 16:32                   ` Al Viro
2024-08-06 17:01                     ` Linus Torvalds
2024-08-05  7:22 ` Christian Brauner
2024-08-05 18:54   ` Al Viro
2024-08-06  9:11     ` Christian Brauner
2024-08-05  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=20240804041733.GC5334@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --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.