On Wed, May 20, 2020, Christian KÃnig wrote:
Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish:In this patch series, each extra "seqcount with associated lock" data
A sequence counter write side critical section must be protected by someMhm, is the dma_resv object the only user of this new seqcount_ww_mutex
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.
The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.
Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.
Use the newly-added seqcount_ww_mutex_t instead:
- It associates the ww_mutex with the sequence count, which enables
lockdep to validate that the write side critical section is properly
serialized.
- It removes the need to explicitly add preempt_disable/enable()
around the write side critical section because the write_begin/end()
functions for this new data type automatically do this.
If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.
variant ?
If yes we are trying to get rid of this sequence counter for quite some
time, so I would rather invest the additional time to finish this.
type costs us, exactly:
- 1 typedef definition, seqcount_ww_mutex_t
- 1 static initializer, SEQCNT_WW_MUTEX_ZERO()
- 1 runtime initializer, seqcount_ww_mutex_init()
Definitions for the typedef and the 2 initializers above are
template-code one liners.
The logic which automatically disables preemption upon entering a
seqcount_ww_mutex_t write side critical section is also already shared
with seqcount_mutex_t and any future, preemptible, associated lock.
So, yes, dma-resv is the only user of seqcount_ww_mutex.
But even in that case, given the one liner template code nature of
seqcount_ww_mutex_t logic, it does not make sense to block the dma_resv
and amdgpu change until at some point in the future the sequence counter
is completely removed.
**If and when** the sequence counter gets removed, please just remove
the seqcount_ww_mutex_t data type with it. It will be extremely simple.
Regards,Thanks,
Christian.
--
Ahmed S. Darwish
Linutronix GmbH