From patchwork Mon Apr 11 18:21:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 8805021 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 7B1359F3D1 for ; Mon, 11 Apr 2016 18:22:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9814120270 for ; Mon, 11 Apr 2016 18:22:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B14F62026D for ; Mon, 11 Apr 2016 18:22:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754798AbcDKSVk (ORCPT ); Mon, 11 Apr 2016 14:21:40 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:34951 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754794AbcDKSVj (ORCPT ); Mon, 11 Apr 2016 14:21:39 -0400 Received: by mail-pf0-f177.google.com with SMTP id n1so128535315pfn.2 for ; Mon, 11 Apr 2016 11:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=oNsDwFF1yFXfFSv9zedQFbVDYRPS2EpiaWktYuH5POg=; b=O7OH1A7qcodvrrbu/CkjnnXOtw0yfUk7AihKBQO7Kw88/m9dKsiVG7ySAUl270+H15 L8jG/d1c4uLtpxVCqSi3WIvu9u0V6itxA1tye8AQmZoPX8jG5RZnDURkaE0QNYwOmII3 WkiHST1cuW+VB/7MLAriwj7a0J3kkkpAQmmTwwHkl4UlmyTA7kpXL+NoQmw3EFlOUhp4 Ht2oYQxHpY+9vq4soyohbZbixzFp3l3TI/xaWR54/3n12do9PpWp1whHE/T5lrvcx4oN pwfDbGnYORhZQvjlJtBMlhw4VTpXD8b0OxWNZ6gJvJCbp94Nir9G8U0eehnTHIFR8JT2 BMVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=oNsDwFF1yFXfFSv9zedQFbVDYRPS2EpiaWktYuH5POg=; b=DwE9ZRCC6rxw9VdUCqkEuAIBXAQMYSV+b13i1QfzHXcy8qS7Q3GUqiRSD19YIaZV7A Z85AQGV7rn2Fx4k+70gn6HESHQrI3CcCpPAxpclItv0ntvTDrPpPbVfF7793BOASpfXb s0gJoecL+az8/sJ/NmDmNwiz5l2HXpIiOZA+xCg8Nj21QCfFSDOCjUH5tPG4Jlz8N1xN P5tbrtTjAij9rPggtRJwGJTaU+llJW568EA366HRmnl6x1sQnZ/wncHab96fM3nfcut7 HckSwGsaJBzs9qtpmbCoZum4YRANlKvLze84TJR+z7mNInCajzxXpuqwVZvCG016CoMA aOoQ== X-Gm-Message-State: AD7BkJKwjxvkpo8xlf/wIfjn0qPWZL0oK6rgslOoWLxAVfN0uq1ZO2t+GkYOlS7wV8lab0by X-Received: by 10.98.76.194 with SMTP id e63mr35031421pfj.89.1460398898413; Mon, 11 Apr 2016 11:21:38 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::b:2b53]) by smtp.gmail.com with ESMTPSA id 17sm37802658pfs.40.2016.04.11.11.21.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Apr 2016 11:21:37 -0700 (PDT) From: Omar Sandoval X-Google-Original-From: Omar Sandoval To: Al Viro Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Omar Sandoval Subject: [PATCH v3 2/2] coredump: only charge written data against RLIMIT_CORE Date: Mon, 11 Apr 2016 11:21:29 -0700 Message-Id: <36e748cf9ab3181f6e325850cab7aabb758dd026.1460398708.git.osandov@fb.com> X-Mailer: git-send-email 2.8.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Omar Sandoval Commit 9b56d54380ad ("dump_skip(): dump_seek() replacement taking coredump_params") introduced a regression with regard to RLIMIT_CORE. Previously, when a core dump was sparse, only the data that was actually written out would count against the limit. Now, the sparse ranges are also included, which leads to truncated core dumps when the actual disk usage is still well below the limit. Restore the old behavior by only counting what gets emitted and ignoring what gets skipped. Signed-off-by: Omar Sandoval --- fs/coredump.c | 5 ++--- include/linux/binfmts.h | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index 9db0c514438e..492c2db25dc9 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -782,7 +782,7 @@ int dump_emit(struct coredump_params *cprm, const void *addr, int nr) struct file *file = cprm->file; loff_t pos = file->f_pos; ssize_t n; - if (pos + nr > cprm->limit) + if (cprm->written + nr > cprm->limit) return 0; while (nr) { if (dump_interrupted()) @@ -791,6 +791,7 @@ int dump_emit(struct coredump_params *cprm, const void *addr, int nr) if (n <= 0) return 0; file->f_pos = pos; + cprm->written += n; nr -= n; } return 1; @@ -802,8 +803,6 @@ int dump_skip(struct coredump_params *cprm, size_t nr) static char zeroes[PAGE_SIZE]; struct file *file = cprm->file; if (file->f_op->llseek && file->f_op->llseek != no_llseek) { - if (file->f_pos + nr > cprm->limit) - return 0; if (dump_interrupted() || file->f_op->llseek(file, nr, SEEK_CUR) < 0) return 0; diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h index 39c6d6e1234e..576e4639ca60 100644 --- a/include/linux/binfmts.h +++ b/include/linux/binfmts.h @@ -64,6 +64,7 @@ struct coredump_params { struct file *file; unsigned long limit; unsigned long mm_flags; + loff_t written; }; /*