Patch Name: PHKL_25049

Patch Description: s700_800 11.04 (VVOS) JFS 3.1 cuml corruption and panic fix

Creation Date: 01/09/28

Post Date:  01/10/22

Hardware Platforms - OS Releases:
	s700: 11.04
	s800: 11.04

Products: N/A

Filesets:
	JournalFS.VXFS-PRG,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP
	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP
	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical:
	Yes
	PHKL_25049: PANIC
		Based on HP-UX Patch PHKL_24014:  PANIC
	PHKL_23013: CORRUPTION HANG
		Based on HP-UX Patch PHKL_20675:  CORRUPTION
		Based on HP-UX Patch PHKL_18452:  HANG

Category Tags:
	defect_repair general_release critical panic halts_system
	corruption

Path Name: /hp-ux_patches/s700_800/11.X/PHKL_25049

Symptoms:
	PHKL_25049:
	Ported HP-UX patch PHKL_24014 to VVOS

	Based on HP-UX patch PHKL_24014:
	( SR: 8606181325 DTS: JAGad50542 )
	A Data Page Fault in vx_do_extfree occurs due to a corrupted
	VxFS file system. VxFS may display a lot of error messages
	on the console before the panic occurs. Some of them are
	listed below:

	vxfs: mesg 001: vx_nospace - /dev/vx/dsk/srtdg1/lfs_004 file
	                system full (1 block extent)
	vxfs: mesg 003: vx_mapbad - /dev/vx/dsk/srtdg1/lfs_003 file
	                system free extent bitmap in au 37 marked
	                bad
	vxfs: mesg 008: vx_direrr: vx_dirscan_2 - /var/opt/sst/work/
	                srtdg1_lfs_003 file system inode 2 block 37
	                error 6

	The stack trace of the thread that panics may look like:
	panic+0x14
	report_trap_or_int_and_panic+0x94
	trap+0x1288
	nokgdb+0x8
	vx_do_extfree+0x204
	vx_extfree+0x128
	vx_trunc_typed+0xa0c
	vx_trunc_typed+0x564
	vx_trunc+0xb8c
	vx_inactive_tran+0x30c
	vx_inactive_list+0x164
	vx_worklist_process+0xe0
	vx_worklist_thread+0x50
	kthread_daemon_startup+0x2c
	kthread_daemon_startup+0x0
	vx_do_extfree+0x204vx_trunc_typed+0xa0c
	vx_trunc_typed+0x564
	vx_trunc+0xb8c
	vx_inactive_tran+0x30c
	vx_inactive_list+0x164
	vx_worklist_process+0xe0
	vx_worklist_thread+0x50
	kthread_daemon_startup+0x2c
	kthread_daemon_startup+0x0
	vx_do_extfree+0x204

	PHKL_23013:
	Ported HP-UX patch PHKL_20675 to VVOS

	Based on HP-UX patch PHKL_20675:
	( SR: 8606111959  DTS: JAGab84162)
	Writing over 2GB to files in a VxFS file system upgraded
	from V2 layout may fail and corrupt the files/file system.
	When write fails, error messages similiar to the following
	are logged into syslog.

	  vxfs: mesg 017: vx_write_default - /ver2 file system
					     inode 4 marked bad
	  vxfs: mesg 016: vx_ilisterr - /ver2 file system error
					reading inode 4

	Based on HP-UX patch PHKL_18452:
	VxFS file systems with sparse files can send invalid I/O
	requests to LVM causing system hangs; the system will also
	be out of space (vx_nospace messages appear).

	Based on HP-UX patch PHKL_18801:
	SR: 4701406454 DTS: JAGaa42801
	JFS file systems with large amounts of free space can get
	'vx_nospace' (ENOSPC) errors while 'fsadm' is running a
	defragmentation (-e option).

Defect Description:
	PHKL_25049:
	Ported HP-UX patch PHKL_24014 to VVOS

	Based on HP-UX patch PHKL_24014:
	( SR: 8606181325 DTS: JAGad50542 )
	The return value from a function was not validated because
	the function is not supposed to fail unless there is data
	corruption in the file system.  Dereferencing the return
	value when this function failed would result in a panic.

	Resolution:
	Make sure that the file system is not corrupted
	before invoking the above mentioned function.

	PHKL_23013:
	Ported HP-UX patch PHKL_20675 to VVOS

	Based on HP-UX patch PHKL_20675:
	( SR: 8606111959  DTS: JAGab84162)
	When a V2 layout VxFS filesystem is upgraded to V3/V4
	layout, the old files in the filesystem have indirect
	extents.  This may cause corruption to files in the
	upgraded file system while writing over 2GB.

	Resolution:
	Make writes over 2GB to files with indirect extents to fail
	in order to prevent data corruption.

	Based on HP-UX patch PHKL_18452:
	Investigation found a bug is in vx_ieextend_typed()
	which was hit when the file system is full, no extent
	is allocated in vx_ieextend_typed(), and there's room
	in the map for a new extent descriptor (the type search
	structure is not marked VX_TS_FULL). In this case, the
	very first call to vx_extentalloc() fails to allocate an
	extent so the vx_extalloc structure remains uninitialized.
	After the loop, the code assumes that an indirect address
	extent has been allocated and its descriptor must be added
	to the map. If the map has unused descriptor records, the
	existing descriptors are shifted to make room for a new
	one. VxFS then adds a bogus indirect address extent to
	the map.

	Based on HP-UX patch PHKL_18801:
	SR: 4701406454 DTS: JAGaa42801
	In some cases we try to allocate more space than is left in
	a given bitmap in 'vx_extsearchodd()'. This causes a false
	ENOSPC return.

	Resolution:

	Check that we're not trying to allocate more space than
	is left in the bitmap in vx_extsearchod() to prevent
	false ENOSPC.

SR:
	1653244277 4701393058 4701406454 8606111959 8606181325

Patch Files:
	
	JournalFS.VXFS-PRG,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP:
	/usr/include/sys/fs/vx_aioctl.h

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP:
	/usr/conf/lib/libvxfs_base.a(vx_aioctl.o)
	/usr/conf/lib/libvxfs_base.a(vx_alloc.o)
	/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o)
	/usr/conf/lib/libvxfs_base.a(vx_lite.o)

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP:
	/usr/conf/lib/libvxfs_base.a(vx_aioctl.o)
	/usr/conf/lib/libvxfs_base.a(vx_alloc.o)
	/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o)
	/usr/conf/lib/libvxfs_base.a(vx_lite.o)

what(1) Output:
	
	JournalFS.VXFS-PRG,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP:
	/usr/include/sys/fs/vx_aioctl.h:
		vx_aioctl.h $Date: 1999/12/13 08:26:44 $Revision: r1
			1ros/1 PATCH_11.00 (PHKL_20675)
		src/kernel/vxfs/vx_aioctl.h 2.1.7.1 17 Jan 1997 19:4
			3:06 -  */
		fshp:src/kernel/vxfs/vx_admin.h 2.1.7.1

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP:
	/usr/conf/lib/libvxfs_base.a(vx_aioctl.o):
		$Source: kern/vxfs/vx_aioctl.c, hpuxsysvx, vvos_rose
			, rose0157 $ $Date: 00/12/22 08:39:16 $ $Rev
			ision: 1.6 PATCH_11.04 (PHKL_23013) $
	/usr/conf/lib/libvxfs_base.a(vx_alloc.o):
		vx_alloc.c $Date: 2001/05/14 12:58:30 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_24014)
	/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o):
		vx_bmaptyped.c $Date: 2001/05/14 12:58:30 $Revision:
			 r11ros/7 PATCH_11.00 (PHKL_24014)
	/usr/conf/lib/libvxfs_base.a(vx_lite.o):
		$Source: kern/vxfs/vx_lite.c, hpuxsysvx, vvos_rose, 
			rose0157 $ $Date: 00/12/22 08:43:33 $ $Revis
			ion: 1.12 PATCH_11.04 (PHKL_23013) $

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP:
	/usr/conf/lib/libvxfs_base.a(vx_aioctl.o):
		$Source: kern/vxfs/vx_aioctl.c, hpuxsysvx, vvos_rose
			, rose0157 $ $Date: 00/12/22 08:39:16 $ $Rev
			ision: 1.6 PATCH_11.04 (PHKL_23013) $
	/usr/conf/lib/libvxfs_base.a(vx_alloc.o):
		vx_alloc.c $Date: 2001/05/14 12:58:30 $Revision: r11
			ros/4 PATCH_11.00 (PHKL_24014)
	/usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o):
		vx_bmaptyped.c $Date: 2001/05/14 12:58:30 $Revision:
			 r11ros/7 PATCH_11.00 (PHKL_24014)
	/usr/conf/lib/libvxfs_base.a(vx_lite.o):
		$Source: kern/vxfs/vx_lite.c, hpuxsysvx, vvos_rose, 
			rose0157 $ $Date: 00/12/22 08:43:33 $ $Revis
			ion: 1.12 PATCH_11.04 (PHKL_23013) $

cksum(1) Output:
	
	JournalFS.VXFS-PRG,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP:
	3417445253 10002 /usr/include/sys/fs/vx_aioctl.h

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_32,v=HP:
	2814753384 5104 /usr/conf/lib/libvxfs_base.a(vx_aioctl.o)
	3764820333 30200 /usr/conf/lib/libvxfs_base.a(vx_alloc.o)
	2276182749 19336 /usr/conf/lib/
		libvxfs_base.a(vx_bmaptyped.o)
	1437935849 4484 /usr/conf/lib/libvxfs_base.a(vx_lite.o)

	JournalFS.VXFS-BASE-KRN,fr=B.11.04,fa=HP-UX_B.11.04_64,v=HP:
	1497503166 8768 /usr/conf/lib/libvxfs_base.a(vx_aioctl.o)
	3509669075 58176 /usr/conf/lib/libvxfs_base.a(vx_alloc.o)
	2393525470 32168 /usr/conf/lib/
		libvxfs_base.a(vx_bmaptyped.o)
	3695682713 14328 /usr/conf/lib/libvxfs_base.a(vx_lite.o)

Patch Conflicts: None

Patch Dependencies: None

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHKL_23013 

Equivalent Patches:
	PHKL_24014:
	s700: 11.00
	s800: 11.00

Patch Package Size: 220 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_25049

	5. Run swinstall to install the patch:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -s /tmp/PHKL_25049.depot

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHKL_25049.  If you do not wish to retain a
	copy of the original software, use the patch_save_files option:

		swinstall -x autoreboot=true -x patch_match_target=true \
			  -x patch_save_files=false -s /tmp/PHKL_25049.depot

	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_25049.text file is 
	available in the product readme:

		swlist -l product -a readme -d @ /tmp/PHKL_25049.depot

	To put this patch on a magnetic tape and install from the
	tape drive, use the command:

		dd if=/tmp/PHKL_25049.depot of=/dev/rmt/0m bs=2k

Special Installation Instructions: None