mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: Vadim Lobanov <vlobanov@speakeasy.net>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Clean up expand_fdtable() and expand_files().
Date: Tue, 5 Sep 2006 12:01:33 -0700	[thread overview]
Message-ID: <20060905120133.69fe7d6e.rdunlap@xenotime.net> (raw)
In-Reply-To: <200609051156.50150.vlobanov@speakeasy.net>

On Tue, 5 Sep 2006 11:56:49 -0700 Vadim Lobanov wrote:

> On Tuesday 05 September 2006 09:55, Randy.Dunlap wrote:
> > On Mon, 4 Sep 2006 22:08:36 -0700 Vadim Lobanov wrote:
> > > Hi,
> > >
> > > This patch performs a code cleanup against the expand_fdtable() and
> > > expand_files() functions inside fs/file.c. It aims to make the flow of
> > > code within these functions simpler and easier to understand, via added
> > > comments and modest refactoring. The patch was generated against
> > > 2.6.18-rc5-mm1, and was successfully run live. Please apply.
> > >
> > > (I'm trying out KMail for this patch. I tested this mailer beforehand to
> > > make sure the patch will come out unmangled, but, as with all things
> > > software, success is far from guaranteed. :) Please yell if the patch is
> > > borked.)
> >
> > It's not (mechanically) b0rked.
> >
> > > Signed-off-by: Vadim Lobanov <vlobanov@speakeasy.net>
> > >
> > > diff -Npru linux-a/fs/file.c linux-b/fs/file.c
> > > --- linux-a/fs/file.c	2006-09-01 20:34:12.000000000 -0700
> > > +++ linux-b/fs/file.c	2006-09-04 16:42:33.000000000 -0700
> > > @@ -296,37 +296,30 @@ static int expand_fdtable(struct files_s
> > >  	__releases(files->file_lock)
> > >  	__acquires(files->file_lock)
> > >  {
> > > -	int error = 0;
> > > -	struct fdtable *fdt;
> > > -	struct fdtable *nfdt = NULL;
> > > +	struct fdtable *new_fdt, *cur_fdt;
> > >
> > >  	spin_unlock(&files->file_lock);
> > > -	nfdt = alloc_fdtable(nr);
> > > -	if (!nfdt) {
> > > -		error = -ENOMEM;
> > > -		spin_lock(&files->file_lock);
> > > -		goto out;
> > > -	}
> > > -
> > > +	new_fdt = alloc_fdtable(nr);
> > >  	spin_lock(&files->file_lock);
> > > -	fdt = files_fdtable(files);
> > > +	if (!new_fdt)
> > > +		return -ENOMEM;
> > >  	/*
> > > -	 * Check again since another task may have expanded the
> > > -	 * fd table while we dropped the lock
> > > +	 * Check again since another task may have expanded the fd table while
> > > +	 * we dropped the lock
> > >  	 */
> > > -	if (nr >= fdt->max_fds || nr >= fdt->max_fdset) {
> > > -		copy_fdtable(nfdt, fdt);
> > > +	cur_fdt = files_fdtable(files);
> > > +	if (nr >= cur_fdt->max_fds || nr >= cur_fdt->max_fdset) {
> > > +		/* Continue as planned */
> > > +		copy_fdtable(new_fdt, cur_fdt);
> > > +		rcu_assign_pointer(files->fdt, new_fdt);
> > > +		free_fdtable(cur_fdt);
> > >  	} else {
> > > -		/* Somebody expanded while we dropped file_lock */
> > > +		/* Somebody else expanded, so undo our attempt */
> > >  		spin_unlock(&files->file_lock);
> > > -		__free_fdtable(nfdt);
> > > +		__free_fdtable(new_fdt);
> > >  		spin_lock(&files->file_lock);
> > > -		goto out;
> > >  	}
> > > -	rcu_assign_pointer(files->fdt, nfdt);
> > > -	free_fdtable(fdt);
> > > -out:
> > > -	return error;
> > > +	return 1;
> >
> > This function didn't previously return a value of 1.
> > If it can do so now, please document it in the function comments
> > "header".  Using kernel-doc would be good too.
> 
> More comments on the function headers. Gotcha. Will resend.
> 
> The problem with kernel-doc in this particular instance is that none of the 
> other functions in that file have comments in that particular style; they all 
> currently use the mostly-unstructured C comments. If anything, it'd be far 
> simpler and cleaner to get this particular patch merged first, and then add 
> kernel-doc comments to _all_ the functions in this file at once in a later 
> patch.

Sure.  The kernel-doc comment was certainly secondary.

---
~Randy

      reply	other threads:[~2006-09-05 18:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-05  5:08 Vadim Lobanov
2006-09-05 16:55 ` Randy.Dunlap
2006-09-05 18:56   ` Vadim Lobanov
2006-09-05 19:01     ` Randy.Dunlap [this message]

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=20060905120133.69fe7d6e.rdunlap@xenotime.net \
    --to=rdunlap@xenotime.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vlobanov@speakeasy.net \
    /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®