[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