linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ariel marcovitch <arielmarcovitch@gmail.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: mpe@ellerman.id.au, paulus@samba.org,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc: fix alignment bug whithin the init sections
Date: Fri, 18 Dec 2020 22:43:06 +0200	[thread overview]
Message-ID: <CAFGKuwoE=Mh3jEnzjfCGzMw3d+R_Z=i+HGEVR+6-PrMYL9oO1g@mail.gmail.com> (raw)
In-Reply-To: <4716e80b-db6f-7669-684f-398971ed5f2e@csgroup.eu>

On Fri, Dec 18, 2020 at 5:39 PM Christophe Leroy <
christophe.leroy@csgroup.eu> wrote:

> It can cause, or it causes ? Did you encounter the issue ?
>
Yes, in configs that result in the section layout I described, the crush is
consistent.

>
> > The init sections are ordered like this:
> >       .init.text
> >       .exit.text
> >       .init.data
> >
> > Currently, these sections aren't page aligned.
> >
> > Because the init code is mapped read-only at runtime and because the
> > .init.text section can potentially reside on the same physical page as
> > .init.data, the beginning of .init.data might be mapped read-only along
> > with .init.text.
>
> init code is mapped PAGE_KERNEL_TEXT.
>
> Whether PAGE_KERNEL_TEXT is read-only or not depends on the selected
> options.
>
You are right, of course. Should I change the commit message to 'might be
mapped' or something?

>
> > Then when the kernel tries to modify a variable in .init.data (like
> > kthreadd_done, used in kernel_init()) the kernel panics.
> >
> > To avoid this, I made these sections page aligned.
>
> Should write this unpersonal, something like "To avoid this, make these
> sections page aligned"
>
Noted, thanks.


>
> >
> > Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
> > Signed-off-by: Ariel Marcovitch <ariel.marcovitch@gmail.com>
> > ---
> >   arch/powerpc/kernel/vmlinux.lds.S | 7 +++++++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/vmlinux.lds.S
> b/arch/powerpc/kernel/vmlinux.lds.S
> > index 326e113d2e45..e3a7c90c03f4 100644
> > --- a/arch/powerpc/kernel/vmlinux.lds.S
> > +++ b/arch/powerpc/kernel/vmlinux.lds.S
> > @@ -179,6 +179,11 @@ SECTIONS
> >   #endif
> >       } :text
> >
> > +     /* .init.text is made RO and .exit.text is not, so we must
> > +      * ensure these sections reside in separate physical pages.
> > +      */
> > +     . = ALIGN(PAGE_SIZE);
> > +
>
> In principle, as it is text, it should be made RO as well. But what
> happens at the begining doesn't
> really matter, anyway .exit.text should never be executed and is discarded
> together with init text.
> So, I think it is OK the live with it as is for the time being.


> Making it page aligned makes sense anyway.
>
> Should we make _einittext page aligned instead, just like _etext ?

Yes, this will probably be better (because when _einittext is not aligned,
the part of the page after _einittext is mapped RO implicitly, and it's
hard to notice from the code). I suppose you mean something like this:
                _sinittext = .;
                INIT_TEXT
+
+               . = ALIGN(.);
                _einittext = .;

>       /* .exit.text is discarded at runtime, not link time,
> >        * to deal with references from __bug_table
> >        */
> > @@ -186,6 +191,8 @@ SECTIONS
> >               EXIT_TEXT
> >       }
> >
> > +     . = ALIGN(PAGE_SIZE);
> > +
>
> Here for sure, as you explain in the coming log, this needs to be
> separated from init text. So
> making it aligned is a must.


> >       .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
> >               INIT_DATA
> >       }
> >
> > base-commit: 1398820fee515873379809a6415930ad0764b2f6
> >
>
> Christophe
>
Thanks for your time,
        Ariel Marcovitch

      reply	other threads:[~2020-12-18 20:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-13 18:35 [PATCH] powerpc: fix alignment bug whithin the init sections Ariel Marcovitch
2020-12-18 15:38 ` Christophe Leroy
2020-12-18 20:43   ` ariel marcovitch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFGKuwoE=Mh3jEnzjfCGzMw3d+R_Z=i+HGEVR+6-PrMYL9oO1g@mail.gmail.com' \
    --to=arielmarcovitch@gmail.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).