linux-kernel - Re: [PATCH] fs/eventpoll: error handling micro-cleanup

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 1 Oct 2006 11:58:06 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fs/eventpoll: error handling micro-cleanup

On Sun, 1 Oct 2006, Jeff Garzik wrote:

> > So? Is PTR_ERR() defined and documented in a way that, if called with a
> > valid pointer, has an unexpected/faulty behaviour?
> 
> When called with a valid pointer, the value assigned to the return-code
> integer is essentially a random number.

That will never be used ...



> > Again, I don't care either ways, but don't tell me you're not sure about the
> > countless occurrences. Take a look at:
> > 
> > `find $LINUXSRC -type f -exec grep -H -C 2 PTR_ERR {} \;`
> 
> Perhaps 1 out of every 100 or so hits from this find(1) is unprotected by
> IS_ERR().  IOW, what I've been describing here is quite rare.

Made a stupid script that try to find such code pattern. Found 193 
instances all around the code. Report and script included for you view 
(I verified about 10 or so of those, and they look correctly captured by 
the script).



- Davide


View attachment "ptrerr-find.pl" of type "TEXT/x-perl" (442 bytes)

View attachment "ptrerr-find.report" of type "TEXT/PLAIN" (6459 bytes)