linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]



  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).