[ + linuxppc-dev ]
Anders Roxell writes:
> If the kernel headers aren't installed we can't build all the tests.
> Add a new make target rule 'khdr' in the file lib.mk to generate the
> kernel headers and that gets include for every test-dir Makefile that
> includes lib.mk If the testdir in turn
With Commit 2ea626306810 ("powerpc/topology: Get topology for shared
processors at boot"), kdump kernel on shared lpar may crash.
The necessary conditions are
- Shared Lpar with atleast 2 nodes having memory and CPUs.
- Memory requirement for kdump kernel must be met by the first N-1 nodes
On Thu, 2018-09-27 at 17:51 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/18/2018 02:41 AM, Michael Neuling wrote:
> > On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> > > In the previous TM code, trecheckpoint was being executed in the middle of
> > > an exception, thus, DSCR was
On Thu, 2018-09-27 at 17:52 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/18/2018 02:50 AM, Michael Neuling wrote:
> > On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> > > Since the transaction will be doomed with treckpt., the TEXASR[FS]
> > > should be set, to reflect that the
On Thu, 2018-09-27 at 17:58 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/17/2018 10:29 PM, Michael Neuling wrote:
> > On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> > > Now the transaction reclaims happens very earlier in the trap handler, and
> > > it is impossible to know
Commit b2d35fa5fc80 ("selftests: add headers_install to lib.mk")
introduced a requirement that Makefiles more than one level below the
selftests directory need to define top_srcdir, but it didn't update
any of the powerpc Makefiles.
This broke building all the powerpc selftests with eg:
Christophe Leroy writes:
> Add call to early_memtest() so that kernel compiled with
> CONFIG_MEMTEST really perform memtest at startup when requested
> via 'memtest' boot parameter.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/setup-common.c | 3 +++
> 1 file changed, 3
On Thu, 2018-09-27 at 18:03 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/18/2018 02:36 AM, Michael Neuling wrote:
> > On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> > > Make sure that we are not suspended on ptrace and that the registers were
> > > already reclaimed.
> > >
> > >
On Thu, 2018-09-27 at 17:57 -0300, Breno Leitao wrote:
> Hi Mikey,
>
> On 09/18/2018 03:36 AM, Michael Neuling wrote:
> > On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
> > > The Documentation/powerpc/transactional_memory.txt says:
> > >
> > > "Syscalls made from within a suspended
Le 26/09/2018 à 21:16, Segher Boessenkool a écrit :
On Wed, Sep 26, 2018 at 11:40:38AM +, Christophe Leroy wrote:
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(,
Masahiro Yamada writes:
> 2018-09-25 10:16 GMT+09:00 Michael Ellerman :
>> Christophe LEROY writes:
>>
>>> Le 24/09/2018 à 14:10, Michael Ellerman a écrit :
Christophe Leroy writes:
> I'm trying to implement TLS based stack protector in the Linux Kernel.
> For that I need to
Michael Neuling writes:
> On Tue, 2018-09-25 at 22:00 +1000, Michael Ellerman wrote:
>> Michael Neuling writes:
>> > Current we store the userspace r1 to PACATMSCRATCH before finally
>> > saving it to the thread struct.
>> >
>> > In theory an exception could be taken here (like a machine check
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing
---
drivers/pci/hotplug/pnv_php.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 5070620..ee54f5b 100644
---
Michael Bringmann writes:
> Hello, Michael:
> I am an idiot this morning. Not enough coffee.
Emailing when insufficiently caffeinated, that is dangerous :)
> I confused this posting with another. Please forget the request.
No worries.
> We do want to omit
>
> [PATCH v08 0/5]
On PPC64, as register r13 points to the paca_struct at all time,
this patch adds a copy of the canary there, which is copied at
task_switch.
That new canary is then used by using the following GCC options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=r13
On Thu, Sep 27, 2018 at 08:20:00AM +0200, Christophe LEROY wrote:
> Le 26/09/2018 à 21:16, Segher Boessenkool a écrit :
> >On Wed, Sep 26, 2018 at 11:40:38AM +, Christophe Leroy wrote:
> >>+static __always_inline void boot_init_stack_canary(void)
> >>+{
> >>+ unsigned long canary;
> >>+
>
@Andrew, Only patch #5 changed (see change notes below). Thanks!
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the
Christophe LEROY writes:
> Le 26/09/2018 à 13:11, Daniel Thompson a écrit :
>> On 16/09/2018 20:06, Daniel Thompson wrote:
>>> On Fri, Sep 14, 2018 at 12:35:44PM +, Christophe Leroy wrote:
On a powerpc 8xx, 'btc' fails as follows:
Entering kdb (current=0x(ptrval), pid 282) due to
Le 27/09/2018 à 13:09, Michael Ellerman a écrit :
Christophe LEROY writes:
Le 26/09/2018 à 13:11, Daniel Thompson a écrit :
On 16/09/2018 20:06, Daniel Thompson wrote:
On Fri, Sep 14, 2018 at 12:35:44PM +, Christophe Leroy wrote:
On a powerpc 8xx, 'btc' fails as follows:
Entering kdb
Le 27/09/2018 à 09:45, Segher Boessenkool a écrit :
On Thu, Sep 27, 2018 at 08:20:00AM +0200, Christophe LEROY wrote:
Le 26/09/2018 à 21:16, Segher Boessenkool a écrit :
On Wed, Sep 26, 2018 at 11:40:38AM +, Christophe Leroy wrote:
+static __always_inline void
YueHaibing writes:
> Use kmemdup rather than duplicating its implementation
>
> Signed-off-by: YueHaibing
> ---
> drivers/pci/hotplug/pnv_php.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
> index
On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote:
>
> Align powerpc with other architectures which build the dtb files in the
> same directory as the dts files. This is also in line with most other
> build targets which are located in the same directory as the source.
> This move will help
On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> I'm not sure this is entirely right.
>
> Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> fail if you allocate something above 1G (which is legit for
> ZONE_DMA32).
And then we will try GFP_DMA
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
> > -* to be able to satisfy them - either by not supporting more physical
> > -* memory, or by providing a ZONE_DMA32. If neither is the case, the
> > -* architecture needs to use an IOMMU instead of the direct
On 20/09/18 19:52, Christoph Hellwig wrote:
This is somewhat modelled after the powerpc version, and differs from
the legacy fallback in use fls64 instead of pointlessly splitting up the
address into low and high dwords and in that it takes (__)phys_to_dma
into account.
Signed-off-by: Christoph
On 20/09/18 19:52, Christoph Hellwig wrote:
We need to take the DMA offset and encryption bit into account when
selecting a zone. User the opportunity to factor out the zone
selection into a helper for reuse.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 31
On 20/09/18 19:52, Christoph Hellwig wrote:
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
[ oops, I should have looked at the replies first, now I see Ben already
had the same thing to say about #3... ]
On 27/09/18 14:49, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
-* to be able to satisfy them - either by not supporting
On Thu, Sep 27, 2018 at 03:12:25PM +0100, Robin Murphy wrote:
>> +u64 dma_direct_get_required_mask(struct device *dev)
>> +{
>> +u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
>> +
>> +return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
>
> I think that may as well just use
On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
>> +static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
>> dma_mask,
>> +u64 *phys_mask)
>> +{
>> +if (force_dma_unencrypted())
>> +*phys_mask = __dma_to_phys(dev, dma_mask);
>> +else
>>
On Thu, Sep 27, 2018 at 03:58:04PM +0100, Robin Murphy wrote:
>> }
>> #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> index 3c404e33d946..64466b7ef67b 100644
>> --- a/kernel/dma/direct.c
>> +++ b/kernel/dma/direct.c
>> @@ -43,10 +43,11
On 27/09/18 16:28, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:12:25PM +0100, Robin Murphy wrote:
+u64 dma_direct_get_required_mask(struct device *dev)
+{
+ u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
+
+ return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
On 27/09/18 16:30, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
+static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
dma_mask,
+ u64 *phys_mask)
+{
+ if (force_dma_unencrypted())
+ *phys_mask =
On Thu, Sep 27, 2018 at 04:38:31PM +0100, Robin Murphy wrote:
> On 27/09/18 16:30, Christoph Hellwig wrote:
>> On Thu, Sep 27, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
+static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64
dma_mask,
+ u64 *phys_mask)
On 27/09/18 16:32, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 03:58:04PM +0100, Robin Murphy wrote:
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3c404e33d946..64466b7ef67b 100644
--- a/kernel/dma/direct.c
+++
On Thu, Sep 27, 2018 at 05:14:56PM +0100, Robin Murphy wrote:
>> This just seemed more readable to me than min_not_zero, but if others
>> prefer min_not_zero I can switch.
>
> Nah, just checking whether there were any intentionally different
> assumptions compared to the couple of other places in
On 27/09/18 17:27, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 05:14:56PM +0100, Robin Murphy wrote:
This just seemed more readable to me than min_not_zero, but if others
prefer min_not_zero I can switch.
Nah, just checking whether there were any intentionally different
assumptions
From: "Gautham R. Shenoy"
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
On 27 September 2018 at 18:55, Maksym Kokhan
wrote:
> There were series of patches [1] for 4.3.0-rc3, that allowed
> architectures to use a generic builtin command line. I have rebased
> these patches on kernel 4.19.0-rc4.
>
Could you please elaborate on the purpose of this series? Is it simply
On a powerpc 8xx, 'btc' fails as follows:
Entering kdb (current=0x(ptrval), pid 282) due to Keyboard Entry
kdb> btc
btc: cpu status: Currently on cpu 0
Available cpus: 0
kdb_getarea: Bad address 0x0
when booting the kernel with 'debug_boot_weak_hash', it fails as well
Entering kdb
Since commit ad67b74d2469 ("printk: hash addresses printed with %p"),
all pointers printed with %p are printed with hashed addresses
instead of real addresses in order to avoid leaking addresses in
dmesg and syslog. But this applies to kdb too, with is unfortunate:
Entering kdb
On 09/27/2018 11:51 AM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> 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
On 09/27/2018 10:05 AM, Ard Biesheuvel wrote:
On 27 September 2018 at 18:55, Maksym Kokhan
wrote:
There were series of patches [1] for 4.3.0-rc3, that allowed
architectures to use a generic builtin command line. I have rebased
these patches on kernel 4.19.0-rc4.
Could you please elaborate
On Wed, Sep 26, 2018 at 1:15 PM Li Yang wrote:
>
> On Wed, Sep 26, 2018 at 4:28 AM Alexandre Belloni
> wrote:
> >
> > On 25/09/2018 21:45:56+0200, Olof Johansson wrote:
> > > Hi,
> > >
> > >
> > > On Thu, Aug 23, 2018 at 11:36 PM Alexandre Belloni
> > > wrote:
> > > >
> > > > If the qman driver
On Mon, 24 Sep 2018 05:38:56 +0530, Vabhav Sharma wrote:
> Add compatible for LX2160A SoC,QDS and RDB board
>
> Signed-off-by: Vabhav Sharma
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 12
> 1 file changed, 12 insertions(+)
>
Reviewed-by: Rob Herring
Hi Mikey,
First of all, thanks for you detailed review. I really appreciate your
comments here.
On 09/17/2018 02:25 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> This patchset for the hardware transactional memory (TM) subsystem aims to
>> avoid spending
Hi Mikey,
On 09/17/2018 10:31 PM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> This patch creates a macro that will be invoked on all entrance to the
>> kernel, so, in kernel space the transaction will be completely reclaimed
>> and not suspended anymore.
>
hi Mikey
On 09/18/2018 01:04 AM, Michael Neuling wrote:
>> On top of that, both tm_reclaim_task() and tm_recheckpoint_new_task()
>> functions are not used anymore, removing them.
>
> What about tm_reclaim_current(). This is being used in places like signals
> which I would have thought we could
There were series of patches [1] for 4.3.0-rc3, that allowed
architectures to use a generic builtin command line. I have rebased
these patches on kernel 4.19.0-rc4.
Things, modified in comparison with original patches:
* There was some bug for mips, in the case when
From: Daniel Walker
This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
From: Daniel Walker
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
[maksym.kok...@globallogic.com: add strlcat to prom_init_check.sh
whitelist]
Cc: Daniel Walker
Cc: Daniel Walker
Signed-off-by: Daniel Walker
Signed-off-by: Maksym Kokhan
---
arch/powerpc/Kconfig
Hi Mikey,
On 09/18/2018 02:41 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> In the previous TM code, trecheckpoint was being executed in the middle of
>> an exception, thus, DSCR was being restored to default kernel DSCR value
>> after trecheckpoint was
Hi Mikey,
On 09/18/2018 02:50 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> Since the transaction will be doomed with treckpt., the TEXASR[FS]
>> should be set, to reflect that the transaction is a failure. This patch
>> ensures it before recheckpointing,
Hi Mikey,
On 09/18/2018 03:36 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> The Documentation/powerpc/transactional_memory.txt says:
>>
>> "Syscalls made from within a suspended transaction are performed as normal
>> and the transaction is not
Hi Mikey,
On 09/17/2018 10:29 PM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> Now the transaction reclaims happens very earlier in the trap handler, and
>> it is impossible to know precisely, at that early time, what should be set
>> as the failure cause for
Hi Mikey,
On 09/18/2018 02:36 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> Make sure that we are not suspended on ptrace and that the registers were
>> already reclaimed.
>>
>> Since the data was already reclaimed, there is nothing to be done here
>>
Hi Rob and Grant,
Various device tree specs are recommending to include all the
potential compatible strings in the device node, with the order from
most specific to most general. But it looks like Linux kernel doesn't
provide a way to bind the device to the most specific driver, however,
the
This is somewhat modelled after the powerpc version, and differs from
the legacy fallback in use fls64 instead of pointlessly splitting up the
address into low and high dwords and in that it takes (__)phys_to_dma
into account.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
We need to take the DMA offset and encryption bit into account when
selecting a zone. User the opportunity to factor out the zone
selection into a helper for reuse.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
kernel/dma/direct.c | 31 +--
1 file
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
kernel/dma/direct.c| 21 +++--
2
This way an architecture with less than 4G of RAM can support dma_mask
smaller than 32-bit without a ZONE_DMA. Apparently that is a common
case on powerpc.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
kernel/dma/direct.c | 28
1 file changed, 16
Hi all,
the dma_get_required_mask dma API implementation has always been a little
odd, in that we by default don't wire it up struct dma_map_ops, but
instead hard code a default implementation. powerpc and ia64 override
this default and either call a method or otherwise duplicate the default.
This save some duplication for ia64, and makes the interface more
general. In the long run we want each dma_map_ops instance to fill this
out, but this will take a little more prep work.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt [powerpc bits]
---
This threshold is no longer used now that all invalidates issue a single
ATSD to each active NPU.
Signed-off-by: Mark Hairgrove
---
arch/powerpc/platforms/powernv/npu-dma.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git
Prior to this change only two types of ATSDs were issued to the NPU:
invalidates targeting a single page and invalidates targeting the whole
address space. The crossover point happened at the configurable
atsd_threshold which defaulted to 2M. Invalidates that size or smaller
would issue per-page
There are two types of ATSDs issued to the NPU: invalidates targeting a
specific virtual address and invalidates targeting the whole address
space. In both cases prior to this change, the sequence was:
for each NPU
- Write the target address to the XTS_ATSD_AVA register
-
When ATS is used in a process, all CPU TLB invalidates in that process
also trigger ATSD invalidates via mmu_notifiers. This additional overhead
is noticeable in applications which do heavy memory allocation or page
migration among nodes, particularly to and from GPUs.
This patch set reduces that
On Thu, 2018-09-27 at 15:49 +0200, Christoph Hellwig wrote:
> On Thu, Sep 27, 2018 at 11:45:15AM +1000, Benjamin Herrenschmidt wrote:
> > I'm not sure this is entirely right.
> >
> > Let's say the mask is 30 bits. You will return GFP_DMA32, which will
> > fail if you allocate something above 1G
On Wed, 26 Sep 2018 19:39:14 +0530
Akshay Adiga wrote:
> On Fri, Sep 14, 2018 at 11:52:40AM +1000, Nicholas Piggin wrote:
> > +
> > + /*
> > +* On POWER9, SRR1 bits do not match exactly as expected.
> > +* SRR1_WS_GPRLOSS (10b) can also result in SPR loss, so
> > +* always test
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we register the DTL
buffer for a cpu when the associated file under powerpc/dtl in debugfs
is opened. When doing so, we need to set the size of the buffer being
registered in the second u32 word of the buffer. This needs to be in big
endian, but
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
Reviewed-by: Rashmica Gupta
Signed-off-by: David Hildenbrand
---
Two trivial fixes to DTL buffer access over debugfs when
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set.
- Naveen
Naveen N. Rao (2):
powerpc/pseries: Fix DTL buffer registration
powerpc/pseries: Fix how we iterate over the DTL entries
arch/powerpc/platforms/pseries/dtl.c | 4 ++--
1 file
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we look up dtl_idx in
the lppaca to determine the number of entries in the buffer. Since
lppaca is in big endian, we need to do an endian conversion before using
this in our calculation to determine the number of entries in the
buffer. Without
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b),
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by: Pavel Tatashin
Reviewed-by:
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the
78 matches
Mail list logo
