Re: [patch V2 6/7] fs/jbd2: Make state lock a spinlock

[Jan Kara]

On Thu 01-08-19 03:01:32, Thomas Gleixner wrote:
> Bit-spinlocks are problematic on PREEMPT_RT if functions which might sleep
> on RT, e.g. spin_lock(), alloc/free(), are invoked inside the lock held
> region because bit spinlocks disable preemption even on RT.
> 
> A first attempt was to replace state lock with a spinlock placed in struct
> buffer_head and make the locking conditional on PREEMPT_RT and
> DEBUG_BIT_SPINLOCKS.
> 
> Jan pointed out that there is a 4 byte hole in struct journal_head where a
> regular spinlock fits in and he would not object to convert the state lock
> to a spinlock unconditionally.
> 
> Aside of solving the RT problem, this also gains lockdep coverage for the
> journal head state lock (bit-spinlocks are not covered by lockdep as it's
> hard to fit a lockdep map into a single bit).
> 
> The trivial change would have been to convert the jbd_*lock_bh_state()
> inlines, but that comes with the downside that these functions take a
> buffer head pointer which needs to be converted to a journal head pointer
> which adds another level of indirection.
> 
> As almost all functions which use this lock have a journal head pointer
> readily available, it makes more sense to remove the lock helper inlines
> and write out spin_*lock() at all call sites.
> 
> Fixup all locking comments as well.
> 
> Suggested-by: Jan Kara <jack@xxxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: "Theodore Ts'o" <tytso@xxxxxxx>
> Cc: Mark Fasheh <mark@xxxxxxxxxx>
> Cc: Joseph Qi <joseph.qi@xxxxxxxxxxxxxxxxx>
> Cc: Joel Becker <jlbec@xxxxxxxxxxxx>
> Cc: Jan Kara <jack@xxxxxxxx>
> Cc: linux-ext4@xxxxxxxxxxxxxxx

Just a heads up that I didn't miss this patch. Just it has some bugs and I
figured that rather than explaining to you subtleties of jh lifetime it is
easier to fix up the problems myself since you're probably not keen on
becoming jbd2 developer ;)... which was more complex than I thought so I'm
not completely done yet. Hopefuly tomorrow.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR