6,534
edits
Changes
created
== Changes ==
* Updated libata and sky2 drivers.
* Small simfs/vzdq/ubc/stats fixes.
* Mainstream bugs and security fixes.
=== Configs ===
Same as {{Kernel link|2.6.8|022stab076.1}} plus:
* +<code>CONFIG_SKY2=m</code>
* +<code>CONFIG_PARTITION_ADVANCED=y</code>
* +<code>CONFIG_EFI_PARTITION=y</code>
* +<code>CONFIG_OPROFILE=m</code>
<includeonly>[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]</includeonly><noinclude>
=== Patches ===
==== diff-ve-sched-stat-iowait-20060417 ====
<div class="change">Patch from Dmitry (dim@):
per VPS i/o wait time was accounted wrongly as presense
of uninterruptible tasks, not those in IO wait state.
[http://forum.openvz.org/index.php?t=tree&goto=2686&#msg_2686 http://forum.openvz.org/index.php?t=tree&goto=2686&#msg_2686]
</div>
==== diff-virtinfo-faudit-statfs ====
'''diff-simfs-statfs-20060421'''<br/>
<div class="change">Patch from Pavel (xemul@):
Compat layer in 64bit systems didn't call faudit
on statfs calls. Now faudit uses struct kstatfs
for patching statfs data and compat layer uses it.
{{bug|142}}.
</div>
==== diff-ms-prio-tree-20060420 ====
<div class="change">Patch from mainstream:<br/>
[PATCH] prio_tree: fix prio_tree_expand corner case
Currently we use prio_tree_root->index_bits to optimize the height of both
the initial heap-and-radix indexed levels of a prio_tree as well as the
heap-and-size indexed overflow-sub-trees. Please see the accompanying
prio_tree documentation patch for further details.
When index_bits is increased in prio_tree_expand we shuffle the initial
heap-and-radix indexed levels to make sure that vmas are placed in the tree
at appropriate places. Similarly, since the overflow-sub-trees' heights
also depend on prio_tree_root->index_bits we should shuffle all the
overflow-sub-trees when index_bits changes. However, I missed to take care
of this in my implementation.
Recently Stefan Hornburg (Racke) reported the problem and patiently tested
the trace patches. Hugh Dickins produced the trace patches that helped to
detect the bug. Moreover, Hugh reduced the crash test case to few lines of
code. Thanks to both of them.
The easy fix is to disable prio_tree_expand code completely. That may lead
to skewed trees in some common cases. Hence, this patch takes a different
approach.
This patch fixes the problem by not optimizing the height of the
overflow-sub-trees using prio_tree_root->index_bits. Now all
overflow-sub-trees use full BITS_PER_LONG bits of size_index to place the
vmas (that have the same start_vm_pgoff) in an overflow-sub-tree.
This may result in skewed overflow-sub-trees because all bits in vm_pgoff
above prio_tree_root->index_bits will be 0 (zero). However, processes
rarely map many vmas with the same start_vm_pgoff and different
end_vm_pgoff. Therefore, such skewed sub-trees should be very rare.
Signed-off-by: Rajesh Venkatasubramanian <vrajesh@umich.edu><br/>
Signed-off-by: Andrew Morton <akpm@osdl.org><br/>
Signed-off-by: Linus Torvalds <torvalds@osdl.org><br/>
[http://lkml.org/lkml/2004/9/20/104 http://lkml.org/lkml/2004/9/20/104]
<br/>
[http://www.thisishull.net/showthread.php?t=44185 http://www.thisishull.net/showthread.php?t=44185]
<br/>
[http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.326.10?nav=index.html|src/|src/mm|related/mm/prio_tree.c http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.326.10?nav=index.html|src/|src/mm|related/mm/prio_tree.c]
<br/>
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@418eea50tBOvxQPlZsh__8RNvMAz6Q http://linux.bkbits.net:8080/linux-2.6/gnupatch@418eea50tBOvxQPlZsh__8RNvMAz6Q]
Bug #61423.
</div>
==== diff-ve-vestat-misprint ====
<div class="change">Patch from Kirill (dev@):<br/>
Fixed small misprint in /proc/vz/vestat.
User time in jiffies was incorrect.
</div>
==== diff-ms-ip-route-input: ====
<div class="change">Patch from mainstream:<br/>
[PATCH] ip_route_input panic fix (CVE-2006-1525)
This fixes [http://bugzilla.kernel.org/show_bug.cgi?id=6388 kernel.org bug #6388].
The bug is caused by ip_route_input dereferencing skb->nh.protocol of
the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
it). It only happens if the route requested is for a multicast IP
address.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org><br/>
Signed-off-by: David S. Miller <davem@davemloft.net><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de><br/>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=a0b277b4fdcbc24c26af7c5d019e9448a51c79cf
</div>
==== diff-ms-shmem-writeable ====
<div class="change">Patch from mainstream:<br/>
[PATCH] shmat: stop mprotect from giving write permission to a readonly attachment ({{CVE|2006-1524}})<br/>
I found that all of 2.4 and 2.6 have been letting mprotect give write
permission to a readonly attachment of shared memory, whether or not IPC
would give the caller that permission.
SUS says "The behaviour of this function [mprotect] is unspecified if the
mapping was not established by a call to mmap", but I don't think we can
interpret that as allowing it to subvert IPC permissions.
I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
the patch below reproduces that behaviour - mprotect cannot be used to add
write permission to a shared memory segment attached readonly.
This patch is simple, and I'm sure it's what we should have done in 2.4.0:
if you want to go on to switch write permission on and off with mprotect,
just don't attach the segment readonly in the first place.
However, we could have accumulated apps which attach readonly (even though
they would be permitted to attach read/write), and which subsequently use
mprotect to switch write permission on and off: it's not unreasonable.
I was going to add a second ipcperms check in do_shmat, to check for
writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
But security_ipc_permission might do auditing, and it seems wrong to
report an attempt for write permission when there has been none. Or we
could flag the vma as SHM, note the shmid or shp in vm_private_data, and
then get mprotect to check.
But the patch below is a lot simpler: I'd rather stick with it, if we can
convince ourselves somehow that it'll be safe.
Signed-off-by: Hugh Dickins <hugh@veritas.com><br/>
Signed-off-by: Andrew Morton <akpm@osdl.org><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=512dba41bae0ec8de72269167f23b75a4770097d
</div>
==== diff-ms-emt64-rip-on-iret ====
<div class="change">Patch from mainstream:<br/>
[PATCH] x86_64: When user could have changed RIP always force IRET
(CVE-2006-0744)
Intel EM64T CPUs handle uncanonical return addresses differently from
AMD CPUs.
The exception is reported in the SYSRET, not the next instruction.
Thgis leads to the kernel exception handler running on the user stack
with the wrong GS because the kernel didn't expect exceptions on this
instruction.
This version of the patch has the teething problems that plagued an
earlier version fixed.
This is CVE-2006-0744
Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial
patches.
Signed-off-by: Andi Kleen <ak@suse.de><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=6b12095a4a0e1f21bbf83f95f13299ca99d758fe
</div>
==== diff-ms-emt64-execve-cleanup ====
<div class="change">Patch from mainstream:<br/>
[PATCH] x86_64: Clean up execve
Just call IRET always, no need for any special cases.
Needed for the next bug fix.
Signed-off-by: Andi Kleen <ak@suse.de><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=59b2832a31ae2f3279bb5b16ae9b1c4e38e40dea X-Git-Url]
</div>
==== diff-vzdq-mnt-20060410 ====
<div class="change">Patch from Vasily Tarasov (vtaras@openvz.org):
All root dentries are unhashed. We have to check for it in
vzquota_check_dtree().
[http://forum.openvz.org/index.php?t=tree&goto=2552&#msg_2552 http://forum.openvz.org/index.php?t=tree&goto=2552&#msg_2552]
{{bug|133}}.
</div>
==== diff-ubc-page-uncharge-20060414 ====
<div class="change">Patch from Pavel (xemul@):
Pages were first put into global list of free pages and ther - uncharged.
During this gap page_alloc could charge not uncharged yet page thus
causing a BUG().
Moved ub_page_uncharge above freeing and out of local_irq_save to reduce
time spent with irqs off.
[http://forum.openvz.org/index.php?t=msg&th=465&start=0 http://forum.openvz.org/index.php?t=msg&th=465&start=0]
</div>
==== linux-2.6.8.1-sky2-0.13.patch ====
<div class="change">Patch from Vasily (vvs@):
adds alternative driver for Marvell Yukon 2 Gigabit Ethernet adapters
sources were taken from RHEL4u3 kernel 2.6.9-34EL
Bug #60787
</div>
==== linux-2.6.8.1-libata-1.20.patch ====
<div class="change">
libata driver updated up to 1.20 version
Patch prepared by Vasily (vvs@),<br/>
sources were taken from RHEL4U3 kernel 2.6.9-34EL
Obsoleted linux-2.6.8.1-libata-1.11.patch, diff-sis-sata-20060109,
diff-libata-conflicts-20051025.
Bug #52529.
</div>
==== diff-ms-iomap-20060407 ====
<div class="change">Patch from mainstream, required for libata 1.20
torvalds@osdl.org:<br/>
"Add skeleton "generic IO mapping" infrastructure.
Jeff wants to use this to clean up SATA and some network drivers."
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@4145e7a0KXuy7feBNXoM6_I1fMX9Qg http://linux.bkbits.net:8080/linux-2.6/gnupatch@4145e7a0KXuy7feBNXoM6_I1fMX9Qg]
Bug #52529.
</div>
==== diff-ms-x86_64-iomap-20060407 ====
<div class="change">
hunk from mainstream patch, required for libata 1.20/x86_64
[PATCH] amd64 io.h annotations
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk><br/>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@41785c78CIpmP_kGG3VZwbQjAvOp9Q http://linux.bkbits.net:8080/linux-2.6/gnupatch@41785c78CIpmP_kGG3VZwbQjAvOp9Q]
Bug #52529.
</div>
==== linux-2.6.9-gpt-partition-noprobe.patch ====
<div class="change">
Patch from RHEL4u3 kernel 2.6.9-34EL:<br/>
EFI partitioning scheme was reading the last reported sector of the
block device to look for the alternate GPT header, before it had
confirmed that it should. This causes problems for devices with the
following problems: a) those who misreport their size (typically
off-by-one), and b) those who fail when asked to read a block
outside their range.
This patch moves the test for the Protective Master Boot Record (PMBR)
ahead of the tests for the Primary and Alternate GPT headers. If the
PMBR is not valid, the disk is assumed to not be a GPT disk. This can
be overridden with the 'gpt' kernel command line option. If the
Primary GPT header is not valid, the Alternate GPT header is not
probed automatically unless the 'gpt' kernel command line option is
passed. If the both the PMBR and Primary GPT header are valid, then
the Alternate GPT header at the end of the disk is probed.
Also re-enables CONFIG_EFI_PARTITION for all architectures.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com><br/>
[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138563 Red Hat bug #138563]
Bug #61205.
</div>
==== diff-ms-iomem-20051024 ====
'''diff-ms-nthpage-20051020'''<br/>
<div class="change">
added fixes for libata 1.20 update
Bug #52529.
</div>
==== linux-2.6.8.1-drbd-0.7.17.patch ====
<div class="change">
fixed driver version in header file
</div>
</noinclude>
* Updated libata and sky2 drivers.
* Small simfs/vzdq/ubc/stats fixes.
* Mainstream bugs and security fixes.
=== Configs ===
Same as {{Kernel link|2.6.8|022stab076.1}} plus:
* +<code>CONFIG_SKY2=m</code>
* +<code>CONFIG_PARTITION_ADVANCED=y</code>
* +<code>CONFIG_EFI_PARTITION=y</code>
* +<code>CONFIG_OPROFILE=m</code>
<includeonly>[[{{PAGENAME}}/changes#Patches|{{Long changelog message}}]]</includeonly><noinclude>
=== Patches ===
==== diff-ve-sched-stat-iowait-20060417 ====
<div class="change">Patch from Dmitry (dim@):
per VPS i/o wait time was accounted wrongly as presense
of uninterruptible tasks, not those in IO wait state.
[http://forum.openvz.org/index.php?t=tree&goto=2686&#msg_2686 http://forum.openvz.org/index.php?t=tree&goto=2686&#msg_2686]
</div>
==== diff-virtinfo-faudit-statfs ====
'''diff-simfs-statfs-20060421'''<br/>
<div class="change">Patch from Pavel (xemul@):
Compat layer in 64bit systems didn't call faudit
on statfs calls. Now faudit uses struct kstatfs
for patching statfs data and compat layer uses it.
{{bug|142}}.
</div>
==== diff-ms-prio-tree-20060420 ====
<div class="change">Patch from mainstream:<br/>
[PATCH] prio_tree: fix prio_tree_expand corner case
Currently we use prio_tree_root->index_bits to optimize the height of both
the initial heap-and-radix indexed levels of a prio_tree as well as the
heap-and-size indexed overflow-sub-trees. Please see the accompanying
prio_tree documentation patch for further details.
When index_bits is increased in prio_tree_expand we shuffle the initial
heap-and-radix indexed levels to make sure that vmas are placed in the tree
at appropriate places. Similarly, since the overflow-sub-trees' heights
also depend on prio_tree_root->index_bits we should shuffle all the
overflow-sub-trees when index_bits changes. However, I missed to take care
of this in my implementation.
Recently Stefan Hornburg (Racke) reported the problem and patiently tested
the trace patches. Hugh Dickins produced the trace patches that helped to
detect the bug. Moreover, Hugh reduced the crash test case to few lines of
code. Thanks to both of them.
The easy fix is to disable prio_tree_expand code completely. That may lead
to skewed trees in some common cases. Hence, this patch takes a different
approach.
This patch fixes the problem by not optimizing the height of the
overflow-sub-trees using prio_tree_root->index_bits. Now all
overflow-sub-trees use full BITS_PER_LONG bits of size_index to place the
vmas (that have the same start_vm_pgoff) in an overflow-sub-tree.
This may result in skewed overflow-sub-trees because all bits in vm_pgoff
above prio_tree_root->index_bits will be 0 (zero). However, processes
rarely map many vmas with the same start_vm_pgoff and different
end_vm_pgoff. Therefore, such skewed sub-trees should be very rare.
Signed-off-by: Rajesh Venkatasubramanian <vrajesh@umich.edu><br/>
Signed-off-by: Andrew Morton <akpm@osdl.org><br/>
Signed-off-by: Linus Torvalds <torvalds@osdl.org><br/>
[http://lkml.org/lkml/2004/9/20/104 http://lkml.org/lkml/2004/9/20/104]
<br/>
[http://www.thisishull.net/showthread.php?t=44185 http://www.thisishull.net/showthread.php?t=44185]
<br/>
[http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.326.10?nav=index.html|src/|src/mm|related/mm/prio_tree.c http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.326.10?nav=index.html|src/|src/mm|related/mm/prio_tree.c]
<br/>
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@418eea50tBOvxQPlZsh__8RNvMAz6Q http://linux.bkbits.net:8080/linux-2.6/gnupatch@418eea50tBOvxQPlZsh__8RNvMAz6Q]
Bug #61423.
</div>
==== diff-ve-vestat-misprint ====
<div class="change">Patch from Kirill (dev@):<br/>
Fixed small misprint in /proc/vz/vestat.
User time in jiffies was incorrect.
</div>
==== diff-ms-ip-route-input: ====
<div class="change">Patch from mainstream:<br/>
[PATCH] ip_route_input panic fix (CVE-2006-1525)
This fixes [http://bugzilla.kernel.org/show_bug.cgi?id=6388 kernel.org bug #6388].
The bug is caused by ip_route_input dereferencing skb->nh.protocol of
the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
it). It only happens if the route requested is for a multicast IP
address.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org><br/>
Signed-off-by: David S. Miller <davem@davemloft.net><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de><br/>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=a0b277b4fdcbc24c26af7c5d019e9448a51c79cf
</div>
==== diff-ms-shmem-writeable ====
<div class="change">Patch from mainstream:<br/>
[PATCH] shmat: stop mprotect from giving write permission to a readonly attachment ({{CVE|2006-1524}})<br/>
I found that all of 2.4 and 2.6 have been letting mprotect give write
permission to a readonly attachment of shared memory, whether or not IPC
would give the caller that permission.
SUS says "The behaviour of this function [mprotect] is unspecified if the
mapping was not established by a call to mmap", but I don't think we can
interpret that as allowing it to subvert IPC permissions.
I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
the patch below reproduces that behaviour - mprotect cannot be used to add
write permission to a shared memory segment attached readonly.
This patch is simple, and I'm sure it's what we should have done in 2.4.0:
if you want to go on to switch write permission on and off with mprotect,
just don't attach the segment readonly in the first place.
However, we could have accumulated apps which attach readonly (even though
they would be permitted to attach read/write), and which subsequently use
mprotect to switch write permission on and off: it's not unreasonable.
I was going to add a second ipcperms check in do_shmat, to check for
writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
But security_ipc_permission might do auditing, and it seems wrong to
report an attempt for write permission when there has been none. Or we
could flag the vma as SHM, note the shmid or shp in vm_private_data, and
then get mprotect to check.
But the patch below is a lot simpler: I'd rather stick with it, if we can
convince ourselves somehow that it'll be safe.
Signed-off-by: Hugh Dickins <hugh@veritas.com><br/>
Signed-off-by: Andrew Morton <akpm@osdl.org><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=512dba41bae0ec8de72269167f23b75a4770097d
</div>
==== diff-ms-emt64-rip-on-iret ====
<div class="change">Patch from mainstream:<br/>
[PATCH] x86_64: When user could have changed RIP always force IRET
(CVE-2006-0744)
Intel EM64T CPUs handle uncanonical return addresses differently from
AMD CPUs.
The exception is reported in the SYSRET, not the next instruction.
Thgis leads to the kernel exception handler running on the user stack
with the wrong GS because the kernel didn't expect exceptions on this
instruction.
This version of the patch has the teething problems that plagued an
earlier version fixed.
This is CVE-2006-0744
Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial
patches.
Signed-off-by: Andi Kleen <ak@suse.de><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=6b12095a4a0e1f21bbf83f95f13299ca99d758fe
</div>
==== diff-ms-emt64-execve-cleanup ====
<div class="change">Patch from mainstream:<br/>
[PATCH] x86_64: Clean up execve
Just call IRET always, no need for any special cases.
Needed for the next bug fix.
Signed-off-by: Andi Kleen <ak@suse.de><br/>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=59b2832a31ae2f3279bb5b16ae9b1c4e38e40dea X-Git-Url]
</div>
==== diff-vzdq-mnt-20060410 ====
<div class="change">Patch from Vasily Tarasov (vtaras@openvz.org):
All root dentries are unhashed. We have to check for it in
vzquota_check_dtree().
[http://forum.openvz.org/index.php?t=tree&goto=2552&#msg_2552 http://forum.openvz.org/index.php?t=tree&goto=2552&#msg_2552]
{{bug|133}}.
</div>
==== diff-ubc-page-uncharge-20060414 ====
<div class="change">Patch from Pavel (xemul@):
Pages were first put into global list of free pages and ther - uncharged.
During this gap page_alloc could charge not uncharged yet page thus
causing a BUG().
Moved ub_page_uncharge above freeing and out of local_irq_save to reduce
time spent with irqs off.
[http://forum.openvz.org/index.php?t=msg&th=465&start=0 http://forum.openvz.org/index.php?t=msg&th=465&start=0]
</div>
==== linux-2.6.8.1-sky2-0.13.patch ====
<div class="change">Patch from Vasily (vvs@):
adds alternative driver for Marvell Yukon 2 Gigabit Ethernet adapters
sources were taken from RHEL4u3 kernel 2.6.9-34EL
Bug #60787
</div>
==== linux-2.6.8.1-libata-1.20.patch ====
<div class="change">
libata driver updated up to 1.20 version
Patch prepared by Vasily (vvs@),<br/>
sources were taken from RHEL4U3 kernel 2.6.9-34EL
Obsoleted linux-2.6.8.1-libata-1.11.patch, diff-sis-sata-20060109,
diff-libata-conflicts-20051025.
Bug #52529.
</div>
==== diff-ms-iomap-20060407 ====
<div class="change">Patch from mainstream, required for libata 1.20
torvalds@osdl.org:<br/>
"Add skeleton "generic IO mapping" infrastructure.
Jeff wants to use this to clean up SATA and some network drivers."
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@4145e7a0KXuy7feBNXoM6_I1fMX9Qg http://linux.bkbits.net:8080/linux-2.6/gnupatch@4145e7a0KXuy7feBNXoM6_I1fMX9Qg]
Bug #52529.
</div>
==== diff-ms-x86_64-iomap-20060407 ====
<div class="change">
hunk from mainstream patch, required for libata 1.20/x86_64
[PATCH] amd64 io.h annotations
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk><br/>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[http://linux.bkbits.net:8080/linux-2.6/gnupatch@41785c78CIpmP_kGG3VZwbQjAvOp9Q http://linux.bkbits.net:8080/linux-2.6/gnupatch@41785c78CIpmP_kGG3VZwbQjAvOp9Q]
Bug #52529.
</div>
==== linux-2.6.9-gpt-partition-noprobe.patch ====
<div class="change">
Patch from RHEL4u3 kernel 2.6.9-34EL:<br/>
EFI partitioning scheme was reading the last reported sector of the
block device to look for the alternate GPT header, before it had
confirmed that it should. This causes problems for devices with the
following problems: a) those who misreport their size (typically
off-by-one), and b) those who fail when asked to read a block
outside their range.
This patch moves the test for the Protective Master Boot Record (PMBR)
ahead of the tests for the Primary and Alternate GPT headers. If the
PMBR is not valid, the disk is assumed to not be a GPT disk. This can
be overridden with the 'gpt' kernel command line option. If the
Primary GPT header is not valid, the Alternate GPT header is not
probed automatically unless the 'gpt' kernel command line option is
passed. If the both the PMBR and Primary GPT header are valid, then
the Alternate GPT header at the end of the disk is probed.
Also re-enables CONFIG_EFI_PARTITION for all architectures.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com><br/>
[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138563 Red Hat bug #138563]
Bug #61205.
</div>
==== diff-ms-iomem-20051024 ====
'''diff-ms-nthpage-20051020'''<br/>
<div class="change">
added fixes for libata 1.20 update
Bug #52529.
</div>
==== linux-2.6.8.1-drbd-0.7.17.patch ====
<div class="change">
fixed driver version in header file
</div>
</noinclude>
