| View previous topic :: View next topic |
| Author |
Message |
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3628
|
 Posted: Sat Mar 16, 2024 8:15 am Post subject: kernel-6.8.0: New CONFIG_BLK_DEV_WRITE_MOUNTED |
 |
|
New setting CONFIG_BLK_DEV_WRITE_MOUNTED is defaulted to Y.
Boots fine.
Because headless I fear to bork boot by cancelling it.
Is it safe to do so.
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here.
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
 |
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1538
|
| Posted: Sat Mar 16, 2024 11:41 am Post subject: |
|
|
| Code: | CONFIG_BLK_DEV_WRITE_MOUNTED:
When a block device is mounted, writing to its buffer cache is very
likely going to cause filesystem corruption. It is also rather easy to
crash the kernel in this way since the filesystem has no practical way
of detecting these writes to buffer cache and verifying its metadata
integrity. However there are some setups that need this capability
like running fsck on read-only mounted root device, modifying some
features on mounted ext4 filesystem, and similar. If you say N, the
kernel will prevent processes from writing to block devices that are
mounted by filesystems which provides some more protection from runaway
privileged processes and generally makes it much harder to crash
filesystem drivers. Note however that this does not prevent
underlying device(s) from being modified by other means, e.g. by
directly submitting SCSI commands or through access to lower layers of
storage stack. If in doubt, say Y. The configuration can be overridden
with the bdev_allow_write_mounted boot option.
|
It's pretty clear you don't need it unless you need it. What I mean is if you need it you'll know it. And chances are whatever was not possible up until now and other means were available to work around it, you wont' start automatically need it now.
I chose N and I don't think it's appropriate for the default choice to be Y.
p.s. | 1 wrote: | | Linux kernel 6.8 can prevent direct writes to block devices with mounted filesystems (excepting Btrfs for now). Devs say writing to mounted devices may lead to filesystem corruption and crashes. This feature is disabled by default but it’s reasoned most Linux distros will choose to enable it. |
1: https://www.omgubuntu.co.uk/2024/03/linux-kernel-6-8-new-features
I guess this came enabled by default by Fedora as Gentoo does not maintain kernel configs. In vanilla kernel it should be disabled by default.
Best Regards,
Georgi |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54247
Location: 56N 3W
|
| Posted: Sat Mar 16, 2024 12:17 pm Post subject: |
|
|
logrusx,
| Code: | ... However there are some setups that need this capability
like running fsck on read-only mounted root device, ... |
That happens every boot, so its probably a good thing.
The kernel mounts root read only, rootfsck runs then the kernel is remounted read write.
Well, if the check passes or the filesystem can be fixed while mounted read only.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2009
|
| Posted: Sat Mar 16, 2024 12:41 pm Post subject: |
|
|
Depends on how you boot. I use an initramfs, and fsck in that before any mounts, so in theory I shouldn't need the block write ability.
But...
Kernel 6.8.1 boots fine with it unset, but then when I come to mount my squashfs portage tree, I get
| Code: | | /dev/loop0: Can't open blockdev |
either via /etc/fstab during boot processing, or manually.
I get the feeling this hasn't been thought through properly...
_________________
Greybeard |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1538
|
| Posted: Sat Mar 16, 2024 12:47 pm Post subject: |
|
|
| Goverp wrote: |
I get the feeling this hasn't been thought through properly... |
And I get the feeling this is unrelated. At least confirm it works when the option is enabled but it still may be a different issue.
Best Regards,
Georgi |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sat Mar 16, 2024 3:05 pm Post subject: |
|
|
As I interpret the help text, CONFIG_BLK_DEV_WRITE_MOUNTED=y has the same semantics as a kernel which predates this feature. Thus, defaulting it to y preserves the historical (somewhat risky) permissive environment. Setting it to n will enforce the restriction, and that enforcement can break the scenarios described above.
| logrusx wrote: | | 1 wrote: | | Linux kernel 6.8 can prevent direct writes to block devices with mounted filesystems (excepting Btrfs for now). Devs say writing to mounted devices may lead to filesystem corruption and crashes. This feature is disabled by default but it’s reasoned most Linux distros will choose to enable it. |
1: https://www.omgubuntu.co.uk/2024/03/linux-kernel-6-8-new-features
I guess this came enabled by default by Fedora as Gentoo does not maintain kernel configs. In vanilla kernel it should be disabled by default. |
The upstream kernel from Linus sets the Kconfig default to y, and the help text encourages uncertain users to leave it set to y. Since this preserves the pre-6.8 semantics, this was likely chosen to minimize users breaking their systems. The bit quoted from omgubuntu is confusingly worded, but I think it is trying to say that the prevention is disabled by default, meaning writes are enabled in 6.8, as they were in pre-6.8. |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2009
|
| Posted: Sat Mar 16, 2024 3:31 pm Post subject: |
|
|
| logrusx wrote: | | Goverp wrote: |
I get the feeling this hasn't been thought through properly... |
And I get the feeling this is unrelated. At least confirm it works when the option is enabled but it still may be a different issue.
|
I've just reversed the setting (no other config changes), and loop mounting the squashfs file now works correctly, as it did with kernel 6.7.x and earlier.
This setting is therefore triggering the problem.
_________________
Greybeard |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1538
|
| Posted: Sat Mar 16, 2024 5:08 pm Post subject: |
|
|
Interesting, I'm getting a bunch of those when I enable that option:
| Code: | CC [M] drivers/bus/mhi/host/pci_generic.o
block/bdev.c:15:10: fatal error: ./include/linux/blk-integrity.h: Bad message
15 | #include <linux/blk-integrity.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
|
Any idea?
Best Regards,
Georgi |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3628
|
| Posted: Sat Mar 16, 2024 5:39 pm Post subject: |
|
|
| NeddySeagoon wrote: | logrusx,
| Code: | ... However there are some setups that need this capability
like running fsck on read-only mounted root device, ... |
That happens every boot, so its probably a good thing.
The kernel mounts root read only, rootfsck runs then the kernel is remounted read write.
Well, if the check passes or the filesystem can be fixed while mounted read only. |
Although OP was very laconic, this is just what I was thinking about...
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here.
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
|
Kernel & Hardware
