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]

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


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> 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. ]

we should think about the simplest approach: switching itimers to 
hrtimers.

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