Re: [PATCH] posix-cpu-timers: use u64 multiplication in update_rlimit_cpu()

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng1024@xxxxxxxxx>

* Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> Wouldn't it be more robust to define NSEC_PER_SEC not as 1000000000L,
> but 1000000000LL? (Together with sorting out the inevitable side
> effects.) Ie. in any logic that uses NSEC_PER_SEC multiplication we
> should default to 64-bit arithmetics and not silent truncation to
> 32-bit width. With that we could remove a number of '(u64)' forced
> type conversions as well.

Agreed, that would be a more robust long-term solution.

I tried it locally and did an i386 allmodconfig build to see what falls
out.

The most interesting thing it immediately exposes is a genuine 32-bit
truncation bug: drivers/scsi/lpfc uses

    60 * NSEC_PER_SEC

in an unsigned long, which should be 60000000000 but is silently
truncated to 4165425152 on 32-bit today.

Beyond that, switching NSEC_PER_SEC to LL falls into three classes:

 - ~7 -Wformat fixups where %lu/%ld now receive long long, e.g.
   fs/proc/uptime.c, drivers/ata/libata-transport.c,
   drivers/scsi/scsi_debug.c, i915 backlight, meson-ir-tx.

 - the lpfc-style constant truncation above.

 - the bulk: ~79 files with expressions like x * NSEC_PER_SEC / var.
   These currently stay in 32-bit arithmetic (and silently truncate
   when the product exceeds 32 bits); with LL they become 64-bit
   divisions and pull in __divdi3/__udivdi3, i.e. a link failure on
   32-bit until converted to div_u64()/do_div(). They span drivers/iio,
   spi, pwm, net, mtd, gpu, ... plus a few core files (kernel/time,
   kernel/events, net/core). (i386 only here; arm would add
   __aeabi_ldivmod and possibly more.)

So it's really a multi-subsystem cleanup series rather than a single
macro change. My inclination would be to fix the affected call sites
first (including the truncation cases), then flip NSEC_PER_SEC to LL
once the tree builds cleanly on 32-bit.

The same likely applies to the sibling constants (USEC_PER_SEC,
NSEC_PER_MSEC, ...), so it may be worth treating as a broader cleanup.

Thanks,
  Zhan