Re: [PATCH] Bug fix for ext2.c

[Bean]

On Sun, Mar 15, 2009 at 1:35 AM, Robert Millan <address@hidden> wrote:
> On Sun, Mar 15, 2009 at 12:56:26AM +0800, Bean wrote:
>> On Sun, Mar 15, 2009 at 12:37 AM, Robert Millan <address@hidden> wrote:
>> > On Sun, Mar 15, 2009 at 12:16:23AM +0800, Bean wrote:
>> >> Hi,
>> >>
>> >> I've discovered a bug in ext2.c, inside grub_ext2_mount. The mount
>> >> function must return GRUB_ERR_BAD_FS if something goes wrong, because
>> >> grub_fs_probe would stop as soon as it sees a non-GRUB_ERR_BAD_FS
>> >> error, thus preventing other fs driver from detecting the correct fs
>> >> type. This patch fixes the problem.
>> >
>> > I think current behaviour is correct.  If a failure is triggered by
>> > grub_disk_read(), from grub_fs_probe perspective it means something is
>> > fucked up other than just "this is not the FS we're looking for", so it
>> > should be aware of the difference.
>> >
>> > Or is grub_ext2_read_inode() failure the one that's causing trouble for
>> > you?
>>
>> Hi,
>>
>> ext2 only reads the first two sectors in mount, which is normally ok ,
>> but there are exceptions. For example, cpio filesystem could be less
>> one sector.
>
> I don't understand what you mean here.  If grub_disk_read failed, this
> indicates something's broken down in the disk layer doesn't it?  How is
> the number of sectors related to this?
>

Hi,

grub_disk_read checks for disk limit. For example, cpio file system
can be one sector long, trying to read two sectors would cause a out
of range error.

>> Also, hostfs always return error in its read function,
>> which would cause ext2 to fail. The effect can be seen in grub-fstest.
>> hostfs is the first fs driver to register, and the last to query. When
>> accessing the (host) device, ext2 cause it to fail before hostfs has a
>> chance to see it.
>
> Why does hostfs fail?  Is this intentional?

Yes, it's intentional. Reading raw sectors from (host) doesn't make
much sense. The (host) device is a place holder for hostfs filesystem.

-- 
Bean