- Use DMA'able addresses for DMA; rtsx_usb
- Use return value in the correct way; kempld-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVED3JAAoJEFGvii+H/Hdh0W0QAIG7pV1Br5K2DgkpMZlg88sa
WIP6G5frOJMdPwQ4+UPI68RMXEa4tman36cTju7vwUV/K6PnXeaiyofwHjNMX7xu
qvdmFGULD3AmJT4phtjZjO6UgrVqBvmIGMwYp8qSjV+eaKA9CbwfGdzqpatfOH94
m+JW6N+5GNAdpi4i6ZnhNWsMbDQz4q4ss5VZHMS6vFv3y3ByQjN+ojb/o5QRmIy5
45XWmnLSzjkwdgtAk9L9FnH1RJnl80kML0cmrjKPvWOX393WpmebjvEplYmOZ9sn
k2GhkDI9oU+GjmLakrZXOmz62Kr/DLgbIHJwA6y0Q7/3HqtoygnUyod2X91g6X7b
dN5bZluu1wx/sP6xrqKNJlMoW/gMyK8uUnfb7qXLEbqHKcLnMmVHOkgOEU9lkCt2
/j2u67vfuYmkZR3wHx8caWMD4pyBhOc6MkIUimPH5o6S+NjPK9f7Gm6584exw+N8
w4YGTDkIrlEc2xdPda4e8wkJjeh/Vlwt2jOb+vCN2ZbsJpv5HYLzWduBcV20RePn
6zgeQWJNAJFtcyWoqIXZF0nV27Fs0APFZyQ/QOf0ZhNeK+NvX0U0O6D9568z2kMw
PfnHCpif3f2ZF8gBRjxJIHhBtnTZ6RLR3b49eVNLSsJUf2rpMeAFhdoG9dM6ewpl
uIlHWnA68HecUhNVSQQS
=FZfe
-----END PGP SIGNATURE-----
Merge tag 'mfd-fixes-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD fixes from Lee Jones:
- Use DMA'able addresses for DMA; rtsx_usb
- Use return value in the correct way; kempld-core
* tag 'mfd-fixes-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
mfd: kempld-core: Fix callback return value check
mfd: rtsx_usb: Prevent DMA from stack
Tvrtko noticed a new warning on boot:
WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]()
Call Trace:
[<ffffffff8161f10c>] dump_stack+0x4f/0x7b
[<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0
[<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20
[<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm]
[<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915]
[<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915]
[<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915]
[<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915]
[<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm]
[<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm]
[<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915]
[<ffffffff813ad59c>] pci_device_probe+0x7c/0x100
[<ffffffff81466aad>] driver_probe_device+0x16d/0x380
We cannot take a reference at this point, not before
intel_framebuffer_init() and the underlying drm_framebuffer_init().
Introduced in:
commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
v2: Don't move update_state_fb(). It was moved around because I
originally put update_state_fb() in intel_alloc_plane_obj() before
finding a better place. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From drm-next:
(cherry picked from commit f55548b5af)
Signed-off-by: Dave Airlie <airlied@redhat.com>
A couple of driver specific fixes of the usual "important if you have
that device" kind together with a fix for a use after free bug that was
introduced into the trace code in some of the recent refactoring of the
message queue handling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVEdEPAAoJECTWi3JdVIfQADEIAIV7j0Ot7bkIBk9I5rxakQyI
TxiAmrFASSJ1Li9tyL56FAzH6rkKtCp7RZgtyAQ7+GS7p8vUmVphVJP+JYbFMJ8t
R7zdUg6YMphY1A2AjPgCskb33ZOWvy5V52+WmkSmVN+iTGgP8ixgdJKEwHQ+Ddjy
JhGDl5MI2G3ubV4d4Deyde4n4tvasvHiwYVo5QxQArbUSU/LbA+kHh2iJxA1kBWX
9x7PFM+SAOSgceddumA+pwvJBgd/52PkQZhSYCO+w40is1UxGlf39nqaYAPKV1Qv
EDVaVZ3C4UodbL9qxFBzGspf+ASBs/LbOOa+Dlk2eKsqJH1XiSuEF0fkKCA0wYA=
=x0qK
-----END PGP SIGNATURE-----
Merge tag 'spi-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of driver specific fixes of the usual "important if you have
that device" kind together with a fix for a use after free bug that
was introduced into the trace code in some of the recent refactoring
of the message queue handling"
* tag 'spi-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: trigger trace event for message-done before mesg->complete
spi: dw-mid: clear BUSY flag fist and test other one
spi: qup: Fix cs-num DT property parsing
Two fixes here, one typo fix in the documentation and one fix for a
system hang with one of the Palmas chips caused by the use of an
incorrect offset being provided for one of the registers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVEaIJAAoJECTWi3JdVIfQ54MH/2q047KXbu0SjJ36x0O/kpnw
zYZhnSSh2anSm64hZYaYEdZUOhsoWXT/iq8P6JSZnpJzQQ0DNiCvUEBWWoyG7cq/
wts6zc9dEJZND5gFFKbQX54Hi5JHAJXNBLqT57d69QJNIHtvXkk2ztIAjxbNu6z8
THnkWX4AFkcGY5ZBF3lrM/Ur3I3E1UWIeIM7hser5KvwPKxQYdV7K4ph4actmXZ/
zGU4oVO4pwSfpA/FKQtpuA3WL89eBSeICt1sleOqSvHhoSdmGbXjndxrkyC0kpeQ
j6DrkeO2dCmPqMoyzyoUPQLvELfwXVGuhemfOAdZtefE/vxH2zY9VKUlDHuL7Do=
=qhJo
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two fixes here, one typo fix in the documentation and one fix for a
system hang with one of the Palmas chips caused by the use of an
incorrect offset being provided for one of the registers"
* tag 'regulator-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix documentation for regmap in the config
regulator: palmas: Correct TPS659038 register definition for REGEN2
This patch fixes a bad interaction between the support that was added
for having regmaps without devices for early system controller
initialization and the trace support. There's a very good analysis of
the actual issue in the commit message for the change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVEGNEAAoJECTWi3JdVIfQO+oH/1E2Ho6+X0lIG1mAIC27fae+
XwxtVvUOjCMSPOJ2gg+++YSKc7KIgkxt/VHpw2VllgklYDz32hHloaX/NCfIFaAt
jqTcE+PEeNJgjiZ0qa9zidMeT+BakhsYYl1gwA+0NYVH6AQuwXhhlKdq5+0MmySB
QMCVmWcB/XdvIW5t1nGleahTxqaIRyFXGk1q4dArKjlWSolKrLJr1QHXVvgJBDWN
BTVuzI5WCzzCc1W4FHO6X91PQCEdc7eJxrCXGIuZ53nZlLx3YbhdKxHifibaxU4e
7pRFH1e5FI2jEYjcfDsYi71A+OuexXGHmq1Trm2uPaSIFsCTz32QzieyTD2Lfp8=
=eX90
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fix from Mark Brown:
"This patch fixes a bad interaction between the support that was added
for having regmaps without devices for early system controller
initialization and the trace support.
There's a very good analysis of the actual issue in the commit message
for the change"
* tag 'regmap-fix-v4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: introduce regmap_name to fix syscon regmap trace events
ucc_geth was indicating link up after a port is administratively enabled even
when nothing is plugged in. This causes user-space tools to see a spurious link
up the first time after boot.
Signed-off-by: Cliff Clark <cliff_clark@selinc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here's a single fix to isp1760 calling spin_unlock_irqsave()
as we should have.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVEZg2AAoJEIaOsuA1yqREjIwP/RktYewtVNJNrLL85lTYgYBX
gZOzkzE44UHa09ZGXYxQJHdHOV+r1VbjeqIcIVXg/FwqMiKcL8U7mP4CHUfz+rm0
N0WoE3vKUhGY66G2Wl8SIczxT3VsqQ02AT763NphOv4usZ+OBbb5tnGZJDDpVWBK
yCgIRbbNFxzy992RtA+4lMP8mHxFAq3tAkikT3M7DB2qRw29lyQ4PkBtKFp7HwpO
VmWGvxLPpBt6pQ1GoqgfYOLcRj+yrYH3fr9qpHRrSQfLXF7zSngfRQ9X2y/wIVVz
as4kOMH+1SnN01/8IUaojp4fEkBcM+cd7mU+J+5zJiDJXQqNt24TUiwEQAO6fbR7
0EO7qWmzZwMWNss/pA8HRJuO4rHXUFLBWoil6oqdDi9cTx4oPxN5g2V/WuIxAAim
HkqagNPvoXX9ok2JHTv9YHqAXbOMB87Zn3aW04pc0xNXvgVr168sB4pqJ5H/zMIr
NN2PypR4H9jcU8jURDGfjCMn5UMpIdAOwv964O945X5NxGDf2Si+Z4iJPHOXFMvs
bt4ccq+pKH2ckkkZO8hMrDq6q/uOxN5tzmMYvecJnDVORgPiwvK/J0sjnPz3UWmP
yyKmL342fVqK0H9b6aQteYliF5BAiFrTDSfSA0Tv9e4FfYkJTvcUisSvYQdPdOge
g4Sp/M2My3MORjEt1a7u
=0QMc
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fix for v4.0-rc6
Here's a single fix to isp1760 calling spin_unlock_irqsave()
as we should have.
Signed-off-by: Felipe Balbi <balbi@ti.com>
* A double free occured on an error path in due to an event registration issue.
The fix is the minimal change rather than possibly reworking this area of
the core to give a more elegant solution (future work).
* A number of drivers were directly accessing indio_dev->buffer->scan_mask
to identify the currently enabled channel set. This may not be correct
if we have additional clients on the push interface. The correct option
is indio_dev->active_scan_mask. This is fixed.
* bmc150 had incorrectly specified sampling frequency (a datasheet confusion
as they are specified in terms of bandwith - e.g. half the sampling
frequency).
* hmc5843 wasn't setting it's name and hence the name attribute was
returning an empty string.
* inv_mpu6050 wasn't clearing the locally held timestamp buffer when the
hardware fifo was reset. Also an inconsistency existed in the interface
for the scale of the channels. Magic numbers were written but real ones
were used for the reads. Now uses real numbers (i.e. not array indexes)
for both.
* fix a missing dependency in the dummy driver. Previously shielded from
the autobuilders by an earlier build error.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVBeZ7AAoJEFSFNJnE9BaIVl4QALH5o/kG81oiTTARzglCiV9z
gglyFnnRxGzAQXr7+VbptPlls68jG1/8UdzEhOrIFKY2zaU0jl0YKxZSF4irU6FY
RR7ZooNchMgVzH4I/byZBhFK/SEbRZTocTxCPPBMgQy5vFlK6sDoolQkqxZ2Oem7
eVmSpwO+maavrWtYgKovLB+lIb/Pm1xQ1ndijKjydUmlfF/4kHrRaR2PZYV1tujz
aXj8homGB7Yc6AOcjXZlm9+CFF9bdLFGUN3TyvdGRQLoMhIkrljrS/QX7McXt+93
Oo+x5nH7h0qsoxrJ0EMGVnbw1CqOXDHWne+3YONR+vZCyHWlO0P4KXXI8uLsyYOU
kPoy/CCW9CUfgAGxQ7NbF+7eB+nnxFeQ3vQttFuTQ/U7zVQTZu1GQVaaMPGJJopj
xHSbGUCW8e1DBkMZUKOQXANgdxR5HfW33hPDE5kS0rbR61fmlCXq/UDn0q9g/UUt
ZlloEphpFLb3nLTgb999d3dRKBGAqqdupq9n8XF/tu1nps2KP0/SClRUU9UFe62o
NRpkEEazfPfm0bspjE8zhFixR43/YpFeiVDyuGKZ0Y8QPkHtdVoutnzBSRoRXnig
VwRZcx9gYjv9FfZeJa6R/5je83jBKVBpMpYSj8L/f5dYCOEngsWEoa9YfH0vtc3m
JH21lKJPPAJDVVQP7aA5
=9ZzZ
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-4.0c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
3rd set of IIO fixes for the 4.0 cycle.
* A double free occured on an error path in due to an event registration issue.
The fix is the minimal change rather than possibly reworking this area of
the core to give a more elegant solution (future work).
* A number of drivers were directly accessing indio_dev->buffer->scan_mask
to identify the currently enabled channel set. This may not be correct
if we have additional clients on the push interface. The correct option
is indio_dev->active_scan_mask. This is fixed.
* bmc150 had incorrectly specified sampling frequency (a datasheet confusion
as they are specified in terms of bandwith - e.g. half the sampling
frequency).
* hmc5843 wasn't setting it's name and hence the name attribute was
returning an empty string.
* inv_mpu6050 wasn't clearing the locally held timestamp buffer when the
hardware fifo was reset. Also an inconsistency existed in the interface
for the scale of the channels. Magic numbers were written but real ones
were used for the reads. Now uses real numbers (i.e. not array indexes)
for both.
* fix a missing dependency in the dummy driver. Previously shielded from
the autobuilders by an earlier build error.
Without proper regulator support for individual boards, it is dangerous
to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
the frequency without the accompanying voltage increase, resulting in
an unstable system.
Remove them for now. We can revisit them with the new version of OPP
bindings, which support boost settings and frequency ranges, among
other things.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The Olimex A10-Lime is known to be unstable when running at 1008MHz.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
- extend/clarify explanations where necessary
- move comments from macro values to before the macro, to
make them more consistent, and to reduce preprocessor overhead
- sort GDT index and selector values likewise by number
- use consistent, modern kernel coding style across the file
- capitalize consistently
- use consistent vertical spacing
- remove the unused get_limit() method (noticed by Andy Lutomirski)
No change in code (verified with objdump -d):
64-bit defconfig+kvmconfig:
815a129bc1f80de6445c1d8ca5b97cad vmlinux.o.before.asm
815a129bc1f80de6445c1d8ca5b97cad vmlinux.o.after.asm
32-bit defconfig+kvmconfig:
e659ef045159ddf41a0771b33a34aae5 vmlinux.o.before.asm
e659ef045159ddf41a0771b33a34aae5 vmlinux.o.after.asm
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We currently have a race: if we're preempted during syscall
exit, we can fail to process syscall return work that is queued
up while we're preempted in ret_from_sys_call after checking
ti.flags.
Fix it by disabling interrupts before checking ti.flags.
Reported-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tejun Heo <tj@kernel.org>
Fixes: 96b6352c12 ("x86_64, entry: Remove the syscall exit audit")
Link: http://lkml.kernel.org/r/189320d42b4d671df78c10555976bb10af1ffc75.1427137498.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The THREAD_INFO() macro has a somewhat confusingly generic name,
defined in a generic .h C header file. It also does not make it
clear that it constructs a memory operand for use in assembly
code.
Rename it to ASM_THREAD_INFO() to make it all glaringly
obvious on first glance.
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/20150324184442.GC14760@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
On CONFIG_IA32_EMULATION=y kernels we set up
MSR_IA32_SYSENTER_CS/ESP/EIP, but on !CONFIG_IA32_EMULATION
kernels we leave them unchanged.
Clear them to make sure the instruction is disabled properly.
SYSCALL is set up properly in both cases.
Acked-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This file just defines a number of constants, and a few macros
and inline functions. It is particularly badly written.
For example, it is not trivial to see how descriptors are
numbered (you'd expect that should be easy, right?).
This change deobfuscates it via the following changes:
Group all GDT_ENTRY_foo together (move intervening stuff away).
Number them explicitly: use a number, not PREV_DEFINE+1, +2, +3:
I want to immediately see that GDT_ENTRY_PNPBIOS_CS32 is 18.
Seeing (GDT_ENTRY_KERNEL_BASE+6) instead is not useful.
The above change allows to remove GDT_ENTRY_KERNEL_BASE
and GDT_ENTRY_PNPBIOS_BASE, which weren't used anywhere else.
After a group of GDT_ENTRY_foo, define all selector values.
Remove or improve some comments. In particular:
Comment deleted as stating the obvious:
/*
* The GDT has 32 entries
*/
#define GDT_ENTRIES 32
"The segment offset needs to contain a RPL. Grr. -AK"
changed to
"Selectors need to also have a correct RPL (+3 thingy)"
"GDT layout to get 64bit syscall right (sysret hardcodes gdt
offsets)" expanded into a description *how exactly* sysret
hardcodes them.
Patch was tested to compile and not change vmlinux.o
on 32-bit and 64-bit builds (verified with objdump).
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Or Gerlitz says:
====================
mlx4 driver RC fixes
Ido's patch should go to -stable of >= 3.14 too, the issue is older but it
hits us with VXLAN for which driver support dates there.
As for Jack's fix, for the time being, picking it to 4.0 is OK.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We occasionally see in procedure mlx4_GEN_EQE that the driver tries
to grab an uninitialized mutex.
This can occur in only one of two ways:
1. We are trying to generate an async event on an uninitialized slave.
2. We are trying to generate an async event on an illegal slave number
( < 0 or > persist->num_vfs) or an inactive slave.
To deal with #1: move the mutex initialization from specific slave init
sequence in procedure mlx_master_do_cmd to mlx4_multi_func_init() (so that
the mutex is always initialized for all slaves).
To deal with #2: check in procedure mlx4_GEN_EQE that the slave number
provided is in the proper range and that the slave is active.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netdevice registration should be performed a the end of the driver
initialization flow. If we don't do that, after calling register_netdevice,
device callbacks may be issued by higher layers of the stack before
final configuration of the device is done.
For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued
after the register_netdev command. System network scripts may configure
the interface (UP) right after the registration, which also attach
unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called,
causing the firmware to fail the rule attachment.
Fixes: 837052d0cc ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling")
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* avoid panic with lots of IBSS stations
* Fix dvm's behavior after suspend resume
* Allow to keep connection after CSA failure
* Remove a noisy by harmless WARN_ON
* New device IDs
rtlwifi:
* fix IOMMU mapping leak in AP mode
brcmfmac:
* disable MBSS feature for BCM43362 to get AP mode working again
ath9k:
* disable Transmit Power Control (TPC) again due to regressions
* fix beaconing issue with AP+STA setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJVEQL4AAoJEG4XJFUm622boBwH/R61GyJvh2OieOfv35fv84N0
h4abht9N4gfogwJcF9AT0rPddo+ueYhD1pSYOS6pyM1d2OjhJq73vEVetCUKpX46
TpFw2hZOOZKj97flYyi7dPXQxGcUYLAzfqZ5Dn45czGuwMk/v3v+Ni3lzHUfmKvm
jrjHWKm2+WiJGRO7xJEmUAZoXTLEZdQtxLC3oViIeldhjsS5XQfx6K7mlp6L/7lC
zvHBSkLFEjjn6fMa17r9GgCsN7HkHuK8/tbXfbDyVw37bWte/6ZJv+1IUn6HPUKJ
mCRl5Sbs/+Rg0sqWaf1ygjGCghx9I7U4R9EvaZxpSnn+KjeeL4ibds2Lq+DoAaM=
=fEF3
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2015-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
iwlwifi:
* avoid panic with lots of IBSS stations
* Fix dvm's behavior after suspend resume
* Allow to keep connection after CSA failure
* Remove a noisy by harmless WARN_ON
* New device IDs
rtlwifi:
* fix IOMMU mapping leak in AP mode
brcmfmac:
* disable MBSS feature for BCM43362 to get AP mode working again
ath9k:
* disable Transmit Power Control (TPC) again due to regressions
* fix beaconing issue with AP+STA setup
Signed-off-by: David S. Miller <davem@davemloft.net>
Master change notifications may occur other than when joining or
leaving a bridge, for example when being added to or removed from
a bond or Open vSwitch.
Previously in those cases rocker_port_bridge_leave() was called
which results in a null-pointer dereference as rocker_port->bridge_dev
is NULL because there is no bridge device.
This patch makes provision for doing nothing in such cases.
Fixes: 6c70794500 ("rocker: implement L2 bridge offloading")
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The FIXUP_TOP_OF_STACK macro is only necessary because we don't save %r11
to pt_regs->r11 on SYSCALL64 fast path, but we want ptrace to see it populated.
Bite the bullet, add a single additional PUSH instruction, and remove
the FIXUP_TOP_OF_STACK macro.
The RESTORE_TOP_OF_STACK macro is already a nop. Remove it too.
On SandyBridge CPU, it does not get slower:
measured 54.22 ns per getpid syscall before and after last two
changes on defconfig kernel.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1426785469-15125-4-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
With this change, on SYSCALL64 code path we are now populating
pt_regs->cs, pt_regs->ss and pt_regs->rcx unconditionally and
therefore don't need to do that in FIXUP_TOP_OF_STACK.
We lose a number of large instructions there:
text data bss dec hex filename
13298 0 0 13298 33f2 entry_64_before.o
12978 0 0 12978 32b2 entry_64.o
What's more important, we convert two "MOVQ $imm,off(%rsp)" to
"PUSH $imm" (the ones which fill pt_regs->cs,ss).
Before this patch, placing them on fast path was slowing it down
by two cycles: this form of MOV is very large, 12 bytes, and
this probably reduces decode bandwidth to one instruction per cycle
when CPU sees them.
Therefore they were living in FIXUP_TOP_OF_STACK instead (away
from fast path).
"PUSH $imm" is a small 2-byte instruction. Moving it to fast path does
not slow it down in my measurements.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1426785469-15125-3-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one "sub $5*8,%rsp"
in syscall/sysenter code paths, where iret frame needs to be
created by hand.
Ironically, none of them benefits from this optimization,
since all of them need to allocate additional data on stack
(struct pt_regs), so they still have to perform subtraction.
This patch eliminates KERNEL_STACK_OFFSET.
PER_CPU_VAR(kernel_stack) now points directly to top of stack.
pt_regs allocations are adjusted to allocate iret frame as well.
Hopefully we can merge it later with 32-bit specific
PER_CPU_VAR(cpu_current_top_of_stack) variable...
Net result in generated code is that constants in several insns
are changed.
This change is necessary for changing struct pt_regs creation
in SYSCALL64 code path from MOV to PUSH instructions.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1426785469-15125-2-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This changes the THREAD_INFO() definition and all its callsites
so that they do not count stack position from
(top of stack - KERNEL_STACK_OFFSET), but from top of stack.
Semi-mysterious expressions THREAD_INFO(%rsp,RIP) - "why RIP??"
are now replaced by more logical THREAD_INFO(%rsp,SIZEOF_PTREGS)
- "calculate thread_info's address using information that
rsp is SIZEOF_PTREGS bytes below top of stack".
While at it, replace "(off)-THREAD_SIZE(reg)" with equivalent
"((off)-THREAD_SIZE)(reg)". The form without parentheses
falsely looks like we invoke THREAD_SIZE() macro.
Improve comment atop THREAD_INFO macro definition.
This patch does not change generated code (verified by objdump).
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1426785469-15125-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
this_cpu operations were implemented for arm64 in:
5284e1b arm64: xchg: Implement cmpxchg_double
f97fc81 arm64: percpu: Implement this_cpu operations
Unfortunately, it is possible for pre-emption to take place between
address generation and data access. This can lead to cases where data
is being manipulated by this_cpu for a different CPU than it was
called on. Which effectively breaks the spec.
This patch disables pre-emption for the this_cpu operations
guaranteeing that address generation and data manipulation take place
without a pre-emption in-between.
Fixes: 5284e1b4bc ("arm64: xchg: Implement cmpxchg_double")
Fixes: f97fc81079 ("arm64: percpu: Implement this_cpu operations")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Steve Capper <steve.capper@linaro.org>
[catalin.marinas@arm.com: remove space after type cast]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Commit a124820de5fd ("usb: isp1760: fix possible deadlock in
isp1760_udc_irq") replaced spin_{un,}lock with spin_{un,}lock_irq{save,restore}.
However it missed an error path resulting in the smatch warning as below:
drivers/usb/isp1760/isp1760-udc.c:1230 isp1760_udc_start() warn: inconsistent returns 'irqsave:flags'.
Locked on: line 1207
Unlocked on: line 1199
This patch fixes the spin unlock in the error path in isp1760_udc_start
thereby removing the smatch warning mentioned above.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In this routine, kzalloc allocates a memory block. This allocation is
freed in the error paths, but not in the normal exit, thus the allocation
is leaked.
The kmemleak facility was used to find the leak.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Intel Linux Wireless <ilw@linux.intel.com>
Having syscall32/sysenter32 initialization in a separate tiny
function, called from within a function that is already syscall
init specific, serves no real purpose.
Its existense also caused an unintended effect of having
wrmsrl(MSR_CSTAR) performed twice: once we set it to a dummy
function returning -ENOSYS, and immediately after
(if CONFIG_IA32_EMULATION), we set it to point to the proper
syscall32 entry point, ia32_cstar_target.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
On s390x, gcc 4.8 compiles this part of tcp_v6_early_demux()
struct dst_entry *dst = sk->sk_rx_dst;
if (dst)
dst = dst_check(dst, inet6_sk(sk)->rx_dst_cookie);
to code reading sk->sk_rx_dst twice, once for the test and once for
the argument of ip6_dst_check() (dst_check() is inline). This allows
ip6_dst_check() to be called with null first argument, causing a crash.
Protect sk->sk_rx_dst access by READ_ONCE() both in IPv4 and IPv6
TCP early demux code.
Fixes: 41063e9dd1 ("ipv4: Early TCP socket demux.")
Fixes: c7109986db ("ipv6: Early TCP socket demux")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Statistics' state-machine in bnx2x driver must be synced with various driver
flows, but its current locking scheme manages to be wasteful [using 2 locks +
additional local variable] and prone to race-conditions at the same time,
as the state-machine and 'action' are being accessed under different locks.
In addition, current 'safe exec' isn't in fact safe, since the only guarantee
it gives is that DMA transactions are over, but ramrods might still be running.
This patch cleans up said logic, leaving us with a single lock for the entire
flow and removing the possible races.
Changes from v2:
- Switched into mutex locking from semaphore locking.
- Release locks on error flows.
Changes from v1:
Failure to acquire lock fails flow instead of printing a warning and
allowing access to the critical section.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJVDxKcAAoJECte4hHFiupUnekP/3jO2DxsQoUypncz/r2oedxc
p+2cghl6q/r05T9B54MYBNwYsWtcySm5u3s1sH3Kym7+3IyH+u1wdhwkDA6wwOns
BOBa79uRmn20O41Ulr0R7HT+WNSkl+yxzeXk6ApEo4EtQmjw57+2ZVKNsf5c97k9
e9Mw9MR719u9Hgjzo7zLw1K/KYMAtZrG4L0PnZ5mAAkAxu4lpkopc/AygQnU+UJ9
Ru/pSl7H2PxwmFqRNio4m+6+D9zzsD/lORGCL8UXtgBDn26Fb25gZzusW2QIB6w6
/iO4Ri6KhD65ZzxkExjy4d5SgW02IvDRqbgBMYCPbg3Ffi3Cm++eW1gGuyhDBalt
CYJmjAqZ68hWJIvqBnkEeyH+DCZBD7aV21847QikDkdP+LlLOQmrOAM7EZt4Iur1
czO81mrfDQu/ACE7qos2irx/cpg/A4YGxXN9MQAvay91mRTOHm9S3vOzEagpiEfJ
2IdZT+SKNVFXgpjkVFPDS6j3PgvuG5J+NjPOiPHI+9X3Ly299ws8Wog2mLgmXMDo
YNjZZQAPcm66LAxKsycAWy8SpmQ9P+IIz9/daa22p5yuE+uR97FcfOISu1jPA2+p
e/sqpdLgPjOLE+cclb81WWzbmnhV2tenJW8aJL8v2UXaIWEmnMPgWeStqx+lTIx7
jpZg3VZQ20YBrdiMbO4I
=oX41
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-4.0-20150322' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2015-03-22
this is a pull-request of 7 patches for net/master.
Ahmed S. Darwish fixes another two problems in the kvaser_usb driver. A patch
by Colin Ian King for the gs_usb driver adds a missing check for kzalloc
allocation failures. Two patches by Stephane Grosjean for the peak_usb driver
add missing support for ISO / non-ISO mode switching. Andri Yngvason
contributes a patch to fix the state handling in the flexcan driver. The last
patch by Andreas Werner for the flexcan driver add missing EPROBE_DEFER
handling for the transceiver regulator.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in
commit 83f45fc360
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 6 09:10:18 2014 +0200
drm: Don't grab an fb reference for the idr
we've switched to weak references, broke that assumption but forgot to
fix it up.
Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.
But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.
Spotted by Matt Roper while reviewing other patches.
[airlied: pull this back into 4.0 - the oops happens there]
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
KVM guest can fail to startup with following trace on host:
qemu-system-x86: page allocation failure: order:4, mode:0x40d0
Call Trace:
dump_stack+0x47/0x67
warn_alloc_failed+0xee/0x150
__alloc_pages_direct_compact+0x14a/0x150
__alloc_pages_nodemask+0x776/0xb80
alloc_kmem_pages+0x3a/0x110
kmalloc_order+0x13/0x50
kmemdup+0x1b/0x40
__kvm_set_memory_region+0x24a/0x9f0 [kvm]
kvm_set_ioapic+0x130/0x130 [kvm]
kvm_set_memory_region+0x21/0x40 [kvm]
kvm_vm_ioctl+0x43f/0x750 [kvm]
Failure happens when attempting to allocate pages for
'struct kvm_memslots', however it doesn't have to be
present in physically contiguous (kmalloc-ed) address
space, change allocation to kvm_kvzalloc() so that
it will be vmalloc-ed when its size is more then a page.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
kvm_ioapic_update_eoi() wasn't called if directed EOI was enabled.
We need to do that for irq notifiers. (Like with edge interrupts.)
Fix it by skipping EOI broadcast only.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=82211
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Commit c4db59d31e ("fs: don't reassign dirty inodes to
default_backing_dev_info") exposed DM to a latent race in free_dev() vs
add_disk() in relation to management of the device's minor number.
Fix this by refactoring free_dev() to match cleanup order of the
alloc_dev() error path. Move cleanup of the gendisk, queue, and bdev
to _before_ the cleanup of the idr managed minor number.
Also, purely due to cleanup that fell out during the free_dev() audit:
- adjust dm_blk_close() to access the gendisk's private_data under
the _minor_lock spinlock.
- move __dm_destroy()'s dm_get_live_table() call out from under the
_minor_lock spinlock.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1202449
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.
However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set, an "Event Ring is Full" event
will be posted to the last entry of the event ring, but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring. That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.
This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c209 ("Intel xhci: Support EHCI/xHCI port switching.").
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Tested-by: Alistair Grant <akgrant0710@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.
Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).
This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().
[The commit log is based on initial Marvell patch posted at
http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
Reported-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Cc: stable <stable@vger.kernel.org> # v3.2+
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The idle_task_exit() function may call switch_mm() with next ==
&init_mm. On arm64, init_mm.pgd cannot be used for user mappings, so
this patch simply sets the reserved TTBR0.
Cc: <stable@vger.kernel.org>
Reported-by: Jon Medhurst (Tixy) <tixy@linaro.org>
Tested-by: Jon Medhurst (Tixy) <tixy@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Its ClickPad shares PNP ID "LEN2006" with the one in model E540 which is
already handled by the driver (both are Haswell iterations of the Edge
line, launched in 2014) but the dimensions it reports are different:
$ sudo ./touchpad-edge-detector /dev/input/event3
Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event3
Move one finger around the touchpad to detect the actual edges
Kernel says: x [1472..5044], y [1408..3398]
Touchpad sends: x [1024..5045], y [2457..4832] /^C
Fortunately we can use the board ID, which is also different, to
distinguish among them.
$ dmesg | grep -i synaptics
psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1,
caps: 0xd001a3/0x940300/0x127c00, board id: 2691, fw id: 1494646
psmouse serio1: synaptics: serio: Synaptics pass-through port at
isa0060/serio1/input0
input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input4
Board ID in E540 is 2722:
psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1,
caps: 0xd001a3/0x940300/0x127c00, board id: 2722, fw id: 1484859
(from https://launchpadlibrarian.net/179702965/BootDmesg.txt)
Signed-off-by: Ramiro Morales <cramm0@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull networking fixes from David Miller:
1) Validate iov ranges before feeding them into iov_iter_init(), from
Al Viro.
2) We changed copy_from_msghdr_from_user() to zero out the msg_namelen
is a NULL pointer is given for the msg_name. Do the same in the
compat code too. From Catalin Marinas.
3) Fix partially initialized tuples in netfilter conntrack helper, from
Ian Wilson.
4) Missing continue; statement in nft_hash walker can lead to crashes,
from Herbert Xu.
5) tproxy_tg6_check looks for IP6T_INV_PROTO in ->flags instead of
->invflags, fix from Pablo Neira Ayuso.
6) Incorrect memory account of TCP FINs can result in negative socket
memory accounting values. Fix from Josh Hunt.
7) Don't allow virtual functions to enable VLAN promiscuous mode in
be2net driver, from Vasundhara Volam.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
netfilter: nft_compat: set IP6T_F_PROTO flag if protocol is set
cx82310_eth: wait for firmware to become ready
net: validate the range we feed to iov_iter_init() in sys_sendto/sys_recvfrom
net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour
be2net: use PCI MMIO read instead of config read for errors
be2net: restrict MODIFY_EQ_DELAY cmd to a max of 8 EQs
be2net: Prevent VFs from enabling VLAN promiscuous mode
tcp: fix tcp fin memory accounting
ipv6: fix backtracking for throw routes
net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5}
ipv6: call ipv6_proxy_select_ident instead of ipv6_select_ident in udp6_ufo_fragment
netfilter: xt_TPROXY: fix invflags check in tproxy_tg6_check()
netfilter: restore rule tracing via nfnetlink_log
netfilter: nf_tables: allow to change chain policy without hook if it exists
netfilter: Fix potential crash in nft_hash walker
netfilter: Zero the tuple in nfnl_cthelper_parse_tuple()
Pull sparc fixes from David Miller:
"Some perf bug fixes from David Ahern, and the fix for that nasty
memmove() bug"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix several bugs in memmove().
sparc: Touch NMI watchdog when walking cpus and calling printk
sparc: perf: Add support M7 processor
sparc: perf: Make counting mode actually work
sparc: perf: Remove redundant perf_pmu_{en|dis}able calls
This model uses the same dock port as the previous generation.
Signed-off-by: Sebastian Wicki <gandro@gmx.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Firstly, handle zero length calls properly. Believe it or not there
are a few of these happening during early boot.
Next, we can't just drop to a memcpy() call in the forward copy case
where dst <= src. The reason is that the cache initializing stores
used in the Niagara memcpy() implementations can end up clearing out
cache lines before we've sourced their original contents completely.
For example, considering NG4memcpy, the main unrolled loop begins like
this:
load src + 0x00
load src + 0x08
load src + 0x10
load src + 0x18
load src + 0x20
store dst + 0x00
Assume dst is 64 byte aligned and let's say that dst is src - 8 for
this memcpy() call. That store at the end there is the one to the
first line in the cache line, thus clearing the whole line, which thus
clobbers "src + 0x28" before it even gets loaded.
To avoid this, just fall through to a simple copy only mildly
optimized for the case where src and dst are 8 byte aligned and the
length is a multiple of 8 as well. We could get fancy and call
GENmemcpy() but this is good enough for how this thing is actually
used.
Reported-by: David Ahern <david.ahern@oracle.com>
Reported-by: Bob Picco <bpicco@meloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
