Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp112346ybf; Fri, 28 Feb 2020 23:15:10 -0800 (PST) X-Google-Smtp-Source: APXvYqw0Qr9K+IKRqrJwaiYTWW0S66L4KEb9m+29AFrv00Snd9AKIUKZ7pha94JjdbN9/lWbpsgw X-Received: by 2002:aca:f405:: with SMTP id s5mr5586535oih.93.1582960510216; Fri, 28 Feb 2020 23:15:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582960510; cv=none; d=google.com; s=arc-20160816; b=DBr2smlxtrsswirAQUnGkPXy6CGwbR0c/1uUa4zq7QZHAZVrQBWcfWZkgwQJCTTXIh f4FUpySG4HIZJ5JVlyKa7DFb4KmiLPpNYGIKxsb1iuFqeehMSBLYpoeu54MgUX665iDN jiyEVh3NbFjn/66Vgn5KFlRkUNjQanuJ/N6KLzgl2ZGz+4U4xaDXX23AL1vuahES/CdD jBxIio1Mnczj5L3AVer2Si0MKDcN8xRNBmAdXEmkdgQ+70WAsHPQXyC/MhFYIreCOA5s 6W1GPsKRkm+93F793S5P0cRUjq1YxIgc09a0Pkovqg6dAUfPR5boRtSGZhRWrv7jWQXm fpxg== 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=FdoltzrPRlgcUbCoc8Wa7Hhf8ndm/Ds7ud8pa5R4j9k=; b=y3rc+aMCQmOBhtd04BakIHzV3JDgnlMkKF1tS9mzFCx4tHNpOHV5ruzEg5C7aKZONp IxWEs1xkGp0VPTcTnfvhw8ivmLsEeGIiL30EZ3a9lV7u1lph23H19C20VmZnzYNZvDty SHS5SXIKnAMbj4hoNI27oWYb0mr5vkOS3BdYkWE/sAyvTuVn8iUG1BzPxp7lNLT1ekrd KSSR4z0gcYGpP0bX/zCeBlsGOIiwoqsxQ4zMNweu+MSqL1ZEqmx2Z7QycN3jnZmlnqrk 2NaWY0wIycFlkpZVUJUJKC6pbFBQk39AQzBhcYPPskgFCpqdTwB0uaDjK8Y8tQo110Ki 6yag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-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 s13si132250otr.94.2020.02.28.23.14.58; Fri, 28 Feb 2020 23:15:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-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-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726525AbgB2HOz convert rfc822-to-8bit (ORCPT + 99 others); Sat, 29 Feb 2020 02:14:55 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:34044 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726170AbgB2HOz (ORCPT ); Sat, 29 Feb 2020 02:14:55 -0500 Received: from marcel-macpro.fritz.box (p4FEFC5A7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id D2995CED04; Sat, 29 Feb 2020 08:24:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: [PATCH v1] bluetooth: guard against controllers sending zero'd events From: Marcel Holtmann In-Reply-To: <20200228205146.161229-1-alainm@chromium.org> Date: Sat, 29 Feb 2020 08:14:54 +0100 Cc: linux-bluetooth@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <788439D3-E0CC-4CBA-99C2-0B9C3703B23D@holtmann.org> References: <20200228205146.161229-1-alainm@chromium.org> To: Alain Michaud X-Mailer: Apple Mail (2.3608.60.0.2.5) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Alain, > Some controllers have been observed to send zero'd events under some > conditions. This change guards against this condition as well as adding > a trace to facilitate diagnosability of this condition. can you include a trace for this as well please. > > Signed-off-by: Alain Michaud > --- > > net/bluetooth/hci_event.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c > index 591e7477e925..f865eddb8d69 100644 > --- a/net/bluetooth/hci_event.c > +++ b/net/bluetooth/hci_event.c > @@ -5868,7 +5868,8 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > u8 status = 0, event = hdr->evt, req_evt = 0; > u16 opcode = HCI_OP_NOP; > > - if (hdev->sent_cmd && bt_cb(hdev->sent_cmd)->hci.req_event == event) { > + if (hdev->sent_cmd && event && > + bt_cb(hdev->sent_cmd)->hci.req_event == event) { Why are you bothering to check for event here. Do we have requests set with hci_req.event == 0? > struct hci_command_hdr *cmd_hdr = (void *) hdev->sent_cmd->data; > opcode = __le16_to_cpu(cmd_hdr->opcode); > hci_req_cmd_complete(hdev, opcode, status, &req_complete, > @@ -5876,6 +5877,9 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > req_evt = event; > } > > + if (!event) > + BT_ERR("Received unexpected HCI Event 00000000"); > + We need to start using bt_dev_err if we want to do that. However in this case bt_dev_warn is better since we should be gracefully handling this anyway. Regards Marcel