From: Tejun Heo <tj@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Block IO bits for 3.3-rc
Date: Sun, 15 Jan 2012 23:22:26 -0800 [thread overview]
Message-ID: <20120116072226.GA3399@mtj.dyndns.org> (raw)
In-Reply-To: <CA+55aFxyiMXg0BHrZ0LJtCeE+u+pNSM1n=zDbW5-7CtZnh2O=Q@mail.gmail.com>
Hello,
On Sun, Jan 15, 2012 at 12:33:20PM -0800, Linus Torvalds wrote:
> On Sun, Jan 15, 2012 at 1:45 AM, Jens Axboe <axboe@kernel.dk> wrote:
> > See below for the initial 3.3-rc1 git pull request in the block IO area.
> > Not too much queued up for this round, mostly some code churn to improve
> > some of the existing functionality.
> >
> > It has the following changes:
> >
> > - The big io context cleanup from Tejun.
>
> Ok. This got some conflicts that I think I got right, but I'd really
> like Tejun to check it out. There were changes mainly to things he had
> removed, and I think all the changes were made irrelevant by his
> cleanups, but...
In cfq-iosched.c, there were the following three mainline commits
which weren't in the block branch.
- 2984ff38cc "cfq-iosched: free cic_index if blkio_alloc_blkg_stats fails"
This fixes cic->cic_index freeing in alloc failure path.
cic_index got moved to q->id which is allocated in
blk_alloc_queue_node() and properly freed after any failure.
This doesn't cause any conflict per-se but causes compiler
failure as cic_index no longer exists. Changes made by this
patch should be removed.
- 5eb46851de "cfq-iosched: fix cfq_cic_link() race confition"
This fixes install race handling in unlock-alloc-lock-install
sequence. The logic got moved to ioc_create_icq() which
already deals with it properly. Ignoring conflict and
removing the conflicted part from mainline should do.
- 6ae0516b8a "block, cfq: fix empty queue crash caused by request merge"
The same commit existed in block as 4a0b75c7d0. Nothing to
do.
In blk-ioc.c, the following commit.
- bb9d97b6df "cgroup: don't use subsys->can_attach_task() or ->attach_task()"
It conflicts with three block commits updating how ioc is
obtained and the changed flag is set. Putting the updated
per-task logic from block inside cgroup_taskset_for_each()
loop is the correct resolution.
So, yeap, my merge matches yours exactly and everything looks good to
me.
Thanks.
--
tejun
prev parent reply other threads:[~2012-01-16 7:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-15 9:45 Jens Axboe
2012-01-15 20:33 ` Linus Torvalds
2012-01-16 7:22 ` Tejun Heo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120116072226.GA3399@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome