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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56702FA3742 for ; Mon, 31 Oct 2022 10:03:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbiJaKDd (ORCPT ); Mon, 31 Oct 2022 06:03:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbiJaKDb (ORCPT ); Mon, 31 Oct 2022 06:03:31 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF3789FD0 for ; Mon, 31 Oct 2022 03:03:30 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id n12so27980097eja.11 for ; Mon, 31 Oct 2022 03:03:30 -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=0j70KPmh+LzbZtTVjrr/AHPs/sOVjC86eqBtQ8+OJD8G400CSnoVqx6te8Eo/2vOGJ mYEw4HjQUsxg4ekbciASytWoQ4KgDvHP2btFmTDn5y4p1BzOatk+9USkuCoPjabBopLc RuIpeQ7BXfdNbFuI07+6KHAf430iAnPEJKw0R6d0CFGXiH5FnCJvLnuTBVj9fuiHTNUt 8bUcvBWVK6UF2gpqahurl8b9nfbhJvNBhZEnVW6qHeR8qEXeufmfbOa82dOtUbtvOKSW 1mGXRVaSlhnICE+CbKKkrqEOBSg/sIcgAAlwjkucvFiPmQAodtnPvbgCU7E3jWlCXmgL StWA== X-Gm-Message-State: ACrzQf16O3RlpAzjsH9AX7CtmngHU8MdH2m38JALvHUpm1n20sA2okgK +d3F+/0M5Q1UD1oz1OvvuWu3YA== 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 Cc: Yury Norov , x86@kernel.org, linux-riscv , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Dave Hansen , Palmer Dabbelt , Paul Walmsley , Albert Ou , Jonas Bonn , Stefan Kristiansson , Stafford Horne , openrisc@lists.librecores.org, Michael Ellerman , "open list:LINUX FOR POWERPC PA SEMI PWRFICIENT" , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , linux-s390@vger.kernel.org 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 mail.librecores.org (lists.librecores.org [88.198.125.70]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0066C38A02 for ; Mon, 31 Oct 2022 10:03:33 +0000 (UTC) Received: from [172.31.1.100] (localhost.localdomain [127.0.0.1]) by mail.librecores.org (Postfix) with ESMTP id 4DDDF24BEA; Mon, 31 Oct 2022 11:03:32 +0100 (CET) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by mail.librecores.org (Postfix) with ESMTPS id 15A9D24BEA for ; Mon, 31 Oct 2022 11:03:30 +0100 (CET) Received: by mail-ej1-f54.google.com with SMTP id n12so27980108eja.11 for ; Mon, 31 Oct 2022 03:03:30 -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=tXrHascOwQPJf/j8F2QuAGdiyqXwSvzN1vKQycUNnb/GFQons2aV1labcnNHJfxOAj J0oOGm9UUUDJAkzXaqLPnsTm7j0+INSJbU4Hi4UNiw7y6etK+/giKSIlUvpF0qCx7Ir/ wnLXpeyh+W1OSM7cQxEFVVCCedJqcvRC3pM43NLkYRGHf7wlQvS66FJ1qj/LnPRR0l00 egWvV6FLe4HIAqbFKO8NNzIRHvletqBfrAkcscwjoTv4wf05nmrj1T4X6tW6UNhlZIBX 4M3d/e795M+f0BFlgzaq3jH3XAGKPY6drN9cKnEYtdV7rh9JOvF9duFMXFnhUbGiJCPv YOdQ== X-Gm-Message-State: ACrzQf1pG6mkbexkwFqFLsuAzrPO+l65tRifcdJEXxsyVlmI0UXCBYCt 1yJuc9aJI2MwZBDr4kaBzseCqg== 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: openrisc@lists.librecores.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion around the OpenRISC processor 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 , Michael Ellerman , Heiko Carstens , x86@kernel.org, Linux Kernel Mailing List , openrisc@lists.librecores.org, Ingo Molnar , Palmer Dabbelt , Paul Walmsley , linux-riscv , "open list:LINUX FOR POWERPC PA SEMI PWRFICIENT" , Thomas Gleixner , Albert Ou Errors-To: openrisc-bounces@lists.librecores.org Sender: "OpenRISC" 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 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 A1D6CFA3740 for ; Mon, 31 Oct 2022 10:03:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AdN8+y5YEGNZRZd/AvBq0iqhiSDUoFPwsfER9s8OMRw=; b=rh7NSa6O/D2pc1 4p75uQROVMhOKSvp8apIqearjEqkB0tBnfOmMrJwWFVTxlLZSe7ADVAEM18QBvM43jQPUT4vr4LSf JyA7rKfStGruk3+6Que/AKKDxAtpB2DOy2+6xeGw7DchQkOUpFzLjLgmb67bOWYJpYoyzCv21nfEW RNXMHZ1j6AzMbyCpX1+lbgvMWlLek1FcURLmBgIhd2zVQkt1aoXVbc3x53IQoXXZJ3M3NCGgoSQ1u FklQQeHH269bmhE3EJqvYmLwm59oHT4UNiBVg3GrtKo/KkszkmvDl396YObRYmDcF04/+b72wPJSd V7q6mNx/irLjp+rkwXxg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1opRdn-00AOkf-ES; Mon, 31 Oct 2022 10:03:35 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1opRdl-00AOj7-ID for linux-riscv@lists.infradead.org; Mon, 31 Oct 2022 10:03:34 +0000 Received: by mail-ej1-x62b.google.com with SMTP id k2so28109089ejr.2 for ; Mon, 31 Oct 2022 03:03:30 -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=TOjcOO8p1rJdD3MKChS36Ne6hwujcye5j/srGtKEcSMfF8Mur2xJ73N3WIQWxMcSjb wIGKd7HUJHVFbXpNArSEV5INROW4qYY/cEGc0pfZ52WI9ApaUf7hsUkUk5eQhogoOy94 T36V1LrqxkO8EcNNz06IRcXPukBPyNz8RKuTuOu6E6f+RbJoaCEqD5UkvnsYpRQX+ikA +C9UdCnVQQeAK62BzvQ18zFvr3SmoSfQ+Tm4LM7qowcIzbWesJaZIlGoU+ctBEFsC0bB 7kiW2idoLmadSfjSlDkGaA203QVJkB5W22ehyqwrFD6y/ZAZtKC5IX5E1yBg30jM4XIW mNNQ== X-Gm-Message-State: ACrzQf10poy7JQ33/ONGUfmtXiIBJu50wcTMNzCAIMrtjzkNdmk0kP2c 21pXqtxxHu37Hqim95UeEGFHJw== 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 Cc: Yury Norov , x86@kernel.org, linux-riscv , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Dave Hansen , Palmer Dabbelt , Paul Walmsley , Albert Ou , Jonas Bonn , Stefan Kristiansson , Stafford Horne , openrisc@lists.librecores.org, Michael Ellerman , "open list:LINUX FOR POWERPC PA SEMI PWRFICIENT" , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , linux-s390@vger.kernel.org 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221031_030333_631180_301E3882 X-CRM114-Status: GOOD ( 17.11 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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