All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Greg KH <greg@kroah.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@mail.by>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: proper tty-ldisc refcounting (was Re: WARNING at: drivers/char/tty_ldisc.c)
Date: Tue, 4 Aug 2009 08:40:20 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0908040825210.3270@localhost.localdomain> (raw)
In-Reply-To: <20090804072351.GA17474@kroah.com>



On Tue, 4 Aug 2009, Greg KH wrote:
> 
> Ok, but due to the lateness of the release cycle, is it worth it to add
> those 3 right now?  Or do we just take the BUG_ON() out as it's pretty
> harmless while shutting down in single user mode?
> 
> What do you think?

If the WARN_ON() happens, it's not just that we have a refcount being off, 
we'll also have memory corruption and a potential oops a bit later. 

Why? Simply because somebody will be touching that 'struct ldisc', even if 
it will be just a decrement of the word that contained the refcount. So we 
have a pretty much guaranteed use-after-free scenario.

So taking out the WARN_ON() is the wrong thing. In that case it would 
probably be better to just leave the WARN_ON(), and at least know "ok, bad 
things happened". 

So I think we have a few options:

 - leave things as-is, leave the WARN_ON(), and know that it's very rare, 
   but that bad things can happen when it triggers.

   The thing I really dislike about this one is that yes, it's rare, but 
   I could see it be user-triggerable. Users do have access to 
   /dev/console when they are logged in at the console.

 - Change the old code from

	WARN_ON(ld->refcount);
	kfree(ld);

   to

	if (!WARN_ON_ONCE(ld->refcount))
		kfree(ld);

   which at least doesn't free the ldisc if it is in use. So now you have 
   a memory leak, but at least hopefully no actual corruption and 
   use-after-free. It's still a bug, but it won't be causing other bugs 
   down the line (except for running out of memory if you can trigger it 
   really easily, but that's unlikely, and I think preferable to unknown 
   problems - even if the unknown problems are very unlikely)

 - Take the three patches now.

I suspect we should take the three now. All of the issues are due to 
totally rewritten code since 2.6.30 - I suspect the risk from new bugs 
from that refcounting series is _smaller_ that the risk of bugs from the 
original ldisc rewrite (commit c65c9bc3e), and if there are bugs, I 
suspect the three patches are more likely to help than to hurt.

			Linus

  parent reply	other threads:[~2009-08-04 15:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-02 12:01 WARNING at: drivers/char/tty_ldisc.c Sergey Senozhatsky
2009-08-02 16:05 ` Greg KH
2009-08-02 17:01   ` Sergey Senozhatsky
2009-08-02 17:07   ` Sergey Senozhatsky
2009-08-02 17:16 ` Linus Torvalds
2009-08-02 19:05   ` Sergey Senozhatsky
2009-08-02 20:20     ` Linus Torvalds
2009-08-02 21:17       ` OGAWA Hirofumi
2009-08-02 21:33         ` Linus Torvalds
2009-08-02 22:46           ` Sergey Senozhatsky
2009-08-02 22:48           ` Alan Cox
2009-08-03  0:40             ` Linus Torvalds
2009-08-03  1:44               ` Linus Torvalds
2009-08-03  9:37               ` Alan Cox
2009-08-03 16:26                 ` OGAWA Hirofumi
2009-08-03 16:59                   ` Alan Cox
2009-08-03 17:55               ` [PATCH 0/2] proper tty-ldisc refcounting (was Re: WARNING at: drivers/char/tty_ldisc.c) Linus Torvalds
2009-08-03 17:58                 ` [PATCH 1/2] tty-ldisc: make refcount be atomic_t 'users' count Linus Torvalds
2009-08-03 18:11                   ` [PATCH 2/2] tty-ldisc: turn ldisc user count into a proper refcount Linus Torvalds
2009-08-03 18:39                     ` Alan Cox
2009-08-03 20:00                     ` OGAWA Hirofumi
2009-08-03 18:18                 ` [PATCH 0/2] proper tty-ldisc refcounting (was Re: WARNING at: drivers/char/tty_ldisc.c) Greg KH
2009-08-03 18:53                   ` Linus Torvalds
2009-08-03 22:16                   ` Sergey Senozhatsky
2009-08-03 22:25                     ` Linus Torvalds
2009-08-03 22:58                       ` [PATCH 3/2] tty-ldisc: be more careful in 'put_ldisc' locking Linus Torvalds
2009-08-03 23:00                         ` [PATCH 4/2] tty-ldisc: make /proc/tty/ldiscs use ldisc_ops instead of ldiscs Linus Torvalds
2009-08-03 23:01                           ` [PATCH 5/2] tty-ldisc: get rid of tty_ldisc_try_get() helper function Linus Torvalds
2009-08-04  0:30                   ` proper tty-ldisc refcounting (was Re: WARNING at: drivers/char/tty_ldisc.c) Sergey Senozhatsky
2009-08-04  0:56                     ` Linus Torvalds
2009-08-04  3:53                       ` Greg KH
2009-08-04  4:08                         ` Greg KH
2009-08-04  6:19                           ` Linus Torvalds
2009-08-04  7:23                             ` Greg KH
2009-08-04  9:12                               ` Sergey Senozhatsky
2009-08-04 14:53                                 ` Greg KH
2009-08-04 15:40                               ` Linus Torvalds [this message]
2009-08-04 16:00                                 ` Greg KH
2009-08-02 22:15       ` WARNING at: drivers/char/tty_ldisc.c Sergey Senozhatsky

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=alpine.LFD.2.01.0908040825210.3270@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergey.senozhatsky@mail.by \
    /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.