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 18:44:32 +0100	[thread overview]
Message-ID: <20110810174432.GN2203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20110810040445.GM2203@ZenIV.linux.org.uk>


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

Fixed and pushed (um-header.git #master); however, looking around that area
shows more races ;-/  Incidentally, why the hell is ->chan_list a cyclic list?
Holding at most two elements...  Why not an array of two possibly NULL
pointers?  And what is chan->primary?  Unless I'm seriously misreading that
code, it's always 1; moreover, all instances of the method that gets ->primary
value as argument ignore that argument completely...

  reply	other threads:[~2011-08-10 17:44 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
2011-08-10 17:44                       ` Al Viro [this message]
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=20110810174432.GN2203@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.