22 Feb, 2018
40 commits
-
commit 5235553d821433e1f4fa720fd025d2c4b7ee9994 upstream.
Mikulas reported a workload that saw bad performance, and figured
out what it was due to various other types of requests being
accounted as reads. Flush requests, for instance. Due to the
high latency of those, we heavily throttle the writes to keep
the latencies in balance. But they really should be accounted
as writes.Fix this by checking the exact type of the request. If it's a
read, account as a read, if it's a write or a flush, account
as a write. Any other request we disregard. Previously everything
would have been mistakenly accounted as reads.Reported-by: Mikulas Patocka
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit e89e8d8fcdc6751e86ccad794b052fe67e6ad619 upstream.
Michal Kalderon reports a BUG that occurs just after device removal:
[ 169.112490] rpcrdma: removing device qedr0 for 192.168.110.146:20049
[ 169.143909] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 169.181837] IP: rpcrdma_dma_unmap_regbuf+0xa/0x60 [rpcrdma]The RPC/RDMA client transport attempts to allocate some resources
on demand. Registered buffers are one such resource. These are
allocated (or re-allocated) by xprt_rdma_allocate to hold RPC Call
and Reply messages. A hardware resource is associated with each of
these buffers, as they can be used for a Send or Receive Work
Request.If a device is removed from under an NFS/RDMA mount, the transport
layer is responsible for releasing all hardware resources before
the device can be finally unplugged. A BUG results when the NFS
mount hasn't yet seen much activity: the transport tries to release
resources that haven't yet been allocated.rpcrdma_free_regbuf() already checks for this case, so just move
that check to cover the DEVICE_REMOVAL case as well.Reported-by: Michal Kalderon
Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA ...")
Signed-off-by: Chuck Lever
Tested-by: Michal Kalderon
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Anna Schumaker
Signed-off-by: Greg Kroah-Hartman -
commit 1179e2c27efe21167ec9d882b14becefba2ee990 upstream.
Commit 16f906d66cd7 ("xprtrdma: Reduce required number of send
SGEs") introduced the rpcrdma_ia::ri_max_send_sges field. This fixes
a problem where xprtrdma would not work if the device's max_sge
capability was small (low single digits).At least RPCRDMA_MIN_SEND_SGES are needed for the inline parts of
each RPC. ri_max_send_sges is set to this value:ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES;
Then when marshaling each RPC, rpcrdma_args_inline uses that value
to determine whether the device has enough Send SGEs to convey an
NFS WRITE payload inline, or whether instead a Read chunk is
required.More recently, commit ae72950abf99 ("xprtrdma: Add data structure to
manage RDMA Send arguments") used the ri_max_send_sges value to
calculate the size of an array, but that commit erroneously assumed
ri_max_send_sges contains a value similar to the device's max_sge,
and not one that was reduced by the minimum SGE count.This assumption results in the calculated size of the sendctx's
Send SGE array to be too small. When the array is used to marshal
an RPC, the code can write Send SGEs into the following sendctx
element in that array, corrupting it. When the device's max_sge is
large, this issue is entirely harmless; but it results in an oops
in the provider's post_send method, if dev.attrs.max_sge is small.So let's straighten this out: ri_max_send_sges will now contain a
value with the same meaning as dev.attrs.max_sge, which makes
the code easier to understand, and enables rpcrdma_sendctx_create
to calculate the size of the SGE array correctly.Reported-by: Michal Kalderon
Fixes: 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs")
Signed-off-by: Chuck Lever
Tested-by: Michal Kalderon
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Anna Schumaker
Signed-off-by: Greg Kroah-Hartman -
commit 9428088c90b6f7d5edd2a1b0d742c75339b36f6e upstream.
QXL associates mouse state with its primary plane.
Destroying a primary plane and putting a new one in place has the side
effect of destroying the cursor as well.This commit changes the driver to reapply the cursor any time a new
primary is created. It achieves this by keeping a reference to the
cursor bo on the qxl_crtc struct.This fix is very similar to
commit 4532b241a4b7 ("drm/qxl: reapply cursor after SetCrtc calls")
which got implicitly reverted as part of implementing the atomic
modeset feature.Cc: Gerd Hoffmann
Cc: Dave Airlie
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1512097
Fixes: 1277eed5fecb ("drm: qxl: Atomic phase 1: convert cursor to universal plane")
Cc: stable@vger.kernel.org
Signed-off-by: Ray Strode
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 62676d10b483a2ff6e8b08c5e7c7d63a831343f5 upstream.
This patch changes the way the primary surface is used for dumb
framebuffers. Instead of configuring the bo itself as primary surface
a shadow bo is created and used instead. Framebuffers can share the
shadow bo in case they have the same format and resolution.On atomic plane updates we don't have to update the primary surface in
case we pageflip from one framebuffer to another framebuffer which
shares the same shadow. This in turn avoids the flicker caused by the
primary-destroy + primary-create cycle, which is very annonying when
running wayland on qxl.The qxl driver never actually writes to the shadow bo. It sends qxl
blit commands which update it though, and the spice server might
actually execute them (and thereby write to the shadow) in case the
local rendering is kicked for some reason. This happens for example in
case qemu is asked to write out a dump of the guest display (screendump
monitor command).Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
Link: http://patchwork.freedesktop.org/patch/msgid/20171019062150.28090-3-kraxel@redhat.com
Signed-off-by: Greg Kroah-Hartman -
commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream.
When KASAN is enabled, the swapper page table contains many identical
mappings of the zero page, which can lead to a stall during boot whilst
the G -> nG code continually walks the same page table entries looking
for global mappings.This patch sets the nG bit (bit 11, which is IGNORED) in table entries
after processing the subtree so we can easily skip them if we see them
a second time.Tested-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream.
There has been a coding error in rtl8821ae since it was first introduced,
namely that an 8-bit register was read using a 16-bit read in
_rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75
("rtlwifi: Fix alignment issues"); however, this change led to
instability in the connection. To restore stability, this change
was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection
lost problem").Unfortunately, the unaligned access causes machine checks in ARM
architecture, and we were finally forced to find the actual cause of the
problem on x86 platforms. Following a suggestion from Pkshih
, it was found that increasing the ASPM L1
latency from 0 to 7 fixed the instability. This parameter was varied to
see if a smaller value would work; however, it appears that 7 is the
safest value. A new symbol is defined for this quantity, thus it can be
easily changed if necessary.Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem")
Cc: Stable # 4.14+
Fix-suggested-by: Pkshih
Signed-off-by: Larry Finger
Tested-by: James Cameron # x86_64 OLPC NL3
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 3968523f855050b8195134da951b87c20bd66130 upstream.
mpls_label_ok() validates that the 'platform_label' array index from a
userspace netlink message payload is valid. Under speculation the
mpls_label_ok() result may not resolve in the CPU pipeline until after
the index is used to access an array element. Sanitize the index to zero
to prevent userspace-controlled arbitrary out-of-bounds speculation, a
precursor for a speculative execution side channel vulnerability.Cc:
Cc: "David S. Miller"
Cc: Eric W. Biederman
Signed-off-by: Dan Williams
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 07234021410bbc27b7c86c18de98616c29fbe667 upstream.
Al Viro reported:
For substring - sure, but what about something like "*a*b" and "a*b"?
AFAICS, filter_parse_regex() ends up with identical results in both
cases - MATCH_GLOB and *search = "a*b". And no way for the caller
to tell one from another.Testing this with the following:
# cd /sys/kernel/tracing
# echo '*raw*lock' > set_ftrace_filter
bash: echo: write error: Invalid argumentWith this patch:
# echo '*raw*lock' > set_ftrace_filter
# cat set_ftrace_filter
_raw_read_trylock
_raw_write_trylock
_raw_read_unlock
_raw_spin_unlock
_raw_write_unlock
_raw_spin_trylock
_raw_spin_lock
_raw_write_lock
_raw_read_lockAl recommended not setting the search buffer to skip the first '*' unless we
know we are not using MATCH_GLOB. This implements his suggested logic.Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk
Cc: stable@vger.kernel.org
Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching")
Reviewed-by: Masami Hiramatsu
Reported-by: Al Viro
Suggsted-by: Al Viro
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman -
commit cf5eebae2cd28d37581507668605f4d23cd7218d upstream.
When resetting iterator on a zero offset we need to discard any data
already in the buffer (count), and private state of the iterator (version).For example this bug results in first line being repeated in /proc/mounts
if doing a zero size read before a non-zero size read.Reported-by: Rich Felker
Signed-off-by: Miklos Szeredi
Fixes: e522751d605d ("seq_file: reset iterator to first record for zero offset")
Cc: # v4.10
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 29fee6eed2811ff1089b30fc579a2d19d78016ab upstream.
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.struct xsd_sockmsg
{
uint32_t type; /* XS_??? */
uint32_t req_id;/* Request identifier, echoed in daemon's response. */
uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
uint32_t len; /* Length of data following this. *//* Generally followed by nul-terminated string(s). */
};Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.Cc: # 4.11
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Reported-by: Bhavesh Davda
Signed-off-by: Joao Martins
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit 781198f1f373c3e350dbeb3af04a7d4c81c1b8d7 upstream.
Commit 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
removed the check for autotranslation from {set,clear}_foreign_p2m_mapping
but those are called by grant-table.c also on PVH/HVM guests.Cc: # 4.14
Fixes: 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
Signed-off-by: Simon Gaiser
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit e573427a440fd67d3f522357d7ac901d59281948 upstream.
This feature bit restricts older clients from performing certain
maintenance operations against an image (e.g. clone, snap create).
krbd does not perform maintenance operations.Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov
Reviewed-by: Jason Dillaman
Signed-off-by: Greg Kroah-Hartman -
commit 724ba8b30b044aa0d94b1cd374fc15806cdd6f18 upstream.
When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.Signed-off-by: Nicolas Pitre
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Greg Kroah-Hartman -
commit 9cb18db0701f6b74f0c45c23ad767b3ebebe37f6 upstream.
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.To make things worse, the parent display node was also prematurely
freed.Note that the display and timings node references are never put after a
successful dt-initialisation so the nodes would leak on later probe
deferrals and on driver unbind.Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
Cc: stable # 3.13
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Signed-off-by: Johan Hovold
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Greg Kroah-Hartman -
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable # 3.18
Acked-by: Murali Karicheri
Signed-off-by: Johan Hovold
[lorenzo.pieralisi@arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi
Signed-off-by: Greg Kroah-Hartman -
commit 3b65ca50d24ce33cb92d88840e289135c92b40ed upstream.
With the inbound DMA mapping supported added, the iProc PCIe driver
parses DT property "dma-ranges" through call to
"of_pci_dma_range_parser_init()". In the case of BCMA, this results in a
NULL pointer deference due to a missing of_node.Fix this by adding a guard in pcie-iproc-platform.c to only enable the
inbound DMA mapping logic when DT property "dma-ranges" is present.Fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support")
Reported-by: Rafał Miłecki
Signed-off-by: Ray Jui
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi
Tested-by: Rafał Miłecki
cc: # 4.10+
Signed-off-by: Greg Kroah-Hartman -
commit deb86999323661c019ef2740eb9d479d1e526b5c upstream.
HiSilicon Hip06/Hip07 can operate as either a Root Port or an Endpoint. It
always advertises an MSI capability, but it can only generate MSIs when in
Endpoint mode.The device has the same Vendor and Device IDs in both modes, so check the
Class Code and disable MSI only when operating as a Root Port.[bhelgaas: changelog]
Fixes: 72f2ff0deb87 ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports")
Signed-off-by: Dongdong Liu
Signed-off-by: Bjorn Helgaas
Reviewed-by: Zhou Wang
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Greg Kroah-Hartman -
commit 67a3ba25aa955198196f40b76b329b3ab9ad415a upstream.
Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
fix to ensure that the memory range between PHYS_OFFSET and low memory
address specified by mem= cmdline argument is not later processed by
free_all_bootmem. This change was incorrect for systems where the
commandline specifies more than 1 mem argument, as it will cause all
memory between PHYS_OFFSET and each of the memory offsets to be marked
as reserved, which results in parts of the RAM marked as reserved
(Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
mem=768M@0x30000000').Change the behaviour to ensure that only the range between PHYS_OFFSET
and the lowest start address of the memories is marked as protected.This change also ensures that the range is marked protected even if it's
only defined through the devicetree and not only via commandline
arguments.Reported-by: Mathieu Malaterre
Signed-off-by: Marcin Nowakowski
Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: # v4.11+
Tested-by: Mathieu Malaterre
Patchwork: https://patchwork.linux-mips.org/patch/18562/
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit 2e6522c565522a2e18409c315c49d78c8b74807b upstream.
MIPS_GENERIC selects some options conditional on BIG_ENDIAN which does
not exist.Replace BIG_ENDIAN with CPU_BIG_ENDIAN which is the correct kconfig
name. Note that BMIPS_GENERIC does the same which confirms that this
patch is needed.Fixes: eed0eabd12ef0 ("MIPS: generic: Introduce generic DT-based board support")
Signed-off-by: Corentin Labbe
Reviewed-by: James Hogan
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: # 4.9+
Patchwork: https://patchwork.linux-mips.org/patch/18495/
[jhogan@kernel.org: Clean up commit message]
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit 10a0cd6e4932b5078215b1ec2c896597eec0eff9 upstream.
The functions devm_memremap_pages() and devm_memremap_pages_release() use
different ways to calculate the section-aligned amount of memory. The
latter function may use an incorrect size if the memory region is small
but straddles a section border.Use the same code for both.
Cc:
Fixes: 5f29a77cd957 ("mm: fix mixed zone detection in devm_memremap_pages")
Signed-off-by: Jan H. Schönherr
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit af27d9403f5b80685b79c88425086edccecaf711 upstream.
We get a warning about some slow configurations in randconfig kernels:
mm/memory.c:83:2: error: #warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid. [-Werror=cpp]
The warning is reasonable by itself, but gets in the way of randconfig
build testing, so I'm hiding it whenever CONFIG_COMPILE_TEST is set.The warning was added in 2013 in commit 75980e97dacc ("mm: fold
page->_last_nid into page->flags where possible").Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9f0372488cc9243018a812e8cfbf27de650b187b upstream.
The grpid option is currently described as being the same as nogrpid.
Signed-off-by: Ernesto A. Fernández
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 06f29cc81f0350261f59643a505010531130eea0 upstream.
In the function __ext4_grp_locked_error(), __save_error_info()
is called to save error info in super block block, but does not sync
that information to disk to info the subsequence fsck after reboot.This patch writes the error information to disk. After this patch,
I think there is no obvious EXT4 error handle branches which leads to
"Remounting filesystem read-only" will leave the disk partition miss
the subsequence fsck.Signed-off-by: Zhouyi Zhou
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit abbc3f9395c76d554a9ed27d4b1ebfb5d9b0e4ca upstream.
This patch fixes a race between the shutdown path and bio completion
handling. In the ext4 direct io path with async io, after submitting a
bio to the block layer, if journal starting fails,
ext4_direct_IO_write() would bail out pretending that the IO
failed. The caller would have had no way of knowing whether or not the
IO was successfully submitted. So instead, we return -EIOCBQUEUED in
this case. Now, the caller knows that the IO was submitted. The bio
completion handler takes care of the error.Tested: Ran the shutdown xfstest test 461 in loop for over 2 hours across
4 machines resulting in over 400 runs. Verified that the race didn't
occur. Usually the race was seen in about 20-30 iterations.Signed-off-by: Harshad Shirwadkar
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit f69120ce6c024aa634a8fc25787205e42f0ccbe6 upstream.
Sphinx emits various (26) warnings when building make target 'htmldocs'.
Currently struct definitions contain duplicate documentation, some as
kernel-docs and some as standard c89 comments. We can reduce
duplication while cleaning up the kernel docs.Move all kernel-docs to right above each struct member. Use the set of
all existing comments (kernel-doc and c89). Add documentation for
missing struct members and function arguments.Signed-off-by: Tobin C. Harding
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit d6fa7588fd7a8def4c747c0c574ce85d453e3788 upstream.
Commit 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb
changes") amended this driver's ->probe hook to lock decoding of normal
(non-legacy) I/O space accesses to the integrated GPU on dual-GPU
MacBook Pros. The lock stays in place until the driver is unbound.The change was made to work around an issue with the out-of-tree nvidia
graphics driver (available at http://www.nvidia.com/object/unix.html).
It contains the following sequence in nvidia/nv.c:#if defined(CONFIG_VGA_ARB) && !defined(NVCPU_PPC64LE)
#if defined(VGA_DEFAULT_DEVICE)
vga_tryget(VGA_DEFAULT_DEVICE, VGA_RSRC_LEGACY_MASK);
#endif
vga_set_legacy_decoding(dev, VGA_RSRC_NONE);
#endifThis code was reported to cause deadlocks with VFIO already in 2013:
https://devtalk.nvidia.com/default/topic/545560I've reported the issue to Nvidia developers once more in 2017:
https://www.spinics.net/lists/dri-devel/msg138754.htmlOn the MacBookPro10,1, this code apparently breaks backlight control
(which is handled by apple-gmux via an I/O region starting at 0x700),
as reported by Petri Hodju:
https://bugzilla.kernel.org/show_bug.cgi?id=86121I tried to replicate Petri's observations on my MacBook9,1, which uses
the same Intel Ivy Bridge + Nvidia GeForce GT 650M architecture, to no
avail. On my machine apple-gmux' I/O region remains accessible even
with the nvidia driver loaded and commit 4eebd5a4e726 reverted.
Petri reported that apple-gmux becomes accessible again after a
suspend/resume cycle because the BIOS changed the VGA routing on the
root port to the Nvidia GPU. Perhaps this is a BIOS issue after all
that can be fixed with an update?In any case, the change made by commit 4eebd5a4e726 has turned out to
cause two new issues:* Wilfried Klaebe reports a deadlock when launching Xorg because it
opens /dev/vga_arbiter and calls vga_get(), but apple-gmux is holding
a lock on I/O space indefinitely. It looks like apple-gmux' current
behavior is an abuse of the vgaarb API as locks are not meant to be
held for longer periods:
https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11
https://bugzilla.kernel.org/attachment.cgi?id=217541* On dual GPU MacBook Pros introduced since 2013, the integrated GPU is
powergated on boot und thus becomes invisible to Linux unless a custom
EFI protocol is used to leave it powered on. (A patch exists but is
not in mainline yet due to several negative side effects.) On these
machines, locking I/O to the integrated GPU (as done by 4eebd5a4e726)
fails and backlight control is therefore broken:
https://bugzilla.kernel.org/show_bug.cgi?id=105051So let's revert commit 4eebd5a4e726 please. Users experiencing the
issue with the proprietary nvidia driver can comment out the above-
quoted problematic code as a workaround (or try updating the BIOS).Cc: Petri Hodju
Cc: Bjorn Helgaas
Cc: Bruno Prémont
Cc: Andy Ritger
Cc: Ronald Tschalär
Tested-by: Wilfried Klaebe
Signed-off-by: Lukas Wunner
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Greg Kroah-Hartman -
commit 2572cf57d75a7f91835d9a38771e9e76d575d122 upstream.
The consumers of this routine expects the affinity map of of vector
index relative to the first completion vector. The upper layers are
not aware of internal/private completion vectors that mlx5 allocates
for its own usage.Hence, return the affinity map of vector index relative to the first
completion vector.Fixes: 05e0cc84e00c ("net/mlx5: Fix get vector affinity helper function")
Reported-by: Logan Gunthorpe
Tested-by: Max Gurtovoy
Reviewed-by: Max Gurtovoy
Cc: # v4.15
Signed-off-by: Sagi Grimberg
Signed-off-by: Doug Ledford
Signed-off-by: Greg Kroah-Hartman -
commit fe0e58048f005fdce315eb4d185e5c160be4ac01 upstream.
This reverts commit 0a44697627d17a66d7dc98f17aeca07ca79c5c20.
This commit was initially intended to fix problems with hs200 and hs400
on some boards, mainly the odroid-c2. The OC2 (Rev 0.2) I have performs
well in this modes, so I could not confirm these issues.We've had several reports about the issues being still present on (some)
OC2, so apparently, this change does not do what it was supposed to do.
Maybe the eMMC signal quality is on the edge on the board. This may
explain the variability we see in term of stability, but this is just a
guess. Lowering the max_frequency to 100Mhz seems to do trick for those
affected by the issueWorse, the commit created new issues (CRC errors and hangs) on other
boards, such as the kvim 1 and 2, the p200 or the libretech-cc.According to amlogic, the Tx phase should not be tuned and left in its
default configuration, so it is best to just revert the commit.Fixes: 0a44697627d1 ("mmc: meson-gx: include tx phase in the tuning process")
Cc: # 4.14+
Signed-off-by: Jerome Brunet
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 118032be389009b07ecb5a03ffe219a89d421def upstream.
The optional DT parameter max-frequency could init the max bus frequency.
So take care of this, before setting the max bus frequency.Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.")
Signed-off-by: Phil Elwell
Signed-off-by: Stefan Wahren
Cc: # 4.12+
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit bd9b902798ab14d19ca116b10bde581ddff8f905 upstream.
The bounce buffer is gone from the MMC core, and now we found out
that there are some (crippled) i.MX boards out there that have broken
ADMA (cannot do scatter-gather), and also broken PIO so they must
use SDMA. Closer examination shows a less significant slowdown
also on SDMA-only capable Laptop hosts.SDMA sets down the number of segments to one, so that each segment
gets turned into a singular request that ping-pongs to the block
layer before the next request/segment is issued.Apparently it happens a lot that the block layer send requests
that include a lot of physically discontiguous segments. My guess
is that this phenomenon is coming from the file system.These devices that cannot handle scatterlists in hardware can see
major benefits from a DMA-contiguous bounce buffer.This patch accumulates those fragmented scatterlists in a physically
contiguous bounce buffer so that we can issue bigger DMA data chunks
to/from the card.When tested with a PCI-integrated host (1217:8221) that
only supports SDMA:
0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS
SD/MMC Card Reader Controller (rev 05)
This patch gave ~1Mbyte/s improved throughput on large reads and
writes when testing using iozone than without the patch.dmesg:
sdhci-pci 0000:0b:00.0: SDHCI controller found [1217:8221] (rev 5)
mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
mmc0: SDHCI controller on PCI [0000:0b:00.0] using DMAOn the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35
the patch restores the performance to what it was before we removed
the bounce buffers.Cc: Pierre Ossman
Cc: Benoît Thébaudeau
Cc: Fabio Estevam
Cc: Benjamin Beckmeyer
Cc: stable@vger.kernel.org # v4.14+
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Tested-by: Benjamin Beckmeyer
Acked-by: Adrian Hunter
Signed-off-by: Linus Walleij
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 3876bbe27d04b848750d5310a37d6b76b593f648 upstream.
KMSAN reported use of uninitialized |entry->e_referenced| in a condition
in mb_cache_shrink():==================================================================
BUG: KMSAN: use of uninitialized memory in mb_cache_shrink+0x3b4/0xc50 fs/mbcache.c:287
CPU: 2 PID: 816 Comm: kswapd1 Not tainted 4.11.0-rc5+ #2877
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x172/0x1c0 lib/dump_stack.c:52
kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927
__msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469
mb_cache_shrink+0x3b4/0xc50 fs/mbcache.c:287
mb_cache_scan+0x67/0x80 fs/mbcache.c:321
do_shrink_slab mm/vmscan.c:397 [inline]
shrink_slab+0xc3d/0x12d0 mm/vmscan.c:500
shrink_node+0x208f/0x2fd0 mm/vmscan.c:2603
kswapd_shrink_node mm/vmscan.c:3172 [inline]
balance_pgdat mm/vmscan.c:3289 [inline]
kswapd+0x160f/0x2850 mm/vmscan.c:3478
kthread+0x46c/0x5f0 kernel/kthread.c:230
ret_from_fork+0x29/0x40 arch/x86/entry/entry_64.S:430
chained origin:
save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:317 [inline]
kmsan_internal_chain_origin+0x12a/0x1f0 mm/kmsan/kmsan.c:547
__msan_store_shadow_origin_1+0xac/0x110 mm/kmsan/kmsan_instr.c:257
mb_cache_entry_create+0x3b3/0xc60 fs/mbcache.c:95
ext4_xattr_cache_insert fs/ext4/xattr.c:1647 [inline]
ext4_xattr_block_set+0x4c82/0x5530 fs/ext4/xattr.c:1022
ext4_xattr_set_handle+0x1332/0x20a0 fs/ext4/xattr.c:1252
ext4_xattr_set+0x4d2/0x680 fs/ext4/xattr.c:1306
ext4_xattr_trusted_set+0x8d/0xa0 fs/ext4/xattr_trusted.c:36
__vfs_setxattr+0x703/0x790 fs/xattr.c:149
__vfs_setxattr_noperm+0x27a/0x6f0 fs/xattr.c:180
vfs_setxattr fs/xattr.c:223 [inline]
setxattr+0x6ae/0x790 fs/xattr.c:449
path_setxattr+0x1eb/0x380 fs/xattr.c:468
SYSC_lsetxattr+0x8d/0xb0 fs/xattr.c:490
SyS_lsetxattr+0x77/0xa0 fs/xattr.c:486
entry_SYSCALL_64_fastpath+0x13/0x94
origin:
save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 [inline]
kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198
kmsan_kmalloc+0x7f/0xe0 mm/kmsan/kmsan.c:337
kmem_cache_alloc+0x1c2/0x1e0 mm/slub.c:2766
mb_cache_entry_create+0x283/0xc60 fs/mbcache.c:86
ext4_xattr_cache_insert fs/ext4/xattr.c:1647 [inline]
ext4_xattr_block_set+0x4c82/0x5530 fs/ext4/xattr.c:1022
ext4_xattr_set_handle+0x1332/0x20a0 fs/ext4/xattr.c:1252
ext4_xattr_set+0x4d2/0x680 fs/ext4/xattr.c:1306
ext4_xattr_trusted_set+0x8d/0xa0 fs/ext4/xattr_trusted.c:36
__vfs_setxattr+0x703/0x790 fs/xattr.c:149
__vfs_setxattr_noperm+0x27a/0x6f0 fs/xattr.c:180
vfs_setxattr fs/xattr.c:223 [inline]
setxattr+0x6ae/0x790 fs/xattr.c:449
path_setxattr+0x1eb/0x380 fs/xattr.c:468
SYSC_lsetxattr+0x8d/0xb0 fs/xattr.c:490
SyS_lsetxattr+0x77/0xa0 fs/xattr.c:486
entry_SYSCALL_64_fastpath+0x13/0x94
==================================================================Signed-off-by: Alexander Potapenko
Signed-off-by: Eric Biggers
Cc: stable@vger.kernel.org # v4.6
Signed-off-by: Greg Kroah-Hartman -
commit 5b8b58063029f02da573120ef4dc9079822e3cda upstream.
According to the OPAL docs:
skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txtOPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and
this indicates either a transient or permanent error.Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
permanent error particularly well, in that you could end up in a busy
loop.This was not too hard to trigger on an AMI BMC based OpenPOWER machine
doing a continuous "ipmitool mc reset cold" to the BMC, the result of
that being that we'd get stuck in an infinite loop in
opal_get_rtc_time().We now retry a few times before returning the error higher up the
stack.Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Stewart Smith
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 3a61b527b4e1f285d21b6e9e623dc45cf8bb391f upstream.
Check the variable that was most recently initialized.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)//
@@
expression x, y, f, g, e, m;
statement S1,S2,S3,S4;
@@x = f(...);
if (\(\&e\)) S1 else S2
(
x = g(...);
|
m = g(...,&x,...);
|
y = g(...);
*if (e)
S3 else S4
)
//Signed-off-by: Julia Lawall
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 239b5f64e12b1f09f506c164dff0374924782979 upstream.
Fixes stability issues.
v2: clamp sclk to 600 Mhz
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 16e574d762ac5512eb922ac0ac5eed360b7db9d8 upstream.
References to CPU part number MIDR_QCOM_FALKOR were dropped from the
mailing list patch due to mainline/arm64 branch dependency. So this
patch adds the missing part number.Fixes: ec82b567a74f ("arm64: Implement branch predictor hardening for Falkor")
Acked-by: Marc Zyngier
Signed-off-by: Shanker Donthineni
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit 24b8ef699e8221d2b7f813adaab13eec053e1507 upstream.
In the past the ast driver relied upon the fbdev emulation helpers to
call ->load_lut at boot-up. But sincecommit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200drm/fb-helper: factor out pseudo-palette
that's cleaned up and drivers are expected to boot into a consistent
lut state. This patch fixes that.Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette")
Cc: Peter Rosin
Cc: Daniel Vetter
Cc: # v4.14+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123
Cc: Bill Fraser
Reported-and-Tested-by: Bill Fraser
Signed-off-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit adab595d16abe48e9c097f000bf8921d35b28fb7 upstream.
The handle describes kernel logical address, should be
unsigned long and not uint32_t.
Fixes KASAN error and GFP on driver unload.Reviewed-by: Rex Zhu
Reviewed-by: Alex Deucher
Signed-off-by: Andrey Grodzovsky
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 16c6db3688734b27487a42d0c2a1062d0b2bad03 upstream.
qxl_cursor_atomic_update allocs a bo for the cursor that
it never frees up at the end of the function.This commit fixes that.
Signed-off-by: Ray Strode
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 95244db2d3f743f37e69446a2807dd1a42750542 upstream.
The buf pointer was not being incremented inside the loop
meaning the same block of data would be read or written
repeatedly.
(v2) Change 'buf' pointer to uint8_t* typeCc: stable@vger.kernel.org
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")Signed-off-by: Tom St Denis
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
