Patch Name: PHKL_30614 Patch Description: s700_800 11.23 msgrcv(2) success on interrupt, mlock truncs Creation Date: 04/03/17 Post Date: 04/04/20 Hardware Platforms - OS Releases: s700: 11.23 s800: 11.23 Products: N/A Filesets: OS-Core.CORE2-KRN,fr=B.11.23,fa=HP-UX_B.11.23_IA,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_30614: PANIC CORRUPTION HANG OTHER Memory corruption could lead to a number of symptoms, including panic, kernel/user memory corruption, or HPMC. Memory leak could lead to application or system hang. PHKL_30483: HANG Category Tags: defect_repair general_release critical panic halts_system corruption Path Name: /hp-ux_patches/s700_800/11.X/PHKL_30614 Symptoms: PHKL_30614: ( SR:8606323514 CR:JAGae85979 ) Physical memory resources may be leaked from user Memory Resource Groups, resulting in process or system hangs. Kernel/user memory corruption, panic or HPMC due to DMA operations to physical pages which have been freed to the system. PHKL_30483: ( SR:8606345103 CR:JAGaf05953 ) PHKL_30065 introduced a defect under the following conditions: a) The system has more device swap space set up than is supported by its currently set value of the swchunk(2) tunable (swchunk's minimum and default value of 2048 supports 32Gb of swap), AND b) The system has 2 or more swap devices, AND c) Memory pressure forces pages to be written to the non-primary swap device which exceeds the swchunk supported limit. When these conditions are met, the system will hang. PHKL_30065: ( SR:8606336741 CR:JAGae97788 ) The msgrcv(2) system call may return success when it has actually been interrupted. When msgrcv(2) is interrupted by a signal, it should return -1 and errno should be set to EINTR. Instead, it was occasionally reporting success when in fact it had been interrupted. Defect Description: PHKL_30614: ( SR:8606323514 CR:JAGae85979 ) The kernel may invalidate pages which have been memory locked (via the mlock(2) or plock(2) interfaces). However, the kernel was returning the physical memory represented by these pages to the system while still considering the address space representing these pages as locked. This represents an accounting inconsistency. If a process in this inconsistent state is migrated between Memory Resource Groups, physical memory is taken from the new MRG that will never be returned to the system. This resource leak may lead to process or system hang due to a percieved lack of resources. The kernel may also invalidate pages which have been locked by kernel drivers for DMA operations. Here, the kernel was returning the physical pages locked by the driver to the system (which could then reuse them) without notifying the driver as required to allow in-flight DMAs to be completed. Since any such DMA would continue to modify pages which could now be user or kernel memory (or unused), this could cause user or kernel memory corruption or HPMCs. Resolution: Invalidation of page ranges due to file truncation is treated as an implicit unlock request for all clients of memory locking. Kernel locked pages will be completely unlocked and the appropriate driver callback invoked. User locked pages are simply unlocked. PHKL_30483: ( SR:8606345103 CR:JAGaf05953 ) PHKL_30065 introduced code in swapon(2) that failed to correctly set the error number value returned to the caller. The code for the swapon(2) system call was written so that it could enable part of a swap device if that swap device would exceed what was supported by the swchunk(5) tunable. The fix delivered in PHKL_30065 touched this path, and incorrectly indicated complete success (by not setting the error number) while marking the device as invalid (-1) due to failure. However, the device was still marked as valid in the swap table. In effect, this changed the major number of the swap device to "-1". When memory pressure is created on the system, vhand will attempt to push pages to the swap device. The -1 is translated into major number 255 (device major numbers are represented by 8 bits). The page IO will therefore go to the device at major number 255, which is mapped to an uninitialized entry in the system device table. This action generates an error which is never checked by vhand. The IOs therefore disappear. vhand notices that IOs never complete and stops paging activity. Meanwhile, processes go to sleep waiting for memory, and the system hangs. Resolution: Correctly set the error number value returned by swapon(2) to the caller. PHKL_30065: ( SR:8606336741 CR:JAGae97788 ) The msgrcv(2) system call was awaiting a message when it received a signal. Errno was set to EINTR to indicate this, but in the process of returning to the user, the kernel took a fault on a user address. Deep inside the fault handler, the virtual memory system set errno to 0. This caused msgrcv(2) to report success instead of EINTR. Resolution: The virtual memory system no longer clears errno in the fault path. Enhancement: No SR: 8606323514 8606336741 8606345103 Patch Files: OS-Core.CORE2-KRN,fr=B.11.23,fa=HP-UX_B.11.23_IA,v=HP: /usr/conf/lib/libvm.a(pregion.o) /usr/conf/lib/libvm.a(region.o) /usr/conf/lib/libvm.a(vm_sw.o) /usr/conf/lib/libvm.a(vm_swalloc.o) what(1) Output: OS-Core.CORE2-KRN,fr=B.11.23,fa=HP-UX_B.11.23_IA,v=HP: /usr/conf/lib/libvm.a(pregion.o): pregion.c $Date: 2004/03/17 15:10:26 $Revision: r11. 23/1 PATCH_11.23 (PHKL_30614) /usr/conf/lib/libvm.a(region.o): region.c $Date: 2004/03/17 15:10:26 $Revision: r11.2 3/2 PATCH_11.23 (PHKL_30614) /usr/conf/lib/libvm.a(vm_sw.o): vm_sw.c $Date: 2004/02/18 21:09:03 $Revision: r11.23 /2 PATCH_11.23 (PHKL_30483) /usr/conf/lib/libvm.a(vm_swalloc.o): vm_swalloc.c $Date: 2003/12/01 17:01:53 $Revision: r 11.23/1 PATCH_11.23 (PHKL_30065) cksum(1) Output: OS-Core.CORE2-KRN,fr=B.11.23,fa=HP-UX_B.11.23_IA,v=HP: 597493768 182424 /usr/conf/lib/libvm.a(pregion.o) 19211286 123520 /usr/conf/lib/libvm.a(region.o) 408939023 100752 /usr/conf/lib/libvm.a(vm_sw.o) 2912076030 55888 /usr/conf/lib/libvm.a(vm_swalloc.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_30483 PHKL_30065 Equivalent Patches: None Patch Package Size: 180 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_30614 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_30614.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_30614. 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_30614.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_30614.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_30614.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None