All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Reuben Dowle <Reuben.Dowle@navico.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Oops when calling fsync on read-only file-system
Date: Wed, 13 Apr 2011 10:31:59 +0300	[thread overview]
Message-ID: <1302679919.2768.9.camel@localhost> (raw)
In-Reply-To: <70F6AAAFDC054F41B9994A9BCD3DF64E1284E165@exch01-aklnz.MARINE.NET.INT>

Hi,

thanks a lot for reporting this!
On Tue, 2011-04-12 at 13:32 +1200, Reuben Dowle wrote:
> On my system, calling the fsync system call on any file in a UBI
> file-system that is mounted read-only leads to a kernel oops. Our
> system is running a customise version of 2.6.31, but as far as I can
> see (without testing which is not possible due to extensive vendor
> customisation of .31 kernel version), the current git branch also
> contains this bug.
> 
> I have created a patch against 2.6.31 that fixes the problem in my
> system. Perhaps someone could test on latest kernel version.
> 
> Signed-off-by: Reuben Dowle <reuben.dowle at navico.com>

Wow! Shame on me for this bug! And it is funny that it is there for
several years already and there are product with this bug! Here is the
fix which I will merge upstream soon:


From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Subject: [PATCH] UBIFS: fix oops when R/O file-system is fsync'ed

This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an
file on R/O-mounter file-system. We (the UBIFS authors) incorrectly
thought that VFS would not propagate 'fsync()' down to the file-system
if it is read-only, but this is not the case.

It is easy to exploit this bug using the following simple perl script:

use strict;
use File::Sync qw(fsync sync);

die "File path is not specified" if not defined $ARGV[0];
my $path = $ARGV[0];

open FILE, "<", "$path" or die "Cannot open $path: $!";
fsync(\*FILE) or die "cannot fsync $path: $!";
close FILE or die "Cannot close $path: $!";

Thanks to Reuben Dowle <Reuben.Dowle@navico.com> for reporting about this
issue.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reported-by: Reuben Dowle <Reuben.Dowle@navico.com>
Cc: stable@kernel.org
---
 fs/ubifs/file.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index a2b5012..3594aae 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1312,6 +1312,9 @@ int ubifs_fsync(struct file *file, int datasync)
 
 	dbg_gen("syncing inode %lu", inode->i_ino);
 
+	if (inode->i_sb->s_flags & MS_RDONLY)
+		return 0;
+
 	/*
 	 * VFS has already synchronized dirty pages for this inode. Synchronize
 	 * the inode unless this is a 'datasync()' call.
-- 
1.7.2.3

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

      reply	other threads:[~2011-04-13  7:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-12  1:32 Oops when calling fsync on read-only file-system Reuben Dowle
2011-04-13  7:31 ` Artem Bityutskiy [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=1302679919.2768.9.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=Reuben.Dowle@navico.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.