linux-kernel - Reiser4 SFRN 4.0.2 kernel 5.10.29/48 on Google Compute Engine (GCE): general protection fault, probably for non-canonical address xyz

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <ccbf78bd8d81b3a716c29d238457c4cc5c5f5afd.camel@metztli.com>
Date:   Mon, 19 Jul 2021 17:47:53 -0700
From:   Metztli Information Technology <jose.r.r@...ztli.com>
To:     Edward Shishkin <edward.shishkin@...il.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        ReiserFS Development List <reiserfs-devel@...r.kernel.org>
Subject: Reiser4 SFRN 4.0.2 kernel 5.10.29/48 on Google Compute Engine
 (GCE): general protection fault, probably for non-canonical address xyz

Niltze [Hello], Ed-

I have recently experienced memory not being released, and
consequently, crashes with the referenced subject being output.

This issue seems to have an affinity to the Google Compute Engine (GCE)
KVM virtualization -based cloud fabric -- where I run/test most of my
Debian -based kernels. It has occurred with reiser4 -enabled kernels
5.10.29 and 5.10.48 built with GCC10 for Debian Bulleye.

Whereas I built those kernels in a bare metal AMD Epyc reiser4 SFRN
4.0.2 environment with 128Gb of RAM and running either of the above
kernels and/or 5.10.42:
< https://metztli.it/bullseye/moiocoiani.png >
I did not experience any issues in the bare metal unit while building
the kernels.

Notwithstanding, utilizing the kernel cloud versions generated for
those kernels referenced above in Debian upcoming Bullseye cloud
instances hosted in GCE seem to swallow the memory and eventually crash
during sustained operations, like SSH incoming 17 Gig data and/or unTAR
12 Gb archive, etc. Indeed, in these cloud instances the memory is
modest -- like 6Gb and/or 16Gb RAM; yet, it should not happen. (see
attached GPFs sections).

Recently I have seen similar GPFs reports in the Linux mailing list --
where users are obviously not using reiser4 -- and thought there might
be a relation.

Best Professional Regards.

P.S. I am patching to enable 'kernel read' on reiser4 -based Debian
netboot installer; including your reiser4 SFRN 4.0.2 modified patch for
5.10.47 kernels and JFS 5.11 for 5.10.xy patches (included)

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

View attachment "cohuatl-gpf_07-19-2021.amatl" of type "text/plain" (20639 bytes)

View attachment "cohuatl_07-19-2021_gpf.amatl" of type "text/plain" (99877 bytes)

View attachment "linux-5.10.26-enable-kernel-read-on-reiser4.patch" of type "text/x-patch" (45056 bytes)

Download attachment "reiser4-for-metztli-5.10.47-stable.patch.gz" of type "application/gzip" (623808 bytes)

View attachment "jfs-5.11-for-5.10.15.patch" of type "text/x-patch" (4582 bytes)