On Mon, Jun 4, 2018 at 6:46 PM, Jason Gunthorpe wrote:
> On Mon, Jun 04, 2018 at 06:23:20PM +0200, Gi-Oh Kim wrote:
>> On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote:
>> > ucma_process_join() will free the new allocated "mc" struct,
>> > if there is any error after that, especially the copy_to_u
On Mon, Jun 04, 2018 at 06:23:20PM +0200, Gi-Oh Kim wrote:
> On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote:
> > ucma_process_join() will free the new allocated "mc" struct,
> > if there is any error after that, especially the copy_to_user().
> >
> > But in parallel, ucma_leave_multicast() could
On Fri, Jun 01, 2018 at 11:31:44AM -0700, Cong Wang wrote:
> ucma_process_join() will free the new allocated "mc" struct,
> if there is any error after that, especially the copy_to_user().
>
> But in parallel, ucma_leave_multicast() could find this "mc"
> through idr_find() before ucma_process_joi
On Mon, Jun 4, 2018 at 9:23 AM, Gi-Oh Kim wrote:
> Hi,
>
> Your patch is reasonable to me.
> Can I ask a question for that?
> Could it be solved by asymmetric locking as following?
Maybe, if you are sure taking file->mut is safe in that place.
Can you double check atomic_inc_not_zero(&mc->ctx->r
On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote:
> ucma_process_join() will free the new allocated "mc" struct,
> if there is any error after that, especially the copy_to_user().
>
> But in parallel, ucma_leave_multicast() could find this "mc"
> through idr_find() before ucma_process_join() frees
ucma_process_join() will free the new allocated "mc" struct,
if there is any error after that, especially the copy_to_user().
But in parallel, ucma_leave_multicast() could find this "mc"
through idr_find() before ucma_process_join() frees it, since it
is already published.
So "mc" could be used i
6 matches
Mail list logo
