* [PATCH 37/38] cxlflash: Support AFU reset
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
Manoj N. Kumar
Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>
The cxlflash core driver resets the AFU when the master contexts are
created in the initialization or recovery paths. Today, the OCXL
provider service to perform this operation is pending implementation.
To avoid a crash due to a missing fop, log an error once and return
success to continue with execution.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
drivers/scsi/cxlflash/ocxl_hw.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index dc45ed2..8a1a9fc 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -468,6 +468,22 @@ static int ocxlflash_stop_context(void *ctx_cookie)
}
/**
+ * ocxlflash_afu_reset() - reset the AFU
+ * @ctx_cookie: Adapter context.
+ */
+static int ocxlflash_afu_reset(void *ctx_cookie)
+{
+ struct ocxlflash_context *ctx = ctx_cookie;
+ struct device *dev = ctx->hw_afu->dev;
+
+ /* Pending implementation from OCXL transport services */
+ dev_err_once(dev, "%s: afu_reset() fop not supported\n", __func__);
+
+ /* Silently return success until it is implemented */
+ return 0;
+}
+
+/**
* ocxlflash_set_master() - sets the context as master
* @ctx_cookie: Adapter context to set as master.
*/
@@ -1393,6 +1409,7 @@ const struct cxlflash_backend_ops cxlflash_ocxl_ops = {
.get_irq_objhndl = ocxlflash_get_irq_objhndl,
.start_context = ocxlflash_start_context,
.stop_context = ocxlflash_stop_context,
+ .afu_reset = ocxlflash_afu_reset,
.set_master = ocxlflash_set_master,
.get_context = ocxlflash_get_context,
.dev_context_init = ocxlflash_dev_context_init,
--
2.1.0
^ permalink raw reply related
* [PATCH 38/38] cxlflash: Enable OpenCXL operations
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
Manoj N. Kumar
Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>
This commit enables the OpenCXL operations for the OpenCXL devices.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
drivers/scsi/cxlflash/main.c | 9 +++++++--
drivers/scsi/cxlflash/main.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 8c55fcd..42a95b7 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -3168,7 +3168,8 @@ static struct dev_dependent_vals dev_corsa_vals = { CXLFLASH_MAX_SECTORS,
static struct dev_dependent_vals dev_flash_gt_vals = { CXLFLASH_MAX_SECTORS,
CXLFLASH_NOTIFY_SHUTDOWN };
static struct dev_dependent_vals dev_briard_vals = { CXLFLASH_MAX_SECTORS,
- CXLFLASH_NOTIFY_SHUTDOWN };
+ (CXLFLASH_NOTIFY_SHUTDOWN |
+ CXLFLASH_OCXL_DEV) };
/*
* PCI device binding table
@@ -3679,9 +3680,13 @@ static int cxlflash_probe(struct pci_dev *pdev,
cfg->init_state = INIT_STATE_NONE;
cfg->dev = pdev;
- cfg->ops = &cxlflash_cxl_ops;
cfg->cxl_fops = cxlflash_cxl_fops;
+ if (ddv->flags & CXLFLASH_OCXL_DEV)
+ cfg->ops = &cxlflash_ocxl_ops;
+ else
+ cfg->ops = &cxlflash_cxl_ops;
+
/*
* Promoted LUNs move to the top of the LUN table. The rest stay on
* the bottom half. The bottom half grows from the end (index = 255),
diff --git a/drivers/scsi/cxlflash/main.h b/drivers/scsi/cxlflash/main.h
index ba0108a..6f1be62 100644
--- a/drivers/scsi/cxlflash/main.h
+++ b/drivers/scsi/cxlflash/main.h
@@ -97,6 +97,7 @@ struct dev_dependent_vals {
u64 flags;
#define CXLFLASH_NOTIFY_SHUTDOWN 0x0000000000000001ULL
#define CXLFLASH_WWPN_VPD_REQUIRED 0x0000000000000002ULL
+#define CXLFLASH_OCXL_DEV 0x0000000000000004ULL
};
struct asyc_intr_info {
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 4.9 34/77] powerpc: fix build errors in stable tree
From: Michael Ellerman @ 2018-02-22 22:31 UTC (permalink / raw)
To: Yves-Alexis Perez, Greg Kroah-Hartman, linux-kernel
Cc: stable, Guenter Roeck, Nicholas Piggin, linuxppc-dev
In-Reply-To: <1519306335.2388.18.camel@debian.org>
Yves-Alexis Perez <corsac@debian.org> writes:
> On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
>> With the patches I just sent, for pseries and powernv, the mitigation
>> should be in place. On machines with updated firmware we'll use the
>> hardware-assisted L1 flush, otherwise we fallback to doing it in
>> software.
>
> So as of 4.9.82 meltdown is *not* addressed on those arches, but it should be
> ok in 4.9.83 or 4.9.84 depending on when the patches are merged?
As of 4.9.82 *most* of the patches to do the mitigation have been
merged.
One of them was missed, due to it not applying (because it was actually
a back port to 4.4 that was sent) that is:
222f20f14062 ("powerpc/64s: Simple RFI macro conversions")
That patch adds calls to do the L1D cache flush when returning to
user/guest, so it is important that it's missing, the mitigation is not
fully effective without that patch.
However, 4.9.82 *does* have a backport of:
b8e90cb7bc04 ("powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL")
So the syscall path is protected, which means any attack which uses
syscalls is likely to fail.
Because the data the attack is trying to read has to be in the L1D, you
can't write an attack that remains in userspace 100% of the time, you
have to enter the kernel and have the kernel load the target data into
the L1D for you. With the syscall flush in place you can't use a syscall
for that, you have to trigger some other kernel entry/exit, eg. a page
fault.
TLDR is with the syscall flush in place it's much harder to write an
attack.
Greg has already released 4.9.83, so hopefully 4.9.84 will be fully
protected.
Note also that 4.9.82/83 have a bug in the SLB miss handler that can
lead to hangs in userspace, fixed by the first patch I sent.
cheers
^ permalink raw reply
* Re: [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Michael Ellerman @ 2018-02-22 22:34 UTC (permalink / raw)
To: Vaibhav Jain, Russell Currey
Cc: Vaibhav Jain, Frederic Barrat, linuxppc-dev,
Benjamin Herrenschmidt, Bryant G . Ly
In-Reply-To: <20180222115803.21738-1-vaibhav@linux.vnet.ibm.com>
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> writes:
> This patch puts a NULL check before branching to the address pointed
> to by eeh_ops->notify_resume in eeh_report_resume(). The callback
> is used to notify the arch EEH code that a pci device is back
> online.
>
> For PPC64 presently, only an implementation for pseries platform is
> available and not for powernv. Hence without this patch EEH recovery
> on all non-virtualized hosts is causing a kernel panic when
> CONFIG_PCI_IOV is set. The panic is usually is of the form:
>
> EEH: Notify device driver to resume
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0x00000000
> Oops: Kernel access of bad area, sig: 11 [#1]
> <snip>
> LR eeh_report_resume+0x218/0x220
> Call Trace:
> eeh_report_resume+0x1f0/0x220 (unreliable)
> eeh_pe_dev_traverse+0x98/0x170
> eeh_handle_normal_event+0x3f4/0x650
> eeh_handle_event+0x188/0x380
> eeh_event_handler+0x208/0x210
> kthread+0x168/0x1b0
> ret_from_kernel_thread+0x5c/0xb4
>
> Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
> Fixes: 856e1eb9bdd4("PCI/AER: Add uevents in AER and EEH error/resume")
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
10 out of 10 for the change log!
But yeah this is already fixed in my fixes branch, thanks anyway.
cheers
^ permalink raw reply
* [PATCH 15/38] cxlflash: Support image reload policy modification
From: Uma Krishnan @ 2018-02-22 22:24 UTC (permalink / raw)
To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
Manoj N. Kumar
Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On a PERST, the AFU image can be reloaded or left intact. Provide means to
set this image reload policy.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
drivers/scsi/cxlflash/ocxl_hw.c | 13 +++++++++++++
drivers/scsi/cxlflash/ocxl_hw.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 2dab547..6f78e71 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -252,6 +252,18 @@ static int ocxlflash_release_context(void *ctx_cookie)
}
/**
+ * ocxlflash_perst_reloads_same_image() - sets the image reload policy
+ * @afu_cookie: Hardware AFU associated with the host.
+ * @image: Whether to load the same image on PERST.
+ */
+static void ocxlflash_perst_reloads_same_image(void *afu_cookie, bool image)
+{
+ struct ocxl_hw_afu *afu = afu_cookie;
+
+ afu->perst_same_image = image;
+}
+
+/**
* ocxlflash_destroy_afu() - destroy the AFU structure
* @afu_cookie: AFU to be freed.
*/
@@ -493,6 +505,7 @@ const struct cxlflash_backend_ops cxlflash_ocxl_ops = {
.get_context = ocxlflash_get_context,
.dev_context_init = ocxlflash_dev_context_init,
.release_context = ocxlflash_release_context,
+ .perst_reloads_same_image = ocxlflash_perst_reloads_same_image,
.create_afu = ocxlflash_create_afu,
.destroy_afu = ocxlflash_destroy_afu,
.get_fd = ocxlflash_get_fd,
diff --git a/drivers/scsi/cxlflash/ocxl_hw.h b/drivers/scsi/cxlflash/ocxl_hw.h
index 7f234b1..6d6e323 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.h
+++ b/drivers/scsi/cxlflash/ocxl_hw.h
@@ -17,6 +17,7 @@ struct ocxl_hw_afu {
struct ocxlflash_context *ocxl_ctx; /* Host context */
struct pci_dev *pdev; /* PCI device */
struct device *dev; /* Generic device */
+ bool perst_same_image; /* Same image loaded on perst */
struct ocxl_fn_config fcfg; /* DVSEC config of the function */
struct ocxl_afu_config acfg; /* AFU configuration data */
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Michael Ellerman @ 2018-02-22 22:38 UTC (permalink / raw)
To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
Nicolas Ferre, Alexandre Belloni, Eric Anholt, Stefan Wahren,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Linus Walleij, Support Opensource,
Baruch Siach, William Breathitt Gray, Jimmy Vance, Keguang Zhang,
Joachim Eastwood, Tomas Winkler, Johannes Thumshirn,
Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras, Jun Nie,
Baoyou Xie, Shawn Guo
Cc: Marcus Folkesson, linux-watchdog, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, adi-buildroot-devel, linux-mips, linux-amlogic,
linux-mediatek, linux-samsung-soc, linux-tegra, linuxppc-dev,
patches, Utz Bacher
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>
Marcus Folkesson <marcus.folkesson@gmail.com> writes:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> license
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
<snip>
> diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
> index 0240c60d14e3..af07f746b7cc 100644
> --- a/drivers/watchdog/wdrtas.c
> +++ b/drivers/watchdog/wdrtas.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
> /*
> * FIXME: add wdrtas_get_status and wdrtas_get_boot_status as soon as
> * RTAS calls are available
> @@ -10,20 +11,6 @@
> * device driver to exploit watchdog RTAS functions
> *
> * Authors : Utz Bacher <utz.bacher@de.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; either version 2, or (at your option)
> - * any later version.
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> */
LGTM.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Bjorn Helgaas @ 2018-02-22 23:12 UTC (permalink / raw)
To: Bryant G. Ly
Cc: Michael Ellerman, bhelgaas, linux-pci, linuxppc-dev, torvalds,
ruscur, jjalvare
In-Reply-To: <dcfc6411-20cf-5b3f-20c5-14167de54700@linux.vnet.ibm.com>
On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote:
>
> On 2/8/18 6:20 AM, Michael Ellerman wrote:
>
> > There's no reason pci_uevent_ers() needs to be inline in pci.h, so
> > move it out to a C file.
> >
> > Given it's used by AER the obvious location would be somewhere in
> > drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
> > unfortunately that doesn't work in the case where EEH is enabled but
> > PCIEPORTBUS is not.
> >
> > So for now put it in pci-driver.c, next to pci_uevent(), with an
> > appropriate #ifdef so it's not built if AER and EEH are both disabled.
> >
> > While we're moving it also fix up the kernel doc comment for @pdev to
> > be accurate.
> >
> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > ---
> > drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
> > include/linux/pci.h | 38 +++-----------------------------------
> > 2 files changed, 39 insertions(+), 35 deletions(-)
>
> Looks good, thanks for fixing it!
>
> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
This would normally be a "Reviewed-by" unless you actually
participated in developing the patch, and in that case, your
"Signed-off-by" would normally be included in the original posting.
What do you intend? I'll be glad to add either.
Bjorn
^ permalink raw reply
* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Bjorn Helgaas @ 2018-02-22 23:12 UTC (permalink / raw)
To: Michael Ellerman
Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, bryantly,
jjalvare
In-Reply-To: <20180208122035.9305-1-mpe@ellerman.id.au>
On Thu, Feb 08, 2018 at 11:20:35PM +1100, Michael Ellerman wrote:
> There's no reason pci_uevent_ers() needs to be inline in pci.h, so
> move it out to a C file.
>
> Given it's used by AER the obvious location would be somewhere in
> drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
> unfortunately that doesn't work in the case where EEH is enabled but
> PCIEPORTBUS is not.
>
> So for now put it in pci-driver.c, next to pci_uevent(), with an
> appropriate #ifdef so it's not built if AER and EEH are both disabled.
>
> While we're moving it also fix up the kernel doc comment for @pdev to
> be accurate.
>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to pci/aer for v4.17, thanks!
> ---
> drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
> include/linux/pci.h | 38 +++-----------------------------------
> 2 files changed, 39 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 3bed6beda051..f21e8b1bef80 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1517,6 +1517,42 @@ static int pci_uevent(struct device *dev, struct kobj_uevent_env *env)
> return 0;
> }
>
> +#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
> +/**
> + * pci_uevent_ers - emit a uevent during recovery path of pci device
> + * @pdev: pci device undergoing error recovery
> + * @err_type: type of error event
> + */
> +void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type)
> +{
> + int idx = 0;
> + char *envp[3];
> +
> + switch (err_type) {
> + case PCI_ERS_RESULT_NONE:
> + case PCI_ERS_RESULT_CAN_RECOVER:
> + envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
> + envp[idx++] = "DEVICE_ONLINE=0";
> + break;
> + case PCI_ERS_RESULT_RECOVERED:
> + envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
> + envp[idx++] = "DEVICE_ONLINE=1";
> + break;
> + case PCI_ERS_RESULT_DISCONNECT:
> + envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
> + envp[idx++] = "DEVICE_ONLINE=0";
> + break;
> + default:
> + break;
> + }
> +
> + if (idx > 0) {
> + envp[idx++] = NULL;
> + kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
> + }
> +}
> +#endif
> +
> static int pci_bus_num_vf(struct device *dev)
> {
> return pci_num_vf(to_pci_dev(dev));
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 024a1beda008..19c1dbcff0c6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2280,41 +2280,9 @@ static inline bool pci_is_thunderbolt_attached(struct pci_dev *pdev)
> return false;
> }
>
> -/**
> - * pci_uevent_ers - emit a uevent during recovery path of pci device
> - * @pdev: pci device to check
> - * @err_type: type of error event
> - *
> - */
> -static inline void pci_uevent_ers(struct pci_dev *pdev,
> - enum pci_ers_result err_type)
> -{
> - int idx = 0;
> - char *envp[3];
> -
> - switch (err_type) {
> - case PCI_ERS_RESULT_NONE:
> - case PCI_ERS_RESULT_CAN_RECOVER:
> - envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
> - envp[idx++] = "DEVICE_ONLINE=0";
> - break;
> - case PCI_ERS_RESULT_RECOVERED:
> - envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
> - envp[idx++] = "DEVICE_ONLINE=1";
> - break;
> - case PCI_ERS_RESULT_DISCONNECT:
> - envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
> - envp[idx++] = "DEVICE_ONLINE=0";
> - break;
> - default:
> - break;
> - }
> -
> - if (idx > 0) {
> - envp[idx++] = NULL;
> - kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
> - }
> -}
> +#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
> +void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type);
> +#endif
>
> /* Provide the legacy pci_dma_* API */
> #include <linux/pci-dma-compat.h>
> --
> 2.14.1
>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig
From: Stewart Smith @ 2018-02-23 0:16 UTC (permalink / raw)
To: Michael Ellerman, Brian King, Guilherme G. Piccoli
Cc: linuxppc-dev, dougmill@us.ibm.com
In-Reply-To: <87y3jkpt0p.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Brian King <brking@linux.vnet.ibm.com> writes:
>> On 09/03/2017 06:19 PM, Stewart Smith wrote:
>>> Michael Ellerman <mpe@ellerman.id.au> writes:
>>>>> 2. On a bare metal machine, if you set ipr.fast_reboot=1 on the skiboot
>>>>> kernel, then we should also avoid resetting the ipr adapter, so ipr
>>>>> init on the kernel being kexec booted from skiboot should be extremely fast.
>>>>
>>>> OK, I didn't know that was an option, so that might help.
>>>>
>>>>> ...
>>>>> If you've got cases where ipr init is taking a long time, I'd be
>>>>> interested to know what scenarios are the most annoying to see if there
>>>>> is any opportunity to improve.
>>>>
>>>> Yeah booting bare metal is where I see it (not using ipr.fast_reboot).
>>>
>>> Hrm... We should probably enable that by default for petitboot then.
>>>
>>> It'd at least cut some time off booting straight through to OS.
>>
>> Agreed. I'd be interested to hear if that helps address the issue
>> Michael is seeing.
>>
>> You can easily test this by exiting to a petitboot shell:
>>
>> echo 1 > /sys/module/ipr/parameters/fast_reboot
>>
>> Then go back to petitboot and boot the OS.
>
> Just following up on this (!).
>
> This does work, and I've now been running it in my CI for about a month
> (~1000 boots) with no problems.
>
> You can also make it persistent by doing:
>
> $ nvram -p ibm,skiboot --update-config bootargs="ipr.fast_reboot=1"
Okay, cool. https://github.com/open-power/op-build/pull/1900 will set it
in firmware - we may as well run with this and fix any bugs we find.
Any reason why it isn't the default behaviour?
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Michael Ellerman @ 2018-02-23 4:09 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, bryantly,
jjalvare
In-Reply-To: <20180222231251.GC14632@bhelgaas-glaptop.roam.corp.google.com>
Bjorn Helgaas <helgaas@kernel.org> writes:
> On Thu, Feb 08, 2018 at 11:20:35PM +1100, Michael Ellerman wrote:
>> There's no reason pci_uevent_ers() needs to be inline in pci.h, so
>> move it out to a C file.
>>
>> Given it's used by AER the obvious location would be somewhere in
>> drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
>> unfortunately that doesn't work in the case where EEH is enabled but
>> PCIEPORTBUS is not.
>>
>> So for now put it in pci-driver.c, next to pci_uevent(), with an
>> appropriate #ifdef so it's not built if AER and EEH are both disabled.
>>
>> While we're moving it also fix up the kernel doc comment for @pdev to
>> be accurate.
>>
>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Applied to pci/aer for v4.17, thanks!
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Michael Ellerman @ 2018-02-23 4:10 UTC (permalink / raw)
To: Bjorn Helgaas, Bryant G. Ly
Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, jjalvare
In-Reply-To: <20180222231236.GB14632@bhelgaas-glaptop.roam.corp.google.com>
Bjorn Helgaas <helgaas@kernel.org> writes:
> On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote:
>>
>> On 2/8/18 6:20 AM, Michael Ellerman wrote:
>>
>> > There's no reason pci_uevent_ers() needs to be inline in pci.h, so
>> > move it out to a C file.
>> >
>> > Given it's used by AER the obvious location would be somewhere in
>> > drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
>> > unfortunately that doesn't work in the case where EEH is enabled but
>> > PCIEPORTBUS is not.
>> >
>> > So for now put it in pci-driver.c, next to pci_uevent(), with an
>> > appropriate #ifdef so it's not built if AER and EEH are both disabled.
>> >
>> > While we're moving it also fix up the kernel doc comment for @pdev to
>> > be accurate.
>> >
>> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> > ---
>> > drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
>> > include/linux/pci.h | 38 +++-----------------------------------
>> > 2 files changed, 39 insertions(+), 35 deletions(-)
>>
>> Looks good, thanks for fixing it!
>>
>> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
>
> This would normally be a "Reviewed-by" unless you actually
> participated in developing the patch, and in that case, your
> "Signed-off-by" would normally be included in the original posting.
>
> What do you intend? I'll be glad to add either.
I wrote the patch, so Bryant meant Reviewed-by or maybe Acked-by.
cheers
^ permalink raw reply
* Re: [PATCH 00/38] cxlflash: OpenCXL transport support
From: Andrew Donnellan @ 2018-02-23 4:13 UTC (permalink / raw)
To: Uma Krishnan, linux-scsi, James Bottomley, Martin K. Petersen,
Matthew R. Ochs, Manoj N. Kumar
Cc: linuxppc-dev, Frederic Barrat, Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On 23/02/18 09:20, Uma Krishnan wrote:
> This patch series adds OpenCXL support to the cxlflash driver. With
> this support, new devices using the OpenCXL transport will be supported
> by the cxlflash driver along with the existing CXL devices. An effort is
> made to keep this transport specific function independent of the existing
> core driver that communicates with the AFU.
It's "OpenCAPI" for the standard, and "ocxl" for the driver - I'd rather
not add "OpenCXL" to our already somewhat confusing proliferation of
names :)
I'll try to review as much of the ocxl-specific stuff as I can get to,
though I'm a bit busy with the OpenCAPI skiboot work and reviewing the
libocxl userspace library at the moment.
Andrew
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 04/38] cxlflash: Introduce OpenCXL backend
From: Andrew Donnellan @ 2018-02-23 4:28 UTC (permalink / raw)
To: Uma Krishnan, linux-scsi, James Bottomley, Martin K. Petersen,
Matthew R. Ochs, Manoj N. Kumar
Cc: linuxppc-dev, Frederic Barrat, Christophe Lombard
In-Reply-To: <1519338163-51928-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On 23/02/18 09:22, Uma Krishnan wrote:
> Add initial infrastructure to support a new cxlflash transport, OpenCXL.
>
> Claim a dependency on OpenCXL (OCXL) and add a new file, ocxl_hw.c, which
> will host the backend routines that are specific to OpenCXL.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Is it necessary to depend on OCXL in all cases? IMHO it should be
possible to build a cxl-only version without ocxl, though I don't feel
very strongly on this.
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: powerpc: Revert support for ibm,drc-info devtree property
From: Michael Ellerman @ 2018-02-23 5:39 UTC (permalink / raw)
To: Michael Bringmann, linuxppc-dev; +Cc: Nathan Fontenot, Michael Ellerman
In-Reply-To: <f5baf8d9-ece2-d3b8-2793-7701a1184c2a@linux.vnet.ibm.com>
On Tue, 2018-02-13 at 20:02:53 UTC, Michael Bringmann wrote:
> This reverts commit 02ef6dd8109b581343ebeb1c4c973513682535d6.
>
> The earlier patch tried to enable support for a new property
> "ibm,drc-info" on powerpc systems.
>
> Unfortunately, some errors in the associated patch set break things
> in some of the DLPAR operations. In particular when attempting to
> hot-add a new CPU or set of CPUs, the original patch failed to
> properly calculate the available resources, and aborted the operation.
> In addition, the original set missed several opportunities to compress
> and reuse common code.
>
> As the associated patch set was meant to provide an optimization of
> storage and performance of a set of device-tree properties for future
> systems with large amounts of resources, reverting just restores
> the previous behavior for existing systems. It seems unnecessary
> to enable this feature and introduce the consequent problems in the
> field that it will cause at this time, so please revert it for now
> until testing of the corrections are finished properly.
>
> Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/c7a3275e0f9e461bb8942132aa6914
cheers
^ permalink raw reply
* Re: bpf, powerpc: fix jit for seccomp_data access
From: Michael Ellerman @ 2018-02-23 5:39 UTC (permalink / raw)
To: Mark Lord, Naveen N. Rao, Alexei Starovoitov, Daniel Borkmann,
Kees Cook, Andy Lutomirski, Will Drewry
Cc: linuxppc-dev
In-Reply-To: <2f428cf9-23f3-d1f1-1524-46d6faa17386@pobox.com>
On Tue, 2018-02-20 at 19:49:20 UTC, Mark Lord wrote:
> I am using SECCOMP to filter syscalls on a ppc32 platform,
> and noticed that the JIT compiler was failing on the BPF
> even though the interpreter was working fine.
>
> The issue was that the compiler was missing one of the instructions
> used by SECCOMP, so here is a patch to enable JIT for that instruction.
>
> Signed-Off-By: Mark Lord <mlord@pobox.com>
>
> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
> +++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494 -0500
> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
> PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
> break;
> + case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
> + PPC_LWZ_OFFS(r_A, r_skb, K);
> + break;
> case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
> PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
> break;
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/083b20907185b076f21c265b30fe5b
cheers
^ permalink raw reply
* Re: powerpc/pseries: Fix duplicate firmware feature for DRC_INFO
From: Michael Ellerman @ 2018-02-23 5:39 UTC (permalink / raw)
To: Michael Ellerman, mwb, nfont; +Cc: linuxppc-dev
In-Reply-To: <20180221130523.27836-1-mpe@ellerman.id.au>
On Wed, 2018-02-21 at 13:05:23 UTC, Michael Ellerman wrote:
> We had a mid-air collision between two new firmware features, DRMEM_V2
> and DRC_INFO, and they ended up with the same value.
>
> No one's actually reported any problems, presumably because the new
> firmware that supports both properties is not widely available, and
> the two properties tend to be enabled together.
>
> Still if we ever had one enabled but not the other, the bugs that
> could result are many and varied. So fix it.
>
> Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/5539d31a04b3b9ac5f55edb766f1d2
cheers
^ permalink raw reply
* Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: kbuild test robot @ 2018-02-23 7:11 UTC (permalink / raw)
To: Ram Pai
Cc: kbuild-all, mpe, mingo, akpm, linuxppc-dev, linux-mm, x86,
linux-arch, linux-kernel, dave.hansen, benh, paulus, khandual,
aneesh.kumar, bsingharora, hbabu, mhocko, bauerman, ebiederm,
linuxram, corbet, arnd, fweimer, msuchanek
In-Reply-To: <1519257138-23797-2-git-send-email-linuxram@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4584 bytes --]
Hi Ram,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180222]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
Note: the linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
In file included from include/linux/pkeys.h:9:0,
from arch/powerpc/include/asm/mman.h:16,
from include/uapi/linux/mman.h:5,
from include/linux/mman.h:9,
from arch/powerpc/kernel/asm-offsets.c:22:
arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is reported only once for each function it appears in
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
^~~~~~~~~~~~
VM_PKEY_BIT0
arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
^~~~~~~~~~~~~~~~~~
make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [sub-make] Error 2
vim +32 arch/powerpc/include/asm/pkeys.h
4fb158f6 Ram Pai 2018-01-18 30
4fb158f6 Ram Pai 2018-01-18 31 #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32 VM_PKEY_BIT3 | VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18 33
013a91b3 Ram Pai 2018-01-18 34 /* Override any generic PKEY permission defines */
013a91b3 Ram Pai 2018-01-18 35 #define PKEY_DISABLE_EXECUTE 0x4
013a91b3 Ram Pai 2018-01-18 36 #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS | \
013a91b3 Ram Pai 2018-01-18 37 PKEY_DISABLE_WRITE | \
013a91b3 Ram Pai 2018-01-18 38 PKEY_DISABLE_EXECUTE)
013a91b3 Ram Pai 2018-01-18 39
013a91b3 Ram Pai 2018-01-18 40 static inline u64 pkey_to_vmflag_bits(u16 pkey)
013a91b3 Ram Pai 2018-01-18 41 {
013a91b3 Ram Pai 2018-01-18 @42 return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
013a91b3 Ram Pai 2018-01-18 43 }
013a91b3 Ram Pai 2018-01-18 44
:::::: The code at line 32 was first introduced by commit
:::::: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation status of all pkeys
:::::: TO: Ram Pai <linuxram@us.ibm.com>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56627 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM
From: Christophe LEROY @ 2018-02-23 8:01 UTC (permalink / raw)
To: Jonathan Neuschäfer, linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Le 22/02/2018 à 13:15, Jonathan Neuschäfer a écrit :
> This patchset solves the same problem as my previous one[1] but follows
> a rather different approach. Instead of implementing DISCONTIGMEM for
> PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller
> to the existing page_is_ram function, and unified page_is_ram to search
> memblock.memory on PPC64 and PPC32.
>
> The intended result is, as before, that my Wii can allocate the MMIO
> range of its GPIO controller, which was previously not possible, because
> the reserved memory hack (__allow_ioremap_reserved) didn't affect the
> API in kernel/resource.c.
>
> Thanks to Christophe Leroy for reviewing the previous patchset.
I tested your new serie, it doesn't break my 8xx so it is OK for me.
Christophe
>
> [1]: https://www.spinics.net/lists/kernel/msg2726786.html
>
> Jonathan Neuschäfer (5):
> powerpc: mm: Simplify page_is_ram by using memblock_is_memory
> powerpc: mm: Use memblock API for PPC32 page_is_ram
> powerpc/mm/32: Use page_is_ram to check for RAM
> powerpc: wii: Don't rely on the reserved memory hack
> powerpc/mm/32: Remove the reserved memory hack
>
> arch/powerpc/mm/init_32.c | 5 -----
> arch/powerpc/mm/mem.c | 12 +-----------
> arch/powerpc/mm/mmu_decl.h | 1 -
> arch/powerpc/mm/pgtable_32.c | 4 +---
> arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
> 5 files changed, 3 insertions(+), 33 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: kbuild test robot @ 2018-02-23 8:06 UTC (permalink / raw)
To: Ram Pai
Cc: kbuild-all, mpe, mingo, akpm, linuxppc-dev, linux-mm, x86,
linux-arch, linux-kernel, dave.hansen, benh, paulus, khandual,
aneesh.kumar, bsingharora, hbabu, mhocko, bauerman, ebiederm,
linuxram, corbet, arnd, fweimer, msuchanek
In-Reply-To: <1519257138-23797-2-git-send-email-linuxram@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]
Hi Ram,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-skiroot_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
Note: the linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from include/linux/pkeys.h:9:0,
from arch/powerpc/include/asm/mman.h:16,
from include/uapi/linux/mman.h:5,
from include/linux/mman.h:9,
from arch/powerpc/kernel/asm-offsets.c:22:
arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is reported only once for each function it appears in
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
^~~~~~~~~~~~
VM_PKEY_BIT3
arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
VM_PKEY_BIT3 | VM_PKEY_BIT4)
^
arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
^~~~~~~~~~~~~~~~~~
make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [sub-make] Error 2
vim +32 arch/powerpc/include/asm/pkeys.h
4fb158f6 Ram Pai 2018-01-18 30
4fb158f6 Ram Pai 2018-01-18 31 #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32 VM_PKEY_BIT3 | VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18 33
:::::: The code at line 32 was first introduced by commit
:::::: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation status of all pkeys
:::::: TO: Ram Pai <linuxram@us.ibm.com>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19998 bytes --]
^ permalink raw reply
* Hotplug + Reboot is crashing HPT guest with HPT resizing enabled
From: Bharata B Rao @ 2018-02-23 9:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Hi,
Rebooting a hash guest after hotplugging memory to it is crashing the
guest. This is seen only when HPT resizing is enabled. I see guest crashing
at multiple places, but this location is fairly commonly seen:
kernel BUG at mm/slub.c:3912!
Testing with latest guest kernel and ppc-for-2.12 branch of QEMU.
A bit of debugging shows me that when memory is added, the guest kernel
tries to resize HPT to a htab_shift value lesser than the value with which
the guest has booted. For eg. a 8GB guest boots with htab_shift of 26. When
1G is hot-added,
arch/powerpc/mm/hash_utils_64.c:resize_hpt_for_hotplug() ends up assigning
24 to target_hpt_shift. This looks suspicious as we are increasing the
memory, but kernel is asking for shrinking the HPT size. HPT resizing
requests fail though, but next reboot crashes the guest.
Regards,
Bharata.
--
http://raobharata.wordpress.com/
[-- Attachment #2: Type: text/html, Size: 1058 bytes --]
^ permalink raw reply
* Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
From: Michal Hocko @ 2018-02-23 9:12 UTC (permalink / raw)
To: Kees Cook; +Cc: Michael Ellerman, Will Drewry, linux-s390, PowerPC, LKML
In-Reply-To: <CAGXu5jLLDOqoSn9usuA-pRLb5X=zK6MYdUVMPEh7x7oMgnU5cQ@mail.gmail.com>
On Thu 22-02-18 09:30:35, Kees Cook wrote:
> On Thu, Feb 22, 2018 at 5:07 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Wed 14-02-18 09:14:47, Kees Cook wrote:
> > [...]
> >> I can send it through my seccomp tree via James Morris.
> >
> > Could you please do it?
>
> Hi! Yes, sorry, this fell through the cracks. Now applied.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4.4 backport 2/3] powerpc/64s: Simple RFI macro conversions
From: Michael Ellerman @ 2018-02-23 12:11 UTC (permalink / raw)
To: stable, greg; +Cc: npiggin, linuxppc-dev, linux, corsac
In-Reply-To: <20180222123545.8946-2-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Subject: [PATCH v4.4 backport 2/3] powerpc/64s: Simple RFI macro conversions
^
4.9
Gah, sorry just realised these last two have "v4.4" in the subject, but
it should be "4.9".
cheers
^ permalink raw reply
* Re: [PATCH v4.4 backport 2/3] powerpc/64s: Simple RFI macro conversions
From: Greg KH @ 2018-02-23 12:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: stable, npiggin, linuxppc-dev, linux, corsac
In-Reply-To: <87606nq527.fsf@concordia.ellerman.id.au>
On Fri, Feb 23, 2018 at 11:11:12PM +1100, Michael Ellerman wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
> > Subject: [PATCH v4.4 backport 2/3] powerpc/64s: Simple RFI macro conversions
> ^
> 4.9
>
> Gah, sorry just realised these last two have "v4.4" in the subject, but
> it should be "4.9".
Ah, good, I was wondering about that :)
I'll apply these after lunch...
greg k-h
^ permalink raw reply
* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Bryant G. Ly @ 2018-02-23 14:38 UTC (permalink / raw)
To: Michael Ellerman, Bjorn Helgaas
Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, jjalvare
In-Reply-To: <87h8q8pcr9.fsf@concordia.ellerman.id.au>
On 2/22/18 10:10 PM, Michael Ellerman wrote:
> Bjorn Helgaas <helgaas@kernel.org> writes:
>
>> On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote:
>>> On 2/8/18 6:20 AM, Michael Ellerman wrote:
>>>
>>>> There's no reason pci_uevent_ers() needs to be inline in pci.h, so
>>>> move it out to a C file.
>>>>
>>>> Given it's used by AER the obvious location would be somewhere in
>>>> drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
>>>> unfortunately that doesn't work in the case where EEH is enabled but
>>>> PCIEPORTBUS is not.
>>>>
>>>> So for now put it in pci-driver.c, next to pci_uevent(), with an
>>>> appropriate #ifdef so it's not built if AER and EEH are both disabled.
>>>>
>>>> While we're moving it also fix up the kernel doc comment for @pdev to
>>>> be accurate.
>>>>
>>>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>>> ---
>>>> drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
>>>> include/linux/pci.h | 38 +++-----------------------------------
>>>> 2 files changed, 39 insertions(+), 35 deletions(-)
>>> Looks good, thanks for fixing it!
>>>
>>> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
>> This would normally be a "Reviewed-by" unless you actually
>> participated in developing the patch, and in that case, your
>> "Signed-off-by" would normally be included in the original posting.
>>
>> What do you intend? I'll be glad to add either.
> I wrote the patch, so Bryant meant Reviewed-by or maybe Acked-by.
>
> cheers
>
Yes, I mean't,
Reviewed-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Thanks,
Bryant
^ permalink raw reply
* [PATCH 0/3] ARM: Implement MODULE_PLT support in FTRACE
From: Alexander Sverdlin @ 2018-02-23 16:58 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, linux-arm-kernel, linux-kernel
Cc: Alexander Sverdlin, Russell King, Catalin Marinas, Will Deacon,
Steven Miao, Tony Luck, Fenghua Yu, James Hogan, Michal Simek,
Ralf Baechle, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S. Miller, Chris Metcalf,
Thomas Gleixner, H. Peter Anvin, x86, adi-buildroot-devel,
linux-ia64, linux-metag, linux-mips, linuxppc-dev, linux-s390,
linux-sh, sparclinux
FTRACE's function tracer currently doesn't always work on ARM with
MODULE_PLT option enabled. If the module is loaded too far, FTRACE's
code modifier cannot cope with introduced veneers and turns the
function tracer off globally.
ARM64 already has a solution for the problem, refer to the following
patches:
arm64: ftrace: emit ftrace-mod.o contents through code
arm64: module-plts: factor out PLT generation code for ftrace
arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels
arm64: ftrace: fix building without CONFIG_MODULES
arm64: ftrace: add support for far branches to dynamic ftrace
arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()
But the presented ARM variant has just a half of the footprint in terms of
the changed LoCs. It also retains the code validation-before-modification
instead of switching it off.
Alexander Sverdlin (3):
ftrace: Add module to ftrace_make_call() parameters
ARM: PLT: Move struct plt_entries definition to header
ftrace: Add MODULE_PLTS support
arch/arm/include/asm/module.h | 10 ++++++
arch/arm/kernel/ftrace.c | 73 ++++++++++++++++++++++++++++++++------
arch/arm/kernel/module-plts.c | 58 +++++++++++++++++++-----------
arch/arm64/kernel/ftrace.c | 3 +-
arch/blackfin/kernel/ftrace.c | 3 +-
arch/ia64/kernel/ftrace.c | 3 +-
arch/metag/kernel/ftrace.c | 3 +-
arch/microblaze/kernel/ftrace.c | 3 +-
arch/mips/kernel/ftrace.c | 3 +-
arch/powerpc/kernel/trace/ftrace.c | 3 +-
arch/s390/kernel/ftrace.c | 3 +-
arch/sh/kernel/ftrace.c | 3 +-
arch/sparc/kernel/ftrace.c | 3 +-
arch/tile/kernel/ftrace.c | 3 +-
arch/x86/kernel/ftrace.c | 3 +-
include/linux/ftrace.h | 4 ++-
kernel/trace/ftrace.c | 6 ++--
17 files changed, 140 insertions(+), 47 deletions(-)
--
2.4.6
^ 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