On 11/01/2018 04:57 PM, Will Deacon wrote:
> [ Nit: Please wrap your lines when replying -- I've done it for you here ]
>
> On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 08:14 PM, John Garry wrote:
>>> I think we should either factor out the sanity
On 11/01/2018 04:57 PM, Will Deacon wrote:
> [ Nit: Please wrap your lines when replying -- I've done it for you here ]
>
> On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 08:14 PM, John Garry wrote:
>>> I think we should either factor out the sanity
Agreed. slit_valid() on the ACPI parsing is currently enforcing that before
acpi_numa_slit_init() which would call into numa_set_distance(). Hence arch
NUMA code numa_set_distance() never had the opportunity to do the sanity
checks as ACPI slit_valid() has completely invalidated the table.
Agreed. slit_valid() on the ACPI parsing is currently enforcing that before
acpi_numa_slit_init() which would call into numa_set_distance(). Hence arch
NUMA code numa_set_distance() never had the opportunity to do the sanity
checks as ACPI slit_valid() has completely invalidated the table.
[ Nit: Please wrap your lines when replying -- I've done it for you here ]
On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
> On 10/29/2018 08:14 PM, John Garry wrote:
> > I think we should either factor out the sanity check
> >> into a core helper or make the core code
[ Nit: Please wrap your lines when replying -- I've done it for you here ]
On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
> On 10/29/2018 08:14 PM, John Garry wrote:
> > I think we should either factor out the sanity check
> >> into a core helper or make the core code
On 10/29/2018 08:18 PM, Will Deacon wrote:
> On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 06:02 PM, John Garry wrote:
>>> On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25,
On 10/29/2018 08:18 PM, Will Deacon wrote:
> On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
>> On 10/29/2018 06:02 PM, John Garry wrote:
>>> On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25,
On 10/29/2018 08:14 PM, John Garry wrote:
>
> I think we should either factor out the sanity check
>> into a core helper or make the core code robust to these funny
>> configurations.
>
> OK, so to me it would make sense to factor out a sanity check into a core
>
On 10/29/2018 08:14 PM, John Garry wrote:
>
> I think we should either factor out the sanity check
>> into a core helper or make the core code robust to these funny
>> configurations.
>
> OK, so to me it would make sense to factor out a sanity check into a core
>
On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
> On 10/29/2018 06:02 PM, John Garry wrote:
> > On 29/10/2018 12:16, Will Deacon wrote:
> >> On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> >>> On 29/10/2018 11:25, Will Deacon wrote:
> On Fri, Oct 26, 2018 at
On Mon, Oct 29, 2018 at 06:15:42PM +0530, Anshuman Khandual wrote:
> On 10/29/2018 06:02 PM, John Garry wrote:
> > On 29/10/2018 12:16, Will Deacon wrote:
> >> On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> >>> On 29/10/2018 11:25, Will Deacon wrote:
> On Fri, Oct 26, 2018 at
I think we should either factor out the sanity check
into a core helper or make the core code robust to these funny configurations.
OK, so to me it would make sense to factor out a sanity check into a core
helper.
That, or have the OF code perform the same validation that slit_valid() is
I think we should either factor out the sanity check
into a core helper or make the core code robust to these funny configurations.
OK, so to me it would make sense to factor out a sanity check into a core
helper.
That, or have the OF code perform the same validation that slit_valid() is
On 10/29/2018 06:02 PM, John Garry wrote:
> On 29/10/2018 12:16, Will Deacon wrote:
>> On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
>>> On 29/10/2018 11:25, Will Deacon wrote:
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> Currently it is acceptable to set
On 10/29/2018 06:02 PM, John Garry wrote:
> On 29/10/2018 12:16, Will Deacon wrote:
>> On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
>>> On 29/10/2018 11:25, Will Deacon wrote:
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> Currently it is acceptable to set
On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
On 29/10/2018 11:25, Will Deacon wrote:
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
On 29/10/2018 12:16, Will Deacon wrote:
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
On 29/10/2018 11:25, Will Deacon wrote:
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25, Will Deacon wrote:
> >On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> >>Currently it is acceptable to set the distance between 2 separate nodes to
> >>LOCAL_DISTANCE.
> >>
> >>Reject this as it is
On Mon, Oct 29, 2018 at 12:14:09PM +, John Garry wrote:
> On 29/10/2018 11:25, Will Deacon wrote:
> >On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> >>Currently it is acceptable to set the distance between 2 separate nodes to
> >>LOCAL_DISTANCE.
> >>
> >>Reject this as it is
On 29/10/2018 11:25, Will Deacon wrote:
Hi John,
Hi Will,
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
Reject this as it is invalid.
This change avoids a crash reported in [1].
[1]
On 29/10/2018 11:25, Will Deacon wrote:
Hi John,
Hi Will,
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
Reject this as it is invalid.
This change avoids a crash reported in [1].
[1]
Hi John,
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> Currently it is acceptable to set the distance between 2 separate nodes to
> LOCAL_DISTANCE.
>
> Reject this as it is invalid.
>
> This change avoids a crash reported in [1].
>
> [1]
Hi John,
On Fri, Oct 26, 2018 at 09:57:47PM +0800, John Garry wrote:
> Currently it is acceptable to set the distance between 2 separate nodes to
> LOCAL_DISTANCE.
>
> Reject this as it is invalid.
>
> This change avoids a crash reported in [1].
>
> [1]
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
Reject this as it is invalid.
This change avoids a crash reported in [1].
[1] https://www.spinics.net/lists/arm-kernel/msg683304.html
Signed-off-by: John Garry
diff --git a/arch/arm64/mm/numa.c
Currently it is acceptable to set the distance between 2 separate nodes to
LOCAL_DISTANCE.
Reject this as it is invalid.
This change avoids a crash reported in [1].
[1] https://www.spinics.net/lists/arm-kernel/msg683304.html
Signed-off-by: John Garry
diff --git a/arch/arm64/mm/numa.c
26 matches
Mail list logo