linux-kernel - Re: [PATCH 14 of 33] IB/ipath - fix port sharing on powerpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Mar 2007 14:27:28 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	"Bryan O'Sullivan" <bos@...hscale.com>
Cc:	openib-general@...nfabrics.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14 of 33] IB/ipath - fix port sharing on powerpc

 > The port sharing feature mixed kernel virtual addresses as well as
 > physical addresses for the offset used to describe the mmap address to map
 > the InfiniPath hardware into user space.  This had a conflict on powerpc.
 > The new scheme converts it to a physical address so it doesn't conflict
 > with chip addresses and yet still fits in 40/44 bits so it isn't truncated
 > by 32-bit applications calling mmap64().

 > +/*
 > + * Convert kernel virtual addresses to physical addresses so they don't
 > + * potentially conflict with the chip addresses used as mmap offsets.
 > + * It doesn't really matter what mmap offset we use as long as we can
 > + * interpret it correctly. 
 > + */

 > +		paddr = page_to_pfn(page) << PAGE_SHIFT;
 > +
 > +	return paddr;

what guarantee is there that physical addresses fit into any number
of bits?  Couldn't I have a NUMA system or something that puts
physical memory starting at an offset of 1 << 48 or whatever?

 - R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/