On Fri, Jun 11, 2021 at 08:55:24AM +0200, Geert Uytterhoeven wrote:
> Hi Dave,
>
> On Fri, Jun 11, 2021 at 12:02 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > On Thu, Jun 10, 2021 at 01:00:01PM +0200, Geert Uytterhoeven wrote:
> > > On 32-bit (e.g. m68k):
> > >
> > > ERROR: modpost: "__udivdi3" [fs/xfs/xfs.ko] undefined!
> > >
> > > Fix this by using a uint32_t intermediate, like before.
> > >
> > > Reported-by: noreply@xxxxxxxxxxxxxx
> > > Fixes: 7660a5b48fbef958 ("xfs: log stripe roundoff is a property of the log")
> > > Signed-off-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> > > ---
> > > Compile-tested only.
> > > ---
> > > fs/xfs/xfs_log.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > <sigh>
> >
> > 64 bit division on 32 bit platforms is still a problem in this day
> > and age?
>
> They're not a problem. But you should use the right operations from
> <linux/math64.h>, iff you really need these expensive operations.
See, that's the whole problem. This *isn't* obviously a 64 bit
division - BBTOB is shifting the variable down by 9 (bytes to blocks)
and then using that as the divisor.
The problem is that BBTOB has an internal cast to a 64 bit size,
and roundup() just blindly takes it and hence we get non-obvious
compile errors only on 32 bit platforms.
We have type checking macros for all sorts of generic functionality
- why haven't these generic macros that do division also have type
checking to catch this? i.e. so that when people build kernels on
64 bit machines find out that they've unwittingly broken 32 bit
builds the moment they use roundup() and/or friends incorrectly?
That would save a lot of extra work having fix crap like this up
after the fact...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
