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 52F25C433FE for ; Thu, 3 Nov 2022 15:54:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232157AbiKCPyQ (ORCPT ); Thu, 3 Nov 2022 11:54:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231983AbiKCPyP (ORCPT ); Thu, 3 Nov 2022 11:54:15 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09072DF06; Thu, 3 Nov 2022 08:54:15 -0700 (PDT) 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-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221103153404.uh77nrdkowrxj6cr@kamzik> Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.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