linux-kernel - Re: [PATCH v2 6/6] mm/balloon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALYGNiM-ArE2+M+xjSbDjLyNc_Rr0C=6TKBKPi4bEwxFfeU_tA@mail.gmail.com>
Date:	Sat, 13 Sep 2014 09:43:54 +0400
From:	Konstantin Khlebnikov <koct9i@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Konstantin Khlebnikov <k.khlebnikov@...sung.com>,
	Rafael Aquini <aquini@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: [PATCH v2 6/6] mm/balloon_compaction: general cleanup

On Sat, Sep 13, 2014 at 4:06 AM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Fri, 12 Sep 2014 17:04:04 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
>
>> On Sat, 30 Aug 2014 20:41:27 +0400 Konstantin Khlebnikov <koct9i@...il.com> wrote:
>>
>> > * move special branch for balloon migraion into migrate_pages
>> > * remove special mapping for balloon and its flag AS_BALLOON_MAP
>> > * embed struct balloon_dev_info into struct virtio_balloon
>> > * cleanup balloon_page_dequeue, kill balloon_page_free
>>
>> Not sure what's going on here - your include/linux/balloon_compaction.h
>> seems significantly different from mine.
>
> OK, I worked it out.
>
>> I think I'll just drop this patch - it's quite inconvenient to have a
>> large "general cleanup" coming after a stack of significant functional
>> changes.  It makes review, debug, fix, merge and reversion harder.
>> Let's worry about it later.
>
> But I'm still thinking we should defer this one?

It seems in this case massive cleanup before fixies leads to much bigger mess.
I've separated fixes specially for merging into stable kernels.

The rest patches mostly rewrites this code using new approatch.
I don't know how to make it more reviewable, it's easier to write a
new version from the scratch.
Probably rework should be untied form fixes and sent as separate patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/