* Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Joakim Tjernlund @ 2021-11-02 21:15 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, Eugene_Bordenkircher@selinc.com,
linux-usb@vger.kernel.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org, leoyang.li@nxp.com
In-Reply-To: <2c275adc278477e1e512ea6ecc0c1f4dcc46969d.camel@infinera.com>
On Sat, 2021-10-30 at 14:20 +0000, Joakim Tjernlund wrote:
> On Fri, 2021-10-29 at 17:14 +0000, Eugene Bordenkircher wrote:
> > Hello all,
> >
> > We've discovered a situation where the FSL udc driver (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the request queue, but the queue has been corrupted at some point so it loops infinitely. I believe we have narrowed into the offending code, but we are in need of assistance trying to find an appropriate fix for the problem. The identified code appears to be in all versions of the Linux kernel the driver exists in.
> >
> > The problem appears to be when handling a USB_REQ_GET_STATUS request. The driver gets this request and then calls the ch9getstatus() function. In this function, it starts a request by "borrowing" the per device status_req, filling it in, and then queuing it with a call to list_add_tail() to add the request to the endpoint queue. Right before it exits the function however, it's calling ep0_prime_status(), which is filling out that same status_req structure and then queuing it with another call to list_add_tail() to add the request to the endpoint queue. This adds two instances of the exact same LIST_HEAD to the endpoint queue, which breaks the list since the prev and next pointers end up pointing to the wrong things. This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ.
> >
> > I'm not sure what the appropriate fix to this problem is, mostly due to my lack of expertise in USB and this driver stack. The code has been this way in the kernel for a very long time, which suggests that it has been working, unless USB_REQ_GET_STATUS requests are never made. This further suggests that there is something else going on that I don't understand. Deleting the call to ep0_prime_status() and the following ep0stall() call appears, on the surface, to get the device working again, but may have side effects that I'm not seeing.
> >
> > I'm hopeful someone in the community can help provide some information on what I may be missing or help come up with a solution to the problem. A big thank you to anyone who would like to help out.
> >
> > Eugene
>
> Run into this to a while ago. Found the bug and a few more fixes.
> This is against 4.19 so you may have to tweak them a bit.
> Feel free to upstream them.
>
> Jocke
Curious, did my patches help? Good to known once we upgrade as well.
Jocke
^ permalink raw reply
* Re: Fwd: Fwd: X stopped working with 5.14 on iBook
From: Christopher M. Riedl @ 2021-11-02 22:27 UTC (permalink / raw)
To: Finn Thain, Christopher M. Riedl
Cc: Stan Johnson, linuxppc-dev, Riccardo Mottola
In-Reply-To: <48c3ed15-2ecf-cc12-c287-2b61457f5fb@nippy.intranet>
On Mon Nov 1, 2021 at 9:20 PM CDT, Finn Thain wrote:
> Hi Christopher,
>
> After many builds and tests, Stan and I were able to determine that this
> regression only affects builds with CONFIG_USER_NS=y. That is,
>
> d3ccc9781560 + CONFIG_USER_NS=y --> fail
> d3ccc9781560 + CONFIG_USER_NS=n --> okay
> d3ccc9781560~ + CONFIG_USER_NS=y --> okay
> d3ccc9781560~ + CONFIG_USER_NS=n --> okay
>
> Stan also tested a PowerMac G3 system and found that the regression is
> not
> present there. Thus far, only PowerMac G4 systems are known to be
> affected
> (Stan's Cube and Riccardo's PowerBook).
>
> I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
> Unexpectedly, this build had the same issue. So, it appears there are
> multiple bad commits that produce this Xorg failure, of which
> d3ccc9781560
> is just the first.
>
> But there's no easy way to identify the other bad commits using
> bisection.
> So I've addressed this message to you. Can you help fix this regression?
Hi,
I switched email addresses a few times since that patch - also I am not
employed at IBM any longer so that @linux.ibm.com email doesn't work
either. In any case, I'll take a look and see if I can figure out what's
going on. I do actually have a PowerBook G4 here (if it can be coaxed to
boot) that could help me root cause this.
Thanks!
Chris R.
>
> Regards,
> Finn
>
> On Fri, 22 Oct 2021, Christophe Leroy wrote:
>
> > ...
> > >
> > > -------- Forwarded Message --------
> > > Subject: Fwd: X stopped working with 5.14 on iBook
> > > Date: Fri, 22 Oct 2021 11:35:21 -0600
> > > From: Stan Johnson
> > > To: Christopher M. Riedl <cmr@codefail.de>
> > > CC: Finn Thain <fthain@fastmail.com.au>
> > >
> > > Hello Christopher Riedl,
> > >
> > > Please see the message below, in which a git bisect identifies a commit
> > > which may have stopped X from working on some PowerPC G4 systems
> > > (specifically the G4 PowerBook and Cube, possibly others).
> > >
> > > I'm not sure how to proceed with further tests. If the identified commit
> > > could not have caused the problem, then further testing may be needed.
> > > Please let me know if you need any additional information.
> > >
> > > Hopefully your e-mail filter will allow messages from yahoo.com addresses.
> > >
> > > thanks for your help
> > >
> > > -Stan Johnson
> > >
> > > -------- Forwarded Message --------
> > > Subject: Re: X stopped working with 5.14 on iBook
> > > Date: Fri, 22 Oct 2021 11:25:14 -0600
> > > From: Stan Johnson
> > > To: debian-powerpc@lists.debian.org
> > > CC: Riccardo Mottola <riccardo.mottola@libero.it>
> > >
> > > On 10/14/21 9:21 PM, Stan Johnson wrote:
> > > > ...
> > > > Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
> > > > kernel source.
> > > > ...
> > > > X works with 5.14 using a tuned config file derived from 5.13 testing.
> > > > ...
> > >
> > > Update:
> > >
> > > The issue originally reported by Riccardo Mottola was that X wasn't
> > > working on a PowerBook G4 using Debian's default
> > > vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
> > > failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
> > > sysvinit-core, Xfce and wdm installed. To test whether X works, I
> > > disabled wdm, then I log in at the text console and run "startx". When X
> > > fails, the screen goes blank and the backlight stays on; when X works,
> > > the normal desktop comes up.
> > >
> > > X works in mainline v5.12 built using a config file based on Debian's
> > > config-5.10.0-8-powerpc.
> > >
> > > X fails in mainline v5.13 built using a config file based on Debian's
> > > config-5.10.0-8-powerpc.
> > >
> > > With much help and advice from Finn Thain, I was able to run a bisect
> > > using a config file based on Debian's config-5.10.0-8-powerpc, with
> > > v5.12 "good" and v5.13 "bad".
> > >
> > > $ git reset --hard
> > > HEAD is now at 62fb9874f5da Linux 5.13
> > > $ git bisect start v5.13
> > > Updating files: 100% (12992/12992), done.
> > > Previous HEAD position was 62fb9874f5da Linux 5.13
> > > HEAD is now at 9f4ad9e425a1 Linux 5.12
> > > $ git bisect bad v5.13
> > > $ git bisect good v5.12
> > > Bisecting: 8739 revisions left to test after this (roughly 13 steps)
> > > > 85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
> > > https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
> > >
> > > After the bisect, git reports this:
> > >
> > > ----------
> > >
> > > d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
> > > commit d3ccc9781560af051554017c702631560bdc0811
> > > Author: Christopher M. Riedl <cmr@codefail.de>
> > > Date: Fri Feb 26 19:12:59 2021 -0600
> > >
> > > powerpc/signal: Use __get_user() to copy sigset_t
> > >
> > > Usually sigset_t is exactly 8B which is a "trivial" size and does not
> > > warrant using __copy_from_user(). Use __get_user() directly in
> > > anticipation of future work to remove the trivial size optimizations
> > > from __copy_from_user().
> > >
> > > The ppc32 implementation of get_sigset_t() previously called
> > > copy_from_user() which, unlike __copy_from_user(), calls access_ok().
> > > Replacing this w/ __get_user() (no access_ok()) is fine here since both
> > > callsites in signal_32.c are preceded by an earlier access_ok().
> > >
> > > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
> > > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > > Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
> > >
> > > arch/powerpc/kernel/signal.h | 7 +++++++
> > > arch/powerpc/kernel/signal_32.c | 2 +-
> > > arch/powerpc/kernel/signal_64.c | 4 ++--
> > > 3 files changed, 10 insertions(+), 3 deletions(-)
> > >
> >
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Michael Ellerman @ 2021-11-02 23:17 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Christophe Leroy
Cc: linux-audit, linuxppc-dev, linux-kernel, Eric Paris, Paul Moore
In-Reply-To: <163584790624.1845480.1785827913484538939.b4-ty@ellerman.id.au>
Michael Ellerman <patch-notifications@ellerman.id.au> writes:
> On Tue, 24 Aug 2021 13:36:13 +0000 (UTC), Christophe Leroy wrote:
>> Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
>> targets") added generic support for AUDIT but that didn't include
>> support for bi-arch like powerpc.
>>
>> Commit 4b58841149dc ("audit: Add generic compat syscall support")
>> added generic support for bi-arch.
>>
>> [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
> https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
And then reverted in:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=b7472e1764bfc0fe3d6578cb281e81c812ca5886
cheers
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Michael Ellerman @ 2021-11-02 23:18 UTC (permalink / raw)
To: Paul Moore, patch-notifications
Cc: linux-kernel, linux-audit, Paul Mackerras, Eric Paris,
linuxppc-dev
In-Reply-To: <CAHC9VhROvSQHVQ6Wo8zHND1rGm+r6dGJur69B65sJ9JwNvMDpQ@mail.gmail.com>
Paul Moore <paul@paul-moore.com> writes:
> On Tue, Nov 2, 2021 at 7:38 AM Michael Ellerman
> <patch-notifications@ellerman.id.au> wrote:
>>
>> On Tue, 24 Aug 2021 13:36:13 +0000 (UTC), Christophe Leroy wrote:
>> > Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
>> > targets") added generic support for AUDIT but that didn't include
>> > support for bi-arch like powerpc.
>> >
>> > Commit 4b58841149dc ("audit: Add generic compat syscall support")
>> > added generic support for bi-arch.
>> >
>> > [...]
>>
>> Applied to powerpc/next.
>>
>> [1/1] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
>> https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
>
> Did the test failure discussed earlier in this thread ever get
> resolved? If not, this really shouldn't be in linux-next IMO.
It's not in next, that notification is from the b4 thanks script, which
didn't notice that the commit has since been reverted.
cheers
^ permalink raw reply
* Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures
From: Luis Chamberlain @ 2021-11-03 0:10 UTC (permalink / raw)
To: Dan Williams
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <CAPcyv4j+xLT=5RUodHWgnPjNq6t5OcmX1oM2zK2ML0U+OS_16Q@mail.gmail.com>
On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote:
> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > If nd_integrity_init() fails we'd get del_gendisk() called,
> > but that's not correct as we should only call that if we're
> > done with device_add_disk(). Fix this by providing unwinding
> > prior to the devm call being registered and moving the devm
> > registration to the very end.
> >
> > This should fix calling del_gendisk() if nd_integrity_init()
> > fails. I only spotted this issue through code inspection. It
> > does not fix any real world bug.
> >
>
> Just fyi, I'm preparing patches to delete this driver completely as it
> is unused by any shipping platform. I hope to get that removal into
> v5.16.
Curious if are you going to nuking it on v5.16? Otherwise it would stand
in the way of the last few patches to add __must_check for the final
add_disk() error handling changes.
Luis
^ permalink raw reply
* Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures
From: Dan Williams @ 2021-11-03 0:49 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <YYHTejXKvsGoDlOa@bombadil.infradead.org>
On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote:
> > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > >
> > > If nd_integrity_init() fails we'd get del_gendisk() called,
> > > but that's not correct as we should only call that if we're
> > > done with device_add_disk(). Fix this by providing unwinding
> > > prior to the devm call being registered and moving the devm
> > > registration to the very end.
> > >
> > > This should fix calling del_gendisk() if nd_integrity_init()
> > > fails. I only spotted this issue through code inspection. It
> > > does not fix any real world bug.
> > >
> >
> > Just fyi, I'm preparing patches to delete this driver completely as it
> > is unused by any shipping platform. I hope to get that removal into
> > v5.16.
>
> Curious if are you going to nuking it on v5.16? Otherwise it would stand
> in the way of the last few patches to add __must_check for the final
> add_disk() error handling changes.
True, I don't think I can get it nuked in time, so you can add my
Reviewed-by for this one.
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Paul Moore @ 2021-11-03 1:15 UTC (permalink / raw)
To: Michael Ellerman
Cc: patch-notifications, linux-kernel, linux-audit, Paul Mackerras,
Eric Paris, linuxppc-dev
In-Reply-To: <87a6im87tq.fsf@mpe.ellerman.id.au>
On Tue, Nov 2, 2021 at 7:19 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Paul Moore <paul@paul-moore.com> writes:
> > On Tue, Nov 2, 2021 at 7:38 AM Michael Ellerman
> > <patch-notifications@ellerman.id.au> wrote:
> >>
> >> On Tue, 24 Aug 2021 13:36:13 +0000 (UTC), Christophe Leroy wrote:
> >> > Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
> >> > targets") added generic support for AUDIT but that didn't include
> >> > support for bi-arch like powerpc.
> >> >
> >> > Commit 4b58841149dc ("audit: Add generic compat syscall support")
> >> > added generic support for bi-arch.
> >> >
> >> > [...]
> >>
> >> Applied to powerpc/next.
> >>
> >> [1/1] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
> >> https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
> >
> > Did the test failure discussed earlier in this thread ever get
> > resolved? If not, this really shouldn't be in linux-next IMO.
>
> It's not in next, that notification is from the b4 thanks script, which
> didn't notice that the commit has since been reverted.
Okay, thanks for the clarification. I know we had already talked
about this so I was a little caught off guard when I saw this mail :)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures
From: Jens Axboe @ 2021-11-03 1:28 UTC (permalink / raw)
To: Dan Williams, Luis Chamberlain
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Geoff Levand, Linux Kernel Mailing List, Jim Paris,
senozhatsky, Richard Weinberger, linux-mtd, linuxppc-dev
In-Reply-To: <CAPcyv4h1dqBm71OQ_A5Qv4agT3PhV7uoojmSB1pEpS-CXaWb5w@mail.gmail.com>
On 11/2/21 6:49 PM, Dan Williams wrote:
> On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>>
>> On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote:
>>> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>>>>
>>>> If nd_integrity_init() fails we'd get del_gendisk() called,
>>>> but that's not correct as we should only call that if we're
>>>> done with device_add_disk(). Fix this by providing unwinding
>>>> prior to the devm call being registered and moving the devm
>>>> registration to the very end.
>>>>
>>>> This should fix calling del_gendisk() if nd_integrity_init()
>>>> fails. I only spotted this issue through code inspection. It
>>>> does not fix any real world bug.
>>>>
>>>
>>> Just fyi, I'm preparing patches to delete this driver completely as it
>>> is unused by any shipping platform. I hope to get that removal into
>>> v5.16.
>>
>> Curious if are you going to nuking it on v5.16? Otherwise it would stand
>> in the way of the last few patches to add __must_check for the final
>> add_disk() error handling changes.
>
> True, I don't think I can get it nuked in time, so you can add my
> Reviewed-by for this one.
Luis, I lost track of the nv* patches from this discussion. If you want
them in 5.16 and they are reviewed, please do resend and I'll pick them
up for the middle-of-merge-window push.
--
Jens Axboe
^ permalink raw reply
* [PATCH] powerpc/sysdev/of_rtc: Fix possible memory leak in of_instantiate_rtc
From: He Ying @ 2021-11-03 1:47 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
If of_address_to_resource() in of_instantiate_rtc() fails, previously
allocated memory res is not freed. Add missing kfree() for it.
Signed-off-by: He Ying <heying24@huawei.com>
---
arch/powerpc/sysdev/of_rtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/of_rtc.c b/arch/powerpc/sysdev/of_rtc.c
index 1f408d34a6a7..23b896996c2f 100644
--- a/arch/powerpc/sysdev/of_rtc.c
+++ b/arch/powerpc/sysdev/of_rtc.c
@@ -44,6 +44,7 @@ void __init of_instantiate_rtc(void)
printk(KERN_ERR "OF RTC: Error "
"translating resources for %pOF\n",
node);
+ kfree(res);
continue;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] powerpc/embedded6xx/hlwd-pic: Add missing of_node_put in hlwd_pic_probe
From: He Ying @ 2021-11-03 1:48 UTC (permalink / raw)
To: mpe, benh, paulus, maz; +Cc: linuxppc-dev, linux-kernel
Early exits from for_each_compatible_node() should decrease the
node reference count.
Signed-off-by: He Ying <heying24@huawei.com>
---
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index 15396333a90b..a4b020e4b6af 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -214,6 +214,7 @@ void hlwd_pic_probe(void)
irq_set_chained_handler(cascade_virq,
hlwd_pic_irq_cascade);
hlwd_irq_host = host;
+ of_node_put(np);
break;
}
}
--
2.17.1
^ permalink raw reply related
* Re: Fwd: Fwd: X stopped working with 5.14 on iBook
From: Riccardo Mottola @ 2021-11-02 22:45 UTC (permalink / raw)
To: Christopher M. Riedl, Finn Thain, Christopher M. Riedl
Cc: Stan Johnson, linuxppc-dev
In-Reply-To: <CFFNC8MZ20HR.13XRVPWSKVLE0@wrwlf0000>
Hi All,
Christopher M. Riedl wrote:
> Stan also tested a PowerMac G3 system and found that the regression is
> not
> present there. Thus far, only PowerMac G4 systems are known to be
> affected
> (Stan's Cube and Riccardo's PowerBook).
I actually tested right now on an iBook G3 kernel 5.14.12-1 of 2021-14
from Debian and X does not start on it anyway, with the same behaviour
on the G4.
During the weekend I did test on an iMac G5 and it works.
I don't know how Stan tested - but at least for me issue seems to be
both G3 and G4.
Riccardo
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Konstantin Ryabitsev @ 2021-11-02 23:54 UTC (permalink / raw)
To: Michael Ellerman
Cc: Paul Moore, patch-notifications, linux-kernel, linux-audit,
Paul Mackerras, Eric Paris, linuxppc-dev
In-Reply-To: <87a6im87tq.fsf@mpe.ellerman.id.au>
On Wed, Nov 03, 2021 at 10:18:57AM +1100, Michael Ellerman wrote:
> It's not in next, that notification is from the b4 thanks script, which
> didn't notice that the commit has since been reverted.
Yeah... I'm not sure how to catch that, but I'm open to suggestions.
-K
^ permalink raw reply
* Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures
From: Luis Chamberlain @ 2021-11-03 12:08 UTC (permalink / raw)
To: Dan Williams
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <CAPcyv4h1dqBm71OQ_A5Qv4agT3PhV7uoojmSB1pEpS-CXaWb5w@mail.gmail.com>
On Tue, Nov 02, 2021 at 05:49:12PM -0700, Dan Williams wrote:
> On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote:
> > > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > >
> > > > If nd_integrity_init() fails we'd get del_gendisk() called,
> > > > but that's not correct as we should only call that if we're
> > > > done with device_add_disk(). Fix this by providing unwinding
> > > > prior to the devm call being registered and moving the devm
> > > > registration to the very end.
> > > >
> > > > This should fix calling del_gendisk() if nd_integrity_init()
> > > > fails. I only spotted this issue through code inspection. It
> > > > does not fix any real world bug.
> > > >
> > >
> > > Just fyi, I'm preparing patches to delete this driver completely as it
> > > is unused by any shipping platform. I hope to get that removal into
> > > v5.16.
> >
> > Curious if are you going to nuking it on v5.16? Otherwise it would stand
> > in the way of the last few patches to add __must_check for the final
> > add_disk() error handling changes.
>
> True, I don't think I can get it nuked in time, so you can add my
> Reviewed-by for this one.
This patch required the previous patch in this series to also be
applied. Can I apply your Reviewed-by there too?
Luis
^ permalink raw reply
* Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures
From: Luis Chamberlain @ 2021-11-03 12:09 UTC (permalink / raw)
To: Jens Axboe
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Dan Williams, Geoff Levand,
Linux Kernel Mailing List, Jim Paris, senozhatsky,
Richard Weinberger, linux-mtd, linuxppc-dev
In-Reply-To: <51f86768-04ca-bc7d-c17c-3d0357d84271@kernel.dk>
On Tue, Nov 02, 2021 at 07:28:02PM -0600, Jens Axboe wrote:
> On 11/2/21 6:49 PM, Dan Williams wrote:
> > On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >>
> >> On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote:
> >>> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >>>>
> >>>> If nd_integrity_init() fails we'd get del_gendisk() called,
> >>>> but that's not correct as we should only call that if we're
> >>>> done with device_add_disk(). Fix this by providing unwinding
> >>>> prior to the devm call being registered and moving the devm
> >>>> registration to the very end.
> >>>>
> >>>> This should fix calling del_gendisk() if nd_integrity_init()
> >>>> fails. I only spotted this issue through code inspection. It
> >>>> does not fix any real world bug.
> >>>>
> >>>
> >>> Just fyi, I'm preparing patches to delete this driver completely as it
> >>> is unused by any shipping platform. I hope to get that removal into
> >>> v5.16.
> >>
> >> Curious if are you going to nuking it on v5.16? Otherwise it would stand
> >> in the way of the last few patches to add __must_check for the final
> >> add_disk() error handling changes.
> >
> > True, I don't think I can get it nuked in time, so you can add my
> > Reviewed-by for this one.
>
> Luis, I lost track of the nv* patches from this discussion. If you want
> them in 5.16 and they are reviewed, please do resend and I'll pick them
> up for the middle-of-merge-window push.
Sure thing, I'll resend whatever is left. I also noticed for some reason
I forgot to convert nvdimm/pmem and so I'll roll those new patches in,
but I suspect that those might be too late unless we get them reviewed
in time.
Luis
^ permalink raw reply
* [PATCH 0/3] KEXEC_SIG with appended signature
From: Michal Suchanek @ 2021-11-03 14:27 UTC (permalink / raw)
To: keyrings
Cc: Rob Herring, linux-s390, Vasily Gorbik, Lakshmi Ramasubramanian,
Heiko Carstens, Jessica Yu, linux-kernel, David Howells,
Christian Borntraeger, Luis Chamberlain, Paul Mackerras,
Hari Bathini, Alexander Gordeev, Michal Suchanek, linuxppc-dev,
Frank van der Linden, Thiago Jung Bauermann
S390 uses appended signature for kernel but implements the check
separately from module loader.
Support for secure boot on powerpc with appended signature is planned -
grub patches submitted upstream but not yet merged.
This is an attempt at unified appended signature verification.
Thanks
Michal
Michal Suchanek (3):
s390/kexec_file: Don't opencode appended signature verification.
module: strip the signature marker in the verification function.
powerpc/kexec_file: Add KEXEC_SIG support.
arch/powerpc/Kconfig | 11 +++++++
arch/powerpc/kexec/elf_64.c | 14 +++++++++
arch/s390/kernel/machine_kexec_file.c | 42 +++------------------------
include/linux/verification.h | 3 ++
kernel/module-internal.h | 2 --
kernel/module.c | 11 +++----
kernel/module_signing.c | 32 ++++++++++++++------
7 files changed, 59 insertions(+), 56 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH 3/3] powerpc/kexec_file: Add KEXEC_SIG support.
From: Michal Suchanek @ 2021-11-03 14:27 UTC (permalink / raw)
To: keyrings
Cc: Rob Herring, linux-s390, Vasily Gorbik, Lakshmi Ramasubramanian,
Heiko Carstens, Jessica Yu, linux-kernel, David Howells,
Christian Borntraeger, Luis Chamberlain, Paul Mackerras,
Hari Bathini, Alexander Gordeev, Michal Suchanek, linuxppc-dev,
Frank van der Linden, Thiago Jung Bauermann
In-Reply-To: <cover.1635948742.git.msuchanek@suse.de>
Use the module verifier for the kernel image verification.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/powerpc/Kconfig | 11 +++++++++++
arch/powerpc/kexec/elf_64.c | 14 ++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 743c9783c64f..27bffafa9e79 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -558,6 +558,17 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config KEXEC_SIG
+ bool "Verify kernel signature during kexec_file_load() syscall"
+ depends on KEXEC_FILE && MODULE_SIG_FORMAT
+ help
+ This option makes kernel signature verification mandatory for
+ the kexec_file_load() syscall.
+
+ In addition to that option, you need to enable signature
+ verification for the corresponding kernel image type being
+ loaded in order for this to work.
+
config PPC64_BUILD_ELF_V2_ABI
bool
diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index eeb258002d1e..e8dff6b23ac5 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -23,6 +23,7 @@
#include <linux/of_fdt.h>
#include <linux/slab.h>
#include <linux/types.h>
+#include <linux/verification.h>
static void *elf64_load(struct kimage *image, char *kernel_buf,
unsigned long kernel_len, char *initrd,
@@ -151,7 +152,20 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
return ret ? ERR_PTR(ret) : NULL;
}
+#ifdef CONFIG_KEXEC_SIG
+int elf64_verify_sig(const char *kernel, unsigned long length)
+{
+ size_t kernel_len = length;
+
+ return verify_appended_signature(kernel, &kernel_len, VERIFY_USE_PLATFORM_KEYRING,
+ "kexec_file");
+}
+#endif /* CONFIG_KEXEC_SIG */
+
const struct kexec_file_ops kexec_elf64_ops = {
.probe = kexec_elf_probe,
.load = elf64_load,
+#ifdef CONFIG_KEXEC_SIG
+ .verify_sig = elf64_verify_sig,
+#endif
};
--
2.31.1
^ permalink raw reply related
* [PATCH 1/3] s390/kexec_file: Don't opencode appended signature verification.
From: Michal Suchanek @ 2021-11-03 14:27 UTC (permalink / raw)
To: keyrings
Cc: Rob Herring, linux-s390, Vasily Gorbik, Lakshmi Ramasubramanian,
Heiko Carstens, Jessica Yu, linux-kernel, David Howells,
Christian Borntraeger, Luis Chamberlain, Paul Mackerras,
Hari Bathini, Alexander Gordeev, Michal Suchanek, linuxppc-dev,
Frank van der Linden, Thiago Jung Bauermann
In-Reply-To: <cover.1635948742.git.msuchanek@suse.de>
Module verification already implements appeded signature verification.
Reuse it for kexec_file.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/s390/kernel/machine_kexec_file.c | 33 ++++-----------------------
include/linux/verification.h | 3 +++
kernel/module-internal.h | 2 --
kernel/module.c | 4 +++-
kernel/module_signing.c | 24 +++++++++++--------
5 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
index f9e4baa64b67..634e641cd8aa 100644
--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -23,11 +23,10 @@ const struct kexec_file_ops * const kexec_file_loaders[] = {
};
#ifdef CONFIG_KEXEC_SIG
-int s390_verify_sig(const char *kernel, unsigned long kernel_len)
+int s390_verify_sig(const char *kernel, unsigned long length)
{
+ size_t kernel_len = length;
const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
- struct module_signature *ms;
- unsigned long sig_len;
/* Skip signature verification when not secure IPLed. */
if (!ipl_secure_flag)
@@ -41,32 +40,8 @@ int s390_verify_sig(const char *kernel, unsigned long kernel_len)
return -EKEYREJECTED;
kernel_len -= marker_len;
- ms = (void *)kernel + kernel_len - sizeof(*ms);
- kernel_len -= sizeof(*ms);
-
- sig_len = be32_to_cpu(ms->sig_len);
- if (sig_len >= kernel_len)
- return -EKEYREJECTED;
- kernel_len -= sig_len;
-
- if (ms->id_type != PKEY_ID_PKCS7)
- return -EKEYREJECTED;
-
- if (ms->algo != 0 ||
- ms->hash != 0 ||
- ms->signer_len != 0 ||
- ms->key_id_len != 0 ||
- ms->__pad[0] != 0 ||
- ms->__pad[1] != 0 ||
- ms->__pad[2] != 0) {
- return -EBADMSG;
- }
-
- return verify_pkcs7_signature(kernel, kernel_len,
- kernel + kernel_len, sig_len,
- VERIFY_USE_PLATFORM_KEYRING,
- VERIFYING_MODULE_SIGNATURE,
- NULL, NULL);
+ return verify_appended_signature(kernel, &kernel_len, VERIFY_USE_PLATFORM_KEYRING,
+ "kexec_file");
}
#endif /* CONFIG_KEXEC_SIG */
diff --git a/include/linux/verification.h b/include/linux/verification.h
index a655923335ae..c1cf0582012a 100644
--- a/include/linux/verification.h
+++ b/include/linux/verification.h
@@ -60,5 +60,8 @@ extern int verify_pefile_signature(const void *pebuf, unsigned pelen,
enum key_being_used_for usage);
#endif
+int verify_appended_signature(const void *data, size_t *len, struct key *trusted_keys,
+ const char *what);
+
#endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
#endif /* _LINUX_VERIFY_PEFILE_H */
diff --git a/kernel/module-internal.h b/kernel/module-internal.h
index 33783abc377b..80461e14bf29 100644
--- a/kernel/module-internal.h
+++ b/kernel/module-internal.h
@@ -27,5 +27,3 @@ struct load_info {
unsigned int sym, str, mod, vers, info, pcpu;
} index;
};
-
-extern int mod_verify_sig(const void *mod, struct load_info *info);
diff --git a/kernel/module.c b/kernel/module.c
index 5c26a76e800b..137b3661be75 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -57,6 +57,7 @@
#include <linux/bsearch.h>
#include <linux/dynamic_debug.h>
#include <linux/audit.h>
+#include <linux/verification.h>
#include <uapi/linux/module.h>
#include "module-internal.h"
@@ -2894,7 +2895,8 @@ static int module_sig_check(struct load_info *info, int flags)
memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
/* We truncate the module to discard the signature */
info->len -= markerlen;
- err = mod_verify_sig(mod, info);
+ err = verify_appended_signature(mod, &info->len,
+ VERIFY_USE_SECONDARY_KEYRING, "module");
if (!err) {
info->sig_ok = true;
return 0;
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 8723ae70ea1f..f492e410564d 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -14,13 +14,19 @@
#include <crypto/public_key.h>
#include "module-internal.h"
-/*
- * Verify the signature on a module.
+/**
+ * verify_appended_signature - Verify the signature on a module with the
+ * signature marker stripped.
+ * @data: The data to be verified
+ * @len: Size of @data.
+ * @trusted_keys: Keyring to use for verification
+ * @what: Informational string for log messages
*/
-int mod_verify_sig(const void *mod, struct load_info *info)
+int verify_appended_signature(const void *data, size_t *len,
+ struct key *trusted_keys, const char *what)
{
struct module_signature ms;
- size_t sig_len, modlen = info->len;
+ size_t sig_len, modlen = *len;
int ret;
pr_devel("==>%s(,%zu)\n", __func__, modlen);
@@ -28,18 +34,18 @@ int mod_verify_sig(const void *mod, struct load_info *info)
if (modlen <= sizeof(ms))
return -EBADMSG;
- memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
+ memcpy(&ms, data + (modlen - sizeof(ms)), sizeof(ms));
- ret = mod_check_sig(&ms, modlen, "module");
+ ret = mod_check_sig(&ms, modlen, what);
if (ret)
return ret;
sig_len = be32_to_cpu(ms.sig_len);
modlen -= sig_len + sizeof(ms);
- info->len = modlen;
+ *len = modlen;
- return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
- VERIFY_USE_SECONDARY_KEYRING,
+ return verify_pkcs7_signature(data, modlen, data + modlen, sig_len,
+ trusted_keys,
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
}
--
2.31.1
^ permalink raw reply related
* [PATCH 2/3] module: strip the signature marker in the verification function.
From: Michal Suchanek @ 2021-11-03 14:27 UTC (permalink / raw)
To: keyrings
Cc: Rob Herring, linux-s390, Vasily Gorbik, Lakshmi Ramasubramanian,
Heiko Carstens, Jessica Yu, linux-kernel, David Howells,
Christian Borntraeger, Luis Chamberlain, Paul Mackerras,
Hari Bathini, Alexander Gordeev, Michal Suchanek, linuxppc-dev,
Frank van der Linden, Thiago Jung Bauermann
In-Reply-To: <cover.1635948742.git.msuchanek@suse.de>
It is stripped by each caller separately.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/s390/kernel/machine_kexec_file.c | 9 ---------
kernel/module.c | 7 +------
kernel/module_signing.c | 12 ++++++++++--
3 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
index 634e641cd8aa..82260bb61060 100644
--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -26,20 +26,11 @@ const struct kexec_file_ops * const kexec_file_loaders[] = {
int s390_verify_sig(const char *kernel, unsigned long length)
{
size_t kernel_len = length;
- const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
/* Skip signature verification when not secure IPLed. */
if (!ipl_secure_flag)
return 0;
- if (marker_len > kernel_len)
- return -EKEYREJECTED;
-
- if (memcmp(kernel + kernel_len - marker_len, MODULE_SIG_STRING,
- marker_len))
- return -EKEYREJECTED;
- kernel_len -= marker_len;
-
return verify_appended_signature(kernel, &kernel_len, VERIFY_USE_PLATFORM_KEYRING,
"kexec_file");
}
diff --git a/kernel/module.c b/kernel/module.c
index 137b3661be75..1c421b0442e3 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2882,7 +2882,6 @@ static inline void kmemleak_load_module(const struct module *mod,
static int module_sig_check(struct load_info *info, int flags)
{
int err = -ENODATA;
- const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
const char *reason;
const void *mod = info->hdr;
@@ -2890,11 +2889,7 @@ static int module_sig_check(struct load_info *info, int flags)
* Require flags == 0, as a module with version information
* removed is no longer the module that was signed
*/
- if (flags == 0 &&
- info->len > markerlen &&
- memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
- /* We truncate the module to discard the signature */
- info->len -= markerlen;
+ if (flags == 0) {
err = verify_appended_signature(mod, &info->len,
VERIFY_USE_SECONDARY_KEYRING, "module");
if (!err) {
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index f492e410564d..4c28cb55275f 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -15,8 +15,7 @@
#include "module-internal.h"
/**
- * verify_appended_signature - Verify the signature on a module with the
- * signature marker stripped.
+ * verify_appended_signature - Verify the signature on a module
* @data: The data to be verified
* @len: Size of @data.
* @trusted_keys: Keyring to use for verification
@@ -25,12 +24,21 @@
int verify_appended_signature(const void *data, size_t *len,
struct key *trusted_keys, const char *what)
{
+ const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
struct module_signature ms;
size_t sig_len, modlen = *len;
int ret;
pr_devel("==>%s(,%zu)\n", __func__, modlen);
+ if (markerlen > modlen)
+ return -ENODATA;
+
+ if (memcmp(data + modlen - markerlen, MODULE_SIG_STRING,
+ markerlen))
+ return -ENODATA;
+ modlen -= markerlen;
+
if (modlen <= sizeof(ms))
return -EBADMSG;
--
2.31.1
^ permalink raw reply related
* Re: Fwd: Fwd: X stopped working with 5.14 on iBook
From: Andreas Schwab @ 2021-11-03 8:51 UTC (permalink / raw)
To: Finn Thain
Cc: Christopher M. Riedl, Stan Johnson, linuxppc-dev,
Riccardo Mottola
In-Reply-To: <48c3ed15-2ecf-cc12-c287-2b61457f5fb__21333.0969143257$1635819996$gmane$org@nippy.intranet>
On Nov 02 2021, Finn Thain wrote:
> After many builds and tests, Stan and I were able to determine that this
> regression only affects builds with CONFIG_USER_NS=y. That is,
>
> d3ccc9781560 + CONFIG_USER_NS=y --> fail
> d3ccc9781560 + CONFIG_USER_NS=n --> okay
> d3ccc9781560~ + CONFIG_USER_NS=y --> okay
> d3ccc9781560~ + CONFIG_USER_NS=n --> okay
On my iBook G4, X is working alright with 5.15 and CONFIG_USER_NS=y.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* [PATCH 1/2] soc: fsl: guts: Revert commit 3c0d64e867ed
From: Christophe JAILLET @ 2021-11-03 20:00 UTC (permalink / raw)
To: leoyang.li, tyreld
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel,
linux-arm-kernel
This reverts commit 3c0d64e867ed
("soc: fsl: guts: reuse machine name from device tree").
A following patch will fix the missing memory allocation failure check
instead.
Suggested-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This is a follow-up of discussion in:
https://lore.kernel.org/kernel-janitors/b12e8c5c5d6ab3061d9504de8fbaefcad6bbc385.1629321668.git.christophe.jaillet@wanadoo.fr/
---
drivers/soc/fsl/guts.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 072473a16f4d..af7741eafc57 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -28,7 +28,6 @@ struct fsl_soc_die_attr {
static struct guts *guts;
static struct soc_device_attribute soc_dev_attr;
static struct soc_device *soc_dev;
-static struct device_node *root;
/* SoC die attribute definition for QorIQ platform */
@@ -138,7 +137,7 @@ static u32 fsl_guts_get_svr(void)
static int fsl_guts_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *root, *np = pdev->dev.of_node;
struct device *dev = &pdev->dev;
const struct fsl_soc_die_attr *soc_die;
const char *machine;
@@ -159,8 +158,9 @@ static int fsl_guts_probe(struct platform_device *pdev)
root = of_find_node_by_path("/");
if (of_property_read_string(root, "model", &machine))
of_property_read_string_index(root, "compatible", 0, &machine);
+ of_node_put(root);
if (machine)
- soc_dev_attr.machine = machine;
+ soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
svr = fsl_guts_get_svr();
soc_die = fsl_soc_die_match(svr, fsl_soc_die);
@@ -195,7 +195,6 @@ static int fsl_guts_probe(struct platform_device *pdev)
static int fsl_guts_remove(struct platform_device *dev)
{
soc_device_unregister(soc_dev);
- of_node_put(root);
return 0;
}
--
2.30.2
^ permalink raw reply related
* [PATCH 2/2] soc: fsl: guts: Add a missing memory allocation failure check
From: Christophe JAILLET @ 2021-11-03 20:00 UTC (permalink / raw)
To: leoyang.li, tyreld
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel,
linux-arm-kernel
In-Reply-To: <1063e5a4738d897adcaffce2ab8e4e45f07998ff.1635969326.git.christophe.jaillet@wanadoo.fr>
If 'devm_kstrdup()' fails, we should return -ENOMEM.
While at it, move the 'of_node_put()' call in the error handling path and
after the 'machine' has been copied.
Better safe than sorry.
Suggested-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Not sure of which Fixes tag to add. Should be a6fc3b698130, but since
another commit needs to be reverted for this patch to make sense, I'm
unsure of what to do. :(
So, none is given.
---
drivers/soc/fsl/guts.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index af7741eafc57..5ed2fc1c53a0 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -158,9 +158,14 @@ static int fsl_guts_probe(struct platform_device *pdev)
root = of_find_node_by_path("/");
if (of_property_read_string(root, "model", &machine))
of_property_read_string_index(root, "compatible", 0, &machine);
- of_node_put(root);
- if (machine)
+ if (machine) {
soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
+ if (!soc_dev_attr.machine) {
+ of_node_put(root);
+ return -ENOMEM;
+ }
+ }
+ of_node_put(root);
svr = fsl_guts_get_svr();
soc_die = fsl_soc_die_match(svr, fsl_soc_die);
--
2.30.2
^ permalink raw reply related
* [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
From: Florian Fainelli @ 2021-11-03 20:56 UTC (permalink / raw)
To: linux-kernel
Cc: open list:MIPS, Palmer Dabbelt, Stefan Agner, Paul Mackerras,
stable, open list:RISC-V ARCHITECTURE, Sasha Levin,
Florian Fainelli, Russell King, Mike Rapoport, James Hogan,
open list:SYNOPSYS ARC ARCHITECTURE,
open list:GENERIC INCLUDE/ASM HEADER FILES, Albert Ou,
Arnd Bergmann, moderated list:ARM PORT, Thomas Bogendoerfer,
Greg Kroah-Hartman, Ralf Baechle, Paul Burton, Vineet Gupta,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
Stefan Agner reported a bug when using zsram on 32-bit Arm machines
with RAM above the 4GB address boundary:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = a27bd01c
[00000000] *pgd=236a0003, *pmd=1ffa64003
Internal error: Oops: 207 [#1] SMP ARM
Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
Hardware name: BCM2711
PC is at zs_map_object+0x94/0x338
LR is at zram_bvec_rw.constprop.0+0x330/0xa64
pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
sp : e376bbe0 ip : 00000000 fp : c1e2921c
r10: 00000002 r9 : c1dda730 r8 : 00000000
r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 30c5383d Table: 235c2a80 DAC: fffffffd
Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
Stack: (0xe376bbe0 to 0xe376c000)
As it turns out, zsram needs to know the maximum memory size, which
is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
The same problem will be hit on all 32-bit architectures that have a
physical address space larger than 4GB and happen to not enable sparsemem
and include asm/sparsemem.h from asm/pgtable.h.
After the initial discussion, I suggested just always defining
MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
set, or provoking a build error otherwise. This addresses all
configurations that can currently have this runtime bug, but
leaves all other configurations unchanged.
I looked up the possible number of bits in source code and
datasheets, here is what I found:
- on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
- on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
support more than 32 bits, even though supersections in theory allow
up to 40 bits as well.
- on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
XPA supports up to 60 bits in theory, but 40 bits are more than
anyone will ever ship
- On PowerPC, there are three different implementations of 36 bit
addressing, but 32-bit is used without CONFIG_PTE_64BIT
- On RISC-V, the normal page table format can support 34 bit
addressing. There is no highmem support on RISC-V, so anything
above 2GB is unused, but it might be useful to eventually support
CONFIG_ZRAM for high pages.
Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arc/include/asm/pgtable.h | 2 ++
arch/arm/include/asm/pgtable-2level.h | 2 ++
arch/arm/include/asm/pgtable-3level.h | 2 ++
arch/mips/include/asm/pgtable-32.h | 3 +++
arch/powerpc/include/asm/pte-common.h | 2 ++
arch/riscv/include/asm/pgtable-32.h | 2 ++
include/asm-generic/pgtable.h | 13 +++++++++++++
7 files changed, 26 insertions(+)
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index cf4be70d5892..f231963b4011 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -138,8 +138,10 @@
#ifdef CONFIG_ARC_HAS_PAE40
#define PTE_BITS_NON_RWX_IN_PD1 (0xff00000000 | PAGE_MASK | _PAGE_CACHEABLE)
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
#else
#define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#endif
/**************************************************************************
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index 12659ce5c1f3..90bf19d99378 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -78,6 +78,8 @@
#define PTE_HWTABLE_OFF (PTE_HWTABLE_PTRS * sizeof(pte_t))
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u32))
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
/*
* PMD_SHIFT determines the size of the area a second-level page table can map
* PGDIR_SHIFT determines what a third-level page table entry can map
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 6d50a11d7793..7ba08dd650e3 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -37,6 +37,8 @@
#define PTE_HWTABLE_OFF (0)
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u64))
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
+
/*
* PGDIR_SHIFT determines the size a top-level page table entry can map.
*/
diff --git a/arch/mips/include/asm/pgtable-32.h b/arch/mips/include/asm/pgtable-32.h
index 74afe8c76bdd..215fb48f644b 100644
--- a/arch/mips/include/asm/pgtable-32.h
+++ b/arch/mips/include/asm/pgtable-32.h
@@ -111,6 +111,7 @@ static inline void pmd_clear(pmd_t *pmdp)
#if defined(CONFIG_XPA)
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
#define pte_pfn(x) (((unsigned long)((x).pte_high >> _PFN_SHIFT)) | (unsigned long)((x).pte_low << _PAGE_PRESENT_SHIFT))
static inline pte_t
pfn_pte(unsigned long pfn, pgprot_t prot)
@@ -126,6 +127,7 @@ pfn_pte(unsigned long pfn, pgprot_t prot)
#elif defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32)
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
#define pte_pfn(x) ((unsigned long)((x).pte_high >> 6))
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t prot)
@@ -140,6 +142,7 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t prot)
#else
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#ifdef CONFIG_CPU_VR41XX
#define pte_pfn(x) ((unsigned long)((x).pte >> (PAGE_SHIFT + 2)))
#define pfn_pte(pfn, prot) __pte(((pfn) << (PAGE_SHIFT + 2)) | pgprot_val(prot))
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index bef56141a549..f740f67ebf98 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -110,8 +110,10 @@ static inline bool pte_user(pte_t pte)
*/
#if defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT)
#define PTE_RPN_MASK (~((1ULL<<PTE_RPN_SHIFT)-1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
#else
#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#endif
/* _PAGE_CHG_MASK masks of bits that are to be preserved across
diff --git a/arch/riscv/include/asm/pgtable-32.h b/arch/riscv/include/asm/pgtable-32.h
index d61974b74182..5cfe5a131867 100644
--- a/arch/riscv/include/asm/pgtable-32.h
+++ b/arch/riscv/include/asm/pgtable-32.h
@@ -22,4 +22,6 @@
#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE - 1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 34
+
#endif /* _ASM_RISCV_PGTABLE_32_H */
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 5901b0005929..1544331bec27 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1115,6 +1115,19 @@ static inline bool arch_has_pfn_modify_check(void)
#endif /* !__ASSEMBLY__ */
+#if !defined(MAX_POSSIBLE_PHYSMEM_BITS) && !defined(CONFIG_64BIT)
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+/*
+ * ZSMALLOC needs to know the highest PFN on 32-bit architectures
+ * with physical address space extension, but falls back to
+ * BITS_PER_LONG otherwise.
+ */
+#error Missing MAX_POSSIBLE_PHYSMEM_BITS definition
+#else
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+#endif
+#endif
+
#ifndef has_transparent_hugepage
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define has_transparent_hugepage() 1
--
2.25.1
^ permalink raw reply related
* [PATCH stable 4.14 0/2] zsmalloc MAX_POSSIBLE_PHYSMEM_BITS
From: Florian Fainelli @ 2021-11-03 20:57 UTC (permalink / raw)
To: linux-kernel
Cc: open list:MIPS, Sergey Senozhatsky, Stefan Agner,
open list:ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR,
Paul Mackerras, Ralf Baechle, H. Peter Anvin, Sasha Levin,
Florian Fainelli, maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT,
Russell King, Mike Rapoport, Ingo Molnar,
open list:SYNOPSYS ARC ARCHITECTURE, Nitin Gupta,
open list:GENERIC INCLUDE/ASM HEADER FILES, Arnd Bergmann,
Thomas Gleixner, moderated list:ARM PORT, Thomas Bogendoerfer,
Greg Kroah-Hartman, stable, Minchan Kim, Vineet Gupta,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, Kirill A. Shutemov
This patch series is a back port necessary to address the problem
reported by Stefan Agner:
https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
but which ended up being addressed by Arnd in a slightly different way
from Stefan's submission.
The first patch from Kirill is back ported in order to have
MAX_POSSIBLE_PHYSMEM_BITS be acted on my the zsmalloc.c code.
Arnd Bergmann (1):
arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Kirill A. Shutemov (1):
mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
arch/arc/include/asm/pgtable.h | 2 ++
arch/arm/include/asm/pgtable-2level.h | 2 ++
arch/arm/include/asm/pgtable-3level.h | 2 ++
arch/mips/include/asm/pgtable-32.h | 3 +++
arch/powerpc/include/asm/pte-common.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 1 +
arch/x86/include/asm/pgtable_64_types.h | 2 ++
include/asm-generic/pgtable.h | 13 +++++++++++++
mm/zsmalloc.c | 13 +++++++------
9 files changed, 34 insertions(+), 6 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH stable 4.14 1/2] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
From: Florian Fainelli @ 2021-11-03 20:57 UTC (permalink / raw)
To: linux-kernel
Cc: open list:MIPS, Sergey Senozhatsky, Peter Zijlstra, Stefan Agner,
linux-mm, Paul Mackerras, stable, H. Peter Anvin, Ingo Molnar,
Sasha Levin, Florian Fainelli,
open list:SYNOPSYS ARC ARCHITECTURE,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Russell King,
Mike Rapoport, Ingo Molnar, Borislav Petkov, Nitin Gupta,
open list:GENERIC INCLUDE/ASM HEADER FILES, Arnd Bergmann,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, Thomas Gleixner,
moderated list:ARM PORT, Thomas Bogendoerfer, Greg Kroah-Hartman,
Ralf Baechle, Andy Lutomirski, Minchan Kim, Vineet Gupta,
Linus Torvalds, Kirill A. Shutemov
In-Reply-To: <20211103205704.374734-1-f.fainelli@gmail.com>
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
commit 02390b87a9459937cdb299e6b34ff33992512ec7 upstream
With boot-time switching between paging mode we will have variable
MAX_PHYSMEM_BITS.
Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y
configuration to define zsmalloc data structures.
The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case.
It also suits well to handle PAE special case.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Nitin Gupta <ngupta@vflare.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/20180214111656.88514-3-kirill.shutemov@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/x86/include/asm/pgtable-3level_types.h | 1 +
arch/x86/include/asm/pgtable_64_types.h | 2 ++
mm/zsmalloc.c | 13 +++++++------
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level_types.h b/arch/x86/include/asm/pgtable-3level_types.h
index 876b4c77d983..6a59a6d0cc50 100644
--- a/arch/x86/include/asm/pgtable-3level_types.h
+++ b/arch/x86/include/asm/pgtable-3level_types.h
@@ -44,5 +44,6 @@ typedef union {
*/
#define PTRS_PER_PTE 512
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
#endif /* _ASM_X86_PGTABLE_3LEVEL_DEFS_H */
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index bf6d2692fc60..2bd79b7ae9d6 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -40,6 +40,8 @@ typedef struct { pteval_t pte; } pte_t;
#define P4D_SIZE (_AC(1, UL) << P4D_SHIFT)
#define P4D_MASK (~(P4D_SIZE - 1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 52
+
#else /* CONFIG_X86_5LEVEL */
/*
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 6ed736ea9b59..633ebcac82f8 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -83,18 +83,19 @@
* This is made more complicated by various memory models and PAE.
*/
-#ifndef MAX_PHYSMEM_BITS
-#ifdef CONFIG_HIGHMEM64G
-#define MAX_PHYSMEM_BITS 36
-#else /* !CONFIG_HIGHMEM64G */
+#ifndef MAX_POSSIBLE_PHYSMEM_BITS
+#ifdef MAX_PHYSMEM_BITS
+#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS
+#else
/*
* If this definition of MAX_PHYSMEM_BITS is used, OBJ_INDEX_BITS will just
* be PAGE_SHIFT
*/
-#define MAX_PHYSMEM_BITS BITS_PER_LONG
+#define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
#endif
#endif
-#define _PFN_BITS (MAX_PHYSMEM_BITS - PAGE_SHIFT)
+
+#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
/*
* Memory for allocating for handle keeps object position by
--
2.25.1
^ permalink raw reply related
* [PATCH stable 4.14 2/2] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
From: Florian Fainelli @ 2021-11-03 20:57 UTC (permalink / raw)
To: linux-kernel
Cc: open list:MIPS, Sergey Senozhatsky, Stefan Agner,
open list:ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR,
Paul Mackerras, stable, H. Peter Anvin, Sasha Levin,
Florian Fainelli, maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT,
Russell King, Mike Rapoport, Ingo Molnar,
open list:SYNOPSYS ARC ARCHITECTURE, Nitin Gupta,
open list:GENERIC INCLUDE/ASM HEADER FILES, Arnd Bergmann,
Thomas Gleixner, moderated list:ARM PORT, Thomas Bogendoerfer,
Greg Kroah-Hartman, Ralf Baechle, Minchan Kim, Vineet Gupta,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, Kirill A. Shutemov
In-Reply-To: <20211103205704.374734-1-f.fainelli@gmail.com>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
Stefan Agner reported a bug when using zsram on 32-bit Arm machines
with RAM above the 4GB address boundary:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = a27bd01c
[00000000] *pgd=236a0003, *pmd=1ffa64003
Internal error: Oops: 207 [#1] SMP ARM
Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
Hardware name: BCM2711
PC is at zs_map_object+0x94/0x338
LR is at zram_bvec_rw.constprop.0+0x330/0xa64
pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
sp : e376bbe0 ip : 00000000 fp : c1e2921c
r10: 00000002 r9 : c1dda730 r8 : 00000000
r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 30c5383d Table: 235c2a80 DAC: fffffffd
Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
Stack: (0xe376bbe0 to 0xe376c000)
As it turns out, zsram needs to know the maximum memory size, which
is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
The same problem will be hit on all 32-bit architectures that have a
physical address space larger than 4GB and happen to not enable sparsemem
and include asm/sparsemem.h from asm/pgtable.h.
After the initial discussion, I suggested just always defining
MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
set, or provoking a build error otherwise. This addresses all
configurations that can currently have this runtime bug, but
leaves all other configurations unchanged.
I looked up the possible number of bits in source code and
datasheets, here is what I found:
- on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
- on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
support more than 32 bits, even though supersections in theory allow
up to 40 bits as well.
- on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
XPA supports up to 60 bits in theory, but 40 bits are more than
anyone will ever ship
- On PowerPC, there are three different implementations of 36 bit
addressing, but 32-bit is used without CONFIG_PTE_64BIT
- On RISC-V, the normal page table format can support 34 bit
addressing. There is no highmem support on RISC-V, so anything
above 2GB is unused, but it might be useful to eventually support
CONFIG_ZRAM for high pages.
Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[florian: patch arch/powerpc/include/asm/pte-common.h for 4.14.y
removed arch/riscv/include/asm/pgtable.h which does not exist]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arc/include/asm/pgtable.h | 2 ++
arch/arm/include/asm/pgtable-2level.h | 2 ++
arch/arm/include/asm/pgtable-3level.h | 2 ++
arch/mips/include/asm/pgtable-32.h | 3 +++
arch/powerpc/include/asm/pte-common.h | 2 ++
include/asm-generic/pgtable.h | 13 +++++++++++++
6 files changed, 24 insertions(+)
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 77676e18da69..a31ae69da639 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -138,8 +138,10 @@
#ifdef CONFIG_ARC_HAS_PAE40
#define PTE_BITS_NON_RWX_IN_PD1 (0xff00000000 | PAGE_MASK | _PAGE_CACHEABLE)
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
#else
#define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#endif
/**************************************************************************
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index 92fd2c8a9af0..6154902bed83 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -78,6 +78,8 @@
#define PTE_HWTABLE_OFF (PTE_HWTABLE_PTRS * sizeof(pte_t))
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u32))
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+
/*
* PMD_SHIFT determines the size of the area a second-level page table can map
* PGDIR_SHIFT determines what a third-level page table entry can map
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 2a029bceaf2f..35807e611b6e 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -37,6 +37,8 @@
#define PTE_HWTABLE_OFF (0)
#define PTE_HWTABLE_SIZE (PTRS_PER_PTE * sizeof(u64))
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
+
/*
* PGDIR_SHIFT determines the size a top-level page table entry can map.
*/
diff --git a/arch/mips/include/asm/pgtable-32.h b/arch/mips/include/asm/pgtable-32.h
index 74afe8c76bdd..215fb48f644b 100644
--- a/arch/mips/include/asm/pgtable-32.h
+++ b/arch/mips/include/asm/pgtable-32.h
@@ -111,6 +111,7 @@ static inline void pmd_clear(pmd_t *pmdp)
#if defined(CONFIG_XPA)
+#define MAX_POSSIBLE_PHYSMEM_BITS 40
#define pte_pfn(x) (((unsigned long)((x).pte_high >> _PFN_SHIFT)) | (unsigned long)((x).pte_low << _PAGE_PRESENT_SHIFT))
static inline pte_t
pfn_pte(unsigned long pfn, pgprot_t prot)
@@ -126,6 +127,7 @@ pfn_pte(unsigned long pfn, pgprot_t prot)
#elif defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32)
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
#define pte_pfn(x) ((unsigned long)((x).pte_high >> 6))
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t prot)
@@ -140,6 +142,7 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t prot)
#else
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#ifdef CONFIG_CPU_VR41XX
#define pte_pfn(x) ((unsigned long)((x).pte >> (PAGE_SHIFT + 2)))
#define pfn_pte(pfn, prot) __pte(((pfn) << (PAGE_SHIFT + 2)) | pgprot_val(prot))
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index ce142ef99ba7..18ebe9a4728e 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -102,8 +102,10 @@ static inline bool pte_user(pte_t pte)
*/
#if defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT)
#define PTE_RPN_MASK (~((1ULL<<PTE_RPN_SHIFT)-1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 36
#else
#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
#endif
/* _PAGE_CHG_MASK masks of bits that are to be preserved across
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index cdee19314061..dd65e925f7cf 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1069,6 +1069,19 @@ static inline bool arch_has_pfn_modify_check(void)
#endif /* !__ASSEMBLY__ */
+#if !defined(MAX_POSSIBLE_PHYSMEM_BITS) && !defined(CONFIG_64BIT)
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+/*
+ * ZSMALLOC needs to know the highest PFN on 32-bit architectures
+ * with physical address space extension, but falls back to
+ * BITS_PER_LONG otherwise.
+ */
+#error Missing MAX_POSSIBLE_PHYSMEM_BITS definition
+#else
+#define MAX_POSSIBLE_PHYSMEM_BITS 32
+#endif
+#endif
+
#ifndef has_transparent_hugepage
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define has_transparent_hugepage() 1
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox