* [PATCH] powerpc/fadump: when fadump is supported register the fadump sysfs files.
From: Michal Suchanek @ 2019-08-20 15:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Yangtao Li, Mahesh Salgaonkar, linux-kernel, Paul Mackerras,
Hari Bathini, Thomas Gleixner, Michal Suchanek
Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.
With this patch sysfs files are available whenever fadump is supported
by firmware.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/powerpc/kernel/fadump.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab97292cc2..f35ab2433a9b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1671,13 +1671,9 @@ static void fadump_init_files(void)
*/
int __init setup_fadump(void)
{
- if (!fw_dump.fadump_enabled)
- return 0;
-
- if (!fw_dump.fadump_supported) {
+ if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
printk(KERN_ERR "Firmware-assisted dump is not supported on"
" this hardware\n");
- return 0;
}
fadump_show_config();
@@ -1685,18 +1681,26 @@ int __init setup_fadump(void)
* If dump data is available then see if it is valid and prepare for
* saving it to the disk.
*/
- if (fw_dump.dump_active) {
+ if (fw_dump.fadump_enabled) {
+ if (fw_dump.dump_active) {
+ /*
+ * if dump process fails then invalidate the
+ * registration and release memory before proceeding
+ * for re-registration.
+ */
+ if (process_fadump(fdm_active) < 0)
+ fadump_invalidate_release_mem();
+ }
/*
- * if dump process fails then invalidate the registration
- * and release memory before proceeding for re-registration.
+ * Initialize the kernel dump memory structure for FAD
+ * registration.
*/
- if (process_fadump(fdm_active) < 0)
- fadump_invalidate_release_mem();
+ else if (fw_dump.reserve_dump_area_size)
+ init_fadump_mem_struct(&fdm,
+ fw_dump.reserve_dump_area_start);
}
- /* Initialize the kernel dump memory structure for FAD registration. */
- else if (fw_dump.reserve_dump_area_size)
- init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
- fadump_init_files();
+ if (fw_dump.fadump_supported)
+ fadump_init_files();
return 1;
}
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] powerpc: Allow flush_(inval_)dcache_range to work across ranges >4GB
From: Greg Kroah-Hartman @ 2019-08-20 16:30 UTC (permalink / raw)
To: Michael Ellerman
Cc: Alastair D'Silva, linux-kernel, stable, Paul Mackerras,
alastair, Thomas Gleixner, linuxppc-dev, Allison Randal
In-Reply-To: <20190816071412.GF1368@kroah.com>
On Fri, Aug 16, 2019 at 09:14:12AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 16, 2019 at 11:42:22AM +1000, Michael Ellerman wrote:
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> > > On Thu, Aug 15, 2019 at 02:55:42PM +1000, Alastair D'Silva wrote:
> > >> From: Alastair D'Silva <alastair@d-silva.org>
> > >>
> > >> Heads Up: This patch cannot be submitted to Linus's tree, as the affected
> > >> assembler functions have already been converted to C.
> >
> > That was done in upstream commit:
> >
> > 22e9c88d486a ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
> >
> > Which is a larger change that we don't want to backport. This patch is a
> > minimal fix for stable trees.
> >
> >
> > >> When calling flush_(inval_)dcache_range with a size >4GB, we were masking
> > >> off the upper 32 bits, so we would incorrectly flush a range smaller
> > >> than intended.
> > >>
> > >> This patch replaces the 32 bit shifts with 64 bit ones, so that
> > >> the full size is accounted for.
> > >>
> > >> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> > >> ---
> > >> arch/powerpc/kernel/misc_64.S | 4 ++--
> > >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> >
> > > <formletter>
> > >
> > > This is not the correct way to submit patches for inclusion in the
> > > stable kernel tree. Please read:
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > for how to do this properly.
> > >
> > > </formletter>
> >
> > Hi Greg,
> >
> > This is "option 3", submit the patch directly, and the patch "deviates
> > from the original upstream patch" because the upstream patch was a
> > wholesale conversion from asm to C.
> >
> > This patch applies cleanly to v4.14 and v4.19.
> >
> > The change log should have mentioned which upstream patch it is not a
> > backport of, is there anything else we should have done differently to
> > avoid the formletter bot :)
>
> That is exactly what you should have done. It needs to be VERY explicit
> as to why this is being submitted different from what upstream did, and
> to what trees it needs to go to and who is going to be responsible for
> when it breaks. And it will break :)
And it needs to be done before I can apply it, I've dropped this thread
from my queue now.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc: support KASAN instrumentation of bitops
From: Christophe Leroy @ 2019-08-20 16:34 UTC (permalink / raw)
To: Daniel Axtens, linux-s390, linux-arch, x86, linuxppc-dev
Cc: Nicholas Piggin, kasan-dev
In-Reply-To: <20190820024941.12640-2-dja@axtens.net>
Le 20/08/2019 à 04:49, Daniel Axtens a écrit :
> The powerpc-specific bitops are not being picked up by the KASAN
> test suite.
>
> Instrumentation is done via the bitops/instrumented-{atomic,lock}.h
> headers. They require that arch-specific versions of bitop functions
> are renamed to arch_*. Do this renaming.
>
> For clear_bit_unlock_is_negative_byte, the current implementation
> uses the PG_waiters constant. This works because it's a preprocessor
> macro - so it's only actually evaluated in contexts where PG_waiters
> is defined. With instrumentation however, it becomes a static inline
> function, and all of a sudden we need the actual value of PG_waiters.
> Because of the order of header includes, it's not available and we
> fail to compile. Instead, manually specify that we care about bit 7.
> This is still correct: bit 7 is the bit that would mark a negative
> byte.
>
> While we're at it, replace __inline__ with inline across the file.
>
> Cc: Nicholas Piggin <npiggin@gmail.com> # clear_bit_unlock_negative_byte
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Now, I only have two KASAN tests which do not trigger any message:
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
Christophe
>
> --
> v2: Address Christophe review
> ---
> arch/powerpc/include/asm/bitops.h | 51 ++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 22 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
> index 603aed229af7..28dcf8222943 100644
> --- a/arch/powerpc/include/asm/bitops.h
> +++ b/arch/powerpc/include/asm/bitops.h
> @@ -64,7 +64,7 @@
>
> /* Macro for generating the ***_bits() functions */
> #define DEFINE_BITOP(fn, op, prefix) \
> -static __inline__ void fn(unsigned long mask, \
> +static inline void fn(unsigned long mask, \
> volatile unsigned long *_p) \
> { \
> unsigned long old; \
> @@ -86,22 +86,22 @@ DEFINE_BITOP(clear_bits, andc, "")
> DEFINE_BITOP(clear_bits_unlock, andc, PPC_RELEASE_BARRIER)
> DEFINE_BITOP(change_bits, xor, "")
>
> -static __inline__ void set_bit(int nr, volatile unsigned long *addr)
> +static inline void arch_set_bit(int nr, volatile unsigned long *addr)
> {
> set_bits(BIT_MASK(nr), addr + BIT_WORD(nr));
> }
>
> -static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
> +static inline void arch_clear_bit(int nr, volatile unsigned long *addr)
> {
> clear_bits(BIT_MASK(nr), addr + BIT_WORD(nr));
> }
>
> -static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
> +static inline void arch_clear_bit_unlock(int nr, volatile unsigned long *addr)
> {
> clear_bits_unlock(BIT_MASK(nr), addr + BIT_WORD(nr));
> }
>
> -static __inline__ void change_bit(int nr, volatile unsigned long *addr)
> +static inline void arch_change_bit(int nr, volatile unsigned long *addr)
> {
> change_bits(BIT_MASK(nr), addr + BIT_WORD(nr));
> }
> @@ -109,7 +109,7 @@ static __inline__ void change_bit(int nr, volatile unsigned long *addr)
> /* Like DEFINE_BITOP(), with changes to the arguments to 'op' and the output
> * operands. */
> #define DEFINE_TESTOP(fn, op, prefix, postfix, eh) \
> -static __inline__ unsigned long fn( \
> +static inline unsigned long fn( \
> unsigned long mask, \
> volatile unsigned long *_p) \
> { \
> @@ -138,34 +138,34 @@ DEFINE_TESTOP(test_and_clear_bits, andc, PPC_ATOMIC_ENTRY_BARRIER,
> DEFINE_TESTOP(test_and_change_bits, xor, PPC_ATOMIC_ENTRY_BARRIER,
> PPC_ATOMIC_EXIT_BARRIER, 0)
>
> -static __inline__ int test_and_set_bit(unsigned long nr,
> - volatile unsigned long *addr)
> +static inline int arch_test_and_set_bit(unsigned long nr,
> + volatile unsigned long *addr)
> {
> return test_and_set_bits(BIT_MASK(nr), addr + BIT_WORD(nr)) != 0;
> }
>
> -static __inline__ int test_and_set_bit_lock(unsigned long nr,
> - volatile unsigned long *addr)
> +static inline int arch_test_and_set_bit_lock(unsigned long nr,
> + volatile unsigned long *addr)
> {
> return test_and_set_bits_lock(BIT_MASK(nr),
> addr + BIT_WORD(nr)) != 0;
> }
>
> -static __inline__ int test_and_clear_bit(unsigned long nr,
> - volatile unsigned long *addr)
> +static inline int arch_test_and_clear_bit(unsigned long nr,
> + volatile unsigned long *addr)
> {
> return test_and_clear_bits(BIT_MASK(nr), addr + BIT_WORD(nr)) != 0;
> }
>
> -static __inline__ int test_and_change_bit(unsigned long nr,
> - volatile unsigned long *addr)
> +static inline int arch_test_and_change_bit(unsigned long nr,
> + volatile unsigned long *addr)
> {
> return test_and_change_bits(BIT_MASK(nr), addr + BIT_WORD(nr)) != 0;
> }
>
> #ifdef CONFIG_PPC64
> -static __inline__ unsigned long clear_bit_unlock_return_word(int nr,
> - volatile unsigned long *addr)
> +static inline unsigned long
> +clear_bit_unlock_return_word(int nr, volatile unsigned long *addr)
> {
> unsigned long old, t;
> unsigned long *p = (unsigned long *)addr + BIT_WORD(nr);
> @@ -185,15 +185,18 @@ static __inline__ unsigned long clear_bit_unlock_return_word(int nr,
> return old;
> }
>
> -/* This is a special function for mm/filemap.c */
> -#define clear_bit_unlock_is_negative_byte(nr, addr) \
> - (clear_bit_unlock_return_word(nr, addr) & BIT_MASK(PG_waiters))
> +/*
> + * This is a special function for mm/filemap.c
> + * Bit 7 corresponds to PG_waiters.
> + */
> +#define arch_clear_bit_unlock_is_negative_byte(nr, addr) \
> + (clear_bit_unlock_return_word(nr, addr) & BIT_MASK(7))
>
> #endif /* CONFIG_PPC64 */
>
> #include <asm-generic/bitops/non-atomic.h>
>
> -static __inline__ void __clear_bit_unlock(int nr, volatile unsigned long *addr)
> +static inline void arch___clear_bit_unlock(int nr, volatile unsigned long *addr)
> {
> __asm__ __volatile__(PPC_RELEASE_BARRIER "" ::: "memory");
> __clear_bit(nr, addr);
> @@ -215,14 +218,14 @@ static __inline__ void __clear_bit_unlock(int nr, volatile unsigned long *addr)
> * fls: find last (most-significant) bit set.
> * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
> */
> -static __inline__ int fls(unsigned int x)
> +static inline int fls(unsigned int x)
> {
> return 32 - __builtin_clz(x);
> }
>
> #include <asm-generic/bitops/builtin-__fls.h>
>
> -static __inline__ int fls64(__u64 x)
> +static inline int fls64(__u64 x)
> {
> return 64 - __builtin_clzll(x);
> }
> @@ -239,6 +242,10 @@ unsigned long __arch_hweight64(__u64 w);
>
> #include <asm-generic/bitops/find.h>
>
> +/* wrappers that deal with KASAN instrumentation */
> +#include <asm-generic/bitops/instrumented-atomic.h>
> +#include <asm-generic/bitops/instrumented-lock.h>
> +
> /* Little-endian versions */
> #include <asm-generic/bitops/le.h>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang
From: Nathan Chancellor @ 2019-08-20 17:58 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-kernel, clang-built-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190820124033.GQ31406@gate.crashing.org>
On Tue, Aug 20, 2019 at 07:40:33AM -0500, Segher Boessenkool wrote:
> On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote:
> > On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote:
> > > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> > > > When building pseries_defconfig, building vdso32 errors out:
> > > >
> > > > error: unknown target ABI 'elfv1'
> > > >
> > > > Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
> > > > powerpc64le toolchain") added these flags to fix building GCC but
> > > > clang is multitargeted and does not need these flags. The ABI is
> > > > properly set based on the target triple, which is derived from
> > > > CROSS_COMPILE.
> > >
> > > You mean that LLVM does not *allow* you to select a different ABI, or
> > > different ABI options, you always have to use the default. (Everything
> > > else you say is true for GCC as well).
> >
> > I need to improve the wording of the commit message as it is really that
> > clang does not allow a different ABI to be selected for 32-bit PowerPC,
> > as the setABI function is not overridden and it defaults to false.
>
> > GCC appears to just silently ignores this flag (I think it is the
> > SUBSUBTARGET_OVERRIDE_OPTIONS macro in gcc/config/rs6000/linux64.h).
>
> What flag? -mabi=elfv[12]?
Yes.
> (Only irrelevant things are ever ignored; otherwise, please do a bug
> report).
I believe that is the case here but looking at the GCC source gives me a
headache.
> > It can be changed for 64-bit PowerPC it seems but it doesn't need to be
> > with clang because everything is set properly internally (I'll find a
> > better way to clearly word that as I am sure I'm not quite getting that
> > subtlety right).
>
> You can have elfv2 on BE, and e.g. the sysv ABI on LE. Neither of those
> is tested a lot.
>
> > > (-mabi= does not set a "target ABI", fwiw, it is more subtle; please see
> > > the documentation. Unless LLVM is incompatible in that respect as well?)
> >
> > Are you referring to the error message?
>
> Yup.
>
> > I suppose I could file an LLVM
> > bug report on that but that message applies to all of the '-mabi='
> > options, which may refer to a target ABI.
>
> That depends on what you call "an ABI", I guess. You can call any ABI
> variant a separate ABI: you'll have to rebuild all of userland. You can
> also says ELFv1 and ELFv2 are pretty much the same thing, which is true
> as well. The way -mabi= is defined is the latter:
>
> '-mabi=ABI-TYPE'
> Extend the current ABI with a particular extension, or remove such
> extension. Valid values are 'altivec', 'no-altivec',
> 'ibmlongdouble', 'ieeelongdouble', 'elfv1', 'elfv2'.
>
>
> Segher
The GCC documentation also has this description for '-mabi=elfv1' and
'-mabi=elfv2':
-mabi=elfv1:
Change the current ABI to use the ELFv1 ABI. This is the default ABI for
big-endian PowerPC 64-bit Linux. Overriding the default ABI requires
special system support and is likely to fail in spectacular ways.
-mabi=elfv2:
Change the current ABI to use the ELFv2 ABI. This is the default ABI for
little-endian PowerPC 64-bit Linux. Overriding the default ABI requires
special system support and is likely to fail in spectacular ways.
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#index-mabi_003delfv1
Thinking about this a little bit more, I think this patch is correct in
the case that clang is cross compiling because the target triple will
always be specified (so the default ABI doesn't need to be changed).
However, I am not sure how native compiling would be affected by this
change; in theory, if someone was on a little endian system and wanted
to build a big endian kernel, they would probably need -mabi=elfv1
like GCC would but I don't have any real way to test this nor am I sure
that anyone actually natively compiles PowerPC kernels with clang. It's
probably not worrying about at this point so I'll just move forward with
a v2 rewording the commit message.
Cheers,
Nathan
^ permalink raw reply
* [PATCH rebased] powerpc/fadump: when fadump is supported register the fadump sysfs files.
From: Michal Suchanek @ 2019-08-20 18:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Yangtao Li, Mahesh Salgaonkar, linux-kernel, Paul Mackerras,
Hari Bathini, Thomas Gleixner, Michal Suchanek
Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.
With this patch sysfs files are available whenever fadump is supported
by firmware.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
Rebase on top of http://patchwork.ozlabs.org/patch/1150160/
[v5,31/31] powernv/fadump: support holes in kernel boot memory area
---
arch/powerpc/kernel/fadump.c | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4b1bb3c55cf9..7ad424729e9c 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1319,13 +1319,9 @@ static void fadump_init_files(void)
*/
int __init setup_fadump(void)
{
- if (!fw_dump.fadump_enabled)
- return 0;
-
- if (!fw_dump.fadump_supported) {
+ if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
printk(KERN_ERR "Firmware-assisted dump is not supported on"
" this hardware\n");
- return 0;
}
fadump_show_config();
@@ -1333,19 +1329,26 @@ int __init setup_fadump(void)
* If dump data is available then see if it is valid and prepare for
* saving it to the disk.
*/
- if (fw_dump.dump_active) {
+ if (fw_dump.fadump_enabled) {
+ if (fw_dump.dump_active) {
+ /*
+ * if dump process fails then invalidate the
+ * registration and release memory before proceeding
+ * for re-registration.
+ */
+ if (fw_dump.ops->fadump_process(&fw_dump) < 0)
+ fadump_invalidate_release_mem();
+ }
/*
- * if dump process fails then invalidate the registration
- * and release memory before proceeding for re-registration.
+ * Initialize the kernel dump memory structure for FAD
+ * registration.
*/
- if (fw_dump.ops->fadump_process(&fw_dump) < 0)
- fadump_invalidate_release_mem();
- }
- /* Initialize the kernel dump memory structure for FAD registration. */
- else if (fw_dump.reserve_dump_area_size)
- fw_dump.ops->fadump_init_mem_struct(&fw_dump);
+ else if (fw_dump.reserve_dump_area_size)
+ fw_dump.ops->fadump_init_mem_struct(&fw_dump);
- fadump_init_files();
+ }
+ if (fw_dump.fadump_supported)
+ fadump_init_files();
return 1;
}
--
2.22.0
^ permalink raw reply related
* [PATCH 1/2] net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run
From: Juliet Kim @ 2019-08-20 21:31 UTC (permalink / raw)
To: netdev; +Cc: julietk, linuxppc-dev
Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset")
made the change to hold the RTNL lock during a reset to avoid deadlock
but linkwatch_event is fired during the reset and needs the RTNL lock.
That keeps linkwatch_event process from proceeding until the reset
is complete. The reset process cannot tolerate the linkwatch_event
processing after reset completes, so release the RTNL lock during the
process to allow a chance for linkwatch_event to run during reset.
This does not guarantee that the linkwatch_event will be processed as
soon as link state changes, but is an improvement over the current code
where linkwatch_event processing is always delayed, which prevents
transmissions on the device from being deactivated leading transmit
watchdog timer to time-out.
Release the RTNL lock before link state change and re-acquire after
the link state change to allow linkwatch_event to grab the RTNL lock
and run during the reset.
Fixes: a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset")
Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 144 +++++++++++++++++++++++++++----------
1 file changed, 108 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index cebd20f3128d..a3e2fbb9c5db 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1733,11 +1733,21 @@ static int do_reset(struct ibmvnic_adapter *adapter,
u64 old_num_rx_queues, old_num_tx_queues;
u64 old_num_rx_slots, old_num_tx_slots;
struct net_device *netdev = adapter->netdev;
+ bool we_lock_rtnl = false;
int i, rc;
netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n",
rwi->reset_reason);
+ /* netif_set_real_num_xx_queues needs to take rtnl lock here
+ * unless wait_for_reset is set, in which case the rtnl lock
+ * has already been taken before initializing the reset
+ */
+ if (!adapter->wait_for_reset && !we_lock_rtnl) {
+ rtnl_lock();
+ we_lock_rtnl = true;
+ }
+
netif_carrier_off(netdev);
adapter->reset_reason = rwi->reset_reason;
@@ -1751,9 +1761,27 @@ static int do_reset(struct ibmvnic_adapter *adapter,
if (reset_state == VNIC_OPEN &&
adapter->reset_reason != VNIC_RESET_MOBILITY &&
adapter->reset_reason != VNIC_RESET_FAILOVER) {
- rc = __ibmvnic_close(netdev);
+ adapter->state = VNIC_CLOSING;
+ if (!adapter->wait_for_reset && we_lock_rtnl) {
+ we_lock_rtnl = false;
+ rtnl_unlock();
+ }
+
+ rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
if (rc)
- return rc;
+ goto out;
+
+ if (!adapter->wait_for_reset && !we_lock_rtnl) {
+ rtnl_lock();
+ we_lock_rtnl = true;
+ }
+
+ if (adapter->state != VNIC_CLOSING) {
+ rc = -1;
+ goto out;
+ }
+
+ adapter->state = VNIC_CLOSED;
}
if (adapter->reset_reason == VNIC_RESET_CHANGE_PARAM ||
@@ -1783,30 +1811,34 @@ static int do_reset(struct ibmvnic_adapter *adapter,
if (rc) {
netdev_err(adapter->netdev,
"Couldn't initialize crq. rc=%d\n", rc);
- return rc;
+ goto out;
}
rc = ibmvnic_reset_init(adapter);
- if (rc)
- return IBMVNIC_INIT_FAILED;
+ if (rc) {
+ rc = IBMVNIC_INIT_FAILED;
+ goto out;
+ }
/* If the adapter was in PROBE state prior to the reset,
* exit here.
*/
- if (reset_state == VNIC_PROBED)
- return 0;
+ if (reset_state == VNIC_PROBED) {
+ rc = 0;
+ goto out;
+ }
rc = ibmvnic_login(netdev);
if (rc) {
adapter->state = reset_state;
- return rc;
+ goto out;
}
if (adapter->reset_reason == VNIC_RESET_CHANGE_PARAM ||
adapter->wait_for_reset) {
rc = init_resources(adapter);
if (rc)
- return rc;
+ goto out;
} else if (adapter->req_rx_queues != old_num_rx_queues ||
adapter->req_tx_queues != old_num_tx_queues ||
adapter->req_rx_add_entries_per_subcrq !=
@@ -1820,23 +1852,25 @@ static int do_reset(struct ibmvnic_adapter *adapter,
rc = init_resources(adapter);
if (rc)
- return rc;
+ goto out;
} else {
rc = reset_tx_pools(adapter);
if (rc)
- return rc;
+ goto out;
rc = reset_rx_pools(adapter);
if (rc)
- return rc;
+ goto out;
}
ibmvnic_disable_irqs(adapter);
}
adapter->state = VNIC_CLOSED;
- if (reset_state == VNIC_CLOSED)
- return 0;
+ if (reset_state == VNIC_CLOSED) {
+ rc = 0;
+ goto out;
+ }
rc = __ibmvnic_open(netdev);
if (rc) {
@@ -1845,7 +1879,8 @@ static int do_reset(struct ibmvnic_adapter *adapter,
else
adapter->state = reset_state;
- return 0;
+ rc = 0;
+ goto out;
}
/* refresh device's multicast list */
@@ -1859,18 +1894,42 @@ static int do_reset(struct ibmvnic_adapter *adapter,
adapter->reset_reason != VNIC_RESET_CHANGE_PARAM)
call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, netdev);
+ if (!adapter->wait_for_reset && we_lock_rtnl) {
+ rtnl_unlock();
+ we_lock_rtnl = false;
+ }
+
return 0;
+
+out:
+ if (!adapter->wait_for_reset && we_lock_rtnl) {
+ rtnl_unlock();
+ we_lock_rtnl = false;
+ }
+
+ return rc;
}
static int do_hard_reset(struct ibmvnic_adapter *adapter,
struct ibmvnic_rwi *rwi, u32 reset_state)
{
struct net_device *netdev = adapter->netdev;
+ bool we_lock_rtnl = false;
int rc;
netdev_dbg(adapter->netdev, "Hard resetting driver (%d)\n",
rwi->reset_reason);
+ /* netif_set_real_num_xx_queues needs to take rtnl lock here
+ * unless wait_for_reset is set, in which case the rtnl lock
+ * has already been taken before initializing the reset
+ */
+ if (!adapter->wait_for_reset && !we_lock_rtnl) {
+ rtnl_lock();
+ we_lock_rtnl = true;
+ }
+
+ adapter->force_reset_recovery = false;
netif_carrier_off(netdev);
adapter->reset_reason = rwi->reset_reason;
@@ -1889,34 +1948,39 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter,
if (rc) {
netdev_err(adapter->netdev,
"Couldn't initialize crq. rc=%d\n", rc);
- return rc;
+ goto out;
}
rc = ibmvnic_init(adapter);
if (rc)
- return rc;
+ goto out;
/* If the adapter was in PROBE state prior to the reset,
* exit here.
*/
- if (reset_state == VNIC_PROBED)
- return 0;
+ if (reset_state == VNIC_PROBED) {
+ rc = 0;
+ goto out;
+ }
rc = ibmvnic_login(netdev);
if (rc) {
adapter->state = VNIC_PROBED;
- return 0;
+ rc = 0;
+ goto out;
}
rc = init_resources(adapter);
if (rc)
- return rc;
+ goto out;
ibmvnic_disable_irqs(adapter);
adapter->state = VNIC_CLOSED;
- if (reset_state == VNIC_CLOSED)
- return 0;
+ if (reset_state == VNIC_CLOSED) {
+ rc = 0;
+ goto out;
+ }
rc = __ibmvnic_open(netdev);
if (rc) {
@@ -1925,10 +1989,25 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter,
else
adapter->state = reset_state;
- return 0;
+ rc = 0;
+ goto out;
+ }
+
+ if (!adapter->wait_for_reset && we_lock_rtnl) {
+ rtnl_unlock();
+ we_lock_rtnl = false;
}
return 0;
+
+out:
+ if (!adapter->wait_for_reset && we_lock_rtnl) {
+ rtnl_unlock();
+ we_lock_rtnl = false;
+ }
+
+ return rc;
+
}
static struct ibmvnic_rwi *get_next_rwi(struct ibmvnic_adapter *adapter)
@@ -1965,26 +2044,16 @@ static void __ibmvnic_reset(struct work_struct *work)
{
struct ibmvnic_rwi *rwi;
struct ibmvnic_adapter *adapter;
- bool we_lock_rtnl = false;
u32 reset_state;
int rc = 0;
adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);
- /* netif_set_real_num_xx_queues needs to take rtnl lock here
- * unless wait_for_reset is set, in which case the rtnl lock
- * has already been taken before initializing the reset
- */
- if (!adapter->wait_for_reset) {
- rtnl_lock();
- we_lock_rtnl = true;
- }
reset_state = adapter->state;
rwi = get_next_rwi(adapter);
while (rwi) {
if (adapter->force_reset_recovery) {
- adapter->force_reset_recovery = false;
rc = do_hard_reset(adapter, rwi, reset_state);
} else {
rc = do_reset(adapter, rwi, reset_state);
@@ -1995,6 +2064,11 @@ static void __ibmvnic_reset(struct work_struct *work)
break;
rwi = get_next_rwi(adapter);
+
+ if (rwi && (rwi->reset_reason == VNIC_RESET_FAILOVER ||
+ rwi->reset_reason == VNIC_RESET_MOBILITY) &&
+ !adapter->force_reset_recovery)
+ adapter->force_reset_recovery = true;
}
if (adapter->wait_for_reset) {
@@ -2009,8 +2083,6 @@ static void __ibmvnic_reset(struct work_struct *work)
}
adapter->resetting = false;
- if (we_lock_rtnl)
- rtnl_unlock();
}
static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
--
2.16.4
^ permalink raw reply related
* [PATCH 2/2] net/ibmvnic: prevent more than one thread from running in reset
From: Juliet Kim @ 2019-08-20 21:31 UTC (permalink / raw)
To: netdev; +Cc: julietk, linuxppc-dev
In-Reply-To: <20190820213120.19880-1-julietk@linux.vnet.ibm.com>
The current code allows more than one thread to run in reset. This can
corrupt struct adapter data. Check adapter->resetting before performing
a reset, if there is another reset running delay (100 msec) before trying
again.
Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 19 ++++++++++++++++++-
drivers/net/ethernet/ibm/ibmvnic.h | 3 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index a3e2fbb9c5db..7db7a44eeeb9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2049,6 +2049,13 @@ static void __ibmvnic_reset(struct work_struct *work)
adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);
+ if (adapter->resetting) {
+ schedule_delayed_work(&adapter->ibmvnic_delayed_reset,
+ IBMVNIC_RESET_DELAY);
+ return;
+ }
+
+ adapter->resetting = true;
reset_state = adapter->state;
rwi = get_next_rwi(adapter);
@@ -2085,6 +2092,15 @@ static void __ibmvnic_reset(struct work_struct *work)
adapter->resetting = false;
}
+static void __ibmvnic_delayed_reset(struct work_struct *work)
+{
+ struct ibmvnic_adapter *adapter;
+
+ adapter = container_of(work, struct ibmvnic_adapter,
+ ibmvnic_delayed_reset.work);
+ __ibmvnic_reset(&adapter->ibmvnic_reset);
+}
+
static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
enum ibmvnic_reset_reason reason)
{
@@ -2137,7 +2153,6 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
rwi->reset_reason = reason;
list_add_tail(&rwi->list, &adapter->rwi_list);
spin_unlock_irqrestore(&adapter->rwi_lock, flags);
- adapter->resetting = true;
netdev_dbg(adapter->netdev, "Scheduling reset (reason %d)\n", reason);
schedule_work(&adapter->ibmvnic_reset);
@@ -4910,6 +4925,8 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
spin_lock_init(&adapter->stats_lock);
INIT_WORK(&adapter->ibmvnic_reset, __ibmvnic_reset);
+ INIT_DELAYED_WORK(&adapter->ibmvnic_delayed_reset,
+ __ibmvnic_delayed_reset);
INIT_LIST_HEAD(&adapter->rwi_list);
spin_lock_init(&adapter->rwi_lock);
init_completion(&adapter->init_done);
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index 70bd286f8932..0e1fadbcffc0 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -38,6 +38,8 @@
#define IBMVNIC_MAX_LTB_SIZE ((1 << (MAX_ORDER - 1)) * PAGE_SIZE)
#define IBMVNIC_BUFFER_HLEN 500
+#define IBMVNIC_RESET_DELAY 100
+
static const char ibmvnic_priv_flags[][ETH_GSTRING_LEN] = {
#define IBMVNIC_USE_SERVER_MAXES 0x1
"use-server-maxes"
@@ -1076,6 +1078,7 @@ struct ibmvnic_adapter {
spinlock_t rwi_lock;
struct list_head rwi_list;
struct work_struct ibmvnic_reset;
+ struct delayed_work ibmvnic_delayed_reset;
bool resetting;
bool napi_enabled, from_passive_init;
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v2 02/12] powerpc/ps3: replace __ioremap() by ioremap_prot()
From: Christoph Hellwig @ 2019-08-20 22:24 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev, hch
In-Reply-To: <36bff5d875ff562889c5e12dab63e5d7c5d1fbd8.1566309262.git.christophe.leroy@c-s.fr>
On Tue, Aug 20, 2019 at 02:07:10PM +0000, Christophe Leroy wrote:
> __ioremap() is similar to ioremap_prot() except that ioremap_prot()
> does a few sanity changes in addition.
>
> The flags used by PS3 are not impacted by those changes so for
> PS3 both functions are equivalent.
>
> At the same time, drop parts of the comment that have been invalid
> since commit e58e87adc8bf ("powerpc/mm: Update _PAGE_KERNEL_RO")
>
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 04/12] powerpc/mm: drop function __ioremap()
From: Christoph Hellwig @ 2019-08-20 22:24 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev, hch
In-Reply-To: <ccc439f481a0884e00a6be1bab44bab2a4477fea.1566309262.git.christophe.leroy@c-s.fr>
On Tue, Aug 20, 2019 at 02:07:12PM +0000, Christophe Leroy wrote:
> __ioremap() is not used anymore, drop it.
>
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Looks good, I've already dropped my version of this from the generic
ioremap series:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.
From: Christoph Hellwig @ 2019-08-20 22:28 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev, hch
In-Reply-To: <5fa3ef069fbd0f152512afaae19e7a60161454cf.1566309262.git.christophe.leroy@c-s.fr>
On Tue, Aug 20, 2019 at 02:07:13PM +0000, Christophe Leroy wrote:
> ppc_md.ioremap() is only used for I/O workaround on CELL platform,
> so indirect function call can be avoided.
>
> This patch reworks the io-workaround and ioremap() functions to
> use the global 'io_workaround_inited' flag for the activation
> of io-workaround.
>
> When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not
> selected, the I/O workaround ioremap() voids and the global flag is
> not used.
Note that CONFIG_PPC_IO_WORKAROUNDS is only selected by a specific cell
config, and CONFIG_PPC_INDIRECT_MMIO is always selected by cell, so
I think we can make CONFIG_PPC_IO_WORKAROUNDS depend on
CONFIG_PPC_INDIRECT_MMIO
> #define _IO_WORKAROUNDS_H
>
> +#ifdef CONFIG_PPC_IO_WORKAROUNDS
> #include <linux/io.h>
> #include <asm/pci-bridge.h>
>
> @@ -32,4 +33,23 @@ extern int spiderpci_iowa_init(struct iowa_bus *, void *);
> #define SPIDER_PCI_DUMMY_READ 0x0810
> #define SPIDER_PCI_DUMMY_READ_BASE 0x0814
>
> +#endif
> +
> +#if defined(CONFIG_PPC_IO_WORKAROUNDS) && defined(CONFIG_PPC_INDIRECT_MMIO)
and simplify the ifdefs here a bit.
Otherwise this looks fine:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 07/12] powerpc/mm: move ioremap_prot() into ioremap.c
From: Christoph Hellwig @ 2019-08-20 22:28 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev, hch
In-Reply-To: <0b3eb0e0f1490a99fd6c983e166fb8946233f151.1566309262.git.christophe.leroy@c-s.fr>
On Tue, Aug 20, 2019 at 02:07:15PM +0000, Christophe Leroy wrote:
> Both ioremap_prot() are idenfical, move them into ioremap.c
s/idenfical/identical/
^ permalink raw reply
* [PATCH] selftests/powerpc: Retry on host facility unavailable
From: Gustavo Romero @ 2019-08-20 22:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: desnesn, mikey, gromero
TM test tm-unavailable must take into account aborts due to host aborting
a transactin because of a facility unavailable exception, just like it
already does for aborts on reschedules (TM_CAUSE_KVM_RESCHED).
Reported-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Tested-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
---
tools/testing/selftests/powerpc/tm/tm.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/tm/tm.h b/tools/testing/selftests/powerpc/tm/tm.h
index 97f9f49..c402464 100644
--- a/tools/testing/selftests/powerpc/tm/tm.h
+++ b/tools/testing/selftests/powerpc/tm/tm.h
@@ -55,7 +55,8 @@ static inline bool failure_is_unavailable(void)
static inline bool failure_is_reschedule(void)
{
if ((failure_code() & TM_CAUSE_RESCHED) == TM_CAUSE_RESCHED ||
- (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED)
+ (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED ||
+ (failure_code() & TM_CAUSE_KVM_FAC_UNAV) == TM_CAUSE_KVM_FAC_UNAV)
return true;
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] powerpc: Don't add -mabi= flags when building with Clang
From: Nathan Chancellor @ 2019-08-20 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: clang-built-linux, Nathan Chancellor, linuxppc-dev, linux-kernel,
Daniel Axtens
In-Reply-To: <20190818191321.58185-1-natechancellor@gmail.com>
When building pseries_defconfig, building vdso32 errors out:
error: unknown target ABI 'elfv1'
This happens because -m32 in clang changes the target to 32-bit,
which does not allow the ABI to be changed, as the setABI virtual
function is not overridden:
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/include/clang/Basic/TargetInfo.h#L1073-L1078
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/lib/Basic/Targets/PPC.h#L327-L365
Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
powerpc64le toolchain") added these flags to fix building big endian
kernels with a little endian GCC.
Clang doesn't need -mabi because the target triple controls the default
value. -mlittle-endian and -mbig-endian manipulate the triple into
either powerpc64-* or powerpc64le-*, which properly sets the default
ABI:
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/lib/Driver/Driver.cpp#L450-L463
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/llvm/lib/Support/Triple.cpp#L1432-L1516
https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc2/clang/lib/Basic/Targets/PPC.h#L377-L383
Adding a debug print out in the PPC64TargetInfo constructor after line
383 above shows this:
$ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null -
Default ABI: elfv1
$ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null -
Default ABI: elfv2
$ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null -
Default ABI: elfv1
$ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null -
Default ABI: elfv2
Don't specify -mabi when building with clang to avoid the build error
with -m32 and not change any code generation.
-mcall-aixdesc is not an implemented flag in clang so it can be
safely excluded as well, see commit 238abecde8ad ("powerpc: Don't
use gcc specific options on clang").
pseries_defconfig successfully builds after this patch and
powernv_defconfig and ppc44x_defconfig don't regress.
Link: https://github.com/ClangBuiltLinux/linux/issues/240
Reviewed-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Improve commit message wording and explanation.
* Add Daniel's reviewed-by.
arch/powerpc/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c345b79414a9..971b04bc753d 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -93,11 +93,13 @@ MULTIPLEWORD := -mmultiple
endif
ifdef CONFIG_PPC64
+ifndef CONFIG_CC_IS_CLANG
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
+endif
ifndef CONFIG_CC_IS_CLANG
cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align
@@ -144,6 +146,7 @@ endif
endif
CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
+ifndef CONFIG_CC_IS_CLANG
ifdef CONFIG_CPU_LITTLE_ENDIAN
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
@@ -152,6 +155,7 @@ 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
+endif
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc))
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
--
2.23.0
^ permalink raw reply related
* Re: [PATCH v5 4/7] powerpc/mm: Use UV_WRITE_PATE ucall to register a PATE
From: Sukadev Bhattiprolu @ 2019-08-21 0:04 UTC (permalink / raw)
To: Michael Ellerman
Cc: Ryan Grimm, Madhavan Srinivasan, Michael Anderson, Ram Pai,
Claudio Carvalho, kvm-ppc, Bharata B Rao, linuxppc-dev,
Ryan Grimm, Guerney Hunt, Thiago Bauermann
In-Reply-To: <871rxo7zif.fsf@concordia.ellerman.id.au>
Michael Ellerman [mpe@ellerman.id.au] wrote:
> Hi Claudio,
>
> Claudio Carvalho <cclaudio@linux.ibm.com> writes:
> > From: Michael Anderson <andmike@linux.ibm.com>
> >
> > In ultravisor enabled systems, the ultravisor creates and maintains the
> > partition table in secure memory where the hypervisor cannot access, and
> ^
> which?
>
> > therefore, the hypervisor have to do the UV_WRITE_PATE ucall whenever it
> ^ ^
> has a
> > wants to set a partition table entry (PATE).
> >
> > This patch adds the UV_WRITE_PATE ucall and uses it to set a PATE if
> > ultravisor is enabled. Additionally, this also also keeps a copy of the
> > partition table because the nestMMU does not have access to secure
> > memory. Such copy has entries for nonsecure and hypervisor partition.
>
> I'm having trouble parsing the last sentence there.
>
> Or at least it doesn't seem to match the code, or I don't understand
> either the code or the comment. More below.
Yes, good catch. We could drop the last sentence. Or maybe change the
last para to:
This patch adds the UV_WRITE_PATE ucall which is used to update
the partition table entry (PATE) for a VM (both normal and secure).
When UV is enabled, the partition table is stored in secure memory
and can only be accessed via the UV. The HV however maintains a
copy of the partition table in normal memory to allow NMMU
translations to occur (for normal VMs). The HV copy includes PATEs
for secure VMs which would currently be unused (NMMU translations
cannot access secure memory) but they would be needed as we add
functionality.
Basically, with UV, PTCR is controlled by the UV and address translations
occur based on the UV's copy of the partition table. (See also:
try_set_ptcr() in "PATCH 5/7 powerpc/mm: Write to PTCR only if ultravisor
disabled")
>
> > diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> > index 85bc81abd286..033731f5dbaa 100644
> > --- a/arch/powerpc/mm/book3s64/pgtable.c
> > +++ b/arch/powerpc/mm/book3s64/pgtable.c
> > @@ -213,34 +223,50 @@ void __init mmu_partition_table_init(void)
> > powernv_set_nmmu_ptcr(ptcr);
> > }
> >
> > -void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
> > - unsigned long dw1)
> > +/*
> > + * Global flush of TLBs and partition table caches for this lpid. The type of
> > + * flush (hash or radix) depends on what the previous use of this partition ID
> > + * was, not the new use.
> > + */
> > +static void flush_partition(unsigned int lpid, unsigned long old_patb0)
>
> A nicer API would be for the 2nd param to be a "bool radix", and have
> the caller worry about the fact that it comes from (patb0 & PATB_HR).
Agree
>
> > {
> > - unsigned long old = be64_to_cpu(partition_tb[lpid].patb0);
> > -
> > - partition_tb[lpid].patb0 = cpu_to_be64(dw0);
> > - partition_tb[lpid].patb1 = cpu_to_be64(dw1);
> > -
> > - /*
> > - * Global flush of TLBs and partition table caches for this lpid.
> > - * The type of flush (hash or radix) depends on what the previous
> > - * use of this partition ID was, not the new use.
> > - */
> > asm volatile("ptesync" : : : "memory");
> > - if (old & PATB_HR) {
> > - asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
> > + if (old_patb0 & PATB_HR) {
> > + asm volatile(PPC_TLBIE_5(%0, %1, 2, 0, 1) : :
> > "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> > - asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
> > + asm volatile(PPC_TLBIE_5(%0, %1, 2, 1, 1) : :
>
> That looks like an unrelated whitespace change.
>
> > "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> > trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
> > } else {
> > - asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
> > + asm volatile(PPC_TLBIE_5(%0, %1, 2, 0, 0) : :
>
> Ditto.
>
> > "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> > trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 0);
> > }
> > /* do we need fixup here ?*/
> > asm volatile("eieio; tlbsync; ptesync" : : : "memory");
> > }
> > +
> > +void mmu_partition_table_set_entry(unsigned int lpid, unsigned long dw0,
> > + unsigned long dw1)
> > +{
> > + unsigned long old = be64_to_cpu(partition_tb[lpid].patb0);
> > +
> > + partition_tb[lpid].patb0 = cpu_to_be64(dw0);
> > + partition_tb[lpid].patb1 = cpu_to_be64(dw1);
>
> ie. here we always update the copy of the partition table, regardless of
> whether we're running under an ultravisor or not. So the copy is a
> complete copy isn't it?
Yes.
>
> > + /*
> > + * In ultravisor enabled systems, the ultravisor maintains the partition
> > + * table in secure memory where we don't have access, therefore, we have
> > + * to do a ucall to set an entry.
> > + */
> > + if (firmware_has_feature(FW_FEATURE_ULTRAVISOR)) {
> > + uv_register_pate(lpid, dw0, dw1);
> > + pr_info("PATE registered by ultravisor: dw0 = 0x%lx, dw1 = 0x%lx\n",
> > + dw0, dw1);
> > + } else {
> > + flush_partition(lpid, old);
> > + }
>
> What is different is whether we flush or not.
only differences are where the partition table used by hardware is stored
(secure memory) and updated (in UV, with higher privilege).
>
> And don't we still need to do the flush for the nestMMU? I assume we're
> saying the ultravisor will broadcast a flush for us, which will also
> handle the nestMMU case?
The same sequence of instructions (as HV) are used in uv_register_pate()
to flush partition and process scoped entries (so nest MMU would also be
covered when NMMU sees the tlbie?)
Thanks,
Sukadev
^ permalink raw reply
* [PATCH v2] powerpc: Allow flush_(inval_)dcache_range to work across ranges >4GB
From: Alastair D'Silva @ 2019-08-21 0:19 UTC (permalink / raw)
To: alastair
Cc: linux-kernel, stable, Paul Mackerras, Greg Kroah-Hartman,
Thomas Gleixner, linuxppc-dev, Allison Randal
From: Alastair D'Silva <alastair@d-silva.org>
The upstream commit:
22e9c88d486a ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
has a similar effect, but since it is a rewrite of the assembler to C, is
too invasive for stable. This patch is a minimal fix to address the issue in
assembler.
This patch applies cleanly to v5.2, v4.19 & v4.14.
When calling flush_(inval_)dcache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.
This patch replaces the 32 bit shifts with 64 bit ones, so that
the full size is accounted for.
Changelog:
v2
- Add related upstream commit
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
arch/powerpc/kernel/misc_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 1ad4089dd110..d4d096f80f4b 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -130,7 +130,7 @@ _GLOBAL_TOC(flush_dcache_range)
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
lwz r9,DCACHEL1LOGBLOCKSIZE(r10) /* Get log-2 of dcache block size */
- srw. r8,r8,r9 /* compute line count */
+ srd. r8,r8,r9 /* compute line count */
beqlr /* nothing to do? */
mtctr r8
0: dcbst 0,r6
@@ -148,7 +148,7 @@ _GLOBAL(flush_inval_dcache_range)
subf r8,r6,r4 /* compute length */
add r8,r8,r5 /* ensure we get enough */
lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of dcache block size */
- srw. r8,r8,r9 /* compute line count */
+ srd. r8,r8,r9 /* compute line count */
beqlr /* nothing to do? */
sync
isync
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.
From: Benjamin Herrenschmidt @ 2019-08-21 0:42 UTC (permalink / raw)
To: Christoph Hellwig, Christophe Leroy
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, npiggin
In-Reply-To: <20190820222828.GC18433@lst.de>
On Wed, 2019-08-21 at 00:28 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 02:07:13PM +0000, Christophe Leroy wrote:
> > ppc_md.ioremap() is only used for I/O workaround on CELL platform,
> > so indirect function call can be avoided.
> >
> > This patch reworks the io-workaround and ioremap() functions to
> > use the global 'io_workaround_inited' flag for the activation
> > of io-workaround.
> >
> > When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not
> > selected, the I/O workaround ioremap() voids and the global flag is
> > not used.
>
> Note that CONFIG_PPC_IO_WORKAROUNDS is only selected by a specific cell
> config, and CONFIG_PPC_INDIRECT_MMIO is always selected by cell, so
> I think we can make CONFIG_PPC_IO_WORKAROUNDS depend on
> CONFIG_PPC_INDIRECT_MMIO
Or we can deprecate that old platform... not sure anybody uses it
anymore (if anybody ever did).
Cheers,
ben.
^ permalink raw reply
* Re: [PATCH v4 2/7] kexec_elf: change order of elf_*_to_cpu() functions
From: Thiago Jung Bauermann @ 2019-08-21 0:59 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-3-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> Change the order to have a 64/32/16 order, no functional change.
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 3/7] kexec_elf: remove parsing of section headers
From: Thiago Jung Bauermann @ 2019-08-21 0:59 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-4-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> We're not using them, so we can drop the parsing.
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 4/7] kexec_elf: remove PURGATORY_STACK_SIZE
From: Thiago Jung Bauermann @ 2019-08-21 1:00 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-5-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> It's not used anywhere so just drop it.
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
> kernel/kexec_elf.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
> index effe9dc0b055..70d31b8feeae 100644
> --- a/kernel/kexec_elf.c
> +++ b/kernel/kexec_elf.c
> @@ -8,8 +8,6 @@
> #include <linux/slab.h>
> #include <linux/types.h>
>
> -#define PURGATORY_STACK_SIZE (16 * 1024)
> -
> #define elf_addr_to_cpu elf64_to_cpu
>
> #ifndef Elf_Rel
Can you remove it from the file in arch/powerpc as well?
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 5/7] kexec_elf: remove Elf_Rel macro
From: Thiago Jung Bauermann @ 2019-08-21 1:01 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-6-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> It wasn't used anywhere, so lets drop it.
>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
> kernel/kexec_elf.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
> index 70d31b8feeae..e346659af324 100644
> --- a/kernel/kexec_elf.c
> +++ b/kernel/kexec_elf.c
> @@ -10,10 +10,6 @@
>
> #define elf_addr_to_cpu elf64_to_cpu
>
> -#ifndef Elf_Rel
> -#define Elf_Rel Elf64_Rel
> -#endif /* Elf_Rel */
> -
> static inline bool elf_is_elf_file(const struct elfhdr *ehdr)
> {
> return memcmp(ehdr->e_ident, ELFMAG, SELFMAG) == 0;
Could you remove this one from the file in arch/powerpc as well? Perhaps
this and the previous patch could be placed before patch 1, so that this
change can be done only once.
In any case:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 6/7] kexec_elf: remove unused variable in kexec_elf_load()
From: Thiago Jung Bauermann @ 2019-08-21 1:02 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-7-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> base was never assigned, so we can remove it.
>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
> kernel/kexec_elf.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
> index e346659af324..9421eebbacf0 100644
> --- a/kernel/kexec_elf.c
> +++ b/kernel/kexec_elf.c
> @@ -350,7 +350,7 @@ int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,
> struct kexec_buf *kbuf,
> unsigned long *lowest_load_addr)
> {
> - unsigned long base = 0, lowest_addr = UINT_MAX;
> + unsigned long lowest_addr = UINT_MAX;
> int ret;
> size_t i;
>
> @@ -372,7 +372,7 @@ int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,
> kbuf->bufsz = size;
> kbuf->memsz = phdr->p_memsz;
> kbuf->buf_align = phdr->p_align;
> - kbuf->buf_min = phdr->p_paddr + base;
> + kbuf->buf_min = phdr->p_paddr;
> ret = kexec_add_buffer(kbuf);
> if (ret)
> goto out;
> @@ -382,9 +382,6 @@ int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,
> lowest_addr = load_addr;
> }
>
> - /* Update entry point to reflect new load address. */
> - ehdr->e_entry += base;
> -
> *lowest_load_addr = lowest_addr;
> ret = 0;
> out:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 7/7] kexec_elf: support 32 bit ELF files
From: Thiago Jung Bauermann @ 2019-08-21 1:03 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-8-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> The powerpc version only supported 64 bit. Add some
> code to switch decoding of fields during runtime so
> we can kexec a 32 bit kernel from a 64 bit kernel and
> vice versa.
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 1/7] kexec: add KEXEC_ELF
From: Thiago Jung Bauermann @ 2019-08-21 0:58 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-2-svens@stackframe.org>
Hello Sven,
Just a few small comments below. Regardless of them:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Sven Schnelle <svens@stackframe.org> writes:
> Right now powerpc provides an implementation to read elf files
> with the kexec_file() syscall. Make that available as a public
Nit: the syscall is kexec_file_load()
> kexec interface so it can be re-used on other architectures.
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
> arch/Kconfig | 3 +
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/kernel/kexec_elf_64.c | 551 +-----------------
> include/linux/kexec.h | 24 +
> kernel/Makefile | 1 +
> .../kexec_elf_64.c => kernel/kexec_elf.c | 199 ++-----
> 6 files changed, 75 insertions(+), 704 deletions(-)
> copy arch/powerpc/kernel/kexec_elf_64.c => kernel/kexec_elf.c (71%)
<snip>
> diff --git a/arch/powerpc/kernel/kexec_elf_64.c b/arch/powerpc/kernel/kexec_elf_64.c
> index ba4f18a43ee8..30bd57a93c17 100644
> --- a/arch/powerpc/kernel/kexec_elf_64.c
> +++ b/arch/powerpc/kernel/kexec_elf_64.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> /*
> * Load ELF vmlinux file for the kexec_file_load syscall.
> *
> @@ -10,15 +11,6 @@
> * Based on kexec-tools' kexec-elf-exec.c and kexec-elf-ppc64.c.
> * Heavily modified for the kernel by
> * Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation (version 2 of the License).
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> */
>
> #define pr_fmt(fmt) "kexec_elf: " fmt
> @@ -39,532 +31,6 @@
> #define Elf_Rel Elf64_Rel
> #endif /* Elf_Rel */
Perhaps this patch could remove the #define for elf_addr_to_cpu since
it's not used anymore in this file?
> diff --git a/arch/powerpc/kernel/kexec_elf_64.c b/kernel/kexec_elf.c
> similarity index 71%
> copy from arch/powerpc/kernel/kexec_elf_64.c
> copy to kernel/kexec_elf.c
> index ba4f18a43ee8..6e9f52171ede 100644
> --- a/arch/powerpc/kernel/kexec_elf_64.c
> +++ b/kernel/kexec_elf.c
> @@ -1,33 +1,10 @@
> -/*
> - * Load ELF vmlinux file for the kexec_file_load syscall.
> - *
> - * Copyright (C) 2004 Adam Litke (agl@us.ibm.com)
> - * Copyright (C) 2004 IBM Corp.
> - * Copyright (C) 2005 R Sharada (sharada@in.ibm.com)
> - * Copyright (C) 2006 Mohan Kumar M (mohan@in.ibm.com)
> - * Copyright (C) 2016 IBM Corporation
> - *
> - * Based on kexec-tools' kexec-elf-exec.c and kexec-elf-ppc64.c.
> - * Heavily modified for the kernel by
> - * Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation (version 2 of the License).
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> +// SPDX-License-Identifier: GPL-2.0-only
I may be wrong, but my understanding of the SPDX license identifier is
that it substitutes the license text (i.e., the last two paragraphs
above), but not the copyright statements. Is it ok to have a file with a
SPDX license identifier but no copyright statement?
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 0/7] kexec: add generic support for elf kernel images
From: Thiago Jung Bauermann @ 2019-08-21 1:11 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <20190715082702.27308-1-svens@stackframe.org>
Sven Schnelle <svens@stackframe.org> writes:
> Changes to v3:
> - add support for 32-bit ELF files
>
> Changes to v2:
> - use git format-patch -C
>
> Changes to v1:
> - split up patch into smaller pieces
> - rebase onto powerpc/next
> - remove unused variable in kexec_elf_load()
>
> Changes to RFC version:
> - remove unused Elf_Rel macro
> - remove section header parsing
> - remove PURGATORY_STACK_SIZE
> - change order of elf_*_to_cpu() functions
> - remove elf_addr_to_cpu macro
>
> Sven Schnelle (7):
> kexec: add KEXEC_ELF
> kexec_elf: change order of elf_*_to_cpu() functions
> kexec_elf: remove parsing of section headers
> kexec_elf: remove PURGATORY_STACK_SIZE
> kexec_elf: remove Elf_Rel macro
> kexec_elf: remove unused variable in kexec_elf_load()
> kexec_elf: support 32 bit ELF files
>
> arch/Kconfig | 3 +
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/kernel/kexec_elf_64.c | 551 +----------------------------
> include/linux/kexec.h | 23 ++
> kernel/Makefile | 1 +
> kernel/kexec_elf.c | 418 ++++++++++++++++++++++
> 6 files changed, 456 insertions(+), 541 deletions(-)
> create mode 100644 kernel/kexec_elf.c
The series applies on v5.1 but not newer kernels, so it needs to be
rebased.
I tested with v5.1 in ppc64le kexecing to both little-endian and
big-endian kernels, and also in ppc64 kexecing to both big-endian and
little-endian kernels so:
Tested-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 4/7] kexec_elf: remove PURGATORY_STACK_SIZE
From: Thiago Jung Bauermann @ 2019-08-21 1:13 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev, deller, Sven Schnelle
In-Reply-To: <87v9urmixq.fsf@morokweng.localdomain>
Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
> Sven Schnelle <svens@stackframe.org> writes:
>
>> It's not used anywhere so just drop it.
>>
>> Signed-off-by: Sven Schnelle <svens@stackframe.org>
>> ---
>> kernel/kexec_elf.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c
>> index effe9dc0b055..70d31b8feeae 100644
>> --- a/kernel/kexec_elf.c
>> +++ b/kernel/kexec_elf.c
>> @@ -8,8 +8,6 @@
>> #include <linux/slab.h>
>> #include <linux/types.h>
>>
>> -#define PURGATORY_STACK_SIZE (16 * 1024)
>> -
>> #define elf_addr_to_cpu elf64_to_cpu
>>
>> #ifndef Elf_Rel
>
> Can you remove it from the file in arch/powerpc as well?
Sorry, forgot to add:
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ 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