We are going to reuse multilevel TCE code for the userspace copy of
the TCE table and since it is big endian, let's make the copy big endian
too.
Reviewed-by: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 2 +-
arch/powerpc/kvm/book3s_64_vio.c|
Right now we have allocation code in pci-ioda.c and traversing code in
pci.c, let's keep them toghether. However both files are big enough
already so let's move this business to a new file.
While we at it, move the code which links IOMMU table groups to
IOMMU tables as it is not specific to any PN
This patchset aims to reduce actual memory use for guests with
sparse memory. The pseries guest uses dynamic DMA windows to map
the entire guest RAM but it only actually maps onlined memory
which may be not be contiguous. I hit this when tried passing
through NVLink2-connected GPU RAM of NVIDIA V
At the moment we allocate the entire TCE table, twice (hardware part and
userspace translation cache). This normally works as we normally have
contigous memory and the guest will map entire RAM for 64bit DMA.
However if we have sparse RAM (one example is a memory device), then
we will allocate TCE
This moves actual pages allocation to a separate function which is going
to be reused later in on-demand TCE allocation.
While we are at it, remove unnecessary level size round up as the caller
does this already.
Reviewed-by: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/pl
We want to support sparse memory and therefore huge chunks of DMA windows
do not need to be mapped. If a DMA window big enough to require 2 or more
indirect levels, and a DMA window is used to map all RAM (which is
a default case for 64bit window), we can actually save some memory by
not allocation
This gets rid of a useless wrapper around
pnv_pci_ioda2_table_free_pages().
Reviewed-by: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-io
On Fri, 2018-06-29 at 17:34 +1000, Russell Currey wrote:
> + /*
> + * The TCE isn't being used, so let's try and
> allocate it.
> + * Bits 0 and 1 are read/write, and we use bit 2 as
> a "lock"
> + * bit. This is to prevent any race where the v
A VM which has:
- a DMA capable device passed through to it (eg. network card);
- running a malicious kernel that ignores H_PUT_TCE failure;
- capability of using IOMMU pages bigger that physical pages
can create an IOMMU mapping that exposes (for example) 16MB of
the host physical memory to the
This is to improve page boundaries checking and should probably
be cc:stable. I came accross this while debugging nvlink2 passthrough
but the lack of checking might be exploited by the existing userspace.
Changes:
v3:
* enforced huge pages not to cross preregistered chunk boundaries
v2:
* 2/2:
The size is always equal to 1 page so let's use this. Later on this will
be used for other checks which use page shifts to check the granularity
of access.
This should cause no behavioral change.
Reviewed-by: David Gibson
Acked-by: Alex Williamson
Signed-off-by: Alexey Kardashevskiy
---
As Al
On Tue, Jul 3, 2018 at 10:28 PM Rafael J. Wysocki wrote:
>
> On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote:
> > Clean up the referring to the code in commit 52cdbdd49853 ("driver core:
> > correct device's shutdown order"). So later we can revert it safely.
> >
> > Cc: Greg Kroah-Hart
On 07/03/18 at 11:57pm, Andy Shevchenko wrote:
> On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> > On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> >> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> >> wrote:
>
> >> > I briefly looked at the code and error codes we have, so, my proposal
>
For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down. This is what we have been doing all along in the old kexec
loading interface and the kexec loading is still default setting in some
distrib
This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.
It will be used in kexec_file code.
Signe
The struct resource uses singly linked list to link siblings, implemented
by pointer operation. Replace it with list_head for better code readability.
Based on this list_head replacement, it will be very easy to do reverse
iteration on iomem_resource's sibling list in later patch.
Besides, type o
reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
so that it's shared.
Signed-off-by: Baoquan He
---
arch/microblaze/pci/pci-common.c | 37 -
arch/powerpc/kernel/pci-com
This patchset is doing:
1) Replace struct resource's sibling list from singly linked list to
list_head. Clearing out those pointer operation within singly linked
list for better code readability.
2) Based on list_head replacement, add a new function
walk_system_ram_res_rev() which can does reversed
Hi.
Thanks for the update.
2018-07-04 8:34 GMT+09:00 Laura Abbott :
>
> The build id generated from --build-id can be generated in several different
> ways, with the default being the sha1 on the output of the linked file. For
> distributions, it can be useful to make sure this ID is unique, eve
Hi.
2018-07-04 8:21 GMT+09:00 Laura Abbott :
>
> Hi,
>
> This is v5 of the series to allow unique build ids in the kernel. As a
> reminder of the context:
> ""
> In Fedora, the debug information is packaged separately (foo-debuginfo) and
> can be installed separately. There's been a long stand
Hi.
2018-07-04 8:34 GMT+09:00 Laura Abbott :
>
> The vDSO needs to have a unique build id in a similar manner
> to the kernel and modules. Use the build salt macro.
>
> Signed-off-by: Laura Abbott
> ---
> v5: I was previously focused on x86 only but since powerpc gave a patch,
> I figured I would
Hi Laurent,
For the test result on Intel 4s skylake platform (192 CPUs, 768G Memory), the
below test cases all were run 3 times.
I check the test results, only page_fault3_thread/enable THP have 6% stddev for
head commit, other tests have lower stddev.
And I did not find other high variation o
On Tue, Jul 3, 2018 at 5:26 PM Pingfan Liu wrote:
>
> On Tue, Jul 3, 2018 at 3:51 PM Lukas Wunner wrote:
> >
> > On Tue, Jul 03, 2018 at 02:50:40PM +0800, Pingfan Liu wrote:
> > > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > > places an assumption of supplier<-consumer
On Tue, Jul 3, 2018 at 10:36 PM Rafael J. Wysocki wrote:
>
> On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote:
> > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > places an assumption of supplier<-consumer order on the process of probe.
> > But it turns out to br
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: I was previously focused on x86 only but since powerpc gave a patch,
I figured I would do arm64 since the changes were also fairly simple.
---
a
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: New approach with the BUILD_SALT macro
---
arch/powerpc/kernel/vdso32/note.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Signed-off-by: Laura Abbott
---
v5: Switched to using the single line BUILD_SALT macro
---
arch/x86/entry/vdso/vdso-note.S | 3 +++
arch/x86/entry/vdso/vdso32/note.S | 3 +++
2 f
The build id generated from --build-id can be generated in several different
ways, with the default being the sha1 on the output of the linked file. For
distributions, it can be useful to make sure this ID is unique, even if the
actual file contents don't change. The easiest way to do this is to
Hi,
This is v5 of the series to allow unique build ids in the kernel. As a
reminder of the context:
""
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only one
version of a debuginfo info package c
Hi,
This is v5 of the series to allow unique build ids in the kernel. As a
reminder of the context:
""
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only one
version of a debuginfo info package c
Thank you Andy for the heads up. I might need to rebase my work
(http://lkml.kernel.org/r/20180629182541.6735-1-pasha.tatas...@oracle.com)
based on this change. But, it is possible it is going to be harder to
parallelize based on device tree. I will need to think about it.
Pavel
On Tue, Jul 3, 20
On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote:
> On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
>> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
>> wrote:
>> > I briefly looked at the code and error codes we have, so, my proposal
>> > is one of the following
>>
>> > - use -ECANCELED (not
On Tue, Jul 03, 2018 at 11:59:14AM -0700, William Kennington wrote:
> Is there a bug tracking the issue?
https://bugs.kde.org/show_bug.cgi?id=386945
> Also, unless your malloc is
> guaranteed to be zeroing out the data or have a strcmp that is writing
> doubleworld aligned data to the string, the
Hi!
On Tue, Jul 03, 2018 at 11:26:55AM -0700, William Kennington wrote:
> I've noticed while trying to do some valgrind testing on code linked
> against system libraries that have inlined strcmps that valgrind is
> unhappy about branches depending on uninitialized memory. I've read
The branches h
Hi,
I've noticed while trying to do some valgrind testing on code linked
against system libraries that have inlined strcmps that valgrind is
unhappy about branches depending on uninitialized memory. I've read
through the generated inline assembly, and it looks like the assembly
will always produce
On Tue, Jul 03, 2018 at 04:33:51PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> A pair of IBM POWER9 SMT4 cores can be fused together to form a big-core
> with 8 SMT threads. This can be discovered via the "ibm,thread-groups"
> CPU property in the device tree which will indicat
On Tue, Jul 03, 2018 at 04:33:50PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> On IBM POWER9, the device tree exposes a property array identifed by
> "ibm,thread-groups" which will indicate which groups of threads share a
> particular set of resources.
>
> As of today we only
On Fri, 2018-06-29 at 00:42 +1000, Michael Ellerman wrote:
> Kent, Jens,
>
> This looks like it might be related to the recent bioset changes?
>
> cheers
>
> Abdul Haleem writes:
> > On Tue, 2018-06-26 at 23:36 +1000, Michael Ellerman wrote:
> >> Abdul Haleem writes:
> ...
> > I was able to re
> -Original Message-
> From: York Sun
> Sent: Tuesday, July 3, 2018 10:27 AM
> To: jo...@infinera.com ; Leo Li
>
> Cc: linuxppc-dev@lists.ozlabs.org; m...@ellerman.id.au; Qiang Zhao
>
> Subject: Re: [PATCH] QE GPIO: Add qe_gpio_set_multiple
>
> +Leo
>
> On 07/03/2018 03:30 AM, Joakim
On 20/05/18 14:49, Nipun Gupta wrote:
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
On 20/05/18 14:49, Nipun Gupta wrote:
of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
1 file changed, 1 insertion(+)
diff --g
On 20/05/18 14:49, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Looks like this is the final arch_setup_dma_ops offender, yay!
Sign
On 20/05/18 14:49, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 21 +
inclu
On 20/05/18 14:49, Nipun Gupta wrote:
With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus
FWIW I had a quick hack at factoring out the commonality with
of_pci_iommu_init(), at which point I reckon this change is easier to
follow as-is
+Leo
On 07/03/2018 03:30 AM, Joakim Tjernlund wrote:
> On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
>>
>> Joakim Tjernlund writes:
>>> On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
-Original Message-
From:
Hi Andy,
On 06/12/18 at 05:24pm, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
> wrote:
> >> Hmm, I just copied it from arch/powerpc/kernel/pci-common.c. The
> >> function interface expects an integer returned value, not sure what a
> >> real error codes look like, cou
On 20/05/18 14:49, Nipun Gupta wrote:
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
On 20/05/18 14:49, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
On Tuesday, July 3, 2018 8:50:38 AM CEST Pingfan Liu wrote:
> commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> places an assumption of supplier<-consumer order on the process of probe.
> But it turns out to break down the parent <- child order in some scene.
> E.g in pci, a br
On Tuesday, July 3, 2018 8:50:41 AM CEST Pingfan Liu wrote:
> Clean up the referring to the code in commit 52cdbdd49853 ("driver core:
> correct device's shutdown order"). So later we can revert it safely.
>
> Cc: Greg Kroah-Hartman
> Cc: Rafael J. Wysocki
> Cc: Grygorii Strashko
> Cc: Christop
Kernel Oops at 0xc0334d5c for reading at address 0xc2236450 which
corresponds to r30 + 80
But r30 should contain what's at r3 + 16 that is at 0xc619ec10 so r30
should be c6236400 as shown below (print_hex_dump(regs->gpr[3]) added at
end of __die() )
So how can r30 contain 0xc2236400 instead
On Tue, 3 Jul 2018 13:40:55 +0200
Mathieu Malaterre wrote:
> On Tue, Jul 3, 2018 at 11:40 AM Mathieu Malaterre wrote:
> >
> > Hi Nick,
> >
> > Would you consider this a bug:
> >
> > $ touch drivers/macintosh/via-pmu.c
> > $ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
> > CROSS_COMPI
On Tue, Jul 3, 2018 at 11:40 AM Mathieu Malaterre wrote:
>
> Hi Nick,
>
> Would you consider this a bug:
>
> $ touch drivers/macintosh/via-pmu.c
> $ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
> CROSS_COMPILE=powerpc-linux-gnu-
> ...
> LD vmlinux.o
> MODPOST vmlinux.o
> WARNI
Le 03/07/2018 à 10:51, Christophe LEROY a écrit :
Hi,
I was having strange unexpected memory corruption, therefore I activated
DEBUG_PAGEALLOC and I now end up with the following Oops, which tends to
make me think we have somewhere in the network code a use-after-free
bug. I saw a few of s
From: "Gautham R. Shenoy"
On IBM POWER9, the device tree exposes a property array identifed by
"ibm,thread-groups" which will indicate which groups of threads share a
particular set of resources.
As of today we only have one form of grouping identifying the group of
threads in the core that shar
From: "Gautham R. Shenoy"
Hi,
This is the second iteration of the patchset to add support for big-core on
POWER9.
The earlier version can be found here: https://lkml.org/lkml/2018/5/11/245.
The changes from the previous version:
- Added comments explaining the "ibm,thread-groups" device t
From: "Gautham R. Shenoy"
A pair of IBM POWER9 SMT4 cores can be fused together to form a big-core
with 8 SMT threads. This can be discovered via the "ibm,thread-groups"
CPU property in the device tree which will indicate which group of
threads that share the L1 cache, translation cache and instr
I think Pavel would be interested to see this as well (he is doing
some parallel device shutdown stuff)
On Tue, Jul 3, 2018 at 9:50 AM, Pingfan Liu wrote:
> commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> places an assumption of supplier<-consumer order on the process of pr
On Tue, 3 Jul 2018 08:08:14 +1000
Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > On pseries, as of today system crashes if we get a machine check
> > exceptions due to SLB errors. These are soft errors and can be
On 07/03/2018 08:55 AM, Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:16:29 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> rtas_log_buf is a buffer to hold RTAS event data that are communicated
>> to kernel by hypervisor. This buffer is then used to pass RTAS event
>> da
On Tue, 2018-06-26 at 23:41 +1000, Michael Ellerman wrote:
>
> Joakim Tjernlund writes:
> > On Thu, 2018-06-21 at 02:38 +, Qiang Zhao wrote:
> > > On 06/19/2018 09:22 AM, Joakim Tjernlund wrote:
> > > -Original Message-
> > > From: Linuxppc-dev
> > > [mailto:linuxppc-dev-bounces+qian
Le 03/07/2018 à 11:40, Mathieu Malaterre a écrit :
Hi Nick,
Would you consider this a bug:
Looks more like a feature ...
In /drivers/macintosh/adb.c you have, and it's the only place
via_pmu_driver is used.
#if defined(CONFIG_ADB_PMU) || defined(CONFIG_ADB_PMU68K)
&via_pmu_drive
Hi Akshay,
On Tue, Jul 03, 2018 at 02:50:56PM +0530, Akshay Adiga wrote:
> Export pnv_idle_states and nr_pnv_idle_states so that its accessible to
> cpuidle driver. Use properties from pnv_idle_states structure for powernv
> cpuidle_init.
>
> Signed-off-by: Akshay Adiga
> Reviewed-by: Nicholas P
Hi Akshay,
On Tue, Jul 03, 2018 at 02:50:55PM +0530, Akshay Adiga wrote:
> Device-tree parsing happens twice, once while deciding idle state to be
> used for hotplug and once during cpuidle init. Hence, parsing the device
> tree and caching it will reduce code duplication. Parsing code has been
>
Hi Nick,
Would you consider this a bug:
$ touch drivers/macintosh/via-pmu.c
$ CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n make ARCH=powerpc
CROSS_COMPILE=powerpc-linux-gnu-
...
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.data+0x216018): Section mismatch in reference from
the variable v
On Tue, Jul 3, 2018 at 3:51 PM Lukas Wunner wrote:
>
> On Tue, Jul 03, 2018 at 02:50:40PM +0800, Pingfan Liu wrote:
> > commit 52cdbdd49853 ("driver core: correct device's shutdown order")
> > places an assumption of supplier<-consumer order on the process of probe.
> > But it turns out to break d
Export pnv_idle_states and nr_pnv_idle_states so that its accessible to
cpuidle driver. Use properties from pnv_idle_states structure for powernv
cpuidle_init.
Signed-off-by: Akshay Adiga
Reviewed-by: Nicholas Piggin
---
arch/powerpc/include/asm/cpuidle.h | 2 +
drivers/cpuidle/cpuidle-powern
Device-tree parsing happens twice, once while deciding idle state to be
used for hotplug and once during cpuidle init. Hence, parsing the device
tree and caching it will reduce code duplication. Parsing code has been
moved to pnv_parse_cpuidle_dt() from pnv_probe_idle_states(). In addition
to the p
Device-tree parsed multiple time in powernv cpuidle and powernv
hotplug code.
First to identify supported flags. Second time, to identify deepest_state
and first deep state. Third time, during cpuidle init to find the available
idle states. Any change in device-tree format will lead to make cha
Hi,
I was having strange unexpected memory corruption, therefore I activated
DEBUG_PAGEALLOC and I now end up with the following Oops, which tends to
make me think we have somewhere in the network code a use-after-free
bug. I saw a few of such bugs have been fixed for IPv4 and IPv6. Maybe
we
* Ard Biesheuvel wrote:
> On 27 June 2018 at 17:15, Will Deacon wrote:
> > Hi Ard,
> >
> > On Tue, Jun 26, 2018 at 08:27:55PM +0200, Ard Biesheuvel wrote:
> >> This adds support for emitting special sections such as initcall arrays,
> >> PCI fixups and tracepoints as relative references rather
On Tue, Jul 3, 2018 at 9:23 AM Nicholas Piggin wrote:
>
> On Tue, 3 Jul 2018 09:03:46 +0200
> Mathieu Malaterre wrote:
>
> > Hi Nick,
> >
> > I am building my kernel (ppc32) with both
> > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
> > to ~316428 warnings such as:
> >
>
Hi Diana,
A few comments below ...
Diana Craciun writes:
> Implement the barrier_nospec as a isync;sync instruction sequence.
> The implementation uses the infrastructure built for BOOK3S 64.
Do you have any details on why that sequence functions as an effective
barrier on your chips?
In a lot
Michal Suchánek writes:
> On Tue, 12 Jun 2018 02:59:11 +
> Bharat Bhushan wrote:
>
>> Hi Diana,
>>
>> > -Original Message-
>> > From: Diana Craciun [mailto:diana.crac...@nxp.com]
>> > Sent: Monday, June 11, 2018 6:23 PM
>> > To: linuxppc-dev@lists.ozlabs.org
>> > Cc: m...@ellerman.id
Diana Craciun writes:
> The speculation barrier can be disabled from the command line
> with the parameter: "nospectre_v1".
Can you please send another patch adding it to
Documentation/admin-guide/kernel-parameters.txt
You should mark it as "PPC" only for now.
cheers
On Tue, 3 Jul 2018 09:03:46 +0200
Mathieu Malaterre wrote:
> Hi Nick,
>
> I am building my kernel (ppc32) with both
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
> to ~316428 warnings such as:
>
> + powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn
>
On 07/03/2018 03:38 AM, Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
>> From: Mahesh Salgaonkar
>>
>> On pseries, as of today system crashes if we get a machine check
>> exceptions due to SLB errors. These are soft errors and can be fixed by
>> flush
Hi Nick,
I am building my kernel (ppc32) with both
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_UBSAN=y. This leads
to ~316428 warnings such as:
+ powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn
--build-id --gc-sections -X -o .tmp_vmlinux1 -T
./arch/powerpc/kernel/vmlinu
This reverts commit 52cdbdd49853dfa856082edb0f4c4c0249d9df07.
Since the device_shutdown() does not rely on the order in devices_kset any
more, reverting that commit safely.
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Grygorii Strashko
Cc: Christoph Hellwig
Cc: Bjorn Helgaas
Cc: Dave Youn
79 matches
Mail list logo
