Re: Mount error on 32 bits, ok on 64 bits

2017-10-02 Thread Jean-Denis Girard
Le 02/10/2017 à 11:46, Goffredo Baroncelli a écrit :
> On 10/02/2017 07:59 PM, Jean-Denis Girard wrote:
>> Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit :
>>> Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit :
>>> The problem seems to come from commit c821e7f3 "pass bytes to
>>> btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the
>>> system is now running fine on 4.13.4 with only that patch reverted.
>>
>> Same situation with 4.14-rc3: my system cannot mount root file-system.
>> If I revert the patch, the system boots normally. This is 100%
>> reproducible. How can I help resolve that issue?
> 
> 
> Looking at the patch, it seems suspect this chunk:
> 
> @@ -2798,7 +2798,7 @@  static int submit_extent_page(int op, int op_flags, 
> struct extent_io_tree *tree,
>   }
>   }
>  
> - bio = btrfs_bio_alloc(bdev, sector);
> + bio = btrfs_bio_alloc(bdev, sector << 9);
>   bio_add_page(bio, page, page_size, offset);
>   bio->bi_end_io = end_io_func;
>   bio->bi_private = tree;
> 
> Now sector, is defined as
> 
>   sector_t   [1]
> 
> which in turn it might be defined as 
> 
>   unsigned long   [2]
> 
> which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == 
> Support for large (2TB+) block devices and files)
> 
> The point is that 
> 
>   sector << 9 
> 
> may overflow if the disk is bigger than 4GB (and in your case it seems to be 
> 8 GB).
> 
> If I am correct, could you please so kindly to 
> 
> - repllay the patch
> - AND try to replace
>   bio = btrfs_bio_alloc(bdev, sector << 9);
> with
>   bio = btrfs_bio_alloc(bdev, (u64)sector << 9);

Hi Goffredo,

Thanks for your reply, analysis and correction: it does work, tested on
4.13-rc3, my system boots fine.


Best regards,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Mount error on 32 bits, ok on 64 bits

2017-10-02 Thread Goffredo Baroncelli
On 10/02/2017 11:46 PM, Goffredo Baroncelli wrote:
> which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == 
> Support for large (2TB+) block devices and files)

Only now I noticed that in the first email you attached the config; in fact in 
your config CONFIG_LBDAF is not set.

BR
G.Baroncelli
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Mount error on 32 bits, ok on 64 bits

2017-10-02 Thread Goffredo Baroncelli
On 10/02/2017 07:59 PM, Jean-Denis Girard wrote:
> Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit :
>> Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit :
>> The problem seems to come from commit c821e7f3 "pass bytes to
>> btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the
>> system is now running fine on 4.13.4 with only that patch reverted.
> 
> Same situation with 4.14-rc3: my system cannot mount root file-system.
> If I revert the patch, the system boots normally. This is 100%
> reproducible. How can I help resolve that issue?


Looking at the patch, it seems suspect this chunk:

@@ -2798,7 +2798,7 @@  static int submit_extent_page(int op, int op_flags, 
struct extent_io_tree *tree,
}
}
 
-   bio = btrfs_bio_alloc(bdev, sector);
+   bio = btrfs_bio_alloc(bdev, sector << 9);
bio_add_page(bio, page, page_size, offset);
bio->bi_end_io = end_io_func;
bio->bi_private = tree;

Now sector, is defined as

sector_t   [1]

which in turn it might be defined as 

unsigned long   [2]

which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == 
Support for large (2TB+) block devices and files)

The point is that 

sector << 9 

may overflow if the disk is bigger than 4GB (and in your case it seems to be 8 
GB).

If I am correct, could you please so kindly to 

- repllay the patch
- AND try to replace
bio = btrfs_bio_alloc(bdev, sector << 9);
with
bio = btrfs_bio_alloc(bdev, (u64)sector << 9);


[1] 
http://elixir.free-electrons.com/linux/latest/source/fs/btrfs/extent_io.c#L2762
[2] 
http://elixir.free-electrons.com/linux/latest/source/include/linux/types.h#L133
> 
> 
> Thanks,
> 
BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Mount error on 32 bits, ok on 64 bits

2017-10-02 Thread Jean-Denis Girard
Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit :
> Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit :
> The problem seems to come from commit c821e7f3 "pass bytes to
> btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the
> system is now running fine on 4.13.4 with only that patch reverted.

Same situation with 4.14-rc3: my system cannot mount root file-system.
If I revert the patch, the system boots normally. This is 100%
reproducible. How can I help resolve that issue?


Thanks,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Mount error on 32 bits, ok on 64 bits

2017-09-30 Thread Jean-Denis Girard
Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit :
> Le 28/09/2017 à 15:29, Jean-Denis Girard a écrit :
> FWIW, kernels up to 4.12.14 are ok, and 4.13-rc1 has the same probem.
> Which patches should I try to reverse first?

The problem seems to come from commit c821e7f3 "pass bytes to
btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the
system is now running fine on 4.13.4 with only that patch reverted.


Thanks,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Mount error on 32 bits, ok on 64 bits

2017-09-28 Thread Jean-Denis Girard
Le 28/09/2017 à 15:29, Jean-Denis Girard a écrit :
> Hi list,
> 
> I have an Alix motherboard with a SD card using btrfs running fine since
> 2010. Today, I wanted to upgrade to kernel 4.13.4 from 4.9.52 (i586). As
> always, I cross-compiled from my main system, installed on Alix, but
> boot failed while trying to mount root: "BTRFS critical (device sda1):
> unable to find logical 1740640256 length 4096".
> 
> Rebooting to 4.9.52 on the Alix works just fine. Btrfs scrub returns no
> error.

FWIW, kernels up to 4.12.14 are ok, and 4.13-rc1 has the same probem.
Which patches should I try to reverse first?


Thanks,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Mount error on 32 bits, ok on 64 bits

2017-09-28 Thread Jean-Denis Girard
Hi list,

I have an Alix motherboard with a SD card using btrfs running fine since
2010. Today, I wanted to upgrade to kernel 4.13.4 from 4.9.52 (i586). As
always, I cross-compiled from my main system, installed on Alix, but
boot failed while trying to mount root: "BTRFS critical (device sda1):
unable to find logical 1740640256 length 4096".

Rebooting to 4.9.52 on the Alix works just fine. Btrfs scrub returns no
error.

Then I took off the SD card, and plugged it in my Intel desktop (running
with kernel 4.13.3-x86_64), and ran a check: no errors were reported. I
was also able to mount the file-system on that other system without
trouble. I mounted with clear_cache, just in case, but it still it would
not mount on the Alix system with kernel 4.13.

One obvious different the 2 systems is 32 / 64 bits. Is this a known
problem? How can I help to fix it? My Alix kernel config is attached

Check and mount on the Intel system:

[jdg@tiare linux]$ uname -a
Linux tiare.sysnux.pf 4.13.3-snx #2 SMP Wed Sep 20 09:09:58 -10 2017
x86_64 x86_64 x86_64 GNU/Linux

[jdg@tiare ~]$ sudo btrfs check /dev/sdd1
Checking filesystem on /dev/sdd1
UUID: 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 598966272 bytes used, no error found
total csum bytes: 545176
total tree bytes: 40312832
total fs tree bytes: 36491264
total extent tree bytes: 2760704
btree space waste bytes: 10016852
file data blocks allocated: 558653440
referenced 987086848

 BTRFS: device fsid 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 devid 1 transid
1982285 /dev/sdd1
 BTRFS info (device sdd1): force clearing of disk cache
 BTRFS info (device sdd1): disk space caching is enabled
 BTRFS info (device sdd1): has skinny extents
 BTRFS info (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0,
corrupt 4, gen 0
 BTRFS info (device sdd1): checking UUID tree


Info from the running Alix system:

jdg@gw:~$ uname -a
Linux gw.sysnux.pf 4.9.52-sysnux-ix100 #1 Thu Sep 28 12:49:53 -10 2017
i586 GNU/Linux

jdg@gw:~$ sudo btrfs scrub start -B /
scrub done for 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8
scrub started at Thu Sep 28 14:48:17 2017 and finished after
00:00:30
total bytes scrubbed: 570.76MiB with 0 errors
jdg@gw:~$ sudo btrfs dev stats /
[/dev/sda1].write_io_errs0
[/dev/sda1].read_io_errs 0
[/dev/sda1].flush_io_errs0
[/dev/sda1].corruption_errs  4
[/dev/sda1].generation_errs  0


Boot failure on Alix with 4.13.4:

 Btrfs loaded, crc32c=crc32c-generic
 ata1.00: CFA: SanDisk SDCFH-008G, HDX 6.03, max UDMA/66
 ata1.00: 15625216 sectors, multi 0: LBA48  
 ata1.00: limited to UDMA/33 due to 40-wire cable
 ata1.00: configured for UDMA/33
 scsi 0:0:0:0: Direct-Access ATA  SanDisk SDCFH-00 6.03 PQ: 0
ANSI: 5
 sd 0:0:0:0: [sda] 15625216 512-byte logical blocks: (8.00 GB/7.45 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
  sda: sda1
 sd 0:0:0:0: [sda] Attached SCSI removable disk
 BTRFS: device fsid 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 devid 1 transid
1982236 /dev/root
 BTRFS info (device sda1): disk space caching is enabled
 BTRFS info (device sda1): has skinny extents
 BTRFS critical (device sda1): unable to find logical 1740640256 length
4096
 BTRFS error (device sda1): failed to read chunk root
 BTRFS error (device sda1): open_ctree failed
 List of all partitions:
 0800 7812608 sda  
  driver: sd
   0801 2097152 sda1 -01
  
 No filesystem could mount root, tried:  
  btrfs
  
 Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(8,1)


Thanks,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.13.4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2