Re: EXT3: problem with copy_from_user inside a transaction

From: Andrea Arcangeli
Date: Fri Sep 03 2004 - 07:43:13 EST


On Fri, Sep 03, 2004 at 03:05:21PM +0400, Andrey Savochkin wrote:
> Hi Andrew,
>
> filemap_copy_from_user() between prepare_write() and commit_write()
> appears to be a problem for ext3.
>
> prepare_write() starts a transaction, and if filemap_copy_from_user() causes
> a page fault, we'll have
> - order violation with mmap_sem taken inside a transaction (possible
> deadlocks),
> - __GFP_FS memory allocation with all re-entrancy problems (e.g.,
> current->journal_info corruption).
>
> Am I missing something?
>
> If this observation is correct, the possible solution is to call
> get_user_pages() or somehow pin the user pages before prepare_write(),
> although it will hurt performance...

yes, Chris is working on it for a few months.

just for the mmap_sem the easiest fix I proposed him, was to take the
mmap_sem in read mode before starting the transaction in prepare_write,
then the mmap_sem has to become recursive but that's trivial (my 2.4
rw semaphores are much simpler, they don't crash with million of
waiters, and they can support recursion).

however it seems the mmap_sem is not the only issue, he found another
issue with the page lock, maybe Chris you want to elaborate (the above
deadlock is absolutely clear, the one with the page lock less, btw, I
don't care much with reading the same page from disk that we're writing
to in the write syscall, that's a case we may just want to forbidden
since it makes no sense and currently it's racey even in 2.4, no pin
happens, but the prefaulting hides it).

We also hidden the above deadlock with prefaulting (but it's far from
fixed), prefaulting is a good idea anyways.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/