xfs_setattr_size is mid-stack during log-flooding stack traces

[Eric Sandeen]

See "[vfs] WARNING: CPU: 3 PID: 2339 at mm/truncate.c:758 pagecache_isize_extended+0xdd/0x120()" sent earlier today.

-Eric

> On Oct 26, 2014, at 10:21 PM, "Michael L. Semon" <mlsemon35 at gmail.com> wrote:
> 
> Hi!  I was having fantastic luck with v5/finobt XFS and kernel
> 3.18.0-rc1, so I decided to disable quota support and debug support
> in XFS...
> 
> [    0.000000] Linux version 3.18.0-rc1+ (root at kyhorse) (gcc version 4.8.3 (GCC) ) #5 SMP Sun Oct 26 14:43:09 EDT 2014
> # i686 Pentium 4, BTW.
> [    0.857655] SGI XFS with ACLs, security attributes, no debug enabled
> 
> Some other debug items were shut off as well.
> 
> Now, my logs are getting pelted with items that look like this (first trace,
> on boot):
> 
> [   14.549583] XFS (sda1): Mounting V5 Filesystem
> [   14.810908] XFS (sda1): Ending clean mount
> [   14.826918] mount (155) used greatest stack depth: 6056 bytes left
> [   15.139152] rc.S (64) used greatest stack depth: 5948 bytes left
> [   29.443780] ------------[ cut here ]------------
> [   29.443801] WARNING: CPU: 0 PID: 387 at mm/truncate.c:758 pagecache_isize_extended+0x124/0x129()
> [   29.443809] CPU: 0 PID: 387 Comm: gtk-query-immod Not tainted 3.18.0-rc1+ #5
> [   29.443813] Hardware name: Gateway                         E-2000                         /D845GRG                        , BIOS RG84510A.15A.0009.P03.020
> [   29.443817]  00000000 00000000 ee1e9e20 c144939c 00000000 ee1e9e50 c1031b03 c154f66c
> [   29.443828]  00000000 00000183 c1553739 000002f6 c1098458 c1098458 e849ed54 00000000
> [   29.443838]  00001000 ee1e9e60 c1031bb8 00000009 00000000 ee1e9e98 c1098458 efd69100
> [   29.443848] Call Trace:
> [   29.443858]  [<c144939c>] dump_stack+0x41/0x52
> [   29.443867]  [<c1031b03>] warn_slowpath_common+0x6f/0x86
> [   29.443873]  [<c1098458>] ? pagecache_isize_extended+0x124/0x129
> [   29.443878]  [<c1098458>] ? pagecache_isize_extended+0x124/0x129
> [   29.443884]  [<c1031bb8>] warn_slowpath_null+0x1d/0x1f
> [   29.443889]  [<c1098458>] pagecache_isize_extended+0x124/0x129
> [   29.443895]  [<c1098494>] truncate_setsize+0x37/0x50
> [   29.443902]  [<c117c534>] xfs_setattr_size+0x13d/0x3d6
> [   29.443909]  [<c116a2ed>] ? __xfs_get_blocks+0x5ff/0x5ff
> [   29.443916]  [<c1172c13>] xfs_file_fallocate+0x2fe/0x340
> [   29.443922]  [<c1444ccc>] ? kmemleak_free+0x20/0x43
> [   29.443931]  [<c10ba00d>] ? kmem_cache_free+0x76/0xc4
> [   29.443938]  [<c10bd802>] do_fallocate+0x111/0x18a
> [   29.443943]  [<c10bd8cb>] SyS_fallocate+0x50/0x70
> [   29.443950]  [<c144f6ef>] syscall_call+0x7/0x7
> [   29.443954] ---[ end trace 281f0f955c16f86c ]---
> 
> In an xfstests run, it seemed to start with generic/012 and hit a
> great many tests after that.  The actual BUG_ON is somewhere in
> mm/truncate.c, though...
> 
>        WARN_ON(!mutex_is_locked(&inode->i_mutex));
> 
> Is this an XFS issue at all?  Or is there some kind of extra
> precaution that has to be taken on the XFS side?  Feel free to toss
> me over to mm to ask, "What is this?"
> 
> Thanks!
> 
> Michael
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20141027/800865ea/attachment.html>