On Fri, May 17, 2013 at 11:17:08AM -0700, Zach Brown wrote:
> > I ended up working on this a bit today, and managed to cobble together
> > something that somewhat works -- please see the patch below.
>
> Just some quick observations:
>
> > + ctx->ctx_file = anon_inode_getfile("[aio]", &aio_ctx_fops, ctx, O_RDWR);
> > + if (IS_ERR(ctx->ctx_file)) {
> > + ctx->ctx_file = NULL;
> > + return -EAGAIN;
> > + }
>
> It's too bad that aio contexts will now be accounted against the filp
> limits (get_empty_filp -> files_stat.max_files, etc).
Yeah, that is a downside of this approach. It would be possible to to
do it with only an inode/address_space, but that would mean bypassing
do_mmap(), which is not worth considering. If it is really an issue, we
could add a flag to bypass that limit since aio has its own.
anon_inode_getfile() as it stands is a major problem.
> > + for (i=0; i<nr_pages; i++) {
> > + struct page *page;
> > + void *ptr;
> > + page = find_or_create_page(ctx->ctx_file->f_inode->i_mapping,
> > + i, GFP_KERNEL);
> > + if (!page) {
> > + break;
> > + }
> > + ptr = kmap(page);
> > + clear_page(ptr);
> > + kunmap(page);
> > + SetPageUptodate(page);
> > + SetPageDirty(page);
> > + unlock_page(page);
> > + }
>
> If they're GFP_KERNEL then you don't need to kmap them. But we probably
> want to allocate with GFP_HIGHUSER and then use clear_user_highpage() to
> zero them?
Adding __GFP_ZERO would fix that too. The next respin will include that
change. I also have to properly handle the mremap() case as well.
-ben
--
"Thought is the essence of where you are now."
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
