Re: [PATCH] Avoid RMW of flags2 outside lock (BZ #27842)

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Adhemerval,

> I am trying to see why exactly we need to disable single-thread optimization
> on flockfile, since there is no FILE operation that takes a callback where
> pthread_create might be called beween _IO_acquire_lock.  Can't we just remove
> the _IO_FLAGS2_NEED_LOCK set on flockfile?

Yes we could. I don't believe you could actually notice the difference - recursion
or starting a thread before funlockfile would work fine.

>> Right so you mean moving NEED_LOCK bit into the lock variable?
>
> Yes, and making the lock smaller on linux (just a word plus the recursive counter).

OK, it will be interesting to see how that works out. Any lock speedup will be
good, however I guess that recursive locks will remain quite expensive. By design
the single-thread optimization does not need to support things like trylock,
recursion or starting a new thread, and that is a huge advantage.

> You mean as it is now? It is a real bug since various functions update flags2
> behind a lock, so it is possible for this RMW to cause corruption (but only if
> you are already multithreaded, which the update is pointless anyway and we
> can just skip it).

> I don't think it would be possible to corrupt because once pthread_create
> is called, _IO_FLAGS2_NEED_LOCK will be always set (so RMW won't see a
> __flags2 without _IO_FLAGS2_NEED_LOCK being set).

The issue is not corruption of _IO_FLAGS2_NEED_LOCK but of a different flag.
Several IO functions may set or clear bits in flag2. So we could get a race
between RMW sequences setting/clearing different bits - if there is any overlap
one of the updates may be lost.

Cheers,
Wilco