linux-kernel - Re: [PATCH] ufs: Fix build errors on 32 bit machines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 17 Jun 2017 19:51:40 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Evgeniy Dushistov <dushistov@...l.ru>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] ufs: Fix build errors on 32 bit machines

On Sat, Jun 17, 2017 at 07:23:28PM +0100, Al Viro wrote:
> On Sat, Jun 17, 2017 at 10:35:13AM -0700, Guenter Roeck wrote:
> > Various 32 builds fail with error messages such as
> > 
> > ERROR: "__udivdi3" [fs/ufs/ufs.ko] undefined!
> > 
> > due to a variable type change from 32 bit to 64 bit.
> 
> Actually, that's not the only problem in that place.  The breakage
> came in 2.4.14.7; the critical part was this:
[snip]

Some background: there are two possible allocation policies for the
bad case of tail unpacking.  If a small (less than 192K, on typical
ufs1) file has the last block packed along with those of other files
and we can't just expand that tail in place, we need to find a place
for longer tail somewhere and copy the old data over there.

First policy: try and put it into a block already containing tail(s).
Kinder on space, higher odds of having to do relocation the next time
that tail needs to grow.  That's what OPTSPACE is.

Second policy: pick a free block and put the expanded tail there.
Better chance of being able to expand in place when/if the tail needs
to grow again, harsher on space.  That's OPTTIME.

The choice between those is controlled by the amount of space left
in partially filled blocks.  If it's high, we need to go for OPTSPACE,
if it's low - OPTTIME.  Cutoff values depend upon the amount of
space reserved for root; for 5% (default) it's "go for OPTSPACE when
more than 3% of total space are taken by free space in partially
filled blocks, go for OPTTIME when fragmentation is less than 2.5%,
stay with the previous state when it's between 2.5% and 3%".

(Christoph's?) typo in 2.4.14.7 has broken the switch from OPTTIME to
OPTSPACE; once in OPTTIME it's stuck in OPTTIME.