XFS assertion from truncate. (3.10-rc2)

XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

[  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
[  464.235108] ------------[ cut here ]------------
[  464.240898] kernel BUG at fs/xfs/xfs_message.c:108!
[  464.247024] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  464.254763] Modules linked in: hidp bnep af_key can_bcm caif_socket caif rose netrom phonet af_rxrpc rfcomm llc2 bluetooth can_raw pppoe can pppox ppp_generic slhc nfnetlink decnet scsi_transport_iscsi irda appletalk ipx crc_ccitt p8023 x25 nfc rds psnap p8022 llc rfkill ipt_ULOG atm ax25 nfsv3 nfs_acl nfs lockd sunrpc fscache xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq e1000e snd_seq_device snd_pcm ptp snd_page_alloc pps_core snd_timer snd soundcore i915 i2c_algo_bit drm_kms_helper drm i2c_core video
[  464.320028] CPU: 3 PID: 26139 Comm: trinity-child3 Not tainted 3.10.0-rc2+ #1
[  464.348866] task: ffff880240858000 ti: ffff88020527e000 task.ti: ffff88020527e000
[  464.358249] RIP: 0010:[<ffffffffa02d4122>]  [<ffffffffa02d4122>] assfail+0x22/0x30 [xfs]
[  464.368418] RSP: 0018:ffff88020527fdd0  EFLAGS: 00010282
[  464.375069] RAX: 00000000000000cd RBX: ffff880215ff8840 RCX: 0000000000000006
[  464.384021] RDX: 00000000000044a0 RSI: ffff880240858758 RDI: ffff880240858000
[  464.392977] RBP: ffff88020527fdd0 R08: 0000000000000000 R09: 0000000000000000
[  464.401932] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88020527fe90
[  464.410877] R13: ffff880240bc0000 R14: 0000000000000000 R15: 0000000000000000
[  464.419829] FS:  00007ffec576d740(0000) GS:ffff880244e00000(0000) knlGS:0000000000000000
[  464.429972] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  464.437192] CR2: 00000000021c0ca8 CR3: 000000020326a000 CR4: 00000000001407e0
[  464.446124] DR0: 0000000041d84849 DR1: 0000000000000000 DR2: 0000000000000000
[  464.455072] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
[  464.464026] Stack:
[  464.466569]  ffff88020527fe30 ffffffffa02d2019 ffffffff8167ebb1 ffff880215ff8b00
[  464.475929]  ffff880200000a09 ffffffff00000a09 ffffffff811a7fb1 0000000000000a09
[  464.485304]  ffff8802124a4940 0000000000008bc7 ffff88020527fe90 ffff880215ff8b00
[  464.494646] Call Trace:
[  464.497724]  [<ffffffffa02d2019>] xfs_setattr_size+0xb9/0x5d0 [xfs]
[  464.505598]  [<ffffffff8167ebb1>] ? sub_preempt_count+0x71/0x100
[  464.514096]  [<ffffffff811a7fb1>] ? do_truncate+0x61/0xa0
[  464.521833]  [<ffffffffa02d2566>] xfs_vn_setattr+0x36/0x40 [xfs]
[  464.530331]  [<ffffffff811c6f1c>] notify_change+0x1dc/0x360
[  464.538268]  [<ffffffff811a7fbd>] do_truncate+0x6d/0xa0
[  464.545765]  [<ffffffff811a814c>] vfs_truncate+0x15c/0x180
[  464.553600]  [<ffffffff811a81dc>] do_sys_truncate+0x6c/0x90
[  464.561530]  [<ffffffff811a836e>] SyS_truncate+0xe/0x10
[  464.569033]  [<ffffffff81683094>] tracesys+0xdd/0xe2
[  464.576203] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 89 e5 48 89 fa 48 c7 c6 48 17 36 a0 31 ff 31 c0 e8 ce fb ff ff <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 
[  464.603000] RIP  [<ffffffffa02d4122>] assfail+0x22/0x30 [xfs]
[  464.611215]  RSP <ffff88020527fdd0>
[  464.620153] ---[ end trace 56da871d7d2d94aa ]---

XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

[  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
[  464.235108] ------------[ cut here ]------------
[  464.240898] kernel BUG at fs/xfs/xfs_message.c:108!
[  464.247024] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  464.254763] Modules linked in: hidp bnep af_key can_bcm caif_socket caif rose netrom phonet af_rxrpc rfcomm llc2 bluetooth can_raw pppoe can pppox ppp_generic slhc nfnetlink decnet scsi_transport_iscsi irda appletalk ipx crc_ccitt p8023 x25 nfc rds psnap p8022 llc rfkill ipt_ULOG atm ax25 nfsv3 nfs_acl nfs lockd sunrpc fscache xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq e1000e snd_seq_device snd_pcm ptp snd_page_alloc pps_core snd_timer snd soundcore i915 i2c_algo_bit drm_kms_helper drm i2c_core video
[  464.320028] CPU: 3 PID: 26139 Comm: trinity-child3 Not tainted 3.10.0-rc2+ #1
[  464.348866] task: ffff880240858000 ti: ffff88020527e000 task.ti: ffff88020527e000
[  464.358249] RIP: 0010:[<ffffffffa02d4122>]  [<ffffffffa02d4122>] assfail+0x22/0x30 [xfs]
[  464.368418] RSP: 0018:ffff88020527fdd0  EFLAGS: 00010282
[  464.375069] RAX: 00000000000000cd RBX: ffff880215ff8840 RCX: 0000000000000006
[  464.384021] RDX: 00000000000044a0 RSI: ffff880240858758 RDI: ffff880240858000
[  464.392977] RBP: ffff88020527fdd0 R08: 0000000000000000 R09: 0000000000000000
[  464.401932] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88020527fe90
[  464.410877] R13: ffff880240bc0000 R14: 0000000000000000 R15: 0000000000000000
[  464.419829] FS:  00007ffec576d740(0000) GS:ffff880244e00000(0000) knlGS:0000000000000000
[  464.429972] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  464.437192] CR2: 00000000021c0ca8 CR3: 000000020326a000 CR4: 00000000001407e0
[  464.446124] DR0: 0000000041d84849 DR1: 0000000000000000 DR2: 0000000000000000
[  464.455072] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
[  464.464026] Stack:
[  464.466569]  ffff88020527fe30 ffffffffa02d2019 ffffffff8167ebb1 ffff880215ff8b00
[  464.475929]  ffff880200000a09 ffffffff00000a09 ffffffff811a7fb1 0000000000000a09
[  464.485304]  ffff8802124a4940 0000000000008bc7 ffff88020527fe90 ffff880215ff8b00
[  464.494646] Call Trace:
[  464.497724]  [<ffffffffa02d2019>] xfs_setattr_size+0xb9/0x5d0 [xfs]
[  464.505598]  [<ffffffff8167ebb1>] ? sub_preempt_count+0x71/0x100
[  464.514096]  [<ffffffff811a7fb1>] ? do_truncate+0x61/0xa0
[  464.521833]  [<ffffffffa02d2566>] xfs_vn_setattr+0x36/0x40 [xfs]
[  464.530331]  [<ffffffff811c6f1c>] notify_change+0x1dc/0x360
[  464.538268]  [<ffffffff811a7fbd>] do_truncate+0x6d/0xa0
[  464.545765]  [<ffffffff811a814c>] vfs_truncate+0x15c/0x180
[  464.553600]  [<ffffffff811a81dc>] do_sys_truncate+0x6c/0x90
[  464.561530]  [<ffffffff811a836e>] SyS_truncate+0xe/0x10
[  464.569033]  [<ffffffff81683094>] tracesys+0xdd/0xe2
[  464.576203] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 89 e5 48 89 fa 48 c7 c6 48 17 36 a0 31 ff 31 c0 e8 ce fb ff ff <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 
[  464.603000] RIP  [<ffffffffa02d4122>] assfail+0x22/0x30 [xfs]
[  464.611215]  RSP <ffff88020527fdd0>
[  464.620153] ---[ end trace 56da871d7d2d94aa ]---

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
> [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719

Never seen that fire before, but this is why we have ASSERT()s like
this - we're being handed something by the VFS we don't expect...

Can you give me some context of the file permissions before the
syscall and what the syscall parameters are? i.e. is this likely to
be trying to strip SUID/SGID during the truncate operation?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
> [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719

Never seen that fire before, but this is why we have ASSERT()s like
this - we're being handed something by the VFS we don't expect...

Can you give me some context of the file permissions before the
syscall and what the syscall parameters are? i.e. is this likely to
be trying to strip SUID/SGID during the truncate operation?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
 > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
 > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
 > 
 > Never seen that fire before, but this is why we have ASSERT()s like
 > this - we're being handed something by the VFS we don't expect...
 > 
 > Can you give me some context of the file permissions before the
 > syscall and what the syscall parameters are? i.e. is this likely to
 > be trying to strip SUID/SGID during the truncate operation?

no idea tbh. Is there something I can add to that assert to dump
which file it was triggered by ?

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
 > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
 > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
 > 
 > Never seen that fire before, but this is why we have ASSERT()s like
 > this - we're being handed something by the VFS we don't expect...
 > 
 > Can you give me some context of the file permissions before the
 > syscall and what the syscall parameters are? i.e. is this likely to
 > be trying to strip SUID/SGID during the truncate operation?

no idea tbh. Is there something I can add to that assert to dump
which file it was triggered by ?

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
>  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
>  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
>  > 
>  > Never seen that fire before, but this is why we have ASSERT()s like
>  > this - we're being handed something by the VFS we don't expect...
>  > 
>  > Can you give me some context of the file permissions before the
>  > syscall and what the syscall parameters are? i.e. is this likely to
>  > be trying to strip SUID/SGID during the truncate operation?
> 
> no idea tbh. Is there something I can add to that assert to dump
> which file it was triggered by ?

Convert the assert to a if (), and then in the body do something
like:

	if (mask & (...) {
		char buf[MAX_PATHLEN];

		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
			 __func__, mask, buf);
		ASSERT(0);
	}

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
>  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
>  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
>  > 
>  > Never seen that fire before, but this is why we have ASSERT()s like
>  > this - we're being handed something by the VFS we don't expect...
>  > 
>  > Can you give me some context of the file permissions before the
>  > syscall and what the syscall parameters are? i.e. is this likely to
>  > be trying to strip SUID/SGID during the truncate operation?
> 
> no idea tbh. Is there something I can add to that assert to dump
> which file it was triggered by ?

Convert the assert to a if (), and then in the body do something
like:

	if (mask & (...) {
		char buf[MAX_PATHLEN];

		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
			 __func__, mask, buf);
		ASSERT(0);
	}

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 09:54:10AM +1000, Dave Chinner wrote:
 > On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
 > >  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
 > >  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
 > >  > 
 > >  > Never seen that fire before, but this is why we have ASSERT()s like
 > >  > this - we're being handed something by the VFS we don't expect...
 > >  > 
 > >  > Can you give me some context of the file permissions before the
 > >  > syscall and what the syscall parameters are? i.e. is this likely to
 > >  > be trying to strip SUID/SGID during the truncate operation?
 > > 
 > > no idea tbh. Is there something I can add to that assert to dump
 > > which file it was triggered by ?
 > 
 > Convert the assert to a if (), and then in the body do something
 > like:
 > 
 > 	if (mask & (...) {
 > 		char buf[MAX_PATHLEN];
 > 
 > 		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
 > 		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
 > 			 __func__, mask, buf);
 > 		ASSERT(0);
 > 	}

fs/xfs/xfs_iops.c: In function ‘xfs_setattr_size’:
fs/xfs/xfs_iops.c:723:17: error: incompatible type for argument 1 of ‘d_path’
                 d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
                 ^
In file included from include/linux/fs.h:8:0,
                 from include/linux/genhd.h:65,
                 from include/linux/blkdev.h:9,
                 from fs/xfs/xfs_linux.h:45,
                 from fs/xfs/xfs.h:32,
                 from fs/xfs/xfs_iops.c:18:
include/linux/dcache.h:338:14: note: expected ‘const struct path *’ but argument is of type ‘struct hlist_head’
 extern char *d_path(const struct path *, char *, int);
              ^


	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 09:54:10AM +1000, Dave Chinner wrote:
 > On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
 > >  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
 > >  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
 > >  > 
 > >  > Never seen that fire before, but this is why we have ASSERT()s like
 > >  > this - we're being handed something by the VFS we don't expect...
 > >  > 
 > >  > Can you give me some context of the file permissions before the
 > >  > syscall and what the syscall parameters are? i.e. is this likely to
 > >  > be trying to strip SUID/SGID during the truncate operation?
 > > 
 > > no idea tbh. Is there something I can add to that assert to dump
 > > which file it was triggered by ?
 > 
 > Convert the assert to a if (), and then in the body do something
 > like:
 > 
 > 	if (mask & (...) {
 > 		char buf[MAX_PATHLEN];
 > 
 > 		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
 > 		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
 > 			 __func__, mask, buf);
 > 		ASSERT(0);
 > 	}

fs/xfs/xfs_iops.c: In function ‘xfs_setattr_size’:
fs/xfs/xfs_iops.c:723:17: error: incompatible type for argument 1 of ‘d_path’
                 d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
                 ^
In file included from include/linux/fs.h:8:0,
                 from include/linux/genhd.h:65,
                 from include/linux/blkdev.h:9,
                 from fs/xfs/xfs_linux.h:45,
                 from fs/xfs/xfs.h:32,
                 from fs/xfs/xfs_iops.c:18:
include/linux/dcache.h:338:14: note: expected ‘const struct path *’ but argument is of type ‘struct hlist_head’
 extern char *d_path(const struct path *, char *, int);
              ^


	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 08:08:03PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:54:10AM +1000, Dave Chinner wrote:
>  > On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
>  > > On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
>  > >  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
>  > >  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
>  > >  > 
>  > >  > Never seen that fire before, but this is why we have ASSERT()s like
>  > >  > this - we're being handed something by the VFS we don't expect...
>  > >  > 
>  > >  > Can you give me some context of the file permissions before the
>  > >  > syscall and what the syscall parameters are? i.e. is this likely to
>  > >  > be trying to strip SUID/SGID during the truncate operation?
>  > > 
>  > > no idea tbh. Is there something I can add to that assert to dump
>  > > which file it was triggered by ?
>  > 
>  > Convert the assert to a if (), and then in the body do something
>  > like:
>  > 
>  > 	if (mask & (...) {
>  > 		char buf[MAX_PATHLEN];
>  > 
>  > 		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
>  > 		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
>  > 			 __func__, mask, buf);
>  > 		ASSERT(0);
>  > 	}
> 
> fs/xfs/xfs_iops.c: In function ‘xfs_setattr_size’:
> fs/xfs/xfs_iops.c:723:17: error: incompatible type for argument 1 of ‘d_path’
>                  d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
>                  ^

Oh, sorry, dentry_path() is the version that takes a dentry as the
first parameter. I always get the two confused...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 08:08:03PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 09:54:10AM +1000, Dave Chinner wrote:
>  > On Tue, May 21, 2013 at 07:40:16PM -0400, Dave Jones wrote:
>  > > On Wed, May 22, 2013 at 09:34:29AM +1000, Dave Chinner wrote:
>  > >  > On Tue, May 21, 2013 at 06:52:57PM -0400, Dave Jones wrote:
>  > >  > > [  464.210598] XFS: Assertion failed: (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET| ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID| ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c, line: 719
>  > >  > 
>  > >  > Never seen that fire before, but this is why we have ASSERT()s like
>  > >  > this - we're being handed something by the VFS we don't expect...
>  > >  > 
>  > >  > Can you give me some context of the file permissions before the
>  > >  > syscall and what the syscall parameters are? i.e. is this likely to
>  > >  > be trying to strip SUID/SGID during the truncate operation?
>  > > 
>  > > no idea tbh. Is there something I can add to that assert to dump
>  > > which file it was triggered by ?
>  > 
>  > Convert the assert to a if (), and then in the body do something
>  > like:
>  > 
>  > 	if (mask & (...) {
>  > 		char buf[MAX_PATHLEN];
>  > 
>  > 		d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
>  > 		xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
>  > 			 __func__, mask, buf);
>  > 		ASSERT(0);
>  > 	}
> 
> fs/xfs/xfs_iops.c: In function ‘xfs_setattr_size’:
> fs/xfs/xfs_iops.c:723:17: error: incompatible type for argument 1 of ‘d_path’
>                  d_path(VFS_I(ip)->i_dentry, buf, MAXPATHLEN);
>                  ^

Oh, sorry, dentry_path() is the version that takes a dentry as the
first parameter. I always get the two confused...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 10:16:03AM +1000, Dave Chinner wrote:

Seems like I can trigger this from paths other than truncate too.. (eg, sys_open)

Here's what I ended up with for debug

diff --git a/fs/dcache.c b/fs/dcache.c
index 2b39d16..b579dfe 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2792,6 +2792,7 @@ char *dentry_path(struct dentry *dentry, char *buf, int buflen)
 Elong:
        return ERR_PTR(-ENAMETOOLONG);
 }
+EXPORT_SYMBOL(dentry_path);
 
 /*
  * NOTE! The user-level library version returns a
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index d82efaa..8419e63 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -47,6 +47,7 @@
 #include <linux/security.h>
 #include <linux/fiemap.h>
 #include <linux/slab.h>
+#include <linux/dcache.h>
 
 static int
 xfs_initxattrs(
@@ -714,9 +715,20 @@ xfs_setattr_size(
                return XFS_ERROR(error);
 
        ASSERT(S_ISREG(ip->i_d.di_mode));
-       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
                        ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {
+
+               struct dentry *dentry = d_find_any_alias(VFS_I(ip));
+               char buf[MAXPATHLEN];
+
+               dentry_path(dentry, buf, MAXPATHLEN);
+               dput(dentry);
+               xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
+                        __func__, mask, buf);
+
+                ASSERT(0);
+       }
 
        if (!(flags & XFS_ATTR_NOLOCK)) {
                lock_flags |= XFS_IOLOCK_EXCL;


Something isn't right though I think.. Because the filenames it outputs
look like crap.

[   71.406552] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffee<\x02\xffffff88\xffffffff\xffffffff\xffffff80O\xffffff82\xffffffff\xffffffff\xffffffff\xffffffff

The mask is always 0xa068 though if that helps.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 10:16:03AM +1000, Dave Chinner wrote:

Seems like I can trigger this from paths other than truncate too.. (eg, sys_open)

Here's what I ended up with for debug

diff --git a/fs/dcache.c b/fs/dcache.c
index 2b39d16..b579dfe 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2792,6 +2792,7 @@ char *dentry_path(struct dentry *dentry, char *buf, int buflen)
 Elong:
        return ERR_PTR(-ENAMETOOLONG);
 }
+EXPORT_SYMBOL(dentry_path);
 
 /*
  * NOTE! The user-level library version returns a
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index d82efaa..8419e63 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -47,6 +47,7 @@
 #include <linux/security.h>
 #include <linux/fiemap.h>
 #include <linux/slab.h>
+#include <linux/dcache.h>
 
 static int
 xfs_initxattrs(
@@ -714,9 +715,20 @@ xfs_setattr_size(
                return XFS_ERROR(error);
 
        ASSERT(S_ISREG(ip->i_d.di_mode));
-       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
                        ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {
+
+               struct dentry *dentry = d_find_any_alias(VFS_I(ip));
+               char buf[MAXPATHLEN];
+
+               dentry_path(dentry, buf, MAXPATHLEN);
+               dput(dentry);
+               xfs_warn(mp, "%s: mask 0x%x mismatch on file %s\n",
+                        __func__, mask, buf);
+
+                ASSERT(0);
+       }
 
        if (!(flags & XFS_ATTR_NOLOCK)) {
                lock_flags |= XFS_IOLOCK_EXCL;


Something isn't right though I think.. Because the filenames it outputs
look like crap.

[   71.406552] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffee<\x02\xffffff88\xffffffff\xffffffff\xffffff80O\xffffff82\xffffffff\xffffffff\xffffffff\xffffffff

The mask is always 0xa068 though if that helps.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 10:56:05PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:16:03AM +1000, Dave Chinner wrote:
> 
> Seems like I can trigger this from paths other than truncate too.. (eg, sys_open)

O_TRUNC?

> The mask is always 0xa068 though if that helps.

A bit - it confirms what I thought - a truncate killing SUID bits.
i.e. mask = ATTR_FORCE|ATTR_KILL_SUID|ATTR_CTIME|ATTR_SIZE.

But then here's the next question - where the hell is the ATTR_MODE
bit?  In do_truncate(), the should_remove_suid() return is or'd into
the mask along with ATTR_FORCE. The ATTR_KILL_SUID is returned after
this check:

        umode_t mode = dentry->d_inode->i_mode;
        int kill = 0;

        /* suid always must be killed */
        if (unlikely(mode & S_ISUID))
                kill = ATTR_KILL_SUID;

However, notify_change() takes this mask and the inode and does this
when the ATTR_KILL_SUID flag is set:

	umode_t mode = inode->i_mode;
...
        if (ia_valid & ATTR_KILL_SUID) {
                if (mode & S_ISUID) {
                        ia_valid = attr->ia_valid |= ATTR_MODE;
                        attr->ia_mode = (inode->i_mode & ~S_ISUID);
                }
        }


So, we know that (mode & S_ISUID) is true, because that's how
ATTR_KILL_SUID gets set, but that same check here doesn't result
in ATTR_MODE being set....

That doesn't make a whole lot of sense to me. What am I missing?
Are you seeing this fire at all from notify_change()?

	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));

<Light Bulb>

What's wrong with this code in do_truncate()?

        /* Remove suid/sgid on truncate too */
        ret = should_remove_suid(dentry);
        if (ret)
                newattrs.ia_valid |= ret | ATTR_FORCE;

        mutex_lock(&dentry->d_inode->i_mutex);
        ret = notify_change(dentry, &newattrs);
        mutex_unlock(&dentry->d_inode->i_mutex);

Patch below to fix this.

However, it probably doesn't fix the fact that truncate can change
the size and kill suid/sgid bits at the same time and XFS doesn't
appear to handle that sanely right now. Can you run the patch below
just so when it fails we can see that the mask is actually sane?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

vfs: do_truncate() needs to serialise should_remove_suid

From: Dave Chinner <dchinner@redhat.com>

Otherwise someone else can come in an remove the suid bit before the
truncate locks the inode and calls notify_change(). This results in
XFS throwing asserts because it's getting a strange attr mask being
passed down to it that it doesn't know how to handle correctly.

Signed-off-by: Dave Chinner <dchinner@redhat.com>

---
 fs/open.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index 8c74100..b8d4899 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -52,11 +52,11 @@ int do_truncate(struct dentry *dentry, loff_t length, unsigned int time_attrs,
 	}
 
 	/* Remove suid/sgid on truncate too */
+	mutex_lock(&dentry->d_inode->i_mutex);
 	ret = should_remove_suid(dentry);
 	if (ret)
 		newattrs.ia_valid |= ret | ATTR_FORCE;
 
-	mutex_lock(&dentry->d_inode->i_mutex);
 	ret = notify_change(dentry, &newattrs);
 	mutex_unlock(&dentry->d_inode->i_mutex);
 	return ret;

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Tue, May 21, 2013 at 10:56:05PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:16:03AM +1000, Dave Chinner wrote:
> 
> Seems like I can trigger this from paths other than truncate too.. (eg, sys_open)

O_TRUNC?

> The mask is always 0xa068 though if that helps.

A bit - it confirms what I thought - a truncate killing SUID bits.
i.e. mask = ATTR_FORCE|ATTR_KILL_SUID|ATTR_CTIME|ATTR_SIZE.

But then here's the next question - where the hell is the ATTR_MODE
bit?  In do_truncate(), the should_remove_suid() return is or'd into
the mask along with ATTR_FORCE. The ATTR_KILL_SUID is returned after
this check:

        umode_t mode = dentry->d_inode->i_mode;
        int kill = 0;

        /* suid always must be killed */
        if (unlikely(mode & S_ISUID))
                kill = ATTR_KILL_SUID;

However, notify_change() takes this mask and the inode and does this
when the ATTR_KILL_SUID flag is set:

	umode_t mode = inode->i_mode;
...
        if (ia_valid & ATTR_KILL_SUID) {
                if (mode & S_ISUID) {
                        ia_valid = attr->ia_valid |= ATTR_MODE;
                        attr->ia_mode = (inode->i_mode & ~S_ISUID);
                }
        }


So, we know that (mode & S_ISUID) is true, because that's how
ATTR_KILL_SUID gets set, but that same check here doesn't result
in ATTR_MODE being set....

That doesn't make a whole lot of sense to me. What am I missing?
Are you seeing this fire at all from notify_change()?

	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));

<Light Bulb>

What's wrong with this code in do_truncate()?

        /* Remove suid/sgid on truncate too */
        ret = should_remove_suid(dentry);
        if (ret)
                newattrs.ia_valid |= ret | ATTR_FORCE;

        mutex_lock(&dentry->d_inode->i_mutex);
        ret = notify_change(dentry, &newattrs);
        mutex_unlock(&dentry->d_inode->i_mutex);

Patch below to fix this.

However, it probably doesn't fix the fact that truncate can change
the size and kill suid/sgid bits at the same time and XFS doesn't
appear to handle that sanely right now. Can you run the patch below
just so when it fails we can see that the mask is actually sane?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

vfs: do_truncate() needs to serialise should_remove_suid

From: Dave Chinner <dchinner@redhat.com>

Otherwise someone else can come in an remove the suid bit before the
truncate locks the inode and calls notify_change(). This results in
XFS throwing asserts because it's getting a strange attr mask being
passed down to it that it doesn't know how to handle correctly.

Signed-off-by: Dave Chinner <dchinner@redhat.com>

---
 fs/open.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index 8c74100..b8d4899 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -52,11 +52,11 @@ int do_truncate(struct dentry *dentry, loff_t length, unsigned int time_attrs,
 	}
 
 	/* Remove suid/sgid on truncate too */
+	mutex_lock(&dentry->d_inode->i_mutex);
 	ret = should_remove_suid(dentry);
 	if (ret)
 		newattrs.ia_valid |= ret | ATTR_FORCE;
 
-	mutex_lock(&dentry->d_inode->i_mutex);
 	ret = notify_change(dentry, &newattrs);
 	mutex_unlock(&dentry->d_inode->i_mutex);
 	return ret;

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 02:03:18PM +1000, Dave Chinner wrote:

 > That doesn't make a whole lot of sense to me. What am I missing?
 > Are you seeing this fire at all from notify_change()?
 > 
 > 	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));

No.
 
 > <Light Bulb>
 > 
 > What's wrong with this code in do_truncate()?
 > 
 >         /* Remove suid/sgid on truncate too */
 >         ret = should_remove_suid(dentry);
 >         if (ret)
 >                 newattrs.ia_valid |= ret | ATTR_FORCE;
 > 
 >         mutex_lock(&dentry->d_inode->i_mutex);
 >         ret = notify_change(dentry, &newattrs);
 >         mutex_unlock(&dentry->d_inode->i_mutex);
 > 
 > Patch below to fix this.
 > 
 > However, it probably doesn't fix the fact that truncate can change
 > the size and kill suid/sgid bits at the same time and XFS doesn't
 > appear to handle that sanely right now. Can you run the patch below
 > just so when it fails we can see that the mask is actually sane?

[   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff

[   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
[   36.359459] ------------[ cut here ]------------
[   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
[   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
[   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
[   36.432814] task: ffff880233e24980 ti: ffff88022dd3a000 task.ti: ffff88022dd3a000
[   36.442191] RIP: 0010:[<ffffffffa01be182>]  [<ffffffffa01be182>] assfail+0x22/0x30 [xfs]
[   36.452369] RSP: 0018:ffff88022dd3b7d8  EFLAGS: 00010292
[   36.459027] RAX: 000000000000003c RBX: ffff88022d8198c0 RCX: 0000000000000006
[   36.467968] RDX: 0000000000004040 RSI: ffff880233e250d8 RDI: ffff880233e24980
[   36.476909] RBP: ffff88022dd3b7d8 R08: 0000000000000000 R09: 0000000000000000
[   36.485851] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022dd3bca8
[   36.494793] R13: ffff880241158948 R14: 0000000000000000 R15: 0000000000000000
[   36.503729] FS:  00007f1f4f9c3800(0000) GS:ffff880244a00000(0000) knlGS:0000000000000000
[   36.513858] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   36.521053] CR2: 00000000007c0360 CR3: 000000022dfb2000 CR4: 00000000001407e0
[   36.529986] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   36.538918] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   36.547851] Stack:
[   36.550373]  ffff88022dd3bc48 ffffffffa01bc3ef 0000000000000046 0000a06881c94d18
[   36.559738]  ffff88022d819b80 ffff88022dadf2e0 00007fff0000a068 0000000000000000
[   36.569091]  ffff88022dd3b830 ffffffff824fc100 00007fff2cd12300 ffff88022dd3b848
[   36.578436] Call Trace:
[   36.581514]  [<ffffffffa01bc3ef>] xfs_setattr_size+0x48f/0x630 [xfs]
[   36.589475]  [<ffffffff810c86ef>] ? is_module_text_address+0x2f/0x60
[   36.597433]  [<ffffffff810774a8>] ? __kernel_text_address+0x58/0x80
[   36.605279]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.612801]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.620103]  [<ffffffff810b69c5>] ? __lock_acquire+0x2e5/0x1af0
[   36.627548]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.635069]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.642591]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.649895]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.657417]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.664947]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.672468]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.679765]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.687068]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.694590]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.701894]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.709417]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.716722]  [<ffffffff810b61ab>] ? mark_held_locks+0xbb/0x140
[   36.724027]  [<ffffffff816e634a>] ? mutex_lock_nested+0x32a/0x430
[   36.731659]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   36.738533]  [<ffffffffa01bc5c6>] xfs_vn_setattr+0x36/0x40 [xfs]
[   36.746047]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
[   36.753024]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
[   36.759574]  [<ffffffffa01ae0a0>] ? xfs_extent_busy_ag_cmp+0x20/0x20 [xfs]
[   36.768182]  [<ffffffff811bb4af>] do_last+0x54f/0xe40
[   36.775319]  [<ffffffff811bbe53>] path_openat+0xb3/0x530
[   36.782780]  [<ffffffff810b3951>] ? lock_release_holdtime.part.30+0xa1/0x170
[   36.792408]  [<ffffffff811bc958>] do_filp_open+0x38/0x80
[   36.799870]  [<ffffffff816ea961>] ? _raw_spin_unlock+0x31/0x60
[   36.807981]  [<ffffffff811cb49f>] ? __alloc_fd+0xaf/0x200
[   36.815544]  [<ffffffff811aae19>] do_sys_open+0xe9/0x1c0
[   36.822989]  [<ffffffff811aaf0e>] SyS_open+0x1e/0x20

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 02:03:18PM +1000, Dave Chinner wrote:

 > That doesn't make a whole lot of sense to me. What am I missing?
 > Are you seeing this fire at all from notify_change()?
 > 
 > 	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));

No.
 
 > <Light Bulb>
 > 
 > What's wrong with this code in do_truncate()?
 > 
 >         /* Remove suid/sgid on truncate too */
 >         ret = should_remove_suid(dentry);
 >         if (ret)
 >                 newattrs.ia_valid |= ret | ATTR_FORCE;
 > 
 >         mutex_lock(&dentry->d_inode->i_mutex);
 >         ret = notify_change(dentry, &newattrs);
 >         mutex_unlock(&dentry->d_inode->i_mutex);
 > 
 > Patch below to fix this.
 > 
 > However, it probably doesn't fix the fact that truncate can change
 > the size and kill suid/sgid bits at the same time and XFS doesn't
 > appear to handle that sanely right now. Can you run the patch below
 > just so when it fails we can see that the mask is actually sane?

[   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff

[   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
[   36.359459] ------------[ cut here ]------------
[   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
[   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
[   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
[   36.432814] task: ffff880233e24980 ti: ffff88022dd3a000 task.ti: ffff88022dd3a000
[   36.442191] RIP: 0010:[<ffffffffa01be182>]  [<ffffffffa01be182>] assfail+0x22/0x30 [xfs]
[   36.452369] RSP: 0018:ffff88022dd3b7d8  EFLAGS: 00010292
[   36.459027] RAX: 000000000000003c RBX: ffff88022d8198c0 RCX: 0000000000000006
[   36.467968] RDX: 0000000000004040 RSI: ffff880233e250d8 RDI: ffff880233e24980
[   36.476909] RBP: ffff88022dd3b7d8 R08: 0000000000000000 R09: 0000000000000000
[   36.485851] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022dd3bca8
[   36.494793] R13: ffff880241158948 R14: 0000000000000000 R15: 0000000000000000
[   36.503729] FS:  00007f1f4f9c3800(0000) GS:ffff880244a00000(0000) knlGS:0000000000000000
[   36.513858] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   36.521053] CR2: 00000000007c0360 CR3: 000000022dfb2000 CR4: 00000000001407e0
[   36.529986] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   36.538918] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   36.547851] Stack:
[   36.550373]  ffff88022dd3bc48 ffffffffa01bc3ef 0000000000000046 0000a06881c94d18
[   36.559738]  ffff88022d819b80 ffff88022dadf2e0 00007fff0000a068 0000000000000000
[   36.569091]  ffff88022dd3b830 ffffffff824fc100 00007fff2cd12300 ffff88022dd3b848
[   36.578436] Call Trace:
[   36.581514]  [<ffffffffa01bc3ef>] xfs_setattr_size+0x48f/0x630 [xfs]
[   36.589475]  [<ffffffff810c86ef>] ? is_module_text_address+0x2f/0x60
[   36.597433]  [<ffffffff810774a8>] ? __kernel_text_address+0x58/0x80
[   36.605279]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.612801]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.620103]  [<ffffffff810b69c5>] ? __lock_acquire+0x2e5/0x1af0
[   36.627548]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.635069]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.642591]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.649895]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.657417]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.664947]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.672468]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.679765]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.687068]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.694590]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.701894]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   36.709417]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   36.716722]  [<ffffffff810b61ab>] ? mark_held_locks+0xbb/0x140
[   36.724027]  [<ffffffff816e634a>] ? mutex_lock_nested+0x32a/0x430
[   36.731659]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   36.738533]  [<ffffffffa01bc5c6>] xfs_vn_setattr+0x36/0x40 [xfs]
[   36.746047]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
[   36.753024]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
[   36.759574]  [<ffffffffa01ae0a0>] ? xfs_extent_busy_ag_cmp+0x20/0x20 [xfs]
[   36.768182]  [<ffffffff811bb4af>] do_last+0x54f/0xe40
[   36.775319]  [<ffffffff811bbe53>] path_openat+0xb3/0x530
[   36.782780]  [<ffffffff810b3951>] ? lock_release_holdtime.part.30+0xa1/0x170
[   36.792408]  [<ffffffff811bc958>] do_filp_open+0x38/0x80
[   36.799870]  [<ffffffff816ea961>] ? _raw_spin_unlock+0x31/0x60
[   36.807981]  [<ffffffff811cb49f>] ? __alloc_fd+0xaf/0x200
[   36.815544]  [<ffffffff811aae19>] do_sys_open+0xe9/0x1c0
[   36.822989]  [<ffffffff811aaf0e>] SyS_open+0x1e/0x20


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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 12:15:21AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 02:03:18PM +1000, Dave Chinner wrote:
> 
>  > That doesn't make a whole lot of sense to me. What am I missing?
>  > Are you seeing this fire at all from notify_change()?
>  > 
>  > 	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));
> 
> No.
>  
>  > <Light Bulb>
>  > 
>  > What's wrong with this code in do_truncate()?
>  > 
>  >         /* Remove suid/sgid on truncate too */
>  >         ret = should_remove_suid(dentry);
>  >         if (ret)
>  >                 newattrs.ia_valid |= ret | ATTR_FORCE;
>  > 
>  >         mutex_lock(&dentry->d_inode->i_mutex);
>  >         ret = notify_change(dentry, &newattrs);
>  >         mutex_unlock(&dentry->d_inode->i_mutex);
>  > 
>  > Patch below to fix this.
>  > 
>  > However, it probably doesn't fix the fact that truncate can change
>  > the size and kill suid/sgid bits at the same time and XFS doesn't
>  > appear to handle that sanely right now. Can you run the patch below
>  > just so when it fails we can see that the mask is actually sane?
> 
> [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff

So, still the same strange mask. That just doesn't seem right.

> [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
> [   36.359459] ------------[ cut here ]------------
> [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
> [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
> [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4

Your compiler is triggering this? That doesn't seem likely...

> [   36.578436] Call Trace:
> [   36.581514]  [<ffffffffa01bc3ef>] xfs_setattr_size+0x48f/0x630 [xfs]
> [   36.738533]  [<ffffffffa01bc5c6>] xfs_vn_setattr+0x36/0x40 [xfs]
> [   36.746047]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
> [   36.753024]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
> [   36.759574]  [<ffffffffa01ae0a0>] ? xfs_extent_busy_ag_cmp+0x20/0x20 [xfs]
> [   36.768182]  [<ffffffff811bb4af>] do_last+0x54f/0xe40
> [   36.775319]  [<ffffffff811bbe53>] path_openat+0xb3/0x530
> [   36.782780]  [<ffffffff810b3951>] ? lock_release_holdtime.part.30+0xa1/0x170
> [   36.792408]  [<ffffffff811bc958>] do_filp_open+0x38/0x80
> [   36.799870]  [<ffffffff816ea961>] ? _raw_spin_unlock+0x31/0x60
> [   36.807981]  [<ffffffff811cb49f>] ? __alloc_fd+0xaf/0x200
> [   36.815544]  [<ffffffff811aae19>] do_sys_open+0xe9/0x1c0
> [   36.822989]  [<ffffffff811aaf0e>] SyS_open+0x1e/0x20

This has come through the open path via handle_truncate(), which
means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
set in the mask. They aren't, and that says to me that something
else has been blottoed before XFS trips over this. Memory
corruption?

Can you print out the entire struct iattr? perhaps even hexdump it?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 12:15:21AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 02:03:18PM +1000, Dave Chinner wrote:
> 
>  > That doesn't make a whole lot of sense to me. What am I missing?
>  > Are you seeing this fire at all from notify_change()?
>  > 
>  > 	WARN_ON_ONCE(!mutex_is_locked(&inode->i_mutex));
> 
> No.
>  
>  > <Light Bulb>
>  > 
>  > What's wrong with this code in do_truncate()?
>  > 
>  >         /* Remove suid/sgid on truncate too */
>  >         ret = should_remove_suid(dentry);
>  >         if (ret)
>  >                 newattrs.ia_valid |= ret | ATTR_FORCE;
>  > 
>  >         mutex_lock(&dentry->d_inode->i_mutex);
>  >         ret = notify_change(dentry, &newattrs);
>  >         mutex_unlock(&dentry->d_inode->i_mutex);
>  > 
>  > Patch below to fix this.
>  > 
>  > However, it probably doesn't fix the fact that truncate can change
>  > the size and kill suid/sgid bits at the same time and XFS doesn't
>  > appear to handle that sanely right now. Can you run the patch below
>  > just so when it fails we can see that the mask is actually sane?
> 
> [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff

So, still the same strange mask. That just doesn't seem right.

> [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
> [   36.359459] ------------[ cut here ]------------
> [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
> [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
> [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4

Your compiler is triggering this? That doesn't seem likely...

> [   36.578436] Call Trace:
> [   36.581514]  [<ffffffffa01bc3ef>] xfs_setattr_size+0x48f/0x630 [xfs]
> [   36.738533]  [<ffffffffa01bc5c6>] xfs_vn_setattr+0x36/0x40 [xfs]
> [   36.746047]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
> [   36.753024]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
> [   36.759574]  [<ffffffffa01ae0a0>] ? xfs_extent_busy_ag_cmp+0x20/0x20 [xfs]
> [   36.768182]  [<ffffffff811bb4af>] do_last+0x54f/0xe40
> [   36.775319]  [<ffffffff811bbe53>] path_openat+0xb3/0x530
> [   36.782780]  [<ffffffff810b3951>] ? lock_release_holdtime.part.30+0xa1/0x170
> [   36.792408]  [<ffffffff811bc958>] do_filp_open+0x38/0x80
> [   36.799870]  [<ffffffff816ea961>] ? _raw_spin_unlock+0x31/0x60
> [   36.807981]  [<ffffffff811cb49f>] ? __alloc_fd+0xaf/0x200
> [   36.815544]  [<ffffffff811aae19>] do_sys_open+0xe9/0x1c0
> [   36.822989]  [<ffffffff811aaf0e>] SyS_open+0x1e/0x20

This has come through the open path via handle_truncate(), which
means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
set in the mask. They aren't, and that says to me that something
else has been blottoed before XFS trips over this. Memory
corruption?

Can you print out the entire struct iattr? perhaps even hexdump it?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:

 > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
 > 
 > So, still the same strange mask. That just doesn't seem right.

any idea what I screwed up in the filename printing part ?
 
 > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
 > > [   36.359459] ------------[ cut here ]------------
 > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
 > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
 > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
 > 
 > Your compiler is triggering this? That doesn't seem likely...

yeah, though it seems pretty much anything that writes to that partition will cause it.
Here's fsx, which died instantly...

[   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02

(Note, different mask this time)


[   34.948754] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
[   34.957305] ------------[ cut here ]------------
[   34.963093] kernel BUG at fs/xfs/xfs_message.c:108!
[   34.969202] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   34.976916] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device e1000e snd_pcm snd_page_alloc snd_timer ptp snd pps_core soundcore
[   35.003254] CPU: 2 PID: 603 Comm: fsx Not tainted 3.10.0-rc2+ #4
[   35.030365] task: ffff8802346824c0 ti: ffff880234318000 task.ti: ffff880234318000
[   35.039733] RIP: 0010:[<ffffffffa01db182>]  [<ffffffffa01db182>] assfail+0x22/0x30 [xfs]
[   35.049897] RSP: 0018:ffff8802343199f0  EFLAGS: 00010286
[   35.056547] RAX: 000000000000003c RBX: ffff8802348af380 RCX: 0000000000000006
[   35.065480] RDX: 00000000000040b0 RSI: ffff880234682c18 RDI: ffff8802346824c0
[   35.074411] RBP: ffff8802343199f0 R08: 0000000000000000 R09: 0000000000000000
[   35.083349] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880234319ec0
[   35.092310] R13: ffff880241171bd8 R14: 0000000000000000 R15: 0000000000000000
[   35.101258] FS:  00007fea1197a740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
[   35.111397] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.118603] CR2: 0000003159cee0b0 CR3: 00000002339bc000 CR4: 00000000001407e0
[   35.127536] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.136467] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.145399] Stack:
[   35.147919]  ffff880234319e60 ffffffffa01d93ef 00000000816eaa35 0000206800000063
[   35.157258]  ffff8802348af640 ffff88023483cb90 ffff880200002068 ffffffff8100a394
[   35.166630]  0000000000000002 ffff880234319a60 ffffffff810916a5 0000000000000002
[   35.176002] Call Trace:
[   35.179112]  [<ffffffffa01d93ef>] xfs_setattr_size+0x48f/0x630 [xfs]
[   35.187071]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.194595]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.201900]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.209418]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.216724]  [<ffffffff810b69c5>] ? __lock_acquire+0x2e5/0x1af0
[   35.224134]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.231656]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.238961]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.245832]  [<ffffffff816ef211>] ? sub_preempt_count+0x71/0x100
[   35.253353]  [<ffffffff813080f0>] ? delay_tsc+0x90/0xe0
[   35.259895]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.267414]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.274718]  [<ffffffff810b33ce>] ? put_lock_stats.isra.29+0xe/0x40
[   35.282564]  [<ffffffff810b399e>] ? lock_release_holdtime.part.30+0xee/0x170
[   35.291387]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.298908]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.306211]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.313731]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.321045]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.327913]  [<ffffffff810b61ab>] ? mark_held_locks+0xbb/0x140
[   35.335216]  [<ffffffff816e634a>] ? mutex_lock_nested+0x32a/0x430
[   35.342844]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.349714]  [<ffffffff816ef211>] ? sub_preempt_count+0x71/0x100
[   35.357241]  [<ffffffffa01d95c6>] xfs_vn_setattr+0x36/0x40 [xfs]
[   35.364763]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
[   35.371741]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
[   35.378284]  [<ffffffff811aa0ee>] do_sys_ftruncate.constprop.16+0x10e/0x160
[   35.387883]  [<ffffffff811aa17e>] SyS_ftruncate+0xe/0x10
[   35.395390]  [<ffffffff816f3714>] tracesys+0xdd/0xe2
[   35.402440] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 89 e5 48 89 fa 48 c7 c6 18 87 26 a0 31 ff 31 c0 e8 ce fb ff ff <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 
[   35.429006] RIP  [<ffffffffa01db182>] assfail+0x22/0x30 [xfs]
[   35.437088]  RSP <ffff8802343199f0>

 > This has come through the open path via handle_truncate(), which
 > means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
 > set in the mask. They aren't, and that says to me that something
 > else has been blottoed before XFS trips over this. Memory
 > corruption?
 >
 > Can you print out the entire struct iattr? perhaps even hexdump it?

About to turn in for the night. If there's a shiny diff in my inbox in the morning,
I'll try it.

Tomorrow I'll also try running some older kernels with the same options to see if it's
something new, or an older bug. This is a new machine, so it may be something
that's been around for a while, and for whatever reason, my other machines don't hit this.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:

 > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
 > 
 > So, still the same strange mask. That just doesn't seem right.

any idea what I screwed up in the filename printing part ?
 
 > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
 > > [   36.359459] ------------[ cut here ]------------
 > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
 > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
 > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
 > 
 > Your compiler is triggering this? That doesn't seem likely...

yeah, though it seems pretty much anything that writes to that partition will cause it.
Here's fsx, which died instantly...

[   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02

(Note, different mask this time)


[   34.948754] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
[   34.957305] ------------[ cut here ]------------
[   34.963093] kernel BUG at fs/xfs/xfs_message.c:108!
[   34.969202] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   34.976916] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device e1000e snd_pcm snd_page_alloc snd_timer ptp snd pps_core soundcore
[   35.003254] CPU: 2 PID: 603 Comm: fsx Not tainted 3.10.0-rc2+ #4
[   35.030365] task: ffff8802346824c0 ti: ffff880234318000 task.ti: ffff880234318000
[   35.039733] RIP: 0010:[<ffffffffa01db182>]  [<ffffffffa01db182>] assfail+0x22/0x30 [xfs]
[   35.049897] RSP: 0018:ffff8802343199f0  EFLAGS: 00010286
[   35.056547] RAX: 000000000000003c RBX: ffff8802348af380 RCX: 0000000000000006
[   35.065480] RDX: 00000000000040b0 RSI: ffff880234682c18 RDI: ffff8802346824c0
[   35.074411] RBP: ffff8802343199f0 R08: 0000000000000000 R09: 0000000000000000
[   35.083349] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880234319ec0
[   35.092310] R13: ffff880241171bd8 R14: 0000000000000000 R15: 0000000000000000
[   35.101258] FS:  00007fea1197a740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
[   35.111397] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.118603] CR2: 0000003159cee0b0 CR3: 00000002339bc000 CR4: 00000000001407e0
[   35.127536] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.136467] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.145399] Stack:
[   35.147919]  ffff880234319e60 ffffffffa01d93ef 00000000816eaa35 0000206800000063
[   35.157258]  ffff8802348af640 ffff88023483cb90 ffff880200002068 ffffffff8100a394
[   35.166630]  0000000000000002 ffff880234319a60 ffffffff810916a5 0000000000000002
[   35.176002] Call Trace:
[   35.179112]  [<ffffffffa01d93ef>] xfs_setattr_size+0x48f/0x630 [xfs]
[   35.187071]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.194595]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.201900]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.209418]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.216724]  [<ffffffff810b69c5>] ? __lock_acquire+0x2e5/0x1af0
[   35.224134]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.231656]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.238961]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.245832]  [<ffffffff816ef211>] ? sub_preempt_count+0x71/0x100
[   35.253353]  [<ffffffff813080f0>] ? delay_tsc+0x90/0xe0
[   35.259895]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.267414]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.274718]  [<ffffffff810b33ce>] ? put_lock_stats.isra.29+0xe/0x40
[   35.282564]  [<ffffffff810b399e>] ? lock_release_holdtime.part.30+0xee/0x170
[   35.291387]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.298908]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.306211]  [<ffffffff8100a394>] ? native_sched_clock+0x24/0x80
[   35.313731]  [<ffffffff810916a5>] ? sched_clock_cpu+0xb5/0x100
[   35.321045]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.327913]  [<ffffffff810b61ab>] ? mark_held_locks+0xbb/0x140
[   35.335216]  [<ffffffff816e634a>] ? mutex_lock_nested+0x32a/0x430
[   35.342844]  [<ffffffff8108c05d>] ? get_parent_ip+0xd/0x50
[   35.349714]  [<ffffffff816ef211>] ? sub_preempt_count+0x71/0x100
[   35.357241]  [<ffffffffa01d95c6>] xfs_vn_setattr+0x36/0x40 [xfs]
[   35.364763]  [<ffffffff811c8e2c>] notify_change+0x1dc/0x360
[   35.371741]  [<ffffffff811a9d9d>] do_truncate+0x6d/0xa0
[   35.378284]  [<ffffffff811aa0ee>] do_sys_ftruncate.constprop.16+0x10e/0x160
[   35.387883]  [<ffffffff811aa17e>] SyS_ftruncate+0xe/0x10
[   35.395390]  [<ffffffff816f3714>] tracesys+0xdd/0xe2
[   35.402440] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 89 e5 48 89 fa 48 c7 c6 18 87 26 a0 31 ff 31 c0 e8 ce fb ff ff <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 
[   35.429006] RIP  [<ffffffffa01db182>] assfail+0x22/0x30 [xfs]
[   35.437088]  RSP <ffff8802343199f0>

 > This has come through the open path via handle_truncate(), which
 > means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
 > set in the mask. They aren't, and that says to me that something
 > else has been blottoed before XFS trips over this. Memory
 > corruption?
 >
 > Can you print out the entire struct iattr? perhaps even hexdump it?

About to turn in for the night. If there's a shiny diff in my inbox in the morning,
I'll try it.

Tomorrow I'll also try running some older kernels with the same options to see if it's
something new, or an older bug. This is a new machine, so it may be something
that's been around for a while, and for whatever reason, my other machines don't hit this.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
> 
>  > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
>  > 
>  > So, still the same strange mask. That just doesn't seem right.
> 
> any idea what I screwed up in the filename printing part ?

Nope.

Right now, I have nothing for you but disappointment....

>  > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
>  > > [   36.359459] ------------[ cut here ]------------
>  > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
>  > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>  > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
>  > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
>  > 
>  > Your compiler is triggering this? That doesn't seem likely...
> 
> yeah, though it seems pretty much anything that writes to that partition will cause it.
> Here's fsx, which died instantly...
> 
> [   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02
> 
> (Note, different mask this time)

Which has ATTR_FORCE set but not ATTR_KILL_SUID or ATTR_KILL_SGID.
And that, AFAICT, is impossible.

>  > This has come through the open path via handle_truncate(), which
>  > means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
>  > set in the mask. They aren't, and that says to me that something
>  > else has been blottoed before XFS trips over this. Memory
>  > corruption?
>  >
>  > Can you print out the entire struct iattr? perhaps even hexdump it?
> 
> About to turn in for the night. If there's a shiny diff in my inbox in the morning,
> I'll try it.

I wouldn't lose sleep over it - I'm stumped at this point. I'll get
a working path print to you, at minimum...

> Tomorrow I'll also try running some older kernels with the same
> options to see if it's something new, or an older bug. This is a
> new machine, so it may be something that's been around for a
> while, and for whatever reason, my other machines don't hit
> this.

Another thing that just occurred to me - what compiler are you
using?  We had a report last week on #xfs that xfsdump was failing
with bad checksums because of link time optimisation (LTO) in
gcc-4.8.0. When they turned that off, everything worked fine. So if
you are using 4.8.0, perhaps trying a different compiler might be a
good idea, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
> 
>  > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
>  > 
>  > So, still the same strange mask. That just doesn't seem right.
> 
> any idea what I screwed up in the filename printing part ?

Nope.

Right now, I have nothing for you but disappointment....

>  > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
>  > > [   36.359459] ------------[ cut here ]------------
>  > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
>  > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>  > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
>  > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
>  > 
>  > Your compiler is triggering this? That doesn't seem likely...
> 
> yeah, though it seems pretty much anything that writes to that partition will cause it.
> Here's fsx, which died instantly...
> 
> [   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02
> 
> (Note, different mask this time)

Which has ATTR_FORCE set but not ATTR_KILL_SUID or ATTR_KILL_SGID.
And that, AFAICT, is impossible.

>  > This has come through the open path via handle_truncate(), which
>  > means that ATTR_MTIME|ATTR_CTIME|ATTR_OPEN|ATTR_FILE should also be
>  > set in the mask. They aren't, and that says to me that something
>  > else has been blottoed before XFS trips over this. Memory
>  > corruption?
>  >
>  > Can you print out the entire struct iattr? perhaps even hexdump it?
> 
> About to turn in for the night. If there's a shiny diff in my inbox in the morning,
> I'll try it.

I wouldn't lose sleep over it - I'm stumped at this point. I'll get
a working path print to you, at minimum...

> Tomorrow I'll also try running some older kernels with the same
> options to see if it's something new, or an older bug. This is a
> new machine, so it may be something that's been around for a
> while, and for whatever reason, my other machines don't hit
> this.

Another thing that just occurred to me - what compiler are you
using?  We had a report last week on #xfs that xfsdump was failing
with bad checksums because of link time optimisation (LTO) in
gcc-4.8.0. When they turned that off, everything worked fine. So if
you are using 4.8.0, perhaps trying a different compiler might be a
good idea, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:

 > > Tomorrow I'll also try running some older kernels with the same
 > > options to see if it's something new, or an older bug. This is a
 > > new machine, so it may be something that's been around for a
 > > while, and for whatever reason, my other machines don't hit
 > > this.
 > 
 > Another thing that just occurred to me - what compiler are you
 > using?  We had a report last week on #xfs that xfsdump was failing
 > with bad checksums because of link time optimisation (LTO) in
 > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > you are using 4.8.0, perhaps trying a different compiler might be a
 > good idea, too.

Yeah, this is 4.8.0. This box is running F19-beta. 
I managed to shoehorn the gcc-4.7 from f18 on there though.
Bug reproduced instantly, so I think we can rule out compiler.

I ran 3.9 with the same debug options. Seems stable.
I'll do a bisect.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:

 > > Tomorrow I'll also try running some older kernels with the same
 > > options to see if it's something new, or an older bug. This is a
 > > new machine, so it may be something that's been around for a
 > > while, and for whatever reason, my other machines don't hit
 > > this.
 > 
 > Another thing that just occurred to me - what compiler are you
 > using?  We had a report last week on #xfs that xfsdump was failing
 > with bad checksums because of link time optimisation (LTO) in
 > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > you are using 4.8.0, perhaps trying a different compiler might be a
 > good idea, too.

Yeah, this is 4.8.0. This box is running F19-beta. 
I managed to shoehorn the gcc-4.7 from f18 on there though.
Bug reproduced instantly, so I think we can rule out compiler.

I ran 3.9 with the same debug options. Seems stable.
I'll do a bisect.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > 
 >  > > Tomorrow I'll also try running some older kernels with the same
 >  > > options to see if it's something new, or an older bug. This is a
 >  > > new machine, so it may be something that's been around for a
 >  > > while, and for whatever reason, my other machines don't hit
 >  > > this.
 >  > 
 >  > Another thing that just occurred to me - what compiler are you
 >  > using?  We had a report last week on #xfs that xfsdump was failing
 >  > with bad checksums because of link time optimisation (LTO) in
 >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 >  > you are using 4.8.0, perhaps trying a different compiler might be a
 >  > good idea, too.
 > 
 > Yeah, this is 4.8.0. This box is running F19-beta. 
 > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > Bug reproduced instantly, so I think we can rule out compiler.
 > 
 > I ran 3.9 with the same debug options. Seems stable.
 > I'll do a bisect.

good news.  It wasn't until I started bisecting I realised I was still
carrying this patch from you to fix slab corruption I was seeing.

It seems to be the culprit (or is masking another problem -- I had to apply
it at each step of the bisect to get past the slab corruption bug).

	Dave

--- /home/davej/src/kernel/git-trees/linux/fs/xfs/xfs_extfree_item.c	2013-05-03 10:03:05.331370231 -0400
+++ linux-dj/fs/xfs/xfs_extfree_item.c	2013-05-07 20:46:42.389262296 -0400
@@ -305,10 +305,22 @@ xfs_efi_release(xfs_efi_log_item_t	*efip
 {
 	ASSERT(atomic_read(&efip->efi_next_extent) >= nextents);
 	if (atomic_sub_and_test(nextents, &efip->efi_next_extent)) {
+		int recovered;
+
+		/*
+		 * __xfs_efi_release() can release the last reference to the EFI
+		 * and free it, so it is unsafe to reference it after we've
+		 * released the reference. The only case this is safe to do is
+		 * if we are in recovery and the XFS_EFI_RECOVERED bit is set,
+		 * meaning that we have two references to release. Check the
+		 * recovered bit before the initial release, as we cannot
+		 * reliably check it afterwards.
+		 */
+		recovered = test_bit(XFS_EFI_RECOVERED, &efip->efi_flags);
 		__xfs_efi_release(efip);
 
 		/* recovery needs us to drop the EFI reference, too */
-		if (test_bit(XFS_EFI_RECOVERED, &efip->efi_flags))
+		if (recovered)
 			__xfs_efi_release(efip);
 	}
 }

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > 
 >  > > Tomorrow I'll also try running some older kernels with the same
 >  > > options to see if it's something new, or an older bug. This is a
 >  > > new machine, so it may be something that's been around for a
 >  > > while, and for whatever reason, my other machines don't hit
 >  > > this.
 >  > 
 >  > Another thing that just occurred to me - what compiler are you
 >  > using?  We had a report last week on #xfs that xfsdump was failing
 >  > with bad checksums because of link time optimisation (LTO) in
 >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 >  > you are using 4.8.0, perhaps trying a different compiler might be a
 >  > good idea, too.
 > 
 > Yeah, this is 4.8.0. This box is running F19-beta. 
 > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > Bug reproduced instantly, so I think we can rule out compiler.
 > 
 > I ran 3.9 with the same debug options. Seems stable.
 > I'll do a bisect.

good news.  It wasn't until I started bisecting I realised I was still
carrying this patch from you to fix slab corruption I was seeing.

It seems to be the culprit (or is masking another problem -- I had to apply
it at each step of the bisect to get past the slab corruption bug).

	Dave

--- /home/davej/src/kernel/git-trees/linux/fs/xfs/xfs_extfree_item.c	2013-05-03 10:03:05.331370231 -0400
+++ linux-dj/fs/xfs/xfs_extfree_item.c	2013-05-07 20:46:42.389262296 -0400
@@ -305,10 +305,22 @@ xfs_efi_release(xfs_efi_log_item_t	*efip
 {
 	ASSERT(atomic_read(&efip->efi_next_extent) >= nextents);
 	if (atomic_sub_and_test(nextents, &efip->efi_next_extent)) {
+		int recovered;
+
+		/*
+		 * __xfs_efi_release() can release the last reference to the EFI
+		 * and free it, so it is unsafe to reference it after we've
+		 * released the reference. The only case this is safe to do is
+		 * if we are in recovery and the XFS_EFI_RECOVERED bit is set,
+		 * meaning that we have two references to release. Check the
+		 * recovered bit before the initial release, as we cannot
+		 * reliably check it afterwards.
+		 */
+		recovered = test_bit(XFS_EFI_RECOVERED, &efip->efi_flags);
 		__xfs_efi_release(efip);
 
 		/* recovery needs us to drop the EFI reference, too */
-		if (test_bit(XFS_EFI_RECOVERED, &efip->efi_flags))
+		if (recovered)
 			__xfs_efi_release(efip);
 	}
 }

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
> On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> > On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
> > 
> >  > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
> >  > 
> >  > So, still the same strange mask. That just doesn't seem right.
> > 
> > any idea what I screwed up in the filename printing part ?
> 
> Nope.
> 
> Right now, I have nothing for you but disappointment....
> 
> >  > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
> >  > > [   36.359459] ------------[ cut here ]------------
> >  > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
> >  > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >  > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
> >  > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
> >  > 
> >  > Your compiler is triggering this? That doesn't seem likely...
> > 
> > yeah, though it seems pretty much anything that writes to that partition will cause it.
> > Here's fsx, which died instantly...
> > 
> > [   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02
> > 
> > (Note, different mask this time)
> 
> Which has ATTR_FORCE set but not ATTR_KILL_SUID or ATTR_KILL_SGID.
> And that, AFAICT, is impossible.

Gah, I've got not idea what the hell I was smoking yesterday
afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.

So a mask of 0xa068 is correct and valid from the open path, and
0x2068 is just file from the truncate path.

But, neither of those should trigger that assert. indeed, on a test
kernel (3.10-rc2 based):

# echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
[  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
#

And there's not assert failure. Indeed, the "masked # 0x0" is what
the assert is checking.

And yeah, path output works. Trick for anyone who doesn't read the
code closely - the buffer is filled from the end backwards, and the
start of the path is the return variable. So, the above code is:

	{
		struct dentry *d = d_find_alias(VFS_I(ip));
		char buf[MAXPATHLEN];
		char *ptr;

		memset(buf, 0, MAXPATHLEN);
		ptr = dentry_path(d, buf, MAXPATHLEN);
		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
			__func__, mask,
	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
			ip, d, ptr);
		dput(d);
	}

Which I put just before the assert that is firing on your machine.

And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
mask of 0xa068.

Gah, what a mess. Sorry for the run-around, Dave, my brain clearly
wasn't working yesterday afternoon.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
> On Wed, May 22, 2013 at 01:29:38AM -0400, Dave Jones wrote:
> > On Wed, May 22, 2013 at 03:12:43PM +1000, Dave Chinner wrote:
> > 
> >  > > [   36.339105] XFS (sda2): xfs_setattr_size: mask 0xa068 mismatch on file 0\xffffffb8\xffffffd3-\x02\xffffff88\xffffffff\xffffffff
> >  > 
> >  > So, still the same strange mask. That just doesn't seem right.
> > 
> > any idea what I screwed up in the filename printing part ?
> 
> Nope.
> 
> Right now, I have nothing for you but disappointment....
> 
> >  > > [   36.350823] XFS: Assertion failed: 0, file: fs/xfs/xfs_iops.c, line: 730
> >  > > [   36.359459] ------------[ cut here ]------------
> >  > > [   36.365247] kernel BUG at fs/xfs/xfs_message.c:108!
> >  > > [   36.371360] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >  > > [   36.379091] Modules linked in: xfs libcrc32c snd_hda_codec_realtek snd_hda_codec_hdmi microcode(+) pcspkr snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd soundcore pps_core
> >  > > [   36.405431] CPU: 1 PID: 2887 Comm: cc1 Not tainted 3.10.0-rc2+ #4
> >  > 
> >  > Your compiler is triggering this? That doesn't seem likely...
> > 
> > yeah, though it seems pretty much anything that writes to that partition will cause it.
> > Here's fsx, which died instantly...
> > 
> > [   34.938367] XFS (sda2): xfs_setattr_size: mask 0x2068 mismatch on file \x02
> > 
> > (Note, different mask this time)
> 
> Which has ATTR_FORCE set but not ATTR_KILL_SUID or ATTR_KILL_SGID.
> And that, AFAICT, is impossible.

Gah, I've got not idea what the hell I was smoking yesterday
afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.

So a mask of 0xa068 is correct and valid from the open path, and
0x2068 is just file from the truncate path.

But, neither of those should trigger that assert. indeed, on a test
kernel (3.10-rc2 based):

# echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
[  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
#

And there's not assert failure. Indeed, the "masked # 0x0" is what
the assert is checking.

And yeah, path output works. Trick for anyone who doesn't read the
code closely - the buffer is filled from the end backwards, and the
start of the path is the return variable. So, the above code is:

	{
		struct dentry *d = d_find_alias(VFS_I(ip));
		char buf[MAXPATHLEN];
		char *ptr;

		memset(buf, 0, MAXPATHLEN);
		ptr = dentry_path(d, buf, MAXPATHLEN);
		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
			__func__, mask,
	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
			ip, d, ptr);
		dput(d);
	}

Which I put just before the assert that is firing on your machine.

And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
mask of 0xa068.

Gah, what a mess. Sorry for the run-around, Dave, my brain clearly
wasn't working yesterday afternoon.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
>  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
>  > 
>  >  > > Tomorrow I'll also try running some older kernels with the same
>  >  > > options to see if it's something new, or an older bug. This is a
>  >  > > new machine, so it may be something that's been around for a
>  >  > > while, and for whatever reason, my other machines don't hit
>  >  > > this.
>  >  > 
>  >  > Another thing that just occurred to me - what compiler are you
>  >  > using?  We had a report last week on #xfs that xfsdump was failing
>  >  > with bad checksums because of link time optimisation (LTO) in
>  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
>  >  > you are using 4.8.0, perhaps trying a different compiler might be a
>  >  > good idea, too.
>  > 
>  > Yeah, this is 4.8.0. This box is running F19-beta. 
>  > I managed to shoehorn the gcc-4.7 from f18 on there though.
>  > Bug reproduced instantly, so I think we can rule out compiler.
>  > 
>  > I ran 3.9 with the same debug options. Seems stable.
>  > I'll do a bisect.
> 
> good news.  It wasn't until I started bisecting I realised I was still
> carrying this patch from you to fix slab corruption I was seeing.
> 
> It seems to be the culprit (or is masking another problem -- I had to apply
> it at each step of the bisect to get past the slab corruption bug).

That doesn't make a whole lot of sense to me. The fix in the xfsdev
tree is a little different:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d

but I can't set how this makes any difference to the problem at all.
See my previous post about the fact that 0xa068 is actually a valid
mask and should not be tripping the assert....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
> On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
>  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
>  > 
>  >  > > Tomorrow I'll also try running some older kernels with the same
>  >  > > options to see if it's something new, or an older bug. This is a
>  >  > > new machine, so it may be something that's been around for a
>  >  > > while, and for whatever reason, my other machines don't hit
>  >  > > this.
>  >  > 
>  >  > Another thing that just occurred to me - what compiler are you
>  >  > using?  We had a report last week on #xfs that xfsdump was failing
>  >  > with bad checksums because of link time optimisation (LTO) in
>  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
>  >  > you are using 4.8.0, perhaps trying a different compiler might be a
>  >  > good idea, too.
>  > 
>  > Yeah, this is 4.8.0. This box is running F19-beta. 
>  > I managed to shoehorn the gcc-4.7 from f18 on there though.
>  > Bug reproduced instantly, so I think we can rule out compiler.
>  > 
>  > I ran 3.9 with the same debug options. Seems stable.
>  > I'll do a bisect.
> 
> good news.  It wasn't until I started bisecting I realised I was still
> carrying this patch from you to fix slab corruption I was seeing.
> 
> It seems to be the culprit (or is masking another problem -- I had to apply
> it at each step of the bisect to get past the slab corruption bug).

That doesn't make a whole lot of sense to me. The fix in the xfsdev
tree is a little different:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d

but I can't set how this makes any difference to the problem at all.
See my previous post about the fact that 0xa068 is actually a valid
mask and should not be tripping the assert....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > >  > 
 > >  >  > > Tomorrow I'll also try running some older kernels with the same
 > >  >  > > options to see if it's something new, or an older bug. This is a
 > >  >  > > new machine, so it may be something that's been around for a
 > >  >  > > while, and for whatever reason, my other machines don't hit
 > >  >  > > this.
 > >  >  > 
 > >  >  > Another thing that just occurred to me - what compiler are you
 > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 > >  >  > with bad checksums because of link time optimisation (LTO) in
 > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 > >  >  > good idea, too.
 > >  > 
 > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > >  > Bug reproduced instantly, so I think we can rule out compiler.
 > >  > 
 > >  > I ran 3.9 with the same debug options. Seems stable.
 > >  > I'll do a bisect.
 > > 
 > > good news.  It wasn't until I started bisecting I realised I was still
 > > carrying this patch from you to fix slab corruption I was seeing.
 > > 
 > > It seems to be the culprit (or is masking another problem -- I had to apply
 > > it at each step of the bisect to get past the slab corruption bug).
 > 
 > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 > tree is a little different:
 > 
 > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d
 > 
 > but I can't set how this makes any difference to the problem at all.
 > See my previous post about the fact that 0xa068 is actually a valid
 > mask and should not be tripping the assert....

Hmm, I did git bisect fs/xfs/, so maybe itit's something outside of that subdir
that's the cause. I'll start over on the whole tree once I'm done bisecting
another entirely different bug.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > >  > 
 > >  >  > > Tomorrow I'll also try running some older kernels with the same
 > >  >  > > options to see if it's something new, or an older bug. This is a
 > >  >  > > new machine, so it may be something that's been around for a
 > >  >  > > while, and for whatever reason, my other machines don't hit
 > >  >  > > this.
 > >  >  > 
 > >  >  > Another thing that just occurred to me - what compiler are you
 > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 > >  >  > with bad checksums because of link time optimisation (LTO) in
 > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 > >  >  > good idea, too.
 > >  > 
 > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > >  > Bug reproduced instantly, so I think we can rule out compiler.
 > >  > 
 > >  > I ran 3.9 with the same debug options. Seems stable.
 > >  > I'll do a bisect.
 > > 
 > > good news.  It wasn't until I started bisecting I realised I was still
 > > carrying this patch from you to fix slab corruption I was seeing.
 > > 
 > > It seems to be the culprit (or is masking another problem -- I had to apply
 > > it at each step of the bisect to get past the slab corruption bug).
 > 
 > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 > tree is a little different:
 > 
 > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d
 > 
 > but I can't set how this makes any difference to the problem at all.
 > See my previous post about the fact that 0xa068 is actually a valid
 > mask and should not be tripping the assert....

Hmm, I did git bisect fs/xfs/, so maybe itit's something outside of that subdir
that's the cause. I'll start over on the whole tree once I'm done bisecting
another entirely different bug.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > >  > 
 > >  >  > > Tomorrow I'll also try running some older kernels with the same
 > >  >  > > options to see if it's something new, or an older bug. This is a
 > >  >  > > new machine, so it may be something that's been around for a
 > >  >  > > while, and for whatever reason, my other machines don't hit
 > >  >  > > this.
 > >  >  > 
 > >  >  > Another thing that just occurred to me - what compiler are you
 > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 > >  >  > with bad checksums because of link time optimisation (LTO) in
 > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 > >  >  > good idea, too.
 > >  > 
 > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > >  > Bug reproduced instantly, so I think we can rule out compiler.
 > >  > 
 > >  > I ran 3.9 with the same debug options. Seems stable.
 > >  > I'll do a bisect.
 > > 
 > > good news.  It wasn't until I started bisecting I realised I was still
 > > carrying this patch from you to fix slab corruption I was seeing.
 > > 
 > > It seems to be the culprit (or is masking another problem -- I had to apply
 > > it at each step of the bisect to get past the slab corruption bug).
 > 
 > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 > tree is a little different:
 > 
 > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d

I did an rc2 build with just that commit on top, and can't reproduce this at all now.
(At least not with the reproducer that worked previously).

 > but I can't set how this makes any difference to the problem at all.

Mysterious.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 > >  > 
 > >  >  > > Tomorrow I'll also try running some older kernels with the same
 > >  >  > > options to see if it's something new, or an older bug. This is a
 > >  >  > > new machine, so it may be something that's been around for a
 > >  >  > > while, and for whatever reason, my other machines don't hit
 > >  >  > > this.
 > >  >  > 
 > >  >  > Another thing that just occurred to me - what compiler are you
 > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 > >  >  > with bad checksums because of link time optimisation (LTO) in
 > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 > >  >  > good idea, too.
 > >  > 
 > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 > >  > Bug reproduced instantly, so I think we can rule out compiler.
 > >  > 
 > >  > I ran 3.9 with the same debug options. Seems stable.
 > >  > I'll do a bisect.
 > > 
 > > good news.  It wasn't until I started bisecting I realised I was still
 > > carrying this patch from you to fix slab corruption I was seeing.
 > > 
 > > It seems to be the culprit (or is masking another problem -- I had to apply
 > > it at each step of the bisect to get past the slab corruption bug).
 > 
 > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 > tree is a little different:
 > 
 > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d

I did an rc2 build with just that commit on top, and can't reproduce this at all now.
(At least not with the reproducer that worked previously).

 > but I can't set how this makes any difference to the problem at all.

Mysterious.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 11:17:21AM -0400, Dave Jones wrote:
 > On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 >  > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 >  > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 >  > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 >  > >  > 
 >  > >  >  > > Tomorrow I'll also try running some older kernels with the same
 >  > >  >  > > options to see if it's something new, or an older bug. This is a
 >  > >  >  > > new machine, so it may be something that's been around for a
 >  > >  >  > > while, and for whatever reason, my other machines don't hit
 >  > >  >  > > this.
 >  > >  >  > 
 >  > >  >  > Another thing that just occurred to me - what compiler are you
 >  > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 >  > >  >  > with bad checksums because of link time optimisation (LTO) in
 >  > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 >  > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 >  > >  >  > good idea, too.
 >  > >  > 
 >  > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 >  > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 >  > >  > Bug reproduced instantly, so I think we can rule out compiler.
 >  > >  > 
 >  > >  > I ran 3.9 with the same debug options. Seems stable.
 >  > >  > I'll do a bisect.
 >  > > 
 >  > > good news.  It wasn't until I started bisecting I realised I was still
 >  > > carrying this patch from you to fix slab corruption I was seeing.
 >  > > 
 >  > > It seems to be the culprit (or is masking another problem -- I had to apply
 >  > > it at each step of the bisect to get past the slab corruption bug).
 >  > 
 >  > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 >  > tree is a little different:
 >  > 
 >  > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d
 > 
 > I did an rc2 build with just that commit on top, and can't reproduce this at all now.
 > (At least not with the reproducer that worked previously).

Ok, scratch all that. I can reproduce it again, it just takes longer.
(And typically, I didn't have your debug patch on top for that run.. nnnngh)

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 11:17:21AM -0400, Dave Jones wrote:
 > On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
 >  > On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
 >  > > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
 >  > >  > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
 >  > >  > 
 >  > >  >  > > Tomorrow I'll also try running some older kernels with the same
 >  > >  >  > > options to see if it's something new, or an older bug. This is a
 >  > >  >  > > new machine, so it may be something that's been around for a
 >  > >  >  > > while, and for whatever reason, my other machines don't hit
 >  > >  >  > > this.
 >  > >  >  > 
 >  > >  >  > Another thing that just occurred to me - what compiler are you
 >  > >  >  > using?  We had a report last week on #xfs that xfsdump was failing
 >  > >  >  > with bad checksums because of link time optimisation (LTO) in
 >  > >  >  > gcc-4.8.0. When they turned that off, everything worked fine. So if
 >  > >  >  > you are using 4.8.0, perhaps trying a different compiler might be a
 >  > >  >  > good idea, too.
 >  > >  > 
 >  > >  > Yeah, this is 4.8.0. This box is running F19-beta. 
 >  > >  > I managed to shoehorn the gcc-4.7 from f18 on there though.
 >  > >  > Bug reproduced instantly, so I think we can rule out compiler.
 >  > >  > 
 >  > >  > I ran 3.9 with the same debug options. Seems stable.
 >  > >  > I'll do a bisect.
 >  > > 
 >  > > good news.  It wasn't until I started bisecting I realised I was still
 >  > > carrying this patch from you to fix slab corruption I was seeing.
 >  > > 
 >  > > It seems to be the culprit (or is masking another problem -- I had to apply
 >  > > it at each step of the bisect to get past the slab corruption bug).
 >  > 
 >  > That doesn't make a whole lot of sense to me. The fix in the xfsdev
 >  > tree is a little different:
 >  > 
 >  > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=52c24ad39ff02d7bd73c92eb0c926fb44984a41d
 > 
 > I did an rc2 build with just that commit on top, and can't reproduce this at all now.
 > (At least not with the reproducer that worked previously).

Ok, scratch all that. I can reproduce it again, it just takes longer.
(And typically, I didn't have your debug patch on top for that run.. nnnngh)

	Dave


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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 07:54:54AM +1000, Dave Chinner wrote:

 > Gah, I've got not idea what the hell I was smoking yesterday
 > afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.
 > 
 > So a mask of 0xa068 is correct and valid from the open path, and
 > 0x2068 is just file from the truncate path.
 > 
 > But, neither of those should trigger that assert. indeed, on a test
 > kernel (3.10-rc2 based):
 > 
 > # echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
 > [  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
 > #
 > 
 > And there's not assert failure. Indeed, the "masked # 0x0" is what
 > the assert is checking.
 > 
 > And yeah, path output works. Trick for anyone who doesn't read the
 > code closely - the buffer is filled from the end backwards, and the
 > start of the path is the return variable. So, the above code is:
 > 
 > 	{
 > 		struct dentry *d = d_find_alias(VFS_I(ip));
 > 		char buf[MAXPATHLEN];
 > 		char *ptr;
 > 
 > 		memset(buf, 0, MAXPATHLEN);
 > 		ptr = dentry_path(d, buf, MAXPATHLEN);
 > 		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
 > 			__func__, mask,
 > 	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
 > 			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
 > 			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
 > 			ip, d, ptr);
 > 		dput(d);
 > 	}
 > 
 > Which I put just before the assert that is firing on your machine.
 > 
 > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
 > mask of 0xa068.

With this, I get a spew of these when I start a kernel build..

[  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
[  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
[  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
[  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
[  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
[  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
[  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
[  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
[  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 07:54:54AM +1000, Dave Chinner wrote:

 > Gah, I've got not idea what the hell I was smoking yesterday
 > afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.
 > 
 > So a mask of 0xa068 is correct and valid from the open path, and
 > 0x2068 is just file from the truncate path.
 > 
 > But, neither of those should trigger that assert. indeed, on a test
 > kernel (3.10-rc2 based):
 > 
 > # echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
 > [  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
 > #
 > 
 > And there's not assert failure. Indeed, the "masked # 0x0" is what
 > the assert is checking.
 > 
 > And yeah, path output works. Trick for anyone who doesn't read the
 > code closely - the buffer is filled from the end backwards, and the
 > start of the path is the return variable. So, the above code is:
 > 
 > 	{
 > 		struct dentry *d = d_find_alias(VFS_I(ip));
 > 		char buf[MAXPATHLEN];
 > 		char *ptr;
 > 
 > 		memset(buf, 0, MAXPATHLEN);
 > 		ptr = dentry_path(d, buf, MAXPATHLEN);
 > 		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
 > 			__func__, mask,
 > 	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
 > 			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
 > 			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
 > 			ip, d, ptr);
 > 		dput(d);
 > 	}
 > 
 > Which I put just before the assert that is firing on your machine.
 > 
 > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
 > mask of 0xa068.

With this, I get a spew of these when I start a kernel build..

[  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
[  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
[  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
[  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
[  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
[  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
[  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
[  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
[  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 02:49:48PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 07:54:54AM +1000, Dave Chinner wrote:
> 
>  > Gah, I've got not idea what the hell I was smoking yesterday
>  > afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.
>  > 
>  > So a mask of 0xa068 is correct and valid from the open path, and
>  > 0x2068 is just file from the truncate path.
>  > 
>  > But, neither of those should trigger that assert. indeed, on a test
>  > kernel (3.10-rc2 based):
>  > 
>  > # echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
>  > [  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
>  > #
>  > 
>  > And there's not assert failure. Indeed, the "masked # 0x0" is what
>  > the assert is checking.
>  > 
>  > And yeah, path output works. Trick for anyone who doesn't read the
>  > code closely - the buffer is filled from the end backwards, and the
>  > start of the path is the return variable. So, the above code is:
>  > 
>  > 	{
>  > 		struct dentry *d = d_find_alias(VFS_I(ip));
>  > 		char buf[MAXPATHLEN];
>  > 		char *ptr;
>  > 
>  > 		memset(buf, 0, MAXPATHLEN);
>  > 		ptr = dentry_path(d, buf, MAXPATHLEN);
>  > 		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
>  > 			__func__, mask,
>  > 	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
>  > 			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
>  > 			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
>  > 			ip, d, ptr);
>  > 		dput(d);
>  > 	}
>  > 
>  > Which I put just before the assert that is firing on your machine.
>  > 
>  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
>  > mask of 0xa068.
> 
> With this, I get a spew of these when I start a kernel build..
> 
> [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
> [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
> [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
> [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
> [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
> [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
> [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
> [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
> [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le

Right, It's printing them out for every truncate that is done.
Just print on the conditional that is was triggering the assert...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 02:49:48PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 07:54:54AM +1000, Dave Chinner wrote:
> 
>  > Gah, I've got not idea what the hell I was smoking yesterday
>  > afternoon. 0x2000 is actually ATTR_FILE, and 0x8000 is ATTR_OPEN.
>  > 
>  > So a mask of 0xa068 is correct and valid from the open path, and
>  > 0x2068 is just file from the truncate path.
>  > 
>  > But, neither of those should trigger that assert. indeed, on a test
>  > kernel (3.10-rc2 based):
>  > 
>  > # echo I need a new drug > /mnt/scr/bah/blah/black/sheep/foo
>  > [  296.742990] XFS (vdb): xfs_setattr_size: mask 0xa068, masked # 0x0 ii 0xffff88003e6297c0, d 0xffff88003e5b9cb0 path /bah/blah/black/sheep/foo
>  > #
>  > 
>  > And there's not assert failure. Indeed, the "masked # 0x0" is what
>  > the assert is checking.
>  > 
>  > And yeah, path output works. Trick for anyone who doesn't read the
>  > code closely - the buffer is filled from the end backwards, and the
>  > start of the path is the return variable. So, the above code is:
>  > 
>  > 	{
>  > 		struct dentry *d = d_find_alias(VFS_I(ip));
>  > 		char buf[MAXPATHLEN];
>  > 		char *ptr;
>  > 
>  > 		memset(buf, 0, MAXPATHLEN);
>  > 		ptr = dentry_path(d, buf, MAXPATHLEN);
>  > 		xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
>  > 			__func__, mask,
>  > 	(mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
>  > 			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
>  > 			ATTR_KILL_PRIV|ATTR_TIMES_SET)),
>  > 			ip, d, ptr);
>  > 		dput(d);
>  > 	}
>  > 
>  > Which I put just before the assert that is firing on your machine.
>  > 
>  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
>  > mask of 0xa068.
> 
> With this, I get a spew of these when I start a kernel build..
> 
> [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
> [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
> [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
> [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
> [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
> [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
> [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
> [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
> [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le

Right, It's printing them out for every truncate that is done.
Just print on the conditional that is was triggering the assert...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 08:30:38AM +1000, Dave Chinner wrote:

 > >  > Which I put just before the assert that is firing on your machine.
 > >  > 
 > >  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
 > >  > mask of 0xa068.
 > > 
 > > With this, I get a spew of these when I start a kernel build..
 > > 
 > > [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
 > > [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
 > > [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
 > > [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
 > > [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
 > > [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
 > > [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
 > > [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
 > > [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le
 > 
 > Right, It's printing them out for every truncate that is done.
 > Just print on the conditional that is was triggering the assert...

I'm missing something.. That's what I did ?

-       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+
+       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
                        ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {
+               struct dentry *d = d_find_alias(VFS_I(ip));
+               char buf[MAXPATHLEN];
+               char *ptr;
+
+               memset(buf, 0, MAXPATHLEN);
+               ptr = dentry_path(d, buf, MAXPATHLEN);
+               xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
+                               __func__, mask,
+               (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+                               ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
+                               ATTR_KILL_PRIV|ATTR_TIMES_SET)),
+                               ip, d, ptr);
+                       dput(d);
+       }

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 08:30:38AM +1000, Dave Chinner wrote:

 > >  > Which I put just before the assert that is firing on your machine.
 > >  > 
 > >  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
 > >  > mask of 0xa068.
 > > 
 > > With this, I get a spew of these when I start a kernel build..
 > > 
 > > [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
 > > [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
 > > [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
 > > [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
 > > [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
 > > [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
 > > [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
 > > [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
 > > [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le
 > 
 > Right, It's printing them out for every truncate that is done.
 > Just print on the conditional that is was triggering the assert...

I'm missing something.. That's what I did ?

-       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+
+       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
                        ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {
+               struct dentry *d = d_find_alias(VFS_I(ip));
+               char buf[MAXPATHLEN];
+               char *ptr;
+
+               memset(buf, 0, MAXPATHLEN);
+               ptr = dentry_path(d, buf, MAXPATHLEN);
+               xfs_warn(mp, "%s: mask 0x%x, masked 0x%x ii 0x%p, d 0x%p path %s",
+                               __func__, mask,
+               (mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+                               ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
+                               ATTR_KILL_PRIV|ATTR_TIMES_SET)),
+                               ip, d, ptr);
+                       dput(d);
+       }

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 08:49:06PM -0400, Dave Jones wrote:
> On Fri, May 24, 2013 at 08:30:38AM +1000, Dave Chinner wrote:
> 
>  > >  > Which I put just before the assert that is firing on your machine.
>  > >  > 
>  > >  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
>  > >  > mask of 0xa068.
>  > > 
>  > > With this, I get a spew of these when I start a kernel build..
>  > > 
>  > > [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
>  > > [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
>  > > [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
>  > > [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
>  > > [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
>  > > [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
>  > > [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
>  > > [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
>  > > [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le
>  > 
>  > Right, It's printing them out for every truncate that is done.
>  > Just print on the conditional that is was triggering the assert...
> 
> I'm missing something.. That's what I did ?
> 
> -       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
> +
> +       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
>                         ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
> -                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
> +                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {

You want to print the debug output if the masked value != 0.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 08:49:06PM -0400, Dave Jones wrote:
> On Fri, May 24, 2013 at 08:30:38AM +1000, Dave Chinner wrote:
> 
>  > >  > Which I put just before the assert that is firing on your machine.
>  > >  > 
>  > >  > And, obviously, it isn't firing on mine and obviously shouldn't be firing on a
>  > >  > mask of 0xa068.
>  > > 
>  > > With this, I get a spew of these when I start a kernel build..
>  > > 
>  > > [  964.378690] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff880221b5d970 path /davej/tmp/ccN2RrM5.s
>  > > [  964.651927] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ff80b90 path /davej/tmp/ccB1Cdmo.s
>  > > [  964.867444] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff8802218a5bc0 path /davej/tmp/ccCUaXbG.s
>  > > [  965.102661] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a95dac0, d 0xffff88020ffacde0 path /davej/tmp/cckMLf2X.s
>  > > [  967.743312] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff88022212c250 path /davej/tmp/ccFMkBbA.s
>  > > [  967.947154] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a93c200, d 0xffff8802226cc6f0 path /davej/tmp/cc5iX4SR.s
>  > > [  968.009414] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a988000, d 0xffff8802219f1970 path /davej/tmp/ccvWCHTZ.o
>  > > [  968.091504] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a9898c0, d 0xffff88022208de10 path /davej/tmp/cc9n6fnm.ld
>  > > [  968.107997] XFS (sda2): xfs_setattr_size: mask 0xa068, masked 0x0 ii 0xffff88020a98dac0, d 0xffff880221160de0 path /davej/tmp/cc5rlvHu.le
>  > 
>  > Right, It's printing them out for every truncate that is done.
>  > Just print on the conditional that is was triggering the assert...
> 
> I'm missing something.. That's what I did ?
> 
> -       ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
> +
> +       if ((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
>                         ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
> -                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
> +                       ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0) {

You want to print the debug output if the masked value != 0.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:

 > You want to print the debug output if the masked value != 0.

Derp. Thanks.
Rerunning the tests now. Hopefully I'll have something in a few hours.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:

 > You want to print the debug output if the masked value != 0.

Derp. Thanks.
Rerunning the tests now. Hopefully I'll have something in a few hours.

	Dave


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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
 
 > You want to print the debug output if the masked value != 0.

XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
 
 > You want to print the debug output if the masked value != 0.

XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 09:52:19PM -0400, Dave Jones wrote:
 > On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
 >  
 >  > You want to print the debug output if the masked value != 0.
 > 
 > XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/

ah, sneaky. There's some unprintable characters there that didn't show up in my terminal when I cut-n-pasted.
They made it to the logs though..

XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/\x01\x01

Hexdump: of that part.. 706d 352e 012f 0a01 
So filename is 0x01 0x01

Don't know if that's relevant to the bug or not..

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Thu, May 23, 2013 at 09:52:19PM -0400, Dave Jones wrote:
 > On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
 >  
 >  > You want to print the debug output if the masked value != 0.
 > 
 > XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/

ah, sneaky. There's some unprintable characters there that didn't show up in my terminal when I cut-n-pasted.
They made it to the logs though..

XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/\x01\x01

Hexdump: of that part.. 706d 352e 012f 0a01 
So filename is 0x01 0x01

Don't know if that's relevant to the bug or not..

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 11:03:00PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 09:52:19PM -0400, Dave Jones wrote:
>  > On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
>  >  
>  >  > You want to print the debug output if the masked value != 0.
>  > 
>  > XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/
> 
> ah, sneaky. There's some unprintable characters there that didn't
> show up in my terminal when I cut-n-pasted.  They made it to the
> logs though..
> 
> XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/\x01\x01

So the mask is:

	ATTR_OPEN | ATTR_FILE | ATTR_KILL_SUID | ATTR_FORCE | \
	ATTR_CTIME | ATTR_MTIME | ATTR_MODE

And so the mask is tripping the assert is (ATTR_KILL_SUID |
ATTR_MODE).

Ok, that now makes sense - that's consistent with open(O_TRUNCATE)
on a suid file. How the hell has this gone unnoticed?

> Hexdump: of that part.. 706d 352e 012f 0a01 
> So filename is 0x01 0x01
> 
> Don't know if that's relevant to the bug or not..

No, it's not. It seems like the XFS code is simply broken, and has
been for a couple of years. This is the commit that changed the code
into the split we currently have now:

commit c4ed4243c40f97ed5b7b121777bbbc6aeaa722f0
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 8 14:34:23 2011 +0200

    xfs: split xfs_setattr
    
    Split up xfs_setattr into two functions, one for the complex truncate
    handling, and one for the trivial attribute updates.  Also move both
    new routines to xfs_iops.c as they are fairly Linux-specific.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Alex Elder <aelder@sgi.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>

Clearly there's a simple test that xfstests is missing, not to
mention every other test suite out there that is run regularly on
linux....

Awww, hell.

xfstest generic/193 is *supposed* to test behaviour of suid/sgid bits
and clearing them is various situations.

You know what I'm about to say, don't you? The test doesn't test
what it thinks it is testing. it puts the destination file in root
directory of the xfstests harness, not in the filesystems being
tested.

So, on all my machines, it runs on ext3 filesystems, never on the
ext4, btrfs, xfs, etc filesystems that I'm actually testing.

That's beside the point, because it doesn't test truncate behaviour.
But at least I know now why my attempts to reproduce the problem
didn't work...

Right, patch below should fix the problem.

What a frustrating bug. Now, where's my bottle of scotch?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

xfs: kill suid/sgid through the truncate path.

From: Dave Chinner <dchinner@redhat.com>

XFS has failed to kill suid/sgid bits correctly when truncating
files of non-zero size since commit c4ed4243 ("xfs: split
xfs_setattr") introduced in the 3.1 kernel. Fix it.

Fix it.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/xfs_iops.c |   43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index d82efaa..c255382 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -455,6 +455,24 @@ xfs_vn_getattr(
 	return 0;
 }
 
+static void
+xfs_setattr_mode(
+	struct inode	*inode,
+	struct iattr	*iattr)
+{
+	struct xfs_inode *ip = XFS_I(inode);
+	umode_t		mode = iattr->ia_mode;
+
+	if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
+		mode &= ~S_ISGID;
+
+	ip->i_d.di_mode &= S_IFMT;
+	ip->i_d.di_mode |= mode & ~S_IFMT;
+
+	inode->i_mode &= S_IFMT;
+	inode->i_mode |= mode & ~S_IFMT;
+}
+
 int
 xfs_setattr_nonsize(
 	struct xfs_inode	*ip,
@@ -606,18 +624,8 @@ xfs_setattr_nonsize(
 	/*
 	 * Change file access modes.
 	 */
-	if (mask & ATTR_MODE) {
-		umode_t mode = iattr->ia_mode;
-
-		if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
-			mode &= ~S_ISGID;
-
-		ip->i_d.di_mode &= S_IFMT;
-		ip->i_d.di_mode |= mode & ~S_IFMT;
-
-		inode->i_mode &= S_IFMT;
-		inode->i_mode |= mode & ~S_IFMT;
-	}
+	if (mask & ATTR_MODE)
+		xfs_setattr_mode(inode, iattr);
 
 	/*
 	 * Change file access or modified times.
@@ -714,9 +722,8 @@ xfs_setattr_size(
 		return XFS_ERROR(error);
 
 	ASSERT(S_ISREG(ip->i_d.di_mode));
-	ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
-			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-			ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+	ASSERT((mask & (ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+			ATTR_MTIME_SET|ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
 
 	if (!(flags & XFS_ATTR_NOLOCK)) {
 		lock_flags |= XFS_IOLOCK_EXCL;
@@ -860,6 +867,12 @@ xfs_setattr_size(
 		xfs_inode_clear_eofblocks_tag(ip);
 	}
 
+	/*
+	 * Change file access modes.
+	 */
+	if (mask & ATTR_MODE)
+		xfs_setattr_mode(inode, iattr);
+
 	if (mask & ATTR_CTIME) {
 		inode->i_ctime = iattr->ia_ctime;
 		ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec;

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Thu, May 23, 2013 at 11:03:00PM -0400, Dave Jones wrote:
> On Thu, May 23, 2013 at 09:52:19PM -0400, Dave Jones wrote:
>  > On Fri, May 24, 2013 at 11:26:25AM +1000, Dave Chinner wrote:
>  >  
>  >  > You want to print the debug output if the masked value != 0.
>  > 
>  > XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/
> 
> ah, sneaky. There's some unprintable characters there that didn't
> show up in my terminal when I cut-n-pasted.  They made it to the
> logs though..
> 
> XFS (sda2): xfs_setattr_size: mask 0xaa69, masked 0x801 ii 0xffff8802129e98c0, d 0xffff88021757d970 path /davej/src/trinity/tmp/tmp.5/\x01\x01

So the mask is:

	ATTR_OPEN | ATTR_FILE | ATTR_KILL_SUID | ATTR_FORCE | \
	ATTR_CTIME | ATTR_MTIME | ATTR_MODE

And so the mask is tripping the assert is (ATTR_KILL_SUID |
ATTR_MODE).

Ok, that now makes sense - that's consistent with open(O_TRUNCATE)
on a suid file. How the hell has this gone unnoticed?

> Hexdump: of that part.. 706d 352e 012f 0a01 
> So filename is 0x01 0x01
> 
> Don't know if that's relevant to the bug or not..

No, it's not. It seems like the XFS code is simply broken, and has
been for a couple of years. This is the commit that changed the code
into the split we currently have now:

commit c4ed4243c40f97ed5b7b121777bbbc6aeaa722f0
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 8 14:34:23 2011 +0200

    xfs: split xfs_setattr
    
    Split up xfs_setattr into two functions, one for the complex truncate
    handling, and one for the trivial attribute updates.  Also move both
    new routines to xfs_iops.c as they are fairly Linux-specific.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Alex Elder <aelder@sgi.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>

Clearly there's a simple test that xfstests is missing, not to
mention every other test suite out there that is run regularly on
linux....

Awww, hell.

xfstest generic/193 is *supposed* to test behaviour of suid/sgid bits
and clearing them is various situations.

You know what I'm about to say, don't you? The test doesn't test
what it thinks it is testing. it puts the destination file in root
directory of the xfstests harness, not in the filesystems being
tested.

So, on all my machines, it runs on ext3 filesystems, never on the
ext4, btrfs, xfs, etc filesystems that I'm actually testing.

That's beside the point, because it doesn't test truncate behaviour.
But at least I know now why my attempts to reproduce the problem
didn't work...

Right, patch below should fix the problem.

What a frustrating bug. Now, where's my bottle of scotch?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

xfs: kill suid/sgid through the truncate path.

From: Dave Chinner <dchinner@redhat.com>

XFS has failed to kill suid/sgid bits correctly when truncating
files of non-zero size since commit c4ed4243 ("xfs: split
xfs_setattr") introduced in the 3.1 kernel. Fix it.

Fix it.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/xfs_iops.c |   43 ++++++++++++++++++++++++++++---------------
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index d82efaa..c255382 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -455,6 +455,24 @@ xfs_vn_getattr(
 	return 0;
 }
 
+static void
+xfs_setattr_mode(
+	struct inode	*inode,
+	struct iattr	*iattr)
+{
+	struct xfs_inode *ip = XFS_I(inode);
+	umode_t		mode = iattr->ia_mode;
+
+	if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
+		mode &= ~S_ISGID;
+
+	ip->i_d.di_mode &= S_IFMT;
+	ip->i_d.di_mode |= mode & ~S_IFMT;
+
+	inode->i_mode &= S_IFMT;
+	inode->i_mode |= mode & ~S_IFMT;
+}
+
 int
 xfs_setattr_nonsize(
 	struct xfs_inode	*ip,
@@ -606,18 +624,8 @@ xfs_setattr_nonsize(
 	/*
 	 * Change file access modes.
 	 */
-	if (mask & ATTR_MODE) {
-		umode_t mode = iattr->ia_mode;
-
-		if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
-			mode &= ~S_ISGID;
-
-		ip->i_d.di_mode &= S_IFMT;
-		ip->i_d.di_mode |= mode & ~S_IFMT;
-
-		inode->i_mode &= S_IFMT;
-		inode->i_mode |= mode & ~S_IFMT;
-	}
+	if (mask & ATTR_MODE)
+		xfs_setattr_mode(inode, iattr);
 
 	/*
 	 * Change file access or modified times.
@@ -714,9 +722,8 @@ xfs_setattr_size(
 		return XFS_ERROR(error);
 
 	ASSERT(S_ISREG(ip->i_d.di_mode));
-	ASSERT((mask & (ATTR_MODE|ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
-			ATTR_MTIME_SET|ATTR_KILL_SUID|ATTR_KILL_SGID|
-			ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
+	ASSERT((mask & (ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
+			ATTR_MTIME_SET|ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0);
 
 	if (!(flags & XFS_ATTR_NOLOCK)) {
 		lock_flags |= XFS_IOLOCK_EXCL;
@@ -860,6 +867,12 @@ xfs_setattr_size(
 		xfs_inode_clear_eofblocks_tag(ip);
 	}
 
+	/*
+	 * Change file access modes.
+	 */
+	if (mask & ATTR_MODE)
+		xfs_setattr_mode(inode, iattr);
+
 	if (mask & ATTR_CTIME) {
 		inode->i_ctime = iattr->ia_ctime;
 		ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec;

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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 06:03:00PM +1000, Dave Chinner wrote:

 > xfstest generic/193 is *supposed* to test behaviour of suid/sgid bits
 > and clearing them is various situations.
 > 
 > You know what I'm about to say, don't you? The test doesn't test
 > what it thinks it is testing. it puts the destination file in root
 > directory of the xfstests harness, not in the filesystems being
 > tested.

awesome, two bugs for the price of one!

 > So, on all my machines, it runs on ext3 filesystems, never on the
 > ext4, btrfs, xfs, etc filesystems that I'm actually testing.
 > 
 > That's beside the point, because it doesn't test truncate behaviour.
 > But at least I know now why my attempts to reproduce the problem
 > didn't work...
 > 
 > Right, patch below should fix the problem.

Haven't seen anything out of the ordinary since I applied that,
so I'd call it good.
 
 > What a frustrating bug. Now, where's my bottle of scotch?

heh, enjoy the weekend.

	Dave

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Jones]

On Fri, May 24, 2013 at 06:03:00PM +1000, Dave Chinner wrote:

 > xfstest generic/193 is *supposed* to test behaviour of suid/sgid bits
 > and clearing them is various situations.
 > 
 > You know what I'm about to say, don't you? The test doesn't test
 > what it thinks it is testing. it puts the destination file in root
 > directory of the xfstests harness, not in the filesystems being
 > tested.

awesome, two bugs for the price of one!

 > So, on all my machines, it runs on ext3 filesystems, never on the
 > ext4, btrfs, xfs, etc filesystems that I'm actually testing.
 > 
 > That's beside the point, because it doesn't test truncate behaviour.
 > But at least I know now why my attempts to reproduce the problem
 > didn't work...
 > 
 > Right, patch below should fix the problem.

Haven't seen anything out of the ordinary since I applied that,
so I'd call it good.
 
 > What a frustrating bug. Now, where's my bottle of scotch?

heh, enjoy the weekend.

	Dave

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

Re: XFS assertion from truncate. (3.10-rc2)

[Eric Sandeen]

On 5/24/13 3:03 AM, Dave Chinner wrote:

> Right, patch below should fix the problem.
> 
> What a frustrating bug. Now, where's my bottle of scotch?

In your pantry, Dave.  Next to the others! ;)

-Eric

> Cheers,
> 
> Dave.
> 

Re: XFS assertion from truncate. (3.10-rc2)

[Eric Sandeen]

On 5/24/13 3:03 AM, Dave Chinner wrote:

> Right, patch below should fix the problem.
> 
> What a frustrating bug. Now, where's my bottle of scotch?

In your pantry, Dave.  Next to the others! ;)

-Eric

> Cheers,
> 
> Dave.
> 

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

Re: XFS assertion from truncate. (3.10-rc2)

[Stan Hoeppner]

On 5/24/2013 11:58 PM, Eric Sandeen wrote:
> On 5/24/13 3:03 AM, Dave Chinner wrote:
> 
>> Right, patch below should fix the problem.
>>
>> What a frustrating bug. Now, where's my bottle of scotch?
> 
> In your pantry, Dave.  Next to the others! ;)

Be careful with that stuff lest you have more bugs to fix. ;)

Heheh, how bout a T-Shirt:  "Don't drink and code" on the front, w/a
graphic of intoxicated Calvin tangled up in a wrecked PC on the back.
At least he won't be pissing on anything in this one. ;)

-- 
Stan


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

Re: XFS assertion from truncate. (3.10-rc2)

[Dave Chinner]

On Sat, May 25, 2013 at 01:39:18AM -0500, Stan Hoeppner wrote:
> On 5/24/2013 11:58 PM, Eric Sandeen wrote:
> > On 5/24/13 3:03 AM, Dave Chinner wrote:
> > 
> >> Right, patch below should fix the problem.
> >>
> >> What a frustrating bug. Now, where's my bottle of scotch?
> > 
> > In your pantry, Dave.  Next to the others! ;)

Yeah, there's a few on the top shelf to choose from....

> Be careful with that stuff lest you have more bugs to fix. ;)

The secret is to wait till the next day before posting the patches.

> Heheh, how bout a T-Shirt:  "Don't drink and code" on the front,

Sorry, Stan, but you lost me at "Don't drink".... :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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