user-mode-linux-devel

Re: [uml-devel] UML tools anywhere?

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

Am 14.07.2016 um 05:08 schrieb Mattia Dongili:
> On Wed, Jul 13, 2016 at 11:11:03PM +0200, Richard Weinberger wrote:
>> Hi!
>>
>> On Wed, Jul 13, 2016 at 5:02 AM, Mattia Dongili <mal...@li...> wrote:
>>> Hi,
>>>
>>> Does anybody knows if there is any newer version of the tools package
>>> (the one with tunctl, uml_mount and friends)?
>>>
>>> I'm maintaining[1] the package in Debian and I was wondering whether the
>>> original code is hosted somewhere.
>>
>> http://user-mode-linux.sourceforge.net/old/dl-sf.html
>>
>> There is no newer version.
> 
> Ha! interesting. I even have a 20070815 (and others post-2004) version
> that is not on that page. I'm wondering how I got that, maybe just a
> snapshot off of CVS.

Sorry, sent you the wrong link, was late yesterday. ;)
http://user-mode-linux.sourceforge.net/downloads.html

It matches what you have, but still old.

>> Do you have a list of issues in the current utilities?
> 
> There are some in the Debian bug tracking system, some (most?) are related to
> packaging issues though[1].
> 
>> Maybe I should take this as chance to convert them to git and make
>> a new release.
> 
> Well my number one wishlist item would be to change the hand rolled
> makefile to something more maintainable where if I have to pass, say,
> LDFLAGS, it'll get honoured by all tools.

Agreed.

> I can certainly help with that, since I would like to do that work
> anyway in order to refresh the debian package. If you want to stuff the
> code in a git repository I can send patches in.

That would be great!

Step one would be converting the CVS repo to git:
http://user-mode-linux.cvs.sourceforge.net/viewvc/user-mode-linux/tools/

Can you do that?

Thanks,
//richard

Re: [uml-devel] UML tools anywhere?

[Mattia D. <mal...@li...>]

On Wed, Jul 13, 2016 at 11:11:03PM +0200, Richard Weinberger wrote:
> Hi!
> 
> On Wed, Jul 13, 2016 at 5:02 AM, Mattia Dongili <mal...@li...> wrote:
> > Hi,
> >
> > Does anybody knows if there is any newer version of the tools package
> > (the one with tunctl, uml_mount and friends)?
> >
> > I'm maintaining[1] the package in Debian and I was wondering whether the
> > original code is hosted somewhere.
> 
> http://user-mode-linux.sourceforge.net/old/dl-sf.html
> 
> There is no newer version.

Ha! interesting. I even have a 20070815 (and others post-2004) version
that is not on that page. I'm wondering how I got that, maybe just a
snapshot off of CVS.

> Do you have a list of issues in the current utilities?

There are some in the Debian bug tracking system, some (most?) are related to
packaging issues though[1].

> Maybe I should take this as chance to convert them to git and make
> a new release.

Well my number one wishlist item would be to change the hand rolled
makefile to something more maintainable where if I have to pass, say,
LDFLAGS, it'll get honoured by all tools.

I can certainly help with that, since I would like to do that work
anyway in order to refresh the debian package. If you want to stuff the
code in a git repository I can send patches in.

[1]:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=uml-utilities

Thanks!
-- 
mattia
:wq!

Re: [uml-devel] UML tools anywhere?

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

Hi!

On Wed, Jul 13, 2016 at 5:02 AM, Mattia Dongili <mal...@li...> wrote:
> Hi,
>
> Does anybody knows if there is any newer version of the tools package
> (the one with tunctl, uml_mount and friends)?
>
> I'm maintaining[1] the package in Debian and I was wondering whether the
> original code is hosted somewhere.

http://user-mode-linux.sourceforge.net/old/dl-sf.html

There is no newer version.
Do you have a list of issues in the current utilities?

Maybe I should take this as chance to convert them to git and make
a new release.

-- 
Thanks,
//richard

[uml-devel] UML tools anywhere?

[Mattia D. <mal...@li...>]

Hi,

Does anybody knows if there is any newer version of the tools package
(the one with tunctl, uml_mount and friends)?

I'm maintaining[1] the package in Debian and I was wondering whether the
original code is hosted somewhere.

Thanks
-- 
mattia
:wq!

[1]: with varying degrees of consistency

Re: [uml-devel] [PATCH v1 0/3] Fix seccomp for UM (next)

[Kees C. <kee...@ch...>]

On Mon, Jul 11, 2016 at 5:56 PM, Mickaël Salaün <mi...@di...> wrote:
> Hi,
>
> This series fix the recent seccomp update for the User-mode Linux architecture
> (32-bit and 64-bit) since commit 26703c636c1f3272b39bd0f6d04d2e970984f1b6
> (close the hole where ptrace can change a syscall out from under seccomp).
>
> Regards,
>
> Mickaël Salaün (3):
>   um/ptrace: Fix the syscall_trace_leave call
>   um/ptrace: Fix the syscall number update after a ptrace
>   seccomp: Remove 2-phase API documentation
>
>  arch/Kconfig                  | 11 -----------
>  arch/um/kernel/skas/syscall.c | 10 +++-------
>  arch/x86/um/ptrace_32.c       |  3 +++
>  arch/x86/um/ptrace_64.c       |  4 ++++
>  4 files changed, 10 insertions(+), 18 deletions(-)

Ah, perfect! Thanks for fixing this! James, can you pick this up for -next?

Acked-by: Kees Cook <kee...@ch...>

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [uml-devel] How to properly load debug symbols for module and set breakpoint

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

On Wed, Jul 6, 2016 at 1:31 PM, Mark Kica <mar...@gm...> wrote:
> I have build custom 64bit UML Linux kernel with TUN/TAP kernel module
> (tun.ko) and then I have installed it on small root filesystem with busybox
> . These module and kernel seems to work and I would like to make simple
> changes in TUN module and measure it's performance .
>
> So I have tried to follow guide from
> http://user-mode-linux.sourceforge.net/hacking.html which explains how to
> attach gdb to UML and set breakpoint for module init function .
>
> (gdb) p modules
> $1 = {next = 0x6385cf38, prev = 0x6385cf38}
>
> (gdb) p *((struct module *)0x6385cf30)
> $2 = {state = MODULE_STATE_LIVE, list = {next = 0x6036aee0, prev =
> 0x6036aee0}, name = "tun", '\000' <repeats 52 times>, mkobj = {kobj = {name
> = 0x62e95b00 "tun", entry = {next = 0x62c30440, prev = 0x62c30148}, parent =
> 0x62c30450,
> kset = 0x62c30440, ktype = 0x603694d0, sd = 0x62dd6fa0, kref = {refcount =
> {counter = 3}}, state_initialized = 1, state_in_sysfs = 1,
> state_add_uevent_sent = 1, state_remove_uevent_sent = 0, uevent_suppress =
> 0},
> mod = 0x6385cf30, drivers_dir = 0x0, mp = 0x0}, modinfo_attrs = 0x62ea0400,
> version = 0x0, srcversion = 0x0, holders_dir = 0x62da7400, syms = 0x0, crcs
> = 0x0, num_syms = 0, kp = 0x0, num_kp = 0, num_gpl_syms = 1,
> gpl_syms = 0x6385c260, gpl_crcs = 0x0, gpl_future_syms = 0x0,
> gpl_future_crcs = 0x0, num_gpl_future_syms = 0, num_exentries = 0, extable =
> 0x0, init = 0x63860000, module_init = 0x0, module_core = 0x6385a000,
> init_size = 0,
> core_size = 13990, init_text_size = 0, core_text_size = 8244, init_ro_size =
> 127, core_ro_size = 11432, arch = {<No data fields>}, taints = 0, num_bugs =
> 0, bug_list = {next = 0x60376a40, prev = 0x60376a40}, bug_table = 0x0,
> symtab = 0x6385d120, core_symtab = 0x6385d120, num_symtab = 37,
> core_num_syms = 37, strtab = 0x6385d498 "", core_strtab = 0x6385d498 "",
> sect_attrs = 0x62c52000, notes_attrs = 0x62e98240, args = 0x62e95b20 " ",
> source_list = {
> next = 0x6385d0e0, prev = 0x6385d0e0}, target_list = {next = 0x6385d0f0,
> prev = 0x6385d0f0}, waiter = 0x62ea10c0, exit = 0x6385a101, refptr =
> 0x62176ca0}
>
> (gdb) add-symbol-file
> /home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko 0x6385a000
> add symbol table from file
> "/home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko" at
> .text_addr = 0x6385a000
> (y or n)
> Please answer y or n.
> (y or n) y
> Reading symbols from
> /home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko...done.

Try extracting the addresses from /sys/module/tun/sections/

> (gdb) p tun_init
> $3 = {int (void)} 0x24 <tun_init>
>
>
> (gdb) break tun_init
> Cannot access memory at address 0x24
>
>
>
> I don't understand why tun_init is located at 0x24 and not at 0x6385a000 ?
> Can somebody point what I am doing wrong and how to load debug symbols and
> set breakpoint ?
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>



-- 
Thanks,
//richard

Re: [uml-devel] ubd is slow. I want to try fixing it

[Артём Л. <the...@gm...>]

Ah, thanks.
I rebuilt it with sync off, and the performance jumped up to something
close to the host one.
Would that actually put ext4 guest fs in any danger in case of a crash?

Sadly, it developed that the 64bit UML can't run 32bit programs, which
is a deal breaker to me.
While it's something that was working at one point and apparently also
fixable with some effort, the sum total of problems makes qemu-kvm
look more attractive in the end.

It's peculiar to see UML in such a state of disrepair - for a long
while i thought it was a widely used lean virtualization platform,
powering things like containers, docker and so on.
Some research and disillusionment later, i'm left wondering what went wrong.
Even the ultra-useful Windows port, CoLinux, seems to be abandoned.

In any case, good luck with the patches!


> 2016-07-09 1:15 GMT+03:00  <use...@li...>:
> Check if you have sync turned on.
>
> Form of async IO - very similar to what posix async IO implementations
> do. If done correctly it can speed up things quite a bit. For it however
> actual files need to be opened async. The number you quoted makes me
> think you have sync enabled (it is enabled in some distros by default
> via kernel config options).

Re: [uml-devel] ubd is slow. I want to try fixing it

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

On 08/07/16 21:03, Артём Литвинович wrote:
> Greetings.
>
> Apparently, ubd is too slow for practical use.
> I'm getting 0.8 Mb/s write speed, while hostfs does 25 Mb/s (and on
> the host itself it's similar).
> This is rather frustrating for such a great project as UML is, and i'd
> like to try fixing this.
>
> So, two questions.
>
> First, am i missing something?
> Is it actually normal for ubd to be that slow?
> I looked around, and apparently it is slow due to design. There even
> were some ancient patches to try to fix that.

Check if you have sync turned on.

>
> Second, why is this problem hard?
> This was going on for over a decade, and no one made a better version,

Not quite, I have one in my patch queue, just no timeslots to work on it.

> which implies a hard problem.

Not really, It is an age old problem - single sector vs multi-sector
read/write - same as ancient PIO IDE vs DMA that replaced it.

As I said - I have patchsets, I however messed up the submission last
time so only some of the simple things like syscall reduction are there.

Actual bulking of requests, etc did not go in. I plan to go back to it
later this summer when I have more time.

> I would love to hear from someone who is familiar with how the code
> works, about what the problems are (instead of hitting my head against
> them later).
> Specifically, why use the IO thread?

Form of async IO - very similar to what posix async IO implementations
do. If done correctly it can speed up things quite a bit. For it however
actual files need to be opened async. The number you quoted makes me
think you have sync enabled (it is enabled in some distros by default
via kernel config options).

A.

> Hostfs seem to work just fine with calling the native read/write directly.
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>

[uml-devel] ubd is slow. I want to try fixing it

[Артём Л. <the...@gm...>]

Greetings.

Apparently, ubd is too slow for practical use.
I'm getting 0.8 Mb/s write speed, while hostfs does 25 Mb/s (and on
the host itself it's similar).
This is rather frustrating for such a great project as UML is, and i'd
like to try fixing this.

So, two questions.

First, am i missing something?
Is it actually normal for ubd to be that slow?
I looked around, and apparently it is slow due to design. There even
were some ancient patches to try to fix that.

Second, why is this problem hard?
This was going on for over a decade, and no one made a better version,
which implies a hard problem.
I would love to hear from someone who is familiar with how the code
works, about what the problems are (instead of hitting my head against
them later).
Specifically, why use the IO thread?
Hostfs seem to work just fine with calling the native read/write directly.

[uml-devel] How to properly load debug symbols for module and set breakpoint

[Mark K. <mar...@gm...>]

I have build custom 64bit UML Linux kernel with TUN/TAP kernel module
(tun.ko) and then I have installed it on small root filesystem with busybox
. These module and kernel seems to work and I would like to make simple
changes in TUN module and measure it's performance .

So I have tried to follow guide from
http://user-mode-linux.sourceforge.net/hacking.html which explains how to
attach gdb to UML and set breakpoint for module init function .

(gdb) p modules
$1 = {next = 0x6385cf38, prev = 0x6385cf38}

(gdb) p *((struct module *)0x6385cf30)
$2 = {state = MODULE_STATE_LIVE, list = {next = 0x6036aee0, prev =
0x6036aee0}, name = "tun", '\000' <repeats 52 times>, mkobj = {kobj =
{name = 0x62e95b00 "tun", entry = {next = 0x62c30440, prev =
0x62c30148}, parent = 0x62c30450,
kset = 0x62c30440, ktype = 0x603694d0, sd = 0x62dd6fa0, kref =
{refcount = {counter = 3}}, state_initialized = 1, state_in_sysfs = 1,
state_add_uevent_sent = 1, state_remove_uevent_sent = 0,
uevent_suppress = 0},
mod = 0x6385cf30, drivers_dir = 0x0, mp = 0x0}, modinfo_attrs =
0x62ea0400, version = 0x0, srcversion = 0x0, holders_dir = 0x62da7400,
syms = 0x0, crcs = 0x0, num_syms = 0, kp = 0x0, num_kp = 0,
num_gpl_syms = 1,
gpl_syms = 0x6385c260, gpl_crcs = 0x0, gpl_future_syms = 0x0,
gpl_future_crcs = 0x0, num_gpl_future_syms = 0, num_exentries = 0,
extable = 0x0, init = 0x63860000, module_init = 0x0, module_core =
0x6385a000, init_size = 0,
core_size = 13990, init_text_size = 0, core_text_size = 8244,
init_ro_size = 127, core_ro_size = 11432, arch = {<No data fields>},
taints = 0, num_bugs = 0, bug_list = {next = 0x60376a40, prev =
0x60376a40}, bug_table = 0x0,
symtab = 0x6385d120, core_symtab = 0x6385d120, num_symtab = 37,
core_num_syms = 37, strtab = 0x6385d498 "", core_strtab = 0x6385d498
"", sect_attrs = 0x62c52000, notes_attrs = 0x62e98240, args =
0x62e95b20 " ", source_list = {
next = 0x6385d0e0, prev = 0x6385d0e0}, target_list = {next =
0x6385d0f0, prev = 0x6385d0f0}, waiter = 0x62ea10c0, exit =
0x6385a101, refptr = 0x62176ca0}

(gdb) add-symbol-file
/home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko 0x6385a000
add symbol table from file
"/home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko" at
.text_addr = 0x6385a000
(y or n)
Please answer y or n.
(y or n) y
Reading symbols from
/home/mark/playground/linux-2.6.39.3/drivers/net/tun.ko...done.

(gdb) p tun_init
$3 = {int (void)} 0x24 <tun_init>


(gdb) break tun_init
Cannot access memory at address 0x24



I don't understand why tun_init is located at 0x24 and not at 0x6385a000 ?
Can somebody point what I am doing wrong and how to load debug symbols and
set breakpoint ?

Re: [uml-devel] [user-mode-linux] memory leak in network path

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

Hi!

Am 18.06.2016 um 13:02 schrieb Enrico Mioso:
> Hi guys.
> 
> I am experiencing an user-mode-linux memory leak, that induces the user-mode kernel to eventually panic.
> 
> My sequence of actions to trigger it is relatively simple:
> - start it on an ubuntu 16.04 core image, after installing "ubuntu-standard" package
> - install aptitude and openssh-server if needed
> 
> When I type
> sudo aptitude build-dep gnuradio
> (but any package with lots of dependencies may do), I can see used memory by UML growing and growing.
> When the allocation limit I specify in the command line is reached, then it crashes.
> 
> This problem is triggerable pretty reliably on my box:
> Running a custom-compiled 4.4.12 kernel.
> 
> 
> UML kernel version: 4.6.1-usermodelinux
> 
> Thank you very much guys for your work and attention,

Please share the log of the crash.
How did you figure that UML is consuming more and more memory?

Thanks,
//richard

Re: [uml-devel] [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

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

Paul,

Am 15.06.2016 um 00:54 schrieb Paul E. McKenney:
> On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>> head:   13ee0de9cd2444b57ce30c4f1607b49b90aa0c38
>> commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make call_rcu_tasks() tolerate first call with irqs disabled
>> config: um-allmodconfig (attached as .config)
>> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>> reproduce:
>>         git checkout f251ac814fc5787765009e60d54a2bd4277350c8
>>         # save the attached .config to linux build tree
>>         make ARCH=um 
> 
> My kneejerk reaction would be to make CONFIG_TASKS_RCU depend on
> !UML or something similar.
> 
> Another approach would be create a arch_irqs_disabled_flags() for UML.
> 
> Any preferences?

Patches for arch_irqs_disabled_flags() support are already on LKML:
https://lkml.org/lkml/2016/6/12/162

My plan was to merge them in the v4.8 merge window.
So having CONFIG_TASKS_RCU depend on !UML for now should be fine.
We can remove the dependency in v4.8 again.

Thanks,
//richard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

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

Am 12.06.2016 um 23:41 schrieb Vegard Nossum:
> I see... nice and hacky ;-) I'll try the same for snprintf and see if
> that works around my bug.
> 
>> A much better approach would be having a real linker scope.
>> Some time ago I posted some thoughts on that:
>> https://lkml.org/lkml/2015/11/19/758
>>
>> Due to -ENOTIME this never materialized, though. ;-(
> 
> Cool, objcopy -G/--keep-global-symbol(s) seems like a good solution.
> Doesn't look like it should be too difficult. I might give it a try.

Not really difficult but unpleasant. ;-)
IIRC last time I looked I figured that UML's source structure
and build process would need a big rework to achieve that.
Would be cool if you could work on it, I'll happily assist as far as my
spare time permits.

Thanks,
//richard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Vegard N. <veg...@gm...>]

On 12 June 2016 at 23:05, Richard Weinberger <ri...@no...> wrote:
> Am 12.06.2016 um 22:59 schrieb Vegard Nossum:
>> On 12 June 2016 at 22:11, Richard Weinberger
>> <ric...@gm...> wrote:
>>>> I wonder why setup_env_path() ends up calling the kernel's snprintf(),
>>>> I thought that it would be using the glibc snprintf() at this point?
>>>
>>> That early you cannot use current() nor any other core kernel stuff
>>> since the kernel has not started so far.
>>> So, the current thread info struct points to garbage.
>>
>> Yes, I know. I think setup_env_path() should call the libc snprintf
>> rather than the kernel one, can you explain how to do that properly?
>
> Currently UML sets up nasty maps for known namespaces clashes.
> i.e.
> KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ \
>         $(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap      \
>         -Din6addr_loopback=kernel_in6addr_loopback \
>         -Din6addr_any=kernel_in6addr_any -Dstrrchr=kernel_strrchr

I see... nice and hacky ;-) I'll try the same for snprintf and see if
that works around my bug.

> A much better approach would be having a real linker scope.
> Some time ago I posted some thoughts on that:
> https://lkml.org/lkml/2015/11/19/758
>
> Due to -ENOTIME this never materialized, though. ;-(

Cool, objcopy -G/--keep-global-symbol(s) seems like a good solution.
Doesn't look like it should be too difficult. I might give it a try.

Thanks!


Vegard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

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

Am 12.06.2016 um 22:59 schrieb Vegard Nossum:
> On 12 June 2016 at 22:11, Richard Weinberger
> <ric...@gm...> wrote:
>>> I wonder why setup_env_path() ends up calling the kernel's snprintf(),
>>> I thought that it would be using the glibc snprintf() at this point?
>>
>> That early you cannot use current() nor any other core kernel stuff
>> since the kernel has not started so far.
>> So, the current thread info struct points to garbage.
> 
> Yes, I know. I think setup_env_path() should call the libc snprintf
> rather than the kernel one, can you explain how to do that properly?

Currently UML sets up nasty maps for known namespaces clashes.
i.e.
KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ \
        $(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap      \
        -Din6addr_loopback=kernel_in6addr_loopback \
        -Din6addr_any=kernel_in6addr_any -Dstrrchr=kernel_strrchr

A much better approach would be having a real linker scope.
Some time ago I posted some thoughts on that:
https://lkml.org/lkml/2015/11/19/758

Due to -ENOTIME this never materialized, though. ;-(

Thanks,
//richard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Vegard N. <veg...@gm...>]

On 12 June 2016 at 22:11, Richard Weinberger
<ric...@gm...> wrote:
>> I wonder why setup_env_path() ends up calling the kernel's snprintf(),
>> I thought that it would be using the glibc snprintf() at this point?
>
> That early you cannot use current() nor any other core kernel stuff
> since the kernel has not started so far.
> So, the current thread info struct points to garbage.

Yes, I know. I think setup_env_path() should call the libc snprintf
rather than the kernel one, can you explain how to do that properly?

Thanks,


Vegard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

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

On Sun, May 22, 2016 at 5:39 PM, Vegard Nossum <veg...@gm...> wrote:
> On 21 May 2016 at 20:18, Thomas Meyer <th...@m3...> wrote:
>> Am 21.05.2016 um 15:51 schrieb Vegard Nossum <veg...@gm...>:
>>> I'm having some trouble with using current_thread_info() during UML
>>> early boot. Sometimes it works just fine, but often I get segfaults
>>> because current_thread_info() is returning an invalid pointer. It
>>> looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.
>>
>> Mhh. Strange. Do you have a stack trace to call to current thread info which ends up with a wrong value. I wonder from were it originates.
>
> One such trace would be:
>
> #2  0x000000006026652c in snprintf (buf=<optimized out>,
> size=<optimized out>, fmt=<optimized out>) at lib/vsprintf.c:2181
> #3  0x00000000600046f8 in setup_env_path () at arch/um/os-Linux/main.c:109
> #4  main (argc=3, argv=0x7ffc3d8c23e8, envp=<optimized out>) at
> arch/um/os-Linux/main.c:125
>
> I wonder why setup_env_path() ends up calling the kernel's snprintf(),
> I thought that it would be using the glibc snprintf() at this point?

That early you cannot use current() nor any other core kernel stuff
since the kernel has not started so far.
So, the current thread info struct points to garbage.

-- 
Thanks,
//richard

[uml-devel] [PATCH 1/2] um: Use asm-generic/irqflags.h

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

From: Daniel Wagner <dan...@bm...>

Instead proving its own arch_local_irq_save() and arch_irqs_disabled()
version use the generic version from asm-generic/irqflags.h.

A nice side effect is that um gets a few additional arch_ functions
as well.

One problem though is the include for the signals. I could figured out
which header file to pick without trigger a bunch of header include
clashes. Leaving it away works though it is surely not the best
practice.

Signed-off-by: Daniel Wagner <dan...@bm...>
Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/include/asm/irqflags.h | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/um/include/asm/irqflags.h b/arch/um/include/asm/irqflags.h
index c780d8a..71c2d64 100644
--- a/arch/um/include/asm/irqflags.h
+++ b/arch/um/include/asm/irqflags.h
@@ -6,37 +6,35 @@ extern int set_signals(int enable);
 extern void block_signals(void);
 extern void unblock_signals(void);
 
+#define arch_local_save_flags arch_local_save_flags
 static inline unsigned long arch_local_save_flags(void)
 {
 	return get_signals();
 }
 
+#define arch_local_irq_restore arch_local_irq_restore
 static inline void arch_local_irq_restore(unsigned long flags)
 {
 	set_signals(flags);
 }
 
+#define arch_local_irq_enable arch_local_irq_enable
 static inline void arch_local_irq_enable(void)
 {
 	unblock_signals();
 }
 
+#define arch_local_irq_disable arch_local_irq_disable
 static inline void arch_local_irq_disable(void)
 {
 	block_signals();
 }
 
-static inline unsigned long arch_local_irq_save(void)
-{
-	unsigned long flags;
-	flags = arch_local_save_flags();
-	arch_local_irq_disable();
-	return flags;
-}
+/* #include <uapi/asm/signal.h> */
 
-static inline bool arch_irqs_disabled(void)
-{
-	return arch_local_save_flags() == 0;
-}
+#define ARCH_IRQ_DISABLED	0
+#define ARCh_IRQ_ENABLED	(SIGIO|SIGVTALRM)
+
+#include <asm-generic/irqflags.h>
 
 #endif
-- 
2.7.3

[uml-devel] [PATCH 2/2] um: Enable TRACE_IRQFLAGS_SUPPORT

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

Now we have everything we need, so enable
TRACE_IRQFLAGS_SUPPORT.

Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/Kconfig.common | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index cc00134..85f14a8 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -30,10 +30,9 @@ config PCI
 config PCMCIA
 	bool
 
-# Yet to do!
 config TRACE_IRQFLAGS_SUPPORT
 	bool
-	default n
+	default y
 
 config LOCKDEP_SUPPORT
 	bool
-- 
2.7.3

[uml-devel] [PATCH] uml: Fix possible deadlock in sig_handler_common()

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

We are in atomic context and must not sleep.
Sleeping here is possible since malloc() maps
to kmalloc() with GFP_KERNEL.

Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/os-Linux/signal.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index 8acaf4e..a86d7cc 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -15,6 +15,7 @@
 #include <kern_util.h>
 #include <os.h>
 #include <sysdep/mcontext.h>
+#include <um_malloc.h>
 
 void (*sig_info[NSIG])(int, struct siginfo *, struct uml_pt_regs *) = {
 	[SIGTRAP]	= relay_signal,
@@ -32,7 +33,7 @@ static void sig_handler_common(int sig, struct siginfo *si, mcontext_t *mc)
 	struct uml_pt_regs *r;
 	int save_errno = errno;
 
-	r = malloc(sizeof(struct uml_pt_regs));
+	r = uml_kmalloc(sizeof(struct uml_pt_regs), UM_GFP_ATOMIC);
 	if (!r)
 		panic("out of memory");
 
@@ -91,7 +92,7 @@ static void timer_real_alarm_handler(mcontext_t *mc)
 {
 	struct uml_pt_regs *regs;
 
-	regs = malloc(sizeof(struct uml_pt_regs));
+	regs = uml_kmalloc(sizeof(struct uml_pt_regs), UM_GFP_ATOMIC);
 	if (!regs)
 		panic("out of memory");
 
-- 
2.7.3

[uml-devel] [PATCH 1/2] um: Setup physical memory in setup_arch()

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

Currently UML sets up physical memory very early,
long before setup_arch() was called by the kernel main
function.
This can cause problems when code paths in UML's memory setup
code assume that the kernel is already running.
i.e. when kmemleak is enabled it will evaluate current()
in free_bootmem(). That early current() is undefined and
UML explodes.

Solve the problem by setting up physical memory in setup_arch(),
at this stage the kernel has materialized and basic infrastructure
such as current() works.

Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/kernel/um_arch.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index 16630e7..e8175a8 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -319,9 +319,6 @@ int __init linux_main(int argc, char **argv)
 
 	start_vm = VMALLOC_START;
 
-	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
-	mem_total_pages(physmem_size, iomem_size, highmem);
-
 	virtmem_size = physmem_size;
 	stack = (unsigned long) argv;
 	stack &= ~(1024 * 1024 - 1);
@@ -334,7 +331,6 @@ int __init linux_main(int argc, char **argv)
 		printf("Kernel virtual memory size shrunk to %lu bytes\n",
 		       virtmem_size);
 
-	stack_protections((unsigned long) &init_thread_info);
 	os_flush_stdout();
 
 	return start_uml();
@@ -342,6 +338,10 @@ int __init linux_main(int argc, char **argv)
 
 void __init setup_arch(char **cmdline_p)
 {
+	stack_protections((unsigned long) &init_thread_info);
+	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
+	mem_total_pages(physmem_size, iomem_size, highmem);
+
 	paging_init();
 	strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
-- 
2.7.3

[uml-devel] [PATCH 2/2] um: Select HAVE_DEBUG_KMEMLEAK

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

Now we have the infrastructure to support kmemleak.
Enable the HAVE flag.

Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/Kconfig.common | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index cc00134..de562da 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -5,6 +5,7 @@ config UML
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
 	select HAVE_FUTEX_CMPXCHG if FUTEX
+	select HAVE_DEBUG_KMEMLEAK
 	select GENERIC_IRQ_SHOW
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IO
-- 
2.7.3

[uml-devel] [GIT PULL] UML updates for v4.7-rc1

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

Linus,

The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99:

  Linux 4.6-rc7 (2016-05-08 14:38:32 -0700)

are available in the git repository at:

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

for you to fetch changes up to a78ff1112263fdd871d3506dbcff44f6f12e8423:

  um: add extended processor state save/restore support (2016-05-21 23:38:06 +0200)

----------------------------------------------------------------
This pull request contains a nice FPU fixup from Eli Cooper for
UML.

----------------------------------------------------------------
Eli Cooper (3):
      um: fix FPU state preservation around signal handlers
      um: extend fpstate to _xstate to support YMM registers
      um: add extended processor state save/restore support

 arch/um/include/shared/registers.h    |  2 ++
 arch/um/kernel/process.c              |  2 +-
 arch/um/os-Linux/signal.c             | 28 ++++++++++++++------
 arch/x86/um/os-Linux/registers.c      | 49 +++++++++++++++++++++++++++++++++--
 arch/x86/um/ptrace_32.c               |  5 ++--
 arch/x86/um/ptrace_64.c               | 16 ++++++------
 arch/x86/um/shared/sysdep/ptrace_64.h |  4 +--
 arch/x86/um/signal.c                  | 37 +++++++++-----------------
 arch/x86/um/user-offsets.c            |  2 +-
 9 files changed, 95 insertions(+), 50 deletions(-)

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

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

Am Sonntag, den 22.05.2016, 17:39 +0200 schrieb Vegard Nossum:
> On 21 May 2016 at 20:18, Thomas Meyer <th...@m3...> wrote:
> > 
> > Am 21.05.2016 um 15:51 schrieb Vegard Nossum <vegard.nossum@gmail.c
> > om>:
> > > 
> > > I'm having some trouble with using current_thread_info() during
> > > UML
> > > early boot. Sometimes it works just fine, but often I get
> > > segfaults
> > > because current_thread_info() is returning an invalid pointer. It
> > > looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.
> > Mhh. Strange. Do you have a stack trace to call to current thread
> > info which ends up with a wrong value. I wonder from were it
> > originates.
> One such trace would be:
> 
> #2  0x000000006026652c in snprintf (buf=<optimized out>,
> size=<optimized out>, fmt=<optimized out>) at lib/vsprintf.c:2181
> #3  0x00000000600046f8 in setup_env_path () at arch/um/os-
> Linux/main.c:109
> #4  main (argc=3, argv=0x7ffc3d8c23e8, envp=<optimized out>) at
> arch/um/os-Linux/main.c:125
> 
> I wonder why setup_env_path() ends up calling the kernel's
> snprintf(),
> I thought that it would be using the glibc snprintf() at this point?

Mhh. Good question!

Doing a make ARCH=um V=1 arch/um/os-Linux/main.o

results in:

gcc -Wp,-MD,arch/um/os-Linux/.main.o.d -Wall -Wundef -Wstrict-
prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-
implicit-function-declaration -Wno-format-security -std=gnu89
-mcmodel=large -fno-builtin -m64 -funit-at-a-time -D__arch_um__
-Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback
-Din6addr_any=kernel_in6addr_any -Dstrrchr=kernel_strrchr
-D_LARGEFILE64_SOURCE  -fno-delete-null-pointer-checks -O2 --
param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone
-fno-partial-inlining -Wframe-larger-than=1024 -fno-stack-protector
-Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-
sibling-calls -fno-var-tracking-assignments -g -gdwarf-4 -Wdeclaration-
after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack 
-Werror=implicit-int -Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO
-I./arch/um/include/shared -I./arch/x86/um/shared
-I./arch/um/include/shared/skas  -D_FILE_OFFSET_BITS=64 -idirafter
./include -idirafter ./include -D__KERNEL__ -D__UM_HOST__ -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -include ./include/linux/kern_levels.h -include
user.h  -c -o arch/um/os-Linux/main.o arch/um/os-Linux/main.c

so it includes user.h and is under os-Linux. So I guess it should
actually call the glibc version, I'm not sure why it doesn't.

with kind regards
thomas


> 
> 
> Vegard
> 

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Vegard N. <veg...@gm...>]

On 21 May 2016 at 20:18, Thomas Meyer <th...@m3...> wrote:
> Am 21.05.2016 um 15:51 schrieb Vegard Nossum <veg...@gm...>:
>> I'm having some trouble with using current_thread_info() during UML
>> early boot. Sometimes it works just fine, but often I get segfaults
>> because current_thread_info() is returning an invalid pointer. It
>> looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.
>
> Mhh. Strange. Do you have a stack trace to call to current thread info which ends up with a wrong value. I wonder from were it originates.

One such trace would be:

#2  0x000000006026652c in snprintf (buf=<optimized out>,
size=<optimized out>, fmt=<optimized out>) at lib/vsprintf.c:2181
#3  0x00000000600046f8 in setup_env_path () at arch/um/os-Linux/main.c:109
#4  main (argc=3, argv=0x7ffc3d8c23e8, envp=<optimized out>) at
arch/um/os-Linux/main.c:125

I wonder why setup_env_path() ends up calling the kernel's snprintf(),
I thought that it would be using the glibc snprintf() at this point?


Vegard