Re: [PATCH] printk: Revert the buffered-printk() changes for now

[Kay Sievers]

On Mon, Jun 25, 2012 at 11:09 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> * Kay Sievers <kay@xxxxxxxx> wrote:

>> I just don't have a better idea than Joe or Steven.
>
> Then pick the fix you see as the best solution, post it and push
> the fix to Linus, don't just sit there passive-aggressively
> leaving a regression you introduced unresolved ...

Yeah, sometimes we can't have everything at the same time, and we
fixed serious reliability and integrity bugs for the cost of changing
the behaviour of: debug-printk + continuation line + crash the box. If
the box does not crash, the output does not change at all from before.

> I think Steve's fix would be OK as a workaround, if no-one can
> think of anything better.
>
> The thing is, this bug, despite being reported early on, has
> been left unresolved for weeks and it's -rc4 time now. Time is
> running out and frankly, I've been watching this thread, and the
> only reason you appear to be taking this bug somewhat seriously
> now is because Andrew and me complained. That is sad.

Steven said he would try something else on Monday, that's why I'm
waiting. I'm not happy with any of the current
optimize-continuation-lines-for-kernel-crashes patches, so I wanted to
see what he has in mind.

> Kernel policy is that kernel bugs introduced during the merge
> window are fixed by those who introduced them, or the changes
> get reverted. The kernel project uses a very user-friendly
> process to resolve regressions and in the worst case you as a
> developer have to suffer your changes reverted. Obviously timely
> fixes are preferred over invasive reverts.

That's true. this change is a trade, and the kernel self-tests
print-continuation-line-and-let-the-kernel-crash is currently affected
by the hugely improved integrity and reliability of all the "normal"
users.

> It is not *Steve's* job to fix this bug. That he actually posted
> a fix is nice from him, it makes your life easier (and you can
> still write some other fix) but *you* should be driving the
> resolution here, not Steve, me or Andrew.

Let's see what other idea Steven has, he wrote "But I have an idea for
a fix. I'll work on it on Monday, and it wont require adding a
pr_flush() like I did in this patch set." before pointing fingers here
please.

If we find a way to solve that cleanly, I'm all for it. But honestly,
just letting these very special-case users print fully terminated
lines instead of continuation lines seems like an option to me too. We
really should not optimize for cosmetics (full lines work reliably,
they are not buffered) of self-tests, for the price of the reliability
and integrity of all other users.

The self-test users would need to be changed anyway to use "flush",
why don't we just print a full line,  omit the "PASSED" in case all
went well, and only print in case of an error? I really do not see the
need for continuation lines for the crash-sensitive self-tests; people
will find out (without PASSED on the same line), that we passed the
test when the box is still alive.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/