On 05/29/2014 01:00 PM, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 06:50:57PM +0200, Peter Zijlstra wrote:
>> > On Thu, May 29, 2014 at 12:44:23PM -0400, Sasha Levin wrote:
>>> > > On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> > > On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wr
On Thu, May 29, 2014 at 06:50:57PM +0200, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 12:44:23PM -0400, Sasha Levin wrote:
> > On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> > > On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
> > >> It doesn't work out well because we later lock a
On 05/29/2014 12:50 PM, Peter Zijlstra wrote:
>> >
>> > So the only caller to sync_child_event() is that loop. According to what
>> > you said
>> > it should be safe to remove that mutex lock, but doing that triggers a list
>> > corruption:
>> >
>> > [ 1204.341887] WARNING: CPU: 20 PID: 12839 at
On Thu, May 29, 2014 at 12:44:23PM -0400, Sasha Levin wrote:
> On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> > On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
> >> It doesn't work out well because we later lock a mutex in
> >> sync_child_event().
> >>
> >
> > Urgh, right you are. I
On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
>> It doesn't work out well because we later lock a mutex in sync_child_event().
>>
>
> Urgh, right you are. I'll go stare at it more. It shouldn't have
> mattered, because the mutex we tak
On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
> It doesn't work out well because we later lock a mutex in sync_child_event().
>
Urgh, right you are. I'll go stare at it more. It shouldn't have
mattered, because the mutex we take just before should ensure existence,
but.. you know..
On 05/29/2014 03:57 AM, Peter Zijlstra wrote:
> On Wed, May 28, 2014 at 07:52:07PM -0400, Sasha Levin wrote:
>> On 05/14/2014 12:35 PM, Peter Zijlstra wrote:
>>> On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/
On Wed, May 28, 2014 at 10:31:38PM -0400, Sasha Levin wrote:
> I've just had this:
>
>
> [ 591.111854] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 591.121057] Dumping ftrace buffer:
> [ 591.121057](ftrace buffer empty)
> [ 591.121057] Modules linked in:
> [ 591.12
On Wed, May 28, 2014 at 07:52:07PM -0400, Sasha Levin wrote:
> On 05/14/2014 12:35 PM, Peter Zijlstra wrote:
> > On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
> >> > -BEGIN PGP SIGNED MESSAGE-
> >> > Hash: SHA1
> >> >
> >> > On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
> >>
On 05/28/2014 07:52 PM, Sasha Levin wrote:
> On 05/14/2014 12:35 PM, Peter Zijlstra wrote:
>> On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
>> On Mon, May 12, 2014 at 1
On 05/14/2014 12:35 PM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
>>> > > On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
> >
On Thu, May 15, 2014 at 08:11:02PM +0200, Peter Zijlstra wrote:
> On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> > kernel I've stumbled on the following spew. Maybe related to the very
On Sat, May 17, 2014 at 12:24:32PM -0400, Sasha Levin wrote:
> On 05/16/2014 10:18 PM, Theodore Ts'o wrote:
> > On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
> >> > This should do the trick:
> >> > dd if=/dev/urandom of=/dev/zero bs=67108707
> >> >
> >> > I suspect ee1de406
On 05/16/2014 10:18 PM, Theodore Ts'o wrote:
> On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
>> > This should do the trick:
>> > dd if=/dev/urandom of=/dev/zero bs=67108707
>> >
>> > I suspect ee1de406ba6eb1 ("random: simplify accounting logic") as the
>> > culprit.
> Yep,
On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
> This should do the trick:
> dd if=/dev/urandom of=/dev/zero bs=67108707
>
> I suspect ee1de406ba6eb1 ("random: simplify accounting logic") as the
> culprit.
Yep, that it's it. Thanks for noticing this so quickly! I'll push
On Fri, May 16, 2014, at 9:21, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 09:06:13AM -0700, H. Peter Anvin wrote:
> > On 05/16/2014 08:34 AM, Peter Zijlstra wrote:
> > >
> > > While fuzzing to reproduce my issue I hit the below, its triggered loads
> > > of times and then the machine wedged (
On Fri, May 16, 2014 at 09:06:13AM -0700, H. Peter Anvin wrote:
> On 05/16/2014 08:34 AM, Peter Zijlstra wrote:
> >
> > While fuzzing to reproduce my issue I hit the below, its triggered loads
> > of times and then the machine wedged (needed a power cycle), I can
> > provide the full console log i
On 05/16/2014 08:34 AM, Peter Zijlstra wrote:
>
> While fuzzing to reproduce my issue I hit the below, its triggered loads
> of times and then the machine wedged (needed a power cycle), I can
> provide the full console log if people care.
>
> Anybody seen that one before?
>
I certainly haven't.
While fuzzing to reproduce my issue I hit the below, its triggered loads
of times and then the machine wedged (needed a power cycle), I can
provide the full console log if people care.
Anybody seen that one before?
---
[ 861.777414] [ cut here ]
[ 861.777416] kernel BUG
On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew. Maybe related to the very recent
> change in freeing on task exit?
>
While fuzzing to reproduce; I
On Wed, May 14, 2014 at 01:20:43PM -0400, Dave Jones wrote:
> Pretty strong odds it's mremap causing those double frees. You can
> -xmremap that to see if it goes away.
unless I'm entirely pebkac atm it doesn't seem to help any.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Wed, May 14, 2014 at 01:09:31PM -0400, Sasha Levin wrote:
> > *** Error in `./trinity': double free or corruption (top):
> > 0x0135af60 ***
> > [main] Random reseed: 3671679404
> > [main] Random reseed: 67838733
> > *** Error in `./trinity': double free or corruption (top):
> >
On 05/14/2014 12:52 PM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 12:38:10PM -0400, Sasha Levin wrote:
>> ./trinity -xinit_module -xreboot -xshutdown -xunshare -xnfsservctl
>> -xclock_nanosleep -xuselib -xumount -xmount -m --quiet --dangerous -C 400 -l
>> off
>>
>> Note that I run it as roo
On Wed, May 14, 2014 at 12:38:10PM -0400, Sasha Levin wrote:
> ./trinity -xinit_module -xreboot -xshutdown -xunshare -xnfsservctl
> -xclock_nanosleep -xuselib -xumount -xmount -m --quiet --dangerous -C 400 -l
> off
>
> Note that I run it as root in a disposable VM. Running that as root on your
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/14/2014 12:35 PM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
>>> On Mon, May 12, 2014 at 11:42:33AM -0
On Wed, May 14, 2014 at 12:32:26PM -0400, Sasha Levin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
> > On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
> >> Hi all,
> >>
> >> While fuzzing with trinity inside a KVM tools gu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/14/2014 12:29 PM, Peter Zijlstra wrote:
> On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel I've stumbled on the following spew.
On Mon, May 12, 2014 at 11:42:33AM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew. Maybe related to the very recent
> change in freeing on task exit?
>
> [ 2509.827261] general prote
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew. Maybe related to the very recent
change in freeing on task exit?
[ 2509.827261] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 2509.830379] Dumping f
29 matches
Mail list logo
