From patchwork Sat May 12 00:17:17 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anton Vorontsov X-Patchwork-Id: 8536 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id D144D23E20 for ; Sat, 12 May 2012 00:18:45 +0000 (UTC) Received: from mail-yw0-f52.google.com (mail-yw0-f52.google.com [209.85.213.52]) by fiordland.canonical.com (Postfix) with ESMTP id A1BC6A18C24 for ; Sat, 12 May 2012 00:18:45 +0000 (UTC) Received: by yhpp61 with SMTP id p61so4054664yhp.11 for ; Fri, 11 May 2012 17:18:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf:date:from :to:cc:subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:x-gm-message-state; bh=iDlieBRfYfqlibcNeEk3LXLkfv0uvz23hreeMRTSPIc=; b=h1SN7PvgDda9aKgI9XMqiYL8T7tcLZLkpXW+Jh8oLVOGzP+/0+rVncKBQ4J+ATpbCR tC4ziK0Ro9HP2ndDhCU2fn3RUI4gtx9ZQ5vEs51k+M5pgeEzt4U5kJm+jgkTV67dC/mf aGs7UgsoqXLyknBkHaXRqGNoXhHoxA9SujAWKeu2MiZiLbhpPNRqEBxXgpDax/J8ZAih nxLSDt9eXtM5wd0xJXo9Sw7AnHHqdz/s0rP8sUzYiXXsbMXBItPLs6eEc/xywNqkp3Ok Xgp1K/qvYepuZlC4oJS4SiNm6v5Z5kpHJbCdWntAtdH9ZwNeH0L5ZDRlEonzFmjtVRFB fTYg== Received: by 10.50.220.136 with SMTP id pw8mr10898igc.1.1336781924961; Fri, 11 May 2012 17:18:44 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.231.73.147 with SMTP id q19csp211476ibj; Fri, 11 May 2012 17:18:44 -0700 (PDT) Received: by 10.68.213.101 with SMTP id nr5mr129825pbc.131.1336781924149; Fri, 11 May 2012 17:18:44 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx.google.com with ESMTPS id p7si16197983pbk.104.2012.05.11.17.18.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 17:18:44 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.160.50 is neither permitted nor denied by best guess record for domain of anton.vorontsov@linaro.org) client-ip=209.85.160.50; Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.160.50 is neither permitted nor denied by best guess record for domain of anton.vorontsov@linaro.org) smtp.mail=anton.vorontsov@linaro.org Received: by mail-pb0-f50.google.com with SMTP id rr4so4860215pbb.37 for ; Fri, 11 May 2012 17:18:43 -0700 (PDT) Received: by 10.68.132.103 with SMTP id ot7mr278993pbb.59.1336781923913; Fri, 11 May 2012 17:18:43 -0700 (PDT) Received: from localhost (c-71-204-165-222.hsd1.ca.comcast.net. [71.204.165.222]) by mx.google.com with ESMTPS id pd3sm14231765pbc.53.2012.05.11.17.18.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 17:18:43 -0700 (PDT) Date: Fri, 11 May 2012 17:17:17 -0700 From: Anton Vorontsov To: Greg Kroah-Hartman , Kees Cook , Colin Cross Cc: Arnd Bergmann , John Stultz , arve@android.com, Rebecca Schultz Zavin , Jesper Juhl , Randy Dunlap , Stephen Boyd , Thomas Meyer , Andrew Morton , Marco Stornelli , WANG Cong , linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, linaro-kernel@lists.linaro.org, patches@linaro.org, kernel-team@android.com Subject: [PATCH 02/11] persistent_ram: Fix buffer size clamping during writes Message-ID: <20120512001717.GB14782@lizard> References: <20120512001506.GA8653@lizard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120512001506.GA8653@lizard> User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmLF3ZXXwtp1ZL0+Ar2sZXE5FIyCWIkcahWQ/K/in8yJk6q29kZqiXkKW8Lh5EFkSC0bAuc This is a longstanding bug, almost unnoticeable when calling persistent_ram_write() for small buffers. But when called for large data buffers, the write routine behaves incorrectly, as the size may never update: instead of clamping the size to the maximum buffer size, buffer_size_add_clamp() returns an error (which is never checked by the write routine, btw). To fix this, we now use buffer_size_add() that actually clamps the size to the max value. Also remove buffer_size_add_clamp(), it is no longer needed. Signed-off-by: Anton Vorontsov Acked-by: Colin Cross --- drivers/staging/android/persistent_ram.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/staging/android/persistent_ram.c b/drivers/staging/android/persistent_ram.c index 12444fd..13a12bc 100644 --- a/drivers/staging/android/persistent_ram.c +++ b/drivers/staging/android/persistent_ram.c @@ -79,23 +79,6 @@ static inline void buffer_size_add(struct persistent_ram_zone *prz, size_t a) } while (atomic_cmpxchg(&prz->buffer->size, old, new) != old); } -/* increase the size counter, retuning an error if it hits the max size */ -static inline ssize_t buffer_size_add_clamp(struct persistent_ram_zone *prz, - size_t a) -{ - size_t old; - size_t new; - - do { - old = atomic_read(&prz->buffer->size); - new = old + a; - if (new > prz->buffer_size) - return -ENOMEM; - } while (atomic_cmpxchg(&prz->buffer->size, old, new) != old); - - return 0; -} - static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz, uint8_t *data, size_t len, uint8_t *ecc) { @@ -300,7 +283,7 @@ int notrace persistent_ram_write(struct persistent_ram_zone *prz, c = prz->buffer_size; } - buffer_size_add_clamp(prz, c); + buffer_size_add(prz, c); start = buffer_start_add(prz, c);