From patchwork Fri Apr 1 18:45:16 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 8727081 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B7F3EC0553 for ; Fri, 1 Apr 2016 18:46:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B2FAB203A0 for ; Fri, 1 Apr 2016 18:46:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BEF072039D for ; Fri, 1 Apr 2016 18:46:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753138AbcDASqQ (ORCPT ); Fri, 1 Apr 2016 14:46:16 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:33618 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbcDASpz (ORCPT ); Fri, 1 Apr 2016 14:45:55 -0400 Received: by mail-pa0-f46.google.com with SMTP id zm5so97361083pac.0 for ; Fri, 01 Apr 2016 11:45:55 -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=VUgOx+HTbKPuATd8sJDurerXyC0pLMHjQ/gYlP3HNBo=; b=hlFSVzsZGnSIbaDs0t4Dazf4oRZriYQeKVxus6P/szSPTaH6CWm8sHFssjyyIFax2T KQ/mMg7qtndlcV24QR2wC8qpBM3TTggWQtdig76KN2oQ/pzcDMQ2pR0KFBtjsIEm8k8E +9VAaeOs7P/e+zeWbg0xH8T+JcpI15iKQrQIUKnnwADRUJbyd1RRojpDBgV0TYdbp5sC B8O3Gc2AZB0FZpxEr0BSlT0UlRFUNTz8M5acLWwl0CNobVRbhWEPqcf5ny+ASVlfyTJ7 wXflUJ5CgV4GHonZKQpmEdud11tpSooxyrERUFb7pgWjDrqWZ9Nz6M41ZIApN2DhbimU BUAA== 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=VUgOx+HTbKPuATd8sJDurerXyC0pLMHjQ/gYlP3HNBo=; b=TjRs54UEIkKQCQ3yeE9FDEpPtftfVrBzPQeWZnu+uNNz0Wz13G+XOVP2xMSu6SnXiP cfp+SLOvq1yPkz8NBCn2IDR8FcGpDwhUWxCoRMuloja32SMjZQzw/e1Ymg5LtBwnTTDK CwD3Qv9iyh/u4HcDeJFgWisDfl32NjVyD06F/TXmgiKnpj0sT4hOufuVdYKw+I2SnMwi y1SwIpJK/F4+Nqzi65e0G4iSIQWvHL3UtdN1Ns2QqcpmmiMDYi6OOkFKbLTPkj1Hcq4P peb6X2L3bgc3GKqbgQzJCIeAowvLEkUseGtD6z0Sw0ZJqhUimM5RnjE+a7ojQ0W/Nkqm gsXA== X-Gm-Message-State: AD7BkJLvy8QMSvtT8H+8rZT5TMdQ/jjiYWIcKRTbnffH6sMiP+rf8mgrv40GZmAGUv4B+RGe X-Received: by 10.66.250.199 with SMTP id ze7mr33353188pac.103.1459536354876; Fri, 01 Apr 2016 11:45:54 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::8:103a]) by smtp.gmail.com with ESMTPSA id g70sm21627401pfj.13.2016.04.01.11.45.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Apr 2016 11:45:54 -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 RESEND 2/2] coredump: only charge written data against RLIMIT_CORE Date: Fri, 1 Apr 2016 11:45:16 -0700 Message-Id: <7e5fd977eef4d8d2d2ed650dbbbaf4b4f0d4bc6a.1459535917.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. --- 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..62bd4eddd0bf 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 += nr; 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; }; /*