Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

BCH_IOCTL_USAGE error: Numerical result out of range #44

Closed
wilson111 opened this issue May 26, 2019 · 5 comments
Closed

BCH_IOCTL_USAGE error: Numerical result out of range #44

wilson111 opened this issue May 26, 2019 · 5 comments

Comments

@wilson111
Copy link

wilson111 commented May 26, 2019 •
edited
Loading

First, thank Kent for writing such promising fs for Linux. I'm a Patreon supporter and I've been testing bcachefs since a year ago. I'm using multiple devices as a backup target filesystem for testing bcachefs (with different Ubuntu distributions). I find that "bcachefs fs usage" command always gives this BCH_IOCTL_USAGE error. Is it normal or something that I did wrong during fs creation?

root@nas2:~# bcachefs format --group hdd /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdi --group ssd /dev/sdj --foreground_target ssd --background_target hdd --promote_target ssd

root@nas2:~# bcachefs fs usage /mnt
BCH_IOCTL_USAGE error: Numerical result out of range

root@nas2:~# bcachefs version
bcachefs tool version v0.1-65-g93bdfcb

root@nas2:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1508708 0 1508708 0% /dev
tmpfs 306944 2580 304364 1% /run
/dev/sda1 60406860 35291088 22024164 62% /
tmpfs 1534712 0 1534712 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 1534712 0 1534712 0% /sys/fs/cgroup
/dev/sdb:/dev/sdc:/dev/sdd:/dev/sde:/dev/sdf:/dev/sdg:/dev/sdi:/dev/sdj 18428465192 7835295628 10593169564 43% /mnt
tmpfs 306940 0 306940 0% /run/user/1000

root@nas2:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic

root@nas2:~# for drive in /dev/sd?; do echo $drive; smartctl -i $drive; done | egrep 'dev|Family|Model|Capacity'
/dev/sda
/dev/sda: Unknown USB bridge [0x0080:0xa001 (0x204)]
Please specify device type with the -d option.
/dev/sdb
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdc
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdd
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sde
Model Family: Hitachi Deskstar 7K3000
Device Model: Hitachi HDS723020BLA642
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdf
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdg
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdh
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST3000DM001-1ER166
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdi
Model Family: Toshiba 3.5" DT01ACA... Desktop HDD
Device Model: TOSHIBA DT01ACA300
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
SMART support is: Available - device has SMART capability.
/dev/sdj
Model Family: Crucial/Micron MX100/MX200/M5x0/M600 Client SSDs
Device Model: Crucial_CT512MX100SSD1
User Capacity: 512,110,190,592 bytes [512 GB]
SMART support is: Available - device has SMART capability.

root@nas2:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 74.5G 0 disk
├─sda1 8:1 0 58.7G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 15.9G 0 part [SWAP]
sdb 8:16 1 2.7T 0 disk /mnt
sdc 8:32 1 2.7T 0 disk
sdd 8:48 1 2.7T 0 disk
sde 8:64 1 1.8T 0 disk
sdf 8:80 1 2.7T 0 disk
sdg 8:96 1 2.7T 0 disk
sdh 8:112 1 2.7T 0 disk
sdi 8:128 1 2.7T 0 disk
sdj 8:144 1 477G 0 disk
@koverstreet
Copy link
Owner

koverstreet commented May 26, 2019 via email

@wilson111
Copy link
Author

root@nas2:~# git clone http://evilpiepirate.org/git/bcachefs-tools.git
Cloning into 'bcachefs-tools'...
warning: redirecting to https://evilpiepirate.org/git/bcachefs-tools.git/
remote: Enumerating objects: 5079, done.
remote: Counting objects: 100% (5079/5079), done.
remote: Compressing objects: 100% (2767/2767), done.
remote: Total 5079 (delta 3839), reused 2994 (delta 2174)
Receiving objects: 100% (5079/5079), 2.70 MiB | 3.01 MiB/s, done.
Resolving deltas: 100% (3839/3839), done.

root@nas2:# cd bcachefs-tools
root@nas2:/bcachefs-tools# ls
bcachefs.8 cmd_attr.c cmd_format.c cmd_migrate.c config.h debian initramfs libbcachefs.h nix README
bcachefs.c cmd_data.c cmd_fs.c cmd_run.c COPYING default.nix INSTALL linux qcow2.c tools-util.
ccan cmd_debug.c cmd_fsck.c cmds.h crypto.c fsck.bcachefs libbcachefs Makefile qcow2.h tools-util.
cmd_assemble.c cmd_device.c cmd_key.c cmd_version.c crypto.h include libbcachefs.c mkfs.bcachefs raid

root@nas2:~/bcachefs-tools# make

root@nas2:/bcachefs-tools# ./bcachefs version
bcachefs tool version v0.1-66-g7e35389
root@nas2:/bcachefs-tools# ./bcachefs fs usage /mnt
BCH_IOCTL_USAGE error: Numerical result out of range

Still not working after a fresh new git clone. Anything else should I look into?

@stintel
Copy link
Contributor

stintel commented Jun 13, 2019

Having the same problem for as long as I can remember. Mentioned it on IRC a few times, first time on 5/10/2018. Can't recall if it ever worked. At some point I suspected it could be related to me using musl libc, but that's a very wild guess.

@koverstreet
Copy link
Owner

Whoops, it was broken for > 4 devices because it was checking for the wrong error code. Fixed now.

@wilson111
Copy link
Author

It works now. Many thanks.

koverstreet pushed a commit that referenced this issue Jun 18, 2023
net/smc: Don't use RMBs not mapped to new link in SMCRv2 ADD LINK
71c6aa0 
We encountered a crash when using SMCRv2. It is caused by a logical
error in smc_llc_fill_ext_v2().

 BUG: kernel NULL pointer dereference, address: 0000000000000014
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 7 PID: 453 Comm: kworker/7:4 Kdump: loaded Tainted: G        W   E      6.4.0-rc3+ #44
 Workqueue: events smc_llc_add_link_work [smc]
 RIP: 0010:smc_llc_fill_ext_v2+0x117/0x280 [smc]
 RSP: 0018:ffffacb5c064bd88 EFLAGS: 00010282
 RAX: ffff9a6bc1c3c02c RBX: ffff9a6be3558000 RCX: 0000000000000000
 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 000000000000000a
 RBP: ffffacb5c064bdb8 R08: 0000000000000040 R09: 000000000000000c
 R10: ffff9a6bc0910300 R11: 0000000000000002 R12: 0000000000000000
 R13: 0000000000000002 R14: ffff9a6bc1c3c02c R15: ffff9a6be3558250
 FS:  0000000000000000(0000) GS:ffff9a6eefdc0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000014 CR3: 000000010b078003 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  <TASK>
  smc_llc_send_add_link+0x1ae/0x2f0 [smc]
  smc_llc_srv_add_link+0x2c9/0x5a0 [smc]
  ? cc_mkenc+0x40/0x60
  smc_llc_add_link_work+0xb8/0x140 [smc]
  process_one_work+0x1e5/0x3f0
  worker_thread+0x4d/0x2f0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xe5/0x120
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x2c/0x50
  </TASK>

When an alernate RNIC is available in system, SMC will try to add a new
link based on the RNIC for resilience. All the RMBs in use will be mapped
to the new link. Then the RMBs' MRs corresponding to the new link will be
filled into SMCRv2 LLC ADD LINK messages.

However, smc_llc_fill_ext_v2() mistakenly accesses to unused RMBs which
haven't been mapped to the new link and have no valid MRs, thus causing
a crash. So this patch fixes the logic.

Fixes: b4ba465 ("net/smc: extend LLC layer for SMC-Rv2")
Signed-off-by: Wen Gu <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
koverstreet pushed a commit that referenced this issue Jul 14, 2024
@floatious
ata: libata-core: Fix null pointer dereference on error
5d92c7c 
If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.

However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:

BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ? __die_body.cold+0x19/0x27
 ? page_fault_oops+0x15a/0x2f0
 ? exc_page_fault+0x7e/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? ata_host_release.cold+0x2f/0x6e [libata]
 ? ata_host_release.cold+0x2f/0x6e [libata]
 release_nodes+0x35/0xb0
 devres_release_group+0x113/0x140
 ata_host_alloc+0xed/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Do not access ata_port struct members unconditionally.

Fixes: 633273a ("libata-pmp: hook PMP support and enable it")
Cc: [email protected]
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Niklas Cassel <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@stintel @koverstreet @wilson111