Alex Deucher [Thu, 10 Mar 2016 20:55:26 +0000 (15:55 -0500)]
drm/radeon: rework fbdev handling on chips with no connectors
[ Upstream commit
e5f243bd2edd95c6cc1d90c1878f821068e83fba ]
Move all the logic to radeon_fb.c and add checks to functions
called frome elsewhere.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=112781
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Josh Boyer [Mon, 14 Mar 2016 16:33:40 +0000 (09:33 -0700)]
Input: powermate - fix oops with malicious USB descriptors
[ Upstream commit
9c6ba456711687b794dcf285856fc14e2c76074f ]
The powermate driver expects at least one valid USB endpoint in its
probe function. If given malicious descriptors that specify 0 for
the number of endpoints, it will crash. Validate the number of
endpoints on the interface before using them.
The full report for this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/85
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sebastian Ott [Mon, 14 Mar 2016 14:47:23 +0000 (15:47 +0100)]
s390/pci: enforce fmb page boundary rule
[ Upstream commit
80c544ded25ac14d7cc3e555abb8ed2c2da99b84 ]
The function measurement block must not cross a page boundary. Ensure
that by raising the alignment requirement to the smallest power of 2
larger than the size of the fmb.
Fixes:
d0b088531 ("s390/pci: performance statistics and debug infrastructure")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Seth Forshee [Fri, 11 Mar 2016 16:35:34 +0000 (10:35 -0600)]
fuse: Add reference counting for fuse_io_priv
[ Upstream commit
744742d692e37ad5c20630e57d526c8f2e2fe3c9 ]
The 'reqs' member of fuse_io_priv serves two purposes. First is to track
the number of oustanding async requests to the server and to signal that
the io request is completed. The second is to be a reference count on the
structure to know when it can be freed.
For sync io requests these purposes can be at odds. fuse_direct_IO() wants
to block until the request is done, and since the signal is sent when
'reqs' reaches 0 it cannot keep a reference to the object. Yet it needs to
use the object after the userspace server has completed processing
requests. This leads to some handshaking and special casing that it
needlessly complicated and responsible for at least one race condition.
It's much cleaner and safer to maintain a separate reference count for the
object lifecycle and to let 'reqs' just be a count of outstanding requests
to the userspace server. Then we can know for sure when it is safe to free
the object without any handshaking or special cases.
The catch here is that most of the time these objects are stack allocated
and should not be freed. Initializing these objects with a single reference
that is never released prevents accidental attempts to free the objects.
Fixes:
9d5722b7777e ("fuse: handle synchronous iocbs internally")
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Robert Doebbelin [Mon, 7 Mar 2016 08:50:56 +0000 (09:50 +0100)]
fuse: do not use iocb after it may have been freed
[ Upstream commit
7cabc61e01a0a8b663bd2b4c982aa53048218734 ]
There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an
iocb that could have been freed if async io has already completed. The fix
in this case is simple and obvious: cache the result before starting io.
It was discovered by KASan:
kernel: ==================================================================
kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr
ffff88036c414390
Signed-off-by: Robert Doebbelin <robert@quobyte.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes:
bcba24ccdc82 ("fuse: enable asynchronous processing direct IO")
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vittorio Gambaletta (VittGam) [Sun, 13 Mar 2016 21:19:34 +0000 (22:19 +0100)]
ALSA: intel8x0: Add clock quirk entry for AD1981B on IBM ThinkPad X41.
[ Upstream commit
4061db03dd71d195b9973ee466f6ed32f6a3fc16 ]
The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
will often fail, so add a quirk entry to fix it.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Thu, 7 Apr 2016 22:19:07 +0000 (18:19 -0400)]
ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda
[ Upstream commit
3ec622f40913ae036f218e5e7e92df9c1f1753d9 ]
Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Aaron Plattner [Sun, 13 Mar 2016 20:58:57 +0000 (13:58 -0700)]
ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda
[ Upstream commit
2d369c748c2ecc2a012ee85412a04007e67913ec ]
Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Fabio Estevam [Mon, 22 Feb 2016 12:01:53 +0000 (09:01 -0300)]
bus: imx-weim: Take the 'status' property value into account
[ Upstream commit
33b96d2c9579213cf3f36d7b29841b1e464750c4 ]
Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:
&weim {
...
status = "okay";
sram@0,0 {
...
status = "okay";
};
mram@0,0 {
...
status = "disabled";
};
};
In this case only the 'sram' device should be probed and not 'mram'.
However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.
Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.
Cc: <stable@vger.kernel.org>
Suggested-by: Wolfgang Netbal <wolfgang.netbal@sigmatek.at>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Thu, 3 Mar 2016 15:34:29 +0000 (18:34 +0300)]
xtensa: clear all DBREAKC registers on start
[ Upstream commit
7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab ]
There are XCHAL_NUM_DBREAK registers, clear them all.
This also fixes cryptic assembler error message with binutils 2.25 when
XCHAL_NUM_DBREAK is 0:
as: out of memory allocating
18446744073709551575 bytes after a total
of 495616 bytes
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Thu, 25 Feb 2016 20:27:51 +0000 (23:27 +0300)]
xtensa: fix preemption in {clear,copy}_user_highpage
[ Upstream commit
a67cc9aa2dfc6e66addf240bbd79e16e01565e81 ]
Disabling pagefault makes little sense there, preemption disabling is
what was meant.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Mon, 8 Feb 2016 22:02:38 +0000 (01:02 +0300)]
xtensa: ISS: don't hang if stdin EOF is reached
[ Upstream commit
362014c8d9d51d504c167c44ac280169457732be ]
Simulator stdin may be connected to a file, when its end is reached
kernel hangs in infinite loop inside rs_poll, because simc_poll always
signals that descriptor 0 is readable and simc_read always returns 0.
Check simc_read return value and exit loop if it's not positive. Also
don't rewind polling timer if it's zero.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hui Wang [Fri, 11 Mar 2016 04:04:02 +0000 (12:04 +0800)]
ALSA: hda - fix the mic mute button and led problem for a Lenovo AIO
[ Upstream commit
6ef2f68fa38bf415830f67903d87180d933e0f47 ]
This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and
uses GPIO2 to control the mic mute led, so applying this quirk can
make both the button and led work.
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1555912
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jenny Derzhavetz [Wed, 24 Feb 2016 17:24:00 +0000 (19:24 +0200)]
iser-target: Separate flows for np listeners and connections cma events
[ Upstream commit
f81bf458208ef6d12b2fc08091204e3859dcdba4 ]
No need to restrict this check to specific events.
Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jenny Derzhavetz [Wed, 24 Feb 2016 17:23:59 +0000 (19:23 +0200)]
iser-target: Add new state ISER_CONN_BOUND to isert_conn
[ Upstream commit
aea92980601f7ddfcb3c54caa53a43726314fe46 ]
We need an indication that isert_conn->iscsi_conn binding has
happened so we'll know not to invoke a connection reinstatement
on an unbound connection which will lead to a bogus isert_conn->conn
dereferece.
Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jenny Derzhavetz [Wed, 24 Feb 2016 17:23:58 +0000 (19:23 +0200)]
iser-target: Fix identification of login rx descriptor type
[ Upstream commit
b89a7c25462b164db280abc3b05d4d9d888d40e9 ]
Once connection request is accepted, one rx descriptor
is posted to receive login request. This descriptor has rx type,
but is outside the main pool of rx descriptors, and thus
was mistreated as tx type.
Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Joe Thornber [Tue, 1 Mar 2016 10:58:44 +0000 (10:58 +0000)]
dm thin metadata: don't issue prefetches if a transaction abort has failed
[ Upstream commit
2eae9e4489b4cf83213fa3bd508b5afca3f01780 ]
If a transaction abort has failed then we can no longer use the metadata
device. Typically this happens if the superblock is unreadable.
This fix addresses a crash seen during metadata device failure testing.
Fixes:
8a01a6af75 ("dm thin: prefetch missing metadata pages")
Cc: stable@vger.kernel.org # 3.19+
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Thu, 3 Mar 2016 22:32:19 +0000 (01:32 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 13d3:3472
[ Upstream commit
75c6aca4765dbe3d0c1507ab5052f2e373dc2331 ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3472 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1552925
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Luck, Tony [Thu, 10 Mar 2016 00:40:48 +0000 (16:40 -0800)]
EDAC/sb_edac: Fix computation of channel address
[ Upstream commit
eb1af3b71f9d83e45f2fd2fd649356e98e1c582c ]
Large memory Haswell-EX systems with multiple DIMMs per channel were
sometimes reporting the wrong DIMM.
Found three problems:
1) Debug printouts for socket and channel interleave were not interpreting
the register fields correctly. The socket interleave field is a 2^X
value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2,
2=3. 3=4).
2) Actual use of the socket interleave value didn't interpret as 2^X
3) Conversion of address to channel address was complicated, and wrong.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Aristeu Rozanski <arozansk@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-edac@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
OGAWA Hirofumi [Thu, 10 Mar 2016 04:47:25 +0000 (23:47 -0500)]
jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path
[ Upstream commit
c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 ]
On umount path, jbd2_journal_destroy() writes latest transaction ID
(->j_tail_sequence) to be used at next mount.
The bug is that ->j_tail_sequence is not holding latest transaction ID
in some cases. So, at next mount, there is chance to conflict with
remaining (not overwritten yet) transactions.
mount (id=10)
write transaction (id=11)
write transaction (id=12)
umount (id=10) <= the bug doesn't write latest ID
mount (id=10)
write transaction (id=11)
crash
mount
[recovery process]
transaction (id=11)
transaction (id=12) <= valid transaction ID, but old commit
must not replay
Like above, this bug become the cause of recovery failure, or FS
corruption.
So why ->j_tail_sequence doesn't point latest ID?
Because if checkpoint transactions was reclaimed by memory pressure
(i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
(And another case is, __jbd2_journal_clean_checkpoint_list() is called
with empty transaction.)
So in above cases, ->j_tail_sequence is not pointing latest
transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
done too.
So, to fix this problem with minimum changes, this patch updates
->j_tail_sequence, and issue REQ_FLUSH. (With more complex changes,
some optimizations would be possible to avoid unnecessary REQ_FLUSH
for example though.)
BTW,
journal->j_tail_sequence =
++journal->j_transaction_sequence;
Increment of ->j_transaction_sequence seems to be unnecessary, but
ext3 does this.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Thu, 10 Mar 2016 10:33:43 +0000 (11:33 +0100)]
ALSA: hda - Apply reboot D3 fix for CX20724 codec, too
[ Upstream commit
56dc66ff1c6d71f9a38c4a7c000b72b921fe4c89 ]
Just like CX20722, CX7024 codec also requires the power down at reboot
in order to reduce the noise at reboot/shutdown.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=113511
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Douglas Gilbert [Thu, 3 Mar 2016 05:31:29 +0000 (00:31 -0500)]
sg: fix dxferp in from_to case
[ Upstream commit
5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]
One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.
From what I can tell, the above action was broken by commit
fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.
Make sure that a user space pointer is passed through when data follows
the sg_header structure and command. Fix the abnormal case when a
non-zero reply_len is also given.
Fixes:
fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc: <stable@vger.kernel.org> #v2.6.28+
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Ewan Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mario Kleiner [Sun, 6 Mar 2016 01:39:53 +0000 (02:39 +0100)]
drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.
[ Upstream commit
459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 ]
As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.
Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Wed, 2 Mar 2016 16:47:29 +0000 (11:47 -0500)]
drm/radeon: disable runtime pm on PX laptops without dGPU power control
[ Upstream commit
e64c952efb8e0c15ae82cec8e455ab4910690ef1 ]
Some PX laptops don't provide an ACPI method to control dGPU power. On
those systems, the driver is responsible for handling the dGPU power
state. Disable runtime PM on them until support for this is implemented.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
NeilBrown [Wed, 9 Mar 2016 01:58:25 +0000 (12:58 +1100)]
md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list
[ Upstream commit
550da24f8d62fe81f3c13e3ec27602d6e44d43dc ]
break_stripe_batch_list breaks up a batch and copies some flags from
the batch head to the members, preserving others.
It doesn't preserve or copy STRIPE_PREREAD_ACTIVE. This is not
normally a problem as STRIPE_PREREAD_ACTIVE is cleared when a
stripe_head is added to a batch, and is not set on stripe_heads
already in a batch.
However there is no locking to ensure one thread doesn't set the flag
after it has just been cleared in another. This does occasionally happen.
md/raid5 maintains a count of the number of stripe_heads with
STRIPE_PREREAD_ACTIVE set: conf->preread_active_stripes. When
break_stripe_batch_list clears STRIPE_PREREAD_ACTIVE inadvertently
this could becomes incorrect and will never again return to zero.
md/raid5 delays the handling of some stripe_heads until
preread_active_stripes becomes zero. So when the above mention race
happens, those stripe_heads become blocked and never progress,
resulting is write to the array handing.
So: change break_stripe_batch_list to preserve STRIPE_PREREAD_ACTIVE
in the members of a batch.
URL: https://bugzilla.kernel.org/show_bug.cgi?id=108741
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1258153
URL: http://thread.gmane.org/
5649C0E9.2030204@zoner.cz
Reported-by: Martin Svec <martin.svec@zoner.cz> (and others)
Tested-by: Tom Weber <linux@junkyard.4t2.com>
Fixes:
1b956f7a8f9a ("md/raid5: be more selective about distributing flags across batch.")
Cc: stable@vger.kernel.org (v4.1 and later)
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maurizio Lombardi [Fri, 4 Mar 2016 09:41:49 +0000 (10:41 +0100)]
be2iscsi: set the boot_kset pointer to NULL in case of failure
[ Upstream commit
84bd64993f916bcf86270c67686ecf4cea7b8933 ]
In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.
Cc: <stable@vger.kernel.org>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjorn Helgaas [Fri, 26 Feb 2016 15:15:11 +0000 (09:15 -0600)]
x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs
[ Upstream commit
b894157145e4ac7598d7062bc93320898a5e059e ]
The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
where a BAR should be. We don't know what the side effects of sizing the
"BAR" would be, and we don't know what address space the "BAR" might appear
to describe.
Mark these devices as having non-compliant BARs so the PCI core doesn't
touch them.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Andi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Mon, 7 Mar 2016 23:17:50 +0000 (15:17 -0800)]
bcache: fix cache_set_flush() NULL pointer dereference on OOM
[ Upstream commit
f8b11260a445169989d01df75d35af0f56178f95 ]
When bch_cache_set_alloc() fails to kzalloc the cache_set, the
asyncronous closure handling tries to dereference a cache_set that
hadn't yet been allocated inside of cache_set_flush() which is called
by __cache_set_unregister() during cleanup. This appears to happen only
during an OOM condition on bcache_register.
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Fri, 26 Feb 2016 22:33:56 +0000 (14:33 -0800)]
bcache: cleaned up error handling around register_cache()
[ Upstream commit
9b299728ed777428b3908ac72ace5f8f84b97789 ]
Fix null pointer dereference by changing register_cache() to return an int
instead of being void. This allows it to return -ENOMEM or -ENODEV and
enables upper layers to handle the OOM case without NULL pointer issues.
See this thread:
http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3521
Fixes this error:
gargamel:/sys/block/md5/bcache# echo /dev/sdh2 > /sys/fs/bcache/register
bcache: register_cache() error opening sdh2: cannot allocate memory
BUG: unable to handle kernel NULL pointer dereference at
00000000000009b8
IP: [<
ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
PGD
120dff067 PUD
1119a3067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: veth ip6table_filter ip6_tables
(...)
CPU: 4 PID: 3371 Comm: kworker/4:3 Not tainted 4.4.2-amd64-i915-volpreempt-
20160213bc1 #3
Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013
Workqueue: events cache_set_flush [bcache]
task:
ffff88020d5dc280 ti:
ffff88020b6f8000 task.ti:
ffff88020b6f8000
RIP: 0010:[<
ffffffffc05a7e8d>] [<
ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Tested-by: Marc MERLIN <marc@merlins.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Fri, 26 Feb 2016 22:39:06 +0000 (14:39 -0800)]
bcache: fix race of writeback thread starting before complete initialization
[ Upstream commit
07cc6ef8edc47f8b4fc1e276d31127a0a5863d4d ]
The bch_writeback_thread might BUG_ON in read_dirty() if
dc->sb==BDEV_STATE_DIRTY and bch_sectors_dirty_init has not yet completed
its related initialization. This patch downs the dc->writeback_lock until
after initialization is complete, thus preventing bch_writeback_thread
from proceeding prematurely.
See this thread:
http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3453
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Tested-by: Marc MERLIN <marc@merlins.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Chris Friesen [Sun, 6 Mar 2016 05:18:48 +0000 (23:18 -0600)]
sched/cputime: Fix steal_account_process_tick() to always return jiffies
[ Upstream commit
f9c904b7613b8b4c85b10cd6b33ad41b2843fa9d ]
The callers of steal_account_process_tick() expect it to return
whether a jiffy should be considered stolen or not.
Currently the return value of steal_account_process_tick() is in
units of cputime, which vary between either jiffies or nsecs
depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN.
If cputime has nsecs granularity and there is a tiny amount of
stolen time (a few nsecs, say) then we will consider the entire
tick stolen and will not account the tick on user/system/idle,
causing /proc/stats to show invalid data.
The fix is to change steal_account_process_tick() to accumulate
the stolen time and only account it once it's worth a jiffy.
(Thanks to Frederic Weisbecker for suggestions to fix a bug in my
first version of the patch.)
Signed-off-by: Chris Friesen <chris.friesen@windriver.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/56DBBDB8.40305@mail.usask.ca
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Stephane Eranian [Thu, 3 Mar 2016 19:50:40 +0000 (20:50 +0100)]
perf/x86/intel: Add definition for PT PMI bit
[ Upstream commit
5690ae28e472d25e330ad0c637a5cea3fc39fb32 ]
This patch adds a definition for GLOBAL_OVFL_STATUS bit 55
which is used with the Processor Trace (PT) feature.
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: adrian.hunter@intel.com
Cc: kan.liang@intel.com
Cc: namhyung@kernel.org
Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andi Kleen [Sun, 10 May 2015 19:22:41 +0000 (12:22 -0700)]
x86: Add new MSRs and MSR bits used for Intel Skylake PMU support
[ Upstream commit
b83ff1c8617aac03a1cf807aafa848fe0f0908f2 ]
Add new MSRs (LBR_INFO) and some new MSR bits used by the Intel Skylake
PMU driver.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1431285767-27027-4-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Fri, 17 Jul 2015 14:27:33 +0000 (16:27 +0200)]
ALSA: hda - Check the return value from pm_runtime_get/put*()
[ Upstream commit
fbce23a0b95763dfc4961ce6240e055c39f497ed ]
This patch changes the return type of snd_hdac_power_up/down() and
variants to pass the error code from the underlying
pm_runtime_get/put() calls. Currently they are ignored, but in most
places, these should be handled properly.
As an example, the regmap handler is updated to check the return value
and accesses the register only when the wakeup succeeds.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Phil Elwell [Tue, 1 Mar 2016 01:30:08 +0000 (17:30 -0800)]
pinctrl-bcm2835: Fix cut-and-paste error in "pull" parsing
[ Upstream commit
2c7e3306d23864d49f686f22e56e180ff0fffb7f ]
The DT bindings for pinctrl-bcm2835 allow both the function and pull
to contain either one entry or one per pin. However, an error in the
DT parsing can cause failures if the number of pulls differs from the
number of functions.
Cc: stable@vger.kernel.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Radim Krčmář [Wed, 2 Mar 2016 21:56:38 +0000 (22:56 +0100)]
KVM: i8254: change PIT discard tick policy
[ Upstream commit
7dd0fdff145c5be7146d0ac06732ae3613412ac1 ]
Discard policy uses ack_notifiers to prevent injection of PIT interrupts
before EOI from the last one.
This patch changes the policy to always try to deliver the interrupt,
which makes a difference when its vector is in ISR.
Old implementation would drop the interrupt, but proposed one injects to
IRR, like real hardware would.
The old policy breaks legacy NMI watchdogs, where PIT is used through
virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
thus a guest deadlock with disabled interrupts will stop NMIs.
Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
through IOAPIC. (KVM's PIT is deeply rotten and luckily not used much
in modern systems.)
Even though there is a chance of regressions, I think we can fix the
LVT0 NMI bug without introducing a new tick policy.
Cc: <stable@vger.kernel.org>
Reported-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oliver Neukum [Wed, 17 Feb 2016 10:52:43 +0000 (11:52 +0100)]
usb: hub: fix a typo in hub_port_init() leading to wrong logic
[ Upstream commit
0d5ce778c43bf888328231bcdce05d5c860655aa ]
A typo of j for i led to a logic bug. To rule out future
confusion, the variable names are made meaningful.
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vinayak Menon [Mon, 22 Feb 2016 13:45:44 +0000 (19:15 +0530)]
of: alloc anywhere from memblock if range not specified
[ Upstream commit
e53b50c0cbe392c946807abf7d07615a3c588642 ]
early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:18:20 +0000 (21:18 -0800)]
mtip32xx: Handle FTL rebuild failure state during device initialization
[ Upstream commit
aae4a033868c496adae86fc6f9c3e0c405bbf360 ]
Allow device initialization to finish gracefully when it is in
FTL rebuild failure state. Also, recover device out of this state
after successfully secure erasing it.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:50:50 +0000 (15:50 -0700)]
mtip32xx: fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
[ Upstream commit
ee04bed690cb49a49512a641405bac42d13c2b2a ]
Fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:18:10 +0000 (21:18 -0800)]
mtip32xx: Handle safe removal during IO
[ Upstream commit
51c6570eb922146470c2fe660c34585414679bd6 ]
Flush inflight IOs using fsync_bdev() when the device is safely
removed. Also, block further IOs in device open function.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:53:18 +0000 (15:53 -0700)]
mtip32xx: fix crash on surprise removal of the drive
[ Upstream commit
2132a544727eb17f76bfef8b550a016a41c38821 ]
pci and block layers have changed a lot compared to when SRSI support was added.
Given the current state of pci and block layers, this driver do not have to do
any specific handling.
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:48:00 +0000 (15:48 -0700)]
mtip32xx: fix rmmod issue
[ Upstream commit
02b48265e7437bfe153af16337b14ee74f00905f ]
put_disk() need to be called after del_gendisk() to free the disk object structure.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:17:32 +0000 (21:17 -0800)]
mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild
[ Upstream commit
d8a18d2d8f5de55666c6011ed175939d22c8e3d8 ]
Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is in FTL rebuild process.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:16:38 +0000 (21:16 -0800)]
mtip32xx: Print exact time when an internal command is interrupted
[ Upstream commit
5b7e0a8ac85e2dfd83830dc9e0b3554d153a37e3 ]
Print exact time when an internal command is interrupted.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nikolay Borisov [Thu, 3 Mar 2016 09:54:57 +0000 (10:54 +0100)]
quota: Fix possible GPF due to uninitialised pointers
[ Upstream commit
ab73ef46398e2c0159f3a71de834586422d2a44a ]
When dqget() in __dquot_initialize() fails e.g. due to IO error,
__dquot_initialize() will pass an array of uninitialized pointers to
dqput_all() and thus can lead to deference of random data. Fix the
problem by properly initializing the array.
CC: stable@vger.kernel.org
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mateusz Guzik [Tue, 1 Mar 2016 22:51:09 +0000 (09:51 +1100)]
xfs: fix two memory leaks in xfs_attr_list.c error paths
[ Upstream commit
2e83b79b2d6c78bf1b4aa227938a214dcbddc83f ]
This plugs 2 trivial leaks in xfs_attr_shortform_list and
xfs_attr3_leaf_list_int.
Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
J. Bruce Fields [Tue, 1 Mar 2016 01:21:21 +0000 (20:21 -0500)]
nfsd4: fix bad bounds checking
[ Upstream commit
4aed9c46afb80164401143aa0fdcfe3798baa9d5 ]
A number of spots in the xdr decoding follow a pattern like
n = be32_to_cpup(p++);
READ_BUF(n + 4);
where n is a u32. The only bounds checking is done in READ_BUF itself,
but since it's checking (n + 4), it won't catch cases where n is very
large, (u32)(-4) or higher. I'm not sure exactly what the consequences
are, but we've seen crashes soon after.
Instead, just break these up into two READ_BUF()s.
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Sun, 28 Feb 2016 15:44:09 +0000 (17:44 +0200)]
watchdog: rc32434_wdt: fix ioctl error handling
[ Upstream commit
10e7ac22cdd4d211cef99afcb9371b70cb175be6 ]
Calling return copy_to_user(...) in an ioctl will not do the right thing
if there's a pagefault: copy_to_user returns the number of bytes not
copied in this case.
Fix up watchdog/rc32434_wdt to do
return copy_to_user(...)) ? -EFAULT : 0;
instead.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Sun, 7 Feb 2016 11:24:29 +0000 (09:24 -0200)]
[media] bttv: Width must be a multiple of 16 when capturing planar formats
[ Upstream commit
5c915c68763889f0183a1cc61c84bb228b60124a ]
On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max
size results in a solid green rectangle being captured (all colors 0 in
YUV).
This turns out to be caused by max-width (924) not being a multiple of 16.
We've likely never hit this problem before since normally xawtv / tvtime,
etc. will prefer packed pixel formats. But when using a video card which
is using xf86-video-modesetting + glamor, only planar XVideo fmts are
available, and xawtv will chose a matching capture format to avoid needing
to do conversion, triggering the solid green window problem.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bart Van Assche [Thu, 11 Feb 2016 19:03:09 +0000 (11:03 -0800)]
IB/srpt: Simplify srpt_handle_tsk_mgmt()
[ Upstream commit
51093254bf879bc9ce96590400a87897c7498463 ]
Let the target core check task existence instead of the SRP target
driver. Additionally, let the target core check the validity of the
task management request instead of the ib_srpt driver.
This patch fixes the following kernel crash:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000001
IP: [<
ffffffffa0565f37>] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt]
Oops: 0002 [#1] SMP
Call Trace:
[<
ffffffffa05660ce>] srpt_process_completion+0xde/0x570 [ib_srpt]
[<
ffffffffa056669f>] srpt_compl_thread+0x13f/0x160 [ib_srpt]
[<
ffffffff8109726f>] kthread+0xcf/0xe0
[<
ffffffff81613cfc>] ret_from_fork+0x7c/0xb0
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Fixes:
3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr")
Tested-by: Alex Estrin <alex.estrin@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Howells [Wed, 24 Feb 2016 14:37:15 +0000 (14:37 +0000)]
X.509: Fix leap year handling again
[ Upstream commit
ac4cbedfdf55455b4c447f17f0fa027dbf02b2a6 ]
There are still a couple of minor issues in the X.509 leap year handling:
(1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
determining whether the year is a leap year or not, I divided the year
by 100 after doing the modulus-by-100, thereby letting the compiler do
one instruction for both, and then did a modulus-by-4.
Unfortunately, I then passed the now-modified year value to mktime64()
to construct a time value.
Since this isn't a fast path and since mktime64() does a bunch of
divisions, just condense down to "% 400". It's also easier to read.
(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.
This is fixed by altering the table.
Reported-by: Rudolf Polzer <rpolzer@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Howells [Wed, 29 Jul 2015 15:58:32 +0000 (16:58 +0100)]
PKCS#7: Improve and export the X.509 ASN.1 time object decoder
[ Upstream commit
fd19a3d195be23e8d9d0d66576b96ea25eea8323 ]
Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
struct tm to make comparison easier (unfortunately, this makes readable
display less easy) and export it so that it can be used by the PKCS#7 code
too.
Further, tighten up its parsing to reject invalid dates (eg. weird
characters, non-existent hour numbers) and unsupported dates (eg. timezones
other than 'Z' or dates earlier than 1970).
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Howells [Mon, 20 Jul 2015 20:16:26 +0000 (21:16 +0100)]
X.509: Extract both parts of the AuthorityKeyIdentifier
[ Upstream commit
b92e6570a992c7d793a209db282f68159368201c ]
Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
as the second part can be used to match X.509 certificates by issuer and
serialNumber.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Tue, 26 Jan 2016 13:41:04 +0000 (13:41 +0000)]
mmc: sdhci: fix data timeout (part 2)
[ Upstream commit
7f05538af71c7d30b5fc821cbe9f318edc645961 ]
The calculation for the timeout based on the number of card clocks is
incorrect. The calculation assumed:
timeout in microseconds = clock cycles / clock in Hz
which is clearly a several orders of magnitude wrong. Fix this by
multiplying the clock cycles by 1000000 prior to dividing by the Hz
based clock. Also, as per part 1, ensure that the division rounds
up.
As this needs 64-bit math via do_div(), avoid it if the clock cycles
is zero.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Tue, 26 Jan 2016 13:40:58 +0000 (13:40 +0000)]
mmc: sdhci: fix data timeout (part 1)
[ Upstream commit
fafcfda9e78cae8796d1799f14e6457790797555 ]
The data timeout gives the minimum amount of time that should be
waited before timing out if no data is received from the card.
Simply dividing the nanosecond part by 1000 does not give this
required guarantee, since such a division rounds down. Use
DIV_ROUND_UP() to give the desired timeout.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Tue, 26 Jan 2016 13:40:47 +0000 (13:40 +0000)]
mmc: sdhci-pxav3: fix higher speed mode capabilities
[ Upstream commit
0ca33b4ad9cfc133bb3d93eec1ad0eea83d6f252 ]
Commit
1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the
SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes
being used.
The commit claims that SDR50 and DDR50 require clock adjustments in
the SDIO3 Configuration register, which is located via the "conf-sdio3"
resource. However, when this resource is given, we fail to read the
host capabilities 1 register, resulting in host->caps1 being zero.
Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain
zero, disabling the SDR50 and DDR50 modes.
The underlying idea in this function appears to be to read the device
capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause
our modified capabilities to be used. Implement exactly that.
Fixes:
1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org # v4.5+
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Sun, 28 Feb 2016 08:04:06 +0000 (11:04 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 04ca:3014
[ Upstream commit
81d90442eac779938217c3444b240aa51fd3db47 ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3014 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1546694
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tom Lendacky [Thu, 25 Feb 2016 22:48:13 +0000 (16:48 -0600)]
crypto: ccp - memset request context to zero during import
[ Upstream commit
ce0ae266feaf35930394bd770c69778e4ef03ba9 ]
Since a crypto_ahash_import() can be called against a request context
that has not had a crypto_ahash_init() performed, the request context
needs to be cleared to insure there is no random data present. If not,
the random data can result in a kernel oops during crypto_ahash_update().
Cc: <stable@vger.kernel.org> # 3.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Shaohua Li [Thu, 25 Feb 2016 01:38:28 +0000 (17:38 -0800)]
RAID5: check_reshape() shouldn't call mddev_suspend
[ Upstream commit
27a353c026a879a1001e5eac4bda75b16262c44a ]
check_reshape() is called from raid5d thread. raid5d thread shouldn't
call mddev_suspend(), because mddev_suspend() waits for all IO finish
but IO is handled in raid5d thread, we could easily deadlock here.
This issue is introduced by
738a273 ("md/raid5: fix allocation of 'scribble' array.")
Cc: stable@vger.kernel.org (v4.1+)
Reported-and-tested-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jes Sorensen [Tue, 16 Feb 2016 21:44:24 +0000 (16:44 -0500)]
md/raid5: Compare apples to apples (or sectors to sectors)
[ Upstream commit
e7597e69dec59b65c5525db1626b9d34afdfa678 ]
'max_discard_sectors' is in sectors, while 'stripe' is in bytes.
This fixes the problem where DISCARD would get disabled on some larger
RAID5 configurations (6 or more drives in my testing), while it worked
as expected with smaller configurations.
Fixes:
620125f2bf8 ("MD: raid5 trim support")
Cc: stable@vger.kernel.org v3.7+
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjorn Helgaas [Thu, 25 Feb 2016 20:35:57 +0000 (14:35 -0600)]
PCI: Disable IO/MEM decoding for devices with non-compliant BARs
[ Upstream commit
b84106b4e2290c081cdab521fa832596cdfea246 ]
The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.
Some non-spec-compliant devices put registers other than BARs where the
BARs should be. When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.
Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Andi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yijing Wang [Thu, 21 May 2015 07:05:02 +0000 (15:05 +0800)]
PCI: Add dev->has_secondary_link to track downstream PCIe links
[ Upstream commit
d0751b98dfa391f862e02dc36a233a54615e3f1d ]
A PCIe Port is an interface to a Link. A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side. For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.
The usual topology has a Root Port connected to an Upstream Port. We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:
+---------------------+
+------+ | Downstream |
| Root | | Upstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port. In this case, a Downstream Port's Link may be on either
the upstream or downstream side:
+---------------------+
+------+ | Upstream |
| Root | | Downstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.
A Root Port's Link is always on the Port's secondary side. A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side. If that component is a Port, it is part of a Switch or
a Bridge. A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link. The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.
[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Aaro Koskinen [Sat, 20 Feb 2016 20:27:48 +0000 (22:27 +0200)]
mtd: onenand: fix deadlock in onenand_block_markbad
[ Upstream commit
5e64c29e98bfbba1b527b0a164f9493f3db9e8cb ]
Commit
5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
incorrectly changed onenand_block_markbad() to call mtd_block_markbad
instead of onenand_chip's block_markbad function. As a result the function
will now recurse and deadlock. Fix by reverting the change.
Fixes:
5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alan [Mon, 15 Feb 2016 18:53:15 +0000 (18:53 +0000)]
aic7xxx: Fix queue depth handling
[ Upstream commit
5a51a7abca133860a6f4429655a9eda3c4afde32 ]
We were setting the queue depth correctly, then setting it back to
two. If you hit this as a bisection point then please send me an email
as it would imply we've been hiding other bugs with this one.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reviewed-by: Hannes Reinicke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Raghava Aditya Renukunta [Wed, 3 Feb 2016 23:06:02 +0000 (15:06 -0800)]
aacraid: Fix memory leak in aac_fib_map_free
[ Upstream commit
f88fa79a61726ce9434df9b4aede36961f709f17 ]
aac_fib_map_free() calls pci_free_consistent() without checking that
dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).
Fixed by adding a check to make sure that dev->hw_fib_va and
dev->max_fib_size are not NULL and 0 respectively.
Fixes:
9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Cc: stable@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Raghava Aditya Renukunta [Wed, 3 Feb 2016 23:06:00 +0000 (15:06 -0800)]
aacraid: Fix RRQ overload
[ Upstream commit
3f4ce057d51a9c0ed9b01ba693df685d230ffcae ]
The driver utilizes an array of atomic variables to keep track of IO
submissions to each vector. To submit an IO multiple threads iterate
through the array to find a vector which has empty slots to send an
IO. The reading and updating of the variable is not atomic, causing race
conditions when a thread uses a full vector to submit an IO.
Fixed by mapping each FIB to a vector, the submission path then uses
said vector to submit IO thereby removing the possibly of a race
condition.The vector assignment is started from 1 since vector 0 is
reserved for the use of AIF management FIBS.If the number of MSIx
vectors is 1 (MSI or INTx mode) then all the fibs are allocated to
vector 0.
Fixes:
495c0217 "aacraid: MSI-x support"
Cc: stable@vger.kernel.org # v4.1
Signed-off-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Tue, 9 Feb 2016 21:49:11 +0000 (00:49 +0300)]
Bluetooth: Add new AR3012 ID 0489:e095
[ Upstream commit
28c971d82fb58ef7cba22e5308be6d2d2590473d ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e095 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
This device requires ar3k/AthrBT_0x31010100.dfu and
ar3k/ramps_0x31010100_40.dfu firmware files that are not in
linux-firmware yet.
BugLink: https://bugs.launchpad.net/bugs/1542944
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Wed, 10 Feb 2016 12:33:17 +0000 (15:33 +0300)]
Bluetooth: btusb: Add new AR3012 ID 13d3:3395
[ Upstream commit
609574eb46335cfac1421a07c0505627cbbab1f0 ]
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3395 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1542564
Reported-and-tested-by: Christopher Simerly <kilikopela29@gmail.com>
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andi Kleen [Wed, 17 Feb 2016 22:44:55 +0000 (14:44 -0800)]
perf tools: Dont stop PMU parsing on alias parse error
[ Upstream commit
940db6dcd3f4659303fdf6befe7416adc4d24118 ]
When an error happens during alias parsing currently the complete
parsing of all attributes of the PMU is stopped. This is breaks old perf
on a newer kernel that may have not-yet-know alias attributes (such as
.scale or .per-pkg).
Continue when some attribute is unparseable.
This is IMHO a stable candidate and should be backported to older
versions to avoid problems with newer kernels.
v2: Print warnings when something goes wrong.
v3: Change warning to debug output
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: stable@vger.kernel.org # v3.6+
Link: http://lkml.kernel.org/r/1455749095-18358-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mike Snitzer [Fri, 5 Feb 2016 13:49:01 +0000 (08:49 -0500)]
dm: fix excessive dm-mq context switching
[ Upstream commit
6acfe68bac7e6f16dc312157b1fa6e2368985013 ]
Request-based DM's blk-mq support (dm-mq) was reported to be 50% slower
than if an underlying null_blk device were used directly. One of the
reasons for this drop in performance is that blk_insert_clone_request()
was calling blk_mq_insert_request() with @async=true. This forced the
use of kblockd_schedule_delayed_work_on() to run the blk-mq hw queues
which ushered in ping-ponging between process context (fio in this case)
and kblockd's kworker to submit the cloned request. The ftrace
function_graph tracer showed:
kworker-2013 => fio-12190
fio-12190 => kworker-2013
...
kworker-2013 => fio-12190
fio-12190 => kworker-2013
...
Fixing blk_insert_clone_request()'s blk_mq_insert_request() call to
_not_ use kblockd to submit the cloned requests isn't enough to
eliminate the observed context switches.
In addition to this dm-mq specific blk-core fix, there are 2 DM core
fixes to dm-mq that (when paired with the blk-core fix) completely
eliminate the observed context switching:
1) don't blk_mq_run_hw_queues in blk-mq request completion
Motivated by desire to reduce overhead of dm-mq, punting to kblockd
just increases context switches.
In my testing against a really fast null_blk device there was no benefit
to running blk_mq_run_hw_queues() on completion (and no other blk-mq
driver does this). So hopefully this change doesn't induce the need for
yet another revert like commit
621739b00e16ca2d !
2) use blk_mq_complete_request() in dm_complete_request()
blk_complete_request() doesn't offer the traditional q->mq_ops vs
.request_fn branching pattern that other historic block interfaces
do (e.g. blk_get_request). Using blk_mq_complete_request() for
blk-mq requests is important for performance. It should be noted
that, like blk_complete_request(), blk_mq_complete_request() doesn't
natively handle partial completions -- but the request-based
DM-multipath target does provide the required partial completion
support by dm.c:end_clone_bio() triggering requeueing of the request
via dm-mpath.c:multipath_end_io()'s return of DM_ENDIO_REQUEUE.
dm-mq fix #2 is _much_ more important than #1 for eliminating the
context switches.
Before: cpu : usr=15.10%, sys=59.39%, ctx=7905181, majf=0, minf=475
After: cpu : usr=20.60%, sys=79.35%, ctx=2008, majf=0, minf=472
With these changes multithreaded async read IOPs improved from ~950K
to ~1350K for this dm-mq stacked on null_blk test-case. The raw read
IOPs of the underlying null_blk device for the same workload is ~1950K.
Fixes:
7fb4898e0 ("block: add blk-mq support to blk_insert_cloned_request()")
Fixes:
bfebd1cdb ("dm: add full blk-mq support to request-based DM")
Cc: stable@vger.kernel.org # 4.1+
Reported-by: Sagi Grimberg <sagig@dev.mellanox.co.il>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eryu Guan [Sun, 21 Feb 2016 23:38:44 +0000 (18:38 -0500)]
ext4: iterate over buffer heads correctly in move_extent_per_page()
[ Upstream commit
87f9a031af48defee9f34c6aaf06d6f1988c244d ]
In commit
bcff24887d00 ("ext4: don't read blocks from disk after extents
being swapped") bh is not updated correctly in the for loop and wrong
data has been written to disk. generic/324 catches this on sub-page
block size ext4.
Fixes:
bcff24887d00 ("ext4: don't read blocks from disk after extentsbeing swapped")
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jarkko Sakkinen [Thu, 18 Feb 2016 20:11:29 +0000 (22:11 +0200)]
tpm_crb: tpm2_shutdown() must be called before tpm_chip_unregister()
[ Upstream commit
99cda8cb4639de81cde785b5bab9bc52e916e594 ]
Wrong call order.
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Fixes:
74d6b3ceaa17
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Sun, 14 Feb 2016 19:51:37 +0000 (17:51 -0200)]
[media] saa7134: Fix bytesperline not being set correctly for planar formats
[ Upstream commit
3e71da19f9dc22e39a755d6ae9678661abb66adc ]
bytesperline should be the bytesperline for the first plane for planar
formats, not that of all planes combined.
This fixes a crash in xawtv caused by the wrong bpl.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389
Reported-and-tested-by: Stas Sergeev <stsp@list.ru>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans Verkuil [Wed, 10 Feb 2016 11:32:25 +0000 (09:32 -0200)]
[media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect
[ Upstream commit
b339a72e04a62f0b1882c43492fc712f1176b3e6 ]
The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present.
The adv7511 however still reported the EDID present after disconnecting
the HDMI cable. Fix the logic regarding this control. And when the EDID
is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver.
This was also missing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v3.12 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Julia Lawall [Wed, 17 Feb 2016 23:16:14 +0000 (00:16 +0100)]
scripts/coccinelle: modernize &
[ Upstream commit
1b669e713f277a4d4b3cec84e13d16544ac8286d ]
& is no longer allowed in column 0, since Coccinelle 1.0.4.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Tested-by: Nishanth Menon <nm@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Benjamin Tissoires [Fri, 12 Feb 2016 16:10:37 +0000 (17:10 +0100)]
HID: fix hid_ignore_special_drivers module parameter
[ Upstream commit
4392bf333388cabdad5afe5b1500002d7b9c318e ]
hid_ignore_special_drivers works fine until hid_scan_report autodetects and
reassign devices (for hid-multitouch, hid-microsoft and hid-rmi).
Simplify the handling of the parameter: if it is there, use hid-generic, no
matter what, and if not, scan the device or rely on the hid_have_special_driver
table.
This was detected while trying to disable hid-multitouch on a Surface Pro cover
which prevented to use the keyboard.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oliver Neukum [Wed, 10 Feb 2016 10:33:18 +0000 (11:33 +0100)]
usb: retry reset if a device times out
[ Upstream commit
264904ccc33c604d4b3141bbd33808152dfac45b ]
Some devices I got show an inability to operate right after
power on if they are already connected. They are beyond recovery
if the descriptors are requested multiple times. So in case of
a timeout we rather bail early and reset again. But it must be
done only on the first loop lest we get into a reset/time out
spiral that can be overcome with a retry.
This patch is a rework of a patch that fell through the cracks.
http://www.spinics.net/lists/linux-usb/msg103263.html
Signed-off-by: Oliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Lior Amsalem [Wed, 10 Feb 2016 16:29:15 +0000 (17:29 +0100)]
ARM: dts: armada-375: use armada-370-sata for SATA
[ Upstream commit
b3a7f31eb7375633cd6a742f19488fc5a4208b36 ]
The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
requires the PHY speed to be set in the LP_PHY_CTL register for SATA
hotplug to work.
Therefore, this commit updates the compatible string used to describe
the SATA IP in Armada 375 from marvell,orion-sata to
marvell,armada-370-sata.
Fixes:
4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
Cc: <stable@vger.kernel.org>
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Kamal Mostafa [Thu, 28 Jan 2016 06:29:33 +0000 (22:29 -0800)]
tools/hv: Use include/uapi with __EXPORTED_HEADERS__
[ Upstream commit
50fe6dd10069e7c062e27f29606f6e91ea979399 ]
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. VSS_OP_REGISTER1).
Fixes:
3eb2094c59e8 ("Adding makefile for tools/hv")
Cc: <stable@vger.kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Spencer E. Olson [Tue, 12 Jan 2016 17:33:18 +0000 (10:33 -0700)]
staging: comedi: ni_tiocmd: change mistaken use of start_src for start_arg
[ Upstream commit
1fd24a4702d2af0ea4d5845126cf57d4d1796216 ]
This fixes a bug in function ni_tio_input_inttrig(). The trigger number
should be compared to cmd->start_arg, not cmd->start_src.
Fixes:
6a760394d7eb ("staging: comedi: ni_tiocmd: clarify the cmd->start_arg validation and use")
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexander Usyskin [Sun, 7 Feb 2016 21:35:32 +0000 (23:35 +0200)]
mei: bus: move driver api functions at the start of the file
[ Upstream commit
6238299774377b12c3e24507b100b2687eb5ea32 ]
To make the file more organize move mei client driver api
to the start of the file and add Kdoc.
There are no functional changes in this patch.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Hurley [Sun, 10 Jan 2016 01:48:45 +0000 (17:48 -0800)]
net: irda: Fix use-after-free in irtty_open()
[ Upstream commit
401879c57f01cbf2da204ad2e8db910525c6dbea ]
The N_IRDA line discipline may access the previous line discipline's closed
and already-fre private data on open [1].
The tty->disc_data field _never_ refers to valid data on entry to the
line discipline's open() method. Rather, the ldisc is expected to
initialize that field for its own use for the lifetime of the instance
(ie. from open() to close() only).
[1]
==================================================================
BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr
ffff8800331dd068
Read of size 4 by task a.out/13960
=============================================================================
BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected
-----------------------------------------------------------------------------
...
Call Trace:
[<
ffffffff815fa2ae>] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279
[<
ffffffff836938a2>] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436
[<
ffffffff829f1b80>] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447
[<
ffffffff829f21c0>] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567
[< inline >] tiocsetd drivers/tty/tty_io.c:2650
[<
ffffffff829da49e>] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883
[< inline >] vfs_ioctl fs/ioctl.c:43
[<
ffffffff816708ac>] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607
[< inline >] SYSC_ioctl fs/ioctl.c:622
[<
ffffffff81671204>] SyS_ioctl+0x74/0x80 fs/ioctl.c:613
[<
ffffffff852a7876>] entry_SYSCALL_64_fastpath+0x16/0x7a
Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tom Lendacky [Tue, 2 Feb 2016 17:38:21 +0000 (11:38 -0600)]
crypto: ccp - Don't assume export/import areas are aligned
[ Upstream commit
b31dde2a5cb1bf764282abf934266b7193c2bc7c ]
Use a local variable for the exported and imported state so that
alignment is not an issue. On export, set a local variable from the
request context and then memcpy the contents of the local variable to
the export memory area. On import, memcpy the import memory area into
a local variable and then use the local variable to set the request
context.
Cc: <stable@vger.kernel.org> # 3.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tom Lendacky [Fri, 29 Jan 2016 18:45:14 +0000 (12:45 -0600)]
crypto: ccp - Limit the amount of information exported
[ Upstream commit
d1662165ae612ec8b5f94a6b07e65ea58b6dce34 ]
Since the exported information can be exposed to user-space, instead of
exporting the entire request context only export the minimum information
needed.
Cc: <stable@vger.kernel.org> # 3.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Fri, 22 Jan 2016 10:53:55 +0000 (08:53 -0200)]
[media] pwc: Add USB id for Philips Spc880nc webcam
[ Upstream commit
7445e45d19a09e5269dc85f17f9635be29d2f76c ]
SPC 880NC PC camera discussions:
http://www.pclinuxos.com/forum/index.php/topic,135688.0.html
Cc: stable@vger.kernel.org
Reported-by: Kikim <klucznik0@op.pl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tiffany Lin [Tue, 19 Jan 2016 07:56:50 +0000 (05:56 -0200)]
[media] media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32
[ Upstream commit
7df5ab8774aa383c6d2bff00688d004585d96dfd ]
In v4l2-compliance utility, test QUERYBUF required correct length
value to go through each planar to check planar's length in
multi-planar buffer type
Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v3.7 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Hurley [Mon, 11 Jan 2016 04:36:12 +0000 (20:36 -0800)]
tty: Fix GPF in flush_to_ldisc(), part 2
[ Upstream commit
f33798deecbd59a2955f40ac0ae2bc7dff54c069 ]
commit
9ce119f318ba ("tty: Fix GPF in flush_to_ldisc()") fixed a
GPF caused by a line discipline which does not define a receive_buf()
method.
However, the vt driver (and speakup driver also) pushes selection
data directly to the line discipline receive_buf() method via
tty_ldisc_receive_buf(). Fix the same problem in tty_ldisc_receive_buf().
Cc: <stable@vger.kernel.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alexander Kochetkov [Tue, 26 Jan 2016 13:34:00 +0000 (16:34 +0300)]
clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks
[ Upstream commit
e8b63288b37dbb8457b510c9d96f6006da4653f6 ]
hclk_cpubus needs to keep running because it is needed for devices like
the rom, i2s0 or spdif to be accessible via cpu. Without that all
accesses to devices (readl/writel) return wrong data. So add it
to the list of critical clocks.
Fixes:
78eaf6095cc763c ("clk: rockchip: disable unused clocks")
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Cc: stable@vger.kernel.org # 4.1.x-
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Romain Perier [Sun, 23 Aug 2015 09:32:37 +0000 (11:32 +0200)]
clk: rockchip: Add pclk_peri to critical clocks on RK3066/RK3188
[ Upstream commit
3bba75a2ec32bd5fa7024a4de3b8cf9ee113a76a ]
Now that the rockchip clock subsystem does clock gating with GPIO banks,
these are no longer enabled once during probe and no longer stay enabled
for eternity. When all these clocks are disabled, the parent clock pclk_peri
might be disabled too, as no other child claims it. So, we need to add pclk_peri
to the critical clocks.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Tested-by: Michael Niewoehner <linux@mniewoehner.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael Niewoehner [Tue, 25 Aug 2015 20:22:07 +0000 (22:22 +0200)]
clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks
[ Upstream commit
1166160ab531198f7abc773992c0e04d0f9b7600 ]
pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.
Signed-off-by: Michael Niewoehner <linux@mniewoehner.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tom Lendacky [Tue, 12 Jan 2016 17:17:38 +0000 (11:17 -0600)]
crypto: ccp - Add hash state import and export support
[ Upstream commit
952bce9792e6bf36fda09c2e5718abb5d9327369 ]
Commit
8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
added a check to prevent ahash algorithms from successfully registering
if the import and export functions were not implemented. This prevents
an oops in the hash_accept function of algif_hash. This commit causes
the ccp-crypto module SHA support and AES CMAC support from successfully
registering and causing the ccp-crypto module load to fail because the
ahash import and export functions are not implemented.
Update the CCP Crypto API support to provide import and export support
for ahash algorithms.
Cc: <stable@vger.kernel.org> # 3.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dan Carpenter [Wed, 20 Jan 2016 09:54:51 +0000 (12:54 +0300)]
EDAC, amd64_edac: Shift wrapping issue in f1x_get_norm_dct_addr()
[ Upstream commit
6f3508f61c814ee852c199988a62bd954c50dfc1 ]
dct_sel_base_off is declared as a u64 but we're only using the lower 32
bits because of a shift wrapping bug. This can possibly truncate the
upper 16 bits of DctSelBaseOffset[47:26], causing us to misdecode the CS
row.
Fixes:
c8e518d5673d ('amd64_edac: Sanitize f10_get_base_addr_offset')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20160120095451.GB19898@mwanda
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andy Lutomirski [Tue, 5 Apr 2016 19:24:24 +0000 (12:24 -0700)]
x86/iopl/64: Properly context-switch IOPL on Xen PV
commit
b7a584598aea7ca73140cb87b40319944dd3393f upstream.
On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL. We need to context
switch it manually.
I'm doing this without going through paravirt because this is
specific to Xen PV. After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.
Fixes XSA-171.
Reviewewd-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ kamal: backport to 4.2-stable: no X86_FEATURE_XENPV so just call
xen_pv_domain() directly ]
Acked-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vladis Dronov [Mon, 16 Nov 2015 17:55:11 +0000 (15:55 -0200)]
[media] usbvision: fix crash on detecting device with invalid configuration
[ Upstream commit
fa52bd506f274b7619955917abfde355e3d19ffe ]
The usbvision driver crashes when a specially crafted usb device with invalid
number of interfaces or endpoints is detected. This fix adds checks that the
device has proper configuration expected by the driver.
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vasily Kulikov [Wed, 9 Sep 2015 22:36:00 +0000 (15:36 -0700)]
include/linux/poison.h: fix LIST_POISON{1,2} offset
[ Upstream commit
8a5e5e02fc83aaf67053ab53b359af08c6c49aaf ]
Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space"
is located starting from 0x0. Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.
The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu
uses only 0x10000). There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted. Changing it
to a smaller value solves the problem for small mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Signed-off-by: Vasily Kulikov <segoon@openwall.com>
Cc: Solar Designer <solar@openwall.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Howells [Tue, 24 Nov 2015 21:36:31 +0000 (21:36 +0000)]
KEYS: Fix handling of stored error in a negatively instantiated user key
[ Upstream commit
096fe9eaea40a17e125569f9e657e34cdb6d73bd ]
If a user key gets negatively instantiated, an error code is cached in the
payload area. A negatively instantiated key may be then be positively
instantiated by updating it with valid data. However, the ->update key
type method must be aware that the error code may be there.
The following may be used to trigger the bug in the user key type:
keyctl request2 user user "" @u
keyctl add user user "a" @u
which manifests itself as:
BUG: unable to handle kernel paging request at
00000000ffffff8a
IP: [<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
PGD
7cc30067 PUD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task:
ffff88003ddea700 ti:
ffff88003dd88000 task.ti:
ffff88003dd88000
RIP: 0010:[<
ffffffff810a376f>] [<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
[<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
RSP: 0018:
ffff88003dd8bdb0 EFLAGS:
00010246
RAX:
00000000ffffff82 RBX:
0000000000000000 RCX:
0000000000000001
RDX:
ffffffff81e3fe40 RSI:
0000000000000000 RDI:
00000000ffffff82
RBP:
ffff88003dd8bde0 R08:
ffff88007d2d2da0 R09:
0000000000000000
R10:
0000000000000000 R11:
ffff88003e8073c0 R12:
00000000ffffff82
R13:
ffff88003dd8be68 R14:
ffff88007d027600 R15:
ffff88003ddea700
FS:
0000000000b92880(0063) GS:
ffff88007fd00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00000000ffffff8a CR3:
000000007cc5f000 CR4:
00000000000006e0
Stack:
ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
Call Trace:
[<
ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
[<
ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
[< inline >] __key_update security/keys/key.c:730
[<
ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
[< inline >] SYSC_add_key security/keys/keyctl.c:125
[<
ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
[<
ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185
Note the error code (-ENOKEY) in EDX.
A similar bug can be tripped by:
keyctl request2 trusted user "" @u
keyctl add trusted user "a" @u
This should also affect encrypted keys - but that has to be correctly
parameterised or it will fail with EINVAL before getting to the bit that
will crashes.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andrew Honig [Wed, 18 Nov 2015 22:50:23 +0000 (14:50 -0800)]
KVM: x86: Reload pit counters for all channels when restoring state
[ Upstream commit
0185604c2d82c560dab2f2933a18f797e74ab5a8 ]
Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash. This will ensure
that 0 values are converted to 65536 as per the spec.
This is CVE-2015-7513.
Signed-off-by: Andy Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Roman Gushchin [Mon, 12 Oct 2015 13:33:44 +0000 (16:33 +0300)]
fuse: break infinite loop in fuse_fill_write_pages()
[ Upstream commit
3ca8138f014a913f98e6ef40e939868e1e9ea876 ]
I got a report about unkillable task eating CPU. Further
investigation shows, that the problem is in the fuse_fill_write_pages()
function. If iov's first segment has zero length, we get an infinite
loop, because we never reach iov_iter_advance() call.
Fix this by calling iov_iter_advance() before repeating an attempt to
copy data from userspace.
A similar problem is described in
124d3b7041f ("fix writev regression:
pan hanging unkillable and un-straceable"). If zero-length segmend
is followed by segment with invalid address,
iov_iter_fault_in_readable() checks only first segment (zero-length),
iov_iter_copy_from_user_atomic() skips it, fails at second and
returns zero -> goto again without skipping zero-length segment.
Patch calls iov_iter_advance() before goto again: we'll skip zero-length
segment at second iteraction and iov_iter_fault_in_readable() will detect
invalid address.
Special thanks to Konstantin Khlebnikov, who helped a lot with the commit
description.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Maxim Patlasov <mpatlasov@parallels.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Fixes:
ea9b9907b82a ("fuse: implement perform_write")
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Miklos Szeredi [Fri, 4 Dec 2015 18:18:48 +0000 (19:18 +0100)]
ovl: fix permission checking for setattr
[ Upstream commit
acff81ec2c79492b180fade3c2894425cd35a545 ]
[Al Viro] The bug is in being too enthusiastic about optimizing ->setattr()
away - instead of "copy verbatim with metadata" + "chmod/chown/utimes"
(with the former being always safe and the latter failing in case of
insufficient permissions) it tries to combine these two. Note that copyup
itself will have to do ->setattr() anyway; _that_ is where the elevated
capabilities are right. Having these two ->setattr() (one to set verbatim
copy of metadata, another to do what overlayfs ->setattr() had been asked
to do in the first place) combined is where it breaks.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
projects / platform / kernel / linux-exynos.git / log