Date: Sun, 30 Jan 2011 04:27:56 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Martin Matuska <mm@FreeBSD.org> Cc: freebsd-fs <freebsd-fs@FreeBSD.org> Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread Message-ID: <20110130041141.G30713@besplex.bde.org> In-Reply-To: <4D443407.7010604@FreeBSD.org> References: <AANLkTikciV_XHvrurytr0-r11W4u=_p5bRi-xfX3S%2BQm@mail.gmail.com> <4D443407.7010604@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-386676537-1296322076=:30713 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 29 Jan 2011, Martin Matuska 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. clock_t should be not signed (int32_t), i.e. uint32_t. This is quite broken in FreeBSD, although it was almost correct in 4.4BSD-Lite ( clock_t was always unsigned long there). Now there is the following mess: amd64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ arm/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock()... *= / i386/include/_types.h:typedef=09unsigned long=09__clock_t;=09=09/* clock().= =2E. */ ia64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / mips/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / powerpc/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock().= =2E. */ sparc64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()..= =2E */ sun4v/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ I think the unsignedness 64-bit arches regressed by copying a bug from NetBSD via alpha. NetBSD had to fix hundreds or thousands of longs in old BSD since the size of long is too fuzzy for ABIs once long is actually longer than int (> 32 bits) although still not long (! > register width), and seems to have broken the unsignedness when changing the type. > D=C5=88a 29.01.2011 11:30, Artem Belevich wrote / nap=C3=ADsal(a) >> Hi, >> >> I'm using ZFS v15 on RELENG_8/amd64 box. Some time back I've noticed >> that after a while ZFS starts to consume 100% of CPU time on one of >> the cores. After a bit of digging it appears that the problem is due >> to an integer overflow. >> >> On amd64 (as wel as most other FreeBSD platforms) clock_t is a signed >> 32-bit integer. On OpenSolaris clock_t is long. I don't know how declaring it as long for cddl works when it is not long in FreeBSD. Pehraps because FreeBSD doesn't really use clock_t. Also, long on i386 is just 32 bits, so I don't see how declaring clock_t as long helps in general. Declaring it as uint32_t might delay the overflow from 24.5 days to 49 days. Bruce --0-386676537-1296322076=:30713--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110130041141.G30713>