From: Martin Schwidefsky <schwidefsky@de.ibm.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Christoph Hellwig <hch@infradead.org>, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org, linux-s390 <linux-s390@vger.kernel.org> Subject: Re: Linux 5.1-rc5 Date: Tue, 16 Apr 2019 11:09:06 +0200 [thread overview] Message-ID: <20190416110906.6c773aff@mschwideX1> (raw) In-Reply-To: <CAHk-=wj7jgMOVFW0tiU-X+zhg6+Rn7mEBTej+f26rV3zXezOSA@mail.gmail.com> On Mon, 15 Apr 2019 09:17:10 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sun, Apr 14, 2019 at 10:19 PM Christoph Hellwig <hch@infradead.org> wrote: > > > > Can we please have the page refcount overflow fixes out on the list > > for review, even if it is after the fact? > > They were actually on a list for review long before the fact, but it > was the security mailing list. The issue actually got discussed back > in January along with early versions of the patches, but then we > dropped the ball because it just wasn't on anybody's radar and it got > resurrected late March. Willy wrote a rather bigger patch-series, and > review of that is what then resulted in those commits. So they may > look recent, but that's just because the original patches got > seriously edited down and rewritten. First time I hear about this, thanks for the heads up. > That said, powerpc and s390 should at least look at maybe adding a > check for the page ref in their gup paths too. Powerpc has the special > gup_hugepte() case, and s390 has its own version of gup entirely. I > was actually hoping the s390 guys would look at using the generic gup > code. We did look at converting the s390 gup code to CONFIG_HAVE_GENERIC_GUP, there are some details that need careful consideration. The top one is access_ok(), for s390 we always return true. The generic gup code relies on the fact that a page table walk with a specific address is doable if access_ok() returned true, the s390 specific check is slightly different: if ((end <= start) || (end > mm->context.asce_limit)) return 0; The obvious approach would be to modify access_ok() to check against the asce_limit. I will try and see if anything breaks, e.g. the automatic page table upgrade. > I ruthlessly also entirely ignored MIPS, SH and sparc, since they seem > largely irrelevant, partly since even theoretically this whole issue > needs a _lot_ of memory. > > Michael, Martin, see commit 6b3a70773630 ("Merge branch 'page-refs' > (page ref overflow)"). You may or may not really care. On s390 we can have up to 16TB of memory in a single LPAR. So yes, I do care about it. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Christoph Hellwig <hch@infradead.org>, linuxppc-dev@lists.ozlabs.org, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, linux-s390 <linux-s390@vger.kernel.org> Subject: Re: Linux 5.1-rc5 Date: Tue, 16 Apr 2019 11:09:06 +0200 [thread overview] Message-ID: <20190416110906.6c773aff@mschwideX1> (raw) In-Reply-To: <CAHk-=wj7jgMOVFW0tiU-X+zhg6+Rn7mEBTej+f26rV3zXezOSA@mail.gmail.com> On Mon, 15 Apr 2019 09:17:10 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sun, Apr 14, 2019 at 10:19 PM Christoph Hellwig <hch@infradead.org> wrote: > > > > Can we please have the page refcount overflow fixes out on the list > > for review, even if it is after the fact? > > They were actually on a list for review long before the fact, but it > was the security mailing list. The issue actually got discussed back > in January along with early versions of the patches, but then we > dropped the ball because it just wasn't on anybody's radar and it got > resurrected late March. Willy wrote a rather bigger patch-series, and > review of that is what then resulted in those commits. So they may > look recent, but that's just because the original patches got > seriously edited down and rewritten. First time I hear about this, thanks for the heads up. > That said, powerpc and s390 should at least look at maybe adding a > check for the page ref in their gup paths too. Powerpc has the special > gup_hugepte() case, and s390 has its own version of gup entirely. I > was actually hoping the s390 guys would look at using the generic gup > code. We did look at converting the s390 gup code to CONFIG_HAVE_GENERIC_GUP, there are some details that need careful consideration. The top one is access_ok(), for s390 we always return true. The generic gup code relies on the fact that a page table walk with a specific address is doable if access_ok() returned true, the s390 specific check is slightly different: if ((end <= start) || (end > mm->context.asce_limit)) return 0; The obvious approach would be to modify access_ok() to check against the asce_limit. I will try and see if anything breaks, e.g. the automatic page table upgrade. > I ruthlessly also entirely ignored MIPS, SH and sparc, since they seem > largely irrelevant, partly since even theoretically this whole issue > needs a _lot_ of memory. > > Michael, Martin, see commit 6b3a70773630 ("Merge branch 'page-refs' > (page ref overflow)"). You may or may not really care. On s390 we can have up to 16TB of memory in a single LPAR. So yes, I do care about it. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2019-04-16 9:09 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-14 22:40 Linux 5.1-rc5 Linus Torvalds 2019-04-15 5:19 ` Christoph Hellwig 2019-04-15 16:17 ` Linus Torvalds 2019-04-15 16:17 ` Linus Torvalds 2019-04-16 9:09 ` Martin Schwidefsky [this message] 2019-04-16 9:09 ` Martin Schwidefsky 2019-04-16 12:06 ` Martin Schwidefsky 2019-04-16 12:06 ` Martin Schwidefsky 2019-04-16 16:16 ` Linus Torvalds 2019-04-16 16:16 ` Linus Torvalds 2019-04-16 16:49 ` Linus Torvalds 2019-04-16 16:49 ` Linus Torvalds 2019-04-17 7:46 ` Martin Schwidefsky 2019-04-17 7:46 ` Martin Schwidefsky 2019-04-17 8:02 ` Martin Schwidefsky 2019-04-17 8:02 ` Martin Schwidefsky 2019-04-17 16:57 ` Linus Torvalds 2019-04-17 16:57 ` Linus Torvalds 2019-04-18 8:02 ` Martin Schwidefsky 2019-04-18 8:02 ` Martin Schwidefsky 2019-04-18 15:49 ` Linus Torvalds 2019-04-18 15:49 ` Linus Torvalds 2019-04-18 18:41 ` Martin Schwidefsky 2019-04-18 18:41 ` Martin Schwidefsky 2019-04-19 13:33 ` Martin Schwidefsky 2019-04-19 13:33 ` Martin Schwidefsky 2019-04-19 17:27 ` Linus Torvalds 2019-04-19 17:27 ` Linus Torvalds 2019-04-23 15:38 ` Martin Schwidefsky 2019-04-23 15:38 ` Martin Schwidefsky 2019-04-23 16:06 ` Linus Torvalds 2019-04-23 16:06 ` Linus Torvalds 2019-04-17 3:38 ` Michael Ellerman 2019-04-17 3:38 ` Michael Ellerman 2019-04-17 4:13 ` Linus Torvalds 2019-04-17 4:13 ` Linus Torvalds 2019-05-02 12:21 ` Greg KH 2019-05-02 12:21 ` Greg KH 2019-05-02 14:17 ` Martin Schwidefsky 2019-05-02 14:17 ` Martin Schwidefsky 2019-05-02 14:31 ` Greg KH 2019-05-02 14:31 ` Greg KH 2019-05-02 15:10 ` Martin Schwidefsky 2019-05-02 15:10 ` Martin Schwidefsky 2019-05-20 11:09 ` Greg KH 2019-05-20 11:09 ` Greg KH 2019-05-03 13:31 ` Michael Ellerman 2019-05-03 13:31 ` Michael Ellerman 2019-05-02 23:15 ` Christoph Hellwig 2019-05-02 23:15 ` Christoph Hellwig 2019-05-02 23:15 ` Christoph Hellwig
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=20190416110906.6c773aff@mschwideX1 \ --to=schwidefsky@de.ibm.com \ --cc=hch@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=torvalds@linux-foundation.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.