All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: kernel BUG at fs/ext/super.c:428
Date: Wed, 21 Jan 2009 12:10:18 -0800	[thread overview]
Message-ID: <1232568618.16682.20.camel@jamoon.sc.intel.com> (raw)
In-Reply-To: <20090114212038.GJ6222@mit.edu>

On Wed, 2009-01-14 at 13:20 -0800, Theodore Tso wrote:
> On Wed, Jan 14, 2009 at 08:29:37PM +0100, Peter Zijlstra wrote:
> > > 38d47c1b7075bd7ec3881141bb3629da58f88dab is first bad commit
> > > commit 38d47c1b7075bd7ec3881141bb3629da58f88dab
> > > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Date:   Fri Sep 26 19:32:20 2008 +0200
> > >
> > >     futex: rely on get_user_pages() for shared futexes
> > >
> > >     On the way of getting rid of the mmap_sem requirement for shared futexes,
> > >     start by relying on get_user_pages().
> > >
> > >     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > >     Acked-by: Nick Piggin <nickpiggin@yahoo.com.au>
> > >     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > >
> > However does a futex change make ext3 crap its pants?
> 
> I agree, this doesn't make much sense.  I've looked at the patch, and
> I don't see how this would cause an ext3 orphaned-inode list handling
> problem
> 
> Are you sure the bisect was done correctly?  Have you tried reverting
> that one commit, or otherwise conclusively shown that a kernel with
> this commit fails, and one without this commit works just fine?
> 

Unfortunately, I cannot revert this patch alone from upstream git.
But I consistently see
upstream git: Always produces this oops on reboot
checkout of 38d47c1b: Always produces this oops on reboot
checkout of 94aca1da (one patch before the above commit): Reboots fine
without the oops.

This is petty specific to the particular userspace, looks like.
I only see this on SLES10 installation. Also, I need a non-root user
logged in at least once after boot through X to see this problem. I was
always seeing this as I had autologin on local terminal and was remotely
rebooting the system. If I just boot to init 3 or boot to init 5 with no
user logged in or boot to init 5 with root logged in, I do not see this
problem.

Thanks,
Venki

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: kernel BUG at fs/ext/super.c:428
Date: Wed, 21 Jan 2009 12:10:18 -0800	[thread overview]
Message-ID: <1232568618.16682.20.camel@jamoon.sc.intel.com> (raw)
In-Reply-To: <20090114212038.GJ6222@mit.edu>

On Wed, 2009-01-14 at 13:20 -0800, Theodore Tso wrote:
> On Wed, Jan 14, 2009 at 08:29:37PM +0100, Peter Zijlstra wrote:
> > > 38d47c1b7075bd7ec3881141bb3629da58f88dab is first bad commit
> > > commit 38d47c1b7075bd7ec3881141bb3629da58f88dab
> > > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Date:   Fri Sep 26 19:32:20 2008 +0200
> > >
> > >     futex: rely on get_user_pages() for shared futexes
> > >
> > >     On the way of getting rid of the mmap_sem requirement for shared futexes,
> > >     start by relying on get_user_pages().
> > >
> > >     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > >     Acked-by: Nick Piggin <nickpiggin@yahoo.com.au>
> > >     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > >
> > However does a futex change make ext3 crap its pants?
> 
> I agree, this doesn't make much sense.  I've looked at the patch, and
> I don't see how this would cause an ext3 orphaned-inode list handling
> problem
> 
> Are you sure the bisect was done correctly?  Have you tried reverting
> that one commit, or otherwise conclusively shown that a kernel with
> this commit fails, and one without this commit works just fine?
> 

Unfortunately, I cannot revert this patch alone from upstream git.
But I consistently see
upstream git: Always produces this oops on reboot
checkout of 38d47c1b: Always produces this oops on reboot
checkout of 94aca1da (one patch before the above commit): Reboots fine
without the oops.

This is petty specific to the particular userspace, looks like.
I only see this on SLES10 installation. Also, I need a non-root user
logged in at least once after boot through X to see this problem. I was
always seeing this as I had autologin on local terminal and was remotely
rebooting the system. If I just boot to init 3 or boot to init 5 with no
user logged in or boot to init 5 with root logged in, I do not see this
problem.

Thanks,
Venki


  reply	other threads:[~2009-01-21 20:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-10  0:36 kernel BUG at fs/ext/super.c:428 Pallipadi, Venkatesh
2009-01-14  0:48 ` Andrew Morton
2009-01-14  1:44   ` Theodore Tso
2009-01-14  2:48     ` Arjan van de Ven
2009-01-14  2:48       ` Arjan van de Ven
2009-01-14  4:40       ` Theodore Tso
2009-01-14 19:16         ` Pallipadi, Venkatesh
2009-01-14 19:16           ` Pallipadi, Venkatesh
2009-01-14 19:29           ` Peter Zijlstra
2009-01-14 19:38             ` Pallipadi, Venkatesh
2009-01-14 19:42               ` Peter Zijlstra
2009-01-14 19:48                 ` Pallipadi, Venkatesh
2009-01-14 21:20             ` Theodore Tso
2009-01-21 20:10               ` Pallipadi, Venkatesh [this message]
2009-01-21 20:10                 ` Pallipadi, Venkatesh
2009-01-24  7:36                 ` Peter Zijlstra
2009-01-24  7:36                   ` Peter Zijlstra
2009-01-26 16:39                   ` Darren Hart
2009-01-26 16:39                     ` Darren Hart
2009-01-26 16:46                     ` Peter Zijlstra
2009-01-26 17:12                       ` Darren Hart

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=1232568618.16682.20.camel@jamoon.sc.intel.com \
    --to=venkatesh.pallipadi@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tytso@MIT.EDU \
    /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.