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

[Edward Shishkin <edward.shishkin@gmail.com>]

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

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


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.