Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Geert Uytterhoeven]

Hi Michael,

On Mon, Jun 25, 2018 at 9:53 AM Michael Schmitz  wrote:
> OK, I'll prepare a patch and submit it to linux-block for review. I'll

Thanks a lot!

> have to refer to your testing back in 2012 since all I can test is
> whether the patch still allows partition tables on small disks to be
> recognized at this time (unless Adrian has a 2 TB disk and a SATA-SCSI
> bridge to test this properly on).

Sparse file and loopback mounting with losetup --partscan?

> Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> > Michael Schmitz - 27.04.18, 04:11:
> >> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> >> indicate the RDB parser bug is fixed by the patch given there, so if
> >> Martin now submits the patch, all should be well?
> > Ok, better be honest than having anyone waiting for it:
> >
> > I do not care enough about this, in order to motivate myself preparing
> > the a patch from Joanne Dow´s fix.
> >
> > I am not even using my Amiga boxes anymore, not even the Sam440ep which
> > I still have in my apartment.
> >
> > So RDB support in Linux it remains broken for disks larger 2 TB, unless
> > someone else does.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Geert Uytterhoeven]

Hi Michael,

On Mon, Jun 25, 2018 at 9:53 AM Michael Schmitz  wrote:
> OK, I'll prepare a patch and submit it to linux-block for review. I'll

Thanks a lot!

> have to refer to your testing back in 2012 since all I can test is
> whether the patch still allows partition tables on small disks to be
> recognized at this time (unless Adrian has a 2 TB disk and a SATA-SCSI
> bridge to test this properly on).

Sparse file and loopback mounting with losetup --partscan?

> Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> > Michael Schmitz - 27.04.18, 04:11:
> >> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> >> indicate the RDB parser bug is fixed by the patch given there, so if
> >> Martin now submits the patch, all should be well?
> > Ok, better be honest than having anyone waiting for it:
> >
> > I do not care enough about this, in order to motivate myself preparing
> > the a patch from Joanne Dow´s fix.
> >
> > I am not even using my Amiga boxes anymore, not even the Sam440ep which
> > I still have in my apartment.
> >
> > So RDB support in Linux it remains broken for disks larger 2 TB, unless
> > someone else does.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi Michael.

Michael Schmitz - 25.06.18, 09:53:
> OK, I'll prepare a patch and submit it to linux-block for review. I'll
> have to refer to your testing back in 2012 since all I can test is
> whether the patch still allows partition tables on small disks to be
> recognized at this time (unless Adrian has a 2 TB disk and a
> SATA-SCSI bridge to test this properly on).

Thank you very much.

I believe the testing I did is still valid.

Feel free to include any parts of the description of the test I made 
back then into your patch description as you see it as relevant for it.

Also feel free to include my Tested-By: (probably with a hint the test 
was in 2012).

I am not sure I am ready to permanently let go of (some of) the hardware 
I still have collected, but at some time I may. I do have SATA-SCSI 
bridges. That A4000T I have here probably could be a nice Debian m68k 
build host.

Thanks,
Martin

> 
> Cheers,
> 
> Michael
> 
> Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> > Hi.
> > 
> > Michael Schmitz - 27.04.18, 04:11:
> >> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> >> indicate the RDB parser bug is fixed by the patch given there, so
> >> if
> >> Martin now submits the patch, all should be well?
> > 
> > Ok, better be honest than having anyone waiting for it:
> > 
> > I do not care enough about this, in order to motivate myself
> > preparing the a patch from Joanne Dow´s fix.
> > 
> > I am not even using my Amiga boxes anymore, not even the Sam440ep
> > which I still have in my apartment.
> > 
> > So RDB support in Linux it remains broken for disks larger 2 TB,
> > unless someone else does.
> > 
> > Thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k"
> in the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Martin

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi Michael.

Michael Schmitz - 25.06.18, 09:53:
> OK, I'll prepare a patch and submit it to linux-block for review. I'll
> have to refer to your testing back in 2012 since all I can test is
> whether the patch still allows partition tables on small disks to be
> recognized at this time (unless Adrian has a 2 TB disk and a
> SATA-SCSI bridge to test this properly on).

Thank you very much.

I believe the testing I did is still valid.

Feel free to include any parts of the description of the test I made 
back then into your patch description as you see it as relevant for it.

Also feel free to include my Tested-By: (probably with a hint the test 
was in 2012).

I am not sure I am ready to permanently let go of (some of) the hardware 
I still have collected, but at some time I may. I do have SATA-SCSI 
bridges. That A4000T I have here probably could be a nice Debian m68k 
build host.

Thanks,
Martin

> 
> Cheers,
> 
> Michael
> 
> Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> > Hi.
> > 
> > Michael Schmitz - 27.04.18, 04:11:
> >> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> >> indicate the RDB parser bug is fixed by the patch given there, so
> >> if
> >> Martin now submits the patch, all should be well?
> > 
> > Ok, better be honest than having anyone waiting for it:
> > 
> > I do not care enough about this, in order to motivate myself
> > preparing the a patch from Joanne Dow´s fix.
> > 
> > I am not even using my Amiga boxes anymore, not even the Sam440ep
> > which I still have in my apartment.
> > 
> > So RDB support in Linux it remains broken for disks larger 2 TB,
> > unless someone else does.
> > 
> > Thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k"
> in the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Martin

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Michael Schmitz]

Hi Martin,

OK, I'll prepare a patch and submit it to linux-block for review. I'll
have to refer to your testing back in 2012 since all I can test is
whether the patch still allows partition tables on small disks to be
recognized at this time (unless Adrian has a 2 TB disk and a SATA-SCSI
bridge to test this properly on).

Cheers,

    Michael



Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> Hi.
>
> Michael Schmitz - 27.04.18, 04:11:
>> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
>> indicate the RDB parser bug is fixed by the patch given there, so if
>> Martin now submits the patch, all should be well?
> Ok, better be honest than having anyone waiting for it:
>
> I do not care enough about this, in order to motivate myself preparing 
> the a patch from Joanne Dow´s fix.
>
> I am not even using my Amiga boxes anymore, not even the Sam440ep which 
> I still have in my apartment.
>
> So RDB support in Linux it remains broken for disks larger 2 TB, unless 
> someone else does.
>
> Thanks.

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Michael Schmitz]

Hi Martin,

OK, I'll prepare a patch and submit it to linux-block for review. I'll
have to refer to your testing back in 2012 since all I can test is
whether the patch still allows partition tables on small disks to be
recognized at this time (unless Adrian has a 2 TB disk and a SATA-SCSI
bridge to test this properly on).

Cheers,

    Michael



Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> Hi.
>
> Michael Schmitz - 27.04.18, 04:11:
>> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
>> indicate the RDB parser bug is fixed by the patch given there, so if
>> Martin now submits the patch, all should be well?
> Ok, better be honest than having anyone waiting for it:
>
> I do not care enough about this, in order to motivate myself preparing 
> the a patch from Joanne Dow´s fix.
>
> I am not even using my Amiga boxes anymore, not even the Sam440ep which 
> I still have in my apartment.
>
> So RDB support in Linux it remains broken for disks larger 2 TB, unless 
> someone else does.
>
> Thanks.

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi.

Michael Schmitz - 27.04.18, 04:11:
> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> indicate the RDB parser bug is fixed by the patch given there, so if
> Martin now submits the patch, all should be well?

Ok, better be honest than having anyone waiting for it:

I do not care enough about this, in order to motivate myself preparing 
the a patch from Joanne Dow´s fix.

I am not even using my Amiga boxes anymore, not even the Sam440ep which 
I still have in my apartment.

So RDB support in Linux it remains broken for disks larger 2 TB, unless 
someone else does.

Thanks.
-- 
Martin

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi.

Michael Schmitz - 27.04.18, 04:11:
> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
> indicate the RDB parser bug is fixed by the patch given there, so if
> Martin now submits the patch, all should be well?

Ok, better be honest than having anyone waiting for it:

I do not care enough about this, in order to motivate myself preparing 
the a patch from Joanne Dow´s fix.

I am not even using my Amiga boxes anymore, not even the Sam440ep which 
I still have in my apartment.

So RDB support in Linux it remains broken for disks larger 2 TB, unless 
someone else does.

Thanks.
-- 
Martin

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Thu 2018-04-26 12:36:50, Martin Steigerwald wrote:
> Pavel Machek - 26.04.18, 08:11:
> > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > Recently ncpfs got moved to staging.  Also recently, we had some
> > > fuzzer developers report bugs in hfs, which they deem a security
> > > hole because Ubuntu attempts to automount an inserted USB device as
> > > hfs.
> > 
> > We promise "no-regressions" for code in main repository, no such
> > promise for staging. We have quite a lot of code without maintainer.
> > 
> > Moving code to staging means it will get broken -- staging was not
> > designed for this. I believe moving anything there is bad idea.
> > 
> > Staging is for ugly code, not for code that needs new maintainter.
> 
> Good point.
> 
> Moving things in and out to some "unmaintained" directory… I am not sure 
> about that either. I tend to think that moving code around does not 
> solve the underlying issue.
> 
> Which, according to what I got from Matthew, was that distributors 
> enable just about every filesystem they can enable which lead to hfs 
> being used for automounting an USB stick formatted with it.

If distro's are shipping it, they are also willing to fix it. So
... no need to drop the code just yet.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Thu 2018-04-26 12:36:50, Martin Steigerwald wrote:
> Pavel Machek - 26.04.18, 08:11:
> > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > Recently ncpfs got moved to staging.  Also recently, we had some
> > > fuzzer developers report bugs in hfs, which they deem a security
> > > hole because Ubuntu attempts to automount an inserted USB device as
> > > hfs.
> > 
> > We promise "no-regressions" for code in main repository, no such
> > promise for staging. We have quite a lot of code without maintainer.
> > 
> > Moving code to staging means it will get broken -- staging was not
> > designed for this. I believe moving anything there is bad idea.
> > 
> > Staging is for ugly code, not for code that needs new maintainter.
> 
> Good point.
> 
> Moving things in and out to some "unmaintained" directory… I am not sure 
> about that either. I tend to think that moving code around does not 
> solve the underlying issue.
> 
> Which, according to what I got from Matthew, was that distributors 
> enable just about every filesystem they can enable which lead to hfs 
> being used for automounting an USB stick formatted with it.

If distro's are shipping it, they are also willing to fix it. So
... no need to drop the code just yet.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Sun 2018-04-29 16:37:37, Greg KH wrote:
> On Sun, Apr 29, 2018 at 10:07:26PM +0200, Ondrej Zary wrote:
> > On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> > > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > > > Recently ncpfs got moved to staging.  Also recently, we had some 
> > > > > fuzzer
> > > > > developers report bugs in hfs, which they deem a security hole because
> > > > > Ubuntu attempts to automount an inserted USB device as hfs.
> > > >
> > > > We promise "no-regressions" for code in main repository, no such
> > > > promise for staging. We have quite a lot of code without maintainer.
> > > >
> > > > Moving code to staging means it will get broken -- staging was not
> > > > designed for this. I believe moving anything there is bad idea.
> > > >
> > > > Staging is for ugly code, not for code that needs new maintainter.
> > >
> > > Staging is used for getting code _out_ of the kernel tree as well as
> > > _in_.  We use it all the time to move code there, see if anyone shows up
> > > in 6-8 months to say "I will fix this!", and if not, we delete it.
> > >
> > > Look at what just happened to IRDA in the 4.17-rc1 release as an example
> > > of this.
> > 
> > Really a "great" example of deleting working code :( 
> 
> What do you mean?  The irda code was broken and not working at all.
> There were loads of bug reports about it for years, with no developers
> or maintainers willing to do the work on it to get it to actually work
> again.
> 
> If someone does want to step up and do it, great!  It's a simple revert
> of two git commits and they are back in business.

> Dropping code from the tree is not like it is gone for forever.  If
> someone wants to pick it up, it is trivial to do so.

That is a lie and you know it.

In particular, having code moved to staging means it is going to
bitrot, because it will not be updated with global changes.

Plus coding standards change over time, so if you simply revert,
you'll not be able to simply merge it back.

Plus that revert means bisection is no longer easy/possible to find
the real breakages.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Sun 2018-04-29 16:37:37, Greg KH wrote:
> On Sun, Apr 29, 2018 at 10:07:26PM +0200, Ondrej Zary wrote:
> > On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> > > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > > > Recently ncpfs got moved to staging.  Also recently, we had some 
> > > > > fuzzer
> > > > > developers report bugs in hfs, which they deem a security hole because
> > > > > Ubuntu attempts to automount an inserted USB device as hfs.
> > > >
> > > > We promise "no-regressions" for code in main repository, no such
> > > > promise for staging. We have quite a lot of code without maintainer.
> > > >
> > > > Moving code to staging means it will get broken -- staging was not
> > > > designed for this. I believe moving anything there is bad idea.
> > > >
> > > > Staging is for ugly code, not for code that needs new maintainter.
> > >
> > > Staging is used for getting code _out_ of the kernel tree as well as
> > > _in_.  We use it all the time to move code there, see if anyone shows up
> > > in 6-8 months to say "I will fix this!", and if not, we delete it.
> > >
> > > Look at what just happened to IRDA in the 4.17-rc1 release as an example
> > > of this.
> > 
> > Really a "great" example of deleting working code :( 
> 
> What do you mean?  The irda code was broken and not working at all.
> There were loads of bug reports about it for years, with no developers
> or maintainers willing to do the work on it to get it to actually work
> again.
> 
> If someone does want to step up and do it, great!  It's a simple revert
> of two git commits and they are back in business.

> Dropping code from the tree is not like it is gone for forever.  If
> someone wants to pick it up, it is trivial to do so.

That is a lie and you know it.

In particular, having code moved to staging means it is going to
bitrot, because it will not be updated with global changes.

Plus coding standards change over time, so if you simply revert,
you'll not be able to simply merge it back.

Plus that revert means bisection is no longer easy/possible to find
the real breakages.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Greg KH]

On Sun, Apr 29, 2018 at 10:07:26PM +0200, Ondrej Zary wrote:
> On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > > > developers report bugs in hfs, which they deem a security hole because
> > > > Ubuntu attempts to automount an inserted USB device as hfs.
> > >
> > > We promise "no-regressions" for code in main repository, no such
> > > promise for staging. We have quite a lot of code without maintainer.
> > >
> > > Moving code to staging means it will get broken -- staging was not
> > > designed for this. I believe moving anything there is bad idea.
> > >
> > > Staging is for ugly code, not for code that needs new maintainter.
> >
> > Staging is used for getting code _out_ of the kernel tree as well as
> > _in_.  We use it all the time to move code there, see if anyone shows up
> > in 6-8 months to say "I will fix this!", and if not, we delete it.
> >
> > Look at what just happened to IRDA in the 4.17-rc1 release as an example
> > of this.
> 
> Really a "great" example of deleting working code :( 

What do you mean?  The irda code was broken and not working at all.
There were loads of bug reports about it for years, with no developers
or maintainers willing to do the work on it to get it to actually work
again.

If someone does want to step up and do it, great!  It's a simple revert
of two git commits and they are back in business.

Dropping code from the tree is not like it is gone for forever.  If
someone wants to pick it up, it is trivial to do so.  Git is good :)

thanks,

greg k-h

Re: Moving unmaintained filesystems to staging

[Greg KH]

On Sun, Apr 29, 2018 at 10:07:26PM +0200, Ondrej Zary wrote:
> On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > > > developers report bugs in hfs, which they deem a security hole because
> > > > Ubuntu attempts to automount an inserted USB device as hfs.
> > >
> > > We promise "no-regressions" for code in main repository, no such
> > > promise for staging. We have quite a lot of code without maintainer.
> > >
> > > Moving code to staging means it will get broken -- staging was not
> > > designed for this. I believe moving anything there is bad idea.
> > >
> > > Staging is for ugly code, not for code that needs new maintainter.
> >
> > Staging is used for getting code _out_ of the kernel tree as well as
> > _in_.  We use it all the time to move code there, see if anyone shows up
> > in 6-8 months to say "I will fix this!", and if not, we delete it.
> >
> > Look at what just happened to IRDA in the 4.17-rc1 release as an example
> > of this.
> 
> Really a "great" example of deleting working code :( 

What do you mean?  The irda code was broken and not working at all.
There were loads of bug reports about it for years, with no developers
or maintainers willing to do the work on it to get it to actually work
again.

If someone does want to step up and do it, great!  It's a simple revert
of two git commits and they are back in business.

Dropping code from the tree is not like it is gone for forever.  If
someone wants to pick it up, it is trivial to do so.  Git is good :)

thanks,

greg k-h

Re: Moving unmaintained filesystems to staging

[Ondrej Zary]

On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > > developers report bugs in hfs, which they deem a security hole because
> > > Ubuntu attempts to automount an inserted USB device as hfs.
> >
> > We promise "no-regressions" for code in main repository, no such
> > promise for staging. We have quite a lot of code without maintainer.
> >
> > Moving code to staging means it will get broken -- staging was not
> > designed for this. I believe moving anything there is bad idea.
> >
> > Staging is for ugly code, not for code that needs new maintainter.
>
> Staging is used for getting code _out_ of the kernel tree as well as
> _in_.  We use it all the time to move code there, see if anyone shows up
> in 6-8 months to say "I will fix this!", and if not, we delete it.
>
> Look at what just happened to IRDA in the 4.17-rc1 release as an example
> of this.

Really a "great" example of deleting working code :( 

-- 
Ondrej Zary

Re: Moving unmaintained filesystems to staging

[Ondrej Zary]

On Sunday 29 April 2018 14:07:05 Greg KH wrote:
> On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > > developers report bugs in hfs, which they deem a security hole because
> > > Ubuntu attempts to automount an inserted USB device as hfs.
> >
> > We promise "no-regressions" for code in main repository, no such
> > promise for staging. We have quite a lot of code without maintainer.
> >
> > Moving code to staging means it will get broken -- staging was not
> > designed for this. I believe moving anything there is bad idea.
> >
> > Staging is for ugly code, not for code that needs new maintainter.
>
> Staging is used for getting code _out_ of the kernel tree as well as
> _in_.  We use it all the time to move code there, see if anyone shows up
> in 6-8 months to say "I will fix this!", and if not, we delete it.
>
> Look at what just happened to IRDA in the 4.17-rc1 release as an example
> of this.

Really a "great" example of deleting working code :( 

-- 
Ondrej Zary

Re: Moving unmaintained filesystems to staging

[Greg KH]

On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > developers report bugs in hfs, which they deem a security hole because
> > Ubuntu attempts to automount an inserted USB device as hfs.
> 
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
> 
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
> 
> Staging is for ugly code, not for code that needs new maintainter.

Staging is used for getting code _out_ of the kernel tree as well as
_in_.  We use it all the time to move code there, see if anyone shows up
in 6-8 months to say "I will fix this!", and if not, we delete it.

Look at what just happened to IRDA in the 4.17-rc1 release as an example
of this.

thanks,

greg k-h

Re: Moving unmaintained filesystems to staging

[Greg KH]

On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> > developers report bugs in hfs, which they deem a security hole because
> > Ubuntu attempts to automount an inserted USB device as hfs.
> 
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
> 
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
> 
> Staging is for ugly code, not for code that needs new maintainter.

Staging is used for getting code _out_ of the kernel tree as well as
_in_.  We use it all the time to move code there, see if anyone shows up
in 6-8 months to say "I will fix this!", and if not, we delete it.

Look at what just happened to IRDA in the 4.17-rc1 release as an example
of this.

thanks,

greg k-h

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Geert Uytterhoeven - 26.04.18, 13:08:
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
> 
>  wrote:
> > You probably put your stick into a cave with ancient sleeping
> > dragons 
> > 
> > Added in linux-m68k mailing list, as they likely have an opinion on
> > how to treat affs + RDB partition support. Also added in Jens Axboe
> > about patching that RDB support broken with 2 TB or larger
> > harddisks issue which had been in Linux kernel for 6 years while a
> > patch exists that to my testing back then solves the issue.
[…]
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's
> still not a reason to move it to staging (hi msdos partitioning!).

What I ran into was *not* a limitation in the RDB format, but a bug in 
the Linux implementation on it. After Joanne Dow´s change the 2 TB disk 
was detected and handled properly by Linux. Also AmigaOS 4.x handles 
those disks just well and I think also AmigaOS 3.1/3.5/3.9 supported 
them, but I am not sure on the details on that, it has been a long time 
since I last booted one of my Amiga systems.

Many classic Amiga users may not deal with such large disks, but AmigaOS 
4 users probably still, and some of them may run Linux on their PowerPC 
motherboards as well.

So I think the issue is worth fixing and am looking into submitting the 
fix, which looks pretty straight-forward to me upstream unless someone 
bets me to it.

Thanks,
-- 
Martin

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Geert Uytterhoeven - 26.04.18, 13:08:
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
> 
>  wrote:
> > You probably put your stick into a cave with ancient sleeping
> > dragons 
> > 
> > Added in linux-m68k mailing list, as they likely have an opinion on
> > how to treat affs + RDB partition support. Also added in Jens Axboe
> > about patching that RDB support broken with 2 TB or larger
> > harddisks issue which had been in Linux kernel for 6 years while a
> > patch exists that to my testing back then solves the issue.
[…]
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's
> still not a reason to move it to staging (hi msdos partitioning!).

What I ran into was *not* a limitation in the RDB format, but a bug in 
the Linux implementation on it. After Joanne Dow´s change the 2 TB disk 
was detected and handled properly by Linux. Also AmigaOS 4.x handles 
those disks just well and I think also AmigaOS 3.1/3.5/3.9 supported 
them, but I am not sure on the details on that, it has been a long time 
since I last booted one of my Amiga systems.

Many classic Amiga users may not deal with such large disks, but AmigaOS 
4 users probably still, and some of them may run Linux on their PowerPC 
motherboards as well.

So I think the issue is worth fixing and am looking into submitting the 
fix, which looks pretty straight-forward to me upstream unless someone 
bets me to it.

Thanks,
-- 
Martin

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Michael Schmitz]

Hi Geert,

test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
indicate the RDB parser bug is fixed by the patch given there, so if
Martin now submits the patch, all should be well?

(MSDOS partition support is not the only one with limitations - the
SGI partition parser also uses int types. Brings back memories of /me
hacking a large disk into many small partitions because Irix couldn't
digest it whole!)

Going to look into Atari partition format limitations now ...

Cheers,

  Michael


On Thu, Apr 26, 2018 at 11:08 PM, Geert Uytterhoeven
 wrote:
> Hi Martin,
>
> CC jdow
>
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
>  wrote:
>> You probably put your stick into a cave with ancient sleeping dragons :)
>>
>> Added in linux-m68k mailing list, as they likely have an opinion on how
>> to treat affs + RDB partition support. Also added in Jens Axboe about
>> patching that RDB support broken with 2 TB or larger harddisks issue
>> which had been in Linux kernel for 6 years while a patch exists that to
>> my testing back then solves the issue.
>
> While non-native Linux filesystem support (e.g. affs/isofs/...) could be
> handled by FUSE, moving RDB partition support to staging is not an option,
> as it is the only partitioning scheme that Amigas can boot from.
>
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's still not
> a reason to move it to staging (hi msdos partitioning!).
>
>> Matthew Wilcox - 26.04.18, 04:57:
>>> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
>>> > I had similar toughts some time ago while browsing the fs/
>>> > directory.
>>> > Access to the filesystem images can be reimplemented in FUSE, but
>>> > other than that, I don't think the in-kernel code would be missed.
>>> >
>>> > It's hard to know how many users are there. I was curious eg. about
>>> > bfs, befs, coda or feevxfs, looked at the last commits and searched
>>> > around web if there are any mentions or user community. But as long
>>> > as there's somebody listed in MAINTAINERS, the above are not
>>> > candidates for moving to staging or deletion.
>>>
>>> Yeah, it's pretty sad how few commits some of these filesystems have
>>> had in recent years.  One can argue that they're stable and don't need
>>> to be fixed because they aren't broken, but I find it hard to believe
>>> that any of them were better-implemented than ext2 which still sees
>>> regular bugfixes.
>>
>> Regarding affs there is a severe issue which is not in affs itself but
>> in the handling of Rigid Disk Block (RDB) partitions, the Amiga
>> partitioning standard, which is far more advanced than MBR: It overruns
>> for 2 TB or larger drives and then wraps over to the beginning of the
>> drive – I bet you can imagine what happens if you write to an area
>> larger than 2 TB. I learned this with an external 2TB RDB partitioned
>> harddisk back then, which I used for Sam440ep (a kind of successor for
>> old, classic Amiga hardware) backup + some Linux related stuff in
>> another partition.
>>
>> Joanne Dow, a developer who developed hdwrench.library which HDToolBox
>> uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then,
>> but never officially put it officially through upstreaming as I offered
>> to make a good description and upstream it through Jens Axboe.
>>
>> I may take this as a reason to… actually follow through this time,
>> hopefully remembering all the details in order to provide a meaningful
>> patch description – but I think mostly I can do just careful copy and
>> paste. Even tough I believe Joanne Dow´s fix only fixed my bug report
>> 43511, but not 43511 which is more about a safeguarding issue in case of
>> future overflows, I still think it would be good to go in in case affs +
>> RDB stays in their current places.
>>
>> However, in case you move affs to staging, I may be less motivated to do
>> so, but then I suggest you also move RDB partitioning support to
>> staging, cause this is the one that is known to be dangerously badly for
>> 2 TB or larger disks. And yeah, I admit I did not follow through with
>> having that patch upstreamed. Probably I did not want to be responsible
>> in case my description would not have been absolutely accurate or the
>> patch breaks something else. I do not have that 2 TB drive anymore and
>> don´t feel like setting one up in a suitable way in order to go about
>> this patch, but my testing back then was quite elaborate and I still
>> feel pretty confident about it.
>>
>> I totally get your motivation, but I would find it somewhat sad to see
>> the filesystems you mentioned go into staging. However, as I just shown
>> clearly, for the user it may be better, cause there may be unfixed
>> dangerous bugs. FUSE might be an interesting approach, but I bet it will
>> not solve the maintenance issue. If there is no one 

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Michael Schmitz]

Hi Geert,

test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
indicate the RDB parser bug is fixed by the patch given there, so if
Martin now submits the patch, all should be well?

(MSDOS partition support is not the only one with limitations - the
SGI partition parser also uses int types. Brings back memories of /me
hacking a large disk into many small partitions because Irix couldn't
digest it whole!)

Going to look into Atari partition format limitations now ...

Cheers,

  Michael


On Thu, Apr 26, 2018 at 11:08 PM, Geert Uytterhoeven
 wrote:
> Hi Martin,
>
> CC jdow
>
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
>  wrote:
>> You probably put your stick into a cave with ancient sleeping dragons :)
>>
>> Added in linux-m68k mailing list, as they likely have an opinion on how
>> to treat affs + RDB partition support. Also added in Jens Axboe about
>> patching that RDB support broken with 2 TB or larger harddisks issue
>> which had been in Linux kernel for 6 years while a patch exists that to
>> my testing back then solves the issue.
>
> While non-native Linux filesystem support (e.g. affs/isofs/...) could be
> handled by FUSE, moving RDB partition support to staging is not an option,
> as it is the only partitioning scheme that Amigas can boot from.
>
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's still not
> a reason to move it to staging (hi msdos partitioning!).
>
>> Matthew Wilcox - 26.04.18, 04:57:
>>> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
>>> > I had similar toughts some time ago while browsing the fs/
>>> > directory.
>>> > Access to the filesystem images can be reimplemented in FUSE, but
>>> > other than that, I don't think the in-kernel code would be missed.
>>> >
>>> > It's hard to know how many users are there. I was curious eg. about
>>> > bfs, befs, coda or feevxfs, looked at the last commits and searched
>>> > around web if there are any mentions or user community. But as long
>>> > as there's somebody listed in MAINTAINERS, the above are not
>>> > candidates for moving to staging or deletion.
>>>
>>> Yeah, it's pretty sad how few commits some of these filesystems have
>>> had in recent years.  One can argue that they're stable and don't need
>>> to be fixed because they aren't broken, but I find it hard to believe
>>> that any of them were better-implemented than ext2 which still sees
>>> regular bugfixes.
>>
>> Regarding affs there is a severe issue which is not in affs itself but
>> in the handling of Rigid Disk Block (RDB) partitions, the Amiga
>> partitioning standard, which is far more advanced than MBR: It overruns
>> for 2 TB or larger drives and then wraps over to the beginning of the
>> drive – I bet you can imagine what happens if you write to an area
>> larger than 2 TB. I learned this with an external 2TB RDB partitioned
>> harddisk back then, which I used for Sam440ep (a kind of successor for
>> old, classic Amiga hardware) backup + some Linux related stuff in
>> another partition.
>>
>> Joanne Dow, a developer who developed hdwrench.library which HDToolBox
>> uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then,
>> but never officially put it officially through upstreaming as I offered
>> to make a good description and upstream it through Jens Axboe.
>>
>> I may take this as a reason to… actually follow through this time,
>> hopefully remembering all the details in order to provide a meaningful
>> patch description – but I think mostly I can do just careful copy and
>> paste. Even tough I believe Joanne Dow´s fix only fixed my bug report
>> 43511, but not 43511 which is more about a safeguarding issue in case of
>> future overflows, I still think it would be good to go in in case affs +
>> RDB stays in their current places.
>>
>> However, in case you move affs to staging, I may be less motivated to do
>> so, but then I suggest you also move RDB partitioning support to
>> staging, cause this is the one that is known to be dangerously badly for
>> 2 TB or larger disks. And yeah, I admit I did not follow through with
>> having that patch upstreamed. Probably I did not want to be responsible
>> in case my description would not have been absolutely accurate or the
>> patch breaks something else. I do not have that 2 TB drive anymore and
>> don´t feel like setting one up in a suitable way in order to go about
>> this patch, but my testing back then was quite elaborate and I still
>> feel pretty confident about it.
>>
>> I totally get your motivation, but I would find it somewhat sad to see
>> the filesystems you mentioned go into staging. However, as I just shown
>> clearly, for the user it may be better, cause there may be unfixed
>> dangerous bugs. FUSE might be an interesting approach, but I bet it will
>> not solve the maintenance issue. If there is no one maintaining it in
>> the kernel, I think its unlikely 

Re: Moving unmaintained filesystems to staging

[Luis R. Rodriguez]

On Wed, Apr 25, 2018 at 11:11 PM, Pavel Machek  wrote:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
>
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
>
> Staging is for ugly code, not for code that needs new maintainter.

Staging is also a hospice for drivers on their way out. Can some of
these be eventually be axed?

  Luis

Re: Moving unmaintained filesystems to staging

[Luis R. Rodriguez]

On Wed, Apr 25, 2018 at 11:11 PM, Pavel Machek  wrote:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
>
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
>
> Staging is for ugly code, not for code that needs new maintainter.

Staging is also a hospice for drivers on their way out. Can some of
these be eventually be axed?

  Luis

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Finn Thain]

On Thu, 26 Apr 2018, Geert Uytterhoeven wrote:

> 
> While non-native Linux filesystem support (e.g. affs/isofs/...) could be 
> handled by FUSE

Moving to FUSE is a great divide-and-conquer strategy for those who just 
want the code to die and don't care about any of the data in that format.

If there is a maintainence burden that can be shared then it should be 
shared -- until it can be established that there is no data of value in 
that format.

> moving RDB partition support to staging is not an option, as it is the 
> only partitioning scheme that Amigas can boot from.
> 

Whether or not the original hardware is in use is mostly irrelevant.

As long as the old format is accessible using current hardware, the data 
in that format remains accessible (to archivists, to curators, to your 
decendents, etc).

> If there are bugs in the RDB parser that people run into, they should be 
> fixed. If there are limitations in the RDB format on large disks, that's 
> still not a reason to move it to staging (hi msdos partitioning!).
> 

-- 

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Finn Thain]

On Thu, 26 Apr 2018, Geert Uytterhoeven wrote:

> 
> While non-native Linux filesystem support (e.g. affs/isofs/...) could be 
> handled by FUSE

Moving to FUSE is a great divide-and-conquer strategy for those who just 
want the code to die and don't care about any of the data in that format.

If there is a maintainence burden that can be shared then it should be 
shared -- until it can be established that there is no data of value in 
that format.

> moving RDB partition support to staging is not an option, as it is the 
> only partitioning scheme that Amigas can boot from.
> 

Whether or not the original hardware is in use is mostly irrelevant.

As long as the old format is accessible using current hardware, the data 
in that format remains accessible (to archivists, to curators, to your 
decendents, etc).

> If there are bugs in the RDB parser that people run into, they should be 
> fixed. If there are limitations in the RDB format on large disks, that's 
> still not a reason to move it to staging (hi msdos partitioning!).
> 

-- 

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Geert Uytterhoeven]

Hi Martin,

CC jdow

On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
 wrote:
> You probably put your stick into a cave with ancient sleeping dragons :)
>
> Added in linux-m68k mailing list, as they likely have an opinion on how
> to treat affs + RDB partition support. Also added in Jens Axboe about
> patching that RDB support broken with 2 TB or larger harddisks issue
> which had been in Linux kernel for 6 years while a patch exists that to
> my testing back then solves the issue.

While non-native Linux filesystem support (e.g. affs/isofs/...) could be
handled by FUSE, moving RDB partition support to staging is not an option,
as it is the only partitioning scheme that Amigas can boot from.

If there are bugs in the RDB parser that people run into, they should
be fixed.
If there are limitations in the RDB format on large disks, that's still not
a reason to move it to staging (hi msdos partitioning!).

> Matthew Wilcox - 26.04.18, 04:57:
>> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
>> > I had similar toughts some time ago while browsing the fs/
>> > directory.
>> > Access to the filesystem images can be reimplemented in FUSE, but
>> > other than that, I don't think the in-kernel code would be missed.
>> >
>> > It's hard to know how many users are there. I was curious eg. about
>> > bfs, befs, coda or feevxfs, looked at the last commits and searched
>> > around web if there are any mentions or user community. But as long
>> > as there's somebody listed in MAINTAINERS, the above are not
>> > candidates for moving to staging or deletion.
>>
>> Yeah, it's pretty sad how few commits some of these filesystems have
>> had in recent years.  One can argue that they're stable and don't need
>> to be fixed because they aren't broken, but I find it hard to believe
>> that any of them were better-implemented than ext2 which still sees
>> regular bugfixes.
>
> Regarding affs there is a severe issue which is not in affs itself but
> in the handling of Rigid Disk Block (RDB) partitions, the Amiga
> partitioning standard, which is far more advanced than MBR: It overruns
> for 2 TB or larger drives and then wraps over to the beginning of the
> drive – I bet you can imagine what happens if you write to an area
> larger than 2 TB. I learned this with an external 2TB RDB partitioned
> harddisk back then, which I used for Sam440ep (a kind of successor for
> old, classic Amiga hardware) backup + some Linux related stuff in
> another partition.
>
> Joanne Dow, a developer who developed hdwrench.library which HDToolBox
> uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then,
> but never officially put it officially through upstreaming as I offered
> to make a good description and upstream it through Jens Axboe.
>
> I may take this as a reason to… actually follow through this time,
> hopefully remembering all the details in order to provide a meaningful
> patch description – but I think mostly I can do just careful copy and
> paste. Even tough I believe Joanne Dow´s fix only fixed my bug report
> 43511, but not 43511 which is more about a safeguarding issue in case of
> future overflows, I still think it would be good to go in in case affs +
> RDB stays in their current places.
>
> However, in case you move affs to staging, I may be less motivated to do
> so, but then I suggest you also move RDB partitioning support to
> staging, cause this is the one that is known to be dangerously badly for
> 2 TB or larger disks. And yeah, I admit I did not follow through with
> having that patch upstreamed. Probably I did not want to be responsible
> in case my description would not have been absolutely accurate or the
> patch breaks something else. I do not have that 2 TB drive anymore and
> don´t feel like setting one up in a suitable way in order to go about
> this patch, but my testing back then was quite elaborate and I still
> feel pretty confident about it.
>
> I totally get your motivation, but I would find it somewhat sad to see
> the filesystems you mentioned go into staging. However, as I just shown
> clearly, for the user it may be better, cause there may be unfixed
> dangerous bugs. FUSE might be an interesting approach, but I bet it will
> not solve the maintenance issue. If there is no one maintaining it in
> the kernel, I think its unlikely to find someone adapting it to be a
> FUSE filesystem and maintaining it. And then I am not aware of FUSE
> based partitioning support. (And I think think ideally we´d had a
> microkernel and run all filesystems in userspace processes with a
> defined set of privileges, but that is simply not Linux as it is.)
>
> Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in
> AmigaOS 4.1
> https://lkml.org/lkml/2012/6/17/6
>
> Bug 43521 - Amiga RDB partitions: truncates miscalculated partition size
> instead of refusing to use it
> https://bugzilla.kernel.org/show_bug.cgi?id=43521
>
> Bug 43511 - Partitions: Amiga RDB 

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Geert Uytterhoeven]

Hi Martin,

CC jdow

On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
 wrote:
> You probably put your stick into a cave with ancient sleeping dragons :)
>
> Added in linux-m68k mailing list, as they likely have an opinion on how
> to treat affs + RDB partition support. Also added in Jens Axboe about
> patching that RDB support broken with 2 TB or larger harddisks issue
> which had been in Linux kernel for 6 years while a patch exists that to
> my testing back then solves the issue.

While non-native Linux filesystem support (e.g. affs/isofs/...) could be
handled by FUSE, moving RDB partition support to staging is not an option,
as it is the only partitioning scheme that Amigas can boot from.

If there are bugs in the RDB parser that people run into, they should
be fixed.
If there are limitations in the RDB format on large disks, that's still not
a reason to move it to staging (hi msdos partitioning!).

> Matthew Wilcox - 26.04.18, 04:57:
>> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
>> > I had similar toughts some time ago while browsing the fs/
>> > directory.
>> > Access to the filesystem images can be reimplemented in FUSE, but
>> > other than that, I don't think the in-kernel code would be missed.
>> >
>> > It's hard to know how many users are there. I was curious eg. about
>> > bfs, befs, coda or feevxfs, looked at the last commits and searched
>> > around web if there are any mentions or user community. But as long
>> > as there's somebody listed in MAINTAINERS, the above are not
>> > candidates for moving to staging or deletion.
>>
>> Yeah, it's pretty sad how few commits some of these filesystems have
>> had in recent years.  One can argue that they're stable and don't need
>> to be fixed because they aren't broken, but I find it hard to believe
>> that any of them were better-implemented than ext2 which still sees
>> regular bugfixes.
>
> Regarding affs there is a severe issue which is not in affs itself but
> in the handling of Rigid Disk Block (RDB) partitions, the Amiga
> partitioning standard, which is far more advanced than MBR: It overruns
> for 2 TB or larger drives and then wraps over to the beginning of the
> drive – I bet you can imagine what happens if you write to an area
> larger than 2 TB. I learned this with an external 2TB RDB partitioned
> harddisk back then, which I used for Sam440ep (a kind of successor for
> old, classic Amiga hardware) backup + some Linux related stuff in
> another partition.
>
> Joanne Dow, a developer who developed hdwrench.library which HDToolBox
> uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then,
> but never officially put it officially through upstreaming as I offered
> to make a good description and upstream it through Jens Axboe.
>
> I may take this as a reason to… actually follow through this time,
> hopefully remembering all the details in order to provide a meaningful
> patch description – but I think mostly I can do just careful copy and
> paste. Even tough I believe Joanne Dow´s fix only fixed my bug report
> 43511, but not 43511 which is more about a safeguarding issue in case of
> future overflows, I still think it would be good to go in in case affs +
> RDB stays in their current places.
>
> However, in case you move affs to staging, I may be less motivated to do
> so, but then I suggest you also move RDB partitioning support to
> staging, cause this is the one that is known to be dangerously badly for
> 2 TB or larger disks. And yeah, I admit I did not follow through with
> having that patch upstreamed. Probably I did not want to be responsible
> in case my description would not have been absolutely accurate or the
> patch breaks something else. I do not have that 2 TB drive anymore and
> don´t feel like setting one up in a suitable way in order to go about
> this patch, but my testing back then was quite elaborate and I still
> feel pretty confident about it.
>
> I totally get your motivation, but I would find it somewhat sad to see
> the filesystems you mentioned go into staging. However, as I just shown
> clearly, for the user it may be better, cause there may be unfixed
> dangerous bugs. FUSE might be an interesting approach, but I bet it will
> not solve the maintenance issue. If there is no one maintaining it in
> the kernel, I think its unlikely to find someone adapting it to be a
> FUSE filesystem and maintaining it. And then I am not aware of FUSE
> based partitioning support. (And I think think ideally we´d had a
> microkernel and run all filesystems in userspace processes with a
> defined set of privileges, but that is simply not Linux as it is.)
>
> Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in
> AmigaOS 4.1
> https://lkml.org/lkml/2012/6/17/6
>
> Bug 43521 - Amiga RDB partitions: truncates miscalculated partition size
> instead of refusing to use it
> https://bugzilla.kernel.org/show_bug.cgi?id=43521
>
> Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way 

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Christoph Hellwig]

On Thu, Apr 26, 2018 at 12:28:40PM +0200, Martin Steigerwald wrote:
> Added in linux-m68k mailing list, as they likely have an opinion on how 
> to treat affs + RDB partition support. Also added in Jens Axboe about 
> patching that RDB support broken with 2 TB or larger harddisks issue 
> which had been in Linux kernel for 6 years while a patch exists that to 
> my testing back then solves the issue.

Jens can't do much unless you actually sent said patch to the
linux-block list.

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Christoph Hellwig]

On Thu, Apr 26, 2018 at 12:28:40PM +0200, Martin Steigerwald wrote:
> Added in linux-m68k mailing list, as they likely have an opinion on how 
> to treat affs + RDB partition support. Also added in Jens Axboe about 
> patching that RDB support broken with 2 TB or larger harddisks issue 
> which had been in Linux kernel for 6 years while a patch exists that to 
> my testing back then solves the issue.

Jens can't do much unless you actually sent said patch to the
linux-block list.

Re: Moving unmaintained filesystems to staging

[Martin Steigerwald]

Pavel Machek - 26.04.18, 08:11:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > Recently ncpfs got moved to staging.  Also recently, we had some
> > fuzzer developers report bugs in hfs, which they deem a security
> > hole because Ubuntu attempts to automount an inserted USB device as
> > hfs.
> 
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
> 
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
> 
> Staging is for ugly code, not for code that needs new maintainter.

Good point.

Moving things in and out to some "unmaintained" directory… I am not sure 
about that either. I tend to think that moving code around does not 
solve the underlying issue.

Which, according to what I got from Matthew, was that distributors 
enable just about every filesystem they can enable which lead to hfs 
being used for automounting an USB stick formatted with it.

In the end what may be beneficial would be hinting distributors and 
people who compile their own kernels at what features are considered 
stable, secure and well tested and what features are not, but how to 
determine that? The hint could be some kernel option flag that would be 
displayed by make *config. But then it probably needs also a 
justification or at least a link to more information.

Actually did ever someone audit the whole kernel source?

Thanks,
-- 
Martin

Re: Moving unmaintained filesystems to staging

[Martin Steigerwald]

Pavel Machek - 26.04.18, 08:11:
> On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> > Recently ncpfs got moved to staging.  Also recently, we had some
> > fuzzer developers report bugs in hfs, which they deem a security
> > hole because Ubuntu attempts to automount an inserted USB device as
> > hfs.
> 
> We promise "no-regressions" for code in main repository, no such
> promise for staging. We have quite a lot of code without maintainer.
> 
> Moving code to staging means it will get broken -- staging was not
> designed for this. I believe moving anything there is bad idea.
> 
> Staging is for ugly code, not for code that needs new maintainter.

Good point.

Moving things in and out to some "unmaintained" directory… I am not sure 
about that either. I tend to think that moving code around does not 
solve the underlying issue.

Which, according to what I got from Matthew, was that distributors 
enable just about every filesystem they can enable which lead to hfs 
being used for automounting an USB stick formatted with it.

In the end what may be beneficial would be hinting distributors and 
people who compile their own kernels at what features are considered 
stable, secure and well tested and what features are not, but how to 
determine that? The hint could be some kernel option flag that would be 
displayed by make *config. But then it probably needs also a 
justification or at least a link to more information.

Actually did ever someone audit the whole kernel source?

Thanks,
-- 
Martin

moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi Matthew.

You probably put your stick into a cave with ancient sleeping dragons :)

Added in linux-m68k mailing list, as they likely have an opinion on how 
to treat affs + RDB partition support. Also added in Jens Axboe about 
patching that RDB support broken with 2 TB or larger harddisks issue 
which had been in Linux kernel for 6 years while a patch exists that to 
my testing back then solves the issue.

Matthew Wilcox - 26.04.18, 04:57:
> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
> > I had similar toughts some time ago while browsing the fs/
> > directory.
> > Access to the filesystem images can be reimplemented in FUSE, but
> > other than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about
> > bfs, befs, coda or feevxfs, looked at the last commits and searched
> > around web if there are any mentions or user community. But as long
> > as there's somebody listed in MAINTAINERS, the above are not
> > candidates for moving to staging or deletion.
> 
> Yeah, it's pretty sad how few commits some of these filesystems have
> had in recent years.  One can argue that they're stable and don't need
> to be fixed because they aren't broken, but I find it hard to believe
> that any of them were better-implemented than ext2 which still sees
> regular bugfixes.

Regarding affs there is a severe issue which is not in affs itself but 
in the handling of Rigid Disk Block (RDB) partitions, the Amiga 
partitioning standard, which is far more advanced than MBR: It overruns 
for 2 TB or larger drives and then wraps over to the beginning of the 
drive – I bet you can imagine what happens if you write to an area 
larger than 2 TB. I learned this with an external 2TB RDB partitioned 
harddisk back then, which I used for Sam440ep (a kind of successor for 
old, classic Amiga hardware) backup + some Linux related stuff in 
another partition.

Joanne Dow, a developer who developed hdwrench.library which HDToolBox 
uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then, 
but never officially put it officially through upstreaming as I offered 
to make a good description and upstream it through Jens Axboe.

I may take this as a reason to… actually follow through this time, 
hopefully remembering all the details in order to provide a meaningful 
patch description – but I think mostly I can do just careful copy and 
paste. Even tough I believe Joanne Dow´s fix only fixed my bug report 
43511, but not 43511 which is more about a safeguarding issue in case of 
future overflows, I still think it would be good to go in in case affs + 
RDB stays in their current places.

However, in case you move affs to staging, I may be less motivated to do 
so, but then I suggest you also move RDB partitioning support to 
staging, cause this is the one that is known to be dangerously badly for 
2 TB or larger disks. And yeah, I admit I did not follow through with 
having that patch upstreamed. Probably I did not want to be responsible 
in case my description would not have been absolutely accurate or the 
patch breaks something else. I do not have that 2 TB drive anymore and 
don´t feel like setting one up in a suitable way in order to go about 
this patch, but my testing back then was quite elaborate and I still 
feel pretty confident about it.

I totally get your motivation, but I would find it somewhat sad to see 
the filesystems you mentioned go into staging. However, as I just shown 
clearly, for the user it may be better, cause there may be unfixed 
dangerous bugs. FUSE might be an interesting approach, but I bet it will 
not solve the maintenance issue. If there is no one maintaining it in 
the kernel, I think its unlikely to find someone adapting it to be a 
FUSE filesystem and maintaining it. And then I am not aware of FUSE 
based partitioning support. (And I think think ideally we´d had a 
microkernel and run all filesystems in userspace processes with a 
defined set of privileges, but that is simply not Linux as it is.)

Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in 
AmigaOS 4.1
https://lkml.org/lkml/2012/6/17/6

Bug 43521 - Amiga RDB partitions: truncates miscalculated partition size 
instead of refusing to use it
https://bugzilla.kernel.org/show_bug.cgi?id=43521

Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way too big, 
while OK in AmigaOS 4.1
https://bugzilla.kernel.org/show_bug.cgi?id=43511

I forward the relevant mail of Joanne, in

https://bugzilla.kernel.org/show_bug.cgi?id=43511#c7

I even have the patch in diff format. And I just checked, the issue is 
still unpatched as of 4.16.3.

--  Weitergeleitete Nachricht  --

Betreff: Re: Partitions: Amiga RDB partition on 2 TB disk way too big, 
while OK in AmigaOS 4.1
Datum: Montag, 18. Juni 2012, 03:28:48 CEST
Von: jdow 
An: Martin Steigerwald 
Kopie: Geert Uytterhoeven 

moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Hi Matthew.

You probably put your stick into a cave with ancient sleeping dragons :)

Added in linux-m68k mailing list, as they likely have an opinion on how 
to treat affs + RDB partition support. Also added in Jens Axboe about 
patching that RDB support broken with 2 TB or larger harddisks issue 
which had been in Linux kernel for 6 years while a patch exists that to 
my testing back then solves the issue.

Matthew Wilcox - 26.04.18, 04:57:
> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
> > I had similar toughts some time ago while browsing the fs/
> > directory.
> > Access to the filesystem images can be reimplemented in FUSE, but
> > other than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about
> > bfs, befs, coda or feevxfs, looked at the last commits and searched
> > around web if there are any mentions or user community. But as long
> > as there's somebody listed in MAINTAINERS, the above are not
> > candidates for moving to staging or deletion.
> 
> Yeah, it's pretty sad how few commits some of these filesystems have
> had in recent years.  One can argue that they're stable and don't need
> to be fixed because they aren't broken, but I find it hard to believe
> that any of them were better-implemented than ext2 which still sees
> regular bugfixes.

Regarding affs there is a severe issue which is not in affs itself but 
in the handling of Rigid Disk Block (RDB) partitions, the Amiga 
partitioning standard, which is far more advanced than MBR: It overruns 
for 2 TB or larger drives and then wraps over to the beginning of the 
drive – I bet you can imagine what happens if you write to an area 
larger than 2 TB. I learned this with an external 2TB RDB partitioned 
harddisk back then, which I used for Sam440ep (a kind of successor for 
old, classic Amiga hardware) backup + some Linux related stuff in 
another partition.

Joanne Dow, a developer who developed hdwrench.library which HDToolBox 
uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then, 
but never officially put it officially through upstreaming as I offered 
to make a good description and upstream it through Jens Axboe.

I may take this as a reason to… actually follow through this time, 
hopefully remembering all the details in order to provide a meaningful 
patch description – but I think mostly I can do just careful copy and 
paste. Even tough I believe Joanne Dow´s fix only fixed my bug report 
43511, but not 43511 which is more about a safeguarding issue in case of 
future overflows, I still think it would be good to go in in case affs + 
RDB stays in their current places.

However, in case you move affs to staging, I may be less motivated to do 
so, but then I suggest you also move RDB partitioning support to 
staging, cause this is the one that is known to be dangerously badly for 
2 TB or larger disks. And yeah, I admit I did not follow through with 
having that patch upstreamed. Probably I did not want to be responsible 
in case my description would not have been absolutely accurate or the 
patch breaks something else. I do not have that 2 TB drive anymore and 
don´t feel like setting one up in a suitable way in order to go about 
this patch, but my testing back then was quite elaborate and I still 
feel pretty confident about it.

I totally get your motivation, but I would find it somewhat sad to see 
the filesystems you mentioned go into staging. However, as I just shown 
clearly, for the user it may be better, cause there may be unfixed 
dangerous bugs. FUSE might be an interesting approach, but I bet it will 
not solve the maintenance issue. If there is no one maintaining it in 
the kernel, I think its unlikely to find someone adapting it to be a 
FUSE filesystem and maintaining it. And then I am not aware of FUSE 
based partitioning support. (And I think think ideally we´d had a 
microkernel and run all filesystems in userspace processes with a 
defined set of privileges, but that is simply not Linux as it is.)

Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in 
AmigaOS 4.1
https://lkml.org/lkml/2012/6/17/6

Bug 43521 - Amiga RDB partitions: truncates miscalculated partition size 
instead of refusing to use it
https://bugzilla.kernel.org/show_bug.cgi?id=43521

Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way too big, 
while OK in AmigaOS 4.1
https://bugzilla.kernel.org/show_bug.cgi?id=43511

I forward the relevant mail of Joanne, in

https://bugzilla.kernel.org/show_bug.cgi?id=43511#c7

I even have the patch in diff format. And I just checked, the issue is 
still unpatched as of 4.16.3.

--  Weitergeleitete Nachricht  --

Betreff: Re: Partitions: Amiga RDB partition on 2 TB disk way too big, 
while OK in AmigaOS 4.1
Datum: Montag, 18. Juni 2012, 03:28:48 CEST
Von: jdow 
An: Martin Steigerwald 
Kopie: Geert Uytterhoeven , linux-
ker...@vger.kernel.org, Jens Axboe , 

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> developers report bugs in hfs, which they deem a security hole because
> Ubuntu attempts to automount an inserted USB device as hfs.

We promise "no-regressions" for code in main repository, no such
promise for staging. We have quite a lot of code without maintainer.

Moving code to staging means it will get broken -- staging was not
designed for this. I believe moving anything there is bad idea.

Staging is for ugly code, not for code that needs new maintainter.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Pavel Machek]

On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote:
> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> developers report bugs in hfs, which they deem a security hole because
> Ubuntu attempts to automount an inserted USB device as hfs.

We promise "no-regressions" for code in main repository, no such
promise for staging. We have quite a lot of code without maintainer.

Moving code to staging means it will get broken -- staging was not
designed for this. I believe moving anything there is bad idea.

Staging is for ugly code, not for code that needs new maintainter.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Moving unmaintained filesystems to staging

[Willy Tarreau]

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.04.2018 23:30, David Sterba wrote:
> > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> >> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> >> developers report bugs in hfs, which they deem a security hole because
> >> Ubuntu attempts to automount an inserted USB device as hfs.
> >>
> >> We have no maintainer for hfs, and no likely prospect of anyone stepping
> >> up soon to become hfs maintainer.  I think it's irresponsible of us
> >> to present unmaintained code on an equal basis with filesystems under
> >> active maintenance like ext2.
> >>
> >> I therefore propose we move the following filesystems which are explicitly
> >> listed as Orphaned to staging:
> >>
> >> affs - Amiga filesystem.
> >> efs - old SGI filesystem predating XFS, used on CDs for a while.
> >> hfs - Mac filesystem.
> >> hfsplus - Mac filesystem.
> >>
> >> I further propose we move the following filesystems which have no entry
> >> in MAINTAINERS to staging:
> >>
> >> adfs - Acorn filesystem from the 1990s.
> >> minix
> >> qnx6
> > 
> > I had similar toughts some time ago while browsing the fs/ directory.
> > Access to the filesystem images can be reimplemented in FUSE, but other
> > than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about bfs,
> > befs, coda or feevxfs, looked at the last commits and searched around
> > web if there are any mentions or user community. But as long as there's
> > somebody listed in MAINTAINERS, the above are not candidates for moving
> > to staging or deletion.
> > 
> 
> I think the presence of maintainers entry is necessary but insufficient.
> What if the maintainer has long lost interest but just didn't bother
> updating the file. In the very least maintainers should be pinged and
> asked if they are still maintaining the respective piece of code.

That's a good point. However the age of the last commit must not be used
as an excuse for moving them, because if the few users are very happy with
the code, never meet corner cases and never have to report bugs, neither
them nor the maintainers should be punished. In my opinion the only two
reasons for deprecating or removing code are that it's not maintained
anymore or that it's using ancient infrastructure that needs to be
changed and there's no way to adapt the old code to the new one.

In fact I think that the problem with very silent maintainers goes way
beyond FS. Everyone in MAINTAINERS who didn't send a commit in one year
should probably be asked if they're still doing the work, if they'd be
interested in someone else taking over, or if they think the whole code
has no reason to continue to exist.

Willy

Re: Moving unmaintained filesystems to staging

[Willy Tarreau]

On Thu, Apr 26, 2018 at 07:58:52AM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.04.2018 23:30, David Sterba wrote:
> > On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> >> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> >> developers report bugs in hfs, which they deem a security hole because
> >> Ubuntu attempts to automount an inserted USB device as hfs.
> >>
> >> We have no maintainer for hfs, and no likely prospect of anyone stepping
> >> up soon to become hfs maintainer.  I think it's irresponsible of us
> >> to present unmaintained code on an equal basis with filesystems under
> >> active maintenance like ext2.
> >>
> >> I therefore propose we move the following filesystems which are explicitly
> >> listed as Orphaned to staging:
> >>
> >> affs - Amiga filesystem.
> >> efs - old SGI filesystem predating XFS, used on CDs for a while.
> >> hfs - Mac filesystem.
> >> hfsplus - Mac filesystem.
> >>
> >> I further propose we move the following filesystems which have no entry
> >> in MAINTAINERS to staging:
> >>
> >> adfs - Acorn filesystem from the 1990s.
> >> minix
> >> qnx6
> > 
> > I had similar toughts some time ago while browsing the fs/ directory.
> > Access to the filesystem images can be reimplemented in FUSE, but other
> > than that, I don't think the in-kernel code would be missed.
> > 
> > It's hard to know how many users are there. I was curious eg. about bfs,
> > befs, coda or feevxfs, looked at the last commits and searched around
> > web if there are any mentions or user community. But as long as there's
> > somebody listed in MAINTAINERS, the above are not candidates for moving
> > to staging or deletion.
> > 
> 
> I think the presence of maintainers entry is necessary but insufficient.
> What if the maintainer has long lost interest but just didn't bother
> updating the file. In the very least maintainers should be pinged and
> asked if they are still maintaining the respective piece of code.

That's a good point. However the age of the last commit must not be used
as an excuse for moving them, because if the few users are very happy with
the code, never meet corner cases and never have to report bugs, neither
them nor the maintainers should be punished. In my opinion the only two
reasons for deprecating or removing code are that it's not maintained
anymore or that it's using ancient infrastructure that needs to be
changed and there's no way to adapt the old code to the new one.

In fact I think that the problem with very silent maintainers goes way
beyond FS. Everyone in MAINTAINERS who didn't send a commit in one year
should probably be asked if they're still doing the work, if they'd be
interested in someone else taking over, or if they think the whole code
has no reason to continue to exist.

Willy

Re: Moving unmaintained filesystems to staging

[Nikolay Borisov]

On 25.04.2018 23:30, David Sterba wrote:
> On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>>
>> We have no maintainer for hfs, and no likely prospect of anyone stepping
>> up soon to become hfs maintainer.  I think it's irresponsible of us
>> to present unmaintained code on an equal basis with filesystems under
>> active maintenance like ext2.
>>
>> I therefore propose we move the following filesystems which are explicitly
>> listed as Orphaned to staging:
>>
>> affs - Amiga filesystem.
>> efs - old SGI filesystem predating XFS, used on CDs for a while.
>> hfs - Mac filesystem.
>> hfsplus - Mac filesystem.
>>
>> I further propose we move the following filesystems which have no entry
>> in MAINTAINERS to staging:
>>
>> adfs - Acorn filesystem from the 1990s.
>> minix
>> qnx6
> 
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.
> 

I think the presence of maintainers entry is necessary but insufficient.
What if the maintainer has long lost interest but just didn't bother
updating the file. In the very least maintainers should be pinged and
asked if they are still maintaining the respective piece of code.

Re: Moving unmaintained filesystems to staging

[Nikolay Borisov]

On 25.04.2018 23:30, David Sterba wrote:
> On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
>> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
>> developers report bugs in hfs, which they deem a security hole because
>> Ubuntu attempts to automount an inserted USB device as hfs.
>>
>> We have no maintainer for hfs, and no likely prospect of anyone stepping
>> up soon to become hfs maintainer.  I think it's irresponsible of us
>> to present unmaintained code on an equal basis with filesystems under
>> active maintenance like ext2.
>>
>> I therefore propose we move the following filesystems which are explicitly
>> listed as Orphaned to staging:
>>
>> affs - Amiga filesystem.
>> efs - old SGI filesystem predating XFS, used on CDs for a while.
>> hfs - Mac filesystem.
>> hfsplus - Mac filesystem.
>>
>> I further propose we move the following filesystems which have no entry
>> in MAINTAINERS to staging:
>>
>> adfs - Acorn filesystem from the 1990s.
>> minix
>> qnx6
> 
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.
> 

I think the presence of maintainers entry is necessary but insufficient.
What if the maintainer has long lost interest but just didn't bother
updating the file. In the very least maintainers should be pinged and
asked if they are still maintaining the respective piece of code.

Re: Moving unmaintained filesystems to staging

[Matthew Wilcox]

On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.

Yeah, it's pretty sad how few commits some of these filesystems have
had in recent years.  One can argue that they're stable and don't need
to be fixed because they aren't broken, but I find it hard to believe
that any of them were better-implemented than ext2 which still sees
regular bugfixes.

As long as there's someone who can be pestered with bugs, I don't see
the need to push their baby out of the tree.  I'm a bit more nervous
about hfsplus; if it has users and no maintainer, those users are at risk.

Perhaps we could advertise on Craigslist or something ... maintainer
wanted for LTR.

Re: Moving unmaintained filesystems to staging

[Matthew Wilcox]

On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
> I had similar toughts some time ago while browsing the fs/ directory.
> Access to the filesystem images can be reimplemented in FUSE, but other
> than that, I don't think the in-kernel code would be missed.
> 
> It's hard to know how many users are there. I was curious eg. about bfs,
> befs, coda or feevxfs, looked at the last commits and searched around
> web if there are any mentions or user community. But as long as there's
> somebody listed in MAINTAINERS, the above are not candidates for moving
> to staging or deletion.

Yeah, it's pretty sad how few commits some of these filesystems have
had in recent years.  One can argue that they're stable and don't need
to be fixed because they aren't broken, but I find it hard to believe
that any of them were better-implemented than ext2 which still sees
regular bugfixes.

As long as there's someone who can be pestered with bugs, I don't see
the need to push their baby out of the tree.  I'm a bit more nervous
about hfsplus; if it has users and no maintainer, those users are at risk.

Perhaps we could advertise on Craigslist or something ... maintainer
wanted for LTR.

Re: Moving unmaintained filesystems to staging

[David Sterba]

On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> developers report bugs in hfs, which they deem a security hole because
> Ubuntu attempts to automount an inserted USB device as hfs.
> 
> We have no maintainer for hfs, and no likely prospect of anyone stepping
> up soon to become hfs maintainer.  I think it's irresponsible of us
> to present unmaintained code on an equal basis with filesystems under
> active maintenance like ext2.
> 
> I therefore propose we move the following filesystems which are explicitly
> listed as Orphaned to staging:
> 
> affs - Amiga filesystem.
> efs - old SGI filesystem predating XFS, used on CDs for a while.
> hfs - Mac filesystem.
> hfsplus - Mac filesystem.
> 
> I further propose we move the following filesystems which have no entry
> in MAINTAINERS to staging:
> 
> adfs - Acorn filesystem from the 1990s.
> minix
> qnx6

I had similar toughts some time ago while browsing the fs/ directory.
Access to the filesystem images can be reimplemented in FUSE, but other
than that, I don't think the in-kernel code would be missed.

It's hard to know how many users are there. I was curious eg. about bfs,
befs, coda or feevxfs, looked at the last commits and searched around
web if there are any mentions or user community. But as long as there's
somebody listed in MAINTAINERS, the above are not candidates for moving
to staging or deletion.

Re: Moving unmaintained filesystems to staging

[David Sterba]

On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
> developers report bugs in hfs, which they deem a security hole because
> Ubuntu attempts to automount an inserted USB device as hfs.
> 
> We have no maintainer for hfs, and no likely prospect of anyone stepping
> up soon to become hfs maintainer.  I think it's irresponsible of us
> to present unmaintained code on an equal basis with filesystems under
> active maintenance like ext2.
> 
> I therefore propose we move the following filesystems which are explicitly
> listed as Orphaned to staging:
> 
> affs - Amiga filesystem.
> efs - old SGI filesystem predating XFS, used on CDs for a while.
> hfs - Mac filesystem.
> hfsplus - Mac filesystem.
> 
> I further propose we move the following filesystems which have no entry
> in MAINTAINERS to staging:
> 
> adfs - Acorn filesystem from the 1990s.
> minix
> qnx6

I had similar toughts some time ago while browsing the fs/ directory.
Access to the filesystem images can be reimplemented in FUSE, but other
than that, I don't think the in-kernel code would be missed.

It's hard to know how many users are there. I was curious eg. about bfs,
befs, coda or feevxfs, looked at the last commits and searched around
web if there are any mentions or user community. But as long as there's
somebody listed in MAINTAINERS, the above are not candidates for moving
to staging or deletion.

Re: Moving unmaintained filesystems to staging

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> hfsplus - Mac filesystem.

I don't think this is unmaintained, and it is pretty heavily used.

> minix

Still plenty of use.

Re: Moving unmaintained filesystems to staging

[Christoph Hellwig]

On Wed, Apr 25, 2018 at 08:46:02AM -0700, Matthew Wilcox wrote:
> hfsplus - Mac filesystem.

I don't think this is unmaintained, and it is pretty heavily used.

> minix

Still plenty of use.

Moving unmaintained filesystems to staging

[Matthew Wilcox]

Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
developers report bugs in hfs, which they deem a security hole because
Ubuntu attempts to automount an inserted USB device as hfs.

We have no maintainer for hfs, and no likely prospect of anyone stepping
up soon to become hfs maintainer.  I think it's irresponsible of us
to present unmaintained code on an equal basis with filesystems under
active maintenance like ext2.

I therefore propose we move the following filesystems which are explicitly
listed as Orphaned to staging:

affs - Amiga filesystem.
efs - old SGI filesystem predating XFS, used on CDs for a while.
hfs - Mac filesystem.
hfsplus - Mac filesystem.

I further propose we move the following filesystems which have no entry
in MAINTAINERS to staging:

adfs - Acorn filesystem from the 1990s.
minix
qnx6

We have no listed maintainer for isofs.  This is clearly not a candidate
for staging.  Jan Kara appears to be acting as default maintainer,
so I'd like to propose he gets the appropriate credit with an entry
in MAINTAINERS.

romfs also has no listed maintainer.  I'm not sure who to suggest,
but it seems to have users.

tracefs isn't listed, and probably needs to become part of the
TRACING entry.

Moving unmaintained filesystems to staging

[Matthew Wilcox]

Recently ncpfs got moved to staging.  Also recently, we had some fuzzer
developers report bugs in hfs, which they deem a security hole because
Ubuntu attempts to automount an inserted USB device as hfs.

We have no maintainer for hfs, and no likely prospect of anyone stepping
up soon to become hfs maintainer.  I think it's irresponsible of us
to present unmaintained code on an equal basis with filesystems under
active maintenance like ext2.

I therefore propose we move the following filesystems which are explicitly
listed as Orphaned to staging:

affs - Amiga filesystem.
efs - old SGI filesystem predating XFS, used on CDs for a while.
hfs - Mac filesystem.
hfsplus - Mac filesystem.

I further propose we move the following filesystems which have no entry
in MAINTAINERS to staging:

adfs - Acorn filesystem from the 1990s.
minix
qnx6

We have no listed maintainer for isofs.  This is clearly not a candidate
for staging.  Jan Kara appears to be acting as default maintainer,
so I'd like to propose he gets the appropriate credit with an entry
in MAINTAINERS.

romfs also has no listed maintainer.  I'm not sure who to suggest,
but it seems to have users.

tracefs isn't listed, and probably needs to become part of the
TRACING entry.