From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Mike Galbraith <efault@gmx.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
ntfs-dev <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: Fri, 2 Nov 2007 19:22:13 +0000 [thread overview]
Message-ID: <1EEFFD17-64E7-41C6-BFED-529A5794EC36@cam.ac.uk> (raw)
In-Reply-To: <3BFCE55A-F7E2-4A19-8FD9-F23AF2A29D76@cam.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Hi Mike,
On 30 Oct 2007, at 09:23, Anton Altaparmakov wrote:
> On 30 Oct 2007, at 08:00, Mike Galbraith wrote:
>> On Mon, 2007-10-29 at 16:18 +0100, Mike Galbraith wrote:
>> 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.
>
> Great, thanks for doing that!
>
>> Below is the hammer which made my box a happy camper again.
>
> Yes that will fix it but the complete solution is more involved as
> there are three related bugs which explain why you were getting the
> hangs after the error... I will make a patch for all of these in
> the next few days...
Attached is a patch that should fix this and the other related issues
I found.
Would you be able to test it in your setup? Thanks a lot in advance!
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
[-- Attachment #2: ntfs-read-fix.diff --]
[-- Type: application/octet-stream, Size: 2028 bytes --]
diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c
index cfdc790..4e42d4e 100644
--- a/fs/ntfs/aops.c
+++ b/fs/ntfs/aops.c
@@ -405,6 +405,14 @@ static int ntfs_readpage(struct file *file, struct page *page)
retry_readpage:
BUG_ON(!PageLocked(page));
+ i_size = i_size_read(vi);
+ /* Is the page fully outside i_size? (truncate in progress) */
+ if (unlikely(page->index >= (i_size + PAGE_CACHE_SIZE - 1) >>
+ PAGE_CACHE_SHIFT)) {
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
+ ntfs_debug("Read outside i_size - truncated?");
+ goto done;
+ }
/*
* This can potentially happen because we clear PageUptodate() during
* ntfs_writepage() of MstProtected() attributes.
diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
index 92dabdc..50d3b0c 100644
--- a/fs/ntfs/attrib.c
+++ b/fs/ntfs/attrib.c
@@ -179,10 +179,7 @@ int ntfs_map_runlist_nolock(ntfs_inode *ni, VCN vcn, ntfs_attr_search_ctx *ctx)
* ntfs_mapping_pairs_decompress() fails.
*/
end_vcn = sle64_to_cpu(a->data.non_resident.highest_vcn) + 1;
- if (!a->data.non_resident.lowest_vcn && end_vcn == 1)
- end_vcn = sle64_to_cpu(a->data.non_resident.allocated_size) >>
- ni->vol->cluster_size_bits;
- if (unlikely(vcn >= end_vcn)) {
+ if (unlikely(vcn && vcn >= end_vcn)) {
err = -ENOENT;
goto err_out;
}
diff --git a/fs/ntfs/compress.c b/fs/ntfs/compress.c
index d98daf5..d1619d0 100644
--- a/fs/ntfs/compress.c
+++ b/fs/ntfs/compress.c
@@ -561,6 +561,16 @@ int ntfs_read_compressed_block(struct page *page)
read_unlock_irqrestore(&ni->size_lock, flags);
max_page = ((i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT) -
offset;
+ /* Is the page fully outside i_size? (truncate in progress) */
+ if (xpage >= max_page) {
+ kfree(bhs);
+ kfree(pages);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
+ ntfs_debug("Compressed read outside i_size - truncated?");
+ SetPageUptodate(page);
+ unlock_page(page);
+ return 0;
+ }
if (nr_pages < max_page)
max_page = nr_pages;
for (i = 0; i < max_page; i++, offset++) {
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
next prev parent reply other threads:[~2007-11-02 19:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 6:08 2.6.23 regression: second access of empty ntfs file leads to D state hang 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
2007-10-30 9:23 ` Anton Altaparmakov
2007-11-02 19:22 ` Anton Altaparmakov [this message]
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=1EEFFD17-64E7-41C6-BFED-529A5794EC36@cam.ac.uk \
--to=aia21@cam.ac.uk \
--cc=efault@gmx.de \
--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;
as well as URLs for NNTP newsgroup(s).