- 14 Jul, 2019 40 commits
-
-
Mariusz Tkaczyk authored
[ Upstream commit 9642fa73 ] Stopping external metadata arrays during resync/recovery causes retries, loop of interrupting and starting reconstruction, until it hit at good moment to stop completely. While these retries curr_mark_cnt can be small- especially on HDD drives, so subtraction result can be smaller than 0. However it is casted to uint without checking. As a result of it the status bar in /proc/mdstat while stopping is strange (it jumps between 0% and 99%). The real problem occurs here after commit 72deb455 ("block: remove CONFIG_LBDAF"). Sector_div() macro has been changed, now the divisor is casted to uint32. For db = -8 the divisior(db/32-1) becomes 0. Check if db value can be really counted and replace these macro by div64_u64() inline. Signed-off-by:
Mariusz Tkaczyk <mariusz.tkaczyk@intel.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mike Marciniszyn authored
[ Upstream commit 942a8993 ] The call to sc_buffer_alloc currently returns NULL (no buffer) or a buffer descriptor. There is a third case when the port is down. Currently that returns NULL and this prevents the caller from properly handling the sc_buffer_alloc() failure. A verbs code link test after the call is racy so the indication needs to come from the state check inside the allocation routine to be valid. Fix by encoding the ECOMM failure like SDMA. IS_ERR_OR_NULL() tests are added at all call sites. For verbs send, this needs to treat any error by returning a completion without any MMIO copy. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 099a884b ] Once a send context is taken down due to a link failure, any QPs waiting for pio credits will stay on the waitlist indefinitely. Fix by wakeing up all QPs linked to piowait list. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit f972775b ] Once an SDMA engine is taken down due to a link failure, any waiting QPs that do not have outstanding descriptors in the ring will stay on the dmawait list as long as the port is down. Since there is no timer running, they will stay there for a long time. The fix is to wake up all iowaits linked to dmawait. The send engine will build and post packets that get flushed back. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 4bb02e95 ] SDMA and pio flushes will cause a lot of packets to be transmitted after a link has gone down, using a lot of CPU to retransmit packets. Fix for RC QPs by recognizing the flush status and: - Forcing a timer start - Putting the QP into a "send one" mode Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit 9755f724 ] This paves the way for another patch that reacts to a flush sdma completion for RC. Fixes: 81cd3891 ("IB/hfi1: Add support for 16B Management Packets") Reviewed-by:
-
Wolfram Sang authored
[ Upstream commit b0e370b9 ] We don't have a reproducible error case, yet our BSP team suggested that the mmc_switch_status() command in mmc_select_hs400() should come after the callback into the driver completing HS400 setup. It makes sense to me because we want the status of a fully setup HS400, so it will increase the reliability of the mmc_switch_status() command. Reported-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Fixes: ba6c7ac3 ("mmc: core: more fine-grained hooks for HS400 tuning") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit 36815b41 ] Permit mux_id values up to 254 to be used in qmimux_register_device() for compatibility with ip(8) and the rmnet driver. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
Reinhard Speyerer <rspmn@arcor.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit a8fdde1c ] Switch qmimux_unregister_device() and qmi_wwan_disconnect() to use unregister_netdevice_queue() and unregister_netdevice_many() instead of unregister_netdevice(). This avoids RCU stalls which have been observed on device disconnect in certain setups otherwise. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Reinhard Speyerer authored
[ Upstream commit 61356088 ] The QMAP code in the qmi_wwan driver is based on the CodeAurora GobiNet driver which does not process QMAP padding in the RX path correctly. Add support for QMAP padding to qmimux_rx_fixup() according to the description of the rmnet driver. Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support") Cc: Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit fe8d9571 ] Since commit 177366bf the %rbp stopped pointing to %rbp of the previous stack frame. That broke frame pointer based stack unwinding. This commit is a partial revert of it. Note that the location of tail_call_cnt is fixed, since the verifier enforces MAX_BPF_STACK stack size for programs with tail calls. Fixes: 177366bf ("bpf: change x86 JITed program stack layout") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit 86723c86 ] .ndo_xdp_xmit() assumes it is called under RCU. For example virtio_net uses RCU to detect it has setup the resources for tx. The assumption accidentally broke when introducing bulk queue in devmap. Fixes: 5d053f9d ("bpf: devmap prepare xdp frames for bulking") Reported-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Toshiaki Makita <toshiaki.makita1@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit edabf4d9 ] dev_map_free() forgot to free bulk queue when freeing its entries. Fixes: 5d053f9d ("bpf: devmap prepare xdp frames for bulking") Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Toshiaki Makita authored
[ Upstream commit d4dd153d ] dev_map_free() waits for flush_needed bitmap to be empty in order to ensure all flush operations have completed before freeing its entries. However the corresponding clear_bit() was called before using the entries, so the entries could be used after free. All access to the entries needs to be done before clearing the bit. It seems commit a5e2da6e ("bpf: netdev is never null in __dev_map_flush") accidentally changed the clear_bit() and memory access order. Note that the problem happens only in __dev_map_flush(), not in dev_map_flush_old(). dev_map_flush_old() is called only after nulling out the corresponding netdev_map entry, so dev_map_free() never frees the entry thus no such race happens there. Fixes: a5e2da6e ("bpf: netdev is never null in __dev_map_flush") Signed-off-by:
-
Avraham Stern authored
[ Upstream commit b6584202 ] Instead of reporting the AP's TSF, host time was reported. Fix it. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Mordechay Goodstein authored
[ Upstream commit 1a473d60 ] The bits of Rx MCS Map in VHT capability were enumerated with index transform - index i -> (i + 1) bit => nss i. BUG! while it should be - index i -> (i + 1) bit => (i + 1) nss. The bug was exposed in commit a53b2a0b ("iwlwifi: mvm: implement VHT extended NSS support in rs.c"), where iwlwifi started using the function. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: b0aa75f0 ("ieee80211: add new VHT capability fields/parsing") Signed-off-by:
-
Naftali Goldstein authored
[ Upstream commit f8891461 ] It is not a good idea to try to perform any work (e.g. send an auth frame) during reconfigure flow. Prevent this from happening, and at the end of the reconfigure flow requeue all the works. Signed-off-by:
Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by:
-
Yibo Zhao authored
[ Upstream commit 56357234 ] In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the AP which is not fully prepared at this point of time, AP's channel context could be NULL. As a result, warning message occurs. Even worse, if the AP is under attack via tools such as MDK3 and massive authentication requests are received in a very short time, console will be hung due to kernel warning messages. WARN_ON_ONCE() could be a better way for indicating warning messages without duplicate messages to flood the console. Johannes: We still need to address the underlying problem, but we don't really have a good handle on it yet. Suppress the worst side-effects for now. Signed-off-by:
Zhi Chen <zhichen@codeaurora.org> Signed-off-by:
Yibo Zhao <yiboz@codeaurora.org> [johannes: add note, change subject] Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit 912bbf7e ] The output of the IC downsizer unit in both dimensions must be <= 1024 before being passed to the IC resizer unit. This was causing corrupted images when: input_dim > 1024, and input_dim / 2 < output_dim < input_dim Some broken examples were 1920x1080 -> 1024x768 and 1920x1080 -> 1280x1080. Fixes: 70b9b6b3 ("gpu: ipu-v3: image-convert: calculate per-tile resize coefficients") Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit bca4d70c ] The input bytesperline calculation for packed pixel formats was incorrect. The min/max clamping values must be multiplied by the packed bits-per-pixel. This was causing corrupted converted images when the input format was RGB4 (probably also other input packed formats). Fixes: d966e23d ("gpu: ipu-v3: image-convert: fix bytesperline adjustment") Reported-by:
Harsha Manjula Mallikarjun <Harsha.ManjulaMallikarjun@in.bosch.com> Suggested-by:
-
Steve Longerbeam authored
[ Upstream commit ff391ecd ] The output width and height alignment values were being used in the input bytesperline calculation. Fix by separating local vars w_align and h_align into w_align_in, h_align_in, w_align_out, and h_align_out. Fixes: d966e23d ("gpu: ipu-v3: image-convert: fix bytesperline adjustment") Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 68f2515b ] The lcdc device is missing the dma_coherent_mask definition causing the following warning on da850-evm: da8xx_lcdc da8xx_lcdc.0: found Sharp_LK043T1DG01 panel ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:247 dma_alloc_attrs+0xc8/0x110 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.2.0-rc3-00077-g16d72dd4 #18 Hardware name: DaVinci DA850/OMAP-L138/AM18x EVM [<c000fce8>] (unwind_backtrace) from [<c000d900>] (show_stack+0x10/0x14) [<c000d900>] (show_stack) from [<c001a4f8>] (__warn+0xec/0x114) [<c001a4f8>] (__warn) from [<c001a634>] (warn_slowpath_null+0x3c/0x48) [<c001a634>] (warn_slowpath_null) from [<c0065860>] (dma_alloc_attrs+0xc8/0x110) [<c0065860>] (dma_alloc_attrs) from [<c02820f8>] (fb_probe+0x228/0x5a8) [<c02820f8>] (fb_probe) from [<c02d3e9c>] (platform_drv_probe+0x48/0x9c) [<c02d3e9c>] (platform_drv_probe) from [<c02d221c>] (really_probe+0x1d8/0x2d4) [<c02d221c>] (really_probe) from [<c02d2474>] (driver_probe_device+0x5c/0x168) [<c02d2474>] (driver_probe_device) from [<c02d2728>] (device_driver_attach+0x58/0x60) [<c02d2728>] (device_driver_attach) from [<c02d27b0>] (__driver_attach+0x80/0xbc) [<c02d27b0>] (__driver_attach) from [<c02d047c>] (bus_for_each_dev+0x64/0xb4) [<c02d047c>] (bus_for_each_dev) from [<c02d1590>] (bus_add_driver+0xe4/0x1d8) [<c02d1590>] (bus_add_driver) from [<c02d301c>] (driver_register+0x78/0x10c) [<c02d301c>] (driver_register) from [<c000a5c0>] (do_one_initcall+0x48/0x1bc) [<c000a5c0>] (do_one_initcall) from [<c05cae6c>] (kernel_init_freeable+0x10c/0x1d8) [<c05cae6c>] (kernel_init_freeable) from [<c048a000>] (kernel_init+0x8/0xf4) [<c048a000>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34) Exception stack(0xc6837fb0 to 0xc6837ff8) 7fa0: 00000000 00000000 00000000 00000000 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace 8a8073511be81dd2 ]--- Add a 32-bit mask to the platform device's definition. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit 0c0c9b57 ] The BB expander at 0x21 i2c bus 1 fails to probe on da850-evm because the board doesn't set has_full_constraints to true in the regulator API. Call regulator_has_full_constraints() at the end of board registration just like we do in da850-lcdk and da830-evm. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Naveen N. Rao authored
[ Upstream commit 3e068269 ] If the result of the division is LLONG_MIN, current tests do not detect the error since the return value is truncated to a 32-bit value and ends up being 0. Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit f9bc5227 ] Unfortunately, a couple of mistakes were made while implementing Enlightened VMCS support, in particular, wrong clean fields were used in copy_enlightened_to_vmcs12(): - exception_bitmap is covered by CONTROL_EXCPN; - vm_exit_controls/pin_based_vm_exec_control/secondary_vm_exec_control are covered by CONTROL_GRP1. Fixes: 945679e3 ("KVM: nVMX: add enlightened VMCS state") Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ido Schimmel authored
[ Upstream commit 4b14cc31 ] When PVID is removed from a bridge port, the Linux bridge drops both untagged and prio-tagged packets. Align mlxsw with this behavior. Fixes: 148f472d ("mlxsw: reg: Add the Switch Port Acceptable Frame Types register") Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Dave Martin authored
[ Upstream commit 4729ec8c ] kvm_device->destroy() seems to be supposed to free its kvm_device struct, but vgic_its_destroy() is not currently doing this, resulting in a memory leak, resulting in kmemleak reports such as the following: unreferenced object 0xffff800aeddfe280 (size 128): comm "qemu-system-aar", pid 13799, jiffies 4299827317 (age 1569.844s) [...] backtrace: [<00000000a08b80e2>] kmem_cache_alloc+0x178/0x208 [<00000000dcad2bd3>] kvm_vm_ioctl+0x350/0xbc0 Fix it. Cc: Andre Przywara <andre.przywara@arm.com> Fixes: 1085fdc6 ("KVM: arm64: vgic-its: Introduce new KVM ITS device") Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Ilya Maximets authored
[ Upstream commit 01d76b53 ] We should not call 'ndo_bpf()' or 'dev_put()' with NULL argument. Fixes: c9b47cc1 ("xsk: fix bug when trying to use both copy and zero-copy on one queue id") Signed-off-by:
Ilya Maximets <i.maximets@samsung.com> Acked-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by:
-
Anson Huang authored
[ Upstream commit ce9a53eb ] There are several scenarios that keyboard can NOT wake up system from suspend, e.g., if a keyboard is depressed between system device suspend phase and device noirq suspend phase, the keyboard ISR will be called and both keyboard depress and release interrupts will be disabled, then keyboard will no longer be able to wake up system. Another scenario would be, if a keyboard is kept depressed, and then system goes into suspend, the expected behavior would be when keyboard is released, system will be waked up, but current implementation can NOT achieve that, because both depress and release interrupts are disabled in ISR, and the event check is still in progress. To fix these issues, need to make sure keyboard's depress or release interrupt is enabled after noirq device suspend phase, this patch moves the suspend/resume callback to noirq suspend/resume phase, and enable the corresponding interrupt according to current keyboard status. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Nick Hu authored
[ Upstream commit d0e1f211 ] In RV32, udelay would delay the wrong cycle. When it shifts right "UDELAY_SHIFT" bits, it either delays 0 cycle or 1 cycle. It only works correctly in RV64. Because the 'ucycles' always needs to be 64 bits variable. Signed-off-by:
Nick Hu <nickhu@andestech.com> Reviewed-by:
Palmer Dabbelt <palmer@sifive.com> [paul.walmsley@sifive.com: fixed minor spelling error] Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by:
-
Qian Cai authored
[ Upstream commit 39916897 ] Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver forgot to set dma_parms appropriately. Set it just after vmw_dma_masks() in vmw_driver_load(). DMA-API: vmwgfx 0000:00:0f.0: mapping sg segment longer than device claims to support [len=2097152] [max=65536] WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232 debug_dma_map_sg+0x360/0x480 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018 RIP: 0010:debug_dma_map_sg+0x360/0x480 Call Trace: vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx] vmw_bo_map_dma+0x25/0x30 [vmwgfx] vmw_otables_setup+0x2a8/0x750 [vmwgfx] vmw_request_device_late+0x78/0xc0 [vmwgfx] vmw_request_device+0xee/0x4e0 [vmwgfx] vmw_driver_load.cold+0x757/0xd84 [vmwgfx] drm_dev_register+0x1ff/0x340 [drm] drm_get_pci_dev+0x110/0x290 [drm] vmw_probe+0x15/0x20 [vmwgfx] local_pci_probe+0x7a/0xc0 pci_device_probe+0x1b9/0x290 really_probe+0x1b5/0x630 driver_probe_device+0xa3/0x1a0 device_driver_attach+0x94/0xa0 __driver_attach+0xdd/0x1c0 bus_for_each_dev+0xfe/0x150 driver_attach+0x2d/0x40 bus_add_driver+0x290/0x350 driver_register+0xdc/0x1d0 __pci_register_driver+0xda/0xf0 vmwgfx_init+0x34/0x1000 [vmwgfx] do_one_initcall+0xe5/0x40a do_init_module+0x10f/0x3a0 load_module+0x16a5/0x1a40 __se_sys_finit_module+0x183/0x1c0 __x64_sys_finit_module+0x43/0x50 do_syscall_64+0xc8/0x606 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: fb1d9738 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU") Co-developed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
Thomas Hellstrom authored
[ Upstream commit bde15555 ] When building sg tables, honor the device sg list segment size limitation. Signed-off-by:
Deepak Rawat <drawat@vmware.com> Signed-off-by:
-
Kevin Hilman authored
[ Upstream commit 3b025f2b ] Enable PRCI clock driver and serial console by default, so the default upstream defconfig is bootable to a serial console. Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Heiko Carstens authored
[ Upstream commit f9364df3 ] Get rid of gcc9 warnings like this: arch/s390/boot/ipl_report.c: In function 'find_bootdata_space': arch/s390/boot/ipl_report.c:42:26: warning: taking address of packed member of 'struct ipl_rb_components' may result in an unaligned pointer value [-Waddress-of-packed-member] 42 | for_each_rb_entry(comp, comps) | ^~~~~ This is effectively the s390 variant of commit 20c6c189 ("x86/boot: Disable the address-of-packed-member compiler warning"). Reviewed-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Teresa Remmet authored
[ Upstream commit 8a0098c0 ] Active level of the mmc1 cd gpio needs to be low instead of high. Fix PCM-953 and phyBOARD-WEGA. Signed-off-by:
Teresa Remmet <t.remmet@phytec.de> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit 7c940b1a ] The return values for these memory allocations are unchecked, which may cause an oops if the driver does not handle them after a failure. Fix by checking the function's return code. Signed-off-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit be32a243 ] It was observed that multicast packets were no longer received after a device reset. The fix is to resend the current multicast list to the backing device after recovery. Signed-off-by:
-
Thomas Falcon authored
[ Upstream commit 1f94608b ] Check driver state before halting it during a reset. If the driver is not running, do nothing. Otherwise, a request to deactivate a down link can cause an error and the reset will fail. Signed-off-by:
-
Michael Schmitz authored
[ Upstream commit a9520543 ] [Resent to net instead of net-next - may clash with Anders Roxell's patch series addressing duplicate module names] Commit 31dd83b9 ("net-next: phy: new Asix Electronics PHY driver") introduced a new PHY driver drivers/net/phy/asix.c that causes a module name conflict with a pre-existiting driver (drivers/net/usb/asix.c). The PHY driver is used by the X-Surf 100 ethernet card driver, and loaded by that driver via its PHY ID. A rename of the driver looks unproblematic. Rename PHY driver to ax88796b.c in order to resolve name conflict. Signed-off-by:
Michael Schmitz <schmitzmic@gmail.com> Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit eb503004 ] Currently the following message is observed when the flexcan driver is probed: flexcan 2090000.flexcan: device registered (reg_base=(ptrval), irq=23) The reason for printing 'ptrval' is explained at Documentation/core-api/printk-formats.rst: "Pointers printed without a specifier extension (i.e unadorned %p) are hashed to prevent leaking information about the kernel memory layout. This has the added benefit of providing a unique identifier. On 64-bit machines the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it gathers enough entropy." Instead of passing %pK, which can print the correct address, simply remove the entire message as it is not really that useful. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
