public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
	Peter Hurley <peter@hurleysoftware.com>,
	Jiri Slaby <jslaby@suse.cz>,
	stable@vger.kernel.org
Subject: Re: [PATCH] tty: make sure a BUG is hit if tty_port will be destroyed before tty
Date: Fri, 17 May 2013 18:41:36 +0200	[thread overview]
Message-ID: <51965DC0.7030901@ahsoftware.de> (raw)
In-Reply-To: <20130517153136.GC19541@kroah.com>

Am 17.05.2013 17:31, schrieb Greg Kroah-Hartman:
> On Fri, May 17, 2013 at 09:12:08AM +0200, Alexander Holler wrote:
>> tty depends on tty_port until tty_release() was called. Make sure a BUG
>> will be hit, if tty_port will be destroyed before tty.
>
> So you want to ensure that we crash a machine?  No, please never add

Exactly. Let me quote myself:

 >> As described before, it ends up with memory corruption because freed
 >> memory is used, so if a BUG() happens, it doesn't help much. E.g. with
 >> kernel 3.9.2 I never have seen a bug, just a rebooting machine
 >> (sometimes minutes after the real bug happened).

> BUG() statements to the kernel, unless something _really_ bad is going
> to happen if we don't call it.  I never want to stop a machine from
> running, do you?

Yes. I'm not sure how you define _really_ bad, but a memory corruption 
with undefined result is exactly how I would define such.

And in the case of rfcomm, the box doesn't stop, at least not here. Just 
the process is killed together with an easy to identfiy oops. And the 
BUG_ON() prevents that memory will become corrupted and the machine is 
still usable afterwards. If that isn't a use case for BUG_ON(), I really 
don't know what else would be a use case for it.

> I can't take this as-is, why not just fix the root problem?

First I'm still not sure about the root problem and awaiting some 
response to my mail before that patch. As noted in the mail with the 
patch, 3.10-rc1 looks different, so the it might already be fixed there, 
even if rfcomm doesn't handle the tty as it (now in 3.8 and 3.9) should 
be (I haven't tested 3.10-rc1 up to now).

Second, if I would fix the bug in rfcomm, as Peter suggested, I still 
would not know if the same problem doesn't appear in any other user of 
ttys too, so even if I would fix rfcomm, I still would want that 
BUG_ON() to make sure I don't get a memory corruption whenever another 
similiar bug is hit.

Regards,

Alexander Holler


  reply	other threads:[~2013-05-17 16:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  6:45 BUG: tty: memory corruption through tty_release/tty_ldisc_release Alexander Holler
2013-05-16 13:15 ` Alexander Holler
2013-05-16 13:47 ` Peter Hurley
2013-05-16 13:59   ` Alexander Holler
2013-05-16 21:53     ` Peter Hurley
2013-05-17  4:43       ` Alexander Holler
2013-05-17  7:12         ` [PATCH] tty: make sure a BUG is hit if tty_port will be destroyed before tty Alexander Holler
2013-05-17 15:31           ` Greg Kroah-Hartman
2013-05-17 16:41             ` Alexander Holler [this message]
2013-05-17 18:06               ` Peter Hurley
2013-05-17 19:22                 ` Alexander Holler
2013-05-17 19:43                   ` Alexander Holler
2013-05-17 22:51                     ` Peter Hurley
2013-05-17 23:41                       ` Alexander Holler
2013-06-25 14:18         ` BUG: tty: memory corruption through tty_release/tty_ldisc_release Dean Jenkins
2013-06-26  7:23           ` Alexander Holler

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=51965DC0.7030901@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox