- 04 May, 2016 40 commits
-
-
Dan Carpenter authored
commit 93fce954 upstream. At the end of the function we expect "status" to be zero, but it's either -EINVAL or uninitialized. Fixes: 788bf83d ('drm/amdkfd: Add wave control operation to debugger') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ville Syrjälä authored
commit fa5a7970 upstream. Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler(). The former is a mask, the latter just the bit number. Fortunately the only thing skl_update_scaler() does with the rotation is check if it's 90/270 degrees or not, and so in this case it would still do the right thing. Cc: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1444917718-28495-1-git-send-email-ville.syrjala@linux.intel.com Fixes: 6156a456 ("drm/i915: skylake primary plane scaling using shared scalers") Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit f1ecaf8f upstream. ilk_compute_pipe_wm() assumes as zeroed pipe_wm structure when it starts. We used to pass such a zeroed struct in, but this got broken when the pipe_wm structure got embedded in the crtc state. To fix it without too much fuzz, we need to resort to a memset(). Fixes: 4e0963c7 ("drm/i915: Calculate pipe watermarks into CRTC state (v3)") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit d890565c upstream. ilk_program_watermarks() is supposed to merge the active watermarks from all pipes. Thus we need to use the active config too instead of some precomputed stuff. Fixes: aa363136 ("drm/i915: Calculate watermark configuration during atomic check (v2)") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7d3fdfff upstream. Restore the lost phys status page cleanup. Fixes the following splat with DMA_API_DEBUG=y: WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974 dma_debug_device_change+0x190/0x1f0() pci 0000:00:02.0: DMA-API: device driver has pending DMA allocations while released from device [count=1] One of leaked entries details: [device address=0x0000000023163000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] Modules linked in: i915(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sha256_generic hmac drbg ctr ccm sch_fq_codel binfmt_misc joydev mousedev arc4 ath5k iTCO_wdt mac80211 smsc_ircc2 ath snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm input_leds i2c_i801 pcspkr snd_timer cfg80211 snd soundcore i2c_core ehci_pci firewire_ohci ehci_hcd firewire_core lpc_ich 8139too rfkill crc_itu_t mfd_core mii usbcore rng_core intel_agp intel_gtt usb_common agpgart irda crc_ccitt fujitsu_laptop led_class parport_pc video parport evdev backlight CPU: 0 PID: 21615 Comm: rmmod Tainted: G U 4.4.0-rc4-mgm-ovl+ #4 Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004 e31a3de0 e31a3de0 e31a3d9c c128d4bd e31a3dd0 c1045a0c c15e00c4 e31a3dfc 0000546f c15dfad2 000003ce c12b3740 000003ce c12b3740 00000000 00000001 f61fb8a0 e31a3de8 c1045a83 00000009 e31a3de0 c15e00c4 e31a3dfc e31a3e4c Call Trace: [<c128d4bd>] dump_stack+0x16/0x19 [<c1045a0c>] warn_slowpath_common+0x8c/0xd0 [<c12b3740>] ? dma_debug_device_change+0x190/0x1f0 [<c12b3740>] ? dma_debug_device_change+0x190/0x1f0 [<c1045a83>] warn_slowpath_fmt+0x33/0x40 [<c12b3740>] dma_debug_device_change+0x190/0x1f0 [<c1065499>] notifier_call_chain+0x59/0x70 [<c10655af>] __blocking_notifier_call_chain+0x3f/0x80 [<c106560f>] blocking_notifier_call_chain+0x1f/0x30 [<c134cfb3>] __device_release_driver+0xc3/0xf0 [<c134d0d7>] driver_detach+0x97/0xa0 [<c134c440>] bus_remove_driver+0x40/0x90 [<c134db18>] driver_unregister+0x28/0x60 [<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0 [<c12c0618>] pci_unregister_driver+0x18/0x80 [<f83e96e7>] drm_pci_exit+0x87/0xb0 [drm] [<f8b3be2d>] i915_exit+0x1b/0x1ee [i915] [<c10b999c>] SyS_delete_module+0x14c/0x210 [<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0 [<c115a9bd>] ? ____fput+0xd/0x10 [<c1002014>] do_fast_syscall_32+0xa4/0x450 [<c149f6fa>] sysenter_past_esp+0x3b/0x5d ---[ end trace c2ecbc77760f10a0 ]--- Mapped at: [<c12b3183>] debug_dma_alloc_coherent+0x33/0x90 [<f83e989c>] drm_pci_alloc+0x18c/0x1e0 [drm] [<f8acd59f>] intel_init_ring_buffer+0x2af/0x490 [i915] [<f8acd8b0>] intel_init_render_ring_buffer+0x130/0x750 [i915] [<f8aaea4e>] i915_gem_init_rings+0x1e/0x110 [i915] v2: s/BUG_ON/WARN_ON/ since dim doens't like the former anymore Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 5c6c6003 ("drm/i915: Remove DRI1 ring accessors and API") Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
commit d919161b upstream. We're supposed to pass the primary DP encoder to intel_ddi_clk_select(), not the fake MST encoder. Do so. There's no real bug here though, since intel_ddi_clk_select() only checks if the encoder type is EDP (which it isn't for either the primary DP encoder or the fake MST encoder), and it gets the DDI port via intel_ddi_get_encoder_port() (which knows how to do the fake->primary->port dance itself). Fixes: e404ba8 ("drm/i915: Setup DDI clk for MST on SKL") Signed-off-by:
-
Vladimir Zapolskiy authored
commit c5857e3f upstream. The change fixes potential oops while accessing iomem on invalid address if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Fixes: 3a9f5957 ("pwm: Add Broadcom BCM7038 PWM controller support") Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
cpaul@redhat.com authored
commit 263efde3 upstream. We can thank KASAN for finding this, otherwise I probably would have spent hours on it. This fixes a somewhat harder to trigger kernel panic, occuring while enabling MST where the port we were currently updating the payload on would have all of it's refs dropped before we finished what we were doing: ================================================================== BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018 Read of size 4 by task Xorg/973 ============================================================================= BUG kmalloc-2048 (Tainted: G B W ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175 ___slab_alloc+0x472/0x490 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x151/0x190 drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] drm_dp_send_link_address+0x526/0x960 [drm_kms_helper] drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper] drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175 __slab_free+0x17f/0x2d0 kfree+0x169/0x180 drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper] process_one_work+0x562/0x1350 worker_thread+0xd9/0x1390 kthread+0x1c5/0x260 ret_from_fork+0x22/0x40 which on this T460s, would eventually lead to kernel panics in somewhat random places later in intel_mst_enable_dp() if we got lucky enough. Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Lyude authored
commit 9dc0487d upstream. Some hubs are forgetful, and end up forgetting whatever GUID we set previously after we do a suspend/resume cycle. This can lead to hotplugging breaking (along with probably other things) since the hub will start sending connection notifications with the wrong GUID. As such, we need to check on resume whether or not the GUID the hub is giving us is valid. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
cpaul@redhat.com authored
commit deba0a2a upstream. With the joys of things running concurrently, there's always a chance that the port we get passed in drm_dp_payload_send_msg() isn't actually valid anymore. Because of this, we need to make sure we validate the reference to the port before we use it otherwise we risk running into various race conditions. For instance, on the Dell MST monitor I have here for testing, hotplugging it enough times causes us to kernel panic: [drm:intel_mst_enable_dp] 1 [drm:drm_dp_update_payload_part2] payload 0 1 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020 [drm:intel_hpd_irq_handler] digital hpd port B - short [drm:intel_dp_hpd_pulse] got hpd irq on port B - short [drm:intel_dp_check_mst_status] got esi 00 10 00 [drm:drm_dp_update_payload_part2] payload 1 1 general protection fault: 0000 [#1] SMP … Call Trace: [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper] [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915] [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915] [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915] [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm] [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm] [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper] [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm] [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm] [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm] [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm] [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0 [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570 [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80 [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90 [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4 RIP [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper] Which occurs because of the hotplug event shown in the log, which ends up causing DRM's dp helpers to drop the port we're updating the payload on and panic. Signed-off-by:
David Airlie <airlied@linux.ie> Signed-off-by:
-
Ben Skeggs authored
commit 28dca905 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Huacai Chen authored
commit 221004c6 upstream. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Vitaly Prosyak authored
commit 5d5b7803 upstream. When crtc/timing is disabled on boot the dig block should be stopped in order ignore timing from crtc, reset the steering fifo otherwise we get display corruption or hung in dp sst mode. v2: agd: fix coding style Signed-off-by:
Vitaly Prosyak <vitaly.prosyak@amd.com> Signed-off-by:
-
Jérôme Glisse authored
commit b5dcec69 upstream. Allowing userptr bo which are basicly a list of page from some vma (so either anonymous page or file backed page) would lead to serious corruption of kernel structures and counters (because we overwrite the page->mapping field when mapping buffer). This will already block if the buffer was populated before anyone does try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm vm fault handler. So to be safe just add a check to verify_access() callback. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 7403c515 upstream. This got lost somewhere along the way. This fixes audio not working until set_property was called. Noticed-by:
Hyungwon Hwang <hyungwon.hwang7@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit bcb31eba upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by:
-
Grigori Goronzy authored
This fix was written against drm-next, but when it was backported to 4.5 as a stable fix, the driver internal structure change was missed. Fix that up here to avoid a hang due to waiting for the wrong sequence number. v2: agd: fix up commit message Signed-off-by:
Grigori Goronzy <greg@chown.ath.cx> Cc: stable@vger.kernel.org Signed-off-by:
-
Sonny Jiang authored
commit 562e2689 upstream. Was previously always hardcoded to 0. Signed-off-by:
Sonny Jiang <sonny.jiang@amd.com> Reviewed-by:
-
Alex Deucher authored
commit 83c5cda2 upstream. Fixes array overflow on these chips. Reviewed-by:
-
Alex Deucher authored
commit 3ea25f85 upstream. Prerequiste for the next patch which ups the limits. Reviewed-by:
-
Rex Zhu authored
commit 85cc88f0 upstream. fix the issue that when resume back, uvd/vce dpm was disabled and uvd/vce's performace dropped. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Robin Murphy authored
commit 07b48ac4 upstream. With the change to stashing just the IOVA-page-aligned remainder of the CPU-page offset rather than the whole thing, the failure path in __invalidate_sg() also needs tweaking to account for that in the case of differing page sizes where the two offsets may not be equivalent. Similarly in __finalise_sg(), lest the architecture-specific wrappers later get the wrong address for cache maintenance on sync or unmap. Fixes: 164afb1d ("iommu/dma: Use correct offset in map_sg") Reported-by:
Magnus Damm <damm+renesas@opensource.se> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Joerg Roedel authored
commit e3156048 upstream. Commit 61289cba ('iommu/amd: Remove old alias handling code') removed the old alias handling code from the AMD IOMMU driver because this is now handled by the IOMMU core code. But this also removed the handling of PCI aliases, which is not handled by the core code. This caused issues with PCI devices that have hidden PCIe-to-PCI bridges that rewrite the request-id. Fix this bug by re-introducing some of the removed functions from commit 61289cba and add a alias field 'struct iommu_dev_data'. This field carrys the return value of the get_alias() function and uses that instead of the amd_iommu_alias_table[] array in the code. Fixes: 61289cba ('iommu/amd: Remove old alias handling code') Tested-by:
Tomasz Golinski <tomaszg@math.uwb.edu.pl> Signed-off-by:
-
Keerthy authored
commit 56b367c0 upstream. pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a corner case where we try to request the pin number = MAX and fails. bit_pos value is being calculted using ffs. pin_num_from_lsb uses bit_pos value. pins array is populated with: pin + pin_num_from_lsb. The above is 1 more than usual bit indices as bit_pos uses ffs to compute first set bit. Hence the last of the pins array is populated with the MAX value and not MAX - 1 which causes error when we call pin_request. mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1)) Consequently val_pos and submask are correct. Hence use __ffs which gives (ffs(x) - 1) as the first bit set. fixes: 4e7e8017 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by:
Keerthy <j-keerthy@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Yingjoe Chen authored
commit 5fedbb92 upstream. The debounce time unit for gpio_chip.set_debounce is us but mtk_gpio_set_debounce regard it as ms. Fix this by correct debounce time array dbnc_arr so it can find correct debounce setting. Debounce time for first debounce setting is 500us, correct this as well. While I'm at it, also change the debounce time array name to "debounce_time" for readability. Signed-off-by:
Yingjoe Chen <yingjoe.chen@mediatek.com> Reviewed-by:
Daniel Kurtz <djkurtz@chromium.org> Acked-by:
Hongzhou Yang <hongzhou.yang@mediatek.com> Signed-off-by:
-
Arnd Bergmann authored
commit 13aa38e2 upstream. The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Suggested-by:
David Vrabel <david.vrabel@citrix.com> Fixes: 36c1132e ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Stephen Boyd authored
commit eda5ecc0 upstream. The trigger delay algorithm that converts from microseconds to the register value looks incorrect. According to most of the PMIC documentation, the equation is delay (Seconds) = (1 / 1024) * 2 ^ (x + 4) except for one case where the documentation looks to have a formatting issue and the equation looks like delay (Seconds) = (1 / 1024) * 2 x + 4 Most likely this driver was written with the improper documentation to begin with. According to the downstream sources the valid delays are from 2 seconds to 1/64 second, and the latter equation just doesn't make sense for that. Let's fix the algorithm and the range check to match the documentation and the downstream sources. Reported-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Fixes: 92d57a73 ("input: Add support for Qualcomm PMIC8XXX power key") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Tested-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Vladis Dronov authored
commit 162f98de upstream. The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. Also let's fix a minor coding style issue. The full correct report of this issue can be found in the public Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283385Reported-by:
Ralf Spenneberg <ralf@spenneberg.net> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
-
Dmitry Ivanov authored
commit e2726020 upstream. All existing users of NETLINK_URELEASE use it to clean up resources that were previously allocated to a socket via some command. As a result, no users require getting this notification for unbound sockets. Sending it for unbound sockets, however, is a problem because any user (including unprivileged users) can create a socket that uses the same ID as an existing socket. Binding this new socket will fail, but if the NETLINK_URELEASE notification is generated for such sockets, the users thereof will be tricked into thinking the socket that they allocated the resources for is closed. In the nl80211 case, this will cause destruction of virtual interfaces that still belong to an existing hostapd process; this is the case that Dmitry noticed. In the NFC case, it will cause a poll abort. In the case of netlink log/queue it will cause them to stop reporting events, as if NFULNL_CFG_CMD_UNBIND/NFQNL_CFG_CMD_UNBIND had been called. Fix this problem by checking that the socket is bound before generating the NETLINK_URELEASE notification. Signed-off-by:
Dmitry Ivanov <dima@ubnt.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dmitry Ivanov authored
commit 8f815cdd upstream. A non-privileged user can create a netlink socket with the same port_id as used by an existing open nl80211 netlink socket (e.g. as used by a hostapd process) with a different protocol number. Closing this socket will then lead to the notification going to nl80211's socket release notification handler, and possibly cause an action such as removing a virtual interface. Fix this issue by checking that the netlink protocol is NETLINK_GENERIC. Since generic netlink has no notifier chain of its own, we can't fix the problem more generically. Fixes: 026331c4 ("cfg80211/mac80211: allow registering for and sending action frames") Signed-off-by:
-
Anton Blanchard authored
commit 4705e024 upstream. We need to update the user TM feature bits (PPC_FEATURE2_HTM and PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature bit. At the moment, if firmware reports TM is not available we turn off the kernel TM feature bit but leave the userspace ones on. Userspace thinks it can execute TM instructions and it dies trying. This (together with a QEMU patch) fixes PR KVM, which doesn't currently support TM. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Anton Blanchard authored
commit beff8237 upstream. scan_features() updates cpu_user_features but not cpu_user_features2. Amongst other things, cpu_user_features2 contains the user TM feature bits which we must keep in sync with the kernel TM feature bit. Signed-off-by:
-
Anton Blanchard authored
commit 6997e57d upstream. The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3 ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by:
-
Horia Geant? authored
commit 340ff60a upstream. After conversion to new AEAD interface, tcrypt tests fail as follows: [...] [ 1.145414] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos [ 1.153564] 00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67 [ 1.160041] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.166509] 00000020: 00 00 00 00 [...] Fix them by providing the correct cipher in & cipher out pointers, i.e. must skip over associated data in src and dst S/G. While here, fix a problem with the HW S/G table index usage: tbl_off must be updated after the pointer to the table entries is set. Fixes: aeb4c132 ("crypto: talitos - Convert to new AEAD interface") Reported-by:
Jonas Eymann <J.Eymann@gmx.net> Signed-off-by:
Horia Geant? <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jonas Eymann authored
commit 89d124cb upstream. Conversion of talitos driver to the new AEAD interface hasn't been properly tested. AEAD algorithms crash in talitos_cra_init as follows: [...] [ 1.141095] talitos ffe30000.crypto: hwrng [ 1.145381] Unable to handle kernel paging request for data at address 0x00000058 [ 1.152913] Faulting instruction address: 0xc02accc0 [ 1.157910] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.163315] SMP NR_CPUS=2 P1020 RDB [ 1.166810] Modules linked in: [ 1.169875] CPU: 0 PID: 1007 Comm: cryptomgr_test Not tainted 4.4.6 #1 [ 1.176415] task: db5ec200 ti: db4d6000 task.ti: db4d6000 [ 1.181821] NIP: c02accc0 LR: c02acd18 CTR: c02acd04 [ 1.186793] REGS: db4d7d30 TRAP: 0300 Not tainted (4.4.6) [ 1.192457] MSR: 00029000 <CE,EE,ME> CR: 95009359 XER: e0000000 [ 1.198585] DEAR: 00000058 ESR: 00000000 GPR00: c017bdc0 db4d7de0 db5ec200 df424b48 00000000 00000000 df424bfc db75a600 GPR08: df424b48 00000000 db75a628 db4d6000 00000149 00000000 c0044cac db5acda0 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 df424940 GPR24: df424900 00003083 00000400 c0180000 db75a640 c03e9f84 df424b40 df424b48 [ 1.230978] NIP [c02accc0] talitos_cra_init+0x28/0x6c [ 1.236039] LR [c02acd18] talitos_cra_init_aead+0x14/0x28 [ 1.241443] Call Trace: [ 1.243894] [db4d7de0] [c03e9f84] 0xc03e9f84 (unreliable) [ 1.249322] [db4d7df0] [c017bdc0] crypto_create_tfm+0x5c/0xf0 [ 1.255083] [db4d7e10] [c017beec] crypto_alloc_tfm+0x98/0xf8 [ 1.260769] [db4d7e40] [c0186a20] alg_test_aead+0x28/0xc8 [ 1.266181] [db4d7e60] [c0186718] alg_test+0x260/0x2e0 [ 1.271333] [db4d7ee0] [c0183860] cryptomgr_test+0x30/0x54 [ 1.276843] [db4d7ef0] [c0044d80] kthread+0xd4/0xd8 [ 1.281741] [db4d7f40] [c000e4a4] ret_from_kernel_thread+0x5c/0x64 [ 1.287930] Instruction dump: [ 1.290902] 38600000 4e800020 81230028 7c681b78 81490010 38e9ffc0 3929ffe8 554a073e [ 1.298691] 2b8a000a 7d474f9e 812a0008 91230030 <80e90058> 39270060 7c0004ac 7cc04828 Fixes: aeb4c132 ("crypto: talitos - Convert to new AEAD interface") Signed-off-by:
-
Xiaodong Liu authored
commit 0851561d upstream. In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used when check and complete other jobs. If the memory of first completed req is freed, while still completing other jobs in the func, kernel will crash since NULL pointer is assigned to RIP. Signed-off-by:
Xiaodong Liu <xiaodong.liu@intel.com> Acked-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Tom Lendacky authored
commit f709b45e upstream. Prevent information from leaking to userspace by doing a memset to 0 of the export state structure before setting the structure values and copying it. This prevents un-initialized padding areas from being copied into the export area. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Tadeusz Struk authored
commit 6f0904ad upstream. The output buffer length has to be at least as big as the key_size. It is then updated to the actual output size by the implementation. Signed-off-by:
Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by:
-
Matti Gottlieb authored
commit 7fdf9663 upstream. Currently paging download buffer is freed during the the unloading of the opmode which happens when the driver is unloaded. This causes a memory leak since the paging download buffer is allocated every time we enable the interface, so the download buffer can be allocated many times, but only be freed once. Free paging download buffer during disabling of the interface. Signed-off-by:
Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 9fc515bc upstream. IWL_INFO is not an error but still printed by default. "can't access the RSA semaphore it is write protected" seems worrisome but it is not really a problem. Signed-off-by:
-
