Patch Name: PHKL_8928 Patch Description: s700 10.10 memory mapping cumulative patch Creation Date: 96/10/14 Post Date: 96/11/01 Hardware Platforms - OS Releases: s700: 10.10 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: No (superseded patches were critical) PHKL_7244: OTHER Performance problems caused by excessive protection id faults Path Name: /hp-ux_patches/s700/10.X/PHKL_8928 Symptoms: PHKL_8928: Unable to mprotect non mmap() addresses. PHKL_7244: MP T500 running 10.01 or 10.10 with Informix database exhibits poor performance and high levels of protection id traps after reboot. Problem exhibits itself after stopping/restarting application until system rebooted. /usr was a JFS VxFS file system. Defect Description: PHKL_8928: Currently mprotect() restricts the addresses it will accept for protection. Only those addresses returned from a call to mmap() can be used for mprotect(). However there are customers who need to mprotect addresses in the data, stack and shared memory segments; objects not created vi a call to mmap(). So mprotect() was opened to allow mprotect'ing on data, stack and shared memory objects. Text is not allowed unless the executable is exec_magic. PHKL_7244: We only allow a public mapping if we are mapping shared (and thus read-only for now) and if the file's modes meet our tests (no ACL, and mode at least r-xr-xr-x). In one case, /usr (where the shared libraries reside) on their system turns out to be a JFS file system. JFS does not know about ACL and does not manipulate the va_acl bit in 'struct vattr', when VOP_GETATTR() is called. HFS on the other hand will set va_acl to 1 if that file has ACL and 0, if not. Since, smmap() does not initialize the structure (on the stack) and calls VOP_GETATTR() and then looks at the va_acl bit, it can either be a 1 or a 0, randomly. It is not correct for VM subsystem to assume all file systems support ACL and will correct set/reset the bit in the vattr structure as there could be third party file system (eg: JFS) that do not support it. When the libc.1 is first mmapp'ed, the smmap() code finds that va_acl is set (wrongly), it decides not to do public mapping (the region does not get the RHDL_MMAP_PUBLIC set) and so the protection id is set to the second quadrant space id of that process, instead of the public protection id of 0 Since, the informix (oninit) processes have a lot of shared memory segments, each of which has an unique protection id, and constantly accesses the shared memory region and execute library code, the protection id (pid3 & pid4) is getting thrashed in the pid registers. The instruction protection fault code is getting thrashed in the pid registers. The instruction protection fault code (IMEM_PROT) does not make use of the cache (kept per processor) and always uses the trap (long) path to update the protection registers. Hence, you see about 30-40% of the time in trap code. The following fix will ensure that the shared library text segments always get the public protection id. This will cut down the number of protection faults seen in informix. SR: 4701319335 5003341925 Patch Files: /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) /usr/conf/lib/libhp-ux.a(sysV_shm.o) /usr/conf/lib/libhp-ux.a(vm_mmap.o) /usr/conf/lib/libhp-ux.a(vm_pregion.o) what(1) Output: /usr/conf/lib/libhp-ux.a(hdl_mprotect.o): hdl_mprotect.c $Date: 96/10/14 11:21:48 $ $Revision: 1.3.89.9 $ PATCH_10.10 (PHKL_8928) /usr/conf/lib/libhp-ux.a(sysV_shm.o): sysV_shm.c $Date: 96/10/14 11:22:42 $ $Revision: 1.5 3.89.8 $ PATCH_10.10 (PHKL_8928) /usr/conf/lib/libhp-ux.a(vm_mmap.o): vm_mmap.c $Date: 96/10/14 13:22:57 $ $Revision : 1.13.89.20 $ PATCH_10.10 (PHKL_8928) /usr/conf/lib/libhp-ux.a(vm_pregion.o): vm_pregion.c $Date: 96/10/14 11:22:38 $ $Revision: 1.12.89.14 $ PATCH_10.10 (PHKL_8928) cksum(1) Output: 450550662 15460 /usr/conf/lib/libhp-ux.a(hdl_mprotect.o) 2746050686 8424 /usr/conf/lib/libhp-ux.a(sysV_shm.o) 1682762504 20080 /usr/conf/lib/libhp-ux.a(vm_mmap.o) 3263801287 11980 /usr/conf/lib/libhp-ux.a(vm_pregion.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7244 Equivalent Patches: None Patch Package Size: 120 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_8928 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_8928.depot 5b. For a homogeneous NFS Diskless cluster run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This will invoke swcluster in the interactive mode and force all clients to be shut down. WARNING: All cluster clients must be shut down prior to the patch installation. Installing the patch while the clients are booted is unsupported and can lead to serious problems. The swcluster command will invoke an swinstall session in which you must specify: alternate root path - default is /export/shared_root/OS_700 source depot path - /tmp/PHKL_8928.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFS Diskless cluster: - run swinstall on the server as in step 5a to install the patch on the cluster server. - run swcluster on the server as in step 5b to install the patch on the cluster clients. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_8928. 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_8928.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_8928.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None