Patch Name: PHKL_11519 Patch Description: s700 10.20 VxFS cumulative patch Creation Date: 97/06/25 Post Date: 97/06/26 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_11519: ABORT PHKL_11321: PANIC PHKL_11013: OTHER This problem leaves the file system disabled and unusable, and requires a system reboot to regain access to it. PHKL_7899: PANIC HANG OTHER The KI instrumentation fix does not fall into any of specified symptoms; the root setuid fix does not either. Path Name: /hp-ux_patches/s700/10.X/PHKL_11519 Symptoms: PHKL_11519: On a NFS server with a Vxfs file system exported, the file /var/adm/nettl.LOG0x grows dramatically with the recording of "read failed with errno 22" (EINVAL). This problem is addressed by kernel patch PHKL_11321 among other problems. However, after the patch is installed, some NFS clients experience command coredump on the NFS mounted VxFS disk. PHKL_11321: This patch fixes two JFS performance problems and one defect: 1) Upgrading from 10.10 to 10.20, customer experienced approximately 25% performance degradation in read operation under JFS. 2) Loading a program for a second and subsequent time takes much longer if the program is using shared libraries on JFS. 3) Occasional panic occurs when running an executable which attempts to pagein through vnode level, producing a stack: trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ... $RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ... lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ... privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ... uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ... vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ... vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ... vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ... mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ... virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ... vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ... trap+0x129c and the message: trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000 savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4 9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996 panic: (display==0xbd00, flags==0x0) Data page fault This is mostly seen on PureAtria's Clearcase product which sets the UIOSEG_PAGEIN flag for vn_rdwr() calls. PHKL_11013: The vxupgrade command, used to convert a JFS version 2 file system to a version 3, can give an I/O error on execution. This causes the file system to be marked as unavailable, and a full fsck to be run. PHKL_7899: KI queuedone, enqueue and queuestart traces on JFS may contain NULL values in the b_apid and b_upid fields. With a system running a heavy load using JFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" Systems running JFS may hang due to a deadlock problem. The setuid bit will be removed on a JFS file when the file is edited or text has been appended to it when run as root. Defect Description: PHKL_11519: During vnode read operation, if the request is from NFS, the request size is checked against the VX_MAXBSIZE and an EINVAL is returned if the request size is greater than or equal to VX_MAXBSIZE. The EINVAL is always returned because the request size is set to VX_MAXBSIZE (8K) for NFS by the calling routine. When PHKL_11321 fixes this problem, the code proceeds to read the data block and returns the buffer back to NFS. This exposes a bug in which if the data we need starts at a non-zero offset within the buffer and the caller receives the whole buffer assuming the good data starts at the beginning, invalid data is loaded and command coredumps. PHKL_11321: 1) In vx_read1(), some unnecessary conditions prevented vx_read_ahead() to be called for large reads. The fix is to remove these extra checkings to allow read_ahead to be performed. ) When we are done with a shared library, pageout routine is called to flush the changes to disk. The way vx_pageout() works is that it invalidates the cached copy of the file then calls vx_do_pageout() to figure out the MMF pages need to be written and write them. A more efficient way of doing this is to invalidate and flush buffers in the buffer cache only if there are and may have been dirty pages. 3) When reading a sparse portion of a file on JFS, vx_read1() calls uiomove() to copy a page of zeroes to the target buffer. If the UIOSEG_PAGEIN flag is set in the uio structure, uiomove() by default will copy vx_zeropage from the buffer cache. Since vx_zeropage is not in the buffer cache's space, but is in space 0, this references an invalid address and triggers a panic. The fix is to replace uiomove() with long_uiomove() which allows the correct space id to be specified. PHKL_11013: During vxupgrade, it is possible for the allocation unit length to change; thus the same inode located in the same block will change allocation unit numbers. There was a check in vx_iremount() to verify that the allocation unit numbers matched, and returned ENOSPC if not. This was the root cause of the problem which was easily reproducible: o Create a version 2 JFS file system on a 1GB volume: mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol o mount it: mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt o fill up the file system halfway: prealloc /tmp_mnt/bigfile 500000000 o copy some files into the filesystem: cp -r /usr /tmp_mnt & o wait a few minutes and execute the vxupgrade command: vxupgrade -n 3 /tmp_mnt PHKL_7899: KI problem: The JFS buffer allocation and IO paths were not fully instrumented causing buffer header b_apid and b_upid fields not to be updated consistently. The resulting KI queuedone, enqueue, and queuestart traces contain NULL values in these fields. A panic can occur with JFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). System can deadlock due to a locking order problem in JFS when vx_fast_read() is called from VOP_BREAD. When a JFS file is created with the SETUID flag, the setuid bit is removed when the file has been edited with vi or text has been appended to it; this should only be the case when the writer is not root. SR: 1653166066 1653199802 4701329292 4701329300 4701329441 4701355560 5003368290 Patch Files: /usr/conf/lib/libvxfs_base.a(vx_bio.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) what(1) Output: /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 96/07/09 10:55:03 $ $Revision: 1.7.9 8.9 $ PATCH_10.20 (PHKL_7899) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 97/05/08 11:08:49 $ $Revision: 1. 6.98.13 $ PATCH_10.20 (PHKL_11013) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 96/07/09 10:56:32 $ $Revision: 1.7 .98.18 $ PATCH_10.20 (PHKL_7899) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 97/06/24 16:17:10 $ $Revision: 1.7 .98.23 $ PATCH_10.20 (PHKL_11519) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 97/06/09 16:47:28 $ $Revision: 1.7.98 .14 $ PATCH_10.20 (PHKL_11321) cksum(1) Output: 3798845514 10476 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 36074079 29780 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 1192397402 44784 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 965719562 35416 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 3906324615 11916 /usr/conf/lib/libvxfs_base.a(vx_vm.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7899 PHKL_11013 PHKL_11321 Equivalent Patches: PHKL_11520: s800: 10.20 Patch Package Size: 200 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_11519 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_11519.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_11519.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_11519. 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_11519.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_11519.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None