Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(19) |
Feb
(11) |
Mar
(56) |
Apr
(31) |
May
(37) |
Jun
(21) |
Jul
(30) |
Aug
(31) |
Sep
(25) |
Oct
(60) |
Nov
(28) |
Dec
(57) |
2001 |
Jan
(47) |
Feb
(119) |
Mar
(279) |
Apr
(198) |
May
(336) |
Jun
(201) |
Jul
(136) |
Aug
(123) |
Sep
(123) |
Oct
(185) |
Nov
(66) |
Dec
(97) |
2002 |
Jan
(318) |
Feb
(101) |
Mar
(167) |
Apr
(233) |
May
(249) |
Jun
(134) |
Jul
(195) |
Aug
(99) |
Sep
(278) |
Oct
(435) |
Nov
(326) |
Dec
(325) |
2003 |
Jan
(214) |
Feb
(309) |
Mar
(142) |
Apr
(141) |
May
(210) |
Jun
(86) |
Jul
(133) |
Aug
(218) |
Sep
(315) |
Oct
(152) |
Nov
(162) |
Dec
(288) |
2004 |
Jan
(277) |
Feb
(267) |
Mar
(182) |
Apr
(168) |
May
(254) |
Jun
(131) |
Jul
(168) |
Aug
(177) |
Sep
(262) |
Oct
(309) |
Nov
(262) |
Dec
(255) |
2005 |
Jan
(258) |
Feb
(169) |
Mar
(282) |
Apr
(208) |
May
(262) |
Jun
(187) |
Jul
(207) |
Aug
(171) |
Sep
(283) |
Oct
(216) |
Nov
(307) |
Dec
(107) |
2006 |
Jan
(207) |
Feb
(82) |
Mar
(192) |
Apr
(165) |
May
(121) |
Jun
(108) |
Jul
(120) |
Aug
(126) |
Sep
(101) |
Oct
(216) |
Nov
(95) |
Dec
(125) |
2007 |
Jan
(176) |
Feb
(117) |
Mar
(240) |
Apr
(120) |
May
(81) |
Jun
(82) |
Jul
(62) |
Aug
(120) |
Sep
(103) |
Oct
(109) |
Nov
(181) |
Dec
(87) |
2008 |
Jan
(145) |
Feb
(69) |
Mar
(31) |
Apr
(98) |
May
(91) |
Jun
(43) |
Jul
(68) |
Aug
(135) |
Sep
(48) |
Oct
(18) |
Nov
(29) |
Dec
(16) |
2009 |
Jan
(26) |
Feb
(15) |
Mar
(83) |
Apr
(39) |
May
(23) |
Jun
(35) |
Jul
(11) |
Aug
(3) |
Sep
(11) |
Oct
(2) |
Nov
(28) |
Dec
(8) |
2010 |
Jan
(4) |
Feb
(40) |
Mar
(4) |
Apr
(46) |
May
(35) |
Jun
(46) |
Jul
(10) |
Aug
(4) |
Sep
(50) |
Oct
(70) |
Nov
(31) |
Dec
(24) |
2011 |
Jan
(17) |
Feb
(8) |
Mar
(35) |
Apr
(50) |
May
(75) |
Jun
(55) |
Jul
(72) |
Aug
(272) |
Sep
(10) |
Oct
(9) |
Nov
(11) |
Dec
(15) |
2012 |
Jan
(36) |
Feb
(49) |
Mar
(54) |
Apr
(47) |
May
(8) |
Jun
(82) |
Jul
(20) |
Aug
(50) |
Sep
(51) |
Oct
(20) |
Nov
(10) |
Dec
(25) |
2013 |
Jan
(34) |
Feb
(4) |
Mar
(24) |
Apr
(40) |
May
(101) |
Jun
(30) |
Jul
(55) |
Aug
(84) |
Sep
(53) |
Oct
(49) |
Nov
(61) |
Dec
(36) |
2014 |
Jan
(26) |
Feb
(22) |
Mar
(30) |
Apr
(4) |
May
(43) |
Jun
(33) |
Jul
(44) |
Aug
(61) |
Sep
(46) |
Oct
(154) |
Nov
(16) |
Dec
(12) |
2015 |
Jan
(18) |
Feb
(2) |
Mar
(122) |
Apr
(23) |
May
(56) |
Jun
(29) |
Jul
(35) |
Aug
(15) |
Sep
|
Oct
(45) |
Nov
(94) |
Dec
(38) |
2016 |
Jan
(50) |
Feb
(39) |
Mar
(39) |
Apr
(1) |
May
(14) |
Jun
(12) |
Jul
(19) |
Aug
(12) |
Sep
(9) |
Oct
(1) |
Nov
(13) |
Dec
(7) |
2017 |
Jan
(6) |
Feb
(1) |
Mar
(16) |
Apr
(5) |
May
(61) |
Jun
(18) |
Jul
(43) |
Aug
(1) |
Sep
(8) |
Oct
(25) |
Nov
(30) |
Dec
(6) |
2018 |
Jan
(5) |
Feb
(2) |
Mar
(25) |
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Anton Ivanov <anton.ivanov@ko...> - 2018-04-20 16:06:25
|
On 04/20/18 15:38, Eric W. Biederman wrote: > Today user mode linux only works on x86 and x86_64 and this allows > simplifications of relay_signal. I believe someone recently fixed the ARM port. I have not had the time to try the fixes though. I have added the new list we are migrating to the cc list. A. > > - x86 always set si_errno to 0 in fault handlers. > - x86 does not implement si_trapno. > - Only si_codes between SI_USER and SI_KERNEL have a fault address. > > Therefore warn if si_errno is set (it should never be). > Use force_sig_info in the case where we know we have a good fault. > > For signals whose content it is not clear how to relay use plain > force_sig and let the signal sending code come up with an > appropriate generic siginfo. > > Cc: Jeff Dike <jdike@...> > Cc: Richard Weinberger <richard@...> > Cc: user-mode-linux-devel@... > Signed-off-by: "Eric W. Biederman" <ebiederm@...> > --- > arch/um/kernel/trap.c | 28 +++++++++++++--------------- > 1 file changed, 13 insertions(+), 15 deletions(-) > > diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c > index d4d38520c4c6..5f0ff17cd790 100644 > --- a/arch/um/kernel/trap.c > +++ b/arch/um/kernel/trap.c > @@ -296,9 +296,6 @@ unsigned long segv(struct faultinfo fi, unsigned long ip, int is_user, > > void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs *regs) > { > - struct faultinfo *fi; > - struct siginfo clean_si; > - > if (!UPT_IS_USER(regs)) { > if (sig == SIGBUS) > printk(KERN_ERR "Bus error - the host /dev/shm or /tmp " > @@ -308,29 +305,30 @@ void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs *regs) > > arch_examine_signal(sig, regs); > > - clear_siginfo(&clean_si); > - clean_si.si_signo = si->si_signo; > - clean_si.si_errno = si->si_errno; > - clean_si.si_code = si->si_code; > + if (unlikely(si->si_errno)) { > + printk(KERN_ERR "Attempted to relay signal %d (si_code = %d) with errno %d\n", > + sig, si->si_code, si->si_errno); > + } > switch (sig) { > case SIGILL: > case SIGFPE: > case SIGSEGV: > case SIGBUS: > case SIGTRAP: > - fi = UPT_FAULTINFO(regs); > - clean_si.si_addr = (void __user *) FAULT_ADDRESS(*fi); > - current->thread.arch.faultinfo = *fi; > -#ifdef __ARCH_SI_TRAPNO > - clean_si.si_trapno = si->si_trapno; > -#endif > - break; > + if ((si->si_code > SI_USER) && (si->si_code < SI_KERNEL)) { > + struct faultinfo *fi = UPT_FAULTINFO(regs); > + current->thread.arch.faultinfo = *fi; > + force_sig_fault(sig, si->si_code, > + (void __user *)FAULT_ADDRESS(*fi), > + current); > + break; > + } > default: > printk(KERN_ERR "Attempted to relay unknown signal %d (si_code = %d)\n", > sig, si->si_code); > } > > - force_sig_info(sig, &clean_si, current); > + force_sig(sig, current); > } > > void bus_handler(int sig, struct siginfo *si, struct uml_pt_regs *regs) |
From: Eric W. Biederman <ebiederm@xm...> - 2018-04-20 15:23:35
|
Today user mode linux only works on x86 and x86_64 and this allows simplifications of relay_signal. - x86 always set si_errno to 0 in fault handlers. - x86 does not implement si_trapno. - Only si_codes between SI_USER and SI_KERNEL have a fault address. Therefore warn if si_errno is set (it should never be). Use force_sig_info in the case where we know we have a good fault. For signals whose content it is not clear how to relay use plain force_sig and let the signal sending code come up with an appropriate generic siginfo. Cc: Jeff Dike <jdike@...> Cc: Richard Weinberger <richard@...> Cc: user-mode-linux-devel@... Signed-off-by: "Eric W. Biederman" <ebiederm@...> --- arch/um/kernel/trap.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c index d4d38520c4c6..5f0ff17cd790 100644 --- a/arch/um/kernel/trap.c +++ b/arch/um/kernel/trap.c @@ -296,9 +296,6 @@ unsigned long segv(struct faultinfo fi, unsigned long ip, int is_user, void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs *regs) { - struct faultinfo *fi; - struct siginfo clean_si; - if (!UPT_IS_USER(regs)) { if (sig == SIGBUS) printk(KERN_ERR "Bus error - the host /dev/shm or /tmp " @@ -308,29 +305,30 @@ void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs *regs) arch_examine_signal(sig, regs); - clear_siginfo(&clean_si); - clean_si.si_signo = si->si_signo; - clean_si.si_errno = si->si_errno; - clean_si.si_code = si->si_code; + if (unlikely(si->si_errno)) { + printk(KERN_ERR "Attempted to relay signal %d (si_code = %d) with errno %d\n", + sig, si->si_code, si->si_errno); + } switch (sig) { case SIGILL: case SIGFPE: case SIGSEGV: case SIGBUS: case SIGTRAP: - fi = UPT_FAULTINFO(regs); - clean_si.si_addr = (void __user *) FAULT_ADDRESS(*fi); - current->thread.arch.faultinfo = *fi; -#ifdef __ARCH_SI_TRAPNO - clean_si.si_trapno = si->si_trapno; -#endif - break; + if ((si->si_code > SI_USER) && (si->si_code < SI_KERNEL)) { + struct faultinfo *fi = UPT_FAULTINFO(regs); + current->thread.arch.faultinfo = *fi; + force_sig_fault(sig, si->si_code, + (void __user *)FAULT_ADDRESS(*fi), + current); + break; + } default: printk(KERN_ERR "Attempted to relay unknown signal %d (si_code = %d)\n", sig, si->si_code); } - force_sig_info(sig, &clean_si, current); + force_sig(sig, current); } void bus_handler(int sig, struct siginfo *si, struct uml_pt_regs *regs) -- 2.14.1 |
From: Eric W. Biederman <ebiederm@xm...> - 2018-04-20 15:16:03
|
Filling in struct siginfo before calling force_sig_info a tedious and error prone process, where once in a great while the wrong fields are filled out, and siginfo has been inconsistently cleared. Simplify this process by using the helper force_sig_fault. Which takes as a parameters all of the information it needs, ensures all of the fiddly bits of filling in struct siginfo are done properly and then calls force_sig_info. In short about a 5 line reduction in code for every time force_sig_info is called, which makes the calling function clearer. Cc: Jeff Dike <jdike@...> Cc: Richard Weinberger <richard@...> Cc: user-mode-linux-devel@... Signed-off-by: "Eric W. Biederman" <ebiederm@...> --- arch/um/kernel/ptrace.c | 13 +++---------- arch/um/kernel/trap.c | 26 ++++++++------------------ 2 files changed, 11 insertions(+), 28 deletions(-) diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c index bc2a516c190f..1a1d88a4d940 100644 --- a/arch/um/kernel/ptrace.c +++ b/arch/um/kernel/ptrace.c @@ -115,17 +115,10 @@ long arch_ptrace(struct task_struct *child, long request, static void send_sigtrap(struct task_struct *tsk, struct uml_pt_regs *regs, int error_code) { - struct siginfo info; - - memset(&info, 0, sizeof(info)); - info.si_signo = SIGTRAP; - info.si_code = TRAP_BRKPT; - - /* User-mode eip? */ - info.si_addr = UPT_IS_USER(regs) ? (void __user *) UPT_IP(regs) : NULL; - /* Send us the fake SIGTRAP */ - force_sig_info(SIGTRAP, &info, tsk); + force_sig_fault(SIGTRAP, TRAP_BRKPT, + /* User-mode eip? */ + UPT_IS_USER(regs) ? (void __user *) UPT_IP(regs) : NULL, tsk); } /* diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c index 5f0ff17cd790..48b70dcb6963 100644 --- a/arch/um/kernel/trap.c +++ b/arch/um/kernel/trap.c @@ -162,14 +162,9 @@ static void show_segv_info(struct uml_pt_regs *regs) static void bad_segv(struct faultinfo fi, unsigned long ip) { - struct siginfo si; - - clear_siginfo(&si); - si.si_signo = SIGSEGV; - si.si_code = SEGV_ACCERR; - si.si_addr = (void __user *) FAULT_ADDRESS(fi); current->thread.arch.faultinfo = fi; - force_sig_info(SIGSEGV, &si, current); + force_sig_fault(SIGSEGV, SEGV_ACCERR, (void __user *) FAULT_ADDRESS(fi), + current); } void fatal_sigsegv(void) @@ -215,13 +210,12 @@ void segv_handler(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs) unsigned long segv(struct faultinfo fi, unsigned long ip, int is_user, struct uml_pt_regs *regs) { - struct siginfo si; jmp_buf *catcher; + int si_code; int err; int is_write = FAULT_WRITE(fi); unsigned long address = FAULT_ADDRESS(fi); - clear_siginfo(&si); if (!is_user && regs) current->thread.segv_regs = container_of(regs, struct pt_regs, regs); @@ -241,7 +235,7 @@ unsigned long segv(struct faultinfo fi, unsigned long ip, int is_user, if (SEGV_IS_FIXABLE(&fi)) err = handle_page_fault(address, ip, is_write, is_user, - &si.si_code); + &si_code); else { err = -EFAULT; /* @@ -273,18 +267,14 @@ unsigned long segv(struct faultinfo fi, unsigned long ip, int is_user, show_segv_info(regs); if (err == -EACCES) { - si.si_signo = SIGBUS; - si.si_errno = 0; - si.si_code = BUS_ADRERR; - si.si_addr = (void __user *)address; current->thread.arch.faultinfo = fi; - force_sig_info(SIGBUS, &si, current); + force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *)address, + current); } else { BUG_ON(err != -EFAULT); - si.si_signo = SIGSEGV; - si.si_addr = (void __user *) address; current->thread.arch.faultinfo = fi; - force_sig_info(SIGSEGV, &si, current); + force_sig_fault(SIGSEGV, si_code, (void __user *) address, + current); } out: -- 2.14.1 |
From: Richard Weinberger <richard@si...> - 2018-04-18 12:41:53
|
Hi! The new mailing list address is: linux-um@... Please subscribe via web[0] or mail[1]. Thanks, //richard [0] http://lists.infradead.org/mailman/listinfo/linux-um [1] linux-um-join@... -- sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y |
From: Richard Weinberger <richard@no...> - 2018-04-18 12:27:58
|
We have a new mailing list, so update the MAINTAINERS file. Signed-off-by: Richard Weinberger <richard@...> --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b60179d948bb..4834d1551248 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14768,8 +14768,7 @@ F: drivers/media/usb/zr364xx/ USER-MODE LINUX (UML) M: Jeff Dike <jdike@...> M: Richard Weinberger <richard@...> -L: user-mode-linux-devel@... -L: user-mode-linux-user@... +L: linux-um@... W: http://user-mode-linux.sourceforge.net T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git S: Maintained -- 2.13.6 |
From: Richard Weinberger <richard@no...> - 2018-04-12 06:40:41
|
Am Donnerstag, 29. März 2018, 22:45:59 CEST schrieb Richard Weinberger: > While the function will never returns, gcc will warns. > Add a return statement to make gcc happy. > Before f44f1e7da7c8 we never noticed because gcc knows that longjmp does > not return. > > arch/um/os-Linux/skas/process.c: In function ‘start_idle_thread’: > arch/um/os-Linux/skas/process.c:613:1: warning: control reaches end of non-void function [-Wreturn-type] > > Fixes: f44f1e7da7c8 ("um: Avoid longjmp/setjmp symbol clashes with libpthread.a") > Signed-off-by: Richard Weinberger <richard@...> Applied. Thanks, //richard |
From: Richard Weinberger <richard@no...> - 2018-04-12 06:40:15
|
Am Donnerstag, 5. April 2018, 23:21:02 CEST schrieb Hernán Gonzalez: > This option restores the DEBUG_BUGVERBOSE functionality as it was > previous to commit 9a93848fe787 ("x86/debug: Implement __WARN() using > UD0"). > > Signed-off-by: Hernán Gonzalez <hernan@...> Applied. Thanks, //richard |
From: Richard Weinberger <richard@no...> - 2018-04-10 21:31:25
|
Linus, The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51: Linux 4.16-rc2 (2018-02-18 17:29:42 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for you to fetch changes up to e40238dedb484c8a19f8257e4ef5d77d038f9ad8: Fix vector raw inintialization logic (2018-03-29 22:18:02 +0200) ---------------------------------------------------------------- This pull request contains: - A new and faster epoll based IRQ controller and NIC driver - Misc fixes and janitorial updates ---------------------------------------------------------------- Anton Ivanov (5): Epoll based IRQ controller High Performance UML Vector Network Driver um: Add missing EXPORT for free_irq_by_fd() Migrate vector timers to new timer API Fix vector raw inintialization logic Arnd Bergmann (1): um: time: Use timespec64 for persistent clock Christophe JAILLET (2): um: vector: Fix a memory allocation check um: vector: Fix an error handling path in 'vector_parse()' Geert Uytterhoeven (1): um: Restore symbol versions for __memcpy and memcpy Jason A. Donenfeld (1): um: Compile with modern headers Krzysztof Mazur (1): um: Use POSIX ucontext_t instead of struct ucontext Wei Yongjun (1): um: vector: fix missing unlock on error in vector_net_open() arch/um/Kconfig.net | 11 + arch/um/drivers/Makefile | 4 +- arch/um/drivers/chan_kern.c | 53 +- arch/um/drivers/line.c | 2 +- arch/um/drivers/net_kern.c | 4 +- arch/um/drivers/random.c | 11 +- arch/um/drivers/ubd_kern.c | 4 +- arch/um/drivers/vector_kern.c | 1633 ++++++++++++++++++++++++++++++++++ arch/um/drivers/vector_kern.h | 130 +++ arch/um/drivers/vector_transports.c | 458 ++++++++++ arch/um/drivers/vector_user.c | 590 ++++++++++++ arch/um/drivers/vector_user.h | 100 +++ arch/um/include/asm/asm-prototypes.h | 1 + arch/um/include/asm/irq.h | 12 + arch/um/include/shared/irq_user.h | 12 +- arch/um/include/shared/net_kern.h | 2 + arch/um/include/shared/os.h | 17 +- arch/um/kernel/irq.c | 461 ++++++---- arch/um/kernel/time.c | 6 +- arch/um/os-Linux/file.c | 1 + arch/um/os-Linux/irq.c | 202 +++-- arch/um/os-Linux/signal.c | 3 +- arch/x86/um/stub_segv.c | 3 +- 23 files changed, 3395 insertions(+), 325 deletions(-) create mode 100644 arch/um/drivers/vector_kern.c create mode 100644 arch/um/drivers/vector_kern.h create mode 100644 arch/um/drivers/vector_transports.c create mode 100644 arch/um/drivers/vector_user.c create mode 100644 arch/um/drivers/vector_user.h create mode 100644 arch/um/include/asm/asm-prototypes.h |
From: Hernán Gonzalez <hernan@va...> - 2018-04-05 21:44:13
|
This option restores the DEBUG_BUGVERBOSE functionality as it was previous to commit 9a93848fe787 ("x86/debug: Implement __WARN() using UD0"). Signed-off-by: Hernán Gonzalez <hernan@...> --- arch/um/Kconfig.common | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common index c68add8..bf2a70f 100644 --- a/arch/um/Kconfig.common +++ b/arch/um/Kconfig.common @@ -8,6 +8,7 @@ config UML select HAVE_UID16 select HAVE_FUTEX_CMPXCHG if FUTEX select HAVE_DEBUG_KMEMLEAK + select HAVE_DEBUG_BUGVERBOSE select GENERIC_IRQ_SHOW select GENERIC_CPU_DEVICES select GENERIC_CLOCKEVENTS -- 2.7.4 |
From: Richard Weinberger <richard@no...> - 2018-03-29 21:06:03
|
While the function will never returns, gcc will warns. Add a return statement to make gcc happy. Before f44f1e7da7c8 we never noticed because gcc knows that longjmp does not return. arch/um/os-Linux/skas/process.c: In function ‘start_idle_thread’: arch/um/os-Linux/skas/process.c:613:1: warning: control reaches end of non-void function [-Wreturn-type] Fixes: f44f1e7da7c8 ("um: Avoid longjmp/setjmp symbol clashes with libpthread.a") Signed-off-by: Richard Weinberger <richard@...> --- arch/um/os-Linux/skas/process.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c index c94c3bd70ccd..d41fdf686a5f 100644 --- a/arch/um/os-Linux/skas/process.c +++ b/arch/um/os-Linux/skas/process.c @@ -610,6 +610,10 @@ int start_idle_thread(void *stack, jmp_buf *switch_buf) fatal_sigsegv(); } longjmp(*switch_buf, 1); + + /* unreachable */ + fatal_sigsegv(); + return 0; } void initial_thread_cb_skas(void (*proc)(void *), void *arg) -- 2.13.6 |
From: Anton Ivanov <anton.ivanov@ko...> - 2018-03-29 20:42:36
|
Yes, Next version though, I have some tweaks enqueued for the socket initialization. We can combine them with these. On 29 March 2018 20:51:55 BST, SF Markus Elfring <elfring@...> wrote: >> Date: Sun, 11 Mar 2018 16:06:16 +0100 >> >> Some update suggestions were taken into account >> from static source code analysis. >… >> Delete unnecessary code in user_init_raw_fds() >> Less checks in user_init_raw_fds() after error detection >> Adjust an error message in user_init_socket_fds() >> Delete an unnecessary check before kfree() in >user_init_socket_fds() >> Delete two unnecessary checks before freeaddrinfo() in >user_init_socket_fds() >> Less checks in user_init_socket_fds() after error detection >> Adjust an error message in user_init_tap_fds() >> Less checks in user_init_tap_fds() after error detection >> Delete an unnecessary variable initialisation in >user_init_tap_fds() >… > >Would you like to pick any idea up from this patch series? > >Regards, >Markus -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
From: Richard Weinberger <richard@no...> - 2018-03-29 20:34:55
|
Am Donnerstag, 29. März 2018, 22:20:47 CEST schrieb Joel Fernandes: > Thanks a lot! I am wondering why the same compiler works when running > the test for a regular image. Maybe different compiler flags. Anyway > good to learn this. > > Also one more slightly OT question, why is UML only doing UP ? Is it > extremely hard to do SMP for UML? Long story short, nobody implemented SMP so far. :-) Because SKAS3/0 we had a SMP implementation of TT mode. In terms of UML implementing SMP means having multiple threads that handle the userspace loop in arch/um/os-Linux/skas/process.c. We could also do a poor man's SMP implementation first, where only user processes run in parallel. IOW userspace() in arch/um/os-Linux/skas/process.c is still a single thread but it let's run up to N user space thread and only if the call into the kernel we degrade to UP. Adding SMP is not extremely hard but it requires a lot of re-work of the UML core and introduces tons of new issues. That said, volunteers are welcome! Thanks, //richard |
From: Joel Fernandes <agnel.joel@gm...> - 2018-03-29 20:20:56
|
On Wed, Mar 28, 2018 at 11:04 PM, Geert Uytterhoeven <geert@...> wrote: > On Thu, Mar 29, 2018 at 12:35 AM, Richard Weinberger <richard@...> wrote: >> Am Donnerstag, 29. März 2018, 00:19:39 CEST schrieb Joel Fernandes: >>> On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <richard@...> wrote: >>> > Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven: >>> >> On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> >>> > wrote: >>> >> > while(release_now == 0); >>> >> >>> >> while (release_now == 0) >>> >> cpu_relax(); >>> > >>> > Not sure whether a cpu_relax() fixes the problem. >>> > I guess the root of the problem is that UML is UP and non-preemptive. >>> > Therefore the loop is never interrupted. >>> > To verify I asked for the full source. >>> > >>> >>> cpu_relax actually worked! >> >> Interesting. >> >>> Any thoughts on why it helps? Even if its non-preemptive, I did >>> receive the timer interrupt, so I expected the variable to be set. >> >> Timers trigger also with preempt off, I forgot... >> I think the cpu_relax() issues internally a barrier such that the >> release_now variable is read again. >> Can you try barrier() instead of cpu_relax()? I bet it works too. >> Same if you mark release_now as volatile. > > Without cpu_relax()/barrier()/volatile, the compiler can assume release_now > never changes, and thus may "optimize" the loop to an infinite loop. > Thanks a lot! I am wondering why the same compiler works when running the test for a regular image. Maybe different compiler flags. Anyway good to learn this. Also one more slightly OT question, why is UML only doing UP ? Is it extremely hard to do SMP for UML? I also happen to notice Qemu has one thread per emulated core... thanks, - Joel |
From: Richard Weinberger <richard@no...> - 2018-03-29 20:18:41
|
Am Montag, 5. März 2018, 14:29:05 CEST schrieb anton.ivanov@...: > From: Anton Ivanov <anton.ivanov@...> > > Vector RAW in UML needs to BPF filter its own MAC only > if QDISC_BYPASS has failed. If QDISC_BYPASS is successful, the > frames originated locally are not visible to readers on the > raw socket. > > Signed-off-by: Anton Ivanov <anton.ivanov@...> Applied. Thanks, //richard |
From: Richard Weinberger <richard@no...> - 2018-03-29 20:17:40
|
Am Montag, 5. März 2018, 11:41:42 CEST schrieb anton.ivanov@...: > From: Anton Ivanov <anton.ivanov@...> > > The patches for the UML vector drivers were in-flight when > the timer changes happened and were not covered by them. > > This change migrates vector_kern.c to use the new timer API. > > Signed-off-by: Anton Ivanov <anton.ivanov@...> Applied. Thanks, //richard |
From: Geert Uytterhoeven <geert@li...> - 2018-03-29 06:04:30
|
On Thu, Mar 29, 2018 at 12:35 AM, Richard Weinberger <richard@...> wrote: > Am Donnerstag, 29. März 2018, 00:19:39 CEST schrieb Joel Fernandes: >> On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <richard@...> wrote: >> > Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven: >> >> On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> >> > wrote: >> >> > while(release_now == 0); >> >> >> >> while (release_now == 0) >> >> cpu_relax(); >> > >> > Not sure whether a cpu_relax() fixes the problem. >> > I guess the root of the problem is that UML is UP and non-preemptive. >> > Therefore the loop is never interrupted. >> > To verify I asked for the full source. >> > >> >> cpu_relax actually worked! > > Interesting. > >> Any thoughts on why it helps? Even if its non-preemptive, I did >> receive the timer interrupt, so I expected the variable to be set. > > Timers trigger also with preempt off, I forgot... > I think the cpu_relax() issues internally a barrier such that the > release_now variable is read again. > Can you try barrier() instead of cpu_relax()? I bet it works too. > Same if you mark release_now as volatile. Without cpu_relax()/barrier()/volatile, the compiler can assume release_now never changes, and thus may "optimize" the loop to an infinite loop. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Richard Weinberger <richard@no...> - 2018-03-28 22:35:23
|
Am Donnerstag, 29. März 2018, 00:19:39 CEST schrieb Joel Fernandes: > Thanks for the quick reply. > > On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <richard@...> wrote: > > Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven: > >> On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> > > wrote: > >> > while(release_now == 0); > >> > >> while (release_now == 0) > >> cpu_relax(); > > > > Not sure whether a cpu_relax() fixes the problem. > > I guess the root of the problem is that UML is UP and non-preemptive. > > Therefore the loop is never interrupted. > > To verify I asked for the full source. > > > > cpu_relax actually worked! Interesting. > Any thoughts on why it helps? Even if its non-preemptive, I did > receive the timer interrupt, so I expected the variable to be set. Timers trigger also with preempt off, I forgot... I think the cpu_relax() issues internally a barrier such that the release_now variable is read again. Can you try barrier() instead of cpu_relax()? I bet it works too. Same if you mark release_now as volatile. Thanks, //richard |
From: Joel Fernandes <agnel.joel@gm...> - 2018-03-28 22:19:49
|
Thanks for the quick reply. On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <richard@...> wrote: > Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven: >> On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> > wrote: >> > while(release_now == 0); >> >> while (release_now == 0) >> cpu_relax(); > > Not sure whether a cpu_relax() fixes the problem. > I guess the root of the problem is that UML is UP and non-preemptive. > Therefore the loop is never interrupted. > To verify I asked for the full source. > cpu_relax actually worked! Any thoughts on why it helps? Even if its non-preemptive, I did receive the timer interrupt, so I expected the variable to be set. Module is attached. Thanks, -Joel |
From: Richard Weinberger <richard@no...> - 2018-03-28 13:19:22
|
Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven: > On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> wrote: > > while(release_now == 0); > > while (release_now == 0) > cpu_relax(); Not sure whether a cpu_relax() fixes the problem. I guess the root of the problem is that UML is UP and non-preemptive. Therefore the loop is never interrupted. To verify I asked for the full source. Thanks, //richard |
From: Geert Uytterhoeven <geert@li...> - 2018-03-28 13:11:39
|
On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agnel.joel@...> wrote: > while(release_now == 0); while (release_now == 0) cpu_relax(); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Richard Weinberger <richard@no...> - 2018-03-28 11:22:45
|
Am Mittwoch, 28. März 2018, 12:28:02 CEST schrieb Joel Fernandes: > Hi, > > I wrote a kernel module to play with hrtimer subsystem and it hangs > with UML, Any ideas on why it may be hanging? It doesn't hang on any > of my other machines. Hopefully I'm not doing something stupid, but I > don't think I am.. > > It appears the timer handler does fire. However, the UML process is > continously doing a kill(SIGALRM) to the host, and the shell hangs. > Here's the continous strace output of UML's process at the time of the > hang: https://hastebin.com/ikehadapon.sql > > To build UML, I do: > make ARCH=um x86_64_defconfig > > UML kernel version is v4.16-rc4 > > Here's the module I'm loading: Please share the full sources that compile. The I can have a look. Thanks, //richard |
From: Joel Fernandes <agnel.joel@gm...> - 2018-03-28 10:28:11
|
Hi, I wrote a kernel module to play with hrtimer subsystem and it hangs with UML, Any ideas on why it may be hanging? It doesn't hang on any of my other machines. Hopefully I'm not doing something stupid, but I don't think I am.. It appears the timer handler does fire. However, the UML process is continously doing a kill(SIGALRM) to the host, and the shell hangs. Here's the continous strace output of UML's process at the time of the hang: https://hastebin.com/ikehadapon.sql To build UML, I do: make ARCH=um x86_64_defconfig UML kernel version is v4.16-rc4 Here's the module I'm loading: static enum hrtimer_restart bigtimer_handle(struct hrtimer *timer) { printk(KERN_ERR "timer fired 2\n"); spin_lock(&il->biglock); spin_unlock(&il->biglock); release_now = 1; return HRTIMER_NORESTART; } void init_bigstr(struct bigstr *b) { spin_lock_init(&b->biglock); } static int __init test_module_init(void) { struct bigstr b1, b2; struct hrtimer *timer; release_now = 0; init_bigstr(&b1); init_bigstr(&b2); timer = &bigtimer; timer->debug = 1; hrtimer_init(timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); timer->function = bigtimer_handle; il = &b2; spin_lock(&b1.biglock); printk(KERN_ERR "Starting timer\n"); hrtimer_start(timer, ns_to_ktime(50000ULL), HRTIMER_MODE_REL_PINNED); while(release_now == 0); spin_unlock(&b1.biglock); return -1; } Thanks for any debug thoughts! I'll also try to hook up gdb tomorrow and see if I find something.. Regards, - Joel |
From: Richard Weinberger <richard@no...> - 2018-03-20 14:51:57
|
Am Dienstag, 20. März 2018, 03:45:11 CET schrieb Bernd Petrovitsch: > On Mon, 2018-03-19 at 15:24 +0100, Richard Weinberger wrote: > [...] > > > I checked, migrating is not an option. > > sourceforge has hacked mailman to hide member mail addresses: > > "As a result of the latest electronic messaging and privacy requirements > > around the world, SourceForge has implemented a number of changes that > > affect > Details please, sf.net. > Otherwise the motivation is very probably a completely different one. > > > email privacy. One part of this is that it is no longer possible for > > project admins to view the member emails of their mailing lists." > > As absurd as it can get if an ML admin isn't allowed to see the email > addresses on his/her list. > > It seems sf.net wants to be abandoned in general .... > > Just create the new - better - list/s and send subscription > information! I've talked to dwmw2, we will move to infradead.org. :-) Thanks, //richard |
From: Bernd Petrovitsch <bernd@pe...> - 2018-03-20 02:46:01
|
On Mon, 2018-03-19 at 15:24 +0100, Richard Weinberger wrote: [...] > I checked, migrating is not an option. > sourceforge has hacked mailman to hide member mail addresses: > "As a result of the latest electronic messaging and privacy requirements > around the world, SourceForge has implemented a number of changes that affect Details please, sf.net. Otherwise the motivation is very probably a completely different one. > email privacy. One part of this is that it is no longer possible for project > admins to view the member emails of their mailing lists." As absurd as it can get if an ML admin isn't allowed to see the email addresses on his/her list. It seems sf.net wants to be abandoned in general .... Just create the new - better - list/s and send subscription information! MfG, Bernd -- Bernd Petrovitsch Email : bernd@... LUGA : http://www.luga.at |
From: Richard Weinberger <richard@no...> - 2018-03-19 14:23:10
|
Am Dienstag, 13. März 2018, 14:59:41 CET schrieb Richard Weinberger: > Am Dienstag, 13. März 2018, 14:24:23 CET schrieb Geert Uytterhoeven: > > Hi Richard, > > > > On Mon, Mar 12, 2018 at 4:21 PM, Richard Weinberger <richard@...> wrote: > > > Am Montag, 12. März 2018, 16:10:45 CET schrieb Brandeburg, Jesse: > > >> > Is the list working for everyone? > > >> > > >> I got this mail... BTW Sourceforge had a major datacenter issue over > > >> the > > >> last few weeks, not sure if that broke something along the way. > > > > > > Hmm, I got this mail only because you CC'ed me. I don't see it in my > > > mailinglist inbox. > > > > > > We should bite the bullet and migrate way from sf.net, finally. > > > Any volunteers? > > > > You can ask DaveM to create a list at vger. > > Yes, or infradead.org. > The bigger problem is migrating all users. > > Maybe there is a way to extract a list of subscribers from > lists.sourceforge.net. Jeff made me project admin some time ago, maybe I can > exhume that account. I checked, migrating is not an option. sourceforge has hacked mailman to hide member mail addresses: "As a result of the latest electronic messaging and privacy requirements around the world, SourceForge has implemented a number of changes that affect email privacy. One part of this is that it is no longer possible for project admins to view the member emails of their mailing lists." > Or we are rude and expect everyone to re-subscribe to the new UML list. > That way we might lose 99% of all subscribers but at least the 1% is > interested in UML for sure. ;-) So, I'll ask for a mailinglist on infradead.org. Thanks, //richard P.s: Just realized that most of my mails also didn't make it to the mailinglist. That _sucks_. |