[<prev] [next>] [day] [month] [year] [list]
Message-ID: <56C1E296.8060602@oracle.com>
Date: Mon, 15 Feb 2016 09:37:10 -0500
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Tommi Airikka <tommi@...ikka.net>, linux-kernel@...r.kernel.org,
xen-devel@...ts.xenproject.org, david.vrabel@...rix.com,
stable@...r.kernel.org
Subject: Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA
locality information was extracted.
On 02/15/2016 09:05 AM, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 13, 2016 at 08:23:14PM -0500, Boris Ostrovsky wrote:
>> On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote:
>>> This patch fixes the issue by:
>>> 1) Use kzalloc to initialize to a well known state.
>>> 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
>>> way access to the 'node' will access the right offset.
>>>
>>> CC: stable@...r.kernel.org
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>
>>
>> (This, btw, is the second time we got bitten by pcifront_sd bit not being
>> pci_sysdata. dc4fdaf0e48 was a workaround for a similar problem and we
>> should have fixed it then).
> I think that the dc4fdaf0e4839109169d8261814813816951c75f commit can be
> reverted then?
>
> Ah no, b/c:
> " Fixes: 97badf873ab6 (device property: Make it possible to use secondary firmware nodes)"
Right --- the problem which that commit fixed was not specific to Xen
but could be observed on ia64 as well.
-boris
Powered by blists - more mailing lists