I cannot spell 'throttling'.
Signed-off-by: Davidlohr Bueso
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 67702b4d9ac7..6601baf2361c 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
That's exactly what you need to explain in the patch or the commit
message. In fact you still haven't explained it fully. Why do we
need a second attempt without the GFP_NOFAIL? How does
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote:
That's exactly what you need to explain in the patch or the commit
message. In fact you still haven't explained it fully. Why do we
need a second attempt without the GFP_NOFAIL? How does
On Wed, 30 May 2018, Herbert Xu wrote:
Well I think we should respect min_size. rhashtable users may
fail at insertion time if the table is too small.
I'm fine either way.
On Wed, 30 May 2018, Herbert Xu wrote:
Well I think we should respect min_size. rhashtable users may
fail at insertion time if the table is too small.
I'm fine either way.
On Wed, 30 May 2018, Herbert Xu wrote:
It doesn't explain it at all. In fact I don't see why we neeed
three attempts, just do the GFP_NOFAIL as the second and final step.
Second attempt is reduced size only as we don't want to GFP_NOFAIL
if we can avoid it helping the allocator. We go from
On Wed, 30 May 2018, Herbert Xu wrote:
It doesn't explain it at all. In fact I don't see why we neeed
three attempts, just do the GFP_NOFAIL as the second and final step.
Second attempt is reduced size only as we don't want to GFP_NOFAIL
if we can avoid it helping the allocator. We go from
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
such that we have a single fallback.
Where did he suggest that?
https://lkml.org/lkml/2018/5/24/1265
On Wed, 30 May 2018, Herbert Xu wrote:
On Tue, May 29, 2018 at 09:42:31AM -0700, Davidlohr Bueso wrote:
For the sake of simplicity, Linus suggested directly using HASH_MIN_SIZE
such that we have a single fallback.
Where did he suggest that?
https://lkml.org/lkml/2018/5/24/1265
On Mon, 28 May 2018, Herbert Xu wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size, otherwise we exhaust our options with
+* __GFP_NOFAIL.
+
On Mon, 28 May 2018, Herbert Xu wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size, otherwise we exhaust our options with
+* __GFP_NOFAIL.
+
On Mon, 28 May 2018, Herbert Xu wrote:
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size
On Mon, 28 May 2018, Herbert Xu wrote:
On Thu, May 24, 2018 at 02:11:31PM -0700, Davidlohr Bueso wrote:
+ /*
+* This is api initialization and thus we need to guarantee the
+* initial rhashtable allocation. Upon failure, retry with a
+* smallest possible size
On Tue, 29 May 2018, Naresh Kamboju wrote:
On 28 May 2018 at 15:30, Greg Kroah-Hartman wrote:
On all devices,
ltp-syscalls-tests:
* cve-2017-5669
ltp-cve-tests:
* cve-2017-5669
Test log:
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
On Tue, 29 May 2018, Naresh Kamboju wrote:
On 28 May 2018 at 15:30, Greg Kroah-Hartman wrote:
On all devices,
ltp-syscalls-tests:
* cve-2017-5669
ltp-cve-tests:
* cve-2017-5669
Test log:
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
On Mon, 28 May 2018, Herbert Xu wrote:
On Mon, May 28, 2018 at 06:12:09AM -0700, Davidlohr Bueso wrote:
Well, I don't really _want_ them; nor does the ipc code which already
does a WARN_ON() (but that goes away in future patches). What I want
is to get rid of the return path. So I don't
On Mon, 28 May 2018, Herbert Xu wrote:
On Mon, May 28, 2018 at 06:12:09AM -0700, Davidlohr Bueso wrote:
Well, I don't really _want_ them; nor does the ipc code which already
does a WARN_ON() (but that goes away in future patches). What I want
is to get rid of the return path. So I don't
On Mon, 28 May 2018, Herbert Xu wrote:
I don't really see why we need these WARN_ONs. The problem should
be quite obvious when you're writing your code.
If you really want them perhaps add them to the ipc code instead?
Well, I don't really _want_ them; nor does the ipc code which already
On Mon, 28 May 2018, Herbert Xu wrote:
I don't really see why we need these WARN_ONs. The problem should
be quite obvious when you're writing your code.
If you really want them perhaps add them to the ipc code instead?
Well, I don't really _want_ them; nor does the ipc code which already
On Thu, 24 May 2018, Linus Torvalds wrote:
On Thu, May 24, 2018 at 2:28 PM Davidlohr Bueso <d...@stgolabs.net> wrote:
10 files changed, 79 insertions(+), 86 deletions(-)
I certainly can't complain about this small code removal, but I think if we
did the kvmalloc_node() cleanup
On Thu, 24 May 2018, Linus Torvalds wrote:
On Thu, May 24, 2018 at 2:28 PM Davidlohr Bueso wrote:
10 files changed, 79 insertions(+), 86 deletions(-)
I certainly can't complain about this small code removal, but I think if we
did the kvmalloc_node() cleanup, we'd be able to get rid
On Thu, 24 May 2018, Davidlohr Bueso wrote:
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
+ if (retry) {
+ gfp |= __GFP_NOFAIL;
+ tbl = kzalloc(size, gfp);
+ } /* fall-through */
+
if (gfp != GFP_KERNEL)
On Thu, 24 May 2018, Davidlohr Bueso wrote:
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
+ if (retry) {
+ gfp |= __GFP_NOFAIL;
+ tbl = kzalloc(size, gfp);
+ } /* fall-through */
+
if (gfp != GFP_KERNEL)
all into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly
get rid of the hack altogether.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
include/linux/ipc_namespace.h | 1 -
ipc/util.c| 23 ---
2 files changed, 8 i
all into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly
get rid of the hack altogether.
Signed-off-by: Davidlohr Bueso
---
include/linux/ipc_namespace.h | 1 -
ipc/util.c| 23 ---
2 files changed, 8 insertions(+), 16 deleti
Now that we know that rhashtable_init() will not fail, we
can get rid of a lot of the unnecessary cleanup paths when
the call errored out.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
ipc/msg.c | 9 -
ipc/namespace.c | 20
ipc/sem.c
Now that we know that rhashtable_init() will not fail, we
can get rid of a lot of the unnecessary cleanup paths when
the call errored out.
Signed-off-by: Davidlohr Bueso
---
ipc/msg.c | 9 -
ipc/namespace.c | 20
ipc/sem.c | 10 --
ipc/shm.c
For some reason we don't use this call, but we rely just
fine on kmalloc_array(). Make both consistent.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
lib/bucket_locks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/bucket_locks.c b/lib/bucket_locks.c
Update the test module as such.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
lib/test_rhashtable.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
index f4000c137dbe..a894eb0407f0 100644
--- a/lib/test_rhasht
For some reason we don't use this call, but we rely just
fine on kmalloc_array(). Make both consistent.
Signed-off-by: Davidlohr Bueso
---
lib/bucket_locks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/bucket_locks.c b/lib/bucket_locks.c
index 266a97c5708b
Update the test module as such.
Signed-off-by: Davidlohr Bueso
---
lib/test_rhashtable.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
index f4000c137dbe..a894eb0407f0 100644
--- a/lib/test_rhashtable.c
+++ b/lib
buckets, we retry with only 4. Any later issues regarding
performance due to collisions or larger table resizing (when
more memory becomes available) is the last of our problems.
Suggested-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Davidlohr Bueso <dbu...@suse.de&
buckets, we retry with only 4. Any later issues regarding
performance due to collisions or larger table resizing (when
more memory becomes available) is the last of our problems.
Suggested-by: Linus Torvalds
Signed-off-by: Davidlohr Bueso
---
lib/rhashtable.c | 40
For the purpose of making rhashtable_init() unable to fail,
we can replace the returning -EINVAL with WARN_ONs whenever
the caller passes bogus parameters during initialization.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
lib/rhashtable.c | 9 -
1 file changed, 4 insertions
For the purpose of making rhashtable_init() unable to fail,
we can replace the returning -EINVAL with WARN_ONs whenever
the caller passes bogus parameters during initialization.
Signed-off-by: Davidlohr Bueso
---
lib/rhashtable.c | 9 -
1 file changed, 4 insertions(+), 5 deletions
.
Please consider for v4.18.
Thanks!
[0] https://lkml.org/lkml/2018/5/23/758
Davidlohr Bueso (6):
lib/rhashtable: convert param sanitations to WARN_ON
lib/rhashtable: guarantee initial hashtable allocation
lib/bucket_locks: use kvmalloc_array()
ipc: get rid of ids->tables_initialized hack
.
Please consider for v4.18.
Thanks!
[0] https://lkml.org/lkml/2018/5/23/758
Davidlohr Bueso (6):
lib/rhashtable: convert param sanitations to WARN_ON
lib/rhashtable: guarantee initial hashtable allocation
lib/bucket_locks: use kvmalloc_array()
ipc: get rid of ids->tables_initialized hack
On Thu, 24 May 2018, Linus Torvalds wrote:
This doesn't seem to be taking 'param->min_size' into account.
It was in that rounded_hashtable_size() does, however, after more
thought I think we can do better by taking it much more into account.
I'm not sure that matters, but right now, if you
On Thu, 24 May 2018, Linus Torvalds wrote:
This doesn't seem to be taking 'param->min_size' into account.
It was in that rounded_hashtable_size() does, however, after more
thought I think we can do better by taking it much more into account.
I'm not sure that matters, but right now, if you
On Wed, 23 May 2018, Linus Torvalds wrote:
One option is to make rhashtable_alloc() shrink the allocation and try
again if it fails, and then you *can* do __GFP_NOFAIL eventually.
The below attempts to implements this, along with converting the EINVAL cases
to WARN_ON().
I've refactored
On Wed, 23 May 2018, Linus Torvalds wrote:
One option is to make rhashtable_alloc() shrink the allocation and try
again if it fails, and then you *can* do __GFP_NOFAIL eventually.
The below attempts to implements this, along with converting the EINVAL cases
to WARN_ON().
I've refactored
On Wed, 23 May 2018, Linus Torvalds wrote:
On Wed, May 23, 2018 at 11:47 AM Davidlohr Bueso <d...@stgolabs.net> wrote:
Note that even if the allocation was guaranteed, there are still param
validations
and rhashtable_init() can return -EINVAL.
So?
It's not going to happen, because
On Wed, 23 May 2018, Linus Torvalds wrote:
On Wed, May 23, 2018 at 11:47 AM Davidlohr Bueso wrote:
Note that even if the allocation was guaranteed, there are still param
validations
and rhashtable_init() can return -EINVAL.
So?
It's not going to happen, because you're not going to give
On Wed, 23 May 2018, Linus Torvalds wrote:
So I'm perfectly fine with getting rid of 'tables_initialized'. But no, not
with a BUG_ON().
If you cannot guarantee that the allocation works (using __GFP_NOFAIL is
ok, for example - but it only works with small allocations), then you need
to handle
On Wed, 23 May 2018, Linus Torvalds wrote:
So I'm perfectly fine with getting rid of 'tables_initialized'. But no, not
with a BUG_ON().
If you cannot guarantee that the allocation works (using __GFP_NOFAIL is
ok, for example - but it only works with small allocations), then you need
to handle
On Wed, 23 May 2018, Davidlohr Bueso wrote:
I see two possible fixes.
I guess a third option would be to make the hashtable static, but I'm not
against using rhashtables so I'm not really considering this.
On Wed, 23 May 2018, Davidlohr Bueso wrote:
I see two possible fixes.
I guess a third option would be to make the hashtable static, but I'm not
against using rhashtables so I'm not really considering this.
Hi,
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70b (ipc: optimize semget/shmget/msgget for lots of keys).
It's there, specifically, to prevent nil pointer dereferences, from using an
uninitialized api. Considering how rhashtable_init() can fail
Hi,
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70b (ipc: optimize semget/shmget/msgget for lots of keys).
It's there, specifically, to prevent nil pointer dereferences, from using an
uninitialized api. Considering how rhashtable_init() can fail
ed-by: Matthew Wilcox <mawil...@microsoft.com>
Acked-by: Davidlohr Bueso <dbu...@suse.de>
rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
Acked-by: Davidlohr Bueso
On Thu, 10 May 2018, Vlastimil Babka wrote:
Can you add appropriate Fixes: tags if possible? I guess patch 1 is
clear, dunno about patch 2...
Right, patch 1 would still benefit from Fixes tag. As to patch 2, the bug
as been there since forever (pre-dates git history). But yeah, as both come
On Thu, 10 May 2018, Vlastimil Babka wrote:
Can you add appropriate Fixes: tags if possible? I guess patch 1 is
clear, dunno about patch 2...
Right, patch 1 would still benefit from Fixes tag. As to patch 2, the bug
as been there since forever (pre-dates git history). But yeah, as both come
ber in INIT_RHT_NULLS_HEAD.
Also move the locking initialization down to the end.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
lib/rhashtable.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 9427b5766134..68aadd6bff
ber in INIT_RHT_NULLS_HEAD.
Also move the locking initialization down to the end.
Signed-off-by: Davidlohr Bueso
---
lib/rhashtable.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 9427b5766134..68aadd6bff60 100644
--- a/
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
include/net/ip_tunnels.h | 4 ++--
net/ipv4/ip_tunnel_core
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Signed-off-by: Davidlohr Bueso
---
include/net/ip_tunnels.h | 4 ++--
net/ipv4/ip_tunnel_core.c | 6 +++---
2 files
against today's linux-next. Compile tested only.
[1] lkml.kernel.org/r/20180326210929.5244-1-d...@stgolabs.net
Thanks!
Davidlohr Bueso (6):
net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api
net/sock: Update memalloc_socks static key to modern api
net: Update [e/in]gress_needed
against today's linux-next. Compile tested only.
[1] lkml.kernel.org/r/20180326210929.5244-1-d...@stgolabs.net
Thanks!
Davidlohr Bueso (6):
net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api
net/sock: Update memalloc_socks static key to modern api
net: Update [e/in]gress_needed
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to generic_xdp_needed, for better self
documentation.
Signed-off-by: Davidlohr Bueso <
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to generic_xdp_needed, for better self
documentation.
Signed-off-by: Davidlohr Bueso
---
net/core
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to memalloc_socks, for better self
documentation.
Signed-off-by: Davidlohr Bueso <dbu...@suse
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to memalloc_socks, for better self
documentation.
Signed-off-by: Davidlohr Bueso
---
include/net
documentation.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
net/ipv4/udp.c | 8
net/ipv6/udp.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index dd3102a37ef9..ea86d8832340 100644
--- a/net/ipv4/udp.c
+++ b/ne
documentation.
Signed-off-by: Davidlohr Bueso
---
net/ipv4/udp.c | 8
net/ipv6/udp.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index dd3102a37ef9..ea86d8832340 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1873,10
No changes in semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to both ingress_needed and egress_needed,
for better self documentation.
Signed-off-by: Davidlohr Bueso <
No changes in semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to both ingress_needed and egress_needed,
for better self documentation.
Signed-off-by: Davidlohr Bueso
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to netstamp_needed, for better self
documentation.
Signed-off-by: Davidlohr Bueso <dbu...@suse
No changes in refcount semantics -- key init is false; replace
static_key_slow_inc|dec with static_branch_inc|dec
static_key_false with static_branch_unlikely
Added a '_key' suffix to netstamp_needed, for better self
documentation.
Signed-off-by: Davidlohr Bueso
---
net/core
, such cases will return -EINVAL.
Reported-by: Andrea Arcangeli <aarca...@redhat.com>
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
ipc/shm.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index b81d53c8f459..29978ee76c2e 1006
, such cases will return -EINVAL.
Reported-by: Andrea Arcangeli
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index b81d53c8f459..29978ee76c2e 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1371,9
relies on shmat(1, SHM_RND) for lowmem initialization[1].
[1]
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
Reported-by: Joe Lawrence <joe.lawre...@redhat.com>
Reported-by: Andrea Arcangeli <aarca...@redhat.com>
Signed-off-by: Davidloh
relies on shmat(1, SHM_RND) for lowmem initialization[1].
[1]
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
Reported-by: Joe Lawrence
Reported-by: Andrea Arcangeli
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 9 ++---
1 file changed, 2
] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
Thanks!
Davidlohr Bueso (2):
Revert "ipc/shm: Fix shmat mmap nil-page protection"
ipc/shm: fix shmat() nil address after round-down when remapping
ipc/shm.c | 19 +++
1 file changed, 11 insertions(+), 8
] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
Thanks!
Davidlohr Bueso (2):
Revert "ipc/shm: Fix shmat mmap nil-page protection"
ipc/shm: fix shmat() nil address after round-down when remapping
ipc/shm.c | 19 +++
1 file changed, 11 insertions(+), 8
On Mon, 25 Sep 2017, Andrea Arcangeli wrote:
Sorry this took so long guys. I had forgotten about this until it recently
resurfaced.
Hello,
On Mon, Sep 25, 2017 at 03:38:07PM -0400, Joe Lawrence wrote:
Hi Davidlohr,
I was looking into backporting commit 95e91b831f87 ("ipc/shm: Fix shmat
mmap
On Mon, 25 Sep 2017, Andrea Arcangeli wrote:
Sorry this took so long guys. I had forgotten about this until it recently
resurfaced.
Hello,
On Mon, Sep 25, 2017 at 03:38:07PM -0400, Joe Lawrence wrote:
Hi Davidlohr,
I was looking into backporting commit 95e91b831f87 ("ipc/shm: Fix shmat
mmap
ue 'sma->sems'
Avoid any possible speculation by using array_index_nospec() thus
ensuring the semnum value is bounded to [0, sma->sem_nsems). With
the exception of sem_lock() all of these are slowpaths.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
ipc/sem.c | 18 ++
1
ue 'sma->sems'
Avoid any possible speculation by using array_index_nospec() thus
ensuring the semnum value is bounded to [0, sma->sem_nsems). With
the exception of sem_lock() all of these are slowpaths.
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 18 ++
1 file changed, 14 ins
On Fri, 20 Apr 2018, Mike Galbraith wrote:
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
Is this similar to what we have in RT (which, IIRC, has an optimistic
spinning implementation as well)?
For the RT spinlock replacement, the top waiter can spin.
Yeah and the difference with
On Fri, 20 Apr 2018, Mike Galbraith wrote:
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
Is this similar to what we have in RT (which, IIRC, has an optimistic
spinning implementation as well)?
For the RT spinlock replacement, the top waiter can spin.
Yeah and the difference with
... we already use these for regular mutexes, rtmutex can
also use it, and while at it rename the whole thing since
this is specific to waiters.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
include/linux/poison.h | 4 ++--
kernel/locking/mutex-debug.c | 4 ++--
kernel/l
... we already use these for regular mutexes, rtmutex can
also use it, and while at it rename the whole thing since
this is specific to waiters.
Signed-off-by: Davidlohr Bueso
---
include/linux/poison.h | 4 ++--
kernel/locking/mutex-debug.c | 4 ++--
kernel/locking/rtmutex-debug.c | 4
the system]
url:
https://github.com/0day-ci/linux/commits/Davidlohr-Bueso/locking-rtmutex-Delete-save_state-member-of-struct-rt_mutex/20180411-155733
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
Ok.
sparse warnings: (new
the system]
url:
https://github.com/0day-ci/linux/commits/Davidlohr-Bueso/locking-rtmutex-Delete-save_state-member-of-struct-rt_mutex/20180411-155733
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
Ok.
sparse warnings: (new
the pi_stress program with increasing thread-group counts.
Signed-off-by: Davidlohr Bueso <db...@suse.de>
---
kernel/Kconfig.locks | 6 -
kernel/locking/rtmutex.c | 62 +++-
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/
the pi_stress program with increasing thread-group counts.
Signed-off-by: Davidlohr Bueso
---
kernel/Kconfig.locks | 6 -
kernel/locking/rtmutex.c | 62 +++-
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/kernel/Kconfig.locks b/kernel
ve regular rt_mutexes, thus we
can safely assume nothing will be done with this field anyway.
There is also the fact that this is under debug.
Signed-off-by: Davidlohr Bueso <dbu...@suse.de>
---
include/linux/rtmutex.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/rtmutex.h
ve regular rt_mutexes, thus we
can safely assume nothing will be done with this field anyway.
There is also the fact that this is under debug.
Signed-off-by: Davidlohr Bueso
---
include/linux/rtmutex.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/rtmutex.h b/include/linux/rtmut
>file = get_file(shp->shm_file);
sfd->vm_ops = NULL;
This probably merits a comment as it is adhoc to remap_file_pages(),
but otherwise:
Acked-by: Davidlohr Bueso <dbu...@suse.de>
>file = get_file(shp->shm_file);
sfd->vm_ops = NULL;
This probably merits a comment as it is adhoc to remap_file_pages(),
but otherwise:
Acked-by: Davidlohr Bueso
On Mon, 09 Apr 2018, Davidlohr Bueso wrote:
So I don't think the pointer is going anywhere, or am I missing
something?
Ah, yes, wrong pointer, this is sdf->file -- sorry for the noise.
On Mon, 09 Apr 2018, Davidlohr Bueso wrote:
So I don't think the pointer is going anywhere, or am I missing
something?
Ah, yes, wrong pointer, this is sdf->file -- sorry for the noise.
On Mon, 09 Apr 2018, Eric Biggers wrote:
It's necessary because if we don't hold a reference to sfd->file, then it can be
a stale pointer when we compare it in __shm_open(). In particular, if the new
struct file happened to be allocated at the same address as the old one, then
'sfd->file ==
On Mon, 09 Apr 2018, Eric Biggers wrote:
It's necessary because if we don't hold a reference to sfd->file, then it can be
a stale pointer when we compare it in __shm_open(). In particular, if the new
struct file happened to be allocated at the same address as the old one, then
'sfd->file ==
Commit-ID: adcc8da8859bee9548bb6d323b1e8de8a7252acd
Gitweb: https://git.kernel.org/tip/adcc8da8859bee9548bb6d323b1e8de8a7252acd
Author: Davidlohr Bueso <d...@stgolabs.net>
AuthorDate: Wed, 4 Apr 2018 09:15:39 -0700
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 5
Commit-ID: adcc8da8859bee9548bb6d323b1e8de8a7252acd
Gitweb: https://git.kernel.org/tip/adcc8da8859bee9548bb6d323b1e8de8a7252acd
Author: Davidlohr Bueso
AuthorDate: Wed, 4 Apr 2018 09:15:39 -0700
Committer: Ingo Molnar
CommitDate: Thu, 5 Apr 2018 09:20:46 +0200
sched/core: Simplify
Commit-ID: d29a20645d5e929aa7e8616f28e5d8e1c49263ec
Gitweb: https://git.kernel.org/tip/d29a20645d5e929aa7e8616f28e5d8e1c49263ec
Author: Davidlohr Bueso <d...@stgolabs.net>
AuthorDate: Mon, 2 Apr 2018 09:49:54 -0700
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 5
Commit-ID: d29a20645d5e929aa7e8616f28e5d8e1c49263ec
Gitweb: https://git.kernel.org/tip/d29a20645d5e929aa7e8616f28e5d8e1c49263ec
Author: Davidlohr Bueso
AuthorDate: Mon, 2 Apr 2018 09:49:54 -0700
Committer: Ingo Molnar
CommitDate: Thu, 5 Apr 2018 09:20:46 +0200
sched/rt: Fix rq
On Mon, 02 Apr 2018, Davidlohr Bueso wrote:
The case for the rt task throttling (which this workload also hits) can be
ignored in
that the skip_update call is actually bogus and quite the contrary (the request
bits
are removed/reverted).
While at it, how about this trivial patch?
8
501 - 600 of 4799 matches
Mail list logo
