On Thu, Jan 20, 2022 at 9:02 PM Arnd Bergmann wrote:
>
> On Thu, Jan 20, 2022 at 8:38 AM wrote:
> >
> > From: Guo Ren
> >
> > There are 7 64bit architectures that support Linux COMPAT mode to
> > run 32bit applications. A lot of definitions are duplicate:
> > - COMPAT_USER_HZ
> > -
On Fri, Jan 28, 2022 at 10:57 AM Lu Baolu wrote:
>
> On 1/27/22 7:14 PM, Kai-Heng Feng wrote:
> > On Thu, Jan 27, 2022 at 3:01 PM Lu Baolu wrote:
> >>
> >> On 2022/1/27 10:54, Kai-Heng Feng wrote:
> >>> Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> >>> hint") enables
On 1/27/22 7:14 PM, Kai-Heng Feng wrote:
On Thu, Jan 27, 2022 at 3:01 PM Lu Baolu wrote:
On 2022/1/27 10:54, Kai-Heng Feng wrote:
Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
hint") enables ACS, and some platforms lose its NVMe after resume from
S3:
[ 50.947816]
defconfig
arm randconfig-c002-20220127
arm randconfig-c002-20220124
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k
Hi Mark,
Mark Rutland writes:
> * I intermittently see a hang when running the tests. I previously hit that
> when originally trying to bisect this issue (and IIRC that bisected down to
> some RCU changes, but I need to re-run that). When the tests hang I
> magic-srsrq + L tells me:
>
>
I just made the huge mistake of hibernating and resuming, I'm going trough
the process of rescue and all, thankfully I had a 2016 cd in the drive.
I'll read up once the sheer panic settles.
-Michael
On Wed, Jan 26, 2022, 21:22 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
>
Hello Michał,
09.01.2022 02:35, Michał Mirosław пишет:
> BTW, I couldn't find a right description of my idea of unifying the
> chains before, so let me sketch it now.
>
> The idea is to have a single system-off chain in which the callback
> gets a mode ({QUERY_*, PREP_*, DO_*} for each of
Mark Rutland writes:
> On Thu, Jan 27, 2022 at 07:46:01AM -0500, Steven Rostedt wrote:
>> On Thu, 27 Jan 2022 12:27:04 +
>> Mark Rutland wrote:
>>
>> > Ah, so those non-ELF relocations for the mcount_loc table just mean "apply
>> > the
>> > KASLR offset here", which is equivalent for all
Mark Rutland writes:
>> Isn't x86 relocatable in some configurations (e.g. for KASLR)?
>>
>> I can't see how the sort works for those cases, because the mcount_loc
>> entries
>> are absolute, and either:
>>
>> * The sorted entries will get overwritten by the unsorted relocation entries,
>>
From f7d4ef4e77464e08af38789ea5d3a9cfb80a3d78 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Google)"
Date: Tue, 25 Jan 2022 09:19:10 -0500
Subject: [PATCH] ftrace: Have architectures opt-in for mcount build time
sorting
First S390 complained that the sorting of the mcount sections at build
On Thu, Jan 27, 2022 at 11:42:49AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> First S390 complained that the sorting of the mcount sections at build
> time caused the kernel to crash on their architecture. Now PowerPC is
> complaining about it too. And also ARM64 appears
Le 27/01/2022 à 17:05, Miroslav Benes a écrit :
>> @@ -195,6 +208,9 @@ static void mod_tree_remove(struct module *mod)
>> {
>> __mod_tree_remove(>core_layout.mtn, _tree);
>> mod_tree_remove_init(mod);
>> +#ifdef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
>> +
There is already a global of_root reference. Use that instead of getting
one on our own. We don't need to care about the reference count either
this way.
Signed-off-by: Michael Walle
---
drivers/soc/fsl/guts.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
This driver cannot be unloaded and it will be needed very early in the
boot process because other driver (weakly) depend on it (eg. for chip
errata handling). Drop all the platform driver and devres stuff and
simply make it a core_initcall.
Signed-off-by: Michael Walle
---
This driver will never be unloaded. Firstly, it is not available as a
module, but more importantly, other drivers will depend on this one to
apply possible chip errata.
Signed-off-by: Michael Walle
---
drivers/soc/fsl/guts.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
Most layerscapes provide a security fuse processor where the vendor
will store a unique id per part. Unfortunately, we cannot use the
corresponding efuse driver because this driver needs to be ready
early during the boot phase. To get the unique identifier, we just
need to access two registers.
Move the reading of the SVR into the probe function as
fsl_guts_get_svr() is the only user of the static guts variable and this
lets us drop that as well as the malloc() for this variable. Also, we
can unmap the memory region after we accessed it, which will simplify
error handling later.
This is the last global static variable. Drop it and allocate the memory
on the heap instead.
Signed-off-by: Michael Walle
---
drivers/soc/fsl/guts.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/soc/fsl/guts.c
If both the model and the compatible properties are missing, then
machine will not be set. Initialize it with NULL.
Fixes: 34c1c21e94ac ("soc: fsl: fix section mismatch build warnings")
Signed-off-by: Michael Walle
---
drivers/soc/fsl/guts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This series converts the guts driver from a platform driver to just an
core_initcall. The driver itself cannot (or rather should never) be
unloaded because others depends on detecting the current SoC revision
to apply chip errata. Other SoC drivers do it the same way. Overall I
got rid of all the
From: "Steven Rostedt (Google)"
First S390 complained that the sorting of the mcount sections at build
time caused the kernel to crash on their architecture. Now PowerPC is
complaining about it too. And also ARM64 appears to be having issues.
It may be necessary to also update the relocation
On Thu, Jan 27, 2022 at 11:46:49AM +, Mark Rutland wrote:
> I'm not sure how x86 works here; AFAICT the relocations are performed during
> decompression, but it looks like there's some special build-time processing
> associated with that, and the vmlinux doesn't contain standard ELF
>
> @@ -195,6 +208,9 @@ static void mod_tree_remove(struct module *mod)
> {
> __mod_tree_remove(>core_layout.mtn, _tree);
> mod_tree_remove_init(mod);
> +#ifdef CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC
> + __mod_tree_remove(>core_layout.mtn, _data_tree);
s/core_layout/data_layout/
On Thu, 27 Jan 2022 at 15:55, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 02:59:31PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 14:24, Mark Rutland wrote:
> > >
> > > On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> > > > I suppose that on arm64, we can work
On Thu, Jan 27, 2022 at 08:55:43AM -0500, Steven Rostedt wrote:
> On Thu, 27 Jan 2022 13:33:02 +
> Mark Rutland wrote:
>
> > I want to get the regression fixed ASAP, so can we take a simple patch for
> > -rc2
> > which disables the build-time sort where it's currently broken (by limiting
>
On Thu, Jan 27, 2022 at 02:59:31PM +0100, Ard Biesheuvel wrote:
> On Thu, 27 Jan 2022 at 14:24, Mark Rutland wrote:
> >
> > On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> > > I suppose that on arm64, we can work around this by passing
> > > --apply-dynamic-relocs to the linker,
Hi Nicholas,
On Thu, Jan 27, 2022 at 8:47 AM Nicholas Piggin wrote:
>
> That sounds like my fault actually.
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239178.html
Thanks for the reference & fix! I confirm it works in our CI too.
Closing the QEMU issue then.
Cheers,
Hi Michael,
On Thu, Jan 27, 2022 at 11:54 AM Michael Ellerman wrote:
>
> It looks like your kernel-ppc64le-release.config does not have the
> hardlockup detector enabled, so I suspect you're hitting the bug
> described in that patch.
On -release it was a hang; but please note that on -debug the
On Thu, 27 Jan 2022 at 14:24, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 13:59, Mark Rutland wrote:
> > >
> > > On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> > > > On Thu, 27 Jan 2022 at 13:20, Mark
On Thu, 27 Jan 2022 13:33:02 +
Mark Rutland wrote:
> I want to get the regression fixed ASAP, so can we take a simple patch for
> -rc2
> which disables the build-time sort where it's currently broken (by limiting
> the
> opt-in to arm and x86), then follow-up per-architecture to re-enable
On Thu, Jan 27, 2022 at 10:10:32PM +1100, Michael Ellerman wrote:
> Dan Carpenter writes:
> > On Wed, Jan 26, 2022 at 12:21:49PM +, Christophe Leroy wrote:
> >> The code is enclosed in a #ifdef CONFIG_PPC64, it is not used for PPC32:
> >>
> >> /arch/powerpc/include/asm/bug.h
> >>99
On Thu, Jan 27, 2022 at 02:16:31PM +0100, Sven Schnelle wrote:
> Mark Rutland writes:
>
> > On Thu, Jan 27, 2022 at 07:46:01AM -0500, Steven Rostedt wrote:
> >> On Thu, 27 Jan 2022 12:27:04 +
> >> Mark Rutland wrote:
> >>
> >> > Ah, so those non-ELF relocations for the mcount_loc table
On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote:
> On Thu, 27 Jan 2022 at 13:59, Mark Rutland wrote:
> >
> > On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> > > On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
> > > > On Thu, Jan 27, 2022 at 01:03:34PM +0100,
On Thu, Jan 27, 2022 at 07:46:01AM -0500, Steven Rostedt wrote:
> On Thu, 27 Jan 2022 12:27:04 +
> Mark Rutland wrote:
>
> > Ah, so those non-ELF relocations for the mcount_loc table just mean "apply
> > the
> > KASLR offset here", which is equivalent for all entries.
> >
> > That makes
On Thu, 27 Jan 2022 at 13:59, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
> > > On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> > >
> > > > These architectures use place-relative
On Thu, Jan 27, 2022 at 01:22:17PM +0100, Ard Biesheuvel wrote:
> On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
> > On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> >
> > > These architectures use place-relative extables for the same reason:
> > > place relative references
On Thu, 27 Jan 2022 12:27:04 +
Mark Rutland wrote:
> Ah, so those non-ELF relocations for the mcount_loc table just mean "apply the
> KASLR offset here", which is equivalent for all entries.
>
> That makes sense, thanks!
And this is why we were having such a hard time understanding each
On Thu, Jan 27, 2022 at 01:04:41PM +0100, Sven Schnelle wrote:
> Mark Rutland writes:
>
> >> Isn't x86 relocatable in some configurations (e.g. for KASLR)?
> >>
> >> I can't see how the sort works for those cases, because the mcount_loc
> >> entries
> >> are absolute, and either:
> >>
> >> *
On Thu, 27 Jan 2022 at 13:20, Mark Rutland wrote:
>
> On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> > On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote:
> > >
> > > [adding LKML so this is easier for others to find]
> > >
> > > If anyone wants to follow the thread from the
On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote:
> On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote:
> >
> > [adding LKML so this is easier for others to find]
> >
> > If anyone wants to follow the thread from the start, it's at:
> >
> >
> >
On Thu, 27 Jan 2022 at 12:47, Mark Rutland wrote:
>
> [adding LKML so this is easier for others to find]
>
> If anyone wants to follow the thread from the start, it's at:
>
>
> https://lore.kernel.org/linuxppc-dev/944d10da-8200-4ba9-8d0a-3bed9aa99...@linux.ibm.com/
>
> Ard, I was under the
[adding LKML so this is easier for others to find]
If anyone wants to follow the thread from the start, it's at:
https://lore.kernel.org/linuxppc-dev/944d10da-8200-4ba9-8d0a-3bed9aa99...@linux.ibm.com/
Ard, I was under the impression that the 32-bit arm kernel was (virtually)
relocatable,
Le 26/01/2022 à 22:36, Mike Rapoport a écrit :
> On Mon, Jan 24, 2022 at 09:22:15AM +, Christophe Leroy wrote:
>> within_module_core() and within_module_init() are doing the exact same
>> test, one on core_layout, the second on init_layout.
>>
>> In preparation of increasing the complexity
Le 24/01/2022 à 13:32, Christoph Hellwig a écrit :
> On Mon, Jan 24, 2022 at 09:22:15AM +, Christophe Leroy wrote:
>> +static inline bool within_range(unsigned long addr, void *base, unsigned
>> int size)
>
> Please avoid the overly long line.
>
> .. But given that this function only has
In order to separate text and data, we need to setup
two rb trees.
This also means that struct mod_tree_root is required even without
MODULES_TREE_LOOKUP.
Also remove module_addr_min and module_addr_max as there will
be one min and one max for each tree.
Signed-off-by: Christophe Leroy
---
book3s/32 and 8xx have a separate area for allocating modules,
defined by MODULES_VADDR / MODULES_END.
On book3s/32, it is not possible to protect against execution
on a page basis. A full 256M segment is either Exec or NoExec.
The module area is in an Exec segment while vmalloc area is
in a
Add CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC to allow architectures
to request having modules data in vmalloc area instead of module area.
This is required on powerpc book3s/32 in order to set data non
executable, because it is not possible to set executability on page
basis, this is done per
In order to allow separation of data from text, add another layout,
called data_layout. For architectures requesting separation of text
and data, only text will go in core_layout and data will go in
data_layout.
For architectures which keep text and data together, make data_layout
an alias of
In order to separate text and data, we need to setup
two rb trees. So modify functions to give the tree
as a parameter.
Signed-off-by: Christophe Leroy
---
kernel/module.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
This series allow architectures to request having modules data in
vmalloc area instead of module area.
This is required on powerpc book3s/32 in order to set data non
executable, because it is not possible to set executability on page
basis, this is done per 256 Mbytes segments. The module area
On Thu, Jan 27, 2022 at 3:01 PM Lu Baolu wrote:
>
> On 2022/1/27 10:54, Kai-Heng Feng wrote:
> > Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> > hint") enables ACS, and some platforms lose its NVMe after resume from
> > S3:
> > [ 50.947816] pcieport :00:1b.0: DPC:
Dan Carpenter writes:
> On Wed, Jan 26, 2022 at 12:21:49PM +, Christophe Leroy wrote:
>> The code is enclosed in a #ifdef CONFIG_PPC64, it is not used for PPC32:
>>
>> /arch/powerpc/include/asm/bug.h
>>99 #ifdef CONFIG_PPC64
>
> Ah...
>
> You know, life would be a lot easier for me
Miguel Ojeda writes:
> Hi PPC folks,
>
> Our ppc64le CI deterministically triggers a hard lockup / hang under
> QEMU since v5.17-rc1 (upgrading from v5.16).
>
> Bisecting points to 0faf20a1ad16 ("powerpc/64s/interrupt: Don't enable
> MSR[EE] in irq handlers unless perf is in use").
Hi Miguel,
53 matches
Mail list logo
