From nobody Sat Apr 11 21:28:57 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 8FCC5C19F2D for ; Sat, 6 Aug 2022 16:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232860AbiHFQZd (ORCPT ); Sat, 6 Aug 2022 12:25:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232621AbiHFQZa (ORCPT ); Sat, 6 Aug 2022 12:25:30 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 171BCF5B4 for ; Sat, 6 Aug 2022 09:25:26 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id w10so5162339plq.0 for ; Sat, 06 Aug 2022 09:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc; bh=UbGxgyfmTUw0NnY5/Pu/ELaJtqQmXlFiXmZPB/RD9VQ=; b=HkHVd3hlXKYP2R+Mk2Pd6mQCloOY1m4EmdMyhrH26cSEUUAiV2mnYf+zdC8MVUqkTP oxASsq1/rht3Ub3fKW+wJRv8oyY/QmeZ0DcOW6KR6SUv5FurMf8OdMr0sLjOXxMTzzXa r5HnPCO2dkvKZ0SV8yiZfMjZVLzBGgmKj7FJN7Su1wqcXggFr3kVsKTHL8Em03nVYOAf /rJadZIvC8REvQxEEeUTDFcqVMb2t1rPLdpFuWBhgiH8GkYrlcaSvspoQ2vyKNGgKTeY PmfrxKA6c6Lh0vENmq5pAud2L7vENuXpOglTWDlCIUEHGzSY/bow6AiP+pSs+6ZLagJ9 lEXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc; bh=UbGxgyfmTUw0NnY5/Pu/ELaJtqQmXlFiXmZPB/RD9VQ=; b=JBWrwYD+nAdA92pPXqZwmu4GDs22SY+PgPf/rVGtEKovOeA7ml+CndaOeiYggZcd7P h7m23P177Dn2H+FH2jinto4gMbgxmEacMJ+xQVYCkG0zTimyBbLYe3AksfN0wvbuCBtm qSIn1TndTWiRJpd/YsmChohPpd5SrKd4VF5B3+GIKsMY1BoIRrqXubs9zNgNlirnkSaB 3+5186IooAm7qYG0YS0LV0vERB/bbsCYxHB4KplZfYZVn+jGmvNiKJpTvc1lcPJ241Ce WgeFkaHyY2et3AM90ExsKeX9TkgLx1RFqZiK84/RgCG/Vu6F0IHXIkeCmSMk5ncsYIR/ YOSQ== X-Gm-Message-State: ACgBeo2l22tf9VJl7IRmUBdhE5QO6+xPO3uHyh8Njpi5AEvxwj0ORHKt mZMQGk53/uOKixM/lGkEFrYxcbyI25DamA== X-Google-Smtp-Source: AA6agR5yVyVKy+WlmRPtgWkf0lsgZfGXMX54t/jfTMb09y973IKoLoy5hBWIn0eoel118MLO+t+QMQ== X-Received: by 2002:a17:902:be16:b0:170:8ebf:204c with SMTP id r22-20020a170902be1600b001708ebf204cmr3102308pls.47.1659803125608; Sat, 06 Aug 2022 09:25:25 -0700 (PDT) Received: from localhost.localdomain (ec2-13-113-80-70.ap-northeast-1.compute.amazonaws.com. [13.113.80.70]) by smtp.gmail.com with ESMTPSA id s1-20020a17090a2f0100b001f04479017fsm4990927pjd.29.2022.08.06.09.25.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Aug 2022 09:25:25 -0700 (PDT) From: Zhang Boyang To: Thomas Gleixner , Ferdinand Blomqvist , linux-kernel@vger.kernel.org Cc: Kees Cook , Randy Dunlap , Zhang Boyang Subject: [PATCH RESEND V3 1/6] rslib: Fix incorrect documentation of rs_modnn() Date: Sun, 7 Aug 2022 00:25:05 +0800 Message-Id: <20220806162510.157196-2-zhangboyang.id@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220806162510.157196-1-zhangboyang.id@gmail.com> References: <20220806162510.157196-1-zhangboyang.id@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Previous documentation of rs_modnn() states simple arithmetic modulo return a wrong result for values >=3D (3 * rs->nn). However, that is not true. The rs_modnn() does the exactly same job as (x % rs->nn). This can be proved from following loop invariants: while (x >=3D rs->nn) { x -=3D rs->nn; // (1) x =3D (x >> rs->mm) + (x & rs->nn); // (2) } Let x0 denote the value of x before assignment. At (1), it is obvious that x % nn =3D=3D x0 % nn. At (2), because nn =3D=3D ((1 << mm) - 1), we h= ave x0 % nn =3D=3D x0 % nn x0 % nn =3D=3D (((x0 >> mm) << mm) + (x0 & nn)) % nn x0 % nn =3D=3D ((x0 >> mm) * (nn + 1) + (x0 & nn)) % nn x0 % nn =3D=3D ((x0 >> mm) * ((nn + 1) % nn) + (x0 & nn)) % nn x0 % nn =3D=3D ((x0 >> mm) * 1 + (x0 & nn)) % nn // let's assume nn > 1 x0 % nn =3D=3D ((x0 >> mm) + (x0 & nn)) % nn x0 % nn =3D=3D x % nn When the loop exits, it is obvious that 0 <=3D x < nn, so the return value must equal to (x % rs->nn). Signed-off-by: Zhang Boyang --- include/linux/rslib.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/rslib.h b/include/linux/rslib.h index 238bb85243d3..507fa14c03b2 100644 --- a/include/linux/rslib.h +++ b/include/linux/rslib.h @@ -116,8 +116,7 @@ void free_rs(struct rs_control *rs); * rs->mm =3D number of bits per symbol * rs->nn =3D (2^rs->mm) - 1 * - * Simple arithmetic modulo would return a wrong result for values - * >=3D 3 * rs->nn + * Calculate (x % rs->nn), without using a div instruction */ static inline int rs_modnn(struct rs_codec *rs, int x) { --=20 2.30.2