public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH RESEND 0/2] fix RLIMIT_CORE accounting for sparse dumps
@ 2016-04-01 18:45 Omar Sandoval
  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
  0 siblings, 2 replies; 3+ messages in thread
From: Omar Sandoval @ 2016-04-01 18:45 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, linux-kernel, kernel-team, Omar Sandoval

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

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-04-01 18:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-01 18:45 [PATCH RESEND 0/2] fix RLIMIT_CORE accounting for sparse dumps Omar Sandoval
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox