 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHKL_25614
Patch Description: s700_800 11.11 VM-JFS deadlock, mmap, perf thread creation
Creation Date: 01/11/02
Post Date: 01/11/07
Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11
Products: N/A
Filesets:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP
Automatic Reboot?: Yes
Status: General Superseded
Critical:
Yes
PHKL_25614: CORRUPTION PANIC ABORT
JAGad62420: a process with a private 3rd quadrant
can obtain an erroneous address when calling mmap(2)
for a large mapping ( size > 1 GB). The erroneous
address can match an already existing address for
that process. If this is the case, subsequent use
of this address could lead to corruption of data
already at that address, as now 2 pointers with
different meaning refer to the same block of data.
The corruption is limited to the own address space
of the process, and possibly files mapped by the
process.
The corruption is limited to the calling process
address space, and will not affect system or other
process memory.
PHKL_25129: CORRUPTION
PHKL_24073: HANG
Category Tags:
defect_repair enhancement general_release critical panic
halts_system corruption
Path Name: /hp-ux_patches/s700_800/11.X/PHKL_25614
Symptoms:
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
A 32 bit process with the 3rd quadrant private (obtained
with the command chattr +q3 enable) can obtain an incorrect
address when requesting a large (~1 GB) mapping with the
mmap(2) call.
Observed symptoms are :
-process aborted because of a memory fault
(signals SIGBUS or SIGSEGV).
-corruption of the memory for the calling process,
including files that are mapped in memory by the process.
System memory and memory from other processes are not
impacted.
( SR:8606212954 CR:JAGad82141 )
When a 32 bit process uses mmap64(2) to mmap(2) a large file
on a 64 bit kernel, if the offset is bigger than 4 GB, the
call returns EINVAL.
( SR:8606188767 CR:JAGad57983 )
Applications requiring large amounts of private memory
address space (greater than 2GB) may use shared memory space
to offset their private memory space needs. This is done by
using the mmap(2) flags:
MAP_ANONYMOUS|MAP_GLOBAL|MAP_SHARED.
Even with this effort to conserve private memory space,
these applications are running out of private memory space.
A close examination shows that allocations intended for
shared space were put into private memory space in error.
( SR:8606205797 CR:JAGad74972 )
A panic "Returning ID that is already free" may occur as a
result of a process (proc A) calling mmap(2) with MAP_FIXED
and an address that overlaps with an existing text mapping.
This will result in a panic in one of the following ways:
(1) Panic occurs when process proc A exits.
(2) The process proc A does a munmap(2) of the previous
mmap(2) (as mentioned above) and subsequent mmap(2)
calls from any process (proc X) get assigned the same
address. When process proc X exits (case 1) the panic
occurs.
A stack trace may look similar to the following:
panic+0x6c
hdl_return_id+0xb8
hdl_free_protid+0x1c
hdl_detach+0x17c
attachreg+0x228
mmap_anon_object+0xc4
smmap_common+0x35c
smmap+0x50
syscall+0x750
$syscallrtn+0x0
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
Memory corruption may occur after the installation of
PHKL_24679.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
The system takes a lot of time in creating a large number of
threads. The cost of creating threads increases
exponentially as the number of threads increases and so the
system appears to be very slow when one tries to create a
lot of threads.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
Narrow mode (32bit) HP-UX 11.11 programs cannot mmap64() any
part of a large file beyond the first 2GB.
PHKL_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Decreased performance for mmap() operations has occasionally
been observed in superdome systems with more than 32 cpus.
These symptoms are not specific to superdomes, but could
possibly occur on other high end systems as well.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
A multi-threaded process hangs and cannot be killed. This
process will have been repeatedly mmap()ing parts of the
same file, while at the same time reading or writing to it
with the read(), write(), readv(), or writev() system calls
from a different thread. That file must also be on a JFS
file system.
The Netscape Messaging Server's smtpd process is the only
application we've seen do the particular combination of
operations required to get into this state.
Defect Description:
PHKL_25614:
( SR:8606193208 CR:JAGad62420 )
On 64 bit systems, calls to mmap(2) by 32 bit processes with
sizes in the range of 1 GB or greater cause the allocation
algorithm to allocate a segment in the 64 bit address space
instead of the 32 bit address space. The 64 bit address is
truncated to 32 bits on return to the 32 bit calling
process. The cause of this error is an incorrect boundaries
checking in the allocation algorithm. When using a
debugger, one can observe a 64 bit segment in the process
address space.
Resolution:
The allocation algorithm now checks boundary conditions
correctly, producing a correct memory address.
( SR:8606212954 CR:JAGad82141 )
One kernel structure associated with the mapped file is
based on the type of the process address space. Thus a 32
bit process creates a 32 bit mapped file kernel structure.
The kernel structure should be independent from the type of
the calling process.
Resolution:
The creation of the kernel structure associated with a mmap
file has been made independent from the type of the process.
( SR:8606188767 CR:JAGad57983 )
The mmap(2) system call ignores the MAP_GLOBAL flag when
used in combination with the MAP_SHARED and MAP_ANONYMOUS
flags.
Resolution:
Checking for the MAP_GLOBAL option in mmap(2) when the
MAP_ANONYMOUS and MAP_SHARED flags are used. The allocation
is then made from the appropriate quadrant.
( SR:8606205797 CR:JAGad74972 )
This panic results from trying to free the same ID twice as
a result of the system allowing a mapping that overlaps with
an existing mapping of text.
Resolution:
mmap(2) calls with addresses that overlap with existing text
mappings will now fail.
PHKL_25129:
( SR:8606215349 CR:JAGad84536 )
In one corner case the fix for "PHKL_24679" overwrites some
memory beyond the allocated limit for an internal data
structure.
Resolution:
Overwriting of memory is fixed by checking for a corner
case.
PHKL_24679:
( SR:8606201639 CR:JAGad70813 )
When ever a range of virtual address space is allocated for
a thread the OS always searches for a hole from the highest
possible address so as to give maximum possible space for
the heap to grow. When large number of threads are created
and all space in the proximity of the highest address is
occupied it takes a while before the search could get a
hole of required size, which slows down the thread creation
process.
Resolution:
The fix to the problem is to keep a hint for starting the
search next time so we do not have to start always from the
highest address.
PHKL_25227:
( SR:8606188435 CR:JAGad57643 )
The kernel code was limited by design to allow narrow
mode mmap64() to 2GB or less only.
Resolution:
The kernel was enhanced to remove this limitation. Narrow
mode mmap64() can now map up to 4GB.
PHKL_24743:
( SR:8606205558 CR:JAGad74733 ) Duplicate
( SR:8606204858 CR:JAGad74036 )
Unnecessary acquisition and release of region locks in
common execution paths can cause unpredictable performance
degradation.
Resolution:
ltered code path to minimize frequency of region
lock/release in procedures mmap_file_pieces() and
mmap_file_object(). Note that this is only one of the
causes for unpredictable performance degradation in mmap.
PHKL_24073:
( SR:8606189205 CR:JAGad58421 )
This problem was caused by a lock ordering problem between
VM and JFS. JFS can call VM while holding an inode lock;
the routines called may require a vas lock. VM can call JFS
while holding a vas lock; the routines called may require
an inode lock. If we get unlucky, we hit the same vas/inode
lock combination from both directions, and the threads
deadlock. Because the vas lock potentially held by VM is
a per process resource, this situation can only be
encountered by a multithreaded process.
Resolution:
The fix is to have the VM routine drop the vas lock before
calling the file system code; fortunately, the VM routine
can safely drop and reacquire the lock around the call ...
it was mostly holding it to avoid dropping and reacquiring
it repeatedly in a loop.
SR:
8606188435 8606188767 8606189205 8606193208 8606201639
8606204858 8606205558 8606205797 8606212954 8606215349
Patch Files:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o)
/usr/conf/lib/libvm.a(vm_mmap.o)
/usr/conf/lib/libvm.a(vm_pregion.o)
/usr/conf/lib/libvm.a(vm_vas.o)
what(1) Output:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r
11.11/3 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2001/10/31 14:13:17 $Revision: r11.
11/4 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2001/09/18 11:21:32 $Revision: r
11.11/2 PATCH_11.11 (PHKL_25129)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2001/07/23 16:14:54 $Revision: r11.1
1/1 PATCH_11.11 (PHKL_24679)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libvm-pdk.a(hdl_policy.o):
hdl_policy.c $Date: 2001/10/31 14:13:17 $Revision: r
11.11/3 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2001/10/31 14:13:17 $Revision: r11.
11/4 PATCH_11.11 (PHKL_25614)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2001/09/18 11:21:32 $Revision: r
11.11/2 PATCH_11.11 (PHKL_25129)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2001/07/23 16:14:54 $Revision: r11.1
1/1 PATCH_11.11 (PHKL_24679)
cksum(1) Output:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
782718132 18940 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
1093821556 32276 /usr/conf/lib/libvm.a(vm_mmap.o)
2722587288 16576 /usr/conf/lib/libvm.a(vm_pregion.o)
977808541 15668 /usr/conf/lib/libvm.a(vm_vas.o)
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
3270490178 42680 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
1068314812 70072 /usr/conf/lib/libvm.a(vm_mmap.o)
2836442045 33120 /usr/conf/lib/libvm.a(vm_pregion.o)
3630002615 36288 /usr/conf/lib/libvm.a(vm_vas.o)
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_25227 PHKL_25129 PHKL_24743 PHKL_24679 PHKL_24073
Equivalent Patches: None
Patch Package Size: 300 KBytes
Installation Instructions:
Please review all instructions and the Hewlett-Packard
SupportLine User Guide or your Hewlett-Packard support terms
and conditions for precautions, scope of license,
restrictions, and, limitation of liability and warranties,
before installing this patch.
------------------------------------------------------------
1. Back up your system before installing a patch.
2. Login as root.
3. Copy the patch to the /tmp directory.
4. Move to the /tmp directory and unshar the patch:
cd /tmp
sh PHKL_25614
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_25614.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_25614. If you do not wish to retain a
copy of the original software, include the patch_save_files
option in the swinstall command above:
-x patch_save_files=false
WARNING: If patch_save_files is false when a patch is installed,
the patch cannot be deinstalled. Please be careful
when using this feature.
For future reference, the contents of the PHKL_25614.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_25614.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_25614.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
|
Printable version
