From patchwork Fri Sep 11 09:06:06 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 53418 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wi0-f200.google.com (mail-wi0-f200.google.com [209.85.212.200]) by patches.linaro.org (Postfix) with ESMTPS id 7B1B322B26 for ; Fri, 11 Sep 2015 09:06:31 +0000 (UTC) Received: by wicgb1 with SMTP id gb1sf16211019wic.3 for ; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=naq295Emvzh9+XAWhUn02weZSkPgyW+aSO7kGsRHdUQ=; b=eUKSJBepRUEKouPrlif+plNXM6kzuwRAEblVkdxkFe0Y8O6t+VMFvh/EbSsLDRE8AO 5yBIstDRrE1kF0pk1uxc5UVTZOt6G+CHn0DLtAGsrrPVXoFYxO/y4Tw3e2kpcRVJzLrJ jz58OsyYK+6f3BJSpBakll3YB1zQzry4+eoWNhgG7rbzQwETKAxTKS+VFLWCoArZ2zOV xqJ27MH03+1i29lWYW8Kpw0F2URXpxrUNuhenIbaUFR+xIv3jMykXA6Cmsmm3xmqNrzo TDkQ3t+RRNrhASnn4l+WCrJ1HrAflAtD46+ObhC1PGf8FYmiKnZcRyHA/+nzPUfbBk0f VRfA== X-Gm-Message-State: ALoCoQlD89NvZa5RZmiowdrLQum07DLNfTTATySVvkjU3RYvIDYvuyO8YHG5PyR+gSeL2ZAVCATC X-Received: by 10.194.240.230 with SMTP id wd6mr1141828wjc.0.1441962390809; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.153.7.134 with SMTP id dc6ls144322lad.94.gmail; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) X-Received: by 10.112.129.202 with SMTP id ny10mr16357660lbb.112.1441962390600; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com. [209.85.215.43]) by mx.google.com with ESMTPS id q3si376770laj.149.2015.09.11.02.06.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 02:06:30 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; Received: by lagj9 with SMTP id j9so44567159lag.2 for ; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) X-Received: by 10.152.26.41 with SMTP id i9mr12516047lag.36.1441962390499; Fri, 11 Sep 2015 02:06:30 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.59.35 with SMTP id w3csp1452274lbq; Fri, 11 Sep 2015 02:06:29 -0700 (PDT) X-Received: by 10.66.144.165 with SMTP id sn5mr86010339pab.122.1441962389481; Fri, 11 Sep 2015 02:06:29 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c6si989525pbu.132.2015.09.11.02.06.28; Fri, 11 Sep 2015 02:06:29 -0700 (PDT) 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; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbbIKJG0 (ORCPT + 28 others); Fri, 11 Sep 2015 05:06:26 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:35369 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751376AbbIKJGZ (ORCPT ); Fri, 11 Sep 2015 05:06:25 -0400 Received: by pacfv12 with SMTP id fv12so71068843pac.2 for ; Fri, 11 Sep 2015 02:06:24 -0700 (PDT) X-Received: by 10.69.3.228 with SMTP id bz4mr94696871pbd.79.1441962384646; Fri, 11 Sep 2015 02:06:24 -0700 (PDT) Received: from localhost ([122.171.186.190]) by smtp.gmail.com with ESMTPSA id sl7sm1035268pbc.54.2015.09.11.02.06.23 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Sep 2015 02:06:23 -0700 (PDT) From: Viresh Kumar To: gregkh@linuxfoundation.org Cc: linaro-kernel@lists.linaro.org, Rafael Wysocki , sboyd@codeaurora.org, Viresh Kumar , linux-kernel@vger.kernel.org (open list) Subject: [PATCH] debugfs: don't access 4 bytes for a boolean Date: Fri, 11 Sep 2015 14:36:06 +0530 Message-Id: <3d6f65fa15363650f2d10ca58b9d9d243e98980f.1441961769.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.4.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.43 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , Long back 'bool' type used to be a typecast to 'int', but that changed in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes just a byte. Anyway, the bool type in kernel is used to store true/false or 1/0 only. So, accessing a single byte should be enough. The problem with current code is that it reads/writes 4 bytes for a boolean, which will read/update 3 excess bytes following the boolean variable. And that can lead to hard to fix bugs. It was a nightmare to crack this one. The debugfs code had this bug since the first time it got introduced, but was never got caught, strange. Maybe the bool variables (monitored by debugfs) were followed by an 'int' or something bigger and the pad bytes made sure, we never see this issue. But the OPP (Operating performance points) library have three booleans allocated to contiguous bytes and this bug got hit quite soon (The debugfs support for OPP is yet to be merged). Fix this by changing type of 'val' pointer to u8 type, so that we only access a single byte. Signed-off-by: Viresh Kumar --- Greg, I wasn't sure about what to add the stable tag. This bug is around for a really long time now. And this also gets me worrying if any other part of the kernel are treating booleans in a similar way :) Also, there is another problem I see, which probably should be fixed as well. But I wanted to hear from you before trying to patch the kernel for this. debugfs_create_bool() declares the pointer to be of type u32 *. Shouldn't that be changed to u8 *? There are many users which are typecasting the variables to make debugfs API happy :) fs/debugfs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index 284f9aa0028b..c123185a296a 100644 --- a/fs/debugfs/file.c +++ b/fs/debugfs/file.c @@ -439,7 +439,7 @@ static ssize_t read_file_bool(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { char buf[3]; - u32 *val = file->private_data; + u8 *val = file->private_data; if (*val) buf[0] = 'Y'; @@ -456,7 +456,7 @@ static ssize_t write_file_bool(struct file *file, const char __user *user_buf, char buf[32]; size_t buf_size; bool bv; - u32 *val = file->private_data; + u8 *val = file->private_data; buf_size = min(count, (sizeof(buf)-1)); if (copy_from_user(buf, user_buf, buf_size))