linux-ext4 - Re: [GIT PULL] dtype handling cleanup for v4.21-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 17 Jan 2019 13:17:08 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Phillip Potter <phil@...lpotter.co.uk>
Cc:     Jan Kara <jack@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "cc: Matthew Wilcox" <willy@...radead.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Ext4 <linux-ext4@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] dtype handling cleanup for v4.21-rc1

On Thu, Jan 17, 2019 at 11:35 AM Jan Kara <jack@...e.cz> wrote:
>
> On Wed 16-01-19 18:56:17, Amir Goldstein wrote:
> > On Wed, Jan 16, 2019 at 6:51 PM Jan Kara <jack@...e.cz> wrote:
> > >
> > > On Wed 16-01-19 16:34:36, Phillip Potter wrote:
> > > > Dear Jan,
> > > >
> > > > I am happy to rework the patches, all fair comment. Slight problem
> > > > being my computer is in a box right now as I've just moved house. I
> > > > will get this done in the next few days if that's ok?
> > >
> > > Sure, no problem. Patches won't make it in this release cycle so we have
> > > like three weeks to get them ready for the next merge window.
> > >
> >
> > Also, and Jan will correct me if I am wrong.
> > I think that reworking only the common and ext2 patches would
> > be sufficient for this cycle.
>
> Yes, that's also true.
>
> > You can prepare the rest of the patches for next cycle after
> > the common patch has landed.
>
> Correct, since the plan is for these to land through other maintainers'
> trees. But still it would be nice if we had them earlier just to see of
> other maintainers don't seriously oppose the idea. To that end it is
> probably good to reference the discussion with Linus in the cover letter
> and the email with common infrastructure, explaining why converting to
> common defines instead of keeping filesystem specific ones was done.
>

Phillip,

While I see no problem with Linus' proposal to get rid of EXT2_FT_*
completely. That may be practical for EXOFS_FT_*, F2FS_FT_*, ...
But some fs maintainers may prefer to define (not re-define) the
fs specific constants, e.g.:

#define EXT4_FT_DIR FT_DIR

If for no other reason, it will result in slightly less code churn.

However, note that you may NOT get rid of defines in uapi headers:
BTRFS_FT_*, NILFS_FT_*
and defining them to the common constant will require exporting
common constants to uapi headers.
That is one mess you do not want to get yourself into.

So I'm afraid for btrfs/nilfs, the "disgusting" BUILD_BUG_ON()
statements in the only practical outlet if they want to use the common
conversions code.

If you prepare the patch series with several options as described
above (choose one option per fs), then later maintainers can use
either option when applying the individual patches.

Thanks,
Amir.