* Re: Looking for architecture papers
From: Segher Boessenkool @ 2018-09-30 8:56 UTC (permalink / raw)
To: Raz; +Cc: linuxppc-dev
In-Reply-To: <CAPB=Z-ojoLwhNWhE6agindvF_41gQYdjZkvquGBF86FYju37vA@mail.gmail.com>
On Sun, Sep 30, 2018 at 10:05:01AM +0300, Raz wrote:
> First, thank you.
> And another question, is there a development environment that
> resembles Fixed Virtual Platform for ARM ( FVP ARM) ?
I don't know FVP, but that seems similar to systemsim?
https://www14.software.ibm.com/webapp/set2/sas/f/pwrfs/home.html
(p8 version)
https://www14.software.ibm.com/webapp/set2/sas/f/pwrfs/pwr9/home.html
(p9 version)
Segher
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
From: Nicholas Piggin @ 2018-09-30 23:27 UTC (permalink / raw)
To: Bin Meng, Nicholas Piggin, Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <1538288720-14910-2-git-send-email-bmeng.cn@gmail.com>
On Sat, 29 Sep 2018 23:25:20 -0700
Bin Meng <bmeng.cn@gmail.com> wrote:
> commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit
> userspace to 512 bytes") only changes stack userspace redzone size.
> We need increase the kernel one to 512 bytes too per ABIv2 spec.
You're right we need 512 to be compatible with ABIv2, but as the
comment says, gcc limits this to 288 bytes so that's what is used
to save stack space. We can use a compiler version test to change
this if llvm or a new version of gcc does something different.
Thanks,
Nick
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> arch/powerpc/include/asm/ptrace.h | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 447cbd1..817be3f 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -30,16 +30,12 @@
> #ifdef __powerpc64__
>
> /*
> - * Size of redzone that userspace is allowed to use below the stack
> + * Size of redzone that kernel/userspace is allowed to use below the stack
> * pointer. This is 288 in the 64-bit big-endian ELF ABI, and 512 in
> * the new ELFv2 little-endian ABI, so we allow the larger amount.
> - *
> - * For kernel code we allow a 288-byte redzone, in order to conserve
> - * kernel stack space; gcc currently only uses 288 bytes, and will
> - * hopefully allow explicit control of the redzone size in future.
> */
> #define USER_REDZONE_SIZE 512
> -#define KERNEL_REDZONE_SIZE 288
> +#define KERNEL_REDZONE_SIZE 512
>
> #define STACK_FRAME_OVERHEAD 112 /* size of minimum stack frame */
> #define STACK_FRAME_LR_SAVE 2 /* Location of LR in stack frame */
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace
From: Breno Leitao @ 2018-09-30 23:51 UTC (permalink / raw)
To: Michael Neuling, linuxppc-dev; +Cc: ldufour, gromero
In-Reply-To: <ceb1c2179b62ff0d418c727d9f016bb854578252.camel@neuling.org>
Hi Mikey,
On 09/28/2018 02:36 AM, Michael Neuling wrote:
>>>> + WARN_ON(MSR_TM_SUSPENDED(mfmsr())); + + tm_enable(); +
>>>> tm_save_sprs(&(tsk->thread));
>>>
>>> Do we need to check if TM was enabled in the task before saving the
>>> TM SPRs?
>>>
>>> What happens if TM was lazily off and hence we had someone else's TM
>>> SPRs in the CPU currently? Wouldn't this flush the wrong values to
>>> the task_struct?
>>>
>>> I think we need to check the processes MSR before doing this.
>>
>> Yes, it is a *very* good point, and I think we are vulnerable even
>> before this patch (in the current kernel). Take a look above, we are
>> calling tm_save_sprs() if MSR is not TM suspended independently if TM
>> is lazily off.
>
> I think you're right, we might already have an issue. There are some
> paths in here that don't check the userspace msr or any of the lazy tm
> enable. :(
I was able to create a test case that reproduces this bug cleanly.
The testcase basically sleeps for N cycles, and then segfaults.
If N is high enough to have load_tm overflowed, then you see a corrupted
TEXASR value in the core dump file. If load_tm != 0 during the coredump, you
see the expected TEXASR value.
I wrote a small bash that check for both cases.
$ git clone https://github.com/leitao/texasr_corrupt.git
$ make check
Anyway, I will propose a fix for this problem soon, since this whole patchset
may delay to get ready. Is it OK?
Thank you
^ permalink raw reply
* Re: [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace
From: Michael Neuling @ 2018-10-01 0:34 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: ldufour, gromero
In-Reply-To: <64e4d511-bfe6-fe37-1145-eed90939d079@debian.org>
On Sun, 2018-09-30 at 20:51 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/28/2018 02:36 AM, Michael Neuling wrote:
> > > > > + WARN_ON(MSR_TM_SUSPENDED(mfmsr())); + + tm_enable(); +
> > > > > tm_save_sprs(&(tsk->thread));
> > > >
> > > > Do we need to check if TM was enabled in the task before saving the
> > > > TM SPRs?
> > > >
> > > > What happens if TM was lazily off and hence we had someone else's TM
> > > > SPRs in the CPU currently? Wouldn't this flush the wrong values to
> > > > the task_struct?
> > > >
> > > > I think we need to check the processes MSR before doing this.
> > >
> > > Yes, it is a *very* good point, and I think we are vulnerable even
> > > before this patch (in the current kernel). Take a look above, we are
> > > calling tm_save_sprs() if MSR is not TM suspended independently if TM
> > > is lazily off.
> >
> > I think you're right, we might already have an issue. There are some
> > paths in here that don't check the userspace msr or any of the lazy tm
> > enable. :(
>
> I was able to create a test case that reproduces this bug cleanly.
>
> The testcase basically sleeps for N cycles, and then segfaults.
>
> If N is high enough to have load_tm overflowed, then you see a corrupted
> TEXASR value in the core dump file. If load_tm != 0 during the coredump, you
> see the expected TEXASR value.
>
> I wrote a small bash that check for both cases.
>
> $ git clone https://github.com/leitao/texasr_corrupt.git
> $ make check
>
> Anyway, I will propose a fix for this problem soon, since this whole patchset
> may delay to get ready. Is it OK?
Yeah, best to get a fix for this one out soon.
Mikey
^ permalink raw reply
* [PATCH AUTOSEL 4.18 47/65] sched/topology: Set correct NUMA topology type
From: Sasha Levin @ 2018-10-01 0:38 UTC (permalink / raw)
To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Srikar Dronamraju, Rik van Riel, Peter Zijlstra, Mel Gorman,
Heiko Carstens, linuxppc-dev, Sasha Levin, Suravee Suthikulpanit,
Andre Wild, Thomas Gleixner, Linus Torvalds, Ingo Molnar
In-Reply-To: <20181001003754.146961-1-alexander.levin@microsoft.com>
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
[ Upstream commit e5e96fafd9028b1478b165db78c52d981c14f471 ]
With the following commit:
051f3ca02e46 ("sched/topology: Introduce NUMA identity node sched domain")
the scheduler introduced a new NUMA level. However this leads to the NUMA topology
on 2 node systems to not be marked as NUMA_DIRECT anymore.
After this commit, it gets reported as NUMA_BACKPLANE, because
sched_domains_numa_level is now 2 on 2 node systems.
Fix this by allowing setting systems that have up to 2 NUMA levels as
NUMA_DIRECT.
While here remove code that assumes that level can be 0.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andre Wild <wild@linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Fixes: 051f3ca02e46 "Introduce NUMA identity node sched domain"
Link: http://lkml.kernel.org/r/1533920419-17410-1-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
kernel/sched/topology.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 56a0fed30c0a..505a41c42b96 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1295,7 +1295,7 @@ static void init_numa_topology_type(void)
n = sched_max_numa_distance;
- if (sched_domains_numa_levels <= 1) {
+ if (sched_domains_numa_levels <= 2) {
sched_numa_topology_type = NUMA_DIRECT;
return;
}
@@ -1380,9 +1380,6 @@ void sched_init_numa(void)
break;
}
- if (!level)
- return;
-
/*
* 'level' contains the number of unique distances
*
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Andy Gross @ 2018-09-30 17:08 UTC (permalink / raw)
To: Rob Herring
Cc: Heiko Stuebner, linuxppc-dev, linux-kernel, Li Yang, David Brown,
Thierry Reding, Santosh Shilimkar, Jonathan Hunter, linux-soc,
linux-arm-kernel, Qiang Zhao
In-Reply-To: <20180828015252.28511-43-robh@kernel.org>
On Mon, Aug 27, 2018 at 08:52:44PM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: Li Yang <leoyang.li@nxp.com>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: David Brown <david.brown@linaro.org>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: Santosh Shilimkar <ssantosh@kernel.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-soc@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
From: Bin Meng @ 2018-10-01 1:11 UTC (permalink / raw)
To: npiggin; +Cc: linuxppc-dev
In-Reply-To: <20181001092715.0a2696bd@roar.ozlabs.ibm.com>
Hi Nick,
On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> On Sat, 29 Sep 2018 23:25:20 -0700
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit
> > userspace to 512 bytes") only changes stack userspace redzone size.
> > We need increase the kernel one to 512 bytes too per ABIv2 spec.
>
> You're right we need 512 to be compatible with ABIv2, but as the
> comment says, gcc limits this to 288 bytes so that's what is used
> to save stack space. We can use a compiler version test to change
> this if llvm or a new version of gcc does something different.
>
I believe what the comment says is for ABIv1. At the time when commit
573ebfa6601f was submitted, kernel had not switched to ABIv2 build
yet.
Regards,
Bin
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
From: Nicholas Piggin @ 2018-10-01 2:22 UTC (permalink / raw)
To: Bin Meng; +Cc: linuxppc-dev
In-Reply-To: <CAEUhbmUih9irf-A8E4rouvpWKjeqg78Vzg+xm5TzUVB_vLPr=g@mail.gmail.com>
On Mon, 1 Oct 2018 09:11:04 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Nick,
>
> On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Sat, 29 Sep 2018 23:25:20 -0700
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit
> > > userspace to 512 bytes") only changes stack userspace redzone size.
> > > We need increase the kernel one to 512 bytes too per ABIv2 spec.
> >
> > You're right we need 512 to be compatible with ABIv2, but as the
> > comment says, gcc limits this to 288 bytes so that's what is used
> > to save stack space. We can use a compiler version test to change
> > this if llvm or a new version of gcc does something different.
> >
>
> I believe what the comment says is for ABIv1. At the time when commit
> 573ebfa6601f was submitted, kernel had not switched to ABIv2 build
> yet.
I see, yes you are right about that. However gcc still seems to be using
288 bytes.
static inline bool
offset_below_red_zone_p (HOST_WIDE_INT offset)
{
return offset < (DEFAULT_ABI == ABI_V4
? 0
: TARGET_32BIT ? -220 : -288);
}
llvm does as well AFAIKS
// DarwinABI has a 224-byte red zone. PPC32 SVR4ABI(Non-DarwinABI) has no
// red zone and PPC64 SVR4ABI has a 288-byte red zone.
unsigned getRedZoneSize() const {
return isDarwinABI() ? 224 : (isPPC64() ? 288 : 0);
}
So I suspect we can get away with using 288 for the kernel. Although
the ELFv2 ABI allows 512, I suspect at this point compilers won't switch
over without an explicit red zone size flag.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
From: Masahiro Yamada @ 2018-10-01 5:49 UTC (permalink / raw)
To: Rob Herring
Cc: Linux-MIPS, linux-xtensa, Will Deacon, Max Filippov,
Paul Mackerras, Frank Rowand, Yoshinori Sato, Russell King,
Ley Foon Tan, Geert Uytterhoeven, Catalin Marinas, James Hogan,
arcml, moderated list:H8/300 ARCHITECTURE, DTML,
Linux Kbuild mailing list, linux-arm-kernel, Chris Zankel,
Michal Simek, Michal Marek, Vineet Gupta,
Linux Kernel Mailing List, Ralf Baechle, Paul Burton, nios2-dev,
linuxppc-dev
In-Reply-To: <20180928154150.GA25013@bogus>
Hi Rob,
2018年9月29日(土) 0:43 Rob Herring <robh@kernel.org>:
> +#
> ---------------------------------------------------------------------------
> +# Devicetree files
> +
> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> +dtstree := arch/$(SRCARCH)/boot/dts
> +endif
> +
> +ifneq ($(dtstree),)
> +
> +%.dtb : scripts_dtc
%.dtb: prepare3 prepare
because we need to make sure KERNELRELEASE
is correctly defined before dtbs_install happens.
> + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> +
> +PHONY += dtbs dtbs_install
> +dtbs: scripts_dtc
dtbs: prepare3 scripts_dtc
> + $(Q)$(MAKE) $(build)=$(dtstree)
> +
> +dtbs_install: dtbs
Please do not have dtbs_install to depend on dtbs.
No install targets should ever trigger building anything
in the source tree.
For the background, see the commit log of
19514fc665ffbce624785f76ee7ad0ea6378a527
> + $(Q)$(MAKE) $(dtbinst)=$(dtstree)
> +
> +ifdef CONFIG_OF_EARLY_FLATTREE
> +all: dtbs
> +endif
> +
> +endif
> +
> +PHONY += scripts_dtc
> +scripts_dtc: scripts_basic
> + $(Q)$(MAKE) $(build)=scripts/dtc
> +
> #
> ---------------------------------------------------------------------------
> # Modules
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] powerpc: remove leftover code of old GCC version checks
From: Masahiro Yamada @ 2018-10-01 6:10 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: Paul Mackerras, linux-kernel, Nicholas Piggin, Masahiro Yamada
Clean up the leftover of commit f2910f0e6835 ("powerpc: remove old
GCC version checks").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
My patch had been sent earlier, with more clean-ups:
https://lore.kernel.org/patchwork/patch/977805/
Anyway, this cleans up the left-over of the Nicholas' one.
arch/powerpc/Makefile | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 2ecd0976..b094375 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -400,10 +400,6 @@ archclean:
archprepare: checkbin
-# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
-# to stdout and these checks are run even on install targets.
-TOUT := .tmp_gas_check
-
# Check toolchain versions:
# - gcc-4.6 is the minimum kernel-wide version so nothing required.
checkbin:
@@ -414,7 +410,3 @@ checkbin:
echo -n '*** Please use a different binutils version.' ; \
false ; \
fi
-
-
-CLEAN_FILES += $(TOUT)
-
--
2.7.4
^ permalink raw reply related
* [PATCH] powerpc/nohash: fix undefined behaviour when testing page size support
From: Daniel Axtens @ 2018-10-01 6:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Daniel Axtens
When enumerating page size definitions to check hardware support,
we construct a constant which is (1U << (def->shift - 10)).
However, the array of page size definitions is only initalised for
various MMU_PAGE_* constants, so it contains a number of 0-initialised
elements with def->shift == 0. This means we end up shifting by a
very large number, which gives the following UBSan splat:
================================================================================
UBSAN: Undefined behaviour in /home/dja/dev/linux/linux/arch/powerpc/mm/tlb_nohash.c:506:21
shift exponent 4294967286 is too large for 32-bit type 'unsigned int'
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc3-00045-ga604f927b012-dirty #6
Call Trace:
[c00000000101bc20] [c000000000a13d54] .dump_stack+0xa8/0xec (unreliable)
[c00000000101bcb0] [c0000000004f20a8] .ubsan_epilogue+0x18/0x64
[c00000000101bd30] [c0000000004f2b10] .__ubsan_handle_shift_out_of_bounds+0x110/0x1a4
[c00000000101be20] [c000000000d21760] .early_init_mmu+0x1b4/0x5a0
[c00000000101bf10] [c000000000d1ba28] .early_setup+0x100/0x130
[c00000000101bf90] [c000000000000528] start_here_multiplatform+0x68/0x80
================================================================================
Fix this by first checking if the element exists (shift != 0) before
constructing the constant.
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
arch/powerpc/mm/tlb_nohash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 15fe5f0c8665..ae5d568e267f 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -503,6 +503,9 @@ static void setup_page_sizes(void)
for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) {
struct mmu_psize_def *def = &mmu_psize_defs[psize];
+ if (!def->shift)
+ continue;
+
if (tlb1ps & (1U << (def->shift - 10))) {
def->flags |= MMU_PAGE_SIZE_DIRECT;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/rtas: Fix a potential race between CPU-Offline & Migration
From: Gautham R Shenoy @ 2018-10-01 6:40 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: ego, linuxppc-dev, Tyrel Datwyler
In-Reply-To: <12262001-fd31-99f4-0eac-2f90bdf47a0c@linux.vnet.ibm.com>
On Fri, Sep 28, 2018 at 03:36:08PM -0500, Nathan Fontenot wrote:
> On 09/28/2018 02:02 AM, Gautham R Shenoy wrote:
> > Hi Nathan,
> >
> > On Thu, Sep 27, 2018 at 12:31:34PM -0500, Nathan Fontenot wrote:
> >> On 09/27/2018 11:51 AM, Gautham R. Shenoy wrote:
> >>> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >>>
> >>> Live Partition Migrations require all the present CPUs to execute the
> >>> H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
> >>> before initiating the migration for this purpose.
> >>>
> >>> The commit 85a88cabad57
> >>> ("powerpc/pseries: Disable CPU hotplug across migrations")
> >>> disables any CPU-hotplug operations once all the offline CPUs are
> >>> brought online to prevent any further state change. Once the
> >>> CPU-Hotplug operation is disabled, the code assumes that all the CPUs
> >>> are online.
> >>>
> >>> However, there is a minor window in rtas_ibm_suspend_me() between
> >>> onlining the offline CPUs and disabling CPU-Hotplug when a concurrent
> >>> CPU-offline operations initiated by the userspace can succeed thereby
> >>> nullifying the the aformentioned assumption. In this unlikely case
> >>> these offlined CPUs will not call H_JOIN, resulting in a system hang.
> >>>
> >>> Fix this by verifying that all the present CPUs are actually online
> >>> after CPU-Hotplug has been disabled, failing which we return from
> >>> rtas_ibm_suspend_me() with -EBUSY.
> >>
> >> Would we also want to havr the ability to re-try onlining all of the cpus
> >> before failing the migration?
> >
> > Given that we haven't been able to hit issue in practice after your
> > fix to disable CPU Hotplug after migrations, it indicates that the
> > race-window, if it is not merely a theoretical one, is extremely
> > narrow. So, this current patch addresses the safety aspect, as in,
> > should someone manage to exploit this narrow race-window, it ensures
> > that the system doesn't go to a hang state.
> >
> > Having the ability to retry onlining all the CPUs is only required for
> > progress of LPM in this rarest of cases. We should add the code to
> > retry onlining the CPUs if the consequence of failing an LPM is high,
> > even in this rarest of case. Otherwise IMHO we should be ok not adding
> > the additional code.
>
> I believe you're correct. One small update to the patch below...
>
> >
> >>
> >> This would involve a bigger code change as the current code to online all
> >> CPUs would work in its current form.
> >>
> >> -Nathan
> >>
> >>>
> >>> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> >>> Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> >>> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> >>> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> >>> ---
> >>> arch/powerpc/kernel/rtas.c | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> >>> index 2c7ed31..27f6fd3 100644
> >>> --- a/arch/powerpc/kernel/rtas.c
> >>> +++ b/arch/powerpc/kernel/rtas.c
> >>> @@ -982,6 +982,16 @@ int rtas_ibm_suspend_me(u64 handle)
> >>> }
> >>>
> >>> cpu_hotplug_disable();
> >>> +
> >>> + /* Check if we raced with a CPU-Offline Operation */
> >>> + if (unlikely(!cpumask_equal(cpu_present_mask, cpu_online_mask))) {
> >>> + pr_err("%s: Raced against a concurrent CPU-Offline\n",
> >>> + __func__);
> >>> + atomic_set(&data.error, -EBUSY);
> >>> + cpu_hotplug_enable();
>
> Before returning, we return all CPUs that were offline prior to the migration
> back to the offline state. We should be doing that here as well. This should
> be as simple as adding a call to rtas_offline_cpus_mask() here.
You are right. I will add the code to undo the offline and send it.
Thanks for the review!
>
> -Nathan
>
> >>> + goto out;
> >>> + }
> >>> +
> >>> stop_topology_update();
> >>>
> >>> /* Call function on all CPUs. One of us will make the
> >>>
^ permalink raw reply
* Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
From: Geert Uytterhoeven @ 2018-10-01 7:53 UTC (permalink / raw)
To: Rob Herring
Cc: Linux MIPS Mailing List, linux-xtensa, Will Deacon, Max Filippov,
Paul Mackerras, Frank Rowand, Yoshinori Sato, Russell King,
ley.foon.tan, Catalin Marinas, James Hogan, arcml,
moderated list:H8/300 ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kbuild, Linux ARM, Chris Zankel, Michal Simek, Michal Marek,
Masahiro Yamada, Vineet Gupta, Linux Kernel Mailing List,
Ralf Baechle, Paul Burton, nios2-dev, linuxppc-dev,
Andreas Färber
In-Reply-To: <CAL_JsqKLOohxGx0Je9niMQ5H3o0Y=EcMQTB6YkbV0sfUOZHu8g@mail.gmail.com>
On Fri, Sep 28, 2018 at 8:42 PM Rob Herring <robh@kernel.org> wrote:
> On Fri, Sep 28, 2018 at 12:21 PM Andreas Färber <afaerber@suse.de> wrote:
> > Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven:
> > > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
> > > <yamada.masahiro@socionext.com> wrote:
> > >> Even x86 can enable OF and OF_UNITTEST.
> > >>
> > >> Another solution might be,
> > >> guard it by 'depends on ARCH_SUPPORTS_OF'.
> > >>
> > >> This is actually what ACPI does.
> > >>
> > >> menuconfig ACPI
> > >> bool "ACPI (Advanced Configuration and Power Interface) Support"
> > >> depends on ARCH_SUPPORTS_ACPI
> > >> ...
> > >
> > > ACPI is a real platform feature, as it depends on firmware.
> > >
> > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
> > > even if it has ACPI ;-)
> >
> > How would loading a DT overlay work on an ACPI platform? I.e., what
> > would it overlay against and how to practically load such a file?
>
> The DT unittests do just that. I run them on x86 and UM builds. In
> this case, the loading source is built-in.
>
> > I wonder whether that could be helpful for USB devices and serdev...
>
> How to load the overlays is pretty orthogonal to the issues to be
> solved here. It would certainly be possible to move forward with
> prototyping this and just have the overlay built-in. It may not even
> need to be an overlay if we can support multiple root nodes.
You indeed need to refer to some anchors for most use cases, although a
simple MMIO device could just be anchored to the root node.
Topologies hanging off a USB device would be my first use case, too,
for serdev, or for e.g. the mcp2210 USB-SPI bridge.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: Michal Hocko @ 2018-10-01 8:40 UTC (permalink / raw)
To: David Hildenbrand
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Pavel Tatashin,
Paul Mackerras, H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan,
Boris Ostrovsky, linux-s390, Michael Neuling, Stephen Hemminger,
Yoshinori Sato, linux-acpi, Ingo Molnar, xen-devel, Rob Herring,
Len Brown, Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com,
Haiyang Zhang, Dan Williams, Jonathan Neuschäfer,
Nicholas Piggin, Joe Perches, Jérôme Glisse,
Mike Rapoport, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Joonsoo Kim, Oscar Salvador, Juergen Gross, Tony Luck,
Mathieu Malaterre, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <20180928150357.12942-1-david@redhat.com>
On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
[...]
I haven't read the patch itself but I just wanted to note one thing
about this part
> For paravirtualized devices it is relevant that memory is onlined as
> quickly as possible after adding - and that it is added to the NORMAL
> zone. Otherwise, it could happen that too much memory in a row is added
> (but not onlined), resulting in out-of-memory conditions due to the
> additional memory for "struct pages" and friends. MOVABLE zone as well
> as delays might be very problematic and lead to crashes (e.g. zone
> imbalance).
I have proposed (but haven't finished this due to other stuff) a
solution for this. Newly added memory can host memmaps itself and then
you do not have the problem in the first place. For vmemmap it would
have an advantage that you do not really have to beg for 2MB pages to
back the whole section but you would get it for free because the initial
part of the section is by definition properly aligned and unused.
I yet have to think about the whole proposal but I am missing the most
important part. _Who_ is going to use the new exported information and
for what purpose. You said that distributions have hard time to
distinguish different types of onlinining policies but isn't this
something that is inherently usecase specific?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
From: Segher Boessenkool @ 2018-10-01 8:51 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20181001122256.7cfdf186@roar.ozlabs.ibm.com>
Hi!
On Mon, Oct 01, 2018 at 12:22:56PM +1000, Nicholas Piggin wrote:
> On Mon, 1 Oct 2018 09:11:04 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Mon, Oct 1, 2018 at 7:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> > > On Sat, 29 Sep 2018 23:25:20 -0700
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit
> > > > userspace to 512 bytes") only changes stack userspace redzone size.
> > > > We need increase the kernel one to 512 bytes too per ABIv2 spec.
> > >
> > > You're right we need 512 to be compatible with ABIv2, but as the
> > > comment says, gcc limits this to 288 bytes so that's what is used
> > > to save stack space. We can use a compiler version test to change
> > > this if llvm or a new version of gcc does something different.
> > >
> >
> > I believe what the comment says is for ABIv1. At the time when commit
> > 573ebfa6601f was submitted, kernel had not switched to ABIv2 build
> > yet.
>
> I see, yes you are right about that. However gcc still seems to be using
> 288 bytes.
And that is required by the ABI!
"""
2.2.2.4. Protected Zone
The 288 bytes below the stack pointer are available as volatile program
storage that is not preserved across function calls. Interrupt handlers and
any other functions that might run without an explicit call must take care
to preserve a protected zone, also referred to as the red zone, of 512 bytes
that consists of:
* The 288-byte volatile program storage region that is used to hold saved
registers and local variables
* An additional 224 bytes below the volatile program storage region that is
set aside as a volatile system storage region for system functions
If a function does not call other functions and does not need more stack
space than is available in the volatile program storage region (that is, 288
bytes), it does not need to have a stack frame. The 224-byte volatile system
storage region is not available to compilers for allocation to saved
registers and local variables.
"""
A routine has a red zone of 288 bytes. Below there is 224 more bytes of
available storage, but that is not available to the routine itself: some
(asynchronous) other code (like an interrupt) can use (i.e. clobber) it.
Segher
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets
From: Segher Boessenkool @ 2018-10-01 8:59 UTC (permalink / raw)
To: Bin Meng; +Cc: linuxppc-dev
In-Reply-To: <1538288720-14910-1-git-send-email-bmeng.cn@gmail.com>
On Sat, Sep 29, 2018 at 11:25:19PM -0700, Bin Meng wrote:
> The -mabi=elfv2 is currently specified twice in the makefile. Remove
> the one that does not test compiler.
This was
ifdef CONFIG_PPC64
cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mcall-aixdesc)
aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
endif
and the later setting is
ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
else
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
endif
Maybe these two pieces should be joined completely?
Segher
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64: Increase stack redzone for 64-bit kernel to 512 bytes
From: Segher Boessenkool @ 2018-10-01 9:07 UTC (permalink / raw)
To: Bin Meng; +Cc: linuxppc-dev
In-Reply-To: <1538288720-14910-2-git-send-email-bmeng.cn@gmail.com>
On Sat, Sep 29, 2018 at 11:25:20PM -0700, Bin Meng wrote:
> /*
> - * Size of redzone that userspace is allowed to use below the stack
> + * Size of redzone that kernel/userspace is allowed to use below the stack
> * pointer. This is 288 in the 64-bit big-endian ELF ABI, and 512 in
> * the new ELFv2 little-endian ABI, so we allow the larger amount.
> - *
> - * For kernel code we allow a 288-byte redzone, in order to conserve
> - * kernel stack space; gcc currently only uses 288 bytes, and will
> - * hopefully allow explicit control of the redzone size in future.
> */
Btw: patches welcome! This will never be useful for userland code, so no
one in GCC land is looking at this (we did not even know it is wanted).
Segher
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-01 9:13 UTC (permalink / raw)
To: Dave Hansen, linux-mm
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Heiko Carstens, Pavel Tatashin, Michal Hocko, Paul Mackerras,
H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan, Boris Ostrovsky,
linux-s390, Michael Neuling, Stephen Hemminger, Yoshinori Sato,
linux-acpi, Ingo Molnar, xen-devel, Rob Herring, Len Brown,
Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com, Haiyang Zhang,
Dan Williams, Jonathan Neuschäfer, Nicholas Piggin,
Joe Perches, Jérôme Glisse, Mike Rapoport,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner, Joonsoo Kim,
Oscar Salvador, Juergen Gross, Tony Luck, Mathieu Malaterre,
Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <5dba97a5-5a18-5df1-5493-99987679cf3a@linux.intel.com>
On 28/09/2018 19:02, Dave Hansen wrote:
> It's really nice if these kinds of things are broken up. First, replace
> the old want_memblock parameter, then add the parameter to the
> __add_page() calls.
Definitely, once we agree that is is not nuts, I will split it up for
the next version :)
>
>> +/*
>> + * NONE: No memory block is to be created (e.g. device memory).
>> + * NORMAL: Memory block that represents normal (boot or hotplugged) memory
>> + * (e.g. ACPI DIMMs) that should be onlined either automatically
>> + * (memhp_auto_online) or manually by user space to select a
>> + * specific zone.
>> + * Applicable to memhp_auto_online.
>> + * STANDBY: Memory block that represents standby memory that should only
>> + * be onlined on demand by user space (e.g. standby memory on
>> + * s390x), but never automatically by the kernel.
>> + * Not applicable to memhp_auto_online.
>> + * PARAVIRT: Memory block that represents memory added by
>> + * paravirtualized mechanisms (e.g. hyper-v, xen) that will
>> + * always automatically get onlined. Memory will be unplugged
>> + * using ballooning, not by relying on the MOVABLE ZONE.
>> + * Not applicable to memhp_auto_online.
>> + */
>> +enum {
>> + MEMORY_BLOCK_NONE,
>> + MEMORY_BLOCK_NORMAL,
>> + MEMORY_BLOCK_STANDBY,
>> + MEMORY_BLOCK_PARAVIRT,
>> +};
>
> This does not seem like the best way to expose these.
>
> STANDBY, for instance, seems to be essentially a replacement for a check
> against running on s390 in userspace to implement a _typical_ s390
> policy. It seems rather weird to try to make the userspace policy
> determination easier by telling userspace about the typical s390 policy
> via the kernel.
Now comes the fun part: I am working on another paravirtualized memory
hotplug way for KVM guests, based on virtio ("virtio-mem").
These devices can potentially be used concurrently with
- s390x standby memory
- DIMMs
How should a policy in user space look like when new memory gets added
- on s390x? Not onlining paravirtualized memory is very wrong.
- on e.g. x86? Onlining memory to the MOVABLE zone is very wrong.
So the type of memory is very important here to have in user space.
Relying on checks like "isS390()", "isKVMGuest()" or "isHyperVGuest()"
to decide whether to online memory and how to online memory is wrong.
Only some specific memory types (which I call "normal") are to be
handled by user space.
For the other ones, we exactly know what to do:
- standby? don't online
- paravirt? always online to normal zone
I will add some more details as reply to Michal.
>
> As for the OOM issues, that sounds like something we need to fix by
> refusing to do (or delaying) hot-add operations once we consume too much
> ZONE_NORMAL from memmap[]s rather than trying to indirectly tell
> userspace to hurry thing along.
That is a moving target and doing that automatically is basically
impossible. You can add a lot of memory to the movable zone and
everything is fine. Suddenly a lot of processes are started - boom.
MOVABLE should only every be used if you expect an unplug. And for
paravirtualized devices, a "typical" unplug does not exist.
>
> So, to my eye, we need:
>
> +enum {
> + MEMORY_BLOCK_NONE,
> + MEMORY_BLOCK_STANDBY, /* the default */
> + MEMORY_BLOCK_AUTO_ONLINE,
> +};
auto-online is strongly misleading, that's why I called it "normal", but
I am open for suggestions. The information about devices handles fully
in the kernel - "paravirt" is key for me.
>
> and we can probably collapse NONE into AUTO_ONLINE because userspace
> ends up doing the same thing for both: nothing.
For external reasons, yes, for internal reasons no (see hmm/device
memory). In user space, we will never end up with MEMORY_BLOCK_NONE,
because there is no memory block.
>
>> struct memory_block {
>> unsigned long start_section_nr;
>> unsigned long end_section_nr;
>> @@ -34,6 +58,7 @@ struct memory_block {
>> int (*phys_callback)(struct memory_block *);
>> struct device dev;
>> int nid; /* NID for this memory block */
>> + int type; /* type of this memory block */
>> };
>
> Shouldn't we just be creating and using an actual named enum type?
>
That makes sense.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: David Hildenbrand @ 2018-10-01 9:34 UTC (permalink / raw)
To: Michal Hocko
Cc: Kate Stewart, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Dave Hansen, Heiko Carstens, linux-mm, Pavel Tatashin,
Paul Mackerras, H. Peter Anvin, Rashmica Gupta, K. Y. Srinivasan,
Boris Ostrovsky, linux-s390, Michael Neuling, Stephen Hemminger,
Yoshinori Sato, linux-acpi, Ingo Molnar, xen-devel, Rob Herring,
Len Brown, Fenghua Yu, Stephen Rothwell, mike.travis@hpe.com,
Haiyang Zhang, Dan Williams, Jonathan Neuschäfer,
Nicholas Piggin, Joe Perches, Jérôme Glisse,
Mike Rapoport, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Joonsoo Kim, Oscar Salvador, Juergen Gross, Tony Luck,
Mathieu Malaterre, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Mauricio Faria de Oliveira, Philippe Ombredanne,
Martin Schwidefsky, devel, Andrew Morton, linuxppc-dev,
Kirill A. Shutemov
In-Reply-To: <20181001084038.GD18290@dhcp22.suse.cz>
On 01/10/2018 10:40, Michal Hocko wrote:
> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> [...]
>
> I haven't read the patch itself but I just wanted to note one thing
> about this part
>
>> For paravirtualized devices it is relevant that memory is onlined as
>> quickly as possible after adding - and that it is added to the NORMAL
>> zone. Otherwise, it could happen that too much memory in a row is added
>> (but not onlined), resulting in out-of-memory conditions due to the
>> additional memory for "struct pages" and friends. MOVABLE zone as well
>> as delays might be very problematic and lead to crashes (e.g. zone
>> imbalance).
>
> I have proposed (but haven't finished this due to other stuff) a
> solution for this. Newly added memory can host memmaps itself and then
> you do not have the problem in the first place. For vmemmap it would
> have an advantage that you do not really have to beg for 2MB pages to
> back the whole section but you would get it for free because the initial
> part of the section is by definition properly aligned and unused.
So the plan is to "host metadata for new memory on the memory itself".
Just want to note that this is basically impossible for s390x with the
current mechanisms. (added memory is dead, until onlining notifies the
hypervisor and memory is allocated). It will also be problematic for
paravirtualized memory devices (e.g. XEN's "not backed by the
hypervisor" hacks).
This would only be possible for memory DIMMs, memory that is completely
accessible as far as I can see. Or at least, some specified "first part"
is accessible.
Other problems are other metadata like extended struct pages and friends.
(I really like the idea of adding memory without allocating memory in
the hypervisor in the first place, please keep me tuned).
And please note: This solves some problematic part ("adding too much
memory to the movable zone or not onlining it"), but not the issue of
zone imbalance in the first place. And not one issue I try to tackle
here: don't add paravirtualized memory to the movable zone.
>
> I yet have to think about the whole proposal but I am missing the most
> important part. _Who_ is going to use the new exported information and
> for what purpose. You said that distributions have hard time to
> distinguish different types of onlinining policies but isn't this
> something that is inherently usecase specific?
>
Let's think about a distribution. We have a clash of use cases here
(just what you describe). What I propose solves one part of it ("handle
what you know how to handle right in the kernel").
1. Users of DIMMs usually expect that they can be unplugged again. That
is why you want to control how to online memory in user space (== add it
to the movable zone).
2. Users of standby memory (s390) expect that memory will never be
onlined automatically. It will be onlined manually.
3. Users of paravirtualized devices (esp. Hyper-V) don't care about
memory unplug in the sense of MOVABLE at all. They (or Hyper-V!) will
add a whole bunch of memory and expect that everything works fine. So
that memory is onlined immediately and that memory is added to the
NORMAL zone. Users never want the MOVABLE zone.
1. is a reason why distributions usually don't configure
"MEMORY_HOTPLUG_DEFAULT_ONLINE", because you really want the option for
MOVABLE zone. That however implies, that e.g. for x86, you have to
handle all new memory in user space, especially also HyperV memory.
There, you then have to check for things like "isHyperV()" to decide
"oh, yes, this should definitely not go to the MOVABLE zone".
As you know, I am working on virtio-mem, which can basically be combined
with 1 or 2. And user space has no idea about the difference between
added memory blocks. Was it memory from a DIMM (== ZONE_MOVABLE)? Was it
memory from a paravirtualized device (== ZONE_NORMAL)? Was it standby
memory? (don't online)
That part, I try to solve with this interface.
To answer your question: User space will only care about "normal" memory
and then decide how to online it (for now, usually MOVABLE, because
that's what customers expect with DIMMs). The use case of DIMMS, we
don't know and therefore we can't expose. The use case of the other
cases, we know exactly already in the kernel.
Existing user space hacks will continue to work but can be replaces by a
new check against "normal" memory block types.
Thanks for looking into this!
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v2] powerpc/rtas: Fix a potential race between CPU-Offline & Migration
From: Gautham R. Shenoy @ 2018-10-01 10:40 UTC (permalink / raw)
To: Michael Ellerman, Nathan Fontenot, Tyrel Datwyler
Cc: Gautham R. Shenoy, linuxppc-dev
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Live Partition Migrations require all the present CPUs to execute the
H_JOIN call, and hence rtas_ibm_suspend_me() onlines any offline CPUs
before initiating the migration for this purpose.
The commit 85a88cabad57
("powerpc/pseries: Disable CPU hotplug across migrations")
disables any CPU-hotplug operations once all the offline CPUs are
brought online to prevent any further state change. Once the
CPU-Hotplug operation is disabled, the code assumes that all the CPUs
are online.
However, there is a minor window in rtas_ibm_suspend_me() between
onlining the offline CPUs and disabling CPU-Hotplug when a concurrent
CPU-offline operations initiated by the userspace can succeed thereby
nullifying the the aformentioned assumption. In this unlikely case
these offlined CPUs will not call H_JOIN, resulting in a system hang.
Fix this by verifying that all the present CPUs are actually online
after CPU-Hotplug has been disabled, failing which we restore the
state of the offline CPUs in rtas_ibm_suspend_me() and return an
-EBUSY.
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
v2: Restore the state of the offline CPUs if all CPUs aren't onlined.
arch/powerpc/kernel/rtas.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2c7ed31..d4468cb 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -982,6 +982,15 @@ int rtas_ibm_suspend_me(u64 handle)
}
cpu_hotplug_disable();
+
+ /* Check if we raced with a CPU-Offline Operation */
+ if (unlikely(!cpumask_equal(cpu_present_mask, cpu_online_mask))) {
+ pr_err("%s: Raced against a concurrent CPU-Offline\n",
+ __func__);
+ atomic_set(&data.error, -EBUSY);
+ goto out_hotplug_enable;
+ }
+
stop_topology_update();
/* Call function on all CPUs. One of us will make the
@@ -996,6 +1005,8 @@ int rtas_ibm_suspend_me(u64 handle)
printk(KERN_ERR "Error doing global join\n");
start_topology_update();
+
+out_hotplug_enable:
cpu_hotplug_enable();
/* Take down CPUs not online prior to suspend */
--
1.9.4
^ permalink raw reply related
* Re: [v4] powerpc: Avoid code patching freed init sections
From: Christophe LEROY @ 2018-10-01 11:25 UTC (permalink / raw)
To: Michael Ellerman, Michael Neuling
Cc: Michal Suchánek, linuxppc-dev, Nicholas Piggin, Haren Myneni
In-Reply-To: <42GsbJ0Knkz9sCh@ozlabs.org>
Le 21/09/2018 à 13:59, Michael Ellerman a écrit :
> On Fri, 2018-09-14 at 01:14:11 UTC, Michael Neuling wrote:
>> This stops us from doing code patching in init sections after they've
>> been freed.
>>
>> In this chain:
>> kvm_guest_init() ->
>> kvm_use_magic_page() ->
>> fault_in_pages_readable() ->
>> __get_user() ->
>> __get_user_nocheck() ->
>> barrier_nospec();
>>
>> We have a code patching location at barrier_nospec() and
>> kvm_guest_init() is an init function. This whole chain gets inlined,
>> so when we free the init section (hence kvm_guest_init()), this code
>> goes away and hence should no longer be patched.
>>
>> We seen this as userspace memory corruption when using a memory
>> checker while doing partition migration testing on powervm (this
>> starts the code patching post migration via
>> /sys/kernel/mobility/migration). In theory, it could also happen when
>> using /sys/kernel/debug/powerpc/barrier_nospec.
>>
>> cc: stable@vger.kernel.org # 4.13+
>> Signed-off-by: Michael Neuling <mikey@neuling.org>
>> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Applied to powerpc fixes, thanks.
>
> https://git.kernel.org/powerpc/c/51c3c62b58b357e8d35e4cc32f7b4e
>
This patch breaks booting on my MPC83xx board (book3s/32) very early
(before console is active), provoking restart.
u-boot reports a checkstop reset at restart.
Reverting this commit fixes the issue.
The following patch fixes the issue as well, but I think it is not the
best solution. I still think the test should be in patch_instruction()
instead of being in __patch_instruction(), see my comment on v2
Christophe
diff --git a/arch/powerpc/lib/code-patching.c
b/arch/powerpc/lib/code-patching.c
index 6ae2777..6192fda 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -29,7 +29,7 @@ static int __patch_instruction(unsigned int
*exec_addr, unsigned int instr,
int err;
/* Make sure we aren't patching a freed init section */
- if (init_mem_is_free && init_section_contains(exec_addr, 4)) {
+ if (*PTRRELOC(&init_mem_is_free) &&
init_section_contains(exec_addr, 4)) {
pr_debug("Skipping init section patching addr:
0x%px\n", exec_addr);
return 0;
}
Christophe
^ permalink raw reply related
* RE: [PATCH v3 5/6] arm64: dts: add QorIQ LX2160A SoC support
From: Vabhav Sharma @ 2018-10-01 12:19 UTC (permalink / raw)
To: Leo Li
Cc: Mark Rutland, Kate Stewart, Yogesh Narayan Gaur,
linux-kernel-owner@vger.kernel.org, Catalin Marinas,
Michael Turquette, Will Deacon, yamada.masahiro@socionext.com,
Sriram Dash, linux-clk, Udit Kumar, Russell King, Priyanka Jain,
Viresh Kumar,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-pm@vger.kernel.org, Scott Wood, Rob Herring,
Varun Sethi, Nipun Gupta,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Ramneek Mehresh, sboyd@kernel.org, Greg Kroah-Hartman, Ying Zhang,
Rafael J. Wysocki, lkml, Sudeep Holla, linuxppc-dev
In-Reply-To: <CADRPPNT7Fcv=gkN4iB+7QYUpFqi5wJWmXKRnK893eBa6GWi1dw@mail.gmail.com>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org <linux-kernel-
> owner@vger.kernel.org> On Behalf Of Li Yang
> Sent: Saturday, September 29, 2018 2:11 AM
> To: Vabhav Sharma <vabhav.sharma@nxp.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Scott Wood <oss@buserror.net>;
> lkml <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; linuxppc-dev
> <linuxppc-dev@lists.ozlabs.org>; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; Michael Turquette
> <mturquette@baylibre.com>; sboyd@kernel.org; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Viresh Kumar <viresh.kumar@linaro.org>; linux-clk <linux-
> clk@vger.kernel.org>; linux-pm@vger.kernel.org; linux-kernel-
> owner@vger.kernel.org; Catalin Marinas <catalin.marinas@arm.com>; Will
> Deacon <will.deacon@arm.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>; Kate
> Stewart <kstewart@linuxfoundation.org>; yamada.masahiro@socionext.com;
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Udit Kumar
> <udit.kumar@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Ying Zhang
> <ying.zhang22455@nxp.com>; Russell King <linux@armlinux.org.uk>; Ramneek
> Mehresh <ramneek.mehresh@nxp.com>; Varun Sethi <V.Sethi@nxp.com>;
> Nipun Gupta <nipun.gupta@nxp.com>; Sriram Dash <sriram.dash@nxp.com>
> Subject: Re: [PATCH v3 5/6] arm64: dts: add QorIQ LX2160A SoC support
>
> On Mon, Sep 24, 2018 at 7:47 AM Vabhav Sharma <vabhav.sharma@nxp.com>
> wrote:
> >
> > LX2160A SoC is based on Layerscape Chassis Generation 3.2 Architecture.
> >
> > LX2160A features an advanced 16 64-bit ARM v8 CortexA72 processor
> > cores in 8 cluster, CCN508, GICv3,two 64-bit DDR4 memory controller, 8
> > I2C controllers, 3 dspi, 2 esdhc,2 USB 3.0, mmu 500, 3 SATA, 4 PL011
> > SBSA UARTs etc.
> >
> > Signed-off-by: Ramneek Mehresh <ramneek.mehresh@nxp.com>
> > Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> > Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 693
> > +++++++++++++++++++++++++
> > 1 file changed, 693 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > new file mode 100644
> > index 0000000..46eea16
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -0,0 +1,693 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) // // Device Tree
> > +Include file for Layerscape-LX2160A family SoC.
> > +//
> > +// Copyright 2018 NXP
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
>
> You included the header file, but you didn't use the MACROs in most of the
> interrupts property below. It is recommended to use them for better readibity.
Ok, I will update it.
>
> > +
> > +/memreserve/ 0x80000000 0x00010000;
> > +
> > +/ {
> > + compatible = "fsl,lx2160a";
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + // 8 clusters having 2 Cortex-A72 cores each
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x0>;
> > + clocks = <&clockgen 1 0>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster0_l2>;
>
> enable-method is a required property for this and cpu below.
Ok
>
> > + };
> > +
> > + cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x1>;
> > + clocks = <&clockgen 1 0>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster0_l2>;
> > + };
> > +
> > + cpu@100 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x100>;
> > + clocks = <&clockgen 1 1>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster1_l2>;
> > + };
> > +
> > + cpu@101 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x101>;
> > + clocks = <&clockgen 1 1>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster1_l2>;
> > + };
> > +
> > + cpu@200 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x200>;
> > + clocks = <&clockgen 1 2>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster2_l2>;
> > + };
> > +
> > + cpu@201 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x201>;
> > + clocks = <&clockgen 1 2>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster2_l2>;
> > + };
> > +
> > + cpu@300 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x300>;
> > + clocks = <&clockgen 1 3>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster3_l2>;
> > + };
> > +
> > + cpu@301 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x301>;
> > + clocks = <&clockgen 1 3>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster3_l2>;
> > + };
> > +
> > + cpu@400 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x400>;
> > + clocks = <&clockgen 1 4>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster4_l2>;
> > + };
> > +
> > + cpu@401 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x401>;
> > + clocks = <&clockgen 1 4>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster4_l2>;
> > + };
> > +
> > + cpu@500 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x500>;
> > + clocks = <&clockgen 1 5>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster5_l2>;
> > + };
> > +
> > + cpu@501 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x501>;
> > + clocks = <&clockgen 1 5>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster5_l2>;
> > + };
> > +
> > + cpu@600 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x600>;
> > + clocks = <&clockgen 1 6>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster6_l2>;
> > + };
> > +
> > + cpu@601 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x601>;
> > + clocks = <&clockgen 1 6>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster6_l2>;
> > + };
> > +
> > + cpu@700 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x700>;
> > + clocks = <&clockgen 1 7>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster7_l2>;
> > + };
> > +
> > + cpu@701 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + reg = <0x701>;
> > + clocks = <&clockgen 1 7>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster7_l2>;
> > + };
> > +
> > + cluster0_l2: l2-cache0 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster1_l2: l2-cache1 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster2_l2: l2-cache2 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster3_l2: l2-cache3 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster4_l2: l2-cache4 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster5_l2: l2-cache5 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster6_l2: l2-cache6 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > +
> > + cluster7_l2: l2-cache7 {
> > + compatible = "cache";
> > + cache-size = <0x100000>;
> > + cache-line-size = <64>;
> > + cache-sets = <1024>;
> > + cache-level = <2>;
> > + };
> > + };
> > +
> > + gic: interrupt-controller@6000000 {
> > + compatible = "arm,gic-v3";
> > + reg = <0x0 0x06000000 0 0x10000>, // GIC Dist
> > + <0x0 0x06200000 0 0x200000>, // GICR (RD_base +
> > + // SGI_base)
> > + <0x0 0x0c0c0000 0 0x2000>, // GICC
> > + <0x0 0x0c0d0000 0 0x1000>, // GICH
> > + <0x0 0x0c0e0000 0 0x20000>; // GICV
> > + #interrupt-cells = <3>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + interrupt-controller;
> > + interrupts = <1 9 0x4>;
> > +
> > + its: gic-its@6020000 {
> > + compatible = "arm,gic-v3-its";
> > + msi-controller;
> > + reg = <0x0 0x6020000 0 0x20000>;
> > + };
> > + };
> > +
> > + rstcr: syscon@1e60000 {
> > + compatible = "syscon";
> > + reg = <0x0 0x1e60000 0x0 0x4>;
> > + };
>
> This is no use if you don't have a syscon-reboot node pointing to it.
Agree, Thanks.
>
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts = <1 13 4>,
> > + <1 14 4>,
> > + <1 11 4>,
> > + <1 10 4>;
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a72-pmu";
> > + interrupts = <1 7 0x8>; // PMU PPI, Level low type
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + memory@80000000 {
> > + // DRAM space - 1, size : 2 GB DRAM
> > + device_type = "memory";
> > + reg = <0x00000000 0x80000000 0 0x80000000>;
> > + };
> > +
> > + ddr1: memory-controller@1080000 {
> > + compatible = "fsl,qoriq-memory-controller";
> > + reg = <0x0 0x1080000 0x0 0x1000>;
> > + interrupts = <0 17 0x4>;
> > + little-endian;
> > + };
> > +
> > + ddr2: memory-controller@1090000 {
> > + compatible = "fsl,qoriq-memory-controller";
> > + reg = <0x0 0x1090000 0x0 0x1000>;
> > + interrupts = <0 18 0x4>;
> > + little-endian;
> > + };
> > +
> > + sysclk: sysclk {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <100000000>;
> > + clock-output-names = "sysclk";
> > + };
> > +
> > + soc {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + clockgen: clocking@1300000 {
> > + compatible = "fsl,lx2160a-clockgen";
>
> Also update the binding to include this new compatible.
Ok,I will update clock/qoriq-clock.txt
>
> > + reg = <0 0x1300000 0 0xa0000>;
> > + #clock-cells = <2>;
> > + clocks = <&sysclk>;
> > + };
> > +
> > + crypto: crypto@8000000 {
> > + compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
> > + fsl,sec-era = <10>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x00 0x8000000 0x100000>;
> > + reg = <0x00 0x8000000 0x0 0x100000>;
> > + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> > + dma-coherent;
> > + status = "disabled";
> > +
> > + sec_jr0: jr@10000 {
> > + compatible = "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg = <0x10000 0x10000>;
> > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + sec_jr1: jr@20000 {
> > + compatible = "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg = <0x20000 0x10000>;
> > + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + sec_jr2: jr@30000 {
> > + compatible = "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg = <0x30000 0x10000>;
> > + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + sec_jr3: jr@40000 {
> > + compatible = "fsl,sec-v5.0-job-ring",
> > + "fsl,sec-v4.0-job-ring";
> > + reg = <0x40000 0x10000>;
> > + interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > + };
> > +
> > + dcfg: dcfg@1e00000 {
> > + compatible = "fsl,lx2160a-dcfg", "syscon";
>
> Update the binding to include this new compatible.
Sure, I will update arm/fsl.txt
>
> > + reg = <0x0 0x1e00000 0x0 0x10000>;
> > + little-endian;
> > + };
> > +
> > + gpio0: gpio@2300000 {
> > + compatible = "fsl,qoriq-gpio";
> > + reg = <0x0 0x2300000 0x0 0x10000>;
> > + interrupts = <0 36 0x4>; // Level high type
> > + gpio-controller;
> > + little-endian;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > +
> > + gpio1: gpio@2310000 {
> > + compatible = "fsl,qoriq-gpio";
> > + reg = <0x0 0x2310000 0x0 0x10000>;
> > + interrupts = <0 36 0x4>; // Level high type
> > + gpio-controller;
> > + little-endian;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > +
> > + gpio2: gpio@2320000 {
> > + compatible = "fsl,qoriq-gpio";
> > + reg = <0x0 0x2320000 0x0 0x10000>;
> > + interrupts = <0 37 0x4>; // Level high type
> > + gpio-controller;
> > + little-endian;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > +
> > + gpio3: gpio@2330000 {
> > + compatible = "fsl,qoriq-gpio";
> > + reg = <0x0 0x2330000 0x0 0x10000>;
> > + interrupts = <0 37 0x4>; // Level high type
> > + gpio-controller;
> > + little-endian;
> > + #gpio-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > +
> > +
>
> One new line is enough.
Ok
>
> > + i2c0: i2c@2000000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2000000 0x0 0x10000>;
> > + interrupts = <0 34 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + fsl-scl-gpio = <&gpio2 15 0>;
> > + status = "disabled";
> > + };
> > +
> > + i2c1: i2c@2010000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2010000 0x0 0x10000>;
> > + interrupts = <0 34 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + i2c2: i2c@2020000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2020000 0x0 0x10000>;
> > + interrupts = <0 35 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + i2c3: i2c@2030000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2030000 0x0 0x10000>;
> > + interrupts = <0 35 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + i2c4: i2c@2040000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2040000 0x0 0x10000>;
> > + interrupts = <0 74 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + fsl-scl-gpio = <&gpio2 16 0>;
> > + status = "disabled";
> > + };
> > +
> > + i2c5: i2c@2050000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2050000 0x0 0x10000>;
> > + interrupts = <0 74 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + i2c6: i2c@2060000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2060000 0x0 0x10000>;
> > + interrupts = <0 75 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + i2c7: i2c@2070000 {
> > + compatible = "fsl,vf610-i2c";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x0 0x2070000 0x0 0x10000>;
> > + interrupts = <0 75 0x4>; // Level high type
> > + clock-names = "i2c";
> > + clocks = <&clockgen 4 7>;
> > + status = "disabled";
> > + };
> > +
> > + uart0: serial@21c0000 {
> > + device_type = "serial";
> > + compatible = "arm,pl011","arm,sbsa-uart";
>
> From the sbsa_uart binding:
> This UART uses a subset of the PL011 registers and consequently lives in the
> PL011 driver. It's baudrate and other communication parameters cannot be
> adjusted at runtime, so it lacks a clock specifier here.
>
> So it is a more specific variant of pl011. Put the sbsa-uart compatible first.
Ok.
>
> > + reg = <0x0 0x21c0000 0x0 0x1000>;
> > + interrupts = <0 32 0x4>; // Level high type
> > + current-speed = <115200>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@21d0000 {
> > + device_type = "serial";
> > + compatible = "arm,pl011","arm,sbsa-uart";
> > + reg = <0x0 0x21d0000 0x0 0x1000>;
> > + interrupts = <0 33 0x4>; // Level high type
> > + current-speed = <115200>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@21e0000 {
> > + device_type = "serial";
> > + compatible = "arm,pl011","arm,sbsa-uart";
> > + reg = <0x0 0x21e0000 0x0 0x1000>;
> > + interrupts = <0 72 0x4>; // Level high type
> > + current-speed = <115200>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@21f0000 {
> > + device_type = "serial";
> > + compatible = "arm,pl011","arm,sbsa-uart";
> > + reg = <0x0 0x21f0000 0x0 0x1000>;
> > + interrupts = <0 73 0x4>; // Level high type
> > + current-speed = <115200>;
> > + status = "disabled";
> > + };
> > +
> > + smmu: iommu@5000000 {
> > + compatible = "arm,mmu-500";
> > + reg = <0 0x5000000 0 0x800000>;
> > + #iommu-cells = <1>;
> > + #global-interrupts = <14>;
> > + interrupts = <0 13 4>, // global secure fault
> > + <0 14 4>, // combined secure interrupt
> > + <0 15 4>, // global non-secure fault
> > + <0 16 4>, // combined non-secure interrupt
> > + // performance counter interrupts 0-9
> > + <0 211 4>, <0 212 4>,
> > + <0 213 4>, <0 214 4>,
> > + <0 215 4>, <0 216 4>,
> > + <0 217 4>, <0 218 4>,
> > + <0 219 4>, <0 220 4>,
> > + // per context interrupt, 64 interrupts
> > + <0 146 4>, <0 147 4>,
> > + <0 148 4>, <0 149 4>,
> > + <0 150 4>, <0 151 4>,
> > + <0 152 4>, <0 153 4>,
> > + <0 154 4>, <0 155 4>,
> > + <0 156 4>, <0 157 4>,
> > + <0 158 4>, <0 159 4>,
> > + <0 160 4>, <0 161 4>,
> > + <0 162 4>, <0 163 4>,
> > + <0 164 4>, <0 165 4>,
> > + <0 166 4>, <0 167 4>,
> > + <0 168 4>, <0 169 4>,
> > + <0 170 4>, <0 171 4>,
> > + <0 172 4>, <0 173 4>,
> > + <0 174 4>, <0 175 4>,
> > + <0 176 4>, <0 177 4>,
> > + <0 178 4>, <0 179 4>,
> > + <0 180 4>, <0 181 4>,
> > + <0 182 4>, <0 183 4>,
> > + <0 184 4>, <0 185 4>,
> > + <0 186 4>, <0 187 4>,
> > + <0 188 4>, <0 189 4>,
> > + <0 190 4>, <0 191 4>,
> > + <0 192 4>, <0 193 4>,
> > + <0 194 4>, <0 195 4>,
> > + <0 196 4>, <0 197 4>,
> > + <0 198 4>, <0 199 4>,
> > + <0 200 4>, <0 201 4>,
> > + <0 202 4>, <0 203 4>,
> > + <0 204 4>, <0 205 4>,
> > + <0 206 4>, <0 207 4>,
> > + <0 208 4>, <0 209 4>;
> > + dma-coherent;
> > + };
> > +
> > + usb0: usb3@3100000 {
> > + compatible = "snps,dwc3";
> > + reg = <0x0 0x3100000 0x0 0x10000>;
> > + interrupts = <0 80 0x4>; // Level high type
> > + dr_mode = "host";
> > + snps,quirk-frame-length-adjustment = <0x20>;
> > + snps,dis_rxdet_inp3_quirk;
> > + status = "disabled";
> > + };
> > +
> > + usb1: usb3@3110000 {
> > + compatible = "snps,dwc3";
> > + reg = <0x0 0x3110000 0x0 0x10000>;
> > + interrupts = <0 81 0x4>; // Level high type
> > + dr_mode = "host";
> > + snps,quirk-frame-length-adjustment = <0x20>;
> > + snps,dis_rxdet_inp3_quirk;
> > + status = "disabled";
> > + };
> > +
> > + watchdog@23a0000 {
> > + compatible = "arm,sbsa-gwdt";
> > + reg = <0x0 0x23a0000 0 0x1000>,
> > + <0x0 0x2390000 0 0x1000>;
> > + interrupts = <0 59 4>;
> > + timeout-sec = <30>;
> > + };
> > +
>
> No new line is needed here.
Ok
>
> > + };
> > +};
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64: Remove duplicated -mabi=elfv2 for little endian targets
From: Bin Meng @ 2018-10-01 12:19 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev
In-Reply-To: <20181001085915.GC23155@gate.crashing.org>
On Mon, Oct 1, 2018 at 4:59 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sat, Sep 29, 2018 at 11:25:19PM -0700, Bin Meng wrote:
> > The -mabi=elfv2 is currently specified twice in the makefile. Remove
> > the one that does not test compiler.
>
> This was
>
> ifdef CONFIG_PPC64
> cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
> cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mcall-aixdesc)
> aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
> aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
> endif
>
> and the later setting is
>
> ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
> else
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
> endif
>
> Maybe these two pieces should be joined completely?
>
Ah, yes! I was only looking at elfv2 stuff before :)
Regards,
Bin
^ permalink raw reply
* [PATCH] powerpc/lib: fix book3s/32 boot failure due to code patching
From: Christophe Leroy @ 2018-10-01 12:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Michael Neuling
Cc: linuxppc-dev, linux-kernel
Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init
sections") accesses 'init_mem_is_free' flag too early, before the
kernel is relocated. This provokes early boot failure (before the
console is active).
As it is not necessary to do this verification that early, this
patch moves the test into patch_instruction() instead of
__patch_instruction().
This modification also has the advantage of avoiding unnecessary
remappings.
Fixes: 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/lib/code-patching.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 6ae2777c220d..5ffee298745f 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -28,12 +28,6 @@ static int __patch_instruction(unsigned int *exec_addr, unsigned int instr,
{
int err;
- /* Make sure we aren't patching a freed init section */
- if (init_mem_is_free && init_section_contains(exec_addr, 4)) {
- pr_debug("Skipping init section patching addr: 0x%px\n", exec_addr);
- return 0;
- }
-
__put_user_size(instr, patch_addr, 4, err);
if (err)
return err;
@@ -148,7 +142,7 @@ static inline int unmap_patch_area(unsigned long addr)
return 0;
}
-int patch_instruction(unsigned int *addr, unsigned int instr)
+static int do_patch_instruction(unsigned int *addr, unsigned int instr)
{
int err;
unsigned int *patch_addr = NULL;
@@ -188,12 +182,22 @@ int patch_instruction(unsigned int *addr, unsigned int instr)
}
#else /* !CONFIG_STRICT_KERNEL_RWX */
-int patch_instruction(unsigned int *addr, unsigned int instr)
+static int do_patch_instruction(unsigned int *addr, unsigned int instr)
{
return raw_patch_instruction(addr, instr);
}
#endif /* CONFIG_STRICT_KERNEL_RWX */
+
+int patch_instruction(unsigned int *addr, unsigned int instr)
+{
+ /* Make sure we aren't patching a freed init section */
+ if (init_mem_is_free && init_section_contains(addr, 4)) {
+ pr_debug("Skipping init section patching addr: 0x%px\n", addr);
+ return 0;
+ }
+ return do_patch_instruction(addr, instr);
+}
NOKPROBE_SYMBOL(patch_instruction);
int patch_branch(unsigned int *addr, unsigned long target, int flags)
--
2.13.3
^ permalink raw reply related
* RE: [PATCH v3 6/6] arm64: dts: add LX2160ARDB board support
From: Vabhav Sharma @ 2018-10-01 12:26 UTC (permalink / raw)
To: Leo Li
Cc: Mark Rutland, Kate Stewart, linux-kernel-owner@vger.kernel.org,
Catalin Marinas, Michael Turquette, Will Deacon,
yamada.masahiro@socionext.com, Sriram Dash, linux-clk, Udit Kumar,
Russell King, Priyanka Jain, Viresh Kumar,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-pm@vger.kernel.org, Scott Wood, Rob Herring,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
sboyd@kernel.org, Greg Kroah-Hartman, Rafael J. Wysocki, lkml,
Sudeep Holla, linuxppc-dev
In-Reply-To: <CADRPPNS1Zj=47M-yOBAJ=X=sjjxmh0k7tNcj1A8uY=cPM398tQ@mail.gmail.com>
> -----Original Message-----
> From: devicetree-owner@vger.kernel.org <devicetree-owner@vger.kernel.org>
> On Behalf Of Li Yang
> Sent: Saturday, September 29, 2018 1:07 AM
> To: Vabhav Sharma <vabhav.sharma@nxp.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Scott Wood <oss@buserror.net>;
> lkml <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; linuxppc-dev
> <linuxppc-dev@lists.ozlabs.org>; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; Michael Turquette
> <mturquette@baylibre.com>; sboyd@kernel.org; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Viresh Kumar <viresh.kumar@linaro.org>; linux-clk <linux-
> clk@vger.kernel.org>; linux-pm@vger.kernel.org; linux-kernel-
> owner@vger.kernel.org; Catalin Marinas <catalin.marinas@arm.com>; Will
> Deacon <will.deacon@arm.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>; Kate
> Stewart <kstewart@linuxfoundation.org>; yamada.masahiro@socionext.com;
> Udit Kumar <udit.kumar@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>;
> Russell King <linux@armlinux.org.uk>; Varun Sethi <V.Sethi@nxp.com>; Sriram
> Dash <sriram.dash@nxp.com>
> Subject: Re: [PATCH v3 6/6] arm64: dts: add LX2160ARDB board support
>
> On Mon, Sep 24, 2018 at 7:51 AM Vabhav Sharma <vabhav.sharma@nxp.com>
> wrote:
> >
> > LX2160A reference design board (RDB) is a high-performance computing,
> > evaluation, and development platform with LX2160A SoC.
>
> Please send next version with Shawn Guo and me in the "to" recipient so that its
> less likely we will miss it.
My mistake, Not Sure how it's missed.
>
> >
> > Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> > Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> > Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 88
> > +++++++++++++++++++++++
> > 2 files changed, 89 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index 86e18ad..445b72b 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -13,3 +13,4 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-
> rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > new file mode 100644
> > index 0000000..1bbe663
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> > @@ -0,0 +1,88 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) // // Device Tree file
> > +for LX2160ARDB // // Copyright 2018 NXP
> > +
> > +/dts-v1/;
> > +
> > +#include "fsl-lx2160a.dtsi"
> > +
> > +/ {
> > + model = "NXP Layerscape LX2160ARDB";
> > + compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +};
> > +
> > +&uart0 {
> > + status = "okay";
> > +};
> > +
> > +&uart1 {
> > + status = "okay";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > + i2c-mux@77 {
> > + compatible = "nxp,pca9547";
> > + reg = <0x77>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + i2c@2 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x2>;
> > +
> > + power-monitor@40 {
> > + compatible = "ti,ina220";
> > + reg = <0x40>;
> > + shunt-resistor = <1000>;
> > + };
> > + };
> > +
> > + i2c@3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x3>;
> > +
> > + temperature-sensor@4c {
> > + compatible = "nxp,sa56004";
> > + reg = <0x4c>;
>
> Need a vcc-supply property according to the binding.
Ok
>
> > + };
> > +
> > + temperature-sensor@4d {
> > + compatible = "nxp,sa56004";
> > + reg = <0x4d>;
>
> Ditto.
Ok
>
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c4 {
> > + status = "okay";
> > +
> > + rtc@51 {
> > + compatible = "nxp,pcf2129";
> > + reg = <0x51>;
> > + // IRQ10_B
> > + interrupts = <0 150 0x4>;
> > + };
> > +
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > +
> > +&crypto {
> > + status = "okay";
> > +};
> > --
> > 2.7.4
> >
^ 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