Use the new api and associate the seqcounter to the jiffies_lock enabling
lockdep support - although for this particular case the write-side locking
and non-preemptibility are quite obvious.
Signed-off-by: Davidlohr Bueso
---
kernel/time/jiffies.c | 3 ++-
kernel/time/timekeeping.h | 2
trivially get rid
of two more users.
Acked-by: Oleg Nesterov
Signed-off-by: Davidlohr Bueso
---
kernel/debug/gdbstub.c | 4 ++--
kernel/debug/kdb/kdb_bt.c | 4 ++--
kernel/debug/kdb/kdb_main.c| 8
kernel/debug/kdb/kdb_private.h | 4
4 files changed, 8 insertions
On Mon, 07 Sep 2020, Daniel Thompson wrote:
No objections to the change but kdb doesn't use tsk->thread_group,
it uses do_each_thread/while_each_thread. Can we change this to
say that is osbsolete and racy to use while_each_thread() (that's
pretty much what the description of the patch that
oiding two atomic ops in the uncontended case.
Signed-off-by: Davidlohr Bueso
---
kernel/trace/fgraph.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
index 1af321dec0f1..5658f13037b3 100644
--- a/kernel/trace/fgraph.c
On Sun, 16 Aug 2020, Davidlohr Bueso wrote:
Hi,
This is a (late) update on trying to reduce some of the scope of the
tasklist_lock
for get/setpriority(2) as well as the block io equivalent. This version
addresses
Oleg's previous concerns and incorporates his feedback.
Changes from v1:
https
to provide.
Signed-off-by: Paul E. McKenney
Reviwed-by: Davidlohr Bueso
On Tue, 01 Sep 2020, Paul E. McKenney wrote:
And it appears that a default-niced CPU-bound SCHED_OTHER process is
not preempted by a newly awakened MAX_NICE SCHED_OTHER process. OK,
OK, I never waited for more than 10 minutes, but on my 2.2GHz that is
close enough to a hang for most people.
The call simply looks up the corresponding task (without iterating
the tasklist), which is safe under rcu instead of the tasklist_lock.
In addition, the setaffinity counter part already does this.
Signed-off-by: Davidlohr Bueso
---
arch/mips/kernel/mips-mt-fpaff.c | 4 ++--
1 file changed, 2
one, maintaining semantics,
of course.
Signed-off-by: Davidlohr Bueso
---
kernel/debug/kdb/kdb_bt.c | 4 ++--
kernel/debug/kdb/kdb_main.c| 8
kernel/debug/kdb/kdb_private.h | 4
3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/de
On Thu, 20 Aug 2020, Qian Cai wrote:
On Thu, Aug 20, 2020 at 01:39:02PM -0700, Davidlohr Bueso wrote:
kmemleak_scan() currently relies on the big tasklist_lock
hammer to stabilize iterating through the tasklist. Instead,
this patch proposes simply using rcu along with the rcu-safe
->thread_group and thus
cannot race with exit. Furthermore, any races with fork()
and not seeing the new child should be benign as it's not
running yet and can also be detected by the next scan.
Signed-off-by: Davidlohr Bueso
---
mm/kmemleak.c | 8
1 file changed, 4 insertions(+), 4 deleti
combo
in PRIO_USER for the rcu-safe for_each_process_thread flavor,
which doesn't make use of next_thread/p->thread_group.
Suggested-by: Oleg Nesterov
Signed-off-by: Davidlohr Bueso
---
kernel/sys.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/ker
: Greg Thelen
Signed-off-by: Davidlohr Bueso
---
block/ioprio.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/ioprio.c b/block/ioprio.c
index 77bcab11dce5..4ede2da961bb 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -119,11 +119,13 @@ SYSCALL_DEFINE3(ioprio_set, int, which, int
-d...@stgolabs.net/
- only take the lock for PGID cases.
- drop bogus PF_EXITING checks (and live with the small exit race).
- add patch for IOPRIO_WHO_PGRP.
Please consider for v5.10.
Thanks!
Davidlohr Bueso (2):
kernel/sys: only take tasklist_lock for get/setpriority(PRIO_PGRP)
block
On Sat, 18 Jul 2020, Joel Fernandes (Google) wrote:
+/* Move from's segment length to to's segment. */
+static void rcu_segcblist_move_seglen(struct rcu_segcblist *rsclp, int from,
int to)
+{
+ long len = rcu_segcblist_get_seglen(rsclp, from);
+
+ if (!len || from == to)
+
-by: Vlastimil Babka
Reviewed-by: Davidlohr Bueso
Zijlstra for suggesting this API as the
least-ugly way of addressing this in the short term.
Signed-off-by: Michel Lespinasse
Reviewed-by: Daniel Jordan
Reviewed-by: Vlastimil Babka
Sigh, bpf, but ok.
Reviewed-by: Davidlohr Bueso
---
include/linux/mmap_lock.h | 14 ++
kernel/bpf
On Tue, 19 May 2020, Michel Lespinasse wrote:
Convert comments that reference old mmap_sem APIs to reference
corresponding new mmap locking APIs instead.
Signed-off-by: Michel Lespinasse
Reviewed-by: Davidlohr Bueso
On Mon, 18 May 2020, Paolo Bonzini wrote:
On 24/04/20 07:48, Davidlohr Bueso wrote:
+/*
+ * Note: this provides no serialization and, just as with waitqueues,
+ * requires care to estimate as to whether or not the wait is active.
+ */
+static inline int rcuwait_active(struct rcuwait *w
On Tue, 12 May 2020, Oleg Nesterov wrote:
On 05/12, Davidlohr Bueso wrote:
On Tue, 12 May 2020, Oleg Nesterov wrote:
>do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
>which moves the task from one hlist to another. Yes, it is safe in
>that task_struct can'
On Tue, 12 May 2020, Oleg Nesterov wrote:
On 05/11, Davidlohr Bueso wrote:
Currently the tasklist_lock is shared mainly in order to observe
the list atomically for the PRIO_PGRP and PRIO_USER cases, as
the actual lookups are already rcu-safe,
not really...
do_each_pid_task(PIDTYPE_PGID
in the changelog but this passes ltp tests. Please consider for v5.8.
Changes from v1:
- split get and set into two patches.
- improved changelog.
Thanks!
Davidlohr Bueso (2):
kernel/sys: only rely on rcu for getpriority(2)
kernel/sys: do not grab tasklist_lock for sys_setpriority(PRIO_PROCESS
( 0.00%)40284.35 * 28.05%*
Hmean get-3230036.64 ( 0.00%)40657.88 * 35.36%*
Hmean get-6431429.86 ( 0.00%)41021.73 * 30.52%*
Hmean get-8031804.13 ( 0.00%)39188.55 * 23.22%*
Signed-off-by: Davidlohr Bueso
---
kernel/sys.c | 8 ++--
1 file
().
Signed-off-by: Davidlohr Bueso
---
kernel/sys.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 0b72184f5e3e..f9f87775d6d2 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -214,16 +214,19 @@ SYSCALL_DEFINE3(setpriority, int, which
Cc'ing Oleg who iirc also like this stuff.
On Sat, 02 May 2020, Peter Zijlstra wrote:
On Fri, May 01, 2020 at 08:05:39PM -0700, Davidlohr Bueso wrote:
For both setpriority(2) and getpriority(2) there's really no need
to be taking the tasklist_lock at all - for which both share
get-8031804.13 ( 0.00%)39188.55 * 23.22%*
Signed-off-by: Davidlohr Bueso
---
kernel/sys.c | 4
1 file changed, 4 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index d325f3ab624a..12ade1a00a18 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -214,7 +214,6 @@ SYSCALL_DEFI
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 12ac6782a40ad7636b6ef45680741825b64ab221
Gitweb:
https://git.kernel.org/tip/12ac6782a40ad7636b6ef45680741825b64ab221
Author:Davidlohr Bueso
AuthorDate:Tue, 21 Apr 2020 21:07:39 -07:00
Cleanup by both getting rid of passing the rb_root down the helper
calls; there is only one. Secondly rename some of the calls from
memtype_rb_*.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/pat_rbtree.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git
Drop the rbt_memtype_* calls (those used by pat.c) as we
no longer use an rbtree directly.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/pat.c | 8
arch/x86/mm/pat_internal.h | 20 ++--
arch/x86/mm/pat_rbtree.c | 12 ++--
3 files changed, 20
-mm=157116340411211
Davidlohr Bueso (4):
x86/mm, pat: Convert pat tree to generic interval tree
x86,mm/pat: Cleanup some of the local memtype_rb_* calls
x86,mm/pat: Drop rbt suffix from external memtype calls
x86/mm, pat: Rename pat_rbtree.c to pat_interval.c
arch/x86/mm/pat.c
with the current version and so far see no differences in the
returned pointer node when doing memtype_rb_lowest_match() lookups.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/pat_rbtree.c | 164 +--
1 file changed, 43 insertions(+), 121 deletions
Considering the previous changes, this is a more proper name.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/{pat_rbtree.c => pat_interval.c} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename arch/x86/mm/{pat_rbtree.c => pat_interval.c} (100%)
diff --git a/arch/x86/mm/pat_rbtr
On Tue, 15 Oct 2019, Peter Zijlstra wrote:
On Mon, Oct 14, 2019 at 06:26:04PM -0700, Davidlohr Bueso wrote:
On Sat, 12 Oct 2019, Manfred Spraul wrote:
> Invalid would be:
>smp_mb__before_atomic();
>atomic_set();
fyi I've caught a couple of naughty users:
drivers/cryp
(), which seems like the
original intent of when the code was written.
Signed-off-by: Davidlohr Bueso
---
drivers/crypto/cavium/nitrox/nitrox_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c
b/drivers/crypto/cavium/nitrox
On Sat, 12 Oct 2019, Manfred Spraul wrote:
Invalid would be:
smp_mb__before_atomic();
atomic_set();
fyi I've caught a couple of naughty users:
drivers/crypto/cavium/nitrox/nitrox_main.c
drivers/gpu/drm/msm/adreno/a5xx_preempt.c
Thanks,
Davidlohr
On Mon, 14 Oct 2019, Manfred Spraul wrote:
I've updated the Change description accordingly
I continue to think my memory-barriers.txt change regarding failed
Rmw is still good to have. Unless any strong objections, could you
also add the patch to the series?
Thanks,
Davidlohr
SE
- CPU2: the spin_lock() of the waker is the ACQUIRE
- CPU2: smp_mb__before_atomic inside wake_q_add() is the RELEASE
- CPU3: smp_mb__after_spinlock() inside try_to_wake_up() is the ACQUIRE
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
Without considering the smp_stor
On Sat, 12 Oct 2019, Manfred Spraul wrote:
Patch entirely from Davidlohr:
pipelined_send() and pipelined_receive() are identical, so merge them.
Sorry, yeah feel free to add my:
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
ipc/mqueue.c | 31
Spraul
Cc: Davidlohr Bueso
---
kernel/sched/core.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dd05a378631a..60ae574317fd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -440,8 +440,16
On Fri, 11 Oct 2019, Manfred Spraul wrote:
But you are right, there are two different scenarios:
1) thread already in another wake_q, wakeup happens immediately after
the cmpxchg_relaxed().
This scenario is safe, due to the smp_mb__before_atomic() in wake_q_add()
2) thread woken up but e.g.
On Fri, 11 Oct 2019, Manfred Spraul wrote:
Update and document memory barriers for mqueue.c:
- ewp->state is read without any locks, thus READ_ONCE is required.
In general we relied on the barrier for not needing READ/WRITE_ONCE,
but I agree this scenario should be better documented with
On Fri, 11 Oct 2019, Manfred Spraul wrote:
I don't know. The new documentation would not have answered my
question (is it ok to combine smp_mb__before_atomic() with
atomic_relaxed()?). And it copies content already present in
atomic_t.txt.
Well, the _relaxed (and release/acquire) extentions
like this?
8<-
From: Davidlohr Bueso
Subject: [PATCH] Documentation/memory-barriers.txt: Mention
smp_mb__{before,after}_atomic() and CAS
Explicitly mention possible usages to guarantee serialization even upon
failed cmpxchg (or simil
to hugetlb_fault_mutex_hash is no longer used. So, remove it from the
definition and all callers.
No functional change.
Reported-by: Nathan Chancellor
Signed-off-by: Mike Kravetz
Reviewed-by: Davidlohr Bueso
On Tue, 17 Sep 2019, Paul E. McKenney wrote:
On Tue, Sep 17, 2019 at 12:16:14AM -0700, Davidlohr Bueso wrote:
On Mon, 16 Sep 2019, Sebastian Andrzej Siewior wrote:
> From: Wolfgang M. Reimer
>
> Including rwlock.h directly will cause kernel builds to fail
> if CONFIG_PREEMPT_R
anyway.
Remove the include of linux/rwlock.h.
Acked-by: Davidlohr Bueso
Signed-off-by: Wolfgang M. Reimer
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/locking/locktorture.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index
the same thing. It was changed here:
commit 83cde9e8ba95d180eaefefe834958fbf7008cf39
Author: Davidlohr Bueso
Date: Fri Dec 12 16:54:21 2014 -0800
mm: use new helper functions around the i_mmap_mutex
Convert all open coded mutex_lock/unlock calls to the
i_mmap_[lock/unlock]_write() helpers
On Wed, 04 Sep 2019, Michel Lespinasse wrote:
Hi Davidlohr,
On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote:
Ok, so for that I've added the following helper which will make the
conversion a bit more straightforward:
#define vma_interval_tree_foreach_stab(vma, root, start
not
change any semantics.
Signed-off-by: Davidlohr Bueso
---
arch/arm/mm/fault-armv.c | 2 +-
arch/arm/mm/flush.c| 2 +-
arch/nios2/mm/cacheflush.c | 2 +-
arch/parisc/kernel/cache.c | 2 +-
fs/dax.c | 2 +-
include/linux/mm.h | 6 ++
kernel/events/uprobes.c
On Wed, 04 Sep 2019, Michel Lespinasse wrote:
I do not have time for a full review right now, but I did have a quick
pass at it and it does seem to match the direction I'd like this to
take.
Thanks, and no worries, I consider all this v5.5 material anyway.
Please let me know if you'd like
On Thu, 22 Aug 2019, Michel Lespinasse wrote:
I think vma_interval_tree is a bit of a mixed bag, but mostly leans
towards using half closed intervals.
Right now vma_last_pgoff() has to do -1 because of the interval tree
using closed intervals. Similarly, rmap_walk_file(), which I consider
to
On Wed, 21 Aug 2019, Michel Lespinasse wrote:
As I had commented some time ago, I wish the interval trees used [start,end)
intervals instead of [start,last] - it would be a better fit for basically
all of the current interval tree users.
So the vma_interval_tree (which is a pretty important
On Wed, 21 Aug 2019, Michel Lespinasse wrote:
On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote:
o The border cases for overlapping differ -- interval trees are closed,
while memtype intervals are open. We need to maintain semantics such
that conflict detection and getting
On Tue, 02 Jul 2019, Michel Lespinasse wrote:
Ehhh, I have my own list of gripes about interval tree (I'm
responsible for some of these too):
Sorry just getting back to this.
- The majority of interval tree users (though either the
interval_tree.h or the interval_tree_generic.h API) do not
Cleanup by both getting rid of passing the rb_root down the helper
calls; there is only one. Secondly rename some of the calls from
memtype_rb_ to memtype_interval_.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/pat_rbtree.c | 33 ++---
1 file changed, 14 insertions
-by: Davidlohr Bueso
---
arch/x86/mm/pat_rbtree.c | 167 +++
1 file changed, 54 insertions(+), 113 deletions(-)
diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index fa16036fa592..1be4d1856a9b 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm
Hi,
Please refer to patch 1 for details, other two are incremental (small) cleanups
that probably depend on the first one.
Thanks!
Davidlohr Bueso (3):
x86,mm/pat: Use generic interval trees
x86,mm/pat: Cleanup some of the local memtype_rb_* calls
x86,mm/pat: Rename pat_rbtree.c
Considering the previous changes, this is a more proper name.
Signed-off-by: Davidlohr Bueso
---
arch/x86/mm/Makefile | 2 +-
arch/x86/mm/{pat_rbtree.c => pat_interval.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/x86/mm/{pat_rbtre
Commit-ID: fce45cd41101f1a9620267146b21f09b3454d8db
Gitweb: https://git.kernel.org/tip/fce45cd41101f1a9620267146b21f09b3454d8db
Author: Davidlohr Bueso
AuthorDate: Sun, 28 Jul 2019 21:47:35 -0700
Committer: Peter Zijlstra
CommitDate: Tue, 6 Aug 2019 12:49:15 +0200
locking/rwsem: Check
On 2019-07-18 06:49, Peter Zijlstra wrote:
These are the patches I ended up with after we started with Jan's
patch (edited).
This series looks good to me.
Acked-by: Davidlohr Bueso
Currently rwsems is the only locking primitive that lacks this
debug feature. Add it under CONFIG_DEBUG_RWSEMS and do the magic
checking in the locking fastpath (trylock) operation such that
we cover all cases. The unlocking part is pretty straightforward.
Signed-off-by: Davidlohr Bueso
Commit-ID: 511885d7061eda3eb1faf3f57dcc936ff75863f1
Gitweb: https://git.kernel.org/tip/511885d7061eda3eb1faf3f57dcc936ff75863f1
Author: Davidlohr Bueso
AuthorDate: Wed, 24 Jul 2019 08:23:23 -0700
Committer: Thomas Gleixner
CommitDate: Wed, 24 Jul 2019 17:38:01 +0200
lib/timerqueue
ins the same.
Passes several hours of rcutorture.
Signed-off-by: Davidlohr Bueso
---
include/linux/timerqueue.h | 13 ++---
lib/timerqueue.c | 28 +++-
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/include/linux/timerqueue.h b/include/li
ping (with the merge window now closed).
-off-by: Michel Lespinasse
Acked-by: Davidlohr Bueso
On Tue, 02 Jul 2019, Michel Lespinasse wrote:
diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index fa16036fa592..2afad8e869fc 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -54,23 +54,10 @@ static u64 get_subtree_max_end(struct rb_node *node)
On Thu, 27 Jun 2019, Michel Lespinasse wrote:
As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
can easily be implemented externally to the core rbtree api.
Change the implementation to do just that. Previously the update of
rb_leftmost was wired deeper into the
.
I think this makes sense, and is more along the lines of the augmented
cached doing the static inline instead of separate instantiations of the
calls.
Change-Id: I0cb62be774fc0138b81188e6ae81d5f1da64578d
what is this?
Signed-off-by: Michel Lespinasse
Acked-by: Davidlohr Bueso
Thanks!
ins the same.
Passes several hours of rcutorture.
Signed-off-by: Davidlohr Bueso
---
include/linux/timerqueue.h | 13 ++---
lib/timerqueue.c | 28 +++-
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/include/linux/timerqueue.h b/include/li
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
fs/aio.c | 5 +++--
fs/coredump.c | 5 +++--
fs/exec.c | 19
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
drivers/android/binder_alloc.c | 7 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
drivers
and some lockdep stuff have been blindly
converted (for now).
This lays out the foundations for later mm address
space locking scalability.
Signed-off-by: Davidlohr Bueso
---
arch/x86/events/core.c | 2 +-
arch/x86/kernel/tboot.c| 2 +-
arch/x86/mm/fault.c| 2 +-
drivers
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time, and we already
have vmf updated. No changes in semantics.
Signed-off-by: Davidlohr Bueso
---
include/linux/mm.h | 8 +++---
mm/filemap.c | 8 +++---
mm/frame_vector.c | 4
rsions,
but not enough to matter in the overall picture.
Signed-off-by: Davidlohr Bueso
Reviewed-by: Jan Kara
---
include/linux/lockdep.h | 33 +++
include/linux/range_lock.h | 189 +
kernel/locking/Makefile | 2 +-
kernel/locking/range_lock.c
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
kernel/acct.c | 5 +++--
kernel/bpf/stackmap.c | 7 +--
kernel/events/core.c| 5 +++--
kernel
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index ce1ca9f7c6e9
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
arch/x86/entry/vdso/vma.c | 12 +++-
arch/x86/kernel/vm86_32.c | 5 +++--
arch/x86/kvm/paging_tmpl.h | 9
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
virt/kvm/arm/mmu.c | 17 ++---
virt/kvm/async_pf.c | 4 ++--
virt/kvm/kvm_main.c | 11 ++-
3 files changed, 18
Conversion is straightforward, mmap_sem is used within the
the same function context most of the time. No change in
semantics.
Signed-off-by: Davidlohr Bueso
---
net/ipv4/tcp.c | 5 +++--
net/xdp/xdp_umem.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv4
ly set VM_MIXEDMAP):
.fault = etnaviv_gem_fault
.fault = udl_gem_fault
tegra_bo_fault()
As such, drop the reader trylock BUG_ON() for the common case.
This avoids having file_operations know about mmranges, as
mmap_sem is held during, mmap() for example.
Signed-off-by: Davidlohr Bueso
---
include
This patch adds the necessary wrappers to encapsulate mmap_sem
locking and will enable any future changes to be a lot more
confined to here. In addition, future users will incrementally
be added in the next patches. mm_[read/write]_[un]lock() naming
is used.
Signed-off-by: Davidlohr Bueso
ouched.
Semantically nothing changes at all, and the 'mmrange' ends up
being unused for now. Later patches will use the variable when
the mmap_sem wrappers replace straightforward down/up.
*** For simplicity, this patch breaks when used in ksm and hmm. ***
Signed-off-by: Davidlohr Bueso
---
arch/
2240.gn29...@dread.disaster.area/
[3] https://lore.kernel.org/lkml/20190314195452.gn19...@bombadil.infradead.org/
[4] http://linux-scalability.org/range-mmap_lock/mmap_sem.cocci
Thanks!
Davidlohr Bueso (14):
interval-tree: build unconditionally
Introduce range reader/writer lock
mm: introduce mm locking wrap
In preparation for range locking, this patch gets rid of
CONFIG_INTERVAL_TREE option as we will unconditionally
build it.
Signed-off-by: Davidlohr Bueso
---
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/i915/Kconfig | 1 -
drivers/iommu/Kconfig| 1 -
lib/Kconfig
the epoll bits (along with the overall
idea) and it seems like a sane alternative to reverting the offending patch.
Feel free to add:
Reviewed-by: Davidlohr Bueso
A small nit, I think we should be a bit more verbose about the return semantics
of restore_user_sigmask()... see at the end.
Reported
On Thu, 02 May 2019, Deepa Dinamani wrote:
Reported-by: Omar Kilani
Do we actually know if this was the issue Omar was hitting?
Thanks,
Davidlohr
On Wed, 01 May 2019, Peter Zijlstra wrote:
Nah, the percpu_rwsem abuse by the freezer is atrocious, we really
should not encourage that. Also, it completely wrecks -RT.
Hence the proposed patch.
Is this patch (and removing rcuwait) only intended for rt?
Thanks,
Davidlohr
On Sun, 28 Apr 2019, Eric Wong wrote:
Just running one test won't trigger since it needs a busy
machine; but:
make test/mgmt_auto_adjust.log
(and "rm make test/mgmt_auto_adjust.log" if you want to rerun)
fyi no luck reproducing on both either a large (280) or small (4 cpu)
On Wed, 24 Apr 2019, Davidlohr Bueso wrote:
On Wed, 24 Apr 2019, Eric Wong wrote:
Omar Kilani wrote:
Hi there,
I???m still trying to piece together a reproducible test that triggers
this, but I wanted to post in case someone goes ???hmmm... change X
might have done this???.
Maybe
On Wed, 24 Apr 2019, Eric Wong wrote:
Omar Kilani wrote:
Hi there,
I???m still trying to piece together a reproducible test that triggers
this, but I wanted to post in case someone goes ???hmmm... change X
might have done this???.
Maybe Davidlohr knows, since he's responsible for most of
On Sat, 13 Apr 2019, Waiman Long wrote:
+/*
+ * We limit the maximum number of readers that can be woken up for a
+ * wake-up call to not penalizing the waking thread for spending too
+ * much time doing it.
+ */
+#define MAX_READERS_WAKEUP 0x100
Although with wake_q this is not really
s,
in general).
Fixes: b5cec28d36f5 ("hugetlbfs: truncate_hugepages() takes a range of pages")
Ok the issue was introduced after we had the mutex table.
Cc:
Thanks for the details, I'm definitely seeing the idx mismatch issue now.
Reviewed-by: Davidlohr Bueso
On Fri, 05 Apr 2019, Waiman Long wrote:
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can
On Wed, 10 Apr 2019, Bueso wrote:
On Wed, 10 Apr 2019, Waiman Long wrote:
2) I want to avoid the extreme case that there are more than 32k readers
in the wait queue and make the count overflow.
But in this case the readers are already on the queue.
Never mind this.
But the limit could
On Wed, 10 Apr 2019, Waiman Long wrote:
There are 2 major reasons why there is a limit.
1) It will be unfair to the task that needs to spend so much of its own
CPU time to wake up too many readers.
This has never been a problem before.
2) I want to avoid the extreme case that there are more
On Fri, 05 Apr 2019, Waiman Long wrote:
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of
On Mon, 08 Apr 2019, Kees Cook wrote:
This fixes the various compiler warnings when building the msgque
selftest. The primary change is using sys/msg.h instead of linux/msg.h
directly to gain the API declarations.
Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test")
On Thu, 28 Mar 2019, Mike Kravetz wrote:
- A BUG can be triggered (not easily) due to temporarily mapping a
page before doing a COW.
But you actually _have_ seen it? Do you have the traces? I ask
not because of the patches perse, but because it would be nice
to have a real snipplet in the
We already store the current task fo the new waiter before calling
wq_sleep() in both send and recv paths. Trivially remove the redundant
assignment.
Signed-off-by: Davidlohr Bueso
---
ipc/mqueue.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index
e the node with the highest priority in O(1), which is
specially nice for the rt cases. Furthermore, some callers can call msg_get()
in a loop.
A new msg_tree_erase() helper is also added to encapsulate the tree removal
and node_cache game. Passes ltp mq testcases.
Signed-off-by: Davidlohr Bueso
101 - 200 of 4799 matches
Mail list logo
