Received: by 10.223.185.116 with SMTP id b49csp1925428wrg; Mon, 12 Feb 2018 00:55:23 -0800 (PST) X-Google-Smtp-Source: AH8x226T7FK5eFNs7JmNT6itC665VKLiBXCFtu7BTrwitWimrWbDXFeW4iEU6e/dfCs3KUrtyaji X-Received: by 10.99.3.8 with SMTP id 8mr3292603pgd.5.1518425723476; Mon, 12 Feb 2018 00:55:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518425723; cv=none; d=google.com; s=arc-20160816; b=LcnjTNtE2K5af0Xvjm7xkXs7UGCJaJCk/RHbkRzeO+uXDxHMVjGx93U12kGcxYRFEK TRg+p5f/UYnAIXIRux5ff5TMeCtAp9p4AqBVtaEuo7iZkrVkWcDxy2Jm2UhyE5DSq+B/ g0uhs+aIKdYfwtPACCLKLbg7C2losnSYWjFwlttk0aMXgvp7D/U2uzv7yaAp7uOoGUnJ ftYDT4ljktv1ykaap7oKCushX5Z8ct8hatxvxZ/ON34f61WT9kyRlDCN7Ha14AuhBpw+ /qv8p2iYSXArpHltWk+N5lMLdqmmTO4mXQF9rfBt77febVbO6yZfNuVqRuSlFOgM++sL 3ozQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=FRagnKnuA5R1oOOE2XtdVWBODvvoHhYYaxnZKqsrwPg=; b=p5oXVeAixDGua8W5zDOWkP7mHd7TeW3oyUHqa6Bh/YHtyTWpoIx0giXVpKIiEDQXEb ayFKyFtWpZlZQ54JJc10cjiP1rinmWCMSSpTBKAZ3uROSlo9CaMWAsTZucfuXV6ORovx DFKoYRKn1s5rLK17w2KH6irmJgHoXj8T7/4KND14JGfCwpNNj+Sc8f9OuypRPTd17hHl M2BdO01wXZv0eGRshbDEA14PO4mWmj9OFPDclz6iTnKiETPGlGOxl2aIUVe9ZeMRGUii WoHY3DvM97v9s27SCH3zL9IecBq+Gj8syjIFEls5+oBsdUbTv2THLfCrjgQGBeY6qYOO bDLQ== 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 bd1-v6si5536263plb.69.2018.02.12.00.55.09; Mon, 12 Feb 2018 00:55:23 -0800 (PST) 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 S1751246AbeBLItb (ORCPT + 99 others); Mon, 12 Feb 2018 03:49:31 -0500 Received: from mx2.suse.de ([195.135.220.15]:35922 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932891AbeBLIt3 (ORCPT ); Mon, 12 Feb 2018 03:49:29 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 346E0ACC8; Mon, 12 Feb 2018 08:49:28 +0000 (UTC) Subject: Re: [PATCH 1/2] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling To: Simon Gaiser , xen-devel@lists.xenproject.org Cc: stable@vger.kernel.org, Boris Ostrovsky , linux-kernel@vger.kernel.org References: <20180207222236.7434-1-simon@invisiblethingslab.com> From: Juergen Gross Message-ID: Date: Mon, 12 Feb 2018 09:49:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180207222236.7434-1-simon@invisiblethingslab.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/02/18 23:22, Simon Gaiser wrote: > Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple > concurrent xenstore accesses") made a subtle change to the semantic of > xenbus_dev_request_and_reply() and xenbus_transaction_end(). > > Before on an error response to XS_TRANSACTION_END > xenbus_dev_request_and_reply() would not decrement the active > transaction counter. But xenbus_transaction_end() has always counted the > transaction as finished regardless of the response. Which is correct now. Xenstore will free all transaction related data regardless of the response. A once failed transaction can't be repaired, it has to be repeated completely. The real problem is decrementing the counter when XS_TRANSACTION_END for a non-existing transaction is being sent. > The new behavior is that xenbus_dev_request_and_reply() and > xenbus_transaction_end() will always count the transaction as finished > regardless the response code (handled in xs_request_exit()). ENOENT should not decrement the transaction counter, while all other responses to XS_TRANSACTION_END should still do so. > But xenbus_dev_frontend tries to end a transaction on closing of the > device if the XS_TRANSACTION_END failed before. Trying to close the > transaction twice corrupts the reference count. So fix this by also > considering a transaction closed if we have sent XS_TRANSACTION_END once > regardless of the return code. A transaction in the list of transactions should not considered to be finished. Either it is not on the list or it is still pending. > > Cc: # 4.11 > Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses") > Signed-off-by: Simon Gaiser So: your patch is a band-aid trying to cure the symptoms, but not the real problem. Please do it properly. NAK. Juergen