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®