, 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
Hi Eric,
On 3/4/21 2:12 AM, Andrew Morton wrote:
On Tue, 23 Feb 2021 23:11:43 +0800 Eric Gao wrote:
sometimes, we need the msgsnd or msgrcv syscall can return after a limited
time, so that the business thread do not be blocked here all the time. In
this case, I add the msgsnd_timed and
is always good, avoiding schedule() is always
good.
Thus I would start with pipelined_receive, and then we would need
feedback from apps that use sysv msg.
(old fakeroot is what I remember as test app)
On Wed, May 27, 2020 at 08:03:17AM +0200, Manfred Spraul wrote:
Hello Artur,
On 5/26/20 9:56
d receive.
On Sun, May 24, 2020 at 03:21:31PM +0200, Manfred Spraul wrote:
Hello Artur,
On 5/23/20 10:34 PM, Artur Barsegyan wrote:
Take into account the total size of the already enqueued messages of
previously handled senders before another one.
Otherwise, we have serious degradation of
Manfred
>From fe2f257b1950a19bf5c6f67e71aa25c2f13bcdc3 Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Sun, 24 May 2020 14:47:31 +0200
Subject: [PATCH 2/2] ipc/msg.c: Handle case of senders not enqueuing the
message
The patch "ipc/msg.c: wake up senders until there is a qu
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
Hello together,
On 4/28/20 1:14 PM, Matthew Wilcox wrote:
On Tue, Apr 28, 2020 at 03:47:36AM +, Wei Yongjun wrote:
The function ipc_id_alloc() is called from ipc_addid(), in which
a spin lock is held, so we should use GFP_ATOMIC instead.
Fixes: de5738d1c364 ("ipc: convert ipcs_idr to
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
Hi,
Updated series, based on input from Davidlohr and Peter Zijlstra:
- I've dropped the documentation update for wake_q_add, as what it
states is normal: When you call a function and pass a parameter
to a structure, you as caller are responsible to ensure that the
parameter is valid, and
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
Hi,
Updated series, based on input from Davidlohr:
- Mixing WRITE_ONCE(), when not holding a lock, and "normal" writes,
when holding a lock, makes the code less readable.
Thus use _ONCE() everywhere, for both WRITE_ONCE() and READ_ONCE().
- According to my understanding, wake_q_add() does
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
Hi,
Partially based on the findings from Waiman Long:
a) The memory barriers in ipc are not properly documented, and at least
for some architectures insufficient:
Reading the xyz->status is only a control barrier, thus
smp_acquire__after_ctrl_dep() was missing in mqueue.c and msg.c
sem.c
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
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 the wake_q code:
Questions:
- Does smp_mb__before_atomic() + a (failed) cmpxchg_relaxed provide an
ordering
Hi Waiman,
I have now written the mail 3 times:
Twice I thought that I found a race, but during further analysis, it
always turns out that the spin_lock() is sufficient.
First, to avoid any obvious things: Until the series with e.g.
27d7be1801a4824e, there was a race inside sem_lock().
Hi,
On 9/26/19 8:12 PM, Waiman Long wrote:
On 9/26/19 5:34 AM, Peter Zijlstra wrote:
On Fri, Sep 20, 2019 at 11:54:02AM -0400, Waiman Long wrote:
While looking at a customr bug report about potential missed wakeup in
the system V semaphore code, I spot a potential problem. The fact that
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
Hi Dmitry,
let's simplify the mail, otherwise noone can follow:
On 12/23/18 11:42 AM, Dmitry Vyukov wrote:
My naive attempts to re-reproduce this failed so far.
But I noticed that _all_ logs for these 3 crashes:
https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
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/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt
But this is working as intended,
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
continue to search, and then send a series with all findings.
--
Manfred
>From 733e888993b71fb3c139f71de61534bc603a2bcb Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Wed, 19 Dec 2018 09:26:48 +0100
Subject: [PATCH] ipc/sem.c: ensure proper locking during namespace teardown
free_i
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
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
Hi,
I have added all all review findings and rediffed the patches
- patch #1-#6: Fix syzcall findings & further race cleanups
patch #1 has an updated subject/comment
patch #2 contains the squashed result of Dmitrys change and my
own updates.
patch #6 is replaced
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,
I have added all all review findings and rediffed the patches
- patch #1-#6: Fix syzcall findings & further race cleanups
patch #1 has an updated subject/comment
patch #2 contains the squashed result of Dmitrys change and my
own updates.
patch #6 is replaced
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
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
-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
Hi,
I have merged the patches from Dmitry, Davidlohr and myself:
- patch #1-#6: Fix syzcall findings & further race cleanups
- patch #7: Cleanup from Dmitry for ipc_idr_alloc.
- patch #8-#11: rhashtable improvement from Davidlohr
- patch #12: Another cleanup for ipc_idr_alloc.
@Davidlohr:
-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
1 - 100 of 1250 matches
Mail list logo
