Patch Name: PHKL_30621

Patch Description: s700_800 11.11 vm preemption point, async_io, mlock_region

Creation Date: 04/03/22

Post Date: 04/04/21

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

Products: N/A

Filesets:
	OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP
	ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP
	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP

Automatic Reboot?: Yes

Status: General Release

Critical:
	Yes
	PHKL_30621: PANIC
	PHKL_25212: CORRUPTION

Category Tags:
	defect_repair enhancement general_release critical panic
	corruption

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

Symptoms:
	PHKL_30621:
	( SR:8606302251 CR:JAGae65610 )
	System panics with the following or similar stack trace

	do_vm_mem_unlock
	mlock_region
	mlock_pregion
	foreach_mapped_range
	mlock_do_range
	vm_mem_do_range
	vm_mem_lock
	asyncdsk_lock_memory
	asyncdsk_config
	asyncdsk_ioctl
	spec_ioctl
	vno_ioctl
	ioctl
	syscall
	syscallinit

	PHKL_25212:
	( SR:8606194602 CR:JAGad63810 )
	Data corruption can occur when Hyperfabric networking
	interface or async I/O driver is being used in the system.

	PHKL_23944:
	( SR:8606128017 CR:JAGac78818 )
	If an application uses mlock or plock to lock a
	large segment of system memory (i.e. a large
	database application), other processes may not be
	scheduled to run while the mlock/plock function is
	executing. Depending on the amount of work that the
	mlocking thread has to perform, time critical
	functions such as realtime heartbeat process
	threads may timeout. For example, applications such
	as ServiceGuard may unexpectedly failover and other
	appliations may suddenly show reduced response
	time when a large database is being initialized.

	This problem will most likely be seen on systems
	with one or two processors.

	Time critical process threads will not be scheduled
	to run until there is an available processor.
	There are instances in the kernel where a process
	thread may not be scheduled to run even when it is
	the highest priority process thread.  This occurs
	when another process thread is executing on a
	processor and must complete a time consuming task
	before releasing the processor.  There are several
	such places in the kernel; this patch addresses one
	specific kernel path.

Defect Description:
	PHKL_30621:
	( SR:8606302251 CR:JAGae65610 )
	The kernel panics in the backout recovery code in
	mlock_region(), where do_vm_mem_unlock() is called with an
	uninitialized argument.

	When mlock_region() attempts to lock a given range of pages
	it divides it into sub-ranges and treats each one
	separately. This is because of previous locking that may
	exist in the given range. In case of failure on any one
	sub-range, the backout code tries to undo the operations
	already done on the previous sub-ranges. One such place in
	the backout code uses a local variable as an argument to
	do_vm_mem_unlock() without initializing it. Since this
	local variable is used in many places before, its incorrect
	residual value is passed to the function and causes a
	panic.

	Resolution:
	Initialize the argument variable before calling
	do_vm_mem_unlock() in mlock_region() backout recovery code.

	PHKL_25212:
	( SR:8606194602 CR:JAGad63810 )
	Kernel subsystems such as the Hyperfabric Networking
	Interface and Async I/O, expect to be notified about
	translation changes that may occur for memory pages they
	are using for DMA. The virtual memory system uses the
	cluster-interconnect flag to determine if such subsystems
	should be notified when the translation changes. If there
	are two different kernel-locked ranges in the same
	largepage, unlocking of first locked range causes the
	cluster-interconnect flag for that page to be cleared
	even though there is another locked range in the same
	page. This could cause a DMA operation to occur on the
	wrong page, resulting in data corruption.

	Resolution:
	A check has been added to see if there are other
	kernel-locked ranges in the same largepage before
	clearing the cluster-interconnect flag.

	PHKL_23944:
	( SR:8606128017 CR:JAGac78818 )
	Long running mlock or plock kernel paths are
	causing delays in scheduling of other process
	threads. No other process threads can be scheduled
	on these processors while the long kernel paths are
	executing. The amount of work performed along these
	kernel paths is propotional to the amount of memory
	involved (being mlocked or plocked) and thus
	impacts the delay time of waiting process threads.

	This problem will most likely be seen on systems
	with one or two processors when all processors are
	executing along these long kernel paths.

	Resolution:
	This patch enables kernel preemption along the
	mlock and plock kernel paths: If a process thread
	has been executing within the kernel mlock or plock
	paths for over a specified period of time, the
	kernel will preempt this process thread and
	schedule a higher priority process thread to run.
	The preempted process thread will be placed back on
	the run queue to resume where it left off in the
	kernel once rescheduled.

	The scheduler dictates the kernel execution time
	allotted to a single process and the policies
	governing which process priorities may preempt the
	current process.

	This enhancement may not necessarily improve
	performance or response time for all processes as
	mlock or plock may not be executing along these
	preemptible paths.

Enhancement:
	No (superseded patches contained enhancements)
	PHKL_30621:
		Enhancements were delivered in a patch this one has
		superseded.  Please review the Defect Description
		text for more information.

SR:
	8606128017 8606194602 8606302251

Patch Files:
	
	OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	/usr/conf/sys/vm_mlock.h

	ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	/usr/include/sys/vm_mlock.h

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
	/usr/conf/lib/libvm.a(vm_clic.o)
	/usr/conf/lib/libvm.a(vm_memlock.o)

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
	/usr/conf/lib/libvm.a(vm_clic.o)
	/usr/conf/lib/libvm.a(vm_memlock.o)

what(1) Output:
	
	OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	/usr/conf/sys/vm_mlock.h:
		vm_mlock.h $Date: 2001/09/11 16:51:29 $Revision: r11
			.11/1 PATCH_11.11 (PHKL_25212) */

	ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	/usr/include/sys/vm_mlock.h:
		vm_mlock.h $Date: 2001/09/11 16:51:29 $Revision: r11
			.11/1 PATCH_11.11 (PHKL_25212) */

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
	/usr/conf/lib/libvm.a(vm_clic.o):
		vm_clic.c $Date: 2001/09/11 16:50:09 $Revision: r11.
			11/1 PATCH_11.11 (PHKL_25212)
	/usr/conf/lib/libvm.a(vm_memlock.o):
		vm_memlock.c $Date: 2004/03/21 23:00:38 $Revision: r
			11.11/5 PATCH_11.11 (PHKL_30621)

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
	/usr/conf/lib/libvm.a(vm_clic.o):
		vm_clic.c $Date: 2001/09/11 16:50:09 $Revision: r11.
			11/1 PATCH_11.11 (PHKL_25212)
	/usr/conf/lib/libvm.a(vm_memlock.o):
		vm_memlock.c $Date: 2004/03/21 23:00:38 $Revision: r
			11.11/5 PATCH_11.11 (PHKL_30621)

cksum(1) Output:
	
	OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	1006741377 12659 /usr/conf/sys/vm_mlock.h

	ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP:
	1006741377 12659 /usr/include/sys/vm_mlock.h

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
	1062820374 4652 /usr/conf/lib/libvm.a(vm_clic.o)
	766215068 12120 /usr/conf/lib/libvm.a(vm_memlock.o)

	OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
	3070569695 9872 /usr/conf/lib/libvm.a(vm_clic.o)
	812034105 30616 /usr/conf/lib/libvm.a(vm_memlock.o)

Patch Conflicts: None

Patch Dependencies: None

Hardware Dependencies: None

Other Dependencies: None

Supersedes:
	PHKL_23944 PHKL_25212

Equivalent Patches:
	PHKL_29648:
	s700: 11.00
	s800: 11.00

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_30621

	5. Run swinstall to install the patch:

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

	By default swinstall will archive the original software in 
	/var/adm/sw/save/PHKL_30621.  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_30621.text file is 
	available in the product readme:

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

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

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

Special Installation Instructions:
	There are three patches providing similar kernel
	preemption enhancements: PHKL_23908, PHKL_23944,
	PHKL_23946. Each of these may be useful in
	preventing a time critical process thread time-out.
	However, these patches, installed either
	individually or collectively, may not necessarily
	improve performance or response time for all
	processes as the process threads causing the delay
	may not be executing along these preemptible paths.
	Each of these patches is independent of the others;
	they may be installed separately or in any
	combination, and in any order.  Each provides
	kernel preemption for a specific long running
	kernel path.