From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: "tee-dev@lists.linaro.org" <tee-dev@lists.linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] optee: remove address tag in check_mem_type()
Date: Mon, 12 Oct 2020 12:24:32 +0000 [thread overview]
Message-ID: <87wnzv639c.fsf@epam.com> (raw)
In-Reply-To: <CAHUa44EAR=5Syz9vz4pCNm8ytqd3rhj=PDE8trAvOiAdhs_T8A@mail.gmail.com>
Hello Jens,
Jens Wiklander writes:
> On Mon, Oct 12, 2020 at 11:26 AM Volodymyr Babchuk
> <Volodymyr_Babchuk@epam.com> wrote:
>>
>> Before passing 'start' to find_vma() we need to remove
>> tags from it to get sane results.
>>
>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>> ---
>> drivers/tee/optee/call.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> Would you mind giving a bit more background to this? For example in
> which contexts this function does or doesn't work as expected? Do you
> have any special use cases that don't work, etc? This is not a new
> regression, it's rather a problem we've always had, right?
Yes, sorry. I had to clarify in the commit description. Issue was found
on Android. Android uses pointer tagging [1], so MSB of user pointers
contain tags. As a result, passing raw user address to find_vma() leads
to NULL result, as it only traverses RB tree and does not alter passed
address in any way.
Code in mm/gup.c already strips tags and maybe, it is better to call
untagged_addr() inside of find_vma(). I'm not sure. Probably, we need
some help from MM maintainers.
Anyways, this patched fixed issue with register_shm failing in our use
case.
[1] https://source.android.com/devices/tech/debug/tagged-pointers
--
Volodymyr Babchuk at EPAM
prev parent reply other threads:[~2020-10-13 3:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 9:26 [PATCH] optee: remove address tag in check_mem_type() Volodymyr Babchuk
2020-10-12 11:35 ` Jens Wiklander
2020-10-12 12:24 ` Volodymyr Babchuk [this message]
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=87wnzv639c.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=jens.wiklander@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tee-dev@lists.linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.