Signed-off-by: Paul Reioux <[email protected]>

This is first official GPL release based on my private implementation.

This release has been tested for xperia Z officially.  It may work
with other devices using the same WCD9320 Audio Codec as well, but not tested

Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

(Use this only for devices with audio reset issues)

Also bump version to 3.1

Signed-off-by: Paul Reioux <[email protected]>

wcd9xxx-core: add register write without mutex protection

This is assuming the calling function will take care of the mutex.

Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

bump to version 3.2

Signed-off-by: Paul Reioux <[email protected]>

Conflicts:
	sound/soc/codecs/wcd9320.c

Signed-off-by: Paul Reioux <[email protected]>

bump driver version to 3.3

Signed-off-by: Paul Reioux <[email protected]>

Bump driver version to 3.4

Change-Id: Idaf374634368e61ba1fc9e24d0c5e1a994271400
Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

with newer hardware revisions coming from Qualcomm, single register lock
control isn't sufficient to cover both playback and recording usage scenarios

bump to version 3.5

Signed-off-by: Paul Reioux <[email protected]>

bump version to 3.6

Signed-off-by: Paul Reioux <[email protected]>

Conflicts:
	drivers/video/msm/mdss/Kconfig
	drivers/video/msm/mdss/Makefile
	drivers/video/msm/mdss/mdss_mdp_pp.c

Conflicts:
	drivers/video/msm/mdss/Makefile
	drivers/video/msm/mdss/mdss_mdp_pp.c

Conflicts:
	drivers/video/msm/mdss/mdss_mdp_pp.c

Change-Id: I26a50aa6bfac69a6f5c8556f38ad9b6ba001374f

…savoca for the hint)

Conflicts:
	drivers/video/msm/mdss/mdss_mdp_pp.c

Change-Id: Iaaf6b6392d42de3faf9e1e6c897047de07ff9ff6

Conflicts:
	drivers/video/msm/mdss/mdss_mdp_pp.c

Change-Id: I58189840163ca38f890954c57b247cf41ec22c13

Change-Id: I702935e2d379099eef3ff8afd4be5072b7412519
Signed-off-by: Saatvik Shukla <[email protected]>

Intellithermal 2.0 is based on the latest Qualcomm thermal driver adapted for
in-kernel use and control.  Newer MSM8974+ chipsets should use this driver
going forward

Signed-off-by: Paul Reioux <[email protected]>

Conflicts:
	drivers/thermal/Kconfig
	drivers/thermal/Makefile
	include/linux/msm_thermal.h

Conflicts:
	include/linux/msm_thermal.h

Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

Signed-off-by: Paul Reioux <[email protected]>

After half a year of repeating research, a 5min google search and the help
of @oshmoun fixed it.

Dear Makefile: Fuck You.

Regards

Change-Id: I8c0fcb1e00d0789b47251434a13f8f7013636e0e

Signed-off-by: klozz <[email protected]>

Thanks to him for his work

Conflicts:
	arch/arm/mach-msm/msm-sleeper.c
	arch/arm/mach-msm/msm_mpdecision.c

Conflicts:
	arch/arm/configs/cm_shinano_sirius_defconfig

Change-Id: Ia916bbca960fcfc52409e813431502325b3b3994

Change-Id: Id4d39bb3e8b9da418890725dd0833a562473ffff

Conflicts:
	arch/arm/configs/cm_rhine_togari_row_defconfig

Conflicts:
	arch/arm/configs/z1_defconfig
	arch/arm/configs/z1c_defconfig

Change-Id: Idec891a3406d96e1eb9b5502f102586deffab3ce

If a user key gets negatively instantiated, an error code is cached in the
payload area.  A negatively instantiated key may be then be positively
instantiated by updating it with valid data.  However, the ->update key
type method must be aware that the error code may be there.

The following may be used to trigger the bug in the user key type:

    keyctl request2 user user "" @U
    keyctl add user user "a" @U

which manifests itself as:

	BUG: unable to handle kernel paging request at 00000000ffffff8a
	IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
	PGD 7cc30067 PUD 0
	Oops: 0002 [AOSPA-L#1] SMP
	Modules linked in:
	CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
	task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000
	RIP: 0010:[<ffffffff810a376f>]  [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
	 [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
	RSP: 0018:ffff88003dd8bdb0  EFLAGS: 00010246
	RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001
	RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82
	RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000
	R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82
	R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700
	FS:  0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
	CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0
	Stack:
	 ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
	 ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
	 ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
	Call Trace:
	 [<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
	 [<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
	 [<     inline     >] __key_update security/keys/key.c:730
	 [<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
	 [<     inline     >] SYSC_add_key security/keys/keyctl.c:125
	 [<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
	 [<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185

Note the error code (-ENOKEY) in EDX.

A similar bug can be tripped by:

    keyctl request2 trusted user "" @U
    keyctl add trusted user "a" @U

This should also affect encrypted keys - but that has to be correctly
parameterised or it will fail with EINVAL before getting to the bit that
will crashes.

Change-Id: I171d566f431c56208e1fe279f466d2d399a9ac7c
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David Howells <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Signed-off-by: James Morris <[email protected]>

Currently we don't check if the new MTU is valid or not and this allows
one to configure a smaller than minimum allowed by RFCs or even bigger
than interface own MTU, which is a problem as it may lead to packet
drops.

If you have a daemon like NetworkManager running, this may be exploited
by remote attackers by forging RA packets with an invalid MTU, possibly
leading to a DoS. (NetworkManager currently only validates for values
too small, but not for too big ones.)

The fix is just to make sure the new value is valid. That is, between
IPV6_MIN_MTU and interface's MTU.

Note that similar check is already performed at
ndisc_router_discovery(), for when kernel itself parses the RA.

Change-Id: I6b70d0c12a77c7932066982f8797d8024f130d7c
Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: Sabrina Dubroca <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

A userspace call to mmap(MAP_LOCKED) may result in the successful locking
of memory while also producing a confusing audit log denial.  can_do_mlock
checks capable and rlimit.  If either of these return positive
can_do_mlock returns true.  The capable check leads to an LSM hook used by
apparmour and selinux which produce the audit denial.  Reordering so
rlimit is checked first eliminates the denial on success, only recording a
denial when the lock is unsuccessful as a result of the denial.

Change-Id: I8d300365c8f85b002d6c5375a22abfb1b7579d20
Signed-off-by: Jeff Vander Stoep <[email protected]>
Acked-by: Nick Kralevich <[email protected]>
Cc: Jeff Vander Stoep <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Paul Cassella <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

commit 910ffdb upstream.

Cleanup and preparation for the next change.

signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.

Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
which adds __TASK_TRACED.

This way ptrace_signal_wake_up() can work "inside" ptrace_request()
even if the tracee doesn't have the TASK_WAKEKILL bit set.

Signed-off-by: Oleg Nesterov <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9899d11 upstream.

putreg() assumes that the tracee is not running and pt_regs_access() can
safely play with its stack.  However a killed tracee can return from
ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
that debugger can actually read/modify the kernel stack until the tracee
does SAVE_REST again.

set_task_blockstep() can race with SIGKILL too and in some sense this
race is even worse, the very fact the tracee can be woken up breaks the
logic.

As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
call, this ensures that nobody can ever wakeup the tracee while the
debugger looks at it.  Not only this fixes the mentioned problems, we
can do some cleanups/simplifications in arch_ptrace() paths.

Probably ptrace_unfreeze_traced() needs more callers, for example it
makes sense to make the tracee killable for oom-killer before
access_process_vm().

While at it, add the comment into may_ptrace_stop() to explain why
ptrace_stop() still can't rely on SIGKILL and signal_pending_state().

Reported-by: Salman Qazi <[email protected]>
Reported-by: Suleiman Souhlal <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 73af963 upstream.

__ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task !=
current, this can can lead to surprising results.

For example, a sub-thread can't readlink("/proc/self/exe") if the
executable is not readable.  setup_new_exec()->would_dump() notices that
inode_permission(MAY_READ) fails and then it does
set_dumpable(suid_dumpable).  After that get_dumpable() fails.

(It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we
could add PTRACE_MODE_NODUMPABLE)

Change __ptrace_may_access() to use same_thread_group() instead of "task
== current".  Any security check is pointless when the tasks share the
same ->mm.

Change-Id: Ib6ca927a1eb0637df8030aabcb3129d5be343512
Signed-off-by: Mark Grondona <[email protected]>
Signed-off-by: Ben Woodard <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream.

As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.

This disallows anybody without CAP_SYS_ADMIN to read the pagemap.

[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

[ Eventually we might want to do anything more finegrained, but for now
  this is the simple model.   - Linus ]

Change-Id: Ib62bf4429dcdafd9fc1cd9b1a0c5665c64cc5d18
Signed-off-by: Kirill A. Shutemov <[email protected]>
Acked-by: Konstantin Khlebnikov <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Mark Seaborn <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
[mancha: Backported to 3.10]
Signed-off-by: mancha security <[email protected]>

On multi core system, in below path, synchronization issue
can happen. tcp_set_state() should be used only on locked socket,
tcp_close access with proper lock, where as tcp_done is accessing
without any lock on socket.

bh_lock_sock just grabs the lock and not compete/spins for the
lock. This is recommended to be used from BH.

tcp_nuke_addr will be always called either from init function or
via icotl call and never called from bottom half, hence lock_sock
is the better approach.

tcp_done need to be called with bh_disable to avoid sync issue
within core

Panic Signature:
PC is at inet_put_port+0x7c/0xac
LR is at arch_timer_read_current_timer+0x14/0x18

Synchrnoization Issue explaind in CR
Core-0			  Core-1
------			  -------
release_sock
tcp_close		  inet_put_port
inet_release	          tcp_set_state
sock_release	          tcp_done
sock_close		  tcp_nuke_addr
fput			  devinet_ioctl
filp_close		  sock_ioctl

Change-Id: I6ededf1245e8ca46ad06b7135af96959a88fef62
Signed-off-by: Vijayakumar Gn <[email protected]>
Reviewed-on: http://gerrit.mot.com/719443
SLTApproved: Slta Waiver <[email protected]>
Tested-by: Jira Key <[email protected]>
Reviewed-by: Jeffrey Carlyle <[email protected]>
Submit-Approved: Jira Key <[email protected]>
Reviewed-by: Sudharsan Yettapu <[email protected]>

The actual size of the tcp hashinfo table is tcp_hashinfo.ehash_mask + 1
so we need to adjust the loop accordingly to get the sockets hashed into
the last bucket.

Change-Id: I796b3c7b4a1a7fa35fba9e5192a4a403eb6e17de
Signed-off-by: Dmitry Torokhov <[email protected]>

Make the keys garbage collector invoke synchronize_rcu() prior to destroying
keys with a zero usage count.  This means that a key can be examined under the
RCU read lock in the safe knowledge that it won't get deallocated until after
the lock is released - even if its usage count becomes zero whilst we're
looking at it.

This is useful in keyring search vs key link.  Consider a keyring containing a
link to a key.  That link can be replaced in-place in the keyring without
requiring an RCU copy-and-replace on the keyring contents without breaking a
search underway on that keyring when the displaced key is released, provided
the key is actually destroyed only after the RCU read lock held by the search
algorithm is released.

This permits __key_link() to replace a key without having to reallocate the key
payload.  A key gets replaced if a new key being linked into a keyring has the
same type and description.

Signed-off-by: David Howells <[email protected]>
Acked-by: Jeff Layton <[email protected]>

Conflicts:
	security/keys/gc.c

Change-Id: Ifd8549b5b906c638d63c358ce1f34acd81139207

Make use of the previous patch that makes the garbage collector perform RCU
synchronisation before destroying defunct keys.  Key pointers can now be
replaced in-place without creating a new keyring payload and replacing the
whole thing as the discarded keys will not be destroyed until all currently
held RCU read locks are released.

If the keyring payload space needs to be expanded or contracted, then a
replacement will still need allocating, and the original will still have to be
freed by RCU.

Change-Id: I6c4f784f120951fb51ac9c23856ea37f51770bb9
Signed-off-by: David Howells <[email protected]>

Add support for invalidating a key - which renders it immediately invisible to
further searches and causes the garbage collector to immediately wake up,
remove it from keyrings and then destroy it when it's no longer referenced.

It's better not to do this with keyctl_revoke() as that marks the key to start
returning -EKEYREVOKED to searches when what is actually desired is to have the
key refetched.

To invalidate a key the caller must be granted SEARCH permission by the key.
This may be too strict.  It may be better to also permit invalidation if the
caller has any of READ, WRITE or SETATTR permission.

The primary use for this is to evict keys that are cached in special keyrings,
such as the DNS resolver or an ID mapper.

Change-Id: I923ea0f0b8f9d6b3ff8ec8beca77b1774984f1c3
Signed-off-by: David Howells <[email protected]>

There appears to be a race between:

 (1) key_gc_unused_keys() which frees key->security and then calls
     keyring_destroy() to unlink the name from the name list

 (2) find_keyring_by_name() which calls key_permission(), thus accessing
     key->security, on a key before checking to see whether the key usage is 0
     (ie. the key is dead and might be cleaned up).

Fix this by calling ->destroy() before cleaning up the core key data -
including key->security.

Change-Id: I4b9b89af020e6348af095e9014bf23b5eb1a9ef9
Reported-by: Petr Matousek <[email protected]>
Signed-off-by: David Howells <[email protected]>

…ring

The following sequence of commands:

    i=`keyctl add user a a @s`
    keyctl request2 keyring foo bar @t
    keyctl unlink $i @s

tries to invoke an upcall to instantiate a keyring if one doesn't already
exist by that name within the user's keyring set.  However, if the upcall
fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
other error code.  When the key is garbage collected, the key destroy
function is called unconditionally and keyring_destroy() uses list_empty()
on keyring->type_data.link - which is in a union with reject_error.
Subsequently, the kernel tries to unlink the keyring from the keyring names
list - which oopses like this:

	BUG: unable to handle kernel paging request at 00000000ffffff8a
	IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
	...
	Workqueue: events key_garbage_collector
	...
	RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
	RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
	RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
	RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
	RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
	R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
	R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
	...
	CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
	...
	Call Trace:
	 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
	 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
	 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
	 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
	 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
	 [<ffffffff810648ad>] kthread+0xf3/0xfb
	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
	 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2

Note the value in RAX.  This is a 32-bit representation of -ENOKEY.

The solution is to only call ->destroy() if the key was successfully
instantiated.

Change-Id: Ia52370813b7e8231fdd99d2a208340af1c7b4007
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Dmitry Vyukov <[email protected]>

[ Upstream commit 1485348 ]

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit dec34fb ]

When SOCK_REFCNT_DEBUG is enabled, below build error is met:

kernel/sysctl_binary.o: In function `sk_refcnt_debug_release':
include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
kernel/sysctl.o:include/net/sock.h:1025: first defined here
kernel/audit.o: In function `sk_refcnt_debug_release':
include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release'
kernel/sysctl.o:include/net/sock.h:1025: first defined here
make[1]: *** [kernel/built-in.o] Error 1
make: *** [kernel] Error 2

So we decide to make sk_refcnt_debug_release static to eliminate
the error.

Signed-off-by: Ying Xue <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

	int socket_fd;
	struct sockaddr_in addr;
	addr.sin_port = 0;
	addr.sin_addr.s_addr = INADDR_ANY;
	addr.sin_family = 10;

	socket_fd = socket(10,3,0x40000000);
	connect(socket_fd , &addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
kernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
kernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110
kernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
kernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10
kernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

Change-Id: I653fad90da54908144cc8916c2dccb1fa6f14eed
CVE: CVE-2015-8543
Cc: Cong Wang <[email protected]>
Reported-by: 郭永刚 <[email protected]>
Signed-off-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit 716b539a12e21c1059ac43dee361fcd89e1d6c13)

Change-Id: I890640975f1af64f71947b6a1820249e08f6375b
Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit d0975b7d81105e1b07e4ae0334835792af3fff47)

commit 7e936b7 upstream.

A hard-linked directory to its parent can cause the VFS to deadlock,
and is a sign of a corrupted file system.  So detect this case in
ext4_lookup(), before the rmdir() lockup scenario can take place.

Signed-off-by: Andreas Dilger <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6a08f44 upstream.

ext4_special_inode_operations have their own ifdef CONFIG_EXT4_FS_XATTR
to mask those methods. And ext4_iget also always sets it, so there is
an inconsistency.

Signed-off-by: Bernd Schubert <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Add case-insensitive name lookup support.

Change-Id: I526d5e12a860d77878de4bc2d1d9c24d67ca9ce4
Signed-off-by: Russ Knize <[email protected]>
Reviewed-on: http://gerrit.mot.com/638188
Tested-by: Jira Key <[email protected]>
Reviewed-by: Igor Kovalenko <[email protected]>
Submit-Approved: Jira Key <[email protected]>
SLTApproved: Christopher Fries <[email protected]>

Instead of checking whether the handle is valid, we check if journal
is enabled. This avoids taking the s_orphan_lock mutex in all cases
when there is no journal in use, including the error paths where
ext4_orphan_del() is called with a handle set to NULL.

Signed-off-by: Anatol Pomozov <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>

Conflicts:
	fs/ext4/namei.c

Change-Id: I734ccb8069fceb12b864e7b9dceb37e27ab94c61
(cherry picked from commit d161fc0019a42fadedf851b4899872199c998cc2)

When trying to mount a file system which does not contain a journal,
but which does have a orphan list containing an inode which needs to
be truncated, the mount call with hang forever in
ext4_orphan_cleanup() because ext4_orphan_del() will return
immediately without removing the inode from the orphan list, leading
to an uninterruptible loop in kernel code which will busy out one of
the CPU's on the system.

This can be trivially reproduced by trying to mount the file system
found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
source tree.  If a malicious user were to put this on a USB stick, and
mount it on a Linux desktop which has automatic mounts enabled, this
could be considered a potential denial of service attack.  (Not a big
deal in practice, but professional paranoids worry about such things,
and have even been known to allocate CVE numbers for such problems.)

Change-Id: I743b57475420aec2b724c0ebc0288bbab3443e97
Signed-off-by: "Theodore Ts'o" <[email protected]>
Reviewed-by: Zheng Liu <[email protected]>
Cc: [email protected]
(cherry picked from commit c37aed1feca886bd61ca864756e57d08466ab0e5)

commit e2bfb08 upstream.

The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5.  In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.

Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure.  This means the
in-memory orphan list is corrupted, leading to a kernel oops.

In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.

Reported-by: Sami Liedes <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>

Conflicts:
	fs/ext4/namei.c

Change-Id: Id47f65995ae98a76555d2fd6f8fcfaa43dbd31f5
(cherry picked from commit 5c84767f87c5994b5c470ce17f919bdbf116fdcf)

Add a new intent flag to let the driver know to perform a case-
insensitive name lookup.

Change-Id: I2c62e23c6ea0415372cd58295baad08c50099e74
Signed-off-by: Russ Knize <[email protected]>
Reviewed-on: http://gerrit.mot.com/637406
Tested-by: Jira Key <[email protected]>
Reviewed-by: Christopher Fries <[email protected]>
SLTApproved: Christopher Fries <[email protected]>
Submit-Approved: Jira Key <[email protected]>

[ Upstream commit 30b678d ]

A peer (or local user) may cause TCP to use a nominal MSS of as little
as 88 (actual MSS of 76 with timestamps).  Given that we have a
sufficiently prodigious local sender and the peer ACKs quickly enough,
it is nevertheless possible to grow the window for such a connection
to the point that we will try to send just under 64K at once.  This
results in a single skb that expands to 861 segments.

In some drivers with TSO support, such an skb will require hundreds of
DMA descriptors; a substantial fraction of a TX ring or even more than
a full ring.  The TX queue selected for the skb may stall and trigger
the TX watchdog repeatedly (since the problem skb will be retried
after the TX reset).  This particularly affects sfc, for which the
issue is designated as CVE-2012-3412.

Therefore:
1. Add the field net_device::gso_max_segs holding the device-specific
   limit.
2. In netif_skb_features(), if the number of segments is too high then
   mask out GSO features to force fall back to software GSO.

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit c0de08d ]

If a packet is emitted on one socket in one group of fanout sockets,
it is transmitted again. It is thus read again on one of the sockets
of the fanout group. This result in a loop for software which
generate packets when receiving one.
This retransmission is not the intended behavior: a fanout group
must behave like a single socket. The packet should not be
transmitted on a socket if it originates from a socket belonging
to the same fanout group.

This patch fixes the issue by changing the transmission check to
take fanout group info account.

Reported-by: Aleksandr Kotov <[email protected]>
Signed-off-by: Eric Leblond <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

During rapid suspend/resume usecases assertive display is being turned
on with backlight level zero. When on command is received with backlight
level zero driver bails out with out turning on AD and doesn't signal
the client that worker queue has stopped processing which results in a
timeout for on command. Change will ensure that client is signalled if
driver is skipping the processing of AD due to backlight being zero.

Change-Id: Iaa6229f10ce54f44ec64c175f67ef7584ad4c8b2
Signed-off-by: Gopikrishnaiah Anandan <[email protected]>
Signed-off-by: Raghavendra Ambadas <[email protected]>

Change-Id: I4029fba1ff4659219338a91871fedea7e664f8d2

cmd-detected panels were suffering of lcd-backlight registration
issues: it was registering the backlight trigger on the first
panel read for detection kickstart, then failing to re-register
it on the real, detected panel (because of obvious reasons).

Fix the issue by adding detection awareness for backlight LED
trigger registration.

Change-Id: Ib3e948c2a2154093342f13cb91a06229e618be45