RE: [PATCH 4/5] fs, xfs: convert xfs_cui_log_item.cui_refcount from atomic_t to refcount_t

[Reshetova, Elena]

 > Signed-off-by: Elena Reshetova <elena.reshetova@xxxxxxxxx>
> > Signed-off-by: Hans Liljestrand <ishkamiel@xxxxxxxxx>
> > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
> > Signed-off-by: David Windsor <dwindsor@xxxxxxxxx>
> > ---
> >  fs/xfs/xfs_refcount_item.c | 4 ++--
> >  fs/xfs/xfs_refcount_item.h | 4 +++-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c
> > index 6e4c744..61bc570 100644
> > --- a/fs/xfs/xfs_refcount_item.c
> > +++ b/fs/xfs/xfs_refcount_item.c
> > @@ -205,7 +205,7 @@ xfs_cui_init(
> >  	cuip->cui_format.cui_nextents = nextents;
> >  	cuip->cui_format.cui_id = (uintptr_t)(void *)cuip;
> >  	atomic_set(&cuip->cui_next_extent, 0);
> > -	atomic_set(&cuip->cui_refcount, 2);
> > +	refcount_set(&cuip->cui_refcount, 2);
> 
> I'm assuming the refcount design is ok with the log item refcounts
> starting at 2 and marching down to zero?  The code seems to be
> fine with it; I just want to make sure everyone's ok with supporting
> this use case.

Yes, as soon as it doesn't go beyond 0 or starting to increment again after reaching zero. 

> 
> >  	return cuip;
> >  }
> > @@ -221,7 +221,7 @@ void
> >  xfs_cui_release(
> >  	struct xfs_cui_log_item	*cuip)
> >  {
> > -	if (atomic_dec_and_test(&cuip->cui_refcount)) {
> > +	if (refcount_dec_and_test(&cuip->cui_refcount)) {
> 
> I suppose it's useful to have refcount_dec_and_test complain loudly if
> we ever have a dangling pointer... Friday I was chasing a possible
> use-after-free of the EFI items in generic/388.

Currently it complains with WARN if it finds itself decrementing from zero. 
There is patch in RFC stage also that would make it configurable: complain with WARN or complain/abort with BUG. 

> 
> >  		xfs_trans_ail_remove(&cuip->cui_item,
> SHUTDOWN_LOG_IO_ERROR);
> >  		xfs_cui_item_free(cuip);
> >  	}
> > diff --git a/fs/xfs/xfs_refcount_item.h b/fs/xfs/xfs_refcount_item.h
> > index 5b74ddd..7f23ff8 100644
> > --- a/fs/xfs/xfs_refcount_item.h
> > +++ b/fs/xfs/xfs_refcount_item.h
> > @@ -20,6 +20,8 @@
> >  #ifndef	__XFS_REFCOUNT_ITEM_H__
> >  #define	__XFS_REFCOUNT_ITEM_H__
> >
> > +#include <linux/refcount.h>
> 
> I still think this include should go in xfs_linux.h, the same as most of
> the other linux/*.h includes in XFS.

Oh, very sorry, I forgot this one. Got too much focused on testing :(
Do you want me to resend with this change or can you take it in and do this small fix yourself? 

Best Regards,
Elena.


> 
> --D
> 
> > +
> >  /*
> >   * There are (currently) two pairs of refcount btree redo item types:
> >   * increase and decrease.  The log items for these are CUI (refcount
> > @@ -63,7 +65,7 @@ struct kmem_zone;
> >   */
> >  struct xfs_cui_log_item {
> >  	struct xfs_log_item		cui_item;
> > -	atomic_t			cui_refcount;
> > +	refcount_t			cui_refcount;
> >  	atomic_t			cui_next_extent;
> >  	unsigned long			cui_flags;	/* misc
> flags */
> >  	struct xfs_cui_log_format	cui_format;
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html