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


Groups > linux.kernel > #1619584

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

From Adam Borowski <kilobyte@angband.pl>
Newsgroups linux.kernel
Subject Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division
Date 2017-04-10 03:20 +0200
Message-ID <tuw9P-2ht-3@gated-at.bofh.it> (permalink)
References <tu2EO-8jn-9@gated-at.bofh.it> <tu5Ml-24v-3@gated-at.bofh.it> <tuckN-6mt-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Sun, Apr 09, 2017 at 05:58:54AM +0200, Adam Borowski wrote:
> On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote:
> > Unbreaks ARM and possibly other 32-bit architectures.
> 
> Turns out those "other 32-bit architectures" happen to include i386.
> 
> A modular build:
> ERROR: "__udivdi3" [fs/btrfs/btrfs.ko] undefined!
> With the patch, i386 builds fine.
> 
> > Tested on amd64 where all is fine, and on arm (Odroid-U2) where scrub
> > sometimes works, but, like most operations, randomly dies with some badness
> > that doesn't look related: io_schedule, kunmap_high.  That badness wasn't
> > there in 4.11-rc5, needs investigating, but since it's not connected to our
> > issue at hand, I consider this patch sort-of tested.
> 
> Looks like current -next is pretty broken: while amd64 is ok, on an i386 box
> (non-NX Pentium 4) it hangs very early during boot, way before filesystem
> modules would be loaded.  Qemu boots but has random hangs.

A non-modular i386_defconfig + btrfs of -next is ok; whatever the problem
is, it's not relevant to our division build failure in scrub.

But, it looks like parity scrub is ${EXPLETIVE}ed on 32-bit.  Not just on
-next, also on 4.11-rc5 and 4.9.  Test script I used is attached, although
it's enough to just scrub a kosher filesystem without even damaging it.
On 64-bit it mostly works, but still warns about bogus unrecoverable errors
when in fact it succeeded.

Thus, I'd recommend:
* applying this patch to at least make it compile
* taking steps to warn outside people about RAID5/6

Let's discuss the rest in another thread, it's no longer interesting to ARM
people, they just want no build failures.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Linux next-20170407 failed to build on ARM due to usage of mod in  btrfs code Icenowy Zheng <icenowy@aosc.io> - 2017-04-08 18:10 +0200
  Re: Linux next-20170407 failed to build on ARM due to usage of mod in  btrfs code Fabio Estevam <festevam@gmail.com> - 2017-04-08 19:50 +0200
    Re: Linux next-20170407 failed to build on ARM due to usage of mod  in btrfs code Adam Borowski <kilobyte@angband.pl> - 2017-04-08 20:40 +0200
    [PATCH] btrfs: scrub: use do_div() for 64-by-32 division Adam Borowski <kilobyte@angband.pl> - 2017-04-08 23:10 +0200
      Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division Adam Borowski <kilobyte@angband.pl> - 2017-04-09 06:10 +0200
        Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division Adam Borowski <kilobyte@angband.pl> - 2017-04-10 03:20 +0200
      Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division David Sterba <dsterba@suse.cz> - 2017-04-10 13:20 +0200
      Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2017-04-10 15:00 +0200
      Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division Liu Bo <bo.li.liu@oracle.com> - 2017-04-10 20:50 +0200

csiph-web