linux-kernel - Re: [PATCH v2] blk-cgroup: remove entries in blkg

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 11 Apr 2018 17:06:41 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "tj@...nel.org" <tj@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "nborisov@...e.com" <nborisov@...e.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>, "shli@...com" <shli@...com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "00moses.alexander00@...il.com" <00moses.alexander00@...il.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "joseph.qi@...ux.alibaba.com" <joseph.qi@...ux.alibaba.com>
Subject: Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue
 release

On Wed, 2018-04-11 at 10:00 -0700, tj@...nel.org wrote:
> On Wed, Apr 11, 2018 at 04:42:55PM +0000, Bart Van Assche wrote:
> > On Wed, 2018-04-11 at 07:56 -0700, Tejun Heo wrote:
> > > And looking at the change, it looks like the right thing we should
> > > have done is caching @lock on the print_blkg side and when switching
> > > locks make sure both locks are held.  IOW, do the following in
> > > blk_cleanup_queue()
> > > 
> > > 	spin_lock_irq(lock);
> > > 	if (q->queue_lock != &q->__queue_lock) {
> > > 		spin_lock(&q->__queue_lock);
> > > 		q->queue_lock = &q->__queue_lock;
> > > 		spin_unlock(&q->__queue_lock);
> > > 	}
> > > 	spin_unlock_irq(lock);
> > > 
> > > Otherwise, there can be two lock holders thinking they have exclusive
> > > access to the request_queue.
> > 
> > I think that's a bad idea. A block driver is allowed to destroy the
> > spinlock it associated with the request queue as soon as blk_cleanup_queue()
> > has finished. If the block cgroup controller would cache a pointer to the
> > block driver spinlock then that could cause the cgroup code to attempt to
> > lock a spinlock after it has been destroyed. I don't think we need that kind
> > of race conditions.
> 
> I see, but that problem is there with or without caching as long as we
> have queu_lock usage which reach beyond cleanup_queue, right?  Whether
> that user caches the lock for matching unlocking or not doesn't really
> change the situation.
> 
> Short of adding protection around queue_lock switching, I can't think
> of a solution tho.  Probably the right thing to do is adding queue
> lock/unlock helpers which are safe to use beyond cleanup_queue.

Hello Tejun,

A simple and effective solution is to dissociate a request queue from the
block cgroup controller before blk_cleanup_queue() returns. This is why commit
a063057d7c73 ("block: Fix a race between request queue removal and the block
cgroup controller") moved the blkcg_exit_queue() call from __blk_release_queue()
into blk_cleanup_queue().

Thanks,

Bart.