Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp236826imm; Tue, 28 Aug 2018 21:45:00 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda0UHpxvex1qdMpku4MX6kaXWo8iq3/rdMO3qN/wR1tUT8yjPzT8d9qmIbGtE/KWTiftEA3 X-Received: by 2002:a62:f208:: with SMTP id m8-v6mr4254469pfh.222.1535517900767; Tue, 28 Aug 2018 21:45:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535517900; cv=none; d=google.com; s=arc-20160816; b=QDeEoIZTCx9oYkgwJtlyXS413E8UrAzRR2Egw/Lh1VAMNEnUe+k4eddPpiKE2Rgbfg xT19bPhUHBeI6fUtT2k2SR6gXEx05AZwiS8B9Js7DBCpRhwQhI6Xh3inRgi0MTPhzMVD ShaeDglzkRwwdQ8nTYWxdtTXlFZyT8chBWDeBRkU2OIrcRBCEKvVbLTFtIrg6/+BIHFx xtB6xnwq4jPABCMrRTOfsmbcQC8MPKbCTPoPiU6/rRz8EatBdmwLVcEtdYJwWOtWF0/b oxQ90XUgslJsa0EspqSOhcxCPPdDBMLopkFgKMZKdkB+wMycnmAefLkC4KsGcqtxRueB XNew== 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:arc-authentication-results; bh=bgq1Xmock/Qe1FIXza09FD1D3tJDdLa+Eam1n+PMlSM=; b=Se7RPbuVAzuKxEzu4xDCcUAmUHx7Rw+54TaoCJFUx8IqUtYWzlmY2CX2kvdWoqs8Iy JiOxYUVJW2sZTHshEE2M9oW1MLw3UXfJHozdQhSKrJ1iSt7OkyOPWCsJXsWI6Q0hRmWh tDhU1TuZDrx6PPxUSZbRtrVT8/cRPEg0eqIsU2Bo8QJY5FxD8KW9H9+Chu3xLvA8rvHD 6MxLL0p6IQupQLINyk++1g/h3odHS183HS/k3fVYRWZVhsvpZX5pFz5JZJl7PYws8t7f tUzyw5iQZZNXKsmpxaC9froxjf3z2TL5x4mGdo0pBAHmzVnrptja+lvNqTqHVsCszIJ+ ziyA== 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 i7-v6si2790182pgk.130.2018.08.28.21.44.43; Tue, 28 Aug 2018 21:45:00 -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 S1727410AbeH2Iic (ORCPT + 99 others); Wed, 29 Aug 2018 04:38:32 -0400 Received: from nautica.notk.org ([91.121.71.147]:53529 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726857AbeH2Iic (ORCPT ); Wed, 29 Aug 2018 04:38:32 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 1DCE6C009; Wed, 29 Aug 2018 06:43:31 +0200 (CEST) Date: Wed, 29 Aug 2018 06:43:16 +0200 From: Dominique Martinet To: Tomas Bortoli Cc: lucho@ionkov.net, Dominique Martinet , ericvh@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, v9fs-developer@lists.sourceforge.net, rminnich@sandia.gov, davem@davemloft.net Subject: Re: [V9fs-developer] [PATCH v2 2/2] 9p: Add refcount to p9_req_t Message-ID: <20180829044316.GA11169@nautica> References: <20180814174342.11068-1-tomasbortoli@gmail.com> <20180814174342.11068-2-tomasbortoli@gmail.com> <20180827230954.GA21513@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180827230954.GA21513@nautica> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dominique Martinet wrote on Tue, Aug 28, 2018: > I think I've found why (see below), so I'll push a fixed version after > some more testing and another thorough read -- at some point today, but > this hasn't been 'approved' explicitely so please review! :) While the issue I pointed at was real, it wasn't what was causing the refcount leak I was observing -- the problem is that we didn't drop a ref when the request was successfully cancelled (e.g. the reply to the flush came and the original request didn't get replied to) The reason for this was that there were multiple versions of the patch which alternated between doing the put in client.c after the cancelled callback inconditionally, and doing the put in each transport's cancelled() function, but virtio does not have this callback so that didn't get added in the final version (codeveloping is hard); so I've added an else() close to just issue a put if there is no callback. (In the end, it felt better to have the req_put in the transport because trans_fd is making refcounting difficult with its list handling, and separating the put from the list removal would be more confusing than is gained by sharing code) Anyway, that's starting to be quite different from the v2 so I'll send a v3 keeping Tomas as the author -- please check my edits are alright with you, Tomas. Meanwhile I'll keep running tests, I'm now confident about virtio but want to spend more time on other transports again, so delaying the push to linux-next for a few more days... -- Dominique