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... > > CPU0 > ---- > lock(&(&ip->i_lock)->mr_lock); > <Interrupt> > lock(&(&ip->i_lock)->mr_lock); > > ...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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
