On 04/16, Satoru Takeuchi wrote:
--- linux-2.6.21-rc6-mm1.tsfix.orig/kernel/exit.c 2007-04-15
16:56:12.0 +0900
+++ linux-2.6.21-rc6-mm1.tsfix/kernel/exit.c 2007-04-15 16:56:17.0
+0900
@@ -680,10 +680,14 @@
reaper = child_reaper(father);
On 04/16, Oleg Nesterov wrote:
On 04/16, Satoru Takeuchi wrote:
--- linux-2.6.21-rc6-mm1.tsfix.orig/kernel/exit.c 2007-04-15
16:56:12.0 +0900
+++ linux-2.6.21-rc6-mm1.tsfix/kernel/exit.c2007-04-15
16:56:17.0 +0900
@@ -680,10 +680,14
On 04/20, Jarek Poplawski wrote:
On Thu, Apr 19, 2007 at 02:21:22PM +0400, Oleg Nesterov wrote:
...
Yes. It would be better to use cancel_work_sync() instead of
flush_workqueue()
to make this less possible (because cancel_work_sync() doesn't need to wait
for
the whole -worklist
On 04/20, Jarek Poplawski wrote:
Here is my proposal to make things clearer:
(this time on 2.6.21-rc7)
CC: David Chinner [EMAIL PROTECTED]
CC: Oleg Nesterov [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp 2.6.21-rc7-/kernel/workqueue.c 2.6.21-rc7
On 04/19, Rafael J. Wysocki wrote:
On Thursday, 19 April 2007 14:02, Gautham R Shenoy wrote:
This patch fixes the race pointed out by Oleg Nesterov.
* Freezer marks a thread as freezeable.
* The thread now marks itself PF_NOFREEZE causing it to
freeze on calling try_to_freeze
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
+ task_lock(current);
for (;;) {
On 04/20, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 10:54:36AM +0200, Rafael J. Wysocki wrote:
Hmm, can't we do something like this instead:
---
kernel/kthread.c | 10 ++
1 file changed, 10 insertions(+)
Index: linux-2.6.21-rc7/kernel/kthread.c
On 04/20, Andrew Morton wrote:
On Fri, 20 Apr 2007 11:41:46 +0100
David Howells [EMAIL PROTECTED] wrote:
There are only two non-net patches that AF_RXRPC depends on:
(1) The key facility changes. That's all my code anyway, and shouldn't be
a
problem to merge unless someone
On 04/23, Jarek Poplawski wrote:
On Fri, Apr 20, 2007 at 09:08:36PM +0400, Oleg Nesterov wrote:
First, this flag should be cleared after return from
cancel_rearming_delayed_work().
I think this flag, if at all, probably should be cleared only
consciously by the owner of a work, maybe
On 04/23, Christoph Hellwig wrote:
On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
This patch implements the kthread helper functions kthread_start
and kthread_end which make it simple to support a kernel thread
that may decided to exit on it's own before we request
On 04/23, David Howells wrote:
We only care when del_timer() returns true. In that case, if the timer
function still runs (possible for single-threaded wqs), it has already
passed __queue_work().
Why do you assume that?
If del_timer() returns true, the timer was pending. This means it
On 04/23, Gautham R Shenoy wrote:
On Fri, Apr 20, 2007 at 10:02:08PM +0400, Oleg Nesterov wrote:
Gautham, isn't it possible to make a more simpler patch ? Just add
PF_NOFREEZE
check to frozen_process,
static inline void frozen_process(struct task_struct *p
On 04/23, Eric W. Biederman wrote:
So I propose we add a kthread_orphan as a basic primitive to decrement the
count on the task_struct if we want a kthread to simply exit after it
has done some work.
And as a helper function we can have a kthread_run_orphan.
Speaking about helpers, could
On 04/23, Gautham R Shenoy wrote:
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock
On 04/23, Gautham R Shenoy wrote:
On Sun, Apr 22, 2007 at 09:40:59PM +0200, Rafael J. Wysocki wrote:
/*
@@ -232,6 +233,14 @@ int kthread_stop(struct task_struct *k)
/* Now set kthread_should_stop() to true, and wake it up. */
kthread_stop_info.k = k;
+ if
On 04/16, Rafael J. Wysocki wrote:
Appended is the updated version of the patch (in addition to the changes
mentioned above I've eliminated the magic constant 0x0008 from cpu.c by
changing the new definitions in notifier.h).
Most sub-systems doesn't care about CPU_TASKS_FROZEN bit. Take for
On 04/23, Rafael J. Wysocki wrote:
On Monday, 23 April 2007 14:35, Gautham R Shenoy wrote:
+ if (!freezer_should_exempt(current)) {
task_lock(k);
+ /* We are freezable, so we must make sure that the thread being
+ * stopped is not frozen and will not be
On 04/22, Rafael J. Wysocki wrote:
Move all of the freezer-related flags to a separate field in task_struct and
introduce functions to operate them using set_bit() etc.
[...snip...]
--- linux-2.6.21-rc6-mm1.orig/kernel/fork.c 2007-04-22 19:37:42.0
+0200
+++
On 04/24, Rafael J. Wysocki wrote:
Should I clear it in dup_task_struct() or is there a better place?
I personally think we should do this in dup_task_struct(). In fact, I believe
it is better to replace the
*tsk = *orig;
with some helper (like setup_thread_stack() below), and that
On 04/24, Rafael J. Wysocki wrote:
On Tuesday, 24 April 2007 00:55, Oleg Nesterov wrote:
On 04/24, Rafael J. Wysocki wrote:
Should I clear it in dup_task_struct() or is there a better place?
I personally think we should do this in dup_task_struct(). In fact, I
believe
On 04/24, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
We only care when del_timer() returns true. In that case, if the timer
function still runs (possible for single-threaded wqs), it has already
passed __queue_work().
Why do you assume that?
Sorry, I
On 04/24, Eric W. Biederman wrote:
The NULL vfork_done is really weird as exec is the only thing that sets
vfork_done to NULL.
Hm, mm_release() clears -vfork_done before complete().
mm_release:
struct completion *vfork_done = tsk-vfork_done;
if
On 04/24, Oleg Nesterov wrote:
Hm, mm_release() clears -vfork_done before complete().
mm_release:
struct completion *vfork_done = tsk-vfork_done;
if (vfork_done) {
tsk-vfork_done = NULL;
complete(vfork_done
On 04/24, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
The current code uses del_timer_sync(). It will also return 0. However, it
will spin waiting for timer-function() to complete. So we are just wasting
CPU.
That's my objection to using cancel_delayed_work
On 04/24, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
Great. I'll send the s/del_timer_sync/del_timer/ patch.
I didn't say I necessarily agreed that this was a good idea. I just meant
that
I agree that it will waste CPU. You must still audit all uses
On 04/24, Jarek Poplawski wrote:
This looks fine. Of course, it requires to remove some debugging
currently done with _PENDING flag
For example?
and it's hard to estimate this
all before you do more, but it should be more foreseeable than
current way. But
On 04/24, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
this change should be completely transparent for all users. Otherwise, it
is buggy.
I guess you will have to make sure
On 04/24, Eric W. Biederman wrote:
I don't know if this is the problem but it certainly needs to be fixed.
I guess you will re-submit these patches soon. May I suggest you to put
this
+ spin_lock_irq(tsk-sighand-siglock);
+ signal_wake_up(tsk, 1);
+
was re-started by work-func(), nobody
else can do this. This in turn means that delayed_work_timer_fn
has already passed __queue_work() (and wont't touch delayed_work)
because nobody else can queue delayed_work-work.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- OLD
On 04/25, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
Yes sure. Note that this is documented:
/*
* Kill off a pending schedule_delayed_work(). Note that the work
callback
* function may still be running on return from cancel_delayed_work().
Run
Andrew Morton wrote:
On Tue, 6 Mar 2007 11:03:48 -0500 linux-os \(Dick Johnson\) [EMAIL
PROTECTED] wrote:
In linux-2.6.16.24, there is a problem with kernel threads
and the aic79xx.c driver.
When nash is executing /initrd/linuxrc in the initial RAM disk
during boot, it will be
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct siginfo
*info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct signalfd_sq *sq;
+
+ list_for_each(pos, sighand-sfdlist) {
+ ctx =
On 03/08, Davide Libenzi wrote:
On Thu, 8 Mar 2007, Oleg Nesterov wrote:
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig, struct
siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+ struct
On 03/08, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Oleg Nesterov wrote:
Logic is, if it's not an RT signal, queue only one, otherwise multiple.
The bit on the -pending mask is clealer only when the queue slot becomes
empty.
Yes, I see what the code does, but I don't undestand
On 03/08, Roland McGrath wrote:
Your change seems fine to me. I certainly concur that it seems insane
for init to be responsible for tasks created magically inside the
kernel. The history I've found says that the setting to SIGCHLD was
introduced as part of v2.5.1.9 - v2.5.1.10, without
On 03/09, Roland McGrath wrote:
Yes sure, this change shoud be tested in -mm tree (I'll send the patch
on Sunday after some testing). The only (afaics) problem is that with
this change a kernel thread must not do do_fork(CLONE_THREAD).
To clarify, the danger here is that an
Davide Libenzi wrote:
+int signalfd_deliver(struct sighand_struct *sighand, int sig,
+ struct siginfo *info)
+{
+ int nsig = 0;
+ struct list_head *pos;
+ struct signalfd_ctx *ctx;
+
+ list_for_each(pos, sighand-sfdlist) {
+ ctx =
On 03/10, Davide Libenzi wrote:
+static void signalfd_put_sighand(struct signalfd_ctx *ctx,
+ struct sighand_struct *sighand,
+ unsigned long *flags)
+{
+ unlock_task_sighand(ctx-tsk, flags);
+}
Note that signalfd_put_sighand()
On 03/12, Rafael J. Wysocki wrote:
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Can we get better name for this function?
Well, I took the name from the Oleg's message. Can you please suggest
something?
Well, kthread_should_stop_check_freeze() is really awful, I agree :)
We
On 03/14, Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Hi.
I'm looking at how alloc_pid() works and can't understand
one (simple/stupid) thing.
It first kmem_cache_alloc()-s a strct pid, then calls
alloc_pidmap() and at the end it taks a global pidmap_lock()
Sukadev Bhattiprolu wrote:
@@ -1237,26 +1237,24 @@ static struct task_struct *copy_process(
}
}
- if (likely(p-pid)) {
- add_parent(p);
- tracehook_init_task(p);
-
- if (thread_group_leader(p)) {
- pid_t
Eric Dumazet wrote:
@@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw = p-signal-cnivcsw;
r-ru_minflt = p-signal-cmin_flt;
r-ru_majflt = p-signal-cmaj_flt;
+ r-ru_inblock =
On 03/16, Eric Dumazet wrote:
On Friday 16 March 2007 18:10, Oleg Nesterov wrote:
Eric Dumazet wrote:
@@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw = p-signal-cnivcsw;
r-ru_minflt = p-signal-cmin_flt
Andrew, unless you stop me right now, I am going to send the following
patches in addition:
[PATCH] kill cancel_rearming_delayed_workqueue()
cancel_rearming_delayed_workqueue(wq, dwork) does not
need the first parameter, it could be figured out from
Change queue_delayed_work() to use queue_delayed_work_on() to avoid the code
duplication (saves 133 bytes).
Q: queue_delayed_work() enqueues dwork-work directly when delay == 0, why?
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 6.20-rc6-mm3/kernel/workqueue.c~2_factor2007-02-10 18:23
the completion of work-func() upon return.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 6.20-rc6-mm3/include/linux/workqueue.h~1_dw_fw 2007-02-10
18:15:04.0 +0300
+++ 6.20-rc6-mm3/include/linux/workqueue.h 2007-02-10 18:16:15.0
+0300
@@ -193,7 +193,7 @@ int
/preempted.
Do flush_work(defense_work.work) after cancel_rearming_delayed_work().
Alternatively, we could add flush_work() to cancel_rearming_delayed_work(),
but note that we can't change cancel_delayed_work() in the same manner because
it may be called from atomic context.
Signed-off-by: Oleg
to
cancel_rearming_delayed_work().
Re-create an inline obsolete cancel_rearming_delayed_workqueue(wq) which just
calls cancel_rearming_delayed_work().
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
include/linux/workqueue.h | 13 ++---
kernel/workqueue.c| 26 +-
2 files
On 02/11, Oleg Nesterov wrote:
This makes impossible to use flush_fork(delayed_work-work) in addition
to cancel_delayed_work/cancel_rearming_delayed_work, not good.
It turns out this patch is in fact bug-fix.
I didn't notice that we already have flush_fork(delayed_work) calls!
This means
On 02/12, Oleg Nesterov wrote:
Remove this parameter, and rename the function to
cancel_rearming_delayed_work().
Damn! Forgot to rename EXPORT_SYMBOL() as well, otherwise unchanged.
[PATCH 4/3] make cancel_rearming_delayed_work() work on any workqueue, not just
keventd_wq
, but flush_work is really bad.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
include/linux/workqueue.h | 21 -
kernel/workqueue.c | 36 +---
fs/aio.c |4 ++--
block/ll_rw_blk.c |2 +-
drivers
Gautham, I'll try to apply this patch and read the code on Sunday, right
now a couple of comments about workqueue.c changes.
On 02/14, Gautham R Shenoy wrote:
--- hotplug.orig/kernel/workqueue.c
+++ hotplug/kernel/workqueue.c
@@ -368,6 +368,7 @@ static int worker_thread(void *__cwq)
On 02/14, Gautham R Shenoy wrote:
This patch reverts all the recent workqueue hacks added to make it
hotplug safe.
In my opinion these hacks are cleanups :)
Ok. If we use freezer then yes, we can remove cpu_populated_map and just
use for_each_online_cpu(). This is easy and good.
What else
On 02/14, Gautham R Shenoy wrote:
o Splits CPU_DEAD into two events namely
- CPU_DEAD: which will be handled while the processes are still
frozen.
- CPU_DEAD_KILL_THREADS: To be handled after we thaw_processes.
Imho, this is not right. This change the meaning of
On 02/14, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 08:13:05PM +0530, Gautham R Shenoy wrote:
+ switch (action) {
+ case CPU_UP_PREPARE:
+ /* Create a new workqueue thread for it. */
+ list_for_each_entry(wq, workqueues, list) {
Its probably safe to
On 02/16, Jiri Slaby wrote:
unify queue_delayed_work and queue_delayed_work_on fix
Since cwq-wq is unset for other than singlethread_cpu when singlethread
workqueue was created, an oops occurs during bootup.
And I thought I tested this...
On 02/16, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 11:09:04PM +0300, Oleg Nesterov wrote:
What else you don't like? Why do you want to remove cwq_should_stop() and
restore an ugly (ugly for workqueue.c) kthread_stop/kthread_should_stop() ?
What is ugly abt kthread_stop
On 02/16, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 10:47:42PM +0300, Oleg Nesterov wrote:
for (;;) {
- if (cwq-wq-freezeable)
+ if (cwq-wq-freezeable) {
Else? This is wrong. The change like this should start from making all
cwq-threads freezeable
On 02/16, Srivatsa Vaddagiri wrote:
On Wed, Feb 14, 2007 at 11:22:09PM +0300, Oleg Nesterov wrote:
o Splits CPU_DEAD into two events namely
- CPU_DEAD: which will be handled while the processes are still
frozen.
- CPU_DEAD_KILL_THREADS: To be handled after we
On 02/16, Srivatsa Vaddagiri wrote:
2.6.20-mm1 (cwq-should_stop)
=
static void cleanup_workqueue_thread(struct cpu_workqueue_struct *cwq, int
cpu)
{
struct wq_barrier barr;
int alive = 0;
spin_lock_irq(cwq-lock);
if
On 02/16, Srivatsa Vaddagiri wrote:
On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
frozen. The only exception is cleaning up of per-cpu threads (which is
not possible with processes frozen - if we can find a way to make that
possible, then everything can be done in
Cleanup. A number of per_cpu_ptr(wq-cpu_wq, cpu) users have to check that cpu
is valid for this wq. Make a simple helper.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 6.20-rc6-mm3/kernel/workqueue.c~8_cpu_helper2007-02-16
23:27:06.0 +0300
+++ 6.20-rc6-mm3/kernel
Except for BUG_ON() checks, we should not use EXIT_ defines outside of
exit/wait paths.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 6.20-rc6-mm3/kernel/power/process.c~2006-12-17 19:06:41.0
+0300
+++ 6.20-rc6-mm3/kernel/power/process.c 2007-02-17 01:27:54.0
Don't use hardcoded 99 value, use MAX_RT_PRIO.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 6.20-rc6-mm3/kernel/softlockup.c~ 2006-10-22 18:24:03.0 +0400
+++ 6.20-rc6-mm3/kernel/softlockup.c2007-02-17 01:35:57.0 +0300
@@ -82,7 +82,7 @@ void softlockup_tick(void
On 02/16, Srivatsa Vaddagiri wrote:
Note with the change proposed in refrigerator, we can avoid
CPU_DEAD_KILL_THREADS and do all cleanup in CPU_DEAD itself.
In that case (all processes are frozen when workqueue_cpu_callback()
calls cleanup_workqueue_thread()) I agree, it is better to just use
Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
couple of questions.
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This doesn't look right. First, an exiting task has -mm == NULL
On 02/17, Srivatsa Vaddagiri wrote:
Yeah, thats what I thought. We will try to split it to the extent
possible in the next iteration.
Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage, we
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int is_user_space(struct task_struct *p)
{
return p-mm !(p-flags PF_BORROWED_MM);
}
This doesn't look right. First, an exiting task has -mm == NULL
On 02/18, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
Alternatively, we can move the check into refrigerator(), like this:
--- linux-2.6.20-git13.orig/kernel/power/process.c
+++ linux-2.6.20-git13/kernel/power/process.c
@@ -39,6 +39,11 @@ void refrigerator(void
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:47, Oleg Nesterov wrote:
However, this means that sys_vfork() makes impossible to freeze processes
until child exits/execs. Not good.
Yes, but this also is the current behavior.
Yes, yes, I see.
I forgot to say that we
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
static inline int is_user_space(struct task_struct *p
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
However, this means that sys_vfork() makes impossible to freeze
processes
until child exits/execs. Not good.
I forgot to say that we have another problem: coredumping.
A thread
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:32, Oleg Nesterov wrote:
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 00:42, Oleg Nesterov wrote:
On 02/17, Rafael J. Wysocki wrote:
On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 12:31, Oleg Nesterov wrote:
A very vague idea: what if parent will do
current-flags |= PF_PLEASE_CONSIDER_ME_AS_FROZEN_BUT_SET_TIF_FREEZE
wait_for_completion(vfork);
try_to_freeze();
?
Hm, what
On 02/18, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 15:52, Oleg Nesterov wrote:
And now another problem: exec. de_thread() sleeps in TASK_UNINTERRUPTIBLE
waiting for all sub-threads to die, and we have the same deadlock if
one of them is frozen. This is nasty. Probably we can
These patches change the code which I absolutely don't understand.
Compile tested. Please review.
Oleg.
-
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
Afaics, noautorel work_struct buys nothing for struct net_bridge_port.
If del_nbp()-cancel_delayed_work(p-carrier_check) fails, port_carrier_check
may be called later anyway. So the reading of *work in port_carrier_check() is
equally unsafe with or without this patch.
Signed-off-by: Oleg
pp_cam_entry-cb_task need not to be _NOAUTOREL ... because in fact it is
never used ???
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- WQ/drivers/media/video/cpia_pp.c~3_cpia_pp 2006-12-17 19:06:40.0
+0300
+++ WQ/drivers/media/video/cpia_pp.c2007-02-19 00:27:41.0 +0300
Looks like dbs_timer() is very careful wrt per_cpu(cpu_dbs_info),
and it doesn't need the help of WORK_STRUCT_NOAUTOREL.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- WQ/drivers/cpufreq/cpufreq_ondemand.c~2_cpufreq 2007-02-18
22:56:47.0 +0300
+++ WQ/drivers/cpufreq
On 02/18, Rafael J. Wysocki wrote:
Appended is a patch that does something along these lines. The necessary
thread_info flags are defined for i386 and x86_64, for now.
I'll try to look at this patch when I am not so sleepy ...
just one small nit right now,
---
refrigerator() can miss a wakeup, wait event loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- WQ/kernel/power/process.c~WAKE 2007-02-18 22:56:49.0 +0300
+++ WQ/kernel/power/process.c 2007-02-19 01:04:26.0 +0300
@@ -46,8 +46,10 @@ void
I have a small hope this patch is correct (compile tested). At least, the code
was not correct before this patch. Cancel and flush should do Cancel, and
then flush.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- WQ/drivers/ata/libata-core.c~4_ata 2007-02-18 22:56:47.0 +0300
+++ WQ
On 02/19, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
pp_cam_entry-cb_task need not to be _NOAUTOREL ... because in fact it is
never used ???
That's a remarkably good point. Did something get deleted since I made my
modifications?
At first I thought the same
On 02/19, David Howells wrote:
Oleg Nesterov [EMAIL PROTECTED] wrote:
Afaics, noautorel work_struct buys nothing for struct net_bridge_port.
You may be right.
If del_nbp()-cancel_delayed_work(p-carrier_check) fails,
port_carrier_check
may be called later anyway.
Called by what
On 02/19, Jarek Poplawski wrote:
On Mon, Feb 19, 2007 at 12:43:59AM +0300, Oleg Nesterov wrote:
Afaics, noautorel work_struct buys nothing for struct net_bridge_port.
If del_nbp()-cancel_delayed_work(p-carrier_check) fails,
port_carrier_check
may be called later anyway. So the reading
On 02/19, Pavel Machek wrote:
refrigerator() can miss a wakeup, wait event loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- WQ/kernel/power/process.c~WAKE 2007-02-18 22:56:49.0 +0300
+++ WQ/kernel/power/process.c 2007-02-19 01
On 02/19, David Howells wrote:
Hmmm... You've got a work_struct (well, a delayed_work actually) - can you
just punt the destruction of the object over to keventd to perform, I wonder?
Yes, this is close (I think) to what I suggested, see below,
The big problem with that that I see is that
On 02/19, Jarek Poplawski wrote:
On Mon, Feb 19, 2007 at 03:03:53PM +0300, Oleg Nesterov wrote:
On 02/19, Jarek Poplawski wrote:
...
kfree() doesn't check WORK_STRUCT_PENDING, it makes no
difference if it is set or not when work-func() runs.
It looks like it's to be checked before
On 02/19, Rafael J. Wysocki wrote:
On Sunday, 18 February 2007 23:01, Oleg Nesterov wrote:
--- linux-2.6.20-mm2.orig/include/asm-i386/thread_info.h 2007-02-18
19:49:34.0 +0100
+++ linux-2.6.20-mm2/include/asm-i386/thread_info.h 2007-02-18
19:50:37.0 +0100
On 02/19, Oleg Nesterov wrote:
I think the fix should be so that port_carrier_check() does get/put on
struct net_bridge_port (container), but not on struct net_device, and
del_nbp(struct net_bridge_port *p)
if (cancel_delayed_work(p-carrier_check))
- dev_put(p-dev
On 02/19, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 21:23, Oleg Nesterov wrote:
@@ -199,6 +189,10 @@ static void thaw_tasks(int thaw_user_spa
do_each_thread(g, p) {
+ if (freezer_should_skip(p))
+ cancel_freezing(p
On 02/20, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 23:41, Oleg Nesterov wrote:
On 02/19, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 21:23, Oleg Nesterov wrote:
@@ -199,6 +189,10 @@ static void thaw_tasks(int thaw_user_spa
do_each_thread(g
On 03/16, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
Sukadev Bhattiprolu wrote:
This means that idle threads (except swapper) are visible to
for_each_process()
and do_each_thread(). Looks dangerous and somewhat strange to me.
Could you explain this change
On 03/17, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
--- a/init/main.c~explicitly-set-pgid-and-sid-of-init-process
+++ a/init/main.c
@@ -783,6 +783,7 @@ static int __init init(void * unused)
*/
init_pid_ns.child_reaper
On 03/17, Oleg Nesterov wrote:
Well the initial kernel process does not have a struct pid so when
it's children start doing:
attach_pid(p, PIDTYPE_PGID, task_group(p));
attach_pid(p, PIDTYPE_SID, task_session(p));
We will get an oops.
So far this is the only reason to have
On 03/17, Eric W. Biederman wrote:
Oleg Nesterov [EMAIL PROTECTED] writes:
On 03/17, Oleg Nesterov wrote:
Well the initial kernel process does not have a struct pid so when
it's children start doing:
attach_pid(p, PIDTYPE_PGID, task_group(p));
attach_pid(p, PIDTYPE_SID
On 03/19, Eric Dumazet wrote:
+static inline unsigned long task_io_get_inblock(const struct task_struct *p)
+{
+ return p-ioac.read_bytes 9;
+}
[...snip...]
@@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw = p-signal-cnivcsw;
On 03/19, Eric Dumazet wrote:
[...snip...]
do {
utime = cputime_add(utime, t-utime);
@@ -2040,6 +2045,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw += t-nivcsw;
On 03/19, Davide Libenzi wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
+struct signalfd_ctx {
+ struct list_head lnk;
+ wait_queue_head_t wqh;
+ sigset_t sigmask;
+ struct task_struct *tsk;
+};
I think you want to use a struct pid *pid instead of a pointer to the
On 03/19, Davide Libenzi wrote:
On Mon, 19 Mar 2007, Oleg Nesterov wrote:
On 03/19, Davide Libenzi wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
+struct signalfd_ctx {
+ struct list_head lnk;
+ wait_queue_head_t wqh;
+ sigset_t sigmask
1 - 100 of 12526 matches
Mail list logo
