prior to this patch, on certain platforms (ie: armv7l), compilation fails due
to atomic64_sub_return_release not being defined here. Ensure that the atomics
header is pulled in, and ensure that it is available in all cases, regardless
of whether ATOMIC64_SPINLOCK is defined.
Signed-off-by: Nicholas Sielicki <linux@opensource.nslick.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
libc proper treats mount flags as an unsigned long, which is usually u64,
except when it isn't. When preparing mount flags, use the libc::c_ulong type
instead of u64 to allow for this.
This fixes compiling this file under armv7l.
Signed-off-by: Nicholas Sielicki <linux@opensource.nslick.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Kent Overstreet [Tue, 7 Nov 2023 01:47:48 +0000 (20:47 -0500)]
Avoiding picking different bucket sizes for different devices
Erasure coding can't create stripes across devices with different bucket
sizes - therefore, format shouldn't pick different bucket sizes for
different devices.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Kent Overstreet [Tue, 7 Nov 2023 00:01:15 +0000 (19:01 -0500)]
cmd_format: Check for device options after device arguments
It's a common user error to specify device specific options at the end
of a format command, and then not have them apply to any devices - add a
check for this.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Brian Foster [Tue, 19 Sep 2023 14:26:11 +0000 (10:26 -0400)]
bcachefs-tools: fix endian problems between bit spinlocks and futexes
bcachefs format on a big-endian (s390x) machine crashes down in the
rhashtable code imported from the kernel. The reason this occurs
lies within the rht_lock() -> bit_spin_lock() code, the latter of
which casts bitmaps down to 32-bits to satisfy the requirements of
the futex interface.
The specific problem here is that a 64 -> 32 bit cast doesn't refer
to the lower 8 bytes on a big endian machine, which means setting
bit number 0 in the 32-bit map actually corresponds to bit 32 in the
64-bit map. The rhashtable code specifically uses bit zero of the
bucket pointer for exclusion and uses native bitops elsewhere (i.e.
__rht_ptr()) to identify NULL pointers. If bit 32 of the pointer is
set by the locking code instead of bit 0, an otherwise NULL pointer
looks like a non-NULL value and results in a segfault.
The bit spinlock code imported by the kernel is originally intended
to work with unsigned long. The kernel code is able to throttle the
cpu directly when under lock contention, while the userspace
implementation relies on the futex primitives to emulate reliable
blocking. Since the futex interface introduces the 32-bit
requirement, isolate the associated userspace hack to that
particular code.
Restore the native bitmap behavior of the bit spinlock code to
address the rhashtable problem described above. Since this is not
compatible with the futex interface, create a futex wrapper
specifically to convert the native bitmap type to a 32-bit virtual
address and mask value for the purposes of waiting/waking when under
lock contention.
Signed-off-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Brian Foster [Fri, 15 Sep 2023 13:40:25 +0000 (09:40 -0400)]
libbcachefs: convert sb features mask to little endian
bch_sb.features is an array of __le64. Convert the native endian format
of the features mask appropriately. This causes a bcachefs format to
produce an unmountable fs when run from a big endian system.
Signed-off-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The comman line help claims that `bcachefs mount <DEV>` without a
mount point will do a dry-run mount - all the steps required to
mount the fs, but without actually doing the final real mount.
Make the code actually do this, rather than complain that you
haven't supplied a mountpoint if you don't provide a mountpoint
Signed-off-by: Christopher James Halse Rogers <raof@ubuntu.com>
Colin Gillespie [Sat, 12 Aug 2023 03:50:37 +0000 (13:50 +1000)]
cmd_mount: use the correct keyring key type
Mount is checking for and adding encryption keys using the logon key
type instead of the user key type. This was causing it to not be able to
unlock volumes on its own, and ask for a passphrase on already unlocked
volumes.
Signed-off-by: Colin Gillespie <colin@cgillespie.xyz>
chore(rust): add opt_get! and expose some FMODE_* as Rust const
In an effort to rewrite `bch2_read_super` from C to Rust,
it is neccessary to have `opt_get!` macro defined, and some
FMODE_* consts (defined as macro in `include/linux/blkdev.h`)
defined as Rust const.
Bindgen is currently unable to exapnd C functional macro [1],
this this commit use the workaround as introduced in [2].
feat(cmd_mount): Add support for magic keyword `OLD_BLKID_UUID`
This commit enhances mount sub command by allowing it to accept
`OLD_BLKID_UUID=xxx` as the device, enabling whole fs mounting without relying
on colon-separated devices.
Using colon-separated devices in fstab is discouraged due to potential device
reference issues after reboot. Additionally, using `UUID=xxx` in fstab or with
`mount -t bcachefs` is currently infeasible as it depends on blkid, which prior
to v2.39, does not recognize bcachefs. This update enables mounting via fstab
using `OLD_BLKID_UUID=xxx` as obtained from `bcachefs show-super` "External
UUID".
Here I'm sending a small compile fix for bcachefs-tools.
Without this patch, I get this error:
cargo build --release --manifest-path rust-src/Cargo.toml
Compiling bch_bindgen v0.1.0
(/usr/src/git/bcachefs-tools/rust-src/bch_bindgen)
error: failed to run custom build command for `bch_bindgen v0.1.0
(/usr/src/git/bcachefs-tools/rust-src/bch_bindgen)`
Caused by:
process didn't exit successfully:
`/usr/src/git/bcachefs-tools/rust-src/target/release/build/bch_bindgen-733e88995ce9eab7/build-script-build`
(exit status: 101)
--- stderr
warning: optimization flag '-fkeep-inline-functions' is not supported
[-Wignored-optimization-argument]
../../include/linux/bit_spinlock.h:20:3: error: call to undeclared
function 'futex'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
../../include/linux/bit_spinlock.h:28:2: error: call to undeclared
function 'futex'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
../../include/linux/bit_spinlock.h:39:2: error: call to undeclared
function 'futex'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
The futex() function is declared in
/usr/include/x86_64-linux-gnu/urcu/futex.h
It is not declared in linux/futex.h, so we need to include urcu/futex.h
Mikulas
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>