Hi Jerry,

The attached patch fixes this by using the TRYLOCK to see if the UNIT is already in use before proceeding with the I/O.  Regression tested on x86_64-linux-gnu.

The idea triggered by Thomas in the PR.

OK for mainline?

Hmm... thinking about the logic, I think that

  if (TRYLOCK(&p->lock))
    {
      if (p->child_dtio == 0)
        {
          generate_error (&dtp->common, LIBERROR_RECURSIVE_IO, NULL);
          return;
        }
      UNLOCK(&p->lock);
    }

might be better, otherwise we would unlock a lock that we did
not acquire.

What do you think?

Best regards

        Thomas

Reply via email to