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.
*/
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox