Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 May 2014 00:39:24 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH v2] Support for no-legacy-syscalls archs

* Rich Felker <dalias@...c.org> [2014-05-26 17:54:12 -0400]:
> On Mon, May 26, 2014 at 11:13:49PM +0200, Szabolcs Nagy wrote:
> > > +	if (tv) {
> > > +		ts.tv_sec = tv->tv_sec;
> > > +		ts.tv_nsec = tv->tv_usec > 999999 ?
> > > +			999999999 : tv->tv_usec * 1000;
> > > +	}
> > > +	return syscall_cp(SYS_pselect6, n, rfds, wfds, efds, tv ? &ts : 0, data);
> > > +#endif
> > 
> > tv_usec may be negative
> 
> Then the kernel should generate the EINVAL for us.
> 

but the multiplication may overflow

> > isnt it better to adjust tv_sec if usec is large?
> > or fail with EINVAL like in futimensat:
> 
> POSIX allows implementation-defined limits on the duration, but now
> that you say it, what I wrote above is not not a correct
> implementation of such a limit. I'm not clear on whether we should
> renormalize into timespec or just reject out-of-range usec values;
> unlike in some other places where timespec is used, POSIX is missing
> text on select and pselect regarding how out-of-range timespec and
> timeval structs should be handled...
> 

fwiw the kernel fixes large tv_usec in select:

...
  tv.tv_sec + (tv.tv_usec / USEC_PER_SEC),
  (tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC))

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.