[PATCH] i386 pci: Handle mmaping 64bit bars.

[PATCH] i386 pci: Handle mmaping 64bit bars.

[Eric W. Biederman]

While reading through pci_mmap_page_range I realized that if don't
properly handle 64bit bars in the 32bit kernel.

Without the added cast the shift will be done in 32bit despite being
assigned to a 64bit variable and if we are mmaping an address above
4G things will do the wrong thing.

Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
 arch/x86/pci/i386.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 5ead808..e9d5636 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -283,7 +283,7 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
 			enum pci_mmap_state mmap_state, int write_combine)
 {
 	unsigned long prot;
-	u64 addr = vma->vm_pgoff << PAGE_SHIFT;
+	u64 addr = ((u64)vma->vm_pgoff) << PAGE_SHIFT;
 	unsigned long len = vma->vm_end - vma->vm_start;
 	unsigned long flags;
 	unsigned long new_flags;
-- 
1.6.0.6

Re: [PATCH] i386 pci: Handle mmaping 64bit bars.

[H. Peter Anvin]

Eric W. Biederman wrote:
> While reading through pci_mmap_page_range I realized that if don't
> properly handle 64bit bars in the 32bit kernel.
> 
> Without the added cast the shift will be done in 32bit despite being
> assigned to a 64bit variable and if we are mmaping an address above
> 4G things will do the wrong thing.

Hm... this really should be resource_size_t, no?

> -	u64 addr = vma->vm_pgoff << PAGE_SHIFT;
> +	u64 addr = ((u64)vma->vm_pgoff) << PAGE_SHIFT;

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] i386 pci: Handle mmaping 64bit bars.

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>> While reading through pci_mmap_page_range I realized that if don't
>> properly handle 64bit bars in the 32bit kernel.
>> 
>> Without the added cast the shift will be done in 32bit despite being
>> assigned to a 64bit variable and if we are mmaping an address above
>> 4G things will do the wrong thing.
>
> Hm... this really should be resource_size_t, no?
>
>> -	u64 addr = vma->vm_pgoff << PAGE_SHIFT;
>> +	u64 addr = ((u64)vma->vm_pgoff) << PAGE_SHIFT;

It is a parameter to the reserve_memtype and free_memtype functions,
which take a u64 so the type looks ok.

If I was going to quibble I would argue that those functions should
take a pfn instead of a u64...

Eric