- 17 Sep, 2014 40 commits
-
-
Markos Chandras authored
commit 6521d9a4 upstream. The CPS code is doing several memory loads when configuring the VPEs from secondary cores, so the segmentation control registers must be initialized in time otherwise the kernel will crash with strange TLB exceptions. Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Patchwork: http://patchwork.linux-mips.org/patch/7424/Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Markos Chandras authored
commit ca4d24f7 upstream. Rename 'eva_entry' to 'platform_eva_init' as required by the new 'eva_init' macro in the eva.h header. Since this macro is now used in a platform dependent way, it must not depend on its caller so move the t1 register initialization inside this macro. Also set the .reorder assembler option in case the caller may have previously set .noreorder. This may allow a few assembler optimizations. Finally include missing headers and document the register usage for this macro. Reviewed-by:
-
Markos Chandras authored
commit f85b71ce upstream. Generic code may need to perform certain operations when EVA is enabled, for example, configure the segmentation registers during boot. In order to avoid using more CONFIG_EVA ifdefs in the arch code, such functions will be added in this header instead. Initially this header contains a macro which will be used by generic code later on during VPEs configuration on secondary cores. All it does is to call the platform specific EVA init code in case EVA is enabled. Reviewed-by:
-
Aaro Koskinen authored
commit 60830868 upstream. get_system_type() is not thread-safe on OCTEON. It uses static data, also more dangerous issue is that it's calling cvmx_fuse_read_byte() every time without any synchronization. Currently it's possible to get processes stuck looping forever in kernel simply by launching multiple readers of /proc/cpuinfo: (while true; do cat /proc/cpuinfo > /dev/null; done) & (while true; do cat /proc/cpuinfo > /dev/null; done) & ... Fix by initializing the system type string only once during the early boot. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nsn.com> Reviewed-by:
-
Markos Chandras authored
commit 64615682 upstream. Using kstrtol to parse the "{e,}memsize" variables was wrong because this parses signed long numbers. In case of '{e,}memsize' >= 2G, the top bit is set, resulting to -ERANGE errors and possibly random system memory boundaries. We fix this by replacing "kstrtol" with "kstrtoul". We also improve the code to check the kstrtoul return value and print a warning if an error was returned. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Markos Chandras authored
commit 52456899 upstream. Commit 4c21b8fd (MIPS: seccomp: Handle indirect system calls (o32)) added indirect syscall detection for O32 processes running on MIPS64 but it did not work as expected. The reason is the the scall64-o32 implementation differs compared to scall32-o32. In the former, the v0 (syscall number) register contains the absolute syscall number (4000 + X) whereas in the latter it contains the relative syscall number (X). Fix the code to avoid doing an extra addition, and load the v0 register directly to the first argument for syscall_trace_enter. Moreover, set the .reorder assembler option in order to have better control on this part of the assembly code. Signed-off-by:
-
Markos Chandras authored
commit 40381529 upstream. On MIPS64, O32 processes set both TIF_32BIT_ADDR and TIF_32BIT_REGS so the previous condition treated O32 applications as N32 when evaluating seccomp filters. Fix the condition to check both TIF_32BIT_{REGS, ADDR} for the N32 AUDIT flag. Signed-off-by:
-
Alex Smith authored
commit bcec7c8d upstream. Get rid of the WANT_COMPAT_REG_H test and instead define both the 32- and 64-bit register offset definitions at the same time with MIPS{32,64}_ prefixes, then define the existing EF_* names to the correct definitions for the kernel's bitness. This patch is a prerequisite of the following bug fix patch. Signed-off-by:
Alex Smith <alex@alex-smith.me.uk> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7451/Signed-off-by:
-
Huacai Chen authored
commit 2e5767a2 upstream. In do_ade(), is_fpu_owner() isn't preempt-safe. For example, when an unaligned ldc1 is executed, do_cpu() is called and then FPU will be enabled (and TIF_USEDFPU will be set for the current process). Then, do_ade() is called because the access is unaligned. If the current process is preempted at this time, TIF_USEDFPU will be cleard. So when the process is scheduled again, BUG_ON(!is_fpu_owner()) is triggered. This small program can trigger this BUG in a preemptible kernel: int main (int argc, char *argv[]) { double u64[2]; while (1) { asm volatile ( ".set push \n\t" ".set noreorder \n\t" "ldc1 $f3, 4(%0) \n\t" ".set pop \n\t" ::"r"(u64): ); } return 0; } V2: Remove the BUG_ON() unconditionally due to Paul's suggestion. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Jie Chen <chenj@lemote.com> Signed-off-by:
Rui Wang <wangr@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Signed-off-by:
-
Huacai Chen authored
commit 8393c524 upstream. In commit 2c8c53e2 (MIPS: Optimize TLB handlers for Octeon CPUs) build_r4000_tlb_refill_handler() is modified. But it doesn't compatible with the original code in HUGETLB case. Because there is a copy & paste error and one line of code is missing. It is very easy to produce a bug with LTP's hugemmap05 test. Signed-off-by:
Binbin Zhou <zhoubb@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/7496/Signed-off-by:
-
Paul Burton authored
commit b1442d39 upstream. If one or more matching FCSR cause & enable bits are set in saved thread context then when that context is restored the kernel will take an FP exception. This is of course undesirable and considered an oops, leading to the kernel writing a backtrace to the console and potentially rebooting depending upon the configuration. Thus the kernel avoids this situation by clearing the cause bits of the FCSR register when handling FP exceptions and after emulating FP instructions. However the kernel does not prevent userland from setting arbitrary FCSR cause & enable bits via ptrace, using either the PTRACE_POKEUSR or PTRACE_SETFPREGS requests. This means userland can trivially cause the kernel to oops on any system with an FPU. Prevent this from happening by clearing the cause bits when writing to the saved FCSR context via ptrace. This problem appears to exist at least back to the beginning of the git era in the PTRACE_POKEUSR case. Signed-off-by:
-
James Hogan authored
commit 7d907fa1 upstream. Commit d6d3c9af (MIPS: MT: proc: Add support for printing VPE and TC ids) causes a link error when CONFIG_PROC_FS=n: arch/mips/built-in.o: In function `proc_cpuinfo_notifier_init': smp-mt.c: undefined reference to `register_proc_cpuinfo_notifier' This is fixed by adding an ifdef around the procfs handling code in smp-mt.c. Signed-off-by:
-
Alex Smith authored
commit 656ff9be upstream. Whenever ptrace attempts to retrieve the FPU implementation register it accesses it through current_cpu_data, which calls smp_processor_id(). Since the code may execute with preemption enabled, this can trigger a warning. Fix this by using boot_cpu_data to get the IR instead. Signed-off-by:
-
Alex Smith authored
commit c23b3d1a upstream. Commit 6a9c001b ("MIPS: Switch ELF core dumper to use regsets.") switched the core dumper to use regsets, however the GP regset code simply makes a direct copy of the kernel's pt_regs, which does not match the original core dump register layout as defined in asm/reg.h. Furthermore, the definition of pt_regs can vary with certain Kconfig variables, therefore the GP regset can never be relied upon to return registers in the same layout. Therefore, this patch changes the GP regset to match the original core dump layout. The layout differs for 32- and 64-bit processes, so separate implementations of the get/set functions are added for the 32- and 64-bit regsets. Signed-off-by:
-
Alex Smith authored
commit 65768a1a upstream. task_user_regset_view() should test for TIF_32BIT_REGS in the flags of the specified task, not of the current task. Signed-off-by:
-
Alex Smith authored
commit e90e6fdd upstream. On 32-bit/O32, pt_regs has a padding area at the beginning into which the syscall arguments passed via the user stack are copied. 4 arguments totalling 16 bytes are copied to offset 16 bytes into this area, however the area is only 24 bytes long. This means the last 2 arguments overwrite pt_regs->regs[{0,1}]. If a syscall function returns an error, handle_sys stores the original syscall number in pt_regs->regs[0] for syscall restart. signal.c checks whether regs[0] is non-zero, if it is it will check whether the syscall return value is one of the ERESTART* codes to see if it must be restarted. Should a syscall be made that results in a non-zero value being copied off the user stack into regs[0], and then returns a positive (non-error) value that matches one of the ERESTART* error codes, this can be mistaken for requiring a syscall restart. While the possibility for this to occur has always existed, it is made much more likely to occur by commit 46e12c07 ("MIPS: O32 / 32-bit: Always copy 4 stack arguments."), since now every syscall will copy 4 arguments and overwrite regs[0], rather than just those with 7 or 8 arguments. Since that commit, booting Debian under a 32-bit MIPS kernel almost always results in a hang early in boot, due to a wait4 syscall returning a PID that matches one of the ERESTART* codes, which then causes an incorrect restart of the syscall. The problem is fixed by increasing the size of the padding area so that arguments copied off the stack will not overwrite pt_regs->regs[{0,1}]. Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Reviewed-by:
Aurelien Jarno <aurelien@aurel32.net> Tested-by:
-
Jeffrey Deans authored
commit ffc8415a upstream. A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK mapping causes the cpu parameter to gic_setup_intr() to be increased to 32, causing memory corruption when pcpu_masks[] is written to again later in the function. Signed-off-by:
Jeffrey Deans <jeffrey.deans@imgtec.com> Signed-off-by:
-
Tony Battersby authored
commit 2ba136da upstream. blk_rq_set_block_pc() memsets rq->cmd to 0, so it should come immediately after blk_get_request() to avoid overwriting the user-supplied CDB. Also check for failure to allocate rq. Fixes: f27b087b ("block: add blk_rq_set_block_pc()") Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Juergen Gross authored
commit f6105c08 upstream. If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's private command pool is needed. scsi_find_host_cmd_pool() will locate it, but scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template. This will result in an access error when the host is removed. Avoid the problem by saving the address of a new allocated command pool where it is expected. Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Christoph Hellwig <hch@lst.de> Fixes: 89d9a567Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Bart Van Assche authored
commit cd53eb68 upstream. If scsi_remove_host() is called while an rport is in the blocked state then scsi_remove_host() will only finish if the rport is unblocked from inside a timer function. Make sure that an rport only enters the blocked state if a timer will be started that will unblock it. This avoids that unloading the ib_srp kernel module after having disconnected the initiator from the target system results in a deadlock if both the fast_io_fail_tmo and dev_loss_tmo parameters have been set to "off". Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
David Dillow <dave@thedillows.org> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Janusz Dziemidowicz authored
commit 0213436a upstream. Some devices don't like REPORT SUPPORTED OPERATION CODES and will simply timeout causing sd_mod init to take a very very long time. Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being issued. Add it to Promise Vtrak E610f entry in scsi scan blacklist. Fixes bug #79901 reported at https://bugzilla.kernel.org/show_bug.cgi?id=79901 Fixes: 98dcc294 ("SCSI: sd: Update WRITE SAME heuristics") Signed-off-by:
Janusz Dziemidowicz <rraptorr@nails.eu.org> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Martin K. Petersen authored
commit c1d40a52 upstream. Despite supporting modern SCSI features some storage devices continue to claim conformance to an older version of the SPC spec. This is done for compatibility with legacy operating systems. Linux by default will not attempt to read VPD pages on devices that claim SPC-2 or older. Introduce a blacklist flag that can be used to trigger VPD page inquiries on devices that are known to support them. Reported-by:
KY Srinivasan <kys@microsoft.com> Tested-by:
-
Hannes Reinecke authored
commit 22ffeb48 upstream. Sequential scan for more than 256 LUNs is very fragile as LUNs might not be numbered sequentially after that point. SAM revisions later than SCSI-3 impose a structure on LUNs larger than 256, making LUN numbers between 256 and 16384 illegal. SCSI-3, however allows for plain 64-bit numbers with no internal structure. So restrict sequential LUN scan to 256 LUNs and add a new blacklist flag 'BLIST_SCSI3LUN' to scan up to max_lun devices. Signed-off-by:
Ewan Milne <emilne@redhat.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 3533f860 upstream. On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. Note that there is sufficient sense information to support scsi error handling even in this case. Signed-off-by:
-
K. Y. Srinivasan authored
commit f885fb73 upstream. Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the Windows host require this. The host validates the command and SRB flags prior to passing the command down to native driver stack. Signed-off-by:
-
K. Y. Srinivasan authored
commit adb6f9e1 upstream. Based on the negotiated VMBUS protocol version, we adjust the size of the storage protocol messages. The two sizes we currently handle are pre-win8 and post-win8. In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8 version. Make adjustments to correctly handle this. Signed-off-by:
-
K. Y. Srinivasan authored
commit 52f9614d upstream. Set cmd_per_lun to reflect value supported by the Host. Signed-off-by:
-
K. Y. Srinivasan authored
commit 4cd83ecd upstream. Hyper-V hosts can support multiple targets and multiple channels and larger number of LUNs per target. Update the code to reflect this. With this patch we can correctly enumerate all the paths in a multi-path storage environment. Signed-off-by:
-
K. Y. Srinivasan authored
commit 8caf92d8 upstream. Going forward it is possible that some of the commands that are not currently implemented will be implemented on future Windows hosts. Even if they are not implemented, we are told the host will corrrectly handle unsupported commands (by returning appropriate return code and sense information). Make command filtering depend on the host version. Signed-off-by:
-
K. Y. Srinivasan authored
commit 56b26e69 upstream. On Azure, we have seen instances of unbounded I/O latencies. To deal with this issue, implement handler that can reset the timeout. Note that the host gaurantees that it will respond to each command that has been issued. Signed-off-by:
-
James Bottomley authored
commit 884ffee0 upstream. hostt->name might contain space, so use the ->proc_name short name instead when creating per-driver command slabs. Signed-off-by:
poma <pomidorabelisima@gmail.com> Tested-by:
Vladimir Davydov <vdavydov@parallels.com> Reviewed-by:
-
Aneesh Kumar K.V authored
commit 7e467245 upstream. We would get wrong results in compiler recomputed old_pmd. Avoid that by using ACCESS_ONCE Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Aneesh Kumar K.V authored
commit 969b7b20 upstream. As per ISA, for 4k base page size we compare 14..65 bits of VA specified with the entry_VA in tlb. That implies we need to make sure we do a tlbie with all the possible 4k va we used to access the 16MB hugepage. With 64k base page size we compare 14..57 bits of VA. Hence we cannot ignore the lower 24 bits of va while tlbie .We also cannot tlb invalidate a 16MB entry with just one tlbie instruction because we don't track which va was used to instantiate the tlb entry. Signed-off-by:
-
Aneesh Kumar K.V authored
commit fc047955 upstream. If we changed base page size of the segment, either via sub_page_protect or via remap_4k_pfn, we do a demote_segment which doesn't flush the hash table entries. We do a lazy hash page table flush for all mapped pages in the demoted segment. This happens when we handle hash page fault for these pages. We use _PAGE_COMBO bit along with _PAGE_HASHPTE to indicate whether a pte is backed by 4K hash pte. If we find _PAGE_COMBO not set on the pte, that implies that we could possibly have older 64K hash pte entries in the hash page table and we need to invalidate those entries. Use _PAGE_COMBO to determine the page size with which we should invalidate the hash table entries on unmap. Signed-off-by:
-
Aneesh Kumar K.V authored
commit 629149fa upstream. If we changed base page size of the segment, either via sub_page_protect or via remap_4k_pfn, we do a demote_segment which doesn't flush the hash table entries. We do a lazy hash page table flush for all mapped pages in the demoted segment. This happens when we handle hash page fault for these pages. We use _PAGE_COMBO bit along with _PAGE_HASHPTE to indicate whether a pte is backed by 4K hash pte. If we find _PAGE_COMBO not set on the pte, that implies that we could possibly have older 64K hash pte entries in the hash page table and we need to invalidate those entries. Handle this correctly for 16M pages Signed-off-by:
-
Aneesh Kumar K.V authored
commit fa1f8ae8 upstream. The segment identifier and segment size will remain the same in the loop, So we can compute it outside. We also change the hugepage_invalidate interface so that we can use it the later patch Signed-off-by:
-
Aneesh Kumar K.V authored
commit b0aa44a3 upstream. With hugepages, we store the hpte valid information in the pte page whose address is stored in the second half of the PMD. Use a write barrier to make sure clearing pmd busy bit and updating hpte valid info are ordered properly. Signed-off-by:
-
Gavin Shan authored
commit 5efbabe0 upstream. Function remove_ddw() could be called in of_reconfig_notifier and we potentially remove the dynamic DMA window property, which invokes of_reconfig_notifier again. Eventually, it leads to the deadlock as following backtrace shows. The patch fixes the above issue by deferring releasing the dynamic DMA window property while releasing the device node. ============================================= [ INFO: possible recursive locking detected ] 3.16.0+ #428 Tainted: G W --------------------------------------------- drmgr/2273 is trying to acquire lock: ((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \ .__blocking_notifier_call_chain+0x40/0x78 but task is already holding lock: ((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \ .__blocking_notifier_call_chain+0x40/0x78 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((of_reconfig_chain).rwsem); lock((of_reconfig_chain).rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by drmgr/2273: #0: (sb_writers#4){.+.+.+}, at: [<c0000000001cbe70>] \ .vfs_write+0xb0/0x1f8 #1: ((of_reconfig_chain).rwsem){.+.+..}, at: [<c000000000091890>] \ .__blocking_notifier_call_chain+0x40/0x78 stack backtrace: CPU: 17 PID: 2273 Comm: drmgr Tainted: G W 3.16.0+ #428 Call Trace: [c0000000137e7000] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable) [c0000000137e70b0] [c00000000083cd34] .dump_stack+0x7c/0x9c [c0000000137e7130] [c0000000000b8afc] .__lock_acquire+0x128c/0x1c68 [c0000000137e7280] [c0000000000b9a4c] .lock_acquire+0xe8/0x104 [c0000000137e7350] [c00000000083588c] .down_read+0x4c/0x90 [c0000000137e73e0] [c000000000091890] .__blocking_notifier_call_chain+0x40/0x78 [c0000000137e7490] [c000000000091900] .blocking_notifier_call_chain+0x38/0x48 [c0000000137e7520] [c000000000682a28] .of_reconfig_notify+0x34/0x5c [c0000000137e75b0] [c000000000682a9c] .of_property_notify+0x4c/0x54 [c0000000137e7650] [c000000000682bf0] .of_remove_property+0x30/0xd4 [c0000000137e76f0] [c000000000052a44] .remove_ddw+0x144/0x168 [c0000000137e7790] [c000000000053204] .iommu_reconfig_notifier+0x30/0xe0 [c0000000137e7820] [c00000000009137c] .notifier_call_chain+0x6c/0xb4 [c0000000137e78c0] [c0000000000918ac] .__blocking_notifier_call_chain+0x5c/0x78 [c0000000137e7970] [c000000000091900] .blocking_notifier_call_chain+0x38/0x48 [c0000000137e7a00] [c000000000682a28] .of_reconfig_notify+0x34/0x5c [c0000000137e7a90] [c000000000682e14] .of_detach_node+0x44/0x1fc [c0000000137e7b40] [c0000000000518e4] .ofdt_write+0x3ac/0x688 [c0000000137e7c20] [c000000000238430] .proc_reg_write+0xb8/0xd4 [c0000000137e7cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8 [c0000000137e7d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0 [c0000000137e7e30] [c00000000000a064] syscall_exit+0x0/0x98 Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Gavin Shan authored
commit f1b3929c upstream. While running command "drmgr -c phb -r -s 'PHB 528'", following backtrace jumped out because the target device node isn't marked with OF_DETACHED by of_detach_node(), which caused by error returned from memory hotplug related reconfig notifier when disabling CONFIG_MEMORY_HOTREMOVE. The patch fixes it. ERROR: Bad of_node_put() on /pci@800000020000210/ethernet@0 CPU: 14 PID: 2252 Comm: drmgr Tainted: G W 3.16.0+ #427 Call Trace: [c000000012a776a0] [c000000000013d9c] .show_stack+0x88/0x148 (unreliable) [c000000012a77750] [c00000000083cd34] .dump_stack+0x7c/0x9c [c000000012a777d0] [c0000000006807c4] .of_node_release+0x58/0xe0 [c000000012a77860] [c00000000038a7d0] .kobject_release+0x174/0x1b8 [c000000012a77900] [c00000000038a884] .kobject_put+0x70/0x78 [c000000012a77980] [c000000000681680] .of_node_put+0x28/0x34 [c000000012a77a00] [c000000000681ea8] .__of_get_next_child+0x64/0x70 [c000000012a77a90] [c000000000682138] .of_find_node_by_path+0x1b8/0x20c [c000000012a77b40] [c000000000051840] .ofdt_write+0x308/0x688 [c000000012a77c20] [c000000000238430] .proc_reg_write+0xb8/0xd4 [c000000012a77cd0] [c0000000001cbeac] .vfs_write+0xec/0x1f8 [c000000012a77d70] [c0000000001cc3b0] .SyS_write+0x58/0xa0 [c000000012a77e30] [c00000000000a064] syscall_exit+0x0/0x98 Signed-off-by:
-
Aneesh Kumar K.V authored
commit 85c1fafd upstream. On ppc64 we support 4K hash pte with 64K page size. That requires us to track the hash pte slot information on a per 4k basis. We do that by storing the slot details in the second half of pte page. The pte bit _PAGE_COMBO is used to indicate whether the second half need to be looked while building real_pte. We need to use read memory barrier while doing that so that load of hidx is not reordered w.r.t _PAGE_COMBO check. On the store side we already do a lwsync in __hash_page_4K Signed-off-by:
-
