From owner-cvs-all Mon Feb 3 13:35:10 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9C1437B401; Mon, 3 Feb 2003 13:35:08 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAEAF43F43; Mon, 3 Feb 2003 13:35:07 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h13LZ5Yu013076; Mon, 3 Feb 2003 22:35:06 +0100 (CET) (envelope-from phk@freebsd.org) To: John Baldwin Cc: cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/fs/msdosfs msdosfs_conv.c src/sys/fs/nwf From: phk@freebsd.org In-Reply-To: Your message of "Mon, 03 Feb 2003 16:23:20 EST." Date: Mon, 03 Feb 2003 22:35:05 +0100 Message-ID: <13075.1044308105@critter.freebsd.dk> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , John Baldwin writes: > >> Modified files: >> sys/fs/msdosfs msdosfs_conv.c >> sys/fs/nwfs nwfs_subr.c >> sys/fs/smbfs smbfs_subr.c >> sys/i386/ibcs2 ibcs2_xenix.c >> sys/i386/isa clock.c >> sys/kern kern_time.c subr_clock.c >> sys/pc98/pc98 clock.c >> sys/sys kernel.h >> Log: >> Split the global timezone structure into two integer fields to >> prevent the compiler from optimizing assignments into byte-copy >> operations which might make access to the individual fields non-atomic. >> >> Use the individual fields throughout, and don't bother locking them with >> Giant: it is no longer needed. > >Umm, what's to prevent, say, a sparc64 CPU from being interrupted >in between the load, modify, and store instructions? There are no load modify and store instructions. Three are reads and there are writes. One of the two fields is only ever used to report back to userland, and userland wisely ignores it, because it has not had any practical significance or meaning for the last ten years. The other field is (mis-)used by certain filesystems which store timestamps in localtime rather than UTC time. This is a problem in its own right: These filesystems are subject to a major race from when DST starts/stops until some userland program comes around and informs the kernel about the new UTC offset. This issue also beggs the question: If the timestamp on the media is "localtime", is it then the localtime where the server is located (Hoople, N. Dakota) or where the user is located (Mud, Elbonia), and when the user causes a timestamp to be updated, which of the two localtimes is it that is used for the update ? The close to ideal solution for these filesystems would be for stat/fstat to have a flag saying "timestamps are in localtime" and have the wrapper in libc convert to proper UTC timestamps when that flag comes out of the kernel. Unfortunately, on the way back into the kernel the problem is much harder to solve in a meaningful way, unless we start passing a localtime timestamp into the kernel for a lot of file operations, including write(2). And no, I'm not even going to think about this problem longer than it will take me to say: Microsoft really screwed this one up... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message