Same behavior than 802.1q : finds the encapsulated protocol and
skip 32bit header.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix ipgre_header() (header_ops->create) to return the correct
amount of bytes pushed. Most callers of dev_hard_header() seem
to care only if it was success, but af_packet.c uses it as
offset to the skb to copy from userspace only once. In practice
this fixes packet socket sendto()/sendmsg() to gre tunnels.
Regression introduced in c544193214
("GRE: Refactor GRE tunneling code.")
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We want the data stored in "addr" and "qual", but the extra ampersands
mean we are copying stack data instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
to be DMA-able, which stack is not.
Patch is only compile tested.
Cc: stable@vger.kernel.org
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
device_close()->recalc_sigpending() is not needed, sigprocmask() takes
care of TIF_SIGPENDING correctly.
And without ->siglock it is racy and wrong, it can wrongly clear
TIF_SIGPENDING and miss a signal.
But even with this patch device_close() is still buggy:
1. sigprocmask() should not be used, we have set_task_blocked(),
but this is minor.
2. We should never block SIGKILL or SIGSTOP, and this is what
the code tries to do.
3. This can't protect against SIGKILL or SIGSTOP anyway. Another
thread can do signal_wake_up(), say, do_signal_stop() or
complete_signal() or debugger.
4. sigprocmask(SIG_BLOCK, allsigs) doesn't necessarily clears
TIF_SIGPENDING, say, freezing() or ->jobctl.
5. device_write() looks equally wrong by the same reason.
Looks like, this tries to protect some wait_event_interruptible() logic
from signals, it should be turned into uninterruptible wait. Or we need
to implement something like signals_stop/start for such a use-case.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 407a2c2a4d.
Explanation provided by Benjamin Tissoires:
Commit "HID: hid-logitech-dj, querying_devices was never set" activate
a flag which guarantees that we do not ask the receiver for too many
enumeration. When the flag is set, each following enumeration call is
discarded (the usb request is not forwarded to the receiver). The flag
is then released when the driver receive a pairing information event,
which normally follows the enumeration request.
However, the USB3 bug makes the driver think the enumeration request
has been forwarded to the receiver. However, it is actually not the
case because the USB stack returns -EPIPE. So, when a new unknown
device appears, the workaround consisting in asking for a new
enumeration is not working anymore: this new enumeration is discarded
because of the flag, which is never reset.
A solution could be to trigger a timeout before releasing it, but for
now, let's just revert the patch.
Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Tested-by: Sune Mølgaard <sune@molgaard.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
If a transaction is rolled back, the Target Address Register (TAR), Processor
Priority Register (PPR) and Data Stream Control Register (DSCR) should be
restored to the checkpointed values before the transaction began. Any changes
to these SPRs inside the transaction should not be visible in the abort
handler.
Currently Linux doesn't save or restore the checkpointed TAR, PPR or DSCR. If
we preempt a processes inside a transaction which has modified any of these, on
process restore, that same transaction may be aborted we but we won't see the
checkpointed versions of these SPRs.
This adds checkpointed versions of these SPRs to the thread_struct and adds the
save/restore of these three SPRs to the treclaim/trechkpt code.
Without this if any of these SPRs are modified during a transaction, users may
incorrectly see a speculated SPR value even if the transaction is aborted.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> [v3.10]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This moves us to save the Target Address Register (TAR) a earlier in
__switch_to. It introduces a new function save_tar() to do this.
We need to save the TAR earlier as we will overwrite it in the transactional
memory reclaim/recheckpoint path. We are going to do this in a subsequent
patch which will fix saving the TAR register when it's modified inside a
transaction.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> [v3.10]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
POWER8 allows the DSCR to be accessed directly from userspace via a new SPR
number 0x3 (Rather than 0x11. DSCR SPR number 0x11 is still used on POWER8 but
like POWER7, is only accessible in HV and OS modes). Currently, we allow this
by setting H/FSCR DSCR bit on boot.
Unfortunately this doesn't work, as the kernel needs to see the DSCR change so
that it knows to no longer restore the system wide version of DSCR on context
switch (ie. to set thread.dscr_inherit).
This clears the H/FSCR DSCR bit initially. If a process then accesses the DSCR
(via SPR 0x3), it'll trap into the kernel where we set thread.dscr_inherit in
facility_unavailable_exception().
We also change _switch() so that we set or clear the H/FSCR DSCR bit based on
the thread.dscr_inherit.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> [v3.10]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This reworks the Facility Status and Control Regsiter (FSCR) config bit
definitions so that we can access the bit numbers. This is needed for a
subsequent patch to fix the userspace DSCR handling.
HFSCR and FSCR bit definitions are the same, so reuse them.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> [v3.10]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Currently if we take hypervisor facility unavaliable (from 0xf80/0x4f80) we
mark it as an OS facility unavaliable (0xf60) as the two share the same code
path.
The becomes a problem in facility_unavailable_exception() as we aren't able to
see the hypervisor facility unavailable exceptions.
Below fixes this by duplication the required macros.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> [v3.10]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
err was overwritten by a previous function call, and checked to be 0. If
the following page allocation fails, 0 is going to be returned instead
of -ENOMEM.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number
when failure occurs, so it need a type cast for comparing.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The procfs entry for global statistics has been missed on PowerNV
platform and the patch is going to add that.
Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Older kernels has just length information in their header. Handle it
while reading old kernel oops log from pstore.
Applies on top of powerpc/pseries: Fix buffer overflow when reading from pstore
Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When reading from pstore there is a buffer overflow during decompression
due to the header added in unzip_oops. Remove unzip_oops and call
pstore_decompress directly in nvram_pstore_read. Allocate buffer of size
report_length of the oops header as header will not be deallocated in pstore.
Since we have 'openssl' command line tool to decompress the compressed data,
dump the compressed data in case decompression fails instead of not dumping
anything.
Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We want PPC_DENORMALISATION enabled when POWERNV is enabled,
so update the Kconfig.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
Commit 5688978 ("ext4: improve handling of conflicting mount options")
introduced incorrect messages shown while choosing wrong mount options.
First of all, both cases of incorrect mount options,
"data=journal,delalloc" and "data=journal,dioread_nolock" result in
the same error message.
Secondly, the problem above isn't solved for remount option: the
mismatched parameter is simply ignored. Moreover, ext4_msg states
that remount with options "data=journal,delalloc" succeeded, which is
not true.
To fix it up, I added a simple check after parse_options() call to
ensure that data=journal and delalloc/dioread_nolock parameters are
not present at the same time.
Signed-off-by: Piotr Sarna <p.sarna@partner.samsung.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Commit 26092bf ("ext4: use a table-driven handler for mount options")
wrongly disallows the specifying the mount options nodelalloc and
data=journal simultaneously. This is incorrect; it should have only
disallowed the combination of delalloc and data=journal
simultaneously.
Reported-by: Piotr Sarna <p.sarna@partner.samsung.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Daniel writes:
A few bugfixes for serious stuff and regressions. Highlight is the
reinstated hack to keep the i915 backlight on when running on an optimus
machine, this prevents black screens especially with some radeon muxed
platforms. And the patch to quiet dmesg on Linus' old mac mini ;-)
* tag 'drm-intel-fixes-2013-08-08' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: do not disable backlight on vgaswitcheroo switch off
drm/i915: Don't call encoder's get_config unless encoder is active
drm/i915: avoid brightness overflow when doing scale
drm/i915: update last_vblank when disabling the power well
drm/i915: fix gen4 digital port hotplug definitions
John W. Linville says:
====================
This is a batch of fixes intended for the 3.11 queue...
Regarding the mac80211 (and related) bits, Johannes says:
"I have a fix from Chris for an infinite loop along with fixes from
myself to prevent it entering the loop to start with (continue using
disabled channels, many thanks to Chris for his debug/test help) and a
workaround for broken APs that advertise a bad HT primary channel in
their beacons. Additionally, a fix for another attrbuf race in mac80211
and a fix to clean up properly while P2P GO interfaces go down."
Along with that...
Solomon Peachy corrects a range check in cw1200 that would lead to
a BUG_ON when starting AP mode.
Stanislaw Gruszka provides an iwl4965 patch to power-up the device
earlier (avoiding microcode errors), and another iwl4965 fix that
resets the firmware after turning rfkill off (resolving a bug in the
Red Hat Bugzilla).
Please let me know if there are problems!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Ensure that user_namespace->parent chain can't grow too much.
Currently we use the hardroded 32 as limit.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In adt7470_write_word_data(), which writes two bytes using
i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
together when they should be OR-ed together.
The return code of i2c_smbus_write_byte_data() is zero for success.
The upshot is only the first byte was ever written to the hardware.
The 2nd byte was never written out.
I noticed that trying to set the fan speed limits was not working
correctly on my system. Setting the fan speed limits is the only
code that uses adt7470_write_word_data(). After making the change
the limit settings work and the alarms work also.
Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABCAAGBQJR+YUoAAoJENNvdpvBGATwxsgQAJzxe8x1SWW8jrvasMELW3bS
I7gl3lu789GROmZo5MI6+XI1DSCjHcMTisoPnPGx8q9LNhiYQGjp9Loxgl+L+Cem
wbDfkSHrhxtDoEw2rdpPb/hFHOpsv8t6TT53GVbdc5l/lxwyvdrblXxhWbLuTRCQ
G0X2VoxvTph7SyVPpRqoU4U99vW3g6LRI0dsxyU8kLc/kp7/t89gwh6Gj0wlb6tb
4pswvEuxK4HauMPjajCIaEeGpQoHbvCVpB4P9HvEtL/wklc5hNIAWy5+KYjMFWil
8Vc6RsJv6DZc66z+X4PT1oYrx6bkhNKNRGBETV2/dzeLU/7o2ttUIQ0vlOlN9gKV
xSne19OKwqhhRMuWrc3LDzunlFiLex2zHbZJVDOeKNXmEJVpO9ZPVkvpoi/g0vOE
DPwcc89J+763CVmXu8uyPqgQRfJTp2dXNggP3lINCDi1mFayrBqR0S6rQ1B2m/6R
8HYDjJ6gBpXBcs0FTGh1cfbpI8GpPx9Xu3Q/FtjvczEXUO3831KCm+k7O3cUjB72
I7I3wmyYQvUanOc39fg+EZ0cXpiSIZG4Mjv+8vWgADFlCMUKMaC+vp2PuKmBxTuk
7dAkxKr2kXfMirGWF1R/vo/CaKnCWmJbAJDFJ8Mt/Nk3zn3NOl/kCRtxndlj7k+m
/s8DHlVLyD8dgvzRO9gp
=xqB3
-----END PGP SIGNATURE-----
Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 bugfixes from Ted Ts'o.
Misc ext4 fixes, delayed by Ted moving mail servers and email getting
marked as spam due to bad spf records.
* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: add WARN_ON to check the length of allocated blocks
ext4: fix retry handling in ext4_ext_truncate()
ext4: destroy ext4_es_cachep on module unload
ext4: make sure group number is bumped after a inode allocation race
A couple of fixes to bring the DT binding documentation for Palmas into
sync with the code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSA3XHAAoJELSic+t+oim99V8P/RlIUqTKx17nWChbpbTYgysx
PNuwXp5TUjkvCmTtCy0OvdxyLoYWGR+LLzNfhYPNItLD9uXMA4Z6I+oNDb0wNxGl
XbPBN3FfZg2SEfV6gjXonXGOhLM7nT/90xwfKBHj2dmkZTCpu2BRnnm5qwgdyfKv
QZytKT3YajmcInCmaaanXznRRAqezc61audbGxbd2g0ewmMUs9NEt6UhkswluQsP
oxYOQ8RnW6jUvZ4451Z2UsYsV/oijZwrqg+gkNz1McEePPS86Yidr4flmv83gB9Y
tFMt4kzw0onHGpH2tmNsvkPkgk3DULdo1P/wiWi/Ap51/ZuhCkEPHIu1MariwEGf
thMrlGqN6FYbT4+j+MzHbF2cM/QodQuN6hqRbUSQO2hYVu8/isoh3bySQPyyK6c6
idbmdEe3oot+OWkBN7wICI0qlNZQBnAq+R/SLzrlOWtW+coGEnOwmMiM18MS9UcV
1Y/cNxS1zhXoFNoNVXjgUWdrTmxMEbVLI9Hr/5XjfBJIYR+uJOtsIPno3NuFJ7o4
4C1RSOxtLsdyP6aJ1IsozUGIRARgVsys6oVKAVW6atJDTTzOW/Qm+2uhSjbJuR5c
W1npzNKvyuFZ+rgiHJPpI+5f5TS30ct56c6UDj0c7fHlYP4PE7u3y3hsTV4DyhIK
LwUGRM9rjtnLF0jvxdac
=faDW
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator DT binding fixes from Mark Brown:
"A couple of fixes to bring the DT binding documentation for Palmas
into sync with the code"
* tag 'regulator-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: palmas-pmic: doc: remove ti,tstep
regulator: palmas-pmic: doc: fix typo for sleep-mode
Two things here, one is a fix for a nasty issue where we were failing to
sync the last register in a block when using raw writes and the other
fixes a missing header for the !REGMAP stubs so that we don't rely on
implicit includes in that case.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSA3O4AAoJELSic+t+oim9stQP+QFLjbyTpjBe10scjPnZ94MV
yfAl31+uBi80YPsNxTQC/JxzNtQCn+X0Y7I2/gdpf5DcUA6Vw+D8l5ABZDAiWWmU
FtijXn86zEmHtjGD88om4WX7trm9wKnL0YYUdNUXYeXduoLl9uElZGqSZedDziXk
5W0967WTKu22OeqsRe5PtXmjtFfWuI0TYEHboc7KVNTZRFdDQVzmr5oRynzW3rL2
vZ3bb9GK0fN2RTwWhjQu5fQJfjV7ZS30JAy6/uHAWaeh1u90yCcMoHgRJ0YfuBMj
3ggFVvMU2rgg9NOdlv4WuxUWEnElgKi6kWg2Figu8gKFeUPlbxkw6AMwYlg9eyUR
mSRoBs34iN1kdPqe467pKxjKZLrhyu3ZDK2fnR+wCQ8uWqKrjE/YvTiYCfzuwi6S
AMV/FiOVSzhTIyQxtvgyhGP5hR401UZtOo4Lom1GcXKeLX3/vPceErqBFYM3m7bB
pf0BlovDR1BgmN6NB9oIk8Q60NJD7Rjl1dYxXyTAgWVSZLVy3mpYYvqvBsLBtfbA
L9hhLuQ5dHWg3rNWLNaKX0z5sBNklnCfSHUhfURBO5X8H+5eoVQatqv9ZCleJp8X
Xyyjjsu4UyoBLfOMmlEEoxsYnhNbTAgvHFZ7YD5DlnZruLPT/hMgvoyf4kWoFFCc
zU96Lr3d9NIBgVtb+0C/
=OFAa
-----END PGP SIGNATURE-----
Merge tag 'regmap-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"Two things here, one is a fix for a nasty issue where we were failing
to sync the last register in a block when using raw writes and the
other fixes a missing header for the !REGMAP stubs so that we don't
rely on implicit includes in that case"
* tag 'regmap-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Add missing header for !CONFIG_REGMAP stubs
regmap: cache: Make sure to sync the last register in a block
Just one update for SPI, a simple fix to the davinci driver to correct
the direction for which DMA is mapped following the dmaengine
conversion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSA3JLAAoJELSic+t+oim9V4EP/1y95gtcWpo6NOxvu88+FRar
QC5FOnuDQRBgZnupurK95C27JZOJfwH0o/6PLiG/c/f+nEYyBhFFnJ+5ZC8O6Rg9
gzGWymtDAuS6Rlh6MI7f++k3z2DrSj8KF/0v2KW71CgaKmdvpTOoXK8FVBXx6Y5W
X74vW/+aZVQU483OUygYHl67QHDuOpKLQwkTKMcxVAheWHRCcb3zhUUgVKog8EEi
Ukl6C2xV67b7/x1TFGhUouq1pS0ShLNQdLYL8NLuc+HdFxg/nob1hGtu9crZ0Asp
FdqIQ6OBJfxkpklBY5g7GDabKD80Wb16fG9JYp0PpRphvrtKpn9rPejQXDpeIhHY
kw+5o0rw0YqyCaL2Gs9uvmgKjYXhrs+lLogCHWxRg7JbMF6FfvDkBJd8wG5UiYEY
/AvHNhsaY1YszdyNqRRc5AOrD8WEmDMS1kWDGk4tOw1lu+3X0gVzxx+7kZa61H9r
t0nFpcuRnvqyiPiGC7kH8g9/BeLMG/kW9h+1W92kIfwof2A9CufTKSFS78/UEw/C
CUTds7hFlpDh8fGSUpx5hr3xC4oGZxSF2hJTtFuHNjKnVfrxBeUQcF+y4oR8+kWH
89Xt1GqO7wKjyVXVlqWL+bCD11s37Ur7PcaFTqIxDKxRA2TY21/THuFJ/JQnEbaa
KCyCUBODgPFJ42X0jXfY
=zVk5
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fix from Mark Brown:
"Just one update for SPI, a simple fix to the davinci driver to correct
the direction for which DMA is mapped following the dmaengine
conversion"
* tag 'spi-v3.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: spi-davinci: Fix direction in dma_map_single()
and all CC:stable..
Thanks,
Rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJSAtjmAAoJENkgDmzRrbjxV/kP+wQaShGQ6Q8U7yYew7yZvo2H
CE3VHpSkp3NnJfAqNMz/sCES7pAvYXvUM1hcVQ+GI1ZqVnN5yJViqeygIOU/xQEN
WjslgtCvpdw0/R3dL4oxhcIMdgBioP9hknB56WPqHFZ9Ytb5GxPVf4wCNpd7FrsC
iGHklImzN1r4AjxSTdbCCCk8iYKJOJRTAfZrtVtkc9uOU68GGBcAl8ArSPIScwEb
41JuuB/Qgja0ssCYpD5jrC74QePvU1eTgSQWs8Tgc6v43UNFjZyKWSY8G13MAd+l
c3SCLCRqzPxpwhIhvAMQFnkmIlIqVpp66nnh6AqJt8Mw2ymSvP3AY5PMegV92Al+
afBofUz2KRPinGINe7SrrpRt/NU3SM+k1CWHeVu76U7V59f8ohxW9dLqI6otOrq+
6GZx2Z9vyVkj4TP8vz4rNZINKXjRBaGhTNcQ0rM3obMFM4Dg+4dhF+PpGA8UyFwI
3Tw2c0zbVIqQ6fEO63ZYGhAdVNdlZoPA2tuA34hfY/D07842tgkPhuAF6yDeb4jg
JmiERc506JpLws0Tu6E6H+x6LQAGr9cYPgBpvucab/SVa3bcrEJj2oqDt0pZaTiO
q6HkkDwfoDVdv9TY3sCgOmKSUp/smkrloa3vMHLUZsnjx66iIPdHn+PcN/7Im8ut
kfnKgLgo/BloWT0XeFv+
=ZV9B
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
Pull virtio fixes from Rusty Russell:
"More virtio console fixes than I'm happy with, but all real issues,
and all CC:stable.."
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
virtio-scsi: Fix virtqueue affinity setup
virtio: console: return -ENODEV on all read operations after unplug
virtio: console: fix raising SIGIO after port unplug
virtio: console: clean up port data immediately at time of unplug
virtio: console: fix race in port_fops_open() and port unplug
virtio: console: fix race with port unplug and open/close
virtio/console: Add pipe_lock/unlock for splice_write
virtio/console: Quit from splice_write if pipe->nrbufs is 0
This reverts commit 318df36e57.
This commit caused Steven Rostedt's hackbench runs to run out of memory
due to a leak. As noted by Joonsoo Kim, it is buggy in the following
scenario:
"I guess, you may set 0 to all kmem caches's cpu_partial via sysfs,
doesn't it?
In this case, memory leak is possible in following case. Code flow of
possible leak is follwing case.
* in __slab_free()
1. (!new.inuse || !prior) && !was_frozen
2. !kmem_cache_debug && !prior
3. new.frozen = 1
4. after cmpxchg_double_slab, run the (!n) case with new.frozen=1
5. with this patch, put_cpu_partial() doesn't do anything,
because this cache's cpu_partial is 0
6. return
In step 5, leak occur"
And Steven does indeed have cpu_partial set to 0 due to RT testing.
Joonsoo is cooking up a patch, but everybody agrees that reverting this
for now is the right thing to do.
Reported-and-bisected-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
there is an additional "{", which causes building error.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Aaro Koskinen reports the following oops:
Installing fiq handler from c001b110, length 0x164
Unable to handle kernel paging request at virtual address ffff1224
pgd = c0004000
[ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a
...
[<c0013154>] (set_fiq_handler+0x0/0x6c) from [<c0365d38>] (ams_delta_init_fiq+0xa8/0x160)
r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c
[<c0365c90>] (ams_delta_init_fiq+0x0/0x160) from [<c0365b14>] (ams_delta_init+0xd4/0x114)
r6:00000000 r5:fffece10 r4:c037a9e0
[<c0365a40>] (ams_delta_init+0x0/0x114) from [<c03613b4>] (customize_machine+0x24/0x30)
This is because the vectors page is now write-protected, and to change
code in there we must write to its original alias. Make that change,
and adjust the cache flushing such that the code will become visible
to the instruction stream on VIVT CPUs.
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The driver used to assume that the streaming endpoint's wMaxPacketSize
value would be an indication of how much data the endpoint expects or
sends, and compute the number of packets per URB using this value.
However, the Focusrite Scarlett 2i4 declares a value of 1024 bytes,
while only about 88 or 44 bytes are be actually used. This discrepancy
would result in URBs with far too few packets, which would not work
correctly on the EHCI driver.
To get correct URBs, use wMaxPacketSize only as an upper limit on the
packet size.
Reported-by: James Stone <jamesmstone@gmail.com>
Tested-by: James Stone <jamesmstone@gmail.com>
Cc: <stable@vger.kernel.org> # 2.6.35+
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, we do not check the return value of client = rpc_clone_client(),
nor do we shut down the resulting cloned rpc_clnt in the case where a
NFS4ERR_WRONGSEC has caused nfs4_proc_lookup_common() to replace the
original value of 'client' (causing a memory leak).
Fix both issues and simplify the code by moving the call to
rpc_clone_client() until after nfs4_proc_lookup_common() has
done its business.
Reported-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
In case a subtree did not match we currently stop backtracking and return
NULL (root table from fib_lookup). This could yield in invalid routing
table lookups when using subtrees.
Instead continue to backtrack until a valid subtree or node is found
and return this match.
Also remove unneeded NULL check.
Reported-by: Teco Boot <teco@inf-net.nl>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: David Lamparter <equinox@diac24.net>
Cc: <boutier@pps.univ-paris-diderot.fr>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle with current xf86-video-ati Git.
[airlied: regression introduced in drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos]
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59836
Tested-by: shui yangwei <yangweix.shui@intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs
with dpm on more rv6xx asics, and fixes suspend and resume with UVD.
* 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: make missing smc ucode non-fatal
drm/radeon/dpm: require rlc for dpm
drm/radeon/cik: use a mutex to properly lock srbm instanced registers
drm/radeon: remove unnecessary unpin
drm/radeon: add more UVD CS checking
drm/radeon: stop sending invalid UVD destroy msg
drm/radeon: only save UVD bo when we have open handles
drm/radeon: always program the MC on startup
drm/radeon: fix audio dto calculation on DCE3+ (v3)
drm/radeon/dpm: disable sclk ss on rv6xx
drm/radeon: fix halting UVD
drm/radeon/dpm: adjust power state properly for UVD on SI
drm/radeon/dpm: fix spread spectrum setup (v2)
drm/radeon/dpm: adjust thermal protection requirements
drm/radeon: select audio dto based on encoder id for DCE3
drm/radeon: properly handle pm on gpu reset
The smc ucode is required for dpm (dynamic power
management), but if it's missing just skip dpm setup
and don't disable acceleration.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=67876
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The rlc is required for dpm to work properly, so if
the rlc ucode is missing, don't enable dpm. Enabling
dpm without the rlc enabled can result in hangs.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We don't pin the BO on allocation, so don't unpin it on free.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Improve error handling in case userspace sends us
an invalid command buffer.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We also need to check the handle.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise just reinitialize from scratch on resume,
and so make it more likely to succeed.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For r6xx+ asics. This mirrors the behavior of pre-r6xx
asics. We need to program the MC even if something
else in startup() fails. Failure to do so results in
an unusable GPU.
Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Need to set the wallclock ratio and adjust the phase
and module registers appropriately. May fix problems
with audio timing at certain display timings.
v2: properly handle clocks below 24mhz
v3: rebase r600 changes
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>