From nobody Sat Apr 11 02:18:40 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07715C32771 for ; Wed, 17 Aug 2022 12:46:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239054AbiHQMqO (ORCPT ); Wed, 17 Aug 2022 08:46:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236380AbiHQMqK (ORCPT ); Wed, 17 Aug 2022 08:46:10 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 109758A6DB for ; Wed, 17 Aug 2022 05:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660740369; x=1692276369; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=kYOYATKAKktz41sDaZZq1GXiosh7ennmO+42v74MCX0=; b=BmFzNif2BqWreUkOOUtX5E9gtVH8H9Dsb+aki42myU77KoVdwOmeS+4o Q/cqpI//50i3NqOLqLwOQAuFPVXL8qaZWSDj95JbcBLWzF5tsQpCXR5AB nzcdRYfHnN3NwodGBTIytpI3IbWD2eHvs3zF5U0XsfoTNjhKoifqjyxEi wm1hBmSQR/t68UglNCnIZx0xbUdf6B2FXIlb7wN4ZHCctyf77ryC8LTCL Z770vZ1G8MRJk8YffLCxbvG8j3Ib0vx7UO+8KjyqCkFETe65lb6p8Ned9 oG86/VgxhNb9Ak9P95UJI4XSknTjZ+WjGwzlOttj8BeXEqOdeh5enKjo6 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10442"; a="293758726" X-IronPort-AV: E=Sophos;i="5.93,243,1654585200"; d="scan'208";a="293758726" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2022 05:46:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,243,1654585200"; d="scan'208";a="935344769" Received: from dev2 (HELO DEV2.igk.intel.com) ([10.237.148.94]) by fmsmga005.fm.intel.com with ESMTP; 17 Aug 2022 05:46:07 -0700 From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= To: Takashi@vger.kernel.org, Iwai@vger.kernel.org, alsa-devel@alsa-project.org Cc: linux-kernel@vger.kernel.org, Cezary Rojewski , =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= Subject: [PATCH] ALSA: info: Fix llseek return value when using callback Date: Wed, 17 Aug 2022 14:46:42 +0200 Message-Id: <20220817124642.3974015-1-amadeuszx.slawinski@linux.intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When using callback there was a flow of ret =3D -EINVAL if (callback) { offset =3D callback(); goto out; } ... offset =3D some other value in case of no callback; ret =3D offset; out: return ret; which causes the snd_info_entry_llseek() to return -EINVAL when there is callback handler. Fix this by setting "ret" directly to callback return value before jumping to "out". 73029e0ff18d ("ALSA: info - Implement common llseek for binary mode") Signed-off-by: Amadeusz S=C5=82awi=C5=84ski --- sound/core/info.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/core/info.c b/sound/core/info.c index b8058b341178..0b2f04dcb589 100644 --- a/sound/core/info.c +++ b/sound/core/info.c @@ -111,9 +111,9 @@ static loff_t snd_info_entry_llseek(struct file *file, = loff_t offset, int orig) entry =3D data->entry; mutex_lock(&entry->access); if (entry->c.ops->llseek) { - offset =3D entry->c.ops->llseek(entry, - data->file_private_data, - file, offset, orig); + ret =3D entry->c.ops->llseek(entry, + data->file_private_data, + file, offset, orig); goto out; } =20 --=20 2.25.1