From: Mike Galbraith <efault@gmx.de>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-ntfs-dev@lists.sourceforge.net, Neil Brown <neilb@suse.de>
Subject: Re: [Linux-NTFS-Dev] 2.6.23 regression: second access of empty ntfs file leads to D state hang
Date: Tue, 30 Oct 2007 09:00:02 +0100 [thread overview]
Message-ID: <1193731202.7229.9.camel@Homer.simpson.net> (raw)
In-Reply-To: <1193671099.7172.0.camel@Homer.simpson.net>
On Mon, 2007-10-29 at 16:18 +0100, Mike Galbraith wrote:
> On Mon, 2007-10-29 at 15:43 +0100, Mike Galbraith wrote:
> > On Mon, 2007-10-29 at 13:39 +0000, Anton Altaparmakov wrote:
> > > Hi Mike,
> > >
> > > Thanks for the files. That is really odd. And you are sure this just
> > > works with 2.6.22.10 on the exact same file? Have you run "chkdsk /
> > > f /v /x" on the NTFS volume from Windows?
> >
> > Yes, 2.6.22.10 can md5sum that file just fine, did it several times. I
> > haven't run chkdsk.
>
> I now have fun chkdsk, it didn't gripe, and the error is still present.
Not being very good at walking away from unsolved mysteries, I chased it
down. The problem is that...
commit[a32ea1e1f925399e0d81ca3f7394a44a6dafa12c] Fix read/truncate race
...calls ntfs_readpage() for a zero i_size inode, which it isn't
accustomed to.
Below is the hammer which made my box a happy camper again.
diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c
index 6e5c253..ddab5a3 100644
--- a/fs/ntfs/aops.c
+++ b/fs/ntfs/aops.c
@@ -401,7 +401,7 @@ static int ntfs_readpage(struct file *file, struct page *page)
MFT_RECORD *mrec;
unsigned long flags;
u32 attr_len;
- int err = 0;
+ int err = 0, once = 0;
retry_readpage:
BUG_ON(!PageLocked(page));
@@ -414,6 +414,18 @@ retry_readpage:
return 0;
}
vi = page->mapping->host;
+ /*
+ * If we've been called to read a zero sized inode, zero and bail.
+ */
+ if (!once) {
+ loff_t i_size = i_size_read(vi);
+
+ once++;
+ if (!i_size) {
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
+ goto done;
+ }
+ }
ni = NTFS_I(vi);
/*
* Only $DATA attributes can be encrypted and only unnamed $DATA
next prev parent reply other threads:[~2007-10-30 8:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 6:08 Mike Galbraith
2007-10-29 6:18 ` Mike Galbraith
2007-10-29 10:40 ` Anton Altaparmakov
2007-10-29 10:31 ` [Linux-NTFS-Dev] " Anton Altaparmakov
2007-10-29 11:45 ` Mike Galbraith
2007-10-29 13:39 ` Anton Altaparmakov
2007-10-29 13:41 ` Anton Altaparmakov
2007-10-29 14:43 ` Mike Galbraith
2007-10-29 15:18 ` Mike Galbraith
2007-10-30 8:00 ` Mike Galbraith [this message]
2007-10-30 9:23 ` Anton Altaparmakov
2007-11-02 19:22 ` Anton Altaparmakov
2007-11-03 4:56 ` Mike Galbraith
2007-11-03 7:27 ` Anton Altaparmakov
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=1193731202.7229.9.camel@Homer.simpson.net \
--to=efault@gmx.de \
--cc=aia21@cam.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=neilb@suse.de \
/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
Powered by JetHome