Re: [uml-devel] [PATCH RESEND] um: vdso: remove unused vdso-syms.lds

[Richard Weinberger]

On Sun, Jun 3, 2018 at 4:37 AM, Masahiro Yamada
 wrote:
> Hi UML maintainers,
>
> 2018-05-15 11:37 GMT+09:00 Masahiro Yamada :
>> 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 
>> Acked-by: Ingo Molnar 
>> ---
>
>
> Could you take a look at this patch, please?

Acked-by: Richard Weinberger 

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [UML] Question about arch/x86/um/vdso/vdso-syms.lds

[Richard Weinberger]

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 <rich...@nod.at>
> 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 <npig...@gmail.com>
> 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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

[Richard Weinberger]

On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
 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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: remove uml initcalls

[Richard Weinberger]

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: 603b75d8 0 NOTYPE  GLOBAL DEFAULT   32 
> __uml_initcall_start
>  25337: 603b75d8 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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [ANNOUNCE] New User Mode Linux Mailing List

[Richard Weinberger]

Hi!

The new mailing list address is: linux...@lists.infradead.org

Please subscribe via web[0] or mail[1].

Thanks,
//richard

[0] http://lists.infradead.org/mailman/listinfo/linux-um
[1] linux-um-j...@lists.infradead.org

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] um: Update mailing list address

[Richard Weinberger]

We have a new mailing list, so update the MAINTAINERS file.

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 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...@addtoit.com>
 M: Richard Weinberger <rich...@nod.at>
-L: user-mode-linux-devel@lists.sourceforge.net
-L: user-mode-linux-u...@lists.sourceforge.net
+L: linux...@lists.infradead.org
 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


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix return value of start_idle_thread

[Richard Weinberger]

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 <rich...@nod.at>

Applied.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Add HAVE_DEBUG_BUGVERBOSE.

[Richard Weinberger]

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 

Applied.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [GIT PULL] UML changes for 4.17-rc1

[Richard Weinberger]

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


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] um: Fix return value of start_idle_thread

[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 <rich...@nod.at>
---
 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


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML hangs with hrtimer test module

[Richard Weinberger]

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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] Fix vector raw inintialization logic

[Richard Weinberger]

Am Montag, 5. März 2018, 14:29:05 CEST schrieb anton.iva...@cambridgegreys.com:
> From: 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 

Applied.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] Migrate vector timers to new timer API

[Richard Weinberger]

Am Montag, 5. März 2018, 11:41:42 CEST schrieb anton.iva...@cambridgegreys.com:
> From: 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 

Applied.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML hangs with hrtimer test module

[Richard Weinberger]

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 <rich...@nod.at> 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.j...@gmail.com>
> > 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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML hangs with hrtimer test module

[Richard Weinberger]

Am Mittwoch, 28. März 2018, 15:11:29 CEST schrieb Geert Uytterhoeven:
> On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes  
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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML hangs with hrtimer test module

[Richard Weinberger]

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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Is the list working correctly

[Richard Weinberger]

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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Is the list working correctly

[Richard Weinberger]

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 <rich...@nod.at> 
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_.

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Is the list working correctly

[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 <rich...@nod.at> 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.

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. ;-)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Is the list working correctly

[Richard Weinberger]

Anton, Jesse,

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?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [RFC PATCH 25/35] hostfs: rename do_rmdir() to hostfs_do_rmdir()

[Richard Weinberger]

Am Sonntag, 11. März 2018, 11:55:47 CET schrieb Dominik Brodowski:
> do_rmdir() is used in the VFS layer at fs/namei.c, so use a different
> name in hostfs.
> 
> CC: Jeff Dike <jd...@addtoit.com>
> CC: Richard Weinberger <rich...@nod.at>
> CC: user-mode-linux-devel@lists.sourceforge.net
> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>

Acked-by: Richard Weinberger <rich...@nod.at>

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 2/2] um: vector: Fix an error handling path in 'vector_parse()'

[Richard Weinberger]

Anton,

Am Samstag, 27. Januar 2018, 12:42:17 CET schrieb Anton Ivanov:
> Thanks, looks correct, +1
> 
> Richard, can you add it to the next pull.
> 
> Thanks in advance,

Is that a Reviewed-by? :)
(Same for the other patch)

Thanks,
//richard

P.s: Something is odd with your mail setup, none of your mails made it to the 
mailinglist.

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] arch/um: compile with modern headers

[Richard Weinberger]

Jason,

Am Mittwoch, 13. Dezember 2017, 18:22:30 CET schrieb Jason A. Donenfeld:
> Recent libcs have gotten a bit more strict, so we actually need to
> include the right headers and use the right types. This enables UML to
> compile again.
> 
> Signed-off-by: Jason A. Donenfeld 
> Cc: sta...@vger.kernel.org
> ---
>  arch/um/os-Linux/file.c   | 1 +
>  arch/um/os-Linux/signal.c | 3 ++-
>  arch/x86/um/stub_segv.c   | 3 ++-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/um/os-Linux/file.c b/arch/um/os-Linux/file.c
> index 2db18cbbb0ea..c0197097c86e 100644
> --- a/arch/um/os-Linux/file.c
> +++ b/arch/um/os-Linux/file.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
> index a86d7cc2c2d8..bf0acb8aad8b 100644
> --- a/arch/um/os-Linux/signal.c
> +++ b/arch/um/os-Linux/signal.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
>   [SIGTRAP]   = relay_signal,
> @@ -159,7 +160,7 @@ static void (*handlers[_NSIG])(int sig, struct siginfo
> *si, mcontext_t *mc) = {
> 
>  static void hard_handler(int sig, siginfo_t *si, void *p)
>  {
> - struct ucontext *uc = p;
> + ucontext_t *uc = p;
>   mcontext_t *mc = >uc_mcontext;
>   unsigned long pending = 1UL << sig;
> 
> diff --git a/arch/x86/um/stub_segv.c b/arch/x86/um/stub_segv.c
> index 1518d2805ae8..27361cbb7ca9 100644
> --- a/arch/x86/um/stub_segv.c
> +++ b/arch/x86/um/stub_segv.c
> @@ -6,11 +6,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  void __attribute__ ((__section__ (".__syscall_stub")))
>  stub_segv_handler(int sig, siginfo_t *info, void *p)
>  {
> - struct ucontext *uc = p;
> + ucontext_t *uc = p;
> 
>   GET_FAULTINFO_FROM_MC(*((struct faultinfo *) STUB_DATA),
> >uc_mcontext);

Can you please rebase your fix on linux-next?
I have already a very similar fix in the pipe.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 1/2] um: vector_kern: Unlock on error in vector_net_open()

[Richard Weinberger]

Anton,

Am Samstag, 9. Dezember 2017, 18:09:17 CET schrieb Anton Ivanov:
> Thanks,
> 
> I guess I missed that one.
> 
> A.
> 
> On 09/12/17 11:49, Dan Carpenter wrote:
> > We need to unlock and restore IRQs on this error path.
> > 
> > Fixes: ad1f62ab2bd4 ("High Performance UML Vector Network Driver")
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
> > index d1d53015d572..bb83a2d22ac2 100644
> > --- a/arch/um/drivers/vector_kern.c
> > +++ b/arch/um/drivers/vector_kern.c
> > @@ -1156,8 +1156,10 @@ static int vector_net_open(struct net_device *dev)
> > 
> > struct vector_device *vdevice;
> > 
> > spin_lock_irqsave(>lock, flags);
> > 
> > -   if (vp->opened)
> > +   if (vp->opened) {
> > +   spin_unlock_irqrestore(>lock, flags);
> > 
> > return -ENXIO;
> > 
> > +   }
> > 
> > vp->opened = true;
> > spin_unlock_irqrestore(>lock, flags);

Please review/ack these patches.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] um: Convert ubd driver to blk-mq

[Richard Weinberger]

Convert the driver to the modern blk-mq framework.
As byproduct we get rid of our open coded restart logic and let
blk-mq handle it.

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 arch/um/drivers/ubd_kern.c | 178 +++--
 1 file changed, 93 insertions(+), 85 deletions(-)

diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index b55fe9bf5d3e..deceb8022a28 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -142,7 +143,6 @@ struct cow {
 #define MAX_SG 64
 
 struct ubd {
-   struct list_head restart;
/* name (and fd, below) of the file opened for writing, either the
 * backing or the cow file. */
char *file;
@@ -156,9 +156,12 @@ struct ubd {
struct cow cow;
struct platform_device pdev;
struct request_queue *queue;
+   struct blk_mq_tag_set tag_set;
spinlock_t lock;
+};
+
+struct ubd_pdu {
struct scatterlist sg[MAX_SG];
-   struct request *request;
int start_sg, end_sg;
sector_t rq_pos;
 };
@@ -182,10 +185,6 @@ struct ubd {
.shared =   0, \
.cow =  DEFAULT_COW, \
.lock = __SPIN_LOCK_UNLOCKED(ubd_devs.lock), \
-   .request =  NULL, \
-   .start_sg = 0, \
-   .end_sg =   0, \
-   .rq_pos =   0, \
 }
 
 /* Protected by ubd_lock */
@@ -196,6 +195,12 @@ static int fake_ide = 0;
 static struct proc_dir_entry *proc_ide_root = NULL;
 static struct proc_dir_entry *proc_ide = NULL;
 
+static blk_status_t ubd_queue_rq(struct blk_mq_hw_ctx *hctx,
+const struct blk_mq_queue_data *bd);
+static int ubd_init_request(struct blk_mq_tag_set *set,
+   struct request *req, unsigned int hctx_idx,
+   unsigned int numa_node);
+
 static void make_proc_ide(void)
 {
proc_ide_root = proc_mkdir("ide", NULL);
@@ -448,11 +453,8 @@ __uml_help(udb_setup,
 "in the boot output.\n\n"
 );
 
-static void do_ubd_request(struct request_queue * q);
-
 /* Only changed by ubd_init, which is an initcall. */
 static int thread_fd = -1;
-static LIST_HEAD(restart);
 
 /* Function to read several request pointers at a time
 * handling fractional reads if (and as) needed
@@ -510,9 +512,6 @@ static int bulk_req_safe_read(
 /* Called without dev->lock held, and only in interrupt context. */
 static void ubd_handler(void)
 {
-   struct ubd *ubd;
-   struct list_head *list, *next_ele;
-   unsigned long flags;
int n;
int count;
 
@@ -532,23 +531,17 @@ static void ubd_handler(void)
return;
}
for (count = 0; count < n/sizeof(struct io_thread_req *); 
count++) {
-   blk_end_request(
-   (*irq_req_buffer)[count]->req,
-   BLK_STS_OK,
-   (*irq_req_buffer)[count]->length
-   );
-   kfree((*irq_req_buffer)[count]);
+   struct io_thread_req *io_req = (*irq_req_buffer)[count];
+   int err = io_req->error ? BLK_STS_IOERR : BLK_STS_OK;
+
+   if (!blk_update_request(io_req->req, err, 
io_req->length))
+   __blk_mq_end_request(io_req->req, err);
+
+   kfree(io_req);
}
}
-   reactivate_fd(thread_fd, UBD_IRQ);
 
-   list_for_each_safe(list, next_ele, ){
-   ubd = container_of(list, struct ubd, restart);
-   list_del_init(>restart);
-   spin_lock_irqsave(>lock, flags);
-   do_ubd_request(ubd->queue);
-   spin_unlock_irqrestore(>lock, flags);
-   }
+   reactivate_fd(thread_fd, UBD_IRQ);
 }
 
 static irqreturn_t ubd_intr(int irq, void *dev)
@@ -869,6 +862,7 @@ static void ubd_device_release(struct device *dev)
struct ubd *ubd_dev = dev_get_drvdata(dev);
 
blk_cleanup_queue(ubd_dev->queue);
+   blk_mq_free_tag_set(_dev->tag_set);
*ubd_dev = ((struct ubd) DEFAULT_UBD);
 }
 
@@ -911,6 +905,11 @@ static int ubd_disk_register(int major, u64 size, int unit,
 
 #define ROUND_BLOCK(n) ((n + ((1 << 9) - 1)) & (-1 << 9))
 
+static const struct blk_mq_ops ubd_mq_ops = {
+   .queue_rq = ubd_queue_rq,
+   .init_request = ubd_init_request,
+};
+
 static int ubd_add(int n, char **error_out)
 {
struct ubd *ubd_dev = _devs[n];
@@ -927,15 +926,24 @@ static int ubd_add(int n, char **error_out)
 
ubd_dev->size = ROUND_BLOCK(ubd_dev->size);
 
-   INIT_LIST_HEAD(_dev->restart);
-   sg_init_table(ubd_dev->sg, MAX_SG);
+ 

Re: [uml-devel] [PATCH] [RFC] um: Convert ubd driver to blk-mq

[Richard Weinberger]

Anton,

please don't crop the CC list.

Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
> I need to do some reading on this.
> 
> First of all - a stupid question: mq's primary advantage is in
> multi-core systems as it improves io and core utilization. We are still
> single-core in UML and AFAIK this is likely to stay that way, right?

Well, someday blk-mq should completely replace the legacy block interface.
Christoph asked me convert the UML driver.
Also do find corner cases in blk-mq.
 
> On 26/11/17 13:10, Richard Weinberger wrote:
> > This is the first attempt to convert the UserModeLinux block driver
> > (UBD) to blk-mq.
> > While the conversion itself is rather trivial, a few questions
> > popped up in my head. Maybe you can help me with them.
> > 
> > MAX_SG is 64, used for blk_queue_max_segments(). This comes from
> > a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
> > value for blk-mq?
> > 
> > The driver does IO batching, for each request it issues many UML struct
> > io_thread_req request to the IO thread on the host side.
> > One io_thread_req per SG page.
> > Before the conversion the driver used blk_end_request() to indicate that
> > a part of the request is done.
> > blk_mq_end_request() does not take a length parameter, therefore we can
> > only mark the whole request as done. See the new is_last property on the
> > driver.
> > Maybe there is a way to partially end requests too in blk-mq?
> > 
> > Another obstacle with IO batching is that UML IO thread requests can
> > fail. Not only due to OOM, also because the pipe between the UML kernel
> > process and the host IO thread can return EAGAIN.
> > In this case the driver puts the request into a list and retried later
> > again when the pipe turns writable.
> > I’m not sure whether this restart logic makes sense with blk-mq, maybe
> > there is a way in blk-mq to put back a (partial) request?
> 
> This all sounds to me as blk-mq requests need different inter-thread
> IPC. We presently rely on the fact that each request to the IO thread is
> fixed size and there is no natural request grouping coming from upper
> layers.
> 
> Unless I am missing something, this looks like we are now getting group
> requests, right? We need to send a group at a time which is not
> processed until the whole group has been received in the IO thread. We
> cans still batch groups though, but should not batch individual
> requests, right?

The question is, do we really need batching at all with blk-mq?
Jeff implemented that 10 years ago.

> My first step (before moving to mq) would have been to switch to a unix
> domain socket pair probably using SOCK_SEQPACKET or SOCK_DGRAM. The
> latter for a socket pair will return ENOBUF if you try to push more than
> the receiving side can handle so we should not have IPC message loss.
> This way, we can push request groups naturally instead of relying on a
> "last" flag and keeping track of that for "end of request".

The pipe is currently a socketpair. UML just calls it "pipe". :-(

> It will be easier to roll back the batching before we do that. Feel free
> to roll back that commit.
> 
> Once that is in, the whole batching will need to be redone as it should
> account for variable IPC record size and use sendmmsg/recvmmsg pair -
> same as in the vector IO. I am happy to do the honors on that one :)

Let's see what block guys say.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] [RFC] um: Convert ubd driver to blk-mq

[Richard Weinberger]

This is the first attempt to convert the UserModeLinux block driver
(UBD) to blk-mq.
While the conversion itself is rather trivial, a few questions
popped up in my head. Maybe you can help me with them.

MAX_SG is 64, used for blk_queue_max_segments(). This comes from
a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
value for blk-mq?

The driver does IO batching, for each request it issues many UML struct
io_thread_req request to the IO thread on the host side.
One io_thread_req per SG page.
Before the conversion the driver used blk_end_request() to indicate that
a part of the request is done.
blk_mq_end_request() does not take a length parameter, therefore we can
only mark the whole request as done. See the new is_last property on the
driver.
Maybe there is a way to partially end requests too in blk-mq?

Another obstacle with IO batching is that UML IO thread requests can
fail. Not only due to OOM, also because the pipe between the UML kernel
process and the host IO thread can return EAGAIN.
In this case the driver puts the request into a list and retried later
again when the pipe turns writable.
I’m not sure whether this restart logic makes sense with blk-mq, maybe
there is a way in blk-mq to put back a (partial) request?

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 arch/um/drivers/ubd_kern.c | 188 ++---
 1 file changed, 107 insertions(+), 81 deletions(-)

diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 90034acace2a..abbfe0c97418 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,6 +58,7 @@ struct io_thread_req {
unsigned long long cow_offset;
unsigned long bitmap_words[2];
int error;
+   bool is_last;
 };
 
 
@@ -142,7 +144,6 @@ struct cow {
 #define MAX_SG 64
 
 struct ubd {
-   struct list_head restart;
/* name (and fd, below) of the file opened for writing, either the
 * backing or the cow file. */
char *file;
@@ -156,9 +157,12 @@ struct ubd {
struct cow cow;
struct platform_device pdev;
struct request_queue *queue;
+   struct blk_mq_tag_set tag_set;
spinlock_t lock;
+};
+
+struct ubd_pdu {
struct scatterlist sg[MAX_SG];
-   struct request *request;
int start_sg, end_sg;
sector_t rq_pos;
 };
@@ -182,10 +186,6 @@ struct ubd {
.shared =   0, \
.cow =  DEFAULT_COW, \
.lock = __SPIN_LOCK_UNLOCKED(ubd_devs.lock), \
-   .request =  NULL, \
-   .start_sg = 0, \
-   .end_sg =   0, \
-   .rq_pos =   0, \
 }
 
 /* Protected by ubd_lock */
@@ -196,6 +196,12 @@ static int fake_ide = 0;
 static struct proc_dir_entry *proc_ide_root = NULL;
 static struct proc_dir_entry *proc_ide = NULL;
 
+static blk_status_t ubd_queue_rq(struct blk_mq_hw_ctx *hctx,
+const struct blk_mq_queue_data *bd);
+static int ubd_init_request(struct blk_mq_tag_set *set,
+   struct request *req, unsigned int hctx_idx,
+   unsigned int numa_node);
+
 static void make_proc_ide(void)
 {
proc_ide_root = proc_mkdir("ide", NULL);
@@ -448,11 +454,8 @@ __uml_help(udb_setup,
 "in the boot output.\n\n"
 );
 
-static void do_ubd_request(struct request_queue * q);
-
 /* Only changed by ubd_init, which is an initcall. */
 static int thread_fd = -1;
-static LIST_HEAD(restart);
 
 /* Function to read several request pointers at a time
 * handling fractional reads if (and as) needed
@@ -510,9 +513,6 @@ static int bulk_req_safe_read(
 /* Called without dev->lock held, and only in interrupt context. */
 static void ubd_handler(void)
 {
-   struct ubd *ubd;
-   struct list_head *list, *next_ele;
-   unsigned long flags;
int n;
int count;
 
@@ -532,23 +532,22 @@ static void ubd_handler(void)
return;
}
for (count = 0; count < n/sizeof(struct io_thread_req *); 
count++) {
-   blk_end_request(
-   (*irq_req_buffer)[count]->req,
-   BLK_STS_OK,
-   (*irq_req_buffer)[count]->length
-   );
-   kfree((*irq_req_buffer)[count]);
+   struct io_thread_req *io_req = (*irq_req_buffer)[count];
+
+   /*
+* UBD is batching IO, only end the blk mq request
+* if this is the last one.
+*/
+   if (io_req->is_last)
+   blk_mq_end_request(io_req->req,
+ 

Re: [uml-devel] [GIT PULL] UBI/UBIFS updates for 4.15-rc1

[Richard Weinberger]

Linus,

Am Freitag, 24. November 2017, 04:41:37 CET schrieb Linus Torvalds:
> On Thu, Nov 23, 2017 at 4:37 AM, Richard Weinberger <rich...@nod.at> wrote:
> >   git://git.infradead.org/linux-ubifs.git tags/upstream-4.15-rc1
> 
> Similarly to the arch/um case, none of this seems to have been in
> linux-next, and is sent late in the merge window, so I'm skipping it.

It is since next-20171120 in linux-next.
I'm sorry for being late, will do a better job next time.

If you don't mind I'll send you a PR with bug fixes for 4.15-rc2.
Same for UML.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [GIT PULL] UML updates for 4.15-rc1

[Richard Weinberger]

Linus,


The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4:

  Linux 4.14 (2017-11-12 10:46:13 -0800)

are available in the git repository at:

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

for you to fetch changes up to 02eb0b11eab56b47bcc36aa04dd522786c8faab9:

  um: Add missing EXPORT for free_irq_by_fd() (2017-11-22 15:20:56 +0100)


This pull request contains updates for UML:
- A new and faster epoll based IRQ controller and NIC driver
- Misc fixes and janitorial updates


Anton Ivanov (3):
  Epoll based IRQ controller
  High Performance UML Vector Network Driver
  um: Add missing EXPORT for free_irq_by_fd()

Arnd Bergmann (1):
  um: time: Use timespec64 for persistent clock

Geert Uytterhoeven (1):
  um: Restore symbol versions for __memcpy and memcpy

Kees Cook (1):
  um: net: Convert timers to use timer_setup()

Krzysztof Mazur (1):
  um: Use POSIX ucontext_t instead of struct ucontext

 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   |   13 +-
 arch/um/drivers/random.c |   11 +-
 arch/um/drivers/ubd_kern.c   |4 +-
 arch/um/drivers/vector_kern.c| 1630 +
+
 arch/um/drivers/vector_kern.h|  129 +++
 arch/um/drivers/vector_transports.c  |  458 ++
 arch/um/drivers/vector_user.c|  586 
 arch/um/drivers/vector_user.h|   99 +++
 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/irq.c   |  202 +++--
 arch/um/os-Linux/signal.c|2 +-
 arch/x86/um/stub_segv.c  |2 +-
 22 files changed, 3387 insertions(+), 330 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


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] PATCH v11-2

[Richard Weinberger]

Am Mittwoch, 22. November 2017, 14:09:11 CET schrieb anton.ivanov@kot-
begemot.co.uk:
> Resending patchset v11 versus Linux Next 20171121

Erm, you sent me again full patches.
*confused*

Version 10 is in linux-next, now we have to deal with the fallout.
Otherwise I have to revert.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] PATCH v11

[Richard Weinberger]

Am Mittwoch, 22. November 2017, 12:57:21 CET schrieb anton.ivanov@kot-
begemot.co.uk:
> This revision adds EXPORT for deactivate_irq_by_fd as needed
> by the random driver with some kernel configs

Please patchs ontop of linux-next.
Rebasing linux-next is not nice.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v9 2/2] High Performance UML Vector Network Driver

[Richard Weinberger]

Anton,

Am Montag, 20. November 2017, 08:39:25 CET schrieb anton.ivanov@kot-
begemot.co.uk:
> +#define VECTOR_NUM_STATS ARRAY_SIZE(ethtool_stats_keys)
> +
> +/* Used in the 4.4 OpenWRT backport */
> +
> +#if LINUX_VERSION_CODE <= KERNEL_VERSION(4, 7, 0)
> +static inline void netif_trans_update(struct net_device *dev)
> +{
> + struct netdev_queue *txq = netdev_get_tx_queue(dev, 0);
> +
> + if (txq->trans_start != jiffies)
> + txq->trans_start = jiffies;
> +}
> +#endif

Didn't checkpatch.pl puke here?

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: use POSIX ucontext_t instead of struct ucontext

[Richard Weinberger]

Am Mittwoch, 15. November 2017, 12:04:16 CET schrieb Krzysztof Mazur:
> On Wed, Nov 15, 2017 at 11:19:41AM +0100, Richard Weinberger wrote:
> > Am Mittwoch, 15. November 2017, 11:12:39 CET schrieb Krzysztof Mazur:
> > > glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance
> > > and break programs, including User Mode Linux. Fix User Mode Linux
> > > by using POSIX ucontext_t.
> > > 
> > > This fixes:
> > > 
> > > arch/um/os-Linux/signal.c: In function 'hard_handler':
> > > arch/um/os-Linux/signal.c:163:22: error: dereferencing pointer to
> > > incomplete type 'struct ucontext' mcontext_t *mc = >uc_mcontext;
> > > arch/x86/um/stub_segv.c: In function 'stub_segv_handler':
> > > arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to
> > > incomplete
> > > type 'struct ucontext' >uc_mcontext);
> > 
> > Do all older glibcs have ucontext_t?
> > Otherwise this patch will break other stuff.
> 
> Yes, ucontext_t typedef was always available. They changed:
> 
> typedef struct ucontext { ... } ucontex_t;
> 
> to
> 
> typedef struct ucontext_t { ... } ucontex_t;
> 
> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27struct_ucontext
> .27

Okay, then we can mark your patch as stable and hope for the best. ;-)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: use POSIX ucontext_t instead of struct ucontext

[Richard Weinberger]

Am Mittwoch, 15. November 2017, 11:12:39 CET schrieb Krzysztof Mazur:
> glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance
> and break programs, including User Mode Linux. Fix User Mode Linux
> by using POSIX ucontext_t.
> 
> This fixes:
> 
> arch/um/os-Linux/signal.c: In function 'hard_handler':
> arch/um/os-Linux/signal.c:163:22: error: dereferencing pointer to incomplete
> type 'struct ucontext' mcontext_t *mc = >uc_mcontext;
> arch/x86/um/stub_segv.c: In function 'stub_segv_handler':
> arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to incomplete
> type 'struct ucontext' >uc_mcontext);

Do all older glibcs have ucontext_t?
Otherwise this patch will break other stuff.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix kcov crash before kernel is started.

[Richard Weinberger]

Am Samstag, 14. Oktober 2017, 00:00:25 CEST schrieb Thomas Meyer:
> UMLs current_thread_info() unconditionally assumes that the top of the stack
> contains the thread_info structure.
> Prevent kcov from using invalid curent_thread_info() data by disable
> instrumentation of early startup code.
> 
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/kernel/skas/Makefile | 2 ++
>  lib/Makefile | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/um/kernel/skas/Makefile b/arch/um/kernel/skas/Makefile
> index 0b76d8869c94..df3aedb974a2 100644
> --- a/arch/um/kernel/skas/Makefile
> +++ b/arch/um/kernel/skas/Makefile
> @@ -3,6 +3,8 @@
>  # Licensed under the GPL
>  #
> 
> +KCOV_INSTRUMENT:= n

So, you disable kconv for the whole SKAS code?
That's a bit broad. ;-\

>  obj-y := clone.o mmu.o process.o syscall.o uaccess.o
> 
>  # clone.o is in the stub, so it can't be built with profiling
> diff --git a/lib/Makefile b/lib/Makefile
> index dafa79613fb4..18319ad5daab 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -16,6 +16,10 @@ KCOV_INSTRUMENT_list_debug.o := n
>  KCOV_INSTRUMENT_debugobjects.o := n
>  KCOV_INSTRUMENT_dynamic_debug.o := n
> 
> +ifdef CONFIG_UML
> +KCOV_INSTRUMENT_cmdline.o := n
> +endif
> +

huh? Why do we need an exception for UML here?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix kcov crash before kernel is started.

[Richard Weinberger]

Am Sonntag, 8. Oktober 2017, 12:31:58 CEST schrieb Thomas Meyer:
> UMLs current_thread_info() unconditionally assumes that the top of the stack
> contains the thread_info structure. But on UML the __sanitizer_cov_trace_pc
> function is called for *all* functions! This results in an early crash:
> 
> Prevent kcov from using invalid curent_thread_info() data by checking
> the system_state.
> 
> Signed-off-by: Thomas Meyer 
> ---
>  kernel/kcov.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 3f693a0f6f3e..d601c0e956f6 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -56,6 +56,12 @@ void notrace __sanitizer_cov_trace_pc(void)
>   struct task_struct *t;
>   enum kcov_mode mode;
> 
> +#ifdef CONFIG_UML
> + if(!(system_state == SYSTEM_SCHEDULING ||
> +  system_state == SYSTEM_RUNNING))
> + return;
> +#endif

Hmm, and why does it work on all other archs then?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 02/14] um: Use %pS printk format for symbols from direct addresses

[Richard Weinberger]

On Tue, Sep 12, 2017 at 2:10 PM, Petr Mladek <pmla...@suse.com> wrote:
> On Wed 2017-09-06 22:27:49, Helge Deller wrote:
>> Use the %pS printk format for printing symbols from direct addresses.
>> In usermode-linux there is actually no difference between %pS and %pF, but 
>> for
>> consistency throughout the kernel fix the wrong usage here too.
>>
>> Signed-off-by: Helge Deller <del...@gmx.de>
>> Cc: Jeff Dike <jd...@addtoit.com>
>> Cc: Richard Weinberger <rich...@nod.at>
>> Cc: user-mode-linux-devel@lists.sourceforge.net
>> ---
>>  arch/um/kernel/sysrq.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
>> index 6b995e8..05585ee 100644
>> --- a/arch/um/kernel/sysrq.c
>> +++ b/arch/um/kernel/sysrq.c
>> @@ -20,7 +20,7 @@
>>
>>  static void _print_addr(void *data, unsigned long address, int reliable)
>>  {
>> - pr_info(" [<%08lx>] %s%pF\n", address, reliable ? "" : "? ",
>> + pr_info(" [<%08lx>] %s%pS\n", address, reliable ? "" : "? ",
>>   (void *)address);
>
> This seems to be used to print addresses from the stack.
> IMHO, we should use %pB here.

%pWTF? ;)

Agreed, let's use %pB.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [GIT PULL] UML updates for 4.14-rc1

[Richard Weinberger]

Linus,

The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261:

  Linux 4.13 (2017-09-03 13:56:17 -0700)

are available in the git repository at:

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

for you to fetch changes up to 6d20e6b235aad0be463b23588093b079362bb2e4:

  um: return negative in tuntap_open_tramp() (2017-09-13 22:36:50 +0200)


This pull request contains updates for UML:
- Minor improvements
- Fixes for Debian's new gcc defaults (pie enabled by default)
- Fixes for XSTATE/XSAVE to make UML work again on modern systems


Dan Carpenter (2):
  um: remove a stray tab
  um: return negative in tuntap_open_tramp()

James Pack (1):
  Fix minor typos and grammar in UML start_up help

Krzysztof Kozlowski (1):
  um: defconfig: Cleanup from old Kconfig options

Thomas Meyer (4):
  um: Fix FP register size for XSTATE/XSAVE
  um: Fix CONFIG_GCOV for modules.
  um: link vmlinux with -no-pie
  um: Use relative modversions with LD_SCRIPT_DYN

 arch/um/Kconfig.um |  1 +
 arch/um/Makefile   |  2 +-
 arch/um/configs/i386_defconfig |  1 -
 arch/um/configs/x86_64_defconfig   |  1 -
 arch/um/include/asm/thread_info.h  |  3 +++
 arch/um/include/shared/os.h|  2 +-
 arch/um/kernel/gmon_syms.c |  7 +++
 arch/um/kernel/process.c   |  4 ++--
 arch/um/os-Linux/drivers/tuntap_user.c |  2 +-
 arch/um/os-Linux/skas/process.c| 17 -
 arch/um/os-Linux/start_up.c|  6 +++---
 arch/x86/um/os-Linux/registers.c   | 18 --
 arch/x86/um/os-Linux/tls.c |  2 +-
 arch/x86/um/user-offsets.c |  2 +-
 14 files changed, 41 insertions(+), 27 deletions(-)


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [GIT PULL] UML fixes for 4.13-rc7

[Richard Weinberger]

Linus,

The following changes since commit 14ccee78fc82f5512908f4424f541549a5705b89:

  Linux 4.13-rc6 (2017-08-20 14:13:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.13-rc7

for you to fetch changes up to 2fb44600fe784449404c6639de26af8361999ec7:

  um: Fix check for _xstate for older hosts (2017-08-24 21:52:28 +0200)


This pull request contains a single fix for a regression which
was introduced while the merge window.



Florian Fainelli (1):
  um: Fix check for _xstate for older hosts

 arch/x86/um/user-offsets.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [GIT PULL] UML updates for 4.13-rc1

[Richard Weinberger]

Linus,

The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:

  Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)

are available in the git repository at:

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

for you to fetch changes up to 61e8d462457f202bf0c6393133425ad387825e22:

  um: Correctly check for PTRACE_GETRESET/SETREGSET (2017-07-10 22:58:06 +0200)


This pull request contains mostly fixes for UML:
- First round of fixes for PTRACE_GETRESET/SETREGSET
- A printf vs. printk cleanup
- Minor improvements


Florian Fainelli (2):
  um: Avoid longjmp/setjmp symbol clashes with libpthread.a
  um: Allow building and running on older hosts

Logan Gunthorpe (1):
  um: add dummy ioremap and iounmap functions

Masami Hiramatsu (6):
  um: Use printk instead of printf in make_uml_dir
  um: Add os_info() for pre-boot information messages
  um: Use os_info for the messages on normal path
  um: Add os_warn() for pre-boot warning/error messages
  um: Use os_warn to print out pre-boot warning/error messages
  um: console: Ignore console= option

Richard Weinberger (1):
  um: Correctly check for PTRACE_GETRESET/SETREGSET

Thomas Meyer (5):
  um: userspace - be more verbose in ptrace set regs error
  um: stub-data.h: remove superfluous include
  um: Add kerneldoc for segv_handler
  um: Add kerneldoc for userspace_tramp() and start_userspace()
  um: v2: Use generic NOTES macro

 arch/um/Makefile|  4 
 arch/um/drivers/stdio_console.c |  3 +++
 arch/um/include/asm/common.lds.S|  2 +-
 arch/um/include/asm/io.h| 17 ++
 arch/um/include/shared/os.h |  4 
 arch/um/include/shared/skas/stub-data.h |  2 --
 arch/um/kernel/physmem.c| 10 
 arch/um/kernel/trap.c   | 10 
 arch/um/kernel/um_arch.c| 16 +++--
 arch/um/kernel/umid.c   |  4 ++--
 arch/um/os-Linux/execvp.c   |  2 +-
 arch/um/os-Linux/main.c |  9 
 arch/um/os-Linux/mem.c  | 28 +++---
 arch/um/os-Linux/skas/process.c | 41 ++---
 arch/um/os-Linux/start_up.c | 28 +++---
 arch/um/os-Linux/umid.c | 19 ---
 arch/um/os-Linux/util.c | 34 +++
 arch/x86/um/os-Linux/registers.c| 12 ++
 arch/x86/um/setjmp_32.S | 16 ++---
 arch/x86/um/setjmp_64.S | 16 ++---
 arch/x86/um/user-offsets.c  |  6 -
 21 files changed, 201 insertions(+), 82 deletions(-)
 create mode 100644 arch/um/include/asm/io.h

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] um: Re-enable verbose panic()

[Richard Weinberger]

Commit 9a93848fe787 ("x86/debug: Implement __WARN() using UD0")
rightfully removed GENERIC_BUG from UML because UML didn't use
that feature.
A side effect of this is that DEBUG_BUGVERBOSE no longer
set and therefore panic() doesn't print a stack trace.

Let's select DEBUG_BUGVERBOSE manually to have a verbose panic()
again.

Cc: Peter Zijlstra (Intel) <pet...@infradead.org>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 arch/um/Kconfig.common | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 85f6dd204ab6..3cb6cd80ee4c 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -13,6 +13,8 @@ config UML
select GENERIC_CLOCKEVENTS
select HAVE_GCC_PLUGINS
select TTY # Needed for line.c
+   select HAVE_DEBUG_BUGVERBOSE
+   select DEBUG_BUGVERBOSE
 
 config MMU
bool
-- 
2.12.3


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: v3: Fix FP register size for XSTATE/XSAVE

[Richard Weinberger]

Thomas,

what about something like that? (untested)
Still not very pretty but IMHO better.

diff --git a/arch/um/include/asm/thread_info.h 
b/arch/um/include/asm/thread_info.h
index 053baff03674..9300f7630d2a 100644
--- a/arch/um/include/asm/thread_info.h
+++ b/arch/um/include/asm/thread_info.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 

 struct thread_info {
struct task_struct  *task;  /* main task structure */
@@ -22,6 +23,8 @@ struct thread_info {
   0-0xBFFF for user
   0-0x for kernel */
struct thread_info  *real_thread;/* Points to non-IRQ stack */
+   unsigned long aux_fp_regs[FP_SIZE]; /* auxiliary fp_regs to 
save/restore
+  them out-of-band */
 };

 #define INIT_THREAD_INFO(tsk)  \
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index cd1fa97776c3..c1d4b6fbc919 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -274,7 +274,7 @@ extern int protect(struct mm_id * mm_idp, unsigned long 
addr,
 extern int is_skas_winch(int pid, int fd, void *data);
 extern int start_userspace(unsigned long stub_stack);
 extern int copy_context_skas0(unsigned long stack, int pid);
-extern void userspace(struct uml_pt_regs *regs);
+extern void userspace(struct uml_pt_regs *regs, unsigned long *aux_fp_regs);
 extern int map_stub_pages(int fd, unsigned long code, unsigned long data,
  unsigned long stack);
 extern void new_thread(void *stack, jmp_buf *buf, void (*handler)(void));
diff --git a/arch/um/kernel/process.c b/arch/um/kernel/process.c
index 2c7f721eccbc..691b83b10649 100644
--- a/arch/um/kernel/process.c
+++ b/arch/um/kernel/process.c
@@ -131,7 +131,7 @@ void new_thread_handler(void)
 * callback returns only if the kernel thread execs a process
 */
n = fn(arg);
-   userspace(>thread.regs.regs);
+   userspace(>thread.regs.regs, 
current_thread_info()->aux_fp_regs);
 }

 /* Called magically, see new_thread_handler above */
@@ -150,7 +150,7 @@ void fork_handler(void)

current->thread.prev_sched = NULL;

-   userspace(>thread.regs.regs);
+   userspace(>thread.regs.regs, 
current_thread_info()->aux_fp_regs);
 }

 int copy_thread(unsigned long clone_flags, unsigned long sp,
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index 03b3c4cc7735..d92a0240dce4 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -88,12 +88,11 @@ void wait_stub_done(int pid)

 extern unsigned long current_stub_stack(void);

-static void get_skas_faultinfo(int pid, struct faultinfo *fi)
+static void get_skas_faultinfo(int pid, struct faultinfo *fi, unsigned long 
*aux_fp_regs)
 {
int err;
-   unsigned long fpregs[FP_SIZE];

-   err = get_fp_registers(pid, fpregs);
+   err = get_fp_registers(pid, aux_fp_regs);
if (err < 0) {
printk(UM_KERN_ERR "save_fp_registers returned %d\n",
   err);
@@ -113,7 +112,7 @@ static void get_skas_faultinfo(int pid, struct faultinfo 
*fi)
 */
memcpy(fi, (void *)current_stub_stack(), sizeof(*fi));

-   err = put_fp_registers(pid, fpregs);
+   err = put_fp_registers(pid, aux_fp_regs);
if (err < 0) {
printk(UM_KERN_ERR "put_fp_registers returned %d\n",
   err);
@@ -121,9 +120,9 @@ static void get_skas_faultinfo(int pid, struct faultinfo 
*fi)
}
 }

-static void handle_segv(int pid, struct uml_pt_regs * regs)
+static void handle_segv(int pid, struct uml_pt_regs *regs, unsigned long 
*aux_fp_regs)
 {
-   get_skas_faultinfo(pid, >faultinfo);
+   get_skas_faultinfo(pid, >faultinfo, aux_fp_regs);
segv(regs->faultinfo, 0, 1, NULL);
 }

@@ -303,7 +302,7 @@ int start_userspace(unsigned long stub_stack)
return err;
 }

-void userspace(struct uml_pt_regs *regs)
+void userspace(struct uml_pt_regs *regs, unsigned long *aux_fp_regs)
 {
int err, status, op, pid = userspace_pid[0];
/* To prevent races if using_sysemu changes under us.*/
@@ -372,11 +371,11 @@ void userspace(struct uml_pt_regs *regs)
case SIGSEGV:
if (PTRACE_FULL_FAULTINFO) {
get_skas_faultinfo(pid,
-  >faultinfo);
+  >faultinfo, 
aux_fp_regs);
(*sig_info[SIGSEGV])(SIGSEGV, (struct 
siginfo *),
 regs);
}
-   else handle_segv(pid, regs);
+   else handle_segv(pid, regs, aux_fp_regs);

Re: [uml-devel] [PATCH] um: v3: Fix FP register size for XSTATE/XSAVE

[Richard Weinberger]

Thomas,

Am 12.07.2017 um 17:11 schrieb Thomas Meyer:
> Am 10.07.2017 9:06 nachm. schrieb Richard Weinberger <rich...@nod.at>:
> 
> Thomas,
> 
> Am 10.07.2017 um 00:33 schrieb Thomas Meyer:
> > Hard code max size. Taken from
> > 
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/common/x86-xstate.h
> >
> > v3: use static fp_regs for get_skas_faultinfo
> >
> > Signed-off-by: Thomas Meyer <tho...@m3y3r.de>
> > ---
> >  arch/um/os-Linux/skas/process.c  |  7 ---
> >  arch/x86/um/os-Linux/registers.c | 18 --
> >  arch/x86/um/user-offsets.c   |  2 +-
> >  3 files changed, 17 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/um/os-Linux/skas/process.c 
> b/arch/um/os-Linux/skas/process.c
> > index 03b3c4cc7735..b5fdef795985 100644
> > --- a/arch/um/os-Linux/skas/process.c
> > +++ b/arch/um/os-Linux/skas/process.c
> > @@ -88,12 +88,13 @@ void wait_stub_done(int pid)
> > 
> >  extern unsigned long current_stub_stack(void);
> > 
> > +static unsigned long skas_faultinfo_fpregs[FP_SIZE];
> > +
> 
> Uhmm, are you sure that this does not race with other userspace() 
> instances?
> 
> Oh, is it really possible that a task gets schedule while we are in userspace 
> signal handling from ptrace?

I hoped that you'd double check. ;)
>From my knowledge it is not possible, but this code was not written by me and 
>UML internal
semantics are more than tricky.
Let's postpone this patch for -rc2 and check again.

> Another question: when malloc a memory area in userspace: when does a 
> userspace process end in userspace function!? Where would you free the 
> malloced memory?

It ends via handle_trap() when userspac does an exit syscall.
I agree this is tricky to catch and needs more effort.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: v2: Fix FP register size for XSTATE/XSAVE

[Richard Weinberger]

Thomas,

On Fri, Jul 7, 2017 at 11:01 PM, Thomas Meyer  wrote:
> Hard code max size. Taken from
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/common/x86-xstate.h
>
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/os-Linux/skas/process.c  | 22 ++
>  arch/x86/um/os-Linux/registers.c | 16 +++-
>  arch/x86/um/user-offsets.c   |  2 +-
>  3 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
> index 03b3c4cc7735..1a7cce387950 100644
> --- a/arch/um/os-Linux/skas/process.c
> +++ b/arch/um/os-Linux/skas/process.c
> @@ -91,19 +91,25 @@ extern unsigned long current_stub_stack(void);
>  static void get_skas_faultinfo(int pid, struct faultinfo *fi)
>  {
> int err;
> -   unsigned long fpregs[FP_SIZE];
> +   void * fpregs;
> +
> +   fpregs = malloc(FP_SIZE * sizeof(unsigned long));
> +   if(fpregs == NULL) {
> +   printk(UM_KERN_ERR "cannot alloc memory for 
> save_fp_registers!");
> +   goto errout;
> +   }

Having a malloc() here is rather expensive.
I suggest to allocate a buffer in userspace() that can be used in
get_skas_faultinfo().

Thanks,
//richard
-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix gcc-plugins dependency

[Richard Weinberger]

Thomas,

Am 07.07.2017 um 23:10 schrieb Thomas Meyer:
> Ensure to build the gcc-plugins for user-offsets.s
> 
> Signed-off-by: Thomas Meyer 

Please describe the problem what this commit solves.
IOW the compiler error.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix gcc 7 sys/sysmacros.h warning

[Richard Weinberger]

Am 07.07.2017 um 12:01 schrieb Thomas Meyer:
> Should I resend with warning as v2?

Yes, please.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix FP register size for XSTATE/XSAVE

[Richard Weinberger]

On Fri, Jul 7, 2017 at 11:26 AM, Richard Weinberger
<richard.weinber...@gmail.com> wrote:
> On Thu, Jul 6, 2017 at 11:04 PM, Thomas Meyer <tho...@m3y3r.de> wrote:
>> Hard code max size. Taken from
>> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/common/x86-xstate.h
>>
>> Signed-off-by: Thomas Meyer <tho...@m3y3r.de>
>> ---
>>  arch/x86/um/os-Linux/registers.c | 9 -
>>  arch/x86/um/user-offsets.c   | 2 +-
>>  2 files changed, 5 insertions(+), 6 deletions(-)
>
> Applied. Thanks a lot for taking care of this nasty issue!

Erm, did you notice the scary compiler warning produced by this commit? :-(

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: v2: Use generic NOTES macro

[Richard Weinberger]

On Fri, Jul 7, 2017 at 11:17 AM, Thomas Meyer  wrote:
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/include/asm/common.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix FP register size for XSTATE/XSAVE

[Richard Weinberger]

On Thu, Jul 6, 2017 at 11:04 PM, Thomas Meyer  wrote:
> Hard code max size. Taken from
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/common/x86-xstate.h
>
> Signed-off-by: Thomas Meyer 
> ---
>  arch/x86/um/os-Linux/registers.c | 9 -
>  arch/x86/um/user-offsets.c   | 2 +-
>  2 files changed, 5 insertions(+), 6 deletions(-)

Applied. Thanks a lot for taking care of this nasty issue!

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix gcc 7 sys/sysmacros.h warning

[Richard Weinberger]

On Thu, Jul 6, 2017 at 10:47 PM, Thomas Meyer  wrote:
> Signed-off-by: Thomas Meyer 

When fixing such a problem, always include die compiler warning.
This has to wait for -rc2.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

On Thu, Jul 6, 2017 at 12:34 AM, Thomas Meyer  wrote:
> Also use correct function name spelling (stub_segv_handler) for better 
> grepping
>
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/os-Linux/skas/process.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)

Series applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: userspace - be more verbose in ptrace set regs error

[Richard Weinberger]

On Thu, Jul 6, 2017 at 12:31 AM, Thomas Meyer  wrote:
> When ptrace fails to set GP/FP regs for the target process,
> log the error before crashing the UML kernel.
>
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/os-Linux/skas/process.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml:linux-next 7/9] arch/um/os-Linux/skas/process.c:579:1: warning: control reaches end of non-void function

[Richard Weinberger]

Am 06.07.2017 um 07:48 schrieb kbuild test robot:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git linux-next
> head:   1bcbfbfdeb0091036db7a32e1cd31b49cce5983a
> commit: f44f1e7da7c8e3f4575d5d61c4df978496903fcc [7/9] um: Avoid 
> longjmp/setjmp symbol clashes with libpthread.a
> config: um-x86_64_defconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout f44f1e7da7c8e3f4575d5d61c4df978496903fcc
> # save the attached .config to linux build tree
> make ARCH=um SUBARCH=x86_64
> 
> All warnings (new ones prefixed by >>):
> 
>arch/um/os-Linux/skas/process.c: In function 'start_idle_thread':
>>> arch/um/os-Linux/skas/process.c:579:1: warning: control reaches end of 
>>> non-void function [-Wreturn-type]
> }
> ^
> 
> vim +579 arch/um/os-Linux/skas/process.c
> 
> abaf6977 Gennady Sharapov 2006-01-18  563 case INIT_JMP_CALLBACK:
> abaf6977 Gennady Sharapov 2006-01-18  564 (*cb_proc)(cb_arg);
> 77f6af77 Jeff Dike2007-05-06  565 longjmp(*cb_back, 1);
> abaf6977 Gennady Sharapov 2006-01-18  566 break;
> abaf6977 Gennady Sharapov 2006-01-18  567 case INIT_JMP_HALT:
> abaf6977 Gennady Sharapov 2006-01-18  568 kmalloc_ok = 0;
> ba180fd4 Jeff Dike2007-10-16  569 return 0;
> abaf6977 Gennady Sharapov 2006-01-18  570 case INIT_JMP_REBOOT:
> abaf6977 Gennady Sharapov 2006-01-18  571 kmalloc_ok = 0;
> ba180fd4 Jeff Dike2007-10-16  572 return 1;
> abaf6977 Gennady Sharapov 2006-01-18  573 default:
> 3e6f2ac4 Jeff Dike2008-02-04  574 printk(UM_KERN_ERR "Bad 
> sigsetjmp return in "
> 3e6f2ac4 Jeff Dike2008-02-04  575
> "start_idle_thread - %d\n", n);
> 3e6f2ac4 Jeff Dike2008-02-04  576 fatal_sigsegv();
> abaf6977 Gennady Sharapov 2006-01-18  577 }
> 77f6af77 Jeff Dike2007-05-06  578 longjmp(*switch_buf, 1);
> abaf6977 Gennady Sharapov 2006-01-18 @579  }
> abaf6977 Gennady Sharapov 2006-01-18  580  
> abaf6977 Gennady Sharapov 2006-01-18  581  void initial_thread_cb_skas(void 
> (*proc)(void *), void *arg)
> abaf6977 Gennady Sharapov 2006-01-18  582  {
> ad28e029 Jeff Dike2006-04-18  583 jmp_buf here;
> abaf6977 Gennady Sharapov 2006-01-18  584  
> abaf6977 Gennady Sharapov 2006-01-18  585 cb_proc = proc;
> abaf6977 Gennady Sharapov 2006-01-18  586 cb_arg = arg;
> abaf6977 Gennady Sharapov 2006-01-18  587 cb_back = 

I suggest this as fix:
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index 03b3c4cc7735..6869df60a722 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -576,6 +576,9 @@ int start_idle_thread(void *stack, jmp_buf *switch_buf)
fatal_sigsegv();
}
longjmp(*switch_buf, 1);
+
+   /* Unreachable */
+   return 0;
 }

Unless I miss something the idle thread never exits here.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: userspace - be more verbose in ptrace set regs error

[Richard Weinberger]

Thomas,

On Wed, May 24, 2017 at 12:45 AM, Thomas Meyer  wrote:
> When ptrace fails to set GP/FP regs for the target process,
> log the error before crashing the UML kernel.
>
> Signed-off-by: Thomas Meyer 
> ---
>  arch/um/os-Linux/skas/process.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
> index 4530867..819d686 100644
> --- a/arch/um/os-Linux/skas/process.c
> +++ b/arch/um/os-Linux/skas/process.c
> @@ -352,11 +352,17 @@ void userspace(struct uml_pt_regs *regs)
>  * fail.  In this case, there is nothing to do but
>  * just kill the process.
>  */
> -   if (ptrace(PTRACE_SETREGS, pid, 0, regs->gp))
> +   if (ptrace(PTRACE_SETREGS, pid, 0, regs->gp)) {
> +   printk(UM_KERN_ERR "userspace - ptrace set regs "
> +  "failed, errno = %d\n", errno);
> fatal_sigsegv();
> +   }
>
> -   if (put_fp_registers(pid, regs->fp))
> +   if (put_fp_registers(pid, regs->fp)) {
> +   printk(UM_KERN_ERR "userspace - ptrace set fp regs "
> +  "failed, errno = %d\n", errno);
> fatal_sigsegv();
> +   }
>
> /* Now we set local_using_sysemu to be used for one loop */
> local_using_sysemu = get_using_sysemu();
>
> --
> 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
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

This patch is also malformed. :-(

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

On Sun, May 14, 2017 at 5:03 PM, Thomas Meyer  wrote:
> Signed-off-by: Thomas Meyer 
> ---
>  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 
> -
>  struct stub_data {
>   unsigned long offset;
>   int fd;
>

All three patches are malformed and don't apply. :-(

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v3 0/6] um: Output messages to stderr and support quiet option

[Richard Weinberger]

Masami,

On Wed, May 17, 2017 at 7:13 PM, Masami Hiramatsu  wrote:
> Hello,
>
> Here is version 3 of um-quiet series. In this version
> I just fixed some printf format issues.
>
> V2 is here.
>
>  https://lkml.org/lkml/2017/5/8/35
>
> This series fixes some boot time printf output to stderr
> by adding os_info() and os_warn(). The information-level
> messages via os_info() are suppressed when "quiet" kernel
> option is specified.
> Also the last one allows user to pass "console=" option
> to kernel.
>
> Note that the output of --help and --version are still
> sent to stdout since they are intentionally shown by
> the user.
>
> Changes from v2:
>   - Cast rlim_min/max to unsigned long long explicitly
> for avoiding printf-format warning.
>   - Fix printf format in physmem.c so that it matches
> the type of arguments.
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (6):
>   um: Use printk instead of printf in make_uml_dir
>   um: Add os_info() for pre-boot information messages
>   um: Use os_info for the messages on normal path
>   um: Add os_warn() for pre-boot warning/error messages
>   um: Use os_warn to print out pre-boot warning/error messages
>   um: console: Ignore console= option
>
>

Series applied. Thanks!

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger]

Florian,

Am 29.06.2017 um 00:40 schrieb Florian Fainelli:
>> Hehe, yes.
>> This patch is good, I like it. :)
>> It will part of the next pull request.
> 
> Humm okay, did you apply the patch in one of your kernel trees on
> git.kernel.org or somewhere else?

Will happen soon since the merge window is near where I will post
a pull request...

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU

[Richard Weinberger]

Thomas, Natale,

Am 21.06.2017 um 11:44 schrieb Thomas Meyer:
>> It is funny to see that this problem was firstly reported here [1] in
>> February 2017 without being considered until someone else bought a
>> new
>> laptop :)

sometimes mails/issues get lost...

> Yes, I like my new laptop :-)
> 
>> Anyway, thank you for digging into this; my temporary workaround at
>> the time was to use always the *_i387_registers functions.
> 
> Oops, there is the complete thread with the same problem. But sorry I
> don't follow uml-user, just uml-devel :-(

We really should merge these lists. ;-\

> As a quick fix you can try this:
> 
> diff --git a/arch/x86/um/os-Linux/registers.c 
> b/arch/x86/um/os-Linux/registers.c
> index 00f54a91bb4b..6eac8220ab29 100644
> --- a/arch/x86/um/os-Linux/registers.c
> +++ b/arch/x86/um/os-Linux/registers.c
> @@ -30,7 +30,7 @@ int save_fp_registers(int pid, unsigned long *fp_regs)
>  
>   if (have_xstate_support) {
>   iov.iov_base = fp_regs;
> - iov.iov_len = sizeof(struct _xstate);
> + iov.iov_len = HOST_FP_SIZE * sizeof(unsigned long);
>   if (ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, ) < 0)
>   return -errno;
>   return 0;
> @@ -49,10 +49,9 @@ int restore_i387_registers(int pid, unsigned long *fp_regs)
>  int restore_fp_registers(int pid, unsigned long *fp_regs)
>  {
>   struct iovec iov;
> -
>   if (have_xstate_support) {
>   iov.iov_base = fp_regs;
> - iov.iov_len = sizeof(struct _xstate);
> + iov.iov_len = HOST_FP_SIZE * sizeof(unsigned long);
>   if (ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, ) < 0)
>   return -errno;
>   return 0;
> @@ -126,7 +125,7 @@ void arch_init_registers(int pid)
>   struct iovec iov;
>  
>   iov.iov_base = _regs;
> - iov.iov_len = sizeof(struct _xstate);
> + iov.iov_len = HOST_FP_SIZE * sizeof(unsigned long);
>   if (ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, ) == 0)
>   have_xstate_support = 1;
>  }
> diff --git a/arch/x86/um/user-offsets.c b/arch/x86/um/user-offsets.c
> index cb3c22370cf5..9dccbbbf2fd1 100644
> --- a/arch/x86/um/user-offsets.c
> +++ b/arch/x86/um/user-offsets.c
> @@ -50,7 +50,7 @@ void foo(void)
>   DEFINE(HOST_GS, GS);
>   DEFINE(HOST_ORIG_AX, ORIG_EAX);
>  #else
> - DEFINE(HOST_FP_SIZE, sizeof(struct _xstate) / sizeof(unsigned long));
> + DEFINE_LONGS(HOST_FP_SIZE, 2688);
>   DEFINE_LONGS(HOST_BX, RBX);
>   DEFINE_LONGS(HOST_CX, RCX);
>   DEFINE_LONGS(HOST_DI, RDI);
> 
> 
> a better fix would be to make the fp regs in struct uml_pt_regs dynamic
> depending on the current kernel idea of the xsave area size.

And we should consider a mechanism to save/restore the full regset only when 
needed.
Otherwise the context switch is even more slower.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU

[Richard Weinberger]

Yu-cheng,

Am 20.06.2017 um 20:17 schrieb Richard Weinberger:
> Yu-cheng,
> 
> Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
>>>> So to summarize:
>>>>
>>>> - PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, with no
>>>> error.
>>>>
>>>> - PTRACE_SETREGSET get 832 (sizeof struct _xstate) but wants at least
>>>> 1088, otherwise it will fail with -EFAULT (why not -EINVAL?)
>>>>
>>>> Ideas?
>>
>> We considered allowing a partial XSAVE buffer for PTRACE_SETREGSET, but
>> it was that the XSAVE instruction requires a full-size buffer led to
>> this choice.  Using a smaller buffer for XSAVE causes a fault.
> 
> So, this code is not supposed to work?
> 
> iov.iov_base = fp_regs;
> iov.iov_len = sizeof(struct _xstate);
> ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, );
> ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, );
> 
> This is what UML does and on Thomas's new Laptop PTRACE_SETREGSET is failing.

Hmm, I think we need to do what gdb does, it uses a buffer of size 
X86_XSTATE_MAX_SIZE.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU

[Richard Weinberger]

Yu-cheng,

Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
>>> So to summarize:
>>>
>>> - PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, with no
>>> error.
>>>
>>> - PTRACE_SETREGSET get 832 (sizeof struct _xstate) but wants at least
>>> 1088, otherwise it will fail with -EFAULT (why not -EINVAL?)
>>>
>>> Ideas?
> 
> We considered allowing a partial XSAVE buffer for PTRACE_SETREGSET, but
> it was that the XSAVE instruction requires a full-size buffer led to
> this choice.  Using a smaller buffer for XSAVE causes a fault.

So, this code is not supposed to work?

iov.iov_base = fp_regs;
iov.iov_len = sizeof(struct _xstate);
ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, );
ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, );

This is what UML does and on Thomas's new Laptop PTRACE_SETREGSET is failing.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU

[Richard Weinberger]

[adding x86 folks]

Am 20.06.2017 um 10:49 schrieb Thomas Meyer:
> Am Dienstag, den 20.06.2017, 08:58 +0200 schrieb Richard Weinberger:
>> Thomas,
>>
>> Am 20.06.2017 um 03:56 schrieb Thomas Meyer:
>>> Hi,
>>>
>>> I finally did figure out where in the host kernel the ptrace
>>> syscall
>>> fails with -EFAULT.
>>
>> Nice! Thanks a lot for digging into this. I still had no chance to
>> setup
>> Ipv6 to connect to your host and figure myself. ;-\
>>
>>> In arch/x86/kernel/fpu/regset.c:130:
>>>
>>> 114 int xstateregs_set(struct task_struct *target, const struct
>>> user_regset *regset,
>>> 115   unsigned int pos, unsigned int count,
>>> 116   const void *kbuf, const void __user *ubuf)
>>> 117 {
>>> 118 struct fpu *fpu = >thread.fpu;
>>> 119 struct xregs_state *xsave;
>>> 120 int ret;
>>> 121 
>>> 122 if (!boot_cpu_has(X86_FEATURE_XSAVE))
>>> 123 return -ENODEV;
>>> 124 
>>> 125 pr_info("in xstateregs_set");
>>> 126 
>>> 127 /*
>>> 128  * A whole standard-format XSAVE buffer is needed:
>>> 129  */
>>> 130 if ((pos != 0) || (count < fpu_user_xstate_size)) {
>>> 131 pr_info("EFAULT from xstateregs_set");
>>> 132->   pr_info("pos = %i, count = %i,
>>> fpu_user_xstate_size= %i\n", pos, count, fpu_user_xstate_size);
>>> 133 return -EFAULT;
>>> 134 }
>>>
>>> Sadly I had to fallback to debugging by printk because kgdb/qemu
>>> gdbstub, all didn't work for some unknown reason :-(
>>
>> As always. printk is best debugger ever. ;-)
>>
>>> output is:
>>> [   69.598349] EFAULT from xstateregs_set
>>> [   69.598350] pos = 0, count = 832, fpu_user_xstate_size= 1088
>>>
>>> calling code is in arch/x86/um/os-Linux/registers.c:
>>>
>>>  49 int restore_fp_registers(int pid, unsigned long *fp_regs)
>>>  50 {
>>>  51 struct iovec iov;
>>>  52 
>>>  53 if (have_xstate_support) {
>>>  54 iov.iov_base = fp_regs;
>>>  55 iov.iov_len = sizeof(struct _xstate);
>>>  56 if (ptrace(PTRACE_SETREGSET, pid,
>>> NT_X86_XSTATE, ) < 0)
>>>  57  -> return -errno;
>>>  58 return 0;
>>>  59 } else {
>>>  60 return restore_i387_registers(pid, fp_regs);
>>>  61 }
>>>  62 }
>>>
>>> it looks like _xstate is too short for above operation, I wonder
>>> why
>>> PTRACE_GETREGSET works without a warning of too short size.
>>
>> Does PTRACE_GETREGSET return a size?
> 
> Yes, it returns 832. the size of struct _xstate.
> 
>> Maybe we have to take this into account.
>> It could be that your host CPU has a smaller set.
>> Also check whether PTRACE_SETREGSET always fails.
> 
> In UML the first userspace ptrace always fails, so init get's killed.
> 
> The check "count < fpu_user_xstate_size" was introduced by commit:
> 
> commit 91c3dba7dbc199191272f4a9863f86ea3bfd679f
> Author: Yu-cheng Yu <yu-cheng...@intel.com>
> Date:   Fri Jun 17 13:07:17 2016 -0700
> 
> x86/fpu/xstate: Fix PTRACE frames for XSAVES
> 
> XSAVES uses compacted format and is a kernel instruction. The kernel
> should use standard-format, non-supervisor state data for PTRACE.
> 
> So to summarize:
> 
> - PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, with no
> error.
> 
> - PTRACE_SETREGSET get 832 (sizeof struct _xstate) but wants at least
> 1088, otherwise it will fail with -EFAULT (why not -EINVAL?)
> 
> Ideas?
> 
>>
>> 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU

[Richard Weinberger]

Thomas,

Am 20.06.2017 um 03:56 schrieb Thomas Meyer:
> Hi,
> 
> I finally did figure out where in the host kernel the ptrace syscall
> fails with -EFAULT.

Nice! Thanks a lot for digging into this. I still had no chance to setup
Ipv6 to connect to your host and figure myself. ;-\

> In arch/x86/kernel/fpu/regset.c:130:
> 
> 114 int xstateregs_set(struct task_struct *target, const struct user_regset 
> *regset,
> 115   unsigned int pos, unsigned int count,
> 116   const void *kbuf, const void __user *ubuf)
> 117 {
> 118 struct fpu *fpu = >thread.fpu;
> 119 struct xregs_state *xsave;
> 120 int ret;
> 121 
> 122 if (!boot_cpu_has(X86_FEATURE_XSAVE))
> 123 return -ENODEV;
> 124 
> 125 pr_info("in xstateregs_set");
> 126 
> 127 /*
> 128  * A whole standard-format XSAVE buffer is needed:
> 129  */
> 130 if ((pos != 0) || (count < fpu_user_xstate_size)) {
> 131 pr_info("EFAULT from xstateregs_set");
> 132->   pr_info("pos = %i, count = %i, fpu_user_xstate_size= 
> %i\n", pos, count, fpu_user_xstate_size);
> 133 return -EFAULT;
> 134 }
> 
> Sadly I had to fallback to debugging by printk because kgdb/qemu
> gdbstub, all didn't work for some unknown reason :-(

As always. printk is best debugger ever. ;-)

> output is:
> [   69.598349] EFAULT from xstateregs_set
> [   69.598350] pos = 0, count = 832, fpu_user_xstate_size= 1088
> 
> calling code is in arch/x86/um/os-Linux/registers.c:
> 
>  49 int restore_fp_registers(int pid, unsigned long *fp_regs)
>  50 {
>  51 struct iovec iov;
>  52 
>  53 if (have_xstate_support) {
>  54 iov.iov_base = fp_regs;
>  55 iov.iov_len = sizeof(struct _xstate);
>  56 if (ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, ) < 
> 0)
>  57  -> return -errno;
>  58 return 0;
>  59 } else {
>  60 return restore_i387_registers(pid, fp_regs);
>  61 }
>  62 }
> 
> it looks like _xstate is too short for above operation, I wonder why
> PTRACE_GETREGSET works without a warning of too short size.

Does PTRACE_GETREGSET return a size? Maybe we have to take this into account.
It could be that your host CPU has a smaller set.
Also check whether PTRACE_SETREGSET always fails.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: add dummy ioremap and iounmap functions

[Richard Weinberger]

Am 08.06.2017 um 20:53 schrieb Logan Gunthorpe:
> Any thoughts on this? My patches for the other architectures are already
> in linux-next. um is the only one that remains.

IMHO an ifdef in scatterlist code does not hurt.
It is equally ugly than mocking ioremap for UML.

So, I'm puzzled.
Arnd, what do you think?
Shall !HAS_IOMEM archs just mock these functions?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 22/35] um: defconfig: Cleanup from old Kconfig options

[Richard Weinberger]

Am 08.06.2017 um 18:10 schrieb Krzysztof Kozlowski:
> Remove old, dead Kconfig option INET_LRO. It is gone since
> commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library").
> 
> Signed-off-by: Krzysztof Kozlowski <k...@kernel.org>

Acked-by: Richard Weinberger <rich...@nod.at>

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger]

Florian,

Am 05.06.2017 um 21:32 schrieb Florian Fainelli:
> On 05/23/2017 05:32 PM, Florian Fainelli wrote:
>> Building a statically linked UML kernel on a Centos 6.9 host resulted in
>> the following linking failure (GCC 4.4, glibc-2.12):
>>
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>> In function `siglongjmp':
>> (.text+0x8490): multiple definition of `longjmp'
>> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
>> first defined here
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
>> In function `sem_open':
>> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
>> `mkstemp'
>> collect2: ld returned 1 exit status
>> make[4]: *** [vmlinux] Error 1
>>
>> Adopt a solution similar to the one done for vmap where we define
>> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
>> do rename the functions in arch/x86/um/setjmp_*.S accordingly.
>>
>> Fixes: a7df4716d195 ("um: link with -lpthread")
>> Signed-off-by: Florian Fainelli 
> 
> Richard, we are kind of hijacking this thread now that was originally
> about statically linking UML, is this particular patch okay?

Hehe, yes.
This patch is good, I like it. :)
It will part of the next pull request.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger]

Am 01.06.2017 um 22:15 schrieb Florian Fainelli:
> On 06/01/2017 01:11 PM, Richard Weinberger wrote:
>> Florian,
>>
>> Am 01.06.2017 um 21:38 schrieb Florian Fainelli:
>>>> Presumably because we are not using the same glibc version? The one I
>>>> have installed on this machine is glibc-2.12, do you want me to attach a
>>>> copy of it?
>>>
>>> Richard, what do we do with this?
>>
>> I'd like to see the issues that Thomas sees also get addressed.
> 
> Sure, but that seems orthogonal? In the absence of an answer from Eli,
> either you could take my patch or just send reverts of Eli's two
> commits, whichever you prefer.

Or you and Thomas could investigate. :-)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger]

Florian,

Am 01.06.2017 um 21:38 schrieb Florian Fainelli:
>> Presumably because we are not using the same glibc version? The one I
>> have installed on this machine is glibc-2.12, do you want me to attach a
>> copy of it?
> 
> Richard, what do we do with this?

I'd like to see the issues that Thomas sees also get addressed.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: add dummy ioremap and iounmap functions

[Richard Weinberger]

Logan,

Am 25.05.2017 um 17:42 schrieb Logan Gunthorpe:
> The user mode architecture does not provide ioremap or iounmap, and
> because of this, the arch won't build when the functions are used in some
> core libraries.

Which ones are failing?
I thought we killed the problem by making CONFIG_COMPILE_TEST depend on !UML.

> I have designs to use these functions in scatterlist.c where they'd
> almost certainly never be called on the um architecture but it does need
> to compile. Thus, if the function is ever hit it returns NULL.

I was never a fan of that approach because in my opinion drivers should have
proper dependencies, including a dependency on HAS_IOMEM.

But I'll no longer block these attempts if we can get rid of tons of fallout
every kernel release.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger]

Florian,

Am 24.05.2017 um 02:32 schrieb Florian Fainelli:
> Building a statically linked UML kernel on a Centos 6.9 host resulted in
> the following linking failure (GCC 4.4, glibc-2.12):
> 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `siglongjmp':
> (.text+0x8490): multiple definition of `longjmp'
> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `sem_open':
> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
> `mkstemp'
> collect2: ld returned 1 exit status
> make[4]: *** [vmlinux] Error 1
> 
> Adopt a solution similar to the one done for vmap where we define
> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
> do rename the functions in arch/x86/um/setjmp_*.S accordingly.

What is not so clear to me, why are you facing this build issue and other 
users, including me,
not?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: prinft patches from Masami Hiramatsu

[Richard Weinberger]

On Tue, May 23, 2017 at 7:56 PM, Thomas Meyer  wrote:
> Hi,
>
>
>
> did you see those patches?
>
>
>
> https://marc.info/?l=linux-kernel=149337486632399=2

Yes, they are on my TODO.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: xstate changes breaks my UML setup

[Richard Weinberger]

Thomas,

On Tue, May 23, 2017 at 7:56 PM, Thomas Meyer  wrote:
> Hi,
>
>
>
> to make UML work again with the latest Fedora Installation I Need to revert
> those commits:
>
> b6024b21fec8367ef961a771cc9dde31f1831965
>
> a78ff1112263fdd871d3506dbcff44f6f12e8423
>
>
>
> A reproducer script/config is available here:
>
> https://github.com/thomasmey/uml/blob/master/fedora-26-install.sh

Please start using the CC feature of your mailer. :-)

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Multiple longjmp definitions with STATIC_LINKING=y

[Richard Weinberger]

Florian,

Am 23.05.2017 um 05:28 schrieb Florian Fainelli:
> Hi Richard,
> 
> I have been playing with UML again and trying to get it to statically
> link on a CentOS 6.9 host that has:
> 
> glibc-2.12-static
> gcc-4.4
> 
> installed results in the following:
> 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `siglongjmp':
> (.text+0x8490): multiple definition of `longjmp'
> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `sem_open':
> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
> `mkstemp'
> collect2: ld returned 1 exit status
> make[4]: *** [vmlinux] Error 1

Meh, this is a new one.
How is musl involved in this game?

Does it help when you add another redefine-hack to arch/um/Makefile?
See -Dvmap=kernel_vmap.

> Should we have some linker script magic not to export this symbol and
> prevent a clash with libpthread.a pulling its own version?

Yes, we should. But so far nobody had the time to bite the bullet. :-)
This is not the first bug of this kind. Please see.
https://lkml.org/lkml/2015/11/19/726

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Am 22.05.2017 um 21:18 schrieb Thomas Meyer:
> 
>> Am 22.05.2017 um 20:34 schrieb Richard Weinberger <rich...@nod.at>:
>>
>> 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//maps tells a different story on my host.
>> Did you check?
> 
> No... I may should have done so...
> 
> Okay, but it should be possible to mprotect those regions ?

Yes, it should.
Can you give it a try?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

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//maps tells a different story on my host.
Did you check?

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
User-mode-linux-devel@lists.sourceforge.net
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 Weinberger]

On Wed, May 17, 2017 at 10:35 AM, Thomas Meyer  wrote:
>> On Tue, 16 May 2017 17:46:47 +0200
>> Thomas Meyer  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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

On Wed, May 17, 2017 at 10:41 PM, Thomas Meyer  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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer  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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

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 <rich...@nod.at>
---
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, );
-   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  - make UML enter  into the kernel log\n\
-proc  - returns the contents of the UML's /proc/\n\
 stack  - 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


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

On Sat, May 13, 2017 at 10:10 AM, Thomas Meyer  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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

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

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

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, =0xdeadbeef

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

Thanks,
//richard
diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 22a358ef1b0c..37c42cead79d 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -259,7 +259,7 @@ static void __init check_sysemu(void)
 static void __init check_ptrace(void)
 {
 	int pid, syscall, n, status;
-
+#if 0
 	non_fatal("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child();
 
@@ -293,6 +293,7 @@ static void __init check_ptrace(void)
 	}
 	stop_ptraced_child(pid, 0, 1);
 	non_fatal("OK\n");
+#endif
 	check_sysemu();
 }
 
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

static void segv(int sig, siginfo_t *info, void *context)
{
	ucontext_t *c = context;
	mcontext_t m = c->uc_mcontext;
	void *fault_addr = (void *)m.gregs[REG_CR2];
	void *addr;

	printf("SIGSEGV at 0x%lx, fixing up\n", (unsigned long)fault_addr);

	addr = mmap(fault_addr, 4096, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
	if (addr == MAP_FAILED) {
		printf("map failed!\n");
		exit(1);
	}
}

static void install_handler(void)
{
	struct sigaction sa;

	sa.sa_sigaction = segv;
	sa.sa_flags = SA_SIGINFO;

	sigaction(SIGSEGV, , NULL);
}

int main(void)
{
	int *x = (void *)0xdeadbeef;

	install_handler();

	*x = 3;

	printf("x=%i, =%p\n", *x, x);

	return 0;
}
--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Can you please give the attached patch a try?

Thanks,
//richard
>From b64c967e3960eff33e96f7dcff261635fffeb504 Mon Sep 17 00:00:00 2001
From: Richard Weinberger <rich...@nod.at>
Date: Mon, 8 May 2017 21:43:27 +0200
Subject: [PATCH] um: Drop PTRACE_OLDSETOPTIONS usage

IMHO in 2017 can assume that nobody uses UML on a 2.4 host.

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 arch/um/include/shared/ptrace_user.h | 20 
 arch/um/os-Linux/skas/process.c  |  8 
 arch/um/os-Linux/start_up.c  |  8 
 3 files changed, 8 insertions(+), 28 deletions(-)

diff --git a/arch/um/include/shared/ptrace_user.h b/arch/um/include/shared/ptrace_user.h
index 56b2f284b108..0f954eee8523 100644
--- a/arch/um/include/shared/ptrace_user.h
+++ b/arch/um/include/shared/ptrace_user.h
@@ -21,26 +21,6 @@ extern int ptrace_setregs(long pid, unsigned long *regs_in);
 #define PTRACE_SYSEMU_SINGLESTEP 32
 #endif
 
-/* On architectures, that started to support PTRACE_O_TRACESYSGOOD
- * in linux 2.4, there are two different definitions of
- * PTRACE_SETOPTIONS: linux 2.4 uses 21 while linux 2.6 uses 0x4200.
- * For binary compatibility, 2.6 also supports the old "21", named
- * PTRACE_OLDSETOPTION. On these architectures, UML always must use
- * "21", to ensure the kernel runs on 2.4 and 2.6 host without
- * recompilation. So, we use PTRACE_OLDSETOPTIONS in UML.
- * We also want to be able to build the kernel on 2.4, which doesn't
- * have PTRACE_OLDSETOPTIONS. So, if it is missing, we declare
- * PTRACE_OLDSETOPTIONS to be the same as PTRACE_SETOPTIONS.
- *
- * On architectures, that start to support PTRACE_O_TRACESYSGOOD on
- * linux 2.6, PTRACE_OLDSETOPTIONS never is defined, and also isn't
- * supported by the host kernel. In that case, our trick lets us use
- * the new 0x4200 with the name PTRACE_OLDSETOPTIONS.
- */
-#ifndef PTRACE_OLDSETOPTIONS
-#define PTRACE_OLDSETOPTIONS PTRACE_SETOPTIONS
-#endif
-
 void set_using_sysemu(int value);
 int get_using_sysemu(void);
 extern int sysemu_supported;
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index 23025d645160..4bed32df0af6 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -283,10 +283,10 @@ int start_userspace(unsigned long stub_stack)
 		goto out_kill;
 	}
 
-	if (ptrace(PTRACE_OLDSETOPTIONS, pid, NULL,
+	if (ptrace(PTRACE_SETOPTIONS, pid, NULL,
 		   (void *) PTRACE_O_TRACESYSGOOD) < 0) {
 		err = -errno;
-		printk(UM_KERN_ERR "start_userspace : PTRACE_OLDSETOPTIONS "
+		printk(UM_KERN_ERR "start_userspace : PTRACE_SETOPTIONS "
 		   "failed, errno = %d\n", errno);
 		goto out_kill;
 	}
@@ -501,10 +501,10 @@ int copy_context_skas0(unsigned long new_stack, int pid)
 		goto out_kill;
 	}
 
-	if (ptrace(PTRACE_OLDSETOPTIONS, pid, NULL,
+	if (ptrace(PTRACE_SETOPTIONS, pid, NULL,
 		   (void *)PTRACE_O_TRACESYSGOOD) < 0) {
 		err = -errno;
-		printk(UM_KERN_ERR "copy_context_skas0 : PTRACE_OLDSETOPTIONS "
+		printk(UM_KERN_ERR "copy_context_skas0 : PTRACE_SETOPTIONS "
 		   "failed, errno = %d\n", errno);
 		goto out_kill;
 	}
diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 22a358ef1b0c..f96b0964e603 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -205,9 +205,9 @@ static void __init check_sysemu(void)
 	non_fatal("Checking advanced syscall emulation patch for ptrace...");
 	pid = start_ptraced_child();
 
-	if ((ptrace(PTRACE_OLDSETOPTIONS, pid, 0,
+	if ((ptrace(PTRACE_SETOPTIONS, pid, 0,
 		   (void *) PTRACE_O_TRACESYSGOOD) < 0))
-		fatal_perror("check_sysemu: PTRACE_OLDSETOPTIONS failed");
+		fatal_perror("check_sysemu: PTRACE_SETOPTIONS failed");
 
 	while (1) {
 		count++;
@@ -263,9 +263,9 @@ static void __init check_ptrace(void)
 	non_fatal("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child();
 
-	if ((ptrace(PTRACE_OLDSETOPTIONS, pid, 0,
+	if ((ptrace(PTRACE_SETOPTIONS, pid, 0,
 		   (void *) PTRACE_O_TRACESYSGOOD) < 0))
-		fatal_perror("check_ptrace: PTRACE_OLDSETOPTIONS failed");
+		fatal_perror("check_ptrace: PTRACE_SETOPTIONS failed");
 
 	while (1) {
 		if (ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
-- 
2.12.0

--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] warning at vma_merge

[Richard Weinberger]

Anton, Thomas,

On Sun, May 7, 2017 at 10:27 PM, Anton Ivanov
 wrote:
> Have a look at the list archive, this was covered a couple of weeks ago.
>
> I believe Richard is working on a fix.

Yep, this reminds me that I have to ping mm folks about this.
Please see: http://lkml.iu.edu/hypermail/linux/kernel/1703.2/02256.html

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Am 08.05.2017 um 18:09 schrieb Thomas Meyer:
> Or asked he other way around:
> 
> Is somewhere documented what's the minimum host kernel version that a UML 
> kernel will run on?
> 
> E.g.:
> building a UML kernel from 4.11 will need a host kernel version 2.6.18 with 
> features x, y and z enabled?

Not really. But let's be realistic, we don't have to support a 2.4 host.
UML should run on any kernel of a supported distro.

On the other hand, if we can help WSL with a small change to UML, I'll happily 
apply such a patch.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Am 08.05.2017 um 17:40 schrieb Thomas Meyer:
> "
> Also, for a little context, the /only/software I can find /on the planet/ 
> that cares is User Mode Linux. Unless someone tries to run some statically 
> linked |strace| or
> maybe |gdb| binary from the 2.4 era, this will simply never be hit on WSL in 
> 2017. UML seems to still care, entirely academically, to maintain binary 
> compatibility with 2.4. You
> can think of it as UML never buying into the idea the value changed, while 
> everyone else moved"

-ENOPATCH. :-)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Am 08.05.2017 um 17:32 schrieb Thomas Meyer:
>> We could figure how to report issues to WSL, create self-hosting unit tests 
>> and ask them to add/fix
>> these features.
> 
> Turns out there was already a bug report by somebody about missing UML 
> support in WSL:
> 
> https://github.com/Microsoft/BashOnWindows/issues/1692

Ah, there are tons of ptrace() features missing.
UML is a major user of ptrace(), worse than GDB. ;-\

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Thomas,

Am 08.05.2017 um 17:02 schrieb Thomas Meyer:
> Sadly, UML executable bails out very early. it Looks like WSL is missing some 
> PTRACE stuff:
> 
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/Downloads$ ./linux
> Core dump limits :
> soft - NONE
> hard - NONE
> Checking that ptrace can change system call numbers...check_ptrace: 
> PTRACE_OLDSETOPTIONS failed: Invalid Argument

We could figure how to report issues to WSL, create self-hosting unit tests and 
ask them to add/fix
these features.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [uml-user] [PATCH] um: Fix _print_addr()

[Richard Weinberger]

On Sun, Dec 25, 2016 at 11:11 PM, Richard Weinberger <rich...@nod.at> wrote:
> Recent changes to printk() broke UML's stack trace
> output. Kill the root of the problem by using a single
> printk() statement.
>
> Signed-off-by: Richard Weinberger <rich...@nod.at>
> ---
>  arch/um/kernel/sysrq.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
> index aa1b56f5ac68..18eddf677ec6 100644
> --- a/arch/um/kernel/sysrq.c
> +++ b/arch/um/kernel/sysrq.c
> @@ -17,10 +17,8 @@
>
>  static void _print_addr(void *data, unsigned long address, int reliable)
>  {
> -   pr_info(" [<%08lx>]", address);
> -   pr_cont(" %s", reliable ? "" : "? ");
> -   print_symbol("%s", address);
> -   pr_cont("\n");
> +   pr_info(" [<%08lx>] %s%pF\n", address, reliable ? "" : "? ",
> +   (void *)address);
>  }
>
>  static const struct stacktrace_ops stackops = {

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH v2] um: Set number of CPUs

[Richard Weinberger]

On Fri, Mar 3, 2017 at 9:11 AM, Richard Weinberger <rich...@nod.at> wrote:
> Nikola,
>
> Am 02.03.2017 um 14:16 schrieb Nikola Kotur:
>> Define NR_CPUS required by the timer subsystem.
>>
>> Fixes this make warning:
>>
>> scripts/kconfig/conf  --oldconfig arch/x86/um/Kconfig
>> kernel/time/Kconfig:155:warning: range is invalid
>>
>> Signed-off-by: Nikola Kotur <kotn...@gmail.com>
>
> Looks good!
>
> 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
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix PTRACE_POKEUSER on x86_64

[Richard Weinberger]

On Sat, Apr 1, 2017 at 12:41 AM, Richard Weinberger <rich...@nod.at> wrote:
> This is broken since ever but sadly nobody noticed.
> Recent versions of GDB set DR_CONTROL unconditionally and
> UML dies due to a heap corruption. It turns out that
> the PTRACE_POKEUSER was copy from i386 and assumes
> that addresses are 4 bytes long.
>
> Fix that by using 8 as address size in the calculation.
>
> Cc: <sta...@vger.kernel.org>
> Reported-by: jie cao <cj3...@gmail.com>
> Signed-off-by: Richard Weinberger <rich...@nod.at>
> ---
>  arch/x86/um/ptrace_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
> index a5c9910d234f..09a085bde0d4 100644
> --- a/arch/x86/um/ptrace_64.c
> +++ b/arch/x86/um/ptrace_64.c
> @@ -125,7 +125,7 @@ int poke_user(struct task_struct *child, long addr, long 
> data)
> else if ((addr >= offsetof(struct user, u_debugreg[0])) &&
> (addr <= offsetof(struct user, u_debugreg[7]))) {
> addr -= offsetof(struct user, u_debugreg[0]);
> -   addr = addr >> 2;
> +   addr = addr >> 3;
> if ((addr == 4) || (addr == 5))
> return -EIO;
> child->thread.arch.debugregs[addr] = data;

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Include kbuild.h instead of duplicating its macros

[Richard Weinberger]

On Mon, Apr 3, 2017 at 9:54 PM, Matthias Kaehlcke  wrote:
> Signed-off-by: Matthias Kaehlcke 
> ---
>  arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h 
> b/arch/x86/um/shared/sysdep/kernel-offsets.h
> index 46a9df99f3c5..7e1d35b6ad5c 100644
> --- a/arch/x86/um/shared/sysdep/kernel-offsets.h
> +++ b/arch/x86/um/shared/sysdep/kernel-offsets.h
> @@ -2,16 +2,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
> -#define DEFINE(sym, val) \
> -   asm volatile("\n->" #sym " %0 " #val : : "i" (val))
> -
> -#define BLANK() asm volatile("\n->" : : )
> -
> -#define OFFSET(sym, str, mem) \
> -   DEFINE(sym, offsetof(struct str, mem));
> -
>  void foo(void)
>  {
>  #include 
> --
> 2.12.2.564.g063fe858b8-goog
>

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix to call read_initrd after init_bootmem

[Richard Weinberger]

On Thu, Apr 27, 2017 at 5:15 AM, Masami Hiramatsu  wrote:
> Since read_initrd() invokes alloc_bootmem() for allocating
> memory to load initrd image, it must be called after init_bootmem.
>
> This makes read_initrd() called directly from setup_arch()
> after init_bootmem() and mem_total_pages().
>
> Signed-off-by: Masami Hiramatsu 
> ---
>  arch/um/kernel/initrd.c  |4 +---
>  arch/um/kernel/um_arch.c |6 ++
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/um/kernel/initrd.c b/arch/um/kernel/initrd.c
> index 48bae81..6f6e789 100644
> --- a/arch/um/kernel/initrd.c
> +++ b/arch/um/kernel/initrd.c
> @@ -14,7 +14,7 @@
>  static char *initrd __initdata = NULL;
>  static int load_initrd(char *filename, void *buf, int size);
>
> -static int __init read_initrd(void)
> +int __init read_initrd(void)
>  {
> void *area;
> long long size;
> @@ -46,8 +46,6 @@ static int __init read_initrd(void)
> return 0;
>  }
>
> -__uml_postsetup(read_initrd);
> -
>  static int __init uml_initrd_setup(char *line, int *add)
>  {
> initrd = line;
> diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
> index 4b85acd..64a1fd0 100644
> --- a/arch/um/kernel/um_arch.c
> +++ b/arch/um/kernel/um_arch.c
> @@ -338,11 +338,17 @@ int __init linux_main(int argc, char **argv)
> return start_uml();
>  }
>
> +int __init __weak read_initrd(void)
> +{
> +   return 0;
> +}
> +
>  void __init setup_arch(char **cmdline_p)
>  {
> stack_protections((unsigned long) _thread_info);
> setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
> mem_total_pages(physmem_size, iomem_size, highmem);
> +   read_initrd();
>
> paging_init();
> strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
>

Applied.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix to call read_initrd after init_bootmem

[Richard Weinberger]

Masami,

Am 28.04.2017 um 00:40 schrieb Masami Hiramatsu:
> Finally, git bisect shows that below commit caused this issue.
> 
> b63236972e1344b247750451e2be0a06cd125f21 is the first bad commit
> commit b63236972e1344b247750451e2be0a06cd125f21
> Author: Richard Weinberger <rich...@nod.at>

Meh, it's always me. ;-)

> 
> For the stable, any kernel later than v4.8 has this issue.

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Include kbuild.h instead of duplicating its macros

[Richard Weinberger]

Matthias,

Am 17.04.2017 um 22:37 schrieb Matthias Kaehlcke:
> El Mon, Apr 03, 2017 at 12:54:58PM -0700 Matthias Kaehlcke ha dit:
> 
>> Signed-off-by: Matthias Kaehlcke 
>> ---
>>  arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +
>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h 
>> b/arch/x86/um/shared/sysdep/kernel-offsets.h
>> index 46a9df99f3c5..7e1d35b6ad5c 100644
>> --- a/arch/x86/um/shared/sysdep/kernel-offsets.h
>> +++ b/arch/x86/um/shared/sysdep/kernel-offsets.h
>> @@ -2,16 +2,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  
>> -#define DEFINE(sym, val) \
>> -asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>> -
>> -#define BLANK() asm volatile("\n->" : : )
>> -
>> -#define OFFSET(sym, str, mem) \
>> -DEFINE(sym, offsetof(struct str, mem));
>> -
>>  void foo(void)
>>  {
>>  #include 
>> -- 
> 
> Ping, any comment on this patch?

Looks good, nothing exploded while a quick test.
I'll queue it for the next merge window. :-)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] um: Fix PTRACE_POKEUSER on x86_64

[Richard Weinberger]

This is broken since ever but sadly nobody noticed.
Recent versions of GDB set DR_CONTROL unconditionally and
UML dies due to a heap corruption. It turns out that
the PTRACE_POKEUSER was copy from i386 and assumes
that addresses are 4 bytes long.

Fix that by using 8 as address size in the calculation.

Cc: <sta...@vger.kernel.org>
Reported-by: jie cao <cj3...@gmail.com>
Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 arch/x86/um/ptrace_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
index a5c9910d234f..09a085bde0d4 100644
--- a/arch/x86/um/ptrace_64.c
+++ b/arch/x86/um/ptrace_64.c
@@ -125,7 +125,7 @@ int poke_user(struct task_struct *child, long addr, long 
data)
else if ((addr >= offsetof(struct user, u_debugreg[0])) &&
(addr <= offsetof(struct user, u_debugreg[7]))) {
addr -= offsetof(struct user, u_debugreg[0]);
-   addr = addr >> 2;
+   addr = addr >> 3;
if ((addr == 4) || (addr == 5))
return -EIO;
child->thread.arch.debugregs[addr] = data;
-- 
2.10.2


--
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Richard Weinberger]

Anton,

Am 17.03.2017 um 18:44 schrieb Anton Ivanov:
>> But you have to enable VM debugging to see it.
> 
> I have most debugging enabled to make sure I do not introduce any
> re-entrancy in the IRQ handlers and/or have any allocations of the wrong
> type where they do not belong.
> 
> We should probably submit a short patch #ifdef to turn this WARN() off
> for UML

Not before we understand the root cause. :)

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Richard Weinberger]

Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> <anton.iva...@kot-begemot.co.uk> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>> page in making UML unusable with the latest 4.11-rc2
>> Which WARN? Can you find the offending commit?
> 
> mm/mmap.c line 1112

Okay, this triggers since:

commit e86f15ee64d8ee46255d964d55f74f5ba9af8c36
Author: Andrea Arcangeli <aarca...@redhat.com>
Date:   Fri Oct 7 17:01:28 2016 -0700

mm: vma_merge: fix vm_page_prot SMP race condition against rmap_walk

But you have to enable VM debugging to see 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Richard Weinberger]

Anton,

Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> <anton.iva...@kot-begemot.co.uk> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>> page in making UML unusable with the latest 4.11-rc2
>> Which WARN? Can you find the offending commit?
> 
> mm/mmap.c line 1112
> 
> I spent the day polishing the epoll patch so have not had the time to look at 
> this.
> 
> It works fine with the 3 warns there commented out.

Hm, it does not trigger here. Can you share your .config?

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] FPU patches broke UML on i7-7700 CPU

[Richard Weinberger]

Natale,

On Wed, Feb 15, 2017 at 3:31 PM, Natale Patriciello
 wrote:
>
> Hello,
>
> as I've reported here [1], by changing the work station I've got the
> same UML guest not working anymore. I investigated and the problem root
> is in the code added in this patchset [2] (add extended processor state
> save/restore support). In particular, the ptrace returns < 0 and the
> errno is set to 14. Reverting the code to use the functions
> *_i387_registers () makes everything to work correctly.
>
> There is something I can do for further debugging the issue? Or should I
> live with a modified kernel tree with a reverse patch applied ?

When reporting such bugs, please always CC all affected parties.
Especially the author of the offending patch.

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Richard Weinberger]

Anton,

On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
 wrote:
> Hi list, hi Richard
>
> There is an extra check in mm/mmap.c which now throws a WARN on every
> page in making UML unusable with the latest 4.11-rc2

Which WARN? Can you find the offending commit?

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel