linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Miguel Ojeda <ojeda@kernel.org>
Subject: Re: [PATCH v2] ELF: add and use SUPPRESS_WARN_UNUSED_RESULT
Date: Fri, 25 Jun 2021 20:13:20 -0700	[thread overview]
Message-ID: <CAHk-=wgitzn6sqXZ0YjFW-pYadEXU808QPJZ5OXvM5oB47K_Lw@mail.gmail.com> (raw)
In-Reply-To: <YNaS5AZDDpL3gJfe@zeniv-ca.linux.org.uk>

On Fri, Jun 25, 2021 at 7:37 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Wasn't there some emulator (dosemu? wine?) that relied upon that?
> Said that, I could be easily wrong - half-asleep right now...

Different issue.

dosemu used to use vm86 mode to do hardware acceleration of 16-bit
emulation. And the way vm86 mode works, it all has to be mapped
beginning at address 0.

So yes, dosemu used to do a mmap at address 0 too, but it didn't use
this ELF mmap MMAP_PAGE_ZERO personality thing to do it, it just did
its own (it also wants a lot more than one page).

Nobody uses vm86 mode any more, because hardware acceleration of
16-bit code just isn't relevant any more. Any 16-bit code you have
doesn't need special hw modes to run sufficiently fast.

Plus x86-64 doesn't support vm86 mode at all (well, technically you
can do it in a VM that runs a 32-bit OS if you really really want to,
but see above as to why you don't really need it).

There are other things that have mmap'ed things at zero. I think all
PA-RISC HP-UX binaries used to do the same thing iBCS2 did, and the
compiler would actually hoist loads to before the NULL pointer test,
so it was pretty much "architectural". Afaik, that's the same reason
why iBCS2 did that zero mapping too, but PA-RISC just required it a
lot more.

It's a horrible thing to do, and only makes debugging harder (because
you won't actually get a SIGSEGV on a NULL pointer load, you'll just
silently get a zero value and your buggy program will continue
running).

                 Linus

  reply	other threads:[~2021-06-26  3:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25 19:52 [PATCH] ELF: add and use SUPRESS_WARN_UNUSED_RESULT Alexey Dobriyan
2021-06-25 20:34 ` Miguel Ojeda
2021-06-25 21:10   ` Alexey Dobriyan
2021-06-25 21:11     ` Randy Dunlap
2021-06-25 21:57     ` Miguel Ojeda
2021-06-26  6:44       ` [PATCH] ELF: add and use SUPRESS_WARN_UNUSED_RESULT\ Alexey Dobriyan
2021-06-26 14:29         ` Miguel Ojeda
2021-06-25 21:13 ` [PATCH v2] ELF: add and use SUPPRESS_WARN_UNUSED_RESULT Alexey Dobriyan
2021-06-25 23:30   ` Andrew Morton
2021-06-26  2:05     ` Linus Torvalds
2021-06-26  2:37       ` Al Viro
2021-06-26  3:13         ` Linus Torvalds [this message]
2021-06-26  6:40     ` Alexey Dobriyan

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='CAHk-=wgitzn6sqXZ0YjFW-pYadEXU808QPJZ5OXvM5oB47K_Lw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [PATCH v2] ELF: add and use SUPPRESS_WARN_UNUSED_RESULT' \
    /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

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