public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
Cc: "kbusch@kernel.org" <kbusch@kernel.org>,
	"hch@lst.de" <hch@lst.de>, "hare@suse.de" <hare@suse.de>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"dlemoal@kernel.org" <dlemoal@kernel.org>,
	"wagi@kernel.org" <wagi@kernel.org>,
	"mpatocka@redhat.com" <mpatocka@redhat.com>,
	"yukuai3@huawei.com" <yukuai3@huawei.com>,
	"xni@redhat.com" <xni@redhat.com>,
	"linan122@huawei.com" <linan122@huawei.com>,
	"bmarzins@redhat.com" <bmarzins@redhat.com>,
	"john.g.garry@oracle.com" <john.g.garry@oracle.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"ncardwell@google.com" <ncardwell@google.com>,
	"kuniyu@google.com" <kuniyu@google.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"dsahern@kernel.org" <dsahern@kernel.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"horms@kernel.org" <horms@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [RFC blktests fix PATCH] tcp: use GFP_ATOMIC in tcp_disconnect
Date: Tue, 25 Nov 2025 16:43:25 +0530	[thread overview]
Message-ID: <0caa9d00-3f69-4ade-b93b-eea307fe6f72@linux.ibm.com> (raw)
In-Reply-To: <ea2958c9-4571-4169-8060-6456892e6b15@nvidia.com>



On 11/25/25 12:58 PM, Chaitanya Kulkarni wrote:
> On 11/24/25 22:27, Christoph Hellwig wrote:
>> I don't think GFP_ATOMIC is right here, you want GFP_NOIO.
>>
>> And just use the scope API so that you don't have to pass a gfp_t
>> several layers down.
>>
>>
> are you saying something like this ?
> 
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index 29ad4735fac6..56d0a3777a4d 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -1438,17 +1438,28 @@ static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
>   	struct nvme_tcp_ctrl *ctrl = to_tcp_ctrl(nctrl);
>   	struct nvme_tcp_queue *queue = &ctrl->queues[qid];
>   	unsigned int noreclaim_flag;
> +	unsigned int noio_flag;
>   
>   	if (!test_and_clear_bit(NVME_TCP_Q_ALLOCATED, &queue->flags))
>   		return;
>   
>   	page_frag_cache_drain(&queue->pf_cache);
>   
> +	/**
> +	 * Prevent memory reclaim from triggering block I/O during socket
> +	 * teardown. The socket release path fput -> tcp_close ->
> +	 * tcp_disconnect -> tcp_send_active_reset may allocate memory, and
> +	 * allowing reclaim to issue I/O could deadlock if we're being called
> +	 * from block device teardown (e.g., del_gendisk -> elevator cleanup)
> +	 * which holds locks that the I/O completion path needs.
> +	 */
> +	noio_flag = memalloc_noio_save();
>   	noreclaim_flag = memalloc_noreclaim_save();
>   	/* ->sock will be released by fput() */
>   	fput(queue->sock->file);
>   	queue->sock = NULL;
>   	memalloc_noreclaim_restore(noreclaim_flag);
> +	memalloc_noio_restore(noio_flag);
>   
>   	kfree(queue->pdu);
>   	mutex_destroy(&queue->send_mutex);

The memalloc_noreclaim_save() above shall already prevent filesystem reclaim,
so if the goal is to avoid fs_reclaim, we should not need an additional
memalloc_noio_save() here. That makes me wonder whether we are looking at the
correct code path. If this teardown path (nvme_tcp_free_queue()) is indeed executed,
it should already be avoiding filesystem reclaim in the first place.

Thanks,
--Nilay

  parent reply	other threads:[~2025-11-25 11:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-25  6:11 [RFC blktests fix PATCH] tcp: use GFP_ATOMIC in tcp_disconnect Chaitanya Kulkarni
2025-11-25  6:27 ` Christoph Hellwig
2025-11-25  7:28   ` Chaitanya Kulkarni
2025-11-25 11:08     ` hch
2025-11-25 11:13     ` Nilay Shroff [this message]
2025-11-25 11:21       ` hch
2025-11-25 11:28         ` Nilay Shroff
2025-11-25 11:30           ` Christoph Hellwig
2025-11-25 11:54             ` Nilay Shroff
2025-11-25 12:33               ` Hannes Reinecke

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=0caa9d00-3f69-4ade-b93b-eea307fe6f72@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=bmarzins@redhat.com \
    --cc=chaitanyak@nvidia.com \
    --cc=ckulkarnilinux@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dlemoal@kernel.org \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=horms@kernel.org \
    --cc=john.g.garry@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linan122@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mpatocka@redhat.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sagi@grimberg.me \
    --cc=wagi@kernel.org \
    --cc=xni@redhat.com \
    --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