Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     Jonathan Corbet <corbet@lwn.net>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Mike Rapoport <rppt@kernel.org>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Ira Weiny <ira.weiny@intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH] Documentation/page_tables: Add info about MMU/TLB and Page Faults
Date:   Wed, 09 Aug 2023 15:27:53 +0200
Message-ID: <2443562.jE0xQCEvom@suse>
In-Reply-To: <CACRpkdYcAWDZV0GkdP6gEJv971wjYQ-8WweHkreTJ-w7sfKKQg@mail.gmail.com>
References: <20230728120054.12306-1-fmdefrancesco@gmail.com>
 <CACRpkdYcAWDZV0GkdP6gEJv971wjYQ-8WweHkreTJ-w7sfKKQg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

On luned=C3=AC 7 agosto 2023 11:40:30 CEST Linus Walleij wrote:
> Hi Fabio,
>=20
> I'm back from vacation! Overall this documentation looks good and
> in line with the reset in this section.
>=20
> On Fri, Jul 28, 2023 at 2:01=E2=80=AFPM Fabio M. De Francesco
>=20
> <fmdefrancesco@gmail.com> wrote:
> > +One cause of page faults is due to bugs (or maliciously crafted=20
addresses)
> > and +happens when a process tries to access a range of memory that it
> > doesn't have +permission to. This could be because the memory is reserv=
ed
> > for the kernel or +for another process, or because the process is tryin=
g=20
to
> > write to a read-only +section of memory. When this happens, the kernel
> > sends a Segmentation Fault +(SIGSEGV) signal to the process, which usua=
lly
> > causes the process to terminate.
> This "segmentation fault" (SIGSEGV reads "signal segmentation violation)
> is actually a bit hard to understand for people not familiar
> with the 1970ies hardware.=20

Linus,

Actually, I see a lot of "Segmentation fault (core dumped)" because I still=
=20
develop in user space.

Stupid distractions are enough to get that message printed...

#include <stdio.h>
#include <malloc.h>

int main() {
        int *p1, *p2;
        p2 =3D malloc(sizeof(int));
        *p2 =3D 9;
        printf("*p2 is %d\n", *p1);
        return 0;
}

fabio@suse:/tmp> gcc -o test test.c=20
fabio@suse:/tmp> ./test
Segmentation fault (core dumped)

=46urthermore, everybody can still type "man signal.h" (document written in=
=20
2017) and lookup the table of the POSIX signals and see that SIGSEGV is for=
=20
"Invalid memory reference.".=20
>
> [Snip]
>
> Other programs and the kernel memory are also in inaccessible segments,
> so accessing any of the own segments in the wrong way, or another programs
> segment, or an unmapped segment (virtual memory) would all result in the
> SIGSEGV opaque message "segmentation fault"
>=20
> I don't know how to reflect this in a good way in the documentation
> though, maybe
> copy/paste/edit some of my text or I can try to write something as an
> additional patch if you prefer.

I suspect that people is much more used to get more "Segmentation fault" th=
ese=20
days than in the 1970's (when developers probably were a little more carefu=
l=20
with pointers - at least this is what I have heard about this subject :-)).

BTW, please feel free to change / extend this paragraph with a follow up=20
patch.

Thanks for your comments,

=46abio
> Yours,
> Linus Walleij