Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1722733ybj; Wed, 6 May 2020 04:14:44 -0700 (PDT) X-Google-Smtp-Source: APiQypKtq7oQRl0VvNqsii8nxdv/N3zrtJJXMMcfOdVzwtlKtO7X/cruG6Qu9SY19qw53AgVLh3p X-Received: by 2002:a50:d0d5:: with SMTP id g21mr6641578edf.92.1588763684002; Wed, 06 May 2020 04:14:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588763683; cv=none; d=google.com; s=arc-20160816; b=oC7Nn+Q1N+CHaebflKW7QmajXYOZKPf9hp6y9M2HDdZxZlU5Zz4qrz0UxO3ESf6KOK YY9XBf7cfMzcB6ZiSJxAs7dxK5rKclEuQuXlDkNTaK4HHushNst5c3RQZlo7N42fTn7N Gk/XgOCpTZnsh0wEAar0RjPgrdlFO6hyfqELVsdy7beEwoU0gwRbTMBVFg0JkBnH7rug 2t/kBFmqqwDQuStKQH4bJV3woGkdWB3qKOguvewMgxDnSIJzJVcZLFvtVzofcSUDQ3m2 OogkBKKfb0wxSvB31EW3TmeBjTd+zpf3K7/IKj40MGzeSTct0WJ7U1V9hMzVr6/WxSXE UMTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=UoMrVgpHFSkqLOX50oUet38/BjwtL1uNpcuGKCdyvyU=; b=0yLS+7Ctx1axgrkM4jaks82AEClZcARFSL3efF+3PgIPNwvTezNg+csYC1To6kb0SP +WZVshpT2649507MrAoYEXV3SFhFsxajZ5r11BkxCpyHYXfU03oaygAh4vnA5QsyuusS K7xagTEJPrX6652lxCWmhJcEVZp2x8srxQrSGCyWjnFF4YVeJqKrsAhrvgs1w/SEEu3F Skfva7Ka7X2QM2+DRZXZDq7v6N3v7FqEBOFY3JyU2G82pZ88nPr4gweBZB0V5PXECBfK LKJlIUqMiefopJKn08DgLFGF38SGmuDv/G2zemF7TdMWL7bFPwbKu5pMdAIQDEUZ2xl0 x06w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-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 l18si924178ejb.405.2020.05.06.04.14.20; Wed, 06 May 2020 04:14:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-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-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727995AbgEFLJa convert rfc822-to-8bit (ORCPT + 99 others); Wed, 6 May 2020 07:09:30 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:56688 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727861AbgEFLJa (ORCPT ); Wed, 6 May 2020 07:09:30 -0400 Received: from marcel-macbook.fritz.box (p4FEFC5A7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id 93695CED03; Wed, 6 May 2020 13:19:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled From: Marcel Holtmann In-Reply-To: Date: Wed, 6 May 2020 13:09:27 +0200 Cc: Manish Mandlik , linux-bluetooth , ChromeOS Bluetooth Upstreaming , Alain Michaud , "David S. Miller" , Johan Hedberg , netdev , LKML , Jakub Kicinski Content-Transfer-Encoding: 8BIT Message-Id: <96B8EB2A-BDFB-49F5-B168-F8FD2991FC33@holtmann.org> References: <20200414115512.1.I9dd050ead919f2cc3ef83d4e866de537c7799cf3@changeid> To: Luiz Augusto von Dentz X-Mailer: Apple Mail (2.3608.80.23.2.2) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Luiz, >>> If user decides to cancel ongoing pairing process (e.g. by clicking >>> the cancel button on the pairing/passkey window), abort any ongoing >>> pairing and then terminate the link. >>> >>> Signed-off-by: Manish Mandlik >>> --- >>> Hello Linux-Bluetooth, >>> >>> This patch aborts any ongoing pairing and then terminates the link >>> by calling hci_abort_conn() in cancel_pair_device() function. >>> >>> However, I'm not very sure if hci_abort_conn() should be called here >>> in cancel_pair_device() or in smp for example to terminate the link >>> after it had sent the pairing failed PDU. >>> > > Id recommend leaving the hci_abort_conn out since that is a policy > decision the userspace should be in charge to decide if the link > should be disconnected or not. eventually the link will disconnect anyway if we have no users. However maybe we should try to track if we created the link because Pair Device action. If created the link, then aborting the pairing should disconnect the link right away. Otherwise we can leave it around. Regards Marcel