All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 6/8] evtchn: convert vIRQ lock to an r/w one
Date: Fri, 30 Oct 2020 13:00:15 +0100	[thread overview]
Message-ID: <33ff45e9-d869-9262-29e0-fa66e3ffb726@suse.com> (raw)
In-Reply-To: <6dec1d48-b8c8-6122-087c-38f36f30596e@xen.org>

On 30.10.2020 11:57, Julien Grall wrote:
> On 20/10/2020 15:10, Jan Beulich wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -449,6 +449,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t
>>   
>>       spin_unlock_irqrestore(&chn->lock, flags);
>>   
>> +    /*
>> +     * If by any, the update of virq_to_evtchn[] would need guarding by
>> +     * virq_lock, but since this is the last action here, there's no strict
>> +     * need to acquire the lock. Hnece holding event_lock isn't helpful
> 
> s/Hnece/Hence/
> 
>> +     * anymore at this point, but utilize that its unlocking acts as the
>> +     * otherwise necessary smp_wmb() here.
>> +     */
>>       v->virq_to_evtchn[virq] = bind->port = port;
> 
> I think all access to v->virq_to_evtchn[virq] should use ACCESS_ONCE() 
> or {read, write}_atomic() to avoid any store/load tearing.

IOW you're suggesting this to be the subject of a separate patch?
I don't think such a conversion belongs here (nor even in this
series, seeing the much wider applicability of such a change
throughout the code base). Or are you seeing anything here which
would require such a conversion to be done as a prereq?

Jan


  reply	other threads:[~2020-10-30 12:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20 14:06 [PATCH v2 0/8] evtchn: recent XSAs follow-on Jan Beulich
2020-10-20 14:08 ` [PATCH v2 1/8] evtchn: avoid race in get_xen_consumer() Jan Beulich
2020-10-21 15:46   ` Roger Pau Monné
2020-10-22  7:33     ` Jan Beulich
2020-10-22  8:11       ` Roger Pau Monné
2020-10-22  8:15         ` Jan Beulich
2020-10-22  8:29           ` Roger Pau Monné
2020-10-22  8:56             ` Jan Beulich
2020-10-22  9:25               ` Roger Pau Monné
2020-10-22  9:21   ` Roger Pau Monné
2020-10-30 10:15   ` Julien Grall
2020-10-20 14:08 ` [PATCH v2 2/8] evtchn: replace FIFO-specific header by generic private one Jan Beulich
2020-10-21 16:00   ` Roger Pau Monné
2020-10-30 10:21   ` Julien Grall
2020-10-30 10:42     ` Jan Beulich
2020-10-30 10:44       ` Julien Grall
2020-10-20 14:09 ` [PATCH v2 3/8] evtchn: rename and adjust guest_enabled_event() Jan Beulich
2020-10-22 10:28   ` Roger Pau Monné
2020-10-20 14:09 ` [PATCH v2 4/8] evtchn: let evtchn_set_priority() acquire the per-channel lock Jan Beulich
2020-10-22 11:17   ` Roger Pau Monné
2020-10-22 13:34     ` Jan Beulich
2020-10-20 14:10 ` [PATCH v2 5/8] evtchn: drop acquiring of per-channel lock from send_guest_{global,vcpu}_virq() Jan Beulich
2020-10-22 16:00   ` Roger Pau Monné
2020-10-22 16:17     ` Jan Beulich
2020-10-30 10:38       ` Julien Grall
2020-10-30 10:49         ` Jan Beulich
2020-10-30 10:57           ` Julien Grall
2020-10-30 11:15             ` Jürgen Groß
2020-10-30 11:55               ` Jan Beulich
2020-10-30 12:27                 ` Jürgen Groß
2020-10-30 12:52                   ` Jan Beulich
2020-10-30 13:02                     ` Jürgen Groß
2020-10-30 13:38                       ` Jan Beulich
2020-10-30 13:43                         ` Jürgen Groß
2020-10-20 14:10 ` [PATCH v2 6/8] evtchn: convert vIRQ lock to an r/w one Jan Beulich
2020-10-30 10:57   ` Julien Grall
2020-10-30 12:00     ` Jan Beulich [this message]
2020-10-30 12:08       ` Julien Grall
2020-10-30 12:25         ` Jan Beulich
2020-10-30 12:46           ` Julien Grall
2020-10-20 14:11 ` [PATCH v2 7/8] evtchn: convert domain event " Jan Beulich
2020-10-20 14:13 ` [PATCH RFC v2 8/8] evtchn: don't call Xen consumer callback with per-channel lock held Jan Beulich
2020-11-03 10:17   ` Isaila Alexandru
2020-11-03 14:54     ` Tamas K Lengyel

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=33ff45e9-d869-9262-29e0-fa66e3ffb726@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --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.