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 BCF27C433FE for ; Thu, 3 Nov 2022 15:54:32 +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=qSqC1mYRpDaTLr3Qgkx9/5GMN5i6sHslZAueq+vxFqA=; b=qKmD869LVWWo9E GZrWs3Qgnhnn4hrptdUkSIVtI7de5yKxOKy+k625vclAHkhNWFnD8qh9DM+wNQE9DGs43xJkW8GMd 5aEmRjrbNv5lHY7sKEPeCuEv8hwVmLhmyhoT/LtfVNTSvYCWD3Cs8b5nKzTD7MohLjozI9YMLQzzG 0PJu8l2kvlWLQH/fAb7TSNH4clkRtuCE0nYaN/d31bM+G3WYUeD99kiXCQ4T4hj8UKzHStDrV2ZoT yX64ZHCaGsfnghhIQd8kHQkjsc9z2P/sKO7JwAI+RPcbuauxwHnxJqbhg0Q1RtIddpS/pMK5W434/ bkynAJyThOz7tI6UxT2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqcXq-000XJn-RR; Thu, 03 Nov 2022 15:54:19 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oqcXn-000XIW-9l for linux-riscv@lists.infradead.org; Thu, 03 Nov 2022 15:54:16 +0000 Received: from zn.tnic (p200300ea9733e7e7329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7e7:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9076F1EC0559; Thu, 3 Nov 2022 16:54:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1667490853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=rA76MiReFYdyzzFnwVP8TI+Yl5vD+IAy50wE2e/pB5o=; b=Q/42eQoMNEpt6v+yMF7SaTCBQyI5cOTWZsxTCcL6g3/hzbNlTitjCnWQ88xqkhu/FWRymK Yb1zoedOXZSjiEJ4AC2A3WoEtNnflcCGCJIWEEJYCYhIhHV/xToo/DQ+YOqFZtP5ofOS+H YnzBPdUv7j4yAJ9/0NbUyRp3pBDX/x4= Date: Thu, 3 Nov 2022 16:54:09 +0100 From: Borislav Petkov To: Andrew Jones 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: References: <20221031080604.6xei6c4e3ckhsvmy@kamzik> <20221031100327.r7tswmpszvs5ot5n@kamzik> <20221103125945.lrr5oxxmylwpam53@kamzik> <20221103153404.uh77nrdkowrxj6cr@kamzik> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221103153404.uh77nrdkowrxj6cr@kamzik> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221103_085415_521524_A82017DF X-CRM114-Status: GOOD ( 12.75 ) 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 Thu, Nov 03, 2022 at 04:34:04PM +0100, Andrew Jones wrote: > Indeed, but that's less of an issue with cpumask_next() than with > the way cpuinfo implements its start and next seq ops (next > unconditionally increments *pos and then calls start and start > must use *pos - 1 since the first time its called it needs to use > -1). Maybe because those are done wrongly... A ->next() function should not call the ->start() function. A ->start() function should, well, only start and nothing else. And a ->stop() function should maybe check *pos and say whether one should stop or not. But I haven't looked at seq_ops at least in a decade and I have no clue whether that would work. I'm just looking at the function pointers and am trying to spell out what looks most natural IMO. IOW, maybe this should be fixed "right" and not only "made to work". Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv