Date: Mon, 31 Jan 2011 00:25:13 +0100 From: Martin Matuska <mm@FreeBSD.org> To: Artem Belevich <fbsdlist@src.cx> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread Message-ID: <4D45F359.4040402@FreeBSD.org> In-Reply-To: <AANLkTikASEbWQRsZr%2BMHth-jzbskwt4P14mXjCjdZrPk@mail.gmail.com> References: <AANLkTikciV_XHvrurytr0-r11W4u=_p5bRi-xfX3S%2BQm@mail.gmail.com> <4D443407.7010604@FreeBSD.org> <AANLkTikASEbWQRsZr%2BMHth-jzbskwt4P14mXjCjdZrPk@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I have re-checked OpenSolaris, and discovered that long is a int32_t. I agree, we should go for int64_t in our case. Dňa 29.01.2011 20:06, Artem Belevich wrote / napísal(a): > On Sat, Jan 29, 2011 at 7:36 AM, Martin Matuska <mm@freebsd.org> wrote: >> I agree to you that we have different types and this may be an issue but >> I disagree to your patch. >> clock_t is not signed (int64_t) and this can be done in a much easier >> (and cleaner way) without touching the code, see attached patch. > > I like the minimalism of your patch. > > It should fix the overflow on LP64, but it would still be there on > i386. To avoid this particular problem we need int64_t even on 32-bit > platforms. Either that, or we should change the way we emulate > solaris' LBOLT in FreeBSD. > > Another concern I have is with this patch we'll end up with parts of > kernel compiled with 32-bit clock_t and other parts build with 64-bit > clock_t. If someone passes a pointer to clock_t between these two > classes of code, we'll have a problem. > > --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D45F359.4040402>