user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard W. <ri...@no...>]

Thomas,

Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
> It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c
> 
> Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?

Hmm, reading /proc/<pid of uml>/maps tells a different story on my host.
Did you check?

Thanks,
//richard

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas M. <th...@m3...>]

> Am 21.05.2017 um 23:28 schrieb Richard Weinberger <ric...@gm...>:
> 
> Thomas,
> 
>> On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer <th...@m3...> wrote:
>> This is actually a no-op as all read-only should be read-only in the ELF.
> 
> What problem does this patch fix? Or what is the purpose?

Hi,

It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c

Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?

> 
> -- 
> Thanks,
> //richard
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [RFC PATCH 1/7] um: Use printk instead of printf in make_uml_dir

[Richard W. <ric...@gm...>]

On Wed, May 17, 2017 at 10:35 AM, Thomas Meyer <th...@m3...> wrote:
>> On Tue, 16 May 2017 17:46:47 +0200
>> Thomas Meyer <th...@m3...> wrote:
>>
>>> Hi,
>>>
>>> as far as I understand everything under os-Linux should be OS specific
>>> and shouldn't rely on kernel functions.
>>
>> I see, but umid.c already uses many printk()s. So that policy
>> is not so clear now. For example, without this series,
>
> Yes you are right. I did write nonsense!
>
> I'm fine with all patches in series. Looks good to me!

Yeah, the policy is not so clear.
In theory os-Linux should contain no kernel stuff, but the printk()s do not
hurt, in most cases.

-- 
Thanks,
//richard

Re: [uml-devel] [PATCH] um: Don't build arch/x86/um/user-offsets.s with gcc plugins

[Richard W. <ric...@gm...>]

Thomas,

On Wed, May 17, 2017 at 10:41 PM, Thomas Meyer <th...@m3...> wrote:
> For some reasons I don't know users-offsets.s get's build before the
> gcc-plugins itself.

Can you please figure? I want to make sure that we really fix the root cause
and not just papering over a symptom.

-- 
Thanks,
//richard

Re: [uml-devel] [RFC][PATCH] um: Remove proc command from mconsole

[Al V. <vi...@Ze...>]

On Sun, May 21, 2017 at 11:19:03PM +0200, Richard Weinberger wrote:
> This feature is another abuser of set_fs().
> Reading proc files from the host side is a debugging feature
> with no security checks at all. The path is not sanitized, therefore
> any file could be read.

ITYM "any file on procfs"

> Let's get rid of it.

Wait a sec - guest is not protected against anyone with mconsole access
anyway.

> Unless I miss something is feature is not ABI since it was addeded for
> debugging UML only. It is broken wrt. security and abuses set_fs().
> I think we can just remove it.

IDGI.  set_fs() abuses are trivial - just switch to kernel_read() and
be done with that...

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard W. <ric...@gm...>]

Thomas,

On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer <th...@m3...> wrote:
> This is actually a no-op as all read-only should be read-only in the ELF.

What problem does this patch fix? Or what is the purpose?

-- 
Thanks,
//richard

[uml-devel] [RFC][PATCH] um: Remove proc command from mconsole

[Richard W. <ri...@no...>]

This feature is another abuser of set_fs().
Reading proc files from the host side is a debugging feature
with no security checks at all. The path is not sanitized, therefore
any file could be read.
Let's get rid of it.

Signed-off-by: Richard Weinberger <ri...@no...>
---
Hi!

Unless I miss something is feature is not ABI since it was addeded for
debugging UML only. It is broken wrt. security and abuses set_fs().
I think we can just remove it.

mconsole_proc anyone? ;)

Thanks,
//richard

---

 arch/um/drivers/mconsole_kern.c | 52 -----------------------------------------
 arch/um/drivers/mconsole_user.c |  1 -
 2 files changed, 53 deletions(-)

diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index af326fb6510d..b7fedf77f9f3 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -122,57 +122,6 @@ void mconsole_log(struct mc_request *req)
 	mconsole_reply(req, "", 0, 0);
 }
 
-void mconsole_proc(struct mc_request *req)
-{
-	struct vfsmount *mnt = task_active_pid_ns(current)->proc_mnt;
-	char *buf;
-	int len;
-	struct file *file;
-	int first_chunk = 1;
-	char *ptr = req->request.data;
-
-	ptr += strlen("proc");
-	ptr = skip_spaces(ptr);
-
-	file = file_open_root(mnt->mnt_root, mnt, ptr, O_RDONLY, 0);
-	if (IS_ERR(file)) {
-		mconsole_reply(req, "Failed to open file", 1, 0);
-		printk(KERN_ERR "open /proc/%s: %ld\n", ptr, PTR_ERR(file));
-		goto out;
-	}
-
-	buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
-	if (buf == NULL) {
-		mconsole_reply(req, "Failed to allocate buffer", 1, 0);
-		goto out_fput;
-	}
-
-	do {
-		loff_t pos = file->f_pos;
-		mm_segment_t old_fs = get_fs();
-		set_fs(KERNEL_DS);
-		len = vfs_read(file, buf, PAGE_SIZE - 1, &pos);
-		set_fs(old_fs);
-		file->f_pos = pos;
-		if (len < 0) {
-			mconsole_reply(req, "Read of file failed", 1, 0);
-			goto out_free;
-		}
-		/* Begin the file content on his own line. */
-		if (first_chunk) {
-			mconsole_reply(req, "\n", 0, 1);
-			first_chunk = 0;
-		}
-		buf[len] = '\0';
-		mconsole_reply(req, buf, 0, (len > 0));
-	} while (len > 0);
- out_free:
-	kfree(buf);
- out_fput:
-	fput(file);
- out: ;
-}
-
 #define UML_MCONSOLE_HELPTEXT \
 "Commands: \n\
     version - Get kernel version \n\
@@ -188,7 +137,6 @@ void mconsole_proc(struct mc_request *req)
     stop - pause the UML; it will do nothing until it receives a 'go' \n\
     go - continue the UML after a 'stop' \n\
     log <string> - make UML enter <string> into the kernel log\n\
-    proc <file> - returns the contents of the UML's /proc/<file>\n\
     stack <pid> - returns the stack of the specified pid\n\
 "
 
diff --git a/arch/um/drivers/mconsole_user.c b/arch/um/drivers/mconsole_user.c
index 99209826adb1..59d81d7ead58 100644
--- a/arch/um/drivers/mconsole_user.c
+++ b/arch/um/drivers/mconsole_user.c
@@ -30,7 +30,6 @@ static struct mconsole_command commands[] = {
 	{ "stop", mconsole_stop, MCONSOLE_PROC },
 	{ "go", mconsole_go, MCONSOLE_INTR },
 	{ "log", mconsole_log, MCONSOLE_INTR },
-	{ "proc", mconsole_proc, MCONSOLE_PROC },
 	{ "stack", mconsole_stack, MCONSOLE_INTR },
 };
 
-- 
2.7.3

[uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas M. <th...@m3...>]

This is actually a no-op as all read-only should be read-only in the ELF.

Signed-off-by: Thomas Meyer <th...@m3...>
---
 arch/um/Kconfig.common | 1 +
 arch/um/kernel/mem.c   | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 85f6dd2..061009b 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -2,6 +2,7 @@ config UML
 	bool
 	default y
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_STRICT_KERNEL_RWX
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index e7437ec..027ed03 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -168,7 +168,6 @@ void __init paging_init(void)
  * This can't do anything because nothing in the kernel image can be freed
  * since it's not in kernel physical memory.
  */
-
 void free_initmem(void)
 {
 }
@@ -238,3 +237,7 @@ void *uml_kmalloc(int size, int flags)
 {
 	return kmalloc(size, flags);
 }
+
+void mark_rodata_ro(void)
+{
+}

[uml-devel] [PATCH] um: Don't build arch/x86/um/user-offsets.s with gcc plugins

[Thomas M. <th...@m3...>]

For some reasons I don't know users-offsets.s get's build before the
gcc-plugins itself.
This patch fixes the problem by not using the gcc-plugins for building
user-offsets.s

make order example:
$ make ARCH=um
  CHK     include/generated/uapi/linux/version.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
  HOSTCC  scripts/unifdef
  CC      arch/x86/um/user-offsets.s
  CHK     include/generated/user_constants.h
  CHK     include/config/kernel.release
  CHK     include/generated/utsrelease.h
  HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o
  HOSTLLD -shared scripts/gcc-plugins/latent_entropy_plugin.so
  HOSTCXX -fPIC scripts/gcc-plugins/structleak_plugin.o
  HOSTLLD -shared scripts/gcc-plugins/structleak_plugin.so

Signed-off-by: Thomas Meyer <th...@m3...>
---
 arch/x86/um/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index 46cbbfe..d67c78a 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -36,7 +36,7 @@ subarch-$(CONFIG_MODULES) += ../kernel/module.o
 USER_OBJS := bugs_$(BITS).o ptrace_user.o fault.o
 
 extra-y += user-offsets.s
-$(obj)/user-offsets.s: c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) \
+$(obj)/user-offsets.s: c_flags = -Wp,-MD,$(depfile) $(filter-out $(GCC_PLUGINS_CFLAGS), $(USER_CFLAGS) ) \
 	-Iarch/x86/include/generated
 
 UNPROFILE_OBJS := stub_segv.o

Re: [uml-devel] [RFC PATCH 1/7] um: Use printk instead of printf in make_uml_dir

[Thomas M. <th...@m3...>]

> Am 17.05.2017 um 03:52 schrieb Masami Hiramatsu <mhi...@ke...>:
> 
> Hi Thomas,

Hi,

> 
> On Tue, 16 May 2017 17:46:47 +0200
> Thomas Meyer <th...@m3...> wrote:
> 
>> Hi,
>> 
>> as far as I understand everything under os-Linux should be OS specific 
>> and shouldn't rely on kernel functions.
> 
> I see, but umid.c already uses many printk()s. So that policy
> is not so clear now. For example, without this series,

Yes you are right. I did write nonsense!

I'm fine with all patches in series. Looks good to me!

> 
> $ grep printk -rw arch/um/os-Linux/ | wc -l
> 159
> 
> Thank you,
> 
>> 
>> @Richard: What do you think about this patch?
>> 
>> See: https://marc.info/?l=linux-kernel&m=149337493432407&w=2
>> 
>> with kind regards
>> thomas
> 
> 
> -- 
> Masami Hiramatsu <mhi...@ke...>

Re: [uml-devel] [RFC PATCH 1/7] um: Use printk instead of printf in make_uml_dir

[Thomas M. <th...@m3...>]

Hi,

as far as I understand everything under os-Linux should be OS specific 
and shouldn't rely on kernel functions.

@Richard: What do you think about this patch?

See: https://marc.info/?l=linux-kernel&m=149337493432407&w=2

with kind regards
thomas

[uml-devel] [PATCH 1/3] um: stub-data.h: remove superfluous include

[Thomas M. <th...@m3...>]

Signed-off-by: Thomas Meyer <th...@m3...>
---
 arch/um/include/shared/skas/stub-data.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/um/include/shared/skas/stub-data.h
b/arch/um/include/shared/skas/stub-data.h
index a9deece..13f404e 100644
--- a/arch/um/include/shared/skas/stub-data.h
+++ b/arch/um/include/shared/skas/stub-data.h
@@ -8,8 +8,6 @@
 #ifndef __STUB_DATA_H
 #define __STUB_DATA_H
 
-#include <time.h>
-
 struct stub_data {
 	unsigned long offset;
 	int fd;

[uml-devel] [PATCH 3/3] um: Add kerneldoc for userspace_tramp() and start_userspace()

[Thomas M. <th...@m3...>]

Also use correct function name spelling (stub_segv_handler) for better
grepping

Signed-off-by: Thomas Meyer <th...@m3...>
---
 arch/um/os-Linux/skas/process.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-
Linux/skas/process.c
index 03b3c4c..4530867 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -108,7 +108,7 @@ static void get_skas_faultinfo(int pid, struct
faultinfo *fi)
 	wait_stub_done(pid);
 
 	/*
-	 * faultinfo is prepared by the stub-segv-handler at start of
+	 * faultinfo is prepared by the stub_segv_handler at start of
 	 * the stub stack page. We just have to copy it.
 	 */
 	memcpy(fi, (void *)current_stub_stack(), sizeof(*fi));
@@ -175,6 +175,21 @@ static void handle_trap(int pid, struct
uml_pt_regs *regs,
 
 extern char __syscall_stub_start[];
 
+/**
+ * userspace_tramp() - userspace trampoline
+ * @stack:	pointer to the new userspace stack page, can be
NULL, if? FIXME:
+ *
+ * The userspace trampoline is used to setup a new userspace process
in start_userspace() after it was clone()'ed.
+ * This function will run on a temporary stack page.
+ * It ptrace()'es itself, then
+ * Two pages are mapped into the userspace address space:
+ * - STUB_CODE (with EXEC), which contains the skas stub code
+ * - STUB_DATA (with R/W), which contains a data page that is used to
transfer certain data between the UML userspace process and the UML
kernel.
+ * Also for the userspace process a SIGSEGV handler is installed to
catch pagefaults in the userspace process.
+ * And last the process stops itself to give control to the UML kernel
for this userspace process.
+ *
+ * Return: Always zero, otherwise the current userspace process is
ended with non null exit() call
+ */
 static int userspace_tramp(void *stack)
 {
 	void *addr;
@@ -236,12 +251,24 @@ static int userspace_tramp(void *stack)
 
 int userspace_pid[NR_CPUS];
 
+/**
+ * start_userspace() - prepare a new userspace process
+ * @stub_stack:	pointer to the stub stack. Can be NULL, if?
FIXME:
+ *
+ * Setups a new temporary stack page that is used while
userspace_tramp() runs
+ * Clones the kernel process into a new userspace process, with FDs
only.
+ *
+ * Return: When positive: the process id of the new userspace process,
+ *         when negative: an error number.
+ * FIXME: can PIDs become negative?!
+ */
 int start_userspace(unsigned long stub_stack)
 {
 	void *stack;
 	unsigned long sp;
 	int pid, status, n, flags, err;
 
+	/* setup a temporary stack page */
 	stack = mmap(NULL, UM_KERN_PAGE_SIZE,
 		     PROT_READ | PROT_WRITE | PROT_EXEC,
 		     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
@@ -252,10 +279,12 @@ int start_userspace(unsigned long stub_stack)
 		return err;
 	}
 
+	/* set stack pointer to the end of the stack page, so it can
grow downwards */
 	sp = (unsigned long) stack + UM_KERN_PAGE_SIZE - sizeof(void
*);
 
 	flags = CLONE_FILES | SIGCHLD;
 
+	/* clone into new userspace process */
 	pid = clone(userspace_tramp, (void *) sp, flags, (void *)
stub_stack);
 	if (pid < 0) {
 		err = -errno;

[uml-devel] [PATCH 2/3] um: Add kerneldoc for segv_handler

[Thomas M. <th...@m3...>]

Signed-off-by: Thomas Meyer <th...@m3...>
---
 arch/um/kernel/trap.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index 5915887..4e6fcb3 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -183,6 +183,16 @@ void fatal_sigsegv(void)
 	os_dump_core();
 }
 
+/**
+ * segv_handler() - the SIGSEGV handler
+ * @sig:	the signal number
+ * @unused_si:	the signal info struct; unused in this handler
+ * @regs:	the ptrace register information
+ *
+ * The handler first extracts the faultinfo from the UML ptrace regs
struct.
+ * If the userfault did not happen in an UML userspace process,
bad_segv is called.
+ * Otherwise the signal did happen in a cloned userspace process,
handle it.
+ */
 void segv_handler(int sig, struct siginfo *unused_si, struct
uml_pt_regs *regs)
 {
 	struct faultinfo * fi = UPT_FAULTINFO(regs);

[uml-devel] [GIT PULL] UML changes for v4.12-rc1

[Richard W. <ri...@no...>]

Linus,

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.12-rc1

for you to fetch changes up to ce4586063f1af780b1c6b7e344907e6f9c1ba59a:

  um: Add missing NR_CPUS include (2017-05-04 08:15:10 +0200)
----------------------------------------------------------------
This pull request contains updates for UML:
- No new stuff, just fixes

----------------------------------------------------------------

Masami Hiramatsu (1):
      um: Fix to call read_initrd after init_bootmem

Matthias Kaehlcke (1):
      um: Include kbuild.h instead of duplicating its macros

Nikola Kotur (1):
      um: Set number of CPUs

Richard Weinberger (3):
      um: Fix _print_addr()
      um: Fix PTRACE_POKEUSER on x86_64
      um: Add missing NR_CPUS include

 arch/um/Kconfig.common                     | 5 +++++
 arch/um/kernel/initrd.c                    | 4 +---
 arch/um/kernel/sysrq.c                     | 6 ++----
 arch/um/kernel/um_arch.c                   | 6 ++++++
 arch/um/os-Linux/skas/process.c            | 4 +---
 arch/x86/um/ptrace_64.c                    | 2 +-
 arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +--------
 7 files changed, 17 insertions(+), 19 deletions(-)

Re: [uml-devel] userfaultfd for UML userspace processes

[Anton I. <ant...@ko...>]

Am I right that this may be a route to avoid the full munmap we have presently upon exec or I am missing something.  If that is the case it will be well worth it.

On 13 May 2017 11:24:04 GMT+01:00, Thomas Meyer <th...@m3...> wrote:
>Am 13.05.2017 um 12:04 schrieb Richard Weinberger:
>> Thomas,
>
>Hi,
>
>> On Sat, May 13, 2017 at 10:10 AM, Thomas Meyer <th...@m3...>
>wrote:
>>>
>>> Hi,
>>>
>>> after looking into using userfaultfd for the userspace UML process
>>> page fault handling, I come to the conclusion that userfaultfd
>>> *cannot* be used for above goal as it only operates on mmaped memory
>>> areas.
>>> Am I missing something? What do you think about it?
>> 
>> See: https://lkml.org/lkml/2015/5/20/541
>Cool! Thanks for the hint. I don't follow LKML, so...
>
>But Andrea wrote:
>
>"Alternatively once we extend the handle_userfault to tmpfs you could
>map the page in two virtual mappings and track the faults in one
>mapping (where the tracked app runs) and read/write the page contents
>in the other mapping that isn't tracked by the userfault."
>
>I think this is now the case with 4.11, isn't it?
>
>As I understand this we must do the following:
>
>kernel process: Map a tmpfs region for each userspace process with 
>read/write.
>userspace process: Map the same tmpfs for the current process and 
>userfaultfd the whole address space, and give the userfaultfd fd to the
>
>kernel somehow and process the page fault there and fill/copy the 
>faulted page accordingly.
>
>so each userspace process would be backed by a tmpfs mmap region? sound
>
>complicated.
>
>with kind regards
>thomas
>
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>User-mode-linux-devel mailing list
>Use...@li...
>https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [uml-devel] userfaultfd for UML userspace processes

[Thomas M. <th...@m3...>]

Am 13.05.2017 um 12:04 schrieb Richard Weinberger:
> Thomas,

Hi,

> On Sat, May 13, 2017 at 10:10 AM, Thomas Meyer <th...@m3...> wrote:
>>
>> Hi,
>>
>> after looking into using userfaultfd for the userspace UML process
>> page fault handling, I come to the conclusion that userfaultfd
>> *cannot* be used for above goal as it only operates on mmaped memory
>> areas.
>> Am I missing something? What do you think about it?
> 
> See: https://lkml.org/lkml/2015/5/20/541
Cool! Thanks for the hint. I don't follow LKML, so...

But Andrea wrote:

"Alternatively once we extend the handle_userfault to tmpfs you could
map the page in two virtual mappings and track the faults in one
mapping (where the tracked app runs) and read/write the page contents
in the other mapping that isn't tracked by the userfault."

I think this is now the case with 4.11, isn't it?

As I understand this we must do the following:

kernel process: Map a tmpfs region for each userspace process with 
read/write.
userspace process: Map the same tmpfs for the current process and 
userfaultfd the whole address space, and give the userfaultfd fd to the 
kernel somehow and process the page fault there and fill/copy the 
faulted page accordingly.

so each userspace process would be backed by a tmpfs mmap region? sound 
complicated.

with kind regards
thomas

Re: [uml-devel] userfaultfd for UML userspace processes

[Richard W. <ric...@gm...>]

Thomas,

On Sat, May 13, 2017 at 10:10 AM, Thomas Meyer <th...@m3...> wrote:
>
> Hi,
>
> after looking into using userfaultfd for the userspace UML process
> page fault handling, I come to the conclusion that userfaultfd
> *cannot* be used for above goal as it only operates on mmaped memory
> areas.
> Am I missing something? What do you think about it?

See: https://lkml.org/lkml/2015/5/20/541

-- 
Thanks,
//richard

[uml-devel] userfaultfd for UML userspace processes

[Thomas M. <th...@m3...>]

Hi,

after looking into using userfaultfd for the userspace UML process  
page fault handling, I come to the conclusion that userfaultfd  
*cannot* be used for above goal as it only operates on mmaped memory  
areas.
Am I missing something? What do you think about it?

with kind regards
thomas

Re: [uml-devel] [uml-user] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 09.05.2017 um 19:25 schrieb Thomas Meyer:
>> IOW we write to 0xdeadbeef, catch the fault and fix it.
> 
> I get this:
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./segtest
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up

Meh, that's a show-stopper.
WSL does not provide a valid signal machine context...

Thanks,
//richard

Re: [uml-devel] [uml-user] UML on WSL

[Thomas M. <th...@m3...>]

Zitat von Richard Weinberger <ri...@no...>:

> Thomas,
>
> Am 09.05.2017 um 10:15 schrieb Thomas Meyer:
>> attached patch work correctly under Linux. But no change under WSL.  
>> As stated in the relevant GH issue, there seems to be far more road  
>> blockers to make UML work under WSL.
>>
>> With you patch I get under WSL:
>>
>> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
>> Core dump limits :
>>         soft - NONE
>>         hard - NONE
>> Checking that ptrace can change system call numbers...check_ptrace  
>> : failed to modify system call: Invalid Argument
>
> Okay, now it fails later.
> UML needs to cancel  syscalls on the host side, it does so by  
> turning them into a getpid() which has no side
> effects and, on non-ancient systems, by using PTRACE_SYSEMU.
> Let's figure whether they support PTRACE_SYSEMU, can you test the  
> attached patch?

okay, it now proceeds even more:

thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux mem=128m
Core dump limits :
         soft - NONE
         hard - NONE
Checking syscall emulation patch for ptrace...missing
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Adding 3665920 bytes to physical memory to account for exec-shield gap
kmsg_dump:
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<7>[    2.050000] SELinux:  Registering netfilter hooks
<6>[    2.050000] cryptomgr_test (23) used greatest stack depth: 6216  
bytes left
<6>[    2.050000] jitterentropy: Initialization failed with host not  
compliant with requirements: 2
<6>[    2.050000] io scheduler noop registered
<6>[    2.050000] io scheduler deadline registered (default)
<3>[    2.050000] Slab cache with size 1416 has lost its name
<3>[    2.050000] Slab cache with size 1304 has lost its name
<3>[    2.050000] Slab cache with size 464 has lost its name
<3>[    2.050000] Slab cache with size 1344 has lost its name
<3>[    2.050000] Slab cache with size 1784 has lost its name
<3>[    2.050000] Slab cache with size 800 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 1288 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 1040 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 2152 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 24 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 768 has lost its name
<3>[    2.050000] Slab cache with size 440 has lost its name
<3>[    2.050000] Slab cache with size 144 has lost its name
<3>[    2.050000] Slab cache with size 696 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 1824 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 352 has lost its name
<3>[    2.050000] Slab cache with size 2704 has lost its name
<3>[    2.050000] Slab cache with size 416 has lost its name
<3>[    2.050000] Slab cache with size 152 has lost its name
<3>[    2.050000] Slab cache with size 2112 has lost its name
<3>[    2.050000] Slab cache with size 216 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 272 has lost its name
<3>[    2.050000] Slab cache with size 120 has lost its name
<3>[    2.050000] Slab cache with size 6056 has lost its name
<3>[    2.050000] Slab cache with size 1208 has lost its name
<3>[    2.050000] Slab cache with size 136 has lost its name
<3>[    2.050000] Slab cache with size 328 has lost its name
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<3>[    2.050000] Slab cache with size 240 has lost its name
<3>[    2.050000] Slab cache with size 1416 has lost its name
<3>[    2.050000] Slab cache with size 1304 has lost its name
<3>[    2.050000] Slab cache with size 464 has lost its name
<3>[    2.050000] Slab cache with size 1344 has lost its name
<3>[    2.050000] Slab cache with size 1784 has lost its name
<3>[    2.050000] Slab cache with size 800 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 1288 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 1040 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 2152 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 24 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 768 has lost its name
<3>[    2.050000] Slab cache with size 440 has lost its name
<3>[    2.050000] Slab cache with size 144 has lost its name
<3>[    2.050000] Slab cache with size 696 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 1824 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 352 has lost its name
<3>[    2.050000] Slab cache with size 2704 has lost its name
<3>[    2.050000] Slab cache with size 416 has lost its name
<3>[    2.050000] Slab cache with size 152 has lost its name
<3>[    2.050000] Slab cache with size 2112 has lost its name
<3>[    2.050000] Slab cache with size 216 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 272 has lost its name
<3>[    2.050000] Slab cache with size 120 has lost its name
<3>[    2.050000] Slab cache with size 6056 has lost its name
<3>[    2.050000] Slab cache with size 1208 has lost its name
<3>[    2.050000] Slab cache with size 136 has lost its name
<3>[    2.050000] Slab cache with size 328 has lost its name
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<6>[    2.050000] io scheduler cfq registered
<6>[    2.050000] io scheduler mq-deadline registered
<4>[    2.050000]
<4>[    2.050000] Modules linked in:
<6>[    2.050000] Pid: 1, comm: swapper Not tainted  
4.11.0-00007-g594e0e4-dirty
<6>[    2.050000] RIP: 0033:[<00007f2e5b961eae>]
<6>[    2.050000] RSP: 0000000067c87c38  EFLAGS: 00010202
<6>[    2.050000] RAX: 0000000068842000 RBX: 0000000067dabae0 RCX:  
0000000000000001
<6>[    2.050000] RDX: 0000000000008000 RSI: 000000006884a000 RDI:  
0000000068842020
<6>[    2.050000] RBP: 0000000067c87c70 R08: 0000000067dabae7 R09:  
0000000067f73000
<6>[    2.050000] R10: 0000000000000000 R11: 0000000000000000 R12:  
0000000060040ae0
<6>[    2.050000] R13: 0000000000000000 R14: 00000000604e7e90 R15:  
0000000060886700
<0>[    2.050000] Kernel panic - not syncing: Segfault with no mm
<4>[    2.050000] CPU: 0 PID: 1 Comm: swapper Not tainted  
4.11.0-00007-g594e0e4-dirty #5
<6>[    2.050000] Stack:
<4>[    2.050000]  604e65b1 200000001 678085d8 67e35000
<4>[    2.050000]  678085c0 604e38b0 678085c0 67c87cf0
<4>[    2.050000]  604e3f02 00400000 678085c0 00000200
<6>[    2.050000] Call Trace:
<6>[    2.050000]  [<604e65b1>] ? check_partition+0x181/0x2c0
<6>[    2.050000]  [<604e38b0>] ? add_partition+0x0/0x5b0
<6>[    2.050000]  [<604e3f02>] rescan_partitions+0xa2/0x470
<6>[    2.050000]  [<604e1bd0>] ? get_gendisk+0x0/0x110
<6>[    2.050000]  [<60228842>] __blkdev_get+0x262/0x610
<6>[    2.050000]  [<601fe3cb>] ? unlock_new_inode+0x8b/0x90
<6>[    2.050000]  [<6027dba0>] ? sysfs_create_link+0x0/0x50
<6>[    2.050000]  [<6022907d>] blkdev_get+0x48d/0x5d0
<6>[    2.050000]  [<60513758>] ? refcount_dec_and_test+0x18/0x20
<6>[    2.050000]  [<604f6d1d>] ? kobject_put+0x5d/0x260
<6>[    2.050000]  [<6027dba0>] ? sysfs_create_link+0x0/0x50
<6>[    2.050000]  [<604e22a1>] device_add_disk+0x3b1/0x610
<6>[    2.050000]  [<604e2925>] ? alloc_disk+0x15/0x20
<6>[    2.050000]  [<604e1ef0>] ? device_add_disk+0x0/0x610
<6>[    2.050000]  [<60030d82>] 0x60030d82
<6>[    2.050000]  [<60030cb0>] ? 0x60030cb0
<6>[    2.050000]  [<60041520>] ? do_one_initcall+0x0/0x1a0
<6>[    2.050000]  [<600415da>] do_one_initcall+0xba/0x1a0
<6>[    2.050000]  [<600928f2>] ? parse_args+0x402/0x6f0
<6>[    2.050000]  [<60041520>] ? do_one_initcall+0x0/0x1a0
<6>[    2.050000]  [<60001fe3>] 0x60001fe3
<6>[    2.050000]  [<6015c8e6>] ? printk+0x0/0x94
<6>[    2.050000]  [<60835037>] kernel_init+0x27/0x150
<6>[    2.050000]  [<60043221>] new_thread_handler+0x81/0xb0
<6>[    2.050000]
Abgebrochen (Speicherabzug geschrieben)

>
> Also please test segv1.c, it tests whether WSL allows us to handle  
> page faults in userspace.
> It should output this:
> SIGSEGV at 0xdeadbeef, fixing up
> x=3, &x=0xdeadbeef
>
> IOW we write to 0xdeadbeef, catch the fault and fix it.

I get this:
thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./segtest
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
[...]

>
> Thanks,
> //richard

[uml-devel] [PATCH] um: Document change_sig and switch to bool type

[Thomas M. <th...@m3...>]

Re: [uml-devel] [uml-user] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 09.05.2017 um 10:15 schrieb Thomas Meyer:
> attached patch work correctly under Linux. But no change under WSL. As stated in the relevant GH issue, there seems to be far more road blockers to make UML work under WSL.
> 
> With you patch I get under WSL:
> 
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
> Core dump limits :
>         soft - NONE
>         hard - NONE
> Checking that ptrace can change system call numbers...check_ptrace : failed to modify system call: Invalid Argument

Okay, now it fails later.
UML needs to cancel  syscalls on the host side, it does so by turning them into a getpid() which has no side
effects and, on non-ancient systems, by using PTRACE_SYSEMU.
Let's figure whether they support PTRACE_SYSEMU, can you test the attached patch?

Also please test segv1.c, it tests whether WSL allows us to handle page faults in userspace.
It should output this:
SIGSEGV at 0xdeadbeef, fixing up
x=3, &x=0xdeadbeef

IOW we write to 0xdeadbeef, catch the fault and fix it.

Thanks,
//richard

Re: [uml-devel] [uml-user] UML on WSL

[Thomas M. <th...@m3...>]

Zitat von Richard Weinberger <ri...@no...>:

> Thomas,
>
> Can you please give the attached patch a try?

Hi,

attached patch work correctly under Linux. But no change under WSL. As  
stated in the relevant GH issue, there seems to be far more road  
blockers to make UML work under WSL.

With you patch I get under WSL:

thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
Core dump limits :
         soft - NONE
         hard - NONE
Checking that ptrace can change system call numbers...check_ptrace :  
failed to modify system call: Invalid Argument

>
> Thanks,
> //richard

[uml-devel] Fwd: DQL and TCQ_F_CAN_BYPASS destroy performance under virtualizaiton (Was: "Re: net_sched strange in 4.11")

[Anton I. <ant...@ko...>]

Once I get some ideas on how to sort out THIS (forwarded) mess I will 
submit the vector drivers and the epoll controller they depend on.

I got the RX to > 1.7Gbit (for the reference, kvm on same machine just 
about manages 1.4 using tap). I cannot get TX done because of the 
wonderful bufferbloat optimizations in the recent kernels.

As usually, the glorious quest against too many buffers is doing more 
harm than good.

I can of course just #ifdef CONFIG_UML the relevant bits in the packet 
scheduler, but this is vandalism. We should not be doing it and it 
affects kvm as well.

A.



-------- Forwarded Message --------
Subject: 	DQL and TCQ_F_CAN_BYPASS destroy performance under 
virtualizaiton (Was: "Re: net_sched strange in 4.11")
Date: 	Tue, 9 May 2017 08:46:46 +0100
From: 	Anton Ivanov <ant...@ca...>
Organization: 	Cambridge Greys Limited
To: 	David S. Miller <da...@da...>
CC: 	ne...@vg..., Stefan Hajnoczi <ste...@re...>



I have figured it out. Two issues.

1) skb->xmit_more is hardly ever set under virtualization because the
qdisc is usually bypassed because of TCQ_F_CAN_BYPASS. Once
TCQ_F_CAN_BYPASS is set a virtual NIC driver is not likely see
skb->xmit_more (this answers my "how does this work at all" question).

2) If that flag is turned off (I patched sched_generic to turn it off in
pfifo_fast while testing), DQL keeps xmit_more from being set. If the
driver is not DQL enabled xmit_more is never ever set. If the driver is
DQL enabled the queue is adjusted to ensure xmit_more stops happening
within 10-15 xmit cycles.

That is plain *wrong* for virtual NICs - virtio, emulated NICs, etc.
There, the BIG cost is telling the hypervisor that it needs to "kick"
the packets. The cost of putting them into the vNIC buffers is
negligible. You want xmit_more to happen - it makes between 50% and 300%
(depending on vNIC design) difference. If there is no xmit_more the vNIC
will immediately "kick" the hypervisor and try to signal that  the
packet needs to move straight away (as for example in virtio_net).

In addition to that, the perceived line rate is proportional to this
cost, so I am not sure that the current dql math holds. In fact, I think
it does not - it is trying to adjust something which influences the
perceived line rate.

So - how do we turn BOTH bypass and DQL adjustment while under
virtualization and set them to be "always qdisc" + "always xmit_more
allowed"

A.

P.S. Cc-ing virtio maintainer

A.


On 08/05/17 08:15, Anton Ivanov wrote:
> Hi all,
>
> I was revising some of my old work for UML to prepare it for
> submission and I noticed that skb->xmit_more does not seem to be set
> any more.
>
> I traced the issue as far as net/sched/sched_generic.c
>
> try_bulk_dequeue_skb() is never invoked (the drivers I am working on
> are dql enabled so that is not the problem).
>
> More interestingly, if I put a breakpoint and debug output into
> dequeue_skb() around line 147 - right before the bulk: tag that skb
> there is always NULL. ???
>
> Similarly, debug in pfifo_fast_dequeue shows only NULLs being
> dequeued. Again - ???
>
> First and foremost, I apologize for the silly question, but how can
> this work at all? I see the skbs showing up at the driver level, why
> are NULLs being returned at qdisc dequeue and where do the skbs at the
> driver level come from?
>
> Second, where should I look to fix it?
>
> A.
>


-- 
Anton R. Ivanov

Cambridge Greys Limited, England company No 10273661
http://www.cambridgegreys.com/