From: Dave Chinner <david@fromorbit.com>
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>,
"peterz@infradead.org" <peterz@infradead.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 1/7] fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to refcount_t
Date: Thu, 23 Feb 2017 09:07:41 +1100 [thread overview]
Message-ID: <20170222220741.GC23007@dastard> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C4EB40@IRSMSX102.ger.corp.intel.com>
On Wed, Feb 22, 2017 at 11:20:31AM +0000, Reshetova, Elena wrote:
> > On Tue, Feb 21, 2017 at 05:49:01PM +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.
> >
> > I'm missing something: how do you overflow a log item object
> > reference count?
>
> We are currently converting all reference counters present in kernel to a safer refcount_t type.
Yes, I see that you are taking anything that you *think* is an
object lifetime reference counter and changing it.
> Agreed, in some cases it might be easier or harder to actually create/trigger an overflow, but since it can be caused even by a bug in the legitimate code (current version or its future iterative), it is good idea to do "safe defaults" and stop worrying about the problem.
>
> Do you have any reasons why it should not be converted?
It's core dirty metadata object code. Any change to code in this
area needs to be gone over with a fine tooth comb, because bugs can
result in filesystem and/or journal corruption issues that may not
be noticed until a system crashes and log recovery fails and the
user loses their entire filesystem....
Hence the repeated comments about needing to actually test the code
you are changing.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-02-22 22:08 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 [this message]
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
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=20170222220741.GC23007@dastard \
--to=david@fromorbit.com \
--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 \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).