All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: kdevtmpfs oops since yesterdays vfs merge
Date: Mon, 25 Jul 2011 03:44:44 +0100	[thread overview]
Message-ID: <20110725024444.GP24703@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20110725015612.GB7603@redhat.com>

On Sun, Jul 24, 2011 at 09:56:12PM -0400, Dave Jones wrote:

> [    7.760774] dracut: luksOpen /dev/sda2 luks-b5a1fb36-5672-4191-a260-e3f389eb0bb6
> [   14.787158] nodename: dm-0
> [   15.082391] nodename: dm-0
> 
> 
> when it triggers the bug_on(), it's that second nodename that is garbage.

Interesting...  The next experiment would be to stick BUG_ON(!req.dev)
into devtmpfs_create_node() right after the assigment to that field.

We couldn't be hit by the lack of barriers here, could we?  Store to
req.dev happens before spin_unlock(&req_lock), so by the time when
that request is seen by loop in devtmpfsd() and passed to handle() it
should be seen - we have grabbed req_lock, found a pointer to req, dropped
req_lock and called handle().  Should've been enough...

Might be interesting to print &req from devtmpfs_create_node(), both on
entry and on exit, and print req right before the call of handle()...

Incidentally, that disassembly shows one really ugly thing - offset of
->devt in struct device is 0x3c0.  IOW, each of those suckers eats a
kilobyte... ;-/

  reply	other threads:[~2011-07-25  2:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-24 23:17 kdevtmpfs oops since yesterdays vfs merge Dave Jones
2011-07-24 23:28 ` Al Viro
2011-07-24 23:40   ` Dave Jones
2011-07-24 23:51     ` Al Viro
2011-07-25  1:53       ` Dave Jones
2011-07-25  1:56         ` Dave Jones
2011-07-25  2:44           ` Al Viro [this message]
2011-07-25  4:58             ` Dave Jones
2011-07-25  5:12               ` Al Viro
2011-07-25  5:53                 ` Dave Jones
2011-07-25  6:15                   ` Al Viro

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=20110725024444.GP24703@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=davej@redhat.com \
    --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.