Patch Name: PHKL_26894 Patch Description: s700 10.20 Cumulative mmap,mprotect,protid;SIGBUS in STDBY Creation Date: 02/04/25 Post Date: 02/04/30 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: OS-Core.CORE-KRN ProgSupport.C-INC Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_26894: HANG processes may hang interruptibly in pfault code on PA2.0 systems PHKL_25093: PANIC PHKL_21779: PANIC CORRUPTION PHKL_24294: PANIC PHKL_21925: PANIC PHKL_20605: PANIC Path Name: /hp-ux_patches/s700/10.X/PHKL_26894 Symptoms: PHKL_26894: (SR: 8606233554 CR: JAGae02777) On a PA2.0 system with PHKL_24294 or PHKL_25093 installed, processes may hang in an interruptible state. Examination of the process shows an inordinate amount of time spent in system mode, and the process stack trace will show that the process is involved in a protection fault. PHKL_17193: (SR: 1653258434 CR: JAGaa05991) An application receives a SIGBUS error when trying to execute a STDBY instruction: Bus error (coredump). This occurs only when running on PA-RISC 2.0 (or greater) based CPUs. PHKL_25093: (SR: 8606208878 CR: JAGad78065) When PHKL_24294 is installed on a PA2.0 system, the system may panic with a "Returning ID that is already free" panic. The stack trace may be similar to the following: panic+0x10 hdl_return_id+0xbc hdl_free_protid+0x24 hdl_mprot_free+0x90 detachreg+0x54 dispreg+0x100 exit+0x1d8 rexit+0x20 syscall+0x1a4 or panic+0x10 hdl_return_id+0xbc hdl_free_protid+0x24 hdl_return_mprotids+0x60 hdl_mprot_cleanup_pids+0x60 statdaemon+0xf8 main+0x4e8 PHKL_21779: (SR: 8606137220 CR: JAGad06338) Data corruption and an eventual system panic can occur when a user application makes a large number (over 65535) of mprotect(2) calls. A typical panic is a data page fault with the following stack: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0x1054 $call_trap+0x20 bcopy_pcxu_method+0xbc hdl_split_sub+0x230 hdl_mprotect+0x3b0 do_mprotect+0x17c foreach_pregion+0xec mprotect+0xa4 syscall+0x1a4 $syscallrtn+0x0 PHKL_24294: (SR: 8606182898 CR: JAGad52114) panic: "hdl_alloc_spaceid" occurs on a PA2.0 system when an application does more than 30k anonymous mmaps. A typical panic stack trace may look like: panic+0x10 hdl_alloc_id+0x1f0 hdl_alloc_spaceid+0x24 hdl_allocreg_spaceid+0x34 choose_shared_mmap_space+0x50 choose_space+0xcc hdl_attach+0x1a4 attachreg+0x88 smmap_common+0xa3c smmap+0x38 syscall+0x75c $syscallrtn+0x0 PHKL_21925: (SR: 8606136642 CR: JAGad05766) panic: "rmfree: overlap" when unmaping an mmap (shared mmf) segment. (SR: 8606146018 CR: JAGad15354) panic: "Data page fault" while trying to mmap maximum number of allowed pregions to a shared region. PHKL_20605: ( SR: 8606105836 CR: JAGab74182 ) Data page fault panic in hdl_choose_protid(). Stack trace looks like: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0x1054 $RDB_trap_patch+0x20 hdl_choose_protid+0xe4 hdl_changerange_0xe4 hdl_mprotect+0x404 choose_shared_mmap_space+0x2c8 choose_space+0xcc hdl_attach+0x1a4 attachreg+0x88 smmap_common+0x27c smmap+0x38 syscall+0x1a4 $syscallrtn+0x0 ( SR: 8606110048 CR: JAGab82751 ) Data page fault panic on multiprocessor system. Stack trace might look like: panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0xa48 $RDB_trap_patch+0x20 hdl_range_same+0x68 hdl_changerange+0x90 hdl_mprotect+0x404 choose_shared_mmap_space+0x268 choose_space+0x9c hdl_attach+0x1a4 attachreg+0x88 smmap_common+0x728 smmap+0x38 syscall+0x1a4 or panic+0x10 report_trap_or_int_and_panic+0xe8 trap+0xa48 $call_trap+0x20 hdl_range_same+0x68 hdl_changerange+0x90 hdl_mprotect+0x404 do_shared_munmap+0xe8 do_munmap+0x14c foreach_pregion+0xb8 munmap+0x64 syscall+0x1a4 PHKL_19383: (SR: 1653277004 CR: JAGaa40535) mmap64(2) returns an error when used to map portions of a file beyond the 2 GB file offset. PHKL_16880: It is possible for "munmap" to unexpectedly release the lock that is obtained from "fcntl". The application may experience an unexpected behavior because of this. Therefore, this patch is to rectify this unexpected behavior. Defect Description: PHKL_26894: (SR: 8606233554 CR: JAGae02777) When the maximum number of protection ids for PA2.0 systems was increased in patch PHKL_24294, some bitmasks were not updated to correctly compare the additional protection id bits. Resolution: All bitmasks used to compare protection ids now correctly compare the total number of bits in the protection id. PHKL_17193: (SR: 1653258434 CR: JAGaa05991) After an attempt to reference a page receives a fault, we try to avoid loading the page if the instruction causing the fault will immediately have a misaligned data fault (SIGBUS). A table is examined to determine which alignments the STDBY instruction can support. There were no alignment conditions set up for this instruction in 10.20; the entry for this instruction was uninitialized, causing random results. Resolution: The alignment conditions for this instruction were supplied so the various data alignments supported by this instruction are now handled correctly. PHKL_25093: (SR: 8606208878 CR: JAGad78065) PHKL_24294 increased the number of protection ids available on the PA2.0 architecture. However, a data structure used in mprotect code still declared a protection id as an unsigned short. The larger protection ids no longer fit in an unsigned short, and the field overflowed. This resulted in the panic when we attempted to free the truncated protection id. Resolution: The mprotect data structure was changed to use the proper data type to accommodate for the increased number of protection ids. PHKL_21779: (SR: 8606137220 CR: JAGad06338) The problem is caused by the limitation of the protection ranges for memory mapped regions. The counter for the number of pregions that can be mprotected is defined as a u_short. When an application uses a very large data segment and makes more than 64K-1 mprotect(2) calls, the range counter overflows, causing memory corruption that results in a system panic. Resolution: Change the definition of mprotect range counters from u_short to int. PHKL_24294: (SR: 8606182898 CR: JAGad52114) There are two issues with this defect. First, we are allocating a spaceid for anonymous mmaps when it is not required. The second issue is the protection id, which is required for anonymous mmaps. The current implementation is based on PA1.1 hardware, which limits the size of the protid map to 32768. PA1.1 allows 16 bits of protection ID, so allowing one bit for write disable, that leaves us with 15 bits, or 2^15, which is 32768. However, the PA2.0 architecture allows 18 bits of protection ID, so allowing for the write disable bit, that gives us 2^17, or 131072. We should be taking advantage of the additional bits the PA2.0 architecture allows. Resolution: First, do not allocate a spaceid for anonymous mmaps. Second, dynamically size the protid map based on a runtime check of the cpu architecture. For PA1.1, we are limited to a size of 32768 as described above, so there will be no functional change for machines running PA1.1 chips. For machines running PA2.0 chips, the protid map will be dynamically increased to 131072, the maximum allowed by the hardware. PHKL_21925: (SR: 8606146018 CR: JAGad15354) The defect is due to a race condition in mmap(2) code which was using a recursive algorithm to map all of the file. A lock was being dropped and reacquired each time the algorithm recursed. While trying to do an attach operation, we drop the reglock() before we are done in the routine hdl_mmf_attach() as it was a recursive routine. Since hdl_mmf_attach() is a recursive routine, there can be a race condition with someone doing a attach operation and another process doing a detach/munmap operation. The fix is not to drop the reglock before being done with the attach operation thus removing the potential race conditions with someone doing a detach/munmap operation. Resolution: This patch fixes recursive hdl_mmf_attach() problem causing mmap/munmap MP race conditions (SR: 8606146018 CR: JAGad15354) The system panic's while trying to mmap() more than the maximum allowed limit of pregions to a shared region. (limited by r_refcnt, which is of type ushort). This was caused by r_refcnt overflow which caused it to reset. If a program mmap's more than this limit, the counter r_refcnt overflow which causes the system to panic. The fix is to check for the overflow and return ENOMEM. Resolution: This patch ensures that we check for maximum limit of pregions attached to a region and if that is reached we return ENOMEM. PHKL_20605: ( SR: 8606105836 CR: JAGab74182 ) When removing a pregion from a region's pregion list, the appropriate pregion structure field was not always cleared. Resolution: This patch ensures that the pregion structure is properly updated when we remove it from a region's pregion list. ( SR: 8606110048 CR: JAGab82751 ) A multiprocessor race condition between mmap/munmap resulted in attempting to access a subpregion before it had been initialized. Resolution: This patch ensures we initialize the subpregion before attempting to access it. PHKL_19383: (SR: 1653277004 CR: JAGaa40535) mmap64(2) previously only supported file offsets up to 2 GB. Resolution: The mmap64(2) system call has been enhanced to support file offsets up to 4 GB. PHKL_16880: To correct the problem, the associations between "memory mapped file" and the system-wide file table reference count is removed. (i.e. The reference count is no longer stored in the system wide file table, however, the vnode reference counter still gets updated when "mmap" and "munmap".) SR: 1653258434 1653270546 1653277004 8606105836 8606110048 8606136642 8606137220 8606146018 8606182898 8606208878 8606233554 Patch Files: /usr/conf/lib/libhp-ux.a(asm_rv.o) /usr/conf/lib/libhp-ux.a(btlb.o) /usr/conf/lib/libhp-ux.a(hdl_init.o) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) /usr/conf/lib/libhp-ux.a(hdl_policy.o) /usr/conf/lib/libhp-ux.a(vm_machreg.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) /usr/conf/machine/hdl_preg.h /usr/include/machine/hdl_preg.h what(1) Output: /usr/conf/lib/libhp-ux.a(asm_rv.o): asm_rv.s $Date: 2002/04/24 06:04:23 $ $Revision: 1. 57.98.16 $ PATCH_10.20 (PHKL_26894) /usr/conf/lib/libhp-ux.a(btlb.o): btlb.c $Date: 2002/04/24 06:17:10 $ $Revision: 1. 9.98.5 $ PATCH_10.20 (PHKL_26894) /usr/conf/lib/libhp-ux.a(hdl_init.o): hdl_init.c $Date: 2002/04/25 12:32:43 $ $Revision : 1.9.98.8 $ PATCH_10.20 (PHKL_26894) /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 2001/08/28 08:30:54 $ $Revisio n: 1.4.98.8 $ PATCH_10.20 (PHKL_25093) /usr/conf/lib/libhp-ux.a(hdl_policy.o): hdl_policy.c $Date: 2001/08/28 10:25:06 $ $Revision: 1.15.98.19 $ PATCH_10.20 (PHKL_25093) /usr/conf/lib/libhp-ux.a(vm_machreg.o): vm_machreg.c $Date: 2002/04/24 06:27:22 $ $Revision: 1.17.98.26 $ PATCH_10.20 (PHKL_26894) /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 2000/07/06 17:39:35 $ $Revision: 1. 17.98.22 $ PATCH_10.20 (PHKL_21925) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 2000/06/29 11:25:43 $ $Revision: 1.16.98.16 $ PATCH_10.20 (PHKL_21925) /usr/conf/machine/hdl_preg.h: hdl_preg.h: $Revision: 1.8.98.4 $ $Date: 2001/08/28 08:23:21 $ hdl_preg.h $Date: 2001/08/28 08:23:21 $ $Revision: 1 .8.98.4 $ PATCH_10.20 (PHKL_25093) /usr/include/machine/hdl_preg.h: hdl_preg.h: $Revision: 1.8.98.4 $ $Date: 2001/08/28 08:23:21 $ hdl_preg.h $Date: 2001/08/28 08:23:21 $ $Revision: 1 .8.98.4 $ PATCH_10.20 (PHKL_25093) cksum(1) Output: 3522231875 20076 /usr/conf/lib/libhp-ux.a(asm_rv.o) 349244170 10360 /usr/conf/lib/libhp-ux.a(btlb.o) 1623305351 6484 /usr/conf/lib/libhp-ux.a(hdl_init.o) 2614844370 15920 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 2200814713 10740 /usr/conf/lib/libhp-ux.a(hdl_policy.o) 3738269355 15552 /usr/conf/lib/libhp-ux.a(vm_machreg.o) 4002093950 22464 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 1687754910 12004 /usr/conf/lib/libhp-ux.a(vm_pregion.o) 3452669349 2509 /usr/conf/machine/hdl_preg.h 3452669349 2509 /usr/include/machine/hdl_preg.h Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_16880 PHKL_17193 PHKL_19383 PHKL_20605 PHKL_21779 PHKL_21925 PHKL_24294 PHKL_25093 Equivalent Patches: PHKL_26895: s800: 10.20 Patch Package Size: 190 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_26894 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_26894.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_26894. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. WARNING: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_26894.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_26894.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: This patch depends on base patch PHKL_16750. For successful installation, please ensure that PHKL_16750 is in the same depot with this patch, or PHKL_16750 is already installed.