Date: Sat, 11 Aug 2012 20:39:43 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: svn commit: r239187 - head/sys/kern Message-ID: <20120811203656.K1239@besplex.bde.org> In-Reply-To: <20120811181037.A853@besplex.bde.org> References: <201208110006.q7B06uPR092724@svn.freebsd.org> <20120811181037.A853@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Aug 2012, Bruce Evans wrote:
> On Sat, 11 Aug 2012, David Xu wrote:
>> ...
>> for (;;) {
>> if (!(uq->uq_flags & UQF_UMTXQ))
>> return (0);
>> - error = msleep(uq, &uc->uc_lock, PCATCH, wmesg,
>> - timo == NULL ? 0 : abs_timeout_gethz(timo));
>> - if (error != EWOULDBLOCK)
>> - break;
>> - umtxq_unlock(&uq->uq_key);
>> - if (abs_timeout_update(timo)) {
>> - error = ETIMEDOUT;
> ...
> This follows the null pointer in abs_timeout_update() if timo == NULL.
> timo == NULL has caused msleep to be called with a timeout of 0 ticks
> (infinity), so EWOULDBLOCK should not normally be returned in this
> case. However, I think it is always returned after the INT_MAX ticks
> since a timeout of infinity is not really infinite, but just INT_MAX,
> and there is no further magic for this value, so EWOULDBLOCK is
> returned as usual if the timeout expires.
Oops, 0 really does mean infinity for msleep(), so there is no problem
unless it somehow returns EWOULDBLOCK.
> ...
>> + abs_timeout_update(timo);
>
> This still follows the null pointer, as above.
Still no problem.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120811203656.K1239>