kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Sadanand Warrier <sadanandwarrier@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Kernelnewbies@kernelnewbies.org
Subject: Re: get_user_pages and pinning
Date: Sat, 2 Jan 2021 10:11:46 -0500	[thread overview]
Message-ID: <CADJuq2z3NtGrztdvSw=C8ZLwsGVGkVG=nuFUj6K9bY-NhEqEPg@mail.gmail.com> (raw)
In-Reply-To: <X/BzCVpyiahjdFrM@kroah.com>

Thanks Greg

> You should get an error of -EFAULT when you try to do this when the
> kernel tries to access memory you don't have.
>
> But the best way to be sure is to actually try it yourself and see!
> There's nothing preventing you from doing that, right?  :)

Ah yes that is of course true.:-)  I did try it on Centos 4.18 and
sadly I do not get an -EFAULT.
Even access_ok blithely passes it off to the depths in the driver. But
I suppose unless the kernel actually tries to access the memory in the
midst of get_user_pages I would not see an error.
Since I do not see such an error I am supposing it doesn't (actually
touch the pages I mean), I haven't yet delved into the bowels of the
code yet. I thought I would ask here.
Now after get_user_pages and  after suitable calls to sg_dma_map etc
to get the bus address associated with the buffer, this area is passed
to a device.

If the buffer has been allocated and initialized in user space all is
good. This has been tried several times, by using memset, calloc,
actually initializing every element of the allocated buffer etc.

If not then I notice for various offsets in the buffer at page
boundaries the physical(bus) address points to the same page.
The device does the DMA and we end up with segmentation faults in
unrelated areas . systemd seems to be a frequent victim, I guess our
device has a bone to pick.

I know 5,0 onwards has the pin_user_pages family which may have some
solutions but for the moment I am stuck with 4.18.

Perhaps some other adventurous soul has tried this?  Again an IOMMU is
not present in bit of hardware though that may be neither here nor
there.

S

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2021-01-02 15:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-02 12:39 get_user_pages and pinning Sadanand Warrier
2021-01-02 13:08 ` Cengiz Can
2021-01-03 17:54   ` Sadanand Warrier
2021-01-03 18:26     ` Rik van Riel
2021-01-03 18:54       ` Sadanand Warrier
2021-01-02 13:20 ` Greg KH
2021-01-02 15:11   ` Sadanand Warrier [this message]
2021-01-03 17:58 Sadanand Warrier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADJuq2z3NtGrztdvSw=C8ZLwsGVGkVG=nuFUj6K9bY-NhEqEPg@mail.gmail.com' \
    --to=sadanandwarrier@gmail.com \
    --cc=Kernelnewbies@kernelnewbies.org \
    --cc=greg@kroah.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).