You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Maarten Lankhorst
1b6e5fd5f4
Op 10-07-13 12:03, Markus Trippelsdorf schreef: > On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote: >> Op 10-07-13 11:46, Markus Trippelsdorf schreef: >>> On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote: >>>> Op 10-07-13 11:22, Markus Trippelsdorf schreef: >>>>> By simply copy/pasting a big document under LibreOffice my system hangs >>>>> itself up. Only a hard reset gets it working again. >>>>> see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551 >>>>> >>>>> I've bisected the issue to: >>>>> >>>>> commitecff665f5e>>>>> Author: Maarten Lankhorst <m.b.lankhorst@gmail.com> >>>>> Date: Thu Jun 27 13:48:17 2013 +0200 >>>>> >>>>> drm/ttm: make ttm reservation calls behave like reservation calls >>>>> >>>>> This commit converts the source of the val_seq counter to >>>>> the ww_mutex api. The reservation objects are converted later, >>>>> because there is still a lockdep splat in nouveau that has to >>>>> resolved first. >>>>> >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> >>>>> Reviewed-by: Jerome Glisse <jglisse@redhat.com> >>>>> Signed-off-by: Dave Airlie <airlied@redhat.com> >>>> Hey, >>>> >>>> Can you try current head with CONFIG_PROVE_LOCKING set and post the >>>> lockdep splat from dmesg, if any? If there is any locking issue >>>> lockdep should warn about it. Lockdep will turn itself off after the >>>> first splat, so if the lockdep splat happens before running the >>>> affected parts those will have to be fixed first. >>> There was an unrelated EDAC lockdep splat, so I simply disabled it. >>> >>> This is what I get: >>> >>> Jul 10 11:40:44 x4 kernel: ================================================ >>> Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ] >>> Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted >>> Jul 10 11:40:44 x4 kernel: ------------------------------------------------ >>> Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held! >>> Jul 10 11:40:44 x4 kernel: 2 locks held by X/211: >>> Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0 >>> Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0 >>> Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync >>> Jul 10 11:40:53 x4 kernel: Emergency Sync complete >>> >> Thanks, exactly what I thought. I missed a backoff somewhere.. >> >> Does the below patch fix it? > Yes. Thank you for your quick reply. 8<------ If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get called. This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were not unlocked afterwards: Jul 10 11:40:44 x4 kernel: ================================================ Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ] Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted Jul 10 11:40:44 x4 kernel: ------------------------------------------------ Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held! Jul 10 11:40:44 x4 kernel: 2 locks held by X/211: Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0 Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0 Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync Jul 10 11:40:53 x4 kernel: Emergency Sync complete This is a regression caused by commitecff665f5e. "drm/ttm: make ttm reservation calls behave like reservation calls" Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
************************************************************
* For the very latest on DRI development, please see: *
* http://dri.freedesktop.org/ *
************************************************************
The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).
The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:
1. The DRM provides synchronized access to the graphics hardware via
the use of an optimized two-tiered lock.
2. The DRM enforces the DRI security policy for access to the graphics
hardware by only allowing authenticated X11 clients access to
restricted regions of memory.
3. The DRM provides a generic DMA engine, complete with multiple
queues and the ability to detect the need for an OpenGL context
switch.
4. The DRM is extensible via the use of small device-specific modules
that rely extensively on the API exported by the DRM module.
Documentation on the DRI is available from:
http://dri.freedesktop.org/wiki/Documentation
http://sourceforge.net/project/showfiles.php?group_id=387
http://dri.sourceforge.net/doc/
For specific information about kernel-level support, see:
The Direct Rendering Manager, Kernel Support for the Direct Rendering
Infrastructure
http://dri.sourceforge.net/doc/drm_low_level.html
Hardware Locking for the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
A Security Analysis of the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/security_low_level.html