linux-kernel - Re: [GIT PULL] block/for-3.5/core: pull in cgroup/for-3.5

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: <20120402115905.cbca9c04113e543163bdb5f2@canb.auug.org.au>
Date:	Mon, 2 Apr 2012 11:59:05 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Tejun Heo <tj@...nel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Vivek Goyal <vgoyal@...hat.com>,
	Li Zefan <lizefan@...wei.com>, linux-kernel@...r.kernel.org,
	ctalbott@...gle.com, rni@...gle.com
Subject: Re: [GIT PULL] block/for-3.5/core: pull in cgroup/for-3.5

Hi Tejun,

On Sun, 1 Apr 2012 13:03:06 -0700 Tejun Heo <tj@...nel.org> wrote:
>
> cgroup/for-3.5 currently contains the following changes which
> blk-cgroup needs to proceed with the on-going cleanup.
> 
> * Dynamic addition and removal of cftypes to make config/stat file
>   handling modular for policies.
> 
> * cgroup removal update to not wait for css references to drain to fix
>   blkcg removal hang caused by cfq caching cfqgs.
> 
> Due to the extensive changes in blk-cgroup.c, the pull results in some
> non-trivial conflicts which can be a bit tricky to resolve correctly.
> 
> The following branch contains the merged commit.  Please feel free to
> pull in as-is or use it as reference.  Stephen, cgroup and block next
> branches will cause nasty conflicts until this merge happens, please
> use this commit as merge reference or skip cgroup/for-3.5 for the time
> being.

OK, I have moved the cgroup tree to before the block tree (just so we see
failures in that tree independently of failures in the block tree).
Currently the block tree contains nothing, so we have no conflicts
today.  The best way to proceed is for the parts of the cgroup tree that
the block tree will depend on (which may be the entire current cgroup
tree) should be in a separate, stable (i.e. non rebasing/rewriting)
branch that can be merged into both the cgroup and block trees.

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

Content of type "application/pgp-signature" skipped