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 a8c60be4f1bb3a4eead20e3fa
Am 07.03.2014 19:37, schrieb anton.iva...@kot-begemot.co.uk:
> From: Anton Ivanov
>
> 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 thread ha
On Wed, Apr 30, 2014 at 8:19 PM, Toralf Förster 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.
This is why ptrace() f
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
>> wrote:
>>> -or- it uncovers a bug in kernel v3.15-rc3 for UML:
>>
>> UML most not panic. :)
>>
>&
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
>
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.
>>
>&g
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.
>>
>&g
On Fri, May 2, 2014 at 8:43 AM, 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 host_vm_op
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 becaus
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
---
arch/um/kernel/tlb.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/ar
This reverts commit 0974a9cadc7886f7baaa458bb0c89f5c5f9d458e.
It was a bad idea and was only papering over the real issue.
Signed-off-by: Richard Weinberger
---
arch/um/os-Linux/skas/process.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/um/os-Linux/skas
On Sat, May 3, 2014 at 6:04 PM, Toralf Förster 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 :
>
> tfoerste@n22 ~/tmp $ gdb
Am 10.05.2014 01:43, schrieb Joe Perches:
> Joe Perches (4):
> UserModeLinux: Convert UM_KERN_ to KERN_
> UserModeLinux: Remove unused #defines of UM_KERN_
> UserModeLinux: Use a more current logging style
> UserModeLinux: Convert printks to pr_
>
> arch/um/drivers/chan_kern.c
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_ to KERN_
>>> UserModeLinux: Remove unused #defines
On Tue, May 27, 2014 at 3:58 PM, Sébastien Frémal
wrote:
> Hello,
>
> I'm a PhD Student studying virtualization methods. I found an article on UML
> explaining how it works in TT mode
> (https://www.kernel.org/doc/ols/2001/uml.pdf).
>
> I read that there is now a skas mode fixing security and perf
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
---
arch/um/kernel/trap.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/um/kernel/trap.c b/arch/um/kernel
ge fault 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
---
arch/um/kernel/trap.c |
On Fri, May 30, 2014 at 10:24 AM, enjoy mindful 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
>
> arch/um/kernel/u
On Fri, May 30, 2014 at 11:17 AM, Richard Weinberger
wrote:
> On Fri, May 30, 2014 at 10:24 AM, enjoy mindful
> wrote:
>> Hi,
>> When I'm trace uml kernel with gdb, I found there are two mem_map
>> (struct page) arrays.
>>
>> 1) the first one crea
Hi!
Am 01.06.2014 02:24, schrieb Real Name:
> 1) uml kernel bootmem managed through bootmem_data->node_bootmem_map,
> not struct page array, so it is unnecessary.
>
> 2) the struct page array allocate has been pointer by a *loacl* pointer
> struct page *map in init_maps function. The array can't
Am 01.06.2014 15:08, schrieb Real Name:
> From: Honggang Li
>
> 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 *map, in init_
Hi!
Am 02.06.2014 11:05, schrieb Sébastien Frémal:
> Hello,
>
> Thank you for these informations, it helps me to understand how skas works. I
> read on the skas website that "This also provides a noticable speedup by
> eliminating the signal
> delivery that used to happen for every UML system c
Am 05.06.2014 06:15, schrieb Honggang Li:
> arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> In fact, exception table dose not work in uml kernel.
Are you sure that exception tables do not work on UML?
I s
Hi!
Am 03.06.2014 07:30, schrieb Real Name:
> From: Honggang Li
>
> The patch based on linux-next-2014-06-02.
>
> The old init_maps function does two things:
> 1) allocates and initializes one struct page array for bootmem
> 2) count the number of total pages
>
> After removed the source code
Am 16.06.2014 05:28, schrieb Real Name:
> On Sat, Jun 14, 2014 at 11:44:04AM +0200, Richard Weinberger wrote:
>> Hi!
>>
>> Am 03.06.2014 07:30, schrieb Real Name:
>>> From: Honggang Li
>>>
>>> The patch based on linux-next-2014-06-02.
>>&
On Tue, Jul 8, 2014 at 7:48 AM, Konstantin Khlebnikov wrote:
> On Tue, Jul 8, 2014 at 2:05 AM, Andrew Morton
> wrote:
>> On Sat, 05 Jul 2014 15:22:38 +0400 Konstantin Khlebnikov
>> wrote:
>>
>>> This fixes command # make checkstack for i386/x86_64.
>>> Looks like $UTS_MACHINE is exactly what s
Am 08.07.2014 10:16, schrieb Konstantin Khlebnikov:
> On Tue, Jul 8, 2014 at 12:01 PM, Richard Weinberger
> wrote:
>> On Tue, Jul 8, 2014 at 7:48 AM, Konstantin Khlebnikov
>> wrote:
>>> On Tue, Jul 8, 2014 at 2:05 AM, Andrew Morton
>>> wrote:
>>>&g
Am 08.07.2014 10:30, schrieb Konstantin Khlebnikov:
> On Tue, Jul 8, 2014 at 12:20 PM, Richard Weinberger wrote:
>> Am 08.07.2014 10:16, schrieb Konstantin Khlebnikov:
>>> On Tue, Jul 8, 2014 at 12:01 PM, Richard Weinberger
>>> wrote:
>>>> On Tue, Jul 8,
Am 08.07.2014 10:47, schrieb Konstantin Khlebnikov:
> On Tue, Jul 8, 2014 at 12:33 PM, Richard Weinberger wrote:
>> Am 08.07.2014 10:30, schrieb Konstantin Khlebnikov:
>>> On Tue, Jul 8, 2014 at 12:20 PM, Richard Weinberger wrote:
>>>> Am 08.07.2014 10:16, schrieb K
Am 08.07.2014 11:03, schrieb Konstantin Khlebnikov:
> I know. But debugging/profiling of kernel code is much easier when it
> runs in userspace.
> I think this is the last use case where uml might beat normal hardware
> accelerated qemu/kvm.
> But without SMP and with that high overhead on each sys
Am 08.07.2014 11:09, schrieb Geert Uytterhoeven:
> On Tue, Jul 8, 2014 at 11:06 AM, Richard Weinberger wrote:
>> Am 08.07.2014 11:03, schrieb Konstantin Khlebnikov:
>>> I know. But debugging/profiling of kernel code is much easier when it
>>> runs in userspace.
>&
Am 08.07.2014 11:22, schrieb Geert Uytterhoeven:
> On Tue, Jul 8, 2014 at 11:14 AM, Richard Weinberger wrote:
>>> And that you don't need root permissions to run it.
>>
>> You can use KVM also without being root.
>> It depends on the rights of /dev/kvm.
>
&g
Am 12.07.2014 19:16, schrieb Toralf Förster:
> On 05/02/2014 04:14 PM, Richard Weinberger wrote:
>> 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:
>>>>&g
Am 18.07.2014 01:13, schrieb Real Name:
> On Sat, Jun 28, 2014 at 12:06:28PM +0800, Real Name wrote:
>> On Sat, Jun 21, 2014 at 03:28:52PM +0800, Real Name wrote:
>>> On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
>>>> Am 05.06.2014 06:15, schri
gate_area functions in the default case.
>>
>> Can one of you pull this somewhere? Otherwise I can put it somewhere
>> stable and ask for -next inclusion, but that seems like overkill for a
>> single patch.
For the um bits:
Acked-by: Richard Weinberger
> I'd be ha
by Trinity.
--------
Richard Weinberger (4):
Revert "um: Fix wait_stub_done() error handling"
um: Ensure that a stub page cannot get unmapped
um: Fix hung task in fix_range_common()
um: segv: Save regs only in case of
From: Richard Weinberger
Use the more generic functions get_signal() signal_setup_done()
for signal delivery.
Signed-off-by: Richard Weinberger
---
arch/um/include/shared/frame_kern.h | 12 --
arch/um/kernel/signal.c | 27 +-
arch/x86/um/signal.c
Himangi,
Am 19.07.2014 13:34, schrieb Himangi Saraogi:
> alloc_bootmem and related functions never return NULL. Thus a NULL
> test or memset after calls to these functions is unnecessary.
>
> The following Coccinelle semantic patch was used for making the change:
>
> @@
> expression E;
> stateme
Am 26.07.2014 22:01, schrieb Toralf Förster:
> On 05/01/2014 02:33 PM, Richard Weinberger wrote:
>> BTW: If you hit "BUG: failure at
>> mm/filemap.c:202/__delete_from_page_cache()!",
>> this is a known issue https://lkml.org/lkml/2014/4/15/577
>
> Since I
Hi Vivek,
Daniel Walter reported that UML is currently broken.
The offending commit is:
commit 8c86e70acead629aacb4afcd818add66bf6844d9
Author: Vivek Goyal
Date: Fri Aug 8 14:25:50 2014 -0700
resource: provide new functions to walk through resources
It dies in next_resource():
/*
On Sun, Aug 10, 2014 at 6:22 PM, Toralf Förster wrote:
> Well, might be too early to try the new kernel at a 32 bit Linux, but this is
> what I got today (just once, next attempt to start the kernel worked fine) :
>
> tfoerste@n22 /mnt/ramdisk $ stresc Xterm.log.n22.2014.08.10.17.43.36.9202
> Loc
Hi Vivek,
Am 11.08.2014 14:22, schrieb Vivek Goyal:
> On Sun, Aug 10, 2014 at 06:56:14PM +0200, Richard Weinberger wrote:
>> Hi Vivek,
>>
>> Daniel Walter reported that UML is currently broken.
>> The offending commit is:
>>
>
> Hi Richard,
>
> Th
Am 11.08.2014 20:44, schrieb Vivek Goyal:
> On Mon, Aug 11, 2014 at 02:25:56PM +0200, Richard Weinberger wrote:
>> Hi Vivek,
>>
>> Am 11.08.2014 14:22, schrieb Vivek Goyal:
>>> On Sun, Aug 10, 2014 at 06:56:14PM +0200, Richard Weinberger wrote:
>>>> Hi Vi
Am 12.08.2014 16:46, schrieb Vivek Goyal:
> Richard and Daniel reported that UML is broken due to changes to resource
> traversal functions. Problem is that iomem_resource.child can be null
> and new code does not consider that possibility. Old code used a for loop
> and that loop will not even exe
Am 12.08.2014 17:04, schrieb Vivek Goyal:
> On Tue, Aug 12, 2014 at 04:49:35PM +0200, Richard Weinberger wrote:
>> Am 12.08.2014 16:46, schrieb Vivek Goyal:
>>> Richard and Daniel reported that UML is broken due to changes to resource
>>> traversal functions. Problem i
On Wed, Aug 13, 2014 at 9:11 PM, Toralf Förster wrote:
>
> The long story is below.
As of now UML has no CONFIG_STACKTRACE_SUPPORT.
But Daniel (CC'd) is working on it.
>
> Forwarded Message
> Subject: Re: trinity seems not to reap all childs
> Date: Wed, 13 Aug 2014 11:02:31 -0
On Thu, Sep 4, 2014 at 9:00 PM, wrote:
>
> Patch dependencies:
>
> [PATCH v3 01/10] Epoll based interrupt controller
>
> Full redesign of the existing UML poll based controller. The old
> poll controller incurs huge penalties for IRQ sharing and many devices
> setup due to the device list being w
On Sun, Sep 14, 2014 at 12:42 PM, Thomas Meyer wrote:
>
> Call machined's "CreateMachine" to create a scope unit for the
> current uml instance.
Can you please describe in detail why we need this feature?
In general I'm fine with adding such functionality but please make it optional.
Having libdb
Rob,
Am 23.09.2014 16:58, schrieb Rob Landley:
> As long as somebody's paying attention to UML again: what would be
> involved in adding support for arm/mips/sh4/sparc...
>
> I've mostly wandered off to use qemu these days, and I package system
> images with native compilers you can boot up and c
Am 26.09.2014 13:49, schrieb anton.iva...@kot-begemot.co.uk:
> From: Anton Ivanov
>
> This is a fix for a very old UML bug which can be triggered with stock
> UML. It takes a lot of effort to trigger it there because the
> lseek()/read() | write() mechanics of the UBD driver implicitly sync the
On Mon, Sep 29, 2014 at 7:36 PM, Thomas Meyer wrote:
> Hi,
>
> I tried to install the latest Fedora 21 from the Network Install Image
> DVD (
> https://fedoraproject.org/get-prerelease#server
> http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Alpha/Server/x86_64/iso/Fedora-Serve
On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer wrote:
> Hi,
>
> I get a timeout in the Fedora 21 alpha:
>
> [ TIME ] Timed out waiting for device
> dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device.
>
> But all devices are available from early kernel start:
> # ls -l /dev
On Fri, Oct 3, 2014 at 1:21 AM, Thomas Meyer wrote:
> Hi,
>
> When you pass an initrd to UML and the size of the initrd is too big for
> the current kernel memory, a panic() call is done with the message("Out
> of memory").
>
> But this message never hits the stdout as the following stack trace
>
Am 07.10.2014 07:28, schrieb Guenter Roeck:
> arch/um/kernel/reboot.c| 2 --
Acked-by: Richard Weinberger
Thanks,
//richard
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve
Am 11.10.2014 um 13:29 schrieb Nicolas Iooss:
> syscall_stub_start is declared with different types in C files:
>
> arch/um/kernel/physmem.c: extern int __syscall_stub_start;
> arch/um/kernel/skas/mmu.c: extern int __syscall_stub_start;
> arch/um/os-Linux/skas/mem.c: extern unsigned long __s
Am 11.10.2014 um 14:15 schrieb Nicolas Iooss:
> 2014-10-11 13:42 GMT+02:00 Richard Weinberger:
>> Am 11.10.2014 um 13:29 schrieb Nicolas Iooss:
>>> syscall_stub_start is declared with different types in C files:
>>>
>>> arch/um/kernel/physmem.c: extern int
Linus,
The following changes since commit c798360cd1438090d51eeaa8e67985da11362eba:
Merge branch 'for-3.18' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu (2014-10-10 07:26:02
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.g
afely obtain a pid reference to the foreground process group and
> release the reference after signalling is complete.
>
> cc: Jeff Dike
> cc: Richard Weinberger
> cc: user-mode-linux-devel@lists.sourceforge.net
> Signed-off-by: Peter Hurley
Acked-by: Richard Weinberger
Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
> The pointer to bp stack-frame is no longer used. Removed it.
Good catch!
> This also removes a corresponding compiler-warning.
Which warning exactly?
Thanks,
//richard
---
Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
> On 2014-10-18 16:42, Richard Weinberger wrote:
>> Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
>>> The pointer to bp stack-frame is no longer used. Removed it.
>>
>> Good catch!
> Thank you.
>
>>
>
Am 18.10.2014 um 17:24 schrieb Manfred Schlaegl:
> On 2014-10-18 17:19, Richard Weinberger wrote:
>> Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
>>> On 2014-10-18 16:42, Richard Weinberger wrote:
>>>> Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
>>>
On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote:
> Hello,
>
> in UML kernel I get a long cpu using loop in __getnstimeofday()
> (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(),
> when I left the host kernel suspended to ram for a few hours and resume
> again.
> this is because
Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
>> Hmm, does this always happen?
>
> Yes, my single core system seems to trigger this every time after resume from
> ram.
What is your host kernel?
>> At least on my notebook it did not happen. I've started an UML yesterday
>> suspended it and after
On Mon, Oct 20, 2014 at 1:18 PM, Thomas Meyer wrote:
> Am 20.10.2014 11:28 schrieb Daniel Walter :
>>
>> - Original Message -
>> > From: "Thomas Meyer"
>> > To: "user-mode-linux-devel"
>> > Sent: Sunday, October 19, 2014 4:14:13 PM
>> > Subject: [uml-devel] [PATCH v3 3/3] um: enable trac
Anton,
Am 23.10.2014 um 09:34 schrieb Anton Ivanov:
> Hi Richard,
>
> I have had a question in my mind on this for quite a while around this bug
> (and a quite a few others).
Fell free to ask, I'll try hand to find time to answer.
> UML by the nature of being UP includes the generic spinlock d
Geert,
On Wed, Nov 12, 2014 at 10:48 AM, Geert Uytterhoeven
wrote:
> On Wed, Nov 12, 2014 at 10:46 AM, Geert Uytterhoeven
> wrote:
>> JFYI, when comparing v3.18-rc4[1] to v3.18-rc3[3], the summaries are:
>> - build errors: +5/-6
>
> + /home/kisskb/slave/src/fs/hostfs/hostfs_user.c: error: '
Am 12.11.2014 um 11:22 schrieb Geert Uytterhoeven:
> On Wed, Nov 12, 2014 at 11:19 AM, Richard Weinberger
> wrote:
>>> + /home/kisskb/slave/src/fs/hostfs/hostfs_user.c: error: 'AT_FDCWD'
>>> undeclared (first use in this function): => 378
>>> +
On Wed, Nov 19, 2014 at 6:06 PM, Toralf Förster wrote:
> console [mc-1] enabled
> Failed to initialize ubd device 0 :Couldn't determine size of device's file
This is ubd_file_size(). Can you find out where exactly it is failing?
Just add a few printk()s into it.
--
Thanks,
//richard
--
On Thu, Nov 20, 2014 at 8:01 PM, Toralf Förster wrote:
> A recent question at trinity's mailing list
> (http://news.gmane.org/gmane.comp.security.fuzzing.trinity) points probably
> to a hostfs issue - therefore I'd like to forward the answer f Dave Jones
> here.
>
> ANd /me wonders how to use
Hi!
Am 10.12.2014 um 11:46 schrieb Miklos Szeredi:
> The guilty commit is:
>
> 00f634bc522d "asm-generic: add generic futex for !CONFIG_SMP"
Thanks a lot Miklos!
Your bisecting faster than I do.
Let's dig into the issue!
Thanks,
//richard
> And the backtrace:
>
> #0 0x77866457 in
Am 10.12.2014 um 12:03 schrieb Arnd Bergmann:
> On Wednesday 10 December 2014 11:49:23 Richard Weinberger wrote:
>> Hi!
>>
>> Am 10.12.2014 um 11:46 schrieb Miklos Szeredi:
>>> The guilty commit is:
>>>
>>> 00f634bc522d "asm-generic: add gen
Am 10.12.2014 um 12:59 schrieb Geert Uytterhoeven:
> On Wed, Dec 10, 2014 at 11:49 AM, Richard Weinberger wrote:
>> Am 10.12.2014 um 11:46 schrieb Miklos Szeredi:
>>> The guilty commit is:
>>>
>>> 00f634bc522d "asm-generic: add generic futex for !CONFI
-by: Geert Uytterhoeven
Signed-off-by: Richard Weinberger
---
arch/um/Kconfig.common | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 87bc868..d195a87 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -3,6 +3,7 @@ config UML
g exciting.
Daniel Borkmann (1):
x86, um: actually mark system call tables readonly
Richard Weinberger (1):
um: Skip futex_atomic_cmpxchg_inatomic() test
arch/um/Kconfig.common | 1 +
arch/x86/um/sys_call_table_32.c | 2 +-
a
On Tue, Jun 24, 2014 at 10:52 PM, Toralf Förster wrote:
> IIRC in former times I could assign an UML instance 2047M, but nowadays
> even 2044M is too big.
This depends on the host side. UML heavily depends on the host memory layout.
Now with ASLR and such stuff the layout changes and the boarder
Am 10.01.2015 um 17:08 schrieb Toralf Förster:
> yes, it never worked with values above 2026M (tested at an old ThinkPad T420,
> running a 32 bit Gentoo Linux with host kernel 3.17.4 )
The theoretical max. was always 2GiB due to the limited address space on ia32.
2GiB - UML binary - ASLR overhea
Am 10.01.2015 um 19:11 schrieb Toralf Förster:
> On 01/10/2015 06:45 PM, Richard Weinberger wrote:
>> Am 10.01.2015 um 18:37 schrieb Toralf Förster:
>>> On 01/10/2015 06:25 PM, Richard Weinberger wrote:
>>>> Am 10.01.2015 um 17:08 schrieb Toralf Förster:
>>
.
Cc: sta...@vger.kernel.org
Reported-and-tested-by: Daniel Gröber
Signed-off-by: Richard Weinberger
---
fs/hostfs/hostfs_kern.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
index fd62cae..a7ac856 100644
--- a/fs/hostfs/hostfs_kern.c
+++ b/fs
Am 13.01.2015 um 23:19 schrieb Christoph Hellwig:
> On Tue, Jan 13, 2015 at 11:15:58PM +0100, Richard Weinberger wrote:
>> Daniel reported that dpkg(1) dies if the root filesystem is a hostfs
>> because it does not expect fsync(2) to fail with EINVAL on directories.
>> While f
Since commit 9af2452a1839 ("um: Include generic barrier.h")
UML uses the generic barrier.h, remove this orphaned file.
Reported-by: Borislav Petkov
Signed-off-by: Richard Weinberger
---
arch/x86/um/asm/barrier.h | 71 ---
1 file changed, 71
On Sun, Jan 18, 2015 at 1:27 PM, Thomas Meyer wrote:
> Hi,
>
> Any news. On this?
>
> http://sourceforge.net/p/user-mode-linux/mailman/message/32947218/
> http://sourceforge.net/p/user-mode-linux/mailman/message/32947219/
> http://sourceforge.net/p/user-mode-linux/mailman/message/32947217/
Easy a
On Mon, Jan 26, 2015 at 9:44 PM, Richard Weinberger
wrote:
> On Sun, Jan 18, 2015 at 1:27 PM, Thomas Meyer wrote:
>> Hi,
>>
>> Any news. On this?
>>
>> http://sourceforge.net/p/user-mode-linux/mailman/message/32947218/
>> http://sourceforge.net/p/user-mode-
On Tue, Mar 3, 2015 at 5:55 AM, Lorenzo Colitti wrote:
> Hi,
>
> when compiling UML with -Wall -Werror, I get:
Don't build with -Werror.
> arch/um/kernel/ptrace.c: In function ‘syscall_trace_enter’:
> arch/um/kernel/ptrace.c:178:32: warning: ignoring return value of
> ‘tracehook_report_syscall_e
Am 03.03.2015 um 09:39 schrieb Lorenzo Colitti:
> On Tue, Mar 3, 2015 at 5:32 PM, Richard Weinberger
> wrote:
>> IIRC the big plan is to make tracehook_report_syscall_entry() tree-wide void.
>
> Ack, thanks. In the meantime, for trees we already build with -Werror,
> we
Am 03.03.2015 um 10:26 schrieb Geert Uytterhoeven:
> On Tue, Mar 3, 2015 at 9:48 AM, Richard Weinberger wrote:
>> Am 03.03.2015 um 09:39 schrieb Lorenzo Colitti:
>>> On Tue, Mar 3, 2015 at 5:32 PM, Richard Weinberger
>>> wrote:
>>>> IIRC the big plan is
On Sun, Mar 8, 2015 at 10:13 PM, Toralf Förster wrote:
> Well, in fact, since I switched from x86 to amd64 under Gentoo, I never
> managed to get that chroot to be booted.
> During boot of the UML guest it just hangs around "devtmpfs: mounted" w/o
> any output
Booting a chroot?!
> Today I dec
Am 08.03.2015 um 23:40 schrieb Toralf Förster:
> On 03/08/2015 10:38 PM, Richard Weinberger wrote:
>> Booting a chroot?!
>
> Well, wrong wording. it is an UML guest image.
Okay. Does it work on a regular host system?
I.e. not broken^Whardened.
I run x86 UML's very often
Am 10.03.2015 um 15:38 schrieb Toralf Förster:
> On 03/08/2015 11:44 PM, Richard Weinberger wrote:
>> Okay. Does it work on a regular host system?
>> I.e. not broken^Whardened.
>>
>> I run x86 UML's very often on x86_64...
>
> Ok, I have here just a ha
Am 10.03.2015 um 18:43 schrieb Toralf Förster:
> On 03/10/2015 04:49 PM, Richard Weinberger wrote:
>> Then just reboot into a pristine kernel and retest. :-)
>
> With latest host vanilla 4.0.0-rc3 kernel I get a similar picture:
Hmm, does not look at all like your initial report.
Am 10.03.2015 um 19:24 schrieb Toralf Förster:
> On 03/10/2015 06:53 PM, Richard Weinberger wrote:
>> What is addr2line -e linux 60250c0e?
>
> $ addr2line -e linux 60250c0e
> /home/tfoerste/devel/linux/include/linux/skbuff.h:1502
>
> $ addr2line -e linux
Am 10.03.2015 um 19:39 schrieb Toralf Förster:
> On 03/10/2015 07:33 PM, Richard Weinberger wrote:
>> So you see *random* crashes?
> yes, the 1st RIP is varying, just the 2nd stays at 6001b011
Okay. Can you please find the last working release?
I'm still a bit puzzled.
Al
Am 10.03.2015 um 19:56 schrieb Toralf Förster:
> On 03/10/2015 07:43 PM, Richard Weinberger wrote:
>> Also please send me your .config.
> attached
This .config works perfecly fine here.
So, what does your userspace? Does UML crash while booting up?
BTW: You do not specify mem=, so y
Am 10.03.2015 um 16:11 schrieb Toralf Förster:
> so, I installed a hardened 64bit Gentoo [1], configured GRsecurity in the
> kernel :
>
> CONFIG_GRKERNSEC=y
> CONFIG_GRKERNSEC_CONFIG_AUTO=y
> # CONFIG_GRKERNSEC_CONFIG_CUSTOM is not set
> # CONFIG_GRKERNSEC_CONFIG_SERVER is not set
> CONFIG_GRKERN
Am 13.03.2015 um 14:40 schrieb Toralf Förster:
> On 03/10/2015 10:21 PM, Richard Weinberger wrote:
>> Am 10.03.2015 um 19:56 schrieb Toralf Förster:
>>> On 03/10/2015 07:43 PM, Richard Weinberger wrote:
>>>> Also please send me your .config.
>>> attached
>
Am 13.03.2015 um 14:40 schrieb Toralf Förster:
> On 03/10/2015 10:21 PM, Richard Weinberger wrote:
>> Am 10.03.2015 um 19:56 schrieb Toralf Förster:
>>> On 03/10/2015 07:43 PM, Richard Weinberger wrote:
>>>> Also please send me your .config.
>>> attached
>
Am 15.03.2015 um 11:54 schrieb Toralf Förster:
> On 03/13/2015 03:31 PM, Richard Weinberger wrote:
>> And what about a regular "unhardened" host?
>> Does it work if you boot a random x86_64 livecd?
>
> tested with GRML - failed too.
> (And I switched the compil
Am 15.03.2015 um 11:54 schrieb Toralf Förster:
> On 03/13/2015 03:31 PM, Richard Weinberger wrote:
>> And what about a regular "unhardened" host?
>> Does it work if you boot a random x86_64 livecd?
>
> tested with GRML - failed too.
BTW: In GRML you need to remo
Am 15.03.2015 um 13:07 schrieb Toralf Förster:
> On 03/15/2015 12:27 PM, Richard Weinberger wrote:
>
> found the culprit :
> CONFIG_MPENTIUMM=y works where CONFIG_MCORE2=y do not work
>
>
> I do have an i5:
I have to double check this. Maybe you hint an UML bug.
Am 15.03.2015 um 13:07 schrieb Toralf Förster:
> On 03/15/2015 12:27 PM, Richard Weinberger wrote:
>
> found the culprit :
> CONFIG_MPENTIUMM=y works where CONFIG_MCORE2=y do not work
BTW: Just ran a x86 UML with CONFIG_MCORE2=y. Works perfectly fine.
But I have a different
Am 15.03.2015 um 17:51 schrieb Toralf Förster:
> On 03/15/2015 03:36 PM, Richard Weinberger wrote:
>> BTW: Just ran a x86 UML with CONFIG_MCORE2=y. Works perfectly fine.
>
> The picture isn't clear.
>
> After twiddling with the kernel config I got a working .config
201 - 300 of 845 matches
Mail list logo
