Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)

From: Jose R Rodriguez
Date: Fri Feb 19 2021 - 03:13:29 EST

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@xxxxxxxxx> 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@xxxxxxxxxx
> > > > > > [  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/
From c241dcb5b611fdb45239b536eb3acd37d09aab95 Mon Sep 17 00:00:00 2001
From: Metztli Information Technology <jose@xxxxxxxxxx>
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: reiser4-for-metztli-5.10.13-stable.patch.gz
Description: application/gzip

Attachment: reiser4-for-metztli-5.10.15.unstable.patch.gz
Description: application/gzip