On 05/03/16 at 11:21am, Russell King wrote: > We need to use 64-bit file IO when mapping system memory and the core > dump file as we may be running on a LPAE system, otherwise we risk > mapping memory we shouldn't, and causing a kernel oops: > > Unhandled fault: asynchronous external abort (0x211) at 0x00000000 > pgd = edd2c740 > [00000000] *pgd=82ec98003, *pmd=82dcd2003, *pte=00000000 > > Signed-off-by: Russell King <rmk at arm.linux.org.uk> > --- > kexec/arch/arm/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile > index 38137d7..60e433a 100644 > --- a/kexec/arch/arm/Makefile > +++ b/kexec/arch/arm/Makefile > @@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%) > > arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt > > +# We want 64-bit file IO for kdump to work correctly on LPAE systems > +arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64 > + It makes sense in this situation. In "man 2 stat" and /usr/include/features.h, we can find the relevant information. EOVERFLOW pathname or fd refers to a file whose size, inode number, or number of blocks cannot be represented in, respectively, the types off_t, ino_t, or blkcnt_t. This error can occur when, for example, an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (1<<31)-1 bytes. Ack this patch. Acked-by: Baoquan He <bhe at redhat.com> Baoquan Thanks
