From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752511AbdB1NRR (ORCPT ); Tue, 28 Feb 2017 08:17:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49698 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbdB1NRQ (ORCPT ); Tue, 28 Feb 2017 08:17:16 -0500 From: Vitaly Kuznetsov To: Dexuan Cui Cc: Stephen Hemminger , "gregkh\@linuxfoundation.org" , Haiyang Zhang , "driverdev-devel\@linuxdriverproject.org" , "Alex Ng \(LIS\)" , "linux-kernel\@vger.kernel.org" Subject: Re: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't References: <87k28av6nm.fsf@vitty.brq.redhat.com> Date: Tue, 28 Feb 2017 14:06:32 +0100 In-Reply-To: (Dexuan Cui's message of "Tue, 28 Feb 2017 13:01:00 +0000") Message-ID: <87fuiyv50n.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 28 Feb 2017 13:06:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dexuan Cui writes: >> From: devel [...] On Behalf Of Dexuan Cui >> > > --- a/drivers/hv/hv_utils_transport.h >> > > +++ b/drivers/hv/hv_utils_transport.h >> > > @@ -32,6 +32,7 @@ struct hvutil_transport { >> > > int mode; /* hvutil_transport_mode */ >> > > struct file_operations fops; /* file operations */ >> > > struct miscdevice mdev; /* misc device */ >> > > + bool dev_opened; /* Is the device opened? */ >> > > struct cb_id cn_id; /* CN_*_IDX/CN_*_VAL */ >> > > struct list_head list; /* hvt_list */ >> > > int (*on_msg)(void *, int); /* callback on new user message */ >> > >> > I think we can get away without introducing this new flag, e.g. if we >> > replace release_event with an atomic which will hold the state >> > (open/closed). This will also elimenate possible races above. I can try >> > prototyping a patch if you want me to. >> > -- >> > Vitaly >> >> Thanks for offering the help! Please do. :-) > > BTW, IMO I found another potential issue: > In hvt_op_open -> hvt_reset -> kvp_on_reset(), I think we should call > init_completion() instead of complete()? > To me it looks like we can do better with something different from struct completion, I'll take a look later today. -- Vitaly