On Fri, Aug 15, 2014 at 07:36:16AM +0400, Konstantin Khlebnikov wrote:
> Don't hurry. The code in this state for years.
> I'm working on patches for this, if everything goes well I'll show it today.
> As usual I couldn't stop myself from cleaning the mess, so it will be
> bigger than yours.
>
Here's a potential final version for the patch mentioned in a earlier message.
The nitpick I raised to myself and a couple of other minor typing issues
are fixed.
I did a preliminary testround, in a KVM guest ballooning in and out memory by
chunks of 1GB while a script within the guest was
On Fri, Aug 15, 2014 at 2:07 AM, Rafael Aquini wrote:
> On Thu, Aug 14, 2014 at 06:43:50PM -0300, Rafael Aquini wrote:
>> On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
>> > We discussed this with Konstantin and he suggested a better solution for
>> > this.
>> > If I understood
On Thu, Aug 14, 2014 at 06:43:50PM -0300, Rafael Aquini wrote:
> On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
> > We discussed this with Konstantin and he suggested a better solution for
> > this.
> > If I understood him correctly the main idea was to store bit
> > identifying
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
> We discussed this with Konstantin and he suggested a better solution for this.
> If I understood him correctly the main idea was to store bit
> identifying ballon page
> in struct page (special value in _mapcount), so we won't need
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
> 2014-08-14 19:13 GMT+04:00 Rafael Aquini :
> > It still a harmless condition as before, but considering what goes above
> > I'm now convinced & confident the patch proposed by Andrey is the real fix
> > for such occurrences.
> >
>
2014-08-14 19:13 GMT+04:00 Rafael Aquini :
>> Yeah, it happens because I failed to anticipate a race window opening where
>> balloon_page_movable() can stumble across an anon page being released --
>> somewhere in the midway of __page_cache_release() & free_pages_prepare()
>> down on the
On Wed, Aug 13, 2014 at 12:35:02PM -0300, Rafael Aquini wrote:
> On Sun, Aug 10, 2014 at 12:49:47PM +0400, Andrey Ryabinin wrote:
> > 2014-08-10 5:45 GMT+04:00 Sasha Levin :
> > > Hi all,
> > >
> > > While fuzzing with trinity inside a KVM tools guest running the latest
> > > -next
> > > kernel
On Wed, Aug 13, 2014 at 12:35:02PM -0300, Rafael Aquini wrote:
On Sun, Aug 10, 2014 at 12:49:47PM +0400, Andrey Ryabinin wrote:
2014-08-10 5:45 GMT+04:00 Sasha Levin sasha.le...@oracle.com:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest
-next
2014-08-14 19:13 GMT+04:00 Rafael Aquini aqu...@redhat.com:
Yeah, it happens because I failed to anticipate a race window opening where
balloon_page_movable() can stumble across an anon page being released --
somewhere in the midway of __page_cache_release() free_pages_prepare()
down on the
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
2014-08-14 19:13 GMT+04:00 Rafael Aquini aqu...@redhat.com:
It still a harmless condition as before, but considering what goes above
I'm now convinced confident the patch proposed by Andrey is the real fix
for such
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
We discussed this with Konstantin and he suggested a better solution for this.
If I understood him correctly the main idea was to store bit
identifying ballon page
in struct page (special value in _mapcount), so we won't need to
On Thu, Aug 14, 2014 at 06:43:50PM -0300, Rafael Aquini wrote:
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
We discussed this with Konstantin and he suggested a better solution for
this.
If I understood him correctly the main idea was to store bit
identifying ballon
On Fri, Aug 15, 2014 at 2:07 AM, Rafael Aquini aqu...@redhat.com wrote:
On Thu, Aug 14, 2014 at 06:43:50PM -0300, Rafael Aquini wrote:
On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote:
We discussed this with Konstantin and he suggested a better solution for
this.
If I
Here's a potential final version for the patch mentioned in a earlier message.
The nitpick I raised to myself and a couple of other minor typing issues
are fixed.
I did a preliminary testround, in a KVM guest ballooning in and out memory by
chunks of 1GB while a script within the guest was
On Fri, Aug 15, 2014 at 07:36:16AM +0400, Konstantin Khlebnikov wrote:
Don't hurry. The code in this state for years.
I'm working on patches for this, if everything goes well I'll show it today.
As usual I couldn't stop myself from cleaning the mess, so it will be
bigger than yours.
Sorry,
I
On Sun, Aug 10, 2014 at 12:49:47PM +0400, Andrey Ryabinin wrote:
> 2014-08-10 5:45 GMT+04:00 Sasha Levin :
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> > kernel with the KASAN patchset, I've stumbled on the following spew:
> >
> >
> > [
On Sun, Aug 10, 2014 at 12:49:47PM +0400, Andrey Ryabinin wrote:
2014-08-10 5:45 GMT+04:00 Sasha Levin sasha.le...@oracle.com:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel with the KASAN patchset, I've stumbled on the following spew:
[
2014-08-10 5:45 GMT+04:00 Sasha Levin :
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel with the KASAN patchset, I've stumbled on the following spew:
>
>
> [ 3837.070452]
> ==
> [
2014-08-10 5:45 GMT+04:00 Sasha Levin sasha.le...@oracle.com:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel with the KASAN patchset, I've stumbled on the following spew:
[ 3837.070452]
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel with the KASAN patchset, I've stumbled on the following spew:
[ 3837.070452]
==
[ 3837.073101] AddressSanitizer: buffer overflow in
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel with the KASAN patchset, I've stumbled on the following spew:
[ 3837.070452]
==
[ 3837.073101] AddressSanitizer: buffer overflow in
22 matches
Mail list logo
