- 14 Feb, 2018 1 commit
-
-
Liviu Dudau authored
Currently the Mali DP version of atomic_commit_hw_done sets the 'go' bit (config_valid) before arming the vblank event to be sent to userspace. As the comments for drm_crtc_arm_vblank_event() warn, that is a sure recipe for sending the vblank event at the wrong vblank interrupt. The correct way of handling this (as hinted by the comments) is to send the vblank event from the IRQ handler and only set the 'go' bit in the atomic_commit_hw_done() hook. Currently the malidp_atomic_commit_hw_done() function still sends the vblank event if the CRTC is disabled, due to IRQs being turned off before the last commit which turns off the CRTC. That will be sorted out in a future patch that will re-order the de-activation of IRQs. Reported-by:
Alexandru-Cosmin Gheorghe <alexandru-cosmin.gheorghe@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
- 12 Feb, 2018 39 commits
-
-
Liviu Dudau authored
HDLCD cannot turn off its primary plane and as such it should not accept states where the CRTC is active but no primary fb is provided. Discovered while playing with modetest and the HDLCD behind an active SMMU which complained loudly that the driver was reading from invalid memory. Signed-off-by: -
The plane cleanup handler currently calls drm_plane_helper_disable(), which is a legacy helper function. Replace it with a call to drm_atomic_helper_shutdown() at removal time. Signed-off-by:Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
The top-level error handler calls drm_mode_config_cleanup() which will destroy all planes. There's no need to destroy them manually in lower error handlers. As plane cleanup is now handled entirely by drm_mode_config_cleanup(), we must ensure that the plane .destroy() handler frees allocated memory for the plane object that was freed by malidp_de_planes_destroy(). Do so by replacing the call to devm_kfree() in the .destroy() handler by kfree(). devm_kfree() is currently a no-op as the plane memory is allocated with kzalloc(), not devm_kzalloc(). Signed-off-by: -
The plane cleanup handler currently calls drm_plane_helper_disable(), which is a legacy helper function. Replace it with a call to drm_atomic_helper_shutdown() at removal time. The plane .destroy() handler now consisting only of a call to drm_plane_cleanup(), replace it with direct calls to that function. Signed-off-by: -
The top-level error handler calls drm_mode_config_cleanup() which will destroy all planes. There's no need to destroy them manually in lower error handlers. Signed-off-by: -
Mali dp needs to disable pixel alpha blending (use layer alpha blending) to display color formats that do not contain alpha bits per pixel Signed-off-by:Ayan Kumar Halder <ayan.halder@arm.com>
-
drm_format_info does not describe the number of bits used for the alpha channel. That information is useful in a central place like drm_fourcc.c where it can be queried by the drivers that want to determine if 'alpha blending' is to be enabled or not. Signed-off-by:
-
In the case, when the user wants to scale and rotate a layer by 90/270 degrees, the scaling engine input dimensions' parameters ie width and height needs to be swapped with respect to the layer's input dimensions. This means scaling engine input height should be set to layer's input width and scaling engine input width should be set to layer's input height. Signed-off-by: -
Liviu Dudau authored
Currently the scaling engine gets enabled for a plane where the input size differs from the composition size. As rotation is done natively by the plane's hardware layer, we don't need the scaling engine to be enabled. Signed-off-by: -
Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on the fact that drm_device holds a pointer to the drm_fb_helper structure. This means that the driver doesn't have to keep track of that. Also use the drm_fb_helper functions directly. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Replace driver's code with the generic helpers that do the same thing including the NULL check. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by: -
We use "mc" without initializing it if scaling is not necessary. Fixes: 28ce675b ("drm: mali-dp: Add plane upscaling support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com>
-
Liviu Dudau authored
Mali DP hardware needs pitch line sizes aligned to the bus burst size for reads, so take that into consideration when allocating dumb buffers. If the layer is rotated then the stride size requirement is even larger for some hardware versions, so allocate for the worst case scenario. Update the ->dumb_create() hook to a driver specific function that sets the correct pitch size. Reported-by:
-
Liviu Dudau authored
Rotated planes need a pitch size that is aligned to 8 bytes for older DP500 and DP550 and at least 64 bytes for DP650. Replace the malidp_hw_pitch_valid() function with one that calculates the correct pitch alignment to take into account rotation. Signed-off-by: -
Liviu Dudau authored
Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"), if no output is connected at framebuffer setup time, we get a default 1024x768 mode that is going to be used when we first connect a monitor. After the commit, on first connection after deferred setup, we probe the monitor and get the preferred resolution, but no mode get set because the drm_fb_helper_hotplug_event() function returns early when the setup has been deferred. That is different from what happens on a second re-connect of the monitor, when the native mode get set. Create a more consistent behaviour by checking in the drm_fb_helper_hotplug_event() function if the deferred setup is still active. If not, that means we now have a valid framebuffer that can be used for setting the correct mode. Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup") Signed-off-by: -
Liviu Dudau authored
For testing purposes only. Signed-off-by: -
Allow stage 1 contexts to default to short-descriptor format if supported and all DRAM is 32-bit-addressable. Signed-off-by:Robin Murphy <robin.murphy@arm.com>
-
Keep track of the allocation details too. Signed-off-by: -
Dump IOVA usage via debugfs. Signed-off-by: -
Liviu Dudau authored
-
Liviu Dudau authored
Also enable the SMMU in front of the HDLCD device. Signed-off-by: -
Liviu Dudau authored
Signed-off-by: -
Liviu Dudau authored
Add support for the FPGA V2F-1XV7 Coretile that can be loaded with a Mali-DP instance. Signed-off-by: -
Internally Mali DP uses an RGB pipeline so video layers that support YUV input buffers need to convert the input data to RGB. The YUV buffers can have various encodings and this patch introduces support for BT.601, BT.709 and BT.2020 encodings, both limited and full ranges. This patch adds support for specifying the color encoding of the input buffers for the planes that are backed by the video layers and programs the YUV2RGB coefficients into hardware based on the selected encoding. Signed-off-by:
Mihail Atanassov <mihail.atanassov@arm.com> [updated to use standard properties] Signed-off-by:
-
Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. Signed-off-by:Jyri Sarha <jsarha@ti.com>
-
Mali-DP has a memory writeback engine which can be used to write the composition result to a memory buffer. Expose this functionality as a DRM writeback connector on supported hardware. Changes since v1: Daniel Vetter: - Don't require a modeset when writeback routing changes - Make writeback connector always disconnected Changes since v2: - Rebase onto new drm_writeback_connector - Add reset callback, allocating subclassed state Daniel Vetter: - Squash out-fence support into this commit Gustavo Padovan: - Don't signal fence directly from driver (and drop malidp_mw_job) Changes since v3: - Modifications to fit with Mali-DP commit tail changes Signed-off-by:
Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by:
-
Add a layer bit for the SE memory-write, and add it to the pixel format matrix for DP550/DP650. Signed-off-by:
-
Liviu Dudau authored
Mali-DP display processors are able to write the composition result to a memory buffer via the SE. Add entry points in the HAL for enabling/disabling this feature, and implement support for it on DP650 and DP550. DP500 acts differently and so is omitted from this change. Changes since v3: - Fix missing vsync interrupt for DP550 Signed-off-by:
-
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. It is not allowed to request an out-fence without a framebuffer attached to the connector. A timeline is added to drm_writeback_connector for use by the writeback out-fences. In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence is set to -1. Changes from v2: - Rebase onto Gustavo Padovan's v9 explicit sync series - Change out_fence_ptr type to s32 __user * - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property - Store fence in drm_writeback_job Gustavo Padovan: - Move out_fence_ptr out of connector_state - Signal fence from drm_writeback_signal_completion instead of in driver directly Changes from v3: - Rebase onto 7e9081c5 drm/fence: fix memory overwrite when setting out_fence fd (change out_fence_ptr to s32 __user *, for real this time.) - Update doc...
-
Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Signed-off-by:
-
Liviu Dudau authored
When enabling lockdep debugging on Juno platform with HDLCD and TDA998x I get the following warning from the system: [ 25.990733] ====================================================== [ 25.998637] WARNING: possible circular locking dependency detected [ 26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted [ 26.014246] ------------------------------------------------------ [ 26.022142] kworker/1:2/140 is trying to acquire lock: [ 26.029001] (&priv->audio_mutex){+.+.+.}, at: [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x] [ 26.041100] [ 26.041100] but task is already holding lock: [ 26.050436] (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm] [ 26.061531] [ 26.061531] which lock already depends on the new lock. [ 26.061531] [ 26.075063] [ 26.075063] the existing dependency chain (in reverse order) is: [ 26.086031] [ 26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}: [ 26.095657] __lock_acquire+0x18a0/0x19b8 [ 26.101918] lock_acquire+0xd0/0x2b0 [ 26.107731] __ww_mutex_lock.constprop.3+0x90/0xe78 [ 26.114817] ww_mutex_lock+0x54/0xe0 [ 26.120672] drm_modeset_lock+0x64/0xf8 [drm] [ 26.127253] drm_helper_probe_single_connector_modes+0x7c/0x6b8 [drm_kms_helper] [ 26.136829] tda998x_connector_fill_modes+0x44/0xa8 [tda998x] [ 26.144797] drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper] [ 26.152429] drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper] [ 26.161097] drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper] [ 26.169857] drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper] [ 26.177559] hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd] [ 26.184310] try_to_bring_up_master+0x180/0x1e0 [ 26.191043] component_master_add_with_match+0xb0/0x108 [ 26.198458] hdlcd_probe+0x58/0x80 [hdlcd] [ 26.204735] platform_drv_probe+0x60/0xc0 [ 26.210913] driver_probe_device+0x23c/0x2e8 [ 26.217350] __driver_attach+0xd4/0xd8 [ 26.223256] bus_for_each_dev+0x5c/0xa8 [ 26.229232] driver_attach+0x30/0x40 [ 26.234917] bus_add_driver+0x1d8/0x248 [ 26.240831] driver_register+0x6c/0x118 [ 26.246715] __platform_driver_register+0x54/0x60 [ 26.253461] 0xffff000000e1b018 [ 26.258644] do_one_initcall+0x44/0x138 [ 26.264503] do_init_module+0x64/0x1d4 [ 26.270238] load_module+0x1f90/0x2590 [ 26.275957] SyS_finit_module+0xb0/0xc8 [ 26.281765] __sys_trace_return+0x0/0x4 [ 26.281767] [ 26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}: [ 26.281778] __lock_acquire+0x18a0/0x19b8 [ 26.281782] lock_acquire+0xd0/0x2b0 [ 26.281877] drm_modeset_acquire_init+0xa8/0xe0 [drm] [ 26.281921] drm_helper_probe_single_connector_modes+0x48/0x6b8 [drm_kms_helper] [ 26.281929] tda998x_connector_fill_modes+0x44/0xa8 [tda998x] [ 26.281970] drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper] [ 26.282009] drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper] [ 26.282049] drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper] [ 26.282088] drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper] [ 26.282095] hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd] [ 26.282099] try_to_bring_up_master+0x180/0x1e0 [ 26.282104] component_master_add_with_match+0xb0/0x108 [ 26.282110] hdlcd_probe+0x58/0x80 [hdlcd] [ 26.282114] platform_drv_probe+0x60/0xc0 [ 26.282117] driver_probe_device+0x23c/0x2e8 [ 26.282121] __driver_attach+0xd4/0xd8 [ 26.282124] bus_for_each_dev+0x5c/0xa8 [ 26.282127] driver_attach+0x30/0x40 [ 26.282130] bus_add_driver+0x1d8/0x248 [ 26.282134] driver_register+0x6c/0x118 [ 26.282138] __platform_driver_register+0x54/0x60 [ 26.282141] 0xffff000000e1b018 [ 26.282145] do_one_initcall+0x44/0x138 [ 26.282149] do_init_module+0x64/0x1d4 [ 26.282152] load_module+0x1f90/0x2590 [ 26.282156] SyS_finit_module+0xb0/0xc8 [ 26.282159] __sys_trace_return+0x0/0x4 [ 26.282161] [ 26.282161] -> #0 (&priv->audio_mutex){+.+.+.}: [ 26.282172] print_circular_bug+0x80/0x2e0 [ 26.282176] __lock_acquire+0x15a8/0x19b8 [ 26.282180] lock_acquire+0xd0/0x2b0 [ 26.282184] __mutex_lock+0x78/0x8e0 [ 26.282188] mutex_lock_nested+0x3c/0x50 [ 26.282196] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x] [ 26.282237] drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper] [ 26.282251] malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp] [ 26.282292] commit_tail+0x4c/0x80 [drm_kms_helper] [ 26.282333] drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper] [ 26.282427] drm_atomic_commit+0x54/0x70 [drm] [ 26.282467] restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper] [ 26.282507] restore_fbdev_mode+0x38/0x188 [drm_kms_helper] [ 26.282547] drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper] [ 26.282586] drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper] [ 26.282625] drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper] [ 26.282665] drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper] [ 26.282704] drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper] [ 26.282716] malidp_output_poll_changed+0x24/0x30 [mali_dp] [ 26.282757] drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper] [ 26.282797] output_poll_execute+0x1a0/0x1f0 [drm_kms_helper] [ 26.282803] process_one_work+0x280/0x790 [ 26.282808] worker_thread+0x48/0x450 [ 26.282812] kthread+0x138/0x140 [ 26.282815] ret_from_fork+0x10/0x40 [ 26.282817] [ 26.282817] other info that might help us debug this: [ 26.282817] [ 26.282819] Chain exists of: [ 26.282819] &priv->audio_mutex --> crtc_ww_class_acquire --> crtc_ww_class_mutex [ 26.282819] [ 26.282830] Possible unsafe locking scenario: [ 26.282830] [ 26.282832] CPU0 CPU1 [ 26.282834] ---- ---- [ 26.282835] lock(crtc_ww_class_mutex); [ 26.282840] lock(crtc_ww_class_acquire); [ 26.282845] lock(crtc_ww_class_mutex); [ 26.282850] lock(&priv->audio_mutex); [ 26.282854] [ 26.282854] *** DEADLOCK *** [ 26.282854] [ 26.282858] 5 locks held by kworker/1:2/140: [ 26.282859] #0: ("events"){.+.+.+}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790 [ 26.282871] #1: ((&(&dev->mode_config.output_poll_work)->work)){+.+.+.}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790 [ 26.282883] #2: (&helper->lock){+.+.+.}, at: [<ffff000000c0631c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0xd0 [drm_kms_helper] [ 26.282929] #3: (crtc_ww_class_acquire){+.+.+.}, at: [<ffff000000c02d80>] restore_fbdev_mode_atomic+0x38/0x220 [drm_kms_helper] [ 26.282976] #4: (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm] [ 26.283077] [ 26.283077] stack backtrace: [ 26.283082] CPU: 1 PID: 140 Comm: kworker/1:2 Not tainted 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 [ 26.283084] Hardware name: ARM Juno development board (r0) (DT) [ 26.283127] Workqueue: events output_poll_execute [drm_kms_helper] [ 26.283131] Call trace: [ 26.283137] [<ffff00000808a778>] dump_backtrace+0x0/0x268 [ 26.283142] [<ffff00000808aabc>] show_stack+0x24/0x30 [ 26.283146] [<ffff000008aa36a8>] dump_stack+0xbc/0xf4 [ 26.283151] [<ffff00000812f454>] print_circular_bug+0x1d4/0x2e0 [ 26.283155] [<ffff000008132480>] __lock_acquire+0x15a8/0x19b8 [ 26.283159] [<ffff000008133008>] lock_acquire+0xd0/0x2b0 [ 26.283163] [<ffff000008aba060>] __mutex_lock+0x78/0x8e0 [ 26.283168] [<ffff000008aba904>] mutex_lock_nested+0x3c/0x50 [ 26.283176] [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x] [ 26.283217] [<ffff000000c00050>] drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper] [ 26.283230] [<ffff000000f1bd0c>] malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp] [ 26.283271] [<ffff000000c0045c>] commit_tail+0x4c/0x80 [drm_kms_helper] [ 26.283312] [<ffff000000c00630>] drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper] [ 26.283406] [<ffff000000eb1604>] drm_atomic_commit+0x54/0x70 [drm] [ 26.283447] [<ffff000000c02f38>] restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper] [ 26.283487] [<ffff000000c03cf0>] restore_fbdev_mode+0x38/0x188 [drm_kms_helper] [ 26.283526] [<ffff000000c06324>] drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper] [ 26.283566] [<ffff000000c0619c>] drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper] [ 26.283606] [<ffff000000c0627c>] drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper] [ 26.283645] [<ffff000000c062c4>] drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper] [ 26.283685] [<ffff000000c07124>] drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper] [ 26.283697] [<ffff000000f1b44c>] malidp_output_poll_changed+0x24/0x30 [mali_dp] [ 26.283738] [<ffff000000bf5264>] drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper] [ 26.283779] [<ffff000000bf5480>] output_poll_execute+0x1a0/0x1f0 [drm_kms_helper] [ 26.283784] [<ffff0000080f85a8>] process_one_work+0x280/0x790 [ 26.283788] [<ffff0000080f8b00>] worker_thread+0x48/0x450 [ 26.283792] [<ffff000008100430>] kthread+0x138/0x140 [ 26.283796] [<ffff000008083710>] ret_from_fork+0x10/0x40 This looks like it has been introduced by 'commit 02efac0f ("drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld()")'. Fix the warning by dropping the use of local audio_mutex and switch to taking the modeset connection_mutex in tda998x_audio_get_eld() for avoidance of race conditions with drm_helper_probe_single_connector_modes() updating the ELD data. v2: Change to taking the modeset connection_mutex rather than changing the time when audio_mutex lock was taken, as suggested by Russell King. v3: Drop the bespoke drm_modeset_acquire_ctx, it is not needed. (suggested by Daniel Vetter) Signed-off-by: -
Liviu Dudau authored
The IPMMU driver still uses initcalls to do its initialisation, while other IOMMU drivers have moved to probe deferal mechanism. Update the IPMMU driver so that it can use modern driver probing which allows for it to be compiled together with other IOMMU drivers and not trying at boot time to replace bus masters for platforms that don't use IPMMU. Signed-off-by: -
Stephen Rothwell authored
Signed-off-by:Stephen Rothwell <sfr@canb.auug.org.au>
-
Stephen Rothwell authored
-
Pavel Tatashin authored
Early in boot Linux patches memset and memcpy to branch to platform optimized versions of these routines. The NG4 (Niagra 4) versions are currently used on all platforms starting from T4. Recently, there were M7 optimized routines added into UEK4 but not into mainline yet. So, even with M7 optimized routines NG4 are still going to be used on T4, T5, M5, and M6 processors. While investigating how to improve initialization time of dentry_hashtable which is 8G long on M6 ldom with 7T of main memory, I noticed that memset() does not reset all the memory in this array, after studying the code, I realized that NG4memset() branches use %icc register instead of %xcc to check compare, so if value of length is over 32-bit long, which is true for 8G array, these routines fail to work properly. The fix is to replace all %icc with %xcc in these routines. (Alternative is to use %ncc, but this is misleading, as the code already has sparcv9 only instructions, and cannot be compiled on 32-bit). This is important to fix this bug, because even older T4-4 can have 2T of memory, and there are large memory proportional data structures in kernel which can be larger than 4G in size. The failing of memset() is silent and corruption is hard to detect. Link: http://lkml.kernel.org/r/1488432825-92126-2-git-send-email-pasha.tatashin@oracle.com Signed-off-by:
Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by:
Babu Moger <babu.moger@oracle.com> Cc: Babu Moger <babu.moger@amd.com> Cc: David Miller <davem@davemloft.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andi Kleen authored
The single caller passes a string to delta_ipc_open, which copies with a fixed size larger than the string. So it copies some random data after the original string the ro segment. If the string was at the end of a page it may fault. Just copy the string with a normal strcpy after clearing the field. Found by a LTO build (which errors out) because the compiler inlines the functions and can resolve the string sizes and triggers the compile time checks in memcpy. In function `memcpy', inlined from `delta_ipc_open.constprop' at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0, inlined from `delta_mjpeg_ipc_open' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0, inlined from `delta_mjpeg_decode' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0: /home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to `__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2(); Link: http://lkml.kernel.org/r/20171222001212.1850-1-andi@firstfloor.org Signed-off-by:Andi Kleen <ak@linux.intel.com> Cc: Hugues FRUCHET <hugues.fruchet@st.com> Signed-off-by:
-
Dan Carpenter authored
We should propogate the error code here but we accidentally return success. Link: http://lkml.kernel.org/r/20180109092919.ndrvscdllrmzz6jo@mwanda Fixes: 946086abeddf ("mqueue: switch to on-demand creation of internal mount") Signed-off-by:
-
Stephen Rothwell authored
-
Stephen Rothwell authored
-
