On Sun 04-11-18 23:17:58, John Hubbard wrote:
> On 10/22/18 12:43 PM, Jason Gunthorpe wrote:
> > On Thu, Oct 11, 2018 at 06:23:24PM -0700, John Hubbard wrote:
> >> On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
> >>> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
> >>>
> > This is a rea
On 10/18/18 3:19 AM, Jan Kara wrote:
> On Thu 11-10-18 20:53:34, John Hubbard wrote:
>> On 10/11/18 6:23 PM, John Hubbard wrote:
>>> On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
[...]
> Well, put_page() cannot assert page is not dma-pinn
On 10/22/18 12:43 PM, Jason Gunthorpe wrote:
> On Thu, Oct 11, 2018 at 06:23:24PM -0700, John Hubbard wrote:
>> On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
>>> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
>>>
> This is a real worry. If someone uses a mistaken put_page() then how
>
On Thu, Oct 11, 2018 at 06:23:24PM -0700, John Hubbard wrote:
> On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
> > On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
> >
> >>> This is a real worry. If someone uses a mistaken put_page() then how
> >>> will that bug manifest at runtime? Under
On Thu 11-10-18 20:53:34, John Hubbard wrote:
> On 10/11/18 6:23 PM, John Hubbard wrote:
> > On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
> >> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
> >>
> This is a real worry. If someone uses a mistaken put_page() then how
> will that
On 10/11/18 6:23 PM, John Hubbard wrote:
> On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
>> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
>>
This is a real worry. If someone uses a mistaken put_page() then how
will that bug manifest at runtime? Under what set of circumstances
On 10/11/18 6:20 AM, Jason Gunthorpe wrote:
> On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
>
>>> This is a real worry. If someone uses a mistaken put_page() then how
>>> will that bug manifest at runtime? Under what set of circumstances
>>> will the kernel trigger the bug?
>>
>> At
On Thu, Oct 11, 2018 at 10:49:29AM +0200, Jan Kara wrote:
> > This is a real worry. If someone uses a mistaken put_page() then how
> > will that bug manifest at runtime? Under what set of circumstances
> > will the kernel trigger the bug?
>
> At runtime such bug will manifest as a page that can
On Wed 10-10-18 16:45:41, Andrew Morton wrote:
> On Tue, 9 Oct 2018 17:42:09 -0700 John Hubbard wrote:
>
> > > Also, maintainability. What happens if someone now uses put_page() by
> > > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > > this from occurring as code evol
On Wed 10-10-18 16:23:35, John Hubbard wrote:
> On 10/10/18 1:59 AM, Jan Kara wrote:
> > On Tue 09-10-18 17:42:09, John Hubbard wrote:
> >> On 10/8/18 5:14 PM, Andrew Morton wrote:
> >>> Also, maintainability. What happens if someone now uses put_page() by
> >>> mistake? Kernel fails in some myst
On Tue, 9 Oct 2018 17:42:09 -0700 John Hubbard wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at r
On Tue, 9 Oct 2018 17:32:16 -0700 John Hubbard wrote:
> > I'm not really understanding. Patch 3/3 changes just one infiniband
> > driver to use put_user_page(). But the changelogs here imply (to me)
> > that every user of get_user_pages() needs to be converted to
> > s/put_page/put_user_page/.
On 10/10/18 1:59 AM, Jan Kara wrote:
> On Tue 09-10-18 17:42:09, John Hubbard wrote:
>> On 10/8/18 5:14 PM, Andrew Morton wrote:
>>> Also, maintainability. What happens if someone now uses put_page() by
>>> mistake? Kernel fails in some mysterious fashion? How can we prevent
>>> this from occurr
On Tue 09-10-18 17:42:09, John Hubbard wrote:
> On 10/8/18 5:14 PM, Andrew Morton wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap w
On 10/8/18 5:14 PM, Andrew Morton wrote:
> On Mon, 8 Oct 2018 14:16:22 -0700 john.hubb...@gmail.com wrote:
>
>> From: John Hubbard
[...]
>> +/*
>> + * Pages that were pinned via get_user_pages*() should be released via
>> + * either put_user_page(), or one of the put_user_pages*() routines
>> +
On 10/9/18 4:20 PM, Andrew Morton wrote:
> On Tue, 9 Oct 2018 10:30:25 +0200 Jan Kara wrote:
>
>>> Also, maintainability. What happens if someone now uses put_page() by
>>> mistake? Kernel fails in some mysterious fashion? How can we prevent
>>> this from occurring as code evolves? Is there a
On Tue, 9 Oct 2018 10:30:25 +0200 Jan Kara wrote:
> > Also, maintainability. What happens if someone now uses put_page() by
> > mistake? Kernel fails in some mysterious fashion? How can we prevent
> > this from occurring as code evolves? Is there a cheap way of detecting
> > this bug at runti
On Mon 08-10-18 17:14:42, Andrew Morton wrote:
> On Mon, 8 Oct 2018 14:16:22 -0700 john.hubb...@gmail.com wrote:
> > + put_user_page(pages[index]);
> > + }
> > +}
> > +
> > +static inline void put_user_pages(struct page **pages,
> > + unsigned long npages)
>
On Mon, 8 Oct 2018 14:16:22 -0700 john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Introduces put_user_page(), which simply calls put_page().
> This provides a way to update all get_user_pages*() callers,
> so that they call put_user_page(), instead of put_page().
>
> Also introduces put
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for release_p
20 matches
Mail list logo