Date: Mon, 30 Mar 2015 16:03:38 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, Don Lewis <truckman@freebsd.org>, svn-src-head@freebsd.org, delphij@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, svn-src-all@freebsd.org Subject: Re: svn commit: r280308 - head/sys/fs/devfs Message-ID: <20150330154136.O1803@besplex.bde.org> In-Reply-To: <20150330145148.C1660@besplex.bde.org> References: <20150322162507.GD2379@kib.kiev.ua> <201503221825.t2MIP7jv096531@gw.catspoiler.org> <20150329175137.GD95224@stack.nl> <20150329184238.GB2379@kib.kiev.ua> <20150330145148.C1660@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Mar 2015, Bruce Evans wrote:
> On Sun, 29 Mar 2015, Konstantin Belousov wrote:
>
>> Interesting complication with the devfs timestamp update is that
>> devfs_read_f() and devfs_write_f() do not lock the vnode. So whatever
>> update method is used, stat(2) on devfs might return inconsistent value,
>> since tv_src/tv_nsec cannot be updated or read by single op, without
>> locking.
>
> Urk.
> ...
>> +static void
>> +devfs_timestamp(struct timespec *tsp)
>> +{
>> + time_t ts;
>> +
>> + if (devfs_dotimes) {
>> + vfs_timestamp(tsp);
>> + } else {
>> + ts = time_second;
>> + if (tsp->tv_sec < ts) {
>> + tsp->tv_sec = ts;
>> + tsp->tv_nsec = 0;
>> + }
> ...
> I think you only want to do a null update if tv_nsec is nonzero due to a
> previous setting with vfs_timestamp(), and the new second hasn't arrived
> yet. Something like:
> ...
Further problems:
- all changes to vfs.timestamp_precision to a lower precision can give
non-monotonic timestamps. I wouldn't bother fixing this only here.
- time_t is bogusly 64 bits on some 32-bit arches (32-bit arm and 32-bit
mips). Thus direct accesses to time_second are racy and should not
be used in MI code. This bug is harmless for the same reason that
64-bit time_t is bogus -- 32-bit unsigned time_t works until 2106.
The first race will occur slightly before then. Except for testing
timestamps far in the future. With 32-bit time_t, you just can't
do such tests, but with 64-bit time_t you can do them to find races
like this one.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150330154136.O1803>