linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Phil Chang (張世勳)" <Phil.Chang@mediatek.com>
To: Sumit Garg <sumit.garg@linaro.org>,
	"ira.weiny@intel.com" <ira.weiny@intel.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"op-tee@lists.trustedfirmware.org"
	<op-tee@lists.trustedfirmware.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH 2/4] tee: Remove vmalloc page support
Date: Wed, 5 Oct 2022 03:28:54 +0000	[thread overview]
Message-ID: <TYZPR03MB65279558CC22F5130B710EA8FB5D9@TYZPR03MB6527.apcprd03.prod.outlook.com> (raw)
In-Reply-To: <CAFA6WYOGT1sJLA4c_B88NaXgxv4fm-idi5QMYvXdXB0acCF3sw@mail.gmail.com>

Hi Sumit

Thanks for mentioning that, in fact, our product is low memory devices, and continuous pages are extremely valuable.
Although our driver is not upstream yet but highly dependent on tee shm vmalloc support,
some scenarios are driver alloc high order pages but system memory is fragmentation so that alloc failed.
In this situation, vmalloc support is important and gives flexible usage to user.


-----Original Message-----
From: Sumit Garg <sumit.garg@linaro.org> 
Sent: Monday, October 3, 2022 2:57 PM
To: ira.weiny@intel.com
Cc: Jens Wiklander <jens.wiklander@linaro.org>; Andrew Morton <akpm@linux-foundation.org>; Al Viro <viro@zeniv.linux.org.uk>; Fabio M. De Francesco <fmdefrancesco@gmail.com>; Christoph Hellwig <hch@lst.de>; Linus Torvalds <torvalds@linux-foundation.org>; op-tee@lists.trustedfirmware.org; linux-kernel@vger.kernel.org; linux-mm@kvack.org; Phil Chang (張世勳) <Phil.Chang@mediatek.com>
Subject: Re: [PATCH 2/4] tee: Remove vmalloc page support

+ Phil

Hi Ira,

On Sun, 2 Oct 2022 at 05:53, <ira.weiny@intel.com> wrote:
>
> From: Ira Weiny <ira.weiny@intel.com>
>
> The kernel pages used by shm_get_kernel_pages() are allocated using 
> GFP_KERNEL through the following call stack:
>
> trusted_instantiate()
>         trusted_payload_alloc() -> GFP_KERNEL
>         <trusted key op>
>                 tee_shm_register_kernel_buf()
>                         register_shm_helper()
>                                 shm_get_kernel_pages()
>
> Where <trusted key op> is one of:
>
>         trusted_key_unseal()
>         trusted_key_get_random()
>         trusted_key_seal()
>
> Remove the vmalloc page support from shm_get_kernel_pages().  Replace 
> with a warn on once.
>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> ---
> Jens I went with the suggestion from Linus and Christoph and rejected 
> vmalloc addresses.  I did not hear back from you regarding Linus'
> question if the vmalloc page support was required by an up coming 
> patch set or not.  So I assumed it was something out of tree.

It looks like I wasn't CC'd to that conversation. IIRC, support for vmalloc addresses was added recently by Phil here [1]. So I would like to give him a chance if he is planning to post a corresponding kernel driver upstream.

[1] https://urldefense.com/v3/__https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmware.org/thread/M7HI3P2M66V27SK35CGQRICZ7DJZ5J2W/__;!!CTRNKA9wMg0ARbw!wGOKR9k3khZJlPt1K_xBCXX4EBM5ZCfWKuruFgSP45H8wTvJrx4_St3Fb5ZrljD5QQ$ 

-Sumit

> ---
>  drivers/tee/tee_shm.c | 36 ++++++++++++------------------------
>  1 file changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 
> 27295bda3e0b..527a6eabc03e 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -24,37 +24,25 @@ static void shm_put_kernel_pages(struct page 
> **pages, size_t page_count)  static int shm_get_kernel_pages(unsigned long start, size_t page_count,
>                                 struct page **pages)  {
> +       struct kvec *kiov;
>         size_t n;
>         int rc;
>
> -       if (is_vmalloc_addr((void *)start)) {
> -               struct page *page;
> -
> -               for (n = 0; n < page_count; n++) {
> -                       page = vmalloc_to_page((void *)(start + PAGE_SIZE * n));
> -                       if (!page)
> -                               return -ENOMEM;
> -
> -                       get_page(page);
> -                       pages[n] = page;
> -               }
> -               rc = page_count;
> -       } else {
> -               struct kvec *kiov;
> -
> -               kiov = kcalloc(page_count, sizeof(*kiov), GFP_KERNEL);
> -               if (!kiov)
> -                       return -ENOMEM;
> +       if (WARN_ON_ONCE(is_vmalloc_addr((void *)start)))
> +               return -EINVAL;
>
> -               for (n = 0; n < page_count; n++) {
> -                       kiov[n].iov_base = (void *)(start + n * PAGE_SIZE);
> -                       kiov[n].iov_len = PAGE_SIZE;
> -               }
> +       kiov = kcalloc(page_count, sizeof(*kiov), GFP_KERNEL);
> +       if (!kiov)
> +               return -ENOMEM;
>
> -               rc = get_kernel_pages(kiov, page_count, 0, pages);
> -               kfree(kiov);
> +       for (n = 0; n < page_count; n++) {
> +               kiov[n].iov_base = (void *)(start + n * PAGE_SIZE);
> +               kiov[n].iov_len = PAGE_SIZE;
>         }
>
> +       rc = get_kernel_pages(kiov, page_count, 0, pages);
> +       kfree(kiov);
> +
>         return rc;
>  }
>
> --
> 2.37.2
>

  reply	other threads:[~2022-10-05  3:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-02  0:23 [PATCH 0/4] Remove get_kernel_pages() ira.weiny
2022-10-02  0:23 ` [PATCH 1/4] highmem: Enhance is_kmap_addr() to check kmap_local_page() mappings ira.weiny
2022-10-02  0:23 ` [PATCH 2/4] tee: Remove vmalloc page support ira.weiny
2022-10-03  6:41   ` Jens Wiklander
2022-10-03  6:57   ` Sumit Garg
2022-10-05  3:28     ` Phil Chang (張世勳) [this message]
2022-10-06  6:23       ` Sumit Garg
2022-10-06 18:19         ` Ira Weiny
2022-10-06 18:20         ` Linus Torvalds
2022-10-07  8:12           ` Jens Wiklander
2022-12-16  0:41             ` Ira Weiny
2022-12-16  5:09               ` Sumit Garg
2022-12-16  8:45                 ` Sumit Garg
2022-12-16  7:06               ` Christoph Hellwig
2022-10-10  7:42           ` Christoph Hellwig
2022-10-10 17:20             ` Linus Torvalds
2022-10-10 17:57               ` Al Viro
2022-10-02  0:23 ` [PATCH 3/4] tee: Remove call to get_kernel_pages() ira.weiny
2022-10-02  0:46   ` Al Viro
2022-10-02  2:30     ` Ira Weiny
2022-10-03  7:17     ` Christoph Hellwig
2022-10-03 15:02       ` Ira Weiny
2022-10-02  0:23 ` [PATCH 4/4] mm: Remove get_kernel_pages() ira.weiny
2022-10-03 20:28   ` John Hubbard
2022-10-03  9:25 ` [PATCH 0/4] " Sumit Garg
2022-10-03 15:22   ` Ira Weiny
2022-10-04  6:32     ` Sumit Garg

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=TYZPR03MB65279558CC22F5130B710EA8FB5D9@TYZPR03MB6527.apcprd03.prod.outlook.com \
    --to=phil.chang@mediatek.com \
    --cc=akpm@linux-foundation.org \
    --cc=fmdefrancesco@gmail.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=sumit.garg@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).