Date:	Mon, 25 Jun 2012 09:42:37 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Kay Sievers <kay@...y.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] printk: Revert the buffered-printk() changes for now

On Mon, 2012-06-25 at 12:06 +0200, Kay Sievers wrote:
> On Mon, Jun 25, 2012 at 11:09 AM, Ingo Molnar <mingo@...nel.org> wrote:
> > * Kay Sievers <kay@...y.org> 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.

But if the box crashes, then we get lies about where it crashed. That's
an important part.

> 
> > 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.

I just posted it. You may not like it either, but it removes the needed
printk_flush(), and doesn't touch any of your 'facility' work. Besides
adding its own 0x1ffc tag.


> 
> > 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.

I'm hoping that my last patch can satisfy both 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.

It's out, please continue to point ;-)

> 
> 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 thing is, you made a fundamental change to the way printk() has
worked from day one. This will give lots of developers a "surprise",
that will last for a long time.

> 
> 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.

Well, it was a way my scripts would check if the test passed or not.

-- Steve


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

Powered by blists - more mailing lists