Hide kernel pointers from unprivileged users by using %pk format-specifier
instead of %p. This respects the kptr_restrict sysctl setting which is by
default on. So by default %pk will print zeroes as address. echo 1 to
kptr_restrict to print proper kernel address.
Change-Id: Ia300e3e38b8662afac15edda28959564b05c9367
Signed-off-by: Satyajit Desai <sadesai@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Check for failed allocations and return error code if allocation
failed. Also checking for NULL function pointer before calling
the function pointer.
Change-Id: I264f81ca43c731dd4abdb0036b3c6bf0b4b11167
Signed-off-by: Edward Lee <eleekimk@codeaurora.org>
Deletion of extra file added previously with
commit: d987cbedc3e69076c25e59ad08658d1d014f84dc
Change-Id: Ie4c125cf6b1c36bf9825456da93ea3747fc586ad
Signed-off-by: Pradosh Das <prados@codeaurora.org>
In ion_debug_heap_show we're iterating over an rb tree (dev->clients)
that could change while we're iterating. Fix this by taking the lock
that is used to control access to this tree.
Change-Id: I6832e1e98e2d2a69fc653451d3752d43ec3ef269
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
There are a few places in Ion where we are iterating over volatile rb
trees without proper locking. In some places the proper locking cannot
be added since it would require us to take locks in a different order
than they are taken in other places in Ion. Fix this by re-working some
of the debug code so that we can take locks in an allowed order.
One side-effect of the re-work is that the memory maps will now show
every client that has a handle to a particular region of memory, rather
than just showing the first one that we encounter. This will allow for
more accurate accounting and will give better insight as to who is
actually using the memory.
Change-Id: Ia43e4dbc412cd480c828173f8c20b5095d87d858
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Currently we use an rb tree to store information about the memory map
which gets passed to the heap print_debug functions. The reason for
using a tree instead of a simple list is to maintain sortedness as we
build the memory map. However, it can be necessary to store multiple
entries for the same address in the memory map since there can be
multiple clients with handles to the same buffer. This information is
interesting and useful but we currently can't store and display it since
the rb tree requires that the key used for sorting (the physical address
in this case) be unique. Fix this by replacing the rb tree with a linked
list. In order to maintain sorted output of the print_debug functions,
sort the list by physical address after fully building the list.
This also has the positive side-effect of simplifying the code and
making future print_debug methods less error-prone.
Change-Id: I5b129fd809fb53c66042eab10d096238a34c2b20
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Removes contention for lock between allocate and free by reducing
the length of time the lock is held for. Split out a seperate
lock to protect the list of heaps and replace it with a rwsem since
the list will most likely only be updated during initialization.
Change-Id: Id10464dfe0d60cdcd64f29edfc94317d8e5ee251
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Git-commit: 675a52aa0d89e8b6c0c05849627381d8a64b2b2b
Git-repo: https://android.googlesource.com/kernel/common
[lauraa@codeaurora.org: Context differences due to debugfs
differences. Need to adjust locking on MSM specific extensions]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Clients may take dma_bufs directly. Add an API to go from
dma_bufs to Ion handles where appropriate.
Change-Id: Ieb2786629dfbbe30aa2778d6ee16113035bce115
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Currently ion can only share buffers with dma buf fd's. Fd's can not be
used inside the kernel as they are process specific so support for
sharing buffers with dma buf kernel handles is needed to support kernel
only use cases. An example use case could be a GPU driver using ion
that wants to share its output buffers with a 3d party display
controller driver supporting dma buf.
Change-Id: I74388160ad65ee5380b87dbb20521a97ddf6727a
Signed-off-by: Johan Mossberg <johan.mossberg@stericsson.com>
Git-commit: 1a6c74e0d58f6ca028f36c3d794fecff8543bbfb
Git-repo: https://android.googlesource.com/kernel/common
[lauraa@codeaurora.org: update callers of function]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
When an sgtable is allocated with sg_alloc_table, the table needs
to be destroyed in addition to being freed. Destroy the sgtable
when freeing the associated memory.
Change-Id: Iedba81146ba453070790f071848f86826f7eec9c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
There is a bug on some hardware that requires us to overmap Iommu
mappings by 2x. Currently, we set aside a dummy buffer onto which we
map all of these dummy mappings. In general, for large mappings it's
nice to use the more efficient iommu_map_range instead of calling
iommu_map repeatedly. However, with our current approach in
msm_iommu_map_extra we can't use iommu_map_range for page_sizes larger
than the dummy buffer. To avoid wasting memory by increasing the size
of the dummy buffer, we can simply remap on top of the the buffer
being mapped in the first place. Since the second mapping should never
be used (besides by the buggy hardware) this should not be a problem.
Re-use existing buffers for all `extra' mappings. Essentially, map the
same physical address range twice. To be extra safe, make the second
mapping read-only.
Change-Id: I35462ad50de8da1f2befa3e3f0895925535cdc98
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The preferred allocation of memory for kernel data structures in
ION is to use kmalloc. This is mainly for performance reasons. However,
we are not guaranteed to be able to allocate large sizes. So to keep
the code performing well and at the same time allow for larger allocations,
implement a fallback mechanism for allocation of memory for ION kernel data
structures.
CRs-Fixed: 488521
Change-Id: I8c6a13ad74cce69f590920d28c01a58f7a540fd2
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[Resolved merge conflict]
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Use correct type for variables to prevent overflow of signed
type when assiging from an unsigned type.
Change-Id: I0055d35c7310d111de590db3798950fd98f1b298
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
There are some Ion clients who would like to use the kmalloc
heap. Enable it.
Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Align the virtual address to the max buffer size to
allow IOMMU mappings at the biggest buffer size.
Change-Id: I74ba665c1782e2f0631274766c5caeeb192224e0
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Video has very large buffers to be flushed. Due to lack of
vmalloc space, ion_map_kernel cannot be called on each of
the video buffers. With this change the ion handle can be
flushed without the need of the kernel mapping.
Change-Id: If026f21e44a2cce6c2b8c232fc80a69d0dabcd14
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
Conflicts:
drivers/gpu/ion/ion_cp_heap.c
drivers/gpu/ion/msm/msm_ion.c
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
On the low-class hardware like flo this only introduces issues
and performance degradation due to increased scheduler overhead.
Revert "arm: configs: flo: set CONFIG_HZ to 300"
This reverts commit 029a1baa6f.
Revert "ARM: msm: flo: fix idle_timeout value to 100ms"
This reverts commit a63fd90f21.
Revert "msm: kgsl: Fix direct references to HZ"
This reverts commit 38d48e1127.
Change-Id: Ib65977c959bff9cce43f5039f8f543e074992fec
Make the various timeout values HZ agnostic by using the proper
macros and values instead.
Change-Id: I906b948657c8873518042c7465272c98c5391e59
Signed-off-by: Suman Tatiraju <sumant@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
This separates the kref for ion handles into two components.
Userspace requests through the ioctl will hold at most one
reference to the internally used kref. All additional requests
will increment a separate counter, and the original reference is
only put once that counter hits 0. This protects the kernel from
a poorly behaving userspace.
Bug: 34276203
Change-Id: Ibc36bc4405788ed0fea7337b541cad3be2b934c0
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Git-repo: https://android.googlesource.com/kernel/msm/
Git-commit: 20abfcc16884a5af973a5e91dd013ddd789c44f4
[d-cagle@codeaurora.org: Resolve style issues]
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
Signed-off-by: Arun KS <arunks@codeaurora.org>
[arunks@codeaurora.org: ported to 3.4]
The format specifier %p can leak kernel addresses
while not valuing the kptr_restrict system settings.
Use %pK instead of %p, which evaluates whether
kptr_restrict is set.
Change-Id: I0778e43e0a03852ca2944377256a7b401586a747
Signed-off-by: Divya Ponnusamy <pdivya@codeaurora.org>
Signed-off-by: Sudeep Yedalapure <sudeepy@codeaurora.org>
(cherry picked from commit aff982f224d45a7faf7ad4e74633d1a8510a1c04)
A malicious application can take advantage of the ION contig heap to
create a specific memory chunk size to exercise a rowhammer attack on the
physical hardware.
So remove support for the ION contig heap.
Change-Id: I9cb454cebb74df291479cecc3533d2c684363f77
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Prakash Gupta <guptap@codeaurora.org>
pagetable list is protected by ptlock. Few functions
while iterating over a pagetable list takes same ptlock,
kgsl_destroy_pagetable() also need same lock. This will
cause spinlock recursion if kgsl_destroy_pagetable()
called while iterating over a list. Created two versions
of same function one is with lock and other is without
lock.
CRs-Fixed: 621172
Change-Id: I61440f99022fce8629a57bb5661e2eef9613187b
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
commit 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e upstream.
There are few defects in vga_get() related to signal hadning:
- we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
case;
- if we found pending signal we must remove ourself from wait queue
and change task state back to running;
- -ERESTARTSYS is more appropriate, I guess.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
If we add the mem entry pointer in the process idr and rb tree
too early, other threads can do operations on the entry by
guessing the ID or GPU address before the object gets returned
by the creating operation.
Allocate an ID for the object but don't assign the pointer until
right before the creating function returns ensuring that another
operation can't access it until it is ready.
Bug: 28026365
CRs-Fixed: 1002974
Change-Id: Ic0dedbadc0dd2125bd2a7bcc152972c0555e07f8
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
Signed-off-by: Santhosh Punugu <spunug@codeaurora.org>
commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream.
On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.
This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 9ac0934bbe52290e4e4c2a58ec41cab9b6ca8c96 upstream.
The size here comes from the user via the ioctl, it is a number between
1-u32max so the addition here could overflow on 32 bit systems.
Fixes: f453ba0460 ('DRM: add mode setting support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 09bfda10e6efd7b65bcc29237bee1765ed779657 upstream.
With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.
Signed-off-by: Jeffery Miller <jmiller@neverware.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream.
Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:
- GPU has only one monitor connected. It's connected via
DisplayPort, and does not go through an adaptor of any sort.
- User unplugs DisplayPort connector from GPU.
- Change in HPD is detected by the driver, we probe every
DisplayPort for a possible connection.
- Probe the port the user originally had the monitor connected
on for it's dpcd. This fails, and we clear the first (and only
the first) byte of the dpcd to indicate we no longer have a
dpcd for this port.
- User plugs the previously disconnected monitor back into the
same DisplayPort.
- radeon_connector_hotplug() is called before everyone else,
and tries to handle the link training. Since only the first
byte of the dpcd is zeroed, the driver is able to complete
link training but does so against the wrong dpcd, causing it
to initialize the link with the wrong settings.
- Display stays blank (usually), dpcd is probed after the
initial link training, and the driver prints no obvious
messages to the log.
In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
In _kgsl_sharedmem_page_alloc():
- Make len of type size_t to be in line with size.
- Check for boundary limits of requested alloc size before honoring.
- Make sure sglen is greater than zero before marking it as end
of sg list.
Bug: 27475454
Change-Id: I5389bcef3478f2ccf2be5f719049867496235f28
Signed-off-by: Yuan Lin <yualin@google.com>
commit 0a90a0cff9f429f886f423967ae053150dce9259 upstream.
Fixes a broken hsync start value uncovered by:
abc0b1447d4974963548777a5ba4a4457c82c426
(drm: Perform basic sanity checks on probed modes)
The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91401
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream.
legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow
the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this
v2: -polish the annotation according to Daniel's comment
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Zhao Junwang <zhjwpku@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 7c0411d2fabc2e2702c9871ffb603e251158b317 upstream.
We have that bug for years and some users report side effects when fixing it on older hardware.
So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[lizf: Backported to 3.4: drop the change to clk.c]
Signed-off-by: Zefan Li <lizefan@huawei.com>
This reverts commit 961bd13539.
Both Satoshi-san and Cal reported a kernel crash due to this commit.
Reported-by: Satoshi Iwamoto <satoshi.iwamoto@nifty.ne.jp>
Reported-by: Cal Peake <cp@absolutedigital.net>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 245ec9d85696c3e539b23e210f248698b478379c upstream.
This reverts commit 0aedb1626566efd72b369c01992ee7413c82a0c5.
I messed things up while applying [1] to drm-intel-fixes. Rectify.
[1] http://mid.gmane.org/1432827156-9605-1-git-send-email-ville.syrjala@linux.intel.com
Fixes: 0aedb1626566 ("drm/i915: Don't skip request retirement if the active list is empty")
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 0aedb1626566efd72b369c01992ee7413c82a0c5 upstream.
Apparently we can have requests even if though the active list is empty,
so do the request retirement regardless of whether there's anything
on the active list.
The way it happened here is that during suspend intel_ring_idle()
notices the olr hanging around and then proceeds to get rid of it by
adding a request. However since there was nothing on the active lists
i915_gem_retire_requests() didn't clean those up, and so the idle work
never runs, and we leave the GPU "busy" during suspend resulting in a
WARN later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 607d48063512707a414e346972e2210dc71ab491 upstream.
The mapping range is inclusive between starting and ending addresses.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[lizf: Backported to 3.4:
- adjust context
- drop the change to clk.c
- drop the second change in cayman_pcie_gart_enable()]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit b421ed15d2c3039eb724680e4de1e4b2bd196a9a upstream.
The number of relocs is passed in by userspace and can be large. It has
been observed to cause kcalloc failures in the wild.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.
Use the correct flags for atom.
v2: handle DRM_MODE_FLAG_DBLCLK
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
Increase the wait timeout for context detachment to 30s instead
of 10s. Large IB's can take longer than 10s to retire and if a
hang happens then recovering from the hang and completing the
long IB's will take much longer than 10s, bump this timer to
30s which should be sufficient for the context's commands to
retire even if hang happens.
Change-Id: I610186473208c574b0bcada0b62a7407ae171d37
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
commit f2c9e560b406f2f6b14b345c7da33467dee9cdf2 upstream.
Use readb() and memcpy_fromio() accessors instead.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
