Hi Johan, > We should let user space request the peer address also in the pending > connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user > space code that tries to do this and will fail without extending the set > of allowed states for the peer address information. > > This patch adds the two states to the allowed ones in the L2CAP and > RFCOMM sock_getname functions, thereby preventing ENOTCONN from being > returned. > > Reported-by: Andrzej Kaczmarek <andrzej.kaczmarek@xxxxxxxxx> > Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx> > Tested-by: Andrzej Kaczmarek <andrzej.kaczmarek@xxxxxxxxx> > --- > This was reported as a regression on its way to 3.15 so we should either > send an immediate pull with it for wireless-next or then have it go in > in the very first patch to the 3.15-rc kernels. > > net/bluetooth/l2cap_sock.c | 3 ++- > net/bluetooth/rfcomm/sock.c | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) patch has been applied to bluetooth-next tree. I also rebased the tree and inserted this patch just after the origin/for-upstream tag so that we can just move the tag forward and include this fix. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
