Re: [PATCH v2] swait: export symbols __prepare_to_swait and __finish_swait

[Mike Snitzer <snitzer@redhat.com>]

On Thu, May 24 2018 at 10:10am -0400,
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, May 23, 2018 at 02:10:46PM -0400, Mike Snitzer wrote:
> > [Peter, in this v2 I switched to using _GPL for the exports and updated
> > the patch header.  As covered in previous mail, please let me know if
> > you're OK with me staging this change for 4.18 via linux-dm.git with
> > your Ack, thanks]
> > 
> > From: Mikulas Patocka <mpatocka@redhat.com>
> > Subject: [PATCH] swait: export symbols __prepare_to_swait and __finish_swait
> > 
> > __prepare_to_swait and __finish_swait are declared in
> > include/linux/swait.h but they are not exported; so they are not useable
> > from kernel modules.
> > 
> > A new consumer of swait (in dm-writecache) reduces its locking overhead
> > by using the spinlock in swait_queue_head to protect not only the wait
> > queue, but also the list of events.  Consequently, this swait consuming
> > kernel module needs to use these unlocked functions.
> > 
> > Peter Zijlstra explained:
> >   "The reason swait exists is to be deterministic (for RT) -- something
> >   that regular wait code cannot be.
> >   And by (ab)using / exporting the wait internal lock you risk losing
> >   that. So I don't think the proposed [dm-writecache] usage is bad, it
> >   is possible to create badness.
> >   So if we're going to export them; someone needs to keep an eye on things
> >   and ensure the lock isn't abused."
> > 
> > So while this new use of the wait internal lock doesn't jeopardize the
> > realtime requirements of swait, these exports do open swait's internal
> > locking up to being abused.  As such, EXPORT_SYMBOL_GPL is used because
> > any future consumers of __prepare_to_swait and __finish_swait must
> > always be thoroughly scrutinized.
> > 
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Thanks Peter.