Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-SDR: ZTdF8SKlYPR3k01bjhig8KcQn2X3mRzMxMpBNMJKq/5oyT9npbrxFEJWEC6jnU2CNACrntnGU/
 4IIIwxg5EFAWnKhI2X5nYjAnebmOqdpQD7ggB379K+ymc50VroXNZVjC6ZNwdggAynxtHpsKKa
 ByS7Sscn7KolkNxghQxYovELiW3Pw6AqLoMED0AlOyZa8KBx+J6yYSCdrcZxbJbvsCNC29rv5Q
 9xIYX4TE+lc9jyu/p5B4ELCH15/ajHshZQj1YY3PoBRlaCuL7JkCs5LTaZNH723cmlj1npaUEA
 VjQ=
From:   Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To:     Logan Gunthorpe <logang@deltatee.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
CC:     Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
        Jens Axboe <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>,
        Max Gurtovoy <maxg@mellanox.com>
Subject: Re: [PATCH v3 2/4] nvmet-loop: Flush nvme_delete_wq when removing the
 port
Thread-Topic: [PATCH v3 2/4] nvmet-loop: Flush nvme_delete_wq when removing
 the port
Thread-Index: AQHVR/iwlIUuBWVyrUKyRjod+n3jbw==
Date:   Wed, 31 Jul 2019 23:53:09 +0000
Message-ID: <BYAPR04MB5749933ACEC902B934CA212586DF0@BYAPR04MB5749.namprd04.prod.outlook.com>
References: <20190731233534.4841-1-logang@deltatee.com>
 <20190731233534.4841-3-logang@deltatee.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e6311538-a3ea-447a-3473-08d716123dc2
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 23:53:09.6375
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Chaitanya.Kulkarni@wdc.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4455
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Looks good.=0A=
=0A=
Reviewed-by : Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>=0A=
=0A=
On 07/31/2019 04:35 PM, Logan Gunthorpe wrote:=0A=
> After calling nvme_loop_delete_ctrl(), the controllers will not=0A=
> yet be deleted because nvme_delete_ctrl() only schedules work=0A=
> to do the delete.=0A=
>=0A=
> This means a race can occur if a port is removed but there=0A=
> are still active controllers trying to access that memory.=0A=
>=0A=
> To fix this, flush the nvme_delete_wq before returning from=0A=
> nvme_loop_remove_port() so that any controllers that might=0A=
> be in the process of being deleted won't access a freed port.=0A=
>=0A=
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>=0A=
> Reviewed-by: Sagi Grimberg <sagi@grimberg.me>=0A=
> Reviewed-by: Max Gurtovoy <maxg@mellanox.com>=0A=
> ---=0A=
>   drivers/nvme/target/loop.c | 8 ++++++++=0A=
>   1 file changed, 8 insertions(+)=0A=
>=0A=
> diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c=0A=
> index b16dc3981c69..0940c5024a34 100644=0A=
> --- a/drivers/nvme/target/loop.c=0A=
> +++ b/drivers/nvme/target/loop.c=0A=
> @@ -654,6 +654,14 @@ static void nvme_loop_remove_port(struct nvmet_port =
*port)=0A=
>   	mutex_lock(&nvme_loop_ports_mutex);=0A=
>   	list_del_init(&port->entry);=0A=
>   	mutex_unlock(&nvme_loop_ports_mutex);=0A=
> +=0A=
> +	/*=0A=
> +	 * Ensure any ctrls that are in the process of being=0A=
> +	 * deleted are in fact deleted before we return=0A=
> +	 * and free the port. This is to prevent active=0A=
> +	 * ctrls from using a port after it's freed.=0A=
> +	 */=0A=
> +	flush_workqueue(nvme_delete_wq);=0A=
>   }=0A=
>=0A=
>   static const struct nvmet_fabrics_ops nvme_loop_ops =3D {=0A=
>=0A=
=0A=