Patch Name: PHKL_26295 Patch Description: s700 10.26 UFS/mmap: hangs, stale data, disk space leak Creation Date: 02/02/14 Post Date: 02/03/04 Hardware Platforms - OS Releases: s700: 10.26 Products: N/A Filesets: OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_26295: HANG Path Name: /hp-ux_patches/s700/10.X/PHKL_26295 Symptoms: PHKL_26295: Porting of 10.20 patch, PHKL_24517 to TOS (PHKL_24517:) (SR: 8606202934 CR: JAGad72108) System will deadlock with the following stack trace when a memory mapped region of a file is used as the I/O buffer to the same file: ilock_reader+0x170 << inode read lock deadlocks ufs_lock_inode+0x14 ufs_pagein+0x60 virtual_fault+0x378 vfault+0x118 trap+0x590 nokgdb+0x8 copyin+0x104 uiomove+0xc0 rwip+0x380 << lock acquired with ilock() ufs_rdwr+0xe0 vno_rw+0x80 write+0x104 syscall+0x480 First seen when using the Netscape imapd server. (PHKL_18617:) (SR: 4701424572 DTS: JAGaa94393) When a file is copied to UFS (HFS) file system and later accessed through mmap, the data accessed through mmap interface will be stale. A user might see linker failures if the file he is linking is on a UFS (HFS) file system or if /tmp file system is a UFS (HFS) file system. This problem will be seen on a 10.20->11.0 upgrade as a kernel build failure if /stand is a UFS (HFS) file system. This defect was introduced in patch PHKL_16498. (PHKL_16498:) Customer may sometimes see many processes hang when using a highly accessed smaller than 4k (page size) memory mapped file. (PHKL_10259:) Disk space leak on UFS file systems; running fsck(1M) on a `clean' file system would report inconsistencies such as: ... ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=386 (4 should be 1) ... ** Phase 5 - Check Cyl groups 3 BLK(S) MISSING ... This would be observed only on UFS file systems with a fragment size less than 4KB. Defect Description: PHKL_26295: Porting of 10.20 patch, PHKL_24517 to TOS (PHKL_24517:) (SR: 8606202934 CR: JAGad72108) Routines going through rwip() lock a UFS filesystem inode. Subsequent routines which must copy the user buffer to buffer cache using uiomove attempt to read- lock the same file if they must fault-in the page through the vfault/pagein interface. This leads to a thread deadlock. Resolution: (SR: 8606202934 CR: JAGad72108) Modified pagein interface to check if inode is already owned by current thread, in which case, there is no attempt to lock it again. (PHKL_18617:) Defect: (SR: 4701424572 DTS: JAGaa94393) PHKL_16498 changed the number of bytes flushed to disk from mmap'd files, but the number of bytes calculated was incorrect and not all blocks were flushed to disk. This showed up as a kernel build failure on a 10.20 to 11.0 upgrade if /stand is a UFS (HFS) file system. Resolution: (SR: 4701424572 DTS: JAGaa94393) Correctly calculate the number of bytes to flush to disk. (PHKL_16498:) Problem was due to procedure ufs_pagein() flushing beyond the inode byte size when rounding up to use page size number of bytes. Now we prevent other blocks which are not part of the memory mapped file from being blkflushed. This resolves the possible deadlock found. (PHKL_10259:) A corner case use of mmap(2) consisting of mapping the first few bytes of a small file (less than 3KB) residing on a UFS file system wrongly resulted in increasing the number of fragments allocated to the file. The file-system disk space could leak, but running fsck(1M) would fix the problem. This problem would only occur on UFS file systems using a fragment size less than 4KB. SR: 1653259861 4701347963 4701424572 8606202934 Patch Files: /usr/conf/lib/libhp-ux.a(ufs_vm.o) what(1) Output: /usr/conf/lib/libhp-ux.a(ufs_vm.o): 02/02/06 kern/sys/ufs_vm.c, hpux, hpux_10.26, ic5gl Revision 1.2 PATCH_10.26 (PHKL_26295) UNMODI FIED cksum(1) Output: 43109972 11036 /usr/conf/lib/libhp-ux.a(ufs_vm.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: None Equivalent Patches: PHKL_24517: s700: 10.20 Patch Package Size: 70 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_26295 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_26295.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_26295. 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_26295.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_26295.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None