On Fri, Oct 19, 2018 at 07:29:45AM -0700, Andy Lutomirski wrote:
> > On Oct 19, 2018, at 1:33 AM, Peter Zijlstra wrote:
> >
> >> On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote:
> >> Consider for example do_int3(), and see my inlined comments:
> >>
> >> dotraplinkage void notrace do_i
On Fri, 19 Oct 2018 04:44:33 +
Nadav Amit wrote:
> at 9:29 PM, Andy Lutomirski wrote:
>
> >> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
> >>
> >> at 10:00 AM, Andy Lutomirski wrote:
> >>
> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>
> at 8:51 PM, Andy Lutomirsk
On Fri, Oct 19, 2018 at 1:22 AM Peter Zijlstra wrote:
>
> On Thu, Oct 18, 2018 at 10:00:53PM -0700, Alexei Starovoitov wrote:
> > >
> > > >
> > > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > > > preempt_enable_no_resched().
> > >
> > > Alexei, I think this code is just wrong.
>
> On Oct 19, 2018, at 1:33 AM, Peter Zijlstra wrote:
>
>> On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote:
>> Consider for example do_int3(), and see my inlined comments:
>>
>> dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
>> {
>>...
>>ist_enter(
On 10/18, Andy Lutomirski wrote:
>
> Oleg, the code in kernel/signal.c:
>
> preempt_disable();
> read_unlock(&tasklist_lock);
> preempt_enable_no_resched();
> freezable_schedule();
>
> looks bogus. I don't get what it's trying to achi
On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote:
> Consider for example do_int3(), and see my inlined comments:
>
> dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
> {
> ...
> ist_enter(regs);// => preempt_disable()
> cond_loca
On Thu, Oct 18, 2018 at 10:00:53PM -0700, Alexei Starovoitov wrote:
> >
> > >
> > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > > preempt_enable_no_resched().
> >
> > Alexei, I think this code is just wrong.
>
> why 'just wrong' ?
Because you lost a preemption point, this is
On Thu, Oct 18, 2018 at 09:29:39PM -0700, Andy Lutomirski wrote:
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong. Do you know why it uses
> preempt_enable_no_resched()?
Yes, that's a straight up bug.
It
>
> >
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong.
why 'just wrong' ?
> Do you know why it uses
> preempt_enable_no_resched()?
dont recall precisely.
we could be preemptable at the point where macro
at 9:29 PM, Andy Lutomirski wrote:
>> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>>
>> at 10:00 AM, Andy Lutomirski wrote:
>>
On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
at 8:51 PM, Andy Lutomirski wrote:
>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>
> at 10:00 AM, Andy Lutomirski wrote:
>
>>
>>
>>> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>>>
>>> at 8:51 PM, Andy Lutomirski wrote:
>>>
> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
> at 6:22 PM, Andy Lutomirski wrote:
>
at 10:00 AM, Andy Lutomirski wrote:
>
>
>> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>>
>> at 8:51 PM, Andy Lutomirski wrote:
>>
On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
at 6:22 PM, Andy Lutomirski wrote:
>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
at 12:54 AM, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 06:22:48PM -0700, Andy Lutomirski wrote:
>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
>>>
>>> It is sometimes beneficial to prevent preemption for very few
>>> instructions, or prevent preemption for some instructions that prece
at 10:29 AM, Andy Lutomirski wrote:
> On Thu, Oct 18, 2018 at 10:25 AM Nadav Amit wrote:
>> at 10:00 AM, Andy Lutomirski wrote:
>>
On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
at 8:51 PM, Andy Lutomirski wrote:
>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
On Thu, Oct 18, 2018 at 10:25 AM Nadav Amit wrote:
>
> at 10:00 AM, Andy Lutomirski wrote:
>
> >
> >
> >> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
> >>
> >> at 8:51 PM, Andy Lutomirski wrote:
> >>
> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
> at 6:22 PM, Andy Lutomirski
at 10:00 AM, Andy Lutomirski wrote:
>
>
>> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>>
>> at 8:51 PM, Andy Lutomirski wrote:
>>
On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
at 6:22 PM, Andy Lutomirski wrote:
>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>
> at 8:51 PM, Andy Lutomirski wrote:
>
>>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
>>> at 6:22 PM, Andy Lutomirski wrote:
>>>
> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
>
> It is sometimes beneficial to preve
at 8:51 PM, Andy Lutomirski wrote:
> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
>> at 6:22 PM, Andy Lutomirski wrote:
>>
On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
It is sometimes beneficial to prevent preemption for very few
instructions, or prevent preemption
On Wed, Oct 17, 2018 at 06:22:48PM -0700, Andy Lutomirski wrote:
>
> > On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
> >
> > It is sometimes beneficial to prevent preemption for very few
> > instructions, or prevent preemption for some instructions that precede
> > a branch (this latter case wi
On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
>
> at 6:22 PM, Andy Lutomirski wrote:
>
> >
> >> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
> >>
> >> It is sometimes beneficial to prevent preemption for very few
> >> instructions, or prevent preemption for some instructions that precede
>
at 8:11 PM, Nadav Amit wrote:
> at 6:22 PM, Andy Lutomirski wrote:
>
>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
>>>
>>> It is sometimes beneficial to prevent preemption for very few
>>> instructions, or prevent preemption for some instructions that precede
>>> a branch (this latter ca
at 6:22 PM, Andy Lutomirski wrote:
>
>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
>>
>> It is sometimes beneficial to prevent preemption for very few
>> instructions, or prevent preemption for some instructions that precede
>> a branch (this latter case will be introduced in the next patc
> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
>
> It is sometimes beneficial to prevent preemption for very few
> instructions, or prevent preemption for some instructions that precede
> a branch (this latter case will be introduced in the next patches).
>
> To provide such functionality on
23 matches
Mail list logo
