user/sven/linux.git, branch v2.6.16.56

Linux 2.6.16.56

2007-11-01T02:23:29Z

Linux 2.6.16.56-rc2

2007-10-28T21:33:36Z

hugetlb: fix size=4G parsing

2007-10-28T21:32:04Z

On 32-bit machines, mount -t hugetlbfs -o size=4G gave a 0GB filesystem, size=5G gave a 1GB filesystem etc: there's no point in masking size with HPAGE_MASK just before shifting its lower bits away, and since HPAGE_MASK is a UL, that removed all the higher bits of the unsigned long long size. Signed-off-by: Hugh Dickins Signed-off-by: Adrian Bunk

hugetlb: fix error return for brk() entering a hugepage region

2007-10-28T21:22:25Z

The lats commit causes the wrong return value. is_hugepage_only_range() is a boolean, so we should return -EINVAL rather than 1. Also - we can use "mm" instead of looking up "current->mm" again. Signed-off-by: Hugh Dickins Signed-off-by: Adrian Bunk

hugetlb: check for brk() entering a hugepage region

2007-10-28T21:20:34Z

Unlike mmap(), the codepath for brk() creates a vma without first checking that it doesn't touch a region exclusively reserved for hugepages. On powerpc, this can allow it to create a normal page vma in a hugepage region, causing oopses and other badness. Add a test to prevent this. With this patch, brk() will simply fail if it attempts to move the break into a hugepage reserved region. Signed-off-by: David Gibson Signed-off-by: Adrian Bunk

[IA64] fix ia64 is_hugepage_only_range

2007-10-28T20:40:41Z

fix is_hugepage_only_range() definition to be "overlaps" instead of "within architectural restricted hugetlb address range". Simplify the ia64 specific code that used to use is_hugepage_only_range() to just check which region the address is in. Signed-off-by: Ken Chen Signed-off-by: Tony Luck Signed-off-by: Adrian Bunk

Linux 2.6.16.56-rc1

2007-10-19T17:15:19Z

Don't allow the stack to grow into hugetlb reserved regions (CVE-2007-3739)

2007-10-19T17:05:10Z

When expanding the stack, we don't currently check if the VMA will cross into an area of the address space that is reserved for hugetlb pages. Subsequent faults on the expanded portion of such a VMA will confuse the low-level MMU code, resulting in an OOPS. Check for this. Signed-off-by: Adam Litke Signed-off-by: Adrian Bunk

drivers/video/macmodes.c:mac_find_mode() mustn't be __init

2007-10-19T16:51:07Z

If it's EXPORT_SYMBOL'ed it can't be __devinit. Reported by Mikael Pettersson. Signed-off-by: Adrian Bunk

hugetlb: fix prio_tree unit (CVE-2007-4133)

2007-10-19T12:30:18Z

hugetlb_vmtruncate_list was misconverted to prio_tree: its prio_tree is in units of PAGE_SIZE (PAGE_CACHE_SIZE) like any other, not HPAGE_SIZE (whereas its radix_tree is kept in units of HPAGE_SIZE, otherwise slots would be absurdly sparse). At first I thought the error benign, just calling __unmap_hugepage_range on more vmas than necessary; but on 32-bit machines, when the prio_tree is searched correctly, it happens to ensure the v_offset calculation won't overflow. As it stood, when truncating at or beyond 4GB, it was liable to discard pages COWed from lower offsets; or even to clear pmd entries of preceding vmas, triggering exit_mmap's BUG_ON(nr_ptes). Signed-off-by: Hugh Dickins Signed-off-by: Adrian Bunk