Hi Benjamin and Johannes,
On Mon, Feb 10, 2025 at 05:09:25PM +0100, Benjamin Berg wrote:
> From: Johannes Berg
>
> Mark read-only data actually read-only (simple mprotect), and
> to be able to test it also implement _nofault accesses. This
> works by setting up a new "segv_continue" pointer in c
rue kernel tasks, but we could do this for a
> userspace task, so the current->thread.segv_continue logic must
> be lifted out of the mm==NULL check.
>
> Finally, while looking at this, put a barrier() so the NULL
> assignment to thread.segv_continue cannot be reorder before
> the
On Thu, Apr 03, 2025 at 08:20:23AM +0200, Benjamin Berg wrote:
> Hi Nathan,
>
> oops, that is a little logic bug in the code. When we are coming from
> userspace, we may be running as part of a user task and have an mm. And
> then the new "current->pagefault_disabled" logic is skipped. So when
> p
; On 10/3/24 6:29 PM, Nathan Chancellor wrote:
> > I seem to have narrowed down it to a few different configurations on top
> > of x86_64_defconfig but I will include the full bad configuration as an
> > attachment just in case anything else is relevant.
> >
On Fri, Nov 22, 2024 at 01:27:03PM +0100, Peter Zijlstra wrote:
> On Thu, Oct 03, 2024 at 04:29:38PM -0700, Nathan Chancellor wrote:
>
> > $ /usr/bin/time -v make -skj"$(nproc)" ARCH=x86_64 LLVM=1 mrproper
> > {def,amd_mem_encrypt.,fortify_source.,llvm_cov.}config b
ed, I think we are all good here.
Tested-by: Nathan Chancellor
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 3407efc26528..243843e44e89 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -124
Hi Mike,
On Wed, Oct 23, 2024 at 07:27:09PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> When module text memory will be allocated with ROX permissions, the
> memory at the actual address where the module will live will contain
> invalid instructions and there will be a wr
less chance of any
> conflicts.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202410242238.sxhs2kq4-...@intel.com/
> Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
> Signed-off-by: Johannes Berg
Review
Hi Mike,
On Wed, Oct 16, 2024 at 03:24:22PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> When module text memory will be allocated with ROX permissions, the
> memory at the actual address where the module will live will contain
> invalid instructions and there will be a wr
'--nmagic', so prefix it with '-Wl,'.
Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
Signed-off-by: Nathan Chancellor
---
arch/um/kernel/skas/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/
This series fixes a couple of issues I see when building ARCH=um
defconfig with LLVM=1 after commit 32e8eaf263d9 ("um: use execveat to
create userspace MMs") in -next.
This passes my basic build and boot testing with both GCC and clang.
---
Nathan Chancellor (2):
um: Fix passi
reate userspace MMs")
Signed-off-by: Nathan Chancellor
---
arch/um/kernel/skas/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/um/kernel/skas/Makefile b/arch/um/kernel/skas/Makefile
index
f93db893b8236cf805edd01b41501d51dd8f0a35..f6a219074772283f3c6c6d8d6ccaa8a1cfc24e33
1
Hi Benjamin,
On Thu, Sep 19, 2024 at 02:45:03PM +0200, Benjamin Berg wrote:
...
> diff --git a/arch/um/kernel/skas/Makefile b/arch/um/kernel/skas/Makefile
> index 6f86d53e3d69..fbb61968055f 100644
> --- a/arch/um/kernel/skas/Makefile
> +++ b/arch/um/kernel/skas/Makefile
> @@ -3,14 +3,43 @@
> # Co
On Fri, Oct 11, 2024 at 03:58:04PM +0300, Mike Rapoport wrote:
> I overlooked how cfi_*_callers routines update addr.
> This patch should fix it:
Thanks, can confirm. My boot is working again and LKDTM's
CFI_FORWARD_PROTO test properly fails.
> diff --git a/arch/x86/kernel/alternative.c b/arch/x8
Hi Mike,
On Wed, Oct 09, 2024 at 09:08:14PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> When module text memory will be allocated with ROX permissions, the
> memory at the actual address where the module will live will contain
> invalid instructions and there will be a wr
Hi Wentao,
I took this series for a spin on next-20241001 with LLVM 19.1.0 using a
distribution configuration tailored for a local development VM using
QEMU. You'll notice on the rebase for 6.12-rc1 but there is a small
conflict in kernel/Makefile due to commit 0e8b67982b48 ("mm: move
kernel/numa.
49/sej.1994.0025 [2]
> Link:
> https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798
> [3]
> Link:
> https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#mc-dc-instrumentation
> [4]
Thank you for using this link format :)
> Signed-off-
>
> Signed-off-by: Wentao Zhang
> Reviewed-by: Chuck Wolber
> Tested-by: Chuck Wolber
Reviewed-by: Nathan Chancellor
> ---
> arch/x86/Kconfig | 2 ++
> arch/x86/kernel/vmlinux.lds.S | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git
ed with gcov as well. See c390c452ebeb ("crypto:
> x86/curve25519 - disable gcov").
>
> Signed-off-by: Wentao Zhang
> Reviewed-by: Chuck Wolber
> Tested-by: Chuck Wolber
Reviewed-by: Nathan Chancellor
> ---
> arch/x86/crypto/Makefile | 3 ++-
> 1 file changed
heckpatch.pl (I didn't check). The Kbuild bits look good as
well, they match the gcov implementation.
As most of my comments are more nits than anything else, feel free to
carry this over:
Reviewed-by: Nathan Chancellor
> diff --git a/kernel/llvm-cov/Kconfig b/kernel/llvm-cov/Kconfig
On Mon, Aug 19, 2024 at 12:29:34PM -0700, Linus Torvalds wrote:
> On Mon, 19 Aug 2024 at 11:53, Nathan Chancellor wrote:
> >
> >
> > Modules linked in:
> > Pid: 24, comm: mount Not tainted 6.11.0-rc4-next-20240819
> > RIP: 0033:0x68006f6c
> > RSP: 000
Hi Michael,
On Mon, Aug 12, 2024 at 06:26:02PM +1000, Michael Ellerman wrote:
> Add an optional close() callback to struct vm_special_mapping. It will
> be used, by powerpc at least, to handle unmapping of the VDSO.
>
> Although support for unmapping the VDSO was initially added
> for CRIU[1], it
On Tue, Jul 16, 2024 at 05:41:14PM -0700, Linus Torvalds wrote:
> On Tue, 16 Jul 2024 at 16:18, Linus Torvalds
> wrote:
> >
> > Hmm... Does this simple (whitespace-damaged) patch fix it for you?
>
> I verified that it seemed to generate the right (generic) code, so
> I've committed this fix. I di
Hi Linus,
Our continuous integration notices a crash when booting User Mode Linux
after commit e3c92e81711d ("runtime constants: add x86 architecture
support"), which I've distilled down to:
$ make -skj"$(nproc)" ARCH=um CROSS_COMPILE=x86_64-linux- defconfig linux
$ curl -LSs
https://github.com
verse Christmas
tree order intact.
Fixes: cd140ce9f611 ("hostfs: convert hostfs to use the new mount API")
Signed-off-by: Nathan Chancellor
---
fs/hostfs/hostfs_kern.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
index
Hi David,
Just a fly by comment on style, I don't have much to say content :)
On Wed, Jun 05, 2024 at 06:40:50AM +0800, David Gow wrote:
> At present, Rust in the kernel only supports 64-bit x86, so UML has
> followed suit. However, it's significantly easier to support 32-bit i386
> on UML than o
with '-mcmodel=large',
which ARCH=um uses. These sections should be handled just as '.text'
and '.text.*' are, so add them to TEXT_SECTIONS.
Cc: sta...@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1981
Link:
https://github.com/llvm/llvm-pr
e' with CONFIG_LD_SCRIPT_DYN=y, so that it is enabled with all
compilers that support this. Furthermore, using gcc-min-version can help
turn this back into
LINK-$(CONFIG_LD_SCRIPT_DYN) += -no-pie
when the minimum version of GCC is bumped past 6.1.0.
Cc: sta...@vger.kernel.org
Closes: http
ntation fault
with modpost.
I have tested these patches with all supported versions of clang,
noticing no regressions.
---
Nathan Chancellor (2):
um: Fix adding '-no-pie' for clang
modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
arch/um/Makefil
On Wed, Dec 06, 2023 at 07:19:35AM +, Anton Ivanov wrote:
>
>
> On 05/12/2023 17:53, Nathan Chancellor wrote:
> > Ping? I would like to turn this warning on for W=1 and the kbuild test
> > robot flagged this instance. If the UML folks don't want to carry it,
> &g
002-enable-wincompatible-function-pointer-types-strict-w-1-v1-1-808ab955d...@kernel.org
---
Nathan Chancellor (2):
um: net: Fix return type of uml_net_start_xmit()
kbuild: Enable -Wincompatible-function-pointer-types-strict in W=1
arch/um/drivers/net_kern.c | 2 +-
scripts/Makefile.extrawar
currently implement support for kCFI, it could in the future, which
means this warning becomes a fatal CFI failure at run time.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310031340.v1vph207-...@intel.com/
Acked-by: Anton Ivanov
Signed-off-by: Nathan Chan
ction-pointer-types-strict-w-1-v1-1-808ab955d...@kernel.org/
On Tue, Oct 03, 2023 at 11:35:53AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to
On Mon, Oct 09, 2023 at 09:42:10PM +0900, Masahiro Yamada wrote:
> Now that vdso_install does not depend on any in-tree build artifact,
> it no longer invokes a compiler, making no-compiler-targets the same
> as no-sync-config-targets.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile | 13
currently implement support for kCFI, it could in the future, which
means this warning becomes a fatal CFI failure at run time.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310031340.v1vph207-...@intel.com/
Signed-off-by: Nathan Chancellor
---
arch/um/drive
Suggested-by: Masahiro Yamada
> Suggested-by: Alexei Starovoitov
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
>
> Changes v1 -> v2:
> https://lore.kernel.org/linux-kbuild/20220819170053.2686006-1-ndesaulni...@google.com/
> * Pick up Boris' a
On Fri, May 20, 2022 at 07:18:28PM +0200, Johannes Berg wrote:
> On Fri, 2022-05-20 at 08:55 -0700, Nathan Chancellor wrote:
> > On Fri, May 20, 2022 at 08:08:01AM +0200, Thorsten Leemhuis wrote:
> > > On 11.04.22 20:45, Richard Weinberger wrote:
> > >
On Fri, May 20, 2022 at 08:08:01AM +0200, Thorsten Leemhuis wrote:
> On 11.04.22 20:45, Richard Weinberger wrote:
> > - Ursprüngliche Mail -
> >> Von: "Nathan Chancellor"
> >> I attempted to print out the error code but it seems like there is no
>
ment error
I merged this series into mainline and tested an Arch Linux
x86_64 configuration and Fedora aarch64 configuration with ThinLTO and
saw no new warnings or issues. Modules loaded just fine in QEMU for Arch
Linux and I did not notice any boot issues or warnings.
Tested-by: Nathan Chancellor
Che
nto most of them and lack
> > knowledge about most of the areas they concern. I thus unfortunately
> > will sometimes get things wrong or miss something important. I hope
> > that's not the case here; if you think it is, don't hesitate to tell me
> &
On Thu, Mar 31, 2022 at 09:11:12AM +0200, Sedat Dilek wrote:
> On Thu, Mar 31, 2022 at 5:27 AM Nathan Chancellor wrote:
> >
> > This flag is specific to clang, where it is only used by the 32-bit and
> > 64-bit ARM backends. In certain situations, the presence of this
ned-off-by: Nathan Chancellor
---
arch/um/Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/arch/um/Makefile b/arch/um/Makefile
index 320b09cd513c..f2fe63bfd819 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -75,10 +75,6 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(pa
r/20220322173547.677760-1-nat...@kernel.org/
[3]:
https://github.com/llvm/llvm-project/commit/863bfdbfb446adaef767ff514d1f2ffb5d489562
Nathan Chancellor (2):
kbuild: Remove '-mno-global-merge'
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
Makefile
f the removal of this
flag, it can be added back under arch/arm{,64}/Makefile to avoid
warnings on other architectures.
Signed-off-by: Nathan Chancellor
---
Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/Makefile b/Makefile
index daeb5c88b50b..f2723d9bfca4 100644
--- a/Make
On Sat, Mar 26, 2022 at 12:29:55PM +0900, Masahiro Yamada wrote:
> On Wed, Mar 23, 2022 at 2:39 AM Nathan Chancellor wrote:
> >
> > When booting a clang compiled UML kernel, the kernel panics when trying
> > to run init:
> >
> > wait_stub_done : failed to
Hello,
On Sat, May 08, 2021 at 11:22:39AM +0800, Zhen Lei wrote:
> Fix to return a negative error code from the error handling case instead
> of 0, as done elsewhere in this function.
>
> Fixes: 89df6bfc0405 ("uml: DEBUG_SHIRQ fixes")
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
> ---
>
USER_CFLAGS properly, which resolves the boot issue noted above.
Fixes: 6580c5c18fb3 ("um: clang: Strip out -mno-global-merge from USER_CFLAGS")
Signed-off-by: Nathan Chancellor
---
arch/um/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch
On Thu, Mar 03, 2022 at 10:04:28AM -0800, Kees Cook wrote:
> On Thu, Mar 03, 2022 at 10:30:47AM -0700, Nathan Chancellor wrote:
> > Hi David,
> >
> > On Thu, Mar 03, 2022 at 05:06:42PM +0800, David Gow wrote:
> > > The things built with USER_CFLAGS don't seem
ing regular kernel builds, maybe something about how UML
objects are compiled exposes this?
Regardless, I would definitely like to clean up this instance of the
warning because I would like to make this warning a hard error so that
we do not get cryptic cc-option failures:
https://github.com/C
49 matches
Mail list logo
