On Wed, 2006-06-21 at 21:41 +1000, Peter Williams wrote:
> Peter Williams wrote:
> > Matt Helsley wrote:
> >> On Wed, 2006-06-21 at 15:41 +1000, Peter Williams wrote:
> >>> On a related note, I can't see where the new task's notify field gets
> >>> initialized during fork.
> >>
> >> It's initialized in kernel/sys.c:notify_per_task_watchers(), which calls
> >> RAW_INIT_NOTIFIER_HEAD(&task->notify) in response to WATCH_TASK_INIT.
> >
> > I think that's too late. It needs to be done at the start of
> > notify_watchers() before any other watchers are called for the new task.
I don't see why you think it's too late. It needs to be initialized
before it's used. Waiting until notify_per_task_watchers() is called
with WATCH_TASK_INIT does this.
> On second thoughts, it would simpler just before the WATCH_TASK_INIT
> call in copy_process() in fork.c. It can be done unconditionally there.
>
> Peter
That would work. It would not simplify the control flow of the code.
The branch for WATCH_TASK_INIT in notify_per_task_watchers() is
unavoidable; we need to call the parent task's chain in that case since
we know the child task's is empty.
It is also counter to one goal of the patches -- reducing the "clutter"
in these paths. Arguably task watchers is the same kind of clutter that
existed before. However, it is a means of factoring such clutter into
fewer instances (ideally one) of the pattern.
Cheers,
-Matt Helsley
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
