Re: [PATCH RFC PKS/PMEM 09/58] drivers/gpu: Utilize new kmap_thread()
On Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Patrik Jakobsson
> Signed-off-by: Ira Weiny
I'm guessing the entire pile goes in through some other tree. If so:
Acked-by: Daniel Vetter
If you want this to land through maintainer trees, then we need a
per-driver split (since aside from amdgpu and radeon they're all different
subtrees).
btw the two kmap calls in drm you highlight in the cover letter should
also be convertible to kmap_thread. We only hold vmalloc mappings for a
longer time (or it'd be quite a driver bug). So if you want maybe throw
those two as two additional patches on top, and we can do some careful
review & testing for them.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 12 ++--
> drivers/gpu/drm/gma500/gma_display.c | 4 ++--
> drivers/gpu/drm/gma500/mmu.c | 10 +-
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 4 ++--
> .../gpu/drm/i915/gem/selftests/i915_gem_context.c| 4 ++--
> drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++--
> drivers/gpu/drm/i915/gt/shmem_utils.c| 4 ++--
> drivers/gpu/drm/i915/i915_gem.c | 8
> drivers/gpu/drm/i915/i915_gpu_error.c| 4 ++--
> drivers/gpu/drm/i915/selftests/i915_perf.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
> 13 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 978bae731398..bd564bccb7a3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -2437,11 +2437,11 @@ static ssize_t amdgpu_ttm_gtt_read(struct file *f,
> char __user *buf,
>
> page = adev->gart.pages[p];
> if (page) {
> - ptr = kmap(page);
> + ptr = kmap_thread(page);
> ptr += off;
>
> r = copy_to_user(buf, ptr, cur_size);
> - kunmap(adev->gart.pages[p]);
> + kunmap_thread(adev->gart.pages[p]);
> } else
> r = clear_user(buf, cur_size);
>
> @@ -2507,9 +2507,9 @@ static ssize_t amdgpu_iomem_read(struct file *f, char
> __user *buf,
> if (p->mapping != adev->mman.bdev.dev_mapping)
> return -EPERM;
>
> - ptr = kmap(p);
> + ptr = kmap_thread(p);
> r = copy_to_user(buf, ptr + off, bytes);
> - kunmap(p);
> + kunmap_thread(p);
> if (r)
> return -EFAULT;
>
> @@ -2558,9 +2558,9 @@ static ssize_t amdgpu_iomem_write(struct file *f, const
> char __user *buf,
> if (p->mapping != adev->mman.bdev.dev_mapping)
> return -EPERM;
>
> - ptr = kmap(p);
> + ptr = kmap_thread(p);
> r = copy_from_user(ptr + off, buf, bytes);
> - kunmap(p);
> + kunmap_thread(p);
> if (r)
> return -EFAULT;
>
> diff --git a/drivers/gpu/drm/gma500/gma_display.c
> b/drivers/gpu/drm/gma500/gma_display.c
> index 3df6d6e850f5..35f4e55c941f 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -400,9 +400,9 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
> /* Copy the cursor to cursor mem */
> tmp_dst = dev_priv->vram_addr + cursor_gt->offset;
> for (i = 0; i < cursor_pages; i++) {
> - tmp_src = kmap(gt->pages[i]);
> + tmp_src = kmap_thread(gt->pages[i]);
> memcpy(tmp_dst, tmp_src, PAGE_SIZE);
> - kunmap(gt->pages[i]);
> + kunmap_thread(gt->pages[i]);
> tmp_dst += PAGE_SIZE;
> }
>
> diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
> index 505044c9a673..fba7a3a461fd 100644
> --- a/drivers/gpu/drm/gma500/mmu.c
> +++ b/drivers/gpu/drm/gma500/mmu.c
> @@ -192,20 +192,20 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct
> psb_mmu_drive
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Wed, May 22, 2019 at 02:38:48PM -0700, Brendan Higgins wrote: > +Bjorn Helgaas > > On Wed, May 15, 2019 at 12:41 AM Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote: > > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins > > > > wrote: > > > > > > > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > > > > > However, the reply is incorrect. Kselftest in-kernel tests > > > > > > > > (which > > > > > > > > is the context here) can be configured as built in instead of as > > > > > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > > > > > running the in-kernel tests before UML attempts to invoke the > > > > > > > > init process. > > > > > > > > > > > > > > Um, Citation needed? > > > > > > > > > > > > > > I don't see any evidence for this in the kselftest documentation, > > > > > > > nor > > > > > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > > > > > > > > > There exists test modules in the kernel that run before the init > > > > > > > scripts run --- but that's not strictly speaking part of > > > > > > > kselftests, > > > > > > > and do not have any kind of infrastructure. As noted, the > > > > > > > kselftests_harness header file fundamentally assumes that you are > > > > > > > running test code in userspace. > > > > > > > > > > > > Yeah I really like the "no userspace required at all" design of > > > > > > kunit, > > > > > > while still collecting results in a well-defined way (unless the > > > > > > current > > > > > > self-test that just run when you load the module, with maybe some > > > > > > kselftest ad-hoc wrapper around to collect the results). > > > > > > > > > > > > What I want to do long-term is to run these kernel unit tests as > > > > > > part of > > > > > > the build-testing, most likely in gitlab (sooner or later, for > > > > > > drm.git > > > > > > > > > > Totally! This is part of the reason I have been insisting on a minimum > > > > > of UML compatibility for all unit tests. If you can suffiently > > > > > constrain > > > > > the environment that is required for tests to run in, it makes it much > > > > > easier not only for a human to run your tests, but it also makes it a > > > > > lot easier for an automated service to be able to run your tests. > > > > > > > > > > I actually have a prototype presubmit already working on my > > > > > "stable/non-upstream" branch. You can checkout what presubmit results > > > > > look like here[1][2]. > > > > > > > > ug gerrit :-) > > > > > > Yeah, yeah, I know, but it is a lot easier for me to get a project set > > > up here using Gerrit, when we already use that for a lot of other > > > projects. > > > > > > Also, Gerrit has gotten a lot better over the last two years or so. Two > > > years ago, I wouldn't touch it with a ten foot pole. It's not so bad > > > anymore, at least if you are used to using a web UI to review code. > > > > I was somewhat joking, I'm just not used to gerrit ... And seems to indeed > > be a lot more polished than last time I looked at it seriously. > > I mean, it is still not perfect, but I think it has finally gotten to > the point where I prefer it over reviewing by email for high context > patches where you don't expect a lot of deep discussion. > > Still not great for patches where you want to have a lot of discussion. > > > > > > > only ofc). So that people get their pull requests (and patch > > > > > > series, we > > > > > > have some ideas to tie this into patchwork) automatically tested > > > > > > for this > > > > &g
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Tue, May 14, 2019 at 8:04 AM Brendan Higgins wrote: > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > However, the reply is incorrect. Kselftest in-kernel tests (which > > > > is the context here) can be configured as built in instead of as > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > running the in-kernel tests before UML attempts to invoke the > > > > init process. > > > > > > Um, Citation needed? > > > > > > I don't see any evidence for this in the kselftest documentation, nor > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > There exists test modules in the kernel that run before the init > > > scripts run --- but that's not strictly speaking part of kselftests, > > > and do not have any kind of infrastructure. As noted, the > > > kselftests_harness header file fundamentally assumes that you are > > > running test code in userspace. > > > > Yeah I really like the "no userspace required at all" design of kunit, > > while still collecting results in a well-defined way (unless the current > > self-test that just run when you load the module, with maybe some > > kselftest ad-hoc wrapper around to collect the results). > > > > What I want to do long-term is to run these kernel unit tests as part of > > the build-testing, most likely in gitlab (sooner or later, for drm.git > > Totally! This is part of the reason I have been insisting on a minimum > of UML compatibility for all unit tests. If you can suffiently constrain > the environment that is required for tests to run in, it makes it much > easier not only for a human to run your tests, but it also makes it a > lot easier for an automated service to be able to run your tests. > > I actually have a prototype presubmit already working on my > "stable/non-upstream" branch. You can checkout what presubmit results > look like here[1][2]. ug gerrit :-) > > only ofc). So that people get their pull requests (and patch series, we > > have some ideas to tie this into patchwork) automatically tested for this > > Might that be Snowpatch[3]? I talked to Russell, the creator of Snowpatch, > and he seemed pretty open to collaboration. > > Before I heard about Snowpatch, I had an intern write a translation > layer that made Prow (the presubmit service that I used in the prototype > above) work with LKML[4]. There's about 3-4 forks/clones of patchwork. snowpatch is one, we have a different one on freedesktop.org. It's a bit a mess :-/ > I am not married to either approach, but I think between the two of > them, most of the initial legwork has been done to make presubmit on > LKML a reality. We do have presubmit CI working already with our freedesktop.org patchwork. The missing glue is just tying that into gitlab CI somehow (since we want to unify build testing more and make it easier for contributors to adjust things). -Daniel > > super basic stuff. > > I am really excited to hear back on what you think! > > Cheers! > > [1] > https://kunit-review.googlesource.com/c/linux/+/1509/10#message-7bfa40efb132e15c8388755c273837559911425c > [2] > https://kunit-review.googlesource.com/c/linux/+/1509/10#message-a6784496eafff442ac98fb068bf1a0f36ee73509 > [3] https://developer.ibm.com/open/projects/snowpatch/ > [4] https://kunit.googlesource.com/prow-lkml/ > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > However, the reply is incorrect. Kselftest in-kernel tests (which > > is the context here) can be configured as built in instead of as > > a module, and built in a UML kernel. The UML kernel can boot, > > running the in-kernel tests before UML attempts to invoke the > > init process. > > Um, Citation needed? > > I don't see any evidence for this in the kselftest documentation, nor > do I see any evidence of this in the kselftest Makefiles. > > There exists test modules in the kernel that run before the init > scripts run --- but that's not strictly speaking part of kselftests, > and do not have any kind of infrastructure. As noted, the > kselftests_harness header file fundamentally assumes that you are > running test code in userspace. Yeah I really like the "no userspace required at all" design of kunit, while still collecting results in a well-defined way (unless the current self-test that just run when you load the module, with maybe some kselftest ad-hoc wrapper around to collect the results). What I want to do long-term is to run these kernel unit tests as part of the build-testing, most likely in gitlab (sooner or later, for drm.git only ofc). So that people get their pull requests (and patch series, we have some ideas to tie this into patchwork) automatically tested for this super basic stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
nit(test_uuid_init); > > lib/test_vmalloc.c:module_init(vmalloc_test_init) > > lib/test_xarray.c:module_init(xarray_checks); > > > > > > > If they do exists, it seems like it would make sense to > > > convert those to kunit and have Kunit tests run-able in a VM or > > > baremetal instance. > > > > They already run in a VM. > > > > They already run on bare metal. > > > > They already run in UML. > > > > This is not to say that KUnit does not make sense. But I'm still trying > > to get a better description of the KUnit features (and there are > > some). > > FYI, I have a master student who looks at converting some of these to KTF, > such as for > instance the XArray tests, which lended themselves quite good to a > semi-automated > conversion. > > The result is also a somewhat more compact code as well as the flexibility > provided by the Googletest executor and the KTF frameworks, such as running > selected > tests, output formatting, debugging features etc. So is KTF already in upstream? Or is the plan to unify the KTF and Kunit in-kernel test harnesses? Because there's tons of these in-kernel unit tests already, and every merge we get more (Frank's list didn't even look into drivers or anywhere else, e.g. it's missing the locking self tests I worked on in the past), and a more structured approach would really be good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
s > subject to regressions due to toolchain issues as much as from coding errors. > That's why I was initially turned off when I heard that KUnit only planned > to support UML and not cross-compilation. > > I'm not sure what the status is of UML for all the weird embedded processors > that get only cross-compiled and not natively-compiled, but there are multiple > reasons why UML is less commonly used in the embedded space. > > > Perhaps your and Frank's experience is different --- perhaps that can > > be explained by your past experience and interest in testing device > > drivers as opposed to file systems. > > > > The other thing I'd add is that at least for me, a really important > > consideration is how quickly we can run tests. I consider > > minimization of developer friction (e.g., all you need to do is > > running "make ; kvm-xfstests --smoke" to run tests), and maximizing > > developer velocity to be high priority goals. Developer velocity is > > how quickly can you run the tests; ideally, less than 5-10 seconds. > > > > And that's the other reason why I consider unit tests to be a > > complement to integration tests. "gce-xfstests --smoke" takes 10-15 > > minutes. If I can have unit tests which takes 5-15 seconds for a > > smoke test of the specific part of ext4 that I am modifying (and often > > with much better coverage than integration tests from userspace), > > that's at really big deal. I can do this for e2fsprogs; but if I have > > to launch a VM, the VM overhead pretty much eats all or most of that > > time budget right there. > > > > From looking at your documentation of KTF, you are targetting the use > > case of continuous testing. That's a different testing scenario than > > what I'm describing; with continuous testing, overhead measured in > > minutes or even tens of minutes is not a big deal. But if you are > > trying to do real-time testing as part of your development process --- > > *real* Test Driven Development, then test latency is a really big > > deal. > > > > I'll grant that for people who are working on device drivers where > > architecture dependencies are a big deal, building for an architecture > > where you can run in a virtual environment or using test hardware is > > going to be a better way to go. And Brendan has said he's willing to > > look at adapting KUnit so it can be built for use in a virtual > > environment to accomodate your requirements. > > This might solve my cross-compile needs, so that's good. > > > > > As far as I'm concerned, however, I would *not* be interested in KTF > > unless you could demonstrate to me that launching at test VM, somehow > > getting the kernel modules copied into the VM, and running the tests > > as kernel modules, has zero overhead compared to using UML. > > > > Ultimately, I'm a pragmatist. If KTF serves your needs best, good for > > you. If other approaches are better for other parts of the kernel, > > let's not try to impose a strict "There Must Be Only One" religion. > > That's already not true today, and for good reason. There are many > > different kinds of kernel code, and many different types of test > > philosophies. Trying to force all kernel testing into a single > > Procrustean Bed is simply not productive. > > Had to look up "Procrustean Bed" - great phrase. :-) > > I'm not of the opinion that there must only be one test framework > in the kernel. But we should avoid unnecessary multiplication. Every > person is going to have a different idea for where the line of necessity > is drawn. My own opinion is that what KUnit is adding is different enough > from kselftest, that it's a valuable addition. > > -- Tim > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [RFC v2 00/14] kunit: introduce KUnit, the Linux kernel unit testing framework
On Tue, Oct 23, 2018 at 04:57:36PM -0700, Brendan Higgins wrote: > This patch set proposes KUnit, a lightweight unit testing and mocking > framework for the Linux kernel. > > Unlike Autotest and kselftest, KUnit is a true unit testing framework; > it does not require installing the kernel on a test machine or in a VM > and does not require tests to be written in userspace running on a host > kernel. Additionally, KUnit is fast: From invocation to completion KUnit > can run several dozen tests in under a second. Currently, the entire > KUnit test suite for KUnit runs in under a second from the initial > invocation (build time excluded). > > KUnit is heavily inspired by JUnit, Python's unittest.mock, and > Googletest/Googlemock for C++. KUnit provides facilities for defining > unit test cases, grouping related test cases into test suites, providing > common infrastructure for running tests, mocking, spying, and much more. > > ## What's so special about unit testing? > > A unit test is supposed to test a single unit of code in isolation, > hence the name. There should be no dependencies outside the control of > the test; this means no external dependencies, which makes tests orders > of magnitudes faster. Likewise, since there are no external dependencies, > there are no hoops to jump through to run the tests. Additionally, this > makes unit tests deterministic: a failing unit test always indicates a > problem. Finally, because unit tests necessarily have finer granularity, > they are able to test all code paths easily solving the classic problem > of difficulty in exercising error handling code. > > ## Is KUnit trying to replace other testing frameworks for the kernel? > > No. Most existing tests for the Linux kernel are end-to-end tests, which > have their place. A well tested system has lots of unit tests, a > reasonable number of integration tests, and some end-to-end tests. KUnit > is just trying to address the unit test space which is currently not > being addressed. > > ## More information on KUnit > > There is a bunch of documentation near the end of this patch set that > describes how to use KUnit and best practices for writing unit tests. > For convenience I am hosting the compiled docs here: > https://google.github.io/kunit-docs/third_party/kernel/docs/ > > ## Changes Since Last Version > > - Updated patchset to apply cleanly on 4.19. > - Stripped down patchset to focus on just the core features (I dropped >mocking, spying, and the MMIO stuff for now; you can find these >patches here: https://kunit-review.googlesource.com/c/linux/+/1132), >as suggested by Rob. > - Cleaned up some of the commit messages and tweaked commit order a >bit based on suggestions. Do you have some example unit tests somewhere? The docs are all neat, but real example helps a lot with the tried art of copypasting :-) I'd like to give this a test spin with some of the unit tests we already have in drm. And especially figuring out how we could integrate this with our existing infrastructure. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 5:08 PM, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Daniel Vetter
At least for the drm and dma-buf bits.
-Daniel
> ---
> drivers/android/binder.c| 2 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +---
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
> drivers/hid/hidraw.c| 4 +---
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 ++--
> drivers/media/rc/lirc_dev.c | 4 +---
> drivers/mfd/cros_ec_dev.c | 4 +---
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/nvdimm/bus.c| 4 ++--
> drivers/nvme/host/core.c| 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 ++--
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +---
> drivers/scsi/3w-.c | 4 +---
> drivers/scsi/cxlflash/main.c| 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/pmcraid.c | 4 +---
> drivers/staging/android/ion/ion.c | 4 +---
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +---
> drivers/video/fbdev/ps3fb.c | 2 +-
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c| 2 +-
> fs/ceph/dir.c | 2 +-
> fs/ceph/file.c | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c| 2 +-
> net/rfkill/core.c | 2 +-
> 37 files changed, 40 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index d58763b6b009..d2464f5759f8 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5576,7 +5576,7 @@ static const struct file_operations binder_fops = {
> .owner = THIS_MODULE,
> .poll = binder_poll,
> .unlocked_ioctl = binder_ioctl,
> - .compat_ioctl = binder_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> .mmap = binder_mmap,
> .open = binder_open,
> .flush = binder_flush,
> diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> index abc7a7f64d64..8ff77a70addc 100644
> --- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> +++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> @@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int
> cmd, unsigned long arg);
> static const struct file_operations adf_ctl_ops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = adf_ctl_ioctl,
> - .compat_ioctl = adf_ctl_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> struct adf_ctl_drv_info {
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..a6d7dc4cf7e9 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -325,9 +325,7 @@ static const struct file_operations dma_buf_fops = {
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> .unlocked_ioctl = dma_buf_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = dma_buf_ioctl,
> -#endif
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> /*
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index 53c1d6d36a64..bc810506d48
Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function
On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote:
> This is a single straightforward conversion from kmap to sg_map.
>
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Probably makes sense to merge through some other tree, but please be aware
of the considerable churn rate in i915 (i.e. make sure your tree is in
linux-next before you send a pull request for this). Plane B would be to
get the prep patch in first and then merge the i915 conversion one kernel
release later.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 67b1fc5..1b1b91a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2188,6 +2188,15 @@ static void __i915_gem_object_reset_page_iter(struct
> drm_i915_gem_object *obj)
> radix_tree_delete(>mm.get_page.radix, iter.index);
> }
>
> +static void i915_gem_object_unmap(const struct drm_i915_gem_object *obj,
> + void *ptr)
> +{
> + if (is_vmalloc_addr(ptr))
> + vunmap(ptr);
> + else
> + sg_unmap(obj->mm.pages->sgl, ptr, SG_KMAP);
> +}
> +
> void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
>enum i915_mm_subclass subclass)
> {
> @@ -2215,10 +2224,7 @@ void __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj,
> void *ptr;
>
> ptr = ptr_mask_bits(obj->mm.mapping);
> - if (is_vmalloc_addr(ptr))
> - vunmap(ptr);
> - else
> - kunmap(kmap_to_page(ptr));
> + i915_gem_object_unmap(obj, ptr);
>
> obj->mm.mapping = NULL;
> }
> @@ -2475,8 +2481,11 @@ static void *i915_gem_object_map(const struct
> drm_i915_gem_object *obj,
> void *addr;
>
> /* A single page can always be kmapped */
> - if (n_pages == 1 && type == I915_MAP_WB)
> - return kmap(sg_page(sgt->sgl));
> + if (n_pages == 1 && type == I915_MAP_WB) {
> + addr = sg_map(sgt->sgl, SG_KMAP);
> + if (IS_ERR(addr))
> + return NULL;
> + }
>
> if (n_pages > ARRAY_SIZE(stack_pages)) {
> /* Too big for stack -- allocate temporary array instead */
> @@ -2543,11 +2552,7 @@ void *i915_gem_object_pin_map(struct
> drm_i915_gem_object *obj,
> goto err_unpin;
> }
>
> - if (is_vmalloc_addr(ptr))
> - vunmap(ptr);
> - else
> - kunmap(kmap_to_page(ptr));
> -
> + i915_gem_object_unmap(obj, ptr);
> ptr = obj->mm.mapping = NULL;
> }
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: Enabling peer to peer device transactions for PCIe devices
On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch <serguei.sagalovi...@amd.com> wrote: > > On 2016-11-22 03:10 PM, Daniel Vetter wrote: >> >> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams <dan.j.willi...@intel.com> >> wrote: >>> >>> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch >>> <serguei.sagalovi...@amd.com> wrote: >>>> >>>> I personally like "device-DAX" idea but my concerns are: >>>> >>>> - How well it will co-exists with the DRM infrastructure / >>>> implementations >>>> in part dealing with CPU pointers? >>> >>> Inside the kernel a device-DAX range is "just memory" in the sense >>> that you can perform pfn_to_page() on it and issue I/O, but the vma is >>> not migratable. To be honest I do not know how well that co-exists >>> with drm infrastructure. >>> >>>> - How well we will be able to handle case when we need to >>>> "move"/"evict" >>>> memory/data to the new location so CPU pointer should point to the >>>> new >>>> physical location/address >>>> (and may be not in PCI device memory at all)? >>> >>> So, device-DAX deliberately avoids support for in-kernel migration or >>> overcommit. Those cases are left to the core mm or drm. The device-dax >>> interface is for cases where all that is needed is a direct-mapping to >>> a statically-allocated physical-address range be it persistent memory >>> or some other special reserved memory range. >> >> For some of the fancy use-cases (e.g. to be comparable to what HMM can >> pull off) I think we want all the magic in core mm, i.e. migration and >> overcommit. At least that seems to be the very strong drive in all >> general-purpose gpu abstractions and implementations, where memory is >> allocated with malloc, and then mapped/moved into vram/gpu address >> space through some magic, > > It is possible that there is other way around: memory is requested to be > allocated and should be kept in vram for performance reason but due > to possible overcommit case we need at least temporally to "move" such > allocation to system memory. With migration I meant migrating both ways of course. And with stuff like numactl we can also influence where exactly the malloc'ed memory is allocated originally, at least if we'd expose the vram range as a very special numa node that happens to be far away and not hold any cpu cores. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
