On 21 February 2012 16:19, Alexander Graf wrote:
> On 02/21/2012 05:11 PM, Peter Maydell wrote:
>> For a proper fix we probably need to handle set/getrlimit for
>> RLIMIT_AS specially so we can apply them ourselves to the guest's
>> mmap/brk usage and don't get spurious allocation failures of
>> o
On 02/21/2012 05:11 PM, Peter Maydell wrote:
On 13 January 2012 16:21, Alexander Graf wrote:
On 13.01.2012, at 17:16, Peter Maydell wrote:
On 13 January 2012 15:46, Alexander Graf wrote:
This patch forces unlocking of that lock in the segv handler. I'm not sure
this is the right approach tho
On 13 January 2012 16:21, Alexander Graf wrote:
> On 13.01.2012, at 17:16, Peter Maydell wrote:
>> On 13 January 2012 15:46, Alexander Graf wrote:
>>> This patch forces unlocking of that lock in the segv handler. I'm not sure
>>> this is the right approach though. Maybe we should rather make sure
I confirm the patch fixes the deadlock I was seeing here.
--
Fabio Erculiani
On 13.01.2012, at 17:16, Peter Maydell wrote:
> On 13 January 2012 15:46, Alexander Graf wrote:
>> When entering the guest we take a lock to ensure that nobody else messes
>> with our TB chaining while we're doing it. If we get a segfault inside that
>> code, we manage to work on, but will not u
On 13 January 2012 15:46, Alexander Graf wrote:
> When entering the guest we take a lock to ensure that nobody else messes
> with our TB chaining while we're doing it. If we get a segfault inside that
> code, we manage to work on, but will not unlock the lock.
>
> This patch forces unlocking of th
When entering the guest we take a lock to ensure that nobody else messes
with our TB chaining while we're doing it. If we get a segfault inside that
code, we manage to work on, but will not unlock the lock.
This patch forces unlocking of that lock in the segv handler. I'm not sure
this is the righ
