From: Peter Zijlstra <peterz@infradead.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"darrick.wong@oracle.com" <darrick.wong@oracle.com>,
Hans Liljestrand <ishkamiel@gmail.com>,
Kees Cook <keescook@chromium.org>,
David Windsor <dwindsor@gmail.com>
Subject: Re: [PATCH 3/7] fs, xfs: convert xfs_buf_log_item.bli_refcount from atomic_t to refcount_t
Date: Tue, 21 Feb 2017 17:27:58 +0100 [thread overview]
Message-ID: <20170221162758.GK6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C4E32A@IRSMSX102.ger.corp.intel.com>
On Tue, Feb 21, 2017 at 04:06:30PM +0000, Reshetova, Elena wrote:
> > On Tue, Feb 21, 2017 at 05:49:03PM +0200, Elena Reshetova wrote:
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> >
> > Changelog forgets to mention if this was runtime tested..
>
> It was boot-tested in the whole refcount_t changes pile, which is not very useful for fs anyway.
> What's why we are sending this through maintainers to get through their tests.
> I am sure that testing would be better than what we can do.
For FS changes, I would recommend at the very least running xfstests on
an instance (which unlike the name suggests is good for most block
filesystems Linux has).
> > > @@ -432,7 +432,7 @@ xfs_trans_brelse(xfs_trans_t *tp,
> > > /***
> > > ASSERT(bp->b_pincount == 0);
> > > ***/
> > > - ASSERT(atomic_read(&bip->bli_refcount) == 0);
> > > + ASSERT(refcount_read(&bip->bli_refcount) == 0);
> > > ASSERT(!(bip->bli_item.li_flags & XFS_LI_IN_AIL));
> > > ASSERT(!(bip->bli_flags & XFS_BLI_INODE_ALLOC_BUF));
> > > xfs_buf_item_relse(bp);
> >
> >
> > This for example looks dodgy.
> >
> > That seems to suggest the atomic_dec() there can actually hit 0, which
> > _will_ generate a WARN.
>
> True, but in some of this cases WARN might be ok, I think? As soon as
> functionality is not changed and object is not reused (by doing
> refcount_inc on it) anywhere later on.
No, your conversion should not generate spurious WARN()s.
And also no, atomic_dec() must not hit 0. If you've been _that_ careful
with your reference counting and you absolutely _know_ this is the very
last one, write something like:
WARN_ON(!refcount_dec_if_one());
Please, stop sending out conversions that haven't been tested. And take
the time to actually look at your own patches. If I can spot fail just
looking through them, so can you (or any of the other many people in
your SoB chain).
Take a little more time and a little extra care.
next prev parent reply other threads:[~2017-02-21 16:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 15:49 [PATCH 0/7] fs, xfs subsystem refcounter conversions Elena Reshetova
2017-02-21 15:49 ` [PATCH 1/7] fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to refcount_t Elena Reshetova
2017-02-21 16:36 ` Darrick J. Wong
2017-02-22 11:17 ` Reshetova, Elena
2017-02-21 22:55 ` Dave Chinner
2017-02-22 11:20 ` Reshetova, Elena
2017-02-22 22:07 ` Dave Chinner
2017-02-23 7:50 ` Reshetova, Elena
2017-02-21 15:49 ` [PATCH 2/7] fs, xfs: convert xfs_buf.b_hold and xfs_buf.b_lru_ref " Elena Reshetova
2017-02-21 16:04 ` Peter Zijlstra
2017-02-21 22:54 ` Dave Chinner
2017-02-22 11:15 ` Reshetova, Elena
2017-02-21 15:49 ` [PATCH 3/7] fs, xfs: convert xfs_buf_log_item.bli_refcount " Elena Reshetova
2017-02-21 15:59 ` Peter Zijlstra
2017-02-21 16:06 ` Reshetova, Elena
2017-02-21 16:27 ` Peter Zijlstra [this message]
2017-02-21 16:32 ` Peter Zijlstra
2017-02-21 17:06 ` Darrick J. Wong
2017-02-21 19:25 ` Brian Foster
2017-02-22 11:26 ` Reshetova, Elena
2017-02-21 15:49 ` [PATCH 4/7] fs, xfs: convert xfs_efi_log_item.efi_refcount " Elena Reshetova
2017-02-21 15:49 ` [PATCH 5/7] fs, xfs: convert xlog_ticket.t_ref " Elena Reshetova
2017-02-21 15:49 ` [PATCH 6/7] fs, xfs: convert xfs_cui_log_item.cui_refcount " Elena Reshetova
2017-02-21 15:49 ` [PATCH 7/7] fs, xfs: convert xfs_rui_log_item.rui_refcount " Elena Reshetova
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=20170221162758.GK6515@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=darrick.wong@oracle.com \
--cc=dwindsor@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ishkamiel@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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