lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 16 Aug 2014 00:33:22 +0200 From: Frederic Weisbecker <fweisbec@...il.com> To: Oleg Nesterov <oleg@...hat.com> Cc: Rik van Riel <riel@...hat.com>, LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>, Frank Mayhar <fmayhar@...gle.com>, Frederic Weisbecker <fweisbec@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, Sanjay Rao <srao@...hat.com>, Larry Woodman <lwoodman@...hat.com> Subject: Re: [PATCH RFC] time,signal: protect resource use statistics with seqlock On Fri, Aug 15, 2014 at 04:26:01PM +0200, Oleg Nesterov wrote: > On 08/15, Frederic Weisbecker wrote: > > > > 2014-08-14 16:39 GMT+02:00 Oleg Nesterov <oleg@...hat.com>: > > > On 08/14, Frederic Weisbecker wrote: > > >> > > >> I mean the read side doesn't use a lock with seqlocks. It's only made > > >> of barriers and sequence numbers to ensure the reader doesn't read > > >> some half-complete update. But other than that it can as well see the > > >> update n - 1 since barriers don't enforce latest results. > > > > > > Yes, sure, read_seqcount_begin/read_seqcount_retry "right after" > > > write_seqcount_begin-update-write_seqcount_begin can miss "update" part > > > along with ->sequence modifications. > > > > > > But I still can't understand how this can lead to non-monotonic results, > > > could you spell? > > > > Well lets say clock = T. > > CPU 0 updates at T + 1. > > Then I call clock_gettime() from CPU 1 and CPU 2. CPU 1 reads T + 1 > > while CPU 1 still reads T. > > If I do yet another round of clock_gettime() on CPU 1 and CPU 2, it's > > possible that CPU 2 still sees T. With the spinlocked version that > > thing can't happen, the second round would read at least T + 1 for > > both CPUs. > > But this is fine? And CPU 2 doesn't see a non-monotonic result? > > OK, this could be wrong if, say, > > void print_clock(void) > { > lock(SOME_LOCK); > printk(..., clock_gettime()); > unlock(SOME_LOCK); > } > > printed the non-monotonic numbers if print_clock() is called on CPU_1 and > then on CPU_2. But in this case CPU_2 can't miss the changes on CPU_0 if > they were already visible to CPU_1 under the same lock. IOW, > > int T = 0; /* can be incremented at any time */ > > void check_monotony(void) > { > static int t = 0; > > lock(SOME_LOCK); > BUG(t > T); > T = t; > unlock(SOME_LOCK); > } > > must work corrrectly (ignoring overflow) even if T is changed without > SOME_LOCK. > > Otherwise, without some sort of synchronization the different results on > CPU_1/2 should be fine. > > Or I am still missing your point? No I think you're right, as long as ordering against something else is involved, monotonicity is enforced. Now I'm trying to think about a case where SMP ordering isn't involved. Perhaps some usecase based on coupling CPU local clocks and clock_gettime() where a drift between both can appear. Now using a local clock probably only makes sense in the context of local usecases where the thread clock update would be local as well. So that's probably not a problem. Now what if somebody couples multithread process wide clocks with per CPU local clocks. Well that's probably too foolish to be considered. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists