Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> writes: > On Tue, Apr 14, 2020 at 12:50:49PM +0300, Sergey Organov wrote: >> Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx>: >> > Correct, and what I said back then still applies - and more. >> >> What bothers me is "we have no real option..." part of this, as it's rarely >> happens to be the case. > > I don't see you coming forward with a solution beyond "let's revert > the commit" or "let's comment out the lock" - neither of which are > an option for mainline kernels. I didn't suggest to revert the commit, as it obviously solves real problem. I asked if and why the lock is needed on non-SMP targets, but either I didn't get a reply or missed it, sorry. I mean everything I said was to get some help rather than to spread useless critics or even insults. > > Until *you* do, since you obviously have better ideas, "we have no > real option". I'm in the process of making myself familiar with the internals of printk machinery to find generic solution, but if nobody else actually cares, I'll stop bothering you guys with my questions. Do I get it right that you still think there are no sensible options but to disable interrupts for ages? If so, it would greatly reduce my drive to find one... or maybe the other way round, but it'd be nice to know either way. > But, as I've said, one of the *important* characteristics of serial > console is that it is synchronous with the kernel, so it can be > relied upon to get complete messages out if the kernel crashes after > a printk() has been executed, and that must not be lost. Do I get it right that it's covered by the 'oops' case, or are there hidden pitfalls as well? Thanks, -- Sergey
