ipc: delete seq_max field in struct ipc_ids
Acked-by: Manfred Spraul
ipc: share ids rwsem when possible in ipcget_public
This patch is a real change. Could you at least make it the last one in
the series?
I will try to review it, but I don't know yet when I will find the time.
ipc,msg
ipc: delete seq_max field in struct ipc_ids
Acked-by: Manfred Spraul manf...@colorfullife.com
ipc: share ids rwsem when possible in ipcget_public
This patch is a real change. Could you at least make it the last one in
the series?
I will try to review it, but I don't know yet when I will find
of additional space_before_tab that were not found by --fix
diff -w is empty.
Tested with some of my msg and sem test apps.
Andrew: Could you include it in -mm and move it towards Linus' tree?
Signed-off-by: Manfred Spraul
Suggested-by: Li Bin
Cc: Joe Perches
Cc: linux-kernel@vger.kernel.org
of additional space_before_tab that were not found by --fix
diff -w is empty.
Tested with some of my msg and sem test apps.
Andrew: Could you include it in -mm and move it towards Linus' tree?
Signed-off-by: Manfred Spraul manf...@colorfullife.com
Suggested-by: Li Bin huawei.li...@huawei.com
Cc
) - unless it collides with something you plan.
--
Manfred
>From 06359c767e3fb5e966efa4653f1db4f6d977da36 Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Mon, 23 Dec 2013 11:03:39 +0100
Subject: [PATCH] ipc: whitespace cleanup
The ipc code does not adhere the typical linux coding st
) - unless it collides with something you plan.
--
Manfred
From 06359c767e3fb5e966efa4653f1db4f6d977da36 Mon Sep 17 00:00:00 2001
From: Manfred Spraul manf...@colorfullife.com
Date: Mon, 23 Dec 2013 11:03:39 +0100
Subject: [PATCH] ipc: whitespace cleanup
The ipc code does not adhere the typical
led with kern_ipc_perm.lock held -- exception made for one
+ * checkpoint case at sys_semtimedop() as noted in code commentary.
*/
static inline bool ipc_valid_object(struct kern_ipc_perm *perm)
{
---
Do we need to change somthing else?
Looking forward your thoughts!
Acked-by: Manfred Spr
ct(>shm_perm)) {
ipc_unlock_object(>shm_perm);
err = -EIDRM;
goto out_unlock;
Please mention the change from "shm_file == NULL" to perm.deleted in the
changelog.
With regards to the impact of this change: No idea, I've never worked on
the shm code.
--
worked on
the shm code.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
with kern_ipc_perm.lock held -- exception made for one
+ * checkpoint case at sys_semtimedop() as noted in code commentary.
*/
static inline bool ipc_valid_object(struct kern_ipc_perm *perm)
{
---
Do we need to change somthing else?
Looking forward your thoughts!
Acked-by: Manfred Spraul manf
be added for
3.14, i.e. let's give the code one more cycle to calm down.
Grek just sent me 47 patches for the backport to 3.10-stable, I don't
want any whitespace noise right now.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
be that the checkpatch -f patch should be added for
3.14, i.e. let's give the code one more cycle to calm down.
Grek just sent me 47 patches for the backport to 3.10-stable, I don't
want any whitespace noise right now.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
deleted, thus no additional
test is required.
Davidlohr: What do you think?
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 8c4f59b..db9d241 100644
--- a/ipc/se
no additional
test is required.
Davidlohr: What do you think?
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 8c4f59b..db9d241 100644
Hi Davidlohr,
On 09/30/2013 07:54 PM, Davidlohr Bueso wrote:
Hi Manfred,
On Mon, 2013-09-30 at 11:13 +0200, Manfred Spraul wrote:
After acquiring the semlock spinlock, the operations must test that the
array is still valid.
- semctl() and exit_sem() would walk stale linked lists (ugly
review much harder.
Davidlohr: Could you please review the patch?
I did some stress test, but probably I didn't hit exactly the modified
lines.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 43 ++-
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git
you please review the patch?
I did some stress test, but probably I didn't hit exactly the modified
lines.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 43 ++-
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/ipc/sem.c
Hi Davidlohr,
On 09/30/2013 07:54 PM, Davidlohr Bueso wrote:
Hi Manfred,
On Mon, 2013-09-30 at 11:13 +0200, Manfred Spraul wrote:
After acquiring the semlock spinlock, the operations must test that the
array is still valid.
- semctl() and exit_sem() would walk stale linked lists (ugly
are preempted before acquiring the kern_ipc_perm.lock.
Manfred illustrates this nicely:
Assume a preemptible kernel that is preempted just after
msq = msq_obtain_object_check(ns, msqid)
in do_msgrcv().
The only lock that is held is rcu_read_lock().
Now the other thread processes IPC_RMID.
When the first
your patch change that?
Unfortunately, I have neither any experience with ipc/shm nor any test
cases.
And:
As far as I can see it's not a problem if we are attaching to a deleted
segment: shm_close cleans up everything.
--
Manfred
--
To unsubscribe from this list: send the line "unsubs
your patch change that?
Unfortunately, I have neither any experience with ipc/shm nor any test
cases.
And:
As far as I can see it's not a problem if we are attaching to a deleted
segment: shm_close cleans up everything.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe
are preempted before acquiring the kern_ipc_perm.lock.
Manfred illustrates this nicely:
Assume a preemptible kernel that is preempted just after
msq = msq_obtain_object_check(ns, msqid)
in do_msgrcv().
The only lock that is held is rcu_read_lock().
Now the other thread processes IPC_RMID.
When the first
() and semtimedop())
--
Manfred
In commit 0a2b9d4c,the update of semaphore's sem_otime(last semop time)
was moved to one central position (do_smart_update).
But: Since do_smart_update() is only called for operations that modify
the array, this means that wait-for-zero semops do not update
.
But it is dangerous and therefore should be fixed.
Andrew:
- Could you include the patch in -mm and push it towards Linus?
- The patch depends on ipc-semc-fix-race-in-sem_lock.patch
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 8
1 file changed, 8 insertions(+)
diff --git a/ipc/sem.c b/ipc
Hi Jia,
On 09/25/2013 05:05 AM, Jia He wrote:
Hi Manfred
IIUC after reivewing your patch and src code, does it seem
sem_otime lost the chance to be updated when calling
semctl_main/semctl_setval?
In old codes, even whendo_smart_update(sma, NULL, 0, 0, ),
the otime can be updated after several
Hi Jia,
On 09/25/2013 05:05 AM, Jia He wrote:
Hi Manfred
IIUC after reivewing your patch and src code, does it seem
sem_otime lost the chance to be updated when calling
semctl_main/semctl_setval?
In old codes, even whendo_smart_update(sma, NULL, 0, 0, tasks),
the otime can be updated after
.
But it is dangerous and therefore should be fixed.
Andrew:
- Could you include the patch in -mm and push it towards Linus?
- The patch depends on ipc-semc-fix-race-in-sem_lock.patch
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 8
1 file changed, 8 insertions(+)
diff
() and semtimedop())
--
Manfred
In commit 0a2b9d4c,the update of semaphore's sem_otime(last semop time)
was moved to one central position (do_smart_update).
But: Since do_smart_update() is only called for operations that modify
the array, this means that wait-for-zero semops do not update
On 09/22/2013 05:14 PM, Jia He wrote:
Hi Manfred
On Sun, 22 Sep 2013 12:42:05 +0200 from manf...@colorfullife.com wrote:
Hi all,
On 09/22/2013 10:26 AM, Mike Galbraith wrote:
On Sun, 2013-09-22 at 10:17 +0200, Mike Galbraith wrote:
On Sun, 2013-09-22 at 10:11 +0800, Jia He wrote
,shm]_free_security(), we can race
if the structure is freed before other tasks are done with it, creating a
use-after-free condition. Manfred illustrates this nicely, for instance with
shared mem and selinux:
--> do_shmat calls rcu_read_lock()
--> do_shmat calls shm_object_check().
Ch
Hi Linus,
On 09/24/2013 03:22 AM, Linus Torvalds wrote:
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso wrote:
Ok, so here's the code - again I've tested it with LTP on the resources
I have.
This looks good to me.
Manfred, mind giving this a look-over and see if this resolves your
race
Hi Linus,
On 09/24/2013 03:22 AM, Linus Torvalds wrote:
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso davidl...@hp.com wrote:
Ok, so here's the code - again I've tested it with LTP on the resources
I have.
This looks good to me.
Manfred, mind giving this a look-over and see
]_free_security(), we can race
if the structure is freed before other tasks are done with it, creating a
use-after-free condition. Manfred illustrates this nicely, for instance with
shared mem and selinux:
-- do_shmat calls rcu_read_lock()
-- do_shmat calls shm_object_check().
Checks that the object
On 09/22/2013 05:14 PM, Jia He wrote:
Hi Manfred
On Sun, 22 Sep 2013 12:42:05 +0200 from manf...@colorfullife.com wrote:
Hi all,
On 09/22/2013 10:26 AM, Mike Galbraith wrote:
On Sun, 2013-09-22 at 10:17 +0200, Mike Galbraith wrote:
On Sun, 2013-09-22 at 10:11 +0800, Jia He wrote
the
sysv standard.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, make sure we hold the kern_ipc_perm.lock while
performing these security checks.
Actually: either kern_ipc_perm or down_xx(_ids(ns).rwsem) is sufficient.
Reported-by: Manfred Spraul
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 23 ++-
1 file changed, 14 insertions(+), 9
, make sure we hold the kern_ipc_perm.lock while
performing these security checks.
Actually: either kern_ipc_perm or down_xx(shm_ids(ns).rwsem) is sufficient.
Reported-by: Manfred Spraul manf...@colorfullife.com
Signed-off-by: Davidlohr Bueso davidl...@hp.com
---
ipc/shm.c | 23
Hi all,
On 09/15/2013 08:09 AM, Mike Galbraith wrote:
On Sat, 2013-09-14 at 23:34 +0200, Manfred Spraul wrote:
The bug is probably also present in 3.10 and 3.11, but for these kernels
is is probably simpler just to move the test of sma->complex_count after
the spin_is_locked() test.
I
Hi all,
On 09/15/2013 08:09 AM, Mike Galbraith wrote:
On Sat, 2013-09-14 at 23:34 +0200, Manfred Spraul wrote:
The bug is probably also present in 3.10 and 3.11, but for these kernels
is is probably simpler just to move the test of sma-complex_count after
the spin_is_locked() test.
IMHO
n't know if it should go into linux-next first.
Signed-off-by: Manfred Spraul
Cc: Mike Galbraith
Cc: Rik van Riel
Cc: Davidlohr Bueso
Cc: Andrew Morton
---
ipc/sem.c | 8
1 file changed, 8 insertions(+)
diff --git a/ipc/sem.c b/ipc/sem.c
index 4836ea7..5274ed1 100644
--- a/ipc/se
have to wait for the global lock to be released.
*/
if (unlikely(spin_is_locked(>sem_perm.lock))) {
spin_unlock(>lock);
spin_unlock_wait(>sem_perm.lock);
goto again;
}
))) {
spin_unlock(sem-lock);
spin_unlock_wait(sma-sem_perm.lock);
goto again;
}
sem_perm.lock already dropped, thus no goto again;
locknum = sops-sem_num;
Signed-off-by: Manfred Spraul manf...@colorfullife.com
Cc: Mike
know if it should go into linux-next first.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
Cc: Mike Galbraith bitbuc...@online.de
Cc: Rik van Riel r...@redhat.com
Cc: Davidlohr Bueso davidlohr.bu...@hp.com
Cc: Andrew Morton a...@linux-foundation.org
---
ipc/sem.c | 8
1 file
Hi all,
On 09/12/2013 02:20 PM, Manfred Spraul wrote:
And: What about the other users of obtain_object_check?
exit_sem() is also quite long, but I didn't spot any obvious problems.
a) I think semtimed(), msgsnd() and msgrcv() must be fixed:
They either leak memory or tasks can sleep forever
lysis correct?
And: What about the other users of obtain_object_check?
exit_sem() is also quite long, but I didn't spot any obvious problems.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
about the other users of obtain_object_check?
exit_sem() is also quite long, but I didn't spot any obvious problems.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Hi all,
On 09/12/2013 02:20 PM, Manfred Spraul wrote:
And: What about the other users of obtain_object_check?
exit_sem() is also quite long, but I didn't spot any obvious problems.
a) I think semtimed(), msgsnd() and msgrcv() must be fixed:
They either leak memory or tasks can sleep forever
that does
#while true;cat /proc/sysvipc/*>/dev/null;done
in parallel with create/remove/whatever operations.
Davidlohr: Have you done any stress tests for the /proc interface?
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
/whatever operations.
Davidlohr: Have you done any stress tests for the /proc interface?
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Hi Sedat,
On 09/03/2013 06:13 PM, Sedat Dilek wrote:
On Tue, Sep 3, 2013 at 4:00 PM, Manfred Spraul wrote:
The check if the queue is full and adding current to the wait queue of pending
msgsnd() operations (ss_add()) must be atomic.
Otherwise:
- the thread that performs msgsnd() finds a full
permissions.
If security_msg_queue_msgsnd() is called without locks, then there might be
races.
- it makes the patch much simpler.
Reported-by: Vineet Gupta
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/ipc/msg.c b/ipc
Hi Vineet,
On 09/03/2013 11:51 AM, Vineet Gupta wrote:
On 09/03/2013 02:53 PM, Manfred Spraul wrote:
The access to msq->q_cbytes is not protected.
Vineet, could you try to move the test for free space after ipc_lock?
I.e. the lock must not get dropped between testing for free sp
On 09/03/2013 11:16 AM, Vineet Gupta wrote:
On 09/03/2013 02:27 PM, Manfred Spraul wrote:
On 09/03/2013 10:44 AM, Vineet Gupta wrote:
b) Could you check that it is not just a performance regression?
Does ./msgctl08 1000 16 hang, too?
Nope that doesn't hang. The minimal configuration
is a case of lost wakeup or some such. I'm running with some more
diagnostics
and will report soon ...
What is the output of ipcs -q? Is the queue full or empty when it hangs?
I.e. do we forget to wake up a receiver or forget to wake up a sender?
--
Manfred
--
To unsubscribe from this lis
permissions.
If security_msg_queue_msgsnd() is called without locks, then there might be
races.
- it makes the patch much simpler.
Reported-by: Vineet Gupta vineet.gup...@synopsys.com
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/msg.c | 12 +---
1 file changed, 5 insertions
Hi Sedat,
On 09/03/2013 06:13 PM, Sedat Dilek wrote:
On Tue, Sep 3, 2013 at 4:00 PM, Manfred Spraul manf...@colorfullife.com wrote:
The check if the queue is full and adding current to the wait queue of pending
msgsnd() operations (ss_add()) must be atomic.
Otherwise:
- the thread
with some more
diagnostics
and will report soon ...
What is the output of ipcs -q? Is the queue full or empty when it hangs?
I.e. do we forget to wake up a receiver or forget to wake up a sender?
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 09/03/2013 11:16 AM, Vineet Gupta wrote:
On 09/03/2013 02:27 PM, Manfred Spraul wrote:
On 09/03/2013 10:44 AM, Vineet Gupta wrote:
b) Could you check that it is not just a performance regression?
Does ./msgctl08 1000 16 hang, too?
Nope that doesn't hang. The minimal configuration
Hi Vineet,
On 09/03/2013 11:51 AM, Vineet Gupta wrote:
On 09/03/2013 02:53 PM, Manfred Spraul wrote:
The access to msq-q_cbytes is not protected.
Vineet, could you try to move the test for free space after ipc_lock?
I.e. the lock must not get dropped between testing for free space
to msq->q_cbytes is not protected. Thus two parallel msgsnd()
calls could succeed, even if both together brings the queue length above
the limit.
But it can't explain why 3.11-rc7 hangs: As explained above, msgctl08
uses one queue for each thread pair.
--
Manfred
--
To unsubscribe f
parallel msgsnd()
calls could succeed, even if both together brings the queue length above
the limit.
But it can't explain why 3.11-rc7 hangs: As explained above, msgctl08
uses one queue for each thread pair.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux
On 2013-08-27 02:51, Bryan Wu wrote:
> On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
> wrote:
>> fb_notifier_callback is called on any event fired by fb_notifier_call_chain.
>> Events may, or may not contain some data (fb_event.data).
>> In case of FB_EVENT_BLAN
On 2013-08-27 02:51, Bryan Wu wrote:
On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
manfred.schla...@gmx.at wrote:
fb_notifier_callback is called on any event fired by fb_notifier_call_chain.
Events may, or may not contain some data (fb_event.data).
In case of FB_EVENT_BLANK fb_event.data
burning a few cycles? If the whole function call can be disabled
(ignored) in a certain configuration, it shouldn't call at all, should
it?
Cheers.
l8er
manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
general angle, wouldn't this leave
a(nother) plain jsr... rts sequence without any effect other than
burning a few cycles? If the whole function call can be disabled
(ignored) in a certain configuration, it shouldn't call at all, should
it?
Cheers.
l8er
manfred
--
To unsubscribe from this list: send
/backlight.c line 43 I would suggest to return
immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl
---
Background information:
I'm currently working on a IMX53(ARM) based hardware and Linux 3.11-rc5 and
detected a problem in drivers/leds/trigger/ledtrig-backlight.c
/backlight.c line 43 I would suggest to return
immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
Background information:
I'm currently working on a IMX53(ARM) based hardware and Linux 3.11-rc5 and
detected a problem in drivers/leds/trigger
-off-by: Manfred Spraul
---
ipc/sem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index f9d1c06..ad9daca 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -785,8 +785,10 @@ static int do_smart_wakeup_zero(struct sem_array *sma,
struct sembuf *sops
ct" cpu causes a transfer back when
setting sem->pid.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
a transfer back when
setting sem-pid.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index f9d1c06..ad9daca 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -785,8 +785,10 @@ static int do_smart_wakeup_zero(struct sem_array *sma,
struct
ting for sma->sem_perm.lock.
With enough cpus, it will stay like this forever.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi all,
On 06/10/2013 07:16 PM, Manfred Spraul wrote:
Hi Andrew,
I have cleaned up/improved my updates to sysv sem.
Could you replace my patches in -akpm with this series?
- 1: cacheline align output from ipc_rcu_alloc
- 2: cacheline align semaphore structures
- 3: seperate-wait-for-zero
Hi all,
On 06/10/2013 07:16 PM, Manfred Spraul wrote:
Hi Andrew,
I have cleaned up/improved my updates to sysv sem.
Could you replace my patches in -akpm with this series?
- 1: cacheline align output from ipc_rcu_alloc
- 2: cacheline align semaphore structures
- 3: seperate-wait-for-zero
-sem_perm.lock.
With enough cpus, it will stay like this forever.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
one will cause an improvement for multi-socket
systems, but I don't have a test setup.
6 is just a cleanup/function rename.
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
are running.
Andrew: Could you merge it into -akpm and then forward it towards Linus' tree?
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 70480a3..1afbc57 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -
, as in linux <=3.0.9
Signed-off-by: Manfred Spraul
---
include/linux/sem.h | 5 +-
ipc/sem.c | 209 +---
2 files changed, 153 insertions(+), 61 deletions(-)
diff --git a/include/linux/sem.h b/include/linux/sem.h
index 53d4265..55e17f6 100
algined pointers, the implementation
of ipc_rcu_alloc breaks that.
Andrew: Could you merge it into -akpm and then forward it towards Linus' tree?
Signed-off-by: Manfred Spraul
---
ipc/util.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
side effect, do_smart_update_queue() becomes much simpler:
No more goto logic.
Signed-off-by: Manfred Spraul
---
ipc/sem.c | 128 ++
1 file changed, 88 insertions(+), 40 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index e7f3d64..dcf99ef 1006
required.
No performance improvement on a single-socket i3 - only important
for larger systems.
Signed-off-by: Manfred Spraul
---
include/linux/sem.h | 1 -
ipc/sem.c | 37 +++--
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/include
Cleanup: Some minor points that I noticed while writing the
previous patches
1) The name try_atomic_semop() is misleading: The function performs the
operation (if it is possible).
2) Some documentation updates.
No real code change, a rename and documentation changes.
Signed-off-by: Manfred
required.
No performance improvement on a single-socket i3 - only important
for larger systems.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
include/linux/sem.h | 1 -
ipc/sem.c | 37 +++--
2 files changed, 31 insertions(+), 7 deletions
Cleanup: Some minor points that I noticed while writing the
previous patches
1) The name try_atomic_semop() is misleading: The function performs the
operation (if it is possible).
2) Some documentation updates.
No real code change, a rename and documentation changes.
Signed-off-by: Manfred
, do_smart_update_queue() becomes much simpler:
No more goto logic.
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 128 ++
1 file changed, 88 insertions(+), 40 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index e7f3d64..dcf99ef
, as in linux =3.0.9
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
include/linux/sem.h | 5 +-
ipc/sem.c | 209 +---
2 files changed, 153 insertions(+), 61 deletions(-)
diff --git a/include/linux/sem.h b/include/linux/sem.h
index
algined pointers, the implementation
of ipc_rcu_alloc breaks that.
Andrew: Could you merge it into -akpm and then forward it towards Linus' tree?
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/util.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
one will cause an improvement for multi-socket
systems, but I don't have a test setup.
6 is just a cleanup/function rename.
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
it into -akpm and then forward it towards Linus' tree?
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 70480a3..1afbc57 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -96,7 +96,7 @@ struct sem
ificant not to share it immediately.
--
Manfred
diff --git a/Makefile b/Makefile
index 73e20db..42137ab 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 10
SUBLEVEL = 0
-EXTRAVERSION = -rc3
+EXTRAVERSION = -rc3-otime
NAME = Unicycling Gorilla
# *DOCUMENTATION*
diff -
Hi all,
On 06/01/2013 11:20 AM, Manfred Spraul wrote:
- osim [i.e.: with reschedules] is much slower: around 21 us per
schedule.
Perhaps the scheduler didn't pair the threads optimally: intra-cpu
reschedules
take around 2 us on my i3, inter-cpu reschedules around 16 us.
I mixed up
Hi Rik,
On 05/27/2013 07:57 PM, Rik van Riel wrote:
On 05/26/2013 05:08 AM, Manfred Spraul wrote:
Introduce seperate queues for operations that do not modify the
semaphore values.
Advantages:
- Simpler logic in check_restart().
- Faster update_queue(): Right now, all wait-for-zero operations
Hi Rik,
On 05/27/2013 07:57 PM, Rik van Riel wrote:
On 05/26/2013 05:08 AM, Manfred Spraul wrote:
Introduce seperate queues for operations that do not modify the
semaphore values.
Advantages:
- Simpler logic in check_restart().
- Faster update_queue(): Right now, all wait-for-zero operations
Hi all,
On 06/01/2013 11:20 AM, Manfred Spraul wrote:
- osim [i.e.: with reschedules] is much slower: around 21 us per
schedule.
Perhaps the scheduler didn't pair the threads optimally: intra-cpu
reschedules
take around 2 us on my i3, inter-cpu reschedules around 16 us.
I mixed up
it immediately.
--
Manfred
diff --git a/Makefile b/Makefile
index 73e20db..42137ab 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 10
SUBLEVEL = 0
-EXTRAVERSION = -rc3
+EXTRAVERSION = -rc3-otime
NAME = Unicycling Gorilla
# *DOCUMENTATION*
diff --git a/include/linux
(assuming 2 cpus, otherwise increase "2" and "20" accordingly)
Here is the link to the tool:
http://marc.info/?l=linux-kernel=125038376609750
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
- and the task switch code is
never triggered.
Could you double check that the number of context switches matches the
output?
I usually use this tool:
http://marc.info/?l=linux-kernel=125038376609750
--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-k
- and the task switch code is
never triggered.
Could you double check that the number of context switches matches the
output?
I usually use this tool:
http://marc.info/?l=linux-kernelm=125038376609750
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
4,277817
(assuming 2 cpus, otherwise increase 2 and 20 accordingly)
Here is the link to the tool:
http://marc.info/?l=linux-kernelm=125038376609750
--
Manfred
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
701 - 800 of 1478 matches
Mail list logo
