Patch Name: PHKL_28393 Patch Description: s700_800 11.11 Contiguous and 32bit ranges, unmapping panic Creation Date: 03/01/31 Post Date: 03/04/09 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_28393: PANIC CORRUPTION PHKL_26266: PANIC CORRUPTION PHKL_23203: PANIC Category Tags: defect_repair general_release critical panic corruption manual_dependencies Path Name: /hp-ux_patches/s700_800/11.X/PHKL_28393 Symptoms: PHKL_28393: ( SR:8606250223 CR:JAGae16603 ) After installation of PHKL_26266, user_iomap() of a range immediately following a range already mapped will fail. The exact behavior of the system following this failure is highly application specific. The most likely result is that a device driver will fail initialization. ( SR:8606265694 CR:JAGae29951 ) panic: rmfree: abut to right or panic: rmfree: overlap on a call to user_iounmap() or on exit of a process which has performed a user_iomap(). A typical stack trace is: panic+0x6c do_rmfree+0x200 rmfree+0x3c io_unmap+0x1f0 iomap_nuke+0x24 iomap_exit+0xa4 exit+0xf30 rexit+0x24 syscall+0x20c $syscallrtn+0x0 ( SR:8606247904 CR:JAGae14304 ) panic: b_deadlock order violation with R/W lock This panic was detected in internal HP testing and has not been seen on customer systems. No typical stack trace is available. ( SR:8606257510 CR:JAGae21813 ) 64-bit user processes which invoke the kernel function user_iomap() directly or via a device driver will map to virtual addresses below 3.75Gb (0xF000'0000) when mapping physical I/O addresses between 0xFFFF'FFFF'1000'0000 and 0xFFFF'FFFF'F000'0000. These mappings do not check for other virtual ranges already in use by the process at these virtual addresses. The exact consequence will depend on process internals and how the process uses the mappings, but can include a kernel panic: hdl_pfault: invalid DBD for intransit page, process shared memory data corruption, or system data corruption. A typical stack trace is: panic+0x14 hdl_pfault+0x660 pfault+0x104 trap+0x4ec nokgdb+0x8 PHKL_26266: ( SR:8606236114 CR:JAGae05179 ) 32-bit user applications may make an iomap request which succeeds, but returns an address which is not within the 32-bit I/O virtual address space. Attempts to access the returned address will result in either a SIGSEGV or incorrect data. Attempts to write to the returned address will cause a SIGSEGV or data corruption in the user space application or files. ( SR:8606234348 CR:JAGae03552 ) A user process which has a mapping of I/O space (via a driver call or other means) can fork a child process. The child, by the nature of fork, automatically has the same I/O mapping as the parent. However, if the child does a duplicate mapping (via the same driver or other means) while the parent waits for the child, the mapping will be removed on the child process's exit. This causes a kernel panic when the parent either exits or tries to unmap the I/O space. PHKL_23203: ( SR:8606165678 CR:JAGad34969 ) Kernel panic may occur on 64-bit servers (L3000 only known case) with a VISUALIZE-FXE graphics card installed or a PCI device which provides a 32-bit interface. Panic stack trace: panic+0x14 hdl_pfault+0x660 pfault+0x104 trap+0x4ec nokgdb+0x8 Also, third party drivers which refuse to link with a linker error: "Unresolved function name: convert_ioaddr_64to32" depend upon this patch and will link properly after it is installed. Defect Description: PHKL_28393: ( SR:8606250223 CR:JAGae16603 ) The check to be sure that a new mapping does not overlap an existing mapping incorrectly considers the starting address of the page after each mapping to be part of that mapping. Resolution: Corrected the address range check called by the overlap detection to only consider pages actually within the considered range. ( SR:8606265694 CR:JAGae29951 ) Given the following scenario: A 32-bit process creates an iomap object using a physical address within the range [0xFFFF'FFFF'F100'0000, 0xFFFF'FFFF'FFFF'FFFF]. Another 32-bit process creates an iomap object using a physical address which is below 0xFFFF'FFFF'F100'0000. The virtual address ranges for the two iomap objects are adjacent (order does not matter). This scenario produces an error condition where the first range to be unmapped also unmaps part of the other range. This causes a kernel panic when the second range is being unmapped. Resolution: The structure used to manage 32-bit user mappings as well as the algorithm for choosing the address range to allocate from that structure were modified so that both address range types are allocated and freed in the same manner. ( SR:8606247904 CR:JAGae14304 ) Kernel synchronization locks are expected to be acquired and released in a specified order to prevent two threads waiting on each other's locks (deadlock). Checks are made on this ordering in debugging routines. A lock used in the iomap subsystem was assigned a lock order which violated the order checks. Resolution: Changed the order of the lock to be compliant with the debugging checks. ( SR:8606257510 CR:JAGae21813 ) The mechanism for selecting the virtual address to use on a 64-bit I/O map request uses a macro to determine if the requested physical address should be placed in the range of I/O virtual addresses which are also used by 32-bit processes (0xF000'0000 to 0xFFFF'FFFF). An erroneous TRUE from the macro for an address which is not 4Gb mappable causes the virtual address for the mapping to be set below the range set aside for I/O virtual addresses and in the ranges for text, data, stack, and shared memory creating the potential for panic or data corruption. Resolution: The macro was corrected to use the appropriate constants to match the intended use and design. PHKL_26266: ( SR:8606236114 CR:JAGae05179 ) Previous design considered large parts of 40-bit I/O space illegal for 32-bit application mapping, but allowed the mappings to occur and returned a 64-bit virtual address to the 32-bit caller. Since the application could not actually form the proper 64-bit virtual address, this could cause a segmentation violation (if the address was not previously in use) or data corruption due to unexpected writes (if it was). Resolution: The restriction on which I/O address ranges are and are not 32-bit mappable was removed. 32-bit iomap requests of previously inaccessible address ranges are now assigned the first free section of 32-bit I/O virtual address space of the appropriate size, and this address is returned to the caller. ( SR:8606234348 CR:JAGae03552 ) Previous design assumed that if two mappings were present (in the panic case, the child and the parent), and the kernel had a virtual translation of the physical I/O address that it was safe to remove the user-space translation. Since early boot code frequently enables translations when enabling I/O devices in the kernel (without using the iomap interface), this assumption is invalid. Resolution: I/O mapping removal code now explicitly checks for other user space mappings to be sure the translation can be removed. PHKL_23203: ( SR:8606165678 CR:JAGad34969 ) On 64 bit systems, 32-bit IO Blocks for IO adapters may be incorrectly mapped outside the 32-bit IO address space. If this happens, a protection fault will occur if the system attempts to use that region of memory for something other than I/O (e.g. shared memory access). This defect has only been seen on the L3000 server with a VISUALIZE-FXE graphics card installed. Resolution: Code was added to correctly place 32-bit I/O blocks into 32-bit I/O space. Code was added to return the proper 32-bit virtual I/O address corresponding to an actual 64-bit I/O address given the 64-bit address instead of always returning the lower 32 bits of the source address. Enhancement: No SR: 8606165678 8606234348 8606236114 8606247904 8606250223 8606257510 8606265694 Patch Files: OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/conf/pa/pde.h ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/include/pa/pde.h OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: /usr/conf/lib/libio-pdk.a(io_map.o) /usr/conf/lib/libvm-pdk.a(vm_ioblk.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libio-pdk.a(io_map.o) /usr/conf/lib/libvm-pdk.a(vm_ioblk.o) what(1) Output: OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/conf/pa/pde.h: pde.h $Date: 2002/12/06 11:51:23 $Revision: r11.11/2 PATCH_11.11 (PHKL_28393) ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/include/pa/pde.h: pde.h $Date: 2002/12/06 11:51:23 $Revision: r11.11/2 PATCH_11.11 (PHKL_28393) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: /usr/conf/lib/libio-pdk.a(io_map.o): io_map.c $Date: 2002/12/06 11:48:15 $Revision: r11.1 1/2 PATCH_11.11 (PHKL_28393) /usr/conf/lib/libvm-pdk.a(vm_ioblk.o): vm_ioblk.c $Date: 2002/12/16 11:50:14 $Revision: r11 .11/3 PATCH_11.11 (PHKL_28393) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: /usr/conf/lib/libio-pdk.a(io_map.o): io_map.c $Date: 2002/12/06 11:48:15 $Revision: r11.1 1/2 PATCH_11.11 (PHKL_28393) /usr/conf/lib/libvm-pdk.a(vm_ioblk.o): vm_ioblk.c $Date: 2002/12/16 11:50:14 $Revision: r11 .11/3 PATCH_11.11 (PHKL_28393) cksum(1) Output: OS-Core.CORE-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: 383247527 25203 /usr/conf/pa/pde.h ProgSupport.C-INC,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: 383247527 25203 /usr/include/pa/pde.h OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP: 278817722 5080 /usr/conf/lib/libio-pdk.a(io_map.o) 1644028464 5672 /usr/conf/lib/libvm-pdk.a(vm_ioblk.o) OS-Core.CORE2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP: 3827972287 16456 /usr/conf/lib/libio-pdk.a(io_map.o) 2669366131 21384 /usr/conf/lib/libvm-pdk.a(vm_ioblk.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: PHKL_23203: Patch PHKL_23204 should also be installed to avoid the kernel panic on servers (L3000 only known case) with VISUALIZE-FXE graphics card installed. Supersedes: PHKL_26266 PHKL_23203 Equivalent Patches: None Patch Package Size: 140 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_28393 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHKL_28393.depot By default swinstall will archive the original software in /var/adm/sw/save/PHKL_28393. 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_28393.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHKL_28393.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_28393.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: PHKL_23203: This patch includes a new version of , which defines a new macro, CONVERT_IOADDR_64TO32. Third party drivers that use this new macro and are linked with the kernel on the customer's system will also require this patch to be installed on the customer's system. Failure to install this patch on the customer's system will lead to a linker error when a new kernel is linked with this new third party driver.