Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1668378 > unrolled thread

[PATCH] ufs: Fix build errors on 32 bit machines

Started byGuenter Roeck <linux@roeck-us.net>
First post2017-06-17 19:40 +0200
Last post2017-06-18 11:40 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] ufs: Fix build errors on 32 bit machines Guenter Roeck <linux@roeck-us.net> - 2017-06-17 19:40 +0200
    Re: [PATCH] ufs: Fix build errors on 32 bit machines Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-17 20:30 +0200
      Re: [PATCH] ufs: Fix build errors on 32 bit machines Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-17 21:00 +0200
      Re: [PATCH] ufs: Fix build errors on 32 bit machines Guenter Roeck <linux@roeck-us.net> - 2017-06-18 11:40 +0200

#1668378 — [PATCH] ufs: Fix build errors on 32 bit machines

FromGuenter Roeck <linux@roeck-us.net>
Date2017-06-17 19:40 +0200
Subject[PATCH] ufs: Fix build errors on 32 bit machines
Message-ID<tTpRv-1Ui-9@gated-at.bofh.it>
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.

Fixes: c596961d1b4c ("ufs: fix s_size/s_dsize users")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
 fs/ufs/balloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/ufs/balloc.c b/fs/ufs/balloc.c
index 0315fea1d589..a93121873fa6 100644
--- a/fs/ufs/balloc.c
+++ b/fs/ufs/balloc.c
@@ -459,7 +459,7 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 fragment,
 	    case UFS_OPTSPACE:
 		request = newcount;
 		if (uspi->s_minfree < 5 || uspi->cs_total.cs_nffree
-		    > uspi->s_dsize * uspi->s_minfree / (2 * 100))
+		    > div_u64(uspi->s_dsize * uspi->s_minfree, 2 * 100))
 			break;
 		usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
 		break;
@@ -468,8 +468,8 @@ u64 ufs_new_fragments(struct inode *inode, void *p, u64 fragment,
 	
 	    case UFS_OPTTIME:
 		request = uspi->s_fpb;
-		if (uspi->cs_total.cs_nffree < uspi->s_dsize *
-		    (uspi->s_minfree - 2) / 100)
+		if (uspi->cs_total.cs_nffree <
+		    div_u64(uspi->s_dsize * (uspi->s_minfree - 2), 100))
 			break;
 		usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
 		break;
-- 
2.7.4

[toc] | [next] | [standalone]


#1668386

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2017-06-17 20:30 +0200
Message-ID<tTqDT-2ud-5@gated-at.bofh.it>
In reply to#1668378
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:
            default:
-               usb1->fs_optim = SWAB32(UFS_OPTTIME);
+               usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
        
            case UFS_OPTTIME:
                request = uspi->s_fpb;
-               if (SWAB32(usb1->fs_cstotal.cs_nffree) < uspi->s_dsize *
+               if (fs32_to_cpu(sb, usb1->fs_cstotal.cs_nffree) < uspi->s_dsize *
                    (uspi->s_minfree - 2) / 100)
                        break;
-               usb1->fs_optim = SWAB32(UFS_OPTSPACE);
+               usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
                break;

See the problem?  Instead of hysteresis loop flipping between optspace and opttime
allocation policies, it *never* switches out of opttime.

That came in

commit 6293d56ca18db9ed322b2a5550ac7b27bd538cff
Author: Linus Torvalds <torvalds@athlon.transmeta.com>
Date:   Mon Feb 4 20:33:51 2002 -0800

    v2.4.14.6 -> v2.4.14.7
    
      - Jeff Garzik: network driver updates
      - Christoph Hellwig: UFS filesystem byteorder cleanups
      - me: modified Andrea VM page allocator tuning

so probably a typo in Christoph's patches, missed by everyone at the time.

And I would prefer to have the nffree levels at which we switch back and
forth precalculated at mount time.  I'll send a fix (along with those
for the last remaining xfstests failures) later today.

[toc] | [prev] | [next] | [standalone]


#1668388

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2017-06-17 21:00 +0200
Message-ID<tTr6V-2I9-7@gated-at.bofh.it>
In reply to#1668386
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.

[toc] | [prev] | [next] | [standalone]


#1668570

FromGuenter Roeck <linux@roeck-us.net>
Date2017-06-18 11:40 +0200
Message-ID<tTEQy-3lF-13@gated-at.bofh.it>
In reply to#1668386
On 06/17/2017 11:23 AM, 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:
>              default:
> -               usb1->fs_optim = SWAB32(UFS_OPTTIME);
> +               usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
>          
>              case UFS_OPTTIME:
>                  request = uspi->s_fpb;
> -               if (SWAB32(usb1->fs_cstotal.cs_nffree) < uspi->s_dsize *
> +               if (fs32_to_cpu(sb, usb1->fs_cstotal.cs_nffree) < uspi->s_dsize *
>                      (uspi->s_minfree - 2) / 100)
>                          break;
> -               usb1->fs_optim = SWAB32(UFS_OPTSPACE);
> +               usb1->fs_optim = cpu_to_fs32(sb, UFS_OPTTIME);
>                  break;
> 
> See the problem?  Instead of hysteresis loop flipping between optspace and opttime
> allocation policies, it *never* switches out of opttime.
> 
Yes. Nice catch.

> That came in
> 
> commit 6293d56ca18db9ed322b2a5550ac7b27bd538cff
> Author: Linus Torvalds <torvalds@athlon.transmeta.com>
> Date:   Mon Feb 4 20:33:51 2002 -0800
> 
>      v2.4.14.6 -> v2.4.14.7
>      
>        - Jeff Garzik: network driver updates
>        - Christoph Hellwig: UFS filesystem byteorder cleanups
>        - me: modified Andrea VM page allocator tuning
> 
> so probably a typo in Christoph's patches, missed by everyone at the time.
> 
> And I would prefer to have the nffree levels at which we switch back and
> forth precalculated at mount time.  I'll send a fix (along with those
> for the last remaining xfstests failures) later today.
> 

Agreed, but wouldn't it be more important to get the code to compile for now ?
After all, optimizing the calculation is an enhancement, not a bug fix.

Thanks,
Guenter

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web