From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752836AbcDASpz (ORCPT ); Fri, 1 Apr 2016 14:45:55 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:33596 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbcDASpx (ORCPT ); Fri, 1 Apr 2016 14:45:53 -0400 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 0/2] fix RLIMIT_CORE accounting for sparse dumps Date: Fri, 1 Apr 2016 11:45:14 -0700 Message-Id: X-Mailer: git-send-email 2.8.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Omar Sandoval Resending this since it didn't get in -rc1. Rebased on Linus' current tree. Please apply. Original cover letter below: Hi, Someone here reported that they were getting truncated core dumps even when RLIMIT_CORE was larger than the physical memory of the machine. It looks some cleanup patches back in v3.13 [1] changed the behaviour of the limit to also charge for sparse areas of a file. Here's an example in 4.5-rc4, where a.out is: ---- #include int main(int argc, char **argv) { raise(SIGQUIT); return 0; } ---- Make sure that your sysctl kernel.core_pattern isn't piping anywhere, and be aware that there's some stupidity about the units used for ulimit -c in different shells (bash uses 1024-byte blocks, same as what's shown by du by default). ---- # ulimit -c unlimited # ./a.out Quit (core dumped) # du core.248 88 core.248 # du --apparent-size core.248 232 core.248 # ulimit -c 128 # ./a.out Quit (core dumped) # du core.252 64 core.252 # du --apparent-size core.252 72 core.252 ---- These 2 patches restore the original behavior: ---- # ulimit -c 128 # ./a.out Quit (core dumped) # du core.245 88 core.245 # du --apparent-size core.245 232 core.245 ---- Patch 1 gets rid of cprm->written, since as far as I could tell, it's always going to be equal to cprm->file->f_pos. Patch 2 reintroduces cprm->written as the number of bytes actually written to the file, not including what we seek over. This series is based on 4.5-rc4. Al, could you apply these? Thanks! 1: http://lkml.iu.edu/hypermail/linux/kernel/1310.1/00758.html Appendix A: a quick sanity test with the patches applied ---- # ulimit -c unlimited # python -c 'import os, signal; l = [0] * 1024 * 1024; os.kill(os.getpid(), signal.SIGQUIT)' Quit (core dumped) # du core.262 12268 core.262 # du --apparent-size core.262 12628 core.262 # ulimit -c 1024 # python -c 'import os, signal; l = [0] * 1024 * 1024; os.kill(os.getpid(), signal.SIGQUIT)' Quit (core dumped) # du core.266 1024 core.266 # du --apparent-size core.266 1024 core.266 ---- Omar Sandoval (2): coredump: get rid of coredump_params->written coredump: only charge written data against RLIMIT_CORE arch/powerpc/platforms/cell/spufs/coredump.c | 5 +++-- fs/binfmt_elf.c | 2 +- fs/binfmt_elf_fdpic.c | 2 +- fs/coredump.c | 7 ++----- 4 files changed, 7 insertions(+), 9 deletions(-) -- 2.8.0