ef8255506f
Do it uncontionally, there's a separate peek function with dma_fence_is_signalled() which can be called from atomic context. v2: Consensus calls for an unconditional might_sleep (Chris, Christian) Full audit: - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps - dma-resv.c: Timeout always at least 1 - st-dma-fence.c: Save to sleep in testcases - amdgpu_cs.c: Both callers are for variants of the wait ioctl - amdgpu_device.c: Two callers in vram recover code, both right next to mutex_lock. - amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve - remaining functions in amdgpu: All for test_ib implementations for various engines, caller for that looks all safe (debugfs, driver load, reset) - etnaviv: another wait ioctl - habanalabs: another wait ioctl - nouveau_fence.c: hardcoded 15*HZ ... glorious - nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but this one does have a WARN_ON :-/ At least this one is only a fallback path for when kmalloc fails. Maybe this should be put onto some worker list instead, instead of a work per unamp ... - i915/selftests: Hardecoded HZ / 4 or HZ / 8 - i915/gt/selftests: Going up the callchain looks safe looking at nearby callers - i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock - i915/gem_i915_gem_wait.c: The i915-version which is called instead for i915 fences already has a might_sleep() annotation, so all good Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com> Cc: Oded Gabbay <oded.gabbay@gmail.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519132756.682888-1-daniel.vetter@ffwll.ch |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.