pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

Change-Id: Iedade4714500e63ad26599fe7aaa91d886df84a9
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

netfilter: conntrack: disable generic tracking for known protocols

commit db29a9508a9246e77087c5531e45b2c88ec6988b upstream.

Given following iptables ruleset:

-P FORWARD DROP
-A FORWARD -m sctp --dport 9 -j ACCEPT
-A FORWARD -p tcp --dport 80 -j ACCEPT
-A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT

One would assume that this allows SCTP on port 9 and TCP on port 80.
Unfortunately, if the SCTP conntrack module is not loaded, this allows
*all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,
which we think is a security issue.

This is because on the first SCTP packet on port 9, we create a dummy
"generic l4" conntrack entry without any port information (since
conntrack doesn't know how to extract this information).

All subsequent packets that are unknown will then be in established
state since they will fallback to proto_generic and will match the
'generic' entry.

Our originally proposed version [1] completely disabled generic protocol
tracking, but Jozsef suggests to not track protocols for which a more
suitable helper is available, hence we now mitigate the issue for in
tree known ct protocol helpers only, so that at least NAT and direction
information will still be preserved for others.

 [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html

Joint work with Daniel Borkmann.

Fixes CVE-2014-8160.

Change-Id: I8dbb1b870c0724acba5f20d353c856f16ec00ae0
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Zhiqiang Zhang <zhangzhiqiang.zhang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

net: add validation for the socket syscall protocol argument

[ Upstream commit 79462ad02e861803b3840cc782248c7359451cd9 ]

郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

int socket_fd;
struct sockaddr_in addr;
addr.sin_port = 0;
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_family = 10;

socket_fd = socket(10,3,0x40000000);
connect(socket_fd , &addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70
kernel:  [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80
kernel:  [<ffffffff81645069>] SYSC_connect+0xd9/0x110
kernel:  [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80
kernel:  [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [<ffffffff81645e0e>] SyS_connect+0xe/0x10
kernel:  [<ffffffff81779515>] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

Change-Id: I30cd09ffb9705304bcda7247fe28ac14c8bb20a9
CVE: CVE-2015-8543
Cc: Cong Wang <cwang@twopensource.com>
Reported-by: 郭永刚 <guoyonggang@360.cn>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

KEYS: close race between key lookup and freeing

commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.

When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.

This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).

This would cause either a panic, or corrupt memory.

Fixes CVE-2014-9529.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iab7bb60ba1db5931cd8911ed04452cdb55358eda
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

KEYS: Fix race between read and revoke

commit b4a1b4f5047e4f54e194681125c74c0aa64d637d upstream.

This fixes CVE-2015-7550.

There's a race between keyctl_read() and keyctl_revoke().  If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.

This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.

Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.

I think the bug was introduced with the original keyrings code.

This was discovered by a multithreaded test program generated by syzkaller
(http://github.com/google/syzkaller).  Here's a cleaned up version:

#include <sys/types.h>
#include <keyutils.h>
#include <pthread.h>
void *thr0(void *arg)
{
key_serial_t key = (unsigned long)arg;
keyctl_revoke(key);
return 0;
}
void *thr1(void *arg)
{
key_serial_t key = (unsigned long)arg;
char buffer[16];
keyctl_read(key, buffer, 16);
return 0;
}
int main()
{
key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
pthread_t th[5];
pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
pthread_join(th[0], 0);
pthread_join(th[1], 0);
pthread_join(th[2], 0);
pthread_join(th[3], 0);
return 0;
}

Build as:

cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

Run as:

while keyctl-race; do :; done

as it may need several iterations to crash the kernel.  The crash can be
summarised as:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffff81279b08>] user_read+0x56/0xa3
...
Call Trace:
 [<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7
 [<ffffffff81277815>] SyS_keyctl+0x83/0xe0
 [<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ie59035bed50d4e1aa2248a0bd5128a0f997ab29a
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

Btrfs: make xattr replace operations atomic

commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream.

Replacing a xattr consists of doing a lookup for its existing value, delete
the current value from the respective leaf, release the search path and then
finally insert the new value. This leaves a time window where readers (getxattr,
listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
so this has security implications.

This change also fixes 2 other existing issues which were:

*) Deleting the old xattr value without verifying first if the new xattr will
   fit in the existing leaf item (in case multiple xattrs are packed in the
   same item due to name hash collision);

*) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
   exist but we have have an existing item that packs muliple xattrs with
   the same name hash as the input xattr. In this case we should return ENOSPC.

A test case for xfstests follows soon.

Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
implementation.

Change-Id: I286d47858be086bb974cb4fa8eee5d32e8bee61d
Reported-by: Alexandre Oliva <oliva@gnu.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
[shengyong: backport to 3.10
 - FIX: CVE-2014-9710
 - adjust context
 - ASSERT() was added v3.12, so we do check with if statement
 - set the first parameter of btrfs_item_nr() as NULL, because it is not
   used, and is removed in v3.13
]
Signed-off-by: Sheng Yong <shengyong1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Junghoon Kim <jhoon20.kim@samsung.com>

kmsg: allow binary characters

* do not touch unprintable characters. This is so that logs can have formatting
  such as newlines, tabulation, or colours.
* the textual part is now delimited by \0. This is because \n which used to be
  the delimiter is now available for logs.

Signed-off-by: Michal Bloch <m.bloch@samsung.com>
Change-Id: I030a4eab791f4468897d3dcdc5bb04549f30b2f7
Signed-off-by: Kichan Kwon <k_c.kwon@samsung.com>

Smack: Assign smack_known_web label for kernel thread's socket in the sk_alloc_security hook

Creating struct sock by sk_alloc function in various kernel subsystems
like bluetooth dosen't call smack_socket_post_create(). In such case,
received sock label is the floor('_') label and makes access deny.

Refers to:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7412301b76bd53ee53b860f611fc3b5b1c2245b5

Change-Id: I614c5f0e6d59be5ca6b49f0581edfef79fc334cf
Signed-off-by: jooseong lee <jooseong.lee@samsung.com>

sensors/ims1911: use deffered probe for i2c fail case from probe

This patch fixes to use deffered probe error for i2c read fail
from probe.

Change-Id: Ic4bc12fef0c9dee69d98bbdfb1ed1d5f2c2f62de
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

input: touchkey: add resume function

Now, there is only suspend function then it will cause a problem that
touchkey is not working after sleep, so add resume function.

It's enough only that resume function calls tc300k_input_open() because
suspend function calls just tc300k_input_close().

Change-Id: I2b96fe797a94fbd20cd3082c9460130dd6b848eb
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: tizen_tm1_defconfig: Enable mali400 r5p2_rel0

Enable mali400 r5p2_rel0 instead of r5p0_rel0.

Change-Id: I4f7f01788d91b6d4e9c102029cbfa5a1b5c3f300
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: replace CONFIG_PM_RUNTIME to CONFIG_PM

After commit 464ed18ebdb6 ("PM: Eliminate CONFIG_PM_RUNTIME") which
is applied kernel version 3.19, PM_RUNTIME is eliminated. So this
patch replaces CONFIG_PM_RUNTIME to CONFIG_PM for kernel version
larger than 3.19.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
[jy0922.shim: apply to mali400 r5p2_rel0 with some modification]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Change-Id: Iab2e17c07b397fe164623e1ecec58c54296c83a7

ARM: mali400: r5p2_rel0: fix build error

Include pm_runtime.h to fix below build error when CONFIG_PM_RUNTIME is
disabled.

drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c: In function ‘mali_driver_suspend_scheduler’:
drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c:595:2: error: implicit declaration of function ‘pm_runtime_active’ [-Werror=implicit-function-declaration]
  if (pm_runtime_active(dev))
  ^

Change-Id: Ic613dd9785a9d563e50361328944bd23d33fd70c
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: fix building out of tree

s/$(src)/$(srctree)\/$(src)/

$(srctree) has absolute path of kernel root directory, so with this
commit, building problem by relative path will be gone from outside of
kernel tree.

Change-Id: Ib6e4a23a5858b029c75b7e760082846a2247f21a
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: add GLES mem profiler feature

This patch adds GLES mem profiler feature.

You could use it by "cat /sys/kernel/debug/mali/gles_mem/<PID>".
Without user-DDK's MALI_IOC_MEM_PROFILE_GLES_MEM, it only show layout.

With this ioctl, you could check current GLES relevant memory status
in opened session and also check memory leakage in trash subdirectory.

The mechanism of detecting memory leakage is checking information when
the session is closed. So the user misses to free (GLES)memory during
session, it(the PID) could be found in trash.

Caution! When app is killed and the session is forcely shut down, then
it(the PID) could be found in trash but we can not guarantee there is a
real memory leakage. That is because like this case, it is impossible
to call MALI_IOC_MEM_PROFILE_GLES_MEM to remove allocated memory.

Change-Id: I78a08f7b53594dc20f8cc6f4c892250fdc9e8208
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
[jy0922.shim: applied to r5p2_rel0 from r5p0_rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: delete proprietary word in Kbuild

This is to guid for non-gpl case, not related with license,
but Tango detects it because it simply compares string.

Change-Id: Iad42e139fd5d040b3242f1e7358720ef24343570
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
[jy0922.shim: applied to r5p2_rel0 from r5p0_rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: add sc8830 platform codes

This comes from r5p0_rel0.

Change-Id: I673ca4624c96f7aaedc15a5caa3ec72aeadb6656
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: sync codes for TM1 from r5p0_rel0

Spectrum added some codes on r5p0_rel0 public, so do it on r5p2_rel0.
But except some codes related with below defines

SPRD_MEM_OPT_PAGE_TABLE_SHRINK
MALI_IOC_MEM_INIT
MALI_IOC_MEM_TERM

because we cannot add them by changed codes from r5p2_rel0.

Change-Id: I1423e7ce5181d4f1a08f3fbd01f9d426290eff29
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: fix Makefile & Kconfig

For building of r5p2_rel0.

Change-Id: I23c3144d886b9cbfe6061650ab16d180eb74e94c
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

Smack: limited capability for changing process label

This feature introduces new kernel interface:

- <smack_fs>/relabel-self - for setting transition labels list

This list is used to control smack label transition mechanism.
List is set by, and per process. Process can transit to new label only if
label is on the list. Only process with CAP_MAC_ADMIN capability can add
labels to this list. With this list, process can change it's label without
CAP_MAC_ADMIN but only once. After label changing, list is unset.

Changes in v2:
* use list_for_each_entry instead of _rcu during label write
* added missing description in security/Smack.txt

Changes in v3:
* squashed into one commit

Changes in v4:
* switch from global list to per-task list
* since the per-task list is accessed only by the task itself
  there is no need to use synchronization mechanisms on it

Changes in v5:
* change smackfs interface of relabel-self to the one used for onlycap
  multiple labels are accepted, separated by space, which
  replace the previous list upon write

Signed-off-by: Zbigniew Jasinski <z.jasinski@samsung.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
[jooseong.lee: Backported from mainline]
Signed-off-by: jooseong lee <jooseong.lee@samsung.com>
Change-Id: Id16abb77e09f89fd6c9d950e6be76eab220b801f

Smack: allow multiple labels in onlycap

Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to
processes running with the configured label. But having single privileged
label is not enough in some real use cases. On a complex system like Tizen,
there maybe few programs that need to configure Smack policy in run-time
and running them all with a single label is not always practical.
This patch extends onlycap feature for multiple labels. They are configured
in the same smackfs "onlycap" interface, separated by spaces.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
[jooseong.lee: We applied this patch before but some codes are missed]
Signed-off-by: jooseong lee <jooseong.lee@samsung.com>
Change-Id: I4a312874be5b88d43f8af146ecde9552731dc454

ARM: mali400: r5p2_rel0: add public codes from ARM

This comes from DX910-SW-99002-r5p2-00rel0.tgz of ARM web site.

Change-Id: I8d556f4abba5497679068eec6540a1d7716f6ebb
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: tizen_tm1_defconfig: enable xts blk cipher config

For luks support on cryptsetup in system, xts blk cipher is
required. So this patch enables xts blk cipher config option.

Change-Id: I2b7495a3d9cee974542f817c6821577b8b57acf9
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

drm/sprd: save pid/tgid in private file data

Let's save pid/tgid in private file data only once when gem object is
created or prime_fd is imported and use them on gem_info. This can solve
wrong pid/tgid information of gem_info node for imported gem object
found on tizen_3.0 platform.

Change-Id: Icfefe0d140ff2955144d509c862875d2d48241eb
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

[Multiple Kmsg] avoid not-allowable mutex lock condition

Change-Id: Icd2c90535687558aa3f294471edb865ef178a5b4

build: change model name as tm1

The model name, tm1 hsould be used for build and module build. So
this patch fixes to change model name.

Change-Id: I0bf1aeacc54ca1bb88d684161c2ff531d160f1e5
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

packaging: remove unnecessary dzImage-recovery

This patch removes unnecessary dzImage-recovery from the package.

Change-Id: I5be95182a69566948930d5821bc7b5ffb8319f81
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

drm/sprd: fix always gem creation of imported dma-buf

The sprd_prime_import() creates gem object always even though there is
existing gem object that refers memory of imported dma-buf. This patch
will make to reuse existing gem object on this case.

Change-Id: I4aa31bd2a41a511774b9e1aaf150ddbf45728c22
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

kmsg: set config to use multiple kmssage at TM1

Change-Id: I4eeaaf17b35ecae108d52f67e880e1e374b05955
Signed-off-by: Kichan Kwon <k_c.kwon@samsung.com>

kmsg: selftests

this patch adds selftests framework and four test scenarios for kmsg. The framework shape and code was inspired by similar selftests framework for kdbus.

Signed-off-by: Paul Osmialowski <p.osmialowsk@samsung.com>
[Fixed multithreaded test bug: buffer size > LOG_LINE_MAX]
Signed-off-by: Kazimierz Krosman <k.krosman@samsung.com>
Change-Id: Icedc0fee86c90430dcdb59d592392fbac05b42f5

kmsg: add ioctl for kmsg* devices operating on buffers

There is no possibility to clear additional kmsg buffers,
get size of them or know what size should be passed to read
file operation (too small size causes it to retrun -EINVAL).

Add following ioctls which solve those issues:
* KMSG_CMD_GET_BUF_SIZE
* KMSG_CMD_GET_READ_SIZE_MAX
* KMSG_CMD_CLEAR

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Ideade7e0b5c66bde3415f3190059742bac79333b

kmsg: add ioctl for adding and deleting kmsg* devices

There is no possibility to add/delete kmsg* buffers from userspace.

Adds following ioctl for main kmsg device adding and deleting
additional kmsg devices:
* KMSG_CMD_BUFFER_ADD
* KMSG_CMD_BUFFER_DEL

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Idead7a787892706249f50f1a19ca7a568753845a

kmsg: add predefined _PID, _TID, _COMM keywords to kmsg* log dict

kmsg* devices write operation wrote no dict along with message
Due to usage of kmsg devices in userspace dict has been added
identifying pid, tid and comm of writing process.

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Idead2fa29607785031e37542c2f48481b04f9949

kmsg: add function for adding and deleting additional buffers

Additional kmsg buffers should be created and deleted dynamically.

Adding two functions
* kmsg_sys_buffer_add() creates additional kmsg buffer returning minor
* kmsg_sys_buffer_del() deletes one based on provided minor

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Idead13dfef110bc05fee3fcf91ce7d44b6e5a46c

kmsg: add additional buffers support to memory class

Memory class does not support additional kmsg buffers.

Add additional kmsg buffers support to:
* devnode() callback of "mem" class
* file operations of major "mem" character device

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Ideadca14d2f2e8abd653ab8677e04132b7d9757e

kmsg: introduce additional kmsg devices support

kmsg device provides operations on cyclic logging buffer used mainly
by kernel but also in userspace by privileged processes.

Additional kmsg devices keep the same log format but may be added
dynamically with custom size.

Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>
Change-Id: Ideada11d07e2a9c9b8c342a1027a350c9531d6f1

printk: add one function for storing log in proper format

Preparation commit for future changes purpose.

Separate code responsible for storing log message in proper format
from operations on consoles by putting it in another function.

Change-Id: Idead21785b8e8a57cd504471d0537a399b4d9cd9
Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>

printk: move code regarding log message storing format

Preparation commit for future changes purpose.

Moves some code responsible for storing log messages in proper format.

Change-Id: Idead14e73d498e1e9ecba2da0e897a99ee15c583
Signed-off-by: Marcin Niesluchowski <m.niesluchow@samsung.com>

printk: guard the amount written per line by devkmsg_read()

This patchset updates netconsole so that it can emit messages with the
same header as used in /dev/kmsg which gives neconsole receiver full log
information which enables things like structured logging and detection
of lost messages.

This patch:

devkmsg_read() uses 8k buffer and assumes that the formatted output
message won't overrun which seems safe given LOG_LINE_MAX, the current use
of dict and the escaping method being used; however, we're planning to use
devkmsg formatting wider and accounting for the buffer size properly isn't
that complicated.

This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates devkmsg_read()
so that it limits output accordingly.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: David Miller <davem@davemloft.net>
Cc: Kay Sievers <kay@vrfy.org>
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: Idead54c1fb93161aebd0e00be0b66f96b907233b

Preparation patch for KMSG.

This is the first of a series of patches which implement KMSG, which is
a replacement for old android log devices, serving as a fast dlog backend.

The patches are not applied onto the original printk file, but to a copy.
This is to keep the codebase maintainable. Any future backports will be
able to merge conflictlessly and preprocessor macroes are prevented from
excessive piling in the original file.

This patch adds a MULTIPLE_KMSG config flag and creates the copy of the
printk file which will serve as the target of subsequent KMSG patches.

Change-Id: Idead56234820ff9d024da88310dc2e505cf051d0
Signed-off-by: Michal Bloch <m.bloch@samsung.com>

Enable the Joystick(JOYDEV)

Change-Id: Ieedec7196065b8b620b004180b30a9a4cfd4a6ab
Signed-off-by: Hyuk Lee <hyuk0512.lee@samsung.com>

video: sprdfd: disable ESD feature

The problem that the screen had been changed to block was reported at
some targets. I'm not sure but it might be related with ESD feature of
sprdfd driver, so as workaround, disable ESD feature.

And add some #ifdef to avoid below build errors.

drivers/built-in.o: In function `sprd_enable_vblank':
/home/pub/git/public/tm1_tizen_3.0/linux-3.10-sc7730/drivers/gpu/drm/sprd/sprd_drm_irq.c:265: undefined reference to `panel_esd_enable'
drivers/built-in.o: In function `sprd_disable_vblank':
/home/pub/git/public/tm1_tizen_3.0/linux-3.10-sc7730/drivers/gpu/drm/sprd/sprd_drm_irq.c:284: undefined reference to `panel_esd_enable'

Change-Id: I9228d883b0aa874e45b14b8f07cec9810634ab47
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

KEYS: Fix keyring ref leak in join_session_keyring()

This fixes CVE-2016-0728.

If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.

This can be tested with the following program:

#include <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <keyutils.h>

int main(int argc, const char *argv[])
{
int i = 0;
key_serial_t serial;

serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}

if (keyctl(KEYCTL_SETPERM, serial,
   KEY_POS_ALL | KEY_USR_ALL) < 0) {
perror("keyctl");
return -1;
}

for (i = 0; i < 100; i++) {
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}
}

return 0;
}

If, after the program has run, there something like the following line in
/proc/keys:

3f3d898f I--Q---   100 perm 3f3f0000     0     0 keyring   leaked-keyring: empty

with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning.  If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.

Change-Id: I08e8b8e929575583a94b6c84826c8f05e4dca075
Reported-by: Yevgeny Pats <yevgeny@perception-point.io>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[Backport from mainline commit 23567fd052a9abb6d67fe8e7a9ccdd9800a540f2 to resolve CVE-2016-0728]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

Tizen: drm/sprd: change pid information on gem_info.

Change-Id: If04b48e0fb9f24f0d2939d5ab7b1f6a62418e188
Signed-off-by: Jin-young Jeon <jy0.jeon@samsung.com>

gator: Merge gator version 5.23.1

Updated gator driver/daemon version from 5.20 to 5.23.1
Newer version supports ttrace annotation

Change-Id: If863ab4ccfd429cb8735635ed812823da8915f8d
Signed-off-by: Hyeongsik Min <hyeongsik.min@samsung.com>

staging/ion: fix build warnings

This fixed below warnings.

include/video/ion_sprd.h:128:7: warning: ‘struct ion_handle’ declared inside parameter list
include/video/ion_sprd.h:128:7: warning: its scope is only this definition or declaration, which is probably not what you want
include/video/ion_sprd.h:129:29: warning: ‘struct ion_handle’ declared inside parameter list

drivers/staging/android/ion/ion.h:126:13: warning: ‘struct drm_gem_object’ declared inside parameter list
drivers/staging/android/ion/ion.h:126:13: warning: its scope is only this definition or declaration, which is probably not what you want

Change-Id: If51462fad12a1f7d20777835b39b1a276149cef1
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

staging/ion: decrease gem reference count in release of dma-buf

Gem reference count is increased hen dma-buf is exported, so release
of dma-buf should decrease gem reference count.

Change-Id: Id298ea79aa14908860e5d87527813994dfdb790d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Rohit kumar <rohit.kr@samsung.com>

drm/sprd: include correct ion.h header file in sprd_drm

This patch updates sprd_drm to include staging/ion header
file instead of include/linux/ion.h as we are now using
staging ion driver.

Change-Id: I799c8553aa43278ecab85bc55d518b572b5ef9ea
Signed-off-by: Rohit kumar <rohit.kr@samsung.com>

staging/ion: sync ion.h with include/linux/ion.h

Change-Id: I7961603a6f9615cf7768841edf0168461b477007
Signed-off-by: Rohit kumar <rohit.kr@samsung.com>

Revert "TizenYoung23gdtv: drm: add ion.h."

This reverts commit 4748300326836a2f632b60f8ec8d8cf01f2b4f85.

drm/sprd: use prime dma-buf to convert fd and gem handle

The sprd drm driver used specific functions to convert fd and gem handle
but they don't support some mechanism of prime dma-buf functions like
reusing of handle exported already, so use prime dma-buf functions.

Change-Id: Ieb591944015bfab0cb15cc21d714f70bffe4b18c
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

Tizen: ion: Fix dma_buf refcount issue in get_ion_handle_from_dmabuf

Change-Id: If9eef4cc5dcdf89e89af062a56607b01e3640c25
Signed-off-by: Rohit kumar <rohit.kr@samsung.com>

staging/ion: Add support to get ion handle from dma buf

Currently we can only import dma buf fd's to get ion_handle.
Adding support to import dma buf handles to support kernel
use cases.

Change-Id: I85b6027b6b142e3f91bce51b717e408530d5523c
Signed-off-by: Rohit kumar <rohit.kr@samsung.com>

drm/sprd: fix locking usage

This fixes locking usage made by backporting patchse to solve dma-buf
issue.

Change-Id: I99c3792cecc5e9974b1fb7c321d8c963de411ea4
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

drm/sprd: fix build errors

This fixes build errors made by backporting patchse to solve dma-buf
issue.

Change-Id: I855c8a98a8b6d1ea9119a51c5249ee470052d076
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

drm/prime: Always add exported buffers to the handle cache

... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarantee that for dma-buf imports we always hand
back an existing handle if there is one.

This is exercised by igt/prime_self_import/with_one_bo_two_files

Now if we extend the locked sections just a notch more we can also
plug th racy buf/handle cache setup in handle_to_fd:

If evil userspace races a concurrent gem close against a prime export
operation we can end up tearing down the gem handle before the dma buf
handle cache is set up. When handle_to_fd gets around to adding the
handle to the cache there will be no one left to clean it up,
effectily leaking the bo (and the dma-buf, since the handle cache
holds a ref on the dma-buf):

Thread A Thread B

handle_to_fd:

lookup gem object from handle
creates new dma_buf

gem_close on the same handle
obj->dma_buf is set, but file priv buf
handle cache has no entry

obj->handle_count drops to 0

drm_prime_add_buf_handle sets up the handle cache

-> We have a dma-buf reference in the handle cache, but since the
handle_count of the gem object already dropped to 0 no on will clean
it up. When closing the drm device fd we'll hit the WARN_ON in
drm_prime_destroy_file_private.

The important change is to extend the critical section of the
filp->prime.lock to cover the gem handle lookup. This serializes with
a concurrent gem handle close.

This leak is exercised by igt/prime_self_import/export-vs-gem_close-race

Change-Id: I19ceb9107a318dc299eb103df4042684f0a4252e
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: make drm_prime_lookup_buf_handle static

... and move it to the top of the function to avoid a forward
declaration.

Change-Id: I1e8ce7ca0bd845ff10d72da56a6a992f3eca75ac
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: Simplify drm_gem_remove_prime_handles

with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.

Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.

Hence we don't need to special case the clean any more and can simply
drop the clause which only runs for foreing objects, i.e. with
obj->import_attach set.

Note that with this change (actually with the previous one to always
set up obj->dma_buf even for foreign objects) it is no longer required
to set obj->import_attach when importing a foreing object. So update
comments accordingly, too.

Change-Id: If153ff3c09c4380b86497d7cb26b5b02b40ec020
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: proper locking+refcounting for obj->dma_buf link

The export dma-buf cache is semantically similar to an flink name. So
semantically it makes sense to treat it the same and remove the name
(i.e. the dma_buf pointer) and its references when the last gem handle
disappears.

Again we need to be careful, but double so: Not just could someone
race and export with a gem close ioctl (so we need to recheck
obj->handle_count again when assigning the new name), but multiple
exports can also race against each another. This is prevented by
holding the dev->object_name_lock across the entire section which
touches obj->dma_buf.

With the new scheme we also need to reinstate the obj->dma_buf link at
import time (in case the only reference userspace has held in-between
was through the dma-buf fd and not through any native gem handle). For
simplicity we don't check whether it's a native object but
unconditionally set up that link - with the new scheme of removing the
obj->dma_buf reference when the last handle disappears we can do that.

To make it clear that this is not just for exported buffers anymore
als rename it from export_dma_buf to dma_buf.

To make sure that now one can race a fd_to_handle or handle_to_fd with
gem_close we use the same tricks as in flink of extending the
dev->object_name_locking critical section. With this change we finally
have a guaranteed 1:1 relationship (at least for native objects)
between gem objects and dma-bufs, even accounting for races (which can
happen since the dma-buf itself holds a reference while in-flight).

This prevent igt/prime_self_import/export-vs-gem_close-race from
Oopsing the kernel. There is still a leak though since the per-file
priv dma-buf/handle cache handling is racy. That will be fixed in a
later patch.

v2: Remove the bogus dma_buf_put from the export_and_register_object
failure path if we've raced with the handle count dropping to 0.

Change-Id: I89173f8802ccc12fbf48f053a7701c114e92692b
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: completely close gem_open vs. gem_close races

The gem flink name holds a reference onto the object itself, and this
self-reference would prevent an flink'ed object from every being
freed. To break that loop we remove the flink name when the last
userspace handle disappears, i.e. when obj->handle_count reaches 0.

Now in gem_open we drop the dev->object_name_lock between the flink
name lookup and actually adding the handle. This means a concurrent
gem_close of the last handle could result in the flink name getting
reaped right inbetween, i.e.

Thread 1 Thread 2
gem_open gem_close

flink -> obj lookup
handle_count drops to 0
remove flink name
create_handle
handle_count++

If someone now flinks this object again, we'll get a new flink name.

We can close this race by removing the lock dropping and making the
entire lookup+handle_create sequence atomic. Unfortunately to still be
able to share the handle_create logic this requires a
handle_create_tail function which drops the lock - we can't hold the
object_name_lock while calling into a driver's ->gem_open callback.

Note that for flink fixing this race isn't really important, since
racing gem_open against gem_close is clearly a userspace bug. And no
matter how the race ends, we won't leak any references.

But with dma-buf where the userspace dma-buf fd itself is refcounted
this is a valid sequence and hence we should fix it. Therefore this
patch here is just a warm-up exercise (and for consistency between
flink buffer sharing and dma-buf buffer sharing with self-imports).

Also note that this extension of the critical section in gem_open
protected by dev->object_name_lock only works because it's now a
mutex: A spinlock would conflict with the potential memory allocation
in idr_preload().

This is exercises by igt/gem_flink_race/flink_name.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
[jy0922.shim: fix up fuzz to apply]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Change-Id: I7fc3ffb1a77b2b5ca7e04a38c26ccd3a73b67f62

drm/gem: switch dev->object_name_lock to a mutex

I want to wrap the creation of a dma-buf from a gem object in it,
so that the obj->export_dma_buf cache can be atomically filled in.

Instead of creating a new mutex just for that variable I've figured
I can reuse the existing dev->object_name_lock, especially since
the new semantics will exactly mirror the flink obj->name already
protected by that lock.

v2: idr_preload/idr_preload_end is now an atomic section, so need to
move the mutex locking outside.

[airlied: fix up conflict with patch to make debugfs use lock]

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
[jy0922.shim: fix up fuzz to apply]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Change-Id: Iffcd6e849d13b7c79bbd6571c92bcdd4f45f3a69

drm/prime: clarify logic a bit in drm_gem_prime_fd_to_handle

if (!ret) implies that ret == 0, so no need to clear it again. And
explicitly check for ret == 0 to indicate that we're checking an errno
integer.

Change-Id: Ica8aaed3a759dd0c8f7cfa87977e7b74aaddda85
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: shrink critical section protected by prime lock

When exporting a gem object as a dma-buf the critical section for the
per-fd prime lock is just the adding (and in case of errors, removing)
of the handle to the per-fd lookup cache.

So restrict the critical section to just that part of the function.

This simplifies later reordering.

Change-Id: I6e571c0ae6d1aa5840781cc38a7637d01ed8849a
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: use proper pointer in drm_gem_prime_handle_to_fd

Part of the function uses the properly-typed dmabuf variable, the
other an untyped void *buf. Kill the later.

Change-Id: I93a9d67a8106b9fa9933c78967c445f0c1709817
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: make drm_gem_object_handle_unreference_unlocked static

No one outside of drm should use this, the official interfaces are
drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
is purely an implementation detail of gem.

Change-Id: I48c8bb42b1c5c48df39c9722fd1ce8836cf99257
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: fix error path in drm_gem_prime_fd_to_handle

handle_unreference only clears up the obj->name and the reference,
but would leave a dangling handle in the idr. The right thing
to do is to call handle_delete.

Change-Id: I69134c470800d5be810892d8bae77a5c5bac6dc9
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: fix up flink name create race

This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:

http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html

The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a zero handle
count, but an flink name (and it's corresponding reference). Which
results in a neat space leak.

In my first attempt I've solved this by rechecking the handle count.
But fundamentally the issue is that ->handle_count isn't your usual
refcount - it can be resurrected from 0 among other things.

For those special beasts atomic_t often suggest way more ordering that
it actually guarantees. To prevent being tricked by those hairy
semantics take the easy way out and simply protect the handle with the
existing dev->object_name_lock.

With that change implemented it's dead easy to fix the flink vs. gem
close reace: When we try to create the name we simply have to check
whether there's still officially a gem handle around and if not refuse
to create the flink name. Since the handle count decrement and flink
name destruction is now also protected by that lock the reace is gone
and we can't ever leak the flink reference again.

Outside of the drm core only the exynos driver looks at the handle
count, and tbh I have no idea why (it's just for debug dmesg output
luckily).

I've considered inlining the drm_gem_object_handle_free, but I plan to
add more name-like things (like the exported dma_buf) to this scheme,
so it's clearer to leave the handle freeing in its own function.

This is exercised by the new gem_flink_race i-g-t testcase, which on
my snb leaks gem objects at a rate of roughly 1k objects/s.

v2: Fix up the error path handling in handle_create and make it more
robust by simply calling object_handle_unreference.

v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
retursn 1 for 0. Oops.

v4: Squash in inlining of drm_gem_object_handle_reference as suggested
by Dave Airlie and add a note that we now have a testcase.

Change-Id: I90ff5be7d2e1d8fead0ef333932424a5b037d4af
Cc: Dave Airlie <airlied@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Remove stale prototypes

A few prototypes have been left in the headers, their function friends
long gone.

Change-Id: I3ad468d6c4152ed104f0b7173cfd2a2833e54d18
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: fix locking in gem debugfs/procfs file

The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.

Change-Id: Ib56e27c3eb86cde0211c6f6b14e9ea2c2fb698aa
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: WARN about unbalanced handle refcounts

Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.

So scream into dmesg with a big WARN in case that ever happens.

Change-Id: I42eea2ec5f5a83ed9c2bdc99ce86f258f0e3d3c8
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: remove bogus NULL check from drm_gem_object_handle_unreference_unlocked

Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.

Change-Id: I412d7ced57a75fd5281d05d584092df9bc420408
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: move drm_gem_object_handle_unreference_unlocked into drm_gem.c

We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.

Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.

Change-Id: I383dd0f8a20c28e587fda7f511bb43aabae03cd2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: add a bit of documentation about gem_obj->import_attach

Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.

Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Similarly
for drm devices which don't need a dma attachment at all (like udl).

But fixing that up is material for different patches.

Change-Id: Ibac8872b498dbe91e42707dcc0d96121b5773cfb
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: remove cargo-cult locking from map_sg helper

I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).

Only the grabbing of the underlying page array is anything we need to
be concerned about, and either those pages are pinned independently,
or we're screwed no matter what.

And indeed, nouveau/radeon pin the backing storage in their
attach/detach functions.

Since I've created this patch cma prime support for dma_buf was added.
drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
the sg table with dma_get_sgtable. It doesn't touch any gem object
state otherwise. So the cma helpers also look safe.

The only thing we might claim it does is prevent concurrent mapping of
dma_buf attachments. But a) that's not allowed and b) the current code
is racy already since it checks whether the sg mapping exists _before_
grabbing the lock.

So the dev->struct_mutex locking here does absolutely nothing useful,
but only distracts. Remove it.

This should also help Maarten's work to eventually pin the backing
storage more dynamically by preventing locking inversions around
dev->struct_mutex.

v2: Add analysis for recently added cma helper prime code.

Change-Id: Ifa09dc3603791b1a361bba18e1ea8c3a2b916d20
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: use common drm_gem_dmabuf_release in i915/exynos drivers

Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.

To use the release helper we need to export it, too.

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
[jy0922.shim: fix up confliction to apply]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Change-Id: Ie2ac40780efe29ca1ece8c3a85ac46e74f0af3d0

drm/gem: remove drm_gem_object_handle_unreference

It's unused, everyone is using the _unlocked variant only.

Change-Id: I4d1d2c19ea11023144d490be6f31804be8f8610f
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/gem: simplify object initialization

drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.

Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.

Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.

Change-Id: I8c23aa0239061192c4c8b69f76c7ec125b7a8705
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>

drm/cma: remove GEM CMA specific dma_buf functionality

We can use prime helpers instead.

Change-Id: I36b746d983c29d2b1c4af2cc2b844cab701b2ece
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/cma: add low-level hook functions to use prime helpers

Instead of using the dma_buf functionality for GEM CMA, we can use prime
helpers if we can provide low-level hook functions for GEM CMA.

Change-Id: Ia5f70596d842fb3f539c7eb9f6f7ce467943c844
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add mmap function to prime helpers

This adds to call low-level mmap() from prime helpers.

Change-Id: I964a481a729c7d9dd23a9d55e2a4ec08091ca5a5
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: fix sgt NULL checking

The drm_gem_map_detach() can be called with sgt is NULL.

Change-Id: I2a422a1bf92333e60de902ab048048f0b4c754dc
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: fix up handle_to_fd ioctl return value

In

commit da34242e5e0638312130f5bd5d2d277afbc6f806
Author: YoungJun Cho <yj44.cho@samsung.com>
Date:   Wed Jun 26 10:21:42 2013 +0900

    drm/prime: add return check for dma_buf_fd

the failure case handling was fixed up. But in the case when we
already had the buffer exported it changed the return value:
Previously we've return 0 on success, now we return the fd.

This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.

Change-Id: I8c6173851e379d5d9ad66b78260b4701665e0eda
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
Cc: YoungJun Cho <yj44.cho@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: add return check for dma_buf_fd

The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.

Change-Id: I70f2d15415ef7d02c21b83ce6fbc06958daa5e6f
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: reorder drm_prime_add_buf_handle and remove prototype

Change-Id: Ice6b0e4838b7a4adcd41d6c7fd85db1520f47466
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: fix to put an exported dma_buf for adding handle failure

When drm_prime_add_buf_handle() returns failure for an exported
dma_buf, the dma_buf was already allocated and its refcount was
increased, so it needs to be put.

Change-Id: Ib28d3feaed21dc71b7f90632e7fd3cec2a1198b8
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: support to cache mapping

The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.

Change-Id: Ia73a42efed8ff7c4df7ec7475ec71f433483e87a
[airlied: rebased on top of other prime changes]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: replace NULL with error value in drm_prime_pages_to_sg

Instead of NULL, error value is casted with ERR_PTR() for
drm_prime_pages_to_sg() and IS_ERR_OR_NULL() macro is replaced
with IS_ERR() macro for drm_gem_map_dma_buf().

Change-Id: Ibe9bd92bbf98c297fa2a7350a7295db3948e492f
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: fix to check return of dma_map_sg in prime helper

The dma_map_sg(), in map_dma_buf callback operation of prime helper,
can return 0 when it fails to map, so it needs to release related
resources.

Change-Id: Iccceea70885a38e3f6e8eb5c67a11503442c6233
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/gem: add mutex lock when using drm_gem_mmap_obj

The drm_gem_mmap_obj() has to be protected with dev->struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds assertion to check whether drm_gem_mmap_obj() is
called with mutex lock or not.

Change-Id: I14bc4ff6ca3bbb263548e1dfc791b83ddebd1f73
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/cma: Cocci spatch "ptr_ret.spatch"

Change-Id: I99278935542e7a39fbd387871f473d4050d4c9c1
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/prime: Cocci spatch "err_cast.spatch"

Change-Id: I0bef77cfc5aaf26379d8da5cf1cc77a155bebffc
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Cocci spatch "memdup.spatch"

Change-Id: Id4720067545bd7aa7cc5e1d8866edc234a4d21a6
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: move pinning/unpinning to buffer attach

This allows importing bo's to own device to work without requiring that the buffer is pinned in GART.

Change-Id: If20aa4e1a112118901baa4110ccb19d68b2a5ea5
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: add unpin function to prime helpers

Prevents buffers from being pinned forever.

Change-Id: Ifee56b3eb72bf4c5e349e0daf5ebf3156c096247
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: GEM CMA: Add DRM PRIME support

Change-Id: Ib62164dfdbafad48053ecbc0b447aa3c9dc81482
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

drm: GEM CMA: Split object mapping into GEM mapping and CMA mapping

The CMA-specific mapping code will be used to implement dma-buf mmap
support.

Change-Id: I8c60b83683b72bc9d5ba352b6c72e111bed86b83
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm: GEM CMA: Split object creation into object alloc and DMA memory alloc

This allows creating a GEM CMA object without an associated DMA memory
buffer, and will be used to implement DRM PRIME support.

Change-Id: I9e9e25f7323829939dae993bb7b343e3dfdd8014
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

drm/omap: Use drm_gem_mmap_obj() to implement dma-buf mmap

The dma-buf mmap code was copied from the GEM mmap implementation.
Replace it with the new drm_gem_mmap_obj() function.

Change-Id: I5dd5b285891debd85f458b66e0f3778d8dcec8d5
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

drm/gem: Split drm_gem_mmap() into object search and object mapping

The drm_gem_mmap() function first finds the GEM object to be mapped
based on the fake mmap offset and then maps the object. Split the object
mapping code into a standalone drm_gem_mmap_obj() function that can be
used to implement dma-buf mmap() operations.

Change-Id: I0be7c06a06dad981ea5f2e7dddbf55e47301bf31
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

Revert "gpu/drm: Allow drm_prime_add_buf_handle to use outside drm_prime.c"

This reverts commit e3bc8acb9541c75789cc486aeff1bd51124676ff.