compilation on x86 though, which is
good enough for me.
Acked-by: Maarten Lankhorst
> Signed-off-by: Chris Metcalf
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
> drivers/gpu/drm/radeon/radeon_ttm.c |1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/dr
Op 04-02-13 08:06, Inki Dae schreef:
>> +/**
>> + * ticket_commit - commit a reservation with a new fence
>> + * @ticket:[in]the reservation_ticket returned by
>> + * ticket_reserve
>> + * @entries: [in]a linked list of struct reservation_entry
>> + * @fence: [in]the fence tha
iltin would still allow ACPI_VIDEO to be used as external
module if some of the deps for acpi_video
have not been met, which would result in a linking failure. Solve this by only
requiring ACPI && X86 to select ACPI_VIDEO.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/
p to put DRM
> client lock in a separate class.
Can you copy paste a typical lockdep splat for this? Also this should be a
separate patch. :-)
> Reported-by: Arend van Spriel
> Reported-by: Peter Hurley
> Reported-by: Maarten Lankhorst
> Reported-by: Daniel J Blueman
> Signe
Op 05-02-13 15:52, Borislav Petkov schreef:
> On Mon, Feb 04, 2013 at 04:41:22PM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 04-02-13 16:23, Borislav Petkov schreef:
>>> Hi,
>>>
>>> I'm guessing someone has already triggered this on latest
id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex_lock_retval_arg, add warnings when using wrong
combination of
mutex_(,reserve_)lock/unlock
was previously used.
Signed-off-by: Maarten Lankhorst
---
arch/ia64/include/asm/mutex.h| 10 --
arch/powerpc/include/asm/mutex.h | 10 --
arch/sh/include/asm/mutex-llsc.h |4 ++--
arch/x86/include/asm/mutex_32.h | 11 ---
arch/x86/include/asm/mutex_64.h
will be cleaned up later when the api for reservations is
accepted. I don't expect the tests to change, since the discussion
is mostly about the fence aspect of reservations.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 522 ++--
1
Hey,
Op 05-02-13 21:52, Ben Skeggs schreef:
> On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
>> Op 04-02-13 22:30, Marcin Slusarz schreef:
>>> 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
>>> locked in arbitrary order,
Hey,
Thanks for reviewing.
Op 02-04-13 13:00, Peter Zijlstra schreef:
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +Reservation type mutexes
>> +struct ticket_mutex {
>> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> That&#
the rom images, and thus not
being able to use the radeon card any more.
The solution is to just remove the check for now, and always copy the rom if
available.
Signed-off-by: Maarten Lankhorst
---
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 18e329c.
Op 30-01-13 02:07, Rob Clark schreef:
> On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst
> wrote:
> Hi Maarten,
>
> This is a nice looking extension to avoid re-implementing a mutex in
> TTM/reservation code.. ofc, probably someone more familiar with mutex
> code should
Op 31-01-13 10:32, Inki Dae schreef:
> Hi,
>
> below is my opinion.
>
>> +struct fence;
>> +struct fence_ops;
>> +struct fence_cb;
>> +
>> +/**
>> + * struct fence - software synchronization primitive
>> + * @refcount: refcount for this fence
>> + * @ops: fence_ops associated with this fence
>> + *
for -next.
> Okay I've just sent out another fbcon patch to fix the locking harder.
>
> There was a path going into set_con2fb_path if an fb driver was
> already registered, I just pushed the locking out further on anyone
> going in there.
>
> it boots on my EFI macbook here.
was previously used.
Signed-off-by: Maarten Lankhorst
---
arch/ia64/include/asm/mutex.h| 10 --
arch/powerpc/include/asm/mutex.h | 10 --
arch/sh/include/asm/mutex-llsc.h |4 ++--
arch/x86/include/asm/mutex_32.h | 11 ---
arch/x86/include/asm/mutex_64.h
normal locks, because __builtin_constant_p might evaluate to
false
for the constant 0 in that case. Tests for this have been added in the next
patch.
- Updated documentation slightly.
Signed-off-by: Maarten Lankhorst
---
Documentation/reservation-mutex-design.txt | 136
include
ff-by: Maarten Lankhorst
---
lib/locking-selftest.c | 588 ++--
1 file changed, 569 insertions(+), 19 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index c3eb261..2c52c0e 100644
--- a/lib/locking-selftest.c
+++ b/lib/lo
Hey,
2013/2/18 Fengguang Wu :
> Greetings,
>
> I got the below warning and the first bad commit is
>
> commit 11eb5a2ce9655ee552f705f2da6b8f96f466c0d4
> Author: Maarten Lankhorst
> Date: Wed Nov 7 11:53:51 2012 +0100
>
> mutex: add support for reservation s
Hey Al,
Your vfs commit ee3efa91e240f513898050ef305a49a653c8ed90 caused my laptop
with a nfs root filesystem to stop working.
My testcase is simply booting through netboot with / and ~/nfs as separate
nfs filesystems, then doing 'ls ~/nfs' followed by 'ls ~' in a gnome-terminal
window, then I get
It is considered good form to lock the lock you claim to be nested in.
Signed-off-by: Maarten Lankhorst
---
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index ea9ee45..7175447 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2998,6 +2998,43 @@ EXPORT_SYMBOL_GPL(lockdep_init_map
Hey,
Op 13-09-12 11:59, Peter Zijlstra schreef:
> On Thu, 2012-09-13 at 11:39 +0200, Maarten Lankhorst wrote:
>> It is considered good form to lock the lock you claim to be nested in.
> Uhm yeah.. cute. You actually found a site where this triggered?
>
Not in mainline, I was
Hey,
Op 03-10-12 09:45, Thomas Hellstrom schreef:
> On 10/02/2012 10:03 AM, Daniel Vetter wrote:
>> On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote:
>>> On 10/01/2012 11:47 AM, Maarten Lankhorst wrote:
>>>> I was doing a evil hack where I 'r
Op 03-10-12 12:53, Thomas Hellstrom schreef:
> On 10/03/2012 10:53 AM, Daniel Vetter wrote:
>> On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom
>> wrote:
> So if I understand you correctly, the reservation changes in TTM are
> motivated by the
> fact that otherwise, in the generic re
Cc: sta...@kernel.org # 3.4 - 3.6
> Cc: Matthew Garrett
> Cc: Maarten Lankhorst
> ---
>
> v2: rebase due to context diffs, and simplified efi_is_native() logic.
>
> arch/x86/kernel/setup.c | 11 +++
> arch/x86/platform/efi/efi.c | 16 +---
>
Op 24-10-12 17:21, Olof Johansson schreef:
> Hi,
>
> On Wed, Oct 24, 2012 at 1:40 AM, Maarten Lankhorst
> wrote:
>> Op 24-10-12 08:24, Olof Johansson schreef:
>>> When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
>>> efi_enabled once setup i
Hey,
Op 05-11-12 02:59, Luming Yu schreef:
> This patch is the first step to test some basic hardware functions like
> TSC to help people understand if there is any hardware latency as well
> as throughput problem exposed on bare metal or left behind by BIOS or
> interfered by SMI. Currently the p
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlo
support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve()
+ dma_buf_unreserve
in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
---
drive
nv*_display_create would be a more logical place to put the disable
call. This will make it more clear that vblank is disabled before the irq is
registered.
Also maybe add a WARN_ON(!nv_engine(dev, NVOBJ_ENGINE_SW)); in
nouveau_vblank_enable and/or return -EINVAL in that case?
If you add the modificati
This reverts commit ee3efa91e240f513898050ef305a49a653c8ed90.
Signed-off-by: Maarten Lankhorst
My thread about the regression seemed to have been ignored, so I can only
conclude nobody objects against a full revert of this patch.
My testcase is simply booting through netboot with / and ~/nfs
Hey,
Op 25-09-12 05:39, Eric W. Biederman schreef:
> Maarten Lankhorst writes:
>
>> This reverts commit ee3efa91e240f513898050ef305a49a653c8ed90.
>>
>> Signed-off-by: Maarten Lankhorst
>>
>> My thread about the regression seemed to have been ignored, so I
Hey,
Op 25-09-12 09:05, Eric W. Biederman schreef:
> Maarten Lankhorst wrote:
>
>> Hey,
>>
>> Op 25-09-12 05:39, Eric W. Biederman schreef:
>>> Maarten Lankhorst writes:
>>>
>>>> This reverts commit ee3efa91e240f513898050ef305a49
Op 25-09-12 12:42, Eric W. Biederman schreef:
> Maarten Lankhorst writes:
>
>> Hey,
>>
>> Op 25-09-12 09:05, Eric W. Biederman schreef:
>>> Maarten Lankhorst wrote:
>>>
>>>> Hey,
>>>>
>>>> Op 25-09-12 05:39, Eric W.
Op 25-09-12 13:29, Eric W. Biederman schreef:
> Maarten Lankhorst writes:
>
>>> Could you try the following patch? This should report what directories
>>> cannot be renamed because one of them is a mount point and it gives some
>>> real insight into what is going
Hey,
It seems that in the merge window my macbook pro stopped working at some point.
I looked for suspicious
efi related commits, and found that reverting commit
1acba98f810a14b1255e34bc620594f83de37e36 worked,
letting my macbook pro boot succesfully.
Is there anything I can do to help diagnose
Move spin_lock_init to be called before the spinlocks are used, preventing a
lockdep splat.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/net/ethernet/atheros/alx/main.c
b/drivers/net/ethernet/atheros/alx/main.c
index 418de8b..d30085c 100644
--- a/drivers/net/ethernet/atheros/alx
Op 08-09-13 09:24, Tetsuo Handa schreef:
> Hello.
>
> Ilia Mirkin wrote:
>>> Commit 040a0a37 "mutex: Add support for wound/wait style locks" used
>>> "!__builtin_constant_p(p == NULL)" which I guess the author meant that
>>> "__builtin_constant_p(p) && p", but gcc 3.x cannot handle such expression
Op 08-09-13 13:53, Tetsuo Handa schreef:
> Hello.
>
> Maarten Lankhorst wrote:
>> if it's broken for your compiler, please add a bool use_ww_ctx or something
>> to __mutex_lock_common that's set directly instead, the __builtin_constant_p
>> trick
>> mi
Op 09-09-13 13:56, Tetsuo Handa schreef:
> Maarten Lankhorst wrote:
>> Almost correct. I meant passing it as parameter to __mutex_lock_common. Your
>> version will still cause an extra pointless null check in the ww_mutex_lock
>> case.
> Ah, I s
Op 12-09-13 17:06, Peter Zijlstra schreef:
> Hi Dave,
>
> So I'm poking around the preemption code and stumbled upon:
>
> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm
Op 12-09-13 17:36, Daniel Vetter schreef:
> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
>> So I'm poking around the preemption code and stumbled upon:
>>
>> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
>> drivers/gpu/drm/ttm/ttm_bo_vm.c:set
Op 12-09-13 18:44, Thomas Hellstrom schreef:
> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 17:36, Daniel Vetter schreef:
>>> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra
>>> wrote:
>>>> So I'm poking around the preemption code
Op 13-09-13 08:44, Thomas Hellstrom schreef:
> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 18:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
>>>> Op 12-09-13 17:36, Daniel Vetter schreef:
>>>>> On
Op 13-09-13 09:46, Thomas Hellstrom schreef:
> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 08:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
>>>> Op 12-09-13 18:44, Thomas Hellstrom schreef:
>>>>&
Op 13-09-13 10:23, Thomas Hellstrom schreef:
> On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 09:46, Thomas Hellstrom schreef:
>>> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
>>>> Op 13-09-13 08:44, Thomas Hellstrom schreef:
>>>>&
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon
op 08-10-13 16:33, Jerome Glisse schreef:
> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>> Allocate and copy all kernel memory before doing reservations. This prevents
>> a locking
>> inversion between mmap_sem and reservation_class, and allows us to dr
e Glisse:
>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>>>>>> Allocate and copy all kernel memory before doing reservations. This
>>>>>> prevents a locking
>>>>>> inversion between mmap_sem and reservat
hristian König wrote:
>>>>> Am 08.10.2013 16:33, schrieb Jerome Glisse:
>>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>>>>>>> Allocate and copy all kernel memory before doing reservations. This
>>>>>&g
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>> On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
>> wrote:
>>> On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
>> if (!bo_tryreserve()) {
>> up_read m
Op 24-09-13 09:22, Thomas Hellstrom schreef:
> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 13-09-13 11:00, Peter Zijlstra schreef:
>>> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>>>> On Fri, Sep 13, 2013 at 10:29
Op 24-09-13 11:03, Thomas Hellstrom schreef:
> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
>>> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
>>>> Hey,
>>>>
>>>> Op 13-09-13 11:00, Peter
Op 24-09-13 11:36, Daniel Vetter schreef:
> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
>> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
>>>> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
&
Op 24-09-13 12:33, Thomas Hellstrom schreef:
> On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
>> Op 24-09-13 11:36, Daniel Vetter schreef:
>>> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
>>>> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
&
Op 28-09-12 14:42, Maarten Lankhorst schreef:
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of gr
Hey,
Op 29-11-12 21:06, Al Viro schreef:
> On Tue, Sep 25, 2012 at 04:29:58AM -0700, Eric W. Biederman wrote:
>> Maarten Lankhorst writes:
>>
>>>> Could you try the following patch? This should report what directories
>>>> cannot be renamed because one of
Op 04-12-12 11:33, Maarten Lankhorst schreef:
> Hey,
>
> Op 29-11-12 21:06, Al Viro schreef:
>> On Tue, Sep 25, 2012 at 04:29:58AM -0700, Eric W. Biederman wrote:
>>> Maarten Lankhorst writes:
>>>
>>>>> Could you try the following patch? Thi
itself without realtime.
Cc: Stable [v2.6.32+]
Signed-off-by: Maarten Lankhorst
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..4c0712a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3757,6 +3757,12 @@ recheck:
if (param->sched_prior
Op 17-10-12 23:18, Maarten Lankhorst schreef:
> When implementing SIGXCPU handling for a thread boosted with rtkit to realtime
> priority, I noticed that sched_setscheduler(somepid, SCHED_OTHER) would return
> -EPERM because the thread was previously SCHED_RR | SCHED_RESET_ON_FORK,
>
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
Reviewed-by: Rob
Op 08-11-12 21:23, Sasha Levin schreef:
> Just use BUG_ON() instead of constructions such as:
>
> if (...)
> BUG()
>
> A simplified version of the semantic patch that makes this transformation
> is as follows: (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression e;
> @@
> - if
r existing __mutex_fastpath_lock_retval implementation.
I'm guessing this has to be split up, but I figured most of the flames would be
about patch 2 anyhow..
Signed-off-by: Maarten Lankhorst
---
diff --git a/arch/ia64/include/asm/mutex.h b/arch/ia64/include/asm/mutex.h
index bed73a6..2510058 100644
--- a/arch/i
mutex_reserve_lock, and mutex_reserve_lock_interruptible:
Lock a buffer with a reservation_id set. reservation_id must not be set to 0,
since this is a special value that means no reservation_id.
Normally if reservation_id is not set, or is older than the reservation_id
that's
currently s
I ran out of free entries when I had CONFIG_DMA_API_DEBUG enabled.
Some other archs seem to default to 65536, so increase this limit for x86 too.
Signed-off-by: Maarten Lankhorst
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index de2b7ad..f5597c5 100644
--- a/arch/x86
m always calling wake_up_all, which does a
unconditional spin_lock_irqsave/irqrestore.
I needed this in kernel/mutex.c because of the extensions to __lock_common,
which are
hopefully optimized away for all normal paths.
Signed-off-by: Maarten Lankhorst
---
diff --git a/include/linux/mu
Op 31-05-13 10:54, Seung-Woo Kim schreef:
> dma-buf attachment has only exporter private data, but importer private data
> can be useful for importer especially to re-import the same dma-buf.
> To use importer private data in attachment of the device, the function to
> search attachment in the atta
Hey,
Op 06-06-13 03:35, Fengguang Wu schreef:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 3d71c6ed43d838e593538176a9a59debe228cfb0
> Author: Maarten Lankhorst
> Date: Tue Apr 2 12:33:01 2013 +0200
>
> drm/ttm: con
Vetter (1):
mutex: w/w mutex slowpath debugging
Maarten Lankhorst (6):
arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded
or not.
mutex: add support for wound/wait style locks, v5
mutex: Add ww tests to lib/locking-selftest.c. v5
mutex: add more
was previously used.
Changes since v1, pointed out by Francesco Lavra:
- fix a small comment issue in mutex_32.h
- fix the __mutex_fastpath_lock_retval macro for mutex-null.h
Signed-off-by: Maarten Lankhorst
---
arch/ia64/include/asm/mutex.h| 10 --
arch/powerpc/include/asm/mutex.h
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to
pass unexpectedly, but there no tests that should start to fail that
pass with CONFIG_PROVE_LOCKING enabled.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c |8 +---
1 file changed, 5 insertions(+), 3
*, normal
functions can be used. Inline versions still exist for extra
debugging.
- Cleanup unneeded memory barriers, add comment to the remaining
smp_mb().
Signed-off-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Signed-off-by: Rob Clark
---
Documentation/ww-mutex-design.txt | 343
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 264 +++-
1 file changed, 261 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 37faefd..d554f3f 100644
--- a/lib/locking-selftest.c
+++ b
.debug definition
to work correctly. (mlankhorst)
v6:
Do not inject -EDEADLK when ctx->acquired == 0, because
the _slow paths are merged now. (mlankhorst)
Cc: Steven Rostedt
Signed-off-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
include/linux/mutex.h |8
None of the ww_mutex codepaths should be taken in the 'normal'
mutex calls. The easiest way to verify this is by using the
normal mutex calls, and making sure o.ctx is unmodified.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftes
locking after ww_acquire_done has been called.
- Added a test for unbalance for ctx->acquired dropping below zero.
- Added a test for unlocked ww_mutex with ctx != NULL.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 400 ++--
1 f
Op 20-06-13 13:55, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserv
Op 29-05-13 12:33, Inki Dae schreef:
> Hi,
>
> Just minor comments
>
> +Usage
>> +-
>> +
>> +Three different ways to acquire locks within the same w/w class. Common
>> +definitions for methods #1 and #2:
>> +
>> +static DEFINE_WW_CLASS(ww_class);
>> +
>> +struct obj {
>> + struct ww_mutex
Op 20-06-13 14:23, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Well they've helped me with some of the changes and contributed some
>> code and/or fixes, but if acked-by is preferred I'll use that..
> Such contributions can be credited in the changel
Op 07-06-13 04:32, 김승우 schreef:
> Hello Maarten,
>
> On 2013년 06월 05일 22:23, Maarten Lankhorst wrote:
>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
>>> dma-buf attachment has only exporter private data, but importer private data
>>> can be useful for importer esp
Hey,
Op 06-06-13 09:28, Fengguang Wu schreef:
> Hi Maarten,
>
> Thanks for the patch! I'll queue it for the tests.
>
>
I haven't heard back from you yet, did it fix all lockdep issues you were
having?
If so I'll get it queued.
~Maarten
--
To unsubscribe from this list: send the line "unsubscrib
Op 10-06-13 03:55, Fengguang Wu schreef:
> Maarten,
>
> Sorry for the delay!
>
> On Sun, Jun 09, 2013 at 08:58:44AM +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 06-06-13 09:28, Fengguang Wu schreef:
>>> Hi Maarten,
>>>
>>> Than
Op 28-05-13 16:48, Maarten Lankhorst schreef:
> Version 4 already?
>
> Small api changes since v3:
> - Remove ww_mutex_unlock_single and ww_mutex_lock_single.
> - Rename ww_mutex_trylock_single to ww_mutex_trylock.
> - Remove separate implementations of ww_mutex_lock_slow*, no
Hey,
Op 03-07-13 02:54, Linus Torvalds schreef:
> On Mon, Jul 1, 2013 at 1:22 AM, Ingo Molnar wrote:
>> Please pull the latest core-mutexes-for-linus git tree from:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>> core-mutexes-for-linus
>>
>>HEAD: 166989e366ffa66108b2f37
Op 05-07-13 08:23, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Hey,
>>
>> Op 03-07-13 02:54, Linus Torvalds schreef:
>>> On Mon, Jul 1, 2013 at 1:22 AM, Ingo Molnar wrote:
>>>> Please pull the latest core-mutexes-for-linus git tree from:
&g
I didn't even know I still had lockdep on.
The following lockdep splat happened when I plugged in a usb bluetooth dongle,
using
the pre-rc1 3.11 kernel at HEAD b2c311075db
=
[ INFO: inconsistent lock state ]
3.10.0+ #106 Not tainted
---
Op 28-06-13 03:32, Davidlohr Bueso schreef:
> On Thu, 2013-06-27 at 11:00 +0200, Ingo Molnar wrote:
> [...]
>> So I tried this out yesterday, but it interacted with the Wait/Wound
>> patches in tip:core/mutexes.
>>
>> Maarten Lankhorst pointed out that if this
s, for small amounts of users (10-100), were the short and
> compute workloads had a +19.36% and +%15.76% in jobs per minute.
>
> Also change some break statements to 'goto slowpath', which IMO makes a
> little more intuitive to read.
Nice turquoise bikeshed you built there. ;-)
Ack
P value.
RIP [<0001>] 0x0
RSP
CR2: 0001
---[ end trace 907323cb8ce6f301 ]---
Signed-off-by: Maarten Lankhorst
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index d109936..c95decf 100644
--- a/drivers/gpu/drm/nouveau/no
rlock_AA5 will pass unexpectedly, marking the test as FAILED and breaking
lockdep for everyone.
The following test should make lockdep complain, but currently doesn't:
lock(a); readlock(x);
writelock(x); lock(a);
Signed-off-by: Maarten Lankhorst
---
diff --git a/lib/locking-selftest.c
Op 12-08-13 17:43, Rob Clark schreef:
> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
> wrote:
>> A fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For exa
n the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problem
n the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problem
Op 15-08-13 14:45, Marcin Ślusarz schreef:
> 2013/8/15 Maarten Lankhorst :
>> A fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For example, userspace can call page_flip
Op 15-08-13 15:14, Rob Clark schreef:
> On Thu, Aug 15, 2013 at 7:16 AM, Maarten Lankhorst
> wrote:
>> Op 12-08-13 17:43, Rob Clark schreef:
>>> On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
>>> wrote:
>>>> +
> [snip]
>>>> +/**
>&
nouveau was a bit tricky, it has no support for interrupts on
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..78714e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -35,88 +35
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9f19259..971284e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
Op 19-08-13 14:35, Christian König schreef:
> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>> [SNIP]
>> @@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
>> int ring)
>> }
>> } while (atomic64_xchg(&rdev-
n the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problem
1 - 100 of 528 matches
Mail list logo
