[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200313193132.GE12521@hirez.programming.kicks-ass.net>
Date: Fri, 13 Mar 2020 20:31:32 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Will Deacon <will@...nel.org>,
"Paul E . McKenney" <paulmck@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Kurt Schwemmer <kurt.schwemmer@...rosemi.com>,
Logan Gunthorpe <logang@...tatee.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org
Subject: Re: [PATCH 3/9] pci/switchtec: Don't abuse completion wait queue for
poll
On Fri, Mar 13, 2020 at 06:46:55PM +0100, Sebastian Andrzej Siewior wrote:
> The poll callback is abusing the completion wait queue and sticks it into
> poll_wait() to wake up pollers after a command has completed.
>
> First of all it's a layering violation as it imposes restrictions on the
> inner workings of completions. Just because C allows to do so does not
> justify that in any way. The proper way to do such things is to post
> patches which extend the core infrastructure and not by silently abusing
> it.
>
> Aside of that the implementation is seriously broken:
>
> 1) It cannot work with EPOLLEXCLUSIVE
>
> 2) It's racy:
>
> poll() write()
> switchtec_dev_poll() switchtec_dev_write()
> poll_wait(&s->comp.wait); mrpc_queue_cmd()
> init_completion(&s->comp)
> init_waitqueue_head(&s->comp.wait)
>
> Replace it with a regular wait queue which removes the completion abuse and
> cures #1 and #2 above.
>
> Cc: Kurt Schwemmer <kurt.schwemmer@...rosemi.com>
> Cc: Logan Gunthorpe <logang@...tatee.com>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> Cc: linux-pci@...r.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Relying on implementation details of locking primitives like that is
yuck.
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Powered by blists - more mailing lists