* Re: [PATCH resend] powerpc/64s: fix page table fragment refcount race vs speculative references
From: Nicholas Piggin @ 2018-08-01 2:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Matthew Wilcox, linux-mm, Linus Torvalds, Andrew Morton,
linuxppc-dev, Aneesh Kumar K . V
In-Reply-To: <87600vhbs1.fsf@concordia.ellerman.id.au>
On Tue, 31 Jul 2018 21:42:22 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
> > On Fri, 27 Jul 2018 08:38:35 -0700
> > Matthew Wilcox <willy@infradead.org> wrote:
> >> On Sat, Jul 28, 2018 at 12:29:06AM +1000, Nicholas Piggin wrote:
> >> > On Fri, 27 Jul 2018 06:41:56 -0700
> >> > Matthew Wilcox <willy@infradead.org> wrote:
> >> > > On Fri, Jul 27, 2018 at 09:48:17PM +1000, Nicholas Piggin wrote:
> >> > > > The page table fragment allocator uses the main page refcount racily
> >> > > > with respect to speculative references. A customer observed a BUG due
> >> > > > to page table page refcount underflow in the fragment allocator. This
> >> > > > can be caused by the fragment allocator set_page_count stomping on a
> >> > > > speculative reference, and then the speculative failure handler
> >> > > > decrements the new reference, and the underflow eventually pops when
> >> > > > the page tables are freed.
> >> > >
> >> > > Oof. Can't you fix this instead by using page_ref_add() instead of
> >> > > set_page_count()?
> >> >
> >> > It's ugly doing it that way. The problem is we have a page table
> >> > destructor and that would be missed if the spec ref was the last
> >> > put. In practice with RCU page table freeing maybe you can say
> >> > there will be no spec ref there (unless something changes), but
> >> > still it just seems much simpler doing this and avoiding any
> >> > complexity or relying on other synchronization.
> >>
> >> I don't want to rely on the speculative reference not happening by the
> >> time the page table is torn down; that's way too black-magic for me.
> >> Another possibility would be to use, say, the top 16 bits of the
> >> atomic for your counter and call the dtor once the atomic is below 64k.
> >> I'm also thinking about overhauling the dtor system so it's not tied to
> >> compound pages; anyone with a bit in page_type would be able to use it.
> >> That way you'd always get your dtor called, even if the speculative
> >> reference was the last one.
> >
> > Yeah we could look at doing either of those if necessary.
> >
> >> > > > Any objection to the struct page change to grab the arch specific
> >> > > > page table page word for powerpc to use? If not, then this should
> >> > > > go via powerpc tree because it's inconsequential for core mm.
> >> > >
> >> > > I want (eventually) to get to the point where every struct page carries
> >> > > a pointer to the struct mm that it belongs to. It's good for debugging
> >> > > as well as handling memory errors in page tables.
> >> >
> >> > That doesn't seem like it should be a problem, there's some spare
> >> > words there for arch independent users.
> >>
> >> Could you take one of the spare words instead then? My intent was to
> >> just take the 'x86 pgds only' comment off that member. _pt_pad_2 looks
> >> ideal because it'll be initialised to 0 and you'll return it to 0 by
> >> the time you're done.
> >
> > It doesn't matter for powerpc where the atomic_t goes, so I'm fine with
> > moving it. But could you juggle the fields with your patch instead? I
> > thought it would be nice to using this field that has been already
> > tested on x86 not to overlap with any other data for
> > bug fix that'll have to be widely backported.
>
> Can we come to a conclusion on this one?
>
> As far as backporting goes pt_mm is new in 4.18-rc so the patch will
> need to be manually backported anyway. But I agree with Nick we'd rather
> use a slot that is known to be free for arch use.
Let's go with that for now. I'd really rather not fix this obscure
bug by introducing something even worse. I'll volunteer to change
the powerpc page table cache code if we can't find any more space in
the struct page.
So what does mapping get used for by page table pages? 4c21e2f2441
("[PATCH] mm: split page table lock") adds that page->mapping = NULL
in pte_lock_deinit, but I don't see why because page->mapping is
never used anywhere else by that patch. Maybe a previous version
of that patch used mapping rather than private?
Thanks,
Nick
^ permalink raw reply
* RE: [PATCH 3/3] ptp_qoriq: convert to use module parameters for initialization
From: Y.b. Lu @ 2018-08-01 4:36 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180730143043.qu66ttzwyjbw6si7@localhost>
Hi Richard,
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, July 30, 2018 10:31 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3] ptp_qoriq: convert to use module parameters for
> initialization
>=20
> On Mon, Jul 30, 2018 at 06:01:54PM +0800, Yangbo Lu wrote:
> > The ptp_qoriq driver initialized the 1588 timer with the
> > configurations provided by the properties of device tree node. For
> > example,
> >
> > fsl,tclk-period =3D <5>;
> > fsl,tmr-prsc =3D <2>;
> > fsl,tmr-add =3D <0xaaaaaaab>;
> > fsl,tmr-fiper1 =3D <999999995>;
> > fsl,tmr-fiper2 =3D <99990>;
> > fsl,max-adj =3D <499999999>;
> >
> > These things actually were runtime configurations which were not
> > proper to be put into dts.
>=20
> That is debatable. While I agree that the dts isn't ideal for these, sti=
ll it is the
> lesser of two or more evils.
[Y.b. Lu] Ok. You're right indeed :)
>=20
> > This patch is to convert
> > to use module parameters for 1588 timer initialization, and to support
> > initial register values calculation.
>=20
> It is hard for me to understand how using module parameters improves the
> situation.
[Y.b. Lu] Actually I'm not sure whether module_param will be accepted to re=
place dts.
I thought the most possibility would be rejection before sending them out.
Just want suggestion and confirmation whether there is better idea than dts=
from your comments.
Since we should keep the dts, I will drop the module_param.
Could I add a function to calculate a set of default register values to ini=
tialize ptp timer when dts method failed to get required properties in driv=
er?
I think this will be useful. The ptp timer on new platforms (you may see tw=
o dts patches in this patchset. Many platforms will be affected.) will work=
without these dts properties. If user want specific setting, they can set =
dts properties.
>=20
> > If the parameters are not provided, the driver will calculate register
> > values with a set of default parameters. With this patch, those dts
> > properties are no longer needed for new platform to support 1588
> > timer, and many QorIQ DPAA platforms (some P series and T series
> > platforms of PowerPC, and some LS series platforms of ARM64) could use
> > this driver for their fman ptp timer with default module parameters.
> > However, this patch didn't remove the dts method. Because there were
> > still many old platforms using the dts method. We need to clean up
> > their dts files, verify module parameters on them, and convert them to
> > the new method gradually in case of breaking any function.
>=20
> In addition, like it or not, because the dts is an ABI, you must continue=
support
> of the dts values as a legacy option.
[Y.b. Lu] I get your point now. The dts should be kept :)
>=20
> Thanks,
> Richard
^ permalink raw reply
* RE: [PATCH 3/3] ptp_qoriq: convert to use module parameters for initialization
From: Y.b. Lu @ 2018-08-01 4:38 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur,
richardcochran@gmail.com, robh+dt@kernel.org, shawnguo@kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180730.092545.225621578249887012.davem@davemloft.net>
Hi David,
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, July 31, 2018 12:26 AM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; richardcochran@gmail.com; robh+dt@kernel.org;
> shawnguo@kernel.org; devicetree@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3] ptp_qoriq: convert to use module parameters for
> initialization
>=20
> From: Yangbo Lu <yangbo.lu@nxp.com>
> Date: Mon, 30 Jul 2018 18:01:54 +0800
>=20
> > +static unsigned int cksel =3D DEFAULT_CKSEL; module_param(cksel, uint,
> > +0644); MODULE_PARM_DESC(cksel, "Select reference clock");
> > +
> > +static unsigned int clk_src;
> > +module_param(clk_src, uint, 0644);
> > +MODULE_PARM_DESC(clk_src, "Reference clock frequency (if clocks
> > +property not provided in dts)");
> > +
> > +static unsigned int tmr_prsc =3D 2;
> > +module_param(tmr_prsc, uint, 0644);
> > +MODULE_PARM_DESC(tmr_prsc, "Output clock division/prescale factor");
> > +
> > +static unsigned int tmr_fiper1 =3D 1000000000; module_param(tmr_fiper1=
,
> > +uint, 0644); MODULE_PARM_DESC(tmr_fiper1, "Desired fixed interval
> > +pulse period (ns)");
> > +
> > +static unsigned int tmr_fiper2 =3D 100000; module_param(tmr_fiper2,
> > +uint, 0644); MODULE_PARM_DESC(tmr_fiper2, "Desired fixed interval
> > +pulse period (ns)");
>=20
> Sorry, there is no way I am every applying something like this. Module
> parameters are to be avoided at all costs.
>=20
> And you don't need it here, you have DTS, please use it.
>=20
> You are required to support the existing DTS cases, in order to avoid bre=
aking
> things, anyways.
[Y.b. Lu] I get your point. Will drop module_param method.
Thanks a lot for your suggestion.
^ permalink raw reply
* Re: [v4,01/11] macintosh/via-pmu: Fix section mismatch warning
From: Michael Ellerman @ 2018-08-01 5:23 UTC (permalink / raw)
To: Finn Thain, Benjamin Herrenschmidt
Cc: Michael Schmitz, linux-m68k, linuxppc-dev, linux-kernel
In-Reply-To: <720e9899186bed184fb9b5cce070e2dc519f9665.1530519301.git.fthain@telegraphics.com.au>
On Mon, 2018-07-02 at 08:21:18 UTC, Finn Thain wrote:
> The pmu_init() function has the __init qualifier, but the ops struct
> that holds a pointer to it does not. This causes a build warning.
> The driver works fine because the pointer is only dereferenced early.
>
> The function is so small that there's negligible benefit from using
> the __init qualifier. Remove it to fix the warning, consistent with
> the other ADB drivers.
>
> Tested-by: Stan Johnson <userm57@yahoo.com>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/73f4447d43484224d7abfba0d9468d
cheers
^ permalink raw reply
* Re: [v4, 1/2] powernv/cpuidle: Parse dt idle properties into global structure
From: Michael Ellerman @ 2018-08-01 5:23 UTC (permalink / raw)
To: Akshay Adiga, linux-kernel, linuxppc-dev, linux-pm
Cc: stewart, ego, rjw, npiggin, Akshay Adiga
In-Reply-To: <20180705114022.19285-2-akshay.adiga@linux.vnet.ibm.com>
On Thu, 2018-07-05 at 11:40:21 UTC, Akshay Adiga wrote:
> Device-tree parsing happens twice, once while deciding idle state to be
> used for hotplug and once during cpuidle init. Hence, parsing the device
> tree and caching it will reduce code duplication. Parsing code has been
> moved to pnv_parse_cpuidle_dt() from pnv_probe_idle_states(). In addition
> to the properties in the device tree the number of available states is
> also required.
>
> Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c7b185ab2fe313b4426bf55da3624
cheers
^ permalink raw reply
* Re: [v3,01/16] powerpc: remove kdump.h from page.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7df5e140a48f60c74374fe77841ad1f3eaf3f594.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:24:51 UTC, Christophe Leroy wrote:
> page.h doesn't need kdump.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/db0a2b633da4216b767d7aed95ffe3
cheers
^ permalink raw reply
* Re: [v3, 02/16] powerpc: remove unneeded inclusions of cpu_has_feature.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f3abb67da795471b235206cfd242c17e856f5b33.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:24:53 UTC, Christophe Leroy wrote:
> Files not using cpu_has_feature() don't need cpu_has_feature.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8c58259bba43084eb5876aeefa574e
cheers
^ permalink raw reply
* Re: [v3,03/16] powerpc/405: move PPC405_ERR77 in asm-405.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a22c869eab31ae38320f2e803833b0708b147d7c.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:24:55 UTC, Christophe Leroy wrote:
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/36a7eeaff7d06cef253c8df6dfe363
cheers
^ permalink raw reply
* Re: [v3, 04/16] powerpc: move ASM_CONST and stringify_in_c() into asm-const.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6a49b03f64750a8308be1465efdc89be9179b608.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:24:57 UTC, Christophe Leroy wrote:
> This patch moves ASM_CONST() and stringify_in_c() into
> dedicated asm-const.h, then cleans all related inclusions.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ec0c464cdbf38bf6ddabec8bfa595b
cheers
^ permalink raw reply
* Re: [v3,05/16] powerpc: clean the inclusion of stringify.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <06d84e9997dddcb1a89fcf443dedf7b5e37f1077.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:24:59 UTC, Christophe Leroy wrote:
> Only include linux/stringify.h is files using __stringify()
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/5c35a02c545a7bbe77f3a1ae337d9e
cheers
^ permalink raw reply
* Re: [v3,06/16] powerpc: clean inclusions of asm/feature-fixups.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6ee3e95be4abc5ed842d3b4bd5d0fedc8fc208ea.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:01 UTC, Christophe Leroy wrote:
> files not using feature fixup don't need asm/feature-fixups.h
> files using feature fixup need asm/feature-fixups.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2c86cd188f8a5631f3d75a1dea14d2
cheers
^ permalink raw reply
* Re: [v3,07/16] powerpc: remove superflous inclusions of asm/fixmap.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <54806495e0f666b3f748e57fabfc91ee268bcbaa.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:03 UTC, Christophe Leroy wrote:
> Files not using fixmap consts or functions don't need asm/fixmap.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e8cb7a55eb8dcf65838d0911dc7ba0
cheers
^ permalink raw reply
* Re: [v3,08/16] powerpc: declare set_breakpoint() static
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <918a4533548b1f2b5ffc16c05cac1c6b0a808142.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:05 UTC, Christophe Leroy wrote:
> set_breakpoint() is only used in process.c so make it static
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b5ac51d747122f8858bdcb3fc7a5c7
cheers
^ permalink raw reply
* Re: [v3,09/16] powerpc/book3s: Remove PPC_PIN_SIZE
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b4b056df7ebb29c1757785baabaec7c1dd71cae8.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:07 UTC, Christophe Leroy wrote:
> PPC_PIN_SIZE is specific to the 44x and is defined in mmu.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6b622669119e20a53a1983cd41115e
cheers
^ permalink raw reply
* Re: [v3,10/16] powerpc: fix includes in asm/processor.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <974766be9a476b4e8cbf5702af7575961c468e64.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:09 UTC, Christophe Leroy wrote:
> Remove superflous includes and add missing ones
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/62b8426578c414c918468ab4cc7517
cheers
^ permalink raw reply
* Re: [v3, 11/16] powerpc/nohash: fix hash related comments in pgtable.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a8fa6d397c3a4c45ba5663ee7048fb3fafebd92a.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:11 UTC, Christophe Leroy wrote:
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0c295d0e9c9f7a592f230bbcf51655
cheers
^ permalink raw reply
* Re: [v3,12/16] powerpc/44x: remove page.h from mmu-44x.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <820e0ab274673d336c49ea47273aae18e5723af5.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:13 UTC, Christophe Leroy wrote:
> mmu-44x.h doesn't need asm/page.h if PAGE_SHIFT are replaced by CONFIG_PPC_XX_PAGES
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7bc396958cafba126078ad92480a42
cheers
^ permalink raw reply
* Re: [v3, 15/16] powerpc: remove unnecessary inclusion of asm/tlbflush.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2940336694008357af53e183791f1d7abff4d757.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:19 UTC, Christophe Leroy wrote:
> asm/tlbflush.h is only needed for:
> - using functions xxx_flush_tlb_xxx()
> - using MMU_NO_CONTEXT
> - including asm-generic/pgtable.h
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/45ef5992e06dcc3a4c7d34d2305228
cheers
^ permalink raw reply
* Re: [v3,16/16] powerpc: split asm/tlbflush.h
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <050c24f2b82d2dcf0007398ec69b7f0b073c3188.1530807556.git.christophe.leroy@c-s.fr>
On Thu, 2018-07-05 at 16:25:21 UTC, Christophe Leroy wrote:
> Split asm/tlbflush.h into:
> asm/nohash/tlbflush.h
> asm/book3s/32/tlbflush.h
> asm/book3s/64/tlbflush.h (already existing)
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/405cb4024e52b137685213b377ea3f
cheers
^ permalink raw reply
* Re: powerpc/mm: Don't report PUDs as memory leaks when using kmemleak
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: pmenzel, aneesh.kumar
In-Reply-To: <20180719143316.23486-1-mpe@ellerman.id.au>
On Thu, 2018-07-19 at 14:33:16 UTC, Michael Ellerman wrote:
> Paul Menzel reported that kmemleak was producing reports such as:
>
> unreferenced object 0xc0000000f8b80000 (size 16384):
> comm "init", pid 1, jiffies 4294937416 (age 312.240s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000d997deb7>] __pud_alloc+0x80/0x190
> [<0000000087f2e8a3>] move_page_tables+0xbac/0xdc0
> [<00000000091e51c2>] shift_arg_pages+0xc0/0x210
> [<00000000ab88670c>] setup_arg_pages+0x22c/0x2a0
> [<0000000060871529>] load_elf_binary+0x41c/0x1648
> [<00000000ecd9d2d4>] search_binary_handler.part.11+0xbc/0x280
> [<0000000034e0cdd7>] __do_execve_file.isra.13+0x73c/0x940
> [<000000005f953a6e>] sys_execve+0x58/0x70
> [<000000009700a858>] system_call+0x5c/0x70
>
> Indicating that a PUD was being leaked.
>
> However what's really happening is that kmemleak is not able to
> recognise the references from the PGD to the PUD, because they are not
> fully qualified pointers.
>
> We can confirm that in xmon, eg:
>
> Find the task struct for pid 1 "init":
> 0:mon> P
> task_struct ->thread.ksp PID PPID S P CMD
> c0000001fe7c0000 c0000001fe803960 1 0 S 13 systemd
>
> Dump virtual address 0 to find the PGD:
> 0:mon> dv 0 c0000001fe7c0000
> pgd @ 0xc0000000f8b01000
>
> Dump the memory of the PGD:
> 0:mon> d c0000000f8b01000
> c0000000f8b01000 00000000f8b90000 0000000000000000 |................|
> c0000000f8b01010 0000000000000000 0000000000000000 |................|
> c0000000f8b01020 0000000000000000 0000000000000000 |................|
> c0000000f8b01030 0000000000000000 00000000f8b80000 |................|
> ^^^^^^^^^^^^^^^^
>
> There we can see the reference to our supposedly leaked PUD. But
> because it's missing the leading 0xc, kmemleak won't recognise it.
>
> We can confirm it's still in use by translating an address that is
> mapped via it:
> 0:mon> dv 7fff94000000 c0000001fe7c0000
> pgd @ 0xc0000000f8b01000
> pgdp @ 0xc0000000f8b01038 = 0x00000000f8b80000 <--
> pudp @ 0xc0000000f8b81ff8 = 0x00000000037c4000
> pmdp @ 0xc0000000037c5ca0 = 0x00000000fbd89000
> ptep @ 0xc0000000fbd89000 = 0xc0800001d5ce0386
> Maps physical address = 0x00000001d5ce0000
> Flags = Accessed Dirty Read Write
>
> The fix is fairly simple. We need to tell kmemleak to ignore PUD
> allocations and never report them as leaks. We can also tell it not to
> scan the PGD, because it will never find pointers in there. However it
> will still notice if we allocate a PGD and then leak it.
>
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> on IBM S822LC
Applied to powerpc next.
https://git.kernel.org/powerpc/c/a984506c542e26b31cbb446438f843
cheers
^ permalink raw reply
* Re: [v8, 1/2] powernv:opal-sensor-groups: Add support to enable sensor groups
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Shilpasri G Bhat, linux
Cc: linux-hwmon, ego, Shilpasri G Bhat, linux-kernel, stewart,
linuxppc-dev
In-Reply-To: <1532423589-18730-2-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
On Tue, 2018-07-24 at 09:13:08 UTC, Shilpasri G Bhat wrote:
> Adds support to enable/disable a sensor group at runtime. This
> can be used to select the sensor groups that needs to be copied to
> main memory by OCC. Sensor groups like power, temperature, current,
> voltage, frequency, utilization can be enabled/disabled at runtime.
>
> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/04baaf28f40c68c35a413cd9d0db71
cheers
^ permalink raw reply
* Re: Adds __init annotation at mmu_init_secondary func
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Alexey Spirkov, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org
Cc: andrew@ncrmnt.org, trivial@kernel.org
In-Reply-To: <AM5PR03MB28499BE4A0B6200F7DA83835C92B0@AM5PR03MB2849.eurprd03.prod.outlook.com>
On Thu, 2018-07-26 at 12:52:50 UTC, Alexey Spirkov wrote:
> mmu_init_secondary function called at initialization sequence
> but it misses __init annotation. As result modpost warning is generated.
> Some building systems sensitive to such kind of warnings.
>
> Signed-off-by: Alexey Spirkov <alexeis@astrosoft.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f7e2a152231f4a0308cc8f9c2296ba
cheers
^ permalink raw reply
* Re: [v3,1/1] powerpc/pseries: fix EEH recovery of some IOV devices
From: Michael Ellerman @ 2018-08-01 5:24 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev, linux-pci; +Cc: bhelgaas, bryantly
In-Reply-To: <e63eb03c87a1a54257aa2bcc384cf07761824a7e.1532915951.git.sbobroff@linux.ibm.com>
On Mon, 2018-07-30 at 01:59:14 UTC, Sam Bobroff wrote:
> EEH recovery currently fails on pSeries for some IOV capable PCI
> devices, if CONFIG_PCI_IOV is on and the hypervisor doesn't provide
> certain device tree properties for the device. (Found on an IOV
> capable device using the ipr driver.)
>
> Recovery fails in pci_enable_resources() at the check on r->parent,
> because r->flags is set and r->parent is not. This state is due to
> sriov_init() setting the start, end and flags members of the IOV BARs
> but the parent not being set later in
> pseries_pci_fixup_iov_resources(), because the
> "ibm,open-sriov-vf-bar-info" property is missing.
>
> Correct this by zeroing the resource flags for IOV BARs when they
> can't be configured (this is the same method used by sriov_init() and
> __pci_read_base()).
>
> VFs cleared this way can't be enabled later, because that requires
> another device tree property, "ibm,number-of-configurable-vfs" as well
> as support for the RTAS function "ibm_map_pes". These are all part of
> hypervisor support for IOV and it seems unlikely that a hypervisor
> would ever partially, but not fully, support it. (None are currently
> provided by QEMU/KVM.)
>
> Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
> Reviewed-by: Bryant G. Ly <bryantly@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b87b9cf4935325c98522823caeddd3
cheers
^ permalink raw reply
* [PATCH] powernv: opal-sensor-groups: Add attributes to disable/enable sensors
From: Shilpasri G Bhat @ 2018-08-01 5:41 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, linux-kernel, ego, Shilpasri G Bhat
This patch provides support to disable and enable plaform specific
sensor groups like performance, utilization and frequency which are
currently not supported in hwmon.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
---
This patch is based on
https://git.kernel.org/powerpc/c/04baaf28f40c68c35a413cd9d0db71
.../ABI/testing/sysfs-firmware-opal-sensor-groups | 33 ++++++++
.../powerpc/platforms/powernv/opal-sensor-groups.c | 99 +++++++++++++++-------
2 files changed, 100 insertions(+), 32 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
new file mode 100644
index 0000000..a236686
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
@@ -0,0 +1,33 @@
+What: /sys/firmware/opal/sensor_groups
+Date: August 2017
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sensor groups directory for POWER9 powernv servers
+
+ Each folder in this directory contains a sensor group
+ which are classified based on type of the sensor
+ like power, temperature, frequency, current, etc. They
+ can also indicate the group of sensors belonging to
+ different owners like CSM, Profiler, Job-Scheduler
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
+Date: August 2017
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to clear the min-max of all the sensors
+ belonging to the group.
+
+ Writing 1 to this file will clear the minimum and
+ maximum values of all the sensors in the group.
+ In POWER9, the min-max of a sensor is the historical minimum
+ and maximum value of the sensor cached by OCC.
+
+What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/enable
+Date: August 2018
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Sysfs file to enable/disable the sensor-group
+
+ Writing 0 to this file will disable all the sensors
+ belonging to the group and writing 1 will enable the
+ sensors.
+ In POWER9, by default all the sensor-groups are enabled and
+ will be copied to main memory by OCC. This file can be used
+ to increase the update frequency of selective sensor-groups.
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index f7d04b6..8bf6c86 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -24,6 +24,8 @@
struct sg_attr {
u32 handle;
struct kobj_attribute attr;
+ u32 opal_no;
+ bool enable;
};
static struct sensor_group {
@@ -60,34 +62,17 @@ int sensor_group_enable(u32 handle, bool enable)
}
EXPORT_SYMBOL_GPL(sensor_group_enable);
-static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static int sensor_group_clear(u32 handle)
{
- struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
struct opal_msg msg;
- u32 data;
- int ret, token;
-
- ret = kstrtoint(buf, 0, &data);
- if (ret)
- return ret;
-
- if (data != 1)
- return -EINVAL;
+ int token, ret;
token = opal_async_get_token_interruptible();
- if (token < 0) {
- pr_devel("Failed to get token\n");
+ if (token < 0)
return token;
- }
-
- ret = mutex_lock_interruptible(&sg_mutex);
- if (ret)
- goto out_token;
- ret = opal_sensor_group_clear(sattr->handle, token);
- switch (ret) {
- case OPAL_ASYNC_COMPLETION:
+ ret = opal_sensor_group_clear(handle, token);
+ if (ret == OPAL_ASYNC_COMPLETION) {
ret = opal_async_wait_response(token, &msg);
if (ret) {
pr_devel("Failed to wait for the async response\n");
@@ -95,20 +80,57 @@ static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
goto out;
}
ret = opal_error_code(opal_get_async_rc(msg));
- if (!ret)
- ret = count;
+ } else {
+ ret = opal_error_code(ret);
+ }
+
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+
+static ssize_t sgroup_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+
+ return sprintf(buf, "%u\n", sattr->enable);
+}
+
+static ssize_t sgroup_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+ bool data;
+ int ret;
+
+ ret = kstrtobool(buf, &data);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(&sg_mutex);
+ if (ret)
+ return ret;
+
+ ret = -EINVAL;
+ switch (sattr->opal_no) {
+ case OPAL_SENSOR_GROUP_CLEAR:
+ if (data)
+ ret = sensor_group_clear(sattr->handle);
break;
- case OPAL_SUCCESS:
- ret = count;
+ case OPAL_SENSOR_GROUP_ENABLE:
+ ret = sensor_group_enable(sattr->handle, data);
+ if (!ret)
+ sattr->enable = data;
break;
default:
- ret = opal_error_code(ret);
+ break;
}
-out:
+ if (!ret)
+ ret = count;
+
mutex_unlock(&sg_mutex);
-out_token:
- opal_async_release_token(token);
return ret;
}
@@ -117,17 +139,25 @@ static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *attr_name;
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
+ ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf);
} ops_info[] = {
- { OPAL_SENSOR_GROUP_CLEAR, "clear", sg_store },
+ { OPAL_SENSOR_GROUP_CLEAR, "clear", sgroup_store, NULL},
+ { OPAL_SENSOR_GROUP_ENABLE, "enable", sgroup_store, sgroup_show},
};
static void add_attr(int handle, struct sg_attr *attr, int index)
{
attr->handle = handle;
+ attr->opal_no = ops_info[index].opal_no;
sysfs_attr_init(&attr->attr.attr);
attr->attr.attr.name = ops_info[index].attr_name;
- attr->attr.attr.mode = 0220;
+ if (ops_info[index].show)
+ attr->attr.attr.mode = 0664;
+ else
+ attr->attr.attr.mode = 0220;
attr->attr.store = ops_info[index].store;
+ attr->attr.show = ops_info[index].show;
}
static int add_attr_group(const __be32 *ops, int len, struct sensor_group *sg,
@@ -142,6 +172,7 @@ static int add_attr_group(const __be32 *ops, int len, struct sensor_group *sg,
add_attr(handle, &sg->sgattrs[count], j);
sg->sg.attrs[count] =
&sg->sgattrs[count].attr.attr;
+ sg->sgattrs[count].enable = true;
count++;
}
@@ -186,6 +217,10 @@ void __init opal_sensor_groups_init(void)
const __be32 *ops;
u32 sgid, len, nr_attrs, chipid;
+ /* Skip sensor groups that are handled in HWMON */
+ if (of_device_is_compatible(node, "ibm,opal-sensor"))
+ continue;
+
ops = of_get_property(node, "ops", &len);
if (!ops)
continue;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v5 5/7] powerpc/pseries: flush SLB contents on SLB MCE errors.
From: Nicholas Piggin @ 2018-08-01 5:49 UTC (permalink / raw)
To: Michal Suchánek
Cc: Mahesh J Salgaonkar, Aneesh Kumar K.V, Laurent Dufour,
linuxppc-dev
In-Reply-To: <20180712154113.46845936@kitsune.suse.cz>
On Thu, 12 Jul 2018 15:41:13 +0200
Michal Such=C3=A1nek <msuchanek@suse.de> wrote:
> On Tue, 3 Jul 2018 08:08:14 +1000
> "Nicholas Piggin" <npiggin@gmail.com> wrote:
>=20
> > On Mon, 02 Jul 2018 11:17:06 +0530
> > Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> > =20
> > > From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> > >=20
> > > On pseries, as of today system crashes if we get a machine check
> > > exceptions due to SLB errors. These are soft errors and can be
> > > fixed by flushing the SLBs so the kernel can continue to function
> > > instead of system crash. We do this in real mode before turning on
> > > MMU. Otherwise we would run into nested machine checks. This patch
> > > now fetches the rtas error log in real mode and flushes the SLBs on
> > > SLB errors.
> > >=20
> > > Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> > > ---
> > > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1=20
> > > arch/powerpc/include/asm/machdep.h | 1=20
> > > arch/powerpc/kernel/exceptions-64s.S | 42
> > > +++++++++++++++++++++ arch/powerpc/kernel/mce.c
> > > | 16 +++++++- arch/powerpc/mm/slb.c |
> > > 6 +++ arch/powerpc/platforms/powernv/opal.c | 1=20
> > > arch/powerpc/platforms/pseries/pseries.h | 1=20
> > > arch/powerpc/platforms/pseries/ras.c | 51
> > > +++++++++++++++++++++++++
> > > arch/powerpc/platforms/pseries/setup.c | 1 9 files
> > > changed, 116 insertions(+), 4 deletions(-) =20
> >=20
> > =20
> > > +TRAMP_REAL_BEGIN(machine_check_pSeries_early)
> > > +BEGIN_FTR_SECTION
> > > + EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)
> > > + mr r10,r1 /* Save r1 */
> > > + ld r1,PACAMCEMERGSP(r13) /* Use MC emergency
> > > stack */
> > > + subi r1,r1,INT_FRAME_SIZE /* alloc stack
> > > frame */
> > > + mfspr r11,SPRN_SRR0 /* Save SRR0 */
> > > + mfspr r12,SPRN_SRR1 /* Save SRR1 */
> > > + EXCEPTION_PROLOG_COMMON_1()
> > > + EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
> > > + EXCEPTION_PROLOG_COMMON_3(0x200)
> > > + addi r3,r1,STACK_FRAME_OVERHEAD
> > > + BRANCH_LINK_TO_FAR(machine_check_early) /* Function call
> > > ABI */ =20
> >=20
> > Is there any reason you can't use the existing
> > machine_check_powernv_early code to do all this?
> > =20
> > > diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> > > index efdd16a79075..221271c96a57 100644
> > > --- a/arch/powerpc/kernel/mce.c
> > > +++ b/arch/powerpc/kernel/mce.c
> > > @@ -488,9 +488,21 @@ long machine_check_early(struct pt_regs *regs)
> > > {
> > > long handled =3D 0;
> > > =20
> > > - __this_cpu_inc(irq_stat.mce_exceptions);
> > > + /*
> > > + * For pSeries we count mce when we go into virtual mode
> > > machine
> > > + * check handler. Hence skip it. Also, We can't access per
> > > cpu
> > > + * variables in real mode for LPAR.
> > > + */
> > > + if (early_cpu_has_feature(CPU_FTR_HVMODE))
> > > + __this_cpu_inc(irq_stat.mce_exceptions);
> > > =20
> > > - if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> > > + /*
> > > + * See if platform is capable of handling machine check.
> > > + * Otherwise fallthrough and allow CPU to handle this
> > > machine check.
> > > + */
> > > + if (ppc_md.machine_check_early)
> > > + handled =3D ppc_md.machine_check_early(regs);
> > > + else if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> > > handled =3D
> > > cur_cpu_spec->machine_check_early(regs); =20
> >=20
> > Would be good to add a powernv ppc_md handler which does the
> > cur_cpu_spec->machine_check_early() call now that other platforms are
> > calling this code. Because those aren't valid as a fallback call, but
> > specific to powernv.
> > =20
>=20
> Something like this (untested)?
Sorry, some emails fell through the cracks. Yes exactly like this would
be good. If you can add a quick changelog and SOB, and
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Thanks,
Nick
>=20
> Subject: [PATCH] powerpc/powernv: define platform MCE handler.
>=20
> ---
> arch/powerpc/kernel/mce.c | 3 ---
> arch/powerpc/platforms/powernv/setup.c | 11 +++++++++++
> 2 files changed, 11 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index 221271c96a57..ae17d8aa60c4 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -498,12 +498,9 @@ long machine_check_early(struct pt_regs *regs)
> =20
> /*
> * See if platform is capable of handling machine check.
> - * Otherwise fallthrough and allow CPU to handle this machine check.
> */
> if (ppc_md.machine_check_early)
> handled =3D ppc_md.machine_check_early(regs);
> - else if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> - handled =3D cur_cpu_spec->machine_check_early(regs);
> return handled;
> }
> =20
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platfo=
rms/powernv/setup.c
> index f96df0a25d05..b74c93bc2e55 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -431,6 +431,16 @@ static unsigned long pnv_get_proc_freq(unsigned int =
cpu)
> return ret_freq;
> }
> =20
> +static long pnv_machine_check_early(struct pt_regs *regs)
> +{
> + long handled =3D 0;
> +
> + if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> + handled =3D cur_cpu_spec->machine_check_early(regs);
> +
> + return handled;
> +}
> +
> define_machine(powernv) {
> .name =3D "PowerNV",
> .probe =3D pnv_probe,
> @@ -442,6 +452,7 @@ define_machine(powernv) {
> .machine_shutdown =3D pnv_shutdown,
> .power_save =3D NULL,
> .calibrate_decr =3D generic_calibrate_decr,
> + .machine_check_early =3D pnv_machine_check_early,
> #ifdef CONFIG_KEXEC_CORE
> .kexec_cpu_down =3D pnv_kexec_cpu_down,
> #endif
^ permalink raw reply
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