mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Oleksandr Andrushchenko <andr2000@gmail.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Cc: jgross@suse.com, sstabellini@kernel.org,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] xen/gntdev: fix unmap notification order
Date: Fri, 10 Dec 2021 19:47:06 -0500	[thread overview]
Message-ID: <7d113a50-5efd-d45e-04b9-a29023092518@oracle.com> (raw)
In-Reply-To: <20211210092817.580718-1-andr2000@gmail.com>


On 12/10/21 4:28 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> While working with Xen's libxenvchan library I have faced an issue with
> unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT
> and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event channel
> notification and then clear the notification byte which renders in the below
> inconsistency (cli_live is the byte which was requested to be cleared on unmap):
>
> [  444.514243] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6
> libxenvchan_is_open cli_live 1
> [  444.515239] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14
>
> Thus it is not possible to reliably implement the checks like
> - wait for the notification (UNMAP_NOTIFY_SEND_EVENT)
> - check the variable (UNMAP_NOTIFY_CLEAR_BYTE)
> because it is possible that the variable gets checked before it is cleared
> by the kernel.
>
> To fix that we need to re-order the notifications, so the variable is first
> gets cleared and then the event channel notification is sent.
> With this fix I can see the correct order of execution:
>
> [   54.522611] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14
> [   54.537966] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6
> libxenvchan_is_open cli_live 0
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>



Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


  reply	other threads:[~2021-12-11  0:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10  9:28 Oleksandr Andrushchenko
2021-12-11  0:47 ` Boris Ostrovsky [this message]
2021-12-13 13:46 ` Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d113a50-5efd-d45e-04b9-a29023092518@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=andr2000@gmail.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®