linux-kernel - Re: [RFC PATCH] hrtimer: removing all ur callback modes

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:	Mon, 08 Dec 2008 11:15:59 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oliver Hartkopp <oliver@...tkopp.net>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH] hrtimer: removing all ur callback modes

On Sun, 2008-12-07 at 13:59 +0100, Oliver Hartkopp wrote:
> Oliver Hartkopp wrote:
> > Peter Zijlstra wrote:
> >> On Tue, 2008-11-25 at 12:43 +0100, Peter Zijlstra wrote:
> >>  
> >>> Hi,
> >>>
> >>> This is an attempt at removing some of the hrtimer complexity by
> >>> reducing the number of callback modes to 1.
> >>>
> >>> This means that all hrtimer callback functions will be ran from 
> >>> HARD-irq
> >>> context.
> >>>
> >>> I went through all the 30 odd hrtimer callback functions in the kernel
> >>> and saw only one that I'm not quite sure of, which is the one in
> >>> net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.
> >>>     
> >
> > Thanks Peter.
> >
> > Indeed i assumed my hrtimer callbacks to run in soft-irq. I tried the 
> > can-bcm protocol with Ingos current linux-2.6-sched-devel.git 
> > including your patches and i did not see any issues so far. And i do 
> > not expect any (recursion) problems with hrtimer_forward() in my code 
> > either.
> >
> > But i'm not that familiar with the timer context's stuff, that i would 
> > like guaranty that the functions i use in bcm_send_user() and in 
> > bcm_can_tx() are always safe to be used in hard-irq context.
> >
> > It would be nice, if you could give me some support by double checking 
> > the correctness of the hard-irq context in the given functions.
> 
> Hi Peter,
> 
> i ran a heavy load test, which get's (reproducible) the attached outputs ...
> 
> Maybe it's not that good to define the hrtimer context to be always 
> hard-irq.

Thing is, this 'cleanup' removes quite a bit of complexity from the core
hrtimer code, and afaict your bit is the only thing that cannot seem to
cope. So I'd rather look at fixing your site than re-introduce softirqs
to hrtimers.

> Any idea?

What are the timing constraints of your problem? - I assume they are not
too aggressive, otherwise you'd not be able to run from softirq, could
you run from keventd?

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