[dm-devel] dm-integrity: revert adc0daad366b to fix recalculation

Mikulas Patocka mpatocka at redhat.com
Wed Jul 22 20:02:04 UTC 2020



On Wed, 22 Jul 2020, Mike Snitzer wrote:

> On Wed, Jul 22 2020 at  2:46pm -0400,
> Mikulas Patocka <mpatocka at redhat.com> wrote:
> 
> > Hi Mike
> > 
> > Please submit this to Linus and to RHEL-8.
> > 
> > Mikulas
> > 
> > 
> > 
> > From: Mikulas Patocka <mpatocka at redhat.com>
> > 
> > The patch adc0daad366b62ca1bce3e2958a40b0b71a8b8b3 broke recalculation on
> > dm-integrity. The patch replaces a private variable "suspending" with a
> > call to "dm_suspended".
> > 
> > The problem is that dm_suspended returns true not only during suspend, but
> > also during resume. This race condition could occur:
> > 1. dm_integrity_resume calls queue_work(ic->recalc_wq, &ic->recalc_work)
> > 2. integrity_recalc (&ic->recalc_work) preempts the current thread
> > 3. integrity_recalc calls if (unlikely(dm_suspended(ic->ti))) goto unlock_ret;
> > 4. integrity_recalc exits and no recalculating is done.
> > 
> > In order to fix this race condition, we stop using dm_suspended and start
> > using the variable "suspending" (that is only set during suspend, not
> > during resume).
> > 
> > Signed-off-by: Mikulas Patocka <mpatocka at redhat.com>
> > Fixes: adc0daad366b ("dm: report suspended device during destroy")
> > Cc: stable at vger.kernel.org	# v4.18+
> 
> OK, but why not add a dm_suspending() to DM core?  Could be other
> future targets would like this same info right?  I don't see harm in
> elevating it.
> 
> Mike

Yes - it may be possible to add this.

Mikulas




More information about the dm-devel mailing list