On Sun, Jul 19, 2020 at 6:51 PM Sergey Senozhatsky
<sergey.senozhatsky@xxxxxxxxx> wrote:
>
> Do I get it right, what you are saying is - when we process a PR_CONT
> message the cont buffer should already contain previous non-LOG_NEWLINE
> and non-PR_CONT message, otherwise it's a bug?
No.
I'm saying that the code that does PR_CONT should have done *some*
printing before, otherwise it's at the very least questionable.
IOW, you can't just randomly start printing with PR_CONT, without
having established _some_ context for it.
But that context could be a previous newline you created (the PR_CONT
will be a no-op). That's certainly useful for printing a header and
then after that printing possible other complex data that may or may
not have line breaks in it.
So your example looks fine. The context starts out with
pr_warn("which would create a new lock dependency:\n");
and after that you can use KERN_CONT / pr_cont() as much as you want,
since you've established a context for what you're printing.
And then it ends with 'pr_cont("\n")'.
So anything that was interrupted by this, and uses KERN_CONT /
pr_cont() will have no ambiguous issues. The code you pointed at both
started and ended a line.
That said, we have traditionally used not just "current process", but
also "last irq-level" as the context information, so I do think it
would be good to continue to do that.
At that point, "an interrupt printed something in the middle" isn't
even an issue any more, because it's clear that the context has
changed.
Linus
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
