linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Palmer Dabbelt <palmer@rivosinc.com>
Subject: Re: Linux 6.2-rc2
Date: Thu, 5 Jan 2023 22:44:09 +0900	[thread overview]
Message-ID: <CAK7LNAQz6f_1jsp22HRRQqwfb6jh8_BGMgyUtE9TK8ENoHzJxQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wg6K2qge_MWHX9DurBUpbd54ih482gV5rf8ts7v8TUipA@mail.gmail.com>

On Wed, Jan 4, 2023 at 3:34 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Jan 3, 2023 at 2:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > The purpose of this change is to prevent .note.GNU-stack from deciding
> > the section type of the .notes output section, and so keeping it in
> > its own section should be sufficient. E.g.,
> >
> > -       /DISCARD/ : { *(.note.GNU-stack) }                              \
> > +       .note.GNU-stack : { *(.note.GNU-stack) }                        \
>
> This seems to work for everybody, so let's go with this. Masahiro?
>
>                Linus



Sorry for the delay, I completely missed this thread.


Tested-by: Masahiro Yamada <masahiroy@kernel.org>



It works for me, but the comment block above should be
changed accordingly, for example:

  /*
 - * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler.
 + * Separte note.GNU-stack, which is emitted as PROGBITS by the compiler.
   * Otherwise, the type of .notes section would become PROGBITS
instead of NOTES.
   */


This change, however, leaves an empty .note.GNU-stack section in vmlinux.



I personally prefer discarding .note.GNU-stack entirely because
GNU linker does not leave empty .note.GNU-stack when linking
user-space programs.



Because I did not notice the discussion was happening in this thread,
I submitted a different approach for fixing s390, and it was quickly merged:

  https://lore.kernel.org/lkml/20230105031306.1455409-1-masahiroy@kernel.org/

This approach requires RUNTIME_DISCARD_EXIT for each architecture, though.

I do not know how Michael will fix powerpc.







While I was looking into this issue,
I noticed the real issue is,
how to discard sections is up to arch maintainers.



[1] Most architectures discard .exit.* sections at run-time.

     Just run
      git grep EXIT_TEXT
       or
     find . -name vmlinux.lds.S | xargs grep "at runtime"


[2] If .exit.* is allocated, then later discarded, it is kept.
    (the first occurrence wins, in other words,
    the sections defined in /DISCARD/ are not necessarily discarded)


[3]  Despite the fact of [1], many architectures forget to
     define RUNTIME_DISCARD_EXIT.
     They still work because they put DISCARD
     at the end of their linker scripts.


[4]  arm64 puts DISCARD at the beginning of the linker
     script, and defines RUNTIME_DISCARD_EXIT because otherwise
     .exit* are discarded due to the "first wins" rule.


[5]  If we really want to discard more sections, we often end
     up with moving DISCARD up, and at this point, we realize
     that RUNTIME_DISCARD_EXIT is missing.





I think it is unreadable (and fragile)
to keep/discard sections depending on the particular
order in the linker scripts.


Is there any better approach to make sure to discard
sections defined in DISCARDS?






--
Best Regards
Masahiro Yamada

  reply	other threads:[~2023-01-05 13:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-01 22:01 Linux 6.2-rc2 Linus Torvalds
2023-01-02 10:20 ` Build regressions/improvements in v6.2-rc2 Geert Uytterhoeven
2023-01-02 22:56 ` Linux 6.2-rc2 Guenter Roeck
2023-01-03  0:21   ` Linus Torvalds
2023-01-03  1:45     ` Guenter Roeck
2023-01-03  2:13       ` Linus Torvalds
2023-01-03  3:57         ` Guenter Roeck
2023-01-03  4:26           ` Nathan Chancellor
2023-01-03  9:14             ` Thorsten Leemhuis
2023-01-03 10:58         ` Ard Biesheuvel
2023-01-03 11:45           ` Conor Dooley
2023-01-03 12:22           ` Guenter Roeck
2023-01-03 18:26           ` Nathan Chancellor
2023-01-03 18:34           ` Linus Torvalds
2023-01-05 13:44             ` Masahiro Yamada [this message]
2023-01-04 10:34           ` Michael Ellerman
2023-01-10  0:32           ` SeongJae Park
2023-01-10 18:39             ` Masahiro Yamada
2023-01-10 19:14               ` SeongJae Park
2023-01-23  9:09                 ` Masahiro Yamada
2023-01-23 18:27                   ` SeongJae Park
2023-02-06 22:56                     ` SeongJae Park
2023-02-08  1:27                       ` Masahiro Yamada
2023-01-13 14:59           ` Tom Saeger

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=CAK7LNAQz6f_1jsp22HRRQqwfb6jh8_BGMgyUtE9TK8ENoHzJxQ@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dalias@libc.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=palmer@rivosinc.com \
    --cc=torvalds@linux-foundation.org \
    --cc=ysato@users.sourceforge.jp \
    /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).