SHIFT, this could be a
loop over 16 million entries.
As there is no get_last() function for idr structures:
Implement a "get_last()" using a binary search.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
Signed-
msgrcv_timed syscall that with time
parameter, which has a unit of ms.
Please cc Manfred and Davidlohr on ipc/ changes.
The above is a very brief description for a new syscall! Please go to
great lengths to tell us why this is considered useful - what are the
use cases?
Also, please fully describe
Mein Name ist Manfred Koch, ich komme aus Deutschland und ich habe
eine Spende von 750.000,00 Euro für jeweils 3 Personen, entweder in
Deutschland, der Schweiz oder Österreich.
Kontaktieren Sie mich und ich werde Ihnen den Grund für mein Angebot
mitteilen.
MK
Hi Artus,
On 6/1/20 4:02 PM, Artur Barsegyan wrote:
Hi, Manfred.
Did you get my last message?
Yes, I'm just too busy right now.
My plan/backlog is:
- the xarray patch from Matthew
- improve finding max_id in ipc_rmid(). Perhaps even remove max_id
entirely and instead calculate
Hello Artur,
On 5/26/20 9:56 AM, Artur Barsegyan wrote:
Hello, Manfred!
Thank you, for your review. I've reviewed your patch.
I forgot about the case with different message types. At now with your patch,
a sender will force message consuming if that doesn't hold own capacity.
I hav
If now a receiver reads one message of type 1, then all 6 senders can send.
WIth your patch applied, only one sender sends the message to one
receiver, and the remaining 10 tasks continue to sleep.
Could you please check and (assuming that you agree) run your benchmarks
with the patch applied?
documentation.
Signed-off-by: Manfred Spraul
---
include/linux/xarray.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/xarray.h b/include/linux/xarray.h
index d79b8e3aa08d..2815c4ec89b1 100644
--- a/include/linux/xarray.h
+++ b/include/linux/xarray.h
@@ -576,7 +576,7
w->seq = ...
spin_lock();
xa_store(,entry=new,GFP_KERNEL);
--
Manfred
Hello,
On 10/21/19 10:35 AM, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 6394de3b868537a90dd9128607192b0e97109f6b ("[PATCH 4/5] ipc/sem.c: Document
and update memory barriers")
url:
https://github.com/0day-ci/linux/commits/Manfred-Spr
n another wake_q.
Then:
- CPU1: spin_unlock() of the task that goes to sleep is the RELEASE
- 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: Manfr
Add comments to all barriers, and mention the rules in the block
regarding locking.
- Switch to using wake_q_add_safe().
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/sem.c | 66 ++-
1 file changed, 41 insertions(+),
Patch from Davidlohr, I just added this change log.
pipelined_send() and pipelined_receive() are identical, so merge them.
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/mqueue.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff
refount
may have been decreased to 0 already when wake_q_add()
tries to get a reference.
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/msg.c | 43 ---
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/ipc/msg.c b
ting. I did some tests, but doubt that the tests would be
sufficient to show issues with regards to incorrect memory barriers.
What do you think?
--
Manfred
sentences.
Fixes: 654672d4ba1a ("locking/atomics: Add _{acquire|release|relaxed}()
variants of some atomic operations")
Signed-off-by: Manfred Spraul
Acked-by: Waiman Long
Cc: Davidlohr Bueso
Cc: Peter Zijlstra
Cc: Will Deacon
---
Documentation/memory-barriers.txt | 16 ++
Hi Peter,
On 10/14/19 3:58 PM, Peter Zijlstra wrote:
On Mon, Oct 14, 2019 at 02:59:11PM +0200, Peter Zijlstra wrote:
On Sat, Oct 12, 2019 at 07:49:55AM +0200, Manfred Spraul wrote:
for (;;) {
+ /* memory barrier not required, we hold info->l
Hello Peter,
On 10/14/19 3:03 PM, Peter Zijlstra wrote:
On Sat, Oct 12, 2019 at 07:49:58AM +0200, Manfred Spraul wrote:
The documentation in memory-barriers.txt claims that
smp_mb__{before,after}_atomic() are for atomic ops that do not return a
value.
This is misleading and doesn't matc
Patch entirely from Davidlohr:
pipelined_send() and pipelined_receive() are identical, so merge them.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
ipc/mqueue.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/ipc/mqueue.c b/ipc
refount
may have been decreased to 0 already when wake_q_add()
tries to get a reference.
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/msg.c | 44 ++--
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/ipc/msg.c b
Add comments to all barriers, and mention the rules in the block
regarding locking.
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/sem.c | 63 ---
1 file changed, 51 insertions(+), 12 deletions(-)
diff --git a/ipc/sem.
tomic_add();
2)
smp_mb__before_atomic();
atomic_xchg_relaxed();
3)
smp_mb__before_atomic();
atomic_fetch_add_relaxed();
Invalid would be:
smp_mb__before_atomic();
atomic_set();
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
Cc:
() 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
---
ipc/mqueue.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/ipc/mqueue.c b/ipc
simplify searching.
4) wake_q.next is accessed without synchroniyation by wake_q_add(),
using cmpxchg_relaxed(), and by wake_up_q().
Therefore: Use WRITE_ONCE in wake_up_q(), to ensure that the
compiler doesn't perform any tricks.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
k
that the tests would be
sufficient to show issues with regards to incorrect memory barriers.
- Should I add a "Fixes:" or "Cc:stable"? The issues that I see are
the missing smp_mb__after_ctrl_dep(), and WRITE_ONCE() vs.
"ptr = NULL", and a risk regarding the refcount that I can't evaluate.
What do you think?
--
Manfred
On 10/11/19 6:55 PM, Davidlohr Bueso wrote:
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 t
add()
- document why __set_current_state() may be used:
Reading task->state cannot happen before the wake_q_add() call,
which happens while holding info->lock.
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/mqueue.c | 32 +--
code relies
on the barrier inside wake_q_add().
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/msg.c | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 8dec945fa030..1e2c0a3d4998
D_ONCE & WRITE_ONCE for the situations where spinlocks
provide exclusion.
- Add comments to all barriers, and mention the rules in the block
regarding locking.
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
---
ipc/sem.c | 64
tomic_add();
2)
smp_mb__before_atomic();
atomic_xchg_relaxed();
3)
smp_mb__before_atomic();
atomic_fetch_add_relaxed();
Invalid would be:
smp_mb__before_atomic();
atomic_set();
Signed-off-by: Manfred Spraul
Cc: Waiman Long
Cc: Davidlohr Bueso
Cc:
issues with regards to incorrect memory barriers.
- Should I add a "Fixes:" or "Cc:stable"? The only issues that I see are
the missing smp_mb__after_ctrl_dep(), and WRITE_ONCE() vs.
"ptr = NULL".
What do you think?
--
Manfred
doesn't perform any tricks.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
kernel/sched/core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dd05a378631a..2cf3f7321303 100644
--- a/kernel/sched/core.c
Hi Davidlohr,
On 10/10/19 9:25 PM, Davidlohr Bueso wrote:
On Thu, 10 Oct 2019, Peter Zijlstra wrote:
On Thu, Oct 10, 2019 at 02:13:47PM +0200, Manfred Spraul wrote:
Therefore smp_mb__{before,after}_atomic() may be combined with
cmpxchg_relaxed, to form a full memory barrier, on all archs
Hi Peter,
On 10/10/19 1:42 PM, Peter Zijlstra wrote:
On Thu, Oct 10, 2019 at 12:41:11PM +0200, Manfred Spraul wrote:
Hi,
Waiman Long noticed that the memory barriers in sem_lock() are not really
documented, and while adding documentation, I ended up with one case where
I'm not certain
smp_mb__after_spinlock()
if(1234->state = TASK_RUNNING) return;
>
rewritten:
start condition: A = 1; B = 0;
CPU1:
B = 1;
RELEASE, unlock LockX;
CPU2:
lock LockX, ACQUIRE
if (LOAD A == 1) return; /* using cmp_xchg_relaxed */
CPU2:
A = 0;
ACQUIRE, lock LockY
smp_mb__after_spinlock();
READ B
Question: is A = 1, B = 0 possible?
--
Manfred
set_current_state();
check_conditions();
unlock();
schedule();
I don't see a race anymore, and I don't see how the proposed change will
help.
e.g.: __set_current_state() and smp_mb() have paired memory barriers
***1 and ***2 above.
--
Manfred
sma->sem_perm);
Anyway, I do think we need to add some comment to clarify the situation
to avoid future confusion.
Around line 190 is the comment that explains locking & memory ordering.
I have only documented the content of sem_undo and sem_array, but
neither queue nor current->state :-(
--
Manfred
On 2/27/19 9:30 PM, Waiman Long wrote:
On 11/20/2018 02:41 PM, Manfred Spraul wrote:
From 6bbade73d21884258a995698f21ad3128df8e98a Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Sat, 29 Sep 2018 15:43:28 +0200
Subject: [PATCH 2/2] ipc/util.c: use idr_alloc_cyclic() for ipc allocations
A
On 1/3/19 11:18 PM, Shakeel Butt wrote:
Hi Manfred,
On Sun, Dec 23, 2018 at 4:26 AM Manfred Spraul wrote:
Hello Dmitry,
On 12/23/18 10:57 AM, Dmitry Vyukov wrote:
I can reproduce this infinite memory consumption with the C program:
https://gist.githubusercontent.com/dvyukov
Manfred Schlaegl | Leitung Entwicklung Linz
GINZINGER ELECTRONIC SYSTEMS GMBH
Tel.: +43 7723 5422 153
Mobil: +43 676 841 208 253
Mail: manfred.schla...@ginzinger.com
Web: www.ginzinger.com
On 04.01.19 16:23, Marc Kleine-Budde wrote:
> On 12/19/18 7:39 PM, Manfred Schlaegl wrote:
>
fers under oom pressure?
- kvmalloc can fall back to vmalloc()
- the 2nd or 3rd of multiple allocations can fail, and that triggers a
rare codepath/race condition.
- rcu callback can happen earlier that expected
So far, I didn't notice anything unexpected :-(
--
Manfred
e.: a new
namespace "inherits" a fraction of the parent namespaces memory limits),
but this we more or less always wrong.
--
Manfred
Hi Dmitry,
On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
wrote:
Hello Dmitry,
On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
On Tue, Dec 11, 2018 at 9:23 PM syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD commit:f5d582777bcb
set
priv->echo_skb[idx]. It is therefore kept NULL.
(As additional argument for revert: The order of check and usage of idx
was changed. idx is used to access an array element before checking it's
boundaries)
Signed-off-by: Manfred Schlaegl
---
drivers/net/can/dev.c | 27 +-
epro.syz?x=16803afb40
+Manfred, this looks similar to the other few crashes related to
semget$private(0x0, 0x4000, 0x3f) that you looked at.
I found one unexpected (incorrect?) locking, see the attached patch.
But I doubt that this is the root cause of the crashes.
Any remarks on the patch
Hi Dmitry,
On 11/30/18 6:58 PM, Dmitry Vyukov wrote:
On Thu, Nov 29, 2018 at 9:13 AM, Manfred Spraul
wrote:
Hello together,
On 11/27/18 4:52 PM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel..
Acked-by: Manfred Rudigier
Regards,
Manfred
> -Original Message-
> From: Richard Cochran
> Sent: Thursday, November 1, 2018 3:12 AM
> To: Thomas Gleixner
> Cc: LKML ; Cristian Marinescu
> ; Manfred Rudigier
>
> Subject: Re: [patch 8/9] posix-clocks: Rem
On 10/2/18 8:27 PM, Waiman Long wrote:
On 10/02/2018 12:19 PM, Manfred Spraul wrote:
A bit related to the patch series that increases IPC_MNI:
(User space) id reuse create the risk of data corruption:
Process A: calls ipc function
Process A: sleeps just at the beginning of the syscall
Process
ids.
Signed-off-by: Manfred Spraul
---
Open questions:
- Is there a significant performance advantage, especially
there are many ipc ids?
- Over how many ids should the code cycle always?
- Further review remarks?
ipc/util.c | 22 +-
1 file changed, 21 insertions(+), 1
Hello Davidlohr,
On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
What is the background of the
finding of
syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com:
syzbot found an issue with kern_ipc_perm.seq
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Reviewed-by: Davidlohr Bueso
---
ipc/msg.c | 19 ++-
ipc/sem.c | 18 +-
ipc/shm.c | 19
: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 ++
ipc/util.c | 10 --
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 49358f474fc9..38119c1f0da3 100644
--- a/ipc
ter in the idr, without
acquiring the object lock.
- The caller is responsible for locking.
- _check means that the sequence number is checked.
Signed-off-by: Manfred Spraul
Reviewed-by: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 +-
ipc/util.c | 8
ipc/
=true may disappear at
the end of the next rcu grace period.
Signed-off-by: Manfred Spraul
Reviewed-by: Davidlohr Bueso
---
ipc/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index cffd12240f67..5cc37066e659 100644
--- a/ipc/util.c
+++ b/ipc
, we
can simply move the logic into shm_lock() and get rid of the
function altogether.
[changelog mostly by manfred]
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/shm.c | 29 +++--
ipc/util.c | 36
ipc/util.h
resizing (when more memory becomes available) is the least
of our problems.
Signed-off-by: Davidlohr Bueso
Acked-by: Herbert Xu
Signed-off-by: Manfred Spraul
---
lib/rhashtable.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
a
positive consequence as for the same reasons we want nowarn semantics in
bucket_table_alloc().
Signed-off-by: Davidlohr Bueso
Acked-by: Michal Hocko
(commit id extended to 12 digits, line wraps updated)
Signed-off-by: Manfred Spraul
---
lib/rhashtable.c | 7 ++-
1 file changed, 2 insert
c structure
isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly
get rid of the hack altogether.
Signed-off-by: Davidlohr Bueso
(commit id extended to 12 digits)
Signed-off-by: Manfred Spraul
---
include/linux/ipc_na
From: Davidlohr Bueso
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
(variable name added to util.h to resolve checkpatch warning)
Signed-off-by: Manfred Spraul
---
ipc
e variable name.
seq: sequence number, to avoid quick collisions of the user space id
key: user space key, used for the rhash tree
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
---
include/linux/ipc_namespace.h | 2 +-
ipc/msg.c | 6 +++---
ipc/sem.c |
ions.
Signed-off-by: Manfred Spraul
---
ipc/util.c | 2 +-
ipc/util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index fb69c911655a..6306eb25180b 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -461,7 +461,7 @@ void ipc_set_key_private(struct
-mm/next?
I have not seen any issues in my tests.
--
Manfred
ipc_addid()
do not fullfill that, i.e. more bugfixes are required.
The patch is a squash of a patch from Dmitry and my own changes.
Reported-by: syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Michael
Hi Davidlohr,
On 07/09/2018 10:09 PM, Davidlohr Bueso wrote:
On Mon, 09 Jul 2018, Manfred Spraul wrote:
@Davidlohr:
Please double check that I have taken the correct patches, and
that I didn't break anything.
Everything seems ok.
Patch 8 had an alternative patch that didn't cha
Hello Dmitry,
On 07/09/2018 07:05 PM, Dmitry Vyukov wrote:
On Mon, Jul 9, 2018 at 5:10 PM, Manfred Spraul wrote:
If idr_alloc within ipc_idr_alloc fails, then the return value (-ENOSPC)
is used to calculate new->id.
Technically, this is not a bug, because new->id is never accessed
syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com:
syzbot found an issue with kern_ipc_perm.seq
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
---
ipc/msg.c | 19 ++-
ipc/sem.c | 18 +-
ipc/shm.c | 19 ++-
3
From: Dmitry Vyukov
ipc_idr_alloc refactoring
Signed-off-by: Dmitry Vyukov
Signed-off-by: Manfred Spraul
---
ipc/util.c | 51 +--
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index 8bc166bb4981
resizing (when more memory becomes available) is the least
of our problems.
Signed-off-by: Davidlohr Bueso
Acked-by: Herbert Xu
Signed-off-by: Manfred Spraul
---
lib/rhashtable.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
a
positive consequence as for the same reasons we want nowarn semantics in
bucket_table_alloc().
Signed-off-by: Davidlohr Bueso
Acked-by: Michal Hocko
(commit id extended to 12 digits, line wraps updated)
Signed-off-by: Manfred Spraul
---
lib/rhashtable.c | 7 ++-
1 file changed, 2 insert
does not check the sequence counter.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
ipc/shm.c | 4 ++--
ipc/util.c | 10 ++
ipc/util.h | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index 426ba1039a7b..cd8655c7bb77 100644
--- a/ipc
c structure
isn't found, and can therefore call into ipcget() callbacks.
Now that rhashtable initialization cannot fail, we can properly
get rid of the hack altogether.
Signed-off-by: Davidlohr Bueso
(commit id extended to 12 digits)
Signed-off-by: Manfred Spraul
---
include/linux/ipc_na
From: Davidlohr Bueso
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
(variable name added to util.h to resolve checkpatch warning)
Signed-off-by: Manfred Spraul
---
ipc
ter in the idr, without
acquiring the object lock.
- The caller is responsible for locking.
- _check means that the sequence number is checked.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 +-
ipc/util.c | 8
ipc/util.h | 2 +
If idr_alloc within ipc_idr_alloc fails, then the return value (-ENOSPC)
is used to calculate new->id.
Technically, this is not a bug, because new->id is never accessed.
But: Clean it up anyways: On error, just return, do not set new->id.
And improve the documentation.
Signed-off-by
: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 ++
ipc/util.c | 12 ++--
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 829c2062ded4..5bf5cb8017ea 100644
--- a/ipc
seen any issues in my tests.
--
Manfred
=true may disappear at
the end of the next rcu grace period.
Signed-off-by: Manfred Spraul
Cc: Davidlohr Bueso
---
ipc/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index bbb1ce212a0d..8133f10832a9 100644
--- a/ipc/util.c
+++ b/ipc/util.c
not fullfill that, i.e. more bugfixes are required.
Reported-by: syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Michael Kerrisk
---
Documentation/sysctl/kernel.txt | 3 ++-
ipc/util.c
Hi Dmitry,
On 07/05/2018 10:36 AM, Dmitry Vyukov wrote:
[...]
Hi Manfred,
The series looks like a significant improvement to me. Thanks!
I feel that this code can be further simplified (unless I am missing
something here). Please take a look at this version:
https://github.com/dvyukov/linux
: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 ++
ipc/util.c | 12 ++--
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 829c2062ded4..5bf5cb8017ea 100644
--- a/ipc
not fullfill that, i.e. more bugfixes are required.
Reported-by: syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Michael Kerrisk
Signed-off-by: Manfred Spraul
---
Documentation/sysctl/kernel.txt | 3
=true may disappear at
the end of the next rcu grace period.
Signed-off-by: Manfred Spraul
---
ipc/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index 4f2db913acf9..776a9ce2905f 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -646,8 +646,8
ter in the idr, without
acquiring the object lock.
- The caller is responsible for locking.
- _check means that some checks are made.
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 2 +-
ipc/sem.c | 2 +-
ipc/shm.c | 2 +-
ipc/util.c | 6 +++---
ipc/util.h | 2 +-
5 files changed, 7 insert
does not check the sequence counter.
Signed-off-by: Manfred Spraul
---
ipc/shm.c | 4 ++--
ipc/util.c | 10 ++
ipc/util.h | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index 426ba1039a7b..cd8655c7bb77 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com:
syzbot found an issue with kern_ipc_perm.seq
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 19 ++-
ipc/sem.c | 18 +-
ipc/shm.c
t-in-ipc_obtain_object_che
Comment correction from code review
The patches are lightly tested, especially I have not tested
the checkpoint/restore code or tested the failure cases.
--
Manfred
Hello Dmitry,
On 07/04/2018 12:03 PM, Dmitry Vyukov wrote:
On Wed, Jul 4, 2018 at 11:18 AM, Manfred Spraul
wrote:
There are 2 relevant values: kern_ipc_perm.id and kern_ipc_perm.seq.
For kern_ipc_perm.id, it is possible to move the access to the codepath that
hold the lock.
For
The ipc code uses the equivalent of
rcu_read_lock();
kfree_rcu(a, rcu);
if (a->deleted) {
rcu_read_unlock();
return FAILURE;
}
<...>
Is this safe, or is dereferencing "a" after having called call_rcu()
a use-after-free?
Acco
oyed, then the newly created object has
temporarily sequence number 0 as well.
--
Manfred
>From 4791e604dcb618ed7ea1f42b2f6ca9cfe3c113c3 Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Wed, 4 Jul 2018 10:04:49 +0200
Subject: [PATCH] ipc: fix races with kern_ipc_perm.id and .seq
o medium cpu usage (no more than ~8 processes on a 40 core box) in a non
trivial way. For more processes it doesn't matter. We can confirm that
the
case for threads is irrelevant. While I'm not happy about the 30%
regression
I guess we can live with this.
Manfred, any thoughts?
Hello Mathew,
On 03/29/2018 12:56 PM, Matthew Wilcox wrote:
On Thu, Mar 29, 2018 at 10:47:45AM +0200, Manfred Spraul wrote:
This can be implemented trivially with the current code
using idr_alloc_cyclic.
Is there a performance impact?
Right now, the idr tree is only large if there are lots of
Hello together,
On 03/29/2018 04:14 AM, Davidlohr Bueso wrote:
Cc'ing mtk, Manfred and linux-api.
See below.
On Thu, 15 Mar 2018, Waiman Long wrote:
On 03/15/2018 03:00 PM, Eric W. Biederman wrote:
Waiman Long writes:
On 03/14/2018 08:49 PM, Eric W. Biederman wrote:
The define I
ce.
To solve this, we simply remove the double-check, which is a paranoia
check anyways.
The modification was intensively tested on i.MX6 with linux-4.1, Winbond
W29N04GV and Micron MT29F4G08ABADAH4.
Signed-off-by: Manfred Schlaegl
---
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c | 9 +
1 f
om smp_load_acquire()
> typeof(*p) ___p1 = READ_ONCE(*p); \
I don't see how ___p1 could be used uninitialized. Perhaps a compiler issue?
--
Manfred
.
Unfortunately, I don't have any reproducer for this bug yet.
Is one of the recent issues reproducible?
Either something is wrong with the faster ipc_get, or the improved
ipc_get makes issues in other areas visible.
--
Manfred
duced. The changelog is really modest on information or
intention but I suspect this just got overlooked during review. SHM_STAT
has always been about read permission and it is explicitly documented
that way.
Are you sure that this patch changed the behavior?
The proc interface is much older.
--
Manfred
Hi,
On 12/01/2017 06:20 PM, Davidlohr Bueso wrote:
On Thu, 30 Nov 2017, Philippe Mikoyan wrote:
As described in the title, this patch fixes id_ds inconsistency
when ctl_stat runs concurrently with some ds-changing function,
e.g. shmat, msgsnd or whatever.
For instance, if shmctl(IPC_STAT) is
Hi Alan,
On 07/08/2017 06:21 PM, Alan Stern wrote:
Pardon me for barging in, but I found this whole interchange extremely
confusing...
On Sat, 8 Jul 2017, Ingo Molnar wrote:
* Paul E. McKenney wrote:
On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:
* Manfred Spraul wrote
o use spin_lock()/spin_unlock().
--
Manfred
Hi Paul,
On 07/06/2017 01:31 AM, Paul E. McKenney wrote:
From: Manfred Spraul
As we want to remove spin_unlock_wait() and replace it with explicit
spin_lock()/spin_unlock() calls, we can use this to simplify the
locking.
In addition:
- Reading nf_conntrack_locks_all needs ACQUIRE memory
can test this?
semop() has a very short hotpath.
Either with aim9.shared_memory.ops_per_sec or
#sem-scalebench -t 10 -m 0
https://github.com/manfred-colorfu/ipcscale/blob/master/sem-scalebench.cpp
--
Manfred
>From b549e0281b66124b62aa94543f91b0e616abaf52 Mon Sep 17 00:00:00 2001
From: Manf
1 - 100 of 771 matches
Mail list logo
