[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090916184749.GF5221@redhat.com>
Date: Wed, 16 Sep 2009 14:47:49 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Nauman Rafique <nauman@...gle.com>
Cc: linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
containers@...ts.linux-foundation.org, dm-devel@...hat.com,
dpshah@...gle.com, lizf@...fujitsu.com, mikew@...gle.com,
fchecconi@...il.com, paolo.valente@...more.it, ryov@...inux.co.jp,
fernando@....ntt.co.jp, s-uchida@...jp.nec.com, taka@...inux.co.jp,
guijianfeng@...fujitsu.com, jmoyer@...hat.com,
dhaval@...ux.vnet.ibm.com, balbir@...ux.vnet.ibm.com,
righi.andrea@...il.com, m-ikeda@...jp.nec.com, agk@...hat.com,
akpm@...ux-foundation.org, peterz@...radead.org,
jmarchan@...hat.com, torvalds@...ux-foundation.org, mingo@...e.hu,
riel@...hat.com
Subject: Re: [PATCH 20/23] io-controller: Per cgroup request descriptor
support
On Mon, Sep 14, 2009 at 11:33:37AM -0700, Nauman Rafique wrote:
[..]
> > struct request *blk_get_request(struct request_queue *q, int rw, gfp_t gfp_mask)
> > {
> > struct request *rq;
> > + struct request_list *rl;
> >
> > BUG_ON(rw != READ && rw != WRITE);
> >
> > spin_lock_irq(q->queue_lock);
> > + rl = blk_get_request_list(q, NULL);
> > if (gfp_mask & __GFP_WAIT) {
> > rq = get_request_wait(q, rw, NULL);
> > } else {
> > - rq = get_request(q, rw, NULL, gfp_mask);
> > + rq = get_request(q, rw, NULL, gfp_mask, rl, NULL);
> > if (!rq)
> > spin_unlock_irq(q->queue_lock);
> > }
> > @@ -1085,12 +1269,13 @@ void __blk_put_request(struct request_queue *q, struct request *req)
> > if (req->cmd_flags & REQ_ALLOCED) {
> > int is_sync = rq_is_sync(req) != 0;
> > int priv = req->cmd_flags & REQ_ELVPRIV;
> > + struct request_list *rl = rq_rl(q, req);
> >
> > BUG_ON(!list_empty(&req->queuelist));
> > BUG_ON(!hlist_unhashed(&req->hash));
> >
> > blk_free_request(q, req);
> > - freed_request(q, is_sync, priv);
> > + freed_request(q, is_sync, priv, rl);
>
> We have a potential memory bug here. freed_request should be called
> before blk_free_request as blk_free_request might result in release of
> cgroup, and request_list. Calling freed_request after blk_free_request
> would result in operations on freed memory.
>
Good point Nauman. freeing rq will drop reference on the io queue. Which
in turn will drop reference on io group and if associated cgroup is
already gone, then io group will be freed hence request list pointer is
no more valid and any operation on that is bad.
So either we can take a reference on the queue, call free_request() and
then drop the reference or we can call freed_request() before
blk_free_request(). Calling freed_request() before blk_free_request()
sounds better to me. The only thing is that this function name and other
dependent function names should now be freeing_request() instead of
freed_request(). :-)
Will move freed_request() before blk_free_request() in next version.
Thanks
Vivek
--
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/
Powered by blists - more mailing lists