* [PATCH] close_files(): reimplement based on do_close_on_exec() [not found] <20240812064427.240190-3-viro@zeniv.linux.org.uk> @ 2024-08-12 7:56 ` Mateusz Guzik 2024-08-14 5:24 ` Al Viro 0 siblings, 1 reply; 3+ messages in thread From: Mateusz Guzik @ 2024-08-12 7:56 UTC (permalink / raw) To: viro; +Cc: brauner, jack, linux-kernel, linux-fsdevel, Mateusz Guzik While here take more advantage of the fact nobody should be messing with the table anymore and don't clear the fd slot. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> --- how about this instead, I think it's a nicer clean up. It's literally do_close_on_exec except locking and put fd are deleted. boots & does not blow up, but admittedly I did not bother with ltp or any serious testing fs/file.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/fs/file.c b/fs/file.c index 74d7ad676579..3ff2e8265156 100644 --- a/fs/file.c +++ b/fs/file.c @@ -389,33 +389,38 @@ struct files_struct *dup_fd(struct files_struct *oldf, unsigned int max_fds) return newf; } -static struct fdtable *close_files(struct files_struct * files) +static struct fdtable *close_files(struct files_struct *files) { /* * It is safe to dereference the fd table without RCU or * ->file_lock because this is the last reference to the * files structure. + * + * For the same reason we can skip locking. */ struct fdtable *fdt = rcu_dereference_raw(files->fdt); - unsigned int i, j = 0; + unsigned i; - for (;;) { + for (i = 0; ; i++) { unsigned long set; - i = j * BITS_PER_LONG; - if (i >= fdt->max_fds) + unsigned fd = i * BITS_PER_LONG; + fdt = files_fdtable(files); + if (fd >= fdt->max_fds) break; - set = fdt->open_fds[j++]; - while (set) { - if (set & 1) { - struct file * file = xchg(&fdt->fd[i], NULL); - if (file) { - filp_close(file, files); - cond_resched(); - } - } - i++; - set >>= 1; + set = fdt->open_fds[i]; + if (!set) + continue; + for ( ; set ; fd++, set >>= 1) { + struct file *file; + if (!(set & 1)) + continue; + file = fdt->fd[fd]; + if (!file) + continue; + filp_close(file, files); + cond_resched(); } + } return fdt; -- 2.43.0 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] close_files(): reimplement based on do_close_on_exec() 2024-08-12 7:56 ` [PATCH] close_files(): reimplement based on do_close_on_exec() Mateusz Guzik @ 2024-08-14 5:24 ` Al Viro 2024-08-14 5:34 ` Mateusz Guzik 0 siblings, 1 reply; 3+ messages in thread From: Al Viro @ 2024-08-14 5:24 UTC (permalink / raw) To: Mateusz Guzik; +Cc: brauner, jack, linux-kernel, linux-fsdevel On Mon, Aug 12, 2024 at 09:56:58AM +0200, Mateusz Guzik wrote: > While here take more advantage of the fact nobody should be messing with > the table anymore and don't clear the fd slot. > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> > --- > > how about this instead, I think it's a nicer clean up. > It's literally do_close_on_exec except locking and put fd are deleted. TBH, I don't see much benefit that way - if anything, you are doing a bunch of extra READ_ONCE() of the same thing (files->fdt), for no visible reason... ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] close_files(): reimplement based on do_close_on_exec() 2024-08-14 5:24 ` Al Viro @ 2024-08-14 5:34 ` Mateusz Guzik 0 siblings, 0 replies; 3+ messages in thread From: Mateusz Guzik @ 2024-08-14 5:34 UTC (permalink / raw) To: Al Viro; +Cc: brauner, jack, linux-kernel, linux-fsdevel On Wed, Aug 14, 2024 at 7:24 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Mon, Aug 12, 2024 at 09:56:58AM +0200, Mateusz Guzik wrote: > > While here take more advantage of the fact nobody should be messing with > > the table anymore and don't clear the fd slot. > > > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> > > --- > > > > how about this instead, I think it's a nicer clean up. > > > It's literally do_close_on_exec except locking and put fd are deleted. > > TBH, I don't see much benefit that way - if anything, you are doing > a bunch of extra READ_ONCE() of the same thing (files->fdt), for no > visible reason... I claim the stock code avoidably implements traversal differently from do_close_on_exec. The fdt reload can be trivially lifted out of the loop, does not affect what I was going for. But now that you mention this can also be done in the do_close_on_exec case -- the thread calling it is supposed to be the only consumer, so fdt can't change. that's my $0,03 here, I'm not going to further argue about it -- Mateusz Guzik <mjguzik gmail.com> ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-08-14 5:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20240812064427.240190-3-viro@zeniv.linux.org.uk>
2024-08-12 7:56 ` [PATCH] close_files(): reimplement based on do_close_on_exec() Mateusz Guzik
2024-08-14 5:24 ` Al Viro
2024-08-14 5:34 ` Mateusz Guzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®