Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1333388 > unrolled thread

Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

Started byBoris Ostrovsky <boris.ostrovsky@oracle.com>
First post2016-02-14 02:30 +0100
Last post2016-02-15 15:40 +0100
Articles 2 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA  locality information was extracted. Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-14 02:30 +0100
    Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA  locality information was extracted. Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-02-15 15:40 +0100

#1333388 — Re: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-02-14 02:30 +0100
SubjectRe: [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.
Message-ID<r1TFD-4kW-9@gated-at.bofh.it>
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@vger.kernel.org
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.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).

-boris

[toc] | [next] | [standalone]


#1334490

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-02-15 15:40 +0100
Message-ID<r2stI-2fA-25@gated-at.bofh.it>
In reply to#1333388
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@vger.kernel.org
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web