Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1253294ybx; Thu, 31 Oct 2019 07:53:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqxasn8nNjFCO7Fxb+j5XfVigwBsThCjwhAnCXcm9ID6xpEu1a6SLyJ8zgs11aG8BLsfbIwy X-Received: by 2002:a50:af44:: with SMTP id g62mr6682139edd.164.1572533621119; Thu, 31 Oct 2019 07:53:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572533621; cv=none; d=google.com; s=arc-20160816; b=1E7VH2D5X2qKI4pfeR6UReqQXP12Dtdum2lZTk+KKaW/t3GyUIFk4PpddcqV1JCR9m 8sOSyYuyhpbfH3yF3AgR+0oiN0kIkGZxq4aJw8VB7XJsWW5r1SqxHOhhftYn6ElPny1u PD+KWnuuYSAG4h3Wr586weqcPSNEQa0FtCYlQ8WkQp1Xony6DIdML5JySJ1bjerBA6XV dLb9GdzmvQJemuLUDMMWBkdtXuPIZzHMkd1zzj3lHFQePAHiqmj3UYLY3rxGLKdmx4yJ fglaa4U9GR/71jC8GniZibdEmbk1Q2USL17UFJKFvh9Bo7NdWJRZp9REehpcozLFwc7k i58Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=5QFIysUCy4dJ3MaQQihEjs9y8titUAe2Pck/Dv/ryjc=; b=uSZAGP8JB2XUVuFKJclgZ9Z2fz/CsWMpFX3nclAhOmgMmNuy7qJIpZXpUci/9A/qFB xlBbq6YqDkjANWU/C7wsV4qkECy6xPpUqMtWrG5g7c0YiSTLkf7xQDynjLeEsiuPassM smvJBktgAEzYotiEpn9ZsruAH4MFTcP9lKUesm43NUF0WOcEHmeA6io++svVcHIS+o/N XEEppKkxJdE9slFhgA18i/zAHKBhCJwVTweLer5yJK50q5fYsWSaCIbbZr2flyE58ma8 Gzq4/q7uIlKN4L1C6/aFmcjC3GttmuyVDmp8ov5Wb2ZUCmmpR/szvvVuDmy3XNOdQFEk i/Wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v9si4310254edf.36.2019.10.31.07.53.17; Thu, 31 Oct 2019 07:53:41 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728258AbfJaOvb (ORCPT + 99 others); Thu, 31 Oct 2019 10:51:31 -0400 Received: from verein.lst.de ([213.95.11.211]:51457 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728134AbfJaOva (ORCPT ); Thu, 31 Oct 2019 10:51:30 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id B76EF68C4E; Thu, 31 Oct 2019 15:51:27 +0100 (CET) Date: Thu, 31 Oct 2019 15:51:27 +0100 From: Christoph Hellwig To: Daniel Wagner Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Sagi Grimberg , Johannes Thumshirn Subject: Re: [RFC] nvmet: Always remove processed AER elements from list Message-ID: <20191031145127.GC6024@lst.de> References: <20191030152418.23753-1-dwagner@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030152418.23753-1-dwagner@suse.de> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 30, 2019 at 04:24:18PM +0100, Daniel Wagner wrote: > All async events are enqueued via nvmet_add_async_event() which > updates the ctrl->async_event_cmds[] array and additionally an struct > nvmet_async_event is added to the ctrl->async_events list. > > Under normal operations the nvmet_async_event_work() updates again the > ctrl->async_event_cmds and removes the corresponding struct > nvmet_async_event from the list again. Though nvmet_sq_destroy() could > be called which calles nvmet_async_events_free() which only updates > the ctrl->async_event_cmds[] array. > > Add a new function nvmet_async_events_process() which processes the > async events and updates both array and the list. With this we avoid > having two places where the array and list are modified. I don't think this patch is correct. We can have AEN commands pending that aren't used - that is the host sent the command, but the target did not have even event yet. That means the command sits in async_event_cmds, but there is no entry in >async_events for it yet. That being said I think what we want is to do the loop in your new nvmet_async_events_free first, but after that still call the loop in the existing nvmet_async_events_free after that. That ensures we first flush out everything in ->async_events, and then also return any potential remaining entry.