All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: richard -rw- weinberger <richard.weinberger@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Arnaud Lacombe <lacombar@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386
Date: Wed, 10 Aug 2011 05:04:45 +0100	[thread overview]
Message-ID: <20110810040445.GM2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20110809233817.GL2203@ZenIV.linux.org.uk>

On Wed, Aug 10, 2011 at 12:38:17AM +0100, Al Viro wrote:

> 	* tty-on-xterm sometimes crashes on the first keysyms reaching it;
> as far as I can tell, it's something related to SIGWINCH handling - whether
> it happens or not depends on the way xterm windows are laid out and flipping
> between them first seems to prevent that shit.  If it hasn't happened at once,
> it won't happen at all...  Something in drivers/chan or drivers/line, most
> likely...

FWIW, what I'm seeing there is chan_interrupt() with tty that has definitely
been kfree'd.  What happens is that we have several opened files for
given tty and they all get closed in parallel.  Now, ->release() of
tty calls ->close() of driver (line_close() in this case) and then
gets around to decrementing tty->count.  As the result, *all* callers
of line_close() see line->tty->count > 1 and leave line->tty not reset to
NULL.  Oops...

Moral: do not use the counters on upper layer objects unless you know
what you are doing *and* know what will happen to that upper layer in
years to come...

  reply	other threads:[~2011-08-10  4:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1312066693.22074.50.camel@i7.infradead.org>
2011-07-30 23:01 ` [PATCH 2/5] um: Remove gratuitous use of $(SUBARCH) in Makefile-i386 David Woodhouse
2011-07-30 23:02 ` [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386 David Woodhouse
2011-07-31 22:11   ` richard -rw- weinberger
2011-07-31 22:11     ` richard -rw- weinberger
2011-07-31 22:24     ` David Woodhouse
2011-07-31 22:48       ` Al Viro
2011-07-31 22:58         ` Al Viro
2011-07-31 22:58           ` [uml-devel] " Al Viro
2011-07-31 23:13           ` David Woodhouse
2011-07-31 23:13             ` [uml-devel] " David Woodhouse
2011-07-31 23:17             ` richard -rw- weinberger
2011-07-31 23:17               ` [uml-devel] " richard -rw- weinberger
2011-07-31 23:24               ` David Woodhouse
2011-07-31 23:24                 ` [uml-devel] " David Woodhouse
2011-08-01  4:32               ` Al Viro
2011-08-01  4:32                 ` [uml-devel] " Al Viro
2011-08-01 10:04                 ` Geert Uytterhoeven
2011-08-01 10:40                   ` richard -rw- weinberger
2011-08-01 17:23                   ` Al Viro
2011-08-01 17:52                 ` richard -rw- weinberger
2011-08-01 17:52                   ` richard -rw- weinberger
2011-08-09 23:38                   ` Al Viro
2011-08-10  4:04                     ` Al Viro [this message]
2011-08-10 17:44                       ` Al Viro
2011-08-11  4:23                         ` Al Viro
2011-08-11 12:13                           ` richard -rw- weinberger
2011-08-11 12:13                             ` richard -rw- weinberger
2011-08-11 14:05                             ` Al Viro
2011-07-31 23:09         ` David Woodhouse
2011-07-31 23:09           ` [uml-devel] " David Woodhouse
2011-07-30 23:02 ` [PATCH 3/5] um: Always use -m32 when building for i386 David Woodhouse
2011-07-30 23:02 ` [PATCH 4/5] um: Do not define SUBARCH in CFLAGS David Woodhouse
2011-07-30 23:04 ` [PATCH 5/5] um: Fix SUBARCH=x86 build David Woodhouse

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=20110810040445.GM2203@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=dwmw2@infradead.org \
    --cc=hpa@zytor.com \
    --cc=lacombar@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.weinberger@gmail.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.