Messages in this thread | | | Date | Thu, 1 Aug 2019 19:57:03 +0200 | From | Jan Kara <> | Subject | Re: [patch V2 6/7] fs/jbd2: Make state lock a spinlock |
| |
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@suse.com> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: "Theodore Ts'o" <tytso@mit.edu> > Cc: Mark Fasheh <mark@fasheh.com> > Cc: Joseph Qi <joseph.qi@linux.alibaba.com> > Cc: Joel Becker <jlbec@evilplan.org> > Cc: Jan Kara <jack@suse.com> > Cc: linux-ext4@vger.kernel.org
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@suse.com> SUSE Labs, CR
| |