In error paths, this was being called without struct_mutex held.
Leading to panics like:
msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU
Kernel panic - not syncing: BUG!
CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
[<ffffffc000089c78>] dump_backtrace+0x0/0x118
[<ffffffc000089da0>] show_stack+0x10/0x20
[<ffffffc0006686d4>] dump_stack+0x84/0xc4
[<ffffffc0006678b4>] panic+0xd0/0x210
[<ffffffc0003e1ce4>] drm_gem_object_free+0x5c/0x60
[<ffffffc000402870>] adreno_gpu_cleanup+0x60/0x80
[<ffffffc0004035a0>] a3xx_destroy+0x20/0x70
[<ffffffc0004036f4>] a3xx_gpu_init+0x84/0x108
[<ffffffc0004018b8>] adreno_load_gpu+0x58/0x190
[<ffffffc000419dac>] msm_open+0x74/0x88
[<ffffffc0003e0a48>] drm_open+0x168/0x400
[<ffffffc0003e7210>] drm_stub_open+0xa8/0x118
[<ffffffc0001a0e84>] chrdev_open+0x94/0x198
[<ffffffc000199f88>] do_dentry_open+0x208/0x310
[<ffffffc00019a4c4>] vfs_open+0x44/0x50
[<ffffffc0001aa26c>] do_last.isra.14+0x2c4/0xc10
[<ffffffc0001aac38>] path_openat+0x80/0x5e8
[<ffffffc0001ac354>] do_filp_open+0x2c/0x98
[<ffffffc00019b60c>] do_sys_open+0x13c/0x228
[<ffffffc00019b72c>] SyS_openat+0xc/0x18
CPU1: stopping
But there isn't any particularly good reason to hold struct_mutex for
teardown, so just standardize on calling it without the mutex held and
use the _unlocked() versions for GEM obj unref'ing
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since many releases, the modifications of the mvebu and berlin device
tree files are merged through the mvebu subsystem. This patch makes it
official in order to help the contributors using the get_maintainer.pl
to find the accurate peoples.
In the same time, updated the mvebu description which now includes the
kirkwood SoCs and new Armada SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Andrew Lunn <andrew@lunn.ch>
l2c_configure() does not follow the pattern of other l2c_* functions.
Fix this so that it does to avoid future confusion.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Before calling the controller specific configuration function, write
the auxiliary control register first, so that bits shared with other
registers (such as the prefetch control register) are not overwritten
by the later write to the auxctrl register.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
l2c_enable() is documented that it must not be called if the cache has
already been enabled. Unfortunately, commit 6b49241ac2 ("ARM: 8259/1:
l2c: Refactor the driver to use commit-like interface") changed this
without updating the comment, for very little reason. Revert this
change and restore the expected behaviour.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
GPLv2-only devicetrees make reuse difficult for software components licensed
under a different license.
The consensus is that a GPL/X11 dual-license should allow all necessary uses,
so relicense the rk3288-evb files to this combination.
CCs were aquired by git shortlog -sne so it should've hopefully catched
every contributor.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Doug Anderson <dianders@chromium.org>
Acked-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Caesar Wang <caesar.wang@rock-chips.com>
Acked-by: Romain Perier <romain.perier@gmail.com>
Acked-by: Chris Zhong<zyw@rock-chips.com>
Acked-by: Roger Chen <roger.chen@rock-chips.com>
Acked-by: Yunzhi Li <lyz@rock-chips.com>
on behalf of Rockchip
Acked-by: Eddie Cai <eddie.cai@rock-chips.com>
GPLv2-only devicetrees make reuse difficult for software components licensed
under a different license.
The consensus is that a GPL/X11 dual-license should allow all necessary uses,
so relicense the rk3288.dtsi to this combination.
CCs were aquired by git shortlog -sne so it should've hopefully catched
every contributor.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Doug Anderson <dianders@chromium.org>
Acked-by: Sonny Rao <sonnyrao@chromium.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Caesar Wang <caesar.wang@rock-chips.com>
Acked-by: Lin Huang <hl@rock-chips.com>
Acked-by: Chris Zhong <zyw@rock-chips.com>
Acked-by: Jianqun Xu<jay.xu@rock-chips.com>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Roger Chen <roger.chen@rock-chips.com>
Acked-by: Yunzhi Li <lyz@rock-chips.com>
on behalf of Rockchip
Acked-by: Eddie Cai <eddie.cai@rock-chips.com>
Josh Stone reports:
I've discovered a case where both arm and arm64 will miss a ptrace
syscall-exit that they should report. If the syscall is entered
without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's
then possible to have TIF_SYSCALL_TRACE added in the middle of the
syscall, but ret_fast_syscall doesn't check this flag again.
Fix this by always checking for a syscall trace in the fast exit path.
Reported-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
I2C drivers that support OF, have both an I2C and OF device ID tables
that are used to fill the supported module aliases. But currently the
I2C core only uses the OF table to match a device with a driver and
the aliases information are always reported in the form i2c:<name>.
The client->name is used as the name postfix and when booting with OF
this is obtained with of_modalias_node() which drops the compatible
string vendor prefix.
So for I2C drivers, the I2C and OF device ID tables should be keep in
sync in order to make module auto-loading to work but the I2C device
entries shouldn't have the vendor prefix since that is not reported.
Before this patch:
MODALIAS=i2c:ptn3460
$ modinfo | grep alias
alias: i2c:nxp,ptn3460
alias: of:N*T*Cnxp,ptn3460*
After this patch:
MODALIAS=i2c:ptn3460
$ modinfo | grep alias
alias: i2c:ptn3460
alias: of:N*T*Cnxp,ptn3460*
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Staticize dw_hdmi_bridge_funcs to fix the following sparse warning:
drivers/gpu/drm/bridge/dw_hdmi.c:1458:25: warning: symbol 'dw_hdmi_bridge_funcs' was not declared. Should it be static?
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The following NOP in a hot function caught my attention:
> 5a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
That's a dead NOP that bloats the function a bit, added for the
default 16-byte alignment that GCC applies for jump targets.
I realize that x86 CPU manufacturers recommend 16-byte jump
target alignments (it's in the Intel optimization manual),
to help their relatively narrow decoder prefetch alignment
and uop cache constraints, but the cost of that is very
significant:
text data bss dec filename
12566391 1617840 1089536 15273767 vmlinux.align.16-byte
12224951 1617840 1089536 14932327 vmlinux.align.1-byte
By using 1-byte jump target alignment (i.e. no alignment at all)
we get an almost 3% reduction in kernel size (!) - and a
probably similar reduction in I$ footprint.
Now, the usual justification for jump target alignment is the
following:
- modern decoders tend to have 16-byte (effective) decoder
prefetch windows. (AMD documents it higher but measurements
suggest the effective prefetch window on curretn uarchs is
still around 16 bytes)
- on Intel there's also the uop-cache with cachelines that have
16-byte granularity and limited associativity.
- older x86 uarchs had a penalty for decoder fetches that crossed
16-byte boundaries. These limits are mostly gone from recent
uarchs.
So if a forward jump target is aligned to cacheline boundary then
prefetches will start from a new prefetch-cacheline and there's
higher chance for decoding in fewer steps and packing tightly.
But I think that argument is flawed for typical optimized kernel
code flows: forward jumps often go to 'cold' (uncommon) pieces
of code, and aligning cold code to cache lines does not bring a
lot of advantages (they are uncommon), while it causes
collateral damage:
- their alignment 'spreads out' the cache footprint, it shifts
followup hot code further out
- plus it slows down even 'cold' code that immediately follows 'hot'
code (like in the above case), which could have benefited from the
partial cacheline that comes off the end of hot code.
But even in the cache-hot case the 16 byte alignment brings
disadvantages:
- it spreads out the cache footprint, possibly making the code
fall out of the L1 I$.
- On Intel CPUs, recent microarchitectures have plenty of
uop cache (typically doubling every 3 years) - while the
size of the L1 cache grows much less aggressively. So
workloads are rarely uop cache limited.
The only situation where alignment might matter are tight
loops that could fit into a single 16 byte chunk - but those
are pretty rare in the kernel: if they exist they tend
to be pointer chasing or generic memory ops, which both tend
to be cache miss (or cache allocation) intensive and are not
decoder bandwidth limited.
So the balance of arguments strongly favors packing kernel
instructions tightly versus maximizing for decoder bandwidth:
this patch changes the jump target alignment from 16 bytes
to 1 byte (tightly packed, unaligned).
Acked-by: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Aswin Chandramouleeswaran <aswin@hp.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Low <jason.low2@hp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Link: http://lkml.kernel.org/r/20150410120846.GA17101@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
A few triggers have status = MLME_SUCCESS and they are still
interesting. E.g. if we want to collect data upon deauth,
the status will be MLME_SUCCESS. Fix that.
Fixes: d42f535034 ("iwlwifi: mvm: add trigger for firmware dump upon MLME failures")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Disabling the clocks is a standard procedure while stopping the
device. On family 8000 however, disabling the bus master DMA clock
increases the NIC's power consumption.
To fix this, skip this call if the device family is
IWL_DEVICE_FAMILY_8000.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
3165 really needs to load iwlwifi-7265D-13.ucode. This
device is supported starting from -13.ucode, update the
MIN and OK defines accordingly. While at it, add 3165 to
the device list in the Kconfig file.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
One mistyped description and another mistyped target were corrected.
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Function pm_runtime_get_sync could fail and we need to check return
value to prevent kernel crash.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
User visible:
- Add --range option to show a variable's location range in 'perf probe',
helping in collecting variables in probes when there is a mismatch
between assembly and source code (He Kuang)
- Show better error message when failed to find variable in 'perf probe' (He Kuang)
- Fix 'perf report --thread' handling and document it better (Namhyung Kim)
Infrastructure:
- Fix to get negative exit codes in 'perf test' test routines (He Kuang)
- Make flex/bison calls honour V=1 (Jiri Olsa)
- Ignore tail calls to probed functions in 'perf probe' (Naveen N. Rao)
- Fix refcount expectations in map_group share 'perf test' (Arnaldo Carvalho de Melo)
Build Fixes:
- Fix 'perf kmem' build due to compiler thinking uninitialized var is
being accessed (Arnaldo Carvalho de Melo)
- Provide le16toh if not defined, to fix the libtraceevent build on
older distros (Arnaldo Carvalho de Melo)
- Fix 'perf trace' build on older distros by providing some CLOEXEC, NONBLOCK
defines (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVVSMDAAoJENZQFvNTUqpAr7oQALNU82mtTInwBc3nPTjDtQoQ
5/d7OQA2WSGi1Cm1XBerYuxFMUQUzlAGxFPl7qcDafaR1sI7WkzP2n5LqZZnvqoq
BpUPoKPXJg3Hetw2AoSwBzn54nf3X5zBLothtozj3qa+PtXa3oE2xI2pFKFuKI0D
qotub8G9G4HK5khI7B9WKNLZxunHmhCYWa1TteXHoIzFVSQaw9IqBa+S1Z4yRLF6
duIEsjrT72enFGBSo3mT39/2z5gkfa3hBI4h2PnC3P5jBlQ2H0PCEROi4PWo3cJY
9vWBSnFGNJiL+Qd+hwBJDArbujZC0ISUDix/UCkPcAqMCn0QLofG8ysRecc2/V9n
0ZWzttuPv4ci+5fVfAw146GYaTzxAcftVExy0Xsp3chR7rnCw8n67G/iNQjdxq51
csReveb0uqI/VpvyXXNQBWQs39Vj/qTYcaV65oudbOrfbA6kmr8GGJhnnGeeKpGQ
5y0GHLJ8iL3L3pTwMVQlNqCiSKOXb37HohHgdaCAa0qt41WFYSNEO4lv28HdQVtf
ftH9LP1r3JSCdtDTj18wy2slRvjO1qB6Zw55oU+LdEm56+CM9pX5i08d3LJWdYG2
zXfcJs28utIEiAVlacvs48Dl2gPDPdb45eF5VLWWPtivSirqOaN6HitSEdgmQVi0
OKDz6YMW1l26BlQtkdr+
=sU6z
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
User visible changes:
- Add --range option to show a variable's location range in 'perf probe',
helping in collecting variables in probes when there is a mismatch
between assembly and source code (He Kuang)
- Show better error message when failed to find variable in 'perf probe' (He Kuang)
- Fix 'perf report --thread' handling and document it better (Namhyung Kim)
Infrastructure changes:
- Fix to get negative exit codes in 'perf test' test routines (He Kuang)
- Make flex/bison calls honour V=1 (Jiri Olsa)
- Ignore tail calls to probed functions in 'perf probe' (Naveen N. Rao)
- Fix refcount expectations in map_group share 'perf test' (Arnaldo Carvalho de Melo)
Build Fixes:
- Fix 'perf kmem' build due to compiler thinking uninitialized var is
being accessed (Arnaldo Carvalho de Melo)
- Provide le16toh if not defined, to fix the libtraceevent build on
older distros (Arnaldo Carvalho de Melo)
- Fix 'perf trace' build on older distros by providing some CLOEXEC, NONBLOCK
defines (Arnaldo Carvalho de Melo)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
some minor cleanups
* 'drm-armada-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/armada: armada_drv: Remove unused function
drm/armada: armada_output: Remove some unused functions
tda998x: use helpers for infoframe.
* 'drm-tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()
fix one gpu hang on resume.
* tag 'drm-intel-fixes-2015-05-13' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Avoid GPU hang when coming out of s3 or s4
radeon minor fixes, and pci id addition.
* 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: don't do mst probing if MST isn't enabled.
drm/radeon: add new bonaire pci id
drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling
these guys are always declared next to each other; might as well put
the former (pointer to previous instance) into the latter and simplify
the calling conventions for {set,restore}_nameidata()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
a) make it reject ERR_PTR() for name
b) make it putname(name) on all other failure exits
c) make it return name on success
again, simplifies the callers
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
a) make it reject ERR_PTR() for name
b) make it putname(name) upon return in all other cases.
seriously simplifies the callers...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Otherwise we are risking a hard error where nonlazy restart would be the right
thing to do; it's a very narrow race with mount --move and most of the time it
ends up being completely harmless, but it's possible to construct a case when
we'll get a bogus hard error instead of falling back to non-lazy walk...
For one thing, when crossing _into_ overmount of parent we need to check for
mount_lock bumps when we get NULL from __lookup_mnt() as well.
For another, and less exotically, we need to make sure that the data fetched
in follow_up_rcu() had been consistent. ->mnt_mountpoint is pinned for as
long as it is a mountpoint, but we need to check mount_lock after fetching
to verify that.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The guidelines for adding automount support to a filesystem
in filesystems/automount-support.txt is out or date.
filesystems/autofs4.txt contains more current text, so replace
the out-of-date content with a reference to that.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
touch_atime is not RCU-safe, and so cannot be called on an RCU walk.
However, in situations where RCU-walk makes a difference, the symlink
will likely to accessed much more often than it is useful to update
the atime.
So split out the test of "Does the atime actually need to be updated"
into atime_needs_update(), and have get_link() unlazy if it finds that
it will need to do that update.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
