Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
GIT 14186fea0cb06bc43181ce239efe0df6f1af260a commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 Author: Josef Gajdusek <atx@atx.name> Date: Mon May 12 13:48:26 2014 +0200 hwmon: (emc1403) Support full range of known chip revision numbers The datasheet for EMC1413/EMC1414, which is fully compatible to EMC1403/1404 and uses the same chip identification, references revision numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers from 0x01 to 0x04 to make sure none are missed. Signed-off-by: Josef Gajdusek <atx@atx.name> Cc: stable@vger.kernel.org [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <linux@roeck-us.net> commit 8759f9046550f463098148bf577ccd32cdb895e3 Author: Jean Delvare <jdelvare@suse.de> Date: Mon May 12 11:44:51 2014 +0200 hwmon: (emc1403) Fix resource leak on module unload Commit 454aee17f claims to convert driver emc1403 to use devm_hwmon_device_register_with_groups, however the patch itself makes use of hwmon_device_register_with_groups instead. As the driver remove function was still dropped, the hwmon device is no longer unregistered on driver removal, leading to a resource leak. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups Cc: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org [3.13+] Signed-off-by: Guenter Roeck <linux@roeck-us.net> commit 17c048fc4bd95efea208a1920f169547d8588f1f Author: Josef Gajdusek <atx@atx.name> Date: Sun May 11 14:40:44 2014 +0200 hwmon: (emc1403) fix inverted store_hyst() Attempts to set the hysteresis value to a temperature below the target limit fails with "write error: Numerical result out of range" due to an inverted comparison. Signed-off-by: Josef Gajdusek <atx@atx.name> Reviewed-by: Jean Delvare <jdelvare@suse.de> Cc: stable@vger.kernel.org [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <linux@roeck-us.net> commit 1f53ba6e81749a420226e5502c49ab83ba85c81d Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Date: Thu May 8 15:48:13 2014 +0000 arm64: introduce virt_to_pfn virt_to_pfn has been defined in arch/arm/include/asm/memory.h by commit e26a9e0 "ARM: Better virt_to_page() handling" and Xen has come to rely on it. Introduce virt_to_pfn on arm64 too. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> commit dd18dbc2d42af75fffa60c77e0f02220bc329829 Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Date: Fri May 9 15:37:00 2014 -0700 mm, thp: close race between mremap() and split_huge_page() It's critical for split_huge_page() (and migration) to catch and freeze all PMDs on rmap walk. It gets tricky if there's concurrent fork() or mremap() since usually we copy/move page table entries on dup_mm() or move_page_tables() without rmap lock taken. To get it work we rely on rmap walk order to not miss any entry. We expect to see destination VMA after source one to work correctly. But after switching rmap implementation to interval tree it's not always possible to preserve expected walk order. It works fine for dup_mm() since new VMA has the same vma_start_pgoff() / vma_last_pgoff() and explicitly insert dst VMA after src one with vma_interval_tree_insert_after(). But on move_vma() destination VMA can be merged into adjacent one and as result shifted left in interval tree. Fortunately, we can detect the situation and prevent race with rmap walk by moving page table entries under rmap lock. See commit 38a76013ad80. Problem is that we miss the lock when we move transhuge PMD. Most likely this bug caused the crash[1]. [1] http://thread.gmane.org/gmane.linux.kernel.mm/96473 Fixes: 108d6642ad81 ("mm anon rmap: remove anon_vma_moveto_tail") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Acked-by: Michel Lespinasse <walken@google.com> Cc: Dave Jones <davej@redhat.com> Cc: David Miller <davem@davemloft.net> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: <stable@vger.kernel.org> [3.7+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> commit 3551a9280bcb728980a13783ff295e9f0bdedd9a Author: Catalin Marinas <catalin.marinas@arm.com> Date: Fri May 9 15:36:59 2014 -0700 mm: postpone the disabling of kmemleak early logging Commit 8910ae896c8c ("kmemleak: change some global variables to int"), in addition to the atomic -> int conversion, moved the disabling of kmemleak_early_log to the beginning of the kmemleak_init() function, before the full kmemleak tracing is actually enabled. In this small window, kmem_cache_create() is called by kmemleak which triggers additional memory allocation that are not traced. This patch restores the original logic with kmemleak_early_log disabling when kmemleak is fully functional. Fixes: 8910ae896c8c (kmemleak: change some global variables to int) Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Li Zefan <lizefan@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> commit f2eb7f6f7a18fc2eff2f74d2bfa12758c0449f12 Author: Cyril Hrubis <chrubis@suse.cz> Date: Fri May 9 15:36:58 2014 -0700 MAINTAINERS: update maintainership of LTP Also remove sf.net git repo which is no longer available and update link to LTP web pages. Signed-off-by: Cyril Hrubis <chrubis@suse.cz> Signed-off-by: Caspar Zhang <caspar@casparzhang.com> Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> commit 282cba6b00a95f0277ed71551e3f6b0477e8836b Author: Heiko Stuebner <heiko@sntech.de> Date: Fri May 9 15:36:57 2014 -0700 drivers/rtc/rtc-hym8563.c: set uie_unsupported The alarm of the hym8563 only supports a minute accuracy, while the uie wants an alarm one second in the future. Therefore things like the select() syscall will fail with a timeout, because the next alarm will happen in a worst case of 60 seconds. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> commit 90f4c5944b38b4647373db7a57a2dda1e0c5566a Author: Matt Porter <mporter@linaro.org> Date: Tue May 6 12:09:45 2014 -0400 MAINTAINERS: update Broadcom ARM tree location and add an SoC family The Broadcom ARM tree location has changed names to reflect other SoC families that are queued here. Also add the 216xx family as maintained. Signed-off-by: Matt Porter <mporter@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 Author: Sascha Hauer <s.hauer@pengutronix.de> Date: Tue May 6 13:01:34 2014 +0200 ARM: dts: i.MX53: Fix ipu register space size The IPU register space is 128MB, not 2GB. Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support' Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Shawn Guo <shawn.guo@freescale.com> Cc: <stable@vger.kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net> commit cf01f4eef9fe367ec0d85b38dd7214e29e376cdb Author: Jeff Layton <jlayton@poochiereds.net> Date: Fri May 9 11:41:54 2014 -0400 locks: only validate the lock vs. f_mode in F_SETLK codepaths v2: replace missing break in switch statement (as pointed out by Dave Jones) commit bce7560d4946 (locks: consolidate checks for compatible filp->f_mode values in setlk handlers) introduced a regression in the F_GETLK handler. flock64_to_posix_lock is a shared codepath between F_GETLK and F_SETLK, but the f_mode checks should only be applicable to the F_SETLK codepaths according to POSIX. Instead of just reverting the patch, add a new function to do this checking and have the F_SETLK handlers call it. Cc: Dave Jones <davej@redhat.com> Reported-and-Tested-by: Reuben Farrelly <reuben@reub.net> Signed-off-by: Jeff Layton <jlayton@poochiereds.net> commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec Author: Kinglong Mee <kinglongmee@gmail.com> Date: Fri Apr 18 20:49:04 2014 +0800 NFSD: Call ->set_acl with a NULL ACL structure if no entries After setting ACL for directory, I got two problems that caused by the cached zero-length default posix acl. This patch make sure nfsd4_set_nfs4_acl calls ->set_acl with a NULL ACL structure if there are no entries. Thanks for Christoph Hellwig's advice. First problem: ............ hang ........... Second problem: [ 1610.167668] ------------[ cut here ]------------ [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239! [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE) rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi [last unloaded: nfsd] [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G OE 3.15.0-rc1+ #15 [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti: ffff88005a944000 [ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>] [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP: 0018:ffff88005a945b00 EFLAGS: 00010293 [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX: 0000000000000000 [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI: ffff880068233300 [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09: 0000000000000000 [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12: ffff880068233300 [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15: ffff880068233300 [ 1610.168320] FS: 0000000000000000(0000) GS:ffff880077800000(0000) knlGS:0000000000000000 [ 1610.168320] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4: 00000000000006f0 [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1610.168320] Stack: [ 1610.168320] ffffffff00000000 0000000b67c83500 000000076700bac0 0000000000000000 [ 1610.168320] ffff88006700bac0 ffff880068233300 ffff88005a945c08 0000000000000002 [ 1610.168320] 0000000000000000 ffff88005a945b88 ffffffffa034e2d5 000000065a945b68 [ 1610.168320] Call Trace: [ 1610.168320] [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd] [ 1610.168320] [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd] [ 1610.168320] [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0 [ 1610.168320] [<ffffffffa0327962>] ? nfsd_setuser_and_check_port+0x52/0x80 [nfsd] [ 1610.168320] [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30 [ 1610.168320] [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd] [ 1610.168320] [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110 [nfsd] [ 1610.168320] [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd] [ 1610.168320] [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd] [ 1610.168320] [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc] [ 1610.168320] [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc] [ 1610.168320] [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd] [ 1610.168320] [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd] [ 1610.168320] [<ffffffff810a5202>] kthread+0xd2/0xf0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0 [ 1610.168320] [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40 [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce 41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c [ 1610.168320] RIP [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP <ffff88005a945b00> [ 1610.257313] ---[ end trace 838254e3e352285b ]--- Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit 4cb57e3032d4e4bf5e97780e9907da7282b02b0c Author: Trond Myklebust <trond.myklebust@primarydata.com> Date: Fri Apr 18 14:43:57 2014 -0400 NFSd: call rpc_destroy_wait_queue() from free_client() Mainly to ensure that we don't leave any hanging timers. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit 5694c93e6c4954fa9424c215f75eeb919bddad64 Author: Trond Myklebust <trond.myklebust@primarydata.com> Date: Fri Apr 18 14:43:56 2014 -0400 NFSd: Move default initialisers from create_client() to alloc_client() Aside from making it clearer what is non-trivial in create_client(), it also fixes a bug whereby we can call free_client() before idr_init() has been called. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 Author: NeilBrown <neilb@suse.de> Date: Tue May 6 09:36:08 2014 +1000 md: avoid possible spinning md thread at shutdown. If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because: 1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop. Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang. Cc: stable@vger.kernel.org (any kernel) Signed-off-by: NeilBrown <neilb@suse.de> commit cc13b1d1500656a20e41960668f3392dda9fa6e2 Author: NeilBrown <neilb@suse.de> Date: Mon May 5 13:34:37 2014 +1000 md/raid10: call wait_barrier() for each request submitted. wait_barrier() includes a counter, so we must call it precisely once (unless balanced by allow_barrier()) for each request submitted. Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 block: Introduce new bio_split() in 3.14-rc1, we don't call it for the extra requests generated when we need to split a bio. When this happens the counter goes negative, any resync/recovery will never start, and "mdadm --stop" will hang. Reported-by: Chris Murphy <lists@colorremedies.com> Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: stable@vger.kernel.org (3.14+) Cc: Kent Overstreet <kmo@daterainc.com> Signed-off-by: NeilBrown <neilb@suse.de> commit 36c38fb7144aa941dc072ba8f58b2dbe509c0345 Author: Tejun Heo <tj@kernel.org> Date: Mon May 5 12:37:30 2014 -0400 blkcg: use trylock on blkcg_pol_mutex in blkcg_reset_stats() During the recent conversion of cgroup to kernfs, cgroup_tree_mutex which nests above both the kernfs s_active protection and cgroup_mutex is added to synchronize cgroup file type operations as cgroup_mutex needed to be grabbed from some file operations and thus can't be put above s_active protection. While this arrangement mostly worked for cgroup, this triggered the following lockdep warning. ====================================================== [ INFO: possible circular locking dependency detected ] 3.15.0-rc3-next-20140430-sasha-00016-g4e281fa-dirty #429 Tainted: G W ------------------------------------------------------- trinity-c173/9024 is trying to acquire lock: (blkcg_pol_mutex){+.+.+.}, at: blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) but task is already holding lock: (s_active#89){++++.+}, at: kernfs_fop_write (fs/kernfs/file.c:283) which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (s_active#89){++++.+}: lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) __kernfs_remove (arch/x86/include/asm/atomic.h:27 fs/kernfs/dir.c:352 fs/kernfs/dir.c:1024) kernfs_remove_by_name_ns (fs/kernfs/dir.c:1219) cgroup_addrm_files (include/linux/kernfs.h:427 kernel/cgroup.c:1074 kernel/cgroup.c:2899) cgroup_clear_dir (kernel/cgroup.c:1092 (discriminator 2)) rebind_subsystems (kernel/cgroup.c:1144) cgroup_setup_root (kernel/cgroup.c:1568) cgroup_mount (kernel/cgroup.c:1716) mount_fs (fs/super.c:1094) vfs_kern_mount (fs/namespace.c:899) do_mount (fs/namespace.c:2238 fs/namespace.c:2561) SyS_mount (fs/namespace.c:2758 fs/namespace.c:2729) tracesys (arch/x86/kernel/entry_64.S:746) -> #1 (cgroup_tree_mutex){+.+.+.}: lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) cgroup_add_cftypes (include/linux/list.h:76 kernel/cgroup.c:3040) blkcg_policy_register (block/blk-cgroup.c:1106) throtl_init (block/blk-throttle.c:1694) do_one_initcall (init/main.c:789) kernel_init_freeable (init/main.c:854 init/main.c:863 init/main.c:882 init/main.c:1003) kernel_init (init/main.c:935) ret_from_fork (arch/x86/kernel/entry_64.S:552) -> #0 (blkcg_pol_mutex){+.+.+.}: __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182) lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) cgroup_file_write (kernel/cgroup.c:2714) kernfs_fop_write (fs/kernfs/file.c:295) vfs_write (fs/read_write.c:532) SyS_write (fs/read_write.c:584 fs/read_write.c:576) tracesys (arch/x86/kernel/entry_64.S:746) other info that might help us debug this: Chain exists of: blkcg_pol_mutex --> cgroup_tree_mutex --> s_active#89 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(s_active#89); lock(cgroup_tree_mutex); lock(s_active#89); lock(blkcg_pol_mutex); *** DEADLOCK *** 4 locks held by trinity-c173/9024: #0: (&f->f_pos_lock){+.+.+.}, at: __fdget_pos (fs/file.c:714) #1: (sb_writers#18){.+.+.+}, at: vfs_write (include/linux/fs.h:2255 fs/read_write.c:530) #2: (&of->mutex){+.+.+.}, at: kernfs_fop_write (fs/kernfs/file.c:283) #3: (s_active#89){++++.+}, at: kernfs_fop_write (fs/kernfs/file.c:283) stack backtrace: CPU: 3 PID: 9024 Comm: trinity-c173 Tainted: G W 3.15.0-rc3-next-20140430-sasha-00016-g4e281fa-dirty #429 ffffffff919687b0 ffff8805f6373bb8 ffffffff8e52cdbb 0000000000000002 ffffffff919d8400 ffff8805f6373c08 ffffffff8e51fb88 0000000000000004 ffff8805f6373c98 ffff8805f6373c08 ffff88061be70d98 ffff88061be70dd0 Call Trace: dump_stack (lib/dump_stack.c:52) print_circular_bug (kernel/locking/lockdep.c:1216) __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182) lock_acquire (arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602) mutex_lock_nested (kernel/locking/mutex.c:486 kernel/locking/mutex.c:587) blkcg_reset_stats (include/linux/spinlock.h:328 block/blk-cgroup.c:455) cgroup_file_write (kernel/cgroup.c:2714) kernfs_fop_write (fs/kernfs/file.c:295) vfs_write (fs/read_write.c:532) SyS_write (fs/read_write.c:584 fs/read_write.c:576) This is a highly unlikely but valid circular dependency between "echo 1 > blkcg.reset_stats" and cfq module [un]loading. cgroup is going through further locking update which will remove this complication but for now let's use trylock on blkcg_pol_mutex and retry the file operation if the trylock fails. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Sasha Levin <sasha.levin@oracle.com> References: http://lkml.kernel.org/g/5363C04B.4010400@oracle.com commit d2c2b11cfa134f4fbdcc34088824da26a084d8de Author: Aristeu Rozanski <aris@redhat.com> Date: Mon May 5 11:18:59 2014 -0400 device_cgroup: check if exception removal is allowed [PATCH v3 1/2] device_cgroup: check if exception removal is allowed When the device cgroup hierarchy was introduced in bd2953ebbb53 - devcg: propagate local changes down the hierarchy a specific case was overlooked. Consider the hierarchy bellow: A default policy: ALLOW, exceptions will deny access \ B default policy: ALLOW, exceptions will deny access There's no need to verify when an new exception is added to B because in this case exceptions will deny access to further devices, which is always fine. Hierarchy in device cgroup only makes sure B won't have more access than A. But when an exception is removed (by writing devices.allow), it isn't checked if the user is in fact removing an inherited exception from A, thus giving more access to B. Example: # echo 'a' >A/devices.allow # echo 'c 1:3 rw' >A/devices.deny # echo $$ >A/B/tasks # echo >/dev/null -bash: /dev/null: Operation not permitted # echo 'c 1:3 w' >A/B/devices.allow # echo >/dev/null # This shouldn't be allowed and this patch fixes it by making sure to never allow exceptions in this case to be removed if the exception is partially or fully present on the parent. v3: missing '*' in function description v2: improved log message and formatting fixes Cc: cgroups@vger.kernel.org Cc: Li Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Aristeu Rozanski <arozansk@redhat.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Tejun Heo <tj@kernel.org> commit 788296b2d19d16ec33aba0a5ad1544d50bb58601 Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Date: Wed Apr 30 14:56:28 2014 +0200 ARM: dts: kirkwood: fix mislocated pcie-controller nodes Commit 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") moved the pcie-controller nodes for the Kirkwood SoCs to the mbus bus node. For some reason, two boards were not properly converted and have their pci-controller nodes still in the ocp bus node. As the corresponding SoC pcie-controller does not exist anymore, it is likely that pcie is broken on those boards since above commit. Fix it by moving the pcie related nodes to the correct location. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") Cc: <stable@vger.kernel.org> # v3.12+ Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit f5f3cf6f7e49b9529fc00a2c4629fa92cf2755fe Author: Aristeu Rozanski <aris@redhat.com> Date: Thu Apr 24 15:33:21 2014 -0400 device_cgroup: fix the comment format for recently added functions Moving more extensive explanations to the end of the comment. Cc: Li Zefan <lizefan@huawei.com> Signed-off-by: Aristeu Rozanski <arozansk@redhat.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Tejun Heo <tj@kernel.org> commit 84e108fc7b23310fb6d93a657e47181d64ab6e93 Author: Maxime Ripard <maxime.ripard@free-electrons.com> Date: Mon Apr 28 11:44:36 2014 -0700 ARM: sunxi: Enable GMAC in sunxi_defconfig Since the support of the GMAC has been merged, we're using it as the ethernet controller on the A20 devices. However, sunxi_defconfig wasn't selecting it hence breaking the NFS boot. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> commit cf7eb979116c2568e8bc3b6a7269c7a359864ace Author: Thomas Gleixner <tglx@linutronix.de> Date: Sun Apr 13 20:44:46 2014 +0200 ARM: common: edma: Fix xbar mapping This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sekhar Nori <nsekhar@ti.com> commit a38670459d6883582bc360ee480f9fcec4900162 Author: Maxime Ripard <maxime.ripard@free-electrons.com> Date: Fri Apr 18 21:13:08 2014 +0200 ARM: sun7i: Fix i2c4 base address For some reason, the base address of the fifth I2C adapter in the A20 was incorrect. Change this to the actual base address. Reported-by: Marcus Cooper <codekipper@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Hans de Goede <hdegoede@redhat.com> commit 05a812ac474d0d6aef6d54b66bb08b81abde79c6 Author: Vladimir Murzin <murzin.v@gmail.com> Date: Sun Apr 27 10:09:12 2014 +0100 xen/events/fifo: correctly align bitops FIFO event channels require bitops on 32-bit aligned values (the event words). Linux's bitops require unsigned long alignment which may be 64-bits. On arm64 an incorrectly unaligned access will fault. Fix this by aligning the bitops along with an adjustment for bit position and using an unsigned long for the local copy of the ready word. Cc: stable@vger.kernel.org Signed-off-by: Vladimir Murzin <murzin.v@gmail.com> Tested-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org> Reviewed-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> commit 063aa8e68e53cc0d0961ea90c12cea40c6b94828 Author: Julien Grall <julien.grall@linaro.org> Date: Fri Apr 18 16:54:34 2014 +0100 arm/xen: Remove definiition of virt_to_pfn in asm/xen/page.h virt_to_pfn has been defined in asm/memory.h by the commit e26a9e0 "ARM: Better virt_to_page() handling" This will result of a compilation warning when CONFIG_XEN is enabled. arch/arm/include/asm/xen/page.h:80:0: warning: "virt_to_pfn" redefined [enabled by default] #define virt_to_pfn(v) (PFN_DOWN(__pa(v))) ^ In file included from arch/arm/include/asm/page.h:163:0, from arch/arm/include/asm/xen/page.h:4, from include/xen/page.h:4, from arch/arm/xen/grant-table.c:33: The definition in memory.h is nearly the same (it directly expand PFN_DOWN), so we can safely drop virt_to_pfn in xen include. Signed-off-by: Julien Grall <julien.grall@linaro.org> Signed-off-by: David Vrabel <david.vrabel@citrix.com> commit e247686085f71e9c25e3488ce83d5d0f77023438 Author: Andrew Lunn <andrew@lunn.ch> Date: Tue Apr 15 14:40:08 2014 +0200 ARM: Kirkwood: T5325: Fix double probe of Codec The codec is defined both in DT and the board file. The board file however contains platform data which is required in order that the codec works. When the DT instantiates the codec before the board files does, it is missing the platform data and so fails. Remove the DT node until we have a binding which can pass the additional data. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1397565608-1830-1-git-send-email-andrew@lunn.ch Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit d685058f5b878a71f99c8e2fd9707b3f49510b94 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Fri Apr 18 09:41:45 2014 +0200 ARM: mvebu: enable the SATA interface on Armada 375 DB The Armada 375 SoC has a dual-port SATA interface, which is exposed on the Armada 375 DB board. This commit therefore enables this interface on the Armada 375 DB board. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397806908-7550-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit ac164d1144f1a699d307bb05095e352ed6de236f Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Fri Apr 18 09:41:44 2014 +0200 ARM: mvebu: specify I2C bus frequency on Armada 370 DB In commit 249f3822509b74f8c8d0731aeb7ccea065376c9b ('ARM: mvebu: add audio support to Armada 370 DB'), the I2C bus 0 was enabled on the Armada 370 DB board, and an I2C codec was described as being connected on this bus. However, this commit forgot to define the I2C bus frequency, which leads the i2c-mv64xxx to fail probing, as it cannot calculate the baud rate multiplier/divisor to derive the I2C bus frequency from the core SoC frequency. It makes audio completely unusable, as the I2C bus is not probed, and therefore the audio codec is not probed either. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397806908-7550-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit 80fa10f4e9278c4df1636a26025b12588078ad61 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Tue Apr 15 15:50:21 2014 +0200 ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces The Armada XP GP isn't using rgmii-id connections between the MAC and PHY, but instead a single QSGMII connection, which is a quad-SGMII connection: a double pair of differential lines that are multiplexed to convey the traffic of four network interfaces between a MAC and a PHY. Until now, the Armada XP GP was relying on the bootloader setting the correct values in various configuration registers. With this change, the mvneta driver can be used as a module on this platform. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Arnaud Ebalard <arno@natisbad.org> Tested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit 6e20bae8a39c40d4e03698e4160bad2d2629062b Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Mon Apr 14 17:29:21 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') Cc: stable@vger.kernel.org # v3.10+ Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit f3aec8f3f05025e7b450102dae0759375346706e Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Mon Apr 14 17:29:20 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP DB Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') which was merged in v3.11. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') Cc: stable@vger.kernel.org # v3.11+ Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Mon Apr 14 17:29:19 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP GP Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') Cc: stable@vger.kernel.org # v3.10+ Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit 4c05160342f16361fc37ae34dcae9210306a83e9 Author: Suman Anna <s-anna@ti.com> Date: Tue Apr 22 17:23:37 2014 -0500 ARM: dts: AM3517: Disable absent IPs inherited from OMAP3 AM3517 inherits OMAP3 dts file, but does not have all the IPs that are present on OMAP3. This patch disables the following absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex. A label had to be added for IVA node in omap3.dtsi to be able to get a reference to the node for disabling. Otherwise we get the following warnings during booting: platform iva.2: Cannot lookup hwmod 'iva' platform 48094000.mailbox: Cannot lookup hwmod 'mailbox' platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp' platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva' Signed-off-by: Suman Anna <s-anna@ti.com> [tony@atomide.com: updated description for the warnings] Signed-off-by: Tony Lindgren <tony@atomide.com> commit 4fe5bd5da2ea7b1b8c9455246ddcdb39ab734487 Author: Suman Anna <s-anna@ti.com> Date: Tue Apr 22 17:23:36 2014 -0500 ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox The mailbox module is capable of generating two interrupts to MPU in OMAP2420, compared to one in OMAP2430. The second interrupt is to handle interrupts from the additional IVA processor present only on OMAP2420. Move the current common mailbox DT node into the SoC specific files to allow the above differentiation. Also, added back the interrupt-names on OMAP2420, that were previously defined in hwmod data. This fixes regression caused by the recent dropping of hwmod data in favor for defining it in the .dts files. Signed-off-by: Suman Anna <s-anna@ti.com> [tony@atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> commit 84d89c3123bf4c3145f7b19fca36dba612a69807 Author: Suman Anna <s-anna@ti.com> Date: Tue Apr 22 17:23:35 2014 -0500 ARM: dts: OMAP5: Add mailbox dt node to fix boot warning Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox IP is identical to that used in OMAP4. The OMAP5 hwmod data no longer publishes the module address space, so this patch fixes the WARN_ON backtrace associated with the following trace during the kernel boot: "omap_hwmod: mailbox: doesn't have mpu register target base". Otherwise we get a warning like this: WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc() omap_hwmod: mailbox: doesn't have mpu register target base Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 #45 [<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14) [<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94) [<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c) [<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40) [<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc) [<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c) [<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40) [<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160) [<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8) [<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4) [<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Suman Anna <s-anna@ti.com> [tony@atomide.com: updated description to for the warning] Signed-off-by: Tony Lindgren <tony@atomide.com> commit da0159fdb57d6fab54ce3179659a1f9e5b593752 Author: Joel Fernandes <joelf@ti.com> Date: Tue Apr 22 14:40:39 2014 -0500 ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This seems to be because the CPU is in ARM mode once the ROM hands over control to the kernel. Switch to Thumb-2 mode if required once the kernel is control of secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on entry so this is not required and SMP boot works as is. Also corrected a spurious '+' and updated copyright information. Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nishanth Menon <nm@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> commit 1ff3859e7ea134c09512498aa2251fd3a57d250d Author: Dave Gerlach <d-gerlach@ti.com> Date: Fri Mar 21 10:50:13 2014 +0530 ARM: dts: am437x-gp-evm: Do not reset gpio5 Do not reset GPIO5 at boot-up because GPIO5_7 is used on AM437x GP-EVM to control VTT regulators on DDR3. Without this some GP-EVM boards will fail to boot because of DDR3 corruption. Reported-by: Nishanth Menon <nm@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> commit ef139e130c8a18cc6cdaa2d98899f74e14389bd4 Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Date: Thu Apr 24 18:53:50 2014 +0200 ARM: dts: omap3-igep0020: use SMSC9221 timings The IGEPv2 board has a SMSC LAN9221i ethernet chip and not a SMSC LAN911x connected to the GPMC. Each chip needs different timings in order to operate correctly so is wrong to include omap-gpmc-smsc911x.dtsi instead of omap-gpmc-smsc9221.dtsi. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> [tony@atomide.com: this is needed to avoid potential memory corruption] Signed-off-by: Tony Lindgren <tony@atomide.com> commit a87c9ad956676d84d459739fc14ec5a3c3565717 Author: Jeff Layton <jlayton@redhat.com> Date: Wed Mar 26 07:24:23 2014 -0700 cifs: fix actimeo=0 corner case when cifs_i->time == jiffies actimeo=0 is supposed to be a special case that ensures that inode attributes are always refetched from the server instead of trusting the cache. The cifs code however uses time_in_range() to determine whether the attributes have timed out. In the case where cifs_i->time equals jiffies, this leads to the cifs code not refetching the inode attributes when it should. Fix this by explicitly testing for actimeo=0, and handling it as a special case. Reported-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com> commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Fri Apr 18 14:19:53 2014 +0200 PCI: mvebu: split PCIe BARs into multiple MBus windows when needed MBus windows are used on Marvell platforms to map certain peripherals in the physical address space. In the PCIe context, MBus windows are needed to map PCIe I/O and memory regions in the physical address. However, those MBus windows can only have power of two sizes, while PCIe BAR do not necessarily guarantee this. For this reason, the current pci-mvebu breaks on platforms where PCIe devices have BARs that don't sum up to a power of two size at the emulated bridge level. This commit fixes this by allowing the pci-mvebu driver to create multiple contiguous MBus windows (each having a power of two size) to cover a given PCIe BAR. To achieve this, two functions are added: mvebu_pcie_add_windows() and mvebu_pcie_del_windows() to respectively add and remove all the MBus windows that are needed to map the provided PCIe region base and size. The emulated PCI bridge code now calls those functions, instead of directly calling the mvebu-mbus driver functions. Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems') Cc: <stable@vger.kernel.org> # v3.11+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit b566e782be32145664d96ada3e389f17d32742e5 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Fri Apr 18 14:19:52 2014 +0200 bus: mvebu-mbus: allow several windows with the same target/attribute Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs have a size that isn't a power of two, and we therefore need to create several MBus windows to cover the PCIe BAR for a given PCIe interface. Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver') Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit 09752a12f430f58523fb6f435f5e30e4048fcfb2 Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Date: Fri Apr 18 14:19:51 2014 +0200 bus: mvebu-mbus: Avoid setting an undefined window size The mbus hardware requires a power of two size, and size aligned base. Currently, if a non-power of two is passed in to the low level routines they configure the register in a way that results in undefined behaviour. Call WARN and return EINVAL instead. Also, update the debugfs routines to show a message if there is an invalid register setting. All together this makes the recent problems with silent failure of PCI very obvious, noisy and debuggable. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit b6d07e0273d3296cfbdc88145b8a00ddbefb310a Author: Willy Tarreau <w@1wt.eu> Date: Fri Apr 18 14:19:50 2014 +0200 PCI: mvebu: fix off-by-one in the computed size of the mbus windows mvebu_pcie_handle_membase_change() and mvebu_pcie_handle_iobase_change() do not correctly compute the window size. PCI uses an inclusive start/end address pair, which requires a +1 when converting to size. This only worked because a bug in the mbus driver allowed it to silently accept and round up bogus sizes. Fix this by adding one to the computed size. Fixes: 45361a4fe446 ('PCIe driver for Marvell Armada 370/XP systems') Cc: <stable@vger.kernel.org> # v3.11+ Signed-off-by: Willy Tarreau <w@1wt.eu> Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit dcf2191933c4d3b3d1fcd8b6f5818cc913baa8b2 Author: Tony Lindgren <tony@atomide.com> Date: Wed Apr 23 11:04:42 2014 -0700 ARM: dts: Fix GPMC timings for LAN9220 I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz <chf.fritz@googlemail.com> Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Cc: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Tony Lindgren <tony@atomide.com> commit de9949a45ec05a9cd5b98eb0a5b5a65db252f1f3 Author: Tony Lindgren <tony@atomide.com> Date: Wed Apr 23 11:04:30 2014 -0700 ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree Looks like we have wrong GPMC timings we have for the cm-t and sbc-t boards. This can cause occasional strange errors with at least doing an rsync of large files or doing apt-get dist-upgrade. Let's fix the issue in two phases. First let's simplify cm-t and sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing the issue in multiple places. Then we can fix the timings in a single place with a follow-up patch. Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com> commit 20f670dcc08682e478770b48bd5fe09f19351674 Author: Tony Lindgren <tony@atomide.com> Date: Wed Apr 23 11:04:29 2014 -0700 ARM: dts: Fix bad OTG muxing for cm-t boards Looks like the OTG pins are off by 2 and we get this: pinctrl-single 48002030.pinmux: pin 480021a0.0 already requested by 49020000.serial; cannot claim for 480ab000.usb_otg_hs pinctrl-single 48002030.pinmux: pin-184 (480ab000.usb_otg_hs) status -22 pinctrl-single 48002030.pinmux: could not request pin 184 (480021a0.0) from group pinmux_hsusb0_pins on device pinctrl-single musb-omap2430 480ab000.usb_otg_hs: Error applying setting, reverse things back That's probably because the TRM lists the values as 32-bit registers so every second needs 2 added to the address. The OTG pin start range must start from 0x21a2, not 0x21a0. Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com> commit 79d719749d23234e9b725098aa49133f3ef7299d Author: Aristeu Rozanski <aris@redhat.com> Date: Mon Apr 21 12:13:03 2014 -0400 device_cgroup: rework device access check and exception checking Whenever a device file is opened and checked against current device cgroup rules, it uses the same function (may_access()) as when a new exception rule is added by writing devices.{allow,deny}. And in both cases, the algorithm is the same, doesn't matter the behavior. First problem is having device access to be considered the same as rule checking. Consider the following structure: A (default behavior: allow, exceptions disallow access) \ B (default behavior: allow, exceptions disallow access) A new exception is added to B by writing devices.deny: c 12:34 rw When checking if that exception is allowed in may_access(): if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { if (behavior == DEVCG_DEFAULT_ALLOW) { /* the exception will deny access to certain devices */ return true; Which is ok, since B is not getting more privileges than A, it doesn't matter and the rule is accepted Now, consider it's a device file open check and the process belongs to cgroup B. The access will be generated as: behavior: allow exception: c 12:34 rw The very same chunk of code will allow it, even if there's an explicit exception telling to do otherwise. A simple test case: # mkdir new_group # cd new_group # echo $$ >tasks # echo "c 1:3 w" >devices.deny # echo >/dev/null # echo $? 0 This is a serious bug and was introduced on c39a2a3018f8 devcg: prepare may_access() for hierarchy support To solve this problem, the device file open function was split from the new exception check. Second problem is how exceptions are processed by may_access(). The first part of the said function tries to match fully with an existing exception: list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) { if ((refex->type & DEV_BLOCK) && !(ex->type & DEV_BLOCK)) continue; if ((refex->type & DEV_CHAR) && !(ex->type & DEV_CHAR)) continue; if (ex->major != ~0 && ex->major != refex->major) continue; if (ex->minor != ~0 && ex->minor != refex->minor) continue; if (refex->access & (~ex->access)) continue; match = true; break; } That means the new exception should be contained into an existing one to be considered a match: New exception Existing match? notes b 12:34 rwm b 12:34 rwm yes b 12:34 r b *:34 rw yes b 12:34 rw b 12:34 w no extra "r" b *:34 rw b 12:34 rw no too broad "*" b *:34 rw b *:34 rwm yes Which is fine in some cases. Consider: A (default behavior: deny, exceptions allow access) \ B (default behavior: deny, exceptions allow access) In this case the full match makes sense, the new exception cannot add more access than the parent allows But this doesn't always work, consider: A (default behavior: allow, exceptions disallow access) \ B (default behavior: deny, exceptions allow access) In this case, a new exception in B shouldn't match any of the exceptions in A, after all you can't allow something that was forbidden by A. But consider this scenario: New exception Existing in A match? outcome b 12:34 rw b 12:34 r no exception is accepted Because the new exception has "w" as extra, it doesn't match, so it'll be added to B's exception list. The same problem can happen during a file access check. Consider a cgroup with allow as default behavior: Access Exception match? b 12:34 rw b 12:34 r no In this case, the access didn't match any of the exceptions in the cgroup, which is required since exceptions will disallow access. To solve this problem, two new functions were created to match an exception either fully or partially. In the example above, a partial check will be performed and it'll produce a match since at least "b 12:34 r" from "b 12:34 rw" access matches. Cc: cgroups@vger.kernel.org Cc: Tejun Heo <tj@kernel.org> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: Li Zefan <lizefan@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Aristeu Rozanski <arozansk@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> commit 35d35aae817706800a4913711d563a99e1dc380a Author: Tushar Behera <tushar.behera@linaro.org> Date: Thu Mar 6 11:34:43 2014 +0530 dt-bindings: clock: Move at91.h to dt-bindigs/clock Most of the clock related dt-binding header files are located in dt-bindings/clock folder. It would be good to keep all the similar header files at a single location. Signed-off-by: Tushar Behera <tushar.behera@linaro.org> CC: Rob Landley <rob@landley.net> CC: Andrew Victor <linux@maxim.org.za> CC: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Acked-by: Boris BREZILLON <b.brezillon.dev@gmail.com> [nicolas.ferre@atmel.com: add new at91sam9261 & at91sam9rl] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> commit d44db494a8d5aa2060240e7a770bbb8fefa2d2b1 Author: Bo Shen <voice.shen@atmel.com> Date: Tue Apr 1 15:12:43 2014 +0800 ARM: at91: fix spi cs on sama5d3 Xplained board The PD16 is the CS3 for SPI0 while not SPI1. Signed-off-by: Bo Shen <voice.shen@atmel.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> commit 77668c8b559e4fe2acf2a0749c7c83cde49a5025 Author: Lai Jiangshan <laijs@cn.fujitsu.com> Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: fix a possible race condition between rescuer and pwq-release There is a race condition between rescuer_thread() and pwq_unbound_release_workfn(). Even after a pwq is scheduled for rescue, the associated work items may be consumed by any worker. If all of them are consumed before the rescuer gets to them and the pwq's base ref was put due to attribute change, the pwq may be released while still being linked on @wq->maydays list making the rescuer dereference already freed pwq later. Make send_mayday() pin the target pwq until the rescuer is done with it. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org # v3.10+ commit 4d595b866d2c653dc90a492b9973a834eabfa354 Author: Lai Jiangshan <laijs@cn.fujitsu.com> Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: make rescuer_thread() empty wq->maydays list before exiting After a @pwq is scheduled for emergency execution, other workers may consume the affectd work items before the rescuer gets to them. This means that a workqueue many have pwqs queued on @wq->maydays list while not having any work item pending or in-flight. If destroy_workqueue() executes in such condition, the rescuer may exit without emptying @wq->maydays. This currently doesn't cause any actual harm. destroy_workqueue() can safely destroy all the involved data structures whether @wq->maydays is populated or not as nobody access the list once the rescuer exits. However, this is nasty and makes future development difficult. Let's update rescuer_thread() so that it empties @wq->maydays after seeing should_stop to guarantee that the list is empty on rescuer exit. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org # v3.10+ commit e37a06f10994c2ba86f54d8f96734f2483a869b8 Author: Li Zefan <lizefan@huawei.com> Date: Thu Apr 17 13:53:08 2014 +0800 cgroup: fix the retry path of cgroup_mount() If we hit the retry path, we'll call parse_cgroupfs_options() again, but the string we pass to it has been modified by the previous call to this function. This bug can be observed by: # mount -t cgroup -o name=foo,cpuset xxx /mnt && umount /mnt && \ mount -t cgroup -o name=foo,cpuset xxx /mnt mount: wrong fs type, bad option, bad superblock on xxx, missing codepage or helper program, or other error ... The second mount passed "name=foo,cpuset" to the parser, and then it hit the retry path and call the parser again, but this time the string passed to the parser is "name=foo". To fix this, we avoid calling parse_cgroupfs_options() again in this case. Signed-off-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> commit 1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Sun Apr 13 16:39:38 2014 +0200 ARM: orion5x: fix target ID for crypto SRAM window In commit 4ca2c04085a1caa903e92a5fc0da25362150aac2 ('ARM: orion5x: Move to ID based window creation'), the mach-orion5x code was changed to use the new mvebu-mbus API. However, in the process, a mistake was made on the crypto SRAM window target ID: it should have been 0x9 (verified in the datasheet) and not 0x0. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: https://lkml.kernel.org/r/1397400006-4315-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 4ca2c04085a1 ('ARM: orion5x: Move to ID based window creation') Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: Jason Cooper <jason@lakedaemon.net> commit ce965c3d2e68c5325dd5624eb101d70423022fef Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Mon Apr 14 17:29:18 2014 +0200 memory: mvebu-devbus: fix the conversion of the bus width According to the Armada 370 and Armada XP datasheets, the part of the Device Bus register that configure the bus width should contain 0 for a 8 bits bus width, and 1 for a 16 bits bus width (other valu…
- Loading branch information