linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk, bvanassche@acm.org,
	gregkh@linuxfoundation.org, rostedt@goodmis.org,
	mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com,
	nstange@suse.de, akpm@linux-foundation.org, mhocko@suse.com,
	yukuai3@huawei.com, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Omar Sandoval <osandov@fb.com>,
	Hannes Reinecke <hare@suse.com>, Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH 4/5] mm/swapfile: refcount block and queue before using blkcg_schedule_throttle()
Date: Tue, 14 Apr 2020 08:44:47 -0700	[thread overview]
Message-ID: <20200414154447.GC25765@infradead.org> (raw)
In-Reply-To: <20200414041902.16769-5-mcgrof@kernel.org>

On Tue, Apr 14, 2020 at 04:19:01AM +0000, Luis Chamberlain wrote:
> block devices are refcounted so to ensure once its final user goes away it
> can be cleaned up by the lower layers properly. The block device's
> request_queue structure is also refcounted, however, if the last
> blk_put_queue() is called under atomic context the block layer has
> to defer removal.
> 
> By refcounting the block device during the use of blkcg_schedule_throttle(),
> we ensure ensure two things:
> 
> 1) the block device remains available during the call
> 2) we ensure avoid having to deal with the fact we're using the
>    request_queue structure in atomic context, since the last
>    blk_put_queue() will be called upon disk_release(), *after*
>    our own bdput().
> 
> This means this code path is *not* going to remove the request_queue
> structure, as we are ensuring some later upper layer disk_release()
> will be the one to release the request_queue structure for us.
> 
> Cc: Bart Van Assche <bvanassche@acm.org>
> Cc: Omar Sandoval <osandov@fb.com>
> Cc: Hannes Reinecke <hare@suse.com>
> Cc: Nicolai Stange <nstange@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: yu kuai <yukuai3@huawei.com>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>  mm/swapfile.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 6659ab563448..9285ff6030ca 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -3753,6 +3753,7 @@ static void free_swap_count_continuations(struct swap_info_struct *si)
>  void mem_cgroup_throttle_swaprate(struct mem_cgroup *memcg, int node,
>  				  gfp_t gfp_mask)
>  {
> +	struct block_device *bdev;
>  	struct swap_info_struct *si, *next;
>  	if (!(gfp_mask & __GFP_IO) || !memcg)
>  		return;
> @@ -3771,8 +3772,17 @@ void mem_cgroup_throttle_swaprate(struct mem_cgroup *memcg, int node,
>  	plist_for_each_entry_safe(si, next, &swap_avail_heads[node],
>  				  avail_lists[node]) {
>  		if (si->bdev) {
> -			blkcg_schedule_throttle(bdev_get_queue(si->bdev),
> -						true);
> +			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(bdev), true);
> +			bdput(bdev);

I don't understand the atomic part of the comment.  How does
bdgrab/bdput help us there?

  reply	other threads:[~2020-04-14 15:45 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14  4:18 [PATCH 0/5] blktrace: fix use after free Luis Chamberlain
2020-04-14  4:18 ` [PATCH 1/5] block: move main block debugfs initialization to its own file Luis Chamberlain
2020-04-14  7:35   ` Greg KH
2020-04-15  2:44   ` Bart Van Assche
2020-04-14  4:18 ` [PATCH 2/5] blktrace: fix debugfs use after free Luis Chamberlain
2020-04-14  7:37   ` Greg KH
2020-04-14 15:38   ` Christoph Hellwig
2020-04-15  2:46   ` Bart Van Assche
2020-04-15 17:38   ` Eric Sandeen
2020-04-15 21:48     ` Bart Van Assche
2020-04-16  0:56     ` Luis Chamberlain
2020-04-16  1:02       ` Eric Sandeen
2020-04-16  1:20         ` Luis Chamberlain
2020-04-16  2:10   ` Ming Lei
2020-04-16  5:25     ` Luis Chamberlain
2020-04-16  5:47       ` Ming Lei
2020-04-16  6:09         ` Ming Lei
2020-04-16  6:22           ` Luis Chamberlain
2020-04-16  6:20         ` Luis Chamberlain
2020-04-16  6:28           ` Ming Lei
2020-04-17  4:09             ` Luis Chamberlain
2020-04-14  4:19 ` [PATCH 3/5] blktrace: refcount the request_queue during ioctl Luis Chamberlain
2020-04-14 15:40   ` Christoph Hellwig
2020-04-15  6:16     ` Luis Chamberlain
2020-04-15  7:14       ` Christoph Hellwig
2020-04-15 12:34         ` Luis Chamberlain
2020-04-15 12:39           ` Christoph Hellwig
2020-04-15 13:25             ` Luis Chamberlain
2020-04-15 14:18           ` Bart Van Assche
2020-04-16  1:12             ` Luis Chamberlain
2020-04-16  3:43               ` Bart Van Assche
2020-04-16  5:29                 ` Luis Chamberlain
2020-04-15 14:45       ` Bart Van Assche
2020-04-16  1:17         ` Luis Chamberlain
2020-04-16  2:31   ` Ming Lei
2020-04-16  5:36     ` Luis Chamberlain
2020-04-14  4:19 ` [PATCH 4/5] mm/swapfile: refcount block and queue before using blkcg_schedule_throttle() Luis Chamberlain
2020-04-14 15:44   ` Christoph Hellwig [this message]
2020-04-15  5:42     ` Luis Chamberlain
2020-04-15  7:27       ` Christoph Hellwig
2020-04-15  7:34         ` Christoph Hellwig
2020-04-15 13:19           ` Luis Chamberlain
2020-04-16  6:10             ` Christoph Hellwig
2020-04-16  6:22   ` Ming Lei
2020-04-16  6:25     ` Luis Chamberlain
2020-04-16  6:34       ` Ming Lei
2020-04-14  4:19 ` [PATCH 5/5] block: revert back to synchronous request_queue removal Luis Chamberlain
2020-04-14 15:47   ` Christoph Hellwig
2020-04-14 20:58     ` Luis Chamberlain
2020-04-15  6:46       ` Christoph Hellwig
2020-04-15 13:20         ` Luis Chamberlain
2020-04-16  2:36   ` Ming Lei
2020-04-14  7:38 ` [PATCH 0/5] blktrace: fix use after free Greg KH

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=20200414154447.GC25765@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=ming.lei@redhat.com \
    --cc=mingo@redhat.com \
    --cc=nstange@suse.de \
    --cc=osandov@fb.com \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yukuai3@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).