Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763394Ab3DCKFx (ORCPT ); Wed, 3 Apr 2013 06:05:53 -0400 Received: from mail-da0-f46.google.com ([209.85.210.46]:51451 "EHLO mail-da0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754750Ab3DCKFt (ORCPT ); Wed, 3 Apr 2013 06:05:49 -0400 Date: Wed, 3 Apr 2013 18:22:04 +0800 From: Zheng Liu To: Dmitry Monakhov Cc: Christian Kujau , CAI Qian , "Theodore Ts'o" , LKML , linux-s390 , Steve Best , linux-ext4@vger.kernel.org Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Message-ID: <20130403102204.GA15383@gmail.com> Mail-Followup-To: Dmitry Monakhov , Christian Kujau , CAI Qian , Theodore Ts'o , LKML , linux-s390 , Steve Best , linux-ext4@vger.kernel.org References: <1211053180.322948.1364797847717.JavaMail.root@redhat.com> <87fvzaspr8.fsf@openvz.org> <874841142.414482.1364875584266.JavaMail.root@redhat.com> <877gkls1q7.fsf@openvz.org> <87r4isd1vn.fsf@openvz.org> <87li90q9mx.fsf@openvz.org> <87hajoq6s2.fsf@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hajoq6s2.fsf@openvz.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3125 Lines: 81 On Wed, Apr 03, 2013 at 01:53:49PM +0400, Dmitry Monakhov wrote: > On Wed, 03 Apr 2013 12:52:06 +0400, Dmitry Monakhov wrote: > Non-text part: multipart/mixed > > On Tue, 2 Apr 2013 16:22:41 -0700 (PDT), Christian Kujau wrote: > > > On Wed, 3 Apr 2013 at 02:05, Dmitry Monakhov wrote: > > > > Please drop that patch and collect logs with a kernel which > > > > has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied > > Ok I have found at least one issue. > Yeah.. My college advise me to use sparse in order to spot all > cpu_to_ondisk format conversion > make C=2 CF="-D__CHECK_ENDIAN__" fs/ext4/ > And it spotted a huge amount of issues. Which tell us that we are deeply > in shit. Yes, My college also suggest me that we should use sparse to check this problem. I think the following patch could fix this bug. Regards, - Zheng Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out From: Zheng Liu When an extent was zeroed out, we forgot to do convert from cpu to le16. It could make us hit a BUG_ON when we try to write dirty pages out. So fix it. Signed-off-by: Zheng Liu --- fs/ext4/extents.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e4a6844..2352467 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2999,20 +2999,23 @@ static int ext4_split_extent_at(handle_t *handle, if (split_flag & EXT4_EXT_DATA_VALID1) { err = ext4_ext_zeroout(inode, ex2); zero_ex.ee_block = ex2->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex2); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(ex2)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex2)); } else { err = ext4_ext_zeroout(inode, ex); zero_ex.ee_block = ex->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); } } else { err = ext4_ext_zeroout(inode, &orig_ex); zero_ex.ee_block = orig_ex.ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(&orig_ex); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(&orig_ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(&orig_ex)); } @@ -3272,7 +3275,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, if (err) goto out; zero_ex.ee_block = ex->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex); + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); err = ext4_ext_get_access(handle, inode, path + depth); -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/