linux-user: Fix locking order in fork_start()
    
    Our locking order is that the tb lock should be taken
    inside the mmap_lock, but fork_start() grabs locks the
    other way around. This means that if a heavily multithreaded
    guest process (such as Java) calls fork() it can deadlock,
    with the thread that called fork() stuck in fork_start()
    with the tb lock and waiting for the mmap lock, but some
    other thread in tb_find() with the mmap lock and waiting
    for the tb lock. The cpu_list_lock() should also always be
    taken last, not first.
    
    Fix this by making fork_start() grab the locks in the
    right order. The order in which we drop locks doesn't
    matter, so we leave fork_end() the way it is.
    
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Cc: qemu-stable@nongnu.org
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
    Message-Id: <1512397331-15238-1-git-send-email-peter.maydell@linaro.org>
    Signed-off-by: Laurent Vivier <laurent@vivier.eu>
    (cherry picked from commit 024949caf32805f4cc3e7d363a80084b47aac1f6)
    Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>