On Thu, Feb 20, 2020 at 1:06 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Thu, Feb 20, 2020 at 11:37:32AM +0100, Dmitry Vyukov wrote: > > On Wed, Feb 19, 2020 at 6:20 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > On Wed, Feb 19, 2020 at 05:30:25PM +0100, Peter Zijlstra wrote: > > > > > > > By inlining everything in poke_int3_handler() (except bsearch :/) we can > > > > mark the whole function off limits to everything and call it a day. That > > > > simplicity has been the guiding principle so far. > > > > > > > > Alternatively we can provide an __always_inline variant of bsearch(). > > > > > > This reduces the __no_sanitize usage to just the exception entry > > > (do_int3) and the critical function: poke_int3_handler(). > > > > > > Is this more acceptible? > > > > Let's say it's more acceptable. > > > > Acked-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > > Thanks, I'll go make it happen. > > > I guess there is no ideal solution here. > > > > Just a straw man proposal: expected number of elements is large enough > > to make bsearch profitable, right? I see 1 is a common case, but the > > other case has multiple entries. > > Latency was the consideration; the linear search would dramatically > increase the runtime of the exception. > > The current limit is 256 entries and we're hitting that quite often. > > (we can trivially increase, but nobody has been able to show significant > benefits for that -- as of yet) I see. Thanks for explaining. Just wanted to check because inlining a linear search would free us from all these unpleasant problems.
