Re: ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)

[Al Viro]

On Mon, Jun 19, 2017 at 03:36:47PM +0100, Ian Jackson wrote:
> osstest service owner writes ("[linux-linus bisection] complete build-i386-pvops"):
> > branch xen-unstable
> > xenbranch xen-unstable
> > job build-i386-pvops
> > testid kernel-build
> > 
> > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >   Bug introduced:  edf9364d3f924aff6f77176b8e52a4b68e5c30d6
> >   Bug not present: 791a9a666d1afe2603bcb2c6a4852d684e879252
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110566/
> 
> This is a merge commit, so the bisection result is not very useful:
> 
>    git-log --pretty=oneline 791a9a666d1afe2603bcb2c6a4852d684e879252..edf9364d3f924aff6f77176b8e52a4b68e5c30d6 | wc -l
>    2233
> 
> The error message is this:
> 
>    ERROR: "__udivdi3" [fs/ufs/ufs.ko] undefined!
>    scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>    make[1]: *** [__modpost] Error 1

It's 64bit ->s_dsize going through "multiply by this, divide by 100".
Can be papered over by using mul_64_u32_div() in ufs_new_fragments(),
but
	* expression remains unchanged, so it's better done at
mount time
	* there's a braino (since circa 2002) in the same code
- the expression(s) are for the levels of fragmentation that
trigger switches in hysteresis loop and both switches lead to
the same state due to cut'n'paste damage
	* for really low minfree we get those levels too close
to each other - at minfree 5 we get 0.025 .. 0.03, at minfree 4
they outright merge and below that the upper bound is less than
the lower one.  We'd copied the original 4.4BSD here; at 1995
FreeBSD got switched to "minfree 5 or below means using OPTSPACE
all the time".

Fixed in vfs.git#ufs-fixes; see commit 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1
there.  Not sure if it's worth splitting...