linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Martin Oliveira <martin.oliveira@eideticom.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-mm@kvack.org,
	Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>, Tejun Heo <tj@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Michael Guralnik <michaelgur@nvidia.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Valentine Sinitsyn <valesini@yandex-team.ru>,
	Lukas Wunner <lukas@wunner.de>
Subject: Re: [PATCH 1/6] kernfs: create vm_operations_struct without page_mkwrite()
Date: Thu, 6 Jun 2024 15:32:39 -0600	[thread overview]
Message-ID: <bb2e5a8d-797d-406c-acc6-60e83b302ede@deltatee.com> (raw)
In-Reply-To: <2024060658-ember-unblessed-4c74@gregkh>

Hi Greg,

On 2024-06-06 14:54, Greg Kroah-Hartman wrote:
> On Wed, Jun 05, 2024 at 01:29:29PM -0600, Martin Oliveira wrote:
>> The standard kernfs vm_ops installs a page_mkwrite() operator which
>> modifies the file update time on write.
>>
>> This not always required (or makes sense), such as in the P2PDMA, which
>> uses the sysfs file as an allocator from userspace.
> 
> That's not a good idea, please don't do that.  sysfs binary files are
> "pass through", why would you want to use this as an allocator?

The P2PDMA code already creates a binary attribute which is used to
allocate P2PDMA memory into userspace[1]. It was done this way a couple
of years ago at the suggestion of Christoph[2]. Using a sysfs attribute
made the code substantially simpler and got rid of a bunch of pseudofs
mess that was required when mmaping a char device. The attribute already
exists and is used by userspace so it's not something we can change at
this point.

The attribute has worked well for what was needed until we wanted to use
P2PDMA memory with FOLL_LONGTERM and GUP. That path specifically denies
FOLL_LONGTERM pins when the underlying VMA has a .page_mkwrite operator,
which sysfs/kernfs forces on us. P2PDMA doesn't benefit from this
operator in any way so the simplest thing is to remove it for this use case.

>> Furthermore, having the page_mkwrite() operator causes
>> writable_file_mapping_allowed() to fail due to
>> vma_needs_dirty_tracking() on the gup flow, which is a pre-requisite for
>> enabling P2PDMA over RDMA.
>>
>> Fix this by adding a new boolean on kernfs_ops to differentiate between
>> the different behaviours.
> 
> This isn't going to work well.

What about it are you worried won't work well? We're open to other
suggestions.

Thanks,

Logan

[1] https://elixir.bootlin.com/linux/latest/source/drivers/pci/p2pdma.c#L164
[2] https://lore.kernel.org/all/20220705075108.GB17451@lst.de/


  reply	other threads:[~2024-06-06 21:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05 19:29 [PATCH 0/6] Enable P2PDMA in Userspace RDMA Martin Oliveira
2024-06-05 19:29 ` [PATCH 1/6] kernfs: create vm_operations_struct without page_mkwrite() Martin Oliveira
2024-06-05 21:43   ` Bjorn Helgaas
2024-06-06 20:54   ` Greg Kroah-Hartman
2024-06-06 21:32     ` Logan Gunthorpe [this message]
2024-06-07  5:03     ` Christoph Hellwig
2024-06-07 16:16       ` Logan Gunthorpe
2024-06-07 19:18         ` Greg Kroah-Hartman
2024-06-05 19:29 ` [PATCH 2/6] sysfs: add mmap_allocates parameter to struct bin_attribute Martin Oliveira
2024-06-05 19:29 ` [PATCH 3/6] PCI/P2PDMA: create VMA without page_mkwrite() operator Martin Oliveira
2024-06-05 21:45   ` Bjorn Helgaas
2024-06-05 19:29 ` [PATCH 4/6] mm/gup: handle ZONE_DEVICE pages in folio_fast_pin_allowed() Martin Oliveira
2024-06-05 19:29 ` [PATCH 5/6] mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA Martin Oliveira
2024-06-05 19:29 ` [PATCH 6/6] RDMA/umem: add support for P2P RDMA Martin Oliveira
2024-06-10 12:11   ` Jason Gunthorpe
2024-06-06  8:53 ` [PATCH 0/6] Enable P2PDMA in Userspace RDMA Zhu Yanjun
2024-06-06 21:32   ` Martin Oliveira

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=bb2e5a8d-797d-406c-acc6-60e83b302ede@deltatee.com \
    --to=logang@deltatee.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=martin.oliveira@eideticom.com \
    --cc=michaelgur@nvidia.com \
    --cc=mike.marciniszyn@intel.com \
    --cc=rafael@kernel.org \
    --cc=tj@kernel.org \
    --cc=valesini@yandex-team.ru \
    /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