Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1560239 > unrolled thread

Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files

Started byDavid Miller <davem@davemloft.net>
First post2017-01-17 04:50 +0100
Last post2017-01-17 22:10 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH RESEND] coredump: Ensure proper size of sparse core  files David Miller <davem@davemloft.net> - 2017-01-17 04:50 +0100
    Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files Christoph Hellwig <hch@infradead.org> - 2017-01-17 09:00 +0100
      Re: [PATCH RESEND] coredump: Ensure proper size of sparse core  files David Miller <davem@davemloft.net> - 2017-01-17 21:50 +0100
        Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files Dave Kleikamp <dave.kleikamp@oracle.com> - 2017-01-17 22:10 +0100

#1560239 — Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files

FromDavid Miller <davem@davemloft.net>
Date2017-01-17 04:50 +0100
SubjectRe: [PATCH RESEND] coredump: Ensure proper size of sparse core files
Message-ID<t0sWt-1EX-7@gated-at.bofh.it>
From: Dave Kleikamp <dave.kleikamp@oracle.com>
Date: Wed, 11 Jan 2017 13:25:00 -0600

> If the last section of a core file ends with an unmapped or zero page,
> the size of the file does not correspond with the last dump_skip() call.
> gdb complains that the file is truncated and can be confusing to users.
> 
> After all of the vma sections are written, make sure that the file size
> is no smaller than the current file position.
> 
> This problem can be demonstrated with gdb's bigcore testcase on the
> sparc architecture.
> 
> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>

The lseek() done by dump_skip() should extend the file properly.

Otherwise, everyone would be seeing this problem.

That test case passed all the time when I was last running the GDB
testsuite all the time on sparc64, say 5 years ago.

[toc] | [next] | [standalone]


#1560310 — Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files

FromChristoph Hellwig <hch@infradead.org>
Date2017-01-17 09:00 +0100
SubjectRe: [PATCH RESEND] coredump: Ensure proper size of sparse core files
Message-ID<t0wQp-4ey-1@gated-at.bofh.it>
In reply to#1560239
On Mon, Jan 16, 2017 at 10:42:43PM -0500, David Miller wrote:
> The lseek() done by dump_skip() should extend the file properly.

lseek never extends a file.  It just moves the current file position.
So if you do not have a write after the lseek it does nothing.

[toc] | [prev] | [next] | [standalone]


#1561007

FromDavid Miller <davem@davemloft.net>
Date2017-01-17 21:50 +0100
Message-ID<t0IRz-3jt-7@gated-at.bofh.it>
In reply to#1560310
From: Christoph Hellwig <hch@infradead.org>
Date: Mon, 16 Jan 2017 23:55:21 -0800

> On Mon, Jan 16, 2017 at 10:42:43PM -0500, David Miller wrote:
>> The lseek() done by dump_skip() should extend the file properly.
> 
> lseek never extends a file.  It just moves the current file position.
> So if you do not have a write after the lseek it does nothing.

Ok, then the only other feedback I have is that we should probably
defer this truncate() call until the last possible dump write occurs
rather than right after the VMA loop.

[toc] | [prev] | [next] | [standalone]


#1561021 — Re: [PATCH RESEND] coredump: Ensure proper size of sparse core files

FromDave Kleikamp <dave.kleikamp@oracle.com>
Date2017-01-17 22:10 +0100
SubjectRe: [PATCH RESEND] coredump: Ensure proper size of sparse core files
Message-ID<t0JaV-3FT-3@gated-at.bofh.it>
In reply to#1561007
On 01/17/2017 02:44 PM, David Miller wrote:
> From: Christoph Hellwig <hch@infradead.org>
> Date: Mon, 16 Jan 2017 23:55:21 -0800
> 
>> On Mon, Jan 16, 2017 at 10:42:43PM -0500, David Miller wrote:
>>> The lseek() done by dump_skip() should extend the file properly.
>>
>> lseek never extends a file.  It just moves the current file position.
>> So if you do not have a write after the lseek it does nothing.
> 
> Ok, then the only other feedback I have is that we should probably
> defer this truncate() call until the last possible dump write occurs
> rather than right after the VMA loop.

Yeah. That's fine with me.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web