* [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA
2016-06-29 12:16 [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Ian Munsie
@ 2016-06-29 12:16 ` Ian Munsie
2016-06-29 16:06 ` Frederic Barrat
` (2 more replies)
2016-06-29 16:06 ` [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Frederic Barrat
` (2 subsequent siblings)
3 siblings, 3 replies; 8+ messages in thread
From: Ian Munsie @ 2016-06-29 12:16 UTC (permalink / raw)
To: Michael Ellerman, mikey, linuxppc-dev, Frederic Barrat, Huy Nguyen
Cc: Ian Munsie
From: Ian Munsie <imunsie@au1.ibm.com>
The Scheduled Process Area is allocated dynamically with enough pages to
fit at least as many processes as the AFU descriptor indicated. Since
the calculation is non-trivial, it does this by calculating how many
processes could fit in an allocation of a given order, and increasing
that order until it can fit enough processes or hits the maximum
supported size.
Currently, it will start this search using a SPA of 2 pages instead of
1. This can waste a page of memory if the AFU's maximum number of
supported processes was small enough to fit in one page.
Fix the algorithm to start the search at 1 page.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
drivers/misc/cxl/native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index e80d8f7..120c468 100644
--- a/drivers/misc/cxl/native.c
+++ b/drivers/misc/cxl/native.c
@@ -189,7 +189,7 @@ int cxl_alloc_spa(struct cxl_afu *afu)
unsigned spa_size;
/* Work out how many pages to allocate */
- afu->native->spa_order = 0;
+ afu->native->spa_order = -1;
do {
afu->native->spa_order++;
spa_size = (1 << afu->native->spa_order) * PAGE_SIZE;
--
2.8.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA
2016-06-29 12:16 ` [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA Ian Munsie
@ 2016-06-29 16:06 ` Frederic Barrat
2016-06-29 23:07 ` Andrew Donnellan
2016-07-11 10:19 ` [2/2] " Michael Ellerman
2 siblings, 0 replies; 8+ messages in thread
From: Frederic Barrat @ 2016-06-29 16:06 UTC (permalink / raw)
To: Ian Munsie, Michael Ellerman, mikey, linuxppc-dev,
Frederic Barrat, Huy Nguyen
Le 29/06/2016 14:16, Ian Munsie a écrit :
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The Scheduled Process Area is allocated dynamically with enough pages to
> fit at least as many processes as the AFU descriptor indicated. Since
> the calculation is non-trivial, it does this by calculating how many
> processes could fit in an allocation of a given order, and increasing
> that order until it can fit enough processes or hits the maximum
> supported size.
>
> Currently, it will start this search using a SPA of 2 pages instead of
> 1. This can waste a page of memory if the AFU's maximum number of
> supported processes was small enough to fit in one page.
>
> Fix the algorithm to start the search at 1 page.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA
2016-06-29 12:16 ` [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA Ian Munsie
2016-06-29 16:06 ` Frederic Barrat
@ 2016-06-29 23:07 ` Andrew Donnellan
2016-07-11 10:19 ` [2/2] " Michael Ellerman
2 siblings, 0 replies; 8+ messages in thread
From: Andrew Donnellan @ 2016-06-29 23:07 UTC (permalink / raw)
To: Ian Munsie, Michael Ellerman, mikey, linuxppc-dev,
Frederic Barrat, Huy Nguyen
On 29/06/16 22:16, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The Scheduled Process Area is allocated dynamically with enough pages to
> fit at least as many processes as the AFU descriptor indicated. Since
> the calculation is non-trivial, it does this by calculating how many
> processes could fit in an allocation of a given order, and increasing
> that order until it can fit enough processes or hits the maximum
> supported size.
>
> Currently, it will start this search using a SPA of 2 pages instead of
> 1. This can waste a page of memory if the AFU's maximum number of
> supported processes was small enough to fit in one page.
>
> Fix the algorithm to start the search at 1 page.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Makes sense.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [2/2] cxl: Fix allocating a minimum of 2 pages for the SPA
2016-06-29 12:16 ` [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA Ian Munsie
2016-06-29 16:06 ` Frederic Barrat
2016-06-29 23:07 ` Andrew Donnellan
@ 2016-07-11 10:19 ` Michael Ellerman
2 siblings, 0 replies; 8+ messages in thread
From: Michael Ellerman @ 2016-07-11 10:19 UTC (permalink / raw)
To: Ian Munsie, mikey, linuxppc-dev, Frederic Barrat, Huy Nguyen; +Cc: Ian Munsie
On Wed, 2016-29-06 at 12:16:26 UTC, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The Scheduled Process Area is allocated dynamically with enough pages to
> fit at least as many processes as the AFU descriptor indicated. Since
> the calculation is non-trivial, it does this by calculating how many
> processes could fit in an allocation of a given order, and increasing
> that order until it can fit enough processes or hits the maximum
> supported size.
>
> Currently, it will start this search using a SPA of 2 pages instead of
> 1. This can waste a page of memory if the AFU's maximum number of
> supported processes was small enough to fit in one page.
>
> Fix the algorithm to start the search at 1 page.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2224b6719b09052a9fbf29422a
cheers
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes
2016-06-29 12:16 [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Ian Munsie
2016-06-29 12:16 ` [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA Ian Munsie
@ 2016-06-29 16:06 ` Frederic Barrat
2016-06-29 22:35 ` Andrew Donnellan
2016-07-11 10:19 ` [1/2] " Michael Ellerman
3 siblings, 0 replies; 8+ messages in thread
From: Frederic Barrat @ 2016-06-29 16:06 UTC (permalink / raw)
To: Ian Munsie, Michael Ellerman, mikey, linuxppc-dev,
Frederic Barrat, Huy Nguyen
Le 29/06/2016 14:16, Ian Munsie a écrit :
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> If the AFU descriptor of an AFU directed AFU indicates that it supports
> 0 maximum processes, we will accept that value and attempt to use it.
> The SPA will still be allocated (with 2 pages due to another minor bug
> and room for 958 processes), and when a context is allocated we will
> pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will
> treat that as meaning no maximum and will allocate a context number and
> we return a valid context.
>
> Conceivably, this could lead to a buffer overflow of the SPA if more
> than 958 contexts were allocated, however this is mitigated by the fact
> that there are no known AFUs in the wild with a bogus AFU descriptor
> like this, and that only the root user is allowed to flash an AFU image
> to a card.
>
> Add a check when validating the AFU descriptor to reject any with 0
> maximum processes.
>
> We do still allow a dedicated process only AFU to indicate that it
> supports 0 contexts even though that is forbidden in the architecture,
> as in that case we ignore the value and use 1 instead. This is just on
> the off-chance that such a dedicated process AFU may exist (not that I
> am aware of any), since their developers are less likely to have cared
> about this value at all.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes
2016-06-29 12:16 [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Ian Munsie
2016-06-29 12:16 ` [PATCH 2/2] cxl: Fix allocating a minimum of 2 pages for the SPA Ian Munsie
2016-06-29 16:06 ` [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Frederic Barrat
@ 2016-06-29 22:35 ` Andrew Donnellan
2016-07-11 10:19 ` [1/2] " Michael Ellerman
3 siblings, 0 replies; 8+ messages in thread
From: Andrew Donnellan @ 2016-06-29 22:35 UTC (permalink / raw)
To: Ian Munsie, Michael Ellerman, mikey, linuxppc-dev,
Frederic Barrat, Huy Nguyen
On 29/06/16 22:16, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> If the AFU descriptor of an AFU directed AFU indicates that it supports
> 0 maximum processes, we will accept that value and attempt to use it.
> The SPA will still be allocated (with 2 pages due to another minor bug
> and room for 958 processes), and when a context is allocated we will
> pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will
> treat that as meaning no maximum and will allocate a context number and
> we return a valid context.
>
> Conceivably, this could lead to a buffer overflow of the SPA if more
> than 958 contexts were allocated, however this is mitigated by the fact
> that there are no known AFUs in the wild with a bogus AFU descriptor
> like this, and that only the root user is allowed to flash an AFU image
> to a card.
>
> Add a check when validating the AFU descriptor to reject any with 0
> maximum processes.
>
> We do still allow a dedicated process only AFU to indicate that it
> supports 0 contexts even though that is forbidden in the architecture,
> as in that case we ignore the value and use 1 instead. This is just on
> the off-chance that such a dedicated process AFU may exist (not that I
> am aware of any), since their developers are less likely to have cared
> about this value at all.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Looks good to me.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes
2016-06-29 12:16 [PATCH 1/2] cxl: Fix allowing bogus AFU descriptors with 0 maximum processes Ian Munsie
` (2 preceding siblings ...)
2016-06-29 22:35 ` Andrew Donnellan
@ 2016-07-11 10:19 ` Michael Ellerman
3 siblings, 0 replies; 8+ messages in thread
From: Michael Ellerman @ 2016-07-11 10:19 UTC (permalink / raw)
To: Ian Munsie, mikey, linuxppc-dev, Frederic Barrat, Huy Nguyen; +Cc: Ian Munsie
On Wed, 2016-29-06 at 12:16:25 UTC, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> If the AFU descriptor of an AFU directed AFU indicates that it supports
> 0 maximum processes, we will accept that value and attempt to use it.
> The SPA will still be allocated (with 2 pages due to another minor bug
> and room for 958 processes), and when a context is allocated we will
> pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will
> treat that as meaning no maximum and will allocate a context number and
> we return a valid context.
>
> Conceivably, this could lead to a buffer overflow of the SPA if more
> than 958 contexts were allocated, however this is mitigated by the fact
> that there are no known AFUs in the wild with a bogus AFU descriptor
> like this, and that only the root user is allowed to flash an AFU image
> to a card.
>
> Add a check when validating the AFU descriptor to reject any with 0
> maximum processes.
>
> We do still allow a dedicated process only AFU to indicate that it
> supports 0 contexts even though that is forbidden in the architecture,
> as in that case we ignore the value and use 1 instead. This is just on
> the off-chance that such a dedicated process AFU may exist (not that I
> am aware of any), since their developers are less likely to have cared
> about this value at all.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/49e9c99f47fc43abc9598f9fcf
cheers
^ permalink raw reply [flat|nested] 8+ messages in thread