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] [thread-next>] [day] [month] [year] [list]

Message-ID: <MWHPR03MB2669AA02934A740171596E8DBF560@MWHPR03MB2669.namprd03.prod.outlook.com>
Date:   Tue, 28 Feb 2017 02:37:10 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Stephen Hemminger <sthemmin@...rosoft.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "driverdev-devel@...uxdriverproject.org" 
        <driverdev-devel@...uxdriverproject.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>
CC:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Alex Ng (LIS)" <alexng@...rosoft.com>
Subject: RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release
 event, if we shouldn't

> From: Stephen Hemminger
> Sent: Tuesday, February 28, 2017 01:02
> 
> The patch looks good. I don't  understand the exact semantics here and
> therefore have a couple of naïve questions
> 
> Is it possible device could be opened multiple times? Is reference counting
> done above?

The file can only be opened once.
When we open it for the first time, in hvt_op_open() we run
hvt->mode = HVUTIL_TRANSPORT_CHARDEV, and when we try to open it later,
the open() gets -EBUSY.
When the first fd is closed, in hvt_op_release() we run 
hvt->mode = HVUTIL_TRANSPORT_INIT, so we can re-open it successfully later.

> If device was never opened do you even have to do all the cleanup steps at
> all?

Yes, e.g. we do need the 3 cancel_*work_sync calls in hv_kvp_deinit():
the driver schedules the 3 works even if there is no daemon at all, e.g.
hv_kvp_onchannelcallback ->
    schedule_delayed_work(&kvp_host_handshake_work, ...).

Thanks,
-- Dexuan