All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Ma, Yu" <yu.ma@intel.com>
Cc: Jan Kara <jack@suse.cz>, Christian Brauner <brauner@kernel.org>,
	viro@zeniv.linux.org.uk, 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
Subject: Re: [PATCH v3 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd()
Date: Thu, 4 Jul 2024 17:41:38 +0200	[thread overview]
Message-ID: <20240704154138.2mzaglillgtvmacz@quack3> (raw)
In-Reply-To: <8fd90ebb-5d47-4630-a972-386a9caed976@intel.com>

On Thu 04-07-24 22:45:32, Ma, Yu wrote:
> 
> On 7/4/2024 6:11 PM, Jan Kara wrote:
> > On Wed 03-07-24 16:34:49, 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?
> > Yeah, not only that but also:
> > 
> > > >   	/*
> > > >   	 * 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;
> > We could then exit here with error set to 0 instead of -EMFILE. So this
> > needs a bit of work. But otherwise the patch looks good to me.
> > 
> > 								Honza
> 
> Do you mean that we return 0 here is fd >=end, I'm afraid that might broke
> the original design of this function. And all the callers of it are using
> ret < 0 for error handling, if ret=0, that should mean the fd allocated is 0
> ...

What I meant is that after your changes alloc_fd() could return 0 in fd >=
end case. It could happen if we went through expand_files() which then
returned 0. Anyway, please just fix the ordering of checks and we should be
fine.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2024-07-04 15:41 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
2024-07-04 10:11       ` Jan Kara
2024-07-04 14:45         ` Ma, Yu
2024-07-04 15:41           ` Jan Kara [this message]
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=20240704154138.2mzaglillgtvmacz@quack3 \
    --to=jack@suse.cz \
    --cc=brauner@kernel.org \
    --cc=edumazet@google.com \
    --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 \
    --cc=yu.ma@intel.com \
    /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.