Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1560239 > unrolled thread
| Started by | David Miller <davem@davemloft.net> |
|---|---|
| First post | 2017-01-17 04:50 +0100 |
| Last post | 2017-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.
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
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2017-01-17 04:50 +0100 |
| Subject | Re: [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]
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Date | 2017-01-17 09:00 +0100 |
| Subject | Re: [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]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2017-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]
| From | Dave Kleikamp <dave.kleikamp@oracle.com> |
|---|---|
| Date | 2017-01-17 22:10 +0100 |
| Subject | Re: [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