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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D7BDC10DCE for ; Thu, 12 Mar 2020 05:44:37 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C87B820663 for ; Thu, 12 Mar 2020 05:44:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="YHrvGF+c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C87B820663 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48dHp90wgZzDqLc for ; Thu, 12 Mar 2020 16:44:33 +1100 (AEDT) Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) (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 48dHmV2zk9zDqJs for ; Thu, 12 Mar 2020 16:43:06 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=YHrvGF+c; dkim-atps=neutral Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 48dHmS46Qmz9sPR; Thu, 12 Mar 2020 16:43:04 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1583991784; bh=4/7I8wVV31S0yz7fC0JwqxKKGm7L9wp0Y4ZlLlEb8kE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YHrvGF+cVz8hW9azlmgNIx2dVUg3Y2AXDTNgvBE90o9P3IN3M5xHB4NlTv0o6PtJu GjqLlHG2y7vB0p58v+RRDmHrP3TAMQgIJvi9R4HlNQFA2WIKIqWDF5NyskIHGlUWce xf6AzikRBCY7dpnvVvuWAWU8XSwV8D666hvpOjXjlkeC/Xm8YyekZOYbxJcgKK2ZG2 YagKR4VlnmgjpJhTVmnwlf+XcyVcUL6vrtu2nV6GDUuFoPiqAiw9TSkyBBPXExBr23 0QjdojHdbvMieHNL/bi3e3S+WYKPFV81Ux+GpVRok41yaaFDPvAfBz0nA1D0Sp0pAW PT4oE2L6PEhJQ== From: Michael Ellerman To: Tyrel Datwyler , Nathan Lynch Subject: Re: [PATCH] powerpc/pseries: fix of_read_drc_info_cell() to point at next record In-Reply-To: References: <20200307024547.5748-1-tyreld@linux.ibm.com> <87tv2w2kc2.fsf@linux.ibm.com> Date: Thu, 12 Mar 2020 16:43:02 +1100 Message-ID: <87imjai0wp.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain 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: mwb@linux.vnet.ibm.com, msuchanek@suse.de, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Tyrel Datwyler writes: > On 3/10/20 10:25 AM, Nathan Lynch wrote: >> Tyrel Datwyler writes: >>> The expectation is that when calling of_read_drc_info_cell() >>> repeatedly to parse multiple drc-info records that the in/out curval >>> parameter points at the start of the next record on return. However, >>> the current behavior has curval still pointing at the final value of >>> the record just parsed. The result of which is that if the >>> ibm,drc-info property contains multiple properties the parsed value >>> of the drc_type for any record after the first has the power_domain >>> value of the previous record appended to the type string. >>> >>> Ex: observed the following 0xffffffff prepended to PHB >>> >>> [ 69.485037] drc-info: type: \xff\xff\xff\xffPHB, prefix: PHB , index_start: 0x20000001 >>> [ 69.485038] drc-info: suffix_start: 1, sequential_elems: 3072, sequential_inc: 1 >>> [ 69.485038] drc-info: power-domain: 0xffffffff, last_index: 0x20000c00 >>> >>> Fix by incrementing curval past the power_domain value to point at >>> drc_type string of next record. >>> >>> Fixes: a29396653b8bf ("pseries/drc-info: Search DRC properties for CPU indexes") >> >> I have a different commit hash for that: >> e83636ac3334 pseries/drc-info: Search DRC properties for CPU indexes > > Oof, looks like I grabbed the commit hash from the SLES 15 SP1 branch. You have > the correct upstream commit. > > Fixes: e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU indexes") > > Michael, let me know if you want me to resubmit, or if you will fixup the Fixes > tag on your end? I can update the Fixes tag. What's the practical effect of this bug? It seems like it should break all the hotplug stuff, but presumably it doesn't in practice for some reason? It would also be *really* nice if we had some unit tests for this parsing code, it's demonstrably very bug prone. cheers