* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
@ 2021-01-08 7:43 Metztli Information Technology
0 siblings, 0 replies; 13+ messages in thread
From: Metztli Information Technology @ 2021-01-08 7:43 UTC (permalink / raw)
To: edward.shishkin, reiserfs-devel, hch, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 15342 bytes --]
On Fri, Dec 25, 2020 at 8:44 AM Metztli Information Technology <jose.r.r@metztli.com> wrote:
>
> On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <edward.shishkin@gmail.com> wrote:
> >
> > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > >
> > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i).
> > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
> > >
> > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image.
> > >
> > > Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16:
> > > ...
> > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
> > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
> > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
> > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
> > > Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed
> > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
> > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.
> > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb
> > >
> >
> > [...]
> >
> > >
> > > Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned.
> > > Notwithstanding, I manually verified that I am able to touch a file and set it +x executable.
> > >
> > > Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with
> > > an apparently related error --can not proceed any further.
> > >
> > > Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output
> > > from an attempt on my physical development machine.
> > > ...
> > > [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4.
> > > [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
> > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
> > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS
> > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > > [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > > [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*]
> > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap)
> > > [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot)
> >
> >
> > Hello.
> >
> > This is because of VFS changes in Linux-5.10.X.
> > Specifically, because of the following patch:
> > https://lkml.org/lkml/2020/8/17/174
> > In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
>
> Earlier I spun up a Google Compute Engine (GCE) AMD Epyc instance from a snapshot with kernel 5.9.15-1
> < https://metztli.it/buster/gce-amd-epyc-5.9.15-1.png >
>
> and built an stable reiser4 SFRN 4.0.2 kernel within the Debian packaging for 5.10.2-1 framework.
> Subsequently, I built my custom Debian-Installer (d-i) and gave it another try. Same kernel fail:
> ... tail -n 30 /var/log/syslog
> Dec 25 10:23:06 kernel: [ 164.409309] reiser4: sda7: found disk format 4.0.2.
> Dec 25 10:23:06 kernel: [ 164.459638] reiser4: sda7: using Hybrid Transaction Model.
> Dec 25 10:23:07 apt-install: Queueing package jfsutils for later installation
> Dec 25 10:23:07 apt-install: Queueing package reiser4progs for later installation
> Dec 25 10:23:07 apt-install: Queueing package initramfs-tools for later installation
> Dec 25 10:23:07 apt-install: Queueing package linux-base for later installation
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 3 (pipe:[8689]) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 3 (pipe:[8689]) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
> Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
> Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
> Dec 25 10:23:07 main-menu[240]: INFO: Falling back to the package description for brltty-udeb
> Dec 25 10:23:07 main-menu[240]: INFO: Falling back to the package description for brltty-udeb
> Dec 25 10:23:07 main-menu[240]: INFO: Menu item 'bootstrap-base' selected
> Dec 25 10:23:07 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://mirrors.namecheap.com/debian/
> Dec 25 10:23:07 debootstrap: /usr/sbin/debootstrap:
> Dec 25 10:23:07 debootstrap: line 1596:
> Dec 25 10:23:07 debootstrap: /target/test-exec: Invalid argument
> Dec 25 10:23:07 debootstrap:
> Dec 25 10:23:07 debootstrap: E: NOEXEC
> Dec 25 10:23:07 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
> Dec 25 10:23:07 kernel: [ 165.368737] kernel read not supported for file /test-exec (pid: 5940 comm: debootstrap)
> Dec 25 10:24:57 init: starting pid 222, tty '/dev/tty3': '-/bin/sh'
> ...
>
> and dmesg from within the installer environment:
>
> ...tail -n 20 /var/log/debian-5.10.2.1.dmesg
> [ 133.743458] raid6: sse2x2 xor() 7821 MB/s
> [ 133.825936] raid6: sse2x1 gen() 11332 MB/s
> [ 133.914288] raid6: sse2x1 xor() 7571 MB/s
> [ 133.914290] raid6: using algorithm sse2x2 gen() 15942 MB/s
> [ 133.914291] raid6: .... xor() 7821 MB/s, rmw enabled
> [ 133.914293] raid6: using ssse3x2 recovery algorithm
> [ 133.915254] xor: automatically using best checksumming function avx
> [ 133.942598] Btrfs loaded, crc32c=crc32c-generic
> [ 133.970966] JFS: nTxBlock = 8192, nTxLock = 65536
> [ 133.994981] Loading Reiser4 (format release: 4.0.2) See www.namesys.com for a description of Reiser4.
> [ 134.047520] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
> [ 134.529127] device-mapper: uevent: version 1.0.3
> [ 134.529484] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
> [ 163.693555] sda: sda1 sda2 < sda5 sda6 sda7 >
> [ 164.012669] Adding 999420k swap on /dev/sda6. Priority:-2 extents:1 across:999420k FS
> [ 164.375818] reiser4: sda5: found disk format 4.0.2.
> [ 164.393521] reiser4: sda5: using Hybrid Transaction Model.
> [ 164.409309] reiser4: sda7: found disk format 4.0.2.
> [ 164.459638] reiser4: sda7: using Hybrid Transaction Model.
> [ 165.368737] kernel read not supported for file /test-exec (pid: 5940 comm: debootstrap)
> ...
>
> Please, note that I even replaced debootstrap UDEB with a newer source release to no avail.
>
> >
> > So, Christoph, what to do now for file systems which implement
> > ->read() method of file operations? It seems that chroot doesn't work
> > for them. And people are not able to release distros with upgraded
> > kernels..
> >
> > Thanks,
> > Edward.
>
[]
I came across 'bug #554444 unable to install a Bullseye system' and Bug#971946: libdebian-installer: READSIZE size insufficient for cdebootstrap to build sid/unstable from buster/stable environment
< https://bugs.debian.org/971946 >
As I exhaust all possibilities, I downloaded Debian Buster package source:
< https://packages.debian.org/source/buster/libdebian-installer >
applied the patch
diff --git a/src/parser_rfc822.c b/src/parser_rfc822.c
index afd336a..b14859e 100644
--- a/src/parser_rfc822.c
+++ b/src/parser_rfc822.c
@@ -35,7 +35,7 @@
#include <sys/types.h>
#include <unistd.h>
-#define READSIZE 65536
+#define READSIZE 262144
int di_parser_rfc822_read (char *begin, size_t size, di_parser_info *info, di_parser_read_entry_new entry_new, di_parser_read_entry_finish entry_finish, void *user_data)
{
and rebuilt the package:
libdebian-installer4_0.119+nmu1_amd64.deb
libdebian-installer4-dbgsym_0.119+nmu1_amd64.deb
libdebian-installer4-dev_0.119+nmu1_amd64.deb
libdebian-installer4-udeb_0.119+nmu1_amd64.udeb *
libdebian-installer-extra4_0.119+nmu1_amd64.deb
libdebian-installer-extra4-dbgsym_0.119+nmu1_amd64.deb
libdebian-installer-extra4-udeb_0.119+nmu1_amd64.udeb *
hoping to get some different feedback by including the resulting UDEBs(*) into my custom Debian-Installer (d-i) --as well as referencing those appropriately in the relevant configuration file for a minimal netboot image.
The result did not vary from prior occassions (this installation attempt is a merely root fs formatted in Reiser4 SFRN 5.1.3, and 500Mb JFS /boot partition):
------------[snip]-------------------------
Jan 8 05:00:59 kernel: [ 133.368304] Adding 998396k swap on /dev/sda6. Priority:-2 extents:1 across:998396k FS
Jan 8 05:00:59 kernel: [ 133.685578] reiser4[mount(5208)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
Jan 8 05:00:59 kernel: [ 133.685578] NOTICE: brick /dev/sda5 has been registered
Jan 8 05:00:59 kernel: [ 133.686528] reiser4 (sda5): found disk format 5.1.3.
Jan 8 05:00:59 kernel: [ 133.746172] reiser4 (/dev/sda5): using Hybrid Transaction Model.
Jan 8 05:00:59 kernel: [ 133.746176] reiser4: brick /dev/sda5 activated
Jan 8 05:00:59 apt-install: Queueing package jfsutils for later installation
Jan 8 05:00:59 apt-install: Queueing package reiser4progs for later installation
Jan 8 05:00:59 apt-install: Queueing package initramfs-tools for later installation
Jan 8 05:00:59 apt-install: Queueing package linux-base for later installation
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 3 (pipe:[8687]) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5363: /bin/sh
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5363: /bin/sh
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5363: /bin/sh
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 3 (pipe:[8687]) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5402: /bin/sh
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5402: /bin/sh
Jan 8 05:00:59 main-menu[239]: (process:3051): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
Jan 8 05:00:59 main-menu[239]: (process:3051): Parent PID 5402: /bin/sh
Jan 8 05:01:00 main-menu[239]: INFO: Falling back to the package description for brltty-udeb
Jan 8 05:01:00 main-menu[239]: INFO: Falling back to the package description for brltty-udeb
Jan 8 05:01:00 main-menu[239]: INFO: Menu item 'bootstrap-base' selected
Jan 8 05:01:00 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
Jan 8 05:01:00 debootstrap: /usr/sbin/debootstrap:
Jan 8 05:01:00 debootstrap: line 1622:
Jan 8 05:01:00 debootstrap: /target/test-exec: Invalid argument
Jan 8 05:01:00 debootstrap:
Jan 8 05:01:00 debootstrap: E: NOEXEC
Jan 8 05:01:00 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
Jan 8 05:01:00 kernel: [ 134.634946] kernel read not supported for file /test-exec (pid: 5609 comm: debootstrap)
--------------------------------------------------------------------
If nothing is modified in 5.10.x kernel upstream, Linux 5.9.15/16EOL may be the last kernel version to benefit from a Reiser5 -enabled custom Debian-Installer (d-i), LXQT snapshot for posterity ;-)
< https://metztli.it/buster/reiser4-sfrn-5.1.3-LXQT-Debian.png >
Best Professional Regards.
--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.15 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---------------------------------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
@ 2021-02-08 12:54 Metztli Information Technology
2021-02-08 16:03 ` Edward Shishkin
0 siblings, 1 reply; 13+ messages in thread
From: Metztli Information Technology @ 2021-02-08 12:54 UTC (permalink / raw)
To: edward.shishkin, reiserfs-devel, hch, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 8563 bytes --]
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <edward.shishkin@gmail.com> wrote:
>
> On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> >
> > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i).
> > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
> >
> > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image.
> >
> > Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16:
> > ...
> > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
> > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
> > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
> > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
> > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
> > Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed
> > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
> > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.
> > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb
> >
>
> [...]
>
> >
> > Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned.
> > Notwithstanding, I manually verified that I am able to touch a file and set it +x executable.
> >
> > Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with
> > an apparently related error --can not proceed any further.
> >
> > Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output
> > from an attempt on my physical development machine.
> > ...
> > [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4.
> > [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
> > [ 509.326270] device-mapper: uevent: version 1.0.3
> > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
> > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS
> > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
> > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > [ 643.759980] reiser4: brick /dev/sda6 activated
> > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*]
> > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > [ 999.093480] reiser4: brick /dev/sda6 activated
> > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap)
> > [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot)
>
>
> Hello.
>
> This is because of VFS changes in Linux-5.10.X.
> Specifically, because of the following patch:
> https://lkml.org/lkml/2020/8/17/174
> In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
>
> So, Christoph, what to do now for file systems which implement
> ->read() method of file operations?
*deafening silence* it appears that -- in the best of cases -- Christoph engaged in an act of _iter masturbation [1];
and in the worst of cases, the gentleman was aiming straight at reiser4.
>... It seems that chroot doesn't work
> for them. And people are not able to release distros with upgraded
> kernels..
Not only 'chroot doesn't work' for us, but even after replacing the kernel in a reiser4 (proper SFRN ;) instance and
upon an initial Linux 5.10.x kernel boot:
...
kernel read not supported for file usr/lib/systemd/systemd (pid: 1 comm: run-init)
kernel panic -- not syncing: Attempted to kill init! exitcod=0x00000100
...
Fact is some of us have commercial interests when deploying reiser4, both in cloud instances, baremetal, and on-premises.
In the future if -- and only if -- our reiser4 efforts come to successful fruition, quite likely in due time we will be
able to financially commit to the Penguin's Linux Foundation temple, just like large corporations do
in exchange for indulgences[2] which virtue-wash their past and/or current corp. officers' *substantially darker deeds*;
heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU) that 'virtuous' cult of GNU/Linux
developers/gatekeepers/maintainers' frivolous, *narcissist*, ethics and/or moralities so often piled up against
Reiser's work --which, paradoxically(!?), actually was largely implemented by Russian developers ;)
In the meantime, I hacked a reverse patch that undoes some(all) of the surreptitious lethal attack on reiser4 fs
-- at least on AMD64 architectures (I did away with other arch/Kconfigs).
And no, I am not a git pro-, undoing what I could of commit 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
does not fix the 'kernel read' issue.
Notwithstanding, I would appreciate if you can take a look at the attached patch. Probably it can be streamlined and/or improved
further to minimize pain on subsequent Linux kernel upgrades.
The patch has been tested in my local development machine environment --
as I intalled the generated reiser4 -enabled linux 5.10.13/14 meta/kernel into a Debian Bullseye already running reiser4 (with proper SFRN)
and the kernel booted nicely. Subsequently, after installing the linux headers, etc. I built a couple of upgraded kernels
in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus the hack seems to be stable.
Additionally, I have just made a Debian-Installer (d-i) with a 'kernel read' -patched Linux 5.10.14.1 which successfully installed
into a VirtualBox 6.1.18 VM:
< https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png >
>
> Thanks,
> Edward.
Best Professional Regards.
[1]
"The bug was fixed, again way back in 2010, and over time chip-designers have moved on to improved memory management techniques.
Torvalds wrote that this sort of memory space override has been banished from the x86, powerpc, s390 and RISC-V architectures."
< https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
[2] https://www.britannica.com/topic/indulgence
--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---------------------------------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
[-- Attachment #2: linux-5.10.14-enable-kernel-read-on-reiser4.patch --]
[-- Type: application/octet-stream, Size: 45102 bytes --]
From 66d439282230942ab050460ef40e3b54022a32a5 Mon Sep 17 00:00:00 2001
From: Metztli Information Technology <jose@metztli.it>
Date: Sun, 7 Feb 2021 21:10:46 -0800
Subject: [PATCH] Ic ome (Второй : Second) commit - preventing 'kernel
read not supported...' panic on Reiser Linux 5.10.14 on AMD64
---
arch/Kconfig | 3 -
arch/x86/ia32/ia32_aout.c | 1 +
arch/x86/include/asm/page_32_types.h | 11 --
arch/x86/include/asm/page_64_types.h | 38 -------
arch/x86/include/asm/processor.h | 60 ++++++++++-
arch/x86/include/asm/thread_info.h | 2 +
arch/x86/include/asm/uaccess.h | 26 ++++-
arch/x86/kernel/asm-offsets.c | 3 +
arch/x86/lib/getuser.S | 47 +++++----
arch/x86/lib/putuser.S | 25 +++--
drivers/misc/lkdtm/bugs.c | 10 ++
drivers/misc/lkdtm/core.c | 2 +
drivers/misc/lkdtm/lkdtm.h | 2 +
drivers/misc/lkdtm/usercopy.c | 15 +++
fs/proc/cpuinfo.c | 2 +-
fs/proc/generic.c | 4 +-
fs/proc/inode.c | 124 ++++++++--------------
fs/proc/proc_sysctl.c | 48 ++++-----
fs/proc/stat.c | 2 +-
fs/read_write.c | 71 +++++--------
fs/splice.c | 130 +++++++++++++++++++++---
include/linux/bpf-cgroup.h | 2 +-
include/linux/fs.h | 2 +
include/linux/proc_fs.h | 1 -
include/linux/uaccess.h | 22 +---
kernel/bpf/cgroup.c | 2 +-
lib/test_bitmap.c | 91 +++++++++++++----
tools/testing/selftests/lkdtm/tests.txt | 2 +
28 files changed, 442 insertions(+), 306 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 69fe7133c765..f8769e61757b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -24,9 +24,6 @@ config KEXEC_ELF
config HAVE_IMA_KEXEC
bool
-config SET_FS
- bool
-
config HOTPLUG_SMT
bool
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index a09fc37ead9d..ca8a657edf59 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -239,6 +239,7 @@ static int load_aout_binary(struct linux_binprm *bprm)
(regs)->ss = __USER32_DS;
regs->r8 = regs->r9 = regs->r10 = regs->r11 =
regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
+ set_fs(USER_DS);
return 0;
}
diff --git a/arch/x86/include/asm/page_32_types.h b/arch/x86/include/asm/page_32_types.h
index f462895a33e4..565ad755c785 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -41,17 +41,6 @@
#define __VIRTUAL_MASK_SHIFT 32
#endif /* CONFIG_X86_PAE */
-/*
- * User space process size: 3GB (default).
- */
-#define IA32_PAGE_OFFSET __PAGE_OFFSET
-#define TASK_SIZE __PAGE_OFFSET
-#define TASK_SIZE_LOW TASK_SIZE
-#define TASK_SIZE_MAX TASK_SIZE
-#define DEFAULT_MAP_WINDOW TASK_SIZE
-#define STACK_TOP TASK_SIZE
-#define STACK_TOP_MAX STACK_TOP
-
/*
* Kernel image size is limited to 512 MB (see in arch/x86/kernel/head_32.S)
*/
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 3f49dac03617..d0c6c10c18a0 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -59,44 +59,6 @@
#define __VIRTUAL_MASK_SHIFT 47
#endif
-/*
- * User space process size. This is the first address outside the user range.
- * There are a few constraints that determine this:
- *
- * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
- * address, then that syscall will enter the kernel with a
- * non-canonical return address, and SYSRET will explode dangerously.
- * We avoid this particular problem by preventing anything executable
- * from being mapped at the maximum canonical address.
- *
- * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
- * CPUs malfunction if they execute code from the highest canonical page.
- * They'll speculate right off the end of the canonical space, and
- * bad things happen. This is worked around in the same way as the
- * Intel problem.
- *
- * With page table isolation enabled, we map the LDT in ... [stay tuned]
- */
-#define TASK_SIZE_MAX ((_AC(1,UL) << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
-
-#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
-
-/* This decides where the kernel will search for a free chunk of vm
- * space during mmap's.
- */
-#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
- 0xc0000000 : 0xFFFFe000)
-
-#define TASK_SIZE_LOW (test_thread_flag(TIF_ADDR32) ? \
- IA32_PAGE_OFFSET : DEFAULT_MAP_WINDOW)
-#define TASK_SIZE (test_thread_flag(TIF_ADDR32) ? \
- IA32_PAGE_OFFSET : TASK_SIZE_MAX)
-#define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_ADDR32)) ? \
- IA32_PAGE_OFFSET : TASK_SIZE_MAX)
-
-#define STACK_TOP TASK_SIZE_LOW
-#define STACK_TOP_MAX TASK_SIZE_MAX
-
/*
* Maximum kernel image size is limited to 1 GiB, due to the fixmap living
* in the next 1 GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S).
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 82a08b585818..5ac507586769 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -482,6 +482,10 @@ extern unsigned int fpu_user_xstate_size;
struct perf_event;
+typedef struct {
+ unsigned long seg;
+} mm_segment_t;
+
struct thread_struct {
/* Cached TLS descriptors: */
struct desc_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
@@ -534,6 +538,8 @@ struct thread_struct {
*/
unsigned long iopl_emul;
+ mm_segment_t addr_limit;
+
unsigned int sig_on_uaccess_err:1;
/* Floating point and extended processor state */
@@ -777,15 +783,67 @@ static inline void spin_lock_prefetch(const void *x)
})
#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define IA32_PAGE_OFFSET PAGE_OFFSET
+#define TASK_SIZE PAGE_OFFSET
+#define TASK_SIZE_LOW TASK_SIZE
+#define TASK_SIZE_MAX TASK_SIZE
+#define DEFAULT_MAP_WINDOW TASK_SIZE
+#define STACK_TOP TASK_SIZE
+#define STACK_TOP_MAX STACK_TOP
+
#define INIT_THREAD { \
.sp0 = TOP_OF_INIT_STACK, \
.sysenter_cs = __KERNEL_CS, \
+ .addr_limit = KERNEL_DS, \
}
#define KSTK_ESP(task) (task_pt_regs(task)->sp)
#else
-#define INIT_THREAD { }
+/*
+ * User space process size. This is the first address outside the user range.
+ * There are a few constraints that determine this:
+ *
+ * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
+ * address, then that syscall will enter the kernel with a
+ * non-canonical return address, and SYSRET will explode dangerously.
+ * We avoid this particular problem by preventing anything executable
+ * from being mapped at the maximum canonical address.
+ *
+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen. This is worked around in the same way as the
+ * Intel problem.
+ *
+ * With page table isolation enabled, we map the LDT in ... [stay tuned]
+ */
+#define TASK_SIZE_MAX ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
+
+#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+ 0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE_LOW (test_thread_flag(TIF_ADDR32) ? \
+ IA32_PAGE_OFFSET : DEFAULT_MAP_WINDOW)
+#define TASK_SIZE (test_thread_flag(TIF_ADDR32) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE_MAX)
+#define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_ADDR32)) ? \
+ IA32_PAGE_OFFSET : TASK_SIZE_MAX)
+
+#define STACK_TOP TASK_SIZE_LOW
+#define STACK_TOP_MAX TASK_SIZE_MAX
+
+#define INIT_THREAD { \
+ .addr_limit = KERNEL_DS, \
+}
extern unsigned long KSTK_ESP(struct task_struct *task);
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index 44733a4bfc42..267701ae3d86 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -102,6 +102,7 @@ struct thread_info {
#define TIF_SYSCALL_TRACEPOINT 28 /* syscall tracepoint instrumentation */
#define TIF_ADDR32 29 /* 32-bit address space on 64 bits */
#define TIF_X32 30 /* 32-bit native x86-64 binary */
+#define TIF_FSCHECK 31 /* Check FS is USER_DS on return */
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
@@ -130,6 +131,7 @@ struct thread_info {
#define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_ADDR32 (1 << TIF_ADDR32)
#define _TIF_X32 (1 << TIF_X32)
+#define _TIF_FSCHECK (1 << TIF_FSCHECK)
/* flags to check in __switch_to() */
#define _TIF_WORK_CTXSW_BASE \
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index c9fa7be3df82..a2c937245753 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -12,6 +12,30 @@
#include <asm/smap.h>
#include <asm/extable.h>
+/*
+ * The fs value determines whether argument validity checking should be
+ * performed or not. If get_fs() == USER_DS, checking is performed, with
+ * get_fs() == KERNEL_DS, checking is bypassed.
+ *
+ * For historical reasons, these macros are grossly misnamed.
+ */
+
+#define MAKE_MM_SEG(s) ((mm_segment_t) { (s) })
+
+#define KERNEL_DS MAKE_MM_SEG(-1UL)
+#define USER_DS MAKE_MM_SEG(TASK_SIZE_MAX)
+
+#define get_fs() (current->thread.addr_limit)
+static inline void set_fs(mm_segment_t fs)
+{
+ current->thread.addr_limit = fs;
+ /* On user-mode return, check fs is correct */
+ set_thread_flag(TIF_FSCHECK);
+}
+
+#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
+#define user_addr_max() (current->thread.addr_limit.seg)
+
/*
* Test whether a block of memory is a valid user space address.
* Returns 0 if the range is valid, nonzero otherwise.
@@ -69,7 +93,7 @@ static inline bool pagefault_disabled(void);
#define access_ok(addr, size) \
({ \
WARN_ON_IN_IRQ(); \
- likely(!__range_not_ok(addr, size, TASK_SIZE_MAX)); \
+ likely(!__range_not_ok(addr, size, user_addr_max())); \
})
extern int __get_user_1(void);
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 70b7154f4bdd..3ca07ad552ae 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -37,6 +37,9 @@ static void __used common(void)
OFFSET(TASK_stack_canary, task_struct, stack_canary);
#endif
+ BLANK();
+ OFFSET(TASK_addr_limit, task_struct, thread.addr_limit);
+
BLANK();
OFFSET(crypto_tfm_ctx_offset, crypto_tfm, __crt_ctx);
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index fa1bc2104b32..2cd902e06062 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -37,19 +37,10 @@
#define ASM_BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
-#ifdef CONFIG_X86_5LEVEL
-#define LOAD_TASK_SIZE_MINUS_N(n) \
- ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \
- __stringify(mov $((1 << 56) - 4096 - (n)),%rdx), X86_FEATURE_LA57
-#else
-#define LOAD_TASK_SIZE_MINUS_N(n) \
- mov $(TASK_SIZE_MAX - (n)),%_ASM_DX
-#endif
-
.text
SYM_FUNC_START(__get_user_1)
- LOAD_TASK_SIZE_MINUS_N(0)
- cmp %_ASM_DX,%_ASM_AX
+ mov PER_CPU_VAR(current_task), %_ASM_DX
+ cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
and %_ASM_DX, %_ASM_AX
@@ -62,13 +53,15 @@ SYM_FUNC_END(__get_user_1)
EXPORT_SYMBOL(__get_user_1)
SYM_FUNC_START(__get_user_2)
- LOAD_TASK_SIZE_MINUS_N(1)
- cmp %_ASM_DX,%_ASM_AX
+ add $1,%_ASM_AX
+ jc bad_get_user
+ mov PER_CPU_VAR(current_task), %_ASM_DX
+ cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
and %_ASM_DX, %_ASM_AX
ASM_STAC
-2: movzwl (%_ASM_AX),%edx
+2: movzwl -1(%_ASM_AX),%edx
xor %eax,%eax
ASM_CLAC
ret
@@ -76,13 +69,15 @@ SYM_FUNC_END(__get_user_2)
EXPORT_SYMBOL(__get_user_2)
SYM_FUNC_START(__get_user_4)
- LOAD_TASK_SIZE_MINUS_N(3)
- cmp %_ASM_DX,%_ASM_AX
+ add $3,%_ASM_AX
+ jc bad_get_user
+ mov PER_CPU_VAR(current_task), %_ASM_DX
+ cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
and %_ASM_DX, %_ASM_AX
ASM_STAC
-3: movl (%_ASM_AX),%edx
+3: movl -3(%_ASM_AX),%edx
xor %eax,%eax
ASM_CLAC
ret
@@ -91,25 +86,29 @@ EXPORT_SYMBOL(__get_user_4)
SYM_FUNC_START(__get_user_8)
#ifdef CONFIG_X86_64
- LOAD_TASK_SIZE_MINUS_N(7)
- cmp %_ASM_DX,%_ASM_AX
+ add $7,%_ASM_AX
+ jc bad_get_user
+ mov PER_CPU_VAR(current_task), %_ASM_DX
+ cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user
sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
and %_ASM_DX, %_ASM_AX
ASM_STAC
-4: movq (%_ASM_AX),%rdx
+4: movq -7(%_ASM_AX),%rdx
xor %eax,%eax
ASM_CLAC
ret
#else
- LOAD_TASK_SIZE_MINUS_N(7)
- cmp %_ASM_DX,%_ASM_AX
+ add $7,%_ASM_AX
+ jc bad_get_user_8
+ mov PER_CPU_VAR(current_task), %_ASM_DX
+ cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX
jae bad_get_user_8
sbb %_ASM_DX, %_ASM_DX /* array_index_mask_nospec() */
and %_ASM_DX, %_ASM_AX
ASM_STAC
-4: movl (%_ASM_AX),%edx
-5: movl 4(%_ASM_AX),%ecx
+4: movl -7(%_ASM_AX),%edx
+5: movl -3(%_ASM_AX),%ecx
xor %eax,%eax
ASM_CLAC
ret
diff --git a/arch/x86/lib/putuser.S b/arch/x86/lib/putuser.S
index 0ea344c5ea43..b34a17763f28 100644
--- a/arch/x86/lib/putuser.S
+++ b/arch/x86/lib/putuser.S
@@ -33,19 +33,12 @@
* as they get called from within inline assembly.
*/
-#ifdef CONFIG_X86_5LEVEL
-#define LOAD_TASK_SIZE_MINUS_N(n) \
- ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rbx), \
- __stringify(mov $((1 << 56) - 4096 - (n)),%rbx), X86_FEATURE_LA57
-#else
-#define LOAD_TASK_SIZE_MINUS_N(n) \
- mov $(TASK_SIZE_MAX - (n)),%_ASM_BX
-#endif
+#define ENTER mov PER_CPU_VAR(current_task), %_ASM_BX
.text
SYM_FUNC_START(__put_user_1)
- LOAD_TASK_SIZE_MINUS_N(0)
- cmp %_ASM_BX,%_ASM_CX
+ ENTER
+ cmp TASK_addr_limit(%_ASM_BX),%_ASM_CX
jae .Lbad_put_user
SYM_INNER_LABEL(__put_user_nocheck_1, SYM_L_GLOBAL)
ASM_STAC
@@ -58,7 +51,9 @@ EXPORT_SYMBOL(__put_user_1)
EXPORT_SYMBOL(__put_user_nocheck_1)
SYM_FUNC_START(__put_user_2)
- LOAD_TASK_SIZE_MINUS_N(1)
+ ENTER
+ mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
+ sub $1,%_ASM_BX
cmp %_ASM_BX,%_ASM_CX
jae .Lbad_put_user
SYM_INNER_LABEL(__put_user_nocheck_2, SYM_L_GLOBAL)
@@ -72,7 +67,9 @@ EXPORT_SYMBOL(__put_user_2)
EXPORT_SYMBOL(__put_user_nocheck_2)
SYM_FUNC_START(__put_user_4)
- LOAD_TASK_SIZE_MINUS_N(3)
+ ENTER
+ mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
+ sub $3,%_ASM_BX
cmp %_ASM_BX,%_ASM_CX
jae .Lbad_put_user
SYM_INNER_LABEL(__put_user_nocheck_4, SYM_L_GLOBAL)
@@ -86,7 +83,9 @@ EXPORT_SYMBOL(__put_user_4)
EXPORT_SYMBOL(__put_user_nocheck_4)
SYM_FUNC_START(__put_user_8)
- LOAD_TASK_SIZE_MINUS_N(7)
+ ENTER
+ mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
+ sub $7,%_ASM_BX
cmp %_ASM_BX,%_ASM_CX
jae .Lbad_put_user
SYM_INNER_LABEL(__put_user_nocheck_8, SYM_L_GLOBAL)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index a0675d4154d2..4dfbfd51bdf7 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -312,6 +312,16 @@ void lkdtm_CORRUPT_LIST_DEL(void)
pr_err("list_del() corruption not detected!\n");
}
+/* Test if unbalanced set_fs(KERNEL_DS)/set_fs(USER_DS) check exists. */
+void lkdtm_CORRUPT_USER_DS(void)
+{
+ pr_info("setting bad task size limit\n");
+ set_fs(KERNEL_DS);
+
+ /* Make sure we do not keep running with a KERNEL_DS! */
+ force_sig(SIGKILL);
+}
+
/* Test that VMAP_STACK is actually allocating with a leading guard page */
void lkdtm_STACK_GUARD_PAGE_LEADING(void)
{
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index 97803f213d9d..a5e344df9166 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -112,6 +112,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(CORRUPT_STACK_STRONG),
CRASHTYPE(CORRUPT_LIST_ADD),
CRASHTYPE(CORRUPT_LIST_DEL),
+ CRASHTYPE(CORRUPT_USER_DS),
CRASHTYPE(STACK_GUARD_PAGE_LEADING),
CRASHTYPE(STACK_GUARD_PAGE_TRAILING),
CRASHTYPE(UNSET_SMEP),
@@ -171,6 +172,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
CRASHTYPE(STACKLEAK_ERASING),
CRASHTYPE(CFI_FORWARD_PROTO),
#ifdef CONFIG_X86_32
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 6dec4c9b442f..8878538b2c13 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -27,6 +27,7 @@ void lkdtm_OVERFLOW_UNSIGNED(void);
void lkdtm_ARRAY_BOUNDS(void);
void lkdtm_CORRUPT_LIST_ADD(void);
void lkdtm_CORRUPT_LIST_DEL(void);
+void lkdtm_CORRUPT_USER_DS(void);
void lkdtm_STACK_GUARD_PAGE_LEADING(void);
void lkdtm_STACK_GUARD_PAGE_TRAILING(void);
void lkdtm_UNSET_SMEP(void);
@@ -95,6 +96,7 @@ void lkdtm_USERCOPY_STACK_FRAME_TO(void);
void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
void lkdtm_USERCOPY_STACK_BEYOND(void);
void lkdtm_USERCOPY_KERNEL(void);
+void lkdtm_USERCOPY_KERNEL_DS(void);
/* lkdtm_stackleak.c */
void lkdtm_STACKLEAK_ERASING(void);
diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 109e8d4302c1..b833367a45d0 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -325,6 +325,21 @@ void lkdtm_USERCOPY_KERNEL(void)
vm_munmap(user_addr, PAGE_SIZE);
}
+void lkdtm_USERCOPY_KERNEL_DS(void)
+{
+ char __user *user_ptr =
+ (char __user *)(0xFUL << (sizeof(unsigned long) * 8 - 4));
+ mm_segment_t old_fs = get_fs();
+ char buf[10] = {0};
+
+ pr_info("attempting copy_to_user() to noncanonical address: %px\n",
+ user_ptr);
+ set_fs(KERNEL_DS);
+ if (copy_to_user(user_ptr, buf, sizeof(buf)) == 0)
+ pr_err("copy_to_user() to noncanonical address succeeded!?\n");
+ set_fs(old_fs);
+}
+
void __init lkdtm_usercopy_init(void)
{
/* Prepare cache that lacks SLAB_USERCOPY flag. */
diff --git a/fs/proc/cpuinfo.c b/fs/proc/cpuinfo.c
index 419760fd77bd..d0989a443c77 100644
--- a/fs/proc/cpuinfo.c
+++ b/fs/proc/cpuinfo.c
@@ -19,7 +19,7 @@ static int cpuinfo_open(struct inode *inode, struct file *file)
static const struct proc_ops cpuinfo_proc_ops = {
.proc_flags = PROC_ENTRY_PERMANENT,
.proc_open = cpuinfo_open,
- .proc_read_iter = seq_read_iter,
+ .proc_read = seq_read,
.proc_lseek = seq_lseek,
.proc_release = seq_release,
};
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 6c0a05f55d6b..63fd4a6c2dec 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -610,7 +610,7 @@ static int proc_seq_release(struct inode *inode, struct file *file)
static const struct proc_ops proc_seq_ops = {
/* not permanent -- can call into arbitrary seq_operations */
.proc_open = proc_seq_open,
- .proc_read_iter = seq_read_iter,
+ .proc_read = seq_read,
.proc_lseek = seq_lseek,
.proc_release = proc_seq_release,
};
@@ -641,7 +641,7 @@ static int proc_single_open(struct inode *inode, struct file *file)
static const struct proc_ops proc_single_ops = {
/* not permanent -- can call into arbitrary ->single_show */
.proc_open = proc_single_open,
- .proc_read_iter = seq_read_iter,
+ .proc_read = seq_read,
.proc_lseek = seq_lseek,
.proc_release = single_release,
};
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index bde6b6f69852..68e55483d6f3 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -297,21 +297,6 @@ static loff_t proc_reg_llseek(struct file *file, loff_t offset, int whence)
return rv;
}
-static ssize_t proc_reg_read_iter(struct kiocb *iocb, struct iov_iter *iter)
-{
- struct proc_dir_entry *pde = PDE(file_inode(iocb->ki_filp));
- ssize_t ret;
-
- if (pde_is_permanent(pde))
- return pde->proc_ops->proc_read_iter(iocb, iter);
-
- if (!use_pde(pde))
- return -EIO;
- ret = pde->proc_ops->proc_read_iter(iocb, iter);
- unuse_pde(pde);
- return ret;
-}
-
static ssize_t pde_read(struct proc_dir_entry *pde, struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
typeof_member(struct proc_ops, proc_read) read;
@@ -587,52 +572,32 @@ static const struct file_operations proc_reg_file_ops = {
.write = proc_reg_write,
.poll = proc_reg_poll,
.unlocked_ioctl = proc_reg_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = proc_reg_compat_ioctl,
+#endif
.mmap = proc_reg_mmap,
.get_unmapped_area = proc_reg_get_unmapped_area,
.open = proc_reg_open,
.release = proc_reg_release,
};
-static const struct file_operations proc_iter_file_ops = {
- .llseek = proc_reg_llseek,
- .read_iter = proc_reg_read_iter,
- .write = proc_reg_write,
- .splice_read = generic_file_splice_read,
- .poll = proc_reg_poll,
- .unlocked_ioctl = proc_reg_unlocked_ioctl,
- .mmap = proc_reg_mmap,
- .get_unmapped_area = proc_reg_get_unmapped_area,
- .open = proc_reg_open,
- .release = proc_reg_release,
-};
-
+ /** .splice_read = generic_file_splice_read,
+ */
#ifdef CONFIG_COMPAT
-static const struct file_operations proc_reg_file_ops_compat = {
+static const struct file_operations proc_reg_file_ops_no_compat = {
.llseek = proc_reg_llseek,
.read = proc_reg_read,
.write = proc_reg_write,
.poll = proc_reg_poll,
.unlocked_ioctl = proc_reg_unlocked_ioctl,
- .compat_ioctl = proc_reg_compat_ioctl,
.mmap = proc_reg_mmap,
.get_unmapped_area = proc_reg_get_unmapped_area,
.open = proc_reg_open,
.release = proc_reg_release,
};
-static const struct file_operations proc_iter_file_ops_compat = {
- .llseek = proc_reg_llseek,
- .read_iter = proc_reg_read_iter,
- .splice_read = generic_file_splice_read,
- .write = proc_reg_write,
- .poll = proc_reg_poll,
- .unlocked_ioctl = proc_reg_unlocked_ioctl,
- .compat_ioctl = proc_reg_compat_ioctl,
- .mmap = proc_reg_mmap,
- .get_unmapped_area = proc_reg_get_unmapped_area,
- .open = proc_reg_open,
- .release = proc_reg_release,
-};
+ /** .splice_read = generic_file_splice_read,
+ */
#endif
static void proc_put_link(void *p)
@@ -659,51 +624,42 @@ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de)
{
struct inode *inode = new_inode(sb);
- if (!inode) {
- pde_put(de);
- return NULL;
- }
+ if (inode) {
+ inode->i_ino = de->low_ino;
+ inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);
+ PROC_I(inode)->pde = de;
- inode->i_ino = de->low_ino;
- inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode);
- PROC_I(inode)->pde = de;
- if (is_empty_pde(de)) {
- make_empty_dir_inode(inode);
- return inode;
- }
+ if (is_empty_pde(de)) {
+ make_empty_dir_inode(inode);
+ return inode;
+ }
+ if (de->mode) {
+ inode->i_mode = de->mode;
+ inode->i_uid = de->uid;
+ inode->i_gid = de->gid;
+ }
+ if (de->size)
+ inode->i_size = de->size;
+ if (de->nlink)
+ set_nlink(inode, de->nlink);
- if (de->mode) {
- inode->i_mode = de->mode;
- inode->i_uid = de->uid;
- inode->i_gid = de->gid;
- }
- if (de->size)
- inode->i_size = de->size;
- if (de->nlink)
- set_nlink(inode, de->nlink);
-
- if (S_ISREG(inode->i_mode)) {
- inode->i_op = de->proc_iops;
- if (de->proc_ops->proc_read_iter)
- inode->i_fop = &proc_iter_file_ops;
- else
+ if (S_ISREG(inode->i_mode)) {
+ inode->i_op = de->proc_iops;
inode->i_fop = &proc_reg_file_ops;
#ifdef CONFIG_COMPAT
- if (de->proc_ops->proc_compat_ioctl) {
- if (de->proc_ops->proc_read_iter)
- inode->i_fop = &proc_iter_file_ops_compat;
- else
- inode->i_fop = &proc_reg_file_ops_compat;
- }
+ if (!de->proc_ops->proc_compat_ioctl) {
+ inode->i_fop = &proc_reg_file_ops_no_compat;
+ }
#endif
- } else if (S_ISDIR(inode->i_mode)) {
- inode->i_op = de->proc_iops;
- inode->i_fop = de->proc_dir_ops;
- } else if (S_ISLNK(inode->i_mode)) {
- inode->i_op = de->proc_iops;
- inode->i_fop = NULL;
- } else {
- BUG();
- }
+ } else if (S_ISDIR(inode->i_mode)) {
+ inode->i_op = de->proc_iops;
+ inode->i_fop = de->proc_dir_ops;
+ } else if (S_ISLNK(inode->i_mode)) {
+ inode->i_op = de->proc_iops;
+ inode->i_fop = NULL;
+ } else
+ BUG();
+ } else
+ pde_put(de);
return inode;
}
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index d2018f70d1fa..4902e8a6caca 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -12,7 +12,6 @@
#include <linux/cred.h>
#include <linux/namei.h>
#include <linux/mm.h>
-#include <linux/uio.h>
#include <linux/module.h>
#include <linux/bpf-cgroup.h>
#include <linux/mount.h>
@@ -541,14 +540,13 @@ static struct dentry *proc_sys_lookup(struct inode *dir, struct dentry *dentry,
return err;
}
-static ssize_t proc_sys_call_handler(struct kiocb *iocb, struct iov_iter *iter,
- int write)
+static ssize_t proc_sys_call_handler(struct file *filp, void __user *ubuf,
+ size_t count, loff_t *ppos, int write)
{
- struct inode *inode = file_inode(iocb->ki_filp);
+ struct inode *inode = file_inode(filp);
struct ctl_table_header *head = grab_header(inode);
struct ctl_table *table = PROC_I(inode)->sysctl_entry;
- size_t count = iov_iter_count(iter);
- char *kbuf;
+ void *kbuf;
ssize_t error;
if (IS_ERR(head))
@@ -571,30 +569,32 @@ static ssize_t proc_sys_call_handler(struct kiocb *iocb, struct iov_iter *iter,
error = -ENOMEM;
if (count >= KMALLOC_MAX_SIZE)
goto out;
- kbuf = kzalloc(count + 1, GFP_KERNEL);
- if (!kbuf)
- goto out;
if (write) {
- error = -EFAULT;
- if (!copy_from_iter_full(kbuf, count, iter))
- goto out_free_buf;
- kbuf[count] = '\0';
+ kbuf = memdup_user_nul(ubuf, count);
+ if (IS_ERR(kbuf)) {
+ error = PTR_ERR(kbuf);
+ goto out;
+ }
+ } else {
+ kbuf = kzalloc(count, GFP_KERNEL);
+ if (!kbuf)
+ goto out;
}
error = BPF_CGROUP_RUN_PROG_SYSCTL(head, table, write, &kbuf, &count,
- &iocb->ki_pos);
+ ppos);
if (error)
goto out_free_buf;
/* careful: calling conventions are nasty here */
- error = table->proc_handler(table, write, kbuf, &count, &iocb->ki_pos);
+ error = table->proc_handler(table, write, kbuf, &count, ppos);
if (error)
goto out_free_buf;
if (!write) {
error = -EFAULT;
- if (copy_to_iter(kbuf, count, iter) < count)
+ if (copy_to_user(ubuf, kbuf, count))
goto out_free_buf;
}
@@ -607,14 +607,16 @@ static ssize_t proc_sys_call_handler(struct kiocb *iocb, struct iov_iter *iter,
return error;
}
-static ssize_t proc_sys_read(struct kiocb *iocb, struct iov_iter *iter)
+static ssize_t proc_sys_read(struct file *filp, char __user *buf,
+ size_t count, loff_t *ppos)
{
- return proc_sys_call_handler(iocb, iter, 0);
+ return proc_sys_call_handler(filp, (void __user *)buf, count, ppos, 0);
}
-static ssize_t proc_sys_write(struct kiocb *iocb, struct iov_iter *iter)
+static ssize_t proc_sys_write(struct file *filp, const char __user *buf,
+ size_t count, loff_t *ppos)
{
- return proc_sys_call_handler(iocb, iter, 1);
+ return proc_sys_call_handler(filp, (void __user *)buf, count, ppos, 1);
}
static int proc_sys_open(struct inode *inode, struct file *filp)
@@ -851,10 +853,8 @@ static int proc_sys_getattr(const struct path *path, struct kstat *stat,
static const struct file_operations proc_sys_file_operations = {
.open = proc_sys_open,
.poll = proc_sys_poll,
- .read_iter = proc_sys_read,
- .write_iter = proc_sys_write,
- .splice_read = generic_file_splice_read,
- .splice_write = iter_file_splice_write,
+ .read = proc_sys_read,
+ .write = proc_sys_write,
.llseek = default_llseek,
};
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index 4695b6de3151..46b3293015fe 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -226,7 +226,7 @@ static int stat_open(struct inode *inode, struct file *file)
static const struct proc_ops stat_proc_ops = {
.proc_flags = PROC_ENTRY_PERMANENT,
.proc_open = stat_open,
- .proc_read_iter = seq_read_iter,
+ .proc_read = seq_read,
.proc_lseek = seq_lseek,
.proc_release = single_release,
};
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..552b993c88ef 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -419,42 +419,27 @@ static ssize_t new_sync_read(struct file *filp, char __user *buf, size_t len, lo
return ret;
}
-static int warn_unsupported(struct file *file, const char *op)
-{
- pr_warn_ratelimited(
- "kernel %s not supported for file %pD4 (pid: %d comm: %.20s)\n",
- op, file, current->pid, current->comm);
- return -EINVAL;
-}
-
ssize_t __kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
{
- struct kvec iov = {
- .iov_base = buf,
- .iov_len = min_t(size_t, count, MAX_RW_COUNT),
- };
- struct kiocb kiocb;
- struct iov_iter iter;
+ mm_segment_t old_fs = get_fs();
ssize_t ret;
if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ)))
return -EINVAL;
if (!(file->f_mode & FMODE_CAN_READ))
return -EINVAL;
- /*
- * Also fail if ->read_iter and ->read are both wired up as that
- * implies very convoluted semantics.
- */
- if (unlikely(!file->f_op->read_iter || file->f_op->read))
- return warn_unsupported(file, "read");
- init_sync_kiocb(&kiocb, file);
- kiocb.ki_pos = pos ? *pos : 0;
- iov_iter_kvec(&iter, READ, &iov, 1, iov.iov_len);
- ret = file->f_op->read_iter(&kiocb, &iter);
+ if (count > MAX_RW_COUNT)
+ count = MAX_RW_COUNT;
+ set_fs(KERNEL_DS);
+ if (file->f_op->read)
+ ret = file->f_op->read(file, (void __user *)buf, count, pos);
+ else if (file->f_op->read_iter)
+ ret = new_sync_read(file, (void __user *)buf, count, pos);
+ else
+ ret = -EINVAL;
+ set_fs(old_fs);
if (ret > 0) {
- if (pos)
- *pos = kiocb.ki_pos;
fsnotify_access(file);
add_rchar(current, ret);
}
@@ -525,32 +510,28 @@ static ssize_t new_sync_write(struct file *filp, const char __user *buf, size_t
/* caller is responsible for file_start_write/file_end_write */
ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
{
- struct kvec iov = {
- .iov_base = (void *)buf,
- .iov_len = min_t(size_t, count, MAX_RW_COUNT),
- };
- struct kiocb kiocb;
- struct iov_iter iter;
+ mm_segment_t old_fs;
+ const char __user *p;
ssize_t ret;
if (WARN_ON_ONCE(!(file->f_mode & FMODE_WRITE)))
return -EBADF;
if (!(file->f_mode & FMODE_CAN_WRITE))
return -EINVAL;
- /*
- * Also fail if ->write_iter and ->write are both wired up as that
- * implies very convoluted semantics.
- */
- if (unlikely(!file->f_op->write_iter || file->f_op->write))
- return warn_unsupported(file, "write");
- init_sync_kiocb(&kiocb, file);
- kiocb.ki_pos = pos ? *pos : 0;
- iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len);
- ret = file->f_op->write_iter(&kiocb, &iter);
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ p = (__force const char __user *)buf;
+ if (count > MAX_RW_COUNT)
+ count = MAX_RW_COUNT;
+ if (file->f_op->write)
+ ret = file->f_op->write(file, p, count, pos);
+ else if (file->f_op->write_iter)
+ ret = new_sync_write(file, p, count, pos);
+ else
+ ret = -EINVAL;
+ set_fs(old_fs);
if (ret > 0) {
- if (pos)
- *pos = kiocb.ki_pos;
fsnotify_modify(file);
add_wchar(current, ret);
}
@@ -908,7 +889,7 @@ ssize_t vfs_iter_write(struct file *file, struct iov_iter *iter, loff_t *ppos,
}
EXPORT_SYMBOL(vfs_iter_write);
-static ssize_t vfs_readv(struct file *file, const struct iovec __user *vec,
+ssize_t vfs_readv(struct file *file, const struct iovec __user *vec,
unsigned long vlen, loff_t *pos, rwf_t flags)
{
struct iovec iovstack[UIO_FASTIOV];
diff --git a/fs/splice.c b/fs/splice.c
index 866d5c2367b2..d9305af930d8 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -341,6 +341,89 @@ const struct pipe_buf_operations nosteal_pipe_buf_ops = {
};
EXPORT_SYMBOL(nosteal_pipe_buf_ops);
+static ssize_t kernel_readv(struct file *file, const struct kvec *vec,
+ unsigned long vlen, loff_t offset)
+{
+ mm_segment_t old_fs;
+ loff_t pos = offset;
+ ssize_t res;
+
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ /* The cast to a user pointer is valid due to the set_fs() */
+ res = vfs_readv(file, (const struct iovec __user *)vec, vlen, &pos, 0);
+ set_fs(old_fs);
+
+ return res;
+}
+
+static ssize_t default_file_splice_read(struct file *in, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len,
+ unsigned int flags)
+{
+ struct kvec *vec, __vec[PIPE_DEF_BUFFERS];
+ struct iov_iter to;
+ struct page **pages;
+ unsigned int nr_pages;
+ unsigned int mask;
+ size_t offset, base, copied = 0;
+ ssize_t res;
+ int i;
+
+ if (pipe_full(pipe->head, pipe->tail, pipe->max_usage))
+ return -EAGAIN;
+
+ /*
+ * Try to keep page boundaries matching to source pagecache ones -
+ * it probably won't be much help, but...
+ */
+ offset = *ppos & ~PAGE_MASK;
+
+ iov_iter_pipe(&to, READ, pipe, len + offset);
+
+ res = iov_iter_get_pages_alloc(&to, &pages, len + offset, &base);
+ if (res <= 0)
+ return -ENOMEM;
+
+ nr_pages = DIV_ROUND_UP(res + base, PAGE_SIZE);
+
+ vec = __vec;
+ if (nr_pages > PIPE_DEF_BUFFERS) {
+ vec = kmalloc_array(nr_pages, sizeof(struct kvec), GFP_KERNEL);
+ if (unlikely(!vec)) {
+ res = -ENOMEM;
+ goto out;
+ }
+ }
+
+ mask = pipe->ring_size - 1;
+ pipe->bufs[to.head & mask].offset = offset;
+ pipe->bufs[to.head & mask].len -= offset;
+
+ for (i = 0; i < nr_pages; i++) {
+ size_t this_len = min_t(size_t, len, PAGE_SIZE - offset);
+ vec[i].iov_base = page_address(pages[i]) + offset;
+ vec[i].iov_len = this_len;
+ len -= this_len;
+ offset = 0;
+ }
+
+ res = kernel_readv(in, vec, nr_pages, *ppos);
+ if (res > 0) {
+ copied = res;
+ *ppos += res;
+ }
+
+ if (vec != __vec)
+ kfree(vec);
+out:
+ for (i = 0; i < nr_pages; i++)
+ put_page(pages[i]);
+ kvfree(pages);
+ iov_iter_advance(&to, copied); /* truncates and discards */
+ return res;
+}
+
/*
* Send 'sd->len' bytes to socket from 'sd->file' at position 'sd->pos'
* using sendpage(). Return the number of bytes sent.
@@ -724,6 +807,33 @@ iter_file_splice_write(struct pipe_inode_info *pipe, struct file *out,
EXPORT_SYMBOL(iter_file_splice_write);
+static int write_pipe_buf(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
+ struct splice_desc *sd)
+{
+ int ret;
+ void *data;
+ loff_t tmp = sd->pos;
+
+ data = kmap(buf->page);
+ ret = __kernel_write(sd->u.file, data + buf->offset, sd->len, &tmp);
+ kunmap(buf->page);
+
+ return ret;
+}
+
+static ssize_t default_file_splice_write(struct pipe_inode_info *pipe,
+ struct file *out, loff_t *ppos,
+ size_t len, unsigned int flags)
+{
+ ssize_t ret;
+
+ ret = splice_from_pipe(pipe, out, ppos, len, flags, write_pipe_buf);
+ if (ret > 0)
+ *ppos += ret;
+
+ return ret;
+}
+
/**
* generic_splice_sendpage - splice data from a pipe to a socket
* @pipe: pipe to splice from
@@ -745,23 +855,15 @@ ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe, struct file *out,
EXPORT_SYMBOL(generic_splice_sendpage);
-static int warn_unsupported(struct file *file, const char *op)
-{
- pr_debug_ratelimited(
- "splice %s not supported for file %pD4 (pid: %d comm: %.20s)\n",
- op, file, current->pid, current->comm);
- return -EINVAL;
-}
-
/*
* Attempt to initiate a splice from pipe to file.
*/
static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
- if (unlikely(!out->f_op->splice_write))
- return warn_unsupported(out, "write");
- return out->f_op->splice_write(pipe, out, ppos, len, flags);
+ if (out->f_op->splice_write)
+ return out->f_op->splice_write(pipe, out, ppos, len, flags);
+ return default_file_splice_write(pipe, out, ppos, len, flags);
}
/*
@@ -783,9 +885,9 @@ static long do_splice_to(struct file *in, loff_t *ppos,
if (unlikely(len > MAX_RW_COUNT))
len = MAX_RW_COUNT;
- if (unlikely(!in->f_op->splice_read))
- return warn_unsupported(in, "read");
- return in->f_op->splice_read(in, ppos, pipe, len, flags);
+ if (in->f_op->splice_read)
+ return in->f_op->splice_read(in, ppos, pipe, len, flags);
+ return default_file_splice_read(in, ppos, pipe, len, flags);
}
/**
diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index ed71bd1a0825..2f98d2fce62e 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -136,7 +136,7 @@ int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
int __cgroup_bpf_run_filter_sysctl(struct ctl_table_header *head,
struct ctl_table *table, int write,
- char **buf, size_t *pcount, loff_t *ppos,
+ void **buf, size_t *pcount, loff_t *ppos,
enum bpf_attach_type type);
int __cgroup_bpf_run_filter_setsockopt(struct sock *sock, int *level,
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8bde32cf9711..c2035afe79b0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1910,6 +1910,8 @@ static inline int call_mmap(struct file *file, struct vm_area_struct *vma)
extern ssize_t vfs_read(struct file *, char __user *, size_t, loff_t *);
extern ssize_t vfs_write(struct file *, const char __user *, size_t, loff_t *);
+extern ssize_t vfs_readv(struct file *, const struct iovec __user *,
+ unsigned long, loff_t *, rwf_t);
extern ssize_t vfs_copy_file_range(struct file *, loff_t , struct file *,
loff_t, size_t, unsigned int);
extern ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 000cc0533c33..7b5b0765ff4c 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -30,7 +30,6 @@ struct proc_ops {
unsigned int proc_flags;
int (*proc_open)(struct inode *, struct file *);
ssize_t (*proc_read)(struct file *, char __user *, size_t, loff_t *);
- ssize_t (*proc_read_iter)(struct kiocb *, struct iov_iter *);
ssize_t (*proc_write)(struct file *, const char __user *, size_t, loff_t *);
loff_t (*proc_lseek)(struct file *, loff_t, int);
int (*proc_release)(struct inode *, struct file *);
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index c7c6e8b8344d..e5da080a7181 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -10,7 +10,6 @@
#include <asm/uaccess.h>
-#ifdef CONFIG_SET_FS
/*
* Force the uaccess routines to be wired up for actual userspace access,
* overriding any possible set_fs(KERNEL_DS) still lingering around. Undone
@@ -28,27 +27,10 @@ static inline void force_uaccess_end(mm_segment_t oldfs)
{
set_fs(oldfs);
}
-#else /* CONFIG_SET_FS */
-typedef struct {
- /* empty dummy */
-} mm_segment_t;
-
-#ifndef TASK_SIZE_MAX
+/** #ifndef TASK_SIZE_MAX
#define TASK_SIZE_MAX TASK_SIZE
#endif
-
-#define uaccess_kernel() (false)
-#define user_addr_max() (TASK_SIZE_MAX)
-
-static inline mm_segment_t force_uaccess_begin(void)
-{
- return (mm_segment_t) { };
-}
-
-static inline void force_uaccess_end(mm_segment_t oldfs)
-{
-}
-#endif /* CONFIG_SET_FS */
+*/
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 96555a8a2c54..16dd5aa4cb87 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1226,7 +1226,7 @@ const struct bpf_verifier_ops cg_dev_verifier_ops = {
*/
int __cgroup_bpf_run_filter_sysctl(struct ctl_table_header *head,
struct ctl_table *table, int write,
- char **buf, size_t *pcount, loff_t *ppos,
+ void **buf, size_t *pcount, loff_t *ppos,
enum bpf_attach_type type)
{
struct bpf_sysctl_kern ctx = {
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 4425a1dd4ef1..df903c53952b 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -354,37 +354,50 @@ static const struct test_bitmap_parselist parselist_tests[] __initconst = {
};
-static void __init test_bitmap_parselist(void)
+static void __init __test_bitmap_parselist(int is_user)
{
int i;
int err;
ktime_t time;
DECLARE_BITMAP(bmap, 2048);
+ char *mode = is_user ? "_user" : "";
for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
#define ptest parselist_tests[i]
- time = ktime_get();
- err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
- time = ktime_get() - time;
+ if (is_user) {
+ mm_segment_t orig_fs = get_fs();
+ size_t len = strlen(ptest.in);
+
+ set_fs(KERNEL_DS);
+ time = ktime_get();
+ err = bitmap_parselist_user((__force const char __user *)ptest.in, len,
+ bmap, ptest.nbits);
+ time = ktime_get() - time;
+ set_fs(orig_fs);
+ } else {
+ time = ktime_get();
+ err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
+ time = ktime_get() - time;
+ }
if (err != ptest.errno) {
- pr_err("parselist: %d: input is %s, errno is %d, expected %d\n",
- i, ptest.in, err, ptest.errno);
+ pr_err("parselist%s: %d: input is %s, errno is %d, expected %d\n",
+ mode, i, ptest.in, err, ptest.errno);
continue;
}
if (!err && ptest.expected
&& !__bitmap_equal(bmap, ptest.expected, ptest.nbits)) {
- pr_err("parselist: %d: input is %s, result is 0x%lx, expected 0x%lx\n",
- i, ptest.in, bmap[0],
+ pr_err("parselist%s: %d: input is %s, result is 0x%lx, expected 0x%lx\n",
+ mode, i, ptest.in, bmap[0],
*ptest.expected);
continue;
}
if (ptest.flags & PARSE_TIME)
- pr_err("parselist: %d: input is '%s' OK, Time: %llu\n",
- i, ptest.in, time);
+ pr_err("parselist%s: %d: input is '%s' OK, Time: %llu\n",
+ mode, i, ptest.in, time);
#undef ptest
}
@@ -430,41 +443,75 @@ static const struct test_bitmap_parselist parse_tests[] __initconst = {
#undef step
};
-static void __init test_bitmap_parse(void)
+static void __init __test_bitmap_parse(int is_user)
{
int i;
int err;
ktime_t time;
DECLARE_BITMAP(bmap, 2048);
+ char *mode = is_user ? "_user" : "";
for (i = 0; i < ARRAY_SIZE(parse_tests); i++) {
struct test_bitmap_parselist test = parse_tests[i];
- size_t len = test.flags & NO_LEN ? UINT_MAX : strlen(test.in);
- time = ktime_get();
- err = bitmap_parse(test.in, len, bmap, test.nbits);
- time = ktime_get() - time;
+ if (is_user) {
+ size_t len = strlen(test.in);
+ mm_segment_t orig_fs = get_fs();
+
+ set_fs(KERNEL_DS);
+ time = ktime_get();
+ err = bitmap_parse_user((__force const char __user *)test.in, len,
+ bmap, test.nbits);
+ time = ktime_get() - time;
+ set_fs(orig_fs);
+ } else {
+ size_t len = test.flags & NO_LEN ?
+ UINT_MAX : strlen(test.in);
+ time = ktime_get();
+ err = bitmap_parse(test.in, len, bmap, test.nbits);
+ time = ktime_get() - time;
+ }
if (err != test.errno) {
- pr_err("parse: %d: input is %s, errno is %d, expected %d\n",
- i, test.in, err, test.errno);
+ pr_err("parse%s: %d: input is %s, errno is %d, expected %d\n",
+ mode, i, test.in, err, test.errno);
continue;
}
if (!err && test.expected
&& !__bitmap_equal(bmap, test.expected, test.nbits)) {
- pr_err("parse: %d: input is %s, result is 0x%lx, expected 0x%lx\n",
- i, test.in, bmap[0],
+ pr_err("parse%s: %d: input is %s, result is 0x%lx, expected 0x%lx\n",
+ mode, i, test.in, bmap[0],
*test.expected);
continue;
}
if (test.flags & PARSE_TIME)
- pr_err("parse: %d: input is '%s' OK, Time: %llu\n",
- i, test.in, time);
+ pr_err("parse%s: %d: input is '%s' OK, Time: %llu\n",
+ mode, i, test.in, time);
}
}
+static void __init test_bitmap_parselist(void)
+{
+ __test_bitmap_parselist(0);
+}
+
+static void __init test_bitmap_parselist_user(void)
+{
+ __test_bitmap_parselist(1);
+}
+
+static void __init test_bitmap_parse(void)
+{
+ __test_bitmap_parse(0);
+}
+
+static void __init test_bitmap_parse_user(void)
+{
+ __test_bitmap_parse(1);
+}
+
#define EXP1_IN_BITS (sizeof(exp1) * 8)
static void __init test_bitmap_arr32(void)
@@ -628,7 +675,9 @@ static void __init selftest(void)
test_replace();
test_bitmap_arr32();
test_bitmap_parse();
+ test_bitmap_parse_user();
test_bitmap_parselist();
+ test_bitmap_parselist_user();
test_mem_optimisations();
test_for_each_set_clump8();
test_bitmap_cut();
diff --git a/tools/testing/selftests/lkdtm/tests.txt b/tools/testing/selftests/lkdtm/tests.txt
index 74a8d329a72c..9d266e79c6a2 100644
--- a/tools/testing/selftests/lkdtm/tests.txt
+++ b/tools/testing/selftests/lkdtm/tests.txt
@@ -9,6 +9,7 @@ EXCEPTION
#CORRUPT_STACK_STRONG Crashes entire system on success
CORRUPT_LIST_ADD list_add corruption
CORRUPT_LIST_DEL list_del corruption
+CORRUPT_USER_DS Invalid address limit on user-mode return
STACK_GUARD_PAGE_LEADING
STACK_GUARD_PAGE_TRAILING
UNSET_SMEP CR4 bits went missing
@@ -66,5 +67,6 @@ USERCOPY_STACK_FRAME_TO
USERCOPY_STACK_FRAME_FROM
USERCOPY_STACK_BEYOND
USERCOPY_KERNEL
+USERCOPY_KERNEL_DS
STACKLEAK_ERASING OK: the rest of the thread stack is properly erased
CFI_FORWARD_PROTO
--
2.29.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-08 12:54 Metztli Information Technology
@ 2021-02-08 16:03 ` Edward Shishkin
2021-02-16 15:56 ` Jose R Rodriguez
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Edward Shishkin @ 2021-02-08 16:03 UTC (permalink / raw)
To: Metztli Information Technology, reiserfs-devel, hch, linux-kernel
On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <edward.shishkin@gmail.com> wrote:
>>
>> On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
>>> Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
>>>
>>> I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i).
>>> The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
>>>
>>> Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image.
>>>
>>> Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16:
>>> ...
>>> Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
>>> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
>>> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
>>> Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
>>> Dec 22 20:19:56 debootstrap: E: NOEXEC
>>> Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
>>> Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed
>>> Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
>>> Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.
>>> Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb
>>>
>>
>> [...]
>>
>>>
>>> Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned.
>>> Notwithstanding, I manually verified that I am able to touch a file and set it +x executable.
>>>
>>> Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with
>>> an apparently related error --can not proceed any further.
>>>
>>> Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output
>>> from an attempt on my physical development machine.
>>> ...
>>> [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4.
>>> [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
>>> [ 509.326270] device-mapper: uevent: version 1.0.3
>>> [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
>>> [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
>>> [ 509.915300] sdb: sdb1 sdb2 sdb3
>>> [ 511.973360] sdb: sdb1 sdb2 sdb3
>>> [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS
>>> [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
>>> [ 636.240812] NOTICE: brick /dev/sda6 has been registered
>>> [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
>>> [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
>>> [ 643.759980] reiser4: brick /dev/sda6 activated
>>> [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
>>> [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
>>> [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
>>> [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*]
>>> [ 898.761385] reiser4: brick /dev/sda6 deactivated
>>> [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
>>> [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
>>> [ 999.093480] reiser4: brick /dev/sda6 activated
>>> [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
>>> [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
>>> [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
>>> [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap)
>>> [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot)
>>
>>
>> Hello.
>>
>> This is because of VFS changes in Linux-5.10.X.
>> Specifically, because of the following patch:
>> https://lkml.org/lkml/2020/8/17/174
>> In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
>>
>> So, Christoph, what to do now for file systems which implement
>> ->read() method of file operations?
>
> *deafening silence* it appears that -- in the best of cases -- Christoph engaged in an act of _iter masturbation [1];
> and in the worst of cases, the gentleman was aiming straight at reiser4.
>
>> ... It seems that chroot doesn't work
>> for them. And people are not able to release distros with upgraded
>> kernels..
>
> Not only 'chroot doesn't work' for us, but even after replacing the kernel in a reiser4 (proper SFRN ;) instance and
> upon an initial Linux 5.10.x kernel boot:
> ...
> kernel read not supported for file usr/lib/systemd/systemd (pid: 1 comm: run-init)
> kernel panic -- not syncing: Attempted to kill init! exitcod=0x00000100
> ...
>
> Fact is some of us have commercial interests when deploying reiser4, both in cloud instances, baremetal, and on-premises.
>
> In the future if -- and only if -- our reiser4 efforts come to successful fruition, quite likely in due time we will be
> able to financially commit to the Penguin's Linux Foundation temple, just like large corporations do
> in exchange for indulgences[2] which virtue-wash their past and/or current corp. officers' *substantially darker deeds*;
> heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU) that 'virtuous' cult of GNU/Linux
> developers/gatekeepers/maintainers' frivolous, *narcissist*, ethics and/or moralities so often piled up against
> Reiser's work --which, paradoxically(!?), actually was largely implemented by Russian developers ;)
>
> In the meantime, I hacked a reverse patch that undoes some(all) of the surreptitious lethal attack on reiser4 fs
> -- at least on AMD64 architectures (I did away with other arch/Kconfigs).
> And no, I am not a git pro-, undoing what I could of commit 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> does not fix the 'kernel read' issue.
>
> Notwithstanding, I would appreciate if you can take a look at the attached patch. Probably it can be streamlined and/or improved
> further to minimize pain on subsequent Linux kernel upgrades.
That patch is an attempt to swim against the current ;)
I no longer remember, why they want to get rid of set_fs for already 15
years, but ->read() and ->write() methods seem to be deprecated, and the
correct way would be to implement the new ->read_iter() and write_iter()
methods, where reiser4 works with "chunked" streams, represented by
iov_iter structure, rather than with "continuous" streams, represented
by char __user *buf. The task is not that difficult, but rather time
consuming - I don't have a time for this right now..
Thanks,
Edward.
>
> The patch has been tested in my local development machine environment --
> as I intalled the generated reiser4 -enabled linux 5.10.13/14 meta/kernel into a Debian Bullseye already running reiser4 (with proper SFRN)
> and the kernel booted nicely. Subsequently, after installing the linux headers, etc. I built a couple of upgraded kernels
> in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus the hack seems to be stable.
>
> Additionally, I have just made a Debian-Installer (d-i) with a 'kernel read' -patched Linux 5.10.14.1 which successfully installed
> into a VirtualBox 6.1.18 VM:
> < https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png >
>
>>
>> Thanks,
>> Edward.
>
> Best Professional Regards.
>
> [1]
> "The bug was fixed, again way back in 2010, and over time chip-designers have moved on to improved memory management techniques.
> Torvalds wrote that this sort of memory space override has been banished from the x86, powerpc, s390 and RISC-V architectures."
> < https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
>
> [2] https://www.britannica.com/topic/indulgence
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-08 16:03 ` Edward Shishkin
@ 2021-02-16 15:56 ` Jose R Rodriguez
2021-02-16 20:02 ` Edward Shishkin
2021-08-04 10:17 ` Metztli Information Technology
2021-08-13 15:20 ` Metztli Information Technology
2 siblings, 1 reply; 13+ messages in thread
From: Jose R Rodriguez @ 2021-02-16 15:56 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, hch, linux-kernel
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
> On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
> > edward.shishkin@gmail.com> wrote:
> > >
> > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > > >
> > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
> > > > usual -- to generate a kernel component for my Debian-Installer
> > > > (d-i).
> > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
> > > > unstable.
> > > >
> > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated
> > > > one set of components for d-i I built the d-i image.
> > > >
> > > > Fact is, the installer throws an error in *both* bare metal and
> > > > VirtualBox 6.1.16:
> > > > ...
> > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
> > > > base' selected
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
> > > > components=main --debian-installer --resolve-deps --
> > > > keyring=/usr/share/keyrings/archive.gpg buster /target
> > > > http://deb.debian.org/debian/
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
> > > > /target/test-exec: Invalid argument
> > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
> > > > supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target
> > > > '/target' mounted with noexec or nodev
> > > > Dec 22 20:20:12 base-installer: error: exiting on error base-
> > > > installer/debootstrap-failed
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
> > > > 'bootstrap-base' failed with error code 1
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
> > > > 'bootstrap-base' failed.
> > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
> > > > package description for brltty-udeb
> > > >
> > >
> > > [...]
> > >
> > > >
> > > > Apparently, d-i [Debian-installer] complains about being unable
> > > > to set the test file executable and causes the error when 1 is
> > > > returned.
> > > > Notwithstanding, I manually verified that I am able to touch a
> > > > file and set it +x executable.
> > > >
> > > > Furthermore, tricking the function return value to 0 I am able
> > > > to make d-i continue with the latest SFRN5 installation (see
> > > > [*trick*] below); yet, subsequently halts again with
> > > > an apparently related error --can not proceed any further.
> > > >
> > > > Digging deeper with dmesg, we can see that apparently it is the
> > > > kernel which cannot 'read' properly. Please find a partial
> > > > dmesg log with relevant output
> > > > from an attempt on my physical development machine.
> > > > ...
> > > > [ 508.614488] Loading Reiser4 (Software Framework Release:
> > > > 5.1.3). See reiser4.wiki.kernel.org for a description of
> > > > Reiser4.
> > > > [ 508.661951] SGI XFS with ACLs, security attributes,
> > > > realtime, quota, no debug enabled
> > > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
> > > > initialised: dm-devel@redhat.com
> > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
> > > > extents:1 across:9765884k FS
> > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
> > > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 643.813488] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 648.168730] kernel read not supported for file /test-exec
> > > > (pid: 9876 comm: debootstrap) [*trick*]
> > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 6373.748413] kernel read not supported for file /test-exec
> > > > (pid: 10094 comm: debootstrap)
> > > > [ 6413.169920] kernel read not supported for file /usr/bin/true
> > > > (pid: 15960 comm: chroot)
> > >
> > >
> > > Hello.
> > >
> > > This is because of VFS changes in Linux-5.10.X.
> > > Specifically, because of the following patch:
> > > https://lkml.org/lkml/2020/8/17/174
> > > In the upstream git repository it is commit
> > > 4d03e3cc59828c82ee89ea6e2
> > >
> > > So, Christoph, what to do now for file systems which implement
> > > ->read() method of file operations?
> >
> > *deafening silence* it appears that -- in the best of cases --
> > Christoph engaged in an act of _iter masturbation [1];
> > and in the worst of cases, the gentleman was aiming straight at
> > reiser4.
> >
> > > ... It seems that chroot doesn't work
> > > for them. And people are not able to release distros with
> > > upgraded
> > > kernels..
> >
> > Not only 'chroot doesn't work' for us, but even after replacing the
> > kernel in a reiser4 (proper SFRN ;) instance and
> > upon an initial Linux 5.10.x kernel boot:
> > ...
> > kernel read not supported for file usr/lib/systemd/systemd (pid: 1
> > comm: run-init)
> > kernel panic -- not syncing: Attempted to kill init!
> > exitcod=0x00000100
> > ...
> >
> > Fact is some of us have commercial interests when deploying
> > reiser4, both in cloud instances, baremetal, and on-premises.
> >
> > In the future if -- and only if -- our reiser4 efforts come to
> > successful fruition, quite likely in due time we will be
> > able to financially commit to the Penguin's Linux Foundation
> > temple, just like large corporations do
> > in exchange for indulgences[2] which virtue-wash their past
> > and/or current corp. officers' *substantially darker deeds*;
> > heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
> > that 'virtuous' cult of GNU/Linux
> > developers/gatekeepers/maintainers' frivolous, *narcissist*,
> > ethics and/or moralities so often piled up against
> > Reiser's work --which, paradoxically(!?), actually was largely
> > implemented by Russian developers ;)
> >
> > In the meantime, I hacked a reverse patch that undoes some(all) of
> > the surreptitious lethal attack on reiser4 fs
> > -- at least on AMD64 architectures (I did away with other
> > arch/Kconfigs).
> > And no, I am not a git pro-, undoing what I could of commit
> > 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> > does not fix the 'kernel read' issue.
> >
> > Notwithstanding, I would appreciate if you can take a look at the
> > attached patch. Probably it can be streamlined and/or improved
> > further to minimize pain on subsequent Linux kernel upgrades.
>
>
> That patch is an attempt to swim against the current ;)
In a sense all of us who prefer reiser4 do not have a herd mentality.
So, yes, we 'swim against the current', if you will put it in those
terms, because we value data integrity (atomicity).
Notwithstanding, it is only an ephemeral hack for AMD64 architectures.
I have running locally reiser4 -enabled 5.10.13-2, 5.10.14-2, whereas I
have an Google Compute Engine (GCE), on an AMD Epyc (reizer4 label)
zone, custom instance testing with a cloud kernel 5.10.15-2.
< https://metztli.it/buster/cloud-5.10.15-2+reizer4_0_2.png >
Heck, I have updated the reiser4, Software Framework Release Number
(SFRN) 5.1.3, d-i netboot installer media with a test kernel 5.10.16-2
< https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso
>
<
https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso.SHA256SUM
>
... крутые?
>
> I no longer remember, why they want to get rid of set_fs for already
> 15
> years, but ->read() and ->write() methods seem to be deprecated, and
> the
> correct way would be to implement the new ->read_iter() and
> write_iter()
> methods, where reiser4 works with "chunked" streams, represented by
> iov_iter structure, rather than with "continuous" streams,
> represented
> by char __user *buf. The task is not that difficult, but rather time
> consuming - I don't have a time for this right now..
>
> Thanks,
> Edward.
>
> >
> > The patch has been tested in my local development machine
> > environment --
> > as I intalled the generated reiser4 -enabled linux 5.10.13/14
> > meta/kernel into a Debian Bullseye already running reiser4 (with
> > proper SFRN)
> > and the kernel booted nicely. Subsequently, after installing the
> > linux headers, etc. I built a couple of upgraded kernels
> > in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus
> > the hack seems to be stable.
> >
> > Additionally, I have just made a Debian-Installer (d-i) with a
> > 'kernel read' -patched Linux 5.10.14.1 which successfully installed
> > into a VirtualBox 6.1.18 VM:
> > <
> > https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png
> > >
> >
> > >
> > > Thanks,
> > > Edward.
> >
> > Best Professional Regards.
> >
> > [1]
> > "The bug was fixed, again way back in 2010, and over time chip-
> > designers have moved on to improved memory management techniques.
> > Torvalds wrote that this sort of memory space override has been
> > banished from the x86, powerpc, s390 and RISC-V architectures."
> > < https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
> >
> > [2] https://www.britannica.com/topic/indulgence
> >
Best Professional Regards.
--
Jose R R
http://metztli.it
-----------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
-----------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-----------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-----------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-16 15:56 ` Jose R Rodriguez
@ 2021-02-16 20:02 ` Edward Shishkin
2021-02-19 8:12 ` Jose R Rodriguez
0 siblings, 1 reply; 13+ messages in thread
From: Edward Shishkin @ 2021-02-16 20:02 UTC (permalink / raw)
To: Jose R Rodriguez; +Cc: reiserfs-devel, linux-kernel
On 02/16/2021 04:56 PM, Jose R Rodriguez wrote:
> On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
>> On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
>>> On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
>>> edward.shishkin@gmail.com> wrote:
>>>>
>>>> On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
>>>>> Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
>>>>>
>>>>> I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
>>>>> usual -- to generate a kernel component for my Debian-Installer
>>>>> (d-i).
>>>>> The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
>>>>> unstable.
>>>>>
>>>>> Once I built the proper reiser4progs-2.0.4.tar.gz and generated
>>>>> one set of components for d-i I built the d-i image.
>>>>>
>>>>> Fact is, the installer throws an error in *both* bare metal and
>>>>> VirtualBox 6.1.16:
>>>>> ...
>>>>> Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
>>>>> base' selected
>>>>> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
>>>>> components=main --debian-installer --resolve-deps --
>>>>> keyring=/usr/share/keyrings/archive.gpg buster /target
>>>>> http://deb.debian.org/debian/
>>>>> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
>>>>> /target/test-exec: Invalid argument
>>>>> Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
>>>>> supported for file /test-exec (pid: 10077 comm: debootstrap)
>>>>> Dec 22 20:19:56 debootstrap: E: NOEXEC
>>>>> Dec 22 20:19:56 debootstrap: EF: Cannot install into target
>>>>> '/target' mounted with noexec or nodev
>>>>> Dec 22 20:20:12 base-installer: error: exiting on error base-
>>>>> installer/debootstrap-failed
>>>>> Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
>>>>> 'bootstrap-base' failed with error code 1
>>>>> Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
>>>>> 'bootstrap-base' failed.
>>>>> Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
>>>>> package description for brltty-udeb
>>>>>
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> Apparently, d-i [Debian-installer] complains about being unable
>>>>> to set the test file executable and causes the error when 1 is
>>>>> returned.
>>>>> Notwithstanding, I manually verified that I am able to touch a
>>>>> file and set it +x executable.
>>>>>
>>>>> Furthermore, tricking the function return value to 0 I am able
>>>>> to make d-i continue with the latest SFRN5 installation (see
>>>>> [*trick*] below); yet, subsequently halts again with
>>>>> an apparently related error --can not proceed any further.
>>>>>
>>>>> Digging deeper with dmesg, we can see that apparently it is the
>>>>> kernel which cannot 'read' properly. Please find a partial
>>>>> dmesg log with relevant output
>>>>> from an attempt on my physical development machine.
>>>>> ...
>>>>> [ 508.614488] Loading Reiser4 (Software Framework Release:
>>>>> 5.1.3). See reiser4.wiki.kernel.org for a description of
>>>>> Reiser4.
>>>>> [ 508.661951] SGI XFS with ACLs, security attributes,
>>>>> realtime, quota, no debug enabled
>>>>> [ 509.326270] device-mapper: uevent: version 1.0.3
>>>>> [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
>>>>> initialised: dm-devel@redhat.com
>>>>> [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
>>>>> [ 509.915300] sdb: sdb1 sdb2 sdb3
>>>>> [ 511.973360] sdb: sdb1 sdb2 sdb3
>>>>> [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
>>>>> extents:1 across:9765884k FS
>>>>> [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
>>>>> (fs/reiser4/init_volume.c:222)[edward-1932]:
>>>>> [ 636.240812] NOTICE: brick /dev/sda6 has been registered
>>>>> [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
>>>>> [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
>>>>> Model.
>>>>> [ 643.759980] reiser4: brick /dev/sda6 activated
>>>>> [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
>>>>> the ext4 subsystem
>>>>> [ 643.813474] EXT4-fs (sda1): mounted filesystem without
>>>>> journal. Opts: (null)
>>>>> [ 643.813488] ext2 filesystem being mounted at /target/boot
>>>>> supports timestamps until 2038 (0x7fffffff)
>>>>> [ 648.168730] kernel read not supported for file /test-exec
>>>>> (pid: 9876 comm: debootstrap) [*trick*]
>>>>> [ 898.761385] reiser4: brick /dev/sda6 deactivated
>>>>> [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
>>>>> [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
>>>>> Model.
>>>>> [ 999.093480] reiser4: brick /dev/sda6 activated
>>>>> [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
>>>>> the ext4 subsystem
>>>>> [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
>>>>> journal. Opts: (null)
>>>>> [ 1009.362737] ext2 filesystem being mounted at /target/boot
>>>>> supports timestamps until 2038 (0x7fffffff)
>>>>> [ 6373.748413] kernel read not supported for file /test-exec
>>>>> (pid: 10094 comm: debootstrap)
>>>>> [ 6413.169920] kernel read not supported for file /usr/bin/true
>>>>> (pid: 15960 comm: chroot)
>>>>
>>>>
>>>> Hello.
>>>>
>>>> This is because of VFS changes in Linux-5.10.X.
>>>> Specifically, because of the following patch:
>>>> https://lkml.org/lkml/2020/8/17/174
>>>> In the upstream git repository it is commit
>>>> 4d03e3cc59828c82ee89ea6e2
>>>>
>>>> So, Christoph, what to do now for file systems which implement
>>>> ->read() method of file operations?
>>>
>>> *deafening silence* it appears that -- in the best of cases --
>>> Christoph engaged in an act of _iter masturbation [1];
>>> and in the worst of cases, the gentleman was aiming straight at
>>> reiser4.
>>>
>>>> ... It seems that chroot doesn't work
>>>> for them. And people are not able to release distros with
>>>> upgraded
>>>> kernels..
>>>
>>> Not only 'chroot doesn't work' for us, but even after replacing the
>>> kernel in a reiser4 (proper SFRN ;) instance and
>>> upon an initial Linux 5.10.x kernel boot:
>>> ...
>>> kernel read not supported for file usr/lib/systemd/systemd (pid: 1
>>> comm: run-init)
>>> kernel panic -- not syncing: Attempted to kill init!
>>> exitcod=0x00000100
>>> ...
>>>
>>> Fact is some of us have commercial interests when deploying
>>> reiser4, both in cloud instances, baremetal, and on-premises.
>>>
>>> In the future if -- and only if -- our reiser4 efforts come to
>>> successful fruition, quite likely in due time we will be
>>> able to financially commit to the Penguin's Linux Foundation
>>> temple, just like large corporations do
>>> in exchange for indulgences[2] which virtue-wash their past
>>> and/or current corp. officers' *substantially darker deeds*;
>>> heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
>>> that 'virtuous' cult of GNU/Linux
>>> developers/gatekeepers/maintainers' frivolous, *narcissist*,
>>> ethics and/or moralities so often piled up against
>>> Reiser's work --which, paradoxically(!?), actually was largely
>>> implemented by Russian developers ;)
>>>
>>> In the meantime, I hacked a reverse patch that undoes some(all) of
>>> the surreptitious lethal attack on reiser4 fs
>>> -- at least on AMD64 architectures (I did away with other
>>> arch/Kconfigs).
>>> And no, I am not a git pro-, undoing what I could of commit
>>> 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
>>> does not fix the 'kernel read' issue.
>>>
>>> Notwithstanding, I would appreciate if you can take a look at the
>>> attached patch. Probably it can be streamlined and/or improved
>>> further to minimize pain on subsequent Linux kernel upgrades.
>>
>>
>> That patch is an attempt to swim against the current ;)
> In a sense all of us who prefer reiser4 do not have a herd mentality.
> So, yes, we 'swim against the current', if you will put it in those
> terms, because we value data integrity (atomicity).
Cool.
Do you have resources to support such fork?
>
> Notwithstanding, it is only an ephemeral hack for AMD64 architectures.
> I have running locally reiser4 -enabled 5.10.13-2, 5.10.14-2, whereas I
> have an Google Compute Engine (GCE), on an AMD Epyc (reizer4 label)
> zone, custom instance testing with a cloud kernel 5.10.15-2.
>
> < https://metztli.it/buster/cloud-5.10.15-2+reizer4_0_2.png >
>
> Heck, I have updated the reiser4, Software Framework Release Number
> (SFRN) 5.1.3, d-i netboot installer media with a test kernel 5.10.16-2
> < https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso
Note that fsck.reiser4 still doesn't work with 5.1.3
Thanks,
Edward.
>>
> <
> https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso.SHA256SUM
>>
>
> ... крутые?
>>
>> I no longer remember, why they want to get rid of set_fs for already
>> 15
>> years, but ->read() and ->write() methods seem to be deprecated, and
>> the
>> correct way would be to implement the new ->read_iter() and
>> write_iter()
>> methods, where reiser4 works with "chunked" streams, represented by
>> iov_iter structure, rather than with "continuous" streams,
>> represented
>> by char __user *buf. The task is not that difficult, but rather time
>> consuming - I don't have a time for this right now..
>>
>> Thanks,
>> Edward.
>>
>>>
>>> The patch has been tested in my local development machine
>>> environment --
>>> as I intalled the generated reiser4 -enabled linux 5.10.13/14
>>> meta/kernel into a Debian Bullseye already running reiser4 (with
>>> proper SFRN)
>>> and the kernel booted nicely. Subsequently, after installing the
>>> linux headers, etc. I built a couple of upgraded kernels
>>> in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus
>>> the hack seems to be stable.
>>>
>>> Additionally, I have just made a Debian-Installer (d-i) with a
>>> 'kernel read' -patched Linux 5.10.14.1 which successfully installed
>>> into a VirtualBox 6.1.18 VM:
>>> <
>>> https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png
>>> >
>>>
>>>>
>>>> Thanks,
>>>> Edward.
>>>
>>> Best Professional Regards.
>>>
>>> [1]
>>> "The bug was fixed, again way back in 2010, and over time chip-
>>> designers have moved on to improved memory management techniques.
>>> Torvalds wrote that this sort of memory space override has been
>>> banished from the x86, powerpc, s390 and RISC-V architectures."
>>> < https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
>>>
>>> [2] https://www.britannica.com/topic/indulgence
>>>
>
> Best Professional Regards.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-16 20:02 ` Edward Shishkin
@ 2021-02-19 8:12 ` Jose R Rodriguez
2021-02-26 7:33 ` Jose R Rodriguez
0 siblings, 1 reply; 13+ messages in thread
From: Jose R Rodriguez @ 2021-02-19 8:12 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 13459 bytes --]
On Tue, 2021-02-16 at 21:02 +0100, Edward Shishkin wrote:
>
>
> On 02/16/2021 04:56 PM, Jose R Rodriguez wrote:
> > On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
> > > On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> > > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
> > > > edward.shishkin@gmail.com> wrote:
> > > > >
> > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > > > > >
> > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
> > > > > > usual -- to generate a kernel component for my Debian-Installer
> > > > > > (d-i).
> > > > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
> > > > > > unstable.
> > > > > >
> > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated
> > > > > > one set of components for d-i I built the d-i image.
> > > > > >
> > > > > > Fact is, the installer throws an error in *both* bare metal and
> > > > > > VirtualBox 6.1.16:
> > > > > > ...
> > > > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
> > > > > > base' selected
> > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
> > > > > > components=main --debian-installer --resolve-deps --
> > > > > > keyring=/usr/share/keyrings/archive.gpg buster /target
> > > > > > http://deb.debian.org/debian/
> > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
> > > > > > /target/test-exec: Invalid argument
> > > > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
> > > > > > supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > > > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target
> > > > > > '/target' mounted with noexec or nodev
> > > > > > Dec 22 20:20:12 base-installer: error: exiting on error base-
> > > > > > installer/debootstrap-failed
> > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
> > > > > > 'bootstrap-base' failed with error code 1
> > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
> > > > > > 'bootstrap-base' failed.
> > > > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
> > > > > > package description for brltty-udeb
> > > > > >
> > > > >
> > > > > [...]
> > > > >
> > > > > >
> > > > > > Apparently, d-i [Debian-installer] complains about being unable
> > > > > > to set the test file executable and causes the error when 1 is
> > > > > > returned.
> > > > > > Notwithstanding, I manually verified that I am able to touch a
> > > > > > file and set it +x executable.
> > > > > >
> > > > > > Furthermore, tricking the function return value to 0 I am able
> > > > > > to make d-i continue with the latest SFRN5 installation (see
> > > > > > [*trick*] below); yet, subsequently halts again with
> > > > > > an apparently related error --can not proceed any further.
> > > > > >
> > > > > > Digging deeper with dmesg, we can see that apparently it is the
> > > > > > kernel which cannot 'read' properly. Please find a partial
> > > > > > dmesg log with relevant output
> > > > > > from an attempt on my physical development machine.
> > > > > > ...
> > > > > > [ 508.614488] Loading Reiser4 (Software Framework Release:
> > > > > > 5.1.3). See reiser4.wiki.kernel.org for a description of
> > > > > > Reiser4.
> > > > > > [ 508.661951] SGI XFS with ACLs, security attributes,
> > > > > > realtime, quota, no debug enabled
> > > > > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
> > > > > > initialised: dm-devel@redhat.com
> > > > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > > > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > > > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
> > > > > > extents:1 across:9765884k FS
> > > > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
> > > > > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > > > Model.
> > > > > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
> > > > > > the ext4 subsystem
> > > > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without
> > > > > > journal. Opts: (null)
> > > > > > [ 643.813488] ext2 filesystem being mounted at /target/boot
> > > > > > supports timestamps until 2038 (0x7fffffff)
> > > > > > [ 648.168730] kernel read not supported for file /test-exec
> > > > > > (pid: 9876 comm: debootstrap) [*trick*]
> > > > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > > > Model.
> > > > > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
> > > > > > the ext4 subsystem
> > > > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
> > > > > > journal. Opts: (null)
> > > > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot
> > > > > > supports timestamps until 2038 (0x7fffffff)
> > > > > > [ 6373.748413] kernel read not supported for file /test-exec
> > > > > > (pid: 10094 comm: debootstrap)
> > > > > > [ 6413.169920] kernel read not supported for file /usr/bin/true
> > > > > > (pid: 15960 comm: chroot)
> > > > >
> > > > >
> > > > > Hello.
> > > > >
> > > > > This is because of VFS changes in Linux-5.10.X.
> > > > > Specifically, because of the following patch:
> > > > > https://lkml.org/lkml/2020/8/17/174
> > > > > In the upstream git repository it is commit
> > > > > 4d03e3cc59828c82ee89ea6e2
> > > > >
> > > > > So, Christoph, what to do now for file systems which implement
> > > > > ->read() method of file operations?
> > > >
> > > > *deafening silence* it appears that -- in the best of cases --
> > > > Christoph engaged in an act of _iter masturbation [1];
> > > > and in the worst of cases, the gentleman was aiming straight at
> > > > reiser4.
> > > >
> > > > > ... It seems that chroot doesn't work
> > > > > for them. And people are not able to release distros with
> > > > > upgraded
> > > > > kernels..
> > > >
> > > > Not only 'chroot doesn't work' for us, but even after replacing the
> > > > kernel in a reiser4 (proper SFRN ;) instance and
> > > > upon an initial Linux 5.10.x kernel boot:
> > > > ...
> > > > kernel read not supported for file usr/lib/systemd/systemd (pid: 1
> > > > comm: run-init)
> > > > kernel panic -- not syncing: Attempted to kill init!
> > > > exitcod=0x00000100
> > > > ...
> > > >
> > > > Fact is some of us have commercial interests when deploying
> > > > reiser4, both in cloud instances, baremetal, and on-premises.
> > > >
> > > > In the future if -- and only if -- our reiser4 efforts come to
> > > > successful fruition, quite likely in due time we will be
> > > > able to financially commit to the Penguin's Linux Foundation
> > > > temple, just like large corporations do
> > > > in exchange for indulgences[2] which virtue-wash their past
> > > > and/or current corp. officers' *substantially darker deeds*;
> > > > heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
> > > > that 'virtuous' cult of GNU/Linux
> > > > developers/gatekeepers/maintainers' frivolous, *narcissist*,
> > > > ethics and/or moralities so often piled up against
> > > > Reiser's work --which, paradoxically(!?), actually was largely
> > > > implemented by Russian developers ;)
> > > >
> > > > In the meantime, I hacked a reverse patch that undoes some(all) of
> > > > the surreptitious lethal attack on reiser4 fs
> > > > -- at least on AMD64 architectures (I did away with other
> > > > arch/Kconfigs).
> > > > And no, I am not a git pro-, undoing what I could of commit
> > > > 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> > > > does not fix the 'kernel read' issue.
> > > >
> > > > Notwithstanding, I would appreciate if you can take a look at the
> > > > attached patch. Probably it can be streamlined and/or improved
> > > > further to minimize pain on subsequent Linux kernel upgrades.
> > >
> > >
> > > That patch is an attempt to swim against the current ;)
> > In a sense all of us who prefer reiser4 do not have a herd mentality.
> > So, yes, we 'swim against the current', if you will put it in those
> > terms, because we value data integrity (atomicity).
>
>
> Cool.
> Do you have resources to support such fork?
Well, I have 10 Gig storage slice in Yandex ;) Likely if I visit the site with
more frequency I might call out the US/NATO's trolls who immediate gang-up on
anyone who expresses anything positive about the President of the Russian
Federation. :)
>
>
> >
> > Notwithstanding, it is only an ephemeral hack for AMD64 architectures.
Reiterating, 'ephemeral hack' and not a fork per se.
> > I have running locally reiser4 -enabled 5.10.13-2, 5.10.14-2, whereas I
> > have an Google Compute Engine (GCE), on an AMD Epyc (reizer4 label)
> > zone, custom instance testing with a cloud kernel 5.10.15-2.
> >
> > < https://metztli.it/buster/cloud-5.10.15-2+reizer4_0_2.png >
> >
> > Heck, I have updated the reiser4, Software Framework Release Number
> > (SFRN) 5.1.3, d-i netboot installer media with a test kernel 5.10.16-2
> > < https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso
>
>
> Note that fsck.reiser4 still doesn't work with 5.1.3
*That* I was unaware, Sir.
>
> Thanks,
> Edward.
>
>
> > >
> > <
> >
> > https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso.SHA256SUM
> > >
> >
> > ... крутые?
> > >
> > > I no longer remember, why they want to get rid of set_fs for already
> > > 15
> > > years, but ->read() and ->write() methods seem to be deprecated, and
> > > the
> > > correct way would be to implement the new ->read_iter() and
> > > write_iter()
> > > methods, where reiser4 works with "chunked" streams, represented by
> > > iov_iter structure, rather than with "continuous" streams,
> > > represented
> > > by char __user *buf. The task is not that difficult, but rather time
> > > consuming - I don't have a time for this right now..
> > >
> > > Thanks,
> > > Edward.
> > >
> > > >
> > > > The patch has been tested in my local development machine
> > > > environment --
> > > > as I intalled the generated reiser4 -enabled linux 5.10.13/14
> > > > meta/kernel into a Debian Bullseye already running reiser4 (with
> > > > proper SFRN)
> > > > and the kernel booted nicely. Subsequently, after installing the
> > > > linux headers, etc. I built a couple of upgraded kernels
> > > > in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus
> > > > the hack seems to be stable.
> > > >
> > > > Additionally, I have just made a Debian-Installer (d-i) with a
> > > > 'kernel read' -patched Linux 5.10.14.1 which successfully installed
> > > > into a VirtualBox 6.1.18 VM:
> > > > <
> > > >
> > > > https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png
> > > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Edward.
> > > >
> > > > Best Professional Regards.
> > > >
> > > > [1]
> > > > "The bug was fixed, again way back in 2010, and over time chip-
> > > > designers have moved on to improved memory management techniques.
> > > > Torvalds wrote that this sort of memory space override has been
> > > > banished from the x86, powerpc, s390 and RISC-V architectures."
> > > > < https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
> > > >
> > > > [2] https://www.britannica.com/topic/indulgence
> > > >
Given the fact that my custom Debian Installer netboot image defaults to a
~500MB JFS boot partition while all the others default to reiser4, there is a
patch from JFS for 5.11 which applies nicely onto kernel 5.10.[0-14]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=9867cb1fd510187d8f828540bdb48f78fceb70b3
Nevertheless, if kernel 5.10.15 and above, I have attached a patch which applies
JFS for 5.11 smoothly onto this 'ephemeral hack'.
Additionally, have attached a couple of your reiser4 patches modified to apply
smoothly onto this, again, 'ephemeral hack':)
the one containing string 'stable' is for reiser4, Software Framework Release
Number (SFRN) 4.0.2.
the one containing string 'unstable' is for reiser4, Software Framework Release
Number (SFRN) 5.1.3.
Best Professional Regards.
--
Jose R R
http://metztli.it
-----------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
-----------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-----------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-----------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
[-- Attachment #2: jfs-5.11-for-5.10.15.patch --]
[-- Type: text/x-patch, Size: 4582 bytes --]
From c241dcb5b611fdb45239b536eb3acd37d09aab95 Mon Sep 17 00:00:00 2001
From: Metztli Information Technology <jose@metztli.it>
Date: Sat, 13 Feb 2021 07:14:18 -0800
Subject: [PATCH] Ic ome (Second) commit applied JFS for 5.11 patch to Linux
5.10.15 already re-enabled with 'kernel read'
---
fs/jfs/jfs_dmap.c | 10 +++++++---
fs/jfs/jfs_extent.c | 2 +-
fs/jfs/jfs_extent.h | 2 +-
fs/jfs/jfs_logmgr.h | 2 +-
fs/jfs/jfs_txnmgr.c | 2 +-
fs/jfs/jfs_xtree.c | 2 +-
6 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 7dfcab2a2da6..94b7c1cb5ceb 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -668,7 +668,7 @@ int dbNextAG(struct inode *ipbmap)
* this does not succeed, we finally try to allocate anywhere
* within the aggregate.
*
- * we also try to allocate anywhere within the aggregate for
+ * we also try to allocate anywhere within the aggregate
* for allocation requests larger than the allocation group
* size or requests that specify no hint value.
*
@@ -2549,15 +2549,19 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level)
*/
if (oldval == NOFREE) {
rc = dbBackSplit((dmtree_t *) dcp, leafno);
- if (rc)
+ if (rc) {
+ release_metapage(mp);
return rc;
+ }
oldval = dcp->stree[ti];
}
dbSplit((dmtree_t *) dcp, leafno, dcp->budmin, newval);
} else {
rc = dbJoin((dmtree_t *) dcp, leafno, newval);
- if (rc)
+ if (rc) {
+ release_metapage(mp);
return rc;
+ }
}
/* check if the root of the current dmap control page changed due
diff --git a/fs/jfs/jfs_extent.c b/fs/jfs/jfs_extent.c
index f65bd6b35412..bb4a342a193d 100644
--- a/fs/jfs/jfs_extent.c
+++ b/fs/jfs/jfs_extent.c
@@ -575,7 +575,7 @@ extBalloc(struct inode *ip, s64 hint, s64 * nblocks, s64 * blkno)
* blkno - starting block number of the extents current allocation.
* nblks - number of blocks within the extents current allocation.
* newnblks - pointer to a s64 value. on entry, this value is the
- * the new desired extent size (number of blocks). on
+ * new desired extent size (number of blocks). on
* successful exit, this value is set to the extent's actual
* new size (new number of blocks).
* newblkno - the starting block number of the extents new allocation.
diff --git a/fs/jfs/jfs_extent.h b/fs/jfs/jfs_extent.h
index dd635a8a0f8c..1c984214e95e 100644
--- a/fs/jfs/jfs_extent.h
+++ b/fs/jfs/jfs_extent.h
@@ -5,7 +5,7 @@
#ifndef _H_JFS_EXTENT
#define _H_JFS_EXTENT
-/* get block allocation allocation hint as location of disk inode */
+/* get block allocation hint as location of disk inode */
#define INOHINT(ip) \
(addressPXD(&(JFS_IP(ip)->ixpxd)) + lengthPXD(&(JFS_IP(ip)->ixpxd)) - 1)
diff --git a/fs/jfs/jfs_logmgr.h b/fs/jfs/jfs_logmgr.h
index 7fd125c8dd19..805877ce5020 100644
--- a/fs/jfs/jfs_logmgr.h
+++ b/fs/jfs/jfs_logmgr.h
@@ -132,7 +132,7 @@ struct logpage {
* (this comment should be rewritten !)
* jfs uses only "after" log records (only a single writer is allowed
* in a page, pages are written to temporary paging space if
- * if they must be written to disk before commit, and i/o is
+ * they must be written to disk before commit, and i/o is
* scheduled for modified pages to their home location after
* the log records containing the after values and the commit
* record is written to the log on disk, undo discards the copy
diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index c8ce7f1bc594..dca8edd2378c 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -1474,7 +1474,7 @@ static int diLog(struct jfs_log * log, struct tblock * tblk, struct lrd * lrd,
* For the LOG_NOREDOINOEXT record, we need
* to pass the IAG number and inode extent
* index (within that IAG) from which the
- * the extent being released. These have been
+ * extent is being released. These have been
* passed to us in the iplist[1] and iplist[2].
*/
lrd->log.noredoinoext.iagnum =
diff --git a/fs/jfs/jfs_xtree.c b/fs/jfs/jfs_xtree.c
index 16ad920f6fb1..3148e9b35f3b 100644
--- a/fs/jfs/jfs_xtree.c
+++ b/fs/jfs/jfs_xtree.c
@@ -3684,7 +3684,7 @@ s64 xtTruncate(tid_t tid, struct inode *ip, s64 newsize, int flag)
*
* function:
* Perform truncate to zero length for deleted file, leaving the
- * the xtree and working map untouched. This allows the file to
+ * xtree and working map untouched. This allows the file to
* be accessed via open file handles, while the delete of the file
* is committed to disk.
*
--
2.29.2
[-- Attachment #3: reiser4-for-metztli-5.10.13-stable.patch.gz --]
[-- Type: application/gzip, Size: 624185 bytes --]
[-- Attachment #4: reiser4-for-metztli-5.10.15.unstable.patch.gz --]
[-- Type: application/gzip, Size: 726668 bytes --]
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-19 8:12 ` Jose R Rodriguez
@ 2021-02-26 7:33 ` Jose R Rodriguez
0 siblings, 0 replies; 13+ messages in thread
From: Jose R Rodriguez @ 2021-02-26 7:33 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, linux-kernel
On Fri, 2021-02-19 at 00:12 -0800, Jose R Rodriguez wrote:
> On Tue, 2021-02-16 at 21:02 +0100, Edward Shishkin wrote:
> >
> >
> > On 02/16/2021 04:56 PM, Jose R Rodriguez wrote:
> > > On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
> > > > On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> > > > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <
> > > > > edward.shishkin@gmail.com> wrote:
> > > > > >
> > > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > > > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > > > > > >
> > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
> > > > > > > usual -- to generate a kernel component for my Debian-Installer
> > > > > > > (d-i).
> > > > > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
> > > > > > > unstable.
> > > > > > >
> > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated
> > > > > > > one set of components for d-i I built the d-i image.
> > > > > > >
> > > > > > > Fact is, the installer throws an error in *both* bare metal and
> > > > > > > VirtualBox 6.1.16:
> > > > > > > ...
> > > > > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
> > > > > > > base' selected
> > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
> > > > > > > components=main --debian-installer --resolve-deps --
> > > > > > > keyring=/usr/share/keyrings/archive.gpg buster /target
> > > > > > > http://deb.debian.org/debian/
> > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
> > > > > > > /target/test-exec: Invalid argument
> > > > > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
> > > > > > > supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > > > > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > > > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target
> > > > > > > '/target' mounted with noexec or nodev
> > > > > > > Dec 22 20:20:12 base-installer: error: exiting on error base-
> > > > > > > installer/debootstrap-failed
> > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
> > > > > > > 'bootstrap-base' failed with error code 1
> > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
> > > > > > > 'bootstrap-base' failed.
> > > > > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
> > > > > > > package description for brltty-udeb
> > > > > > >
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > >
> > > > > > > Apparently, d-i [Debian-installer] complains about being unable
> > > > > > > to set the test file executable and causes the error when 1 is
> > > > > > > returned.
> > > > > > > Notwithstanding, I manually verified that I am able to touch a
> > > > > > > file and set it +x executable.
> > > > > > >
> > > > > > > Furthermore, tricking the function return value to 0 I am able
> > > > > > > to make d-i continue with the latest SFRN5 installation (see
> > > > > > > [*trick*] below); yet, subsequently halts again with
> > > > > > > an apparently related error --can not proceed any further.
> > > > > > >
> > > > > > > Digging deeper with dmesg, we can see that apparently it is the
> > > > > > > kernel which cannot 'read' properly. Please find a partial
> > > > > > > dmesg log with relevant output
> > > > > > > from an attempt on my physical development machine.
> > > > > > > ...
> > > > > > > [ 508.614488] Loading Reiser4 (Software Framework Release:
> > > > > > > 5.1.3). See reiser4.wiki.kernel.org for a description of
> > > > > > > Reiser4.
> > > > > > > [ 508.661951] SGI XFS with ACLs, security attributes,
> > > > > > > realtime, quota, no debug enabled
> > > > > > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > > > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
> > > > > > > initialised: dm-devel@redhat.com
> > > > > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > > > > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > > > > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > > > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
> > > > > > > extents:1 across:9765884k FS
> > > > > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
> > > > > > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > > > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > > > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > > > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > > > > Model.
> > > > > > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > > > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
> > > > > > > the ext4 subsystem
> > > > > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without
> > > > > > > journal. Opts: (null)
> > > > > > > [ 643.813488] ext2 filesystem being mounted at /target/boot
> > > > > > > supports timestamps until 2038 (0x7fffffff)
> > > > > > > [ 648.168730] kernel read not supported for file /test-exec
> > > > > > > (pid: 9876 comm: debootstrap) [*trick*]
> > > > > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > > > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > > > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > > > > Model.
> > > > > > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > > > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
> > > > > > > the ext4 subsystem
> > > > > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
> > > > > > > journal. Opts: (null)
> > > > > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot
> > > > > > > supports timestamps until 2038 (0x7fffffff)
> > > > > > > [ 6373.748413] kernel read not supported for file /test-exec
> > > > > > > (pid: 10094 comm: debootstrap)
> > > > > > > [ 6413.169920] kernel read not supported for file /usr/bin/true
> > > > > > > (pid: 15960 comm: chroot)
> > > > > >
> > > > > >
> > > > > > Hello.
> > > > > >
> > > > > > This is because of VFS changes in Linux-5.10.X.
> > > > > > Specifically, because of the following patch:
> > > > > > https://lkml.org/lkml/2020/8/17/174
> > > > > > In the upstream git repository it is commit
> > > > > > 4d03e3cc59828c82ee89ea6e2
Your hint played a key role solving my issue, Sir. Thank you.
> > > > > >
> > > > > > So, Christoph, what to do now for file systems which implement
> > > > > > ->read() method of file operations?
> > > > >
> > > > > *deafening silence* it appears that -- in the best of cases --
> > > > > Christoph engaged in an act of _iter masturbation [1];
> > > > > and in the worst of cases, the gentleman was aiming straight at
> > > > > reiser4.
> > > > >
> > > > > > ... It seems that chroot doesn't work
> > > > > > for them. And people are not able to release distros with
> > > > > > upgraded
> > > > > > kernels..
> > > > >
> > > > > Not only 'chroot doesn't work' for us, but even after replacing the
> > > > > kernel in a reiser4 (proper SFRN ;) instance and
> > > > > upon an initial Linux 5.10.x kernel boot:
> > > > > ...
> > > > > kernel read not supported for file usr/lib/systemd/systemd (pid: 1
> > > > > comm: run-init)
> > > > > kernel panic -- not syncing: Attempted to kill init!
> > > > > exitcod=0x00000100
> > > > > ...
> > > > >
> > > > > Fact is some of us have commercial interests when deploying
> > > > > reiser4, both in cloud instances, baremetal, and on-premises.
> > > > >
> > > > > In the future if -- and only if -- our reiser4 efforts come to
> > > > > successful fruition, quite likely in due time we will be
> > > > > able to financially commit to the Penguin's Linux Foundation
> > > > > temple, just like large corporations do
> > > > > in exchange for indulgences[2] which virtue-wash their past
> > > > > and/or current corp. officers' *substantially darker deeds*;
> > > > > heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
> > > > > that 'virtuous' cult of GNU/Linux
> > > > > developers/gatekeepers/maintainers' frivolous, *narcissist*,
> > > > > ethics and/or moralities so often piled up against
> > > > > Reiser's work --which, paradoxically(!?), actually was largely
> > > > > implemented by Russian developers ;)
> > > > >
> > > > > In the meantime, I hacked a reverse patch that undoes some(all) of
> > > > > the surreptitious lethal attack on reiser4 fs
> > > > > -- at least on AMD64 architectures (I did away with other
> > > > > arch/Kconfigs).
> > > > > And no, I am not a git pro-, undoing what I could of commit
> > > > > 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> > > > > does not fix the 'kernel read' issue.
> > > > >
> > > > > Notwithstanding, I would appreciate if you can take a look at the
> > > > > attached patch. Probably it can be streamlined and/or improved
> > > > > further to minimize pain on subsequent Linux kernel upgrades.
> > > >
> > > >
> > > > That patch is an attempt to swim against the current ;)
> > > In a sense all of us who prefer reiser4 do not have a herd mentality.
> > > So, yes, we 'swim against the current', if you will put it in those
> > > terms, because we value data integrity (atomicity).
> >
> >
> > Cool.
> > Do you have resources to support such fork?
> Well, I have 10 Gig storage slice in Yandex ;) Likely if I visit the site with
> more frequency I might call out the US/NATO's trolls who immediate gang-up on
> anyone who expresses anything positive about the President of the Russian
> Federation. :)
> >
> >
> > >
> > > Notwithstanding, it is only an ephemeral hack for AMD64 architectures.
> Reiterating, 'ephemeral hack' and not a fork per se.
>
> > > I have running locally reiser4 -enabled 5.10.13-2, 5.10.14-2, whereas I
> > > have an Google Compute Engine (GCE), on an AMD Epyc (reizer4 label)
> > > zone, custom instance testing with a cloud kernel 5.10.15-2.
> > >
> > > < https://metztli.it/buster/cloud-5.10.15-2+reizer4_0_2.png >
Had a rough time pulling this reiser4 kernel hack out, Sir; thus I created a
post for posterity and to potentially guide others who want to develop their
reiser4 kernel hacks within the 'Debian way' (well, just an approximation ;) --
including a patch hack for Debian packaging for Linux 5.10.17 which generates
the reiser4 module:
< https://metztli.blog/nochtli/aS2 >
Apropos, the Linux 5.10.15-2 reiser4 cloud instance previously referenced
running on a Google AMD Epyc/Ryzen (reizer4 label) computing fabric zone/region,
has now logged 11+ days humming smoothly:
< https://metztli.it/buster/perf.png >
> > >
> > > Heck, I have updated the reiser4, Software Framework Release Number
> > > (SFRN) 5.1.3, d-i netboot installer media with a test kernel 5.10.16-2
> > > < https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso
> >
> >
> > Note that fsck.reiser4 still doesn't work with 5.1.3
> *That* I was unaware, Sir.
> >
> > Thanks,
> > Edward.
> >
> >
> > > >
> > > <
> > >
> > >
> > > https://metztli.it/buster-reiser5/5.10.x/metztli-reiser4-sfrn5-ng.iso.SHA256SUM
> > > >
> > >
> > > ... крутые?
> > > >
> > > > I no longer remember, why they want to get rid of set_fs for already
> > > > 15
> > > > years, but ->read() and ->write() methods seem to be deprecated, and
> > > > the
> > > > correct way would be to implement the new ->read_iter() and
> > > > write_iter()
> > > > methods, where reiser4 works with "chunked" streams, represented by
> > > > iov_iter structure, rather than with "continuous" streams,
> > > > represented
> > > > by char __user *buf. The task is not that difficult, but rather time
> > > > consuming - I don't have a time for this right now..
> > > >
> > > > Thanks,
> > > > Edward.
> > > >
> > > > >
> > > > > The patch has been tested in my local development machine
> > > > > environment --
> > > > > as I intalled the generated reiser4 -enabled linux 5.10.13/14
> > > > > meta/kernel into a Debian Bullseye already running reiser4 (with
> > > > > proper SFRN)
> > > > > and the kernel booted nicely. Subsequently, after installing the
> > > > > linux headers, etc. I built a couple of upgraded kernels
> > > > > in Debian Buster GCC-8 and Bullseye GCC-10 environments -- thus
> > > > > the hack seems to be stable.
> > > > >
> > > > > Additionally, I have just made a Debian-Installer (d-i) with a
> > > > > 'kernel read' -patched Linux 5.10.14.1 which successfully installed
> > > > > into a VirtualBox 6.1.18 VM:
> > > > > <
> > > > >
> > > > >
> > > > > https://metztli.it/buster/reiser4_0_2-linux-5.10.14-kernel-read-patched.png
> > > > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Edward.
> > > > >
> > > > > Best Professional Regards.
> > > > >
> > > > > [1]
> > > > > "The bug was fixed, again way back in 2010, and over time chip-
> > > > > designers have moved on to improved memory management techniques.
> > > > > Torvalds wrote that this sort of memory space override has been
> > > > > banished from the x86, powerpc, s390 and RISC-V architectures."
> > > > > < https://www.theregister.com/2020/10/25/linux_5_10_rc1/ >
> > > > >
> > > > > [2] https://www.britannica.com/topic/indulgence
> > > > >
>
> Given the fact that my custom Debian Installer netboot image defaults to a
> ~500MB JFS boot partition while all the others default to reiser4, there is a
> patch from JFS for 5.11 which applies nicely onto kernel 5.10.[0-14]:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=9867cb1fd510187d8f828540bdb48f78fceb70b3
>
> Nevertheless, if kernel 5.10.15 and above, I have attached a patch which
> applies
> JFS for 5.11 smoothly onto this 'ephemeral hack'.
>
> Additionally, have attached a couple of your reiser4 patches modified to apply
> smoothly onto this, again, 'ephemeral hack':)
> the one containing string 'stable' is for reiser4, Software Framework Release
> Number (SFRN) 4.0.2.
> the one containing string 'unstable' is for reiser4, Software Framework
> Release
> Number (SFRN) 5.1.3.
>
[]
Best Professional Regards
--
--
Jose R R
http://metztli.it
-----------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
-----------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-----------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-----------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-08 16:03 ` Edward Shishkin
2021-02-16 15:56 ` Jose R Rodriguez
@ 2021-08-04 10:17 ` Metztli Information Technology
2021-08-13 15:20 ` Metztli Information Technology
2 siblings, 0 replies; 13+ messages in thread
From: Metztli Information Technology @ 2021-08-04 10:17 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, linux-kernel, Andrew Morton
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
> On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin
> > <edward.shishkin@gmail.com> wrote:
> > >
> > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > > >
> > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
> > > > usual -- to generate a kernel component for my Debian-Installer
> > > > (d-i).
> > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
> > > > unstable.
> > > >
> > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated
> > > > one set of components for d-i I built the d-i image.
> > > >
> > > > Fact is, the installer throws an error in *both* bare metal and
> > > > VirtualBox 6.1.16:
> > > > ...
> > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
> > > > base' selected
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
> > > > components=main --debian-installer --resolve-deps --
> > > > keyring=/usr/share/keyrings/archive.gpg buster /target
> > > > http://deb.debian.org/debian/
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
> > > > /target/test-exec: Invalid argument
> > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
> > > > supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target
> > > > '/target' mounted with noexec or nodev
> > > > Dec 22 20:20:12 base-installer: error: exiting on error base-
> > > > installer/debootstrap-failed
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
> > > > 'bootstrap-base' failed with error code 1
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
> > > > 'bootstrap-base' failed.
> > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
> > > > package description for brltty-udeb
> > > >
> > >
> > > [...]
> > >
> > > >
> > > > Apparently, d-i [Debian-installer] complains about being unable
> > > > to set the test file executable and causes the error when 1 is
> > > > returned.
> > > > Notwithstanding, I manually verified that I am able to touch a
> > > > file and set it +x executable.
> > > >
> > > > Furthermore, tricking the function return value to 0 I am able
> > > > to make d-i continue with the latest SFRN5 installation (see
> > > > [*trick*] below); yet, subsequently halts again with
> > > > an apparently related error --can not proceed any further.
> > > >
> > > > Digging deeper with dmesg, we can see that apparently it is the
> > > > kernel which cannot 'read' properly. Please find a partial
> > > > dmesg log with relevant output
> > > > from an attempt on my physical development machine.
> > > > ...
> > > > [ 508.614488] Loading Reiser4 (Software Framework Release:
> > > > 5.1.3). See reiser4.wiki.kernel.org for a description of
> > > > Reiser4.
> > > > [ 508.661951] SGI XFS with ACLs, security attributes,
> > > > realtime, quota, no debug enabled
> > > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
> > > > initialised: dm-devel@redhat.com
> > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
> > > > extents:1 across:9765884k FS
> > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
> > > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 643.813488] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 648.168730] kernel read not supported for file /test-exec
> > > > (pid: 9876 comm: debootstrap) [*trick*]
> > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 6373.748413] kernel read not supported for file /test-exec
> > > > (pid: 10094 comm: debootstrap)
> > > > [ 6413.169920] kernel read not supported for file /usr/bin/true
> > > > (pid: 15960 comm: chroot)
> > >
> > >
> > > Hello.
> > >
> > > This is because of VFS changes in Linux-5.10.X.
> > > Specifically, because of the following patch:
> > > https://lkml.org/lkml/2020/8/17/174
> > > In the upstream git repository it is commit
> > > 4d03e3cc59828c82ee89ea6e2
> > >
> > > So, Christoph, what to do now for file systems which implement
> > > ->read() method of file operations?
> >
> > *deafening silence* it appears that -- in the best of cases --
> > Christoph engaged in an act of _iter masturbation [1];
> > and in the worst of cases, the gentleman was aiming straight at
> > reiser4.
> >
> > > ... It seems that chroot doesn't work
> > > for them. And people are not able to release distros with
> > > upgraded
> > > kernels..
> >
> > Not only 'chroot doesn't work' for us, but even after replacing the
> > kernel in a reiser4 (proper SFRN ;) instance and
> > upon an initial Linux 5.10.x kernel boot:
> > ...
> > kernel read not supported for file usr/lib/systemd/systemd (pid: 1
> > comm: run-init)
> > kernel panic -- not syncing: Attempted to kill init!
> > exitcod=0x00000100
> > ...
> >
> > Fact is some of us have commercial interests when deploying
> > reiser4, both in cloud instances, baremetal, and on-premises.
> >
> > In the future if -- and only if -- our reiser4 efforts come to
> > successful fruition, quite likely in due time we will be
> > able to financially commit to the Penguin's Linux Foundation
> > temple, just like large corporations do
> > in exchange for indulgences[2] which virtue-wash their past
> > and/or current corp. officers' *substantially darker deeds*;
> > heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
> > that 'virtuous' cult of GNU/Linux
> > developers/gatekeepers/maintainers' frivolous, *narcissist*,
> > ethics and/or moralities so often piled up against
> > Reiser's work --which, paradoxically(!?), actually was largely
> > implemented by Russian developers ;)
> >
> > In the meantime, I hacked a reverse patch that undoes some(all) of
> > the surreptitious lethal attack on reiser4 fs
> > -- at least on AMD64 architectures (I did away with other
> > arch/Kconfigs).
> > And no, I am not a git pro-, undoing what I could of commit
> > 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> > does not fix the 'kernel read' issue.
> >
> > Notwithstanding, I would appreciate if you can take a look at the
> > attached patch. Probably it can be streamlined and/or improved
> > further to minimize pain on subsequent Linux kernel upgrades.
>
>
> That patch is an attempt to swim against the current ;)
>
> I no longer remember, why they want to get rid of set_fs for already
> 15
> years, but ->read() and ->write() methods seem to be deprecated, and
> the
> correct way would be to implement the new ->read_iter() and
> write_iter()
> methods, where reiser4 works with "chunked" streams, represented by
> iov_iter structure, rather than with "continuous" streams,
> represented
> by char __user *buf. The task is not that difficult, but rather time
> consuming - I don't have a time for this right now..
On Sun, Jun 20, 2021 at 10:45 AM Edward Shishkin
<edward.shishkin@gmail.com> wrote:
So, I have implemented ->read_iter() for all plugins (*). It is
included
to reiser4-for-5.12 stuff. Not sure if it is enough to make distro with
root over reiser4 though: ->write_iter() is not yet implemented (not so
trivial because of transactions).
(*)
https://github.com/edward6/reiser4/commit/ac72aba7e8bb16a28755c1b2b762971927d17c3c
https://github.com/edward6/reiser4/commit/4d3200fbcb2003c680cdb822e3f616d3fa83c391
Edward.
You updated reiser4 patch implementation enables the reiser4 Debian
Installer (d-i) to proceed with the installation into a reiser4 root fs
disk media, Sir, much appreciated.
< https://metztli.it/bullseye/netboot-ng/metztli-reiser4.iso >
< https://metztli.it/bullseye/netboot-ng/metztli-reiser4.iso.SHA256SUM
>
Took me a while because there is no Debian packaging for the Linux
kernel 5.12, i.e., the Debian kernel package maintainers/developers'
last package is for 5.10.46-zt and then they skipped 5.11 and 5.12 to
begin experimenting with packaging for 5.13.xy-zt. I had to come up
with a crude hack -- based on inductive reasoning -- to combine patches
from those two packaging extremes and thus test if your patch actually
solved the installation issue.
Apropos, I have been running that reiser4 linux 5.12.19 EOL build
locally, as well, for a couple of days without apparent issues thus
far.
< https://metztli.it/bullseye/tezcatlipoca.jpg >
Best Professional Regards.
--
--
Jose R R
http://metztli.it
-----------------------------------------------------------------------
----------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.10.26 AMD64
-----------------------------------------------------------------------
----------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-----------------------------------------------------------------------
----------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-----------------------------------------------------------------------
--------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-02-08 16:03 ` Edward Shishkin
2021-02-16 15:56 ` Jose R Rodriguez
2021-08-04 10:17 ` Metztli Information Technology
@ 2021-08-13 15:20 ` Metztli Information Technology
2021-08-14 11:00 ` Edward Shishkin
2 siblings, 1 reply; 13+ messages in thread
From: Metztli Information Technology @ 2021-08-13 15:20 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, linux-kernel, Andrew Morton
On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote:
> On 02/08/2021 01:54 PM, Metztli Information Technology wrote:
> > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin
> > <edward.shishkin@gmail.com> wrote:
> > >
> > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> > > >
> > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as
> > > > usual -- to generate a kernel component for my Debian-Installer
> > > > (d-i).
> > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-
> > > > unstable.
> > > >
> > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated
> > > > one set of components for d-i I built the d-i image.
> > > >
> > > > Fact is, the installer throws an error in *both* bare metal and
> > > > VirtualBox 6.1.16:
> > > > ...
> > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-
> > > > base' selected
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --
> > > > components=main --debian-installer --resolve-deps --
> > > > keyring=/usr/share/keyrings/archive.gpg buster /target
> > > > http://deb.debian.org/debian/
> > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596:
> > > > /target/test-exec: Invalid argument
> > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not
> > > > supported for file /test-exec (pid: 10077 comm: debootstrap)
> > > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target
> > > > '/target' mounted with noexec or nodev
> > > > Dec 22 20:20:12 base-installer: error: exiting on error base-
> > > > installer/debootstrap-failed
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring
> > > > 'bootstrap-base' failed with error code 1
> > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item
> > > > 'bootstrap-base' failed.
> > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the
> > > > package description for brltty-udeb
> > > >
> > >
> > > [...]
> > >
> > > >
> > > > Apparently, d-i [Debian-installer] complains about being unable
> > > > to set the test file executable and causes the error when 1 is
> > > > returned.
> > > > Notwithstanding, I manually verified that I am able to touch a
> > > > file and set it +x executable.
> > > >
> > > > Furthermore, tricking the function return value to 0 I am able
> > > > to make d-i continue with the latest SFRN5 installation (see
> > > > [*trick*] below); yet, subsequently halts again with
> > > > an apparently related error --can not proceed any further.
> > > >
> > > > Digging deeper with dmesg, we can see that apparently it is the
> > > > kernel which cannot 'read' properly. Please find a partial
> > > > dmesg log with relevant output
> > > > from an attempt on my physical development machine.
> > > > ...
> > > > [ 508.614488] Loading Reiser4 (Software Framework Release:
> > > > 5.1.3). See reiser4.wiki.kernel.org for a description of
> > > > Reiser4.
> > > > [ 508.661951] SGI XFS with ACLs, security attributes,
> > > > realtime, quota, no debug enabled
> > > > [ 509.326270] device-mapper: uevent: version 1.0.3
> > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01)
> > > > initialised: dm-devel@redhat.com
> > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > > > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2
> > > > extents:1 across:9765884k FS
> > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol
> > > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 643.759980] reiser4: brick /dev/sda6 activated
> > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 643.813488] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 648.168730] kernel read not supported for file /test-exec
> > > > (pid: 9876 comm: debootstrap) [*trick*]
> > > > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > > > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction
> > > > Model.
> > > > [ 999.093480] reiser4: brick /dev/sda6 activated
> > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using
> > > > the ext4 subsystem
> > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without
> > > > journal. Opts: (null)
> > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot
> > > > supports timestamps until 2038 (0x7fffffff)
> > > > [ 6373.748413] kernel read not supported for file /test-exec
> > > > (pid: 10094 comm: debootstrap)
> > > > [ 6413.169920] kernel read not supported for file /usr/bin/true
> > > > (pid: 15960 comm: chroot)
> > >
> > >
> > > Hello.
> > >
> > > This is because of VFS changes in Linux-5.10.X.
> > > Specifically, because of the following patch:
> > > https://lkml.org/lkml/2020/8/17/174
> > > In the upstream git repository it is commit
> > > 4d03e3cc59828c82ee89ea6e2
> > >
> > > So, Christoph, what to do now for file systems which implement
> > > ->read() method of file operations?
> >
> > *deafening silence* it appears that -- in the best of cases --
> > Christoph engaged in an act of _iter masturbation [1];
> > and in the worst of cases, the gentleman was aiming straight at
> > reiser4.
> >
> > > ... It seems that chroot doesn't work
> > > for them. And people are not able to release distros with
> > > upgraded
> > > kernels..
> >
> > Not only 'chroot doesn't work' for us, but even after replacing the
> > kernel in a reiser4 (proper SFRN ;) instance and
> > upon an initial Linux 5.10.x kernel boot:
> > ...
> > kernel read not supported for file usr/lib/systemd/systemd (pid: 1
> > comm: run-init)
> > kernel panic -- not syncing: Attempted to kill init!
> > exitcod=0x00000100
> > ...
> >
> > Fact is some of us have commercial interests when deploying
> > reiser4, both in cloud instances, baremetal, and on-premises.
> >
> > In the future if -- and only if -- our reiser4 efforts come to
> > successful fruition, quite likely in due time we will be
> > able to financially commit to the Penguin's Linux Foundation
> > temple, just like large corporations do
> > in exchange for indulgences[2] which virtue-wash their past
> > and/or current corp. officers' *substantially darker deeds*;
> > heck, 'indulgence trafficking' seems to assuage->numb->arg(STFU)
> > that 'virtuous' cult of GNU/Linux
> > developers/gatekeepers/maintainers' frivolous, *narcissist*,
> > ethics and/or moralities so often piled up against
> > Reiser's work --which, paradoxically(!?), actually was largely
> > implemented by Russian developers ;)
> >
> > In the meantime, I hacked a reverse patch that undoes some(all) of
> > the surreptitious lethal attack on reiser4 fs
> > -- at least on AMD64 architectures (I did away with other
> > arch/Kconfigs).
> > And no, I am not a git pro-, undoing what I could of commit
> > 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf (as your hinted, Ed)
> > does not fix the 'kernel read' issue.
> >
> > Notwithstanding, I would appreciate if you can take a look at the
> > attached patch. Probably it can be streamlined and/or improved
> > further to minimize pain on subsequent Linux kernel upgrades.
>
>
> That patch is an attempt to swim against the current ;)
>
> I no longer remember, why they want to get rid of set_fs for already
> 15
> years, but ->read() and ->write() methods seem to be deprecated, and
> the
> correct way would be to implement the new ->read_iter() and
> write_iter()
> methods, where reiser4 works with "chunked" streams, represented by
> iov_iter structure, rather than with "continuous" streams,
> represented
> by char __user *buf. The task is not that difficult, but rather time
> consuming - I don't have a time for this right now..
On Sun, Jun 20, 2021 at 10:45 AM Edward Shishkin
<edward.shishkin@gmail.com> wrote:
So, I have implemented ->read_iter() for all plugins (*). It is
included
to reiser4-for-5.12 stuff. Not sure if it is enough to make distro with
root over reiser4 though: ->write_iter() is not yet implemented (not so
trivial because of transactions).
(*)
https://github.com/edward6/reiser4/commit/ac72aba7e8bb16a28755c1b2b762971927d17c3c
https://github.com/edward6/reiser4/commit/4d3200fbcb2003c680cdb822e3f616d3fa83c391
Edward.
Your updated reiser4 patch implementation enables the reiser4 Debian
Installer (d-i) to proceed with the installation into a reiser4 root fs
disk media, Sir, much appreciated.
< https://metztli.it/bullseye/netboot-ng/metztli-reiser4.iso >
< https://metztli.it/bullseye/netboot-ng/metztli-reiser4.iso.SHA256SUM
>
Took me a while because there is no Debian packaging for the Linux
kernel 5.12, i.e., the Debian kernel package maintainers/developers'
last package is for 5.10.46-zt and then they skipped 5.11 and 5.12 to
begin experimenting with packaging for 5.13.xy-zt. I had to come up
with a crude hack -- based on inductive reasoning -- to combine patches
from those two packaging extremes and thus test if your patch actually
solved the installation issue.
Apropos, I have been running that reiser4 linux 5.12.19 EOL build
locally, as well, for a couple of days without apparent issues thus
far.
< https://metztli.it/bullseye/tezcatlipoca.jpg >
Best Professional Regards.
Niltze, Ed-
I finally got around to creating an SFRN 5.1.3 -enabled Debian
Installer (d-i) for upcoming Debian 11 (codenamed Bullseye). Applied
your unstable reiser4 for 5.12 patch onto my debianized hack packaging
for Linux kernel 5.12.19 EOL.
I gave the d-i a spin in VirtualBox 6.1.26 and it choked on the
following code fragment:
---------------------------------------------------------------------
setup_dev_linux () {
# Ensure static device nodes created during install are
preserved
# Tests in MAKEDEV require this is done in the D-I environment
mkdir -p /dev/.static/dev
chmod 700 /dev/.static/
mount --bind /target/dev /dev/.static/dev
# Mirror device nodes in D-I environment to target
mount --bind /dev /target/dev/
}
-----------------------------------------------------------------------
specifically:
mount --bind /target/dev /dev/.static/dev
See relevant code fragment next to VirtualBox VM, where I manually
entered the above directive:
< https://metztli.it/bullseye-reiser5/d-i-sfrn5-fail.jpg >
i.e., '--bind' is causing the SFRN5 -enabled installer to bail out
*only* for this reiser4 unstable SFRN 5.1.3 -patched kernel. On the
other hand, as reported previously, no such issue occurs with your
reiser4 stable SFRN 4.0.2 patch applied to the *same* debianized kernel
source tree, Ed.
Best Professional Regards.
--
--
Jose R R
http://metztli.it
-----------------------------------------------------------------------
----------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.26 AMD64
-----------------------------------------------------------------------
----------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-----------------------------------------------------------------------
----------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-----------------------------------------------------------------------
--------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-08-13 15:20 ` Metztli Information Technology
@ 2021-08-14 11:00 ` Edward Shishkin
2021-08-16 19:22 ` Metztli Information Technology
0 siblings, 1 reply; 13+ messages in thread
From: Edward Shishkin @ 2021-08-14 11:00 UTC (permalink / raw)
To: Metztli Information Technology
Cc: reiserfs-devel, linux-kernel, Andrew Morton
On 08/13/2021 05:20 PM, Metztli Information Technology wrote:
[...]
>>>
>>> Notwithstanding, I would appreciate if you can take a look at the
>>> attached patch. Probably it can be streamlined and/or improved
>>> further to minimize pain on subsequent Linux kernel upgrades.
>>
>>
>> That patch is an attempt to swim against the current ;)
>>
>> I no longer remember, why they want to get rid of set_fs for already
>> 15
>> years, but ->read() and ->write() methods seem to be deprecated, and
>> the
>> correct way would be to implement the new ->read_iter() and
>> write_iter()
>> methods, where reiser4 works with "chunked" streams, represented by
>> iov_iter structure, rather than with "continuous" streams,
>> represented
>> by char __user *buf. The task is not that difficult, but rather time
>> consuming - I don't have a time for this right now..
>
> On Sun, Jun 20, 2021 at 10:45 AM Edward Shishkin
> <edward.shishkin@gmail.com> wrote:
> So, I have implemented ->read_iter() for all plugins (*). It is
> included
> to reiser4-for-5.12 stuff. Not sure if it is enough to make distro with
> root over reiser4 though: ->write_iter() is not yet implemented (not so
> trivial because of transactions).
>
> (*)
> https://github.com/edward6/reiser4/commit/ac72aba7e8bb16a28755c1b2b762971927d17c3c
>
> https://github.com/edward6/reiser4/commit/4d3200fbcb2003c680cdb822e3f616d3fa83c391
>
> Edward.
>
Hello,
Now the new striped file plugin implements ->write_iter():
https://github.com/edward6/reiser4/commit/a3795ffffbb841bfaa66bfb18c12fb317533d1ff
[...]
> I finally got around to creating an SFRN 5.1.3 -enabled Debian
> Installer (d-i) for upcoming Debian 11 (codenamed Bullseye). Applied
> your unstable reiser4 for 5.12 patch onto my debianized hack packaging
> for Linux kernel 5.12.19 EOL.
>
> I gave the d-i a spin in VirtualBox 6.1.26 and it choked on the
> following code fragment:
> ---------------------------------------------------------------------
> setup_dev_linux () {
> # Ensure static device nodes created during install are
> preserved
> # Tests in MAKEDEV require this is done in the D-I environment
> mkdir -p /dev/.static/dev
> chmod 700 /dev/.static/
> mount --bind /target/dev /dev/.static/dev
> # Mirror device nodes in D-I environment to target
> mount --bind /dev /target/dev/
> }
> -----------------------------------------------------------------------
>
> specifically:
> mount --bind /target/dev /dev/.static/dev
>
> See relevant code fragment next to VirtualBox VM, where I manually
> entered the above directive:
> < https://metztli.it/bullseye-reiser5/d-i-sfrn5-fail.jpg >
>
> i.e., '--bind' is causing the SFRN5 -enabled installer to bail out
> *only* for this reiser4 unstable SFRN 5.1.3 -patched kernel. On the
> other hand, as reported previously, no such issue occurs with your
> reiser4 stable SFRN 4.0.2 patch applied to the *same* debianized kernel
> source tree, Ed.
I have checked - everything works for me (Linux-5.12).
# mount /dev/vdd1 /mnt/test
# volume.reiser4 /mnt/test
Logical Volume Info:
ID: 03ac5995-bf77-4851-a302-e875a6fd752f
volume: 0x1 (asym)
distribution: 0x1 (fsx32m)
stripe: 262144
segments: 1024
bricks total: 3
bricks in DSA: 3
slots: 3
map blocks: 2
balanced: Yes
health: OK
# mkdir bindmnt
# mount --bind /mnt/test bindmnt
# mount
[...]
/dev/vdd1 on /mnt/test type reiser4
(rw,relatime,atom_max_size=0x3d88e,atom_max_age=0x927c0,atom_min_size=0x100,atom_max_flushers=0x1,cbk_cache_slots=0x10)
/dev/vdd1 on /root/bindmnt type reiser4
(rw,relatime,atom_max_size=0x3d88e,atom_max_age=0x927c0,atom_min_size=0x100,atom_max_flushers=0x1,cbk_cache_slots=0x10)
Thanks,
Edward.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
2021-08-14 11:00 ` Edward Shishkin
@ 2021-08-16 19:22 ` Metztli Information Technology
0 siblings, 0 replies; 13+ messages in thread
From: Metztli Information Technology @ 2021-08-16 19:22 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-devel, linux-kernel, Andrew Morton
On 8/14/21 4:00 AM, Edward Shishkin wrote:
> On 08/13/2021 05:20 PM, Metztli Information Technology wrote:
>
> [...]
>
>>>>
>>>> Notwithstanding, I would appreciate if you can take a look at the
>>>> attached patch. Probably it can be streamlined and/or improved
>>>> further to minimize pain on subsequent Linux kernel upgrades.
>>>
>>>
>>> That patch is an attempt to swim against the current ;)
>>>
>>> I no longer remember, why they want to get rid of set_fs for already
>>> 15
>>> years, but ->read() and ->write() methods seem to be deprecated, and
>>> the
>>> correct way would be to implement the new ->read_iter() and
>>> write_iter()
>>> methods, where reiser4 works with "chunked" streams, represented by
>>> iov_iter structure, rather than with "continuous" streams,
>>> represented
>>> by char __user *buf. The task is not that difficult, but rather time
>>> consuming - I don't have a time for this right now..
>>
>> On Sun, Jun 20, 2021 at 10:45 AM Edward Shishkin
>> <edward.shishkin@gmail.com> wrote:
>> So, I have implemented ->read_iter() for all plugins (*). It is
>> included
>> to reiser4-for-5.12 stuff. Not sure if it is enough to make
>> distro with
>> root over reiser4 though: ->write_iter() is not yet
>> implemented (not so
>> trivial because of transactions).
>> (*)
>> https://github.com/edward6/reiser4/commit/ac72aba7e8bb16a28755c1b2b762971927d17c3c
>> https://github.com/edward6/reiser4/commit/4d3200fbcb2003c680cdb822e3f616d3fa83c391
>> Edward.
>
> Hello,
>
> Now the new striped file plugin implements ->write_iter():
> https://github.com/edward6/reiser4/commit/a3795ffffbb841bfaa66bfb18c12fb317533d1ff
>
Wow! That must have been a lot of extra work on your part, Sir, Спасибо!
Debian Installer (d-i) makes use of BusyBox. Notwithstanding, for
whatever reason, BusyBox barebones (link) mount utility failed with
similar message -- even though I took care to build the latest from source:
< https://www.busybox.net/ >
I had to hack a mount-udeb small package, wrapping mount and umount within:
< https://metztli.it/readOnlyEphemeral/mount-udeb_2.37.1-1_amd64.udeb >
by utilizing debian packaging for previous version of util-linux
< https://packages.debian.org/sid/util-linux >
and a more recent util linux source
< https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.37/ >
That solved the d-i 'mount -o bind' and/or 'mount --bind' issue on /dev
resources (i.e., red underlined)
< https://metztli.it/bullseye-reiser5/non-busybox-mount-d-i.png >
> [...]
>
>> I finally got around to creating an SFRN 5.1.3 -enabled Debian
>> Installer (d-i) for upcoming Debian 11 (codenamed Bullseye). Applied
>> your unstable reiser4 for 5.12 patch onto my debianized hack packaging
>> for Linux kernel 5.12.19 EOL.
>>
>> I gave the d-i a spin in VirtualBox 6.1.26 and it choked on the
>> following code fragment:
>> ---------------------------------------------------------------------
>> setup_dev_linux () {
>> # Ensure static device nodes created during install are
>> preserved
>> # Tests in MAKEDEV require this is done in the D-I environment
>> mkdir -p /dev/.static/dev
>> chmod 700 /dev/.static/
>> mount --bind /target/dev /dev/.static/dev
>> # Mirror device nodes in D-I environment to target
>> mount --bind /dev /target/dev/
>> }
>> -----------------------------------------------------------------------
>>
>> specifically:
>> mount --bind /target/dev /dev/.static/dev
>>
>> See relevant code fragment next to VirtualBox VM, where I manually
>> entered the above directive:
>> < https://metztli.it/bullseye-reiser5/d-i-sfrn5-fail.jpg >
>>
>> i.e., '--bind' is causing the SFRN5 -enabled installer to bail out
>> *only* for this reiser4 unstable SFRN 5.1.3 -patched kernel. On the
>> other hand, as reported previously, no such issue occurs with your
>> reiser4 stable SFRN 4.0.2 patch applied to the *same* debianized kernel
>> source tree, Ed.
>
> I have checked - everything works for me (Linux-5.12).
>
> # mount /dev/vdd1 /mnt/test
> # volume.reiser4 /mnt/test
>
> Logical Volume Info:
> ID: 03ac5995-bf77-4851-a302-e875a6fd752f
> volume: 0x1 (asym)
> distribution: 0x1 (fsx32m)
> stripe: 262144
> segments: 1024
> bricks total: 3
> bricks in DSA: 3
> slots: 3
> map blocks: 2
> balanced: Yes
> health: OK
>
> # mkdir bindmnt
> # mount --bind /mnt/test bindmnt
> # mount
> [...]
> /dev/vdd1 on /mnt/test type reiser4
> (rw,relatime,atom_max_size=0x3d88e,atom_max_age=0x927c0,atom_min_size=0x100,atom_max_flushers=0x1,cbk_cache_slots=0x10)
> /dev/vdd1 on /root/bindmnt type reiser4
> (rw,relatime,atom_max_size=0x3d88e,atom_max_age=0x927c0,atom_min_size=0x100,atom_max_flushers=0x1,cbk_cache_slots=0x10)
Summarizing...
Your modified reiser4 SFRN 4.0.2 patch implementing '->read_iter() for
all plugins (*)' successfully enabled Debian Installer netboot for
bullseye to install upcoming Debian 11 Bullseye for AMD64 with hacked
Linux kernel 5.12.19-2 EOL
< https://metztli.it/bullseye-reiser5/guided-install-sfrn4.jpg >
Analogously, your modified reiser4 SFRN 5.1.3 patch implementing
'->read_iter() for all plugins (*)' and ' ->write_iter()' successfully
enabled Debian Installer netboot for bullseye to install upcoming Debian
11 Bullseye for AMD64 with hacked Linux kernel 5.12.19-2 EOL
guided installation (which defaults to MSDOS partitioning) with sample
from one of three options: /home and / root reiser4 but /boot JFS
< https://metztli.it/bullseye-reiser5/guided-install-sfrn5.jpg >
Or expert, which enables GPT partitioning; here is a / reiser4 and /boot
JFS VirtualBox 6.1.26 VM JPG snapshot:
< https://metztli.it/bullseye-reiser5/expert-install-sfrn5.jpg >
and the PoC reiser4 SFRN 5.1.3 -enabled Debian Installer (d-i):
< https://metztli.it/bullseye-reiser5/netboot-ng/metztli-reiser4-sfrn5.iso >
<
https://metztli.it/bullseye-reiser5/netboot-ng/metztli-reiser4-sfrn5.iso.SHA256SUM
>
I have not tested the bricks feature for which you specifically created
the SFRN 5.1.3 enhancement. Other Linux users are welcomed to test that
feature and provide feedback to you, Sir. The entry into reiser4 is
substantially lowered with a native reiser4 installer, which is what I
have done with the above ISO images freely made available but with *NO
IMPLICIT NOR EXPLICIT WARRANTIES*
Best Professional Regards.
P.S. Reiser4 quirk: If during expert installation of reiser4 -enhanced
Debian /tmp is formatted in other than reiser4, after a reboot
attempting a MySQL/MariaDB installation will fail. I experienced that in
a remote bare metal server.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
@ 2020-12-25 16:42 Metztli Information Technology
0 siblings, 0 replies; 13+ messages in thread
From: Metztli Information Technology @ 2020-12-25 16:42 UTC (permalink / raw)
To: edward.shishkin, reiserfs-devel, hch, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10089 bytes --]
On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin <edward.shishkin@gmail.com> wrote:
>
> On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed-
> >
> > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i).
> > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
> >
> > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image.
> >
> > Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16:
> > ...
> > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
> > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
> > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
> > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
> > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
> > Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed
> > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
> > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.
> > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb
> >
>
> [...]
>
> >
> > Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned.
> > Notwithstanding, I manually verified that I am able to touch a file and set it +x executable.
> >
> > Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with
> > an apparently related error --can not proceed any further.
> >
> > Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output
> > from an attempt on my physical development machine.
> > ...
> > [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4.
> > [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
> > [ 509.326270] device-mapper: uevent: version 1.0.3
> > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
> > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> > [ 509.915300] sdb: sdb1 sdb2 sdb3
> > [ 511.973360] sdb: sdb1 sdb2 sdb3
> > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS
> > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
> > [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> > [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > [ 643.759980] reiser4: brick /dev/sda6 activated
> > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*]
> > [ 898.761385] reiser4: brick /dev/sda6 deactivated
> > [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > [ 999.093480] reiser4: brick /dev/sda6 activated
> > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap)
> > [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot)
>
>
> Hello.
>
> This is because of VFS changes in Linux-5.10.X.
> Specifically, because of the following patch:
> https://lkml.org/lkml/2020/8/17/174
> In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
Earlier I spun up a Google Compute Engine (GCE) AMD Epyc instance from a snapshot with kernel 5.9.15-1
< https://metztli.it/buster/gce-amd-epyc-5.9.15-1.png >
and built an stable reiser4 SFRN 4.0.2 kernel within the Debian packaging for 5.10.2-1 framework.
Subsequently, I built my custom Debian-Installer (d-i) and gave it another try. Same kernel fail:
... tail -n 30 /var/log/syslog
Dec 25 10:23:06 kernel: [ 164.409309] reiser4: sda7: found disk format 4.0.2.
Dec 25 10:23:06 kernel: [ 164.459638] reiser4: sda7: using Hybrid Transaction Model.
Dec 25 10:23:07 apt-install: Queueing package jfsutils for later installation
Dec 25 10:23:07 apt-install: Queueing package reiser4progs for later installation
Dec 25 10:23:07 apt-install: Queueing package initramfs-tools for later installation
Dec 25 10:23:07 apt-install: Queueing package linux-base for later installation
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 3 (pipe:[8689]) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5687: /bin/sh
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 3 (pipe:[8689]) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 4 (/dev/pts/0) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
Dec 25 10:23:07 main-menu[240]: (process:3056): File descriptor 5 (/dev/pts/0) leaked on pvs invocation.
Dec 25 10:23:07 main-menu[240]: (process:3056): Parent PID 5726: /bin/sh
Dec 25 10:23:07 main-menu[240]: INFO: Falling back to the package description for brltty-udeb
Dec 25 10:23:07 main-menu[240]: INFO: Falling back to the package description for brltty-udeb
Dec 25 10:23:07 main-menu[240]: INFO: Menu item 'bootstrap-base' selected
Dec 25 10:23:07 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://mirrors.namecheap.com/debian/
Dec 25 10:23:07 debootstrap: /usr/sbin/debootstrap:
Dec 25 10:23:07 debootstrap: line 1596:
Dec 25 10:23:07 debootstrap: /target/test-exec: Invalid argument
Dec 25 10:23:07 debootstrap:
Dec 25 10:23:07 debootstrap: E: NOEXEC
Dec 25 10:23:07 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
Dec 25 10:23:07 kernel: [ 165.368737] kernel read not supported for file /test-exec (pid: 5940 comm: debootstrap)
Dec 25 10:24:57 init: starting pid 222, tty '/dev/tty3': '-/bin/sh'
...
and dmesg from within the installer environment:
...tail -n 20 /var/log/debian-5.10.2.1.dmesg
[ 133.743458] raid6: sse2x2 xor() 7821 MB/s
[ 133.825936] raid6: sse2x1 gen() 11332 MB/s
[ 133.914288] raid6: sse2x1 xor() 7571 MB/s
[ 133.914290] raid6: using algorithm sse2x2 gen() 15942 MB/s
[ 133.914291] raid6: .... xor() 7821 MB/s, rmw enabled
[ 133.914293] raid6: using ssse3x2 recovery algorithm
[ 133.915254] xor: automatically using best checksumming function avx
[ 133.942598] Btrfs loaded, crc32c=crc32c-generic
[ 133.970966] JFS: nTxBlock = 8192, nTxLock = 65536
[ 133.994981] Loading Reiser4 (format release: 4.0.2) See www.namesys.com for a description of Reiser4.
[ 134.047520] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
[ 134.529127] device-mapper: uevent: version 1.0.3
[ 134.529484] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
[ 163.693555] sda: sda1 sda2 < sda5 sda6 sda7 >
[ 164.012669] Adding 999420k swap on /dev/sda6. Priority:-2 extents:1 across:999420k FS
[ 164.375818] reiser4: sda5: found disk format 4.0.2.
[ 164.393521] reiser4: sda5: using Hybrid Transaction Model.
[ 164.409309] reiser4: sda7: found disk format 4.0.2.
[ 164.459638] reiser4: sda7: using Hybrid Transaction Model.
[ 165.368737] kernel read not supported for file /test-exec (pid: 5940 comm: debootstrap)
...
Please, note that I even replaced debootstrap UDEB with a newer source release to no avail.
>
> So, Christoph, what to do now for file systems which implement
> ->read() method of file operations? It seems that chroot doesn't work
> for them. And people are not able to release distros with upgraded
> kernels..
>
> Thanks,
> Edward.
Best Professional Regards.
--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.15 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---------------------------------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20201223160113.C1A15732548B@huitzilopochtli.metztli-it.com>]
* Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
[not found] <20201223160113.C1A15732548B@huitzilopochtli.metztli-it.com>
@ 2020-12-23 23:40 ` Edward Shishkin
0 siblings, 0 replies; 13+ messages in thread
From: Edward Shishkin @ 2020-12-23 23:40 UTC (permalink / raw)
To: Metztli Information Technology,
ReiserFS development mailing list, Christoph Hellwig,
linux-kernel
On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> Niltze [ЗдравÑтвуйте : Hello], Ed-
>
> I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to generate a kernel component for my Debian-Installer (d-i).
> The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
>
> Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set of components for d-i I built the d-i image.
>
> Fact is, the installer throws an error in *both* bare metal and VirtualBox 6.1.16:
> ...
> Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main --debian-installer --resolve-deps --keyring=/usr/share/keyrings/archive.gpg buster /target http://deb.debian.org/debian/
> Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: /target/test-exec: Invalid argument
> Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file /test-exec (pid: 10077 comm: debootstrap)
> Dec 22 20:19:56 debootstrap: E: NOEXEC
> Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' mounted with noexec or nodev
> Dec 22 20:20:12 base-installer: error: exiting on error base-installer/debootstrap-failed
> Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
> Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' failed.
> Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package description for brltty-udeb
>
[...]
>
> Apparently, d-i [Debian-installer] complains about being unable to set the test file executable and causes the error when 1 is returned.
> Notwithstanding, I manually verified that I am able to touch a file and set it +x executable.
>
> Furthermore, tricking the function return value to 0 I am able to make d-i continue with the latest SFRN5 installation (see [*trick*] below); yet, subsequently halts again with
> an apparently related error --can not proceed any further.
>
> Digging deeper with dmesg, we can see that apparently it is the kernel which cannot 'read' properly. Please find a partial dmesg log with relevant output
> from an attempt on my physical development machine.
> ...
> [ 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See reiser4.wiki.kernel.org for a description of Reiser4.
> [ 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
> [ 509.326270] device-mapper: uevent: version 1.0.3
> [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) initialised: dm-devel@redhat.com
> [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6
> [ 509.915300] sdb: sdb1 sdb2 sdb3
> [ 511.973360] sdb: sdb1 sdb2 sdb3
> [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 extents:1 across:9765884k FS
> [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol (fs/reiser4/init_volume.c:222)[edward-1932]:
> [ 636.240812] NOTICE: brick /dev/sda6 has been registered
> [ 636.243003] reiser4 (sda6): found disk format 5.1.3.
> [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> [ 643.759980] reiser4: brick /dev/sda6 activated
> [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> [ 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> [ 643.813488] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> [ 648.168730] kernel read not supported for file /test-exec (pid: 9876 comm: debootstrap) [*trick*]
> [ 898.761385] reiser4: brick /dev/sda6 deactivated
> [ 991.001332] reiser4 (sda6): found disk format 5.1.3.
> [ 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> [ 999.093480] reiser4: brick /dev/sda6 activated
> [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
> [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
> [ 1009.362737] ext2 filesystem being mounted at /target/boot supports timestamps until 2038 (0x7fffffff)
> [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 comm: debootstrap)
> [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 15960 comm: chroot)
Hello.
This is because of VFS changes in Linux-5.10.X.
Specifically, because of the following patch:
https://lkml.org/lkml/2020/8/17/174
In the upstream git repository it is commit 4d03e3cc59828c82ee89ea6e2
So, Christoph, what to do now for file systems which implement
->read() method of file operations? It seems that chroot doesn't work
for them. And people are not able to release distros with upgraded
kernels..
Thanks,
Edward.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-08-16 19:22 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-08 7:43 [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\) Metztli Information Technology
-- strict thread matches above, loose matches on Subject: below --
2021-02-08 12:54 Metztli Information Technology
2021-02-08 16:03 ` Edward Shishkin
2021-02-16 15:56 ` Jose R Rodriguez
2021-02-16 20:02 ` Edward Shishkin
2021-02-19 8:12 ` Jose R Rodriguez
2021-02-26 7:33 ` Jose R Rodriguez
2021-08-04 10:17 ` Metztli Information Technology
2021-08-13 15:20 ` Metztli Information Technology
2021-08-14 11:00 ` Edward Shishkin
2021-08-16 19:22 ` Metztli Information Technology
2020-12-25 16:42 Metztli Information Technology
[not found] <20201223160113.C1A15732548B@huitzilopochtli.metztli-it.com>
2020-12-23 23:40 ` Edward Shishkin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).
