Am 01.06.2014 15:08, schrieb Real Name:
From: Honggang Li enjoymind...@gmail.com
1) uml kernel bootmem managed through bootmem_data-node_bootmem_map,
not the struct page array, so the array is unnecessary.
2) the bootmem struct page array has been pointed by a *local* pointer,
struct page
On Fri, May 30, 2014 at 11:17 AM, Richard Weinberger
richard.weinber...@gmail.com wrote:
On Fri, May 30, 2014 at 10:24 AM, enjoy mindful enjoymind...@gmail.com
wrote:
Hi,
When I'm trace uml kernel with gdb, I found there are two mem_map
(struct page) arrays.
1) the first one created
On Fri, May 30, 2014 at 10:24 AM, enjoy mindful enjoymind...@gmail.com wrote:
Hi,
When I'm trace uml kernel with gdb, I found there are two mem_map
(struct page) arrays.
1) the first one created in init_maps function, and pointed by *local*
pointer struct page *map in init_maps function
There is no need to go through handle_page_fault().
If we try to access the zero page in kernel mode just panic().
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/trap.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/um/kernel/trap.c b/arch
handler is not designed to fix such faults the
SIGSEGV stays and UML consumes all CPU handling SIGSEGV.
The only sane thing we can do here is calling panic().
This patch helps to detect bad memory access from the kernel side.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/trap.c
Am 10.05.2014 01:43, schrieb Joe Perches:
Joe Perches (4):
UserModeLinux: Convert UM_KERN_LEVEL to KERN_LEVEL
UserModeLinux: Remove unused #defines of UM_KERN_LEVEL
UserModeLinux: Use a more current logging style
UserModeLinux: Convert printks to pr_level
Am 14.05.2014 22:07, schrieb Joe Perches:
On Wed, 2014-05-14 at 21:52 +0200, Richard Weinberger wrote:
Am 10.05.2014 01:43, schrieb Joe Perches:
Joe Perches (4):
UserModeLinux: Convert UM_KERN_LEVEL to KERN_LEVEL
UserModeLinux: Remove unused #defines of UM_KERN_LEVEL
UserModeLinux: Use
This fixes a long standing problem that UML crashes
or locks up if a task messes with it' stub vma.
Reported-by: toralf.foers...@gmx.de
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/tlb.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git
This reverts commit 0974a9cadc7886f7baaa458bb0c89f5c5f9d458e.
It was a bad idea and was only papering over the real issue.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/os-Linux/skas/process.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/um/os
On Sat, May 3, 2014 at 6:04 PM, Toralf Förster toralf.foers...@gmx.de wrote:
I could force a crash using latest kernel tree (v3.15-rc3-159-g6c6ca9c with
applied fix3.patch for the mremap syscall) and latest trinity tree
(1.1-1349-g18ebf71).
The backtrace of the core dump gives :
Am 01.05.2014 23:34, schrieb Toralf Förster:
On 05/01/2014 10:57 PM, Richard Weinberger wrote:
Toralf,
Yeah, this is because trinity destroys the UML stub code.
Please test the attached patch, it should fix the root cause of the problem.
Thanks,
//richard
If I do just apply fix2.patch
Am 01.05.2014 23:34, schrieb Toralf Förster:
On 05/01/2014 10:57 PM, Richard Weinberger wrote:
Toralf,
Yeah, this is because trinity destroys the UML stub code.
Please test the attached patch, it should fix the root cause of the problem.
Thanks,
//richard
If I do just apply fix2.patch
On Fri, May 2, 2014 at 8:43 AM, st...@nixia.no wrote:
Yeah, this is because trinity destroys the UML stub code.
Please test the attached patch, it should fix the root cause of the
problem.
@@ -124,6 +125,9 @@ static int add_munmap(unsigned long addr, unsigned
long len,
struct
Am 02.05.2014 16:07, schrieb Toralf Förster:
On 05/02/2014 09:46 AM, Richard Weinberger wrote:
Am 01.05.2014 23:34, schrieb Toralf Förster:
On 05/01/2014 10:57 PM, Richard Weinberger wrote:
Toralf,
Yeah, this is because trinity destroys the UML stub code.
Please test the attached patch
On Wed, Apr 30, 2014 at 8:19 PM, Toralf Förster toralf.foers...@gmx.de wrote:
-or- it uncovers a bug in kernel v3.15-rc3 for UML:
UML most not panic. :)
Do you have the trinity logs?
I'd like to know the syscalls parameters.
It looks like trinity managed it to crash a thread on the host side.
Am 01.05.2014 12:29, schrieb Toralf Förster:
On 05/01/2014 11:22 AM, Richard Weinberger wrote:
On Wed, Apr 30, 2014 at 8:19 PM, Toralf Förster toralf.foers...@gmx.de
wrote:
-or- it uncovers a bug in kernel v3.15-rc3 for UML:
UML most not panic. :)
Do you have the trinity logs?
I'd like
Toralf,
Am 01.05.2014 17:15, schrieb Toralf Förster:
On 05/01/2014 02:33 PM, Richard Weinberger wrote:
Am 01.05.2014 12:29, schrieb Toralf Förster:
On 05/01/2014 11:22 AM, Richard Weinberger wrote:
On Wed, Apr 30, 2014 at 8:19 PM, Toralf Förster toralf.foers...@gmx.de
wrote
Linus,
The following changes since commit a798c10faf62a505d24e5f6213fbaf904a39623f:
Linux 3.15-rc2 (2014-04-20 11:08:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus
for you to fetch changes up to
Am 07.03.2014 19:37, schrieb anton.iva...@kot-begemot.co.uk:
From: Anton Ivanov antiv...@cisco.com
PIPE is the wrong IPC for this type of inter-thread communication.
For more details see:
http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
The observations on that
Am 07.03.2014 19:37, schrieb anton.iva...@kot-begemot.co.uk:
From: Anton Ivanov antiv...@cisco.com
PIPE is the wrong IPC for this type of inter-thread communication.
For more details see:
http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
The observations on
On Sat, Mar 1, 2014 at 10:28 AM, Toralf Förster toralf.foers...@gmx.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Today I tested if I can activate that syscall again here (munmap works fine
since few days).
Testing a 32 bit user mode linux image with $trinity -q -N 10 -C 8
Am 28.02.2014 09:27, schrieb Anton Ivanov (antivano):
Hi Richard, Hi Jeff, hi list,
On behalf of Cisco systems, I am authorized to make a offer a set bug
fixes as well as contribute several additional features and performance
improvements to UML. All of these have been used internally for a
Am 27.02.2014 20:05, schrieb Boaz Harrosh:
Hi Richard, uml hackers
Since some time my echo t /proc/sysrq-trigger stopped producing the
proper global back-traces for all Kernel threads.
All I get is:
I have an idea, do you see this regression starting with v3.12?
Thanks,
//richard
On Sun, Nov 17, 2013 at 1:57 PM, Richard Weinberger rich...@nod.at wrote:
Am 11.11.2013 19:03, schrieb Tristan Schmelcher:
From: Tristan Schmelcher tschmelc...@google.com
Inferring the mount hierarchy correctly from /proc/mounts is hard when
MS_MOVE
may have been used, and the previous code
.
-
James Hogan (1):
um: hostfs: make functions static
Richard Weinberger (2):
um: Removed unused attributes from thread_struct
um: Include generic barrier.h
arch/um/include/asm/Kbuild | 1 +
arch/um/include/asm/processor-generic.h | 3 --
fs
...to get smp_store_release().
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/include/asm/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
index fdde187..fb3a6cc 100644
Am Sonntag, 12. Januar 2014, 09:02:06 schrieb H. Peter Anvin:
On 01/12/2014 06:52 AM, Richard Weinberger wrote:
Commit x86: Delete non-required instances of include linux/init.h
broke the UML build.
arch/x86/um/vdso/vdso.S: Assembler messages:
arch/x86/um/vdso/vdso.S:2: Error
Am Sonntag, 12. Januar 2014, 19:58:06 schrieb Geert Uytterhoeven:
On Sun, Jan 12, 2014 at 6:17 PM, Richard Weinberger rich...@nod.at wrote:
Fengguang, please make sure that you build both UML/i386 and UML/x86_64.
i.e. make defconfig ARCH=um SUBARCH=i386 make linux ARCH=um
and make
On Sat, Jan 11, 2014 at 11:47 AM, Toralf Förster toralf.foers...@gmx.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I do fuzz testing with trinity (latest git version) a stable 32 bit Gentoo
Linux user mode linux image.
The host is a stable 32 bit vanilla 3.12.7 kernel, the guest
On Sun, Dec 29, 2013 at 2:14 PM, st...@nixia.no wrote:
#6 0x08421d02 in rest_init () at init/main.c:401
pid = -516
#7 0x080487e1 in start_kernel () at init/main.c:655
command_line = 0x85b6400 command_line earlyprintk
ubda=/home/tfoerste/virtual/uml/trinity
On Fri, Dec 13, 2013 at 10:52 AM, Toralf Förster toralf.foers...@gmx.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/11/2013 09:26 PM, Jan Kara wrote:
Thanks! So this works more or less as expected - trinity issued a
read at absurdly high offset so we created pagecache page a
Hi Greg,
please add commit fdfa4c952844fce881df8c76de9c7180cbe913ab (um: add missing
declaration of 'getrlimit()' and friends) to -stable.
The change was introduced in 3.9 and needs backporting to all stable trees.
Thanks,
//richard
Am Sonntag, 1. Dezember 2013, 20:05:55 schrieb Toralf Förster:
On 12/01/2013 11:20 AM, Richard Weinberger wrote:
I meant xterm for all consoles but con0...
Such that you can trigger the crash but are still able to see the output.
Not sure if the 2 attached files contains useful info
Am Montag, 2. Dezember 2013, 22:32:11 schrieb Toralf Förster:
On 12/02/2013 10:21 PM, Richard Weinberger wrote:
Am Sonntag, 1. Dezember 2013, 20:05:55 schrieb Toralf Förster:
On 12/01/2013 11:20 AM, Richard Weinberger wrote:
I meant xterm for all consoles but con0...
Such that you can
Am Sonntag, 1. Dezember 2013, 11:17:31 schrieb Toralf Förster:
On 12/01/2013 12:19 AM, Richard Weinberger wrote:
after another minute now all xterms are away
So, it does not crash immediately.
Right, to be precise, just 1 sub-process crashes immediately
Please do not use xterm
.
Richard Weinberger (2):
um: Rename print_stack_trace to do_stack_trace
um: Build always with -mcmodel=large on 64bit
arch/um/Makefile | 9 -
arch/um/kernel/sysrq.c | 4 ++--
2 files changed, 6 insertions(+), 7
On Sat, Nov 30, 2013 at 3:43 PM, Toralf Förster toralf.foers...@gmx.de wrote:
On 11/30/2013 03:37 PM, Toralf Förster wrote:
Today I realized that a UML cores if I use the xterm for the in/out.
I do usually use con0=fd:0,fd:1 con=pts to start a 32bit UML but because
the xterm way was fine
Am Samstag, 30. November 2013, 17:28:55 schrieb Toralf Förster:
On 11/30/2013 03:51 PM, Richard Weinberger wrote:
Please more details.
Does Linus' tree work?
Does it crash immediately?
Does this helps ? :
Please try Linus's tree and run it without GDB.
UML now has a complete new stack
Am Samstag, 30. November 2013, 18:26:45 schrieb Toralf Förster:
On 11/30/2013 05:36 PM, Richard Weinberger wrote:
Am Samstag, 30. November 2013, 17:28:55 schrieb Toralf Förster:
On 11/30/2013 03:51 PM, Richard Weinberger wrote:
Please more details.
Does Linus' tree work?
Does it crash
Am Samstag, 30. November 2013, 19:19:59 schrieb Toralf Förster:
On 11/30/2013 06:35 PM, Richard Weinberger wrote:
Am Samstag, 30. November 2013, 18:26:45 schrieb Toralf Förster:
On 11/30/2013 05:36 PM, Richard Weinberger wrote:
Am Samstag, 30. November 2013, 17:28:55 schrieb Toralf Förster
Am Samstag, 30. November 2013, 19:43:47 schrieb Toralf Förster:
On 11/30/2013 07:23 PM, Richard Weinberger wrote:
Sorry for being imprecise, I meant the raw output from UML, not GDB.
Currently it looks like yet another cluster fuck within the winch-Thread.
Thanks,
//richard
ah - ok
On UML SUBARCH can be x86, x86_64 and i386 and if it is x86
we use uname -m to select a defconfig.
Therefore we can no longer use -mcmodel=large only if SUBARCH
is x86_64.
Reported-by: Boaz Harrosh bharr...@panasas.com
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/Makefile | 9
Am Donnerstag, 28. November 2013, 16:40:48 schrieb Boaz Harrosh:
Hi um hackers
I'm using an x86_64 deployment both host and um-guest.
(Fedora 18)
When I load with mem=384M all is well but anything bigger will
eventually give me problems because loadable modules will no
longer load. The
Am Mittwoch, 20. November 2013, 16:52:05 schrieb Randy Dunlap:
On 11/20/13 16:14, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2013-11-20-16-13 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
We cannot use print_stack_trace because the name conflicts
with linux/stacktrace.h.
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/sysrq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/kernel
and x86_64
um/vdso: add .gitignore for a couple of targets
Richard Weinberger (4):
um: Rewrite show_stack()
um: Make stack trace reliable against kernel mode faults
um: Get rid of thread_struct-saved_task
um: Make kstack_depth_to_print conform to arch/x86
arch/um
Am 11.11.2013 19:03, schrieb Tristan Schmelcher:
From: Tristan Schmelcher tschmelc...@google.com
Inferring the mount hierarchy correctly from /proc/mounts is hard when MS_MOVE
may have been used, and the previous code did it wrongly. This change
simplifies
the logic to only require that
Am 13.11.2013 06:06, schrieb Chen Gang:
Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
succeed, they may be used, so in the next failure, we have to skip them
to let exit_mmap() or do_munmap() to process it.
According to Documentation/vm/locking, 'mm-page_table_lock'
Am 14.11.2013 08:33, schrieb Chen Gang:
On 11/14/2013 02:48 PM, Chen Gang wrote:
From the look of it, if an error did occur in init_stub_pte(),
then the special mapping of STUB_CODE and STUB_DATA would not
be installed, so this area would be invisible to munmap and exit,
and with your patch
Am 12.11.2013 14:22, schrieb Mark Salter:
Signed-off-by: Mark Salter msal...@redhat.com
CC: Jeff Dike jd...@addtoit.com
CC: Richard Weinberger rich...@nod.at
CC: user-mode-linux-devel@lists.sourceforge.net
---
arch/um/include/asm/fixmap.h | 40 +---
1
Am 12.11.2013 20:42, schrieb Geert Uytterhoeven:
_end is used, but it's already provided by asm/sections.h, so use that.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Richard Weinberger rich...@nod.at
Cc: user-mode-linux-devel@lists.sourceforge.net
Geert, do you want me
Am 10.11.2013 16:14, schrieb Toralf Förster:
On 11/06/2013 10:31 PM, Richard Weinberger wrote:
Am 06.11.2013 22:18, schrieb Toralf Förster:
On 11/06/2013 05:06 PM, Konstantin Khlebnikov wrote:
In this case it must stop after scanning whole tree in line:
/* Overflow after ~0UL */
if (!index
Am 09.11.2013 20:07, schrieb Toralf Förster:
On 11/06/2013 10:31 PM, Richard Weinberger wrote:
Am 06.11.2013 22:18, schrieb Toralf Förster:
On 11/06/2013 05:06 PM, Konstantin Khlebnikov wrote:
In this case it must stop after scanning whole tree in line:
/* Overflow after ~0UL */
if (!index
On Wed, Nov 6, 2013 at 3:12 PM, Michael Wolf anath...@yahoo.com wrote:
It has been a while so I thought I would re-up the question. Are there any
efforts anywhere to port this to ARM? If not, are there specific technical
blocking issues?
Not really.
If someone *really* wants a arm UML he
Am 06.11.2013 22:18, schrieb Toralf Förster:
On 11/06/2013 05:06 PM, Konstantin Khlebnikov wrote:
In this case it must stop after scanning whole tree in line:
/* Overflow after ~0UL */
if (!index)
return NULL;
A fresh current example with latest git tree shows that lines 769 and 770 do
Am 29.10.2013 20:06, schrieb Dan Carpenter:
We don't cap the size of buffer from the user so we could write past
the end of the array here. Only root can write to this file.
Reported-by: Nico Golde n...@ngolde.de
Reported-by: Fabian Yamaguchi f...@goesec.de
Signed-off-by: Dan Carpenter
On Tue, Oct 22, 2013 at 5:16 PM, Toralf Förster toralf.foers...@gmx.de wrote:
When I fuzz testing a 32 bit UML at a 32 bit host (guest 3.12.-rc6-x, host
3.11.6) with trinity
and use hostfs for the victom files for trinity. then trintiy often hangs
while trying to finish.
At the host I do
Am 22.10.2013 18:23, schrieb Toralf Förster:
On 10/22/2013 06:12 PM, Richard Weinberger wrote:
On Tue, Oct 22, 2013 at 5:16 PM, Toralf Förster toralf.foers...@gmx.de
wrote:
When I fuzz testing a 32 bit UML at a 32 bit host (guest 3.12.-rc6-x, host
3.11.6) with trinity
and use hostfs
Am 27.09.2013 11:22, schrieb Toralf Förster:
On 09/26/2013 12:35 PM, Richard Weinberger wrote:
Am 26.09.2013 12:20, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
This patch is based on: https://lkml.org/lkml/2013/7/4/396
Cc: Ramkumar Ramachandra artag...@gmail.com
Signed-off
Am 26.09.2013 12:20, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
This patch is based on: https://lkml.org/lkml/2013/7/4/396
Cc: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/configs/i386_defconfig | 954
Am 26.09.2013 13:57, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
$ file linux
linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped
$ ./linux ubd0=busybox-rootfs
[...]
Kernel panic
Am 26.09.2013 13:43, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
Auto-detection of SUBARCH, which can be done with a simple call to
uname -m (the 90% case). The second patch I submitted prevented
spawning xterms unnecessarily, which we discussed was a good move.
Covering only 90
Am 26.09.2013 12:53, schrieb Ramkumar Ramachandra:
Richard Weinberger wrote:
So, what exactly is broken in upstream?
make defconfig works as it always did.
Auto-detection of SUBARCH, which can be done with a simple call to
uname -m (the 90% case). The second patch I submitted prevented
-by: Richard Weinberger rich...@nod.at
---
arch/um/include/asm/processor-generic.h | 1 +
arch/um/include/shared/os.h | 1 +
arch/um/kernel/sysrq.c | 32 +++-
arch/um/kernel/trap.c | 14 +++---
arch/um/os-Linux
As we have a sane show_stack() now, we can drop
the -saved_task hack.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/drivers/mconsole_kern.c | 6 ++
arch/um/include/asm/processor-generic.h | 1 -
arch/um/kernel/process.c| 15 ++-
3 files
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/sysrq.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index 7122bf9..4d6fdf6 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -46,9
Currently on UML stack traces are not very reliable and both
x86 and x86_64 have their on implementations.
This patch unifies both and adds support to outline unreliable
functions calls.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/sysrq.c | 85
:db) :
TUN/TAP backend -
winch_thread : TIOCSCTTY failed on fd 1 err = 1
Hmm, that's a regression introduced by:
commit 250127216dd6635f5730752d7444bdec992aecb0
Author: Richard Weinberger rich...@nod.at
Date: Sun Aug 18 13:30:09 2013 +0200
um: Run UML in it's own session.
If UML
,
//richard
Richard Weinberger (8):
um: hostfs: Fix writeback
um: Implement probe_kernel_read()
um: ubd: Add REQ_FLUSH suppport
um: ubd: Introduce submit_request()
um: Cleanup SIGTERM handling
um: Run UML
Am 07.09.2013 14:14, schrieb Richard W.M. Jones:
On Mon, Aug 19, 2013 at 10:30:49AM +0100, Richard W.M. Jones wrote:
On Sun, Aug 18, 2013 at 01:30:09PM +0200, Richard Weinberger wrote:
If UML is not run by a shell it can happen that UML
will kill unrelated proceses upon a fatal exit because
Am 02.09.2013 18:53, schrieb Toralf Förster:
On 09/01/2013 11:15 PM, Richard Weinberger wrote:
Am 01.09.2013 18:09, schrieb Toralf Förster:
On 08/30/2013 04:36 PM, Richard Weinberger wrote:
Am 30.08.2013 16:10, schrieb Toralf Förster:
On 08/29/2013 03:30 PM, J. Bruce Fields wrote:
On Thu
These handlers are not optional and need in our case
dummy implementions to avoid NULL pointer bugs within
the irq core code.
Reported-and-tested-by: Toralf Foester toralf.foers...@gmx.de
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/kernel/irq.c | 4
1 file changed, 4
Am 01.09.2013 18:09, schrieb Toralf Förster:
On 08/30/2013 04:36 PM, Richard Weinberger wrote:
Am 30.08.2013 16:10, schrieb Toralf Förster:
On 08/29/2013 03:30 PM, J. Bruce Fields wrote:
On Thu, Aug 29, 2013 at 11:57:45AM +0200, richard -rw- weinberger wrote:
On Wed, Aug 28, 2013 at 7:21 PM
Am 30.08.2013 16:10, schrieb Toralf Förster:
On 08/29/2013 03:30 PM, J. Bruce Fields wrote:
On Thu, Aug 29, 2013 at 11:57:45AM +0200, richard -rw- weinberger wrote:
On Wed, Aug 28, 2013 at 7:21 PM, Toralf Förster toralf.foers...@gmx.de
wrote:
On 08/27/2013 08:06 PM, J. Bruce Fields wrote:
from asm/ptrace.h.
Reported-by: David Oberhollenzer david.oberhollen...@tele2.at
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/x86/um/os-Linux/prctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/um/os-Linux/prctl.c b/arch/x86/um/os-Linux/prctl.c
index
Forces the user to specify CROSS_COMPILE at compile time instead
of automatically selecting more or less randomly a cross compiler
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/unicore32/Makefile | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/unicore32/Makefile b/arch
The old unified defconfig is no longer needed.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/defconfig | 901 --
1 file changed, 901 deletions(-)
delete mode 100644 arch/um/defconfig
diff --git a/arch/um/defconfig b/arch/um
make defconfig ARCH=um
SUBARCH=x86_64
Finally a make ARCH=um will produce an UML as described in your .config and
you
don't have to worry about setting the correct SUBARCH.
This patch is based on: https://lkml.org/lkml/2013/7/4/396
Cc: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Richard
This series is an attempt to remove the SUBARCH make parameter.
It as introduced at the times of Linux 2.5 for UML to tell the UML
build system what the real architecture is.
But we actually don't need SUBARCH, we can store this information
in the .config file.
i386_defconfig will produce a
Forces the user to specify CROSS_COMPILE at compile time instead
of automatically selecting more or less randomly a cross compiler.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/m68k/Makefile | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/m68k/Makefile b/arch/m68k
Am 21.08.2013 14:07, schrieb Geert Uytterhoeven:
On Wed, Aug 21, 2013 at 10:19 AM, Richard Weinberger rich...@nod.at wrote:
This series is an attempt to remove the SUBARCH make parameter.
It as introduced at the times of Linux 2.5 for UML to tell the UML
build system what the real architecture
Instead of having one defconfig for both i386 and x86_64
we have now two.
This is the first step to get rid of SUBARCH.
This patch is based on: https://lkml.org/lkml/2013/7/4/396
Cc: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/configs
Forces the user to specify CROSS_COMPILE at compile time instead
of automatically selecting more or less randomly a cross compiler.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/mips/Makefile | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/mips/Makefile b/arch/mips
Forces the user to specify CROSS_COMPILE at compile time instead
of automatically selecting more or less randomly a cross compiler.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/sh/Makefile | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/sh/Makefile b/arch/sh/Makefile
As all users of SUBARCH have been removed we can finally get
rid of it.
Signed-off-by: Richard Weinberger rich...@nod.at
---
Makefile | 15 +++
arch/um/Makefile | 2 +-
2 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index a5a55f4..48bd8fe
Am 19.08.2013 11:30, schrieb Richard W.M. Jones:
On Sun, Aug 18, 2013 at 01:30:09PM +0200, Richard Weinberger wrote:
If UML is not run by a shell it can happen that UML
will kill unrelated proceses upon a fatal exit because
it issues a kill(0, ...).
To prevent such oddities we create a new
If UML is not run by a shell it can happen that UML
will kill unrelated proceses upon a fatal exit because
it issues a kill(0, ...).
To prevent such oddities we create a new session in main().
Cc: rjo...@redhat.com
Reported-by: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Richard
Just a clean-up patch to remove the open coded
variants and to ensure that all requests are submitted the
same way.
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/drivers/ubd_kern.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git
handler for all
UML helper threads/processes.
Such that last_ditch_exit() does not get called multiple times
and all processes can exit due to SIGTERM.
Cc: rjo...@redhat.com
Reported-by: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/um/drivers
UML's block device driver does not support write barriers,
to support this this patch adds REQ_FLUSH suppport.
Every time the block layer sends a REQ_FLUSH we fsync() now
our backing file to guarantee data consistency.
Cc: rjo...@redhat.com
Signed-off-by: Richard Weinberger rich...@nod.at
Am 13.08.2013 12:36, schrieb Richard W.M. Jones:
On Mon, Aug 12, 2013 at 09:53:00AM +0100, Richard W.M. Jones wrote:
On Mon, Aug 12, 2013 at 10:15:24AM +0200, richard -rw- weinberger wrote:
Found the root cause, patch is on the way.
I can test patches if you CC me on them.
I'm still
Am 27.07.2013 17:23, schrieb Gabriel de Perthuis:
Useful for
* limiting privileges
* opening block devices O_EXCL
So, the goal of this patch is to allow passing a file descriptor
number as block device instead of a file?
I assume you have already a wrapper around UML which exec()'s it such
Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus
Special thanks goes to Toralf Föster for continuously testing UML and reporting
issues!
Thanks,
//richard
Richard Weinberger (5
Am 08.07.2013 22:19, schrieb Tristan Schmelcher:
From: Tristan Schmelcher tschmelc...@google.com
which_tmpdir did the wrong thing if /dev/shm was a symlink (e.g., to
/run/shm),
if there were multiple mounts on top of each other, if the mount(s) were
obscured by a later mount, or if
Am 26.06.2013 11:33, schrieb Chen Gang:
On 06/26/2013 05:03 PM, Richard Weinberger wrote:
Am 26.06.2013 10:58, schrieb Chen Gang:
On 06/26/2013 04:39 PM, Richard Weinberger wrote:
The drivers internal code has already check the related
return value,
so it is the architecture's duty to 'tell
Am 26.06.2013 10:34, schrieb Chen Gang:
On 06/26/2013 04:05 PM, Richard Weinberger wrote:
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..e80331d 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,10 +303,10 @@ static inline void
Am 26.06.2013 12:01, schrieb Chen Gang:
On 06/26/2013 05:48 PM, Geert Uytterhoeven wrote:
On Wed, Jun 26, 2013 at 11:38 AM, Richard Weinberger rich...@nod.at wrote:
Since the API itself already contents the meaning: return NULL means
the arch has no related io memory,
No, NULL means it could
Am 26.06.2013 10:58, schrieb Chen Gang:
On 06/26/2013 04:39 PM, Richard Weinberger wrote:
The drivers internal code has already check the related return value,
so it is the architecture's duty to 'tell' the driver whether support
io memory (e.g. define ioremap, but return NULL).
It does so
Hi!
Am 26.06.2013 08:31, schrieb Chen Gang:
For User Mode Linux, it may enable 'MMU', but not need implement
ioremap and iounmap, so include/asm-generic/io.h need notice this
case to keep itself 'generic'.
The related error (with allmodconfig, without pcap):
CC [M]
Hi!
Am 26.06.2013 09:56, schrieb Chen Gang:
On 06/26/2013 02:54 PM, Richard Weinberger wrote:
Hi!
Am 26.06.2013 08:31, schrieb Chen Gang:
For User Mode Linux, it may enable 'MMU', but not need implement
ioremap and iounmap, so include/asm-generic/io.h need notice this
case to keep itself
401 - 500 of 727 matches
Mail list logo
