It is spurious to allocate a bitmap for 'num_qpls' bits and record the
size of this bitmap with another value.
'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
'find_[first|next]_zero_bit()'.
So, it looks that memory after the allocated 'qpl_id_map' could be
scanned.
Remove the '* BITS_PER_BYTE' to have allocation and length be the same.
Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
Signed-off-by: Christophe JAILLET <[email protected]>
---
This patch is completely speculative and un-tested!
You'll be warned.
---
drivers/net/ethernet/google/gve/gve_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 7647cd05b1d2..19fe9e9b62f5 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -866,7 +866,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
}
priv->qpl_cfg.qpl_map_size = BITS_TO_LONGS(num_qpls) *
- sizeof(unsigned long) * BITS_PER_BYTE;
+ sizeof(unsigned long);
priv->qpl_cfg.qpl_id_map = kvcalloc(BITS_TO_LONGS(num_qpls),
sizeof(unsigned long), GFP_KERNEL);
if (!priv->qpl_cfg.qpl_id_map) {
--
2.30.2
On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
<[email protected]> wrote:
>
> It is spurious to allocate a bitmap for 'num_qpls' bits and record the
> size of this bitmap with another value.
>
> 'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
> 'find_[first|next]_zero_bit()'.
> So, it looks that memory after the allocated 'qpl_id_map' could be
> scanned.
find_first_zero_bit takes a length argument in bits:
/**
* find_first_zero_bit - find the first cleared bit in a memory region
* @addr: The address to start the search at
* @size: The maximum number of bits to search
qpl_map_size is passed to find_first_zero_bit.
It does seem roundabout to compute first the number of longs needed to
hold num_qpl bits
BITS_TO_LONGS(num_qpls)
then again compute the number of bits in this buffer
* sizeof(unsigned long) * BITS_PER_BYTE
Which will simply be num_qpls again.
But, removing BITS_PER_BYTE does not arrive at the right number.
>
> Remove the '* BITS_PER_BYTE' to have allocation and length be the same.
>
> Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> This patch is completely speculative and un-tested!
> You'll be warned.
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 7647cd05b1d2..19fe9e9b62f5 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -866,7 +866,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
> }
>
> priv->qpl_cfg.qpl_map_size = BITS_TO_LONGS(num_qpls) *
> - sizeof(unsigned long) * BITS_PER_BYTE;
> + sizeof(unsigned long);
> priv->qpl_cfg.qpl_id_map = kvcalloc(BITS_TO_LONGS(num_qpls),
> sizeof(unsigned long), GFP_KERNEL);
> if (!priv->qpl_cfg.qpl_id_map) {
> --
> 2.30.2
>
Le 24/10/2021 à 15:51, Willem de Bruijn a écrit :
> On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
> <[email protected]> wrote:
>>
>> It is spurious to allocate a bitmap for 'num_qpls' bits and record the
>> size of this bitmap with another value.
>>
>> 'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
>> 'find_[first|next]_zero_bit()'.
>> So, it looks that memory after the allocated 'qpl_id_map' could be
>> scanned.
>
> find_first_zero_bit takes a length argument in bits:
>
> /**
> * find_first_zero_bit - find the first cleared bit in a memory region
> * @addr: The address to start the search at
> * @size: The maximum number of bits to search
>
> qpl_map_size is passed to find_first_zero_bit.
>
> It does seem roundabout to compute first the number of longs needed to
> hold num_qpl bits
>
> BITS_TO_LONGS(num_qpls)
>
> then again compute the number of bits in this buffer
>
> * sizeof(unsigned long) * BITS_PER_BYTE
>
> Which will simply be num_qpls again.
>
> But, removing BITS_PER_BYTE does not arrive at the right number.
(* embarrassed *)
So obvious.
Thank you for taking time for the explanation on a so badly broken patch.
I apologize for the noise and the waste of time :(
BTW, why not just have 'priv->qpl_cfg.qpl_map_size = num_qpls;'?
CJ
>
>
>>
>> Remove the '* BITS_PER_BYTE' to have allocation and length be the same.
>>
>> Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
>> Signed-off-by: Christophe JAILLET <[email protected]>
>> ---
>> This patch is completely speculative and un-tested!
>> You'll be warned.
>> ---
>> drivers/net/ethernet/google/gve/gve_main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
>> index 7647cd05b1d2..19fe9e9b62f5 100644
>> --- a/drivers/net/ethernet/google/gve/gve_main.c
>> +++ b/drivers/net/ethernet/google/gve/gve_main.c
>> @@ -866,7 +866,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
>> }
>>
>> priv->qpl_cfg.qpl_map_size = BITS_TO_LONGS(num_qpls) *
>> - sizeof(unsigned long) * BITS_PER_BYTE;
>> + sizeof(unsigned long);
>> priv->qpl_cfg.qpl_id_map = kvcalloc(BITS_TO_LONGS(num_qpls),
>> sizeof(unsigned long), GFP_KERNEL);
>> if (!priv->qpl_cfg.qpl_id_map) {
>> --
>> 2.30.2
>>
>
On Sun, Oct 24, 2021 at 10:58 AM Christophe JAILLET
<[email protected]> wrote:
>
> Le 24/10/2021 à 15:51, Willem de Bruijn a écrit :
> > On Sun, Oct 24, 2021 at 7:52 AM Christophe JAILLET
> > <[email protected]> wrote:
> >>
> >> It is spurious to allocate a bitmap for 'num_qpls' bits and record the
> >> size of this bitmap with another value.
> >>
> >> 'qpl_map_size' is used in 'drivers/net/ethernet/google/gve/gve.h' with
> >> 'find_[first|next]_zero_bit()'.
> >> So, it looks that memory after the allocated 'qpl_id_map' could be
> >> scanned.
> >
> > find_first_zero_bit takes a length argument in bits:
> >
> > /**
> > * find_first_zero_bit - find the first cleared bit in a memory region
> > * @addr: The address to start the search at
> > * @size: The maximum number of bits to search
> >
> > qpl_map_size is passed to find_first_zero_bit.
> >
> > It does seem roundabout to compute first the number of longs needed to
> > hold num_qpl bits
> >
> > BITS_TO_LONGS(num_qpls)
> >
> > then again compute the number of bits in this buffer
> >
> > * sizeof(unsigned long) * BITS_PER_BYTE
> >
> > Which will simply be num_qpls again.
> >
> > But, removing BITS_PER_BYTE does not arrive at the right number.
>
> (* embarrassed *)
>
> So obvious.
> Thank you for taking time for the explanation on a so badly broken patch.
>
> I apologize for the noise and the waste of time :(
No worries, it happens. Thanks for reviewing code.
>
> BTW, why not just have 'priv->qpl_cfg.qpl_map_size = num_qpls;'?
Yes, that seems more straightforward to me too.