> 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
--
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
