From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 05:03:55 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE66EDCD; Mon, 30 Mar 2015 05:03:55 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 42B67F3B; Mon, 30 Mar 2015 05:03:54 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 419E61A2581; Mon, 30 Mar 2015 16:03:39 +1100 (AEDT) Date: Mon, 30 Mar 2015 16:03:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans Subject: Re: svn commit: r280308 - head/sys/fs/devfs In-Reply-To: <20150330145148.C1660@besplex.bde.org> Message-ID: <20150330154136.O1803@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ZuzUdbLG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=zzdhk42y61ABjVYjYAsA:9 a=CjuIK1q_8ugA:10 Cc: src-committers@freebsd.org, Jilles Tjoelker , Don Lewis , svn-src-head@freebsd.org, delphij@freebsd.org, Konstantin Belousov , svn-src-all@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 05:03:55 -0000 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