public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Hein_Tibosch <hein_tibosch@yahoo.es>
To: James Stewart <jstewart@teradici.com>
Cc: linux-ext4@vger.kernel.org
Subject: Ext2 - ext3 unstable under 2.6.24: now solved (?)
Date: Wed, 05 Mar 2008 03:42:16 +0800	[thread overview]
Message-ID: <47CDA618.9040007@yahoo.es> (raw)
In-Reply-To: <20080221123543.412096f7@dhcp-252-066.norway.atmel.com>

Could someone please check the following?

The ext2 and ext3 filesystems of 2.6.24 show many Oops and hangups. 
After debugging I found the following common cause:

In a new 2.6.24 function an unwanted sign-extension takes place in:

fs/ext2/dir.c

static inline unsigned ext2_rec_len_from_disk(__le16 dlen)
{
   unsigned len = le16_to_cpu(dlen);

   if (len == EXT2_MAX_REC_LEN)
       return 1 << 16;
   return len;
}

include/ext3_fs.h :

static inline unsigned ext3_rec_len_from_disk(__le16 dlen)
{
    unsigned len = le16_to_cpu(dlen);

    if (len == EXT3_MAX_REC_LEN)
        return 1 << 16;
    return len;
}

00A0 will be returned as 0xFFFFA000 !!

Many code which iterates through dirent's, uses the above function to 
determine the start of the next dirent.(ext2_dirent, ext3_dir_entry_2)
See fs/ext2/dir.c and fs/ext3/namei.c

As a test I replaced "le16_to_cpu()" by a simple:

static inline unsigned my_le16_to_cpu (__le16 value)
{
    return ((value & 0x00FF) << 8) | ((value & 0xFF00) >> 8);
}

It showed no more "negative" rec_len values which cause the crashes, and 
both ext2/3 now run stable.

Compiler: gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Kernel: 2.6.24.atmel.1
Platform: Atmel AP7000 CPU, compiling with "ARCH=avr32 
CROSS_COMPILE=avr32-linux-"


Hein Tibosch


Haavard Skinnemoen wrote:
> (Adding the ext2/ext3/ext4 list to Cc)
>
> Note that the MMC/SD card driver in question, atmel-mci, is not in
> mainline, and may be the real cause of this problem. But it looks like
> there might be a potential problem in the ext3 code as well?
>
> Haavard
>
> On Thu, 21 Feb 2008 14:17:04 +0800
> Hein_Tibosch <hein_tibosch@yahoo.es> wrote:
>
>   
>> Hi James,
>>
>>
>> I've had all kinds of problems with the SD-card hooked to an NGW100, just as John Voltz reported earlier:
>>
>>     http://www.avr32linux.org/archives/kernel/2007-November/000421.html
>>     http://www.avr32linux.org/archives/kernel/2007-November/000425.html
>>
>> I debugged this problem and my conclusion is: using an SD-card may lead to both BUS-errors and a complete hanging of the system, with 2.6.23.atmel.5 as well as 2.6.24.atmel.1.
>>
>> Both the driver for ext2 and ext3 are using this type of function to iterate through a array of inodes:
>>
>>     static inline ext2_dirent *ext2_next_entry(ext2_dirent *p)
>>     {
>>         return (ext2_dirent *)((char*)p + le16_to_cpu(p->rec_len));
>>     }
>>
>>     static inline struct ext3_dir_entry_2 *
>>         ext3_next_entry(struct ext3_dir_entry_2 *p)
>>     {
>>         return (struct ext3_dir_entry_2 *)((char *)p +
>>             ext3_rec_len_from_disk(p->rec_len));
>>     }
>>
>>
>> Sometimes, rec_len is checked for a zero-value, sometimes the entry is checked thoroughly for validity (like with ext2_check_page() or ext3_check_dir_entry()), but in other cases rec_len isn't checked at all! This is the case in e.g. fs/ext3/namei.c, function ext3_dx_find_entry(). This function is always enabled since 2.6.24 (CONFIG_EXT3_INDEX not used anymore).
>>
>> I had a card on which at one place rec_len turned out to be a small negative number. When iterating, it would either cycle for ever (until WDT) or it could enter invalid memory (OOPS: BUS error).
>>
>> ( strange though that the rec_len appeared to have a negative number, I just did a "mkfs -t ext3" on Ubuntu. Could that be caused by the Atmel-driver? )
>>
>> I don't yet feel qualified to make a patch for this, I only did it for myself. Maybe someone can pick this up: a validity check should be made before any call to xxx_next_entry().
>>
>>
>> Regards,
>>
>> Hein Tibosch (HeinBali at avr32linux)
>>
>>
>>
>> James Stewart wrote:
>> Hi,
>>  
>> I'm wondering if there are any known issues with booting from SD card on the ATNGW100 using this kernel. I get a bunch of ext2 looking errors and then a stack dump immediately after mounting VFS. 2.6.23.atmel.5 runs perfectly, however.
>>  
>> This is just compiling using atngw100_defconfig.
>>  
>> Thanks,
>>  
>> James
>>
>> ------------------------------------------------
>>
>> _______________________________________________
>> Kernel mailing list
>> Kernel@avr32linux.org
>> http://duppen.flaskehals.net/cgi-bin/mailman/listinfo/kernel
>>   
>>     
>
>   


  parent reply	other threads:[~2008-03-04 19:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <71C39AE3DF382B4A9CD370AD1C63B855EA060C@stervanexmb01.teradici.local>
     [not found] ` <47BD1760.9080007@yahoo.es>
2008-02-21 11:35   ` Linux 2.6.24.atmel.1 MMC/SD Haavard Skinnemoen
2008-02-21 17:45     ` Hein_Tibosch
2008-03-04 19:42     ` Hein_Tibosch [this message]
2008-03-05  0:22       ` Ext2 - ext3 unstable under 2.6.24: now solved (?) Andreas Dilger

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=47CDA618.9040007@yahoo.es \
    --to=hein_tibosch@yahoo.es \
    --cc=jstewart@teradici.com \
    --cc=linux-ext4@vger.kernel.org \
    /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