From nobody Mon Apr 6 14:57:32 2026 Received: from mail-dl1-f42.google.com (mail-dl1-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D7B9314A90 for ; Thu, 19 Mar 2026 04:23:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773894234; cv=none; b=tPfhcEbuhePRWLXjDKii1uLHieBM97nEkd5cZXpEZxZkIhQKqBcEP5uF5wx/yYiaVRNx6Hfztwosrw2j9BBbsBaavZ8o8naPva+z51tKwJMVBn+ey9bDcYqsM6l9ODSTdpXq72Fo6CFzgDYvLHI4hjF805UwIAxR4F+L2IT9u5s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773894234; c=relaxed/simple; bh=732FWN47KnJJGZ7cjdTpPeleb+eK+860yewRn8CzY1k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=UPyQU2EX6FNwbFpgygl5uE0vdIv63NUw9hDGLD0VJ52d8uj5epY0KGTZdCN5JrXoNDRk8M39FEmUndSOz8yQFy0Ws/hbv0JZPs0N2XyUp7KgH9WXHwXOLkh0GmykTearKwepLSfXJnz0Zun8JcMGD5FYYCwqBIceUGoHkFZsqGg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=T2ObG7na; arc=none smtp.client-ip=74.125.82.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="T2ObG7na" Received: by mail-dl1-f42.google.com with SMTP id a92af1059eb24-128d7db88b9so813376c88.0 for ; Wed, 18 Mar 2026 21:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773894232; x=1774499032; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=eIcKzwG6x118AH0uYawVORj0pRHsg/+p7rL0Vqj2QJo=; b=T2ObG7na6GEOPi4JIqD1n9HUAm4QigOF/t0ZKIcDRL4fvIbv6YPaKyISXiXVeiio9l vXKb4Ps3WbTClV3zusBhk+Sx19B97inUaxDz/nepnGWc4Y92ksfZrpMzGQZO7rEp9+EH O+ev1zZi7uuuDZUGyQiB9er4xU6G8rcuJu2C06wC/doy1W1XytmhDsgucSE1RO/R+yYg DUhG6ZsjfTtGojeyeydZHDdK4kDksvaYHKDR1yrvUI2FeVeqZL172+xfBRhzRtZuCcz5 /YVapxnyr+yAC5F45eWOmOozrMN3XkFroED10xkoYVRq4sXj40t4IBKx7r930YhaMTDE QA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773894232; x=1774499032; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eIcKzwG6x118AH0uYawVORj0pRHsg/+p7rL0Vqj2QJo=; b=rL10w0TJYtgLOtfpIPFTVVuOUeA1FgAT7PHQ4iC9TgQV+Ugu9RXbDqJ4tfBeMd5qNB FLMuNkiZ/XwsnO5Tqh1ASqLsaucEnjX71VHsqan/R9lF5HNF8KHMBoXlvkSd5ycYVC8+ 54pOR9WqMz+Dt+itB+S0aMLp4wbstz9a42NyoYpFvZzLBuUWJKMp9cj6bFUPFHuyjXhC 4ffR1XakpXiQwhRqDOmC9Sq/0nXGR5jLa/b0oDLm4V9faxW2wfw4QRZTBK6MUUryDZfZ d0pQYHis0wvmGylQHab2jX9dC4DIE7qKtpcYVg/d8CJDhTgoCyhhnQaz8KMU5ffBnl9b Y0Mw== X-Forwarded-Encrypted: i=1; AJvYcCV1jjITrIXAh8dSxeSb6xn06CfjQbeGqTjoB0gYwN1YarEvPVYTwGJeQlpQwTcKbkuOfrxLZ84c8ClhB3w=@vger.kernel.org X-Gm-Message-State: AOJu0Yyg5qqhFUdXrRjWTjWpz/Ou2uK98bPARTSkI+hgIkKl5mKIBuwj VjWxrJRdiduCr2KV4HDrMUW+un1eR+B3lVDxsuYcJthfGxM6fsvJnYda X-Gm-Gg: ATEYQzx7bhRTVWJWZPncUsHe4fEsfHBiAt6vYHwxd8KSbkNUYq8SuK4AJLILWgHwzNl MAesVD6SbHMcwFWs2zxxurUDNu052Veqj2BfqA4yWV9/RecTxlshzbgz7GzPsc/UO49hgoeseSe r9V4Y5JkbnNmisucxKHnNcYqTjCFkD6HcC/BW0VVTH85flS7QbAy0hA4TI+dZbdc0h8xYlJ3PQ/ 9/fmMiJ9pCGJNeSq2qOMqq6/3FvGH86cej4aFX6kUsTKD47TclcwNTLqHqXEeNA7OKJzxuzlsyQ Ero2y63cZdbtzgKmcvmW55UUOrb2xdISP7Qh2inOEjaZx11JvkhPBiXdnxNS4o193ETac3VxlE3 tpr8+L7SyhedtgEWwgrF6b4TGIoJmo4QFIQ34NNIIBiQtJO8xvppkUSOIkq5X9X4xGwhTMwGEJH B5DyXaoO2TjHclrKlI0y1i6PqtK+nlGmeV9kkxBNhWT/QWpzCF5rwiUEBdpqmWO7D46AfURoG3c PdC X-Received: by 2002:a05:7022:60a2:b0:128:cf86:d1e5 with SMTP id a92af1059eb24-1299ba9f899mr3088225c88.16.1773894231330; Wed, 18 Mar 2026 21:23:51 -0700 (PDT) Received: from [192.168.1.18] (177-4-160-195.user3p.v-tal.net.br. [177.4.160.195]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-129b4127b7esm8401813c88.9.2026.03.18.21.23.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 21:23:50 -0700 (PDT) From: =?utf-8?q?C=C3=A1ssio_Gabriel?= Date: Thu, 19 Mar 2026 01:23:40 -0300 Subject: [PATCH] ALSA: pcm: reconstruct compat appl_ptr in SYNC_PTR ioctl Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260319-alsa-pcm-compat-syncptr-boundary-v1-1-ce2b2a61f167@gmail.com> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x3NwQrCMAyA4VcZORvoKurwVcRDTDMNuLYkmzjG3 t3i8bv8/wYupuJw7TYw+ahryQ39oQN+UX4KamqGGOI5HPsB6e2ElSfkMlWa0dfMdTZ8lCUnshV DOsUUxyHxRaBlqsmo3//idt/3H5lXMepyAAAA X-Change-ID: 20260318-alsa-pcm-compat-syncptr-boundary-0d52d2f8dc7e To: Takashi Iwai Cc: Jaroslav Kysela , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?C=C3=A1ssio_Gabriel?= X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3747; i=cassiogabrielcontato@gmail.com; h=from:subject:message-id; bh=732FWN47KnJJGZ7cjdTpPeleb+eK+860yewRn8CzY1k=; b=owGbwMvMwCV2IdZeKur/u2bG02pJDJm7q0JazQ08fFVU5z98amrLuJXX89/tL6/3OLx7fdBq5 YusAztVOkpZGMS4GGTFFFlWJy2y3NP14Gp93AoPmDmsTCBDGLg4BWAi7aEMf+VSfns8Srrh+3HK 0p8zH82x2vlsUvvffxMCTsda9enePbmK4X/YG6FjZZNcjizrPVkgvfjH8sMXkvYEOGtvLn5x9zG XwUZ+AA== X-Developer-Key: i=cassiogabrielcontato@gmail.com; a=openpgp; fpr=AB62A239BC8AE0D57F5EA848D05D3F1A5AFFEE83 The compat SYNC_PTR ioctl exposes appl_ptr and hw_ptr in a reduced 32-bit boundary domain. However, when compat user space passes appl_ptr back to the kernel, the value is currently fed to pcm_lib_apply_appl_ptr() as if it were already in the native runtime->boundary domain. This leaves the compat SYNC_PTR path asymmetric: appl_ptr is exported to compat user space modulo the compat boundary, but the value written back is not reconstructed in the native boundary domain before being applied. The mismatch becomes visible after appl_ptr wraps in the compat boundary. At that point, compat user space sends a small appl_ptr value again, but the kernel may interpret it as a different native appl_ptr position instead of the nearest congruent position around the current control->appl_ptr. Fix this by reconstructing the compat appl_ptr in the native runtime boundary before passing it to pcm_lib_apply_appl_ptr(). Signed-off-by: C=C3=A1ssio Gabriel --- sound/core/pcm_native.c | 50 +++++++++++++++++++++++++++++++++++++++++++++= ---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 674b50c7c5f6..f2e2854847ae 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3228,6 +3228,45 @@ static snd_pcm_uframes_t recalculate_boundary(struct= snd_pcm_runtime *runtime) return boundary / 2; } =20 +/* + * Reconstruct the nearest native appl_ptr for a compat appl_ptr + * value modulo compat_boundary. + */ +static snd_pcm_uframes_t +snd_pcm_compat_reconstruct_appl_ptr(struct snd_pcm_runtime *runtime, + snd_pcm_uframes_t compat_boundary, + u32 appl_ptr) +{ + snd_pcm_uframes_t cur =3D runtime->control->appl_ptr; + snd_pcm_sframes_t rel; /* relative offset */ + snd_pcm_sframes_t new_appl_ptr; + + if (!compat_boundary || compat_boundary >=3D runtime->boundary) + return appl_ptr; + + appl_ptr %=3D compat_boundary; + rel =3D (snd_pcm_sframes_t)appl_ptr - + (snd_pcm_sframes_t)(cur % compat_boundary); + + /* + * Pick the shortest relative distance in the compat ring so the + * reconstructed native appl_ptr stays nearest to the current + * position. + */ + if (rel > (snd_pcm_sframes_t)(compat_boundary / 2)) + rel -=3D compat_boundary; + else if (rel < -(snd_pcm_sframes_t)(compat_boundary / 2)) + rel +=3D compat_boundary; + + new_appl_ptr =3D (snd_pcm_sframes_t)cur + rel; + if (new_appl_ptr < 0) + new_appl_ptr +=3D runtime->boundary; + else if ((snd_pcm_uframes_t)new_appl_ptr >=3D runtime->boundary) + new_appl_ptr -=3D runtime->boundary; + + return (snd_pcm_uframes_t)new_appl_ptr; +} + static int snd_pcm_ioctl_sync_ptr_compat(struct snd_pcm_substream *substre= am, struct snd_pcm_sync_ptr32 __user *src) { @@ -3253,13 +3292,16 @@ static int snd_pcm_ioctl_sync_ptr_compat(struct snd= _pcm_substream *substream, status =3D runtime->status; control =3D runtime->control; boundary =3D recalculate_boundary(runtime); - if (! boundary) + if (!boundary) boundary =3D 0x7fffffff; scoped_guard(pcm_stream_lock_irq, substream) { - /* FIXME: we should consider the boundary for the sync from app */ if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) { - err =3D pcm_lib_apply_appl_ptr(substream, - scontrol.appl_ptr); + err =3D pcm_lib_apply_appl_ptr + (substream, + snd_pcm_compat_reconstruct_appl_ptr + (runtime, + boundary, + scontrol.appl_ptr)); if (err < 0) return err; } else --- base-commit: b3c48fa1fb397b490101785ddd87caf2e5513a66 change-id: 20260318-alsa-pcm-compat-syncptr-boundary-0d52d2f8dc7e Best regards, --=20 C=C3=A1ssio Gabriel