On Tue, 2012-08-21 at 15:05 +0200, Eric Dumazet wrote: > From: Eric Dumazet <eduma...@google.com> > > It seems commit 4a9d4b02 (switch fput to task_work_add) reintroduced > the problem addressed in commit 944be0b2 (close_files(): add scheduling > point) > > If a server process with a lot of files (say 2 million tcp sockets) > is killed, we can spend a lot of time in task_work_run() and trigger > a soft lockup. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- > kernel/task_work.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/task_work.c b/kernel/task_work.c > index 91d4e17..d320d44 100644 > --- a/kernel/task_work.c > +++ b/kernel/task_work.c > @@ -75,6 +75,7 @@ void task_work_run(void) > p = q->next; > q->func(q); > q = p; > + cond_resched(); > } > } > }
We're here, because fput() called schedule_work() to delay the last fput(). The execution needs to take place before the syscall returns to userspace. Need to read __schedule()... Do you know if cond_resched() can guarantee that it will be executed before the return to userspace? thanks, Mimi -- 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/
