From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Ritesh Harjani <riteshh@linux.ibm.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
wugyuan@cn.ibm.com, jlayton@kernel.org, hsiangkao@aol.com,
Jan Kara <jack@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH][RFC] race in exportfs_decode_fh()
Date: Mon, 11 Nov 2019 10:16:44 +0100 [thread overview]
Message-ID: <20191111091644.GA11108@lst.de> (raw)
In-Reply-To: <20191109031333.GA8566@ZenIV.linux.org.uk>
On Sat, Nov 09, 2019 at 03:13:33AM +0000, Al Viro wrote:
> Does anyone see objections to the following patch? Christoph, that seems to
> be your code; am I missing something subtle here? AFAICS, that goes back to
> 2007 or so...
This goes back to way before that, that series jut factored out proper
export operations from the two inode or superblock methods we had before
with the rest handled in core code somewhere that made a complete
mess of file systems with 64-bit inode numbers.
Otherwise this looks fine, although splitting the refactoring from
the actual change would make for a much more readable series.
prev parent reply other threads:[~2019-11-11 9:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 4:42 [PATCH RESEND 1/1] vfs: Really check for inode ptr in lookup_fast Ritesh Harjani
2019-10-15 4:07 ` Ritesh Harjani
2019-10-22 13:38 ` Ritesh Harjani
2019-10-22 14:37 ` Al Viro
2019-10-22 14:50 ` Al Viro
2019-10-22 20:11 ` Al Viro
2019-10-23 11:05 ` Ritesh Harjani
2019-11-01 23:46 ` Al Viro
2019-11-02 6:17 ` Al Viro
2019-11-02 17:24 ` Paul E. McKenney
2019-11-02 17:22 ` Paul E. McKenney
2019-11-02 18:08 ` Al Viro
2019-11-03 14:41 ` Paul E. McKenney
2019-11-03 16:35 ` [RFC] lookup_one_len_unlocked() lousy calling conventions Al Viro
2019-11-03 18:20 ` Al Viro
2019-11-03 18:51 ` [PATCH][RFC] ecryptfs_lookup_interpose(): lower_dentry->d_inode is not stable Al Viro
2019-11-03 19:03 ` [PATCH][RFC] ecryptfs_lookup_interpose(): lower_dentry->d_parent is not stable either Al Viro
2019-11-13 7:01 ` [PATCH][RFC] ecryptfs_lookup_interpose(): lower_dentry->d_inode is not stable Amir Goldstein
2019-11-13 12:52 ` Al Viro
2019-11-13 16:22 ` Amir Goldstein
2019-11-13 20:18 ` Jean-Louis Biasini
2019-11-03 17:05 ` [PATCH][RFC] ecryptfs unlink/rmdir breakage (similar to caught in ecryptfs rename last year) Al Viro
2019-11-09 3:13 ` [PATCH][RFC] race in exportfs_decode_fh() Al Viro
2019-11-09 16:55 ` Linus Torvalds
2019-11-09 18:26 ` Al Viro
2019-11-11 9:16 ` Christoph Hellwig [this message]
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=20191111091644.GA11108@lst.de \
--to=hch@lst.de \
--cc=bfields@fieldses.org \
--cc=hsiangkao@aol.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riteshh@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wugyuan@cn.ibm.com \
/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).