mkfs.minix V3 is broken

mkfs.minix V3 is broken

[Maurizio Lombardi]

Hi all,

I noticed a lot of bugs in the mkfs.minix program when dealing with V3
filesystems.
I did a lot of fixes in the source code and then I decided to set up a
github repository to make the review easier:

git@github.com:maurizio-lombardi/util-linux.git

Can the mkfs.minix mantainer review the patches please?

Please cc me because I'm not subscribed to the list.

Regards,
-- 
--------------------
Maurizio Lombardi

Re: mkfs.minix V3 is broken

[Davidlohr Bueso]

On Mon, 2011-11-21 at 20:40 +0100, Maurizio Lombardi wrote:
> Hi all,
> 
> I noticed a lot of bugs in the mkfs.minix program when dealing with V3
> filesystems.
> I did a lot of fixes in the source code and then I decided to set up a
> github repository to make the review easier:
> 
> git@github.com:maurizio-lombardi/util-linux.git
> 
> Can the mkfs.minix mantainer review the patches please?

Most of the work I did on supporting v3 was based on the kernel's
implementation and the mkfs shipped with minix (by ast), so a lot of
what you say makes sense. I've taken a quick look at the changes and
most are bugs are pretty straightforward, except:

- mkfs.minix: The total number of zones is limited to 65536 only on V1
filesystems

Unless I'm missing something, this doesn't really change any logic.


I'll give the changes a proper test over the weekend.

Thanks,
Davidlohr

> 
> Please cc me because I'm not subscribed to the list.
> 
> Regards,

Re: mkfs.minix V3 is broken

[Maurizio Lombardi]

On Mon, Nov 21, 2011 at 11:06 PM, Davidlohr Bueso <dave@gnu.org> wrote:
>
> Most of the work I did on supporting v3 was based on the kernel's
> implementation and the mkfs shipped with minix (by ast), so a lot of
> what you say makes sense. I've taken a quick look at the changes and
> most are bugs are pretty straightforward, except:
>
> - mkfs.minix: The total number of zones is limited to 65536 only on V1
> filesystems
>
> Unless I'm missing something, this doesn't really change any logic.

Sorry, probably the commit message is not very well written... However
this commit fixes a very nasty bug, let me explain why....
Look at what the code did *before* my patch:

if (fs_version == 3)
     magic = MINIX3_SUPER_MAGIC;
if (fs_version == 2) {
     if (namelen == 14)
       magic = MINIX2_SUPER_MAGIC;
     else
       magic = MINIX2_SUPER_MAGIC2;
} else {
    if (BLOCKS > MINIX_MAX_INODES)
       BLOCKS = MINIX_MAX_INODES;
}

Can you see what happens if fs_version is == 3 ?
The total number of blocks is restricted to a maximum of 65536 both
with V1 and V3 filesystems, this is wrong because the total number of
blocks in V3 is a 32 bit number (the same of V2). With this
realization, it is really simple to fix the bug, and this is exactly
what I did:

if (fs_version == 3)
     magic = MINIX3_SUPER_MAGIC;
- if (fs_version == 2) {
+else if (fs_version == 2) {
     if (namelen == 14)
       magic = MINIX2_SUPER_MAGIC;
     else
       magic = MINIX2_SUPER_MAGIC2;
} else {
    if (BLOCKS > MINIX_MAX_INODES)
       BLOCKS = MINIX_MAX_INODES;
}

>
> I'll give the changes a proper test over the weekend.

Ok, thanks.
In case you accept the changes I did, this is the github repository
link with read-only access from where you can pull the changes from:

git://github.com/maurizio-lombardi/util-linux.git

Regards,
-- 
--------------------
Maurizio Lombardi

Re: mkfs.minix V3 is broken

[Maurizio Lombardi]

>    if (BLOCKS > MINIX_MAX_INODES)
>       BLOCKS = MINIX_MAX_INODES;

Please note that this piece of code is horrible too, comparing the
number of blocks to the max number of inodes is like comparing apples
and oranges, no? :)

In general I think that the mkfs.minix is full of weird things and
needs a serious cleanup.

Regards,
-- 
--------------------
Maurizio Lombardi

Re: mkfs.minix V3 is broken

[Karel Zak]

On Tue, Nov 22, 2011 at 11:05:04AM +0100, Maurizio Lombardi wrote:
> >    if (BLOCKS > MINIX_MAX_INODES)
> >       BLOCKS = MINIX_MAX_INODES;
> 
> Please note that this piece of code is horrible too, comparing the
> number of blocks to the max number of inodes is like comparing apples
> and oranges, no? :)
> 
> In general I think that the mkfs.minix is full of weird things and
> needs a serious cleanup.

 Go ahead! :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: mkfs.minix V3 is broken

[Davidlohr Bueso]

On Tue, 2011-11-22 at 10:03 +0100, Maurizio Lombardi wrote:
> On Mon, Nov 21, 2011 at 11:06 PM, Davidlohr Bueso <dave@gnu.org> wrote:
> >
> > Most of the work I did on supporting v3 was based on the kernel's
> > implementation and the mkfs shipped with minix (by ast), so a lot of
> > what you say makes sense. I've taken a quick look at the changes and
> > most are bugs are pretty straightforward, except:
> >
> > - mkfs.minix: The total number of zones is limited to 65536 only on V1
> > filesystems
> >
> > Unless I'm missing something, this doesn't really change any logic.
> 
> Sorry, probably the commit message is not very well written... However
> this commit fixes a very nasty bug, let me explain why....
> Look at what the code did *before* my patch:
> 
> if (fs_version == 3)
>      magic = MINIX3_SUPER_MAGIC;
> if (fs_version == 2) {
>      if (namelen == 14)
>        magic = MINIX2_SUPER_MAGIC;
>      else
>        magic = MINIX2_SUPER_MAGIC2;
> } else {
>     if (BLOCKS > MINIX_MAX_INODES)
>        BLOCKS = MINIX_MAX_INODES;
> }
> 
> Can you see what happens if fs_version is == 3 ?
> The total number of blocks is restricted to a maximum of 65536 both
> with V1 and V3 filesystems, this is wrong because the total number of
> blocks in V3 is a 32 bit number (the same of V2). With this
> realization, it is really simple to fix the bug, and this is exactly
> what I did:

Oh, yes, my bad, we should definitely have more blocks with v3. 

I made a couple of filesystems with your changes and things look good,
specially incrementing the amount of inodes. The 60 character filename
was already featured but it's good to specify it explicitly as well.

Karel, unless you have any objections please pull these changes in.

Thanks,
Davidlohr

> 
> if (fs_version == 3)
>      magic = MINIX3_SUPER_MAGIC;
> - if (fs_version == 2) {
> +else if (fs_version == 2) {
>      if (namelen == 14)
>        magic = MINIX2_SUPER_MAGIC;
>      else
>        magic = MINIX2_SUPER_MAGIC2;
> } else {
>     if (BLOCKS > MINIX_MAX_INODES)
>        BLOCKS = MINIX_MAX_INODES;
> }
> 
> >
> > I'll give the changes a proper test over the weekend.
> 
> Ok, thanks.
> In case you accept the changes I did, this is the github repository
> link with read-only access from where you can pull the changes from:
> 
> git://github.com/maurizio-lombardi/util-linux.git
> 
> Regards,

Re: mkfs.minix V3 is broken

[Karel Zak]

On Sun, Nov 27, 2011 at 11:03:38PM +0100, Davidlohr Bueso wrote:
> On Tue, 2011-11-22 at 10:03 +0100, Maurizio Lombardi wrote:
> > On Mon, Nov 21, 2011 at 11:06 PM, Davidlohr Bueso <dave@gnu.org> wrote:
> > >
> > > Most of the work I did on supporting v3 was based on the kernel's
> > > implementation and the mkfs shipped with minix (by ast), so a lot of
> > > what you say makes sense. I've taken a quick look at the changes and
> > > most are bugs are pretty straightforward, except:
> > >
> > > - mkfs.minix: The total number of zones is limited to 65536 only on V1
> > > filesystems
> > >
> > > Unless I'm missing something, this doesn't really change any logic.
> > 
> > Sorry, probably the commit message is not very well written... However
> > this commit fixes a very nasty bug, let me explain why....
> > Look at what the code did *before* my patch:
> > 
> > if (fs_version == 3)
> >      magic = MINIX3_SUPER_MAGIC;
> > if (fs_version == 2) {
> >      if (namelen == 14)
> >        magic = MINIX2_SUPER_MAGIC;
> >      else
> >        magic = MINIX2_SUPER_MAGIC2;
> > } else {
> >     if (BLOCKS > MINIX_MAX_INODES)
> >        BLOCKS = MINIX_MAX_INODES;
> > }
> > 
> > Can you see what happens if fs_version is == 3 ?
> > The total number of blocks is restricted to a maximum of 65536 both
> > with V1 and V3 filesystems, this is wrong because the total number of
> > blocks in V3 is a 32 bit number (the same of V2). With this
> > realization, it is really simple to fix the bug, and this is exactly
> > what I did:
> 
> Oh, yes, my bad, we should definitely have more blocks with v3. 
> 
> I made a couple of filesystems with your changes and things look good,
> specially incrementing the amount of inodes. The 60 character filename
> was already featured but it's good to specify it explicitly as well.
> 
> Karel, unless you have any objections please pull these changes in.

 Merged, thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com