From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6181D7F50 for ; Wed, 12 Aug 2015 01:19:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3AE4E8F8037 for ; Tue, 11 Aug 2015 23:19:55 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by cuda.sgi.com with ESMTP id 0cGaNFT3yLjMpJnc (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 11 Aug 2015 23:19:53 -0700 (PDT) From: Subject: Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Date: Wed, 12 Aug 2015 06:19:07 +0000 Message-ID: References: <557AD4D4.3010901@skylable.com> <20150612225209.GA20262@dastard> <20150812031407.GB20596@dastard> In-Reply-To: <20150812031407.GB20596@dastard> Content-Language: en-US Content-ID: MIME-Version: 1.0 List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: david@fromorbit.com 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 On Wed, 12 Aug 2015 13:14:07 +1000, Dave Chinner wrote: > 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... I have the following versions of GCC now. 4.5.1 4.6.4 4.7.2 # Sorry I don't have the recent versions of GCC. And the results are: 4.5.1 (-O2) OK. 4.6.4 (-O2) BAD. 4.7.2 (-O2) BAD. But even using gcc 4.7, this bug does not happen with -Os instead of -O2. It means that when CONFIG_CC_OPTIMIZE_FOR_SIZE Kernel option is used, it does not happen. As for the version of kernel, I am using 3.10 now. At least. it is the same as 2.6.32. -- The following are codes generated by GCCs. GCC 4.5.1 with -O2 (OK) 178: 41a00003 movmi r0, r3 17c: 51a00057 asrpl r0, r7, r0 180: e58da02c str sl, [sp, #44] ; 0x2c 184: ebfffffe bl 0 <__do_div64> 188: e1cd26f8 strd r2, [sp, #104] ; 0x68 18c: e3a08000 mov r8, #0 190: e5d51175 ldrb r1, [r5, #373] ; 0x175 194: e59d2068 ldr r2, [sp, #104] ; 0x68 198: e251e020 subs lr, r1, #32 19c: e5d5308c ldrb r3, [r5, #140] ; 0x8c 1a0: e261c020 rsb ip, r1, #32 1a4: e1a00136 lsr r0, r6, r1 1a8: e1800c17 orr r0, r0, r7, lsl ip 1ac: e2634020 rsb r4, r3, #32 1b0: 51a00e57 asrpl r0, r7, lr 1b4: e253c020 subs ip, r3, #32 1b8: e1a0b432 lsr fp, r2, r4 1bc: e1a0a312 lsl sl, r2, r3 1c0: 51a0bc12 lslpl fp, r2, ip 1c4: e59dc024 ldr ip, [sp, #36] ; 0x24 1c8: e5954064 ldr r4, [r5, #100] ; 0x64 1cc: e1a01157 asr r1, r7, r1 1d0: e58d804c str r8, [sp, #76] ; 0x4c 1d4: e58dc048 str ip, [sp, #72] ; 0x48 1d8: ebfffffe bl 0 <__do_div64> GCC 4.6.4 with -O2 (BAD) 19c: 51a0025e asrpl r0, lr, r2 1a0: e3a0a001 mov sl, #1 1a4: ebfffffe bl 0 <__do_div64> 1a8: e1a0bb32 lsr fp, r2, fp 1ac: e2553020 subs r3, r5, #32 1b0: e1a01008 mov r1, r8 1b4: e58d704c str r7, [sp, #76] ; 0x4c 1b8: e1a0800b mov r8, fp 1bc: e58d7060 str r7, [sp, #96] ; 0x60 1c0: 51a08312 lslpl r8, r2, r3 1c4: e1a02512 lsl r2, r2, r5 1c8: e58d8034 str r8, [sp, #52] ; 0x34 1cc: e1a0500a mov r5, sl 1d0: e58d2030 str r2, [sp, #48] ; 0x30 1d4: e28d8048 add r8, sp, #72 ; 0x48 1d8: ebfffffe bl 0 <__do_div64> GCC 4.7.2 with -Os (OK) 1a0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28 1a4: e1a0200b mov r2, fp 1a8: ebfffffe bl 0 <__aeabi_lasr> 1ac: e5954064 ldr r4, [r5, #100] ; 0x64 1b0: ebfffffe bl 0 <__do_div64> 1b4: e3a01000 mov r1, #0 1b8: e1a00002 mov r0, r2 1bc: e5d5208c ldrb r2, [r5, #140] ; 0x8c 1c0: ebfffffe bl 0 <__aeabi_llsl> 1c4: e1a0200b mov r2, fp 1c8: e1a06000 mov r6, r0 1cc: e1a07001 mov r7, r1 1d0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28 1d4: ebfffffe bl 0 <__aeabi_lasr> 1d8: e58da040 str sl, [sp, #64] ; 0x40 1dc: ebfffffe bl 0 <__do_div64> Thank you, -- UWATOKO _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: katsuki.uwatoko@toshiba.co.jp (katsuki.uwatoko at toshiba.co.jp) Date: Wed, 12 Aug 2015 06:19:07 +0000 Subject: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' In-Reply-To: <20150812031407.GB20596@dastard> References: <557AD4D4.3010901@skylable.com> <20150612225209.GA20262@dastard> <20150812031407.GB20596@dastard> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 12 Aug 2015 13:14:07 +1000, Dave Chinner wrote: > 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... I have the following versions of GCC now. 4.5.1 4.6.4 4.7.2 # Sorry I don't have the recent versions of GCC. And the results are: 4.5.1 (-O2) OK. 4.6.4 (-O2) BAD. 4.7.2 (-O2) BAD. But even using gcc 4.7, this bug does not happen with -Os instead of -O2. It means that when CONFIG_CC_OPTIMIZE_FOR_SIZE Kernel option is used, it does not happen. As for the version of kernel, I am using 3.10 now. At least. it is the same as 2.6.32. -- The following are codes generated by GCCs. GCC 4.5.1 with -O2 (OK) 178: 41a00003 movmi r0, r3 17c: 51a00057 asrpl r0, r7, r0 180: e58da02c str sl, [sp, #44] ; 0x2c 184: ebfffffe bl 0 <__do_div64> 188: e1cd26f8 strd r2, [sp, #104] ; 0x68 18c: e3a08000 mov r8, #0 190: e5d51175 ldrb r1, [r5, #373] ; 0x175 194: e59d2068 ldr r2, [sp, #104] ; 0x68 198: e251e020 subs lr, r1, #32 19c: e5d5308c ldrb r3, [r5, #140] ; 0x8c 1a0: e261c020 rsb ip, r1, #32 1a4: e1a00136 lsr r0, r6, r1 1a8: e1800c17 orr r0, r0, r7, lsl ip 1ac: e2634020 rsb r4, r3, #32 1b0: 51a00e57 asrpl r0, r7, lr 1b4: e253c020 subs ip, r3, #32 1b8: e1a0b432 lsr fp, r2, r4 1bc: e1a0a312 lsl sl, r2, r3 1c0: 51a0bc12 lslpl fp, r2, ip 1c4: e59dc024 ldr ip, [sp, #36] ; 0x24 1c8: e5954064 ldr r4, [r5, #100] ; 0x64 1cc: e1a01157 asr r1, r7, r1 1d0: e58d804c str r8, [sp, #76] ; 0x4c 1d4: e58dc048 str ip, [sp, #72] ; 0x48 1d8: ebfffffe bl 0 <__do_div64> GCC 4.6.4 with -O2 (BAD) 19c: 51a0025e asrpl r0, lr, r2 1a0: e3a0a001 mov sl, #1 1a4: ebfffffe bl 0 <__do_div64> 1a8: e1a0bb32 lsr fp, r2, fp 1ac: e2553020 subs r3, r5, #32 1b0: e1a01008 mov r1, r8 1b4: e58d704c str r7, [sp, #76] ; 0x4c 1b8: e1a0800b mov r8, fp 1bc: e58d7060 str r7, [sp, #96] ; 0x60 1c0: 51a08312 lslpl r8, r2, r3 1c4: e1a02512 lsl r2, r2, r5 1c8: e58d8034 str r8, [sp, #52] ; 0x34 1cc: e1a0500a mov r5, sl 1d0: e58d2030 str r2, [sp, #48] ; 0x30 1d4: e28d8048 add r8, sp, #72 ; 0x48 1d8: ebfffffe bl 0 <__do_div64> GCC 4.7.2 with -Os (OK) 1a0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28 1a4: e1a0200b mov r2, fp 1a8: ebfffffe bl 0 <__aeabi_lasr> 1ac: e5954064 ldr r4, [r5, #100] ; 0x64 1b0: ebfffffe bl 0 <__do_div64> 1b4: e3a01000 mov r1, #0 1b8: e1a00002 mov r0, r2 1bc: e5d5208c ldrb r2, [r5, #140] ; 0x8c 1c0: ebfffffe bl 0 <__aeabi_llsl> 1c4: e1a0200b mov r2, fp 1c8: e1a06000 mov r6, r0 1cc: e1a07001 mov r7, r1 1d0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28 1d4: ebfffffe bl 0 <__aeabi_lasr> 1d8: e58da040 str sl, [sp, #64] ; 0x40 1dc: ebfffffe bl 0 <__do_div64> Thank you, -- UWATOKO