linux-kernel - RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CY4PR03MB2662F68B4C07645D03E74C19BF290@CY4PR03MB2662.namprd03.prod.outlook.com>
Date:   Wed, 1 Mar 2017 14:34:29 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
CC:     Stephen Hemminger <sthemmin@...rosoft.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "driverdev-devel@...uxdriverproject.org" 
        <driverdev-devel@...uxdriverproject.org>,
        "Alex Ng (LIS)" <alexng@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release
 event, if we shouldn't

> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
(c)
> >>> > >     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.
> 
> Dexuan,
> 
> please take a look at the attached patch. After looking at the code
> again it occured to me that it's going to be easier to move release wait
> to the transport itself. Lightly tested.
> 
>   Vitaly

You made a neat patch, which can fix the bug.

Thank you a lot!

Thanks,
-- Dexuan