Revision 31a55cf145f2e3d74a7488e86bd0b33b64250fce authored by Dave Airlie on 19 March 2015, 04:01:42 UTC, committed by Dave Airlie on 19 March 2015, 04:01:42 UTC
Some urgent regression fixes to booting failures Exynos DRM occured.
Summary:
- Fix two urgent null pointer dereference bugs in case of enabling
or disabling IOMMU. There was two cases to these issues.
One is that plane->crtc is accessed by exynos_disable_plane()
when device tree binding is broken so device driver tries
to release, which means that the mode set operation isn't invoked yet
so plane->crtc is still NULL and exynos_disable_plane() will access
NULL pointer. This issue is fixed by checking if the plane->crtc
is NULL or not in exynos_disable_plane()
Other is that fimd_wait_for_vblank() is called to avoid from page fault
with IOMMU before the ctx object is created. At this time,
fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc
is still NULL because exynos_drm_crtc_create() isn't called yet.
This issue is fixed by creating a crtc object and setting it to
ctx->crtc prior to fimd_wait_for_vblank() call.
For more details, you can refer to below an e-mail thread,
http://www.spinics.net/lists/linux-samsung-soc/msg42436.html
- Remove unnecessary file not used and fix trivial issues.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: fix the initialization order in FIMD
drm/exynos: fix typo config name correctly.
drm/exynos: Check for NULL dereference of crtc
drm/exynos: IS_ERR() vs NULL bug
drm/exynos: remove unused files
highuid.txt
Notes on the change from 16-bit UIDs to 32-bit UIDs:
- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
when communicating between user and kernel space in an ioctl or data
structure.
- kernel code should use uid_t and gid_t in kernel-private structures and
code.
What's left to be done for 32-bit UIDs on all Linux architectures:
- Disk quotas have an interesting limitation that is not related to the
maximum UID/GID. They are limited by the maximum file size on the
underlying filesystem, because quota records are written at offsets
corresponding to the UID in question.
Further investigation is needed to see if the quota system can cope
properly with huge UIDs. If it can deal with 64-bit file offsets on all
architectures, this should not be a problem.
- Decide whether or not to keep backwards compatibility with the system
accounting file, or if we should break it as the comments suggest
(currently, the old 16-bit UID and GID are still written to disk, and
part of the former pad space is used to store separate 32-bit UID and
GID)
- Need to validate that OS emulation calls the 16-bit UID
compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
uses the 32-bit UID system calls properly otherwise.
This affects at least:
iBCS on Intel
sparc32 emulation on sparc64
(need to support whatever new 32-bit UID system calls are added to
sparc32)
- Validate that all filesystems behave properly.
At present, 32-bit UIDs _should_ work for:
ext2
ufs
isofs
nfs
coda
udf
Ioctl() fixups have been made for:
ncpfs
smbfs
Filesystems with simple fixups to prevent 16-bit UID wraparound:
minix
sysv
qnx4
Other filesystems have not been checked yet.
- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in
all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
more are needed. (as well as new user<->kernel data structures)
- The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
sh, and sparc32. Fixing this is probably not that important, but would
require adding a new ELF section.
- The ioctl()s used to control the in-kernel NFS server only support
16-bit UIDs on arm, i386, m68k, sh, and sparc32.
- make sure that the UID mapping feature of AX25 networking works properly
(it should be safe because it's always used a 32-bit integer to
communicate between user and kernel)
Chris Wing
wingc@umich.edu
last updated: January 11, 2000
Computing file changes ...
