* [PATCH 6/6] drivers: base/node.c: fixes a kernel-doc markups
From: Mauro Carvalho Chehab @ 2019-06-18 18:51 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Greg Kroah-Hartman, Rafael J. Wysocki
In-Reply-To: <a83ea390bc28784518fce772b4c961ea1c976f14.1560883872.git.mchehab+samsung@kernel.org>
There was a typo at the name of the vars inside the kernel-doc
comment, causing those warnings:
./drivers/base/node.c:690: warning: Function parameter or member 'mem_nid' not described in 'register_memory_node_under_compute_node'
./drivers/base/node.c:690: warning: Function parameter or member 'cpu_nid' not described in 'register_memory_node_under_compute_node'
./drivers/base/node.c:690: warning: Excess function parameter 'mem_node' description in 'register_memory_node_under_compute_node'
./drivers/base/node.c:690: warning: Excess function parameter 'cpu_node' description in 'register_memory_node_under_compute_node'
There's also a description missing here:
./drivers/base/node.c:78: warning: Function parameter or member 'hmem_attrs' not described in 'node_access_nodes'
Copy an existing description from another function call.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
drivers/base/node.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 9be88fd05147..4ee32db9d61d 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -673,8 +673,8 @@ int register_cpu_under_node(unsigned int cpu, unsigned int nid)
/**
* register_memory_node_under_compute_node - link memory node to its compute
* node for a given access class.
- * @mem_node: Memory node number
- * @cpu_node: Cpu node number
+ * @mem_nid: Memory node number
+ * @cpu_nid: Cpu node number
* @access: Access class to register
*
* Description:
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Dave Martin @ 2019-06-18 16:50 UTC (permalink / raw)
To: Florian Weimer
Cc: Yu-cheng Yu, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <8736k67tdc.fsf@oldenburg2.str.redhat.com>
On Tue, Jun 18, 2019 at 06:25:51PM +0200, Florian Weimer wrote:
> * Dave Martin:
>
> > On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote:
> >> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote:
> >> > * Yu-cheng Yu:
> >> >
> >> > > > I assumed that it would also parse the main executable and make
> >> > > > adjustments based on that.
> >> > >
> >> > > Yes, Linux also looks at the main executable's header, but not its
> >> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader.
> >> > >
> >> > > >
> >> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak
> >> > > > the existing loader anyway.
> >> > > >
> >> > > > No valid statically-linked binaries exist today, so this is not a
> >> > > > consideration at this point.
> >> > >
> >> > > So from kernel, we look at only PT_GNU_PROPERTY?
> >> >
> >> > If you don't parse notes/segments in the executable for CET, then yes.
> >> > We can put PT_GNU_PROPERTY into the loader.
> >>
> >> Thanks!
> >
> > Would this require the kernel and ld.so to be updated in a particular
> > order to avoid breakage? I don't know enough about RHEL to know how
> > controversial that might be.
>
> There is no official ld.so that will work with the current userspace
> interface (in this patch submission). Upstream glibc needs to be
> updated anyway, so yet another change isn't much of an issue. This is
> not a problem; we knew that something like this might happen.
>
> Sure, people need a new binutils with backports for PT_GNU_PROPERTY, but
> given that only very few people will build CET binaries with older
> binutils, I think that's not a real issue either.
OK, just wanted to check we weren't missing any requirement for x86.
This approach should satisfy the requirement for arm64 nicely.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Florian Weimer @ 2019-06-18 16:25 UTC (permalink / raw)
To: Dave Martin
Cc: Yu-cheng Yu, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <20190618162005.GF2790@e103592.cambridge.arm.com>
* Dave Martin:
> On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote:
>> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote:
>> > * Yu-cheng Yu:
>> >
>> > > > I assumed that it would also parse the main executable and make
>> > > > adjustments based on that.
>> > >
>> > > Yes, Linux also looks at the main executable's header, but not its
>> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader.
>> > >
>> > > >
>> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak
>> > > > the existing loader anyway.
>> > > >
>> > > > No valid statically-linked binaries exist today, so this is not a
>> > > > consideration at this point.
>> > >
>> > > So from kernel, we look at only PT_GNU_PROPERTY?
>> >
>> > If you don't parse notes/segments in the executable for CET, then yes.
>> > We can put PT_GNU_PROPERTY into the loader.
>>
>> Thanks!
>
> Would this require the kernel and ld.so to be updated in a particular
> order to avoid breakage? I don't know enough about RHEL to know how
> controversial that might be.
There is no official ld.so that will work with the current userspace
interface (in this patch submission). Upstream glibc needs to be
updated anyway, so yet another change isn't much of an issue. This is
not a problem; we knew that something like this might happen.
Sure, people need a new binutils with backports for PT_GNU_PROPERTY, but
given that only very few people will build CET binaries with older
binutils, I think that's not a real issue either.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Dave Martin @ 2019-06-18 16:20 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Florian Weimer, Peter Zijlstra, Thomas Gleixner, x86,
H. Peter Anvin, Ingo Molnar, linux-kernel, linux-doc, linux-mm,
linux-arch, linux-api, Arnd Bergmann, Andy Lutomirski,
Balbir Singh, Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <b0491cb517ba377da6496fe91a98fdbfca4609a9.camel@intel.com>
On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote:
> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote:
> > * Yu-cheng Yu:
> >
> > > > I assumed that it would also parse the main executable and make
> > > > adjustments based on that.
> > >
> > > Yes, Linux also looks at the main executable's header, but not its
> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader.
> > >
> > > >
> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak
> > > > the existing loader anyway.
> > > >
> > > > No valid statically-linked binaries exist today, so this is not a
> > > > consideration at this point.
> > >
> > > So from kernel, we look at only PT_GNU_PROPERTY?
> >
> > If you don't parse notes/segments in the executable for CET, then yes.
> > We can put PT_GNU_PROPERTY into the loader.
>
> Thanks!
Would this require the kernel and ld.so to be updated in a particular
order to avoid breakage? I don't know enough about RHEL to know how
controversial that might be.
Also:
What about static binaries distrubited as part of RHEL?
A user would also reasonably expect static binaries built using the
distro toolchain to work on top of the distro kernel... which might
be broken by this.
(When I say "broken" I mean that the binary would run, but CET
protections would be silently turned off.)
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-18 16:00 UTC (permalink / raw)
To: Florian Weimer
Cc: Dave Martin, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <87blyu7ubf.fsf@oldenburg2.str.redhat.com>
On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote:
> * Yu-cheng Yu:
>
> > > I assumed that it would also parse the main executable and make
> > > adjustments based on that.
> >
> > Yes, Linux also looks at the main executable's header, but not its
> > NT_GNU_PROPERTY_TYPE_0 if there is a loader.
> >
> > >
> > > ld.so can certainly provide whatever the kernel needs. We need to tweak
> > > the existing loader anyway.
> > >
> > > No valid statically-linked binaries exist today, so this is not a
> > > consideration at this point.
> >
> > So from kernel, we look at only PT_GNU_PROPERTY?
>
> If you don't parse notes/segments in the executable for CET, then yes.
> We can put PT_GNU_PROPERTY into the loader.
Thanks!
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Florian Weimer @ 2019-06-18 16:05 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Dave Martin, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <1ca57aaae8a2121731f2dcb1a137b92eed39a0d2.camel@intel.com>
* Yu-cheng Yu:
>> I assumed that it would also parse the main executable and make
>> adjustments based on that.
>
> Yes, Linux also looks at the main executable's header, but not its
> NT_GNU_PROPERTY_TYPE_0 if there is a loader.
>
>>
>> ld.so can certainly provide whatever the kernel needs. We need to tweak
>> the existing loader anyway.
>>
>> No valid statically-linked binaries exist today, so this is not a
>> consideration at this point.
>
> So from kernel, we look at only PT_GNU_PROPERTY?
If you don't parse notes/segments in the executable for CET, then yes.
We can put PT_GNU_PROPERTY into the loader.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-18 15:53 UTC (permalink / raw)
To: Florian Weimer
Cc: Dave Martin, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <87pnna7v1d.fsf@oldenburg2.str.redhat.com>
On Tue, 2019-06-18 at 17:49 +0200, Florian Weimer wrote:
> * Yu-cheng Yu:
>
> > The kernel looks at only ld-linux. Other applications are loaded by ld-
> > linux.
> > So the issues are limited to three versions of ld-linux's. Can we somehow
> > update those??
>
> I assumed that it would also parse the main executable and make
> adjustments based on that.
Yes, Linux also looks at the main executable's header, but not its
NT_GNU_PROPERTY_TYPE_0 if there is a loader.
>
> ld.so can certainly provide whatever the kernel needs. We need to tweak
> the existing loader anyway.
>
> No valid statically-linked binaries exist today, so this is not a
> consideration at this point.
So from kernel, we look at only PT_GNU_PROPERTY?
Yu-cheng
^ permalink raw reply
* Re: [PATCH] docs/vm: hwpoison.rst: Fix quote formatting
From: Valentin Schneider @ 2019-06-18 15:51 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-kernel, linux-doc
In-Reply-To: <20190618093159.26352aed@lwn.net>
On 18/06/2019 16:31, Jonathan Corbet wrote:
> On Tue, 18 Jun 2019 15:56:05 +0100
> Valentin Schneider <valentin.schneider@arm.com> wrote:
>
>> The asterisks prepended to the quoted text currently get translated to
>> bullet points, which gets increasingly confusing the smaller your
>> screen is (when viewing the sphinx output, that is).
>>
>> Convert the whole quote to a literal block.
>>
>> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
>
> That definitely seems worth fixing, and I can apply this. But a few
> things to ponder first...
>
> - If you convert it to a literal block, the asterisks can remain, making
> for a less intrusive patch.
>
> - I was wondering if we should just use a kernel-doc directive to pull
> the comment directly from the source, but investigation quickly showed
> that the "overview comment" doesn't actually exist in anything close to
> the quoted form. See mm/memory-failure.c.
>
> Given that, and things like references to support in "upcoming Intel
> CPUs", I suspect that this document is pretty seriously out of date and
> needs some more in-depth attention. If you're playing in this area and
> feel like it, updating the document for real would be much appreciated...:)
>
I'm afraid this was only a "drive-by" patch, as I just happened to skim
through this page on my phone while waiting for a meeting - I'm quite
clueless about page poisoning.
However, I could try to replace the quote with a kernel-doc directive to
get a more up-to-date description (and maybe add a small note to say the
rest of the doc is somewhat outdated). That, or just keep the quote as is
but keep the asterisks - whichever you're happier with.
> Thanks,
>
> jon
>
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Florian Weimer @ 2019-06-18 15:49 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: Dave Martin, Peter Zijlstra, Thomas Gleixner, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <d54fe81be77b9edd8578a6d208c72cd7c0b8c1dd.camel@intel.com>
* Yu-cheng Yu:
> The kernel looks at only ld-linux. Other applications are loaded by ld-linux.
> So the issues are limited to three versions of ld-linux's. Can we somehow
> update those??
I assumed that it would also parse the main executable and make
adjustments based on that.
ld.so can certainly provide whatever the kernel needs. We need to tweak
the existing loader anyway.
No valid statically-linked binaries exist today, so this is not a
consideration at this point.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH 00/15] kbuild: refactor headers_install and support compile-test of UAPI headers
From: Masahiro Yamada @ 2019-06-18 15:46 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Song Liu, open list:DOCUMENTATION, Benjamin Herrenschmidt,
Palmer Dabbelt, Heiko Carstens, Alexei Starovoitov, David Howells,
Paul Mackerras, linux-riscv, Vincent Chen, Sam Ravnborg,
linux-s390, Vasily Gorbik, Daniel Borkmann, Jonathan Corbet,
Michael Ellerman, Helge Deller, Christian Borntraeger,
Yonghong Song, arcml, Albert Ou, Arnd Bergmann, Jani Nikula,
Greentime Hu, James E.J. Bottomley, Michal Marek, linux-parisc,
Vineet Gupta, Randy Dunlap, Linux Kernel Mailing List, Networking,
bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190604101409.2078-1-yamada.masahiro@socionext.com>
On Tue, Jun 4, 2019 at 7:15 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> Multiple people have suggested to compile-test UAPI headers.
>
> Currently, Kbuild provides simple sanity checks by headers_check
> but they are not enough to catch bugs.
>
> The most recent patch I know is David Howells' work:
> https://patchwork.kernel.org/patch/10590203/
>
> I agree that we need better tests for UAPI headers,
> but I want to integrate it in a clean way.
>
> The idea that has been in my mind is to compile each header
> to make sure the selfcontainedness.
>
> Recently, Jani Nikula proposed a new syntax 'header-test-y'.
> https://patchwork.kernel.org/patch/10947005/
>
> So, I implemented UAPI compile-testing on top of that.
>
> When adding a new feature, cleaning the code first is a
> good practice.
>
> [1] Remove headers_install_all
>
> This target installs UAPI headers of all architectures
> in a single tree.
> It does not make sense to compile test of headers from
> multiple arches at the same time. Hence, removed.
>
> [2] Split header installation into 'make headers' and 'make headers_install'
>
> To compile-test UAPI headers, we need a work-directory somewhere
> to save objects and .*.cmd files.
>
> usr/include/ will be the work-directory.
>
> Since we cannot pollute the final destination of headers_install,
>
> I split the header installation into two stages.
>
> 'make headers' will build up
> the ready-to-install headers in usr/include,
> which will be also used as a work-directory for the compile-test.
>
> 'make headers_install' will copy headers
> from usr/include to $(INSTALL_HDR_PATH)/include.
>
> [3] Support compile-test of UAPI headers
>
> This is implemented in usr/include/Makefile
>
>
> Jani Nikula (1):
> kbuild: add support for ensuring headers are self-contained
>
> Masahiro Yamada (14):
> kbuild: remove headers_{install,check}_all
> kbuild: remove stale dependency between Documentation/ and
> headers_install
> kbuild: make gdb_script depend on prepare0 instead of prepare
> kbuild: fix Kconfig prompt of CONFIG_HEADERS_CHECK
> kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of
> samples
> kbuild: remove build_unifdef target in scripts/Makefile
> kbuild: build all prerequisite of headers_install simultaneously
> kbuild: add 'headers' target to build up ready-to-install uapi headers
> kbuild: re-implement Makefile.headersinst without directory descending
> kbuild: move hdr-inst shorthand to top Makefile
> kbuild: simplify scripts/headers_install.sh
> kbuild: deb-pkg: do not run headers_check
> fixup: kbuild: add support for ensuring headers are self-contained
> kbuild: compile test UAPI headers to ensure they are self-contained
Series, applied to linux-kbuild.
> Documentation/kbuild/headers_install.txt | 7 --
> Documentation/kbuild/makefiles.txt | 13 ++-
> Makefile | 56 +++++-----
> arch/arc/configs/tb10x_defconfig | 1 +
> arch/nds32/configs/defconfig | 1 +
> arch/parisc/configs/a500_defconfig | 1 +
> arch/parisc/configs/b180_defconfig | 1 +
> arch/parisc/configs/c3000_defconfig | 1 +
> arch/parisc/configs/default_defconfig | 1 +
> arch/powerpc/configs/ppc6xx_defconfig | 1 +
> arch/s390/configs/debug_defconfig | 1 +
> include/uapi/{linux => }/Kbuild | 6 +-
> init/Kconfig | 20 ++++
> lib/Kconfig.debug | 25 +++--
> samples/Kconfig | 14 ++-
> samples/Makefile | 4 +-
> scripts/Kbuild.include | 6 --
> scripts/Makefile | 5 -
> scripts/Makefile.build | 9 ++
> scripts/Makefile.headersinst | 132 ++++++++++-------------
> scripts/Makefile.lib | 3 +
> scripts/cc-system-headers.sh | 8 ++
> scripts/headers.sh | 29 -----
> scripts/headers_install.sh | 48 ++++-----
> scripts/package/builddeb | 2 +-
> usr/.gitignore | 1 -
> usr/Makefile | 2 +
> usr/include/.gitignore | 3 +
> usr/include/Makefile | 132 +++++++++++++++++++++++
> 29 files changed, 329 insertions(+), 204 deletions(-)
> rename include/uapi/{linux => }/Kbuild (77%)
> create mode 100755 scripts/cc-system-headers.sh
> delete mode 100755 scripts/headers.sh
> create mode 100644 usr/include/.gitignore
> create mode 100644 usr/include/Makefile
>
> --
> 2.17.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] kbuild: add support for ensuring headers are self-contained
From: Masahiro Yamada @ 2019-06-18 15:45 UTC (permalink / raw)
To: Sam Ravnborg, Jani Nikula
Cc: Linux Kbuild mailing list, Randy Dunlap, Arnd Bergmann,
David Howells, Chris Wilson, Michal Marek,
open list:DOCUMENTATION, Linux Kernel Mailing List,
Jonathan Corbet
In-Reply-To: <20190604172553.GA2383@ravnborg.org>
On Wed, Jun 5, 2019 at 2:26 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Tue, Jun 04, 2019 at 03:42:48PM +0300, Jani Nikula wrote:
> > Sometimes it's useful to be able to explicitly ensure certain headers
> > remain self-contained, i.e. that they are compilable as standalone
> > units, by including and/or forward declaring everything they depend on.
> >
> > Add special target header-test-y where individual Makefiles can add
> > headers to be tested if CONFIG_HEADER_TEST is enabled. This will
> > generate a dummy C file per header that gets built as part of extra-y.
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Cc: Michal Marek <michal.lkml@markovi.net>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> Looks good, thanks.
>
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>
Applied to linux-kbuild.
Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] docs/vm: hwpoison.rst: Fix quote formatting
From: Jonathan Corbet @ 2019-06-18 15:31 UTC (permalink / raw)
To: Valentin Schneider; +Cc: linux-kernel, linux-doc
In-Reply-To: <20190618145605.21208-1-valentin.schneider@arm.com>
On Tue, 18 Jun 2019 15:56:05 +0100
Valentin Schneider <valentin.schneider@arm.com> wrote:
> The asterisks prepended to the quoted text currently get translated to
> bullet points, which gets increasingly confusing the smaller your
> screen is (when viewing the sphinx output, that is).
>
> Convert the whole quote to a literal block.
>
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
That definitely seems worth fixing, and I can apply this. But a few
things to ponder first...
- If you convert it to a literal block, the asterisks can remain, making
for a less intrusive patch.
- I was wondering if we should just use a kernel-doc directive to pull
the comment directly from the source, but investigation quickly showed
that the "overview comment" doesn't actually exist in anything close to
the quoted form. See mm/memory-failure.c.
Given that, and things like references to support in "upcoming Intel
CPUs", I suspect that this document is pretty seriously out of date and
needs some more in-depth attention. If you're playing in this area and
feel like it, updating the document for real would be much appreciated...:)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 2/2] fTPM: add documentation for ftpm driver
From: Randy Dunlap @ 2019-06-18 15:25 UTC (permalink / raw)
To: Sasha Levin, peterhuewe, jarkko.sakkinen, jgg
Cc: corbet, linux-kernel, linux-doc, linux-integrity, linux-kernel,
thiruan, bryankel, tee-dev
In-Reply-To: <20190530152758.16628-3-sashal@kernel.org>
On 5/30/19 8:27 AM, Sasha Levin wrote:
> This patch adds basic documentation to describe the new fTPM driver.
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>
> ---
> Documentation/security/tpm/index.rst | 1 +
> Documentation/security/tpm/tpm_ftpm_tee.rst | 31 +++++++++++++++++++++
> 2 files changed, 32 insertions(+)
> create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
Hi,
Just some minor editing...
> diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst b/Documentation/security/tpm/tpm_ftpm_tee.rst
> new file mode 100644
> index 0000000000000..29c2f8b5ed100
> --- /dev/null
> +++ b/Documentation/security/tpm/tpm_ftpm_tee.rst
> @@ -0,0 +1,31 @@
> +=============================================
> +Firmware TPM Driver
> +=============================================
> +
> +| Authors:
> +| Thirupathaiah Annapureddy <thiruan@microsoft.com>
> +| Sasha Levin <sashal@kernel.org>
> +
> +This document describes the firmware Trusted Platform Module (fTPM)
> +device driver.
> +
> +Introduction
> +============
> +
> +This driver is a shim for a firmware implemented in ARM's TrustZone
for firmware
> +environment. The driver allows programs to interact with the TPM in the same
> +way the would interact with a hardware TPM.
they
> +
> +Design
> +======
> +
> +The driver acts as a thin layer that passes commands to and from a TPM
> +implemented in firmware. The driver itself doesn't contain much logic and is
> +used more like a dumb pipe between firmware and kernel/userspace.
> +
> +The firmware itself is based on the following paper:
> +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf
> +
> +When the driver is loaded it will expose ``/dev/tpmX`` character devices to
> +userspace which will enable userspace to communicate with the firmware tpm
TPM
> +through this device.
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-18 14:58 UTC (permalink / raw)
To: Dave Martin, Peter Zijlstra
Cc: Florian Weimer, Thomas Gleixner, x86, H. Peter Anvin, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Andy Lutomirski, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue
In-Reply-To: <20190618133223.GD2790@e103592.cambridge.arm.com>
On Tue, 2019-06-18 at 14:32 +0100, Dave Martin wrote:
> On Tue, Jun 18, 2019 at 02:55:12PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 02:47:00PM +0200, Florian Weimer wrote:
> > > * Peter Zijlstra:
> > >
> > > > I'm not sure I read Thomas' comment like that. In my reading keeping the
> > > > PT_NOTE fallback is exactly one of those 'fly workarounds'. By not
> > > > supporting PT_NOTE only the 'fine' people already shit^Hpping this out
> > > > of tree are affected, and we don't have to care about them at all.
> > >
> > > Just to be clear here: There was an ABI document that required PT_NOTE
> > > parsing.
> >
> > URGH.
> >
> > > The Linux kernel does *not* define the x86-64 ABI, it only
> > > implements it. The authoritative source should be the ABI document.
> > >
> > > In this particularly case, so far anyone implementing this ABI extension
> > > tried to provide value by changing it, sometimes successfully. Which
> > > makes me wonder why we even bother to mainatain ABI documentation. The
> > > kernel is just very late to the party.
> >
> > How can the kernel be late to the party if all of this is spinning
> > wheels without kernel support?
>
> PT_GNU_PROPERTY is mentioned and allocated a p_type value in hjl's
> spec [1], but otherwise seems underspecified.
>
> In particular, it's not clear whether a PT_GNU_PROPERTY phdr _must_ be
> emitted for NT_GNU_PROPERTY_TYPE_0. While it seems a no-brainer to emit
> it, RHEL's linker already doesn't IIUC, and there are binaries in the
> wild.
>
> Maybe this phdr type is a late addition -- I haven't attempted to dig
> through the history.
>
>
> For arm64 we don't have this out-of-tree legacy to support, so we can
> avoid exhausitvely searching for the note: no PT_GNU_PROPERTY ->
> no note.
>
> So, can we do the same for x86, forcing RHEL to carry some code out of
> tree to support their legacy binaries? Or do we accept that there is
> already a de facto ABI and try to be compatible with it?
>
>
> From my side, I want to avoid duplication between x86 and arm64, and
> keep unneeded complexity out of the ELF loader where possible.
Hi Florian,
The kernel looks at only ld-linux. Other applications are loaded by ld-linux.
So the issues are limited to three versions of ld-linux's. Can we somehow
update those??
Thanks,
Yu-cheng
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Documentation: platform: convert x86-laptop-drivers.txt to reST
From: Shuah Khan @ 2019-06-18 15:04 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet, cezary.jackiewicz, Darren Hart, andy,
Shuah Khan
Cc: Puranjay Mohan, linux-doc, linux-kernel-mentees, linux-kernel,
platform-driver-x86
In-Reply-To: <20190618133948.GB5416@kroah.com>
On 6/18/19 7:39 AM, Greg KH wrote:
> On Tue, Jun 18, 2019 at 07:17:17AM -0600, Jonathan Corbet wrote:
>> On Tue, 18 Jun 2019 07:41:58 +0200
>> Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>>> On Tue, Jun 18, 2019 at 11:02:27AM +0530, Puranjay Mohan wrote:
>>>> This converts the plain text documentation to reStructuredText format.
>>>> No essential content change.
>>>>
>>>> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
>>>> ---
>>>> Documentation/platform/x86-laptop-drivers.rst | 23 +++++++++++++++++++
>>>> Documentation/platform/x86-laptop-drivers.txt | 18 ---------------
>>>> 2 files changed, 23 insertions(+), 18 deletions(-)
>>>> create mode 100644 Documentation/platform/x86-laptop-drivers.rst
>>>> delete mode 100644 Documentation/platform/x86-laptop-drivers.txt
>>>
>>> Don't you also need to hook it up to the documentation build process
>>> when doing this?
>>
>> Hooking it into the TOC tree is a good thing, but I think it's also good
>> to think about the exercise in general. This is a document dropped into
>> place five years ago and never touched again. It's a short list of
>> seemingly ancient laptops with no explanation of what it means. So the
>> real question, IMO, is whether this document is useful to anybody and, if
>> not, whether it should just be deleted instead.
>
> I bet it should be deleted, but we should ask the platform driver
> maintainers first before we do that :)
>
Adding Platform driver maintainers Darren Hart and Andy Shevchenko, and
Compal laptop maintainer Cezary Jackiewicz to the discussion.
+ platform-driver-x86@vger.kernel.org
Hi Darren, Andy, and Cezary,
Would it be okay to remove the x86-laptop-drivers.txt or should it be
converted to .rst and kept around?
thanks,
-- Shuah
^ permalink raw reply
* [PATCH] docs/vm: hwpoison.rst: Fix quote formatting
From: Valentin Schneider @ 2019-06-18 14:56 UTC (permalink / raw)
To: linux-kernel, linux-doc; +Cc: corbet
The asterisks prepended to the quoted text currently get translated to
bullet points, which gets increasingly confusing the smaller your
screen is (when viewing the sphinx output, that is).
Convert the whole quote to a literal block.
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
---
Documentation/vm/hwpoison.rst | 52 +++++++++++++++++------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/Documentation/vm/hwpoison.rst b/Documentation/vm/hwpoison.rst
index 09bd24a92784..a5c884293dac 100644
--- a/Documentation/vm/hwpoison.rst
+++ b/Documentation/vm/hwpoison.rst
@@ -13,32 +13,32 @@ kill the processes associated with it and avoid using it in the future.
This patchkit implements the necessary infrastructure in the VM.
-To quote the overview comment:
-
- * High level machine check handler. Handles pages reported by the
- * hardware as being corrupted usually due to a 2bit ECC memory or cache
- * failure.
- *
- * This focusses on pages detected as corrupted in the background.
- * When the current CPU tries to consume corruption the currently
- * running process can just be killed directly instead. This implies
- * that if the error cannot be handled for some reason it's safe to
- * just ignore it because no corruption has been consumed yet. Instead
- * when that happens another machine check will happen.
- *
- * Handles page cache pages in various states. The tricky part
- * here is that we can access any page asynchronous to other VM
- * users, because memory failures could happen anytime and anywhere,
- * possibly violating some of their assumptions. This is why this code
- * has to be extremely careful. Generally it tries to use normal locking
- * rules, as in get the standard locks, even if that means the
- * error handling takes potentially a long time.
- *
- * Some of the operations here are somewhat inefficient and have non
- * linear algorithmic complexity, because the data structures have not
- * been optimized for this case. This is in particular the case
- * for the mapping from a vma to a process. Since this case is expected
- * to be rare we hope we can get away with this.
+To quote the overview comment::
+
+ High level machine check handler. Handles pages reported by the
+ hardware as being corrupted usually due to a 2bit ECC memory or cache
+ failure.
+
+ This focusses on pages detected as corrupted in the background.
+ When the current CPU tries to consume corruption the currently
+ running process can just be killed directly instead. This implies
+ that if the error cannot be handled for some reason it's safe to
+ just ignore it because no corruption has been consumed yet. Instead
+ when that happens another machine check will happen.
+
+ Handles page cache pages in various states. The tricky part
+ here is that we can access any page asynchronous to other VM
+ users, because memory failures could happen anytime and anywhere,
+ possibly violating some of their assumptions. This is why this code
+ has to be extremely careful. Generally it tries to use normal locking
+ rules, as in get the standard locks, even if that means the
+ error handling takes potentially a long time.
+
+ Some of the operations here are somewhat inefficient and have non
+ linear algorithmic complexity, because the data structures have not
+ been optimized for this case. This is in particular the case
+ for the mapping from a vma to a process. Since this case is expected
+ to be rare we hope we can get away with this.
The code consists of a the high level handler in mm/memory-failure.c,
a new page poison bit and various checks in the VM to handle poisoned
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] docs: fix some broken references due to txt->rst renames
From: Daniel Vetter @ 2019-06-18 13:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rob Herring, Mark Rutland, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Ajay Gupta, Amit Kucheria, Sudeep Holla, Otto Sabart, Li Yang,
Will Deacon, devicetree, intel-gfx, dri-devel, linux-i2c
In-Reply-To: <6f09587b7678f2fb378d736f45a02ffa9412cc99.1560864716.git.mchehab+samsung@kernel.org>
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> This patch is against today's next-20190617 branch. Not sure if it
> will apply cleanly at -docs tree. If not, Please let me know for me to
> split.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
> drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
> index 3bdbe675b9e6..d8d9aa7167e8 100644
> --- a/Documentation/devicetree/bindings/arm/idle-states.txt
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -703,4 +703,4 @@ cpus {
> https://www.devicetree.org/specifications/
>
> [6] ARM Linux Kernel documentation - Booting AArch64 Linux
> - Documentation/arm64/booting.txt
> + Documentation/arm64/booting.rst
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h b/drivers/gpu/drm/i915/intel_runtime_pm.h
> index f2d6299a8161..3cb391cd81c1 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
> @@ -44,7 +44,7 @@ enum i915_drm_suspend_mode {
> * to be disabled. This shouldn't happen and we'll print some error messages in
> * case it happens.
> *
> - * For more, read the Documentation/power/runtime_pm.txt.
> + * For more, read the Documentation/power/runtime_pm.rst.
> */
> struct intel_runtime_pm {
> atomic_t wakeref_count;
> diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c b/drivers/i2c/busses/i2c-nvidia-gpu.c
> index cfc76b5de726..5a1235fd86bb 100644
> --- a/drivers/i2c/busses/i2c-nvidia-gpu.c
> +++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
> @@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
> /*
> * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
> * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
> - * Documentation/power/pci.txt also insists for driver to provide this.
> + * Documentation/power/pci.rst also insists for driver to provide this.
> */
> static __maybe_unused int gpu_i2c_suspend(struct device *dev)
> {
> --
> 2.21.0
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] docs: fix some broken references due to txt->rst renames
From: Wolfram Sang @ 2019-06-18 13:41 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rob Herring, Mark Rutland, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Ajay Gupta, Amit Kucheria, Sudeep Holla, Otto Sabart, Li Yang,
Will Deacon, devicetree, intel-gfx, dri-devel, linux-i2c
In-Reply-To: <6f09587b7678f2fb378d736f45a02ffa9412cc99.1560864716.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Thanks!
Acked-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Documentation: platform: convert x86-laptop-drivers.txt to reST
From: Greg KH @ 2019-06-18 13:39 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Puranjay Mohan, Shuah Khan, linux-doc, linux-kernel-mentees,
linux-kernel
In-Reply-To: <20190618071717.2132a1b7@lwn.net>
On Tue, Jun 18, 2019 at 07:17:17AM -0600, Jonathan Corbet wrote:
> On Tue, 18 Jun 2019 07:41:58 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, Jun 18, 2019 at 11:02:27AM +0530, Puranjay Mohan wrote:
> > > This converts the plain text documentation to reStructuredText format.
> > > No essential content change.
> > >
> > > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> > > ---
> > > Documentation/platform/x86-laptop-drivers.rst | 23 +++++++++++++++++++
> > > Documentation/platform/x86-laptop-drivers.txt | 18 ---------------
> > > 2 files changed, 23 insertions(+), 18 deletions(-)
> > > create mode 100644 Documentation/platform/x86-laptop-drivers.rst
> > > delete mode 100644 Documentation/platform/x86-laptop-drivers.txt
> >
> > Don't you also need to hook it up to the documentation build process
> > when doing this?
>
> Hooking it into the TOC tree is a good thing, but I think it's also good
> to think about the exercise in general. This is a document dropped into
> place five years ago and never touched again. It's a short list of
> seemingly ancient laptops with no explanation of what it means. So the
> real question, IMO, is whether this document is useful to anybody and, if
> not, whether it should just be deleted instead.
I bet it should be deleted, but we should ask the platform driver
maintainers first before we do that :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] docs: fix some broken references due to txt->rst renames
From: Mauro Carvalho Chehab @ 2019-06-18 13:33 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rob Herring, Mark Rutland, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Ajay Gupta, Amit Kucheria, Sudeep Holla, Otto Sabart, Li Yang,
Will Deacon, devicetree, intel-gfx, dri-devel, linux-i2c
There are three left-overs from the recent file renames,
probably due to some other conflicting patch.
Fix them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
This patch is against today's next-20190617 branch. Not sure if it
will apply cleanly at -docs tree. If not, Please let me know for me to
split.
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index 3bdbe675b9e6..d8d9aa7167e8 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -703,4 +703,4 @@ cpus {
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
- Documentation/arm64/booting.txt
+ Documentation/arm64/booting.rst
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h b/drivers/gpu/drm/i915/intel_runtime_pm.h
index f2d6299a8161..3cb391cd81c1 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.h
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
@@ -44,7 +44,7 @@ enum i915_drm_suspend_mode {
* to be disabled. This shouldn't happen and we'll print some error messages in
* case it happens.
*
- * For more, read the Documentation/power/runtime_pm.txt.
+ * For more, read the Documentation/power/runtime_pm.rst.
*/
struct intel_runtime_pm {
atomic_t wakeref_count;
diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c b/drivers/i2c/busses/i2c-nvidia-gpu.c
index cfc76b5de726..5a1235fd86bb 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
/*
* We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
* correctly. Without it, lspci shows runtime pm status as "D0" for the card.
- * Documentation/power/pci.txt also insists for driver to provide this.
+ * Documentation/power/pci.rst also insists for driver to provide this.
*/
static __maybe_unused int gpu_i2c_suspend(struct device *dev)
{
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Dave Martin @ 2019-06-18 13:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Florian Weimer, Thomas Gleixner, Yu-cheng Yu, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <20190618125512.GJ3419@hirez.programming.kicks-ass.net>
On Tue, Jun 18, 2019 at 02:55:12PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 02:47:00PM +0200, Florian Weimer wrote:
> > * Peter Zijlstra:
> >
> > > I'm not sure I read Thomas' comment like that. In my reading keeping the
> > > PT_NOTE fallback is exactly one of those 'fly workarounds'. By not
> > > supporting PT_NOTE only the 'fine' people already shit^Hpping this out
> > > of tree are affected, and we don't have to care about them at all.
> >
> > Just to be clear here: There was an ABI document that required PT_NOTE
> > parsing.
>
> URGH.
>
> > The Linux kernel does *not* define the x86-64 ABI, it only
> > implements it. The authoritative source should be the ABI document.
> >
> > In this particularly case, so far anyone implementing this ABI extension
> > tried to provide value by changing it, sometimes successfully. Which
> > makes me wonder why we even bother to mainatain ABI documentation. The
> > kernel is just very late to the party.
>
> How can the kernel be late to the party if all of this is spinning
> wheels without kernel support?
PT_GNU_PROPERTY is mentioned and allocated a p_type value in hjl's
spec [1], but otherwise seems underspecified.
In particular, it's not clear whether a PT_GNU_PROPERTY phdr _must_ be
emitted for NT_GNU_PROPERTY_TYPE_0. While it seems a no-brainer to emit
it, RHEL's linker already doesn't IIUC, and there are binaries in the
wild.
Maybe this phdr type is a late addition -- I haven't attempted to dig
through the history.
For arm64 we don't have this out-of-tree legacy to support, so we can
avoid exhausitvely searching for the note: no PT_GNU_PROPERTY ->
no note.
So, can we do the same for x86, forcing RHEL to carry some code out of
tree to support their legacy binaries? Or do we accept that there is
already a de facto ABI and try to be compatible with it?
From my side, I want to avoid duplication between x86 and arm64, and
keep unneeded complexity out of the ELF loader where possible.
Cheers
---Dave
[1] https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Documentation: platform: convert x86-laptop-drivers.txt to reST
From: Jonathan Corbet @ 2019-06-18 13:17 UTC (permalink / raw)
To: Greg KH
Cc: Puranjay Mohan, Shuah Khan, linux-doc, linux-kernel-mentees,
linux-kernel
In-Reply-To: <20190618054158.GA3713@kroah.com>
On Tue, 18 Jun 2019 07:41:58 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Jun 18, 2019 at 11:02:27AM +0530, Puranjay Mohan wrote:
> > This converts the plain text documentation to reStructuredText format.
> > No essential content change.
> >
> > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> > ---
> > Documentation/platform/x86-laptop-drivers.rst | 23 +++++++++++++++++++
> > Documentation/platform/x86-laptop-drivers.txt | 18 ---------------
> > 2 files changed, 23 insertions(+), 18 deletions(-)
> > create mode 100644 Documentation/platform/x86-laptop-drivers.rst
> > delete mode 100644 Documentation/platform/x86-laptop-drivers.txt
>
> Don't you also need to hook it up to the documentation build process
> when doing this?
Hooking it into the TOC tree is a good thing, but I think it's also good
to think about the exercise in general. This is a document dropped into
place five years ago and never touched again. It's a short list of
seemingly ancient laptops with no explanation of what it means. So the
real question, IMO, is whether this document is useful to anybody and, if
not, whether it should just be deleted instead.
Puranjay, thanks for working to improve the kernel docs! Please don't be
discouraged by this response - it's just a sign that kernel documentation
has problems far beyond just formatting...
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v5 1/2] arm64: Define Documentation/arm64/tagged-address-abi.txt
From: Kevin Brodsky @ 2019-06-18 13:13 UTC (permalink / raw)
To: Vincenzo Frascino, linux-arm-kernel, linux-doc, linux-mm,
linux-arch, linux-kselftest, linux-kernel
Cc: Catalin Marinas, Will Deacon, Andrey Konovalov, Alexander Viro
In-Reply-To: <20190613155137.47675-2-vincenzo.frascino@arm.com>
I'm happy with the ABI overall, but I think we need a few more tweaks.
On 13/06/2019 16:51, Vincenzo Frascino wrote:
> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
>
> This change in the ABI requires a mechanism to requires the userspace
> to opt-in to such an option.
>
> Specify and document the way in which sysctl and prctl() can be used
> in combination to allow the userspace to opt-in this feature.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> CC: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> Documentation/arm64/tagged-address-abi.txt | 134 +++++++++++++++++++++
> 1 file changed, 134 insertions(+)
> create mode 100644 Documentation/arm64/tagged-address-abi.txt
>
> diff --git a/Documentation/arm64/tagged-address-abi.txt b/Documentation/arm64/tagged-address-abi.txt
> new file mode 100644
> index 000000000000..0ae900d4bb2d
> --- /dev/null
> +++ b/Documentation/arm64/tagged-address-abi.txt
> @@ -0,0 +1,134 @@
> +ARM64 TAGGED ADDRESS ABI
> +========================
> +
> +This document describes the usage and semantics of the Tagged Address
> +ABI on arm64.
> +
> +1. Introduction
> +---------------
> +
> +On arm64 the TCR_EL1.TBI0 bit has been always enabled on the kernel, hence
"been always" -> "always been"
> +the userspace (EL0) is entitled to perform a user memory access through a
> +64-bit pointer with a non-zero top byte but the resulting pointers are not
> +allowed at the user-kernel syscall ABI boundary.
> +
> +This document describes a relaxation of the ABI that makes it possible to
> +to pass tagged pointers to the syscalls, when these pointers are in memory
> +ranges obtained as described in section 2.
> +
> +Since it is not desirable to relax the ABI to allow tagged user addresses
> +into the kernel indiscriminately, arm64 provides a new sysctl interface
> +(/proc/sys/abi/tagged_addr) that is used to prevent the applications from
> +enabling the relaxed ABI and a new prctl() interface that can be used to
> +enable or disable the relaxed ABI.
> +A detailed description of the newly introduced mechanisms will be provided
> +in section 2.
> +
> +2. ARM64 Tagged Address ABI
> +---------------------------
> +
> +From the kernel syscall interface perspective, we define, for the purposes
> +of this document, a "valid tagged pointer" as a pointer that either has a
> +zero value set in the top byte or has a non-zero value, it is in memory
> +ranges privately owned by a userspace process and it is obtained in one of
Remove all the remaining "it": "a pointer that either [...], is in memory ranges
[...] and is obtained..."
> +the following ways:
> + - mmap() done by the process itself, where either:
> + * flags have MAP_PRIVATE and MAP_ANONYMOUS
> + * flags have MAP_PRIVATE and the file descriptor refers to a regular
> + file or "/dev/zero"
> + - brk() system call done by the process itself (i.e. the heap area between
> + the initial location of the program break at process creation and its
> + current location).
> + - any memory mapped by the kernel in the process's address space during
> + creation and following the restrictions presented above (i.e. data, bss,
> + stack).
As I commented on v2, the "i.e." is not correct: these 3 sections are not the only
ones that are covered by this ABI (.text also is, for instance). Replacing "i.e."
with "e.g." would work.
Also, since the rules above say explicitly "done by the process itself", it might be
clearer to replace "following the restrictions presented above" with "with the same
restrictions as for mmap()".
> +
> +The ARM64 Tagged Address ABI is an opt-in feature, and an application can
> +control it using the following:
> + - /proc/sys/abi/tagged_addr: a new sysctl interface that can be used to
> + prevent the applications from enabling the relaxed ABI.
> + The sysctl is meant also for testing purposes in order to provide a
> + simple way for the userspace to verify the return error checking of
> + the prctl() commands without having to reconfigure the kernel.
> + The sysctl supports the following configuration options:
> + - 0: Disable ARM64 Tagged Address ABI for all the applications.
> + - 1 (Default): Enable ARM64 Tagged Address ABI for all the
> + applications.
I find this very confusing, because it suggests that the default value of
PR_GET_TAGGED_ADDR_CTRL for new processes will be set to the value of this sysctl,
when in fact this sysctl is about restricting the *availability* of the new ABI.
Instead of disabling the ABI, I would talk about disabling access to the new ABI here.
> + If the ARM64 Tagged Address ABI is disabled at a certain point in
> + time, all the applications that were using tagging before this event
> + occurs, will continue to use tagging.
> +
> + - prctl()s:
> + - PR_SET_TAGGED_ADDR_CTRL: can be used to enable or disable the Tagged
> + Address ABI.
> + The (unsigned int) arg2 argument is a bit mask describing the
> + control mode used:
> + - PR_TAGGED_ADDR_ENABLE: Enable ARM64 Tagged Address ABI.
> + The arguments arg3, arg4, and arg5 are ignored.
Have we definitely decided that arg{3,4,5} are ignored? Catalin?
> +
> + - PR_GET_TAGGED_ADDR_CTRL: can be used to check the status of the Tagged
> + Address ABI.
> + The arguments arg2, arg3, arg4, and arg5 are ignored.
> +
> +The ABI properties set by the mechanisms described above are inherited by threads
> +of the same application and fork()'ed children but cleared by execve().
> +
> +As a consequence of invoking PR_SET_TAGGED_ADDR_CTRL prctl() by an applications,
I think this is too vague, you can use this prctl() to disable the new ABI, and it
can also fail. Maybe it's best to simply say that the process has successfully opted
into the new ABI.
> +the ABI guarantees the following behaviours:
> +
> + - Every current or newly introduced syscall can accept any valid tagged
> + pointers.
"pointer". Also, is it really useful to talk about newly introduced syscall? New from
which point of view?
> +
> + - If a non valid tagged pointer is passed to a syscall then the behaviour
> + is undefined.
> +
> + - Every valid tagged pointer is expected to work as an untagged one.
> +
> + - The kernel preserves any valid tagged pointers and returns them to the
"pointer", "returns it"
> + userspace unchanged (i.e. on syscall return) in all the cases except the
> + ones documented in the "Preserving tags" section of tagged-pointers.txt.
> +
> +A definition of the meaning of tagged pointers on arm64 can be found in:
> +Documentation/arm64/tagged-pointers.txt.
> +
> +3. ARM64 Tagged Address ABI Exceptions
> +--------------------------------------
> +
> +The behaviours described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer are not applicable
> +to the following cases:
> + - mmap() addr parameter.
> + - mremap() new_address parameter.
> + - prctl_set_mm() struct prctl_map fields.
> + - prctl_set_mm_map() struct prctl_map fields.
prctl_set_mm() and prctl_set_mm_map() are internal kernel functions, not syscall
names. IIUC, we don't want to allow any address field settable via the PR_SET_MM
prctl() to be tagged. Catalin, is that correct? I think this needs rephrasing.
Kevin
> +
> +Any attempt to use non-zero tagged pointers will lead to undefined behaviour.
> +
> +4. Example of correct usage
> +---------------------------
> +
> +void main(void)
> +{
> + static int tbi_enabled = 0;
> + unsigned long tag = 0;
> +
> + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
> + MAP_ANONYMOUS, -1, 0);
> +
> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
> + 0, 0, 0) == 0)
> + tbi_enabled = 1;
> +
> + if (ptr == (void *)-1) /* MAP_FAILED */
> + return -1;
> +
> + if (tbi_enabled)
> + tag = rand() & 0xff;
> +
> + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> +
> + *ptr = 'a';
> +
> + ...
> +}
> +
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Peter Zijlstra @ 2019-06-18 12:55 UTC (permalink / raw)
To: Florian Weimer
Cc: Dave Martin, Thomas Gleixner, Yu-cheng Yu, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <87ef3r9i2j.fsf@oldenburg2.str.redhat.com>
On Tue, Jun 18, 2019 at 02:47:00PM +0200, Florian Weimer wrote:
> * Peter Zijlstra:
>
> > I'm not sure I read Thomas' comment like that. In my reading keeping the
> > PT_NOTE fallback is exactly one of those 'fly workarounds'. By not
> > supporting PT_NOTE only the 'fine' people already shit^Hpping this out
> > of tree are affected, and we don't have to care about them at all.
>
> Just to be clear here: There was an ABI document that required PT_NOTE
> parsing.
URGH.
> The Linux kernel does *not* define the x86-64 ABI, it only
> implements it. The authoritative source should be the ABI document.
>
> In this particularly case, so far anyone implementing this ABI extension
> tried to provide value by changing it, sometimes successfully. Which
> makes me wonder why we even bother to mainatain ABI documentation. The
> kernel is just very late to the party.
How can the kernel be late to the party if all of this is spinning
wheels without kernel support?
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Florian Weimer @ 2019-06-18 12:47 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dave Martin, Thomas Gleixner, Yu-cheng Yu, x86, H. Peter Anvin,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Andy Lutomirski, Balbir Singh,
Borislav Petkov, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, H.J. Lu, Jann Horn, Jonathan Corbet,
Kees Cook, Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <20190618124122.GH3419@hirez.programming.kicks-ass.net>
* Peter Zijlstra:
> I'm not sure I read Thomas' comment like that. In my reading keeping the
> PT_NOTE fallback is exactly one of those 'fly workarounds'. By not
> supporting PT_NOTE only the 'fine' people already shit^Hpping this out
> of tree are affected, and we don't have to care about them at all.
Just to be clear here: There was an ABI document that required PT_NOTE
parsing. The Linux kernel does *not* define the x86-64 ABI, it only
implements it. The authoritative source should be the ABI document.
In this particularly case, so far anyone implementing this ABI extension
tried to provide value by changing it, sometimes successfully. Which
makes me wonder why we even bother to mainatain ABI documentation. The
kernel is just very late to the party.
Thanks,
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox