All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: David Miller <davem@davemloft.net>, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: WARNING at tty_buffer.c:428 process_one_work()
Date: Tue, 05 Mar 2013 12:01:06 +0100	[thread overview]
Message-ID: <5135D072.8070101@suse.cz> (raw)
In-Reply-To: <20130301.170056.382924644594872197.davem@davemloft.net>

On 03/01/2013 11:00 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Fri, 01 Mar 2013 16:47:11 -0500 (EST)
> 
>>
>> I'm getting these non-stop right when the hypervisor console registers
>> on sparc64, and the machine won't boot up properly.  This is with
>> Linus's current tree.
> 
> As a quick addendum I'm looking at all of these tty_insert_flip_char()
> conversions and I'm extremely disappointed.
> 
> Let's just look at just two of the sparc drivers converted in commit
> 92a19f9cec9a80ad93c06e115822deb729e2c6ad, namely sunhv.c and sunsab.c.
> 
> The changes to the uart_handle_sysrq_char() call sites are handled
> completely differently in these two drivers, in nearly identical
> situations.  How can this be correct?
> 
> In the sunhv.c case the uart_handle_sysrq_char() call is preserved
> but the guarding test is changed from:
> 
> 	if (tty == NULL)
> 
> into
> 
> 	if (port->start == NULL)
> 
> Whereas in the sunsab.c case, the entire guarding test as well as
> the uart_handle_sysrq_char() invocation itself are both
> completly removed.
> 
> How in the world can that be right?
> 
> Either the receive_chars() method's invocations of
> uart_handle_sysrq_char() should be retained, or this sysrq processing
> is handled now elsewhere and in which case that should be documented
> clearly and in detail in the commit log message.

Ok, uart_handle_sysrq_char is still there, in both of them. But since we
do not care about the tty pointer in those routines any more, the tty ==
NULL test is removed along with its body. I didn't considered that so
critical to document that in the commit log. I thought it's obvious.

All those "if (port->state == NULL)"'s are mostly wrong. Look for
example to subsab's receive_chars and transmit_chars. One checks that,
one dereferences that immediately OTOH. Yes, serial_core should ensure
the interrupts are off by the time port->state is NULL (by calling
driver's ->shutdown). I will remove the test from receive_chars too
which will make the code cleaner.

I left that "if (port->start == NULL)" in sunhv in place because it
behaves completely differently. It checks port->start on all paths prior
dereferencing it. And it does not stop interrupts on ->shutdown.

thanks,
-- 
js
suse labs

  reply	other threads:[~2013-03-05 11:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 21:47 WARNING at tty_buffer.c:428 process_one_work() David Miller
2013-03-01 21:56 ` Greg KH
2013-03-01 22:10   ` David Miller
2013-03-02  4:49     ` Stephen Rothwell
2013-03-02  5:23       ` Al Viro
2013-03-02  6:35         ` David Miller
2013-03-01 22:00 ` David Miller
2013-03-05 11:01   ` Jiri Slaby [this message]
2013-03-05 19:39     ` David Miller
2013-03-05 19:44       ` Jiri Slaby
2013-03-05 20:03         ` David Miller
2013-03-05 20:27           ` Jiri Slaby
2013-03-05 20:33             ` David Miller
2013-03-05 20:34               ` David Miller
2013-03-05 21:43                 ` Jiri Slaby
2013-03-05 22:11                   ` Jiri Slaby
2013-03-05 20:47           ` Peter Hurley
2013-03-05 20:53             ` David Miller
2013-03-05 21:44               ` Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5135D072.8070101@suse.cz \
    --to=jslaby@suse.cz \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.