All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Omer Shpigelman <oshpigelman@habana.ai>
Cc: Christoph Hellwig <hch@infradead.org>,
	"oded.gabbay@gmail.com" <oded.gabbay@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] habanalabs: support vmalloc memory mapping
Date: Fri, 11 Oct 2019 01:10:55 -0700	[thread overview]
Message-ID: <20191011081055.GA9052@infradead.org> (raw)
In-Reply-To: <AM6PR0202MB338206146804E2E2BC18C67FB8940@AM6PR0202MB3382.eurprd02.prod.outlook.com>

On Thu, Oct 10, 2019 at 07:54:07PM +0000, Omer Shpigelman wrote:
> The is_vmalloc_addr checks are for user pointers and for memory which was allocated by the driver with vmalloc_user.

This does not make any sense whatsoever.  vmalloc_user returns a kernel
address, it just does a GFP_USER instead of GFP_KERNEL allocation, which
is just accounting differences.

> > > Mapping vmalloc memory is needed for Gaudi ASIC.
> > 
> > How does that ASIC pass in the vmalloc memory?  I don't fully understand
> > the code, but it seems like the addresses are fed from ioctl, which means
> > they only come from userspace.
> 
> The user pointers are indeed fed from ioctl for DMA purpose, but as I wrote above the vmalloc memory is allocated by the driver with vmalloc_user which will be mmapped later on in order to create a shared buffer between the driver and the userspace process.

Again, you can't pass pointers obtained from vmalloc* to userspace.  You
can map the underlying pages into user pagetables, but is_vmalloc_addr
won't know that.  I think you guys need to read up on virtual memory 101
first and then come back and actually explain what you are trying to do.

  reply	other threads:[~2019-10-11  8:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 14:06 [PATCH 1/2] habanalabs: support vmalloc memory mapping Omer Shpigelman
2019-10-10 14:06 ` [PATCH 2/2] habanalabs: handle large memory on MMU Omer Shpigelman
2019-10-10 14:09 ` [PATCH 1/2] habanalabs: support vmalloc memory mapping Christoph Hellwig
2019-10-10 19:54   ` Omer Shpigelman
2019-10-11  8:10     ` Christoph Hellwig [this message]
2019-10-11  9:19       ` Oded Gabbay
2019-10-11  9:26         ` Christoph Hellwig
2019-10-11  9:27           ` Oded Gabbay

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=20191011081055.GA9052@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oded.gabbay@gmail.com \
    --cc=oshpigelman@habana.ai \
    /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.