All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Penyaev <rpenyaev@suse.de>
To: Jason Baron <jbaron@akamai.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Davidlohr Bueso <dave@stgolabs.net>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Eric Wong <normalperson@yhbt.net>
Subject: Re: [PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK_ALLOC
Date: Tue, 24 Sep 2019 19:52:18 +0200	[thread overview]
Message-ID: <76f656dc7ac92f92682641e22e1c44c4@suse.de> (raw)
In-Reply-To: <04b08b78-6348-d592-ca2e-f718955bcc68@akamai.com>

On 2019-09-24 19:34, Jason Baron wrote:
> 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@akamai.com>
>>>> Cc: Davidlohr Bueso <dave@stgolabs.net>
>>>> Cc: Roman Penyaev <rpenyaev@suse.de>
>>>> Cc: Al Viro <viro@zeniv.linux.org.uk>
>>>> Cc: Eric Wong <normalperson@yhbt.net>
>>>> Cc: Andrew Morton <akpm@linux-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@suse.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.

That is correct, but seems this is the original behavior of 
ep_call_nested(),
where irq can happen just after spin_unlock_irqrestore():

	spin_unlock_irqrestore(&ncalls->lock, flags);

         >>>> irq here <<<<<

	/* Call the nested function */
	error = (*nproc)(priv, cookie, call_nests);

so eventually you end up with spin_lock_irqsave_nested() call where
call_nests is not monotonically increased (not sequential) but has
a gap (depends on nesting).

So if shorter, I thought that your "local_irq_save + increment" sequence
is excessive.

--
Roman


  reply	other threads:[~2019-09-24 17:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 20:22 [PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK_ALLOC Jason Baron
2019-09-23 15:43 ` Jason Baron
2019-09-23 19:23   ` Roman Penyaev
2019-09-24 17:34     ` Jason Baron
2019-09-24 17:52       ` Roman Penyaev [this message]
2020-01-06 19:38         ` [PATCH] fs/epoll: rework safewake " Davidlohr Bueso
2020-01-06 20:28           ` Jason Baron
2020-01-06 21:01             ` Davidlohr Bueso
2020-01-17 19:16               ` [PATCH] fs/epoll: make nesting accounting safe for -rt kernel Jason Baron
2020-02-25  0:38                 ` Andrew Morton
2020-02-26 17:56                   ` [PATCH v2] " Jason Baron
2020-03-17 16:34                     ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76f656dc7ac92f92682641e22e1c44c4@suse.de \
    --to=rpenyaev@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=jbaron@akamai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.