* Re: [PATCH 2/3] soc: qcom: smd: Remove standalone driver
From: Andy Gross @ 2017-03-22 21:53 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Eugene Krasnikov,
Kalle Valo, David Brown, David S. Miller, Arnd Bergmann,
linux-bluetooth, linux-kernel, wcn36xx, linux-wireless, netdev,
linux-arm-msm, linux-soc
In-Reply-To: <20170320233544.1656-2-bjorn.andersson@linaro.org>
On Mon, Mar 20, 2017 at 04:35:43PM -0700, Bjorn Andersson wrote:
> Remove the standalone SMD implementation as we have transitioned the
> client drivers to use the RPMSG based one.
>
> Also remove all dependencies on QCOM_SMD from Kconfig files, in order to
> keep them selectable in the absence of the removed symbol.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* Re: [PATCH 3/3] soc: qcom: smd-rpm: Add msm8996 compatibility
From: Andy Gross @ 2017-03-22 21:54 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Eugene Krasnikov,
Kalle Valo, David Brown, David S. Miller, Arnd Bergmann,
linux-bluetooth, linux-kernel, wcn36xx, linux-wireless, netdev,
linux-arm-msm, linux-soc
In-Reply-To: <20170320233544.1656-3-bjorn.andersson@linaro.org>
On Mon, Mar 20, 2017 at 04:35:44PM -0700, Bjorn Andersson wrote:
> With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM
> driver ontop of GLINK for 8996, without any modifications.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Andy Gross @ 2017-03-22 21:56 UTC (permalink / raw)
To: David Miller
Cc: bjorn.andersson, marcel, gustavo, johan.hedberg, k.eugene.e,
kvalo, david.brown, arnd, linux-bluetooth, linux-kernel, wcn36xx,
linux-wireless, netdev, linux-arm-msm, linux-soc
In-Reply-To: <20170322.114439.679826829857326050.davem@davemloft.net>
On Wed, Mar 22, 2017 at 11:44:39AM -0700, David Miller wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> Date: Mon, 20 Mar 2017 16:35:42 -0700
>
> > By moving these client drivers to use RPMSG instead of the direct SMD
> > API we can reuse them ontop of the newly added GLINK wire-protocol
> > support found in the 820 and 835 Qualcomm platforms.
> >
> > As the new (RPMSG-based) and old SMD implementations are mutually
> > exclusive we have to change all client drivers in one commit, to make
> > sure we have a working system before and after this transition.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> > (https://lkml.org/lkml/2017/3/20/1038).
>
> Just some questions since I'm supposed to merge this into my net-next
> tree.
>
> What is the status of the Kconfig dependency fix and how will I be
> getting it?
>
> Second, should I merge all three of these patches to net-next or just
> this one?
David,
I ack'd all three. Please take these through your tree.
Bjorn,
Are we going to need an immutable branch or tag for sychronizing work?
Regards,
Andy Gross
^ permalink raw reply
* Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Bjorn Andersson @ 2017-03-22 21:57 UTC (permalink / raw)
To: David Miller
Cc: marcel, gustavo, johan.hedberg, k.eugene.e, kvalo, andy.gross,
david.brown, arnd, linux-bluetooth, linux-kernel, wcn36xx,
linux-wireless, netdev, linux-arm-msm, linux-soc
In-Reply-To: <20170322.114439.679826829857326050.davem@davemloft.net>
On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> Date: Mon, 20 Mar 2017 16:35:42 -0700
>
> > By moving these client drivers to use RPMSG instead of the direct SMD
> > API we can reuse them ontop of the newly added GLINK wire-protocol
> > support found in the 820 and 835 Qualcomm platforms.
> >
> > As the new (RPMSG-based) and old SMD implementations are mutually
> > exclusive we have to change all client drivers in one commit, to make
> > sure we have a working system before and after this transition.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> > (https://lkml.org/lkml/2017/3/20/1038).
>
> Just some questions since I'm supposed to merge this into my net-next
> tree.
>
> What is the status of the Kconfig dependency fix and how will I be
> getting it?
>
There are two Kconfig dependencies in play here, the first is
c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
picked up by Linus yesterday and will as such be in v4.10-rc4.
The other dependency, is the one Marcel wants you to pick up here is
https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
want I can resend it with you as direct recipient, with Marcel's ack.
Likely Arnd would like this fix to be sent upstream for v4.11 already.
> Second, should I merge all three of these patches to net-next or just
> this one?
>
I would like all three to be merged in this cycle and in addition I have
a couple of patches coming up that will cause some minor conflicts with
patch 2 - so I would prefer if patch 2 was available in a tag I can
merge into my tree.
Would it be possible for you to prepare merge all 4 (these 3 and the
bluetooth fix) and prepare a tag for Andy, Marcel and myself to include
in our trees?
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCHv2 09/11] Bluetooth: add nokia driver
From: Sebastian Reichel @ 2017-03-22 22:48 UTC (permalink / raw)
To: Rob Herring
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Samuel Thibault,
Pavel Machek, Tony Lindgren, Greg Kroah-Hartman, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+UXxocmpSJwJ8dVY0ZSLn1Rk+GfTRKP7Wqvo-_cE4qPg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
Hi,
On Wed, Mar 22, 2017 at 04:26:28PM -0500, Rob Herring wrote:
> On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > This adds a driver for the Nokia H4+ protocol, which is used
> > at least on the Nokia N9, N900 & N950.
> >
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
>
> > + btdev->wakeup_host = devm_gpiod_get(dev, "host-wakeup", GPIOD_IN);
> > + if (IS_ERR(btdev->wakeup_host)) {
> > + err = PTR_ERR(btdev->wakeup_host);
> > + dev_err(dev, "could not get host wakeup gpio: %d", err);
> > + return err;
> > + }
> > +
> > + btdev->wake_irq = gpiod_to_irq(btdev->wakeup_host);
>
> Missed this in the binding review, but generally, we make these
> interrupts rather than gpios in the binding.
I also read the state of the GPIO. AFAIK it's not possible to read
the state of an IRQ, so I can't switch to IRQ.
> > +
> > + err = devm_request_threaded_irq(dev, btdev->wake_irq, NULL,
> > + wakeup_handler,
> > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> > + "wakeup", btdev);
> > + if (err) {
> > + dev_err(dev, "could request wakeup irq: %d", err);
> > + return err;
> > + }
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHv2 10/11] ARM: dts: N900: Add bluetooth
From: Tony Lindgren @ 2017-03-22 23:55 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Samuel Thibault, Pavel Machek, Greg Kroah-Hartman,
Jiri Slaby, Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqLBNSWdbiO2A11c=BDWAKvWVGjOWafaNT+1OxoZgvH+fg@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [170322 14:09]:
> On Tue, Mar 21, 2017 at 5:32 PM, Sebastian Reichel <sre@kernel.org> wrote:
> > Add bcm2048 node and its system clock to the N900 device tree file.
> > Apart from that a reference to the new clock has been added to
> > wl1251 (which uses it, too).
> >
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> > Changes since PATCHv1:
> > - update compatible string
> > ---
> > arch/arm/boot/dts/omap3-n900.dts | 23 +++++++++++++++++++++--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
>
> Acked-by: Rob Herring <robh@kernel.org>
Picking patches 10 and 11 into omap-for-v4.12/dt-v2.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: David Miller @ 2017-03-23 2:23 UTC (permalink / raw)
To: marcel
Cc: bjorn.andersson, gustavo, johan.hedberg, k.eugene.e, kvalo,
andy.gross, david.brown, arnd, linux-bluetooth, linux-kernel,
wcn36xx, linux-wireless, netdev, linux-arm-msm, linux-soc
In-Reply-To: <21FCFC89-07EE-49EE-81C2-A138DD4C5F99@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Wed, 22 Mar 2017 20:23:15 +0100
> Hi Dave,
>
>>> By moving these client drivers to use RPMSG instead of the direct SMD
>>> API we can reuse them ontop of the newly added GLINK wire-protocol
>>> support found in the 820 and 835 Qualcomm platforms.
>>>
>>> As the new (RPMSG-based) and old SMD implementations are mutually
>>> exclusive we have to change all client drivers in one commit, to make
>>> sure we have a working system before and after this transition.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>> ---
>>>
>>> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
>>> (https://lkml.org/lkml/2017/3/20/1038).
>>
>> Just some questions since I'm supposed to merge this into my net-next
>> tree.
>>
>> What is the status of the Kconfig dependency fix and how will I be
>> getting it?
>
> I acked that one separately and added you:
>
> [PATCH v2] Bluetooth: btqcomsmd: fix compile-test dependency
I applied this to my 'net' tree, thanks.
^ permalink raw reply
* Re: [PATCHv2 09/11] Bluetooth: add nokia driver
From: Frédéric Danis @ 2017-03-23 7:50 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Rob Herring,
Samuel Thibault, Pavel Machek, Tony Lindgren, Greg Kroah-Hartman,
Jiri Slaby, Mark Rutland, linux-bluetooth, linux-serial,
devicetree, linux-kernel, frederic.danis.oss
In-Reply-To: <20170321223216.11733-10-sre@kernel.org>
Hello Sebastian,
Le 21/03/2017 à 23:32, Sebastian Reichel a écrit :
> This adds a driver for the Nokia H4+ protocol, which is used
> at least on the Nokia N9, N900 & N950.
>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
> Changes since PATCHv1:
> * replace __u8 and uint8_t with u8
> * replace __u16 and uint16_t with u16
> * drop BT_BAUDRATE_DIVIDER and use btdev->sysclk_speed * 10 instead
> * fix wording of a sentence
> * fix error path of negotation & alive package receive functions
> * replaced nokia_wait_for_cts with newly introduced serdev function
> * use "nokia,h4p-bluetooth" as compatible string
> ---
> drivers/bluetooth/Kconfig | 12 +
> drivers/bluetooth/Makefile | 2 +
> drivers/bluetooth/hci_nokia.c | 819 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 833 insertions(+)
> create mode 100644 drivers/bluetooth/hci_nokia.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index c2c14a12713b..2e3e4d3547ad 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -86,6 +86,18 @@ config BT_HCIUART_H4
>
> Say Y here to compile support for HCI UART (H4) protocol.
>
> +config BT_HCIUART_NOKIA
> + tristate "UART Nokia H4+ protocol support"
> + depends on BT_HCIUART
> + depends on SERIAL_DEV_BUS
> + depends on PM
> + help
> + Nokia H4+ is serial protocol for communication between Bluetooth
> + device and host. This protocol is required for Bluetooth devices
> + with UART interface in Nokia devices.
> +
> + Say Y here to compile support for Nokia's H4+ protocol.
> +
> config BT_HCIUART_BCSP
> bool "BCSP protocol support"
> depends on BT_HCIUART
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index fd571689eed6..a7f237320f4b 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -25,6 +25,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
> obj-$(CONFIG_BT_RTL) += btrtl.o
> obj-$(CONFIG_BT_QCA) += btqca.o
>
> +obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
> +
> btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
This does not build as module with following error:
ERROR: "hci_uart_tx_wakeup" [drivers/bluetooth/hci_nokia.ko] undefined!
ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko]
undefined!
Should not hci_nokia be part of the hci_uart module?
Regards,
Fred
^ permalink raw reply
* Re: [PATCHv2 09/11] Bluetooth: add nokia driver
From: Sebastian Reichel @ 2017-03-23 9:07 UTC (permalink / raw)
To: Frédéric Danis
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Rob Herring,
Samuel Thibault, Pavel Machek, Tony Lindgren, Greg Kroah-Hartman,
Jiri Slaby, Mark Rutland, linux-bluetooth, linux-serial,
devicetree, linux-kernel
In-Reply-To: <07cf4c22-b798-6e77-cca0-548e32e9de3f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
Hi,
On Thu, Mar 23, 2017 at 08:50:42AM +0100, Frédéric Danis wrote:
> Le 21/03/2017 à 23:32, Sebastian Reichel a écrit :
> > This adds a driver for the Nokia H4+ protocol, which is used
> > at least on the Nokia N9, N900 & N950.
> >
> > Signed-off-by: Sebastian Reichel <sre@kernel.org>
> > ---
> > Changes since PATCHv1:
> > * replace __u8 and uint8_t with u8
> > * replace __u16 and uint16_t with u16
> > * drop BT_BAUDRATE_DIVIDER and use btdev->sysclk_speed * 10 instead
> > * fix wording of a sentence
> > * fix error path of negotation & alive package receive functions
> > * replaced nokia_wait_for_cts with newly introduced serdev function
> > * use "nokia,h4p-bluetooth" as compatible string
> > ---
> > drivers/bluetooth/Kconfig | 12 +
> > drivers/bluetooth/Makefile | 2 +
> > drivers/bluetooth/hci_nokia.c | 819 ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 833 insertions(+)
> > create mode 100644 drivers/bluetooth/hci_nokia.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index c2c14a12713b..2e3e4d3547ad 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -86,6 +86,18 @@ config BT_HCIUART_H4
> > Say Y here to compile support for HCI UART (H4) protocol.
> > +config BT_HCIUART_NOKIA
> > + tristate "UART Nokia H4+ protocol support"
> > + depends on BT_HCIUART
> > + depends on SERIAL_DEV_BUS
> > + depends on PM
> > + help
> > + Nokia H4+ is serial protocol for communication between Bluetooth
> > + device and host. This protocol is required for Bluetooth devices
> > + with UART interface in Nokia devices.
> > +
> > + Say Y here to compile support for Nokia's H4+ protocol.
> > +
> > config BT_HCIUART_BCSP
> > bool "BCSP protocol support"
> > depends on BT_HCIUART
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index fd571689eed6..a7f237320f4b 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -25,6 +25,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
> > obj-$(CONFIG_BT_RTL) += btrtl.o
> > obj-$(CONFIG_BT_QCA) += btqca.o
> > +obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
> > +
> > btmrvl-y := btmrvl_main.o
> > btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>
> This does not build as module with following error:
> ERROR: "hci_uart_tx_wakeup" [drivers/bluetooth/hci_nokia.ko] undefined!
> ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko]
> undefined!
>
> Should not hci_nokia be part of the hci_uart module?
Yeah, I also received that from kbuild test robot after sending the
patchset. I intentionally did not add this to hci_uart, so that I can
use module_serdev_device_driver(). I think at least for serdev-only
based bluetooth drivers it makes sense to have them in their own module.
I already have added EXPORT_SYMBOL_GPL for those functions in the next
version of this patchset.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: David Miller @ 2017-03-23 23:56 UTC (permalink / raw)
To: bjorn.andersson
Cc: marcel, gustavo, johan.hedberg, k.eugene.e, kvalo, andy.gross,
david.brown, arnd, linux-bluetooth, linux-kernel, wcn36xx,
linux-wireless, netdev, linux-arm-msm, linux-soc
In-Reply-To: <20170322215733.GH20094@minitux>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Wed, 22 Mar 2017 14:57:33 -0700
> On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:
>
>> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Date: Mon, 20 Mar 2017 16:35:42 -0700
>>
>> What is the status of the Kconfig dependency fix and how will I be
>> getting it?
>>
>
> There are two Kconfig dependencies in play here, the first is
> c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
> picked up by Linus yesterday and will as such be in v4.10-rc4.
>
> The other dependency, is the one Marcel wants you to pick up here is
> https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
> want I can resend it with you as direct recipient, with Marcel's ack.
>
> Likely Arnd would like this fix to be sent upstream for v4.11 already.
>
>> Second, should I merge all three of these patches to net-next or just
>> this one?
>>
>
> I would like all three to be merged in this cycle and in addition I have
> a couple of patches coming up that will cause some minor conflicts with
> patch 2 - so I would prefer if patch 2 was available in a tag I can
> merge into my tree.
I should have all the dependencies in net-next now, but when I apply
this series I get undefined symbols:
[davem@localhost net-next]$ time make -s -j8
Kernel: arch/x86/boot/bzImage is ready (#578)
ERROR: "qcom_rpm_smd_write" [drivers/regulator/qcom_smd-regulator.ko] undefined!
ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
ERROR: "qcom_rpm_smd_write" [drivers/clk/qcom/clk-smd-rpm.ko] undefined!
ERROR: "qcom_wcnss_open_channel" [drivers/bluetooth/btqcomsmd.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
Please fix this up.
^ permalink raw reply
* Re: [PATCH V2 0/2] Avoid bt_accept_unlink() double unlinking
From: Dean Jenkins @ 2017-03-24 9:13 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Yichen Zhao, Gustavo F . Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <64b87b89-f4f5-e3c2-180b-c0efea70deee@mentor.com>
Hi Marcel,
On 13/03/17 16:19, Dean Jenkins wrote:
> Hi Marcel,
>
> On 10/03/17 11:34, Dean Jenkins wrote:
>> This is a patchset to manage a race condition between
>> bt_accept_dequeue() and
>> bt_accept_unlink() that leads to double unlinking resulting in a NULL
>> pointer
>> dereference crash.
>>
>> This issue has been highlighted in the following mailing list threads:
>>
>> http://www.spinics.net/lists/linux-bluetooth/msg67218.html
>> "[PATCH] Bluetooth: Fix l2cap_sock_teardown_cb race condition with
>> bt_accept_dequeue" by Yichen Zhao
>>
>> My old V1 patchset
>> https://www.spinics.net/lists/linux-bluetooth/msg69647.html
>> "L2CAP l2cap_sock_teardown_cb() race condition with RFCOMM
>> rfcomm_accept_connection()" by Dean Jenkins
>>
>> Follow-up by Yichen Zhao on my V1 patch 2/2
>> https://www.spinics.net/lists/linux-bluetooth/msg69839.html
>>
>>
>> Reproduction of crash
>> ---------------------
>>
>> On our commercial highly modified ARM kernel 3.14 a rare crash was seen:
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 0000013c
>> pgd = 80004000
>> [0000013c] *pgd=00000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> CPU: 1 PID: 1085 Comm: krfcommd Not tainted 3.14.51-03614-g82f0eab #1
>> [17685.267230] task: aaa5d080 ti: aabd0000 task.ti: aabd0000
>> PC is at bt_accept_unlink+0x34/0x78 [bluetooth]
>> LR is at bt_accept_dequeue+0x4c/0xe0 [bluetooth]
>> pc : [<7f37d1d0>] lr : [<7f37d260>] psr: 600d0013
>> sp : aabd1e20 ip : aabd1e30 fp : aabd1e2c
>> r10: b316f3bc r9 : aab39e00 r8 : af4135c0
>> r7 : aab39fc0 r6 : 9f81a600 r5 : b4786bc0 r4 : b4786a00
>> r3 : 0000013c r2 : b4786bc0 r1 : b4786bc0 r0 : b4786a00
>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
>> Control: 10c5387d Table: 388e404a DAC: 00000015
>> Process krfcommd (pid: 1085, stack limit = 0xaabd0238)
>> Backtrace:
>> [<7f37d19c>] (bt_accept_unlink [bluetooth]) from [<7f37d260>]
>> (bt_accept_dequeue+0x4c/0xe0 [bluetooth])
>> [<7f37d214>] (bt_accept_dequeue [bluetooth]) from [<7f39ed64>]
>> (l2cap_sock_accept+0x9c/0x14c [bluetooth])
>> [<7f39ecc8>] (l2cap_sock_accept [bluetooth]) from [<80441a90>]
>> (kernel_accept+0x54/0x94)
>> [<80441a3c>] (kernel_accept) from [<7f3d0934>]
>> (rfcomm_run+0x1d8/0x1088 [rfcomm])
>> [<7f3d075c>] (rfcomm_run [rfcomm]) from [<8004209c>]
>> (kthread+0xec/0x100)
>> [<80041fb0>] (kthread) from [<8000e1d0>] (ret_from_fork+0x14/0x24)
>> Code: e58031c0 e58031c4 e59031c8 e2833f4f (e1d320b0)
>> Kernel panic - not syncing: Fatal exception
>>
>> bt_accept_dequeue() is the victim of another thread calling
>> bt_accept_unlink()
>> which causes an attempt to double unlink the same sk and this crashes.
>>
>> The probability of failure can be increased by a adding a 1 second
>> msleep here:
>>
>> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
>> index cfb2fab..3d3772a 100644
>> --- a/net/bluetooth/af_bluetooth.c
>> +++ b/net/bluetooth/af_bluetooth.c
>> @@ -184,6 +184,8 @@ struct sock *bt_accept_dequeue(struct sock
>> *parent, struct socket *newsock)
>> list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q,
>> accept_q) {
>> sk = (struct sock *)s;
>> + /* increase probability of failure by sleeping */
>> + msleep(1000);
>> lock_sock(sk);
>> /* FIXME: Is this check still needed */
>>
>> The 1 second sleep is only for test purposes and it can be reduced to
>> say 275ms
>> and still trigger the crash. Therefore, the failure is hard to
>> reproduce without
>> adding some artificial manipulation of the timing of the threads.
>>
>> With the 1 second sleep test code in place, the kernel will crash
>> every-time
>> the PTS test suite runs testcase RFCOMM/DEVA-DEVB/RFC/BV-13C
>>
>> This testcase performs pairing then requests a RFCOMM connection with
>> the kernel
>> and establishes a RFCOMM connection. The test does a remote line
>> status exchange
>> then immediately drops the RF connection by doing a HCI RESET command
>> on the
>> testing equipment. No DISCs are seen on RFCOMM and no L2CAP channels are
>> requested to disconnect. In the kernel under test, this causes the
>> RFCOMM and
>> L2CAP layers to proceed to clean up but causes both RFCOMM and L2CAP
>> layers to
>> unlink the same sk which causes a NULL pointer crash in
>> bt_accept_unlink().
>>
>> For testing, the patches were ported on top of Linux 4.10.1 on a PC
>> with some
>> msleep debug added. The PTS testcase was run which showed that the
>> fix worked by
>> outputting the following debug in dmesg and no crash occurred:
>>
>> bt_accept_dequeue: sk ffff939d7fdac400, already unlinked
>>
>>
>> Description of issue
>> --------------------
>>
>> The issue is that bt_accept_dequeue() is not prevented from running
>> in parallel
>> with bt_accept_unlink(). There is sk locking, but this can cause the
>> list_for_each_entry_safe sk loop in bt_accept_dequeue() to wait for
>> the sk lock
>> to become available. If bt_accept_dequeue() waits and then wakes-up,
>> the sk
>> pointer can become stale because bt_accept_unlink() might of been
>> called by the
>> parallel thread.
>>
>> An alternative solution could be to lock the parent list as attempted by
>> Yichen Zhao's patch. However, this parent locking would need to be
>> applied in
>> all possible thread combinations of bt_accept_dequeue() and
>> bt_accept_unlink().
>> Also the parent locking may be conditional as sk may or may not be in
>> the parent
>> list at the time of deciding whether to apply the parent lock and
>> that is
>> undesirable as the code becomes complex.
>>
>> In addition, Yichen Zhao also pointed out in
>> https://www.spinics.net/lists/linux-bluetooth/msg69839.html
>> that list_for_each_entry_safe() is not thread safe. Yichen Zhao
>> described that
>> they had observed an infinite loop due to list_for_each_entry_safe()
>> being
>> intercepted by list_del_init() which caused sk to point to itself so
>> looped
>> forever.
>>
>> Therefore, avoid the crash by detecting an attempt at unlinking the
>> same sk
>> twice and restart the loop (introduced in V2 patch).
>>
>>
>> Solution
>> --------
>>
>> 1. Patch "Bluetooth: Handle bt_accept_enqueue() socket atomically"
>>
>> Ensure that the socket is in the parent list with the parent member
>> set. Do
>> this by adding sk locking in bt_accept_enqueue(). Therefore, it
>> should not be
>> possible to have a socket in the parent list with a NULL parent member.
>>
>> 2. Patch "Bluetooth: Avoid bt_accept_unlink() double unlinking"
>>
>> Add a defensive test into bt_accept_dequeue() to check that sk has a
>> non-NULL
>> parent member otherwise sk has already been unlinked so ignore this
>> now stale
>> sk pointer.
>>
>> In the V1 version of this patch the loop used "continue" after
>> detecting that sk
>> was no longer in the parent list. This potentially might get stuck in an
>> infinite loop.
>>
>> Therfore, the new V2 version of this patch restarts the loop when the
>> sk is
>> detected as not being in the parent list. This should avoid the possible
>> infinite loop as described by Yichen Zhao by refreshing the loop
>> variables to
>> take the latest values.
>>
>>
>> The following patches will apply cleanly to bluetooth-next master branch
>> with head commit:
>>
>> 8d70eeb Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>>
>>
>> Dean Jenkins (2):
>> Bluetooth: Handle bt_accept_enqueue() socket atomically
>> Bluetooth: Avoid bt_accept_unlink() double unlinking
>>
>> net/bluetooth/af_bluetooth.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>
> Did you see my V2 patchset ?
>
> Do you have any thoughts on taking or not taking my V2 patchset ?
>
> Thanks for your time.
>
> Regards,
> Dean
>
I expect you are very busy, but is there any chance of replying to me so
that I know my E-mails are getting to you ?
Thanks,
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: hci_bcm: Support platform enumeration
From: Andy Shevchenko @ 2017-03-26 12:28 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth
Cc: Jarkko Nikula
In-Reply-To: <20170310122820.7584-1-andriy.shevchenko@linux.intel.com>
On Fri, 2017-03-10 at 14:28 +0200, Andy Shevchenko wrote:
> Until now the driver supports only ACPI enumeration. Nevertheless
> Intel Edison SoM has Broadcom Wi-Fi + BT chip and neither ACPI nor DT
> enumeration mechanism.
>
> Enable pure platform driver in order to support Intel Edison SoM.
>
Any comment on this?
> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/bluetooth/hci_bcm.c | 50 ++++++++++++++++++++++++++++++----
> -----------
> 1 file changed, 33 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index 5262a2077d7a..a26a4ca6968b 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -697,28 +697,14 @@ static int bcm_resource(struct acpi_resource
> *ares, void *data)
> /* Always tell the ACPI core to skip this resource */
> return 1;
> }
> +#endif /* CONFIG_ACPI */
>
> -static int bcm_acpi_probe(struct bcm_device *dev)
> +static int bcm_platform_probe(struct bcm_device *dev)
> {
> struct platform_device *pdev = dev->pdev;
> - LIST_HEAD(resources);
> - const struct dmi_system_id *dmi_id;
> - const struct acpi_gpio_mapping *gpio_mapping =
> acpi_bcm_int_last_gpios;
> - const struct acpi_device_id *id;
> - int ret;
>
> dev->name = dev_name(&pdev->dev);
>
> - /* Retrieve GPIO data */
> - id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> &pdev->dev);
> - if (id)
> - gpio_mapping = (const struct acpi_gpio_mapping *) id-
> >driver_data;
> -
> - ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(&pdev->dev),
> - gpio_mapping);
> - if (ret)
> - return ret;
> -
> dev->clk = devm_clk_get(&pdev->dev, NULL);
>
> dev->device_wakeup = devm_gpiod_get_optional(&pdev->dev,
> @@ -755,6 +741,33 @@ static int bcm_acpi_probe(struct bcm_device *dev)
> return -EINVAL;
> }
>
> + return 0;
> +}
> +
> +#ifdef CONFIG_ACPI
> +static int bcm_acpi_probe(struct bcm_device *dev)
> +{
> + struct platform_device *pdev = dev->pdev;
> + LIST_HEAD(resources);
> + const struct dmi_system_id *dmi_id;
> + const struct acpi_gpio_mapping *gpio_mapping =
> acpi_bcm_int_last_gpios;
> + const struct acpi_device_id *id;
> + int ret;
> +
> + /* Retrieve GPIO data */
> + id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> &pdev->dev);
> + if (id)
> + gpio_mapping = (const struct acpi_gpio_mapping *) id-
> >driver_data;
> +
> + ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(&pdev->dev),
> + gpio_mapping);
> + if (ret)
> + return ret;
> +
> + ret = bcm_platform_probe(dev);
> + if (ret)
> + return ret;
> +
> /* Retrieve UART ACPI info */
> ret = acpi_dev_get_resources(ACPI_COMPANION(&dev->pdev->dev),
> &resources, bcm_resource, dev);
> @@ -789,7 +802,10 @@ static int bcm_probe(struct platform_device
> *pdev)
>
> dev->pdev = pdev;
>
> - ret = bcm_acpi_probe(dev);
> + if (has_acpi_companion(&pdev->dev))
> + ret = bcm_acpi_probe(dev);
> + else
> + ret = bcm_platform_probe(dev);
> if (ret)
> return ret;
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH BlueZ] src/adapter: Add the NULL check for response
From: hyuk0512 @ 2017-03-27 1:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lee Hyuk
In-Reply-To: <CGME20170327011830epcas5p448d6a1d19f613c5962d386546fe9ecf5@epcas5p4.samsung.com>
From: Lee Hyuk <hyuk0512.lee@samsung.com>
It is just bug fix.
Please review this.
Lee Hyuk (1):
src/adapter: Add the NULL check for response
src/adapter.c | 3 +++
1 file changed, 3 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH BlueZ] src/adapter: Add the NULL check for response
From: hyuk0512 @ 2017-03-27 1:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lee Hyuk
In-Reply-To: <1490577507-28351-1-git-send-email-hyuk0512@gmail.com>
From: Lee Hyuk <hyuk0512.lee@samsung.com>
The response can be NULL pointer. It should be checked.
---
src/adapter.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 3dac7d6..472b817 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1227,6 +1227,9 @@ static void passive_scanning_complete(uint8_t status, uint16_t length,
struct btd_adapter *adapter = user_data;
const struct mgmt_cp_start_discovery *rp = param;
+ if (!rp)
+ return;
+
DBG("status 0x%02x", status);
if (length < sizeof(*rp)) {
--
1.9.1
^ permalink raw reply related
* RE: Unexpected SMP Command 0x0a
From: Wong, Joshua Weng Onn @ 2017-03-27 3:35 UTC (permalink / raw)
To: marcel@holtmann.org; +Cc: Bluez mailing list, Wong, Mun choy, Zulqarnain, Adam
Hi Marcel,
Thank you for your reply. We are using the 4.1.x kernel as our group has pe=
rformed validation work on it and achieved 'Gold release' standard for our =
customers.
I have attached my logs during the LE pairing process at the end of this em=
ail. There are two logs namely master and slave device. Note that the logs =
I provided is for secure connections on.
The log I sent previously was ford secure connections turned off. Nonethele=
ss, the LE pairing fails on both settings i.e. when secured connections is =
turned on and when secured connections is turned off.
Also, I've realized that my title was wrong previously. I've updated it to =
reflect 0x0a instead of 0x17.
> Hi Joshua,
>=20
> > I am seeing an error during the LE pairing process which makes the pair=
ing to
> fail. I have two DUTs which uses the Marvell 88W8897.
> > Here are my BT settings for both master and slave:
> >
> > Master:
> > $ btmgmt info
> > current settings: powered connectable discoverable bondable ssp br/edr =
le
> secure-conn
> >
> > Slave:
> > $ btmgmt info
> > Current settings: powered connectable bondable le advertising secure-co=
nn
> >
> > When I initiate the pairing process from the master, I observed the mes=
sage:
> > "Bluetooth: hci0 unexpected SMP command 0x0a from 74:c6:3b:ab:68:ea"
> >
> > Where 74:c6:3b:ab:68:ea is the address of the slave device.
> >
> > In the btmon log of the master device, it is observed that after the Sl=
ave device
> has transmitted the keys, the Master does not transmit it. Hence, the Sla=
ve is not
> receiving the keys and thus disconnects the link and pairing is failed.
> >
> >> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0]
> 124.801098
> > SMP: Encryption Information (0x06) len 16
> > Long term key: 9ac691e96e85e82ca68f4b6d2abec80f
> >> HCI Event: Encryption Change (0x08) plen 4 =
[hci0]
> 124.801261
> > Status: Success (0x00)
> > Handle: 128
> > Encryption: Enabled with AES-CCM (0x01)
> >> ACL Data RX: Handle 128 flags 0x02 dlen 15 =
[hci0]
> 124.812761
> > SMP: Master Identification (0x07) len 10
> > EDIV: 0xea3f
> > Rand: 0x806e542a78f55d7c
> >> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0]
> 124.812782
> > SMP: Signing Information (0x0a) len 16
> > Signature key: 4451b8ae0eff90f0a47fb96be53479fb
> >> HCI Event: Disconnect Complete (0x05) plen 4 =
[hci0]
> 154.839591
> > Status: Success (0x00)
> > Handle: 128
> > Reason: Remote User Terminated Connection (0x13)
> >
> > =3D> At this point, Master should start sending LTK to slave, but Maste=
r doesn't
> send the LTK so Slave disconnects the link and pairing is failed.
> >
> > What could possibly cause the master to not send the LTK? My kernel ver=
sion
> is v4.1.27 and bluez stack is v5.40. I would appreciate advice on this.
>=20
> if this is LE Secure Connections, then the LTK is no longer distributed. =
It is being
> calculated from ECDH. Please include the complete SMP exchanges. Only the=
n
> we can see what is going on.
>=20
> Also keep in mind that 4.1.x kernels are actually rather old. The latest =
one is
> 4.10.x and if there is a bug, you should verify that it also happens with=
the latest
> kernel.
>=20
> Regards
>=20
> Marcel
btmon log of master device:
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 =
[hci0] 752.498799
Scan interval: 60.000 msec (0x0060)
Scan window: 30.000 msec (0x0030)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: 74:C6:3B:AB:68:EA (OUI 74-C6-3B)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0x0000
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 =
[hci0] 752.505320
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 =
[hci0] 753.061210
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 128
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: 74:C6:3B:AB:68:EA (OUI 74-C6-3B)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x01
@ Device Connected: 74:C6:3B:AB:68:EA (1) flags 0x0000
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2 =
[hci0] 753.063118
Handle: 128
> HCI Event: Command Status (0x0f) plen 4 =
[hci0] 753.068964
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 =
[hci0] 753.249205
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 128
Features: 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LL Privacy
< ACL Data TX: Handle 128 flags 0x00 dlen 11 =
[hci0] 753.250193
SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
Max encryption key size: 16
Initiator key distribution: EncKey Sign LinkKey (0x0d)
Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)
< ACL Data TX: Handle 128 flags 0x00 dlen 7 =
[hci0] 753.262956
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> ACL Data RX: Handle 128 flags 0x02 dlen 7 =
[hci0] 753.315441
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.315718
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 7 =
[hci0] 753.316060
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.316008
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 11 =
[hci0] 753.382935
SMP: Pairing Response (0x02) len 6
IO capability: DisplayYesNo (0x01)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
Max encryption key size: 16
Initiator key distribution: EncKey Sign (0x05)
Responder key distribution: EncKey Sign (0x05)
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.383085
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 =
[hci0] 753.383401
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
< ACL Data TX: Handle 128 flags 0x00 dlen 69 =
[hci0] 753.385376
SMP: Pairing Public Key (0x0c) len 64
X: 17780eede45fb83689cabb6803f5f0de1da6cfe3d51a3cf5553eafb94910c5b5
Y: 85e0b332945e7190afd622a1fdd5aa5d365722319a25fc8d7d860d02dc60b4af
< ACL Data TX: Handle 128 flags 0x00 dlen 11 =
[hci0] 753.385625
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 128 flags 0x02 dlen 11 =
[hci0] 753.451682
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.451999
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 18 =
[hci0] 753.452165
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.452420
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.518890
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 69 =
[hci0] 753.518986
SMP: Pairing Public Key (0x0c) len 64
X: 1da0aaa663fe5fd9da217d0da76c3ee298ba52150bbf2785fddd38f464faef84
Y: 8f378562b6e025f2e2dc4e1e05e501f599f4bb63efde8c46cc98a12cf8cc16f5
> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0] 753.519023
SMP: Pairing Confirm (0x03) len 16
Confim value: 906ada103cf5a740c67a316e15c5e133
> ACL Data RX: Handle 128 flags 0x02 dlen 18 =
[hci0] 753.519487
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
< ACL Data TX: Handle 128 flags 0x00 dlen 21 =
[hci0] 753.523611
SMP: Pairing Random (0x04) len 16
Random value: 52bd97adce116ec51777d770ac159c35
< ACL Data TX: Handle 128 flags 0x00 dlen 11 =
[hci0] 753.524480
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000a-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 128 flags 0x02 dlen 11 =
[hci0] 753.586528
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000a-0xffff
Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.586580
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.586824
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 9 =
[hci0] 753.586903
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0] 753.652953
SMP: Pairing Random (0x04) len 16
Random value: e7af794cd9f6401a29aaedc8fac8db18
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.653123
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 9 =
[hci0] 753.653417
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
@ User Confirmation Request: 74:C6:3B:AB:68:EA (1) hint 0 value 706962
< ACL Data TX: Handle 128 flags 0x00 dlen 9 =
[hci0] 753.685954
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.720303
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 5 =
[hci0] 753.856549
ATT: Write Response (0x13) len 0
> ACL Data RX: Handle 128 flags 0x02 dlen 9 =
[hci0] 753.856852
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
< ACL Data TX: Handle 128 flags 0x00 dlen 5 =
[hci0] 753.857115
ATT: Write Response (0x13) len 0
< ACL Data TX: Handle 128 flags 0x00 dlen 7 =
[hci0] 753.857138
ATT: Read Request (0x0a) len 2
Handle: 0x0003
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.922945
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 753.923257
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 =
[hci0] 753.991563
ATT: Read Request (0x0a) len 2
Handle: 0x0003
> ACL Data RX: Handle 128 flags 0x02 dlen 10 =
[hci0] 753.991866
ATT: Read Response (0x0b) len 5
Value: 426c75655a
< ACL Data TX: Handle 128 flags 0x00 dlen 12 =
[hci0] 753.992217
ATT: Read Response (0x0b) len 7
Value: 67697261666665
< ACL Data TX: Handle 128 flags 0x00 dlen 7 =
[hci0] 753.992256
ATT: Read Request (0x0a) len 2
Handle: 0x0005
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 754.057946
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 754.058278
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 =
[hci0] 754.126628
ATT: Read Response (0x0b) len 2
Value: 0000
> ACL Data RX: Handle 128 flags 0x02 dlen 7 =
[hci0] 754.126945
ATT: Read Request (0x0a) len 2
Handle: 0x0005
< ACL Data TX: Handle 128 flags 0x00 dlen 7 =
[hci0] 754.127655
ATT: Read Response (0x0b) len 2
Value: 1001
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 754.192985
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 21 =
[hci0] 760.114731
SMP: Pairing DHKey Check (0x0d) len 16
E: f3373b60ba9063449ebef0f3dd7d9781
> HCI Event: Number of Completed Packets (0x13) plen 5 =
[hci0] 760.132942
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0] 760.200373
SMP: Pairing DHKey Check (0x0d) len 16
E: 975be5ee4a205e1ac4811baa970abf10
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28 =
[hci0] 760.200595
Handle: 128
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 7ee01e3f27750b9393533941a4f3e198
> HCI Event: Command Status (0x0f) plen 4 =
[hci0] 760.206677
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> ACL Data RX: Handle 128 flags 0x02 dlen 21 =
[hci0] 760.470529
SMP: Signing Information (0x0a) len 16
Signature key: 1866336f92238bf953611245b7ad51f7
> HCI Event: Encryption Change (0x08) plen 4 =
[hci0] 760.470733
Status: Success (0x00)
Handle: 128
Encryption: Enabled with AES-CCM (0x01)
> HCI Event: Disconnect Complete (0x05) plen 4 =
[hci0] 790.576443
Status: Success (0x00)
Handle: 128
Reason: Remote User Terminated Connection (0x13)
@ Device Disconnected: 74:C6:3B:AB:68:EA (1) reason 3
btmon log of slave device:
> HCI Event: LE Meta Event (0x3e) plen 19 [hci0] 201.87=
5863
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 128
Role: Slave (0x01)
Peer address type: Public (0x00)
Peer address: 74:C6:3B:AB:68:E0 (OUI 74-C6-3B)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0.00 msec (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x01
@ Device Connected: 74:C6:3B:AB:68:E0 (1) flags 0x0000
< HCI Command: LE Read Remote Used Fe.. (0x08|0x0016) plen 2 [hci0] 201.87=
7629
Handle: 128
> HCI Event: Command Status (0x0f) plen 4 [hci0] 201.88=
4437
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 [hci0] 202.06=
3367
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 128
Features: 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LL Privacy
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 202.07=
6740
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> ACL Data RX: Handle 128 flags 0x02 dlen 11 [hci0] 202.13=
0925
SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
Max encryption key size: 16
Initiator key distribution: EncKey Sign LinkKey (0x0d)
Responder key distribution: EncKey IdKey Sign LinkKey (0x0f)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.13=
1213
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 [hci0] 202.13=
1481
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
< ACL Data TX: Handle 128 flags 0x00 dlen 11 [hci0] 202.13=
1616
SMP: Pairing Response (0x02) len 6
IO capability: DisplayYesNo (0x01)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
Max encryption key size: 16
Initiator key distribution: EncKey Sign (0x05)
Responder key distribution: EncKey Sign (0x05)
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 202.13=
2157
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
> ACL Data RX: Handle 128 flags 0x02 dlen 7 [hci0] 202.19=
8437
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.19=
8721
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 11 [hci0] 202.19=
9227
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.26=
4636
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.26=
5101
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 69 [hci0] 202.26=
5382
SMP: Pairing Public Key (0x0c) len 64
X: 17780eede45fb83689cabb6803f5f0de1da6cfe3d51a3cf5553eafb94910c5b5
Y: 85e0b332945e7190afd622a1fdd5aa5d365722319a25fc8d7d860d02dc60b4af
> ACL Data RX: Handle 128 flags 0x02 dlen 11 [hci0] 202.26=
5849
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 128 flags 0x00 dlen 69 [hci0] 202.28=
1447
SMP: Pairing Public Key (0x0c) len 64
X: 1da0aaa663fe5fd9da217d0da76c3ee298ba52150bbf2785fddd38f464faef84
Y: 8f378562b6e025f2e2dc4e1e05e501f599f4bb63efde8c46cc98a12cf8cc16f5
< ACL Data TX: Handle 128 flags 0x00 dlen 21 [hci0] 202.28=
1508
SMP: Pairing Confirm (0x03) len 16
Confim value: 906ada103cf5a740c67a316e15c5e133
< ACL Data TX: Handle 128 flags 0x00 dlen 18 [hci0] 202.28=
1958
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
> ACL Data RX: Handle 128 flags 0x02 dlen 18 [hci0] 202.33=
4680
ATT: Read By Group Type Response (0x11) len 13
Attribute data length: 6
Attribute group list: 2 entries
Handle range: 0x0001-0x0005
UUID: Generic Access Profile (0x1800)
Handle range: 0x0006-0x0009
UUID: Generic Attribute Profile (0x1801)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.33=
4962
Num handles: 1
Handle: 128
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.33=
5273
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 11 [hci0] 202.33=
5631
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000a-0xffff
Attribute group type: Primary Service (0x2800)
> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 202.39=
9670
SMP: Pairing Random (0x04) len 16
Random value: 52bd97adce116ec51777d770ac159c35
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.39=
9938
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 21 [hci0] 202.39=
9986
SMP: Pairing Random (0x04) len 16
Random value: e7af794cd9f6401a29aaedc8fac8db18
> ACL Data RX: Handle 128 flags 0x02 dlen 11 [hci0] 202.40=
0459
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x000a-0xffff
Attribute group type: Primary Service (0x2800)
@ User Confirmation Request: 74:C6:3B:AB:68:E0 (1) hint 0 value 706962
< ACL Data TX: Handle 128 flags 0x00 dlen 9 [hci0] 202.40=
0956
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.40=
0898
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 9 [hci0] 202.46=
8436
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.46=
8638
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 9 [hci0] 202.53=
5940
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.53=
6128
Num handles: 1
Handle: 128
Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 5 [hci0] 202.59=
7986
ATT: Write Response (0x13) len 0
< ACL Data TX: Handle 128 flags 0x00 dlen 9 [hci0] 202.59=
8036
ATT: Write Request (0x12) len 4
Handle: 0x0009
Data: 0200
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.67=
0869
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 5 [hci0] 202.73=
7205
ATT: Write Response (0x13) len 0
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.73=
7378
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 [hci0] 202.73=
7672
ATT: Read Request (0x0a) len 2
Handle: 0x0003
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 202.73=
7767
ATT: Read Request (0x0a) len 2
Handle: 0x0003
< ACL Data TX: Handle 128 flags 0x00 dlen 10 [hci0] 202.73=
7914
ATT: Read Response (0x0b) len 5
Value: 426c75655a
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.80=
5865
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 12 [hci0] 202.87=
2207
ATT: Read Response (0x0b) len 7
Value: 67697261666665
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.87=
2429
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 [hci0] 202.87=
2742
ATT: Read Request (0x0a) len 2
Handle: 0x0005
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 202.87=
3489
ATT: Read Response (0x0b) len 2
Value: 0000
< ACL Data TX: Handle 128 flags 0x00 dlen 7 [hci0] 202.87=
3543
ATT: Read Request (0x0a) len 2
Handle: 0x0005
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 202.94=
0673
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 7 [hci0] 203.00=
9022
ATT: Read Response (0x0b) len 2
Value: 1001
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 203.00=
9069
Num handles: 1
Handle: 128
Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 208.94=
8405
SMP: Pairing DHKey Check (0x0d) len 16
E: f3373b60ba9063449ebef0f3dd7d9781
< ACL Data TX: Handle 128 flags 0x00 dlen 21 [hci0] 208.94=
8615
SMP: Pairing DHKey Check (0x0d) len 16
E: 975be5ee4a205e1ac4811baa970abf10
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 209.08=
3476
Num handles: 1
Handle: 128
Count: 1
> HCI Event: LE Meta Event (0x3e) plen 13 [hci0] 209.08=
3793
LE Long Term Key Request (0x05)
Handle: 128
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
< HCI Command: LE Long Term Key Requ.. (0x08|0x001a) plen 18 [hci0] 209.08=
3869
Handle: 128
Long term key: 7ee01e3f27750b9393533941a4f3e198
> HCI Event: Command Complete (0x0e) plen 6 [hci0] 209.08=
7194
LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
Status: Success (0x00)
Handle: 128
> HCI Event: Encryption Change (0x08) plen 4 [hci0] 209.21=
8486
Status: Success (0x00)
Handle: 128
Encryption: Enabled with AES-CCM (0x01)
< ACL Data TX: Handle 128 flags 0x00 dlen 21 [hci0] 209.21=
8733
SMP: Signing Information (0x0a) len 16
Signature key: 1866336f92238bf953611245b7ad51f7
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 209.35=
2241
Num handles: 1
Handle: 128
Count: 1
< HCI Command: Disconnect (0x01|0x0006) plen 3 [hci0] 239.26=
1952
Handle: 128
Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4 [hci0] 239.26=
8876
Disconnect (0x01|0x0006) ncmd 1
Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 239.39=
2130
Status: Success (0x00)
Handle: 128
Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 74:C6:3B:AB:68:E0 (1) reason 2
Thank you.
Best regards,
Joshua
^ permalink raw reply
* Re: [PATCH BlueZ] src/adapter: Add the NULL check for response
From: Luiz Augusto von Dentz @ 2017-03-27 10:54 UTC (permalink / raw)
To: hyuk0512; +Cc: linux-bluetooth@vger.kernel.org, Lee Hyuk
In-Reply-To: <1490577507-28351-2-git-send-email-hyuk0512@gmail.com>
Hi,
On Mon, Mar 27, 2017 at 4:18 AM, <hyuk0512@gmail.com> wrote:
> From: Lee Hyuk <hyuk0512.lee@samsung.com>
>
> The response can be NULL pointer. It should be checked.
> ---
> src/adapter.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 3dac7d6..472b817 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -1227,6 +1227,9 @@ static void passive_scanning_complete(uint8_t status, uint16_t length,
> struct btd_adapter *adapter = user_data;
> const struct mgmt_cp_start_discovery *rp = param;
>
> + if (!rp)
> + return;
> +
> DBG("status 0x%02x", status);
>
> if (length < sizeof(*rp)) {
> --
> 1.9.1
It looks like you might have a broken kernel in this regard since
Start Discovery shall always return the parameters given and in case
it doesn't it is probably a nice thing to log an error.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Unexpected SMP Command 0x0a
From: Marcel Holtmann @ 2017-03-27 13:59 UTC (permalink / raw)
To: Wong, Joshua Weng Onn
Cc: Bluez mailing list, Wong, Mun choy, Zulqarnain, Adam
In-Reply-To: <E3B98393E6037849B63EA428240A6513607424@PGSMSX103.gar.corp.intel.com>
Hi Joshua,
please refrain from top posting on this mailing list.
> Thank you for your reply. We are using the 4.1.x kernel as our group has performed validation work on it and achieved 'Gold release' standard for our customers.
> I have attached my logs during the LE pairing process at the end of this email. There are two logs namely master and slave device. Note that the logs I provided is for secure connections on.
> The log I sent previously was ford secure connections turned off. Nonetheless, the LE pairing fails on both settings i.e. when secured connections is turned on and when secured connections is turned off.
So the pairing itself succeeds, but for some reason the mgmt command indicating its completion.
> < ACL Data TX: Handle 128 flags 0x00 dlen 21 [hci0] 760.114731
> SMP: Pairing DHKey Check (0x0d) len 16
> E: f3373b60ba9063449ebef0f3dd7d9781
>> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 760.132942
> Num handles: 1
> Handle: 128
> Count: 1
>> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 760.200373
> SMP: Pairing DHKey Check (0x0d) len 16
> E: 975be5ee4a205e1ac4811baa970abf10
> < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 [hci0] 760.200595
> Handle: 128
> Random number: 0x0000000000000000
> Encrypted diversifier: 0x0000
> Long term key: 7ee01e3f27750b9393533941a4f3e198
>> HCI Event: Command Status (0x0f) plen 4 [hci0] 760.206677
> LE Start Encryption (0x08|0x0019) ncmd 1
> Status: Success (0x00)
>> ACL Data RX: Handle 128 flags 0x02 dlen 21 [hci0] 760.470529
> SMP: Signing Information (0x0a) len 16
> Signature key: 1866336f92238bf953611245b7ad51f7
>> HCI Event: Encryption Change (0x08) plen 4 [hci0] 760.470733
> Status: Success (0x00)
> Handle: 128
> Encryption: Enabled with AES-CCM (0x01)
>> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 790.576443
> Status: Success (0x00)
> Handle: 128
> Reason: Remote User Terminated Connection (0x13)
> @ Device Disconnected: 74:C6:3B:AB:68:EA (1) reason 3
The pairing itself completes and the encryption gets enabled. Also the CSRK gets distributed (note LTK gets not distributed in the SC case).
What is missing here is that mgmt notifies user space about the new LTK and CSRK. However what I wonder is if the CSRK distribution might cause some issue since it is the only distributed material. I don’t think that I have seen that before.
Can this be reproduced with a 4.9 kernel?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: hci_bcm: Support platform enumeration
From: Marcel Holtmann @ 2017-03-27 14:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth, Jarkko Nikula
In-Reply-To: <20170310122820.7584-1-andriy.shevchenko@linux.intel.com>
Hi Andy,
> Until now the driver supports only ACPI enumeration. Nevertheless
> Intel Edison SoM has Broadcom Wi-Fi + BT chip and neither ACPI nor DT
> enumeration mechanism.
>
> Enable pure platform driver in order to support Intel Edison SoM.
explain to me what this the case. Didn’t we enabled also DT for Edison? And I assumed in general we planned to move away from platform drivers in favour of DT.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] btmrvl: fix spelling mistake: "unregester" -> "unregister"
From: Marcel Holtmann @ 2017-03-27 14:02 UTC (permalink / raw)
To: Colin King
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <20170321122028.16224-1-colin.king@canonical.com>
Hi Colin,
> trivial fix to spelling mistake in debug message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/bluetooth/btmrvl_sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 05/18] net, bluetooth: convert rfcomm_dlc.refcnt from atomic_t to refcount_t
From: Marcel Holtmann @ 2017-03-27 14:05 UTC (permalink / raw)
To: Elena Reshetova
Cc: Network Development, LKML, linux-decnet-user, David S. Miller,
James Morris, Patrick McHardy, Hideaki YOSHIFUJI,
Alexey Kuznetsov, 3chas3, ralf, stephen, jchapman, jhs, bridge,
linux-hams, linux-x25, linux-bluetooth, Johan Hedberg, peterz,
keescook, Hans Liljestrand, David Windsor
In-Reply-To: <1489749179-12063-6-git-send-email-elena.reshetova@intel.com>
Hi Elena,
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
> include/net/bluetooth/rfcomm.h | 8 +++++---
> net/bluetooth/rfcomm/core.c | 4 ++--
> 2 files changed, 7 insertions(+), 5 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm: Fix clock (un)prepare
From: Marcel Holtmann @ 2017-03-27 14:07 UTC (permalink / raw)
To: John Keeping
Cc: linux-bluetooth, linux-kernel, Gustavo F. Padovan, Johan Hedberg
In-Reply-To: <20170315122005.7702-2-john@metanate.com>
Hi John,
> The hci_bcm driver currently does not prepare/unprepare the clock and
> goes directly to enable, but as the documentation for clk_enable says,
> clk_prepare must be called before clk_enable.
>
> Signed-off-by: John Keeping <john@metanate.com>
> ---
> drivers/bluetooth/hci_bcm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: bluecard: use setup_timer
From: Marcel Holtmann @ 2017-03-27 14:11 UTC (permalink / raw)
To: Geliang Tang
Cc: Gustavo F. Padovan, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <e0af154c08327dbf266e641b135e4ef340913feb.1489061552.git.geliangtang@gmail.com>
Hi Geliang,
> Use setup_timer() instead of init_timer() to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> ---
> drivers/bluetooth/bluecard_cs.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v7 0/6] Bluetooth: 6LoWPAN: Fix lladdr length
From: Marcel Holtmann @ 2017-03-27 14:11 UTC (permalink / raw)
To: Luiz Augusto von Dentz, David S. Miller
Cc: linux-bluetooth, patrik.flykt, aar, jukka.rissanen, linux-wpan,
netdev
In-Reply-To: <20170312081938.11700-1-luiz.dentz@gmail.com>
Hi Luiz,
> These patches fixes lladdr length to be 6 bytes long and not 8 which cause
> neighbor advertisement to be sent with wrong lladdr including FF:FE filler
> bytes for eui64.
>
> Note: This does not fix some of the existing crashes which I hope to address
> in a different set.
>
> v2: Make all code paths that generate a link-local from lladdr use the same
> code.
> v3: Use lowpan_iphc_uncompress_eui48_lladdr to generate the remote ip address.
> v4: Handle comments from Stefan Schmidt.
> v5: Add patch to fix IID format for Bluetooth
> v6: Fix addrconf_ifid_eui48 to follow IID format for Bluetooth
> v7: Rework addrconf_ifid_6lowpan so it doesn't use addrconf_ifid_eui48
>
> Alexander Aring (2):
> 6lowpan: iphc: override l2 packet information
> ipv6: addrconf: fix 48 bit 6lowpan autoconfiguration
>
> Luiz Augusto von Dentz (2):
> 6lowpan: Use netdev addr_len to determine lladdr len
> 6lowpan: Fix IID format for Bluetooth
>
> Patrik Flykt (2):
> bluetooth: Set 6 byte device addresses
> 6lowpan: Set MAC address length according to LOWPAN_LLTYPE
>
> include/net/6lowpan.h | 15 ++++++
> net/6lowpan/core.c | 11 +++-
> net/6lowpan/iphc.c | 57 +++++++++++++++++----
> net/bluetooth/6lowpan.c | 130 ++++++++----------------------------------------
> net/ipv6/addrconf.c | 23 ++++++---
> 5 files changed, 109 insertions(+), 127 deletions(-)
all 6 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: Fix L2CAP_CR_SCID_IN_USE value
From: Marcel Holtmann @ 2017-03-27 14:13 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1488978581-9574-1-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> Fix issue found during L2CAP qualification test TP/LE/CFC/BV-20-C.
>
> Signed-off-by: Marcin Kraglak <marcin.kraglak@tieto.com>
> ---
> include/net/bluetooth/l2cap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH V2 0/2] Avoid bt_accept_unlink() double unlinking
From: Marcel Holtmann @ 2017-03-27 14:14 UTC (permalink / raw)
To: Dean Jenkins
Cc: Yichen Zhao, Gustavo F. Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1489145686-23077-1-git-send-email-Dean_Jenkins@mentor.com>
Hi Dean,
> This is a patchset to manage a race condition between bt_accept_dequeue() and
> bt_accept_unlink() that leads to double unlinking resulting in a NULL pointer
> dereference crash.
>
> This issue has been highlighted in the following mailing list threads:
>
> http://www.spinics.net/lists/linux-bluetooth/msg67218.html
> "[PATCH] Bluetooth: Fix l2cap_sock_teardown_cb race condition with
> bt_accept_dequeue" by Yichen Zhao
>
> My old V1 patchset
> https://www.spinics.net/lists/linux-bluetooth/msg69647.html
> "L2CAP l2cap_sock_teardown_cb() race condition with RFCOMM
> rfcomm_accept_connection()" by Dean Jenkins
>
> Follow-up by Yichen Zhao on my V1 patch 2/2
> https://www.spinics.net/lists/linux-bluetooth/msg69839.html
>
>
> Reproduction of crash
> ---------------------
>
> On our commercial highly modified ARM kernel 3.14 a rare crash was seen:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000013c
> pgd = 80004000
> [0000013c] *pgd=00000000
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> CPU: 1 PID: 1085 Comm: krfcommd Not tainted 3.14.51-03614-g82f0eab #1
> [17685.267230] task: aaa5d080 ti: aabd0000 task.ti: aabd0000
> PC is at bt_accept_unlink+0x34/0x78 [bluetooth]
> LR is at bt_accept_dequeue+0x4c/0xe0 [bluetooth]
> pc : [<7f37d1d0>] lr : [<7f37d260>] psr: 600d0013
> sp : aabd1e20 ip : aabd1e30 fp : aabd1e2c
> r10: b316f3bc r9 : aab39e00 r8 : af4135c0
> r7 : aab39fc0 r6 : 9f81a600 r5 : b4786bc0 r4 : b4786a00
> r3 : 0000013c r2 : b4786bc0 r1 : b4786bc0 r0 : b4786a00
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 388e404a DAC: 00000015
> Process krfcommd (pid: 1085, stack limit = 0xaabd0238)
> Backtrace:
> [<7f37d19c>] (bt_accept_unlink [bluetooth]) from [<7f37d260>] (bt_accept_dequeue+0x4c/0xe0 [bluetooth])
> [<7f37d214>] (bt_accept_dequeue [bluetooth]) from [<7f39ed64>] (l2cap_sock_accept+0x9c/0x14c [bluetooth])
> [<7f39ecc8>] (l2cap_sock_accept [bluetooth]) from [<80441a90>] (kernel_accept+0x54/0x94)
> [<80441a3c>] (kernel_accept) from [<7f3d0934>] (rfcomm_run+0x1d8/0x1088 [rfcomm])
> [<7f3d075c>] (rfcomm_run [rfcomm]) from [<8004209c>] (kthread+0xec/0x100)
> [<80041fb0>] (kthread) from [<8000e1d0>] (ret_from_fork+0x14/0x24)
> Code: e58031c0 e58031c4 e59031c8 e2833f4f (e1d320b0)
> Kernel panic - not syncing: Fatal exception
>
> bt_accept_dequeue() is the victim of another thread calling bt_accept_unlink()
> which causes an attempt to double unlink the same sk and this crashes.
>
> The probability of failure can be increased by a adding a 1 second msleep here:
>
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> index cfb2fab..3d3772a 100644
> --- a/net/bluetooth/af_bluetooth.c
> +++ b/net/bluetooth/af_bluetooth.c
> @@ -184,6 +184,8 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
> list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
> sk = (struct sock *)s;
>
> + /* increase probability of failure by sleeping */
> + msleep(1000);
> lock_sock(sk);
>
> /* FIXME: Is this check still needed */
>
> The 1 second sleep is only for test purposes and it can be reduced to say 275ms
> and still trigger the crash. Therefore, the failure is hard to reproduce without
> adding some artificial manipulation of the timing of the threads.
>
> With the 1 second sleep test code in place, the kernel will crash every-time
> the PTS test suite runs testcase RFCOMM/DEVA-DEVB/RFC/BV-13C
>
> This testcase performs pairing then requests a RFCOMM connection with the kernel
> and establishes a RFCOMM connection. The test does a remote line status exchange
> then immediately drops the RF connection by doing a HCI RESET command on the
> testing equipment. No DISCs are seen on RFCOMM and no L2CAP channels are
> requested to disconnect. In the kernel under test, this causes the RFCOMM and
> L2CAP layers to proceed to clean up but causes both RFCOMM and L2CAP layers to
> unlink the same sk which causes a NULL pointer crash in bt_accept_unlink().
>
> For testing, the patches were ported on top of Linux 4.10.1 on a PC with some
> msleep debug added. The PTS testcase was run which showed that the fix worked by
> outputting the following debug in dmesg and no crash occurred:
>
> bt_accept_dequeue: sk ffff939d7fdac400, already unlinked
>
>
> Description of issue
> --------------------
>
> The issue is that bt_accept_dequeue() is not prevented from running in parallel
> with bt_accept_unlink(). There is sk locking, but this can cause the
> list_for_each_entry_safe sk loop in bt_accept_dequeue() to wait for the sk lock
> to become available. If bt_accept_dequeue() waits and then wakes-up, the sk
> pointer can become stale because bt_accept_unlink() might of been called by the
> parallel thread.
>
> An alternative solution could be to lock the parent list as attempted by
> Yichen Zhao's patch. However, this parent locking would need to be applied in
> all possible thread combinations of bt_accept_dequeue() and bt_accept_unlink().
> Also the parent locking may be conditional as sk may or may not be in the parent
> list at the time of deciding whether to apply the parent lock and that is
> undesirable as the code becomes complex.
>
> In addition, Yichen Zhao also pointed out in
> https://www.spinics.net/lists/linux-bluetooth/msg69839.html
> that list_for_each_entry_safe() is not thread safe. Yichen Zhao described that
> they had observed an infinite loop due to list_for_each_entry_safe() being
> intercepted by list_del_init() which caused sk to point to itself so looped
> forever.
>
> Therefore, avoid the crash by detecting an attempt at unlinking the same sk
> twice and restart the loop (introduced in V2 patch).
>
>
> Solution
> --------
>
> 1. Patch "Bluetooth: Handle bt_accept_enqueue() socket atomically"
>
> Ensure that the socket is in the parent list with the parent member set. Do
> this by adding sk locking in bt_accept_enqueue(). Therefore, it should not be
> possible to have a socket in the parent list with a NULL parent member.
>
> 2. Patch "Bluetooth: Avoid bt_accept_unlink() double unlinking"
>
> Add a defensive test into bt_accept_dequeue() to check that sk has a non-NULL
> parent member otherwise sk has already been unlinked so ignore this now stale
> sk pointer.
>
> In the V1 version of this patch the loop used "continue" after detecting that sk
> was no longer in the parent list. This potentially might get stuck in an
> infinite loop.
>
> Therfore, the new V2 version of this patch restarts the loop when the sk is
> detected as not being in the parent list. This should avoid the possible
> infinite loop as described by Yichen Zhao by refreshing the loop variables to
> take the latest values.
>
>
> The following patches will apply cleanly to bluetooth-next master branch
> with head commit:
>
> 8d70eeb Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
>
> Dean Jenkins (2):
> Bluetooth: Handle bt_accept_enqueue() socket atomically
> Bluetooth: Avoid bt_accept_unlink() double unlinking
>
> net/bluetooth/af_bluetooth.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox