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, 6 Oct 2011 16:01:44 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Thomas Meyer <thomas@...3r.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sys_poll(): fix function definition/negative timeout
 values

On Thu, 15 Sep 2011 20:21:02 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le jeudi 15 septembre 2011 __ 20:12 +0200, Andi Kleen a __crit :
> > On Thu, Sep 15, 2011 at 08:05:17PM +0200, Eric Dumazet wrote:
> > > Le jeudi 15 septembre 2011 __ 10:47 -0700, Andi Kleen a __crit :
> > > > Thomas Meyer <thomas@...3r.de> writes:
> > > > 
> > > > > Fix negative timeout values for x86 userland on x86_64 kernels.
> > > > > Align sys_poll() definition to glibc's definition.
> > > > 
> > > > Nack. Please write a compat wrapper that sign extends.
> > > > 
> > > 
> > > Why ?
> > 
> > Because we shouldn't change existing interfaces and there could
> > be valid reasons on 64bit for really long delays.
> 
> I disagree.
> 
> Existing interface and POSIX mandates "int delay"
> 
> The kernel part of the contract was fine when we supported 32bit only
> machines, by chance, because sizeof(int) == sizeof(long).
> 
> If you want more than 31 bits delay, then we need a new interface, and
> this new interface must also work on 32bit arches (sort of poll64())

So what's happening here?

If the change will break (or alter) existing code which does

	poll(..., something_greater_than_2g)

then I don't think we can apply the patch.  There may be code out there
which breaks, there may not be.  We don't know.  We screwed up, we get
to wear the cost of having done so.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ