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: <CAFTL4hwvPobNwm39qzLdP1mPLya7Wg-bLQnWn-Bt5mSV_i3QsA@mail.gmail.com> Date: Thu, 14 Aug 2014 15:38:50 +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 2014-08-14 15:22 GMT+02:00 Oleg Nesterov <oleg@...hat.com>: > On 08/13, Rik van Riel wrote: >> >> On Wed, 13 Aug 2014 20:45:11 +0200 >> Oleg Nesterov <oleg@...hat.com> wrote: >> >> > That said, it is not that I am really sure that seqcount_t in ->signal >> > is actually worse, not to mention that this is subjective anyway. IOW, >> > I am not going to really fight with your approach ;) >> >> This is what it looks like, on top of your for_each_thread series >> from yesterday: > > OK, lets forget about alternative approach for now. We can reconsider > it later. At least I have to admit that seqlock is more straighforward. > >> --- a/include/linux/sched.h >> +++ b/include/linux/sched.h >> @@ -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. -- 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