mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nikita Danilov <Nikita@Namesys.COM>
To: Linus Torvalds <Torvalds@Transmeta.COM>
Cc: Reiserfs developers mail-list <Reiserfs-Dev@Namesys.COM>,
	"Linux kernel developer's mailing list" 
	<linux-kernel@vger.kernel.org>
Subject: [PATCH]: reiserfs: B-check_nlink_in_reiserfs_read_inode2.patch
Date: Mon, 17 Dec 2001 18:46:23 +0300	[thread overview]
Message-ID: <15390.4943.64152.676583@laputa.namesys.com> (raw)

Hello, Linus,

    This patch closes a race between iput() and threads accessing files
    directly by "inode numbers" (i.e., bypassing directory lookup) like
    knfsd.

    Suppose, last reference to file is being unlinked and iput() sleeps
    in sb->s_op->delete_inode(), after removing inode from hash
    table. At this moment "knfsd" comes and looks for this inode. Inode
    is not found in hash table, new instance is created and
    hashed. ->read_inode() is called only to find that on disk inode is
    there, still not deleted by sb->s_op->delete_inode(), so
    ->read_inode() returns successfully. Now, delete_inode() wakes up
    and removes remaining meta-data. At this moment we have valid inode
    in memory without meta-data on disk.

    Reiserfs updates on-disk meta-data including nlink during unlink(),
    so it's enough to check nlink during reiserfs_read_inode2(). This is
    _not_ enough to fix this race for ext2.

Please apply.

Nikita.
diff -rup -X dontdiff linux/fs/reiserfs/inode.c linux.patched/fs/reiserfs/inode.c
--- linux/fs/reiserfs/inode.c	Wed Oct 31 02:11:34 2001
+++ linux.patched/fs/reiserfs/inode.c	Mon Nov 26 15:27:09 2001
@@ -1138,6 +1138,30 @@ void reiserfs_read_inode2 (struct inode 
     }
 
     init_inode (inode, &path_to_sd);
+   
+    /* It is possible that knfsd is trying to access inode of a file
+       that is being removed from the disk by some other thread. As we
+       update sd on unlink all that is required is to check for nlink
+       here. This bug was first found by Sizif when debugging
+       SquidNG/Butterfly, forgotten, and found again after Philippe
+       Gramoulle <philippe.gramoulle@mmania.com> reproduced it. 
+
+       More logical fix would require changes in fs/inode.c:iput() to
+       remove inode from hash-table _after_ fs cleaned disk stuff up and
+       in iget() to return NULL if I_FREEING inode is found in
+       hash-table. */
+    /* Currently there is one place where it's ok to meet inode with
+       nlink==0: processing of open-unlinked and half-truncated files
+       during mount (fs/reiserfs/super.c:finish_unfinished()). */
+    if( ( inode -> i_nlink == 0 ) && 
+	! inode -> i_sb -> u.reiserfs_sb.s_is_unlinked_ok ) {
+	    reiserfs_warning( "vs-13075: reiserfs_read_inode2: "
+			      "dead inode read from disk %K. "
+			      "This is likely to be race with knfsd. Ignore\n", 
+			      &key );
+	    make_bad_inode( inode );
+    }
+
     reiserfs_check_path(&path_to_sd) ; /* init inode should be relsing */
 
 }
diff -rup -X dontdiff linux/include/linux/reiserfs_fs_sb.h linux.patched/include/linux/reiserfs_fs_sb.h
--- linux/include/linux/reiserfs_fs_sb.h	Thu Nov 22 22:46:19 2001
+++ linux.patched/include/linux/reiserfs_fs_sb.h	Mon Nov 26 15:22:44 2001
@@ -420,6 +420,10 @@ struct reiserfs_sb_info
     int s_bmaps_without_search;
     int s_direct2indirect;
     int s_indirect2direct;
+	/* set up when it's ok for reiserfs_read_inode2() to read from
+	   disk inode with nlink==0. Currently this is only used during
+	   finish_unfinished() processing at mount time */
+    int s_is_unlinked_ok;
     reiserfs_proc_info_data_t s_proc_info_data;
     struct proc_dir_entry *procdir;
 };

                 reply	other threads:[~2001-12-17 15:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=15390.4943.64152.676583@laputa.namesys.com \
    --to=nikita@namesys.com \
    --cc=Reiserfs-Dev@Namesys.COM \
    --cc=Torvalds@Transmeta.COM \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®