linux-kernel - Re: [GIT PULL] kbuild updates for v4.7-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]

Message-ID: <20160527215210.GU14480@ZenIV.linux.org.uk>
Date:	Fri, 27 May 2016 22:52:10 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arnd Bergmann <arnd@...db.de>, Michal Marek <mmarek@...e.com>,
	Макс Жуков 
	<mussitantesmortem@...il.com>, nicolas.ferre@...el.com,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	robert.jarzmik@...e.fr, yamada.masahiro@...ionext.com,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bob Peterson <rpeterso@...hat.com>
Subject: Re: [GIT PULL] kbuild updates for v4.7-rc1

On Fri, May 27, 2016 at 01:20:29PM -0700, Linus Torvalds wrote:

> I didn't look at the details of your patch, but I did look at several
> IS_ERR_VALUE() uses in the standard kernel, and they were basically
> all wrong. Even the ones that used it for the rigth reason (vm_brk()
> that returns a pointer or an error in an "unsigned long") had actively
> screwed up and truncated that (correct) unsigned long value to "int"
> before doing the IS_ERR_VALUE(), which made it all wrong again.
> 
> And the other users just looked entirely bogus, and were all just
> "zero or negative error code" that has nothing to do with
> IS_ERR_VALUE(). The code should just check against zero, not use that
> macro that was designed for something different.

Both gfs2 ones and the one in fs/romfs are crap.  AFS one is simply ridiculous -
        result = generic_file_write_iter(iocb, from);
        if (IS_ERR_VALUE(result)) {
                _leave(" = %zd", result);
                return result;
        }

        _leave(" = %zd", result);
        return result;
In binfmt*.c some callers are valid (vm_mmap and vm_brk values; BTW, the
code in binfmt_flat.c checks for vm_mmap returning 0, which should never
happen, AFAICS).  Most of binfmt_flat.c ones are pure cargo-culting.

net/9p/client.c ones are results of serious mistake in design of 9P.L
extensions to 9P - they assume that numeric values of E... are
architecture-independent and send them over the wire.  The uses of
IS_ERR_VALUE there are papering over that.  Badly.

A couple of sound/* ones should be simply "is negative".

netfilter ones are caused by bad calling conventions of
xt_percpu_counter_alloc().

I hadn't looked through drivers/* users, but judging by fs/, net/ and sound/,
I would expect them to be pointless garbage in the best case and red flags
for broken code in the worst.

IMO IS_ERR_VALUE() should be renamed to something less generic and be used
a lot less than it is right now.