linux-stable.git/drivers/dma-buf, branch v4.13.2

dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence

2017-07-31T13:55:24+00:00

Up until recently sync_file were create to export a single dma-fence to
userspace, and so we could canabalise a bit insie dma-fence to mark
whether or not we had enable polling for the sync_file itself. However,
with the advent of syncobj, we do allow userspace to create multiple
sync_files for a single dma-fence. (Similarly, that the sw-sync
validation framework also started returning multiple sync-files wrapping
a single dma-fence for a syncpt also triggering the problem.)

This patch reverts my suggestion in commit e24165537312
("dma-buf/sync_file: only enable fence signalling on poll()") to use a
single bit in the shared dma-fence and restores the sync_file->flags for
tracking the bits individually.

Reported-by: Gustavo Padovan 
Fixes: f1e8c67123cf ("dma-buf/sw-sync: Use an rbtree to sort fences in the timeline")
Fixes: e9083420bbac ("drm: introduce sync objects (v4)")
Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Sean Paul 
Cc: Gustavo Padovan 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.13-rc1+
Signed-off-by: Gustavo Padovan 
Link: http://patchwork.freedesktop.org/patch/msgid/20170728212951.7818-1-chris@chris-wilson.co.uk
(cherry picked from commit db1fc97ca0c0d3fdeeadf314d99a26188438940a)

Merge branch 'drm-misc-next-fixes' into drm-misc-fixes

2017-07-17T15:56:07+00:00

Pick up

1ed134e6526b drm/vc4: Fix VBLANK handling in crtc->enable() path

From drm-misc-next-fixes, it was applied after the last pull request
was sent from that branch. We'll send it through drm-fixes instead.

dma-buf/fence: Avoid use of uninitialised timestamp

2017-07-14T19:09:55+00:00

[  236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8802538683d0)
[  236.828642] 420000001e7f0000000000000000000000080000000000000000000000000000
[  236.839543]  i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u
[  236.850420]                                  ^
[  236.854123] RIP: 0010:[]  [] fence_signal+0x17/0xd0
[  236.861313] RSP: 0018:ffff88024acd7ba0  EFLAGS: 00010282
[  236.865027] RAX: ffffffff812f6a90 RBX: ffff8802527ca800 RCX: ffff880252cb30e0
[  236.868801] RDX: ffff88024ac5d918 RSI: ffff880252f780e0 RDI: ffff880253868380
[  236.872579] RBP: ffff88024acd7bc0 R08: ffff88024acd7be0 R09: 0000000000000000
[  236.876407] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880253868380
[  236.880185] R13: ffff8802538684d0 R14: ffff880253868380 R15: ffff88024cd48e00
[  236.883983] FS:  00007f1646d1a740(0000) GS:ffff88025d000000(0000) knlGS:0000000000000000
[  236.890959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  236.894702] CR2: ffff880251360318 CR3: 000000024ad21000 CR4: 00000000001406f0
[  236.898481]  [] i915_gem_request_retire+0x1cd/0x230
[  236.902439]  [] i915_gem_request_alloc+0xa3/0x2f0
[  236.906435]  [] i915_gem_do_execbuffer.isra.41+0xb6d/0x18b0
[  236.910434]  [] i915_gem_execbuffer2+0x95/0x1e0
[  236.914390]  [] drm_ioctl+0x1e5/0x460
[  236.918275]  [] do_vfs_ioctl+0x8f/0x5c0
[  236.922168]  [] SyS_ioctl+0x3c/0x70
[  236.926090]  [] entry_SYSCALL_64_fastpath+0x17/0x93
[  236.930045]  [] 0xffffffffffffffff

We only set the timestamp before we mark the fence as signaled. It is
done before to avoid observers having a window in which they may see the
fence as complete but no timestamp. Having it does incur a potential for
the timestamp to be written twice, and even for it to be corrupted if
the u64 write is not atomic. Instead use a new bit to record the
presence of the timestamp, and teach the readers to wait until it is set
if the fence is complete. There still remains a race where the timestamp
for the signaled fence may be shown before the fence is reported as
signaled, but that's a pre-existing error.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Reported-by: Rafael Antognolli 
Signed-off-by: Gustavo Padovan 
Link: http://patchwork.freedesktop.org/patch/msgid/20170214124001.1930-1-chris@chris-wilson.co.uk

dma-buf/sync-file: Defer creation of sync_file->name

2017-05-24T16:08:29+00:00

Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name until it is first used.

v2: Update kerneldoc (kbuild test robot)
v3: sync_debug.c was peeking at the name
v4: Comment upon the potential race between two users of
sync_file_get_name() and claim that such a race is below the level of
notice. However, to prevent any future nuisance, use a global spinlock
to serialize the assignment of the name.
v5: Completely avoid the read/write race by only storing the name passed
in from the user inside sync_file->user_name and passing in a buffer to
dynamically construct the name otherwise.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: David Herrmann 
Reviewed-by: Daniel Vetter 
Signed-off-by: Gustavo Padovan 
Link: http://patchwork.freedesktop.org/patch/msgid/20170516111042.24719-1-chris@chris-wilson.co.uk

dma-buf: Use seq_putc() in two functions

2017-05-08T15:20:21+00:00

Three single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Sumit Semwal 
Link: http://patchwork.freedesktop.org/patch/msgid/b8a85220-039a-e4bb-c74b-d76baab234e8@users.sourceforge.net

dma-buf: Adjust a null pointer check in dma_buf_attach()

2017-05-08T15:20:21+00:00

The script "checkpatch.pl" pointed information out like the following.

Comparison to NULL could be written "!attach"

Thus adjust this expression.

Signed-off-by: Markus Elfring 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Sumit Semwal

dma-buf: Improve a size determination in dma_buf_attach()

2017-05-08T15:20:21+00:00

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Sumit Semwal

dma-buf: Combine two function calls into one in dma_buf_debug_show()

2017-05-08T15:20:21+00:00

A bit of data was put into a sequence by two separate function calls.
Print the same data by a single function call instead.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Sumit Semwal

Merge tag 'drm-for-v4.12' of git://people.freedesktop.org/~airlied/linux into drm-misc-next

2017-05-04T12:42:49+00:00

Backmerging Dave's 'drm-for-v4.12' pull request now that it's landed. There are
a bunch of non-drm changes which are just random bits we hadn't yet picked up in
misc-next.

main drm pull request for 4.12 kernel

Signed-off-by: Sean Paul 

Link: http://patchwork.freedesktop.org/patch/msgid/CAPM=9ty0jHgzG18zOr5CYODyTqZfH55kOCOFqNnXiWnTb_uNWw@mail.gmail.com

dma-buf: avoid scheduling on fence status query v2

2017-04-27T19:56:10+00:00

When a timeout of zero is specified, the caller is only interested in
the fence status.

In the current implementation, dma_fence_default_wait will always call
schedule_timeout() at least once for an unsignaled fence. This adds a
significant overhead to a fence status query.

Avoid this overhead by returning early if a zero timeout is specified.

v2: move early return after enable_signaling

Signed-off-by: Andres Rodriguez 
Reviewed-by: Christian König 
Signed-off-by: Gustavo Padovan 
Link: http://patchwork.freedesktop.org/patch/msgid/20170426144620.3560-1-andresx7@gmail.com