Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2962467pxb; Sun, 29 Aug 2021 08:52:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoNO6bfFifEpVFuayfOOW70LCCWC/ocRTTgyZAEygroemSjAp+s/7/OzdSSZnx3oMbQMNf X-Received: by 2002:a05:6402:16d1:: with SMTP id r17mr20145930edx.73.1630252366478; Sun, 29 Aug 2021 08:52:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1630252366; cv=pass; d=google.com; s=arc-20160816; b=FpS7PHho7YR/CIjRSDF5VTXPtwkMPxSH5A0QIsE3RduXi0PS+PuwMEVkXf44YJdC5K IUXPlq9lHIMTRxyX04e+etwnB2ddNdFI1ALOFg+yLgyAp1We55Erssa0Im5Q8zpA6sWS 6i6Pp2nJkR+NutmpjvyjKgnrCj94B2w3/EGYMNHG6uPOUDOfvKyNdGSsEHEm6k2+Cm8h fZieVYSFQ0jqPZtx0KmBdZWCw/mk4dnXjHum2BCSbUBr9bWUgkKKsgVsmaypEjYeErSQ 0Cnq60nftEIlAPh4J+xr7h2F+DE0UMyoNSswMf3q5RqFCjscb/T5gDqCw3SZwNiIuuIz Ubrw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=2si6XWMCbQPjqdTAIENbIuOFv95gcAwkago37fkP+Qo=; b=JYc92hH/tDYVrLKiU7aQQ++QCOAjViGD8EfdeC/ibPaJaZOndcdQ6ezlxcKk+tf19y Nf4w5esuyaKNYRb/5yrybuHSWBfspkoycPlWI2eRzGgUpCMIJUfWh0zoLlv4OUbWPuJt DwB4iymkBBmiYS0Knl3bs6VLClURCF/jjjp9xJ4cHagVLMlr8YU2/507wzdeA7grhXK0 pZAUtj1/zvBOsao6Hlmx8IRJ63HJiQUmJTIeED7hOEalW11KfSEFLesVlCHBpJC4hypp htWjl0a+dl/gndX+xZljNucxhWuxID0NcNfealHSd8l1oApCWxoSr0mzbN17RiArWQhp ++xQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@iki.fi header.s=lahtoruutu header.b=VXnAcE7D; arc=pass (i=1); spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g12si12616975edy.563.2021.08.29.08.51.56; Sun, 29 Aug 2021 08:52:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@iki.fi header.s=lahtoruutu header.b=VXnAcE7D; arc=pass (i=1); spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235709AbhH2PvM (ORCPT + 99 others); Sun, 29 Aug 2021 11:51:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235711AbhH2PvL (ORCPT ); Sun, 29 Aug 2021 11:51:11 -0400 Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20648C061575 for ; Sun, 29 Aug 2021 08:50:19 -0700 (PDT) Received: from monolith.lan (91-152-122-41.elisa-laajakaista.fi [91.152.122.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pav) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C5F341B00188; Sun, 29 Aug 2021 18:50:15 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1630252215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2si6XWMCbQPjqdTAIENbIuOFv95gcAwkago37fkP+Qo=; b=VXnAcE7DfbJNV4fzu+9CmBKRoOAiMyLlXPJHUFzp8fHh50WBQRUTta3Y3Ve/NqNXkSXxS2 kaw5hXHjRYSKbCsmygq5g0D+3l47fyOaLW7F2ScYkAxmQcTGiub+723XME88VQeDEz0ux+ PF6qzFxBEfHYMUOB/q3GHetDbqBtor/mQtX9c+9P8HZgisjnk1iBEKPx7LDXcZ9YTohGEZ InnQD64Ik6zV+AuBPWDI+EECn85rq9yTAZBSKlPzUvpA4XPeWqrw5m+TCqQ3nuK/3ajpUG lhjssPrZM0okoFri10FkHXFpikNIJfW6SHu5yit6kh2b+jd9+CFY/zZTLwXb/g== From: Pauli Virtanen To: linux-bluetooth@vger.kernel.org Cc: Pauli Virtanen Subject: [PATCH BlueZ 0/2] AVDTP SEID pool seems too small Date: Sun, 29 Aug 2021 18:50:10 +0300 Message-Id: <20210829155012.164880-1-pav@iki.fi> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1630252215; a=rsa-sha256; cv=none; b=J8buDMQZHQuJWfCJLAJops8WVIGsVlOeSV9Qocs7nGDdfQ/NtB/0EHJwjKg71N5mhGnSFO oXctvVoA28n913E0ZyQ6vAnQE6E3nJDltVdO3AXr8mHNa+EEIvNwXULtzpo1W28tNzbwU+ uEOTT29/NIJNmpagjE6Wglx4WKfrXuOLFCBmJz0BcgEa81rVX9Yp/nje/a4GnnBZ+6UZVw 9WFfSQECAzb7W6j4Ij0jj+18D6nAWfaFU/3qCcHpsq4XQlBqnQXHRDOuMrZ6MbjsYrvX3P h5bsKtdRx/FpqdEBJ9ViAIWOrcul/ma6oZec0TJjYz+k4KG8pNckdtrilxvedw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1630252215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2si6XWMCbQPjqdTAIENbIuOFv95gcAwkago37fkP+Qo=; b=DOtZDGlJM6DZl7mlvB2CLEVZmXzXfEoTIgqFCmoIW07UZACM6mMKfGAo4vi+IzYQrLBzRW Prm3r9V6mysjWN7z6WpiV5JENpvJTKaMq/Mpjqgs/XvQRCezD7vc9pkLldM49veZwirouz sSyCraUWJ5yxBU9sl15wDdoRdD6ak8IGYSPQ0vi8hzcZ6X9Z20+HcuGBWmOM6xbaCDia+J NhfK5Qq68iSkoHjw9wB78hbX3NszcCGYSjaBripXCtNpfcb49zveNIChoWsqYhG6MCYx9x rw9knkuvMAEtId6U+42YwnMVHLTQGdR0jFX+qcBXOLCDBI84gEwhuKG6x0HGWw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=pav smtp.mailfrom=pav@iki.fi Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi, It seems that if media application is registered to multiple BT adapters, BlueZ can easily run out of free AVDTP SEIDs. This occurs in practice when running Pipewire (or Pulseaudio) and plugging in 3+ adapters: their media application has 10+ SEPs for various vendor A2DP codecs, registered for each adapter. After having registered 32 SEPs across all adapters, Media1.RegisterApplication starts failing, due to SEP registration not finding free SEIDs. However, if I understand the AVDTP spec and BlueZ implementation correctly, this behavior is not quite correct: (i) the SEID pool in BlueZ is limited to 8*sizeof(int) == 32 entries, which is smaller than the 0x3E = 62 entries (AVDTP1.3, 8.20.1). Also, (ii) BlueZ allocates SEIDs from a pool shared by all adapters, whereas it seems they should be device & connection local (AVDTP1.3, 4.10). Since adapters are separate devices in this context, this then appears to imply that each should have separate SEID pool. If this interpretation is right (I don't know the AVDTP spec very well, so...), here are two patches that address this. In (limited) tests this seemed to work. Pauli Virtanen (2): shared/util: use 64-bit bitmap in util_get/clear_uid avdtp: use separate local SEID pool for each adapter android/avdtp.c | 2 +- profiles/audio/a2dp.c | 2 +- profiles/audio/avdtp.c | 55 ++++++++++++++++++++++++++++++++++++------ profiles/audio/avdtp.h | 4 ++- src/advertising.c | 2 +- src/shared/util.c | 27 ++++++++++++--------- src/shared/util.h | 4 +-- unit/test-avdtp.c | 2 +- 8 files changed, 71 insertions(+), 27 deletions(-) -- 2.31.1