All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: maciej.rutecki@gmail.com
Cc: Tao Ma <tm@tao.ma>,
	npiggin@gmail.com, Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org, Theodore Tso <tytso@mit.edu>
Subject: Re: 38-rc1: umount+rmmod cause ext4 error.
Date: Wed, 26 Jan 2011 14:40:44 -0600	[thread overview]
Message-ID: <4D4086CC.5050309@redhat.com> (raw)
In-Reply-To: <201101262128.25528.maciej.rutecki@gmail.com>

On 1/26/11 2:28 PM, Maciej Rutecki wrote:
> I created a Bugzilla entry at 
> https://bugzilla.kernel.org/show_bug.cgi?id=27652
> for your bug report, please add your address to the CC list in there, thanks!

I believe patches have been sent that should fix this; there were
2 module unloading regressions in .37, both fixed.

If you can test with:

http://marc.info/?l=linux-ext4&m=129546975702198&w=2
and
http://marc.info/?l=linux-ext4&m=129527644524410&w=2

that'd be great.

Thanks,
-Eric

> On środa, 19 stycznia 2011 o 07:53:36 Tao Ma wrote:
>> Hi Nick and Ted,
>> 	I ran some very basic test with 38-rc1 and my box run into error with
>> the message like:
>>
>> slab error in kmem_cache_destroy(): cache `ext4_inode_cache': Can't free
>> all objects
>> Pid: 4395, comm: rmmod Not tainted 2.6.38-rc1 #1
>> Call Trace:
>>   [<ffffffff820d61dc>] ? kmem_cache_destroy+0x83/0xc7
>>   [<ffffffffa0574025>] ? destroy_inodecache+0x15/0x17 [ext4]
>>   [<ffffffffa05923d1>] ? ext4_exit_fs+0x109/0x143 [ext4]
>>   [<ffffffff8203d194>] ? put_online_cpus+0x56/0x58
>>   [<ffffffff8206735a>] ? module_refcount+0x85/0x9d
>>   [<ffffffff82067b22>] ? sys_delete_module+0x1b5/0x218
>>   [<ffffffff82074fc3>] ? audit_syscall_entry+0x187/0x1ba
>>   [<ffffffff82002a6b>] ? system_call_fastpath+0x16/0x1b
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>>
>> The reproduce process is simple:just rmmod ext4 immediately after umount
>> an ext4 volume.
>>
>> I have done some very simple investigation and it seems that with Nick's
>> new ext4_i_callback, even after we do ext4_destroy_inode, it isn't
>> freed. So after we destroy the ext_inode_cache, and when freeing the
>> inode, it errors. Hope it helps. If you have any fixes, I can test it.
>>
>> Regards,
>> Tao
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
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: Eric Sandeen <sandeen@redhat.com>
To: maciej.rutecki@gmail.com
Cc: Tao Ma <tm@tao.ma>,
	npiggin@gmail.com, Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org, Theodore Tso <tytso@mit.edu>
Subject: Re: 38-rc1: umount+rmmod cause ext4 error.
Date: Wed, 26 Jan 2011 14:40:44 -0600	[thread overview]
Message-ID: <4D4086CC.5050309@redhat.com> (raw)
In-Reply-To: <201101262128.25528.maciej.rutecki@gmail.com>

On 1/26/11 2:28 PM, Maciej Rutecki wrote:
> I created a Bugzilla entry at 
> https://bugzilla.kernel.org/show_bug.cgi?id=27652
> for your bug report, please add your address to the CC list in there, thanks!

I believe patches have been sent that should fix this; there were
2 module unloading regressions in .37, both fixed.

If you can test with:

http://marc.info/?l=linux-ext4&m=129546975702198&w=2
and
http://marc.info/?l=linux-ext4&m=129527644524410&w=2

that'd be great.

Thanks,
-Eric

> On środa, 19 stycznia 2011 o 07:53:36 Tao Ma wrote:
>> Hi Nick and Ted,
>> 	I ran some very basic test with 38-rc1 and my box run into error with
>> the message like:
>>
>> slab error in kmem_cache_destroy(): cache `ext4_inode_cache': Can't free
>> all objects
>> Pid: 4395, comm: rmmod Not tainted 2.6.38-rc1 #1
>> Call Trace:
>>   [<ffffffff820d61dc>] ? kmem_cache_destroy+0x83/0xc7
>>   [<ffffffffa0574025>] ? destroy_inodecache+0x15/0x17 [ext4]
>>   [<ffffffffa05923d1>] ? ext4_exit_fs+0x109/0x143 [ext4]
>>   [<ffffffff8203d194>] ? put_online_cpus+0x56/0x58
>>   [<ffffffff8206735a>] ? module_refcount+0x85/0x9d
>>   [<ffffffff82067b22>] ? sys_delete_module+0x1b5/0x218
>>   [<ffffffff82074fc3>] ? audit_syscall_entry+0x187/0x1ba
>>   [<ffffffff82002a6b>] ? system_call_fastpath+0x16/0x1b
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>> SLAB: cache with size 888 has lost its name
>>
>> The reproduce process is simple:just rmmod ext4 immediately after umount
>> an ext4 volume.
>>
>> I have done some very simple investigation and it seems that with Nick's
>> new ext4_i_callback, even after we do ext4_destroy_inode, it isn't
>> freed. So after we destroy the ext_inode_cache, and when freeing the
>> inode, it errors. Hope it helps. If you have any fixes, I can test it.
>>
>> Regards,
>> Tao
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2011-01-26 20:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19  6:53 38-rc1: umount+rmmod cause ext4 error Tao Ma
2011-01-26 20:28 ` Maciej Rutecki
2011-01-26 20:28   ` Maciej Rutecki
2011-01-26 20:40   ` Eric Sandeen [this message]
2011-01-26 20:40     ` Eric Sandeen

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=4D4086CC.5050309@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.rutecki@gmail.com \
    --cc=npiggin@gmail.com \
    --cc=tm@tao.ma \
    --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.