From: "Jürgen Groß" <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: "Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>
Subject: Re: [PATCH 2/2] xen/evtchn: rework per event channel lock
Date: Mon, 12 Oct 2020 11:15:14 +0200 [thread overview]
Message-ID: <3a7c7346-6506-f2e1-ad22-cd18aa1ccfc3@suse.com> (raw)
In-Reply-To: <20201012091058.27023-3-jgross@suse.com>
On 12.10.20 11:10, Juergen Gross wrote:
> Currently the lock for a single event channel needs to be taken with
> interrupts off, which causes deadlocks in some cases.
>
> Rework the per event channel lock to be non-blocking for the case of
> sending an event and removing the need for disabling interrupts for
> taking the lock.
>
> The lock is needed for avoiding races between sending an event or
> querying the channel's state against removal of the event channel.
>
> Use a locking scheme similar to a rwlock, but with some modifications:
>
> - sending an event or querying the event channel's state uses an
> operation similar to read_trylock(), in case of not obtaining the
> lock the sending is omitted or a default state is returned
>
> - closing an event channel is similar to write_lock(), but without
> real fairness regarding multiple writers (this saves some space in
> the event channel structure and multiple writers are impossible as
> closing an event channel requires the domain's event_lock to be
> held).
>
> With this locking scheme it is mandatory that a writer will always
> either start with an unbound or free event channel or will end with
> an unbound or free event channel, as otherwise the reaction of a reader
> not getting the lock would be wrong.
>
> Fixes: e045199c7c9c54 ("evtchn: address races with evtchn_reset()")
> Signed-off-by: Juergen Gross <jgross@suse.com>
Oh, please ignore. I forgot to add the needed barriers to the locking
functions.
Juergen
prev parent reply other threads:[~2020-10-12 9:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 9:10 [PATCH 0/2] XSA-343 followup patches Juergen Gross
2020-10-12 9:10 ` [PATCH 1/2] xen/events: access last_priority and last_vcpu_id together Juergen Gross
2020-10-12 9:10 ` [PATCH 2/2] xen/evtchn: rework per event channel lock Juergen Gross
2020-10-12 9:15 ` Jürgen Groß [this message]
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=3a7c7346-6506-f2e1-ad22-cd18aa1ccfc3@suse.com \
--to=jgross@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.