linux-kernel - Re: 3.7 XFS lockdep trace

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] [day] [month] [year] [list]

Message-ID: <20121211223109.GD16353@dastard>
Date:	Wed, 12 Dec 2012 09:31:09 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, xfs@....sgi.com
Subject: Re: 3.7 XFS lockdep trace

On Tue, Dec 11, 2012 at 10:42:07AM -0500, Dave Jones wrote:
> This says rc8+, but it's just missing the Makefile change, so it's still there in 3.7
> Curious that firefox was the process mentioned here, as ~/.mozilla isn't on xfs.
> My only xfs partition is /data holding a kernel source tree & .ccache

The fs freeze lockdep annotations have caused some ....  interesting
lockdep reports.....

> [30557.776326] 3 locks on stack by firefox/17386:
> [30557.776571]  #0: blocked:  (&mm->mmap_sem){++++++}, instance: ffff8800a823c308, at: [<ffffffff816ac2b3>] __do_page_fault+0x103/0x4f0
> [30557.777276]  #1: blocked:  (shrinker_rwsem){++++..}, instance: ffffffff81c49de0, at: [<ffffffff81169ccc>] shrink_slab+0x3c/0x510
> [30557.777962]  #2: blocked:  (&type->s_umount_key#42){.+.+.+}, instance: ffff8800c4ed5730, at: [<ffffffff811c24c4>] grab_super_passive+0x44/0x90

There's no filesystem specific locks here, and it indicates that
the shrinkers are involved, so firefox can indeed touch the XFS
filesystem directly this way...

> [30557.789160]     RECLAIM_FS-ON-W at:
> [30557.789362]                          [<ffffffff810c8042>] mark_held_locks+0xb2/0x130
> [30557.789792]                          [<ffffffff810c8795>] lockdep_trace_alloc+0x75/0xd0
> [30557.790241]                          [<ffffffff811af81a>] kmem_cache_alloc_node_trace+0x3a/0x2e0
> [30557.790740]                          [<ffffffff81192242>] vm_map_ram+0x2a2/0x7f0
> [30557.791161]                          [<ffffffffa052a4c3>] _xfs_buf_map_pages+0x73/0x130 [xfs]
> [30557.791646]                          [<ffffffffa052baeb>] xfs_buf_get_map+0x15b/0x270 [xfs]
> [30557.792114]                          [<ffffffffa05ada19>] xfs_trans_get_buf_map+0x1d9/0x3b0 [xfs]
> [30557.792615]                          [<ffffffffa0589f04>] xfs_ialloc_inode_init+0xe4/0x1f0 [xfs]

Oh, that's already fixed in the 3.8- queue.

$ gl -n 1 7c4cebe
commit 7c4cebe8e02dd0b0e655605442bbe9268db9ed4f
Author: Dave Chinner <dchinner@...hat.com>
Date:   Fri Nov 23 14:24:23 2012 +1100

    xfs: inode allocation should use unmapped buffers.
    
    Inode buffers do not need to be mapped as inodes are read or written
    directly from/to the pages underlying the buffer. This fixes a
    regression introduced by commit 611c994 ("xfs: make XBF_MAPPED the
    default behaviour").
....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/