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-\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
> >
> > (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@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
