[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5001fb4f-28b8-26b1-fc66-11b3105b15b9@acm.org>
Date: Thu, 9 Apr 2020 20:02:59 -0700
From: Bart Van Assche <bvanassche@....org>
To: Luis Chamberlain <mcgrof@...nel.org>, axboe@...nel.dk,
viro@...iv.linux.org.uk, gregkh@...uxfoundation.org,
rostedt@...dmis.org, mingo@...hat.com, jack@...e.cz,
ming.lei@...hat.com, nstange@...e.de, akpm@...ux-foundation.org
Cc: mhocko@...e.com, yukuai3@...wei.com, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Omar Sandoval <osandov@...com>,
Hannes Reinecke <hare@...e.com>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: [RFC v2 4/5] mm/swapfile: refcount block and queue before using
blkcg_schedule_throttle()
On 2020-04-09 14:45, Luis Chamberlain wrote:
> if (si->bdev) {
> + bdev = bdgrab(si->bdev);
> + if (!bdev)
> + continue;
> + /*
> + * By adding our own bdgrab() we ensure the queue
> + * sticks around until disk_release(), and so we ensure
> + * our release of the request_queue does not happen in
> + * atomic context.
> + */
> blkcg_schedule_throttle(bdev_get_queue(si->bdev),
> true);
How about changing the si->bdev argument of blkcg_schedule_throttle()
into bdev?
Thanks,
Bart.
Powered by blists - more mailing lists