Patchwork [BUG] lib/kernel_lock.c:126 with cgroups regression ltp tests

login
register
mail settings
Submitter Michael Ellerman
Date June 17, 2009, 11:20 a.m.
Message ID <1245237613.4269.13.camel@concordia>
Download mbox | patch
Permalink /patch/28772/
State Not Applicable, archived
Headers show

Comments

Michael Ellerman - June 17, 2009, 11:20 a.m.
On Wed, 2009-06-17 at 16:21 +0530, Sachin Sant wrote:
> While executing cgroups regression tests from LTP May 2009
> release on a Power6 box came across the following bug.

> This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6)

Looks like 337eb00a2 missed some return paths in do_remount_sb()?

$ git log -p -U13 337eb00a2c3a421999c39c94ce7e33545ee8baa7 fs/super.c
commit 337eb00a2c3a421999c39c94ce7e33545ee8baa7
Author: Alessio Igor Bogani <abogani@texware.it>
Date:   Tue May 12 15:10:54 2009 +0200

    Push BKL down into ->remount_fs()
    
    [xfs, btrfs, capifs, shmem don't need BKL, exempt]
    
    Signed-off-by: Alessio Igor Bogani <abogani@texware.it>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

> TASK = c0000000407cbc20[9581] 'mount' THREAD: c00000002a5d0000 CPU: 3
> <6>GPR00: 0000000000000001 c00000002a5d3b90 c000000000ef31f0 fffffffffffffff0 
> <6>GPR04: c0000000000f0098 c000000000799813 0000000000000000 0000000000000001 
> <6>GPR08: c000000000e36aa0 c0000000407cbc20 0000000000000002 c0000000407cbc20 
> <6>GPR12: 0000000024042424 c000000000ff2a00 00000fffed50f6fd 00000fffed506e08 
> <6>GPR16: 00000fffed506db8 000000001002b638 0000000000000000 0000000000000000 
> <6>GPR20: 00000000100329a0 00000fffed506e0c c00000003e14b870 0000000000000000 
> <6>GPR24: 0000000000000000 c00000002a030000 0000000000000000 0000000000000000 
> <6>GPR28: c00000003e14b800 fffffffffffffff0 c000000000e7aa40 c00000002a5d3b90 
> NIP [c0000000005c6dac] .unlock_kernel+0x20/0x78
> LR [c0000000001965ac] .do_remount_sb+0x190/0x204
> Call Trace:
> [c00000002a5d3bd0] [c00000000019659c] .do_remount_sb+0x180/0x204
> [c00000002a5d3c70] [c0000000001b8210] .do_mount+0x38c/0x9fc
> [c00000002a5d3d60] [c0000000001b8940] .SyS_mount+0xc0/0x12c
> [c00000002a5d3e30] [c000000000008534] syscall_exit+0x0/0x40
> Instruction dump:
> 383f0040 ebc1fff0 ebe1fff8 4e800020 fbc1fff0 fbe1fff8 f821ffc1 7c3f0b78 
> ebc2c0b8 e92d01b0 e809001e 78000fe0 <0b000000> e96d01b0 812b001c 3929ffff 
> ---[ end trace 3bf0012ad33d52b2 ]---
> 
> Corresponding c code is :
> 
> void __lockfunc unlock_kernel(void)
> {
>         BUG_ON(current->lock_depth < 0);  <<======
>         if (likely(--current->lock_depth < 0))
>                 __unlock_kernel();
> 
> Have attached the cgroups regression test run log.
> 
> Thanks
> -Sachin
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Sachin P. Sant - June 17, 2009, 12:16 p.m.
Michael Ellerman wrote:
> On Wed, 2009-06-17 at 16:21 +0530, Sachin Sant wrote:
>   
>> While executing cgroups regression tests from LTP May 2009
>> release on a Power6 box came across the following bug.
>>     
>
>   
>> This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6)
>>     
>
> Looks like 337eb00a2 missed some return paths in do_remount_sb()?
>
> $ git log -p -U13 337eb00a2c3a421999c39c94ce7e33545ee8baa7 fs/super.c
> commit 337eb00a2c3a421999c39c94ce7e33545ee8baa7
> Author: Alessio Igor Bogani <abogani@texware.it>
Thanks Michael.

The following submitted patch from Chris fixes this issue.

http://patchwork.kernel.org/patch/30675/

Thanks
-Sachin

Patch

diff --git a/fs/super.c b/fs/super.c
index 1905f4a..83b4741 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -530,53 +530,51 @@  int do_remount_sb(struct super_block *sb, int flags, void 
 {
        int retval;
        int remount_rw;
        
 #ifdef CONFIG_BLOCK
        if (!(flags & MS_RDONLY) && bdev_read_only(sb->s_bdev))
                return -EACCES;
 #endif
        if (flags & MS_RDONLY)
                acct_auto_close(sb);
        shrink_dcache_sb(sb);
        sync_filesystem(sb);
 
-       lock_kernel();
        /* If we are remounting RDONLY and current sb is read/write,
           make sure there are no rw files opened */
        if ((flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY)) {
                if (force)
                        mark_files_ro(sb);
                else if (!fs_may_remount_ro(sb)) {
                        unlock_kernel();
                        return -EBUSY;
                }
                retval = vfs_dq_off(sb, 1);
                if (retval < 0 && retval != -ENOSYS) {
                        unlock_kernel();
                        return -EBUSY;
                }
        }
        remount_rw = !(flags & MS_RDONLY) && (sb->s_flags & MS_RDONLY);
 
        if (sb->s_op->remount_fs) {
                retval = sb->s_op->remount_fs(sb, &flags, data);
                if (retval) {
                        unlock_kernel();
                        return retval;
                }
        }
        sb->s_flags = (sb->s_flags & ~MS_RMT_MASK) | (flags & MS_RMT_MASK);
-       unlock_kernel();


cheers


> ------------[ cut here ]------------
> kernel BUG at lib/kernel_lock.c:126!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea cdrom sg ibmveth sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
> NIP: c0000000005c6dac LR: c0000000001965ac CTR: 0000000000000006
> REGS: c00000002a5d3910 TRAP: 0700   Not tainted  (2.6.30-git10)
> MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 82042442  XER: 00000000