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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 02/08/2021 05:03 PM, 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


This is because of VFS changes in Linux-5.10.X.
Specifically, because of the following patch:
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

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..

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).



[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux