linux-kernel - Re: [PATCH 1/2] itimers: fix racy writes to cpu

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2009 20:04:27 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] itimers: fix racy writes to cpu_itimer fields

On Thu, 2009-09-24 at 19:57 +0200, Stanislaw Gruszka wrote:
> On Thu, 24 Sep 2009 16:48:07 +0200
> Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> 
> > On Thu, 2009-09-24 at 16:35 +0200, Stanislaw Gruszka wrote:
> > > incr_error and error fields of struct cpu_itimer are used when calculating
> > > next timer tick in check_cpu_itimers() and should not be modified without
> > > tsk->sighand->siglock taken.
> > 
> > Won't it be all-round much better to convert these things to hrtimers
> > instead of adding more and more fuzz on top to make them deal with
> > jiffies?
> 
> Perhaps it would, but I don't know how to do it :{ . Especially how to
> precisely account user time. The only idea I have is make something like 
> microstate accounting (http://lwn.net/Articles/127296/), but this patch
> and whole idea was rejected long time ago. 

That patch does look a little painful indeed.

I was more thinking about about looking if an itimer was to expire less
than 1 tick away on either sched-in or the tick.

When we find it is indeed less than 1 tick away, program an hrtimer for
that cpu to expire at the required moment, see hrtick_start().

If we happen to de-schedule the task before the timer fires, we clear
the hrtimer again (or let it pend and ignore the fire), see
hrtick_clear().

[ there is no reason to rely on the tick though, we can program the
hrtimer on sched in to expire on at the right moment, and do so on each
schedule for as long as an itimer is active - re-setting whatever
pending timer the cpu still had. ]

--
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/