On Tue, 11 Dec 2012 15:44:50 +0100
din...@linux.vnet.ibm.com wrote:
> From: Dominik Dingel <din...@linux.vnet.ibm.com>
>
> page_mkwrite is initalized with zero and only set once, from that point
> exists no way to get to the oom or oom_free_new labels.
>
> Signed-off-by: Dominik Dingel <din...@linux.vnet.ibm.com>
> ---
> mm/memory.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 221fc9f..c322708 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2795,10 +2795,6 @@ oom_free_new:
> page_cache_release(new_page);
> oom:
> if (old_page) {
> - if (page_mkwrite) {
> - unlock_page(old_page);
> - page_cache_release(old_page);
> - }
> page_cache_release(old_page);
> }
> return VM_FAULT_OOM;
I hope you've checked all this carefully, including the "goto reuse"
and "goto gotten" paths. I *think* it's OK, but geeze. And the oom path
surely gets very little testing.
do_wp_page() has become truly awful. I'm wondering if we should
actually leave that code in there in case something changes in the
future and it becomes necessary.
With my compiler version this patch actually increases the size of
memory.o's text by 7 bytes. Odd.
Ho hum. You should also have done this:
--- a/mm/memory.c~mm-memoryc-remove-unused-code-from-do_wp_page-fix
+++ a/mm/memory.c
@@ -2780,9 +2780,8 @@ unlock:
oom_free_new:
page_cache_release(new_page);
oom:
- if (old_page) {
+ if (old_page)
page_cache_release(old_page);
- }
return VM_FAULT_OOM;
unwritable_page:
_
--
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/
