lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 14 Mar 2014 01:49:01 +0100
From:	Sander Eikelenboom <linux@...elenboom.it>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"John W. Linville" <linville@...driver.com>,
	"David S. Miller" <davem@...emloft.net>,
	Marcel Holtmann <marcel@...tmann.org>
CC:	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Peter Hurley <peter@...leysoftware.com>,
	"bluez mailin list (linux-bluetooth@...r.kernel.org)" 
	<linux-bluetooth@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes


Tuesday, March 11, 2014, 4:14:38 PM, you wrote:

> Hi John,

>>> Since:
>>> - 3.14-RC6 has been cut
>>> - this regression is known and reported since the merge window
>>> - the fix (revert of 3 patches) is known for over a month now
>>> - but it's still not in mainline
>>> - my polite ping request from last week seems to have provoked exactly 0 (zero) response.
>>> 
>>> IT'S TIME TO CHIME SOME BELLS :-)
>>> 
>>> Hope that WILL be heard somewhere ...
>>> 
>>> --
>>> Sander
>>> 
>>> PS. on the informative side the 3 commits to be reverted are:
>>> 
>>> f86772af6a0f643d3e13eb3f4f9213ae0c333ee4 Bluetooth: Remove rfcomm_carrier_raised()
>>> 4a2fb3ecc7467c775b154813861f25a0ddc11aa0 Bluetooth: Always wait for a connection on RFCOMM open()
>>> e228b63390536f5b737056059a9a04ea016b1abf Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()
>> 
>> Gustavo, should I be expecting a pull request?

> you have all 3 reverts already in wireless-next as part of a larger RFCOMM change from Peter that we had to do to get this bug fixed. The whole series ended up as 24 patches and was way to late in the -rc stage. In addition we did not have enough exposure from people running that patch set. I did not wanted to end up in a ping-pong situation with apply + revert over and over again until we gave this some test exposure.

> I think it is pretty safe to revert these 3 patches from 3.14-rc6 since they broke more than they actually fixed. However everybody has to be aware of that the real fix only comes in 3.15 since the change unfortunately is large. As far as we can tell, only users of RFCOMM TTY are affected. All RFCOMM socket users are fine.

> So I do not know what the best way of getting these reverts merged. Gustavo has a tree ready for you to pull from. Or would it be better if they get cherry picked from wireless-next tree.

> Regards

> Marcel


<sarcasm on>
Is it just me .. or is this going at the speed of about a bluetooth connection ..
and probably missing the boot for 3.14 ? (for no good reason IMHO)
<sarcasm off>

(it was not in John's nor Dave's last pull request, although it seems to be reverted in the bluetooth tree now .. i didn't
see any formal pull request from that .. to get it even *starting* to traverse all the trees up to Linus ... )

--
Sander

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ