From mboxrd@z Thu Jan 1 00:00:00 1970 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B06B4FA3740 for ; Mon, 31 Oct 2022 10:04:37 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N17zm0xJsz3cLT for ; Mon, 31 Oct 2022 21:04:36 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com header.a=rsa-sha256 header.s=google header.b=NVMInip0; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=ventanamicro.com (client-ip=2a00:1450:4864:20::62c; helo=mail-ej1-x62c.google.com; envelope-from=ajones@ventanamicro.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com header.a=rsa-sha256 header.s=google header.b=NVMInip0; dkim-atps=neutral Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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) by lists.ozlabs.org (Postfix) with ESMTPS id 4N17yg5W7lz2xCj for ; Mon, 31 Oct 2022 21:03:37 +1100 (AEDT) Received: by mail-ej1-x62c.google.com with SMTP id y14so28047576ejd.9 for ; Mon, 31 Oct 2022 03:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ij0opVplOZ4JlIp6K8xwI+xLgpGAyEZHWtU1AyZKEUo=; b=NVMInip05i3j2Mewd8/9DA5VH9moDODkHGKksq2V35DG4ZziDSBIvUuAT9vkgpRf0d 21cfnb+Ic7yb0fKpaQko2/3X06kq6xe/XCHQEYDl6OhLI2/0FrdGqDZUQd1J7/senkcv DOl89eFWBJftp3vto1gh5cWgUBeCTuph9SIKiz0krDlDYUjX/89nzBZ1SkCF6yXeBQ5L oy/FLx+eyQ0Wt0BTeHJp3vkdt0LtCHU4KDi4RBqwOyUiIBl9/k/dAugnydtOxw9EUUT/ ArMtYe3iEM2RkUy0/xdIxnvFPevgupjBBbMoUxHQvvlem6IUyPz4BSgqjGCJMagdWnvZ oKCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ij0opVplOZ4JlIp6K8xwI+xLgpGAyEZHWtU1AyZKEUo=; b=p4jS+1T13TYomWq1cXVFF1n7w4BYp1RixetW8cllh+QK/nW4XA+YVR+A5YExT0ofLg 7set24jlWxxl29IkY2xhkVvD78Cn6RkhgOuc++06SQ7rFbHOR9bB3IHw3bYsaBUbCPrq 2TmbZkSvYL1jBOuG7zYaFGEZaxYywpiMJEOoBRFWNkdOjDopSQwe9ximAPi4jzbqA/LU IjyUrqbq75Q6r9olj1BVJ2ZygckkXN2Kono0OKJ3sukMiKHgaULCLolfcXvYK2AU8OAS U6okwb6Y4dpfsjzpXNyHfz96UrJXvW5G79QxbMWFTJCeQFX5XRQAnbFuF2/eO77gMuJX xkbQ== X-Gm-Message-State: ACrzQf1ZpnoXPKM6q08OnyVQcFLEz+2s+oEePSSrTHyw0YS7WVPWe8Xi 3fQ1GeLPpDM+eB2c5wJlAs56Yw== X-Google-Smtp-Source: AMsMyM6ycpS4chQBPAohNrxS8VumeP7MjXmU/tZoBGLw1w6j4emq8bR2PAjr2PZhdKbiabGv9P0mtA== X-Received: by 2002:a17:906:9745:b0:78d:480f:cee7 with SMTP id o5-20020a170906974500b0078d480fcee7mr11952970ejy.192.1667210609260; Mon, 31 Oct 2022 03:03:29 -0700 (PDT) Received: from localhost (cst2-173-61.cust.vodafone.cz. [31.30.173.61]) by smtp.gmail.com with ESMTPSA id eh22-20020a0564020f9600b00461bacee867sm3048302edb.25.2022.10.31.03.03.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Oct 2022 03:03:28 -0700 (PDT) Date: Mon, 31 Oct 2022 11:03:27 +0100 From: Andrew Jones To: Borislav Petkov Subject: Re: [PATCH v3 2/2] x86: Fix /proc/cpuinfo cpumask warning Message-ID: <20221031100327.r7tswmpszvs5ot5n@kamzik> References: <20221014155845.1986223-1-ajones@ventanamicro.com> <20221014155845.1986223-3-ajones@ventanamicro.com> <20221028074828.b66uuqqfbrnjdtab@kamzik> <20221031080604.6xei6c4e3ckhsvmy@kamzik> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jonas Bonn , linux-s390@vger.kernel.org, Alexander Gordeev , Dave Hansen , Vasily Gorbik , Yury Norov , Heiko Carstens , x86@kernel.org, Linux Kernel Mailing List , Stefan Kristiansson , openrisc@lists.librecores.org, Ingo Molnar , Palmer Dabbelt , Paul Walmsley , Stafford Horne , linux-riscv , "open list:LINUX FOR POWERPC PA SEMI PWRFICIENT" , Thomas Gleixner , Albert Ou Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Oct 31, 2022 at 09:58:57AM +0100, Borislav Petkov wrote: > On Mon, Oct 31, 2022 at 09:06:04AM +0100, Andrew Jones wrote: > > The valid cpumask range is [0, nr_cpu_ids) and cpumask_next() always > > returns a CPU ID greater than its input, which results in its input > > range being [-1, nr_cpu_ids - 1). Ensure showing CPU info avoids > > triggering error conditions in cpumask_next() by stopping its loop > > What error conditions? > > What would happen if @n is outside of the valid range? Currently (after the revert of 78e5a3399421) with DEBUG_PER_CPU_MAPS we'll get a warning splat when the cpu is outside the range [-1, nr_cpu_ids) and cpumask_next() will call find_next_bit() with the input plus one anyway. find_next_bit() doesn't explicity document what happens when an input is outside the range, but it currently returns the bitmap size without any side effects, which means cpumask_next() will return nr_cpu_ids. show_cpuinfo() doesn't try to show anything in that case and stops its loop, or, IOW, things work fine now with an input of nr_cpu_ids - 1. But, show_cpuinfo() is just getting away with a violated cpumask_next() contract, which 78e5a3399421 exposed. How about a new commit message like this seq_read_iter() and cpuinfo's start and next seq operations implement a pattern like n = cpumask_next(n - 1, mask); show(n); while (1) { ++n; n = cpumask_next(n - 1, mask); if (n >= nr_cpu_ids) break; show(n); } which loops until cpumask_next() identifies its CPU ID input is out of its valid range, [-1, nr_cpu_ids - 1). seq_read_iter() assumes the result of an invalid input is to return nr_cpu_ids or larger without any side effects, however the cpumask API does not document that and it reserves the right to change how it responds to invalid inputs. Ensure inputs from seq_read_iter() are valid. Thanks, drew