If io_submit() returns -EAGAIN, that just means the io context is full
and we need to wait for completions - no need to die.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
nixos has trouble with the shell script wrappers - readlink isn't
available by default!
But, there's a better approach: just get rid of them and use symlinks
instead, and have main() check what we're supposed to be.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
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>
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>
After setting a new passphrase, the previous key is left untouched. This
revokes the old key, preventing future actions from using it in error.
Signed-off-by: Colin Gillespie <colin@cgillespie.xyz>
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>
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>
In nochanges mode, without read_only, we can go into a fake rw mode
where we allow writes but hold them in memory.
That's not what we want for the dump tool - this fixes a bug where btree
nodes don't always get dumped correctly.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Also, add helpers for the fuse.bcachefs filesystem type; this means we
can now test the fuse version with fstests.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
To prevent uncontrolled usage of new rust features, directly or from
dependencies, set a minimum supported Rust version and verify it builds.
Signed-off-by: Alexander Fougner <fougner89@gmail.com>
This adds additional details about how encryption works in
bcachefs, along with a warning regarding snapshots.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
