public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alexander Viro <viro@math.psu.edu>,
	Linus Torvalds <torvalds@transmeta.com>,
	torrey.hoffman@myrio.com, linux-kernel@vger.kernel.org,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes
Date: Mon, 7 Jan 2002 04:08:28 +0100	[thread overview]
Message-ID: <20020107040828.H1561@athlon.random> (raw)
In-Reply-To: <3C2EB208.B2BA7CBF@zip.com.au> <Pine.GSO.4.21.0112300129060.8523-100000@weyl.math.psu.edu>, <Pine.GSO.4.21.0112300129060.8523-100000@weyl.math.psu.edu>; <20011231010537.K1356@athlon.random> <3C36E6E8.628BF0BF@zip.com.au>
In-Reply-To: <3C36E6E8.628BF0BF@zip.com.au>; from akpm@zip.com.au on Sat, Jan 05, 2002 at 03:43:36AM -0800

On Sat, Jan 05, 2002 at 03:43:36AM -0800, Andrew Morton wrote:
>  static int msync_interval(struct vm_area_struct * vma,
>  	unsigned long start, unsigned long end, int flags)
>  {
> +	int ret = 0;
>  	struct file * file = vma->vm_file;
> +
>  	if (file && (vma->vm_flags & VM_SHARED)) {
> -		int error;
> -		error = filemap_sync(vma, start, end-start, flags);
> +		/* filemap_sync() cannot fail */

:) yes, I guess it cames from some old debugging code trying to catch
pte corruption, now dead in current kernels.

> +		ret = filemap_sync(vma, start, end-start, flags);
>  
> -		if (!error && (flags & MS_SYNC)) {
> +		if (flags & (MS_SYNC|MS_ASYNC)) {

ok, it cannot fail but I prefer you either avoid the 'ret =
filemap_sync' and you make filemap_sync return void, or you also left
'(!err' over here.

>  			struct inode * inode = file->f_dentry->d_inode;
> +
>  			down(&inode->i_sem);
> -			filemap_fdatasync(inode->i_mapping);
> -			if (file->f_op && file->f_op->fsync)
> -				error = file->f_op->fsync(file, file->f_dentry, 1);
> -			filemap_fdatawait(inode->i_mapping);
> +			ret = filemap_fdatasync(inode->i_mapping);
> +			if (flags & MS_SYNC) {
> +				int err;
> +
> +				if (file->f_op && file->f_op->fsync) {
> +					err = file->f_op->fsync(file, file->f_dentry, 1);
> +					if (err && !ret)
> +						ret = err;
> +				}
> +				err = filemap_fdatawait(inode->i_mapping);
> +				if (err && !ret)
> +					ret = err;
> +			}

sounds right (not something I'd love to do in 2.4 but it's
strightforward enough so I'll take the risk).

> @@ -433,9 +439,9 @@ asmlinkage long sys_fdatasync(unsigned i
>  	struct file * file;
>  	struct dentry * dentry;
>  	struct inode * inode;
> -	int err;
> +	int ret, err;
>  
> -	err = -EBADF;
> +	ret = -EBADF;
>  	file = fget(fd);
>  	if (!file)
>  		goto out;
> @@ -443,14 +449,18 @@ asmlinkage long sys_fdatasync(unsigned i
>  	dentry = file->f_dentry;
>  	inode = dentry->d_inode;
>  
> -	err = -EINVAL;
> +	ret = -EINVAL;
>  	if (!file->f_op || !file->f_op->fsync)
>  		goto out_putf;
>  
>  	down(&inode->i_sem);
> -	filemap_fdatasync(inode->i_mapping);
> +	ret = filemap_fdatasync(inode->i_mapping);
>  	err = file->f_op->fsync(file, dentry, 1);
> -	filemap_fdatawait(inode->i_mapping);
> +	if (err && !ret)
> +		ret = err;
> +	err = filemap_fdatawait(inode->i_mapping);
> +	if (err && !ret)
> +		ret = err;
>  	up(&inode->i_sem);
>  
>  out_putf:

you forgot return ret here.

> --- linux-2.4.18-pre1/fs/nfs/file.c	Wed Dec 26 11:47:41 2001
> +++ linux-akpm/fs/nfs/file.c	Sat Jan  5 03:21:07 2002
> @@ -244,6 +244,7 @@ nfs_lock(struct file *filp, int cmd, str
>  {
>  	struct inode * inode = filp->f_dentry->d_inode;
>  	int	status = 0;
> +	int	status2;
>  
>  	dprintk("NFS: nfs_lock(f=%4x/%ld, t=%x, fl=%x, r=%Ld:%Ld)\n",
>  			inode->i_dev, inode->i_ino,
> @@ -278,11 +279,18 @@ nfs_lock(struct file *filp, int cmd, str
>  	 * Flush all pending writes before doing anything
>  	 * with locks..
>  	 */
> -	filemap_fdatasync(inode->i_mapping);
> +	/*
> +	 * Shouldn't filemap_fdatasync/wait be inside i_sem?
> +	 */

I think it's not necessary, because the list browse it's serialized by
the pagecache_lock and writepage can run outside the i_sem.

> +	status = filemap_fdatasync(inode->i_mapping);
>  	down(&inode->i_sem);
> -	status = nfs_wb_all(inode);
> +	status2 = nfs_wb_all(inode);
> +	if (status2 && !status)
> +		status = status2;
>  	up(&inode->i_sem);
> -	filemap_fdatawait(inode->i_mapping);
> +	status2 = filemap_fdatawait(inode->i_mapping);
> +	if (status2 && !status)
> +		status = status2;
>  	if (status < 0)
>  		return status;
>  
> @@ -300,11 +308,17 @@ nfs_lock(struct file *filp, int cmd, str
>  	 */
>   out_ok:
>  	if ((IS_SETLK(cmd) || IS_SETLKW(cmd)) && fl->fl_type != F_UNLCK) {
> -		filemap_fdatasync(inode->i_mapping);
> +		status2 = filemap_fdatasync(inode->i_mapping);
> +		if (status2 && !status)
> +			status = status2;
>  		down(&inode->i_sem);
> -		nfs_wb_all(inode);      /* we may have slept */
> +		status2 = nfs_wb_all(inode);      /* we may have slept */
> +		if (status2 && !status)
> +			status2 = status;
>  		up(&inode->i_sem);
> -		filemap_fdatawait(inode->i_mapping);
> +		status2 = filemap_fdatawait(inode->i_mapping);
> +		if (status2 && !status)
> +			status = status2;
>  		nfs_zap_caches(inode);
>  	}
>  	return status;

all right, thanks.

Andrea

  parent reply	other threads:[~2002-01-07  3:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-20 19:06 ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes Torrey Hoffman
2001-12-20 19:46 ` Linus Torvalds
2001-12-20 22:56   ` Alexander Viro
2001-12-20 23:42   ` Andrea Arcangeli
2001-12-21  1:49     ` Andrea Arcangeli
     [not found]       ` <3C22CF16.C78B1F19@zip.com.au>
2001-12-29 15:40         ` Andrea Arcangeli
2001-12-30  6:19           ` Andrew Morton
2001-12-30  6:33             ` Alexander Viro
2001-12-30  6:38               ` Andrew Morton
2001-12-30  7:17                 ` Alexander Viro
2001-12-30 10:15                   ` ramdisk corruption problems - was: RE: pivot_root and initrd Alan Cox
2001-12-31  0:08                 ` ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes Andrea Arcangeli
2001-12-30  7:08               ` Andrew Morton
2001-12-30  7:29                 ` Alexander Viro
2001-12-30  7:59                   ` ramdisk corruption problems - was: RE: pivot_root and initrdkern " Andrew Morton
2001-12-30 17:40                     ` Linus Torvalds
2001-12-31  0:28                       ` Andrea Arcangeli
2001-12-31  0:35                         ` Linus Torvalds
2001-12-31  1:00                           ` Andrea Arcangeli
2001-12-31  0:05               ` ramdisk corruption problems - was: RE: pivot_root and initrd kern " Andrea Arcangeli
2002-01-05 11:43                 ` Andrew Morton
2002-01-05 14:04                   ` Trond Myklebust
2002-01-07  3:08                   ` Andrea Arcangeli [this message]
2002-01-07  3:49                     ` Andrew Morton
2002-01-07  4:31                       ` Andrea Arcangeli
2001-12-30 23:56             ` Andrea Arcangeli
2001-12-31 10:06             ` Daniel Phillips
2002-01-04 16:38             ` Stephen C. Tweedie
2002-01-05  7:53       ` Andrew Morton
2002-01-07  1:08         ` Andrea Arcangeli
2001-12-21  1:38   ` Tachino Nobuhiro
2001-12-21  1:51     ` Everyone else but TWO Andre Hedrick
     [not found] <Pine.GSO.4.21.0112210151020.15555-100000@weyl.math.psu.edu>
2001-12-21 23:11 ` ramdisk corruption problems - was: RE: pivot_root and initrd kern el panic woes Linus Torvalds
2001-12-21 23:39   ` Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2001-12-18 20:14 Torrey Hoffman
2001-12-20 12:19 ` Tachino Nobuhiro
2001-12-18  1:44 Torrey Hoffman

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=20020107040828.H1561@athlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=sct@redhat.com \
    --cc=torrey.hoffman@myrio.com \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@math.psu.edu \
    /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