From: "Ma, Yu" <yu.ma@intel.com>
To: Christian Brauner <brauner@kernel.org>
Cc: viro@zeniv.linux.org.uk, jack@suse.cz, mjguzik@gmail.com,
edumazet@google.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, pan.deng@intel.com,
tianyou.li@intel.com, tim.c.chen@intel.com,
tim.c.chen@linux.intel.com, yu.ma@intel.com
Subject: Re: [PATCH v3 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd()
Date: Wed, 3 Jul 2024 22:46:36 +0800 [thread overview]
Message-ID: <5ece40f0-0d28-4d7f-b028-91825cb05ed7@intel.com> (raw)
In-Reply-To: <20240703-ketchup-aufteilen-3e4c648b20c8@brauner>
On 7/3/2024 10:34 PM, Christian Brauner wrote:
> On Wed, Jul 03, 2024 at 10:33:09AM GMT, Yu Ma wrote:
>> alloc_fd() has a sanity check inside to make sure the struct file mapping to the
>> allocated fd is NULL. Remove this sanity check since it can be assured by
>> exisitng zero initilization and NULL set when recycling fd. Meanwhile, add
>> likely/unlikely and expand_file() call avoidance to reduce the work under
>> file_lock.
>>
>> Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
>> Signed-off-by: Yu Ma <yu.ma@intel.com>
>> ---
>> fs/file.c | 38 ++++++++++++++++----------------------
>> 1 file changed, 16 insertions(+), 22 deletions(-)
>>
>> diff --git a/fs/file.c b/fs/file.c
>> index a3b72aa64f11..5178b246e54b 100644
>> --- a/fs/file.c
>> +++ b/fs/file.c
>> @@ -515,28 +515,29 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags)
>> if (fd < files->next_fd)
>> fd = files->next_fd;
>>
>> - if (fd < fdt->max_fds)
>> + if (likely(fd < fdt->max_fds))
>> fd = find_next_fd(fdt, fd);
>>
>> + error = -EMFILE;
>> + if (unlikely(fd >= fdt->max_fds)) {
>> + error = expand_files(files, fd);
>> + if (error < 0)
>> + goto out;
>> + /*
>> + * If we needed to expand the fs array we
>> + * might have blocked - try again.
>> + */
>> + if (error)
>> + goto repeat;
>> + }
> So this ends up removing the expand_files() above the fd >= end check
> which means that you can end up expanding the files_struct even though
> the request fd is past the provided end. That seems odd. What's the
> reason for that reordering?
Yes, you are right, thanks Christian. This incorrect reordering here is
due to historical versions with fast path inside. I'll update the order
back.
>> +
>> /*
>> * N.B. For clone tasks sharing a files structure, this test
>> * will limit the total number of files that can be opened.
>> */
>> - error = -EMFILE;
>> - if (fd >= end)
>> - goto out;
>> -
>> - error = expand_files(files, fd);
>> - if (error < 0)
>> + if (unlikely(fd >= end))
>> goto out;
>>
>> - /*
>> - * If we needed to expand the fs array we
>> - * might have blocked - try again.
>> - */
>> - if (error)
>> - goto repeat;
>> -
>> if (start <= files->next_fd)
>> files->next_fd = fd + 1;
>>
>> @@ -546,13 +547,6 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags)
>> else
>> __clear_close_on_exec(fd, fdt);
>> error = fd;
>> -#if 1
>> - /* Sanity check */
>> - if (rcu_access_pointer(fdt->fd[fd]) != NULL) {
>> - printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd);
>> - rcu_assign_pointer(fdt->fd[fd], NULL);
>> - }
>> -#endif
>>
>> out:
>> spin_unlock(&files->file_lock);
>> @@ -618,7 +612,7 @@ void fd_install(unsigned int fd, struct file *file)
>> rcu_read_unlock_sched();
>> spin_lock(&files->file_lock);
>> fdt = files_fdtable(files);
>> - BUG_ON(fdt->fd[fd] != NULL);
>> + WARN_ON(fdt->fd[fd] != NULL);
>> rcu_assign_pointer(fdt->fd[fd], file);
>> spin_unlock(&files->file_lock);
>> return;
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2024-07-03 14:46 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 16:34 [PATCH 0/3] fs/file.c: optimize the critical section of Yu Ma
2024-06-14 16:34 ` [PATCH 1/3] fs/file.c: add fast path in alloc_fd() Yu Ma
2024-06-15 6:31 ` Mateusz Guzik
2024-06-16 4:01 ` Ma, Yu
2024-06-17 17:49 ` Tim Chen
2024-06-19 10:36 ` David Laight
2024-06-19 17:09 ` Ma, Yu
2024-06-14 16:34 ` [PATCH 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-06-14 16:34 ` [PATCH 3/3] fs/file.c: move sanity_check from alloc_fd() to put_unused_fd() Yu Ma
2024-06-15 4:41 ` Mateusz Guzik
2024-06-15 5:07 ` Mateusz Guzik
2024-06-17 17:55 ` Tim Chen
2024-06-17 17:59 ` Mateusz Guzik
2024-06-17 18:04 ` Tim Chen
2024-06-18 8:35 ` Michal Hocko
2024-06-18 9:06 ` Mateusz Guzik
2024-06-18 20:40 ` Tim Chen
2024-06-16 3:47 ` Ma, Yu
2024-06-17 11:23 ` Mateusz Guzik
2024-06-17 17:22 ` Ma, Yu
2024-06-17 8:36 ` Christian Brauner
2024-06-22 15:49 ` [PATCH v2 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-06-22 15:49 ` [PATCH v2 1/3] fs/file.c: add fast path in alloc_fd() Yu Ma
2024-06-25 11:52 ` Jan Kara
2024-06-25 12:53 ` Jan Kara
2024-06-25 15:33 ` Ma, Yu
2024-06-26 11:54 ` Jan Kara
2024-06-26 16:43 ` Tim Chen
2024-06-26 16:52 ` Tim Chen
2024-06-27 12:09 ` Jan Kara
2024-06-27 12:20 ` Mateusz Guzik
2024-06-27 16:21 ` Tim Chen
2024-06-26 19:13 ` Mateusz Guzik
2024-06-27 14:03 ` Jan Kara
2024-06-27 15:33 ` Christian Brauner
2024-06-27 18:27 ` Ma, Yu
2024-06-27 19:59 ` Mateusz Guzik
2024-06-28 9:12 ` Jan Kara
2024-06-29 15:41 ` Ma, Yu
2024-06-29 15:46 ` Mateusz Guzik
2024-06-29 14:23 ` Ma, Yu
2024-06-22 15:49 ` [PATCH v2 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-06-25 11:54 ` Jan Kara
2024-06-25 15:41 ` Ma, Yu
2024-06-22 15:49 ` [PATCH v2 3/3] fs/file.c: remove sanity_check from alloc_fd() Yu Ma
2024-06-25 12:08 ` Jan Kara
2024-06-25 13:09 ` Mateusz Guzik
2024-06-25 13:11 ` Mateusz Guzik
2024-06-25 13:30 ` Jan Kara
2024-06-26 13:10 ` Christian Brauner
2024-07-03 14:33 ` [PATCH v3 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-03 14:33 ` [PATCH v3 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-07-03 14:34 ` Christian Brauner
2024-07-03 14:46 ` Ma, Yu [this message]
2024-07-04 10:11 ` Jan Kara
2024-07-04 14:45 ` Ma, Yu
2024-07-04 15:41 ` Jan Kara
2024-07-03 14:33 ` [PATCH v3 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-03 14:33 ` [PATCH v3 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-03 14:17 ` Mateusz Guzik
2024-07-03 14:28 ` Ma, Yu
2024-07-04 10:07 ` Jan Kara
2024-07-04 10:03 ` Jan Kara
2024-07-04 14:50 ` Ma, Yu
2024-07-04 17:44 ` Mateusz Guzik
2024-07-04 21:55 ` Jan Kara
2024-07-05 7:56 ` Ma, Yu
2024-07-09 8:32 ` Ma, Yu
2024-07-09 10:17 ` Mateusz Guzik
2024-07-10 23:40 ` Tim Chen
2024-07-11 9:27 ` Ma, Yu
2024-07-13 2:39 ` [PATCH v4 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-13 2:39 ` [PATCH v4 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-07-16 11:11 ` Jan Kara
2024-07-13 2:39 ` [PATCH v4 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-13 2:39 ` [PATCH v4 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-16 11:19 ` Jan Kara
2024-07-16 12:37 ` Ma, Yu
2024-07-17 14:50 ` [PATCH v5 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-17 14:50 ` [PATCH v5 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-08-06 13:44 ` kernel test robot
2024-08-14 21:38 ` Al Viro
2024-08-15 2:49 ` Ma, Yu
2024-08-15 3:45 ` Al Viro
2024-08-15 8:34 ` Ma, Yu
2024-10-31 7:42 ` Mateusz Guzik
2024-10-31 10:14 ` Christian Brauner
2024-07-17 14:50 ` [PATCH v5 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-17 14:50 ` [PATCH v5 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-19 17:53 ` Mateusz Guzik
2024-07-20 12:57 ` Ma, Yu
2024-07-20 14:22 ` Mateusz Guzik
2024-08-06 13:48 ` kernel test robot
2024-07-22 15:02 ` [PATCH v5 0/3] fs/file.c: optimize the critical section of file_lock in Christian Brauner
2024-08-01 19:13 ` Al Viro
2024-08-02 11:04 ` Christian Brauner
2024-08-02 14:22 ` Al Viro
2024-08-05 6:56 ` Christian Brauner
2024-08-12 1:31 ` Ma, Yu
2024-08-12 2:40 ` Al Viro
2024-08-12 15:09 ` Ma, Yu
2024-11-06 17:44 ` Jan Kara
2024-11-06 17:59 ` Al Viro
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=5ece40f0-0d28-4d7f-b028-91825cb05ed7@intel.com \
--to=yu.ma@intel.com \
--cc=brauner@kernel.org \
--cc=edumazet@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=pan.deng@intel.com \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®