linux-kernel - Re: 2.6.21.3 Oops (was Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Jun 2007 11:22:09 +0200
From:	"Marco Berizzi" <pupilla@...mail.com>
To:	"Christoph Lameter" <clameter@....com>
Cc:	"Satyam Sharma" <satyam.sharma@...il.com>,
	<linux-kernel@...r.kernel.org>, "David Chinner" <dgc@....com>,
	<xfs@....sgi.com>, "Andrew Morton" <akpm@...ux-foundation.org>,
	"Marco Berizzi" <pupilla@...mail.com>
Subject: Re: 2.6.21.3 Oops (was Re: XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd)

Christoph Lameter wrote:

> On Thu, 21 Jun 2007, Marco Berizzi wrote:
>
> > > > Some RCU callback (that calls kmem_cache_free()) oopsed and
> > > > panic'ed his box. [ Marco had experienced fs issues lately, so
we
> > > could
> > > > suspect file_free_rcu() here, but I can't really tell from the
stack
> > > trace;
> > > > BTW whats with the rampant disease in the kernel to declare as
> > inline
> > > > even those functions exclusively meant to be dereferenced and
passed
> > > > as pointers to call_rcu()?! ]
>
>
> The BUG_ON that triggers this signals us that someone tried to perform
> a kfree or kmem_cache_free on an object that is not in a slab page.
>
>
> > Hello everybody.
> > Few minutes ago 2.6.22-rc5 has been
> > crashed with this error (see also the
> > bitmap at http://80.204.235.230/foto2.jpg).
> > Just for record: if I build linux
> > with 'Debug slab memory allocations'
> > the box doesn't crash.
>
> Hmmm.. That is strange and could point to some sort of race condition.
>
> 1. The object is freed. It is the last page on the slab. Thus slab
> decommissions the page and resets PageSlab.
>
> 2. Another process tries to free the object again. Now the page is no
> longer marked as being a SLAB page. Thus the BUG_ON is triggered.
>
> Can you try the same with SLUB? Boot with "slub_debug".

With the same kernel or should I compile with
some other options?

> If you cannot
> trigger the error anymore do limited debugging by booting with
> "slub_debug=F". Maybe that will be enough to trigger the race.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/