From: Ira Weiny <ira.weiny@intel.com> To: John Hubbard <jhubbard@nvidia.com> Cc: john.hubbard@gmail.com, "Andrew Morton" <akpm@linux-foundation.org>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Björn Töpel" <bjorn.topel@intel.com>, "Boaz Harrosh" <boaz@plexistor.com>, "Christoph Hellwig" <hch@lst.de>, "Daniel Vetter" <daniel@ffwll.ch>, "Dan Williams" <dan.j.williams@intel.com>, "Dave Chinner" <david@fromorbit.com>, "David Airlie" <airlied@linux.ie>, "David S . Miller" <davem@davemloft.net>, "Ilya Dryomov" <idryomov@gmail.com>, "Jan Kara" <jack@suse.cz>, "Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>, "Jérôme Glisse" <jglisse@redhat.com>, "Johannes Thumshirn" <jthumshirn@suse.de>, "Magnus Karlsson" <magnus.karlsson@intel.com>, "Matthew Wilcox" <willy@infradead.org>, "Miklos Szeredi" <miklos@szeredi.hu>, "Ming Lei" <ming.lei@redhat.com>, "Sage Weil" <sage@redhat.com>, "Santosh Shilimkar" <santosh.shilimkar@oracle.com>, "Yan Zheng" <zyan@redhat.com>, netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 3/3] net/xdp: convert put_page() to put_user_page*() Date: Tue, 23 Jul 2019 11:06:13 -0700 [thread overview] Message-ID: <20190723180612.GB29729@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <a4e9b293-11f8-6b3c-cf4d-308e3b32df34@nvidia.com> On Mon, Jul 22, 2019 at 09:41:34PM -0700, John Hubbard wrote: > On 7/22/19 5:25 PM, Ira Weiny wrote: > > On Mon, Jul 22, 2019 at 03:34:15PM -0700, john.hubbard@gmail.com wrote: > > > From: John Hubbard <jhubbard@nvidia.com> > > > > > > For pages that were retained via get_user_pages*(), release those pages > > > via the new put_user_page*() routines, instead of via put_page() or > > > release_pages(). > > > > > > This is part a tree-wide conversion, as described in commit fc1d8e7cca2d > > > ("mm: introduce put_user_page*(), placeholder versions"). > > > > > > Cc: Björn Töpel <bjorn.topel@intel.com> > > > Cc: Magnus Karlsson <magnus.karlsson@intel.com> > > > Cc: David S. Miller <davem@davemloft.net> > > > Cc: netdev@vger.kernel.org > > > Signed-off-by: John Hubbard <jhubbard@nvidia.com> > > > --- > > > net/xdp/xdp_umem.c | 9 +-------- > > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > > > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c > > > index 83de74ca729a..0325a17915de 100644 > > > --- a/net/xdp/xdp_umem.c > > > +++ b/net/xdp/xdp_umem.c > > > @@ -166,14 +166,7 @@ void xdp_umem_clear_dev(struct xdp_umem *umem) > > > static void xdp_umem_unpin_pages(struct xdp_umem *umem) > > > { > > > - unsigned int i; > > > - > > > - for (i = 0; i < umem->npgs; i++) { > > > - struct page *page = umem->pgs[i]; > > > - > > > - set_page_dirty_lock(page); > > > - put_page(page); > > > - } > > > + put_user_pages_dirty_lock(umem->pgs, umem->npgs); > > > > What is the difference between this and > > > > __put_user_pages(umem->pgs, umem->npgs, PUP_FLAGS_DIRTY_LOCK); > > > > ? > > No difference. > > > > > I'm a bit concerned with adding another form of the same interface. We should > > either have 1 call with flags (enum in this case) or multiple calls. Given the > > previous discussion lets move in the direction of having the enum but don't > > introduce another caller of the "old" interface. > > I disagree that this is a "problem". There is no maintenance pitfall here; there > are merely two ways to call the put_user_page*() API. Both are correct, and > neither one will get you into trouble. > > Not only that, but there is ample precedent for this approach in other > kernel APIs. > > > > > So I think on this patch NAK from me. > > > > I also don't like having a __* call in the exported interface but there is a > > __get_user_pages_fast() call so I guess there is precedent. :-/ > > > > I thought about this carefully, and looked at other APIs. And I noticed that > things like __get_user_pages*() are how it's often done: > > * The leading underscores are often used for the more elaborate form of the > call (as oppposed to decorating the core function name with "_flags", for > example). > > * There are often calls in which you can either call the simpler form, or the > form with flags and additional options, and yes, you'll get the same result. > > Obviously, this stuff is all subject to a certain amount of opinion, but I > think I'm on really solid ground as far as precedent goes. So I'm pushing > back on the NAK... :) Fair enough... However, we have discussed in the past how GUP can be a confusing interface to use. So I'd like to see it be more directed. Only using the __put_user_pages() version allows us to ID callers easier through a grep of PUP_FLAGS_DIRTY_LOCK in addition to directing users to use that interface rather than having to read the GUP code to figure out that the 2 calls above are equal. It is not a huge deal but... Ira > > thanks, > -- > John Hubbard > NVIDIA >
WARNING: multiple messages have this Message-ID
From: Ira Weiny <ira.weiny@intel.com> To: John Hubbard <jhubbard@nvidia.com> Cc: john.hubbard@gmail.com, "Andrew Morton" <akpm@linux-foundation.org>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Björn Töpel" <bjorn.topel@intel.com>, "Boaz Harrosh" <boaz@plexistor.com>, "Christoph Hellwig" <hch@lst.de>, "Daniel Vetter" <daniel@ffwll.ch>, "Dan Williams" <dan.j.williams@intel.com>, "Dave Chinner" <david@fromorbit.com>, "David Airlie" <airlied@linux.ie>, "David S . Miller" <davem@davemloft.net>, "Ilya Dryomov" <idryomov@gmail.com>, "Jan Kara" <jack@suse.cz>, "Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>, "Jérôme Glisse" <jglisse@redhat.com>, "Johannes Thumshirn" <jthumshirn@suse.de>, "Magnus Karlsson" <magnus.karlsson@intel.com>, "Matthew Wilcox" <willy@infradead.org>, "Miklos Szeredi" <miklos@szeredi.hu> Subject: Re: [PATCH 3/3] net/xdp: convert put_page() to put_user_page*() Date: Tue, 23 Jul 2019 11:06:13 -0700 [thread overview] Message-ID: <20190723180612.GB29729@iweiny-DESK2.sc.intel.com> (raw) In-Reply-To: <a4e9b293-11f8-6b3c-cf4d-308e3b32df34@nvidia.com> On Mon, Jul 22, 2019 at 09:41:34PM -0700, John Hubbard wrote: > On 7/22/19 5:25 PM, Ira Weiny wrote: > > On Mon, Jul 22, 2019 at 03:34:15PM -0700, john.hubbard@gmail.com wrote: > > > From: John Hubbard <jhubbard@nvidia.com> > > > > > > For pages that were retained via get_user_pages*(), release those pages > > > via the new put_user_page*() routines, instead of via put_page() or > > > release_pages(). > > > > > > This is part a tree-wide conversion, as described in commit fc1d8e7cca2d > > > ("mm: introduce put_user_page*(), placeholder versions"). > > > > > > Cc: Björn Töpel <bjorn.topel@intel.com> > > > Cc: Magnus Karlsson <magnus.karlsson@intel.com> > > > Cc: David S. Miller <davem@davemloft.net> > > > Cc: netdev@vger.kernel.org > > > Signed-off-by: John Hubbard <jhubbard@nvidia.com> > > > --- > > > net/xdp/xdp_umem.c | 9 +-------- > > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > > > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c > > > index 83de74ca729a..0325a17915de 100644 > > > --- a/net/xdp/xdp_umem.c > > > +++ b/net/xdp/xdp_umem.c > > > @@ -166,14 +166,7 @@ void xdp_umem_clear_dev(struct xdp_umem *umem) > > > static void xdp_umem_unpin_pages(struct xdp_umem *umem) > > > { > > > - unsigned int i; > > > - > > > - for (i = 0; i < umem->npgs; i++) { > > > - struct page *page = umem->pgs[i]; > > > - > > > - set_page_dirty_lock(page); > > > - put_page(page); > > > - } > > > + put_user_pages_dirty_lock(umem->pgs, umem->npgs); > > > > What is the difference between this and > > > > __put_user_pages(umem->pgs, umem->npgs, PUP_FLAGS_DIRTY_LOCK); > > > > ? > > No difference. > > > > > I'm a bit concerned with adding another form of the same interface. We should > > either have 1 call with flags (enum in this case) or multiple calls. Given the > > previous discussion lets move in the direction of having the enum but don't > > introduce another caller of the "old" interface. > > I disagree that this is a "problem". There is no maintenance pitfall here; there > are merely two ways to call the put_user_page*() API. Both are correct, and > neither one will get you into trouble. > > Not only that, but there is ample precedent for this approach in other > kernel APIs. > > > > > So I think on this patch NAK from me. > > > > I also don't like having a __* call in the exported interface but there is a > > __get_user_pages_fast() call so I guess there is precedent. :-/ > > > > I thought about this carefully, and looked at other APIs. And I noticed that > things like __get_user_pages*() are how it's often done: > > * The leading underscores are often used for the more elaborate form of the > call (as oppposed to decorating the core function name with "_flags", for > example). > > * There are often calls in which you can either call the simpler form, or the > form with flags and additional options, and yes, you'll get the same result. > > Obviously, this stuff is all subject to a certain amount of opinion, but I > think I'm on really solid ground as far as precedent goes. So I'm pushing > back on the NAK... :) Fair enough... However, we have discussed in the past how GUP can be a confusing interface to use. So I'd like to see it be more directed. Only using the __put_user_pages() version allows us to ID callers easier through a grep of PUP_FLAGS_DIRTY_LOCK in addition to directing users to use that interface rather than having to read the GUP code to figure out that the 2 calls above are equal. It is not a huge deal but... Ira > > thanks, > -- > John Hubbard > NVIDIA >
next prev parent reply other threads:[~2019-07-23 18:06 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-22 22:34 [PATCH 0/3] introduce __put_user_pages(), convert a few call sites john.hubbard 2019-07-22 22:34 ` john.hubbard 2019-07-22 22:34 ` [PATCH 1/3] mm/gup: introduce __put_user_pages() john.hubbard 2019-07-22 22:34 ` john.hubbard 2019-07-23 5:53 ` Christoph Hellwig 2019-07-23 6:33 ` John Hubbard 2019-07-23 6:33 ` John Hubbard 2019-07-23 15:36 ` Christoph Hellwig 2019-07-23 15:36 ` Christoph Hellwig 2019-07-22 22:34 ` [PATCH 2/3] drivers/gpu/drm/via: convert put_page() to put_user_page*() john.hubbard 2019-07-22 22:34 ` john.hubbard 2019-07-22 22:34 ` [PATCH 3/3] net/xdp: " john.hubbard 2019-07-22 22:34 ` john.hubbard 2019-07-23 0:25 ` Ira Weiny 2019-07-23 0:25 ` Ira Weiny 2019-07-23 4:41 ` John Hubbard 2019-07-23 4:41 ` John Hubbard 2019-07-23 12:47 ` Jason Gunthorpe 2019-07-23 12:47 ` Jason Gunthorpe 2019-07-23 18:06 ` Ira Weiny [this message] 2019-07-23 18:06 ` Ira Weiny 2019-07-23 23:24 ` John Hubbard 2019-07-23 23:24 ` 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=20190723180612.GB29729@iweiny-DESK2.sc.intel.com \ --to=ira.weiny@intel.com \ --cc=airlied@linux.ie \ --cc=akpm@linux-foundation.org \ --cc=axboe@kernel.dk \ --cc=bjorn.topel@intel.com \ --cc=boaz@plexistor.com \ --cc=bpf@vger.kernel.org \ --cc=dan.j.williams@intel.com \ --cc=daniel@ffwll.ch \ --cc=davem@davemloft.net \ --cc=david@fromorbit.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@lst.de \ --cc=idryomov@gmail.com \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=jglisse@redhat.com \ --cc=jhubbard@nvidia.com \ --cc=john.hubbard@gmail.com \ --cc=jthumshirn@suse.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rdma@vger.kernel.org \ --cc=magnus.karlsson@intel.com \ --cc=miklos@szeredi.hu \ --cc=ming.lei@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=sage@redhat.com \ --cc=santosh.shilimkar@oracle.com \ --cc=viro@zeniv.linux.org.uk \ --cc=willy@infradead.org \ --cc=zyan@redhat.com \ --subject='Re: [PATCH 3/3] net/xdp: convert put_page() to put_user_page*()' \ /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
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.