[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090415115858.AC31.A69D9226@jp.fujitsu.com>
Date: Wed, 15 Apr 2009 12:00:16 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Jeff Moyer <jmoyer@...hat.com>
Cc: kosaki.motohiro@...fujitsu.com,
LKML <linux-kernel@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Jens Axboe <jens.axboe@...cle.com>, linux-api@...r.kernel.org,
Linus Torvalds <torvalds@...l.org>,
Andrew Morton <akpm@...l.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Andrea Arcangeli <aarcange@...hat.com>, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC][PATCH v3 4/6] aio: Don't inherit aio ring memory at fork
Hi
> > drawback worst aio scenario here
> > -----------------------------------------------------------------------
> > io_setup() and gup inc page_count
> >
> > fork inc mapcount
> > and make write-protect to pte
> >
> > write ring from userland(*) page fault and
> > COW break.
> > parent process get copyed page and
> > child get original page owner-ship.
> >
> > kmap and memcpy from kernel change child page. (it mean data lost)
> >
> > (*) Is this happend?
>
> I guess it's possible, but I don't know of any programs that do this.
Yup, I also think this isn't happen in real world.
>
> > MADV_DONTFORK or down_read(mmap_sem) or down_read(mm_pinned_sem)
> > or copy-at-fork mecanism(=Nick/Andrea patch) solve it.
>
> OK, thanks for the explanation.
>
> + /*
> + * aio context doesn't inherit while fork. (see mm_init())
> + * Then, aio ring also mark DONTFORK.
> + */
>
> Would you mind if I did some word-smithing on that comment? Something
> like:
> /*
> * The io_context is not inherited by the child after fork()
> * (see mm_init). Therefore, it makes little sense for the
> * completion ring to be inherited.
> */
>
> + ret = sys_madvise(info->mmap_base, info->mmap_size, MADV_DONTFORK);
> + BUG_ON(ret);
> +
>
> It appears there's no other way to set the VM_DONTCOPY flag, so I guess
> calling sys_madvise is fine. I'm not sure I agree with the BUG_ON(ret),
> however, as EAGAIN may be feasible.
>
> So, fix that up and you can add my reviewed-by. I think you should push
> this patch independent of the other patches in this series.
Done :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists