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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyMvt2Nc6s99BbzTSpFBJt6ekdfsi4Le2sCU0LGb-6RLg@mail.gmail.com>
Date:   Wed, 5 Jul 2017 14:51:43 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@....de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs.git part 3

On Wed, Jul 5, 2017 at 12:14 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Christoph's fs/read_write.c series - consolidation and cleanups.

Side note - when looking through this, it struck me how confusing that
"int flags" argument was.

We have a ton of "flags" in the filesystem layer, and how all the
read/write helpers take them too, and it's really hard to see what
kind of flags they are.

Could we perhaps make those RWF_xyz flags have a nice bitwise type,
and use that type in the argument list, so that not only could there
be some sparse typechecking, but the functions that pass flags on to
each other would automatically have a certain amount of actual
self-documenting prototypes?

So when you look at one of those vfs_iter_write() or whatever
functions, you just see *what* flags the flags argument is.

Because "int flags" really is the worst. It's the wrong type anyway
(at least make it unsigned if it's a collection of bits), but it's
also very ambiguous indeed when there are so many other flags that are
often used/tested in the same functions (there's the "iter" flagsm,
there's file->f_mode, there's just a lot of different flags going on,
and the "int flags" is the least well documented of them all,
particularly since 99.9% of all users just pass in zero).

Hmm?

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ