Re: [PATCH 1/1] xendump: Use off_t not long for 32bit code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/14 14:56, Daniel Kiper wrote:
On Wed, Jun 11, 2014 at 02:36:23PM -0400, Dave Anderson wrote:

----- Original Message -----
On Wed, Jun 11, 2014 at 01:28:27PM -0400, Don Slutz wrote:
This enables crash to handle xen dumps that are larger then 4G
in size in 32bit mode.

Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
---
This is the same as was sent as an attachment.  Just a clean top post.

  x86.c     | 10 ++++-----
  x86_64.c  | 10 ++++-----
  xendump.c | 74
  +++++++++++++++++++++++++++++++++------------------------------
  xendump.h |  6 +++---
  4 files changed, 52 insertions(+), 48 deletions(-)

diff --git a/x86.c b/x86.c
index 833a11b..608bb88 100644
--- a/x86.c
+++ b/x86.c
@@ -4897,7 +4897,7 @@ x86_xendump_p2m_create(struct xendump_data *xd)
  		    "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n",
  			ctrlreg_offset);

-	offset = (off_t)xd->xc_core.header.xch_ctxt_offset +
+	offset = xd->xc_core.header.xch_ctxt_offset +
  		(off_t)ctrlreg_offset;
Good job. However, as I can see this fix requires explicit type
conversions in many places. I am almost sure that next time when
somebody improve the code then he/she will forget about this needed
type conversions. So maybe it is worth creating new struct which
will have xch_ctxt_offset as off_t instead of unsigned long and
do this conversion once somewhere.

Daniel
Hi Daniel,

I'm confused -- isn't that exactly what Don has done?  I.e., changing the
type of the xen_core_header's xch_ctxt_offset, xch_index_offset and
xch_pages_offset members from unsigned long to off_t.  It does require
explicit type conversions when assigning them from the obsoleted
xenctrl.h xc_core_header structures where they were/are unsigned ints,
and when assigning them from shdr.sh_offset values, but for the most
part, the patch mostly removes the (off_t) casts.
Ugh... Sorry... What a shame... Forget it... I was reading in my
imagination not what was written...

I don't have any sample 32-bit Xen ELF coredumps larger than 4GB,
I do not have either.

I only have an ELF64 dump of a 32bit guest with 8G.  Since it is
2.7G of non-zero data (1.2G    centos-6.4-i386-sparse.tgz) I do not know
how to get this to Dave. The .tgz includes the vmlinux, 3g and 8g xen hvm
dumps from a xen 4.3.0 system.

   -Don Slutz

and our support organization has never filed any bugs reporting
this issue.  (Could it require later versions of the dom0 kernel
or other Xen sources?)  Anyway, the patch seems safe enough, and
This issue was discovered by guy from Huawei on Xen 4.1.2.
I will ask him to do a test.

doesn't break any of my other sample x86 and x86_64 Xen dumpfiles.
I agree.

Daniel

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux