All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	Ingo Molnar <mingo@redhat.com>,
	linux-mm@kvack.org, linux-raid@vger.kernel.org,
	Anna-Maria Gleixner <anna-maria@linutronix.de>
Subject: Re: [PATCH 3/8] md: raid5: use refcount_t for reference counting instead atomic_t
Date: Wed, 23 May 2018 12:22:39 -0700	[thread overview]
Message-ID: <20180523192239.GA59657@kernel.org> (raw)
In-Reply-To: <20180523174904.GY12198@hirez.programming.kicks-ass.net>

On Wed, May 23, 2018 at 07:49:04PM +0200, Peter Zijlstra wrote:
> On Wed, May 23, 2018 at 06:21:19AM -0700, Matthew Wilcox wrote:
> > On Wed, May 09, 2018 at 09:36:40PM +0200, Sebastian Andrzej Siewior 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.
> > > 
> > > Most changes are 1:1 replacements except for
> > > 	BUG_ON(atomic_inc_return(&sh->count) != 1);
> > > 
> > > which has been turned into
> > >         refcount_inc(&sh->count);
> > >         BUG_ON(refcount_read(&sh->count) != 1);
> > 
> > @@ -5387,7 +5387,8 @@ static struct stripe_head *__get_priority_stripe(struct
> > +r5conf *conf, int group)
> >                 sh->group = NULL;
> >         }
> >         list_del_init(&sh->lru);
> > -       BUG_ON(atomic_inc_return(&sh->count) != 1);
> > +       refcount_inc(&sh->count);
> > +	BUG_ON(refcount_read(&sh->count) != 1);
> >         return sh;
> >  }
> > 
> > 
> > That's the only problematic usage.  And I think what it's really saying is:
> > 
> > 	BUG_ON(refcount_read(&sh->count) != 0);
> > 	refcount_set(&sh->count, 1);
> > 
> > With that, this looks like a reasonable use of refcount_t to me.
> 
> I'm not so sure, look at:
> 
>   r5c_do_reclaim():
> 
> 	if (!list_empty(&sh->lru) &&
> 	    !test_bit(STRIPE_HANDLE, &sh->state) &&
> 	    atomic_read(&sh->count) == 0) {
> 	      r5c_flush_stripe(cond, sh)
> 
> Which does:
> 
>   r5c_flush_stripe():
> 
> 	atomic_inc(&sh->count);
> 
> Which is another inc-from-zero. Also, having sh's with count==0 in a
> list is counter to the concept of refcounts and smells like usage-counts
> to me. For refcount 0 really means deads and gone.
> 
> If this really is supposed to be a refcount, someone more familiar with
> the raid5 should do the patch and write a comprehensive changelog on it.

I don't know what is changed in the refcount, such raid5 change has attempted
before and didn't work. 0 for the stripe count is a valid usage and we do
inc-from-zero in several places.

Thanks,
Shaohua

  reply	other threads:[~2018-05-23 19:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 19:36 [PATCH v2 0/8] Introduce refcount_dec_and_lock_irqsave() Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 1/8] bdi: use refcount_t for reference counting instead atomic_t Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 2/8] userns: " Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 3/8] md: raid5: " Sebastian Andrzej Siewior
2018-05-23 12:36   ` Peter Zijlstra
2018-05-23 12:50     ` Sebastian Andrzej Siewior
2018-05-23 12:55       ` Peter Zijlstra
2018-05-23 13:21   ` Matthew Wilcox
2018-05-23 17:49     ` Peter Zijlstra
2018-05-23 19:22       ` Shaohua Li [this message]
2018-05-24  7:14         ` Peter Zijlstra
2018-05-09 19:36 ` [PATCH 4/8] locking/refcount: implement refcount_dec_and_lock_irqsave() Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 5/8] bdi: Use irqsave variant of refcount_dec_and_lock() Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 6/8] userns: " Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 7/8] md: raid5: " Sebastian Andrzej Siewior
2018-05-09 19:36 ` [PATCH 8/8] md: raid5: Do not disable irq on release_inactive_stripe_list() call Sebastian Andrzej Siewior
2018-05-23 13:01 ` [PATCH v2 0/8] Introduce refcount_dec_and_lock_irqsave() Peter Zijlstra
2018-05-23 13:09   ` Sebastian Andrzej Siewior

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=20180523192239.GA59657@kernel.org \
    --to=shli@kernel.org \
    --cc=anna-maria@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=willy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.