linux-kernel - Re: [PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK

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: <04b08b78-6348-d592-ca2e-f718955bcc68@akamai.com>
Date:   Tue, 24 Sep 2019 13:34:58 -0400
From:   Jason Baron <jbaron@...mai.com>
To:     Roman Penyaev <rpenyaev@...e.de>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dave@...olabs.net>,
        Al Viro <viro@...iv.linux.org.uk>,
        Eric Wong <normalperson@...t.net>
Subject: Re: [PATCH] epoll: simplify ep_poll_safewake() for
 CONFIG_DEBUG_LOCK_ALLOC



On 9/23/19 3:23 PM, Roman Penyaev wrote:
> On 2019-09-23 17:43, Jason Baron wrote:
>> On 9/4/19 4:22 PM, Jason Baron wrote:
>>> Currently, ep_poll_safewake() in the CONFIG_DEBUG_LOCK_ALLOC case uses
>>> ep_call_nested() in order to pass the correct subclass argument to
>>> spin_lock_irqsave_nested(). However, ep_call_nested() adds unnecessary
>>> checks for epoll depth and loops that are already verified when doing
>>> EPOLL_CTL_ADD. This mirrors a conversion that was done for
>>> !CONFIG_DEBUG_LOCK_ALLOC in: commit 37b5e5212a44 ("epoll: remove
>>> ep_call_nested() from ep_eventpoll_poll()")
>>>
>>> Signed-off-by: Jason Baron <jbaron@...mai.com>
>>> Cc: Davidlohr Bueso <dave@...olabs.net>
>>> Cc: Roman Penyaev <rpenyaev@...e.de>
>>> Cc: Al Viro <viro@...iv.linux.org.uk>
>>> Cc: Eric Wong <normalperson@...t.net>
>>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>>> ---
>>>  fs/eventpoll.c | 36 +++++++++++++-----------------------
>>>  1 file changed, 13 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
>>> index d7f1f50..a9b2737 100644
>>> --- a/fs/eventpoll.c
>>> +++ b/fs/eventpoll.c
>>> @@ -551,28 +551,23 @@ static int ep_call_nested(struct nested_calls
>>> *ncalls,
>>>   */
>>>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
>>>
>>> -static struct nested_calls poll_safewake_ncalls;
>>> -
>>> -static int ep_poll_wakeup_proc(void *priv, void *cookie, int
>>> call_nests)
>>> -{
>>> -    unsigned long flags;
>>> -    wait_queue_head_t *wqueue = (wait_queue_head_t *)cookie;
>>> -
>>> -    spin_lock_irqsave_nested(&wqueue->lock, flags, call_nests + 1);
>>> -    wake_up_locked_poll(wqueue, EPOLLIN);
>>> -    spin_unlock_irqrestore(&wqueue->lock, flags);
>>> -
>>> -    return 0;
>>> -}
>>> +static DEFINE_PER_CPU(int, wakeup_nest);
>>>
>>>  static void ep_poll_safewake(wait_queue_head_t *wq)
>>>  {
>>> -    int this_cpu = get_cpu();
>>> -
>>> -    ep_call_nested(&poll_safewake_ncalls,
>>> -               ep_poll_wakeup_proc, NULL, wq, (void *) (long)
>>> this_cpu);
>>> +    unsigned long flags;
>>> +    int subclass;
>>>
>>> -    put_cpu();
>>> +    local_irq_save(flags);
>>> +    preempt_disable();
>>> +    subclass = __this_cpu_read(wakeup_nest);
>>> +    spin_lock_nested(&wq->lock, subclass + 1);
>>> +    __this_cpu_inc(wakeup_nest);
>>> +    wake_up_locked_poll(wq, POLLIN);
>>> +    __this_cpu_dec(wakeup_nest);
>>> +    spin_unlock(&wq->lock);
>>> +    local_irq_restore(flags);
>>> +    preempt_enable();
>>>  }
> 
> What if reduce number of lines with something as the following:
> 
>    int this_cpu = get_cpu();
>    subclass = __this_cpu_inc_return(wakeup_nest);
>    spin_lock_irqsave_nested(&wq->lock, flags, subclass);
>    wake_up_locked_poll(wq, POLLIN);
>    spin_unlock_irqrestore(&wq->lock, flags);
>    __this_cpu_dec(wakeup_nest);
>    put_cpu();
> 
> Other than that looks good to me.
> 
> Reviewed-by: Roman Penyaev <rpenyaev@...e.de>
> 
> -- 
> Roman


Hi,

I put the local_irq_save(flags), call there first so that there wouldn't
be any nesting. For example, in your sequence, there could be an irq
after the  __this_cpu_inc_return(), that could end up back here.

I still can use __this_cpu_inc_return() to simplify things a bit.

Thanks,

-Jason