mutex: Place lock in contended state after fastpath_lock failure

ARM recently moved to asm-generic/mutex-xchg.h for its mutex
implementation after the previous implementation was found to be missing
some crucial memory barriers. However, this has revealed some problems
running hackbench on SMP platforms due to the way in which the
MUTEX_SPIN_ON_OWNER code operates.

The symptoms are that a bunch of hackbench tasks are left waiting on an
unlocked mutex and therefore never get woken up to claim it. This boils
down to the following sequence of events:

        Task A        Task B        Task C        Lock value
0                                                     1
1       lock()                                        0
2                     lock()                          0
3                     spin(A)                         0
4       unlock()                                      1
5                                   lock()            0
6                     cmpxchg(1,0)                    0
7                     contended()                    -1
8       lock()                                        0
9       spin(C)                                       0
10                                  unlock()          1
11      cmpxchg(1,0)                                  0
12      unlock()                                      1

At this point, the lock is unlocked, but Task B is in an uninterruptible
sleep with nobody to wake it up.

This patch fixes the problem by ensuring we put the lock into the
contended state if we fail to acquire it on the fastpath, ensuring that
any blocked waiters are woken up when the mutex is released.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Mason <chris.mason@fusionio.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@vger.kernel.org>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
ARM: 7495/1: mutex: use generic atomic_dec-based implementation for ARMv6+

Commit a76d7bd96d65 ("ARM: 7467/1: mutex: use generic xchg-based
implementation for ARMv6+") removed the barrier-less, ARM-specific
mutex implementation in favour of the generic xchg-based code.

Since then, a bug was uncovered in the xchg code when running on SMP
platforms, due to interactions between the locking paths and the
MUTEX_SPIN_ON_OWNER code. This was fixed in 0bce9c46bf3b ("mutex: place
lock in contended state after fastpath_lock failure"), however, the
atomic_dec-based mutex algorithm is now marginally more efficient for
ARM (~0.5% improvement in hackbench scores on dual A15).

This patch moves ARMv6+ platforms to the atomic_dec-based mutex code.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
block: fix infinite loop in __getblk_slow

Commit 080399aaaf35 ("block: don't mark buffers beyond end of disk as
mapped") exposed a bug in __getblk_slow that causes mount to hang as it
loops infinitely waiting for a buffer that lies beyond the end of the
disk to become uptodate.

The problem was initially reported by Torsten Hilbrich here:

    https://lkml.org/lkml/2012/6/18/54

and also reported independently here:

    http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511

and then Richard W.M.  Jones and Marcos Mello noted a few separate
bugzillas also associated with the same issue.  This patch has been
confirmed to fix:

    https://bugzilla.redhat.com/show_bug.cgi?id=835019

The main problem is here, in __getblk_slow:

        for (;;) {
                struct buffer_head * bh;
                int ret;

                bh = __find_get_block(bdev, block, size);
                if (bh)
                        return bh;

                ret = grow_buffers(bdev, block, size);
                if (ret < 0)
                        return NULL;
                if (ret == 0)
                        free_more_memory();
        }

__find_get_block does not find the block, since it will not be marked as
mapped, and so grow_buffers is called to fill in the buffers for the
associated page.  I believe the for (;;) loop is there primarily to
retry in the case of memory pressure keeping grow_buffers from
succeeding.  However, we also continue to loop for other cases, like the
block lying beond the end of the disk.  So, the fix I came up with is to
only loop when grow_buffers fails due to memory allocation issues
(return value of 0).

The attached patch was tested by myself, Torsten, and Rich, and was
found to resolve the problem in call cases.

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reported-and-Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
Cc: Stable <stable@vger.kernel.org>  # 3.0+
[ Jens is on vacation, taking this directly  - Linus ]
--
Stable Notes: this patch requires backport to 3.0, 3.2 and 3.3.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ext4: fix potential deadlock in ext4_nonda_switch()

In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle().  The problem is that we can be
holding i_mutex already, and this causes a potential deadlock when
writeback_inodes_sb_if_idle() when it tries to take s_umount.  (See
lockdep output below).

As it turns out we don't need need to hold s_umount; the fact that we
are in the middle of the write(2) system call will keep the superblock
pinned.  Unfortunately writeback_inodes_sb() checks to make sure
s_umount is taken, and the VFS uses a different mechanism for making
sure the file system doesn't get unmounted out from under us.  The
simplest way of dealing with this is to just simply grab s_umount
using a trylock, and skip kicking the writeback flusher thread in the
very unlikely case that we can't take a read lock on s_umount without
blocking.

Also, we now check the cirteria for kicking the writeback thread
before we decide to whether to fall back to non-delayed writeback, so
if there are any outstanding delayed allocation writes, we try to get
them resolved as soon as possible.

   [ INFO: possible circular locking dependency detected ]
   3.6.0-rc1-00042-gce894ca #367 Not tainted
   -------------------------------------------------------
   dd/8298 is trying to acquire lock:
    (&type->s_umount_key#18){++++..}, at: [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46

   but task is already holding lock:
    (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   which lock already depends on the new lock.

   2 locks held by dd/8298:
    #0:  (sb_writers#2){.+.+.+}, at: [<c01ddcc5>] generic_file_aio_write+0x56/0xd3
    #1:  (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   stack backtrace:
   Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367
   Call Trace:
    [<c015b79c>] ? console_unlock+0x345/0x372
    [<c06d62a1>] print_circular_bug+0x190/0x19d
    [<c019906c>] __lock_acquire+0x86d/0xb6c
    [<c01999db>] ? mark_held_locks+0x5c/0x7b
    [<c0199724>] lock_acquire+0x66/0xb9
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c06db935>] down_read+0x28/0x58
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
    [<c026f3b2>] ext4_nonda_switch+0xe1/0xf4
    [<c0271ece>] ext4_da_write_begin+0x27/0x193
    [<c01dcdb0>] generic_file_buffered_write+0xc8/0x1bb
    [<c01ddc47>] __generic_file_aio_write+0x1dd/0x205
    [<c01ddce7>] generic_file_aio_write+0x78/0xd3
    [<c026d336>] ext4_file_write+0x480/0x4a6
    [<c0198c1d>] ? __lock_acquire+0x41e/0xb6c
    [<c0180944>] ? sched_clock_cpu+0x11a/0x13e
    [<c01967e9>] ? trace_hardirqs_off+0xb/0xd
    [<c018099f>] ? local_clock+0x37/0x4e
    [<c0209f2c>] do_sync_write+0x67/0x9d
    [<c0209ec5>] ? wait_on_retry_sync_kiocb+0x44/0x44
    [<c020a7b9>] vfs_write+0x7b/0xe6
    [<c020a9a6>] sys_write+0x3b/0x64
    [<c06dd4bd>] syscall_call+0x7/0xb

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
slimport: anx7808: refactor the driver and minor updates

- refactor the driver
- Add a VGA Dongle into RX_VGA (00 22 b9 73 69 76 61)
- recovery when backuped dongle type != current dongle type

Change-Id: I3e4dbaac6085308b1997b6b871a5a52fd91c6972
slimport: anx7808: Fix the error handling

There are wrong error handling in probe(). For example, if you failed to
request the irq, you don't need to free the irq at that time. You just need
to free the irq after you requested the irq successfully.

Change-Id: I353e0cf79b71af760ba4d478fb39ab888e633d0a
slimport: anx7808: Remove the redundant codes, irq_set_irq_wake

enable_irq_wake is a wrapper function of irq_set_irq_wake(). So you don't need
to use irq_set_irq_wake().

Change-Id: I68ceeda1468b449ba32de63430e45dad5ebfeb15
slimport: anx7808: Fix the wake_lock exception

Possible to use the wake_lock in the interrupt handler before initializing
the wake lock. So you should initialize the wake_lock before using it.

Change-Id: I73c1de326403e24c5ba3dae9654cf6bc06f8ea93
slimport: anx7808: nullify the anx7808_client on removing the driver

When the driver is removed from the kernel, you should nullify the
anx7808_client to avoid wrong detecting the slimport cable.
Because it is used in slimport_is_connected().

Change-Id: Ia9cc580e0463e30008493e628a1d3ea9cb07377c
mako_defconfig: enable CONFIG_EXT4_FS_SECURITY

Signed-off-by: Iliyan Malchev <malchev@google.com>
netfilter: xt_qtaguid: remove AID_* dependency for access control

qtaguid limits what can be done with /ctrl and /stats based on group
membership.
This changes removes AID_NET_BW_STATS and AID_NET_BW_ACCT, and picks
up the groups from the gid of the matching proc entry files.

Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I42e477adde78a12ed5eb58fbc0b277cdaadb6f94
netfilter: xt_qtaguid: extend iface stat to report protocols

In the past the iface_stat_fmt would only show global bytes/packets
for the skb-based numbers.
For stall detection in userspace, distinguishing tcp vs other protocols
makes it easier.
Now we report
  ifname total_skb_rx_bytes total_skb_rx_packets total_skb_tx_bytes
  total_skb_tx_packets {rx,tx}_{tcp,udp,ohter}_{bytes,packets}

Bug: 6818637
Signed-off-by: JP Abgrall <jpa@google.com>
mako: Disable MSM VCAP

We doesn't use the MSM VCAP for vidoe capture and video processing

Change-Id: Ie61a5571c09526167618b0a6d6acb341c70c7708
mako: clean up codes on board-mako

Remove the unused codes from board-mako.c

Change-Id: I27576e7954de5a83ac3f0b08e5db28a82a1fc6e2
slimport: anx7808: Improve the cable detection

The device might fall in abnormal state in slimport with power on.
The slimport couldn't detect the cable correctly at that time.
We make a sure that the slimport is in power off before turning it on
to avoid that issue.

Change-Id: I119f17e3767221582d1d4330fdfa913552b84503
msm: camera: Fix the kernel crash on AF

Kernel should not use the memory of userspace directly. In msm actuator,
there is wrong use case of using the memory of userspace
in msm_actuator_move_focus. It might cause a kernel crash.
use copy_from_user to avoid that issue.

Change-Id: Icb0852a2358e708741f10c64b0ac429db08b536e
Signed-off-by: Iliyan Malchev <malchev@google.com>
prima: Fix build for GCC 4.7

Change-Id: I05cd4b04d54d39ef39b3130b5f84e59712baefd0
Fix build for GCC 4.7

Change-Id: I4e9265369174d82b55fd435bc47887972f99c9d4
mako: msm: hsic: Disallow processor idle sleep while driving resume signal

HSIC controller should send SOF with in 3 msec after completing
the resume signal.  If processor is in idle sleep state, the timer
interrupt generated by HSIC controller to indicate resume completion
gets delayed.  If the interrupt handler is not run with in 3msec
after resume, the resume sequence is repeated.  Disallow processor
idle sleep to avoid multiple resume cycles.

CRs-Fixed: 397154
Change-Id: Ie2c6f60b3a36f46f8246e2e0f41a64675df632a5
Signed-off-by: Iliyan Malchev <malchev@google.com>
mako: EHCI: HSIC: Allow standalone power collapse when HSIC is active

HSIC generates interrupt at 4ms interval. If idle power collapse
is enabled when HSIC is active, krait keeps on going into idle
power collapse requesting RPM to handle the sleep set requirement.
If HSIC interrupt comes after 4ms interval, krait comes out of idle
power collapse and it again ask RPM to handle this request therefore
keeps RPM busy handling requests due to frequent idle power collapse.
This has a power impact. Hence only allow standalone power collapse
when HSIC is active to avoid RPM involvement in assisting kraits to
power collapse. Vote for idle power collapse when HSIC goes to low
power mode.

Change-Id: I12d877b1489f26fea32b6e2026aaffea6b5858a9
Signed-off-by: Iliyan Malchev <malchev@google.com>