Messages in this thread | | | From | "byungchul.park" <> | Subject | RE: [RFC][PATCH v4 1/2] printk: Make printk() completely async | Date | Fri, 18 Mar 2016 17:23:38 +0900 |
| |
> [..] > > diff --git a/kernel/locking/spinlock_debug.c > b/kernel/locking/spinlock_debug.c > > index fd24588..30559c6 100644 > > --- a/kernel/locking/spinlock_debug.c > > +++ b/kernel/locking/spinlock_debug.c > > @@ -138,14 +138,25 @@ static void __spin_lock_debug(raw_spinlock_t *lock) > > { > > u64 i; > > u64 loops = loops_per_jiffy * HZ; > > + static raw_spinlock_t *suspected_lock = NULL; > > this has no chances to survive on SMP systems that have spin_lockup-ed on > at > least two different spin locks.
I don't think so. It can have chances to survive on SMP with 2 different locks. Remind the condition this problem can happen.
1. when it is "lockup suspected". 2. when it is within a printk().
2 different locks mean 2 different timing. Therefore it's important to prevent a recursion at a place trying to obtain the lock. After a lock is solved, the other lock can be solved step by step.
> I'd really prefer not to mix-in spin_dump/printk recursion problems into > this
I didn't mix-in it into this. I only focused your patch. Your approach introduces unnecessary losing a message which we don't want. But you worried about "infinite recursion" when implementing it without losing the message. That's why I am saying it doesn't need to be worried and there's another way, that is, my suggestion.
> patch set. it makes sense not to make printk recursion detection worse due > to
It makes more sense not to introduce newly added spin_locks. You are currently utilize the last resort for detecting recursion. It's too bad. Don't you think so?
> newly added spin_locks to vprintk_emit(), but that's it. this patch set > set is > fixing other things in the first place.
As I said, this patch's trying to fix a problem in your patch, which is introduced while discussing yours.
Thanks, Byungchul
| |