[Ksummit-discuss] [TECH TOPIC] asynchronous printk

[James Bottomley]

On Tue, 2016-07-19 at 23:55 +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (07/19/16 07:45), James Bottomley wrote:
> > On Tue, 2016-07-19 at 12:47 +0900, Sergey Senozhatsky wrote:
> > > Hello,
> > > 
> > > Wondering if anyone will be interested in printk-related topics
> > > (or we can handle it in the mailing list).
> > > 
> > > What I have on my list is:
> > 
> > Are there any bug reports for these cases?  If there are, I'd use 
> > the bug report as an opportunity to fix on the relevant list and if
> > there aren't, I'd say that the problem is then largely theoretical 
> > and there's not much point solving it until it becomes a real
> > problem.
> 
> yes, there are reports. for instance,
> http://marc.info/?l=linux-kernel&m=146823278316663

That's about backporting a fix from upstream to 3.12 to fix the
particular issue, so it seems to be solved for the reporter as far as
it goes.

> I do have same problems with pintk (lockups, stalls, etc.)
> and even more.

OK, but given that the bugs are fixed as they're reported, the only
issue seems to be that some people think the fix is incomplete and
Andrew is sitting on it because he's unsure if the patches actually
solve the problem (or even if we have a problem).

The only comments from him I can find are in Jan's series:

http://thread.gmane.org/gmane.linux.kernel/1619692

The concern seems to be "prink is fragile you look to be making it
differently fragile, how is that of benefit".

So the problem is there's no overriding need driving this and it's
blocked by "vague concerns" about fragility.  Is there a process
problem that there's no effective way to move these patches forward
without finding an overriding need or addressing the concerns?

> > For instance on the KERN_CONT we've been debating the problems of 
> > pre-empt and continuation lines for years but no-ones cared enough 
> > to fix it.  This means either the problem isn't seen often enough 
> > in the field or that when it is seen there hasn't been much difficu
> > lty disentangling the log.  For the former, there's no need to fix 
> > something that isn't seen in practice and for the latter, if no-one 
> > cares enough then it's not a big enough problem to fix.
> 
> well, I agree that it doesn't make it impossible to read the logs.
> how often does it happen... on my laptop sometimes KERN_CONT lines
> are not always really continuous. so I observe it, in some sense.

OK, so it's unsightly but not necessarily a problem for reading the
logs.  Again, this means we have no overriding need to fix it.

James