Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

2018-01-19 Thread J. Bruce Fields
On Fri, Jan 19, 2018 at 09:36:34AM -0500, Jeff Layton wrote: > Shrug...we have that problem with the spinlock in place too. The bottom > line is that reads of this value are not serialized with the increment > at all. OK, so this wouldn't even be a new bug. > I'm not 100% thrilled with this

Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

2018-01-19 Thread Jeff Layton
On Thu, 2018-01-18 at 16:45 -0500, J. Bruce Fields wrote: > On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > The rationale for taking the i_lock when incrementing this value is > > lost in antiquity. The readers of the field don't

Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

2018-01-18 Thread J. Bruce Fields
On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote: > From: Jeff Layton > > The rationale for taking the i_lock when incrementing this value is > lost in antiquity. The readers of the field don't take it (at least > not universally), so my assumption is that it was

Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

2018-01-09 Thread Jan Kara
On Tue 09-01-18 09:10:42, Jeff Layton wrote: > From: Jeff Layton > > The rationale for taking the i_lock when incrementing this value is > lost in antiquity. The readers of the field don't take it (at least > not universally), so my assumption is that it was only done here to

[PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion

2018-01-09 Thread Jeff Layton
From: Jeff Layton The rationale for taking the i_lock when incrementing this value is lost in antiquity. The readers of the field don't take it (at least not universally), so my assumption is that it was only done here to serialize incrementors. If that is indeed the case,