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
(15) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Pablo P. <ppe...@ho...> - 2019-06-06 23:27:38
|
Hi: I need to run a custom (host-OS) system call from a user-space process of a running UML (without been ptraced) The system call considers the host-OS task_struct, nor UML kernel allocated task_struct for the process. So as not to break the UML operating mode, I think that could I do it running a function located in the process' SKAS stub and invoked from the UML Kernel (such as stub_clone_handler()) I there any way to do that? Can I define global/static variables in the process' SKAS stub? Regards. PAP |
From: Pablo P. <ppe...@ho...> - 2019-04-30 15:38:14
|
Hi: I am writing a UML device driver wrapper (uml/drivers), and I need to convert an address of a UML user-space process into an address of UML kernel space. i.e. Process_running_within_UML(){ char uml_usr_buffer[MAXBUF]; ..... ret = ioctl(dvk_fd,DVK_IOCSDCINIT, (int) uml_usr_buffer); } UML ioctl() syscall is translated by UML to os_ioctl_generic<https://elixir.bootlin.com/linux/v4.9.88/ident/os_ioctl_generic>() which then calls host ioctl(). The uml_usr_buffer address is a UML virtual address, not host virtual address. I need to convert this UML user-space virtual address into user-space HOST virtual address. Can I use, virt_to_phys() ?? Thanks in advance. PAP |
From: Anton I. <ant...@ko...> - 2019-02-20 21:01:37
|
I do not think that this is possible without an additional device in the UML itself. In fact, if you want two processes in two different UML instances to communicate in-between themselves you should aim at a UML device. The kernel device is probably suprlus to requirements as the two UML instances can communicate between themselves within the host userspace using any of the mechanisms available for that. A. On 2/20/19 6:36 PM, Pablo Pessolani wrote: > Hi: > I wrote an IPC mechanism as a Linux kernel module. The access > to their services is through a dummy character device called /dev/dvk > using ioctl(). Therefore, only open(), ioctl() and close() system > calls are used. > How can a process running within an UML Guest access the > /dev/dvk host device? (humfs??) > The idea is to communicate two o more UML instances through > this IPC mechanism. > Thanks in advance. > Regards. > PAP > > > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Anton R Ivanov http://www.kot-begemot.co.uk |
From: Pablo P. <ppe...@ho...> - 2019-02-20 18:37:05
|
Hi: I wrote an IPC mechanism as a Linux kernel module. The access to their services is through a dummy character device called /dev/dvk using ioctl(). Therefore, only open(), ioctl() and close() system calls are used. How can a process running within an UML Guest access the /dev/dvk host device? (humfs??) The idea is to communicate two o more UML instances through this IPC mechanism. Thanks in advance. Regards. PAP |
From: Pablo P. <ppe...@ho...> - 2018-10-18 14:16:42
|
Hi: We wrote a filesystem prototype and we want to use it from UML as a externfs. Is there any example code of another filesystem as externfs ? Is externfs like a FUSE driver? Why do not use FUSE ? Which are the main differences among both? Regards. PAP |
From: Richard W. <ric...@gm...> - 2018-06-03 08:33:51
|
On Sun, Jun 3, 2018 at 4:37 AM, Masahiro Yamada <yam...@so...> wrote: > Hi UML maintainers, > > 2018-05-15 11:37 GMT+09:00 Masahiro Yamada <yam...@so...>: >> This file contains symbol values, and was originally linked into >> vmlinux, but I have no idea what it was actually used for. >> >> Since commit 827880ec260b ("x86/um: thin archives build fix"), it is >> not even linked. Now it is completely orphan, and no problem has >> been reported. It is a proof that this file was not needed in the >> first place. >> >> Signed-off-by: Masahiro Yamada <yam...@so...> >> Acked-by: Ingo Molnar <mi...@ke...> >> --- > > > Could you take a look at this patch, please? Acked-by: Richard Weinberger <ri...@no...> -- Thanks, //richard |
From: Pablo P. <ppe...@ho...> - 2018-05-10 15:47:34
|
Hi: I am a UML newbie . Is SKAS3 mode now included into the Linux kernel or it should be applied as a patch? Thanks in advance. PAP |
From: Richard W. <ri...@no...> - 2018-05-09 06:36:29
|
Masahiro, Am Mittwoch, 9. Mai 2018, 05:36:18 CEST schrieb Masahiro Yamada: > Hi Richard, > > > Please let me ask a question about vdso-syms.lds > under arch/x86/um/vdso/. > > This file exists since: > > commit f1c2bb8b9964ed31de988910f8b1cfb586d30091 > Author: Richard Weinberger <ri...@no...> > Date: Mon Jul 25 17:12:54 2011 -0700 > > um: implement a x86_64 vDSO > > > So, I think you are the right person > to reach out to. > > > Originally, vdso-syms.lds was linked to vmlinux, > but it is not since: > > commit 827880ec260ba048f95fe646b96a205c394fa0f0 > Author: Nicholas Piggin <np...@gm...> > Date: Fri Jun 9 15:24:16 2017 +1000 > > x86/um: thin archives build fix > > > > Something may be missing from my thought, > but I wonder what vdso-syms.lds is used for. Hmm, I think we can kill it. In 2011 I used the x86 vdso code as "template" this is how the file made it into UML. AFAICT it was forgotten after all the vdso related refactoring in um and x86. Thanks, //richard |
From: <ebi...@xm...> - 2018-04-28 14:02:21
|
This patchset is a respin of my latest patch to relay_signal for uml. As I understand relay_signal it very carefully scrubs the signal information it gets from the host kernel before passing it on. Basically making certain it recognizes what it is dealing with. This patchset updates siginfo_layout so that relay_signal and arm64's force_signal_inject can reliably use it to verify the kind of signal being processed, by recognizing the specializations of SIL_FAULT as separate cases. To make the siginfo_layout changes clean. signalfd is first brought into the modern world of using a single copy_to_user, no default case statement (so gcc will flag missing cases), and handling SIGSYS for seccomp. The net is a simpler relay_signal is also more careful about which signals it relays. Eric The changes are also available at: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git siginfo-review3 Eric W. Biederman (5): signal/signalfd: Remove __put_user from signalfd_copyinfo signal/signalfd: Add support for SIGSYS signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR} signal/um: More carefully relay signals in relay_signal. arch/um/kernel/trap.c | 38 ++++++++------------ fs/signalfd.c | 84 +++++++++++++++++++++++++------------------ include/linux/signal.h | 3 ++ include/uapi/linux/signalfd.h | 6 +++- kernel/signal.c | 82 +++++++++++++++++++++++++++--------------- 5 files changed, 125 insertions(+), 88 deletions(-) |
From: <ebi...@xm...> - 2018-04-24 22:26:16
|
Martin Pärtel <mar...@gm...> writes: > And once more in plain text.. > > On 25 April 2018 at 01:00, Martin Pärtel <mar...@gm...> wrote: >> >> Hi all, >> >> This was ages ago, but from what I remember... >> >>> >>> Having a second look I really don't understand what relay_signal is >>> trying to do. >>> >>> The function relay_signal does not pass siginfo through unchanged. >> >> >> Just copying the entire struct would do the wrong thing. It was discussed here: >> https://marc.info/?l=user-mode-linux-devel&m=133910707911999&w=2 So you are regnerating siginfo to ensure you don't copy unintended things such as the host pid and host uid. Then my analysis is correct that you simply missed filtering out the si codes that are not signal specific and do not use the fault layout in struct siginfo. Is si_addr safe to copy across? I presume so since the kernel just ptraces an ordinary process, but I figure I should ask and double check. I am going to respin my patch. I would say that you really need a white-list of si_codes that whose use of struct siginfo that you know. Otherwise you could get into the same problem of under or over copying data. Eric |
From: <ebi...@xm...> - 2018-04-24 16:01:23
|
Sigh I should have Cc'd Martin Partel as well as this bit is his original code. Anton Ivanov <ant...@ko...> writes: > Hi Richard, > > There was a post to uml-devel during the days when the sourceforge mailing list > was working in random drop mode which claimed that "this fixes the arm build". > > I have not kept it locally and I do not see it the archive (I do not see a few > other posts there either - including some of mine). > > The joys of having a broken list :( > > Whoever posted it, if you are reading it, please re-post again so we can have a > look. > > In the meantime we are as you said - x86 only. The only case I can see my changed relay_signal affecting on arm is the nasty hach where errno is set in conjunction with trap_trace. Having a second look I really don't understand what relay_signal is trying to do. The function relay_signal does not pass siginfo through unchanged. The function relay_signal does not handle cases where si_code is not SI_USER or SI_KERNEL, or any of the other signal independent si_codes. In my change I believe I have preserved the character of relay_signal of just passing through the fault. Still even after reading the commit that upgraded relay_signal to preserve si_code and si_addr I really don't understand the intended logic. Am I missing something subtle or have the subtle details of siginfo just always been ignored? commit d3c1cfcdb43e023ab1b1c7a555cd9e929026500a Author: Martin Pärtel <mar...@gm...> Date: Thu Aug 2 00:49:17 2012 +0200 um: pass siginfo to guest process UML guest processes now get correct siginfo_t for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code are now correct where previously they were si_addr = NULL and si_code = 128. Signed-off-by: Martin Pärtel <mar...@gm...> Signed-off-by: Richard Weinberger <ri...@no...> Eric |
From: Anton I. <ant...@ko...> - 2018-04-24 08:44:34
|
Hi Richard, There was a post to uml-devel during the days when the sourceforge mailing list was working in random drop mode which claimed that "this fixes the arm build". I have not kept it locally and I do not see it the archive (I do not see a few other posts there either - including some of mine). The joys of having a broken list :( Whoever posted it, if you are reading it, please re-post again so we can have a look. In the meantime we are as you said - x86 only. A. On 04/24/18 09:32, Richard Weinberger wrote: > On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov > <ant...@ko...> wrote: >> 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. > Huh? UML is for ages x86 only. > |
From: Richard W. <ric...@gm...> - 2018-04-24 08:33:07
|
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov <ant...@ko...> wrote: > > 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. Huh? UML is for ages x86 only. -- Thanks, //richard |
From: Richard W. <ri...@no...> - 2018-04-23 19:43:51
|
Alexander, Am Montag, 23. April 2018, 20:20:17 CEST schrieb Alexander Pateenok: > __uml_initcall() is not used and .uml.initcall.init section is empty: > > $ grep -r '__uml_initcall(' > arch/um/include/shared/init.h:#define __uml_initcall(fn) \ > $ readelf -s ../umobj/linux | grep __uml_initcall > 23214: 00000000603b75d8 0 NOTYPE GLOBAL DEFAULT 32 __uml_initcall_start > 25337: 00000000603b75d8 0 NOTYPE GLOBAL DEFAULT 32 __uml_initcall_end > > So it is unnecessary. Right. The last user was removed almost 10 years ago by: d2efa6d5ce14 ("uml: remove the dead TTY_LOG code") Thanks, //richard |
From: Anton I. <ant...@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 <jd...@ad...> > Cc: Richard Weinberger <ri...@no...> > Cc: use...@li... > Signed-off-by: "Eric W. Biederman" <ebi...@xm...> > --- > 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. B. <ebi...@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 <jd...@ad...> Cc: Richard Weinberger <ri...@no...> Cc: use...@li... Signed-off-by: "Eric W. Biederman" <ebi...@xm...> --- 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. B. <ebi...@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 <jd...@ad...> Cc: Richard Weinberger <ri...@no...> Cc: use...@li... Signed-off-by: "Eric W. Biederman" <ebi...@xm...> --- 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 W. <ri...@si...> - 2018-04-18 12:41:53
|
Hi! The new mailing list address is: lin...@li... Please subscribe via web[0] or mail[1]. Thanks, //richard [0] http://lists.infradead.org/mailman/listinfo/linux-um [1] lin...@li... -- sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y |
From: Richard W. <ri...@no...> - 2018-04-18 12:27:58
|
We have a new mailing list, so update the MAINTAINERS file. Signed-off-by: Richard Weinberger <ri...@no...> --- 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 <jd...@ad...> M: Richard Weinberger <ri...@no...> -L: use...@li... -L: use...@li... +L: lin...@li... 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 W. <ri...@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 <ri...@no...> Applied. Thanks, //richard |
From: Richard W. <ri...@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 <he...@va...> Applied. Thanks, //richard |
From: Richard W. <ri...@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 G. <he...@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 <he...@va...> --- 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 W. <ri...@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 <ri...@no...> --- 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 I. <ant...@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 <el...@us...> 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. |