Fix: Remove 'type' argument from access_ok() function (v5.0)

Fix: Remove 'type' argument from access_ok() function (v5.0)

See upstream commit :

  commit 96d4f267e40f9509e8a66e2b39e8b95655617693
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Thu Jan 3 18:57:57 2019 -0800

    Remove 'type' argument from access_ok() function

    Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
    of the user address range verification function since we got rid of the
    old racy i386-only code to walk page tables by hand.

    It existed because the original 80386 would not honor the write protect
    bit when in kernel mode, so you had to do COW by hand before doing any
    user access.  But we haven't supported that in a long time, and these
    days the 'type' argument is a purely historical artifact.

    A discussion about extending 'user_access_begin()' to do the range
    checking resulted this patch, because there is no way we're going to
    move the old VERIFY_xyz interface to that model.  And it's best done at
    the end of the merge window when I've done most of my merges, so let's
    just get this done once and for all.

    This patch was mostly done with a sed-script, with manual fix-ups for
    the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

    There were a couple of notable cases:

     - csky still had the old "verify_area()" name as an alias.

     - the iter_iov code had magical hardcoded knowledge of the actual
       values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
       really used it)

     - microblaze used the type argument for a debug printout

    but other than those oddities this should be a total no-op patch.

    I tried to fix up all architectures, did fairly extensive grepping for
    access_ok() uses, and the changes are trivial, but I may have missed
    something.  Any missed conversion should be trivially fixable, though.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>