Hi Stanislav,
sorry for the slow reply, I finally got the time to perform tests with
your patches.
On 08/13/2012 02:32 PM, Stanislav Kinsbursky wrote:
This test is a part of CRIU development test suit.
---
tools/testing/selftests/ipc/msgque.c | 151 ++
1 f
On 08/13/2012 02:32 PM, Stanislav Kinsbursky wrote:
This patch is required for checkpoint/restore in userspace.
IOW, c/r requires some way to get all pending IPC messages without deleting
them from the queue (checkpoint can fail and in this case tasks will be resumed,
so queue have to be valid).
eted, 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
goto again;
}
<<< sem_perm.lock already dropped, thus no "goto again;"
locknum = sops->sem_num;
Signed-off-by: Manfred Spraul
Cc: Mike Galbraith
Cc: Rik van Riel
Cc: Davidlohr Bueso
Cc: Andrew Morton
---
ipc/sem.c |
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/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.
I
, 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
Signed-off-by: Davidlohr Bueso
---
ipc/shm.c | 23 ++-
1 file changed, 14 insert
Hi Dave,
On 09/04/2013 11:50 PM, Dave Jones wrote:
Haven't seen this before.
Tree based on v3.11-3104-gf357a82
BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child0:25479]
Modules linked in: sctp snd_seq_dummy fuse dlci rfcomm tun bnep hidp ipt_ULOG
nfnetlink can_raw can_bcm scsi_transport_i
Hi Davidlohr,
I think the patch (3dd1f784ed6603d7ab1043e51e6371235edf2313) is still
unsafe, i.e. my correction (bebcb928c820d0ee83aca4b192adc195e43e66a2)
doesn't fix everything:
AFAICS, ipc_obtain_object_check:
- look up the id in the idr tree
- check if it is deleted
- return without taking
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 fo
Hi,
[forgot to cc everyone, thus I'll summarize some mails...]
On 09/02/2013 06:58 AM, Vineet Gupta wrote:
On 08/31/2013 11:20 PM, Linus Torvalds wrote:
Vineet, actual patch for what Davidlohr suggests attached. Can you try it?
Linus
Apologies for late in getting back to this -
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 that hangs reliably is msgctl
5 2
With this config there are 3 processes.
...
555 554
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 configur
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
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 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
pdate sem_otime
anymore.
The fix is simple:
Non-alter operations must update sem_otime.
Signed-off-by: Manfred Spraul
Reported-by: Jia He
---
ipc/sem.c | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index e5
Hi Davidlohr,
On 09/16/2013 05:04 AM, Davidlohr Bueso wrote:
This fixes a race in shmat() between finding the msq and
actually attaching the segment, as another thread can delete shmid
underneath us if we are preempted before acquiring the kern_ipc_perm.lock.
According the the man page, Linux su
task is resumed, then it will happily wait for messages on a
deleted queue.
Fix this by checking for if the queue has been deleted after taking the lock.
Reported-by: Manfred Spraul
Cc: sta...@vger.kernel.org # for 3.11
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
--
To
the
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(-)
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, but
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:
In commit 0a2b9d4c,the update of semaphore's sem_otime(last semop time)
was removed because he wanted to move setting sem->sem_otime t
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 conc
doesn't break anything we weren't aware of.
Suggested-by: Linus Torvalds
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
--
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/
ed to be
applied on top of Jia's patch.
_If_ the performance degradation is too large, then the alternative
would be to set sem_otime directly in semtimedop() for successfull
non-alter operations.
--
Manfred
>From 07da483abc88748a666f655f3e1d81a94df88e38 Mon Sep 17 00:00:00 2001
From: Ma
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 se
ut 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
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-and
On 06/14/2013 09:05 PM, Mike Galbraith wrote:
32 of 64 cores DL980 without the -rt killing goto again loop removal I
showed you. Unstable, not wonderful throughput.
Unfortunately the -rt approach is defintively unstable:
@@ -285,9 +274,29 @@ static inline int sem_lock(struct sem_ar
On 06/14/2013 09:05 PM, Mike Galbraith wrote:
# Events: 802K cycles
#
# Overhead Symbol
# ..
#
18.42% [k] SYSC_semtimedop
15.39% [k] sem_lock
10.26% [k] _raw_spin_lock
9.00% [k] perform
igned-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
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 mix
Hi Rik,
I finally managed to get EFI boot, i.e. I'm now able to test on my i3
(2core+HT).
With semscale (i.e.: just overhead, perform semop=0 operations), the
scalability from 1 to 2 cores is good, but not linear:
# semscale 10 | grep "interleave 2"
Cpus 1, interleave 2 delay 0: 35502103 in
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
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
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/u
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-and-alter-tasks
- 4: Always-use-only-one-queue-for-alter-opera
threads 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
Hi,
On 05/06/2013 05:51 AM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in ipc/sem.c
between commit 321310ced2d6 ("ipc: move sem_obtain_lock() rcu locking
into the only caller") from Linus' tree and commit "ipc/sem.c:
alternatives to preempt_disab
Hi Rik,
I like your change to the ipc/sem locking:
A scheme with a per-semaphore lock and without the overhead of always
acquiring both the global and the per-semaphore lock.
But:
1) I found one bug with your sem locking changes:
If
- a complex operation is sleeping [would be woken up by updat
7;t prefer FIFO semantics).
Other changes:
- try_atomic_semop() also performs the semop. Thus rename the function.
It passes tests with qemu, but not boot-tested due to EFI problems.
Signed-off-by: Manfred Spraul
---
diff --git a/include/linux/sem.h b/include/linux/sem.h
index 53d4265..3f2c6c8 10064
Hi Peter,
You wrote:
When MSG_COPY is set, a duplicate message must be allocated for
the copy before locking the queue. However, the copy could
not be larger than was sent which is limited to msg_ctlmax.
Signed-off-by: Peter Hurley
---
ipc/msg.c | 6 --
1 file changed, 4 insertions(+),
Hi Rik,
On 05/25/2013 03:49 PM, Rik van Riel wrote:
On 05/25/2013 04:54 AM, Manfred Spraul wrote:
But: Let's wait if this really exists: An application that does rarely
complex operations (and that doesn't prefer FIFO semantics).
I do not like that downside at all.
The danger of
- Fewer restarts in update_queue(), because pending wait-for-zero do not
force a restart anymore.
Other changes:
- try_atomic_semop() also performs the semop. Thus rename the function.
It passes tests with qemu, but not boot-tested due to EFI problems.
Signed-off-by: Manfred Spraul
---
diff
of(int)*sems);
if (!nr || !val) {
printf("Malloc failed.\n");
return 1;
}
printf("pid %d: changing %d semaphores:\n",getpid(), sems);
for (i=0;i/*
* Copyright (C) 1999 by Manfred Spraul.
*
* Redistribution of this
Hi Rik,
On 05/20/2013 12:32 AM, Rik van Riel wrote:
@@ -751,17 +744,19 @@ static int update_queue(struct sem_array *sma, int
semnum, struct list_head *pt)
static void do_smart_update(struct sem_array *sma, struct sembuf *sops, int
nsops,
int otime, struct list_head *p
I've split my patch into 4 parts:
- 1: Fix-missing-wakeups-in-do_smart_update
- 2: seperate-wait-for-zero-and-alter-tasks
- 3: Always-use-only-one-queue-for-alter-operations
- 4: Rename-try_atomic_semop-to-perform_atomic
Linus:
- Patch 1 should be merged immediately: It fixes bugs,
the current c
be scanned - regardless of the reason
for calling do_smart_update_queue()
The patch is not optimized, i.e. even completing a wait-for-zero
operation causes a rescan. This is done to keep the patch as simple as
possible.
Avoiding unnecessary scans is implemented in the following patches.
Signed-off-b
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
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 ce25da3..9ed3853 1006
: Manfred Spraul
---
ipc/sem.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 9ed3853..1dbb2fa 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -153,12 +153,15 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void
Hi Davidlohr,
On 05/26/2013 10:50 PM, Davidlohr Bueso wrote:
In lack of getting my swingbench DSS environment back, I ran these
changes against the semop-multi program on my laptop. For 256 threads,
with Manfred's patchset the ops/sec suffers around -7.3%.
Could you also check the performance
Hi Rik,
On 05/27/2013 07:51 PM, Rik van Riel wrote:
Very much not optimized, but we need to fix the regression.
Acked-by: Rik van Riel
Thanks for the review.
I was afraid that the differences would be noticeable but they aren't:
At least on my laptop, the differences between the patches ar
Hi Seiichi,
On 08/03/2012 02:49 PM, Seiichi Ikarashi wrote:
> semop() with SEM_UNDO sem_flg can result in ENOMEM even after
> succeeding semget() with large nsems.
How large is nsems, what is the use case?
Which kind of operations are performed?
Only simple semop(,,1) calls?
still documents ~800
Hi Seiichi,
2012/8/6 Seiichi Ikarashi
>
>
> A real case was as follows.
> semget(IPC_PRIVATE, 7, IPC_CREAT | IPC_EXCL);
> sops[0].sem_num = 0;
> sops[0].sem_op = 1;
> sops[0].sem_flg = SEM_UNDO;
> semop(semid, sops, 1);
>
I think this can't work: sops[].sem_num is
Hi Stanislav,
2012/8/10 Stanislav Kinsbursky :
> This patch is required for checkpoint/restore in userspace.
> IOW, c/r requires some way to get all pending IPC messages without deleting
> them from the queue (checkpoint can fail and in this case tasks will be
> resumed,
> so queue have to be val
Hi Stanislav,
2012/8/11 Stanislav Kinsbursky :
> 11.08.2012 15:20, Manfred Spraul пишет:
>> a) What about the simpler approach:
>> - if MSG_COPY is set, then @mtype is interpreted as the number of the
>> message that should be copied.
>>If there are less than @mtyp
> ps xl:
> F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
> /home/data/mozilla/obj/dist/bin/mozi
>
down_w
Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a
rw-sem.
Did you compile sysrq into your kernel? Then
From: "Pavel Machek" <[EMAIL PROTECTED]>
>
> > Ok, there are 2 bugs that are (afaics) impossible to fix without
> > checking for pending softirq's in cpu_idle():
> >
> > a)
> > queue_task(my_task1, tq_immediate);
> > mark_bh();
> > schedule();
> > ;within schedule: do_softirq()
> > ;within my_task
>
> everything seems to work fine. are these interrupt problems "bad" or merely
> indicators of a high load. can/should one get rid of them?
>
Could you try the 8139too driver?
It's a bug in the rtl8139 driver, and under really high load it can
cause crashes.
--
Manfred
-
To unsubscri
Pavel Machek wrote:
>
> Ok. I was missing the fact it is checked on going userspace.
>
What about the attached patch?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 3
// EXTRAVERSION = -ac3
--- 2.4/include/linux/interrupt.h Thu Feb 22
The Intel documentation recommends that spinlocks should use
loop:
rep;nop;
cmp $0,lock_var
jne loop
ftp://download.intel.com/design/perftool/cbts/appnotes/sse2/w_spinlock.pdf
but the linux spinlock implementation uses
loop:
cmp $0, lock_var
rep; nop;
Just a guess:
Perhaps one bios is older and contains an older microcode patch?
Have you tried the microcode driver?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
From: <[EMAIL PROTECTED]>
> Hello!
>
> > + if (softirq_active(smp_processor_id()) &
softirq_mask(smp_processor_id())) {
> > + do_softirq();
> > + return 0;
>
> BTW you may delete do_softirq()... schedule() will call this.
>
But with a huge overhead. I'd prefer to call it directly from within the
From: <[EMAIL PROTECTED]>
To: "Manfred Spraul" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 7:58 PM
Subject: Re: softirq buggy [Re: Serial port latency]
> Hello!
>
> > But with a huge overhead. I'd prefer to call it dir
I've attached a new patch:
* cpu_is_idle() moved to
* function uninlined due to header dependencies
* cpu_is_idle() doesn't call do_softirq directly, instead the caller
returns to schedule()
* cpu_is_idle() exported for modules.
* docu updated.
I'd prefer to inline cpu_is_idle(), but optimizing
Afaics cpu bindings could allow a thread to run with an "unlimited"
timeslice.
cpu0: one thread running with 'nice==19'.
NICE_TO_TICKS==1.
cpu1: lots of other threads with 'nice==0' (NICE_TO_TICKS==6)
cpu0 will enter schedule() every tick.
can_schedule() returns '0' for all thre
Andrea Arcangeli wrote:
>
> your cpu_is_idle will return 0 in the need_resched != 0 check even if the cpu
> is idle (because of the -1 trick for avoiding the SMP-IPI to notify the cpu).
>
Fixed.
> The issue you are addressing is quite londstanding and it is not only related
> to the loop with an
> it is very hard to imagine the scenario which can lead to this...
> I will try your suggestion..
Perhaps a problem with the csum assembler implementations? Which cpu
type do you optimize for, and which cpu is installed?
Btw, are you overclocking anything?
--
Manfred
-
To unsubscribe f
> I was expecting to receive some replies to my last desperate messages:
>
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg35446.html
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg36591.html
>
If you don't receive an answer, then it either indicates that the bug is
t
> I was expecting to receive some replies to my last desperate messages:
>
[EMAIL PROTECTED]/msg35446.html">http://www.mail-archive.com/
[EMAIL PROTECTED]/msg35446.html
[EMAIL PROTECTED]/msg36591.html">http://www.mail-archive.com/
[EMAIL PROTECTED]/msg36591.html
> Maybe someone can see which is
>> Ah. Of course. All (or most) kernel initialisation is
>> done by PID 1. Search for "kernel_thread" in init/main.c
>>
>> So it seems that in your setup, process 1 is not reaping
>> children, which is why this hasn't been reported before.
>> Is there something unusual about your setup?
> I found
Hi Alan,
Rod's init version (from RH 7.0) doesn't reap children that died before
it was started. Is that an init bug or should the kernel reap them
before the execve?
The attached patch reaps all zombies before the execve("/sbin/init").
I also found a bug in kernel/context.c: it doesn't acquire
From: "Alan Cox" <[EMAIL PROTECTED]>
>
> That has an implicit race, a zombie can always appear as we are
execing init.
> I think init wants fixing
>
Rod, could you boot again with the unpatched kernel and send a sigchild
to init?
#kill -CHLD 1
If I understand the init code correctly the sigchild
I found the problem:
* init uses waitpid(-1,,), thus the __WALL flag is not set
* without __WALL, only processes with exit_signal == SIGCHLD are reaped
* it's impossible for user space processes to die with another
exit_signal, forget_original_parent changes the exit_signal back to
SIGCHLD ("We d
The first 2 problems aren't real problems (modify /etc/fstab, perhaps a
special ioctl could be added to raid and fsck stops the reconstruction)
- at most anoying, but clearly no bugs.
But the third one could be a bug:
>
> Third problem:
>
> I just tried boot 2.4.3 today. (after an unclean shut
Are you sure the trace is decoded correctly?
> CPU:0
> EIP:0010:[sys_mremap+31/884]
> EFLAGS: 00010206
> Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9
ac ae is
lodsb
scasb
Could you run
#objdump --disassemble-all --reloc linux/mm/mremap.o | less
and check that the
> Well looking a little more closely than I did last night it looks like
> access_process_vm (called from ptrace) can cause what amounts to a
> page fault at pretty arbitrary times.
It's also used for several /proc/ files.
I remember that I got crashes with concurrent exec+cat
/proc//cmdline unt
ext2_find_entry is quite expensive for directories with lots of entries
- what about caching the block and offset in the dcache?
Each dentry contains 2 values reserved for the filesystem:
dentry->d_fsdata
dentry->d_time
ext2 doesn't use them - yet.
I've written a small patch that caches the dir
"N. Jason Kleinbub" wrote:
>
> People,
>
> Not sure where to go from here but
>
> ( Yes I have read the FAQ )
>
> For practical reasons, I have created some modification to the
> Linux kernel. These changes were to make our implementation of
> software more convenient (elegant).
Martin Rode wrote:
>
> >
> > Run this oops message through ksymoops please. It will make debugging
> > it alot easier.
> >
> >
>
> Since I did not compile the kernel myself, ksymoops is not too happy with
> what is has to analyse the dump. I tried compile the Mandrake kernel myself
> but there
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff. I believe the test should work in all cases as it basically
> implements a manual replacement for EOI
Michael E Brown wrote:
>
> >
> > Anyway, an ioctl just to read the last sector is too silly.
> > An ioctl to change the blocksize is more reasonable.
>
> That may be better, I don't know. That's why this is an RFC. Are there any
> possible races with that method? It seems to me that you might ad
I found 2 bugs in several network drivers:
* dev->mem_start: NULL means "not command line configuration" 0x
means "default".
several drivers only check for NULL, not for 0x.
* incorrect bounds checks for phy_idx: 2 entries in the structure, but
up to 4 are initialized.
* somethi
David Hinds wrote:
>
> Say the driver is linked into the kernel. Hot plug drivers should not
> all complain about not finding their hardware.
>
That's handled by pci_module_init(), check :
if CONFIG_HOTPLUG is enabled, then pci_module_init() never returns with
-ENODEV.
Which means that eisa ca
Which tulip card do you use?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I have another idea for sse, and this one is far safer:
only use sse prefetch, leave the string operations for the actual copy.
The prefetch operations only prefetch, don't touch the sse registers,
thus neither any reentency nor interrupt problems.
I tried the attached hack^H^H^H^Hpatch, and rea
Rob Cermak wrote:
>
> Anyone who can tell me what's going on here?
>
Perhaps it's the 'dev->memstart==~0' bug I found yesterday?
Could you go into line 450 of 3c509.c and replace
- dev->if_port = (dev->mem_start & 0x1f) ?dev->mem_start & 3: if_port;
+ printk(KERN_WARNING "%s: mem_start is %lxh.
"Eric W. Biederman" wrote:
>
> But the gcc bounds checking work is the ultimate buffer overflow fix.
> You can recompile all of your trusted applications, and libraries with
> it and be safe from one source of bugs.
>
void main(int argc, char **argv[])
{
char local[128];
if(argc
Nathan Walp wrote:
>
> The fix in ac14 for the ac13 patch that killed the tulip driver doesn't
> quite work either:
>
I need more details:
does it immediately time out (after a few seconds), or a after a few
minutes.
Which network speed do you use? 100MBit half duplex?
Could you please run the
Kanoj Sarcar wrote:
>
> Okay, I will quote from Intel Architecture Software Developer's Manual
> Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27:
>
> "Bus cycles to the page directory and page tables in memory are performed
> only when the TLBs do not contain the translat
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >> > << lock;
> >> > read pte
> >> > if (!present(pte))
> >> >do_page_fault();
> >> > pte |= dirty
> >> > write pte.
> >> > >> end lock;
> >>
> >> No, it is a little more complicated. You al
Manfred Spraul wrote:
>
> I just benchmarked a single flush_tlb_page().
>
> Pentium II 350: ~ 2000 cpu ticks.
> Pentium III 850: ~ 3000 cpu ticks.
>
I forgot the important part:
SMP, including a smp_call_function() IPI.
IIRC Ingo wrote that a local 'invp
Stephen Thomas wrote:
>
> On trying 2.4.1-ac13 I hit the tulip driver problems reported elsewhere,
> and ac14 does not seem to fix the problem on my machine. Attached is an
> extract from my /var/log/messages.
>
Could you try the attached oneliner patches?
patch-tulip-fix1 is integrated in -a
Jamie Lokier wrote:
>
> Linus Torvalds wrote:
> > So the only case that ends up being fairly heavy may be a case that is
> > very uncommon in practice (only for unmapping shared mappings in
> > threaded programs or the lazy TLB case).
>
The lazy tlb case is quite fast: lazy tlb thread never write
Jamie Lokier wrote:
>
> /* mprotect.c */
> entry = ptep_get_and_clear(pte);
> set_pte(pte, pte_modify(entry, newprot));
>
> I.e. the only code with the race condition is code which explicitly
> clears the dirty bit, in vmscan.c.
>
> Do you see any possibility of losing a dirty b
Jamie Lokier wrote:
>
> And how does that lose a dirty bit?
>
> For the other processor to not write a dirty bit, it must have a dirty
^^^
> TLB entry already which, along with the locked cycle in
> ptep_get_and_clear, means that `entry' will have _PAGE_DIRTY
1 - 100 of 655 matches
Mail list logo
