Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751858AbcCKU1P (ORCPT ); Fri, 11 Mar 2016 15:27:15 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:55904 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750953AbcCKU1M (ORCPT ); Fri, 11 Mar 2016 15:27:12 -0500 Date: Fri, 11 Mar 2016 12:27:11 -0800 From: Andrew Morton To: Dave Young Cc: linux-kernel@vger.kernel.org, d.hatayama@jp.fujitsu.com, bhe@redhat.com, vgoyal@redhat.com, kexec@lists.infradead.org, nasa4836@gmail.com, mhuang@redhat.com Subject: Re: [PATCH V2] proc-vmcore: wrong data type casting fix Message-Id: <20160311122711.f738d878070641f113dfd348@linux-foundation.org> In-Reply-To: <20160311084248.GA9417@dhcp-128-65.nay.redhat.com> References: <20160311084248.GA9417@dhcp-128-65.nay.redhat.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2321 Lines: 64 On Fri, 11 Mar 2016 16:42:48 +0800 Dave Young wrote: > On i686 PAE enabled machine the contiguous physical area could be large > and it can cause trimming down variables in below calculation in > read_vmcore() and mmap_vmcore(): > > tsz = min_t(size_t, m->offset + m->size - *fpos, buflen); > > Then the real size passed down is not correct any more. > Suppose m->offset + m->size - *fpos being truncated to 0, buflen >0 then > we will get tsz = 0. It is of course not an expected result. I don't really understand this. vmcore.offset if loff_t which is 64-bit vmcore.size is long long *fpos is loff_t so the expression should all be done with 64-bit arithmetic anyway. Maybe buflen (size_t) has the wrong type, but the result of the other expression should be in-range by the time we come to doing the comparison. > During our tests there are two problems caused by it: > 1) read_vmcore will refuse to continue so makedumpfile fails. > 2) mmap_vmcore will trigger BUG_ON() in remap_pfn_range(). > > Use unsigned long long in min_t instead so that the variables are not > truncated. > > Signed-off-by: Baoquan He > Signed-off-by: Dave Young I think we'll need a cc:stable here. > --- linux-x86.orig/fs/proc/vmcore.c > +++ linux-x86/fs/proc/vmcore.c > @@ -231,7 +231,9 @@ static ssize_t __read_vmcore(char *buffe > > list_for_each_entry(m, &vmcore_list, list) { > if (*fpos < m->offset + m->size) { > - tsz = min_t(size_t, m->offset + m->size - *fpos, buflen); > + tsz = (size_t)min_t(unsigned long long, > + m->offset + m->size - *fpos, > + buflen); This is rather a mess. Can we please try to fix this bug by choosing appropriate types rather than all the typecasting? > start = m->paddr + *fpos - m->offset; > tmp = read_from_oldmem(buffer, tsz, &start, userbuf); > if (tmp < 0) > @@ -461,7 +463,8 @@ static int mmap_vmcore(struct file *file > if (start < m->offset + m->size) { > u64 paddr = 0; > > - tsz = min_t(size_t, m->offset + m->size - start, size); > + tsz = (size_t)min_t(unsigned long long, > + m->offset + m->size - start, size); > paddr = m->paddr + start - m->offset; > if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len, > paddr >> PAGE_SHIFT, tsz,