user-mode-linux-user

Re: [uml-user] Welcome to the "User-mode-linux-user" mailing list

[renjianxinlover <ren...@16...>]

hi,  referring to the doc: http://eggdrop.ch/texts/uml/  and  https://gist.github.com/AVGP/5410903 for debian stretch UML installation
as a result, run script output looks like
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Adding 5685248 bytes to physical memory to account for exec-shield gap
Linux version 4.9.25 (root@x86-csail-01) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #2 Sun May 21 14:29:37 UTC 2017
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65878
Kernel command line: mem=256M eth0=daemon root=98:0
PID hash table entries: 2048 (order: 2, 16384 bytes)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 245644K/267696K available (4935K kernel code, 1259K rwdata, 1356K rodata, 157K init, 232K bss, 22052K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:15
clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
Calibrating delay loop... 6631.42 BogoMIPS (lpj=33157120)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Yama: disabled by default; enable with sysctl kernel.yama.*
SELinux: Initializing.
AppArmor: AppArmor disabled by boot time parameter
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
devtmpfs: initialized
Using 2.6 host AIO
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: 0, 6144 bytes)
xor: measuring software checksum speed
8regs : 23990.400 MB/sec
8regs_prefetch: 22278.400 MB/sec
32regs : 23095.600 MB/sec
32regs_prefetch: 21914.800 MB/sec
xor: using function: 8regs (23990.400 MB/sec)
NET: Registered protocol family 16
raid6: int64x1 gen() 4185 MB/s
raid6: int64x1 xor() 2112 MB/s
raid6: int64x2 gen() 4034 MB/s
raid6: int64x2 xor() 2482 MB/s
raid6: int64x4 gen() 2923 MB/s
raid6: int64x4 xor() 2406 MB/s
raid6: int64x8 gen() 3401 MB/s
raid6: int64x8 xor() 2299 MB/s
raid6: using algorithm int64x1 gen() 4185 MB/s
raid6: .... xor() 2112 MB/s, rmw enabled
raid6: using intx1 recovery algorithm
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
clocksource: Switched to clocksource timer
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
console [stderr0] disabled
mconsole (version 2) initialized on /root/.uml/mDx5TS/mconsole
Checking host MADV_REMOVE support...OK
Mapper v0.1
mmapper_init - find_iomem failed
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1661404030.232:1): initialized
workingset: timestamp_bits=46 max_order=16 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFS: nTxBlock = 1919, nTxLock = 15352
SGI XFS with ACLs, security attributes, realtime, no debug enabled
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
NET: Registered protocol family 17
Initialized stdio console driver
Console initialized on /dev/tty0
console [tty0] enabled
Initializing software serial port version 1
Choosing a random ethernet address for device eth0
Netdevice 0 (32:49:32:98:ef:73) : daemon backend (uml_switch version 3) - unix:/var/run/uml-utilities/uml_switch.ctl

console [mc-1] enabled
registered taskstats version 1
zswap: default zpool zbud not available
zswap: pool creation failed
Btrfs loaded, crc32c=crc32c-generic
winch_thread : TIOCSCTTY failed on fd 1 err = 1
EXT4-fs (ubda): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ubda): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
random: fast init done
devtmpfs: mounted
This architecture does not have kernel memory protection.
SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.30: No such file or directory
systemd[1]: Failed to insert module 'autofs4': No such file or directory
systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
systemd[1]: Detected virtualization kvm.
systemd[1]: Detected architecture x86-64.

Welcome to Debian GNU/Linux 9 (stretch)!

systemd[1]: Set hostname to <uml-demo-host>.
systemd[1]: Failed to enable kbrequest handling: Inappropriate ioctl for device
systemd[1]: Listening on Journal Socket.
[ OK ] Listening on Journal Socket.
systemd[1]: Listening on Journal Socket (/dev/log).
[ OK ] Listening on Journal Socket (/dev/log).
systemd[1]: Listening on udev Kernel Socket.
[ OK ] Listening on udev Kernel Socket.
systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
systemd[1]: Created slice System Slice.
[ OK ] Created slice System Slice.
Starting Remount Root and Kernel File Systems...
Starting Load Kernel Modules...
Starting Create Static Device Nodes in /dev...
[ OK ] Started Dispatch Password Requests to Console Directory Watch.
Mounting POSIX Message Queue File System...
[ OK ] Created slice User and Session Slice.
[ OK ] Reached target Slices.
[ OK ] Created slice system-getty.slice.
[ OK ] Listening on Journal Audit Socket.
[UNSUPP] Starting of Arbitrary Executable File Formats File System Automount Point not supported.
[ OK ] Reached target Remote File Systems.
[ OK ] Listening on udev Control Socket.
[ OK ] Started Forward Password Requests to Wall Directory Watch.
[ OK ] Reached target Encrypted Volumes.
[ OK ] Reached target Paths.
[ OK ] Reached target Swap.
[ OK ] Listening on Syslog Socket.
Starting Journal Service...
[ OK ] Started Load Kernel Modules.
[ OK ] Mounted POSIX Message Queue File System.
EXT4-fs (ubda): re-mounted. Opts: (null)
Starting Apply Kernel Variables...
[ OK ] Started Remount Root and Kernel File Systems.
Starting Load/Save Random Seed...
Starting udev Coldplug all Devices...
[ OK ] Started Create Static Device Nodes in /dev.
Starting udev Kernel Device Manager...
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
[ OK ] Started Load/Save Random Seed.
[ OK ] Started Journal Service.
Starting Flush Journal to Persistent Storage...
[ OK ] Started Apply Kernel Variables.
Starting Raise network interfaces...
[ OK ] Started udev Kernel Device Manager.
systemd-journald[842]: Received request to flush runtime journal from PID 1
[ OK ] Started Flush Journal to Persistent Storage.
Starting Create Volatile Files and Directories...
[ OK ] Started Create Volatile Files and Directories.
Starting Update UTMP about System Boot/Shutdown...
Starting Network Time Synchronization...
[ OK ] Started Update UTMP about System Boot/Shutdown.
[ OK ] Started Network Time Synchronization.
[ OK ] Reached target System Time Synchronized.
[ OK ] Started udev Coldplug all Devices.
[ OK ] Reached target System Initialization.
[ OK ] Listening on D-Bus System Message Bus Socket.
[ OK ] Reached target Sockets.
[ OK ] Reached target Basic System.
Starting Login Service...
[ OK ] Started Regular background program processing daemon.
[ OK ] Started D-Bus System Message Bus.
[ OK ] Started Daily Cleanup of Temporary Directories.
[ OK ] Started Daily apt download activities.
Starting System Logging Service...
[ OK ] Started Daily apt upgrade and clean activities.
[ OK ] Reached target Timers.
xterm_open: $DISPLAY not set.
[ OK ] Started Login Service.
[ OK ] Started Raise network interfaces.
[ OK ] Reached target Network.
Starting OpenBSD Secure Shell server...
Starting Permit User Sessions...
[ OK ] Started Permit User Sessions.
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Started OpenBSD Secure Shell server.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
random: crng init done
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
[ OK ] Stopped Getty on tty1.
[ OK ] Started Getty on tty1.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
[ OK ] Stopped Getty on tty1.
[ OK ] Started Getty on tty1.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.
xterm_open: $DISPLAY not set.






x window boot repeatedly comes and it seems config option not working with uml creation script above, any suggestion?


Brs
| |
renjianxinlover
|
|
ren...@16...
|
On 8/25/2022 13:22，<use...@li...> wrote：
Welcome to the Use...@li... mailing
list!

To post to this list, send your message to:

use...@li...

General information about the mailing list is at:

https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

If you ever want to unsubscribe or change your options (eg, switch to
or from digest mode, change your password, etc.), visit your
subscription page at:

https://lists.sourceforge.net/lists/options/user-mode-linux-user/renjianxinlover%40163.com


You can also make such adjustments via email by sending a message to:

Use...@li...

with the word `help' in the subject or body (don't include the
quotes), and you will get back a message with instructions.

You must know your password to change your options (including changing
the password, itself) or to unsubscribe without confirmation.  It is:

woebugev

Normally, Mailman will remind you of your lists.sourceforge.net
mailing list passwords once every month, although you can disable this
if you prefer.  This reminder will also include instructions on how to
unsubscribe or change your account options.  There is also a button on
your options page that will email your current password to you.

Re: [uml-user] This script ends up generating a UML guest and ends with a Kernel Panic

[Steven A. <wan...@gm...>]

HI! so i have updated my script.. Thanks for the help #linux and #bash
guys! Much appreciated!

@ the url is an updated script which fails  with a memory allocation error.

This script should be pretty much self contained. Run it on a  virt manager
guest or some other VM platform , it is tested on Ubuntu 22.04.
See url.


https://bpa.st/5Z2A


Regards,


SA

[uml-user] This script ends up generating a UML guest and ends with a Kernel Panic

[Steven A. <wan...@gm...>]

Hi!

Thanks in advance for the help!!

This self contained script generates a kernel panic error.

https://bpa.st/NKAQ

It has been tested on Ubuntu 22.04.

It builds a debian UML guest disk and builds a UML kernel from the latest
available configuration with a late kernel linux-5.5.3 with a couple other
.config changes that I have been able to figure out are needed for sure.

Can anyone run this on a new Ubuntu 22.04 VM instance and see if you tell
me the cause of the kernel panic?

It will take about 20 minutes to run.

Look over the source code before running it of course , but it is designed
to be self contained and cleans up after itself and builds in a directory
that I am sure doesn't exist on your server [but it should be a VM that you
don't care about (just in case)]. It will need internet access to download
the sources.

NOTE: the kernel panic code is not enabled and will not run. The patch that
I think is applicable doesn't work on the x86_64 platform. Like this script
is built on, but I think the panic error is almost an exact match only it
was designed for android arch!

Thanks again for the help figuring out how to fix it! It's much appreciated!

Regards,


Steven

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

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

Hi!

The new mailing list address is: lin...@li...

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

Thanks,
//richard

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

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

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

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

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

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

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d948bb..4834d1551248 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14768,8 +14768,7 @@ F:	drivers/media/usb/zr364xx/
 USER-MODE LINUX (UML)
 M:	Jeff Dike <jd...@ad...>
 M:	Richard Weinberger <ri...@no...>
-L:	use...@li...
-L:	use...@li...
+L:	lin...@li...
 W:	http://user-mode-linux.sourceforge.net
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
 S:	Maintained
-- 
2.13.6

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

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

Am Donnerstag, 5. April 2018, 23:21:02 CEST schrieb Hernán Gonzalez:
> This option restores the DEBUG_BUGVERBOSE functionality as it was
> previous to commit 9a93848fe787 ("x86/debug: Implement __WARN() using
> UD0").
> 
> Signed-off-by: Hernán Gonzalez <he...@va...>

Applied.

Thanks,
//richard

[uml-user] [PATCH] um: Add HAVE_DEBUG_BUGVERBOSE.

[Hernán G. <he...@va...>]

This option restores the DEBUG_BUGVERBOSE functionality as it was
previous to commit 9a93848fe787 ("x86/debug: Implement __WARN() using
UD0").

Signed-off-by: Hernán Gonzalez <he...@va...>
---
 arch/um/Kconfig.common | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index c68add8..bf2a70f 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -8,6 +8,7 @@ config UML
 	select HAVE_UID16
 	select HAVE_FUTEX_CMPXCHG if FUTEX
 	select HAVE_DEBUG_KMEMLEAK
+	select HAVE_DEBUG_BUGVERBOSE
 	select GENERIC_IRQ_SHOW
 	select GENERIC_CPU_DEVICES
 	select GENERIC_CLOCKEVENTS
-- 
2.7.4

[uml-user] What is the current state of User Mode Linux?

[Grant T. <gt...@tn...>]

What is the current state of User Mode Linux?  Most of what I'm finding 
on line is documentation between 10 years (± 5 years) old.

It's been about 15 years since I last did anything serious with UML and 
I'm wondering about it's current state.

I'm particularly interested in the possibility of using UML with 
namespaces (lightweight containers) so that I can work with different 
kernel versions on the same host.



-- 
Grant. . . .
unix || die

[uml-user] "Kernel panic - not syncing: Kernel mode signal 8" error on running UML

[Vijay T. <vi...@in...>]

Hi All,

System configuration:
rootfs: Fedora21-AMD64-root_fs
linux image: Linux  4.13.11 #11 Wed Nov 29 10:31:11 IST 2017 x86_64 
x86_64 x86_64 GNU/Linux

     Getting below two errors on running UML. Don't know exact steps to 
re-produce the issue but if I leave the UML idle for more than 30 mins, 
problem occurs. reproducibility is 1/3.

1)
--------------------------------------------------------------------------------
io_thread - read failed, fd = 5, err = 0
io_thread - read failed, fd = 5, err = 4,reminder = 0
Kernel panic - not syncing: Kernel mode signal 8
--------------------------------------------------------------------------------

2)
--------------------------------------------------------------------------------
io_thread - read failed, fd = 5, err = 4,reminder = 0
do_io - write failed err = 9 fd = 152767770
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
do_io - read failed, err = 29 fd = 0
Kernel panic - not syncing: Kernel mode signal 8
--------------------------------------------------------------------------------

output of mount:
--------------------------------------------------------------------------------
findmnt
TARGET                       SOURCE    FSTYPE   OPTIONS
/                            /dev/ubda ext4 rw,relatime,data=ordered
|-/dev                       devtmpfs  devtmpfs rw,relatime,mode=755
| |-/dev/shm                 tmpfs     tmpfs    rw,nosuid,nodev
| |-/dev/pts                 devpts    devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
| `-/dev/mqueue              mqueue    mqueue   rw,relatime
|-/sys                       sysfs     sysfs rw,nosuid,nodev,noexec,relatime
| `-/sys/fs/cgroup           tmpfs     tmpfs ro,nosuid,nodev,noexec,mode=755
|   |-/sys/fs/cgroup/systemd cgroup    cgroup 
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,
|   |-/sys/fs/cgroup/cpu,cpuacct
                              cgroup    cgroup 
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
|   |-/sys/fs/cgroup/blkio   cgroup    cgroup 
rw,nosuid,nodev,noexec,relatime,blkio
|   |-/sys/fs/cgroup/devices cgroup    cgroup 
rw,nosuid,nodev,noexec,relatime,devices
|   `-/sys/fs/cgroup/freezer cgroup    cgroup 
rw,nosuid,nodev,noexec,relatime,freezer
|-/proc                      proc      proc rw,nosuid,nodev,noexec,relatime
|-/run                       tmpfs     tmpfs rw,nosuid,nodev,mode=755
|-/tmp                       tmpfs     tmpfs    rw
|-/etc/tejas                 /dev/ubdc ext4 rw,relatime,data=ordered
`-/etc/bin                   /dev/ubdd ext4 rw,relatime,data=ordered

--------------------------------------------------------------------------------
/dev/ubda on / type ext4 (rw,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
/dev/ubdd on /etc/bin type ext4 (rw,relatime,data=ordered)
/dev/ubdc on /etc/tejas type ext4 (rw,relatime,data=ordered)
--------------------------------------------------------------------------------

If any of you faced the similar issue and have a solution, please let me 
know.

Thanks,
Vijay

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

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

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 <dan...@or...>
> > 
> > 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(&vp->lock, flags);
> > 
> > -	if (vp->opened)
> > +	if (vp->opened) {
> > +		spin_unlock_irqrestore(&vp->lock, flags);
> > 
> >  		return -ENXIO;
> > 
> > +	}
> > 
> >  	vp->opened = true;
> >  	spin_unlock_irqrestore(&vp->lock, flags);

Please review/ack these patches.

Thanks,
//richard

[uml-user] [PATCH] um/time: use timespec64 for persistent clock

[Arnd B. <ar...@ar...>]

This read_persistent_clock() implementation is the only remaining
caller of set_normalized_timespec(). Using read_persistent_clock64()
and set_normalized_timespec64() instead lets us remove the deprecated
interface in the future and helps make 32-bit arch/um get closer to
working beyond 2038.

Signed-off-by: Arnd Bergmann <ar...@ar...>
---
 arch/um/kernel/time.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 7f69d17de354..052de4c8acb2 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -121,12 +121,12 @@ static void __init um_timer_setup(void)
 	clockevents_register_device(&timer_clockevent);
 }
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
 	long long nsecs = os_persistent_clock_emulation();
 
-	set_normalized_timespec(ts, nsecs / NSEC_PER_SEC,
-				nsecs % NSEC_PER_SEC);
+	set_normalized_timespec64(ts, nsecs / NSEC_PER_SEC,
+				  nsecs % NSEC_PER_SEC);
 }
 
 void __init time_init(void)
-- 
2.9.0

Re: [uml-user] [PATCH] um: Use common error handling code in port_listen_fd()

[Joe P. <jo...@pe...>]

On Fri, 2017-10-20 at 19:29 +0200, SF Markus Elfring wrote:
> arch/um/drivers/port_user.c

If you are going to use multiple labels,
it'd be nicer to rename out: too.

Re: [uml-user] [PATCH] um: Correctly check for PTRACE_GETRESET/SETREGSET

[Florian F. <f.f...@gm...>]

On 07/06/2017 12:35 AM, Richard Weinberger wrote:
> When checking for PTRACE_GETRESET/SETREGSET, make sure that
> the correct header file is included. We need linux/ptrace.h
> which contains all ptrace UAPI related defines.
> Otherwise #if defined(PTRACE_GETRESET) is always false.
> 
> Cc: Florian Fainelli <f.f...@gm...>
> Signed-off-by: Richard Weinberger <ri...@no...>

Ah ah, I see what happened now, because of this invalid include, I was
indeed getting PTRACE_GETREGSET not to be defined, which happened to
solve the build failure I was seeing against 2.6.32. Your fix is
correct, but we actually need a better way to determine whether struct
_xstate is defined or not.

Now that we have this change in place, I can hit the following build
failure (again):

arch/x86/um/user-offsets.c: In function 'foo':
arch/x86/um/user-offsets.c:54: error: invalid application of 'sizeof' to
incomplete type 'struct _xstate'

This is because we have included signal.h which includes
bits/sigcontext.h which does not have a _xstate structure definition.

A possible fix would be:

diff --git a/arch/x86/um/user-offsets.c b/arch/x86/um/user-offsets.c
index ae4cd58c0c7a..02250b2633b8 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
-#if defined(PTRACE_GETREGSET) && defined(PTRACE_SETREGSET)
+#ifdef FP_XSTATE_MAGIC1
        DEFINE(HOST_FP_SIZE, sizeof(struct _xstate) / sizeof(unsigned
long));
 #else
        DEFINE(HOST_FP_SIZE, sizeof(struct _fpstate) / sizeof(unsigned
long));

I incorrectly linked PTRACE_GETREGSET and PTRACE_SETREGSET with the
introduce of the _xstate...


> ---
>  arch/x86/um/user-offsets.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/um/user-offsets.c b/arch/x86/um/user-offsets.c
> index 8af0fb5d2780..ae4cd58c0c7a 100644
> --- a/arch/x86/um/user-offsets.c
> +++ b/arch/x86/um/user-offsets.c
> @@ -5,7 +5,7 @@
>  #include <sys/mman.h>
>  #include <sys/user.h>
>  #define __FRAME_OFFSETS
> -#include <asm/ptrace.h>
> +#include <linux/ptrace.h>
>  #include <asm/types.h>
>  
>  #ifdef __i386__
> 


-- 
Florian

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

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

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

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

[Florian F. <f.f...@gm...>]

On 06/05/2017 12:34 PM, Richard Weinberger wrote:
> 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 <f.f...@gm...>
>>
>> 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.

Humm okay, did you apply the patch in one of your kernel trees on
git.kernel.org or somewhere else?
-- 
Florian

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

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

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 <kr...@ke...>

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

Thanks,
//richard

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

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

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 <f.f...@gm...>
> 
> 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

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

[Florian F. <f.f...@gm...>]

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 <f.f...@gm...>

Richard, we are kind of hijacking this thread now that was originally
about statically linking UML, is this particular patch okay?

> ---
> Changes in v2:
> - fix typo introduced on longjmp
> 
>  arch/um/Makefile        |  4 ++++
>  arch/x86/um/setjmp_32.S | 16 ++++++++--------
>  arch/x86/um/setjmp_64.S | 16 ++++++++--------
>  3 files changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/um/Makefile b/arch/um/Makefile
> index 0ca46ededfc7..6ca4f66085c1 100644
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -59,10 +59,14 @@ KBUILD_CPPFLAGS += -I$(srctree)/$(HOST_DIR)/um
>  # Same things for in6addr_loopback and mktime - found in libc. For these two we
>  # only get link-time error, luckily.
>  #
> +# -Dlongjmp=kernel_longjmp prevents anything from referencing the libpthread.a
> +# embedded copy of longjmp, same thing for setjmp.
> +#
>  # These apply to USER_CFLAGS to.
>  
>  KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ \
>  	$(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap	\
> +	-Dlongjmp=kernel_longjmp -Dsetjmp=kernel_setjmp \
>  	-Din6addr_loopback=kernel_in6addr_loopback \
>  	-Din6addr_any=kernel_in6addr_any -Dstrrchr=kernel_strrchr
>  
> diff --git a/arch/x86/um/setjmp_32.S b/arch/x86/um/setjmp_32.S
> index b766792c9933..39053192918d 100644
> --- a/arch/x86/um/setjmp_32.S
> +++ b/arch/x86/um/setjmp_32.S
> @@ -16,9 +16,9 @@
>  
>  	.text
>  	.align 4
> -	.globl setjmp
> -	.type setjmp, @function
> -setjmp:
> +	.globl kernel_setjmp
> +	.type kernel_setjmp, @function
> +kernel_setjmp:
>  #ifdef _REGPARM
>  	movl %eax,%edx
>  #else
> @@ -35,13 +35,13 @@ setjmp:
>  	movl %ecx,20(%edx)		# Return address
>  	ret
>  
> -	.size setjmp,.-setjmp
> +	.size kernel_setjmp,.-kernel_setjmp
>  
>  	.text
>  	.align 4
> -	.globl longjmp
> -	.type longjmp, @function
> -longjmp:
> +	.globl kernel_longjmp
> +	.type kernel_longjmp, @function
> +kernel_longjmp:
>  #ifdef _REGPARM
>  	xchgl %eax,%edx
>  #else
> @@ -55,4 +55,4 @@ longjmp:
>  	movl 16(%edx),%edi
>  	jmp *20(%edx)
>  
> -	.size longjmp,.-longjmp
> +	.size kernel_longjmp,.-kernel_longjmp
> diff --git a/arch/x86/um/setjmp_64.S b/arch/x86/um/setjmp_64.S
> index 45f547b4043e..c56942e1a38c 100644
> --- a/arch/x86/um/setjmp_64.S
> +++ b/arch/x86/um/setjmp_64.S
> @@ -18,9 +18,9 @@
>  
>  	.text
>  	.align 4
> -	.globl setjmp
> -	.type setjmp, @function
> -setjmp:
> +	.globl kernel_setjmp
> +	.type kernel_setjmp, @function
> +kernel_setjmp:
>  	pop  %rsi			# Return address, and adjust the stack
>  	xorl %eax,%eax			# Return value
>  	movq %rbx,(%rdi)
> @@ -34,13 +34,13 @@ setjmp:
>  	movq %rsi,56(%rdi)		# Return address
>  	ret
>  
> -	.size setjmp,.-setjmp
> +	.size kernel_setjmp,.-kernel_setjmp
>  
>  	.text
>  	.align 4
> -	.globl longjmp
> -	.type longjmp, @function
> -longjmp:
> +	.globl kernel_longjmp
> +	.type kernel_longjmp, @function
> +kernel_longjmp:
>  	movl %esi,%eax			# Return value (int)
>  	movq (%rdi),%rbx
>  	movq 8(%rdi),%rsp
> @@ -51,4 +51,4 @@ longjmp:
>  	movq 48(%rdi),%r15
>  	jmp *56(%rdi)
>  
> -	.size longjmp,.-longjmp
> +	.size kernel_longjmp,.-kernel_longjmp
> 


-- 
Florian

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

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

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

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

[Florian F. <f.f...@gm...>]

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

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

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

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

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

[Florian F. <f.f...@gm...>]

On 05/24/2017 09:19 AM, Florian Fainelli wrote:
> On 05/24/2017 12:02 AM, Richard Weinberger wrote:
>> 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?
> 
> 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?
-- 
Florian

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

[Florian F. <f.f...@gm...>]

On 05/24/2017 12:02 AM, Richard Weinberger wrote:
> 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?

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?
-- 
Florian

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

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

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

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

[Florian F. <f.f...@gm...>]

On 05/23/2017 02:08 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 <f.f...@gm...>
> ---

> -	.globl longjmp
> -	.type longjmp, @function
> -longjmp:
> +	.globl kernel_jongjmp
> +	.type kernel_jongjmp, @function
> +kernel_jongjmp:

Dyslexia at its finest, I will submit a corrected v2, the perils of
switching between machines....

-- 
Florian