[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <316ACAE4-B98C-4396-8121-DCFC20BEC448@holtmann.org>
Date: Fri, 14 Feb 2014 13:45:49 -0800
From: Marcel Holtmann <marcel@...tmann.org>
To: Peter Hurley <peter@...leysoftware.com>
Cc: "Gustavo F. Padovan" <gustavo@...ovan.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Gianluca Anzolin <gianluca@...tospazio.it>,
Alexander Holler <holler@...oftware.de>,
Andrey Vihrov <andrey.vihrov@...il.com>,
Sander Eikelenboom <linux@...elenboom.it>,
"bluez mailin list (linux-bluetooth@...r.kernel.org)"
<linux-bluetooth@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/24] rfcomm fixes
Hi Peter,
> This patch series addresses a number of previously unknown issues
> with the RFCOMM tty device implementation, in addition to
> addressing the locking regression recently reported [1].
>
> As Gianluca suggested and I agree, this series first reverts
> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
>
> The reasoning is detailed in the changelog for
> Revert "Bluetooth: Always wait for a connection on RFCOMM open()"
> but the short answer is that it re-implements a long-standing
> bug by blocking on a non-blocking open.
>
> This patch series corrects the reported regressions from 3.13
> (to the extent that correction is required). Specifically,
> the ModemManager regression reported by Gianluca Anzolin [2]
> and the rfcomm bind with wvdial reported by Andrey Vihrov [3].
>
> tty: Fix ref counting for port krefs
> Bluetooth: Fix racy acquire of rfcomm_dev reference
> Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctl
> Bluetooth: Release rfcomm_dev only once
> Bluetooth: Fix unreleased rfcomm_dev reference
> These first 5 patches after the reverts
> fix 4 different rfcomm_dev ref count mishandling bugs.
>
> Bluetooth: Fix RFCOMM tty teardown race and
> Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls
> Fix races which occur due to the design of the rfcomm ioctls
> (note that buses don't have these kinds of races).
>
> Bluetooth: Verify dlci not in use before rfcomm_dev create
> Bluetooth: Simplify RFCOMM session state eval
> Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()
> Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()
> Bluetooth: Directly close dlc for not yet started RFCOMM session
> These 5 patches fix issues with reusing the dlci after
> closing the tty (found by unit test).
>
> Bluetooth: Fix unsafe RFCOMM device parenting
> Bluetooth: Fix RFCOMM parent device for reused dlc
> These 2 patches fix the ModemManager regression.
>
> Bluetooth: Refactor rfcomm_dev_add()
> Bluetooth: Cleanup RFCOMM device registration error handling
> These 2 patches fix an unreleased module reference while
> error handling.
>
> Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()
> This is a trivial naming patch with no functional impact.
>
> Bluetooth: Force -EIO from tty read/write if .activate() fails
> The tty core provides an existing mechanism for failing
> reads/writes if device activation fails (like an error
> allocating the dlc).
>
> Bluetooth: Don't fail RFCOMM tty writes
> This patch implements buffered writes even if the device
> is not connected.
>
> While unit testing this, I discovered a serious defect in
> the way available space is computed that under-utilizes
> rfcomm i/o and may even halt further tx on that link, which
> is fixed by:
> Bluetooth: Refactor write_room() calculation
> Bluetooth: Fix write_room() calculation
>
>
> Note that this series does not fix the naively inefficient
> method of packetizing tty output; packetizing should be
> done on the krfcommd thread to take advantage of aggregating
> multiple tty writes into 1 or more packets. Look at any
> line-by-line console output to realize how under-utilized
> the rfcomm tty packeting is.
>
> [1] http://www.spinics.net/lists/linux-wireless/msg117818.html
> [2] http://www.spinics.net/lists/linux-bluetooth/msg42075.html
> [3] http://www.spinics.net/lists/linux-bluetooth/msg42057.html
>
>
> Regards,
>
>
> Peter Hurley (24):
> Revert "Bluetooth: Remove rfcomm_carrier_raised()"
> Revert "Bluetooth: Always wait for a connection on RFCOMM open()"
> Revert "Bluetooth: Move rfcomm_get_device() before
> rfcomm_dev_activate()”
these 3 patches are in bluetooth-next to give them extra testing. We will get them into 3.14-rc4 after an extra week of them being in linux-next.
> tty: Fix ref counting for port krefs
I am taking this one with Greg’s ack through bluetooth-next. Unless someone objects.
> Bluetooth: Fix racy acquire of rfcomm_dev reference
> Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctl
> Bluetooth: Release rfcomm_dev only once
> Bluetooth: Fix unreleased rfcomm_dev reference
> Bluetooth: Fix RFCOMM tty teardown race
> Bluetooth: Verify dlci not in use before rfcomm_dev create
> Bluetooth: Simplify RFCOMM session state eval
> Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()
> Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()
> Bluetooth: Directly close dlc for not yet started RFCOMM session
> Bluetooth: Fix unsafe RFCOMM device parenting
> Bluetooth: Fix RFCOMM parent device for reused dlc
> Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()
> Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls
> Bluetooth: Refactor rfcomm_dev_add()
> Bluetooth: Cleanup RFCOMM device registration error handling
> Bluetooth: Force -EIO from tty read/write if .activate() fails
> Bluetooth: Don't fail RFCOMM tty writes
> Bluetooth: Refactor write_room() calculation
> Bluetooth: Fix write_room() calculation
>
> include/linux/tty.h | 6 +-
> include/net/bluetooth/rfcomm.h | 9 +-
> net/bluetooth/rfcomm/core.c | 88 ++++++++++----
> net/bluetooth/rfcomm/tty.c | 262 ++++++++++++++++++++++-------------------
> 4 files changed, 223 insertions(+), 142 deletions(-)
all patches have been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists