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 3803EC4332F for ; Thu, 3 Nov 2022 15:55:10 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N37cr2dlyz3cFb for ; Fri, 4 Nov 2022 02:55:08 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=alien8.de header.i=@alien8.de header.a=rsa-sha256 header.s=dkim header.b=Q/42eQoM; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=alien8.de (client-ip=5.9.137.197; helo=mail.skyhub.de; envelope-from=bp@alien8.de; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=alien8.de header.i=@alien8.de header.a=rsa-sha256 header.s=dkim header.b=Q/42eQoM; dkim-atps=neutral Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4N37br1M76z3bnH for ; Fri, 4 Nov 2022 02:54:16 +1100 (AEDT) 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 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> 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 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