[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27c875fb-9507-4034-8468-c4d46c952754@moroto.mountain>
Date: Thu, 7 Mar 2024 12:17:45 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Zhihao Cheng <chengzhihao1@...wei.com>
Cc: Daniel Golle <daniel@...rotopia.org>,
Richard Weinberger <richard@....at>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Vignesh Raghavendra <vigneshr@...com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
Guenter Roeck <linux@...ck-us.net>,
Daniel Diaz <daniel.diaz@...aro.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>
Subject: Re: [PATCH v2] mtd: ubi: fix NVMEM over UBI volumes on 32-bit systems
On Wed, Feb 28, 2024 at 09:45:13AM +0800, Zhihao Cheng wrote:
> 在 2024/2/28 8:46, Daniel Golle 写道:
> > A compiler warning related to sizeof(int) != 8 when calling do_div()
> > is triggered when building on 32-bit platforms.
> > Address this by using integer types having a well-defined size.
> >
> > Fixes: 3ce485803da1 ("mtd: ubi: provide NVMEM layer over UBI volumes")
> > Signed-off-by: Daniel Golle <daniel@...rotopia.org>
> > ---
> > v2: use size_t for 'bytes_left' variable to match parameter type
> >
> > drivers/mtd/ubi/nvmem.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/ubi/nvmem.c b/drivers/mtd/ubi/nvmem.c
> > index b7a93c495d172..e68b8589c4279 100644
> > --- a/drivers/mtd/ubi/nvmem.c
> > +++ b/drivers/mtd/ubi/nvmem.c
> > @@ -23,9 +23,12 @@ struct ubi_nvmem {
> > static int ubi_nvmem_reg_read(void *priv, unsigned int from,
> > void *val, size_t bytes)
> > {
> > - int err = 0, lnum = from, offs, bytes_left = bytes, to_read;
> > struct ubi_nvmem *unv = priv;
> > struct ubi_volume_desc *desc;
> > + size_t bytes_left = bytes;
> > + uint32_t offs, to_read;
> There still exist a type truncation assignment 'to_read = bytes_left' below,
> although it's safe in logic.
Yeah. As you say, from looking at the logic we know it's safe.
41 if (to_read > bytes_left)
42 to_read = bytes_left;
Obviously the new value is smaller than the original, so it must fit
within a u32 range...
This bug has been breaking the build since Dec 19. It's fine if you're
able to manually create your own .configs to work around build breakage.
But if you're doing automated testing at scale then it's a show stopper.
Could we please fix it.
regards,
dan carpenter
Powered by blists - more mailing lists