Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3236474ybf; Tue, 3 Mar 2020 02:09:02 -0800 (PST) X-Google-Smtp-Source: ADFU+vsknrlQHFlkht+DBPn11lR5JDht3UUzHOtVUT54tdvIuuudnQlfczX2fAHio1zrca54jhjc X-Received: by 2002:aca:d50f:: with SMTP id m15mr1944420oig.33.1583230142779; Tue, 03 Mar 2020 02:09:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583230142; cv=none; d=google.com; s=arc-20160816; b=ckf+CRYdGLXpOa13YqP9dciIgQVABhoCmnIwYINdrCccAaByUFeSMG+mJJtDoioTEU icNGICYnRgCn3gMXl2StILO+6LSUzwIDAML62dk/rD4eobY9obM6mCc/sPYQ5ja7XjlS hYyqr7gyH486UZ5RmCZv10yr4TDxfGmRL/nfpZtGWHzUXOYDynCAhpMQU0bJNT5+dCGg 4EFickFHkXEcBFTVlsNz/mKZPosd/nxaaAS1bDVBXTtmoBNc/y+ZS9RAfiEbDcNYsLjW N9avIM9P+uCZiqqzgCWjP+X2TT4VbYwqSClYnEchSfeHfN/YQivcgpKXaEYLTJVV61XZ RInw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=EX9/Etye/FrfYfGoNd01CxIWlukHlzefx1fc36skZBg=; b=p4d9Dujb5zTYrC/FXqwUQt7ycWLoqvAxO/rJZl1JIlH6R9pcCAx6JNjWwLuedJpcaT 1JMuR10SNfL7VotreZ7RrDk8NF4b1mu3QTywdh61nU6fbrd9WPQWEykPagCNMn1PYLM5 dzNxvEO9HePt4VjNok5K7zllOhyf3H3tdJP7v3DAstE/XD3TOdeWROrcfr8pKT26fy6N RiJ3K+CQHcZbL0cL3iyT3XZ/2x23roDhoNaCiLPekLa5E+0BI4JKcNrh1JuAo5B0gSon hfgG4db0rq0P9xm39VTG+7ftdP1S5WfyLKA+swam11ns8mQPpw7KWuVJmPpgjOhfvG8M kpNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si7533573oia.264.2020.03.03.02.08.50; Tue, 03 Mar 2020 02:09:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728037AbgCCKIJ (ORCPT + 99 others); Tue, 3 Mar 2020 05:08:09 -0500 Received: from foss.arm.com ([217.140.110.172]:44994 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbgCCKIJ (ORCPT ); Tue, 3 Mar 2020 05:08:09 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 65490FEC; Tue, 3 Mar 2020 02:08:08 -0800 (PST) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7FF783F6C4; Tue, 3 Mar 2020 02:08:07 -0800 (PST) Date: Tue, 3 Mar 2020 10:08:01 +0000 From: Sudeep Holla To: "Zengtao (B)" Cc: Linuxarm , Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] cpu-topology: Fix the potential data corruption Message-ID: <20200303100801.GA56564@bogus> References: <1582878945-50415-1-git-send-email-prime.zeng@hisilicon.com> <20200228104034.GB26973@bogus> <678F3D1BB717D949B966B68EAEB446ED341F2AE2@DGGEMM506-MBS.china.huawei.com> <20200302111038.GA16218@e107533-lin.cambridge.arm.com> <678F3D1BB717D949B966B68EAEB446ED342092EE@dggemm526-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED342092EE@dggemm526-mbx.china.huawei.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 03, 2020 at 02:58:41AM +0000, Zengtao (B) wrote: [...] > > Do you think I need to update the commit message and resend the patch? Yes > And I don't mind if you can help modify the commit message since both > are fine for me, and it's a very trivial change. > Sure, something like below: "Currently there are only 10 bytes to store the cpu-topology 'name' information. Only 10 bytes copied into cluster/thread/core names. If the cluster ID exceeds 2-digit number, it will result in the data corruption, and ending up in a dead loop in the parsing routines. The same applies to the thread names with more that 3-digit number. This issue was found using the boundary tests under virtualised environment like QEMU. Let us increase the buffer to fix such potential issues." With the above commit log, you can add my: Reviewed-by: Sudeep Holla -- Regards, Sudeep