On Sat, Jul 13, 2013 at 08:33:56PM -0400, Michael L. Semon wrote:
> Hi! Here's a lockdep that happened while executing an `rm -r linux` to
> remove an old kernel git directory. This is for a git 3.10.0+ kernel
> on a non-CRC XFS filesystem that's less than a week old.
> I'm not getting lockdep reports like this unless I'm minding my own
> business. xfstests could be running until there's a faint burning
> electrical smell in the room, and this won't show up. But if all I'm
> doing is removing things to prepare for the next xfstests session or
> git activity, then this lockdep will show up. I'm not sure if I get
> the same lockdep every time, but it's related to deletes somehow, and
> it's newer than the production 3.10 kernel, AFAIK.
> For the lockdeps, this pattern is prominent...
> ...and lockdep hasn't suggested the SMP scenario on XFS in some time.
> There does seem to be some new lockdep work in the kernel, so maybe
> it's not a regression but something else.
> [<c10a3d44>] __get_free_pages+0x1c/0x37
> [<c1025dc4>] pte_alloc_one_kernel+0x14/0x16
> [<c10b7716>] __pte_alloc_kernel+0x16/0x71
> [<c10c0f27>] vmap_page_range_noflush+0x12c/0x13a
> [<c10c1fdb>] vm_map_ram+0x32c/0x3d7
> [<c10c1d21>] ? vm_map_ram+0x72/0x3d7
> [<c1171d3b>] _xfs_buf_map_pages+0x5b/0xe1
It's vmap related. Again. Ignore it.
On the bright side, I think I've found precedence in the kernel for
getting this fixed, so stay tuned....