On Wed, Sep 02, 2020 at 05:09:58PM +0200, Gerald Schaefer wrote:
> I guess we *could* assume that all the extra pXd_offset() calls and
> also the de-referencing would be optimized out by the compiler for other
> archs, but it is one example where my gut tells me that this might not
> be so trivial
On Wed, 2 Sep 2020 14:24:37 +0200
Gerald Schaefer wrote:
> On Tue, 1 Sep 2020 16:22:22 -0700
> John Hubbard wrote:
>
> > On 9/1/20 10:40 AM, Gerald Schaefer wrote:
> > > On Mon, 31 Aug 2020 12:15:53 -0700
> > > Andrew Morton wrote:
> > ...
> > > diff --git a/include/linux/pgtable.h
On Tue, 1 Sep 2020 16:22:22 -0700
John Hubbard wrote:
> On 9/1/20 10:40 AM, Gerald Schaefer wrote:
> > On Mon, 31 Aug 2020 12:15:53 -0700
> > Andrew Morton wrote:
> ...
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index e8cbc2e795d5..43dacbce823f 100644
> > ---
On 9/1/20 10:40 AM, Gerald Schaefer wrote:
On Mon, 31 Aug 2020 12:15:53 -0700
Andrew Morton wrote:
...
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index e8cbc2e795d5..43dacbce823f 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -681,6 +681,38 @@ static
On Tue, Sep 01, 2020 at 07:40:20PM +0200, Gerald Schaefer wrote:
> +/*
> + * With dynamic page table levels on s390, the static pXd_addr_end()
> functions
> + * will not return corresponding dynamic boundaries. This is no problem as
> long
> + * as only pXd pointers are passed down during page
On Mon, 31 Aug 2020 12:15:53 -0700
Andrew Morton wrote:
> On Mon, 31 Aug 2020 13:53:36 +0200 Christian Borntraeger
> wrote:
>
> >
> >
> > On 28.08.20 16:03, Gerald Schaefer wrote:
> > have some feedback soon if option 1 or option 2 would be acceptable
> > from a common code perspective.
On Mon, 31 Aug 2020 13:53:36 +0200 Christian Borntraeger
wrote:
>
>
> On 28.08.20 16:03, Gerald Schaefer wrote:
> have some feedback soon if option 1 or option 2 would be acceptable
> from a common code perspective. Andrew, who of the mm people would
> be the right one to decide?
Jason and
On 28.08.20 16:03, Gerald Schaefer wrote:
[...]
> We came up with two possible fix-ups, both will introduce some gup-specific
> helper functions, which will have no effect on other archs than s390.
>
> Patch 1 is the solution that has already been discussed in
>
On Fri, Aug 28, 2020 at 05:01:03PM +0200, Gerald Schaefer wrote:
> Just to make sure, you are referring to some future / planned
> changes to mm/pagewalk.c, and not some currently existing
> pagetable walkers already using the READ_ONCE logic w/o
> spinlocks?
Yes no current code, just something
On Fri, 28 Aug 2020 11:21:37 -0300
Jason Gunthorpe wrote:
> On Fri, Aug 28, 2020 at 04:03:12PM +0200, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic page
On Fri, Aug 28, 2020 at 04:03:12PM +0200, Gerald Schaefer wrote:
> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> code") introduced a subtle but severe bug on s390 with gup_fast, due to
> dynamic page table folding.
I think the page walk code in mm/pagewalk.c has
Hi,
Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
code") introduced a subtle but severe bug on s390 with gup_fast, due to
dynamic page table folding.
The question "What would it require for the generic code to work for s390"
has already been discussed here
12 matches
Mail list logo
