DESC
remap_file_pages protection support: readd lock downgrading
EDESC
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

Even now, we'll sometimes take the write lock.  So, in that case, we could
downgrade it; after a tiny bit of thought, I've choosen doing that when we'll
either do any I/O or we'll alter a lot of PTEs. About how much "a lot" is,
I've copied the values from this code in mm/memory.c:

#ifdef CONFIG_PREEMPT
# define ZAP_BLOCK_SIZE	(8 * PAGE_SIZE)
#else
/* No preempt: go for improved straight-line efficiency */
# define ZAP_BLOCK_SIZE	(1024 * PAGE_SIZE)
#endif

I'm not sure about the trade-offs - we used to have a down_write, now we have
a down_read() and a possible up_read()down_write(), and with this patch, the
fast-path still takes only down_read, but the slow path will do down_read(),
down_write(), downgrade_write(). This will increase the number of atomic
operation but increase concurrency wrt mmap and similar operations - I don't
know how much contention there is on that lock.

Also, drop a bust comment: we cannot clear VM_NONLINEAR simply because code
elsewhere is going to use it. At the very least, madvise_dontneed() relies on
that flag being set (remaining non-linear truncation read the mapping
list), but the list is probably longer and going to increase in the next
patches of this series.

Just in case this wasn't clear: this patch is not strictly related to
protection support, I was just too lazy to move it up in the hierarchy.
