, 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-off-b
and 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 have measured
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?
--
the 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
= ...
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
, the 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
ts, 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 match
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
, the 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.
_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: Pete
ake_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
---
ipc/mqueue.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/ipc/mqueue.c b/ipc
, to 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
---
kernel
bt 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 ag
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 +--
that the 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
_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: Pete
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
+++ b
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 about
>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
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
k 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
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 wr
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
riv->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 +---
=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?
I would
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...
git tree
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...
git tree
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
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
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
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
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
to 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
-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 | 10 --
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 49358f474fc9..38119c1f0da3 100644
--- a/ipc
to 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
-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 | 10 --
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 49358f474fc9..38119c1f0da3 100644
--- a/ipc
a pointer 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/
a pointer 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
=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
, 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
e
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_namespace.h | 1
e
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_namespace.h | 1
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 |
ersions.
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
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 |
ersions.
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
of 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
-mm/next?
I have not seen any issues in my tests.
--
Manfred
of 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 change nowarn
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 change nowarn
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 ac
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 ac
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
Cc: Davidlohr Bueso
---
ipc/msg.c | 19 ++-
ipc/sem.c | 18 +-
ipc/shm.c | 19 ++-
3
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
Cc: Davidlohr Bueso
---
ipc/msg.c | 19 ++-
ipc/sem.c | 18 +-
ipc/shm.c | 19 ++-
3
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
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
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
that it 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
that it 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
e
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_namespace.h | 1
e
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_namespace.h | 1
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
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
a pointer 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
1 - 100 of 1478 matches
Mail list logo
