Re: gcc-3.2 breaks rmap on s390x

[Ulrich Weigand]

Hugh Dickins wrote:

>Isn't it rather odd that it should fix the problem you describe?
>because the barrier you're adding comes only in the exceptional path,
>when the lock was found already held.  I suppose the compiler is free
>to make the barrier more general than you've asked for, but it seems
>unsafe to rely on that.

No, it's the other way around:  the compiler is free to ignore the
barrier only if can prove the path containing it is not taken
(which it cannot in this case as the outer while depends on a volatile
test_and_set_bit operation).

However, this code still contains a (theoretical) problem:

>       while (test_and_set_bit(PG_chainlock, &page->flags)) {
> -             while (test_bit(PG_chainlock, &page->flags))
> +             while (test_bit(PG_chainlock, &page->flags)) {
>                       cpu_relax();
> +                     barrier();
> +             }

nothing in the inner loop contains a (hardware) memory barrier
('serialization' in s390-speak), so nothing forces the processor
to ever refresh its cached value of page->flags from memory.

On s390, the architecture definition would allow a processor
to loop endlessly (that is, until the next interrupt, which
serves as serialization operation).  However, none of the currently
existing processors do that, so the problem is only theoretical ...

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: [phone]   ---   Email: [e-mail]