On Thu, Jan 28, 2016 at 03:08:19PM -0800, Peter Hurley wrote: > The problem is you have postulated a very shallow recursion. > This looks much worse if this happens 1000 times, and > probably won't recover to output anything. > > Additionally, what if the console_sem is simply corrupted? > A livelock with no output ever is not very helpful. > > As I wrote earlier, I don't think this is the way to fix > recursion problems with printk() [by eliding output].
I think you are currently misunderstading about this patch. Or I'm misunderstanding you.. The patch was changed in v4 so that it can print a debug message even in the recursive cycle case, at the first time. I also thought printing nothing in the case was not helpful at all which I did in v1,2,3. But it's changed in v4, that is, this patch. thanks, byungchul > > Rather, a way to effectively determine a recursion is in progress, > and _at a minimum_ guaranteeing that the recursive output will > eventually be output should be the goal. > > Including dumb recursion like a console driver printing > an error :/ > > Then, lockdep could remain enabled while calling console drivers. > > Regards, > Peter Hurley > > > sem->count-- > > spin_unlock() << unlock, return > > arch_spin_lock() << got the lock, return > > sem->count-- > > spin_unlock() << unlock, return > > arch_spin_lock() << got the lock, return > > sem->count-- > > spin_unlock() << unlock, return > > > > > > ...um > > > > > >> But I found there's a possiblity in the debug code *itself* to cause a > >> lockup. > > > > please explain. > > > > -ss > >
