linux-kernel - [PATCH] xen: fix frontend driver disconnected from xenbus on removal

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

Message-Id: <1517475439-10541-1-git-send-email-andr2000@gmail.com>
Date:   Thu,  1 Feb 2018 10:57:18 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Cc:     jgross@...e.com, david.vrabel@...rix.com,
        boris.ostrovsky@...cle.com, otubo@...hat.com,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: [PATCH] xen: fix frontend driver disconnected from xenbus on removal

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>

Hi, all!

While working on DRM PV frontend driver I faced an issue with
driver removal, e.g. when driver's .remove callback is called
the driver is already disconnected form the xenbus and it is not
possible to synchronize the process of removal with the backend.
Backend in my case is a user-space application, so this may explain
why backends which are kernel modules do not suffer from this:
it seems that user-space is clumsy and its states are not delivered
through xenbus fast enough.

The obvious way to fix this behavior is to disconnect frontend
drivers from xenbus _after_ their .remove callback is called.

Thank you,
Oleksandr Andrushchenko

Oleksandr Andrushchenko (1):
  xen: fix frontend driver disconnected from xenbus on removal

 drivers/xen/xenbus/xenbus_probe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.4