linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Weiny, Ira" <ira.weiny@intel.com>
To: John Hubbard <jhubbard@nvidia.com>, Michal Hocko <mhocko@kernel.org>
Cc: "Jan Kara" <jack@suse.cz>, "Matthew Wilcox" <willy@infradead.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"Dave Chinner" <david@fromorbit.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	"devel@lists.orangefs.org" <devel@lists.orangefs.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-rpi-kernel@lists.infradead.org"
	<linux-rpi-kernel@lists.infradead.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"rds-devel@oss.oracle.com" <rds-devel@oss.oracle.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH 00/34] put_user_pages(): miscellaneous call sites
Date: Thu, 8 Aug 2019 16:25:04 +0000	[thread overview]
Message-ID: <2807E5FD2F6FDA4886F6618EAC48510E79E79644@CRSMSX101.amr.corp.intel.com> (raw)
In-Reply-To: <e648a7f3-6a1b-c9ea-1121-7ab69b6b173d@nvidia.com>

> 
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> >>>> On 8/2/19 7:52 AM, Jan Kara wrote:
> >>>>> On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> >>>>>> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> >>>>>>> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> >>>>>>>> On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
>   [...]
> > Before I go on, I would like to say that the "imbalance" of
> > get_user_pages() and put_page() bothers me from a purist standpoint...
> > However, since this discussion cropped up I went ahead and ported my
> > work to Linus' current master
> > (5.3-rc3+) and in doing so I only had to steal a bit of Johns code...
> > Sorry John...  :-(
> >
> > I don't have the commit messages all cleaned up and I know there may
> > be some discussion on these new interfaces but I wanted to throw this
> > series out there because I think it may be what Jan and Michal are
> > driving at (or at least in that direction.
> >
> > Right now only RDMA and DAX FS's are supported.  Other users of GUP
> > will still fail on a DAX file and regular files will still be at
> > risk.[2]
> >
> > I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
> >
> > https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
> >
> > I think the most relevant patch to this conversation is:
> >
> > https://github.com/weiny2/linux-
> kernel/commit/5d377653ba5cf11c3b716f90
> > 4b057bee6641aaf6
> >
> 
> ohhh...can you please avoid using the old __put_user_pages_dirty()
> function? 

Agreed... I did not like that.  Part of the reason I did not post this is I'm still trying to figure out what has landed and what I can and can't depend on.

For example, Christoph H. was proposing changes to some of the GUP calls which may conflict.  But I'm not sure his changes are moving forward.  So rather than waiting for the dust to settle I decided to see how hard it would be to get this rebased against mainline and working.  Turns out it was not too hard.

I think that is because, as time has moved on it seems that, for some users such as RDMA, a simple put_user_page() is not going to be sufficient.  We need something else to allow GUP to keep track of the file pins as we discussed.  So I'm starting to think some of this could go in at the same time.

> I thought I'd caught things early enough to get away with the
> rename and deletion of that. You could either:
> 
> a) open code an implementation of vaddr_put_pages_dirty_lock() that
> doesn't call any of the *put_user_pages_dirty*() variants, or
> 
> b) include my first patch ("") are part of your series, or
> 
> c) base this on Andrews's tree, which already has merged in my first patch.
> 

Yep I can do this.  I did not realize that Andrew had accepted any of this work.  I'll check out his tree.  But I don't think he is going to accept this series through his tree.  So what is the ETA on that landing in Linus' tree?

To that point I'm still not sure who would take all this as I am now touching mm, procfs, rdma, ext4, and xfs.

I just thought I would chime in with my progress because I'm to a point where things are working and so I can submit the code but I'm not sure what I can/should depend on landing...  Also, now that 0day has run overnight it has found issues with this rebase so I need to clean those up...  Perhaps I will base on Andrew's tree prior to doing that...

Thanks,
Ira

> 
> thanks,
> --
> John Hubbard
> NVIDIA


  reply	other threads:[~2019-08-08 16:25 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02  2:19 [PATCH 00/34] put_user_pages(): miscellaneous call sites john.hubbard
2019-08-02  2:19 ` [PATCH 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock() john.hubbard
2019-08-02  2:19 ` [PATCH 02/34] net/rds: convert put_page() to put_user_page*() john.hubbard
2019-08-02  2:19 ` [PATCH 03/34] net/ceph: " john.hubbard
2019-08-02 22:32   ` Jeff Layton
2019-08-02  2:19 ` [PATCH 04/34] x86/kvm: " john.hubbard
2019-08-02  2:19 ` [PATCH 05/34] drm/etnaviv: convert release_pages() to put_user_pages() john.hubbard
2019-08-02  2:19 ` [PATCH 06/34] drm/i915: convert put_page() to put_user_page*() john.hubbard
2019-08-02  9:19   ` Joonas Lahtinen
2019-08-02 18:48     ` John Hubbard
2019-08-03 20:03       ` John Hubbard
2019-08-02  2:19 ` [PATCH 07/34] drm/radeon: " john.hubbard
2019-08-02  2:19 ` [PATCH 08/34] media/ivtv: " john.hubbard
2019-08-02  2:19 ` [PATCH 09/34] media/v4l2-core/mm: " john.hubbard
2019-08-02  2:19 ` [PATCH 10/34] genwqe: " john.hubbard
2019-08-03  7:06   ` Greg Kroah-Hartman
2019-08-02  2:19 ` [PATCH 11/34] scif: " john.hubbard
2019-08-02  2:19 ` [PATCH 12/34] vmci: " john.hubbard
2019-08-02  2:19 ` [PATCH 13/34] rapidio: " john.hubbard
2019-08-02  2:19 ` [PATCH 14/34] oradax: " john.hubbard
2019-08-02  2:19 ` [PATCH 15/34] staging/vc04_services: " john.hubbard
2019-08-03  7:06   ` Greg Kroah-Hartman
2019-08-02  2:19 ` [PATCH 16/34] drivers/tee: " john.hubbard
2019-08-02  6:29   ` Jens Wiklander
2019-08-02 18:51     ` John Hubbard
2019-08-02  2:19 ` [PATCH 17/34] vfio: " john.hubbard
2019-08-02  2:19 ` [PATCH 18/34] fbdev/pvr2fb: " john.hubbard
2019-08-02  2:19 ` [PATCH 19/34] fsl_hypervisor: " john.hubbard
2019-08-02  2:19 ` [PATCH 20/34] xen: " john.hubbard
2019-08-02  4:36   ` Juergen Gross
2019-08-02  5:48     ` John Hubbard
2019-08-02  6:10       ` Juergen Gross
2019-08-02 16:09         ` Weiny, Ira
2019-08-02 19:25           ` John Hubbard
2019-08-02  2:19 ` [PATCH 21/34] fs/exec.c: " john.hubbard
2019-08-02  2:19 ` [PATCH 22/34] orangefs: " john.hubbard
2019-08-02  2:19 ` [PATCH 23/34] uprobes: " john.hubbard
2019-08-02  2:19 ` [PATCH 24/34] futex: " john.hubbard
2019-08-02  2:19 ` [PATCH 25/34] mm/frame_vector.c: " john.hubbard
2019-08-02  2:19 ` [PATCH 26/34] mm/gup_benchmark.c: " john.hubbard
2019-08-02 14:19   ` Keith Busch
2019-08-02  2:19 ` [PATCH 27/34] mm/memory.c: " john.hubbard
2019-08-02  2:19 ` [PATCH 28/34] mm/madvise.c: " john.hubbard
2019-08-02  2:20 ` [PATCH 29/34] mm/process_vm_access.c: " john.hubbard
2019-08-02  2:20 ` [PATCH 30/34] crypt: " john.hubbard
2019-08-02  2:20 ` [PATCH 31/34] nfs: " john.hubbard
2019-08-03  1:27   ` Calum Mackay
2019-08-03  1:41     ` John Hubbard
2019-08-04 23:28       ` Calum Mackay
2019-08-02  2:20 ` [PATCH 32/34] goldfish_pipe: " john.hubbard
2019-08-02  2:20 ` [PATCH 33/34] kernel/events/core.c: " john.hubbard
2019-08-02  2:20 ` [PATCH 34/34] fs/binfmt_elf: " john.hubbard
2019-08-02  9:12 ` [PATCH 00/34] put_user_pages(): miscellaneous call sites Michal Hocko
2019-08-02 12:41   ` Jan Kara
2019-08-02 14:24     ` Matthew Wilcox
2019-08-02 14:52       ` Jan Kara
2019-08-02 19:14         ` John Hubbard
2019-08-07  8:37           ` Jan Kara
2019-08-07  8:46             ` Michal Hocko
2019-08-08  2:36               ` Ira Weiny
2019-08-08  3:46                 ` John Hubbard
2019-08-08 16:25                   ` Weiny, Ira [this message]
2019-08-08 18:18                     ` John Hubbard
2019-08-09  8:34                 ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2019-08-02  2:16 john.hubbard
2019-08-02  2:39 ` John Hubbard
2019-08-02  8:05 ` Peter Zijlstra
2019-08-02 19:33   ` John Hubbard

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=2807E5FD2F6FDA4886F6618EAC48510E79E79644@CRSMSX101.amr.corp.intel.com \
    --to=ira.weiny@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@fromorbit.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=devel@lists.orangefs.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rds-devel@oss.oracle.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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 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).