Re: (subset) [PATCH v2 0/3] RISC-V: Fix a few kexec_file_load(2) failures
On Wed, 26 Jul 2023 11:53:58 +0200, Petr Tesarik wrote: > From: Petr Tesarik > > The kexec_file_load(2) syscall does not work at least in some kernel > builds. For details see the relevant section in this blog post: > > https://sigillatum.tesarici.cz/2023-07-21-state-of-riscv64-kdump.html > > [...] Applied, thanks! [1/3] riscv/kexec: handle R_RISCV_CALL_PLT relocation type https://git.kernel.org/palmer/c/d0b4f95a5103 [3/3] riscv/kexec: load initrd high in available memory https://git.kernel.org/palmer/c/49af7a2cd5f6 Best regards, -- Palmer Dabbelt ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RESEND PATCH -fixes 1/2] riscv: Export va_kernel_pa_offset in vmcoreinfo
On Mon, 24 Jul 2023 18:09:16 +0800, Song Shuai wrote:
> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
> PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base
> from the physical start of the kernel to the actual start of the DRAM.
>
> The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr
> to translate kernel virtual address, that failed the Crash with Linux v6.4
> [1].
>
> [...]
Applied, thanks!
[1/2] riscv: Export va_kernel_pa_offset in vmcoreinfo
https://git.kernel.org/palmer/c/fbe7d19d2b7f
[2/2] Documentation: kdump: Add va_kernel_pa_offset for RISCV64
https://git.kernel.org/palmer/c/640c503d7dbd
Best regards,
--
Palmer Dabbelt
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 2/3] riscv/purgatory: do not link with string.o and its dependencies
On Wed, 26 Jul 2023 09:33:49 PDT (-0700), Conor Dooley wrote:
On Wed, Jul 26, 2023 at 11:54:00AM +0200, Petr Tesarik wrote:
From: Petr Tesarik
Linking with this object file makes kexec_file_load(2) fail because of
multiple unknown relocation types:
- R_RISCV_ADD16, R_RISCV_SUB16: used by alternatives in strcmp()
- R_RISCV_GOT_HI20: used to resolve _ctype in strcasecmp()
All this hassle is needed for one single call to memcmp() from
verify_sha256_digest() to compare 32 bytes of SHA256 checksum.
Simply replace this memcmp() call with an explicit loop over those 32 bytes
and remove the need to link with string.o and all the other object files
that provide undefined symbols from that object file.
Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
Signed-off-by: Petr Tesarik
This version keeps the automation happy,
Acked-by: Conor Dooley
Oddly enough, this breaks my builds. I tried fixing the first one with
something like
From 41c5a952f77e53bf4201296abff0132725aa19e6 Mon Sep 17 00:00:00 2001
From: Palmer Dabbelt
Date: Wed, 2 Aug 2023 20:22:33 -0700
Subject: [PATCH] RISC-V: Include io from timex
Without this I get some implicit declarations.
CC arch/riscv/kernel/asm-offsets.s
In file included from linux/include/linux/timex.h:67,
from linux/include/linux/time32.h:13,
from linux/include/linux/time.h:60,
from linux/include/linux/ktime.h:24,
from linux/include/linux/timer.h:6,
from linux/include/linux/workqueue.h:9,
from linux/include/linux/mm_types.h:19,
from linux/include/linux/mmzone.h:22,
from linux/include/linux/gfp.h:7,
from linux/include/linux/mm.h:7,
from linux/arch/riscv/kernel/asm-offsets.c:10:
linux/arch/riscv/include/asm/timex.h: In function 'get_cycles':
linux/arch/riscv/include/asm/timex.h:25:16: error: implicit declaration of
function 'readl_relaxed' [-Werror=implicit-function-declaration]
25 | return readl_relaxed(((u32 *)clint_time_val));
|
Signed-off-by: Palmer Dabbelt
---
arch/riscv/include/asm/timex.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h
index a06697846e69..1a4d181193e0 100644
--- a/arch/riscv/include/asm/timex.h
+++ b/arch/riscv/include/asm/timex.h
@@ -7,6 +7,7 @@
#define _ASM_RISCV_TIMEX_H
#include
+#include
typedef unsigned long cycles_t;
--
2.41.0
The other two look fine and are somewhat independent, so I've picked those up
for fixes.
Thanks!
Thanks,
Conor.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 4/4] risc/purgatory: Add linker script
On Mon, 01 May 2023 05:38:22 PDT (-0700), riba...@chromium.org wrote:
If PGO is enabled, the purgatory ends up with multiple .text sections.
This is not supported by kexec and crashes the system.
Cc: sta...@vger.kernel.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda
---
arch/riscv/purgatory/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
index 5730797a6b40..cf3a44121a90 100644
--- a/arch/riscv/purgatory/Makefile
+++ b/arch/riscv/purgatory/Makefile
@@ -35,6 +35,11 @@ CFLAGS_sha256.o := -D__DISABLE_EXPORTS
CFLAGS_string.o := -D__DISABLE_EXPORTS
CFLAGS_ctype.o := -D__DISABLE_EXPORTS
+# When profile optimization is enabled, llvm emits two different overlapping
+# text sections, which is not supported by kexec. Remove profile optimization
+# flags.
+KBUILD_CFLAGS := $(filter-out -fprofile-sample-use=%
-fprofile-use=%,$(KBUILD_CFLAGS))
+
# When linking purgatory.ro with -r unresolved symbols are not checked,
# also link a purgatory.chk binary without -r to check for unresolved symbols.
PURGATORY_LDFLAGS := -e purgatory_start -z nodefaultlib
Acked-by: Palmer Dabbelt
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] RISC-V: kexec: Fix memory leak of fdt buffer
On Fri, 4 Nov 2022 17:56:57 +0800, Li Huafei wrote: > This is reported by kmemleak detector: > > unreferenced object 0xff6082864000 (size 9588): > comm "kexec", pid 146, jiffies 4294900634 (age 64.788s) > hex dump (first 32 bytes): > d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...H...@ > 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...( > backtrace: > [<f95b17c4>] kmemleak_alloc+0x34/0x3e > [<b9ec8e3e>] kmalloc_order+0x9c/0xc4 > [<a95cf02e>] kmalloc_order_trace+0x34/0xb6 > [<f01e68b4>] __kmalloc+0x5c2/0x62a > [<2bd497b2>] kvmalloc_node+0x66/0xd6 > [<906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea > [<e1166bde>] elf_kexec_load+0x206/0x4ec > [<36548e09>] kexec_image_load_default+0x40/0x4c > [<79fbe1b4>] sys_kexec_file_load+0x1c4/0x322 > [<40c62c03>] ret_from_syscall+0x0/0x2 > > [...] Applied, thanks! [1/2] RISC-V: kexec: Fix memory leak of fdt buffer https://git.kernel.org/palmer/c/96df59b1ae23 [2/2] RISC-V: kexec: Fix memory leak of elf header buffer https://git.kernel.org/palmer/c/cbc32023ddbd These are on for-next. They'd probably be fine fixes candidates had I gotten to them in time, but it's pretty late and a leak during kexec doesn't seem like a show-stopper. They'll get backported anyway, but this way they get an extra week in linux-next just to see. Best regards, -- Palmer Dabbelt ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > As disscussed in below patch set, the patch of 'describe VMCOREINFO export in > Documentation' > need to update according to Bagas's comments. > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > As others patches in above patch set already applied, so this patch set only > contains below two > patches. > > [...] Applied, thanks! [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support https://git.kernel.org/palmer/c/649d6b1019a2 [2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64 https://git.kernel.org/palmer/c/c5b4216929eb Best regards, -- Palmer Dabbelt ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V6 0/6] RISC-V fixups to work with crash tool
On Thu, 11 Aug 2022 00:41:44 PDT (-0700), xianting.t...@linux.alibaba.com wrote: I ever sent the patch 1 in the link: https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352830-3-xianting.t...@linux.alibaba.com/ And patch 2,3 in the link: https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367854-2-xianting.t...@linux.alibaba.com/ https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367854-3-xianting.t...@linux.alibaba.com/ This patch set just put these patches together, and with three new patch 4, 5, 6. these six patches are the fixups for machine_kexec, kernel mode PC for vmcore and improvements for vmcoreinfo, memory layout dump and fixup schedule out issue in machine_crash_shutdown(). The main changes in the six patchs as below, Patch 1: Fixup use of smp_processor_id() in preemptible context, to cleanup the console prints. Patch 2: Fixup to get correct kernel mode PC for kernel mode regs for vmcore. Patch 3: Fixup schedule out issue in machine_crash_shutdown() Patch 4: Add modules to virtual kernel memory layout dump. Patch 5: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify the development of crash tool as ARM64 already did (arch/arm64/kernel/crash_core.c). Patch 6: Updates vmcoreinfo.rst for vmcoreinfo export for RISCV64. With these six patches(patch 2 is must), crash tool can work well to analyze a vmcore. The patches for crash tool for RISCV64 is in the link: https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.t...@linux.alibaba.com/ -- Changes v1 -> v2: 1, remove the patch "Add a fast call path of crash_kexec()" from this series of patches, as it already applied to riscv git. https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h=for-next=3f1901110a89b0e2e13adb2ac8d1a7102879ea98 2, add 'Reviewed-by' based on the comments of v1. Changes v2 -> v3: use "riscv" instead of "riscv64" in patch 5 subject line. Changes v3 -> v4: use "riscv" instead of "riscv64" in the summary of patch 5 subject line. Changes v4 -> v5: add a new patch "RISC-V: Fixup schedule out issue in machine_crash_shutdown()" Changes v5 -> v6: 1, move "fixup" patches to the start of the patch set. 2, change patch 1, 2, 6's subject to make it tell more what it's about. 3, add Fixes for patch 3. 4, adjuest the changes format for patch 6. Xianting Tian (6): RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context RISC-V: Fixup get incorrect user mode PC for kernel mode regs RISC-V: Fixup schedule out issue in machine_crash_shutdown() RISC-V: Add modules to virtual kernel memory layout dump RISC-V: Add arch_crash_save_vmcoreinfo support Documentation: kdump: describe VMCOREINFO export for RISCV64 .../admin-guide/kdump/vmcoreinfo.rst | 31 +++ arch/riscv/kernel/Makefile| 1 + arch/riscv/kernel/crash_core.c| 29 + arch/riscv/kernel/crash_save_regs.S | 2 +- arch/riscv/kernel/machine_kexec.c | 28 ++--- arch/riscv/mm/init.c | 4 +++ 6 files changed, 89 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/kernel/crash_core.c Thank. I've taken the first 4 onto for-next, which is still targeted for 5.20, as they're fixes. I'm not opposed to taking the documentation patch for this cycle as well, it just needs some going-over as the wording looks very odd (or at least it does to me right now, maybe I'm just still half asleep). Patch 5 is a new feature, and given that it's being spun during the merge window it's too late. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISC-V: Prepare dropping week attribute from arch_kexec_apply_relocations[_add]
On Mon, 30 May 2022 22:58:03 PDT (-0700), u.kleine-koe...@pengutronix.de wrote:
On Mon, May 30, 2022 at 04:11:27PM -0700, Palmer Dabbelt wrote:
On Mon, 30 May 2022 12:41:33 PDT (-0700), u.kleine-koe...@pengutronix.de wrote:
> Hello,
>
> On Mon, May 30, 2022 at 11:58:16AM -0700, Palmer Dabbelt wrote:
> > On Mon, 30 May 2022 00:42:02 PDT (-0700), u.kleine-koe...@pengutronix.de
wrote:
> > > Without this change arch/riscv/kernel/elf_kexec.c fails to compile once
> > > commit 233c1e6c319c ("kexec_file: drop weak attribute from
> > > arch_kexec_apply_relocations[_add]") is also contained in the tree.
> > > This currently happens in next-20220527.
> > > > Prepare the RISC-V similar to the s390 adaption done in
> > 233c1e6c319c.
> > > This is safe to do on top of the riscv change even without the change to
> > > arch_kexec_apply_relocations.
> > > > Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
> > > Looks-good-to: liaochang (A)
> > > Signed-off-by: Uwe Kleine-König
> > > ---
> > > > On Mon, May 30, 2022 at 09:43:26AM +0800, liaochang (A) wrote:
> > > > > I can confirm that doing
> > > > > > diff --git a/arch/riscv/include/asm/kexec.h
> > > > b/arch/riscv/include/asm/kexec.h
> > > > > index 206217b23301..eee260e8ab30 100644
> > > > > --- a/arch/riscv/include/asm/kexec.h
> > > > > +++ b/arch/riscv/include/asm/kexec.h
> > > > > @@ -55,6 +55,13 @@ extern riscv_kexec_method riscv_kexec_norelocate;
> > > > > > #ifdef CONFIG_KEXEC_FILE
> > > > > extern const struct kexec_file_ops elf_kexec_ops;
> > > > > +
> > > > > +struct purgatory_info;
> > > > > +int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> > > > > + Elf_Shdr *section,
> > > > > + const Elf_Shdr *relsec,
> > > > > + const Elf_Shdr *symtab);
> > > > > +#define arch_kexec_apply_relocations_add
arch_kexec_apply_relocations_add
> > > > > #endif
> > > > > > #endif
> > > > > > LGTM, you could send a fixup patch to riscv, thanks.
> > > > > > > > on top of 838b3e28488f results in a compilable tree. And
> > when
> > > > merging
> > > > > 233c1e6c319c into this, it is still building.
> > > > > > I'm not enough into kexec (and riscv) to judge if this is
> > > > sensible, or
> > > > > create a useful commit log but the obvious way forward is to apply the
> > > > > above patch to the riscv tree before it hits Linus' tree.
> > > > Ok, here comes a patch with a generic commit log.
> > > > @riscv people: If you prefer, squash it into 838b3e28488f.
> >
> > Sorry, just saw this after I sent my version of the fix. They're the same,
> > but do you mind sending a full-on patch so I can merge it?
>
> Sorry, I don't understand your request. I found
>
https://lore.kernel.org/linux-riscv/20220530180408.16239-1-pal...@rivosinc.com/
>
> but I don't know what a full-on patch is and what stops you merging my
> patch.
>
> Is it that it's in reply to a patch series and b4 fails to fetch the
> right patch and you ask to send it in a new thread?
Ya, with the reply bits in there my mail merge (which unfortunately isn't
b4, I haven't gotten around to converting yet) got tripped up. It's kind of
easy to for me to screw something up trying to pull bits out of replies and
such, but I think this one was pretty simple (looks like maybe some PGP or
MIME thing was the issue).
I just put
<https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next=7699f7aacf3ebfee51c670b6f796b2797f0f7487>
on my staging branch, it looks OK to me but LMK if there's a problem.
there is indeed a problem, but caused by me: If you are ready to rewrite
it, please do s/week/weak/ in the subject line. Otherwise looks good to
me.
Ah, sorry, I missed that too. I was hoping to send a PR this morning,
I'd usually just rewrite and delay this one but given it's necessary to
make the post-merge build work I'm going to just send it up with the
spelling error.
Best regards and thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISC-V: Prepare dropping week attribute from arch_kexec_apply_relocations[_add]
On Mon, 30 May 2022 12:41:33 PDT (-0700), u.kleine-koe...@pengutronix.de wrote:
Hello,
On Mon, May 30, 2022 at 11:58:16AM -0700, Palmer Dabbelt wrote:
On Mon, 30 May 2022 00:42:02 PDT (-0700), u.kleine-koe...@pengutronix.de wrote:
> Without this change arch/riscv/kernel/elf_kexec.c fails to compile once
> commit 233c1e6c319c ("kexec_file: drop weak attribute from
> arch_kexec_apply_relocations[_add]") is also contained in the tree.
> This currently happens in next-20220527.
>
> Prepare the RISC-V similar to the s390 adaption done in 233c1e6c319c.
> This is safe to do on top of the riscv change even without the change to
> arch_kexec_apply_relocations.
>
> Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
> Looks-good-to: liaochang (A)
> Signed-off-by: Uwe Kleine-König
> ---
>
> On Mon, May 30, 2022 at 09:43:26AM +0800, liaochang (A) wrote:
> > > I can confirm that doing
> > > > diff --git a/arch/riscv/include/asm/kexec.h
> > b/arch/riscv/include/asm/kexec.h
> > > index 206217b23301..eee260e8ab30 100644
> > > --- a/arch/riscv/include/asm/kexec.h
> > > +++ b/arch/riscv/include/asm/kexec.h
> > > @@ -55,6 +55,13 @@ extern riscv_kexec_method riscv_kexec_norelocate;
> > > > #ifdef CONFIG_KEXEC_FILE
> > > extern const struct kexec_file_ops elf_kexec_ops;
> > > +
> > > +struct purgatory_info;
> > > +int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> > > + Elf_Shdr *section,
> > > + const Elf_Shdr *relsec,
> > > + const Elf_Shdr *symtab);
> > > +#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add
> > > #endif
> > > > #endif
> >
> > LGTM, you could send a fixup patch to riscv, thanks.
> >
> > > > on top of 838b3e28488f results in a compilable tree. And when
> > merging
> > > 233c1e6c319c into this, it is still building.
> > > > I'm not enough into kexec (and riscv) to judge if this is
> > sensible, or
> > > create a useful commit log but the obvious way forward is to apply the
> > > above patch to the riscv tree before it hits Linus' tree.
>
> Ok, here comes a patch with a generic commit log.
>
> @riscv people: If you prefer, squash it into 838b3e28488f.
Sorry, just saw this after I sent my version of the fix. They're the same,
but do you mind sending a full-on patch so I can merge it?
Sorry, I don't understand your request. I found
https://lore.kernel.org/linux-riscv/20220530180408.16239-1-pal...@rivosinc.com/
but I don't know what a full-on patch is and what stops you merging my
patch.
Is it that it's in reply to a patch series and b4 fails to fetch the
right patch and you ask to send it in a new thread?
Ya, with the reply bits in there my mail merge (which unfortunately
isn't b4, I haven't gotten around to converting yet) got tripped up.
It's kind of easy to for me to screw something up trying to pull bits
out of replies and such, but I think this one was pretty simple (looks
like maybe some PGP or MIME thing was the issue).
I just put
<https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next=7699f7aacf3ebfee51c670b6f796b2797f0f7487>
on my staging branch, it looks OK to me but LMK if there's a problem.
Thanks!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] RISC-V: Prepare dropping week attribute from arch_kexec_apply_relocations[_add]
On Mon, 30 May 2022 00:42:02 PDT (-0700), u.kleine-koe...@pengutronix.de wrote:
Without this change arch/riscv/kernel/elf_kexec.c fails to compile once
commit 233c1e6c319c ("kexec_file: drop weak attribute from
arch_kexec_apply_relocations[_add]") is also contained in the tree.
This currently happens in next-20220527.
Prepare the RISC-V similar to the s390 adaption done in 233c1e6c319c.
This is safe to do on top of the riscv change even without the change to
arch_kexec_apply_relocations.
Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
Looks-good-to: liaochang (A)
Signed-off-by: Uwe Kleine-König
---
On Mon, May 30, 2022 at 09:43:26AM +0800, liaochang (A) wrote:
> I can confirm that doing
>
> diff --git a/arch/riscv/include/asm/kexec.h b/arch/riscv/include/asm/kexec.h
> index 206217b23301..eee260e8ab30 100644
> --- a/arch/riscv/include/asm/kexec.h
> +++ b/arch/riscv/include/asm/kexec.h
> @@ -55,6 +55,13 @@ extern riscv_kexec_method riscv_kexec_norelocate;
>
> #ifdef CONFIG_KEXEC_FILE
> extern const struct kexec_file_ops elf_kexec_ops;
> +
> +struct purgatory_info;
> +int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> + Elf_Shdr *section,
> + const Elf_Shdr *relsec,
> + const Elf_Shdr *symtab);
> +#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add
> #endif
>
> #endif
LGTM, you could send a fixup patch to riscv, thanks.
>
> on top of 838b3e28488f results in a compilable tree. And when merging
> 233c1e6c319c into this, it is still building.
>
> I'm not enough into kexec (and riscv) to judge if this is sensible, or
> create a useful commit log but the obvious way forward is to apply the
> above patch to the riscv tree before it hits Linus' tree.
Ok, here comes a patch with a generic commit log.
@riscv people: If you prefer, squash it into 838b3e28488f.
Sorry, just saw this after I sent my version of the fix. They're the
same, but do you mind sending a full-on patch so I can merge it?
Best regards
Uwe
arch/riscv/include/asm/kexec.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/include/asm/kexec.h b/arch/riscv/include/asm/kexec.h
index 206217b23301..eee260e8ab30 100644
--- a/arch/riscv/include/asm/kexec.h
+++ b/arch/riscv/include/asm/kexec.h
@@ -55,6 +55,13 @@ extern riscv_kexec_method riscv_kexec_norelocate;
#ifdef CONFIG_KEXEC_FILE
extern const struct kexec_file_ops elf_kexec_ops;
+
+struct purgatory_info;
+int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+Elf_Shdr *section,
+const Elf_Shdr *relsec,
+const Elf_Shdr *symtab);
+#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add
#endif
#endif
base-commit: 838b3e28488f702e2b5477b393f009b2639d2b1a
--
2.36.1
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 -next 1/6] kexec_file: Fix kexec_file.c build error for riscv platform
On Fri, 08 Apr 2022 03:09:09 PDT (-0700), lizheng...@huawei.com wrote:
From: Liao Chang
When CONFIG_KEXEC_FILE is set for riscv platform, the compilation of
kernel/kexec_file.c generate build error:
kernel/kexec_file.c: In function 'crash_prepare_elf64_headers':
./arch/riscv/include/asm/page.h:110:71: error: request for member 'virt_addr'
in something not a structure or union
110 | ((x) >= PAGE_OFFSET && (!IS_ENABLED(CONFIG_64BIT) || (x) <
kernel_map.virt_addr))
| ^
./arch/riscv/include/asm/page.h:131:2: note: in expansion of macro
'is_linear_mapping'
131 | is_linear_mapping(_x) ? \
| ^
./arch/riscv/include/asm/page.h:140:31: note: in expansion of macro
'__va_to_pa_nodebug'
140 | #define __phys_addr_symbol(x) __va_to_pa_nodebug(x)
| ^~
./arch/riscv/include/asm/page.h:143:24: note: in expansion of macro
'__phys_addr_symbol'
143 | #define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned
long)(x), 0))
|^~
kernel/kexec_file.c:1327:36: note: in expansion of macro '__pa_symbol'
1327 | phdr->p_offset = phdr->p_paddr = __pa_symbol(_text);
This occurs is because the "kernel_map" referenced in macro
is_linear_mapping() is suppose to be the one of struct kernel_mapping
defined in arch/riscv/mm/init.c, but the 2nd argument of
crash_prepare_elf64_header() has same symbol name, in expansion of macro
is_linear_mapping in function crash_prepare_elf64_header(), "kernel_map"
actually is the local variable.
Signed-off-by: Liao Chang
---
include/linux/kexec.h | 2 +-
kernel/kexec_file.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 58d1b58a971e..ebb1bffbf068 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -227,7 +227,7 @@ struct crash_mem {
extern int crash_exclude_mem_range(struct crash_mem *mem,
unsigned long long mstart,
unsigned long long mend);
-extern int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map,
+extern int crash_prepare_elf64_headers(struct crash_mem *mem, int
need_kernel_map,
void **addr, unsigned long *sz);
#endif /* CONFIG_KEXEC_FILE */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 8347fc158d2b..331a4f0f10f5 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -1260,7 +1260,7 @@ int crash_exclude_mem_range(struct crash_mem *mem,
return 0;
}
-int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map,
+int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
void **addr, unsigned long *sz)
{
Elf64_Ehdr *ehdr;
@@ -1324,7 +1324,7 @@ int crash_prepare_elf64_headers(struct crash_mem *mem,
int kernel_map,
phdr++;
/* Prepare PT_LOAD type program header for kernel text region */
- if (kernel_map) {
+ if (need_kernel_map) {
phdr->p_type = PT_LOAD;
phdr->p_flags = PF_R|PF_W|PF_X;
phdr->p_vaddr = (unsigned long) _text;
IMO this is fine: we could rename all the kernel_map stuff in
arch/riscv, but this is much more self-contained. It's not been ack'd
by anyone else, but get_maintainers just suggests the kexec@ list so I'm
going to take it via the RISC-V tree along with the rest of these.
Thanks!
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 -next 0/6] riscv: kexec: add kexec_file_load() support
On Fri, 08 Apr 2022 03:09:08 PDT (-0700), lizheng...@huawei.com wrote:
This patchset implement kexec_file_load() support on riscv, Most of the
code is based on the kexec-tool-patch repo developed by Nick Kossifids.
This patch series enables us to load the riscv vmlinux by specifying
its file decriptor, instead of user-filled buffer via kexec_file_load()
syscall.
``
Contrary to kexec_load() system call, we reuse the dt blob of the first
kernel to the 2nd explicitly.
To use kexec_file_load() system call, instead of kexec_load(), at kexec
command, '-s' options must be specified. The patch for kexec_tools has
to be apply to riscv architecture source like this:
int elf_riscv_load(int argc, char **argv, const char *buf, off_t len,
...
if (info->file_mode) {
return prepare_kexec_file_options(info);
}
...
Add following routine to prepare cmdline_ptr, cmdline_len and initrd_fd
for syscall kexec_file_load:
int prepare_kexec_file_options(struct kexec_info *info)
{
int fd;
ssize_t result;
struct stat stats;
if (arch_options.cmdline) {
info->command_line = (char *)arch_options.cmdline;
info->command_line_len = strlen(info->command_line) + 1;
}
if (!arch_options.initrd_path) {
info->initrd_fd = -1;
return 0;
}
fd = open(arch_options.initrd_path, O_RDONLY | _O_BINARY);
if (fd < 0) {
fprintf(stderr, "Cannot open `%s': %s\n",
arch_options.initrd_path,
strerror(errno));
return -EINVAL;
}
result = fstat(fd, );
if (result < 0) {
close(fd);
fprintf(stderr, "Cannot stat: %s: %s\n",
arch_options.initrd_path,
strerror(errno));
return -EINVAL;
}
info->initrd_fd = fd;
return 0;
}
The basic usage of kexec_file is:
1) Reload capture kernel image:
$ kexec -s -l --reuse-cmdline
2) Startup capture kernel:
$ kexec -e
For kdump:
1) Reload capture kernel image:
$ kexec -s -p --reuse-cmdline
2) Do something to crash, like:
$ echo c > /proc/sysrq-trigger
v3:
* Rebase on v5.18-rc1
* Workaround for -Wmissing-prototypes
v2:
* Support kdump
* Support purgatory
* Minor cleanups
Li Zhengyu (3):
RISC-V: Support for kexec_file on panic
RISC-V: Add purgatory
RISC-V: Load purgatory in kexec_file
Liao Chang (3):
kexec_file: Fix kexec_file.c build error for riscv platform
RISC-V: use memcpy for kexec_file mode
RISC-V: Add kexec_file support
arch/riscv/Kbuild | 2 +
arch/riscv/Kconfig | 17 +
arch/riscv/include/asm/kexec.h | 4 +
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/elf_kexec.c | 448 +
arch/riscv/kernel/machine_kexec.c | 4 +-
arch/riscv/kernel/machine_kexec_file.c | 14 +
arch/riscv/purgatory/.gitignore| 4 +
arch/riscv/purgatory/Makefile | 95 ++
arch/riscv/purgatory/entry.S | 47 +++
arch/riscv/purgatory/purgatory.c | 45 +++
include/linux/kexec.h | 2 +-
kernel/kexec_file.c| 4 +-
13 files changed, 683 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kernel/elf_kexec.c
create mode 100644 arch/riscv/kernel/machine_kexec_file.c
create mode 100644 arch/riscv/purgatory/.gitignore
create mode 100644 arch/riscv/purgatory/Makefile
create mode 100644 arch/riscv/purgatory/entry.S
create mode 100644 arch/riscv/purgatory/purgatory.c
This doesn't build on 32-bit, there's some issues both in the arch code
and the generic code. Looks like nobody else supports these bits on
32-bit platforms, so I've restricted this to rv64 for now and sent along
a patch set to fix everything up for 32-bit platforms.
This, with that minor Kconfig change just squashed in, is on for-next.
It passes my tests, but I don't have anything specific to kexec_file()
so that's probbaly not so exciting.
Thanks!
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 -next 0/6] riscv: kexec: add kexec_file_load() support
On Wed, 30 Mar 2022 01:16:55 PDT (-0700), lizheng...@huawei.com wrote:
This patchset implement kexec_file_load() support on riscv, Most of the
code is based on the kexec-tool-patch repo developed by Nick Kossifids.
This patch series enables us to load the riscv vmlinux by specifying
its file decriptor, instead of user-filled buffer via kexec_file_load()
syscall.
``
Contrary to kexec_load() system call, we reuse the dt blob of the first
kernel to the 2nd explicitly.
To use kexec_file_load() system call, instead of kexec_load(), at kexec
command, '-s' options must be specified. The patch for kexec_tools has
to be apply to riscv architecture source like this:
int elf_riscv_load(int argc, char **argv, const char *buf, off_t len,
...
if (info->file_mode) {
return prepare_kexec_file_options(info);
}
...
Add following routine to prepare cmdline_ptr, cmdline_len and initrd_fd
for syscall kexec_file_load:
int prepare_kexec_file_options(struct kexec_info *info)
{
int fd;
ssize_t result;
struct stat stats;
if (arch_options.cmdline) {
info->command_line = (char *)arch_options.cmdline;
info->command_line_len = strlen(info->command_line) + 1;
}
if (!arch_options.initrd_path) {
info->initrd_fd = -1;
return 0;
}
fd = open(arch_options.initrd_path, O_RDONLY | _O_BINARY);
if (fd < 0) {
fprintf(stderr, "Cannot open `%s': %s\n",
arch_options.initrd_path,
strerror(errno));
return -EINVAL;
}
result = fstat(fd, );
if (result < 0) {
close(fd);
fprintf(stderr, "Cannot stat: %s: %s\n",
arch_options.initrd_path,
strerror(errno));
return -EINVAL;
}
info->initrd_fd = fd;
return 0;
}
The basic usage of kexec_file is:
1) Reload capture kernel image:
$ kexec -s -l --reuse-cmdline
2) Startup capture kernel:
$ kexec -e
For kdump:
1) Reload capture kernel image:
$ kexec -s -p --reuse-cmdline
2) Do something to crash, like:
$ echo c > /proc/sysrq-trigger
v2:
* Support kdump
* Support purgatory
* Minor cleanups
Li Zhengyu (3):
RISC-V: Support for kexec_file on panic
RISC-V: Add purgatory
RISC-V: Load purgatory in kexec_file
Liao Chang (3):
kexec_file: Fix kexec_file.c build error for riscv platform
RISC-V: use memcpy for kexec_file mode
RISC-V: Add kexec_file support
arch/riscv/Kbuild | 2 +
arch/riscv/Kconfig | 17 +
arch/riscv/include/asm/kexec.h | 4 +
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/elf_kexec.c | 448 +
arch/riscv/kernel/machine_kexec.c | 4 +-
arch/riscv/kernel/machine_kexec_file.c | 14 +
arch/riscv/purgatory/.gitignore| 4 +
arch/riscv/purgatory/Makefile | 95 ++
arch/riscv/purgatory/entry.S | 47 +++
arch/riscv/purgatory/purgatory.c | 42 +++
include/linux/kexec.h | 2 +-
kernel/kexec_file.c| 4 +-
13 files changed, 680 insertions(+), 4 deletions(-)
create mode 100644 arch/riscv/kernel/elf_kexec.c
create mode 100644 arch/riscv/kernel/machine_kexec_file.c
create mode 100644 arch/riscv/purgatory/.gitignore
create mode 100644 arch/riscv/purgatory/Makefile
create mode 100644 arch/riscv/purgatory/entry.S
create mode 100644 arch/riscv/purgatory/purgatory.c
This seems like a reasonable way to do things, but I haven't looked over
the code yet. Looks like the autobuilders are finding some failures,
and it's way too late for 5.18. If you have time to fix the failures
then it'd be great to have a version based on rc1 with these fixed, so
we can target the next merge window. That'll also make it easier to
look this over on my end.
Thanks!
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 2/5] riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
On Mon, 06 Dec 2021 08:05:11 PST (-0800), jszh...@kernel.org wrote:
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE"
by a check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code
and increase compile coverage.
Signed-off-by: Jisheng Zhang
---
arch/riscv/mm/init.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index a15640eeb334..84879a5ce818 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -748,7 +748,6 @@ static inline void setup_vm_final(void)
}
#endif /* CONFIG_MMU */
-#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -765,6 +764,8 @@ static void __init reserve_crashkernel(void)
int ret = 0;
+ if (!IS_ENABLED(CONFIG_KEXEC_CORE))
+ return;
/*
* Don't reserve a region for a crash kernel on a crash kernel
* since it doesn't make much sense and we have limited memory
@@ -805,7 +806,6 @@ static void __init reserve_crashkernel(void)
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
-#endif /* CONFIG_KEXEC_CORE */
void __init paging_init(void)
{
@@ -819,9 +819,7 @@ void __init misc_mem_init(void)
arch_numa_init();
sparse_init();
zone_sizes_init();
-#ifdef CONFIG_KEXEC_CORE
reserve_crashkernel();
-#endif
memblock_dump_all();
}
Acked-by: Palmer Dabbelt
LMK if you wanted me to take this through the RISC-V tree, otherwise I'm
going to assume all these are going in together.
Thanks!
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4 06/10] riscv: Remove non-standard linux, elfcorehdr handling
On Wed, 14 Jul 2021 05:50:16 PDT (-0700), geert+rene...@glider.be wrote:
RISC-V uses platform-specific code to locate the elf core header in
memory. However, this does not conform to the standard
"linux,elfcorehdr" DT bindings, as it relies on a reserved memory node
with the "linux,elfcorehdr" compatible value, instead of on a
"linux,elfcorehdr" property under the "/chosen" node.
The non-compliant code can just be removed, as the standard behavior is
already implemented by platform-agnostic handling in the FDT core code.
Fixes: 5640975003d0234d ("RISC-V: Add crash kernel support")
Signed-off-by: Geert Uytterhoeven
---
v4:
- No changes.
---
arch/riscv/mm/init.c | 20
1 file changed, 20 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 269fc648ef3d84b2..4aa4b6a034086df6 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -829,26 +829,6 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
-#ifdef CONFIG_CRASH_DUMP
-/*
- * We keep track of the ELF core header of the crashed
- * kernel with a reserved-memory region with compatible
- * string "linux,elfcorehdr". Here we register a callback
- * to populate elfcorehdr_addr/size when this region is
- * present. Note that this region will be marked as
- * reserved once we call early_init_fdt_scan_reserved_mem()
- * later on.
- */
-static int __init elfcore_hdr_setup(struct reserved_mem *rmem)
-{
- elfcorehdr_addr = rmem->base;
- elfcorehdr_size = rmem->size;
- return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
-#endif
-
void __init paging_init(void)
{
setup_bootmem();
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
LMK if you wanted me to take this series, otherwise I'm going to assume
it's going in via some other tree.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 1/5] RISC-V: Add EM_RISCV to kexec UAPI header
On Mon, 05 Apr 2021 01:57:08 PDT (-0700), m...@ics.forth.gr wrote: Add RISC-V to the list of supported kexec architecturs, we need to add the definition early-on so that later patches can use it. EM_RISCV is 243 as per ELF psABI specification here: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md Signed-off-by: Nick Kossifidis --- include/uapi/linux/kexec.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h index 05669c87a..778dc191c 100644 --- a/include/uapi/linux/kexec.h +++ b/include/uapi/linux/kexec.h @@ -42,6 +42,7 @@ #define KEXEC_ARCH_MIPS_LE (10 << 16) #define KEXEC_ARCH_MIPS( 8 << 16) #define KEXEC_ARCH_AARCH64 (183 << 16) +#define KEXEC_ARCH_RISCV (243 << 16) /* The artificial cap on the number of segments passed to kexec_load. */ #define KEXEC_SEGMENT_MAX 16 This is missing the kexec maintainers, who I've added. I'm happy to just take this along with the rest of the patch set, as that's probably easiest. I usually like to get an Ack on this sort of thing, but I'm just going to speculate that this isn't controversial and put this on riscv/for-next. LMK if you want me to do something more complicated like a shared tag, but I see the arm64 stuff went in via the arm64 tree so I'm assuming this is fine. Thanks! ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
On Wed, 04 Nov 2015 04:21:51 PST (-0800), pet...@infradead.org wrote: > On Wed, Nov 04, 2015 at 12:41:06PM +0100, Peter Zijlstra wrote: >> On Tue, Nov 03, 2015 at 11:46:30AM -0800, Palmer Dabbelt wrote: >> > This has a "#ifdef CONFIG_*" that used to be exposed to userspace. >> > >> > The names in here are so generic that I don't think it's a good idea >> > to expose them to userspace (or even the rest of the kernel). Since >> > there's only one kernel user, it's been moved to that file. >> > >> > Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com> >> > Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu> >> > Reviewed-by: Albert Ou <a...@eecs.berkeley.edu> >> >> Assuming you want to keep all these patches together in a tree or so. >> Let me know if you want me to take this patch. Well, the plan was to try to get the whole patch set all upstream together. I'd prefer that, because it'll be easier to make sure everything gets in before the last checker patch. Since it touches so many different places I'd be OK with doing it peicemeal. I'm kind of new to this whole process: do you think someone is likely to take this patch set all together? >> Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> > > Ah, build-bot finds your change is broken and you didn't grep right. It > is used in more places. Sorry about that, I must have mis-grep'd. I guess that's what the build-bot is for :). > How about moving it to include/linux/hw_breakpoint.h, instead of having > it in the uapi crud? Yep, that makes sense. I'm going to re-submit a v5 of this patch set, since there was also a missing patch for blackfin that the buildbot found. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl
I recently got bit by a CONFIG_ in userspace bug. This has apparently
happened before, but the check got disabled for triggering too much.
In order to reduce false positives, I added some hueristics to avoid
detecting comments.
Since these tests all pass, I've now re-enabled them.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
scripts/headers_check.pl | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index 62320f9..1634b51 100755
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -27,6 +27,7 @@ my $ret = 0;
my $line;
my $lineno = 0;
my $filename;
+my $check_config_in_multiline_comment = 0;
foreach my $file (@files) {
$filename = $file;
@@ -40,7 +41,7 @@ foreach my $file (@files) {
_asm_types();
_sizetypes();
_declarations();
- # Dropped for now. Too much noise _config();
+ _config();
}
close $fh;
}
@@ -78,7 +79,21 @@ sub check_declarations
sub check_config
{
- if ($line =~ m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
+ my $nocomments = $line;
+ $nocomments =~ s/\/\*.*\*\///; # Remove ANSI-style comments (/* to */)
+ $nocomments =~ s/\/\/.*//; # Remove C99-style comments (// to EOL)
+
+ # Check to see if we're within a multiline comment, and if so
+ # just remove the whole line. I tried matching on '^ * ', but
+ # there's one header that doesn't prepend multi-line comments
+ # with * so that won't work.
+ if ($nocomments =~ m/\/\*/) { $check_config_in_multiline_comment = 1; }
+ if ($nocomments =~ m/\*\//) { $check_config_in_multiline_comment = 0; }
+ if ($check_config_in_multiline_comment == 1) { $nocomments = "" }
+
+ # Check to see if there is something that looks like CONFIG_
+ # inside a userspace-accessible header file and if so, print that out.
+ if ($nocomments =~
m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
printf STDERR "$filename:$lineno: leaks CONFIG_$1 to userspace
where it is not valid\n";
}
}
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 10/13] Move USE_WCACHING to drivers/block/pktcdvd.c
I don't think this was ever intended to be exposed to userspace, but
it did require an "#ifdef CONFIG_*". Since the name is kind of
generic and was only used in one place, I've moved the definition to
the one user.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
drivers/block/pktcdvd.c | 11 +++
include/uapi/linux/pktcdvd.h | 11 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 7be2375..18d2d05 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -90,6 +90,17 @@ do {
\
#define MAX_SPEED 0x
+/*
+ * use drive write caching -- we need deferred error handling to be
+ * able to successfully recover with this option (drive will return good
+ * status as soon as the cdb is validated).
+ */
+#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
+#define USE_WCACHING 1
+#else
+#define USE_WCACHING 0
+#endif
+
static DEFINE_MUTEX(pktcdvd_mutex);
static struct pktcdvd_device *pkt_devs[MAX_WRITERS];
static struct proc_dir_entry *pkt_proc;
diff --git a/include/uapi/linux/pktcdvd.h b/include/uapi/linux/pktcdvd.h
index 2640b9d..05c2bee 100644
--- a/include/uapi/linux/pktcdvd.h
+++ b/include/uapi/linux/pktcdvd.h
@@ -29,17 +29,6 @@
#define PACKET_WAIT_TIME (HZ * 5 / 1000)
/*
- * use drive write caching -- we need deferred error handling to be
- * able to successfully recover with this option (drive will return good
- * status as soon as the cdb is validated).
- */
-#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
-#define USE_WCACHING 1
-#else
-#define USE_WCACHING 0
-#endif
-
-/*
* No user-servicable parts beyond this point ->
*/
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 11/13] Always define MAX_RAW_MINORS as 2**20 in userspace
While I don't think this was ever meant to be exposed to userspace, if
anyone is using it then this will at least provide a correct (if
unlikely) definition.
MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
with CONFIG_MAX_RAW_MINORS.
Note that there's a checkpatch.pl warning about a split config string
here, but I've left that alone.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
drivers/char/raw.c | 7 ---
include/uapi/linux/raw.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
index 60316fb..362d7a6 100644
--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -36,7 +36,7 @@ static struct raw_device_data *raw_devices;
static DEFINE_MUTEX(raw_mutex);
static const struct file_operations raw_ctl_fops; /* forward declaration */
-static int max_raw_minors = MAX_RAW_MINORS;
+static int max_raw_minors = CONFIG_MAX_RAW_MINORS;
module_param(max_raw_minors, int, 0);
MODULE_PARM_DESC(max_raw_minors, "Maximum number of raw devices (1-65536)");
@@ -317,8 +317,9 @@ static int __init raw_init(void)
if (max_raw_minors < 1 || max_raw_minors > 65536) {
printk(KERN_WARNING "raw: invalid max_raw_minors (must be"
- " between 1 and 65536), using %d\n", MAX_RAW_MINORS);
- max_raw_minors = MAX_RAW_MINORS;
+ " between 1 and 65536), using %d\n",
+ CONFIG_MAX_RAW_MINORS);
+ max_raw_minors = CONFIG_MAX_RAW_MINORS;
}
raw_devices = vzalloc(sizeof(struct raw_device_data) * max_raw_minors);
diff --git a/include/uapi/linux/raw.h b/include/uapi/linux/raw.h
index 62d543e..f3d009b 100644
--- a/include/uapi/linux/raw.h
+++ b/include/uapi/linux/raw.h
@@ -13,6 +13,6 @@ struct raw_config_request
__u64 block_minor;
};
-#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
+#define MAX_RAW_MINORS (1 << 20)
#endif /* __LINUX_RAW_H */
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 08/13] Move MAX_SHARED_LIBS to fs/binfmt_flat.c
I'm not sure what this is, but it doesn't feel like something that
should be exposed to userspace here. I'm assuming this file was
exposed for the structure in it, which doesn't depend on
MAX_SHARED_LIBS.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
fs/binfmt_flat.c | 6 ++
include/uapi/linux/flat.h | 6 --
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f723cd3..e89fb43 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -72,6 +72,12 @@
#define RELOC_FAILED 0xff00ff01/* Relocation incorrect
somewhere */
#define UNLOADED_LIB 0x7ff000ff/* Placeholder for unused
library */
+#ifdef CONFIG_BINFMT_SHARED_FLAT
+#defineMAX_SHARED_LIBS (4)
+#else
+#defineMAX_SHARED_LIBS (1)
+#endif
+
struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
diff --git a/include/uapi/linux/flat.h b/include/uapi/linux/flat.h
index 88cd6ba..1b177c7 100644
--- a/include/uapi/linux/flat.h
+++ b/include/uapi/linux/flat.h
@@ -13,12 +13,6 @@
#defineFLAT_VERSION0x0004L
-#ifdef CONFIG_BINFMT_SHARED_FLAT
-#defineMAX_SHARED_LIBS (4)
-#else
-#defineMAX_SHARED_LIBS (1)
-#endif
-
/*
* To make everything easier to port and manage cross platform
* development, all fields are in network byte order.
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 06/13] Move ep_take_care_of_epollwakeup() to fs/eventpoll.c
This doesn't make any sense to expose to userspace, so it's been moved
to the one user. This was introduced by commit 95f19f658ce1 ("epoll:
drop EPOLLWAKEUP if PM_SLEEP is disabled").
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
fs/eventpoll.c | 13 +
include/uapi/linux/eventpoll.h | 12
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 1e009ca..aadee3d 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1812,6 +1812,19 @@ SYSCALL_DEFINE1(epoll_create, int, size)
return sys_epoll_create1(0);
}
+#ifdef CONFIG_PM_SLEEP
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
+ epev->events &= ~EPOLLWAKEUP;
+}
+#else
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ epev->events &= ~EPOLLWAKEUP;
+}
+#endif
+
/*
* The following function implements the controller interface for
* the eventpoll file that enables the insertion/removal/change of
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index bc81fb2..7850373 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -61,16 +61,4 @@ struct epoll_event {
__u64 data;
} EPOLL_PACKED;
-#ifdef CONFIG_PM_SLEEP
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
- epev->events &= ~EPOLLWAKEUP;
-}
-#else
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- epev->events &= ~EPOLLWAKEUP;
-}
-#endif
#endif /* _UAPI_LINUX_EVENTPOLL_H */
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4] Remove #ifdef CONFIG_* from all userspace headers
I think this is good to go. There are two acks, but I wasn't sure if I was supposed to collect them in the patches or not. Arnd Bergman acked #1 and #7. Changes since v3 (<1442271047-4908-1-git-send-email-pal...@dabbelt.com>) * #4 is very different: rather than defining a canonical value for MAP_UNINITIALIZED, it just punts on the problem and lets arch maintainers deal with it. There's still an #ifndef MAP_UNINITIALIZED in there, but that shouldn't get triggered by anything because the arch headers should set it to whatever they actually want. * #11 defines MAX_RAW_MINORS to 2^20 instead of 2^16. * #13 moves the variable around a bit so it gets initialized. I forgot I was in perl and not C :). Changes since v2 (<1441832902-28993-1-git-send-email-pal...@dabbelt.com>) * Patch set renamed. * #2 is rewritten to use sys_ni.c instead of an #ifdef * #3, #6, #8, #9, #10, and #11 no longer use "#ifdef __KERNEL__" but have instead moved the offending lines to the correct, kernel-only files. * #4 has been rewritten to always define MAP_UNINITIALIZED to non-zero, rather than defining it to zero when in userspace. * #5 got a whole lot longer -- rather than just always hiding these fields from userspace, there is now a second "struct elf_fdpic_prstatus" structure. This should allow userspace to parse core dumps correctly. * Rebased onto 9c488de24f7264f08d341024bffdd637b4d04c96. Changes since v1 (<1441152610-22566-1-git-send-email-pal...@dabbelt.com>) * All patches but #1 were added. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c
This used to be behind an #ifdef COMPAT_COMPAT, so most of userspace
wouldn't have seen the definition before. Unfortunately this header
file became visible to userspace, so the definition has instead been
moved to net/atm/svc.c (the only user).
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
include/uapi/linux/atmdev.h | 4
net/atm/svc.c | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/atmdev.h b/include/uapi/linux/atmdev.h
index 93e0ec0..3dcec70 100644
--- a/include/uapi/linux/atmdev.h
+++ b/include/uapi/linux/atmdev.h
@@ -100,10 +100,6 @@ struct atm_dev_stats {
/* use backend to make new if */
#define ATM_ADDPARTY _IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
/* add party to p2mp call */
-#ifdef CONFIG_COMPAT
-/* It actually takes struct sockaddr_atmsvc, not struct atm_iobuf */
-#define COMPAT_ATM_ADDPARTY_IOW('a', ATMIOC_SPECIAL+4,struct
compat_atm_iobuf)
-#endif
#define ATM_DROPPARTY _IOW('a', ATMIOC_SPECIAL+5,int)
/* drop party from p2mp call */
diff --git a/net/atm/svc.c b/net/atm/svc.c
index 3fa0a9e..9e2e6ef 100644
--- a/net/atm/svc.c
+++ b/net/atm/svc.c
@@ -27,6 +27,11 @@
#include "signaling.h"
#include "addr.h"
+#ifdef CONFIG_COMPAT
+/* It actually takes struct sockaddr_atmsvc, not struct atm_iobuf */
+#define COMPAT_ATM_ADDPARTY _IOW('a', ATMIOC_SPECIAL+4, struct
compat_atm_iobuf)
+#endif
+
static int svc_create(struct net *net, struct socket *sock, int protocol,
int kern);
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 07/13] Make FB_BACKLIGHT_{LEVELS,MAX} always visible
Nothing else in the kernel defines this, and this header is visible to
userspace. Rather than hiding it in an #ifdef, I think it's sane to
just make this visible to userspace.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
include/uapi/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
index fb795c3..8926f13 100644
--- a/include/uapi/linux/fb.h
+++ b/include/uapi/linux/fb.h
@@ -392,11 +392,8 @@ struct fb_cursor {
struct fb_image image; /* Cursor image */
};
-#ifdef CONFIG_FB_BACKLIGHT
/* Settings for the generic backlight code */
#define FB_BACKLIGHT_LEVELS128
#define FB_BACKLIGHT_MAX 0xFF
-#endif
-
#endif /* _UAPI_LINUX_FB_H */
--
2.4.10
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c
On Thu, 17 Sep 2015 02:57:12 PDT (-0700), dhowe...@redhat.com wrote:
> Palmer Dabbelt <pal...@dabbelt.com> wrote:
>
>> +#ifdef CONFIG_COMPAT
>> +/* It actually takes struct sockaddr_atmsvc, not struct atm_iobuf */
>> +#define COMPAT_ATM_ADDPARTY _IOW('a', ATMIOC_SPECIAL+4, struct
>> compat_atm_iobuf)
>> +#endif
>
> I wonder if it would hurt to ditch the conditionals entirely. It only eats
> cpp namespace, not C namespace so it won't affect the output if it is not used
> because the code that uses it is compiled out.
Makes sense to me.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
On Tue, 15 Sep 2015 01:06:07 PDT (-0700), pet...@infradead.org wrote:
> On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>>
>> The names in here are so generic that I don't think it's a good idea
>> to expose them to userspace (or even the rest of the kernel). Since
>> there's only one kernel user, it's been moved to that file.
>>
>> Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
>> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
>> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
>> ---
>> include/uapi/linux/hw_breakpoint.h | 10 --
>> kernel/events/hw_breakpoint.c | 10 ++
>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/uapi/linux/hw_breakpoint.h
>> b/include/uapi/linux/hw_breakpoint.h
>> index b04000a2296a..7a6a5a7f9511 100644
>> --- a/include/uapi/linux/hw_breakpoint.h
>> +++ b/include/uapi/linux/hw_breakpoint.h
>> @@ -17,14 +17,4 @@ enum {
>> HW_BREAKPOINT_INVALID = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>> };
>>
>> -enum bp_type_idx {
>> -TYPE_INST = 0,
>> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> -TYPE_DATA = 0,
>> -#else
>> -TYPE_DATA = 1,
>> -#endif
>> -TYPE_MAX
>> -};
>
> This is rather unfortunate; you are correct that the naming is too
> generic (and I tend to agree), but I think these values are required by
> userspace to fill out:
>
> perf_event_attr::bp_type
>
> So removing them will break things.
>
> Frederic?
perf_event_open(2) says
bp_type (since Linux 2.6.33)
This chooses the breakpoint type. It is one of:
HW_BREAKPOINT_EMPTY
No breakpoint.
HW_BREAKPOINT_R
Count when we read the memory location.
HW_BREAKPOINT_W
Count when we write the memory location.
HW_BREAKPOINT_RW
Count when we read or write the memory location.
HW_BREAKPOINT_X
Count when we execute code at the memory location.
The values can be combined via a bitwise or, but the combination
of HW_BREAKPOINT_R or HW_BREAKPOINT_W with HW_BREAKPOINT_X is
not allowed.
so I think removing this enum from userspace is OK. Did I miss
something?
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
On Tue, 15 Sep 2015 12:39:10 PDT (-0700), pet...@infradead.org wrote:
> On Tue, Sep 15, 2015 at 11:40:11AM -0700, Palmer Dabbelt wrote:
>> On Tue, 15 Sep 2015 01:06:07 PDT (-0700), pet...@infradead.org wrote:
>> > On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> >> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>> >>
>> >> The names in here are so generic that I don't think it's a good idea
>> >> to expose them to userspace (or even the rest of the kernel). Since
>> >> there's only one kernel user, it's been moved to that file.
>> >>
>> >> Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
>> >> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
>> >> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
>> >> ---
>> >> include/uapi/linux/hw_breakpoint.h | 10 --
>> >> kernel/events/hw_breakpoint.c | 10 ++
>> >> 2 files changed, 10 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/include/uapi/linux/hw_breakpoint.h
>> >> b/include/uapi/linux/hw_breakpoint.h
>> >> index b04000a2296a..7a6a5a7f9511 100644
>> >> --- a/include/uapi/linux/hw_breakpoint.h
>> >> +++ b/include/uapi/linux/hw_breakpoint.h
>> >> @@ -17,14 +17,4 @@ enum {
>> >> HW_BREAKPOINT_INVALID = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>> >> };
>> >>
>> >> -enum bp_type_idx {
>> >> - TYPE_INST = 0,
>> >> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> >> - TYPE_DATA = 0,
>> >> -#else
>> >> - TYPE_DATA = 1,
>> >> -#endif
>> >> - TYPE_MAX
>> >> -};
>> >
>> > This is rather unfortunate; you are correct that the naming is too
>> > generic (and I tend to agree), but I think these values are required by
>> > userspace to fill out:
>> >
>> > perf_event_attr::bp_type
>> >
>> > So removing them will break things.
>> >
>> > Frederic?
>>
>> perf_event_open(2) says
>>
>>bp_type (since Linux 2.6.33)
>> This chooses the breakpoint type. It is one of:
>>
>> HW_BREAKPOINT_EMPTY
>> No breakpoint.
>>
>> HW_BREAKPOINT_R
>> Count when we read the memory location.
>>
>> HW_BREAKPOINT_W
>> Count when we write the memory location.
>>
>> HW_BREAKPOINT_RW
>> Count when we read or write the memory location.
>>
>> HW_BREAKPOINT_X
>> Count when we execute code at the memory location.
>>
>> The values can be combined via a bitwise or, but the
>> combination
>> of HW_BREAKPOINT_R or HW_BREAKPOINT_W with HW_BREAKPOINT_X
>> is
>> not allowed.
>>
>> so I think removing this enum from userspace is OK. Did I miss
>> something?
>
> Nah, could've just been me not being awake. Unless Frederic says
> otherwise I'll chalk it up to not having drank enough morning juice.
Well, I'm going to leave this alone, then -- as Arnd pointed out in a
later email that got mis-threaded, this would be super tricky to fix
if userspace actually relied on it (which is why I was scared I was
wrong).
v4 (which is hopefully the final version of the patch set) will leave
this as it is.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace
On Tue, 15 Sep 2015 13:42:47 PDT (-0700), h...@zytor.com wrote: > On 09/14/2015 03:50 PM, Palmer Dabbelt wrote: >> While I don't think this was ever meant to be exposed to userspace, if >> anyone is using it then this will at least provide a correct (if >> unlikely) definition. >> >> MAX_RAW_MINORS used to be used in the kernel, where it's been replaced >> with CONFIG_MAX_RAW_MINORS. >> >> Note that there's a checkpatch.pl warning about a split config string >> here, but I've left that alone. > > From a UAPI perspective I would think the right value would be 2^20. Wow, I'm super surprised. For some reason I thought major/minor numbers were 16 bits, but according to glibc I just have no idea what I'm doing :). Thanks for catching this! ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 10/13] Move USE_WCACHING to drivers/block/pktcdvd.c
I don't think this was ever intended to be exposed to userspace, but
it did require an "#ifdef CONFIG_*". Since the name is kind of
generic and was only used in one place, I've moved the definition to
the one user.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
drivers/block/pktcdvd.c | 11 +++
include/uapi/linux/pktcdvd.h | 11 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 7be2375db7f2..18d2d05f5ac9 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -90,6 +90,17 @@ do {
\
#define MAX_SPEED 0x
+/*
+ * use drive write caching -- we need deferred error handling to be
+ * able to successfully recover with this option (drive will return good
+ * status as soon as the cdb is validated).
+ */
+#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
+#define USE_WCACHING 1
+#else
+#define USE_WCACHING 0
+#endif
+
static DEFINE_MUTEX(pktcdvd_mutex);
static struct pktcdvd_device *pkt_devs[MAX_WRITERS];
static struct proc_dir_entry *pkt_proc;
diff --git a/include/uapi/linux/pktcdvd.h b/include/uapi/linux/pktcdvd.h
index 2640b9d4e243..05c2bee70d6c 100644
--- a/include/uapi/linux/pktcdvd.h
+++ b/include/uapi/linux/pktcdvd.h
@@ -29,17 +29,6 @@
#define PACKET_WAIT_TIME (HZ * 5 / 1000)
/*
- * use drive write caching -- we need deferred error handling to be
- * able to successfully recover with this option (drive will return good
- * status as soon as the cdb is validated).
- */
-#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
-#define USE_WCACHING 1
-#else
-#define USE_WCACHING 0
-#endif
-
-/*
* No user-servicable parts beyond this point ->
*/
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 12/13] Remove AT_VECTOR_SIZE_ARCH on x86
It looks like there aren't actually users of this macro anywhere: * The kernel doesn't use it on x86 because we don't suppor ELF FDPIC. * The only Google results point to LMKL patches, both the one that wrote this (from 2010) and my patch to hide it behind __KERNEL__. * I grep'd through all the source tarballs on my machine, and the only packages that matched were the kernel and crui (which copied a PPC kernel header). Since I'm not sure how to actually provide the right answer (if I understand correctly, CONFIG_IA32_EMULATION is not __i386__), the only thing I can think of to do is to just remove the definition. Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu> --- arch/x86/include/uapi/asm/auxvec.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/arch/x86/include/uapi/asm/auxvec.h b/arch/x86/include/uapi/asm/auxvec.h index 77203ac352de..1316b4c35425 100644 --- a/arch/x86/include/uapi/asm/auxvec.h +++ b/arch/x86/include/uapi/asm/auxvec.h @@ -9,11 +9,4 @@ #endif #define AT_SYSINFO_EHDR33 -/* entries in ARCH_DLINFO: */ -#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64) -# define AT_VECTOR_SIZE_ARCH 2 -#else /* else it's non-compat x86-64 */ -# define AT_VECTOR_SIZE_ARCH 1 -#endif - #endif /* _ASM_X86_AUXVEC_H */ -- 2.4.6 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
The names in here are so generic that I don't think it's a good idea
to expose them to userspace (or even the rest of the kernel). Since
there's only one kernel user, it's been moved to that file.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
include/uapi/linux/hw_breakpoint.h | 10 --
kernel/events/hw_breakpoint.c | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/hw_breakpoint.h
b/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..7a6a5a7f9511 100644
--- a/include/uapi/linux/hw_breakpoint.h
+++ b/include/uapi/linux/hw_breakpoint.h
@@ -17,14 +17,4 @@ enum {
HW_BREAKPOINT_INVALID = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
};
-enum bp_type_idx {
- TYPE_INST = 0,
-#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
- TYPE_DATA = 0,
-#else
- TYPE_DATA = 1,
-#endif
- TYPE_MAX
-};
-
#endif /* _UAPI_LINUX_HW_BREAKPOINT_H */
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 92ce5f4ccc26..5ad117e0f55b 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -58,6 +58,16 @@ struct bp_cpuinfo {
unsigned intflexible; /* XXX: placeholder, see fetch_this_slot() */
};
+enum bp_type_idx {
+ TYPE_INST = 0,
+#if defined(CONFIG_HAVE_MIXED_BREAKPOINTS_REGS)
+ TYPE_DATA = 0,
+#else
+ TYPE_DATA = 1,
+#endif
+ TYPE_MAX
+};
+
static DEFINE_PER_CPU(struct bp_cpuinfo, bp_cpuinfo[TYPE_MAX]);
static int nr_slots[TYPE_MAX];
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 01/13] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h
When working on the RISC-V port I noticed that F_SETLK64 was being defined on our 64-bit platform, despite our port being so new that we've only ever had the 64-bit file ops. Since there's not compat layer for these, this causes fcntl to bail out. It turns out that one of the ways in with F_SETLK64 was being defined (there's some more in glibc, but that's a whole different story... :)) is the result of CONFIG_64BIT showing up in this user-visible header. confirms this isn't sane, so I replaced it with a __BITS_PER_LONG check. Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu> --- include/uapi/asm-generic/fcntl.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h index e063effe0cc1..14a5c8237d84 100644 --- a/include/uapi/asm-generic/fcntl.h +++ b/include/uapi/asm-generic/fcntl.h @@ -1,6 +1,7 @@ #ifndef _ASM_GENERIC_FCNTL_H #define _ASM_GENERIC_FCNTL_H +#include #include /* @@ -115,7 +116,7 @@ #define F_GETSIG 11 /* for sockets. */ #endif -#ifndef CONFIG_64BIT +#if (__BITS_PER_LONG == 32) #ifndef F_GETLK64 #define F_GETLK64 12 /* using 'struct flock64' */ #define F_SETLK64 13 -- 2.4.6 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 13/13] Re-enable and clean up "check_config()" in headers_check.pl
I recently got bit by a CONFIG_ in userspace bug. This has apparently
happened before, but the check got disabled for triggering too much.
In order to reduce false positives, I added some hueristics to avoid
detecting comments.
Since these tests all pass, I've now re-enabled them.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
scripts/headers_check.pl | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index 62320f93e903..dd413ad9c850 100755
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -40,7 +40,7 @@ foreach my $file (@files) {
_asm_types();
_sizetypes();
_declarations();
- # Dropped for now. Too much noise _config();
+ _config();
}
close $fh;
}
@@ -76,9 +76,24 @@ sub check_declarations
}
}
+my $check_config_in_multiline_comment = 0;
sub check_config
{
- if ($line =~ m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
+ my $nocomments = $line;
+ $nocomments =~ s/\/\*.*\*\///; # Remove ANSI-style comments (/* to */)
+ $nocomments =~ s/\/\/.*//; # Remove C99-style comments (// to EOL)
+
+ # Check to see if we're within a multiline comment, and if so
+ # just remove the whole line. I tried matching on '^ * ', but
+ # there's one header that doesn't prepend multi-line comments
+ # with * so that won't work.
+ if ($nocomments =~ m/\/\*/) { $check_config_in_multiline_comment = 1; }
+ if ($nocomments =~ m/\*\//) { $check_config_in_multiline_comment = 0; }
+ if ($check_config_in_multiline_comment == 1) { $nocomments = "" }
+
+ # Check to see if there is something that looks like CONFIG_
+ # inside a userspace-accessible header file and if so, print that out.
+ if ($nocomments =~
m/[^a-zA-Z0-9_]+CONFIG_([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/) {
printf STDERR "$filename:$lineno: leaks CONFIG_$1 to userspace
where it is not valid\n";
}
}
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace
While I don't think this was ever meant to be exposed to userspace, if
anyone is using it then this will at least provide a correct (if
unlikely) definition.
MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
with CONFIG_MAX_RAW_MINORS.
Note that there's a checkpatch.pl warning about a split config string
here, but I've left that alone.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
drivers/char/raw.c | 7 ---
include/uapi/linux/raw.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
index 60316fbaf295..362d7a6511b9 100644
--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -36,7 +36,7 @@ static struct raw_device_data *raw_devices;
static DEFINE_MUTEX(raw_mutex);
static const struct file_operations raw_ctl_fops; /* forward declaration */
-static int max_raw_minors = MAX_RAW_MINORS;
+static int max_raw_minors = CONFIG_MAX_RAW_MINORS;
module_param(max_raw_minors, int, 0);
MODULE_PARM_DESC(max_raw_minors, "Maximum number of raw devices (1-65536)");
@@ -317,8 +317,9 @@ static int __init raw_init(void)
if (max_raw_minors < 1 || max_raw_minors > 65536) {
printk(KERN_WARNING "raw: invalid max_raw_minors (must be"
- " between 1 and 65536), using %d\n", MAX_RAW_MINORS);
- max_raw_minors = MAX_RAW_MINORS;
+ " between 1 and 65536), using %d\n",
+ CONFIG_MAX_RAW_MINORS);
+ max_raw_minors = CONFIG_MAX_RAW_MINORS;
}
raw_devices = vzalloc(sizeof(struct raw_device_data) * max_raw_minors);
diff --git a/include/uapi/linux/raw.h b/include/uapi/linux/raw.h
index 62d543e70603..f0390b3e8530 100644
--- a/include/uapi/linux/raw.h
+++ b/include/uapi/linux/raw.h
@@ -13,6 +13,6 @@ struct raw_config_request
__u64 block_minor;
};
-#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
+#define MAX_RAW_MINORS 65535
#endif /* __LINUX_RAW_H */
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v3] Remove #ifdef CONFIG_* from all userspace headers
This patch set used to be called "[PATCH] Remove #ifdef CONFIG_64BIT from all asm-generic/fcntl.h". This is version 3 of the patch set. I think things are kind of cleaning up, but there's still some questions I have: * #4 might be dangerous, but I think this is the best way to do it because otherwise arch maintainers will have to #define this to something. Since Xtensa already had exactly the same bug as the asm-generic header did, I think it'd be best to avoid those if possible. I'm OK changing this to define the value to 0 by default (though thinking now, I think it'd be better to not define it by default), since most kernels aren't going to have MAP_UNINITIALIZED do anything anyway. * #5 is big and I don't really understand what's going on, so it's probably broken somewhere. Also, there's some checkpatch warnings that I purposely haven't fixed: * In #5, there's a checkpatch.pl complaint about same-line struct braces. I've left that in to match the rest of the file, but I can also fix all of them if that would be better. * In #10, there's a checkpatch.pl complaint about a split printk format string, but that was there before and I don't see a way to make it a lot cleaner, so I'm leaving it alone. * In #13, there's two checkpatch.pl complains. One is about block comments that is bogus, and one is about long lines but there's more of those so I think it's OK. Thanks to everyone who looked at v2! Changes since v2 (<1441832902-28993-1-git-send-email-pal...@dabbelt.com>) * Patch set renamed. * #2 is rewritten to use sys_ni.c instead of an #ifdef * #3, #6, #8, #9, #10, and #11 no longer use "#ifdef __KERNEL__" but have instead moved the offending lines to the correct, kernel-only files. * #4 has been rewritten to always define MAP_UNINITIALIZED to non-zero, rather than defining it to zero when in userspace. * #5 got a whole lot longer -- rather than just always hiding these fields from userspace, there is now a second "struct elf_fdpic_prstatus" structure. This should allow userspace to parse core dumps correctly. * Rebased onto 9c488de24f7264f08d341024bffdd637b4d04c96. Changes since v1 (<1441152610-22566-1-git-send-email-pal...@dabbelt.com>) * All patches but #1 were added. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 05/13] Split FDPIC "struct elf_prstatus" to "struct elf_fdpic_prstatus"
This is a pretty big change that I haven't tested any, which worries
me a lot. The general idea here is that "struct elf_prstatus" can be
visible to userspace (from )
"
Generic ptrace interface that exports the architecture specific
regsets using the corresponding NT_* types (which are also used in
the core dump). Please note that the NT_PRSTATUS note type in a
core dump contains a full 'struct elf_prstatus'. But the
user_regset for NT_PRSTATUS contains just the elf_gregset_t that is
the pr_reg field of 'struct elf_prstatus'. For all the other
user_regset flavors, the user_regset layout and the ELF core dump
note payload are exactly the same layout.
"
so it shouldn't have an "#ifdef CONFIG_" in there.
This splits the structure into two different structures, one still
named "struct elf_prstatus", and one for ELF FDPIC that is named
"struct elf_fdpic_prstatus" -- the idea here is that most users are
standard ELF, so that's the name that didn't change.
I tried to fix all the users of "struct elf_prstatus" that should now
be using "struct elf_fdpic_prstatus". The only testing I did here was
to build a Blackfin defconfig with "struct elf_prstatus" not defined,
and to build an x86 defconfig with "struct elf_fdpic_prstatus" not
defined.
Note that this fails checkpatch.pl with a complaint about wanting open
braces on the same line as struct definitions. The existing struct
definitions in this file have the brace a line afterwards, so I'm
going to leave this alone.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
fs/binfmt_elf_fdpic.c| 6 +++---
fs/proc/kcore.c | 16
include/linux/kexec.h| 4
include/uapi/linux/elfcore.h | 37 +++--
kernel/kexec_core.c | 4
5 files changed, 62 insertions(+), 5 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index d3634bfb7fe1..587bf0466d71 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1323,7 +1323,7 @@ static inline void fill_note(struct memelfnote *note,
const char *name, int type
* fill up all the fields in prstatus from the given task struct, except
* registers which need to be filled up separately.
*/
-static void fill_prstatus(struct elf_prstatus *prstatus,
+static void fill_prstatus(struct elf_fdpic_prstatus *prstatus,
struct task_struct *p, long signr)
{
prstatus->pr_info.si_signo = prstatus->pr_cursig = signr;
@@ -1406,7 +1406,7 @@ static int fill_psinfo(struct elf_prpsinfo *psinfo,
struct task_struct *p,
struct elf_thread_status
{
struct list_head list;
- struct elf_prstatus prstatus; /* NT_PRSTATUS */
+ struct elf_fdpic_prstatus prstatus; /* NT_PRSTATUS */
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
@@ -1539,7 +1539,7 @@ static int elf_fdpic_core_dump(struct coredump_params
*cprm)
loff_t offset = 0, dataoff;
int numnote;
struct memelfnote *notes = NULL;
- struct elf_prstatus *prstatus = NULL; /* NT_PRSTATUS */
+ struct elf_fdpic_prstatus *prstatus = NULL; /* NT_PRSTATUS */
struct elf_prpsinfo *psinfo = NULL; /* NT_PRPSINFO */
LIST_HEAD(thread_list);
struct list_head *t;
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 92e6726f6e37..b1edd77ec854 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -90,7 +90,11 @@ static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
(*nphdr + 2)*sizeof(struct elf_phdr) +
3 * ((sizeof(struct elf_note)) +
roundup(sizeof(CORE_STR), 4)) +
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+ roundup(sizeof(struct elf_fdpic_prstatus), 4) +
+#else
roundup(sizeof(struct elf_prstatus), 4) +
+#endif
roundup(sizeof(struct elf_prpsinfo), 4) +
roundup(arch_task_struct_size, 4);
*elf_buflen = PAGE_ALIGN(*elf_buflen);
@@ -318,7 +322,11 @@ static char *storenote(struct memelfnote *men, char *bufp)
*/
static void elf_kcore_store_hdr(char *bufp, int nphdr, int dataoff)
{
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+ struct elf_fdpic_prstatus prstatus; /* NT_PRSTATUS */
+#else
struct elf_prstatus prstatus; /* NT_PRSTATUS */
+#endif
struct elf_prpsinfo prpsinfo; /* NT_PRPSINFO */
struct elf_phdr *nhdr, *phdr;
struct elfhdr *elf;
@@ -387,10 +395,18 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr,
int dataoff)
/* set up the process status */
notes[0].name = CORE_STR;
notes[0].type = NT_PRSTATUS;
+
[PATCH 07/13] Make FB_BACKLIGHT_{LEVELS,MAX} always visible
Nothing else in the kernel defines this, and this header is visible to
userspace. Rather than hiding it in an #ifdef, I think it's sane to
just make this visible to userspace.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
include/uapi/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
index fb795c3b3c17..8926f13bc19f 100644
--- a/include/uapi/linux/fb.h
+++ b/include/uapi/linux/fb.h
@@ -392,11 +392,8 @@ struct fb_cursor {
struct fb_image image; /* Cursor image */
};
-#ifdef CONFIG_FB_BACKLIGHT
/* Settings for the generic backlight code */
#define FB_BACKLIGHT_LEVELS128
#define FB_BACKLIGHT_MAX 0xFF
-#endif
-
#endif /* _UAPI_LINUX_FB_H */
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 03/13] Move COMPAT_ATM_ADDPARTY to net/atm/svc.c
This used to be behind an #ifdef COMPAT_COMPAT, so most of userspace
wouldn't have seen the definition before. Unfortunately this header
file became visible to userspace, so the definition has instead been
moved to net/atm/svc.c (the only user).
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
include/uapi/linux/atmdev.h | 4
net/atm/svc.c | 5 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/atmdev.h b/include/uapi/linux/atmdev.h
index 93e0ec008ca8..3dcec701501c 100644
--- a/include/uapi/linux/atmdev.h
+++ b/include/uapi/linux/atmdev.h
@@ -100,10 +100,6 @@ struct atm_dev_stats {
/* use backend to make new if */
#define ATM_ADDPARTY _IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
/* add party to p2mp call */
-#ifdef CONFIG_COMPAT
-/* It actually takes struct sockaddr_atmsvc, not struct atm_iobuf */
-#define COMPAT_ATM_ADDPARTY_IOW('a', ATMIOC_SPECIAL+4,struct
compat_atm_iobuf)
-#endif
#define ATM_DROPPARTY _IOW('a', ATMIOC_SPECIAL+5,int)
/* drop party from p2mp call */
diff --git a/net/atm/svc.c b/net/atm/svc.c
index 3fa0a9ee98d1..9e2e6ef285e8 100644
--- a/net/atm/svc.c
+++ b/net/atm/svc.c
@@ -27,6 +27,11 @@
#include "signaling.h"
#include "addr.h"
+#ifdef CONFIG_COMPAT
+/* It actually takes struct sockaddr_atmsvc, not struct atm_iobuf */
+#define COMPAT_ATM_ADDPARTY _IOW('a', ATMIOC_SPECIAL+4, struct
compat_atm_iobuf)
+#endif
+
static int svc_create(struct net *net, struct socket *sock, int protocol,
int kern);
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace
This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so userspace wouldn't actually ever see it be non-zero. While I could have kept hiding it, the man pages seem to indicate that MAP_UNINITIALIZED should be visible: mmap(2) MAP_UNINITIALIZED (since Linux 2.6.33) Don't clear anonymous pages. This flag is intended to improve performance on embedded devices. This flag is honored only if the kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED option. Because of the security implications, that option is normally enabled only on embedded devices (i.e., devices where one has complete control of the contents of user memory). and since the only time it shows up in my /usr/include is in this header I believe this should have been visible to userspace (as non-zero, which wouldn't do anything when or'd into the flags) all along. This change also applies to the xtensa version of this definition, whic is the same as the generic one. Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu> --- arch/xtensa/include/uapi/asm/mman.h| 4 +--- include/uapi/asm-generic/mman-common.h | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h index 201aec0e0446..2cbc1e717082 100644 --- a/arch/xtensa/include/uapi/asm/mman.h +++ b/arch/xtensa/include/uapi/asm/mman.h @@ -55,11 +55,9 @@ #define MAP_NONBLOCK 0x2 /* do not block on IO */ #define MAP_STACK 0x4 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x8 /* create a huge page mapping */ -#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED +#ifndef MAP_UNINITIALIZED # define MAP_UNINITIALIZED 0x400 /* For anonymous mmap, memory could be * uninitialized */ -#else -# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */ #endif /* diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h index ddc3b36f1046..7aeeb12db193 100644 --- a/include/uapi/asm-generic/mman-common.h +++ b/include/uapi/asm-generic/mman-common.h @@ -19,10 +19,8 @@ #define MAP_TYPE 0x0f/* Mask for type of mapping */ #define MAP_FIXED 0x10/* Interpret addr exactly */ #define MAP_ANONYMOUS 0x20/* don't use a file */ -#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED +#ifndef MAP_UNINITIALIZED # define MAP_UNINITIALIZED 0x400 /* For anonymous mmap, memory could be uninitialized */ -#else -# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */ #endif #define MS_ASYNC 1 /* sync memory asynchronously */ -- 2.4.6 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 06/13] Move ep_take_care_of_epollwakeup() to fs/eventpoll.c
This doesn't make any sense to expose to userspace, so it's been moved
to the one user. This was introduced by commit 95f19f658ce1 ("epoll:
drop EPOLLWAKEUP if PM_SLEEP is disabled").
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
fs/eventpoll.c | 13 +
include/uapi/linux/eventpoll.h | 12
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 1e009cad8d5c..aadee3d1931a 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1812,6 +1812,19 @@ SYSCALL_DEFINE1(epoll_create, int, size)
return sys_epoll_create1(0);
}
+#ifdef CONFIG_PM_SLEEP
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
+ epev->events &= ~EPOLLWAKEUP;
+}
+#else
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ epev->events &= ~EPOLLWAKEUP;
+}
+#endif
+
/*
* The following function implements the controller interface for
* the eventpoll file that enables the insertion/removal/change of
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index bc81fb2e1f0e..7850373079ee 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -61,16 +61,4 @@ struct epoll_event {
__u64 data;
} EPOLL_PACKED;
-#ifdef CONFIG_PM_SLEEP
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
- epev->events &= ~EPOLLWAKEUP;
-}
-#else
-static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
-{
- epev->events &= ~EPOLLWAKEUP;
-}
-#endif
#endif /* _UAPI_LINUX_EVENTPOLL_H */
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 02/13] Use sys_ni.c instead of #ifdef to disable fork on CONFIG_NOMMU
I think this change actually doesn't do anything: __NR_fork was still being defined either way, and on my machine fork() in comes from libc. This just moves to the standard mechanism for defining syscalls that aren't implemented instead, which has the side-effect of no longer having an #ifdef CONFIG_* in a user-visible header. Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com> Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu> Reviewed-by: Albert Ou <a...@eecs.berkeley.edu> --- include/uapi/asm-generic/unistd.h | 4 kernel/sys_ni.c | 1 + 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 8da542a2874d..21689284360b 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -867,11 +867,7 @@ __SYSCALL(__NR_uselib, sys_uselib) __SYSCALL(__NR__sysctl, sys_sysctl) #define __NR_fork 1079 -#ifdef CONFIG_MMU __SYSCALL(__NR_fork, sys_fork) -#else -__SYSCALL(__NR_fork, sys_ni_syscall) -#endif /* CONFIG_MMU */ #undef __NR_syscalls #define __NR_syscalls (__NR_fork+1) diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index a02decf15583..c830f7f9e36d 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -174,6 +174,7 @@ cond_syscall(sys_setfsuid); cond_syscall(sys_setfsgid); cond_syscall(sys_capget); cond_syscall(sys_capset); +cond_syscall(sys_fork); /* arch-specific weak syscall entries */ cond_syscall(sys_pciconfig_read); -- 2.4.6 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 08/13] Move MAX_SHARED_LIBS to fs/binfmt_flat.c
I'm not sure what this is, but it doesn't feel like something that
should be exposed to userspace here. I'm assuming this file was
exposed for the structure in it, which doesn't depend on
MAX_SHARED_LIBS.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: Andrew Waterman <water...@eecs.berkeley.edu>
Reviewed-by: Albert Ou <a...@eecs.berkeley.edu>
---
fs/binfmt_flat.c | 6 ++
include/uapi/linux/flat.h | 6 --
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f723cd3a455c..e89fb43c2a10 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -72,6 +72,12 @@
#define RELOC_FAILED 0xff00ff01/* Relocation incorrect
somewhere */
#define UNLOADED_LIB 0x7ff000ff/* Placeholder for unused
library */
+#ifdef CONFIG_BINFMT_SHARED_FLAT
+#defineMAX_SHARED_LIBS (4)
+#else
+#defineMAX_SHARED_LIBS (1)
+#endif
+
struct lib_info {
struct {
unsigned long start_code; /* Start of text
segment */
diff --git a/include/uapi/linux/flat.h b/include/uapi/linux/flat.h
index 88cd6baba8f3..1b177c7637c4 100644
--- a/include/uapi/linux/flat.h
+++ b/include/uapi/linux/flat.h
@@ -13,12 +13,6 @@
#defineFLAT_VERSION0x0004L
-#ifdef CONFIG_BINFMT_SHARED_FLAT
-#defineMAX_SHARED_LIBS (4)
-#else
-#defineMAX_SHARED_LIBS (1)
-#endif
-
/*
* To make everything easier to port and manage cross platform
* development, all fields are in network byte order.
--
2.4.6
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace
On Mon, 14 Sep 2015 17:23:58 PDT (-0700), kir...@shutemov.name wrote: > On Mon, Sep 14, 2015 at 03:50:38PM -0700, Palmer Dabbelt wrote: >> This used to be hidden behind CONFIG_MMAP_ALLOW_UNINITIALIZED, so >> userspace wouldn't actually ever see it be non-zero. While I could >> have kept hiding it, the man pages seem to indicate that >> MAP_UNINITIALIZED should be visible: >> >> mmap(2) >> MAP_UNINITIALIZED (since Linux 2.6.33) >> Don't clear anonymous pages. This flag is intended to improve >> performance on embedded devices. This flag is honored only if the >> kernel was configured with the CONFIG_MMAP_ALLOW_UNINITIALIZED >> option. Because of the security implications, that option is >> normally enabled only on embedded devices (i.e., devices where one >> has complete control of the contents of user memory). >> >> and since the only time it shows up in my /usr/include is in this >> header I believe this should have been visible to userspace (as >> non-zero, which wouldn't do anything when or'd into the flags) all >> along. > > Are you sure about "wouldn't do anything"? That was bad writing for me. I'd originally written something like "I believe this should have been visible to userspace all along", but then added the ()'s. I meant to say: * I think MAP_UNINITIALIZED should have been non-zero in userspace. * MAP_UNINITAILIZED was zero in userspace. * A zero MAP_UNINITIALIZED does nothing when OR'd in. > Suspiciously, 0x400 is also (1 << MAP_HUGE_SHIFT). I'm not sure if any > architecture has order-1 huge pages, but still looks like we have conflict > here. > > I think it's harmful to expose non-zero MAP_UNINITIALIZED to system which > potentially can handle multiple users. Or non-trivial user space in > general. This doesn't have MAP_UNINITIALIZED do anything by default, it just defines the flag the same way on all systems. I was under the impression that this just happened if I set MAP_UNINITIALIZED. Looking at MAP_HUGE_SHIFT it mmap.c, that's definitely why my mmap() test case ignored the set MAP_UNINITIALIZED on my PC. I'm going to make this #ifndef MAP_UNINITAILIZED #define MAP_UNINITAILIZED 0 #endif and then leave Xtensa's port alone. This is what Arnd suggested originally, sorry for the extra work! > Should we leave it at least under '#ifndef CONFIG_MMU'? I don't think it's > possible to have single ABI for MMU and MMU-less systems anyway. And we > can avoid conflict with MAP_HUGE_SHIFT this way. The whole goal here was to eliminate "#ifndef CONFIG_*" from the user-visible headers. This all started because I got bit by a very similar-looking bug (see patch #1), so I'd prefer not to go down that route. > P.S. MAP_UNINITIALIZED itself looks very broken to me. I probably need dig > mailing list on why it was allowed. > But that's other topic. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
