[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482af7c4-ad9e-6054-db45-ec05249a2517@oracle.com>
Date: Wed, 11 Aug 2021 11:05:33 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Maximilian Heyne <mheyne@...zon.de>
Cc: Amit Shah <aams@...zon.de>, Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Wei Liu <wei.liu@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jan Beulich <jbeulich@...e.com>,
Malcolm Crossley <malcolm.crossley@...rix.com>,
David Vrabel <david.vrabel@...rix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xen/events: Fix race in set_evtchn_to_irq
On 8/11/21 10:08 AM, Maximilian Heyne wrote:
>
> This patch sets evtchn_to_irq rows via a cmpxchg operation so that they
> will be set only once. Clearing the row was moved up before writing the
> row to evtchn_to_irq in order to not create a race once the row is
> visible for other threads. Accesses to the rows are now guarded by
> READ_ONCE and WRITE_ONCE just as for the columns in the data structure.
Is this last part really needed? We needed to do that for array elements to avoid an interrupt handler from seeing a partially updated entry but I am not sure I see how this can happen to the row pointer. The only place where it might be important is when we update the pointer to the new page but you are using cmpxchg there already.
>
> - evtchn_to_irq[row] = (int *)get_zeroed_page(GFP_KERNEL);
> - if (evtchn_to_irq[row] == NULL)
> + evtchn_row = (int *) get_zeroed_page(GFP_KERNEL);
Not directly related to this patch but I don't think we need to get a zeroed page --- we will initialize it to -1 immediately below.
-boris
Powered by blists - more mailing lists