user-mode-linux-devel

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

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

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

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

[Joel F. <agn...@gm...>]

On Wed, Mar 28, 2018 at 11:04 PM, Geert Uytterhoeven
<ge...@li...> wrote:
> On Thu, Mar 29, 2018 at 12:35 AM, Richard Weinberger <ri...@no...> wrote:
>> Am Donnerstag, 29. März 2018, 00:19:39 CEST schrieb Joel Fernandes:
>>> On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <ri...@no...> 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 <agn...@gm...>
>>> > wrote:
>>> >> >         while(release_now == 0);
>>> >>
>>> >> while (release_now == 0)
>>> >>         cpu_relax();
>>> >
>>> > Not sure whether a cpu_relax() fixes the problem.
>>> > I guess the root of the problem is that UML is UP and non-preemptive.
>>> > Therefore the loop is never interrupted.
>>> > To verify I asked for the full source.
>>> >
>>>
>>> cpu_relax actually worked!
>>
>> Interesting.
>>
>>> Any thoughts on why it helps? Even if its non-preemptive, I did
>>> receive the timer interrupt, so I expected the variable to be set.
>>
>> Timers trigger also with preempt off, I forgot...
>> I think the cpu_relax() issues internally a barrier such that the
>> release_now variable is read again.
>> Can you try barrier() instead of cpu_relax()? I bet it works too.
>> Same if you mark release_now as volatile.
>
> Without cpu_relax()/barrier()/volatile, the compiler can assume release_now
> never changes, and thus may "optimize" the loop to an infinite loop.
>

Thanks a lot! I am wondering why the same compiler works when running
the test for a regular image. Maybe different compiler flags. Anyway
good to learn this.

Also one more slightly OT question, why is UML only doing UP ? Is it
extremely hard to do SMP for UML?

I also happen to notice Qemu has one thread per emulated core...

thanks,

- Joel

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

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

Am Montag, 5. März 2018, 14:29:05 CEST schrieb ant...@ca...:
> From: Anton Ivanov <ant...@ca...>
> 
> 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 <ant...@ca...>

Applied.

Thanks,
//richard

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

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

Am Montag, 5. März 2018, 11:41:42 CEST schrieb ant...@ca...:
> From: Anton Ivanov <ant...@ca...>
> 
> 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 <ant...@ca...>

Applied.

Thanks,
//richard

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

[Geert U. <ge...@li...>]

On Thu, Mar 29, 2018 at 12:35 AM, Richard Weinberger <ri...@no...> wrote:
> Am Donnerstag, 29. März 2018, 00:19:39 CEST schrieb Joel Fernandes:
>> On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <ri...@no...> 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 <agn...@gm...>
>> > wrote:
>> >> >         while(release_now == 0);
>> >>
>> >> while (release_now == 0)
>> >>         cpu_relax();
>> >
>> > Not sure whether a cpu_relax() fixes the problem.
>> > I guess the root of the problem is that UML is UP and non-preemptive.
>> > Therefore the loop is never interrupted.
>> > To verify I asked for the full source.
>> >
>>
>> cpu_relax actually worked!
>
> Interesting.
>
>> Any thoughts on why it helps? Even if its non-preemptive, I did
>> receive the timer interrupt, so I expected the variable to be set.
>
> Timers trigger also with preempt off, I forgot...
> I think the cpu_relax() issues internally a barrier such that the
> release_now variable is read again.
> Can you try barrier() instead of cpu_relax()? I bet it works too.
> Same if you mark release_now as volatile.

Without cpu_relax()/barrier()/volatile, the compiler can assume release_now
never changes, and thus may "optimize" the loop to an infinite loop.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

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 <ri...@no...> 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 <agn...@gm...>
> > 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

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

[Joel F. <agn...@gm...>]

Thanks for the quick reply.

On Wed, Mar 28, 2018 at 6:19 AM, Richard Weinberger <ri...@no...> 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 <agn...@gm...>
> wrote:
>> >         while(release_now == 0);
>>
>> while (release_now == 0)
>>         cpu_relax();
>
> Not sure whether a cpu_relax() fixes the problem.
> I guess the root of the problem is that UML is UP and non-preemptive.
> Therefore the loop is never interrupted.
> To verify I asked for the full source.
>

cpu_relax actually worked!

Any thoughts on why it helps? Even if its non-preemptive, I did
receive the timer interrupt, so I expected the variable to be set.

Module is attached.

Thanks,
-Joel

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

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

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

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

[Geert U. <ge...@li...>]

On Wed, Mar 28, 2018 at 12:28 PM, Joel Fernandes <agn...@gm...> wrote:
>         while(release_now == 0);

while (release_now == 0)
        cpu_relax();

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

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

[uml-devel] UML hangs with hrtimer test module

[Joel F. <agn...@gm...>]

Hi,

I wrote a kernel module to play with hrtimer subsystem and it hangs
with UML, Any ideas on why it may be hanging? It doesn't hang on any
of my other machines. Hopefully I'm not doing something stupid, but I
don't think I am..

It appears the timer handler does fire. However, the UML process is
continously doing a kill(SIGALRM) to the host, and the shell hangs.
Here's the continous strace output of UML's process at the time of the
hang: https://hastebin.com/ikehadapon.sql

To build UML, I do:
make ARCH=um x86_64_defconfig

UML kernel version is v4.16-rc4

Here's the module I'm loading:

static enum hrtimer_restart bigtimer_handle(struct hrtimer *timer)
{
        printk(KERN_ERR "timer fired 2\n");
        spin_lock(&il->biglock);
        spin_unlock(&il->biglock);

        release_now = 1;

        return HRTIMER_NORESTART;
}

void init_bigstr(struct bigstr *b)
{
        spin_lock_init(&b->biglock);
}

static int __init test_module_init(void)
{
        struct bigstr b1, b2;
        struct hrtimer *timer;

        release_now = 0;

        init_bigstr(&b1);
        init_bigstr(&b2);

        timer = &bigtimer;
        timer->debug = 1;

        hrtimer_init(timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
        timer->function = bigtimer_handle;

        il = &b2;
        spin_lock(&b1.biglock);

        printk(KERN_ERR "Starting timer\n");
        hrtimer_start(timer, ns_to_ktime(50000ULL),
                      HRTIMER_MODE_REL_PINNED);

        while(release_now == 0);

        spin_unlock(&b1.biglock);
        return -1;
}


Thanks for any debug thoughts!
I'll also try to hook up gdb tomorrow and see if I find something..

Regards,

- Joel

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

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

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

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

[Bernd P. <be...@pe...>]

On Mon, 2018-03-19 at 15:24 +0100, Richard Weinberger wrote:
[...]
> I checked, migrating is not an option.
> sourceforge has hacked mailman to hide member mail addresses:
> "As a result of the latest electronic messaging and privacy requirements 
> around the world, SourceForge has implemented a number of changes that affect 

Details please, sf.net.
Otherwise the motivation is very probably a completely different one.

> email privacy. One part of this is that it is no longer possible for project 
> admins to view the member emails of their mailing lists."

As absurd as it can get if an ML admin isn't allowed to see the email
addresses on his/her list.

It seems sf.net wants to be abandoned in general ....

Just create the new - better - list/s and send subscription
information!

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : be...@pe...
                     LUGA : http://www.luga.at

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

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

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 <ri...@no...> 
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_.

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

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

On 03/13/18 13:59, Richard Weinberger wrote:
> 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 <ri...@no...> 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. ;-)

+1

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

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

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

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 <ri...@no...> 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

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

[Geert U. <ge...@li...>]

Hi Richard,

On Mon, Mar 12, 2018 at 4:21 PM, Richard Weinberger <ri...@no...> 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

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

On 03/12/18 15:10, Brandeburg, Jesse wrote:
>> 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.
>
>
Thanks,

I will try to pin it down. A couple of mails where I had the list cc-ed 
for patches never came back to me. I need to check if they show up in 
the archive.

A.

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

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

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

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

[Brandeburg, J. <jes...@in...>]

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

[uml-devel] Is the list working correctly

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

HI all,

Is the list working for everyone?

I did not get the last two messages I sent to the list. Nothing in the 
logs on my side either - they were accepted by sourceforge, but no 
attempts to send them back.

A

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

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

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...@ad...>
> CC: Richard Weinberger <ri...@no...>
> CC: use...@li...
> Signed-off-by: Dominik Brodowski <li...@do...>

Acked-by: Richard Weinberger <ri...@no...>

Thanks,
//richard

[uml-devel] [PATCH] uml: Fix build with recent glibc

[Andi K. <an...@fi...>]

From: Andi Kleen <ak...@li...>

Newer glibc did some include namespace "cleanups" and removed
struct ucontext and friends. This already broke a lot of software,
and UML seems to be the latest victim.

Use the typedefs which are still available. They also work on
older glibcs.

Signed-off-by: Andi Kleen <ak...@li...>
---
 arch/um/os-Linux/signal.c | 2 +-
 arch/x86/um/stub_segv.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index a86d7cc2c2d8..a5c0c909c48b 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -159,7 +159,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->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..fd6825537b97 100644
--- a/arch/x86/um/stub_segv.c
+++ b/arch/x86/um/stub_segv.c
@@ -10,7 +10,7 @@
 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->uc_mcontext);
-- 
2.14.3

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

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

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.

[uml-devel] [PATCH] um: fix user mode linux build

[Jesse B. <jes...@in...>]

Not sure when it got broken, but without this patch the command
make ARCH=um defconfig
make ARCH=um

fails due to struct ucontext being undefined.
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->uc_mcontext;
<there are two errors like the above>

The fix seems fairly simple, that the code just needs to use
ucontext_t define instead.

I didn't verify that user-mode-linux is working after this change,
just that it builds successfully.

Cc: Jeff Dike <jd...@ad...>
Cc: Richard Weinberger <ri...@no...>
Cc: use...@li...
Signed-off-by: Jesse Brandeburg <jes...@in...>
---
 arch/um/os-Linux/signal.c | 2 +-
 arch/x86/um/stub_segv.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index a86d7cc2c2d8..a5c0c909c48b 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -159,7 +159,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->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..fd6825537b97 100644
--- a/arch/x86/um/stub_segv.c
+++ b/arch/x86/um/stub_segv.c
@@ -10,7 +10,7 @@
 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->uc_mcontext);
-- 
2.14.3