From: Dave Chinner <david@fromorbit.com>
To: katsuki.uwatoko@toshiba.co.jp
Cc: gangchen@rdamicro.com, linux@arm.linux.org.uk,
karanvir.singh@hgst.com, bfoster@redhat.com, sandeen@sandeen.net,
luca@skylable.com, xfs@oss.sgi.com, christopher.squires@hgst.com,
edwin@skylable.com, wayne.burri@hgst.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
Date: Wed, 12 Aug 2015 13:14:07 +1000 [thread overview]
Message-ID: <20150812031407.GB20596@dastard> (raw)
In-Reply-To: <C6D0D499B56584katsuki.uwatoko@toshiba.co.jp>
On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko@toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
>
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
>
> I think that this is not a toolchain bug, this is related to
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html
Interesting! Very good work finding that bug, Katsuki-san.
FWIW, I suspect this fix will need to go back into stable kernels,
too.
> --
>
> The problematic line in xfs is:
> irecs->br_startblock = XFS_DADDR_TO_FSB(mp, mappedbno)
> in xfs_dabuf_map()/fs/xfs/xfs_da_btree.c.
>
> The expansion of it is:
>
> ld = mappedbno >> mp->m_blkbb_log;
> do_div(ld, mp->m_sb.sb_agblocks);
> startblock = ld << mp->m_sb.sb_agblklog;
> ld = mappedbno >> mp->m_blkbb_log;
> startblock |= do_div(ld, mp->m_sb.sb_agblocks);
> irecs->br_startblock = startblock;
>
> The assembler of these are:
>
> :
> bl __do_div64
> ldr r1, [sp, #44]
> subs r3, r7, #32
> orr r1, r1, r2, lsr r5
> add r5, sp, #80
> str r5, [sp, #64]
> ldr r5, [sp, #60]
> movpl r1, r2, asl r3
> mov r2, r2, asl r7
> str r2, [sp, #40]
> str r1, [sp, #44]
> mov r1, r9
> str r5, [sp, #96]
> mov r7, #0
> ldr r2, [sp, #96]
> mov r5, #1
> ldr fp, [sp, #64]
> str r7, [sp, #84]
> mov r9, r2, asr #31
> str r7, [sp, #104]
> bl __do_div64
> :
>
> by GCC 4.7.2 with -O2 option.
To close the loop, what code do the other versions GCC produce for
this macro? Evidence so far says that the result depends on the
compiler version, so I would like to have confirmation that other
versions of the compiler generate working code. There are other
XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
the same problem, maybe with different compiler versions?
Basically I'm asking what is the scope of the problem you've found?
i.e. when was the bug introduced, what compilers expose it, etc
so that when ARM users report XFS corruptions we have some idea of
whether their kernel/compiler combination might have caused the
issue they are seeing...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-12 3:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 6:23 PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Török Edwin
2015-06-11 15:16 ` Brian Foster
2015-06-11 15:28 ` Török Edwin
2015-06-11 15:51 ` Eric Sandeen
2015-06-11 15:58 ` Eric Sandeen
2015-06-11 16:32 ` Török Edwin
2015-06-11 17:10 ` Eric Sandeen
2015-06-11 17:13 ` Török Edwin
2015-06-11 17:16 ` Eric Sandeen
2015-06-11 20:07 ` Eric Sandeen
2015-06-11 20:29 ` Eric Sandeen
2015-06-11 22:53 ` Dave Chinner
2015-06-12 12:21 ` Brian Foster
2015-06-12 12:47 ` Török Edwin
2015-06-12 13:54 ` Brian Foster
2015-06-12 20:19 ` Eric Sandeen
[not found] ` <BLUPR04MB593340A765596780F266454F2BB0@BLUPR04MB593.namprd04.prod.outlook.com>
2015-06-13 13:55 ` Török Edwin
2015-06-12 22:52 ` Dave Chinner
2015-08-12 0:56 ` katsuki.uwatoko
2015-08-12 3:14 ` Dave Chinner [this message]
2015-08-12 6:19 ` katsuki.uwatoko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150812031407.GB20596@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=christopher.squires@hgst.com \
--cc=edwin@skylable.com \
--cc=gangchen@rdamicro.com \
--cc=karanvir.singh@hgst.com \
--cc=katsuki.uwatoko@toshiba.co.jp \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=luca@skylable.com \
--cc=sandeen@sandeen.net \
--cc=wayne.burri@hgst.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox