From patchwork Fri Jun 25 23:48:23 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Deiters X-Patchwork-Id: 57041 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 3B559B7090 for ; Sat, 26 Jun 2010 09:50:06 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OSIdL-0008Tz-Sj; Fri, 25 Jun 2010 23:48:31 +0000 Received: from tethra.basler.com ([206.107.254.19]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OSIdK-0008RU-1X for linux-mtd@lists.infradead.org; Fri, 25 Jun 2010 23:48:30 +0000 Received: from exchserver.basler.com (unknown [192.168.1.5]) by tethra.basler.com (Postfix) with ESMTP id 8CEBA334A; Fri, 25 Jun 2010 18:48:25 -0500 (CDT) X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: JFFS2 corruption when mounting filesystem with filenames oflength> 7 Date: Fri, 25 Jun 2010 18:48:23 -0500 Message-ID: <181804936ABC2349BE503168465576460F20CB90@exchserver.basler.com> In-Reply-To: <181804936ABC2349BE503168465576460F1AB73E@exchserver.basler.com> Thread-Topic: JFFS2 corruption when mounting filesystem with filenames oflength> 7 Thread-Index: AcsTIlTTm7ObgDTcT2SMXs1NbMok+wAAi3dwACvphRAAOyFoMA== References: <181804936ABC2349BE503168465576460F1AAEC6@exchserver.basler.com> <181804936ABC2349BE503168465576460F1AAEE1@exchserver.basler.com> <181804936ABC2349BE503168465576460F1AB73E@exchserver.basler.com> From: "Steve Deiters" To: X-BaslerElectric-MailScanner-Information: Please contact the ISP for more information X-BaslerElectric-MailScanner-ID: 8CEBA334A.A7492 X-BaslerElectric-MailScanner: Found to be clean X-BaslerElectric-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-BaslerElectric-MailScanner-From: stevedeiters@basler.com X-BaslerElectric-MailScanner-To: linux-mtd@lists.infradead.org, linuxppc-dev@lists.ozlabs.org X-Spam-Status: No X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20100625_194830_153267_62CA5D20 X-CRM114-Status: GOOD ( 30.54 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.3.1 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Cc: linuxppc-dev@lists.ozlabs.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org > -----Original Message----- > From: linux-mtd-bounces@lists.infradead.org > [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of > Steve Deiters > Sent: Thursday, June 24, 2010 3:02 PM > To: linux-mtd@lists.infradead.org > Subject: RE: JFFS2 corruption when mounting filesystem with > filenames oflength> 7 > > > -----Original Message----- > > From: linux-mtd-bounces@lists.infradead.org > > [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Steve > > Deiters > > Sent: Wednesday, June 23, 2010 5:42 PM > > To: linux-mtd@lists.infradead.org > > Subject: RE: JFFS2 corruption when mounting filesystem with > filenames > > oflength > 7 > > > > > -----Original Message----- > > > From: linux-mtd-bounces@lists.infradead.org > > > [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Steve > > > Deiters > > > Sent: Wednesday, June 23, 2010 5:21 PM > > > To: linux-mtd@lists.infradead.org > > > Subject: JFFS2 corruption when mounting filesystem with > > filenames of > > > length > 7 > > > > > > I found an archived post which seems to be identical to my issue. > > > However, this is quite old and there never seemed to be any > > > resolution. > > > > > > http://www.infradead.org/pipermail/linux-mtd/2006-September/01 > > > 6491.html > > > > > > If I mount a filesystem that has filenames greater than 7 > > characters > > > in length, the files are corrupted when I mount. > > > In my case, I am making a > > > JFFS2 image with mkfs.jffs2 and flashing it in with u-boot. > > > However, I have attached a workflow where I erase the Flash > > and create > > > a new filesystem completely within Linux and it gives the same > > > behavior. I can list the files with the 'ls' > > > command from within u-boot. If I mount from within > Linux, and then > > > reboot into u-boot, it will not display any files that had > > a filename > > > greater than 7 characters. > > > > > > I enabled the MTD debug verbosity at level 2 for the > > attached example > > > session. > > > > > > I am running on a custom board with a MPC5121 and Linux 2.6.33.4. > > > > > > Thanks in advance for any help. > > > > > > Sorry for the jumbled mess. Looks like the line endings are messed > > up. > > Trying again. I also provided this as an attachment in > case it gets > > messed up again. > > Once again sorry for the mess. > > I tried this again with the DENX-v2.6.34 tag in the DENX git > repository (git://git.denx.de/linux-2.6-denx.git). The only > modification I made was to add my dts file. I still get the > same issue I had before. > > I've attached my kernel config if that gives any clues. > > Are there any thoughts on what may be causing this? > > Thanks. I think there may be something weird going on with the memcpy in my build. If I use the following patch I no longer get errors when I mount the filesystem. All I did was replace the memcpy with a loop. I'm not sure what's special about this particular use of memcpy. I can't believe that things would be working as well as they do if memcpy was broken in general. This is on a PowerPC 32 bit build for a MPC5121. I am using a GCC 4.1.2 to compile. Is anyone aware of any issues with memcpy in this configuration? Thanks. ------- crc = crc32(0, fd->name, rd->nsize); diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c index 46f870d..673caa2 100644 --- a/fs/jffs2/scan.c +++ b/fs/jffs2/scan.c @@ -1038,7 +1038,10 @@ static int jffs2_scan_dirent_node(struct jffs2_sb_info *c, struct jffs2_eraseblo if (!fd) { return -ENOMEM; } - memcpy(&fd->name, rd->name, checkedlen); + int i; + for(i = 0; i < checkedlen; i++) + ((unsigned char*)fd->name)[i] = ((const unsigned char*)rd->name)[i]; + fd->name[checkedlen] = 0;