Re: Lockdep for 3.10.0+ for rm of kernel git...

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs