Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2406475ybk; Mon, 11 May 2020 21:28:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxH6kKRKXx960eEovqznExHZzl2XTR+xWm4LiB4BcDCtrB7JojzZLEgfy3vdk7/msYnS/HB X-Received: by 2002:aa7:d284:: with SMTP id w4mr3367199edq.223.1589257695667; Mon, 11 May 2020 21:28:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589257695; cv=none; d=google.com; s=arc-20160816; b=NyqHoQz8zK+CnP0pPSsbww8Gn+Kxgi1Eke7ke5OmGYaZu/qlJuM8V/7S7AnwXtI9aR rK3w+J95JJBW9RphdzAkIk9EhSxf8AecNQgnQxEbTbH7GdRWS4NO8xsf73R1q/SD4FUn 4Pz2MnMmN1THFB/fsCTrdYs/NVwhm9seBP+vhssit6O5b6ylHQGHWDYEp2UWMqudN/fz 8W3zbBirCxv0YnpqjcsnRnh/spuPekHaRTXgUjjJrT0rjkjz3cLnpnm92RWtUVBLhdzi zPfea0FqOAztBJK0MIrf3qEeAUUu/EFIR4uLsr0O31thBqKRhDupsdp1O2zYcJ0uGKG0 k7Ug== 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; bh=+e3iog7UOSgrIil/JCq5Ol7JscTbzdaqq7FIyneIm5U=; b=thqNM9kTNajUIx+qbwrQtF2H3MFuSv0kBywZHJwGVd/c29ZCGDHuOWE40dlN0aBf0G WTD/rhGf6bu9wVTdg3TszVcjBukDYeKPjVb5XD1PZTqK/VBT/t7aEzv0NBRQdcIww/v7 IYYrpVhLrztBXJ8RGTFZYbOClxeep0WG4Fa15PAJ6HupRHN62Zij4tvoxz2rR1dmTJIw kS9IzhdlRRpRX6oift1n60jtk4VaHCJqGc/DFzwuoHBFF4wEh1OYjd66Z4lj1+PkdXZ1 ljo0Ci3XeVgRy/xVr2KcjPOnhGxQYvTptqaXFm/dzBzeqCjV1/M4Ewa9oGvrRBDB0nP8 kfQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w11si6997953ede.42.2020.05.11.21.27.53; Mon, 11 May 2020 21:28:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728110AbgELEYX (ORCPT + 99 others); Tue, 12 May 2020 00:24:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:50014 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725816AbgELEYW (ORCPT ); Tue, 12 May 2020 00:24:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A3E99AEDF; Tue, 12 May 2020 04:24:23 +0000 (UTC) Subject: Re: [PATCH] xen/pvcalls-back: test for errors when calling backend_connect() To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Boris Ostrovsky , stable@vger.kernel.org References: <20200511074231.19794-1-jgross@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <17512c98-b309-7b83-8c9c-cc8d43a495a2@suse.com> Date: Tue, 12 May 2020 06:24:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11.05.20 23:41, Stefano Stabellini wrote: > On Mon, 11 May 2020, Juergen Gross wrote: >> backend_connect() can fail, so switch the device to connected only if >> no error occurred. >> >> Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling") >> Cc: stable@vger.kernel.org >> Signed-off-by: Juergen Gross > > Reviewed-by: Stefano Stabellini > > >> --- >> drivers/xen/pvcalls-back.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c >> index cf4ce3e9358d..41a18ece029a 100644 >> --- a/drivers/xen/pvcalls-back.c >> +++ b/drivers/xen/pvcalls-back.c >> @@ -1088,7 +1088,8 @@ static void set_backend_state(struct xenbus_device *dev, >> case XenbusStateInitialised: >> switch (state) { >> case XenbusStateConnected: >> - backend_connect(dev); >> + if (backend_connect(dev)) >> + return; > > Do you think it would make sense to WARN? There already should be an error message (either due to a failed grant mapping or a failed memory allocation). Juergen