sys_util: fix issue in ppoll on 32-bit architectures

I ran into an issue on ARM where ppoll() was returning EINVAL and it
was becuase our timespec value sent to ppoll contained a negative
value for tv_sec.  We need to use the correct type when determining
the max value.

BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline

Change-Id: I7f8818e5f93e0327fd9facefb5032f7c5fb00ea0
Reviewed-on: https://chromium-review.googlesource.com/945111
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>

1 files changed, 1 insertions, 3 deletions

diff --git a/sys_util/src/poll.rs b/sys_util/src/poll.rs
index d6c3d4a..b6f3a1b 100644
--- a/sys_util/src/poll.rs
+++ b/sys_util/src/poll.rs
@@ -2,7 +2,6 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-use std::i64;
 use std::time::Duration;
 use std::ptr::null;
 use std::os::unix::io::{AsRawFd, RawFd};
@@ -82,7 +81,7 @@ impl Poller {
     /// This is guaranteed to not allocate if `pollables.len()` is less than the `capacity` given in
     /// `Poller::new`.
     pub fn poll(&mut self, pollables: &[(u32, &Pollable)]) -> Result<&[u32]> {
-        self.poll_timeout(pollables, &mut Duration::new(i64::MAX as u64, 0))
+        self.poll_timeout(pollables, &mut Duration::new(time_t::max_value() as u64, 0))
     }
 
     /// Waits for up to the given timeout for any of the given slice of `token`-`Pollable` tuples to
@@ -111,7 +110,6 @@ impl Poller {
             tv_sec: timeout.as_secs() as time_t,
             tv_nsec: timeout.subsec_nanos() as c_long,
         };
-
         // Safe because poll is given the correct length of properly initialized pollfds, and we
         // check the return result.
         let ret = unsafe {