| Message ID | 20240124091527.8469-1-caoqq@fujitsu.com |
|---|---|
| State | Accepted |
| Commit | d76779dd3681c01a4c6c3cae4d0627c9083e0ee6 |
| Headers | show |
| Series | cxl/region：Fix overflow issue in alloc_hpa() | expand |
On Wed, Jan 24, 2024 at 05:15:26PM +0800, Quanquan Cao wrote: > Creating a region with 16 memory devices caused a problem. The div_u64_rem > function, used for dividing an unsigned 64-bit number by a 32-bit one, > faced an issue when SZ_256M * p->interleave_ways. The result surpassed > the maximum limit of the 32-bit divisor (4G), leading to an overflow > and a remainder of 0. > note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G > > To fix this issue, I replaced the div_u64_rem function with div64_u64_rem > and adjusted the type of the remainder. > > Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> > --- > drivers/cxl/core/region.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c > index 0f05692bfec3..ce0e2d82bb2b 100644 > --- a/drivers/cxl/core/region.c > +++ b/drivers/cxl/core/region.c > @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); > struct cxl_region_params *p = &cxlr->params; > struct resource *res; > - u32 remainder = 0; > + u64 remainder = 0; > > lockdep_assert_held_write(&cxl_region_rwsem); > > @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) > return -ENXIO; > > - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); > + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); > if (remainder) > return -EINVAL; > Make sense to me. Fan > -- > 2.43.0 >
On 1/24/24 02:15, Quanquan Cao wrote: > Creating a region with 16 memory devices caused a problem. The div_u64_rem > function, used for dividing an unsigned 64-bit number by a 32-bit one, > faced an issue when SZ_256M * p->interleave_ways. The result surpassed > the maximum limit of the 32-bit divisor (4G), leading to an overflow > and a remainder of 0. > note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G > > To fix this issue, I replaced the div_u64_rem function with div64_u64_rem > and adjusted the type of the remainder. > > Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> > --- > drivers/cxl/core/region.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c > index 0f05692bfec3..ce0e2d82bb2b 100644 > --- a/drivers/cxl/core/region.c > +++ b/drivers/cxl/core/region.c > @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); > struct cxl_region_params *p = &cxlr->params; > struct resource *res; > - u32 remainder = 0; > + u64 remainder = 0; > > lockdep_assert_held_write(&cxl_region_rwsem); > > @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) > return -ENXIO; > > - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); > + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); > if (remainder) > return -EINVAL; >
On Wed, 24 Jan 2024 17:15:26 +0800 Quanquan Cao <caoqq@fujitsu.com> wrote: > Creating a region with 16 memory devices caused a problem. The div_u64_rem > function, used for dividing an unsigned 64-bit number by a 32-bit one, > faced an issue when SZ_256M * p->interleave_ways. The result surpassed > the maximum limit of the 32-bit divisor (4G), leading to an overflow > and a remainder of 0. > note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G > > To fix this issue, I replaced the div_u64_rem function with div64_u64_rem > and adjusted the type of the remainder. > > Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> Good find, though now I'm curious on whether you have a real system doing 16 way interleave :) Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > --- > drivers/cxl/core/region.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c > index 0f05692bfec3..ce0e2d82bb2b 100644 > --- a/drivers/cxl/core/region.c > +++ b/drivers/cxl/core/region.c > @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); > struct cxl_region_params *p = &cxlr->params; > struct resource *res; > - u32 remainder = 0; > + u64 remainder = 0; > > lockdep_assert_held_write(&cxl_region_rwsem); > > @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) > return -ENXIO; > > - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); > + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); > if (remainder) > return -EINVAL; >
On Wed, Jan 24, 2024 at 05:15:26PM +0800, Quanquan Cao wrote: > Creating a region with 16 memory devices caused a problem. The div_u64_rem > function, used for dividing an unsigned 64-bit number by a 32-bit one, > faced an issue when SZ_256M * p->interleave_ways. The result surpassed > the maximum limit of the 32-bit divisor (4G), leading to an overflow > and a remainder of 0. > note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G > > To fix this issue, I replaced the div_u64_rem function with div64_u64_rem > and adjusted the type of the remainder. Good find! Should this have a Fixes Tag? Reviewed-by: Alison Schofield <alison.schofield@intel.com> > > Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> > --- > drivers/cxl/core/region.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c > index 0f05692bfec3..ce0e2d82bb2b 100644 > --- a/drivers/cxl/core/region.c > +++ b/drivers/cxl/core/region.c > @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); > struct cxl_region_params *p = &cxlr->params; > struct resource *res; > - u32 remainder = 0; > + u64 remainder = 0; > > lockdep_assert_held_write(&cxl_region_rwsem); > > @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) > (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) > return -ENXIO; > > - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); > + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); > if (remainder) > return -EINVAL; > > -- > 2.43.0 > >
在 2024/1/27 1:42, Jonathan Cameron 写道: > On Wed, 24 Jan 2024 17:15:26 +0800 > Quanquan Cao <caoqq@fujitsu.com> wrote: > >> Creating a region with 16 memory devices caused a problem. The div_u64_rem >> function, used for dividing an unsigned 64-bit number by a 32-bit one, >> faced an issue when SZ_256M * p->interleave_ways. The result surpassed >> the maximum limit of the 32-bit divisor (4G), leading to an overflow >> and a remainder of 0. >> note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G >> >> To fix this issue, I replaced the div_u64_rem function with div64_u64_rem >> and adjusted the type of the remainder. >> >> Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> > Good find, though now I'm curious on whether you have a real system doing > 16 way interleave :) Yes, currently the specification is 8, and 16 will be the maximum value. > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> >> --- >> drivers/cxl/core/region.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c >> index 0f05692bfec3..ce0e2d82bb2b 100644 >> --- a/drivers/cxl/core/region.c >> +++ b/drivers/cxl/core/region.c >> @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) >> struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); >> struct cxl_region_params *p = &cxlr->params; >> struct resource *res; >> - u32 remainder = 0; >> + u64 remainder = 0; >> >> lockdep_assert_held_write(&cxl_region_rwsem); >> >> @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) >> (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) >> return -ENXIO; >> >> - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); >> + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); >> if (remainder) >> return -EINVAL; >> >
diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index 0f05692bfec3..ce0e2d82bb2b 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -525,7 +525,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) struct cxl_root_decoder *cxlrd = to_cxl_root_decoder(cxlr->dev.parent); struct cxl_region_params *p = &cxlr->params; struct resource *res; - u32 remainder = 0; + u64 remainder = 0; lockdep_assert_held_write(&cxl_region_rwsem); @@ -545,7 +545,7 @@ static int alloc_hpa(struct cxl_region *cxlr, resource_size_t size) (cxlr->mode == CXL_DECODER_PMEM && uuid_is_null(&p->uuid))) return -ENXIO; - div_u64_rem(size, SZ_256M * p->interleave_ways, &remainder); + div64_u64_rem(size, (u64)SZ_256M * p->interleave_ways, &remainder); if (remainder) return -EINVAL;
Creating a region with 16 memory devices caused a problem. The div_u64_rem function, used for dividing an unsigned 64-bit number by a 32-bit one, faced an issue when SZ_256M * p->interleave_ways. The result surpassed the maximum limit of the 32-bit divisor (4G), leading to an overflow and a remainder of 0. note: At this point, p->interleave_ways is 16, meaning 16 * 256M = 4G To fix this issue, I replaced the div_u64_rem function with div64_u64_rem and adjusted the type of the remainder. Signed-off-by: Quanquan Cao <caoqq@fujitsu.com> --- drivers/cxl/core/region.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)