Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1592365
| From | Jeff Layton <jlayton@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag |
| Date | 2017-03-04 02:00 +0100 |
| Message-ID | <th6dc-Gi-3@gated-at.bofh.it> (permalink) |
| References | <sQSyR-6ed-3@gated-at.bofh.it> <sQSyS-6ed-27@gated-at.bofh.it> <th5K9-wg-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, 2017-03-04 at 11:03 +1100, NeilBrown wrote:
> On Wed, Dec 21 2016, Jeff Layton wrote:
>
> > @@ -2072,7 +2093,12 @@ inode_cmp_iversion(const struct inode *inode, const u64 old)
> > static inline bool
> > inode_iversion_need_inc(struct inode *inode)
> > {
> > - return true;
> > + bool ret;
> > +
> > + spin_lock(&inode->i_lock);
> > + ret = inode->i_state & I_VERS_BUMP;
> > + spin_unlock(&inode->i_lock);
> > + return ret;
> > }
> >
>
> I know this code gets removed, so this isn't really important.
> By why do you take the spinlock here? What are you racing again?
>
> Thanks,
> NeilBrown
I think I was worried about I_VERS_BUMP being set or cleared during an
increment or query. It is quite possible that that spinlock is not
necessary.
--
Jeff Layton <jlayton@redhat.com>
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag NeilBrown <neil@brown.name> - 2017-03-04 01:30 +0100 Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag Jeff Layton <jlayton@redhat.com> - 2017-03-04 02:00 +0100
csiph-web