 |
» |
|
|
|
|
|
|
|
|
|
Patch Name: PHKL_28267
Patch Description: s700_800 11.11 thread perf, user limit, cumulative VM
Creation Date: 02/11/26
Post Date: 02/12/10
Warning: 04/05/18 - This Critical Warning has been issued by HP.
- PHKL_26386 introduced behavior that in rare circumstances
can cause a system panic. When the behavior occurs, the
mmap(2) system call may panic with a stack trace similar to
the following:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
shrinkvfd+0x70
growreg+0x1e8
mapvnode+0x1e0
mmap_file_object+0x128
smmap_common+0x2e8
smmap+0x50
syscall+0xaec
syscallinit+0x554
- The same behavior is exhibited by superseding patches
PHKL_26744, PHKL_27278, PHKL_28267, PHKL_28428, PHKL_28990,
PHKL_30158, and PHKL_30616.
- Since this change was implemented in February 2002, if a
system has been successfully running with any of these
patches installed it is unlikely that the behavior will be
observed in the future. However, to avoid this behavior, HP
recommends removing these patches from any systems
experiencing system panics with a stack trace similar to the
one described above.
- Additional information on this behavior may be found in
Service Request 8606354805 (JAGaf15561).
- The superseded patch, PHKL_26233, does not exhibit the
same behavior. If you choose to remove these patches, HP
recommends that PHKL_26233 be installed after the patches
are removed to ensure as many known issues as possible are
addressed. If PHKL_26233 was installed prior to these
patches, it will automatically be restored when the patches
are removed and it will not need to be reinstalled.
- This behavior will be corrected in a new patch as soon as
possible.
- PHKL_28267 is included in the following Support Plus
Patch Bundles:
Jun 2003: GOLDBASE11i,B.11.11.0306.4
Sep 2003: GOLDBASE11i,B.11.11.0306.4
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 With Warnings
Critical:
Yes
PHKL_28267: PANIC CORRUPTION
PHKL_27278: PANIC CORRUPTION
PHKL_26744: PANIC
PHKL_26233: PANIC
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_28267
Symptoms:
PHKL_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
Under certain conditions of a process fork/exit, the system
may panic with the panic string: "freevas: vas cnt 0, but
still pointing to pregions".
The stack trace may be similar to:
panic+0x14
freevas+0x164
freeproc+0x22c
wait1+0x25c
waitpid+0x38
syscall+0x394
$syscallrtn+0x0
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
Using glance, or any tools based on pstat, to report memory
information about a single-threaded process, can cause a
panic.
The panic will occur in psl_search(). Before the panic
occurs, corruption is possible as the process address space
is corrupted.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
A data page fault panic may occur as the result of running
mmap(2) more than 65535 times on a file. The resulting
stack trace may look similar to the following:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xa9c
nokgdb+0x8
skl_deletevalue+0x4
remove_pregion_from_region+0xc8
detachreg+0xa4
dispreg+0x164
exit+0xb3c
rexit+0x24
syscall+0x724
$syscallrtn+0x0
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update provides pre-enablement of extensions
to mmap to allow mapping of I/O registers or address
ranges.
This product update will have no impact on your system
until the extensions to mmap are fully enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
System panic with the following stack trace.
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4
thandler+0xd20
hdl_vfault+0x80
vfault+0x12c
trap+0x234
thandler+0xd20
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_28267:
( SR:8606220721 CR:JAGad89858 ) Duplicate
( SR:8606227157 CR:JAGad96219 )
The reference count for the process' Virtual Address Space
(vas) is not protected from multiple concurrent accesses
by any lock. This results in a race condition and possible
ambiguous value in the reference count. If the reference
count is decremented to zero but the vas is still pointing
to valid pregions that are still in use, the freevas panic
will occur when attempting to free the vas.
Resolution:
The resolution is to lock the vas whenever the reference
count is incremented/decremented, thereby serializing
any changes and maintaining coherency of the reference
count.
PHKL_27278:
( SR:8606262338 CR:JAGae26673 )
There is a race condition between pstat and a function
managing a process address space. This causes the corruption
of the list representing a process address space, leading
to a panic.
Resolution:
The fix consists of enforcing locking even for
single-threaded processes, to protect them from
external pstat requests.
PHKL_26744:
( SR:8606202772 CR:JAGad71946 )
The variable holding the mmap reference count is not checked
for overflow. When the variable resets to zero, the system
panics with a data page fault.
Resolution:
The overflow condition is now detected. The panic is
avoided by returning ENOMEM when the mmap(2) reference count
variable overflows.
PHKL_26386:
( SR:8606186482 CR:JAGad55686 )
This product update contains minor enhancements required to
enable extensions to mmap to allow mapping of I/O registers
or address ranges.
Resolution:
Extended mmap to recognize MAP_IO flag and perform mapping
if functionality is enabled.
PHKL_26233:
( SR:8606230627 CR:JAGad99677 )
Kernel incorrectly handles some of the parameters to
setrlimit.
Resolution:
The kernel is fixed to handle the particular parameters
correctly.
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.
Enhancement:
No (superseded patches contained enhancements)
PHKL_28267:
Enhancements were delivered in a patch this one has
superseded. Please review the Defect Description
text for more information.
SR:
8606186482 8606188435 8606188767 8606189205 8606193208
8606201639 8606202772 8606204858 8606205558 8606205797
8606212954 8606215349 8606220721 8606227157 8606230627
8606262338
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-pdk.a(vm_procdup.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-pdk.a(vm_procdup.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-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2002/02/20 09:03:01 $Revision: r11.
11/6 PATCH_11.11 (PHKL_26386)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2002/06/11 09:14:53 $Revision: r
11.11/5 PATCH_11.11 (PHKL_27278)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2002/11/21 12:16:28 $Revision: r11.1
1/4 PATCH_11.11 (PHKL_28267)
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-pdk.a(vm_procdup.o):
vm_procdup.c $Date: 2002/11/21 12:14:20 $Revision: r
11.11/2 PATCH_11.11 (PHKL_28267)
/usr/conf/lib/libvm.a(vm_mmap.o):
vm_mmap.c $Date: 2002/02/20 09:03:01 $Revision: r11.
11/6 PATCH_11.11 (PHKL_26386)
/usr/conf/lib/libvm.a(vm_pregion.o):
vm_pregion.c $Date: 2002/06/11 09:14:53 $Revision: r
11.11/5 PATCH_11.11 (PHKL_27278)
/usr/conf/lib/libvm.a(vm_vas.o):
vm_vas.c $Date: 2002/11/21 12:16:28 $Revision: r11.1
1/4 PATCH_11.11 (PHKL_28267)
cksum(1) Output:
OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
3693964096 18940 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
3456433223 8576 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
2080683133 32604 /usr/conf/lib/libvm.a(vm_mmap.o)
1522369544 16404 /usr/conf/lib/libvm.a(vm_pregion.o)
2727995738 15744 /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:
2007197880 42680 /usr/conf/lib/libvm-pdk.a(hdl_policy.o)
442015647 17144 /usr/conf/lib/libvm-pdk.a(vm_procdup.o)
2907702662 70488 /usr/conf/lib/libvm.a(vm_mmap.o)
3518405407 32680 /usr/conf/lib/libvm.a(vm_pregion.o)
3225287562 36568 /usr/conf/lib/libvm.a(vm_vas.o)
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHKL_27278 PHKL_26744 PHKL_26386 PHKL_26233 PHKL_25614 PHKL_25227
PHKL_25129 PHKL_24743 PHKL_24679 PHKL_24073
Equivalent Patches: None
Patch Package Size: 330 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_28267
5. Run swinstall to install the patch:
swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHKL_28267.depot
By default swinstall will archive the original software in
/var/adm/sw/save/PHKL_28267. 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_28267.text file is
available in the product readme:
swlist -l product -a readme -d @ /tmp/PHKL_28267.depot
To put this patch on a magnetic tape and install from the
tape drive, use the command:
dd if=/tmp/PHKL_28267.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
|
Printable version
