gt;> -> somehow a grace period
> >> -> sem_rcu_free()
> >> -> security_sem_free()
> >>
> >> Perhaps: modify ipc_free_security() to hexdump perm and a few more bytes if
> >> the pointer is NULL?
> >
> > I
On Fri, 2015-01-23 at 10:19 +0800, ethan zhao wrote:
> > If not, what kernel
> > version were you running when you triggered the bug?
> To be honest, a kernel from distro, but not released, but before we
> get it clear, we wouldn't public more.
Sheesh, could Oracle be any more (ridiculously)
Call __set_task_state() instead of assigning the new state
directly. These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP
environments, keeping track of who last changed the state.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/rwsem-spinlock.c | 2 +-
kernel/locking/rwsem-xadd.c | 3
and rwsem_try_write_lock_unqueued
(when the lock is obtained while spinning). This requires creating
a new internal rwsem.h header to share the owner related calls.
Also cleanup some headers for mutex and rwsem.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 2 +-
kernel/lock
e lock, instead of blocking.
This patch therefore replaces this bogus check to solely rely on
the counter to know if the lock is available. Because we don't
hold the wait lock, we can obviously do this in an unqueued
manner.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/rwsem-xadd.c | 8
and makes no tangible difference.
This patch increases Unixbench's 'execl' throughput by 25% on a 40
core machine.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/rwsem-xadd.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/kernel/l
.60
Signed-off-by: Davidlohr Bueso
---
kernel/locking/rwsem-xadd.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 88b3468..e0e9738 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b
blocking. While I believe
this is safe, it certainly needs more eyeballs, I could have easily overlooked
something. Most of these changes are straighforward, but have various
implications.
Passes multiple x86-64 tests.
Thanks!
[1] https://lkml.org/lkml/2015/1/7/884
Davidlohr Bueso (6):
locking
The need for the smp_mb in __rwsem_do_wake should be
properly documented. Applies to both xadd and spinlock
variants.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/rwsem-spinlock.c | 5 +
kernel/locking/rwsem-xadd.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/kernel
Oops, cc'ing lkml.
On Mon, 2015-01-26 at 02:10 -0800, Davidlohr Bueso wrote:
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
> keeping track of who changed the state.
>
> Signed-off
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
keeping track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
drivers/block/swim.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments,
keeping track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
drivers/staging/comedi/drivers/me_daq.c | 2 +-
drivers/staging/dgnc
;
> Signed-off-by: Christian Borntraeger
Acked-by: Davidlohr Bueso
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Ingo,
> x86 defconfig produces:
>
> kernel/locking/mcs_spinlock.h:81:2: error: implicit declaration of function
> ‘ASSIGN_ONCE’ [-Werror=implicit-function-declaration]
>
> Also, this patch should really be split into three separate (and
> tested) patches.
These patches were tested, the f
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
Cc: Oleg Nesterov
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2
A quick search shows that there are no users, drop the
macro for both jbd and jbd2.
Signed-off-by: Davidlohr Bueso
Cc: Jan Kara
---
My goal here was to just change how we set current state, however
I realized that the function is not used.
include/linux/jbd.h | 9 -
include/linux
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc
From: Davidlohr Bueso
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
sound/oss/msnd_pinnacle.c | 4 ++--
sound/oss
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
Completely untested.
arch/ia64/kernel/mca.c| 2 +-
arch/ia64/kernel/ptrace.c
On Thu, 2015-01-15 at 08:33 +0100, Takashi Iwai wrote:
> At Wed, 14 Jan 2015 23:11:43 -0800,
> Davidlohr Bueso wrote:
> >
> > From: Davidlohr Bueso
> >
> > Call __set_current_state() instead of assigning the new state directly.
> > These interface
On Thu, 2015-01-15 at 09:11 +0100, Takashi Iwai wrote:
> Well, it's a bit unusual. Why do they need to differ? Is the author
> another Davidlohr? :) If this form is preferred, I'm willing to
> apply, but I just wonder...
Personal taste, really. Yes I'd prefer you apply as is.
Thanks,
Davidlohr
On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
Cc'ing Peter.
> FYI, we noticed the below changes on
>
> commit c8c06efa8b552608493b7066c234cfa82c47fcea ("mm: convert i_mmap_mutex to
> rwsem")
Same exact everything, except for the lock type. No sharing going on.
> testbox/testcase/testpar
On Wed, 2015-01-07 at 23:45 -0800, Davidlohr Bueso wrote:
> On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
> Cc'ing Peter.
Err, resending with the complete msg.
> > FYI, we noticed the below changes on
> >
> > commit c8c06efa8b552608493b7066c234cfa82c47fc
On Wed, 2015-01-07 at 23:50 -0800, Davidlohr Bueso wrote:
> On Wed, 2015-01-07 at 23:45 -0800, Davidlohr Bueso wrote:
> > On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
> > Cc'ing Peter.
>
> Err, resending with the complete msg.
>
> > >
On Thu, 2015-01-08 at 10:27 +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> commit c8c06efa8b552608493b7066c234cfa82c47fcea ("mm: convert i_mmap_mutex to
> rwsem")
>
>
> testbox/testcase/testparams: lituya/unixbench/performance-execl
>
> 83cde9e8ba95d180 c8c06efa8b55260849
On Fri, 2015-01-09 at 11:03 +0800, Huang Ying wrote:
> Is it possible for you to try the reproduce steps in the original
> reporting email sent by me? If you have any question on that steps,
> feel free to ask.
Yes I've already done that, nothing. My question remains, can you
reproduce this yours
On Thu, 2015-01-08 at 07:22 -0800, Paul E. McKenney wrote:
> > Didn't we just obsolete ACCESS_ONCE with that {READ,WRITE}_ONCE stuff?
>
> Indeed we did! But that was after I did this commit back on October 29th.
>
> I am planning a bulk change to READ_ONCE() and ASSIGN_ONCE() either as
> the las
On Fri, 2015-01-09 at 22:58 +0100, Christian Borntraeger wrote:
> When we talk about changing the parameters it might make sense to also think
> about some comments from George Spelvin and consider a rename to WRITE_ONCE
> or STORE_ONCE (READ_ONCE --> LOAD_ONCE). Unfortunately there doesnt seem t
On Fri, 2015-01-09 at 20:19 +0530, Vaibhav Shinde wrote:
> My app runs on cpu0, while other cpus looks idle; as per my
> understanding from your comment owner of the mutex is on the cpu other
> than cpu0, and which is causing wait spin on cpu0.
The thing is, cpu0 is rescheduling too often, so you'
I was finally able to reproduce this (had to hack the damn Run script).
I'll look into it more carefully now, thanks for reporting it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
> > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> >
> >> Hello Thomas,
> >>
> >> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
> >>> On Thu, 15 Jan 2015, Michael Kerr
On Fri, 2015-01-16 at 16:02 -0800, Andrew Morton wrote:
> On Fri, 16 Jan 2015 12:56:36 +0530 "Aneesh Kumar K.V"
> wrote:
>
> > This make sure that we try to allocate hugepages from local node if
> > allowed by mempolicy. If we can't, we fallback to small page allocation
> > based on mempolicy. T
On Wed, 2015-01-14 at 23:50 -0800, Davidlohr Bueso wrote:
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
> track of who changed the state.
ping?
--
To unsubscribe from this list: send
By the time we wake up and get the lock after being asleep
in the slowpath, we better be running. As good practice,
be explicit about this and avoid any mischief.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/locking
On Tue, 2015-01-27 at 18:10 +0100, Peter Zijlstra wrote:
> This is the thing I suggested
> lkml.kernel.org/r/20150108103708.ge29...@twins.programming.kicks-ass.net
> there right?
Yeah.
> Do you have numbers for how much this gained?
This is more of a correctness patch, nothing really tangible fo
On Tue, 2015-01-27 at 18:07 +0100, Peter Zijlstra wrote:
> On Sun, Jan 25, 2015 at 11:36:05PM -0800, Davidlohr Bueso wrote:
> > The need for the smp_mb in __rwsem_do_wake should be
> > properly documented. Applies to both xadd and spinlock
> > variants.
> >
> &g
On Tue, 2015-01-27 at 15:45 +0800, Huang Ying wrote:
> Hi, Davidlohr,
>
> Any update on this? The latest news I gotten is that you finally
> reproduced this.
The overall differences and cause of the issue is commit 37e9562453b
(locking/rwsem: Allow conservative optimistic spinning when readers h
On Tue, 2015-01-27 at 18:34 +0100, Peter Zijlstra wrote:
> On Sun, Jan 25, 2015 at 11:36:08PM -0800, Davidlohr Bueso wrote:
> > When blocking , we incur in multiple barriers when setting the
> > task's uninterruptable state. This is particularly bad when the
> > lock kee
On Tue, 2015-01-27 at 09:23 -0800, Jason Low wrote:
> On Sun, 2015-01-25 at 23:36 -0800, Davidlohr Bueso wrote:
> > When readers hold the semaphore, the ->owner is nil. As such,
> > and unlike mutexes, '!owner' does not necessarily imply that
> > the lock is fre
On Wed, 2015-01-28 at 13:03 -0800, Jason Low wrote:
> On Tue, 2015-01-27 at 19:54 -0800, Davidlohr Bueso wrote:
> > On Tue, 2015-01-27 at 09:23 -0800, Jason Low wrote:
> > > On Sun, 2015-01-25 at 23:36 -0800, Davidlohr Bueso wrote:
> > > > When readers hold the sem
On Fri, 2015-04-17 at 11:06 -0400, Mathieu Desnoyers wrote:
> [ Not in this patch: tests (Pranith Kumar has a patch for this), man page. ]
Actually, we had discussed that for new syscalls, the changelog _would_
be the manpage -- at least included in it.
Thanks,
Davidlohr
--
To unsubscribe from t
ction regardless of the status of
the scan_q.
Compile tested only.
Signed-off-by: Davidlohr Bueso
Cc: Jens Axboe
Cc: Mike Miller
Cc: Don Brace
---
drivers/block/cciss.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
On Thu, 2015-04-23 at 10:51 -0600, Jens Axboe wrote:
> Not that it's wrong, but this is mostly some unneeded optimizations.
> It's not like this is in a hot path.
Most definitely small optimizations, I just happened to run into
auditing schedule calls. Still no harm in applying.
Thanks,
Davidloh
It would be nice to not run into this by accident. Please CC all
relevant parties ;)
On Thu, 2015-04-23 at 14:24 -0400, Waiman Long wrote:
> In up_read()/up_write(), rwsem_wake() will be called whenever it
> detects that some writers/readers are waiting. The rwsem_wake()
> function will take the w
On Tue, 2015-04-14 at 16:09 -0700, Jason Low wrote:
> While running a database workload, we found a scalability issue with itimers.
>
> Much of the problem was caused by the thread_group_cputimer spinlock.
> Each time we account for group system/user time, we need to obtain a
> thread_group_cputim
On Sun, 2015-04-12 at 20:02 -0700, Davidlohr Bueso wrote:
> Doing the wakeups while holding the lock is also a general performance
> issue for futex_wake. The problem being dealing with spurious wakeups
> (wacky drivers), which makes no difference wrt nr_wake.
So I did some measurements
On Thu, 2015-04-16 at 12:16 +0200, Peter Zijlstra wrote:
> But if we decide we want to go do this, I'd propose we reintroduce this
> delayed wake list thing again.
Given that futexes aren't the only potential users, I definitely agree.
Lemme cleanup the patches and I'll resend. Now, one thing I wo
On Thu, 2015-04-16 at 17:54 +0200, Peter Zijlstra wrote:
> On Thu, Apr 16, 2015 at 07:42:55AM -0700, Davidlohr Bueso wrote:
> > On Thu, 2015-04-16 at 12:16 +0200, Peter Zijlstra wrote:
> > > But if we decide we want to go do this, I'd propose we reintroduce this
> > &g
On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>The condition is represented by the futex word, which is an address in
>memory supplied to the futex() system call, and the value at this mem‐
>ory location. (While the virtual addresses for the same memory in sep
On Sat, 2015-03-28 at 13:03 +0100, Peter Zijlstra wrote:
> > If the timeout argument is non-NULL, its contents specify a
> > rel‐
> > ative timeout for the wait, measured according to
> > the
> > CLOCK_MONOTONIC clock. (This interval will be r
f the crappy FUTEX_CMP_REQUEUE man
page, incorrectly mentioning that the number of requeued tasks is
in fact returned, not the wakeups. This patch acknowledges this
and updates the corresponding futex_wake code around it.
Signed-off-by: Davidlohr Bueso
---
tools/perf/bench/futex-requeue.c
On Fri, 2015-04-24 at 11:50 -0600, David Ahern wrote:
> On 4/24/15 11:00 AM, Davidlohr Bueso wrote:
> > This bug, while perhaps suggesting missing wakeups in kernel futex
> > code, is merely a consequence of the crappy FUTEX_CMP_REQUEUE man
> > page, incorrectly mentioni
On Fri, 2015-04-24 at 13:54 -0400, Waiman Long wrote:
> This patch also checks one more time in __rwsem_do_wake() to see if
> the rwsem was stolen just before doing the expensive wakeup operation
> which will be unnecessary if the lock was stolen.
It strikes me that this should be another patch, a
of the implied barrier. Secondly, and related
to the lockless wakeups, comment the smp_wmb and add barrier pairing on
the reader side.
Based-on-work-from: Sebastian Andrzej Siewior
Signed-off-by: Davidlohr Bueso
---
ipc/mqueue.c | 52 +---
1 file
On Tue, 2015-04-28 at 14:37 +0200, Peter Zijlstra wrote:
> On Mon, Apr 27, 2015 at 08:24:53PM -0700, Davidlohr Bueso wrote:
> > +static inline void pipelined_send(struct wake_q_head *wake_q,
> > + struct mqueue_inode_info *info,
> >
On Tue, 2015-04-28 at 18:43 +0200, Peter Zijlstra wrote:
> Well, if you can 'guarantee' the cmpxchg will not fail, you can then
> rely on the fact that cmpxchg implies a full barrier, which would
> obviate the need for the wmb.
Yes, assuming it implies barriers on both sides. And we could obviousl
On Tue, 2015-04-28 at 10:50 -0700, Jason Low wrote:
> On Tue, 2015-04-28 at 19:17 +0200, Peter Zijlstra wrote:
>
> > To me it makes more sense to reverse these two branches (identical code
> > wise of course) and put the special case first.
> >
> > Alternatively we could also do something like th
On Mon, 2015-04-27 at 16:25 -0400, Waiman Long wrote:
> >> + /*
> >> + * up_write() cleared the owner field before calling this function.
> >> + * If that field is now set, a writer must have stolen the lock and
> >> + * the wakeup operation should be aborted.
> >> + */
> >> + if (rwsem_h
On Wed, 2015-04-08 at 11:15 -0500, Shawn Bohrer wrote:
> AnonHugePages:241664 kB
> HugePages_Total: 512
> HugePages_Free: 512
> HugePages_Rsvd: 384
> HugePages_Surp:0
> Hugepagesize: 2048 kB
>
> So here I have 384 pages reserved and I can't find anything that is
> u
On Wed, 2015-04-08 at 12:39 -0700, Jason Low wrote:
> This patchset applies on top of tip.
>
> Jason Low (2):
> locking/mutex: Further refactor mutex_spin_on_owner()
> locking/rwsem: Use a return variable in rwsem_spin_on_owner()
>
> kernel/locking/mutex.c | 14 --
> kerne
On Thu, 2015-04-09 at 12:43 -0700, Jason Low wrote:
> So that looks more similar to how the original code was where the
> rcu_read_lock() and rcu_read_unlock() was done inside the owner_running
> helper function (though without the CONFIG_DEBUG_PAGEALLOC), before
> commit 307bf9803f25 ("sched: Simp
On Wed, 2015-04-29 at 15:58 -0400, Waiman Long wrote:
> A write lock can also be acquired by a spinning writer in
> rwsem_try_write_lock_unqueued() where wait_lock isn't used. With
> multiple down_read's, it is possible that the first exiting reader wakes
> up a writer who acquires the write loc
Hello,
I am hoping we can have a scaling track this year. The purpose of this
email is to 1) confirm some of the key participants, 2) suggestions for
other key participants and 3) more topics so that we can have a big
enough pool to screen correctly for what's really worth discussing.
I have setu
On Thu, 2015-04-30 at 19:05 +0200, Mike Galbraith wrote:
> LKML is a very high volume list, if you're seeing problems that were
> introduced by a particular patch, it's a good idea to CC the author of
> that patch.
Adding tglx as well, who's the actual author.
--
To unsubscribe from this list: se
On Wed, 2015-04-29 at 21:44 +0200, Manfred Spraul wrote:
> Hi Davidlohr,
>
> On 04/28/2015 06:59 PM, Davidlohr Bueso wrote:
> > On Tue, 2015-04-28 at 18:43 +0200, Peter Zijlstra wrote:
> >> Well, if you can 'guarantee' the cmpxchg will not fail, you can then
On Thu, 2015-04-30 at 14:42 -0400, Waiman Long wrote:
> On 04/29/2015 02:45 PM, Jason Low wrote:
> > On Wed, 2015-04-29 at 14:14 -0400, Waiman Long wrote:
> >> On 04/28/2015 04:00 PM, Jason Low wrote:
> >>> The p->mm->numa_scan_seq is accessed using READ_ONCE/WRITE_ONCE
> >>> and modified without e
Hello,
This series is aimed at addressing some of the futex hash bucket
lock hold times by introducing lockless wake-queues for futex_wake.
patch-1: introduces the lockless wake-queue machinery.
patch-2: makes use of patch 1 for futexes.
Details in the individual patches.
This was suggested som
point
that other events can already trigger them anyway.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 2579e40..f9984c3 100644
--- a/kernel/futex.c
up.
This patch adds the needed infrastructure into the scheduler code
and uses the new wake_q to delay the futex wakeups until after
we've released the corresponding user locks.
Signed-off-by: Peter Zijlstra
[tweaks, adjustments, comments, etc.]
Signed-off-by: Davidlohr Bueso
---
include/lin
On Mon, 2015-04-20 at 08:18 +0200, Ingo Molnar wrote:
> Please write a small description we can cite to driver authors once
> the (inevitable) breakages appear, outlining this new behavior and its
> implications, so that we can fix any remaining bugs ASAP.
I wouldn't call this new behavior, simp
On Mon, 2015-04-20 at 16:57 +0200, Peter Zijlstra wrote:
> Haha, you dug that out did you ;-)
>
> Does this patch on its own actually help anything? Back when I wrote
> that there was the vague hope it would actually help some of the
> client-server ping-pong workloads, where the client does sync
On Mon, 2015-04-20 at 14:24 -0400, George Spelvin wrote:
> +struct wake_q_head {
> + struct wake_q_node *first;
> + struct wake_q_node *last;
> +};
> +
> +#define WAKE_Q_TAIL ((struct wake_q_node *) 0x01)
> +
> +#define WAKE_Q(name) \
> + struct wake_q_he
On Fri, 2015-04-10 at 18:11 +0200, Sebastian Andrzej Siewior wrote:
> This patch delays the wakeup of the process untill
^^^ until
> the hb->lock is
> dropped to avoid boosting + context switch to obtain the lock.
Doing the wakeups while holding th
From: Davidlohr Bueso
AMD has renamed nested page table technology to rapid virtualization indexing,
reflect this change in the kernel.
Signed-off-by: Davidlohr Bueso
---
arch/x86/include/asm/cpufeature.h |2 +-
arch/x86/kernel/cpu/scattered.c |2 +-
arch/x86/kvm/svm.c
On Sat, 2012-07-14 at 12:19 +0200, Borislav Petkov wrote:
> On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote:
> > From: Davidlohr Bueso
> >
> > AMD has renamed nested page table technology to rapid virtualization
> > indexing,
> >
On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote:
> Yep, NAK on this one.
Ok, we could at least add a comment when defining X86_FEATURE_NPT.
Thanks,
Davidlohr
>
> Borislav Petkov wrote:
>
> >On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote:
> >
gion_chg). If fewer pages are actually added,
> this indicates a race and adjust counters accordingly.
>
> Signed-off-by: Mike Kravetz
Reviewed-by: Davidlohr Bueso
With one nit below.
> ---
> mm/hugetlb.c | 34 ++
> 1 file changed, 30 in
On Thu, 2015-06-11 at 14:01 -0700, Mike Kravetz wrote:
> /* Forward declaration */
> static int hugetlb_acct_memory(struct hstate *h, long delta);
> @@ -3324,7 +3324,8 @@ static u32 fault_mutex_hash(struct hstate *h, struct
> mm_struct *mm,
> unsigned long key[2];
> u32 hash;
>
> -
On Mon, 2015-06-15 at 11:34 -0700, Jason Low wrote:
> The CCAS technique was typically used in the slow paths for those
> other locks, where the chance of the operation returning false is
> higher.
That is true. Although I really want to use it in patch 4, I guess I
could move the check in there,
,
the srcu read lock will guarantee the existence of the structure. This
optimizes the common (read locked) case while maintaining the semantics,
such that a shrinker task will not occur if the list is being modified.
Signed-off-by: Davidlohr Bueso
---
fs/super.c | 9 -
mm/vmscan.c | 44
On Tue, 2015-06-16 at 21:29 +0200, Sebastian Andrzej Siewior wrote:
> Davidlohr, would it work for you to replace that patch #1 from your
> series with this one?
I prefer having two separate patches, thus keeping their own changelog
for the change justification.
Thanks,
Davidlohr
--
To unsubscr
On Wed, 2015-06-17 at 09:47 +0200, Michal Hocko wrote:
> On the other hand using srcu is a neat idea. Shrinkers only need the
> existence guarantee when racing with unregister. Register even shouldn't
> be that interesting because such a shrinker wouldn't have much to
> shrink anyway so we can safe
On Mon, 2015-06-22 at 14:16 +0200, Peter Zijlstra wrote:
> This series converts the cpu hotplug lock into a percpu-rwsem to provide a 3rd
> user.
Curious, why not also mem hotplug? It seems to use the exact same
locking mayhem than cpu.
Thanks,
Davidlohr
--
To unsubscribe from this list: send th
On Tue, 2015-06-23 at 00:25 +0200, Marcus Gelderie wrote:
> A while back, the message queue implementation in the kernel was
> improved to use btrees to speed up retrieval of messages (commit
> d6629859b36). The patch introducing the improved kernel handling of
> message queues (using btrees) has,
On Thu, 2015-06-04 at 19:57 +0200, Manfred Spraul wrote:
> On 05/30/2015 02:03 AM, Davidlohr Bueso wrote:
> > We currently use a full barrier on the sender side to
> > to avoid receiver tasks disappearing on us while still
> > performing on the sender side wakeup. We lack ho
On Thu, 2015-06-04 at 11:41 -0700, Davidlohr Bueso wrote:
> On Thu, 2015-06-04 at 19:57 +0200, Manfred Spraul wrote:
> > On 05/30/2015 02:03 AM, Davidlohr Bueso wrote:
> > > We currently use a full barrier on the sender side to
> > > to avoid receiver tasks dis
On Thu, 2015-06-04 at 20:35 +0200, Manfred Spraul wrote:
> Hi Davidlohr,
>
> On 05/30/2015 02:03 AM, Davidlohr Bueso wrote:
> > Upon every shm_lock call, we BUG_ON if an error was returned,
> > indicating racing either in idr or in RMID. Move this logic
> > into the loc
On Thu, 2015-06-04 at 20:35 +0200, Manfred Spraul wrote:
> Hi Davidlohr,
>
> On 05/30/2015 02:03 AM, Davidlohr Bueso wrote:
> > Upon every shm_lock call, we BUG_ON if an error was returned,
> > indicating racing either in idr or in RMID. Move this logic
> > into the loc
Upon every shm_lock call, we BUG_ON if an error was returned,
indicating racing either in idr or in shm_destroy. Move this logic
into the locking.
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
upon a RMID call (->deleted
check), and thus return EINVAL for wrong seq. This difference
in semantics has also caused real bugs, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=246509
Signed-off-by: Davidlohr Bueso
---
ipc/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
pc related ltp tests.
Thanks!
Davidlohr Bueso (5):
ipc,shm: move BUG_ON check into shm_lock
ipc,msg: provide barrier pairings for lockless receive
ipc: rename ipc_obtain_object
ipc,sysv: make return -EIDRM when racing with RMID consistent
ipc,sysv: return -EINVAL upon incorrect id/seqnum
destroying a queue.
Signed-off-by: Davidlohr Bueso
---
ipc/msg.c | 48 ++--
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 2b6fdbb..a9c3c51 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -196,7 +196,7 @@ static void
ock:
if (!ipc_valid_object()) {
err = -EIDRM;
goto out_unlock;
}
Thus make ipc_lock consistent with the rest of ipc code and return
-EIDRM in ipc_lock when !ipc_valid_object().
Signed-off-by: Davidlohr Bueso
---
ipc/util.c | 13 -
1 file ch
... to ipc_obtain_object_idr, which is more meaningful
and makes the code slightly easier to follow.
Signed-off-by: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 4 ++--
ipc/shm.c | 2 +-
ipc/util.c | 8
ipc/util.h | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff
On Fri, 2015-06-05 at 14:38 +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Davidlohr Bueso wrote:
>
> > Avoid unnecessary cmpxchg calls, all of our other locks
> > use it as well.
> >
> > Signed-off-by: Davidlohr Bueso
> > ---
> > kernel/locking
/Makefile that simply passes the building to the individual
subdirectory.
Signed-off-by: Davidlohr Bueso
---
tools/testing/selftests/ipc/.gitignore | 3 +
tools/testing/selftests/ipc/Makefile | 32 +-
tools/testing/selftests/ipc/mqueue/Makefile| 22 +
tools
On Fri, 2015-06-05 at 15:59 +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Davidlohr Bueso wrote:
> >
> > +/*
> > + * Lockless alternative to rt_mutex_has_waiters() as we do not need the
> > + * wait_lock to check if we are in, for instance, a transitional
On Mon, 2015-06-01 at 15:52 -0700, Andrew Morton wrote:
> On Fri, 29 May 2015 17:03:05 -0700 Davidlohr Bueso wrote:
>
> > Upon every shm_lock call, we BUG_ON if an error was returned,
> > indicating racing either in idr or in RMID. Move this logic
> > into the locking.
&g
On Mon, 2015-06-01 at 15:52 -0700, Andrew Morton wrote:
> On Fri, 29 May 2015 17:03:05 -0700 Davidlohr Bueso wrote:
>
> > Upon every shm_lock call, we BUG_ON if an error was returned,
> > indicating racing either in idr or in RMID. Move this logic
> > into the locking.
&g
Hello,
This conference will happen, so if you are interested in attending, I
urge you to please register for plumbers (and update the wiki if you
have not done so already). Note that last day of earlybird registration
is tomorrow, Friday June 5.
Thanks,
Davidlohr
--
To unsubscribe from this list
601 - 700 of 2531 matches
Mail list logo
