public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, Omar Sandoval <osandov@fb.com>
Subject: [PATCH RESEND 0/2] fix RLIMIT_CORE accounting for sparse dumps
Date: Fri,  1 Apr 2016 11:45:14 -0700	[thread overview]
Message-ID: <cover.1459535917.git.osandov@fb.com> (raw)

From: Omar Sandoval <osandov@fb.com>

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 <signal.h>

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

             reply	other threads:[~2016-04-01 18:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 18:45 Omar Sandoval [this message]
2016-04-01 18:45 ` [PATCH RESEND 1/2] coredump: get rid of coredump_params->written Omar Sandoval
2016-04-01 18:45 ` [PATCH RESEND 2/2] coredump: only charge written data against RLIMIT_CORE Omar Sandoval

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1459535917.git.osandov@fb.com \
    --to=osandov@osandov.com \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osandov@fb.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox