similar to: [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*()

On 7/23/19 11:17 PM, Christoph Hellwig wrote: > On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard at gmail.com wrote: >> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. >> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when >> it is time to release the pages. That allows choosing between put_page() >> and

On 7/23/19 11:17 PM, Christoph Hellwig wrote: > On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard at gmail.com wrote: >> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. >> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when >> it is time to release the pages. That allows choosing between put_page() >> and

From: John Hubbard <jhubbard at nvidia.com> In commit d241a95f3514 ("block: optionally mark pages dirty in bio_release_pages"), new "bool mark_dirty" argument was added to bio_release_pages. In upcoming work, another bool argument (to indicate that the pages came from get_user_pages) is going to be added. That's one bool too many, because it's not desirable have

On 7/24/19 12:25 PM, john.hubbard at gmail.com wrote: > From: John Hubbard <jhubbard at nvidia.com> > > Hi, > > This is mostly Jerome's work, converting the block/bio and related areas > to call put_user_page*() instead of put_page(). Because I've changed > Jerome's patches, in some cases significantly, I'd like to get his > feedback before we

On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard at gmail.com wrote: > * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. > Then, use the new iov_iter_get_pages_use_gup() to retrieve it when > it is time to release the pages. That allows choosing between put_page() > and put_user_page*(). > > * Pass in one more piece of information to

On Mon, Aug 05, 2019 at 03:54:35PM -0700, John Hubbard wrote: > On 7/23/19 11:17 PM, Christoph Hellwig wrote: > > On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard at gmail.com wrote: > >> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. > >> Then, use the new iov_iter_get_pages_use_gup() to retrieve it when > >> it is

On Tue, Jul 23, 2019 at 10:30:53PM -0700, Christoph Hellwig wrote: > On Tue, Jul 23, 2019 at 09:25:09PM -0700, john.hubbard at gmail.com wrote: > > From: John Hubbard <jhubbard at nvidia.com> > > > > In commit d241a95f3514 ("block: optionally mark pages dirty in > > bio_release_pages"), new "bool mark_dirty" argument was added to > >

On Tue, Jul 23, 2019 at 10:30:53PM -0700, Christoph Hellwig wrote: > On Tue, Jul 23, 2019 at 09:25:09PM -0700, john.hubbard at gmail.com wrote: > > From: John Hubbard <jhubbard at nvidia.com> > > > > In commit d241a95f3514 ("block: optionally mark pages dirty in > > bio_release_pages"), new "bool mark_dirty" argument was added to > >

From: J?r?me Glisse <jglisse at redhat.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(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder versions"). Changes from J?r?me's original patch: * Changed a WARN_ON to a

On Tue, Jul 23, 2019 at 09:25:13PM -0700, john.hubbard at gmail.com wrote: > From: J?r?me Glisse <jglisse at redhat.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(). > > This is part a tree-wide conversion, as described in commit fc1d8e7cca2d > ("mm: introduce

On Tue, Jul 23, 2019 at 09:25:09PM -0700, john.hubbard at gmail.com wrote: > From: John Hubbard <jhubbard at nvidia.com> > > In commit d241a95f3514 ("block: optionally mark pages dirty in > bio_release_pages"), new "bool mark_dirty" argument was added to > bio_release_pages. > > In upcoming work, another bool argument (to indicate that the pages

On Mon, Jul 29, 2019 at 04:57:21PM -0400, Jerome Glisse wrote: > > All pages releases by bio_release_pages should come from > > get_get_user_pages, so I don't really see the point here. > > No they do not all comes from GUP for see various callers > of bio_check_pages_dirty() for instance iomap_dio_zero() > > I have carefully tracked down all this and i did not do

On Tue, Jul 30, 2019 at 12:25:57PM +0200, Christoph Hellwig wrote: > On Mon, Jul 29, 2019 at 04:57:21PM -0400, Jerome Glisse wrote: > > > All pages releases by bio_release_pages should come from > > > get_get_user_pages, so I don't really see the point here. > > > > No they do not all comes from GUP for see various callers > > of bio_check_pages_dirty()

Hi, We have couple of places which can result in deadlock. This patch series fixes these. We can be called with fc->bg_lock (for background requests) while submitting a request. This leads to two constraints. - We can't end requests in submitter's context and call fuse_end_request() as it tries to take fc->bg_lock as well. So queue these requests on a list and use a worker to

Hi, It recently became clear to me that there are some get_user_pages*() callers that don't fit neatly into any of the four cases that are so far listed in pin_user_pages.rst. vhost.c is one of those. Add a Case 5 to the documentation, and refer to that when converting vhost.c. Thanks to Jan Kara for helping me (again) in understanding the interaction between get_user_pages() and page

On 2020-06-22 16:38, Ralph Campbell wrote: > The patch to add zero page migration to GPU memory inadvertantly included inadvertently > part of a future change which broke normal page migration to GPU memory > by copying too much data and corrupting GPU memory. > Fix this by only copying one page instead of a byte count. > > Fixes: 9d4296a7d4b3 ("drm/nouveau/nouveau/hmm:

Hi, I tried opening a new ticket with a patch I wanted to submit. But when I tried to attach files to the ticket I keep getting a ticket not found error. I kept trying to get it to work, but I accidentally opened 4 new tickets. Sorry. Charlie -- Posted via http://www.ruby-forum.com/.

I''m trying to add a way to query across associations for a model in acts_as_ferret. Say I have a model A and it has a relationship with model B. Like say a Book has many pages. I want to search across the pages of the Book and produce a list of unique books who''s pages match the terms. So if I have a page that hits then I will add that book to my list of results. Right

I have a problem, and I think it''s because stop word analysis isn''t happenning in the queries. I think it''s the way ferret is doing things that''s causing this bug. Let''s say I''m searching across documents with a title. And I have a document with a title of "Bash Guide for Beginners". If a user types in the query: Bash Guide

Everything was working fine till last night. This morning I have many errors. I am using acts_as_ferret. Last updated around a month ago on linux. There are two different type of exceptions. I have over 12 exception emails but these are the two distince types. First exception: A EOFError occurred in home#event_info: End-of-File Error occured at <except.c>:79 in xraise Error occured in