• Ahmed S. Darwish's avatar
    seqlock: Extend seqcount API with associated locks · 55f3560d
    Ahmed S. Darwish authored
    A sequence counter write side critical section must be protected by some
    form of locking to serialize writers. If the serialization primitive is
    not disabling preemption implicitly, preemption has to be explicitly
    disabled before entering the write side critical section.
    
    There is no built-in debugging mechanism to verify that the lock used
    for writer serialization is held and preemption is disabled. Some usage
    sites like dma-buf have explicit lockdep checks for the writer-side
    lock, but this covers only a small portion of the sequence counter usage
    in the kernel.
    
    Add new sequence counter types which allows to associate a lock to the
    sequence counter at initialization time. The seqcount API functions are
    extended to provide appropriate lockdep assertions depending on the
    seqcount/lock type.
    
    For sequence counters with associated locks that do not implicitly
    disable preemption, preemption protection is enforced in the sequence
    counter write side functions. This removes the need to explicitly add
    preempt_disable/enable() around the write side critical sections: the
    write_begin/end() functions for these new sequence counter types
    automatically do this.
    
    Introduce the following seqcount types with associated locks:
    
         seqcount_spinlock_t
         seqcount_raw_spinlock_t
         seqcount_rwlock_t
         seqcount_mutex_t
         seqcount_ww_mutex_t
    
    Extend the seqcount read and write functions to branch out to the
    specific seqcount_LOCKTYPE_t implementation at compile-time. This avoids
    kernel API explosion per each new seqcount_LOCKTYPE_t added. Add such
    compile-time type detection logic into a new, internal, seqlock header.
    
    Document the proper seqcount_LOCKTYPE_t usage, and rationale, at
    Documentation/locking/seqlock.rst.
    
    If lockdep is disabled, this lock association is compiled out and has
    neither storage size nor runtime overhead.
    Signed-off-by: default avatarAhmed S. Darwish <a.darwish@linutronix.de>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20200720155530.1173732-10-a.darwish@linutronix.de
    55f3560d
seqlock.rst 6.94 KB