This is a series of patches of nommu arch addition to UML. It would
be nice to ask comments/opinions on this.
There are several limitations/issues which we already found; here is
the list of those issues.
- prompt configured with /etc/profile is broken (variables are not
expanded, ${HOSTNAME%%
This helper can be used to set the parent-death signal of the calling
process to SIGKILL to ensure that the process will be killed if the
UML kernel dies unexpectedly without proper cleanup. This helper will
be used in the follow-up patches.
Signed-off-by: Tiwei Bie
---
arch/um/include/shared/os
This commit adds a mechanism to hook syscalls for unmodified userspace
programs used under UML in !MMU mode. The mechanism, called zpoline,
translates syscall/sysenter instructions with `call *%rax`, which can be
processed by a trampoline code also installed upon an initcall during
boot. The transl
This commit introduces an entry point of syscall interface for !MMU
mode. It uses an entry function, __kernel_vsyscall, a kernel-wide global
symbol accessible from any locations.
Although it isn't in the scope of this commit, it can be also exposed
via vdso image which is directly accessible from
From: Johannes Berg
CONFIG_GCOV is special and only in UML since it builds the
kernel with a "userspace" option. This is fine, but the stub
is even more special and not really a full userspace process,
so it then fails to link as reported.
For good measure, also remove the GPROF options, even th
On Thu, 2024-10-24 at 22:28 +0800, Tiwei Bie wrote:
> The ubd io and write_sigio threads/processes may leak e.g. when
> the main process is killed by "kill -9". Fix it by setting the
> parent-death signal for them.
>
I always used killall, but yeah, good idea, thanks!
johannes
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> Since ptrace facility isn't used under !MMU of UML, there is different
> code path to invoke proceeses/threads; on an entry to the syscall
typo: processes
> /* Called magically, see new_thread_handler above */
> static void fork_handler(
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> This commit adds a mechanism to hook syscalls for unmodified userspace
> programs used under UML in !MMU mode. The mechanism, called zpoline,
> translates syscall/sysenter instructions with `call *%rax`, which can be
> processed by a trampol
On Fri, 25 Oct 2024 18:19:25 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > This commit adds a mechanism to hook syscalls for unmodified userspace
> > programs used under UML in !MMU mode. The mechanism, called zpoline,
> > translates syscall/sysenter
On Fri, 25 Oct 2024 18:14:19 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> >
> > +++ b/arch/x86/um/do_syscall_64.c
> > @@ -0,0 +1,42 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#in
On Fri, 25 Oct 2024 18:29:07 +0900,
Johannes Berg wrote:
>
>
> > oom:
> > - printk(KERN_ERR "Cannot allocate vdso\n");
> > + pr_err("Cannot allocate vdso");
>
> kind of unrelated change
thanks, will fix it.
-- Hajime
On Fri, 25 Oct 2024 18:28:01 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> >
> > +static void sigill(int sig, siginfo_t *si, void *ctx_void)
> > +{
> > + longjmp(jmpbuf, 1);
> > +}
>
> Should this code use sigsetjmp/siglongjmp?
the code is referr
On Fri, 2024-10-25 at 22:05 +0900, Hajime Tazaki wrote:
> On Fri, 25 Oct 2024 18:33:06 +0900,
> Johannes Berg wrote:
> >
> > On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > >
> > > config MMU
> > > - bool
> > > + bool "MMU-based Paged Memory Management Support"
> > > default y
> >
Hello Johannes,
On Fri, 25 Oct 2024 17:56:51 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> >
> > +#ifndef CONFIG_MMU
> > +#include
>
> Not sure that makes so much sense in the middle of the file, no harm
> always having it?
agree.
> > +static inl
On Fri, 2024-10-25 at 21:55 +0900, Hajime Tazaki wrote:
> >
> > Should that really do _nothing_? Perhaps it's not called at all in no-
> > MMU, but then you don't need it, but otherwise it seems it should do
> > something even if it's just panic()?
>
> it is called also in !MMU. I'll think to fi
On Fri, 2024-10-25 at 21:58 +0900, Hajime Tazaki wrote:
>
> > > + if (down_write_killable(&mm->mmap_lock)) {
> > > + err = -EINTR;
> > > + return err;
> >
> > ?
>
> the lock isn't needed actually so, will remove it.
Oh, I was just looking at the weird handling of the err variabl
On Fri, 2024-10-25 at 22:27 +0900, Hajime Tazaki wrote:
>
> On Fri, 25 Oct 2024 18:28:01 +0900,
> Johannes Berg wrote:
> >
> > On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > >
> > > +static void sigill(int sig, siginfo_t *si, void *ctx_void)
> > > +{
> > > + longjmp(jmpbuf, 1);
> >
On Fri, 25 Oct 2024 18:33:06 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> >
> > config MMU
> > - bool
> > + bool "MMU-based Paged Memory Management Support"
> > default y
>
> "if !64bit" or something
not sure if I understand correctly but
The write_sigio thread is not really a traditional thread. Set
the parent-death signal for it to ensure that it will be killed
if the UML kernel dies unexpectedly without proper cleanup.
Signed-off-by: Tiwei Bie
---
arch/um/os-Linux/sigio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arc
On Fri, 25 Oct 2024 18:11:01 +0900,
Johannes Berg wrote:
>
> (I should say, I'm still reading through this, and haven't formed an
> overall opinion. Just nitpicking on the details as I see them for now)
thanks anyway. looking forward to any opinions.
> > +#endif
> > +
> >
> > #include
>
On Fri, 25 Oct 2024 18:22:29 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > Since ptrace facility isn't used under !MMU of UML, there is different
> > code path to invoke proceeses/threads; on an entry to the syscall
>
> typo: processes
thanks. (I t
On Fri, 25 Oct 2024 18:30:41 +0900,
Johannes Berg wrote:
>
> On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> > This commit updates the behavior of signal handling under !MMU
> > environment. 1) the stack preparation for the signal handlers and
> > 2) retoration of stack after rt_sigret
On Wed, Oct 23, 2024, at 05:36, Christoph Hellwig wrote:
> page_to_phys is duplicated by all architectures, and from some strange
> reason placed in where it doesn't fit at all.
>
> phys_to_page is only provided by a few architectures despite having a lot
> of open coded users.
>
> Provide gene
umid is already generated during make_umid_init __initcall so there is
no need to allocate UMID_LEN bytes to accommodate the max possible name
for the umid segment of the filepath
This patch replaces UMID_LEN occurences in which it's redundant
Signed-off-by: Paulo Miguel Almeida
---
arch/um/os-
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> config MMU
> - bool
> + bool "MMU-based Paged Memory Management Support"
> default y
"if !64bit" or something
> config UML_DMA_EMULATION
> @@ -187,8 +190,14 @@ config MAGIC_SYSRQ
> The keys are documented in
>
free_pages() performs a parameter null check inside
therefore remove double zero check here.
Signed-off-by: Shaojie Dong
---
Changes in v5:
- EDITME: fit the git setup and simplify commit description
- Link to v4:
https://lore.kernel.org/r/20241025-upstream_branch-v4-1-8967d1b6e...@quicinc.com
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +#ifndef CONFIG_MMU
> +#include
Not sure that makes so much sense in the middle of the file, no harm
always having it?
>
> +static inline const struct user_regset_view *task_user_regset_view(
> + struct task_struct *task)
What hap
(I should say, I'm still reading through this, and haven't formed an
overall opinion. Just nitpicking on the details as I see them for now)
> +#endif
> +
>
> #include
extra newline
> /* tlb.c */
> +#ifdef CONFIG_MMU
> extern void report_enomem(void);
> +#else
> +static inline void report_e
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +++ b/arch/x86/um/do_syscall_64.c
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifndef CONFIG_MMU
This seems unnecessary, you don't build the file w
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
>
> +static void sigill(int sig, siginfo_t *si, void *ctx_void)
> +{
> + longjmp(jmpbuf, 1);
> +}
Should this code use sigsetjmp/siglongjmp?
> +int os_has_fsgsbase(void)
> +{
> + return has_fsgsbase;
> +}
Why should this be a funct
> oom:
> - printk(KERN_ERR "Cannot allocate vdso\n");
> + pr_err("Cannot allocate vdso");
kind of unrelated change
johannes
On Thu, 2024-10-24 at 21:09 +0900, Hajime Tazaki wrote:
> This commit updates the behavior of signal handling under !MMU
> environment. 1) the stack preparation for the signal handlers and
> 2) retoration of stack after rt_sigreturn(2) syscall. Those are
typo: restoration
> @@ -562,6 +574,20 @@
32 matches
Mail list logo
