[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21a4daf9-c77e-ec80-9da0-78ab512d248d@os.inf.tu-dresden.de>
Date: Thu, 25 Jul 2019 16:36:20 +0200
From: Maksym Planeta <mplaneta@...inf.tu-dresden.de>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Moni Shoua <monis@...lanox.com>,
Doug Ledford <dledford@...hat.com>, linux-rdma@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/10] Replace tasklets with workqueues
Is this one better?
Replace tasklets with workqueues in rxe driver. The reason for this
replacement is that tasklets are supposed to run atomically, although
the actual code may block.
Modify the SKB destructor for outgoing SKB's to schedule QP tasks only
if the QP is not destroyed itself.
Add a variable "pending_skb_down" to ensure that reference counting for
a QP is decremented only when QP access related to this skb is over.
Separate part of pool element cleanup code to allow this code to be
called in the very end of cleanup, even if some of cleanup is scheduled
for asynchronous execution. Example, when it was happening is destructor
for a QP.
Disallow calling of task functions "directly". This allows to simplify
logic inside rxe_task.c
Schedule rxe_qp_do_cleanup onto high-priority system workqueue, because
this function can be scheduled from normal system workqueue.
Before destroying a QP, wait until all references to this QP are gone.
Previously the problem was that outgoing SKBs could be freed after the
QP these SKBs refer to is destroyed.
Add blocking rxe_run_task to replace __rxe_do_task that was calling task
function directly.
On 22/07/2019 17:32, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 05:14:26PM +0200, Maksym Planeta wrote:
>> Replace tasklets with workqueues in rxe driver.
>>
>> Ensure that task is called only through a workqueue. This allows to
>> simplify task logic.
>>
>> Add additional dependencies to make sure that cleanup tasks do not
>> happen after object's memory is already reclaimed.
>>
>> Improve overal stability of the driver by removing multiple race
>> conditions and use-after-free situations.
>
> This should be described more precisely
>
> Jason
>
--
Regards,
Maksym Planeta
Powered by blists - more mailing lists