From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751381AbdJWIA6 convert rfc822-to-8bit (ORCPT ); Mon, 23 Oct 2017 04:00:58 -0400 Received: from 20pmail.ess.barracuda.com ([64.235.150.247]:55391 "EHLO 20pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294AbdJWIAy (ORCPT ); Mon, 23 Oct 2017 04:00:54 -0400 From: Miodrag Dinic To: David Daney , Maciej Rozycki , Aleksandar Markovic CC: "linux-mips@linux-mips.org" , Dragan Cecavac , Aleksandar Markovic , Douglas Leung , Goran Ferenc , James Hogan , James Hogan , "linux-kernel@vger.kernel.org" , "Maciej W. Rozycki" , Paul Burton , Paul Burton , Petar Jovanovic , Raghu Gandham , Ralf Baechle Subject: RE: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo Thread-Topic: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo Thread-Index: AQHTSa6AKc81zDqezU6JLxwEPQbWYqLtq1+AgAA0zoCAAzCuiA== Date: Mon, 23 Oct 2017 07:54:30 +0000 Message-ID: <48924BBB91ABDE4D9335632A6B179DD6A711BA@MIPSMAIL01.mipstec.com> References: <1508509203-30661-1-git-send-email-aleksandar.markovic@rt-rk.com> ,<601ab9f9-5092-7e44-acf1-ba5a9f0c1962@caviumnetworks.com> In-Reply-To: <601ab9f9-5092-7e44-acf1-ba5a9f0c1962@caviumnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.117.201.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BESS-ID: 1508745650-298554-20470-177121-1 X-BESS-VER: 2017.12-r1710102214 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.186217 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, the issue was found on Android using VTS, where its cpuinfo parser stumbled upon an extra space while trying to extract information about FPU. By comparing with ARM and Intel it seemed that only MIPS had this quirk in the cpuinfo format, so we submitted this change to make it conform to the format used by other architectures. However I agree that this is pretty sensitive code to userspace and it is better to leave it as is. @Macijej, David, thank you for pointing out the risks and explanation of the origin of this extra space in the cpuinfo format. Please ignore this change. Kind regards, Miodrag ________________________________________ From: David Daney [ddaney@caviumnetworks.com] Sent: Saturday, October 21, 2017 1:56 AM To: Maciej Rozycki; Aleksandar Markovic Cc: linux-mips@linux-mips.org; Dragan Cecavac; Aleksandar Markovic; Douglas Leung; Goran Ferenc; James Hogan; James Hogan; linux-kernel@vger.kernel.org; Maciej W. Rozycki; Miodrag Dinic; Paul Burton; Paul Burton; Petar Jovanovic; Raghu Gandham; Ralf Baechle Subject: Re: [PATCH] MIPS: kernel: proc: Remove spurious white space in cpuinfo On 10/20/2017 01:47 PM, Maciej W. Rozycki wrote: > On Fri, 20 Oct 2017, Aleksandar Markovic wrote: > >> Remove unnecessary space from FPU info segment of /proc/cpuinfo. > > NAK. As I recall back in Nov 2001 I placed the extra space there to > visually separate the CPU part from the FPU part, e.g.: > > cpu model : R3000A V3.0 FPU V4.0 > cpu model : SiByte SB1 V0.2 FPU V0.2 > > etc. And the motivation behind it still stands. Please remember that > /proc/cpuinfo is there for live humans to parse and grouping all these > pieces together would make it harder. Which means your change adds no > value I'm afraid. I think it is even riskier than that. This is part of the kernel-userspace ABI, many programs parse this file, any gratuitous changes risk breaking something. I don't really have an opinion about the various *printf functions being used, but think the resultant change in what is visible to userspace should not be done. > > NB regrettably back in those days much of the patch traffic happened off > any mailing list, however I have quickly tracked down my archival copy of > the original submission of the change introducing this piece of code and > I'll be happy to share it with anyone upon request. > > Maciej >