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
| ||
|
Message-ID: <20140814135318.GA26891@redhat.com> Date: Thu, 14 Aug 2014 15:53:18 +0200 From: Oleg Nesterov <oleg@...hat.com> To: Frederic Weisbecker <fweisbec@...il.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 08/14, Frederic Weisbecker wrote: > > 2014-08-14 15:22 GMT+02:00 Oleg Nesterov <oleg@...hat.com>: > > On 08/13, Rik van Riel wrote: > >> > >> @@ -646,6 +646,7 @@ struct signal_struct { > >> * Live threads maintain their own counters and add to these > >> * in __exit_signal, except for the group leader. > >> */ > >> + seqlock_t stats_lock; > > > > Ah. Somehow I thought that you were going to use seqcount_t and fallback > > to taking ->siglock if seqcount_retry, but this patch adds the "full blown" > > seqlock_t. > > > > OK, I won't argue, this can make the seqbegin_or_lock simpler... > > Is this really needed? seqlock are useful when we have concurrent > updaters. But updaters of thread stats should be under the thread lock > already, right? If we have only one updater at a time, seqcount should > be enough. Yes, this is what I meant. Although I can see 2 reasons to use seqlock_t: 1. It can simplify the seqbegin-or-lock logic. If nothing else, you simply can't use read_seqbegin_or_lock() to take ->siglock. But this is just syntactic sugar. 2. If we use ->siglock in fallback path, we need to verify that thread_group_cputime() is never called with ->siglock held first. Or, we need a fat comment to explain that need_seqrtry == T is not possible if it is called under ->siglock, and thus "fallback to lock_task_sighand" must be always safe. But in this case we need to ensure that the caller didn't do write_seqcount_begin(). So perhaps seqlock_t makes more sense at least initially... Oleg. -- 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