* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Lucas Stach @ 2021-04-21 17:43 UTC (permalink / raw)
To: Robin Gong, Shengjiu Wang
Cc: sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
Linux-ALSA, linuxppc-dev@lists.ozlabs.org, Timur Tabi, Xiubo Li,
Fabio Estevam, s.hauer@pengutronix.de, Takashi Iwai,
Liam Girdwood, dri-devel@lists.freedesktop.org, linux-kernel,
Nicolin Chen, Mark Brown, dl-linux-imx, kernel@pengutronix.de,
perex@perex.cz, shawnguo@kernel.org, S.j. Wang,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>
Am Mittwoch, dem 21.04.2021 um 14:54 +0000 schrieb Robin Gong:
> On 20201/04/20 22:01 Lucas Stach <l.stach@pengutronix.de> wrote:
> > Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong:
> > > On 2021/04/19 17:46 Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> > > > > Hi Lucas,
> > > > >
> > > > > On 2021/04/14 Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > > > Hi Robin,
> > > > > >
> > > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > > > > > On 2020/05/20 17:43 Lucas Stach <l.stach@pengutronix.de> wrote:
> > > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu
> > Wang:
> > > > > > > > > Hi
> > > > > > > > >
> > > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > > > > > <l.stach@pengutronix.de>
> > > > > > > > wrote:
> > > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu
> > Wang:
> > > > > > > > > > > There are two requirements that we need to move the
> > > > > > > > > > > request of dma channel from probe to open.
> > > > > > > > > >
> > > > > > > > > > How do you handle -EPROBE_DEFER return code from the
> > > > > > > > > > channel request if you don't do it in probe?
> > > > > > > > >
> > > > > > > > > I use the dma_request_slave_channel or dma_request_channel
> > > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should
> > > > > > > > > be not -EPROBE_DEFER return code.
> > > > > > > >
> > > > > > > > This is a pretty weak argument. The dmaengine device might
> > > > > > > > probe after you try to get the channel. Using a function to
> > > > > > > > request the channel that doesn't allow you to handle probe
> > > > > > > > deferral is IMHO a bug and should be fixed, instead of
> > > > > > > > building even more assumptions on top
> > > > > > of it.
> > > > > > > >
> > > > > > > > > > > - When dma device binds with power-domains, the power
> > > > > > > > > > > will be enabled when we request dma channel. If the
> > > > > > > > > > > request of dma channel happen on probe, then the
> > > > > > > > > > > power-domains will be always enabled after kernel boot
> > > > > > > > > > > up, which is not good for power saving, so we need
> > > > > > > > > > > to move the request of dma channel to .open();
> > > > > > > > > >
> > > > > > > > > > This is certainly something which could be fixed in the
> > > > > > > > > > dmaengine driver.
> > > > > > > > >
> > > > > > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > > > > > device_alloc_chan_resources, the
> > > > > > > > > device_alloc_chan_resources is called when channel is
> > > > > > > > > requested. so power is enabled on channel
> > > > > > request.
> > > > > > > >
> > > > > > > > So why can't you fix the dmaengine driver to do that RPM
> > > > > > > > call at a later time when the channel is actually going to
> > > > > > > > be used? This will allow further power savings with other
> > > > > > > > slave devices than the audio
> > > > PCM.
> > > > > > > Hi Lucas,
> > > > > > > Thanks for your suggestion. I have tried to implement
> > > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with
> > > > > > > delay time (2
> > > > > > > sec) for this feature as below (or you can refer to
> > > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface
> > > > > > > like
> > > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d
> > > > > > > ma_c
> > > > > > > ycli
> > > > > > > c/
> > > > > > > device_tx_status...
> > > > > > >
> > > > > > >
> > > > > > > pm_runtime_use_autosuspend(fsl_chan->de
> > v);
> > > > > > > pm_runtime_set_autosuspend_delay(fsl_cha
> > n->
> > > > dev,
> > > > > > 2000);
> > > > > > >
> > > > > > > That could resolve this audio case since the autosuspend could
> > > > > > > suspend runtime after
> > > > > > > 2 seconds if there is no further dma transfer but only channel
> > > > > > request(device_alloc_chan_resources).
> > > > > > > But unfortunately, it cause another issue. As you know, on our
> > > > > > > i.mx8qm/qxp, power domain done by scfw
> > > > > > > (drivers/firmware/imx/scu-pd.c)
> > > > > > over mailbox:
> > > > > > > imx_sc_pd_power()->imx_scu_call_rpc()->
> > > > > > > imx_scu_ipc_write()->mbox_send_message()
> > > > > > > which means have to 'waits for completion', meanwhile, some
> > > > > > > driver like tty will call dmaengine interfaces in non-atomic
> > > > > > > case as below,
> > > > > > >
> > > > > > > static int uart_write(struct tty_struct *tty, const unsigned
> > > > > > > char *buf, int count) {
> > > > > > > .......
> > > > > > > port = uart_port_lock(state, flags);
> > > > > > > ......
> > > > > > > __uart_start(tty); //call
> > > > start_tx()->dmaengine_prep_slave_sg...
> > > > > > > uart_port_unlock(port, flags);
> > > > > > > return ret;
> > > > > > > }
> > > > > > >
> > > > > > > Thus dma runtime resume may happen in that timing window and
> > > > > > > cause
> > > > > > kernel alarm.
> > > > > > > I'm not sure whether there are similar limitations on other
> > > > > > > driver subsystem. But for me, It looks like the only way to
> > > > > > > resolve the contradiction between tty and scu-pd (hardware
> > > > > > > limitation on
> > > > > > > i.mx8qm/qxp) is to give up autosuspend and keep
> > > > > > > pm_runtime_get_sync
> > > > > > only in device_alloc_chan_resources because request channel is a
> > > > > > safe non-atomic phase.
> > > > > > > Do you have any idea? Thanks in advance.
> > > > > >
> > > > > > If you look closely at the driver you used as an example
> > > > > > (hidma.c) it looks like there is already something in there,
> > > > > > which looks very much like what you need
> > > > > > here:
> > > > > >
> > > > > > In hidma_issue_pending() the driver tries to get the device to
> > > > > > runtime
> > > > resume.
> > > > > > If this doesn't work, maybe due to the power domain code not
> > > > > > being able to be called in atomic context, the actual work of
> > > > > > waking up the dma hardware and issuing the descriptor is shunted to a
> > tasklet.
> > > > > >
> > > > > > If I'm reading this right, this is exactly what you need here to
> > > > > > be able to call the dmaengine code from atomic context: try the
> > > > > > rpm get and issue immediately when possible, otherwise shunt the
> > > > > > work to a
> > > > > > non- atomic context where you can deal with the requirements of
> > scu-pd.
> > > > > Yes, I can schedule_work to worker to runtime resume edma channel
> > > > > by
> > > > calling scu-pd.
> > > > > But that means all dmaengine interfaces should be taken care, not
> > > > > only
> > > > > issue_pending() but also
> > > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> > > > > dmaengine_tx_status(). Not sure why hidma only take care
> > > > > issue_pending. Maybe their user case is just for memcpy/memset so
> > > > > that no further complicate case as ALSA or TTY.
> > > > > Besides, for autosuspend in cyclic, we have to add
> > > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but
> > > > > how could resolve the scu-pd's non-atmoic limitation in interrupt
> > handler?
> > > >
> > > > Sure, this all needs some careful analysis on how those functions
> > > > are called and what to do about atomic callers, but it should be
> > > > doable. I don't see any fundamental issues here.
> > > >
> > > > I don't see why you would ever need to wake the hardware in an
> > > > interrupt handler. Surely the hardware is already awake, as it
> > > > wouldn't signal an interrupt otherwise. And for the issue with
> > > > scu-pd you only care about the state transition of
> > > > suspended->running. If the hardware is already running/awake, the
> > > > runtime pm state handling is nothing more than bumping a refcount,
> > > > which is atomic safe. Putting the HW in suspend is already handled
> > asynchronously in a worker, so this is also atomic safe.
> > > But with autosuspend used, in corner case, may runtime suspended
> > > before falling Into edma interrupt handler if timeout happen with the
> > > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch
> > > any edma interrupt status register unless runtime resume edma in
> > > interrupt handler while runtime resume function based on scu-pd's power
> > domain may block or sleep.
> > > I have a simple workaround that disable runtime suspend in
> > > issue_pending worker by calling pm_runtime_forbid() and then enable
> > > runtime auto suspend in dmaengine_terminate_all so that we could
> > > easily regard that edma channel is always in runtime resume between
> > > issue_pending and channel terminated and ignore the above interrupt
> > handler/scu-pd limitation.
> >
> > The IRQ handler is the point where you are informed by the hardware that a
> > specific operation is complete. I don't see any use-case where it would be valid
> > to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware
> > needs to stay awake until the currently queued operations are complete and if
> > the IRQ handler is the completion point the IRQ handler is the first point in
> > time where your autosuspend timer should start to run. There should never be
> > a situation where the timer expiry can get between IRQ signaling and the
> > handler code running.
> But the timer of runtime_auto_suspend decide when enter runtime suspend rather
> than hardware, while transfer data size and transfer rate on IP bus decide when the
> dma interrupt happen.
>
But it isn't the hardware that decides to drop the rpm refcount to 0
and starting the autosuspend timer, it's the driver.
> Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
> pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend
> timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic
> and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer
> 100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile
> the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent
> by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start
> to run after runtime suspend.
If your driver code drops the rpm refcount to 0 and starts the
autosuspend timer while a cyclic transfer is still in flight this is
clearly a bug. Autosuspend is not there to paper over driver bugs, but
to amortize cost of actually suspending and resuming the hardware. Your
driver code must still work even if the timeout is 0, i.e. the hardware
is immediately suspended after you drop the rpm refcount to 0.
If you still have transfers queued/in-flight the driver code must keep
a rpm reference.
Regards,
Lucas
^ permalink raw reply
* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Mark Brown @ 2021-04-21 17:46 UTC (permalink / raw)
To: Lucas Stach
Cc: Linux-ALSA, Xiubo Li, dri-devel@lists.freedesktop.org,
Liam Girdwood, Robin Gong, Fabio Estevam, sumit.semwal@linaro.org,
Shengjiu Wang, dl-linux-imx, linux-media@vger.kernel.org,
s.hauer@pengutronix.de, linaro-mm-sig@lists.linaro.org,
perex@perex.cz, linux-arm-kernel@lists.infradead.org,
Nicolin Chen, Timur Tabi, linuxppc-dev@lists.ozlabs.org,
S.j. Wang, Takashi Iwai, linux-kernel, kernel@pengutronix.de,
shawnguo@kernel.org
In-Reply-To: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Wed, Apr 21, 2021 at 07:43:18PM +0200, Lucas Stach wrote:
> If your driver code drops the rpm refcount to 0 and starts the
> autosuspend timer while a cyclic transfer is still in flight this is
> clearly a bug. Autosuspend is not there to paper over driver bugs, but
> to amortize cost of actually suspending and resuming the hardware. Your
> driver code must still work even if the timeout is 0, i.e. the hardware
> is immediately suspended after you drop the rpm refcount to 0.
> If you still have transfers queued/in-flight the driver code must keep
> a rpm reference.
Right, failing to do that is a clear bug.
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] opal/fadump: fix fadump to work with a different endian capture kernel
From: Hari Bathini @ 2021-04-21 17:50 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
Dump capture would fail if capture kernel is not of the endianess as
the production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/platforms/powernv/opal-fadump.c | 94 ++++++++++++++------------
arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
2 files changed, 57 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c b/arch/powerpc/platforms/powernv/opal-fadump.c
index 9a360ced663b..e23a51a05f99 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
- if (opal_fdm_active->registered_regions == 0)
+ if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, &addr);
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump *fadump_conf);
static void opal_fadump_update_config(struct fw_dump *fadump_conf,
const struct opal_fadump_mem_struct *fdm)
{
- pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+ pr_debug("Boot memory regions count: %d\n", be16_to_cpu(fdm->region_cnt));
/*
* The destination address of the first boot memory region is the
* destination address of boot memory regions.
*/
- fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+ fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
fadump_conf->boot_mem_dest_addr);
- fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+ fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
}
/*
@@ -126,9 +126,9 @@ static void opal_fadump_get_config(struct fw_dump *fadump_conf,
fadump_conf->boot_memory_size = 0;
pr_debug("Boot memory regions:\n");
- for (i = 0; i < fdm->region_cnt; i++) {
- base = fdm->rgn[i].src;
- size = fdm->rgn[i].size;
+ for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+ base = be64_to_cpu(fdm->rgn[i].src);
+ size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void opal_fadump_get_config(struct fw_dump *fadump_conf,
* Start address of reserve dump area (permanent reservation) for
* re-registering FADump after dump capture.
*/
- fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+ fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
/*
* Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void opal_fadump_get_config(struct fw_dump *fadump_conf,
* Hope the memory that could not be preserved only has pages
* that are usually filtered out while saving the vmcore.
*/
- if (fdm->region_cnt > fdm->registered_regions) {
+ if (be16_to_cpu(fdm->region_cnt) > be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn(" Unsaved memory regions:\n");
- i = fdm->registered_regions;
- while (i < fdm->region_cnt) {
+ i = be16_to_cpu(fdm->registered_regions);
+ while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
- i, fdm->rgn[i].src, fdm->rgn[i].size);
+ i, be64_to_cpu(fdm->rgn[i].src),
+ be64_to_cpu(fdm->rgn[i].size));
i++;
}
@@ -170,7 +171,7 @@ static void opal_fadump_get_config(struct fw_dump *fadump_conf,
}
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
- fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+ fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
}
@@ -178,35 +179,38 @@ static void opal_fadump_get_config(struct fw_dump *fadump_conf,
static void opal_fadump_init_metadata(struct opal_fadump_mem_struct *fdm)
{
fdm->version = OPAL_FADUMP_VERSION;
- fdm->region_cnt = 0;
- fdm->registered_regions = 0;
- fdm->fadumphdr_addr = 0;
+ fdm->region_cnt = cpu_to_be16(0);
+ fdm->registered_regions = cpu_to_be16(0);
+ fdm->fadumphdr_addr = cpu_to_be64(0);
}
static u64 opal_fadump_init_mem_struct(struct fw_dump *fadump_conf)
{
u64 addr = fadump_conf->reserve_dump_area_start;
+ u16 reg_cnt;
int i;
opal_fdm = __va(fadump_conf->kernel_metadata);
opal_fadump_init_metadata(opal_fdm);
/* Boot memory regions */
+ reg_cnt = be16_to_cpu(opal_fdm->region_cnt);
for (i = 0; i < fadump_conf->boot_mem_regs_cnt; i++) {
- opal_fdm->rgn[i].src = fadump_conf->boot_mem_addr[i];
- opal_fdm->rgn[i].dest = addr;
- opal_fdm->rgn[i].size = fadump_conf->boot_mem_sz[i];
+ opal_fdm->rgn[i].src = cpu_to_be64(fadump_conf->boot_mem_addr[i]);
+ opal_fdm->rgn[i].dest = cpu_to_be64(addr);
+ opal_fdm->rgn[i].size = cpu_to_be64(fadump_conf->boot_mem_sz[i]);
- opal_fdm->region_cnt++;
+ reg_cnt++;
addr += fadump_conf->boot_mem_sz[i];
}
+ opal_fdm->region_cnt = cpu_to_be16(reg_cnt);
/*
* Kernel metadata is passed to f/w and retrieved in capture kerenl.
* So, use it to save fadump header address instead of calculating it.
*/
- opal_fdm->fadumphdr_addr = (opal_fdm->rgn[0].dest +
- fadump_conf->boot_memory_size);
+ opal_fdm->fadumphdr_addr = cpu_to_be64(be64_to_cpu(opal_fdm->rgn[0].dest) +
+ fadump_conf->boot_memory_size);
opal_fadump_update_config(fadump_conf, opal_fdm);
@@ -269,18 +273,21 @@ static u64 opal_fadump_get_bootmem_min(void)
static int opal_fadump_register(struct fw_dump *fadump_conf)
{
s64 rc = OPAL_PARAMETER;
+ u16 registered_regs;
int i, err = -EIO;
- for (i = 0; i < opal_fdm->region_cnt; i++) {
+ registered_regs = be16_to_cpu(opal_fdm->registered_regions);
+ for (i = 0; i < be16_to_cpu(opal_fdm->region_cnt); i++) {
rc = opal_mpipl_update(OPAL_MPIPL_ADD_RANGE,
- opal_fdm->rgn[i].src,
- opal_fdm->rgn[i].dest,
- opal_fdm->rgn[i].size);
+ be64_to_cpu(opal_fdm->rgn[i].src),
+ be64_to_cpu(opal_fdm->rgn[i].dest),
+ be64_to_cpu(opal_fdm->rgn[i].size));
if (rc != OPAL_SUCCESS)
break;
- opal_fdm->registered_regions++;
+ registered_regs++;
}
+ opal_fdm->registered_regions = cpu_to_be16(registered_regs);
switch (rc) {
case OPAL_SUCCESS:
@@ -291,7 +298,8 @@ static int opal_fadump_register(struct fw_dump *fadump_conf)
case OPAL_RESOURCE:
/* If MAX regions limit in f/w is hit, warn and proceed. */
pr_warn("%d regions could not be registered for MPIPL as MAX limit is reached!\n",
- (opal_fdm->region_cnt - opal_fdm->registered_regions));
+ (be16_to_cpu(opal_fdm->region_cnt) -
+ be16_to_cpu(opal_fdm->registered_regions)));
fadump_conf->dump_registered = 1;
err = 0;
break;
@@ -312,7 +320,7 @@ static int opal_fadump_register(struct fw_dump *fadump_conf)
* If some regions were registered before OPAL_MPIPL_ADD_RANGE
* OPAL call failed, unregister all regions.
*/
- if ((err < 0) && (opal_fdm->registered_regions > 0))
+ if ((err < 0) && (be16_to_cpu(opal_fdm->registered_regions) > 0))
opal_fadump_unregister(fadump_conf);
return err;
@@ -328,7 +336,7 @@ static int opal_fadump_unregister(struct fw_dump *fadump_conf)
return -EIO;
}
- opal_fdm->registered_regions = 0;
+ opal_fdm->registered_regions = cpu_to_be16(0);
fadump_conf->dump_registered = 0;
return 0;
}
@@ -563,19 +571,20 @@ static void opal_fadump_region_show(struct fw_dump *fadump_conf,
else
fdm_ptr = opal_fdm;
- for (i = 0; i < fdm_ptr->region_cnt; i++) {
+ for (i = 0; i < be16_to_cpu(fdm_ptr->region_cnt); i++) {
/*
* Only regions that are registered for MPIPL
* would have dump data.
*/
if ((fadump_conf->dump_active) &&
- (i < fdm_ptr->registered_regions))
- dumped_bytes = fdm_ptr->rgn[i].size;
+ (i < be16_to_cpu(fdm_ptr->registered_regions)))
+ dumped_bytes = be64_to_cpu(fdm_ptr->rgn[i].size);
seq_printf(m, "DUMP: Src: %#016llx, Dest: %#016llx, ",
- fdm_ptr->rgn[i].src, fdm_ptr->rgn[i].dest);
+ be64_to_cpu(fdm_ptr->rgn[i].src),
+ be64_to_cpu(fdm_ptr->rgn[i].dest));
seq_printf(m, "Size: %#llx, Dumped: %#llx bytes\n",
- fdm_ptr->rgn[i].size, dumped_bytes);
+ be64_to_cpu(fdm_ptr->rgn[i].size), dumped_bytes);
}
/* Dump is active. Show reserved area start address. */
@@ -624,6 +633,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
{
const __be32 *prop;
unsigned long dn;
+ __be64 be_addr;
u64 addr = 0;
int i, len;
s64 ret;
@@ -680,13 +690,13 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
if (!prop)
return;
- ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_KERNEL, &addr);
- if ((ret != OPAL_SUCCESS) || !addr) {
+ ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_KERNEL, &be_addr);
+ if ((ret != OPAL_SUCCESS) || !be_addr) {
pr_err("Failed to get Kernel metadata (%lld)\n", ret);
return;
}
- addr = be64_to_cpu(addr);
+ addr = be64_to_cpu(be_addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = __va(addr);
@@ -697,14 +707,14 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, u64 node)
}
/* Kernel regions not registered with f/w for MPIPL */
- if (opal_fdm_active->registered_regions == 0) {
+ if (be16_to_cpu(opal_fdm_active->registered_regions) == 0) {
opal_fdm_active = NULL;
return;
}
- ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_CPU, &addr);
- if (addr) {
- addr = be64_to_cpu(addr);
+ ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_CPU, &be_addr);
+ if (be_addr) {
+ addr = be64_to_cpu(be_addr);
pr_debug("CPU metadata addr: %llx\n", addr);
opal_cpu_metadata = __va(addr);
}
diff --git a/arch/powerpc/platforms/powernv/opal-fadump.h b/arch/powerpc/platforms/powernv/opal-fadump.h
index f1e9ecf548c5..3f715efb0aa6 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.h
+++ b/arch/powerpc/platforms/powernv/opal-fadump.h
@@ -31,14 +31,14 @@
* OPAL FADump kernel metadata
*
* The address of this structure will be registered with f/w for retrieving
- * and processing during crash dump.
+ * in the capture kernel to process the crash dump.
*/
struct opal_fadump_mem_struct {
u8 version;
u8 reserved[3];
- u16 region_cnt; /* number of regions */
- u16 registered_regions; /* Regions registered for MPIPL */
- u64 fadumphdr_addr;
+ __be16 region_cnt; /* number of regions */
+ __be16 registered_regions; /* Regions registered for MPIPL */
+ __be64 fadumphdr_addr;
struct opal_mpipl_region rgn[FADUMP_MAX_MEM_REGS];
} __packed;
@@ -135,7 +135,7 @@ static inline void opal_fadump_read_regs(char *bufp, unsigned int regs_cnt,
for (i = 0; i < regs_cnt; i++, bufp += reg_entry_size) {
reg_entry = (struct hdat_fadump_reg_entry *)bufp;
val = (cpu_endian ? be64_to_cpu(reg_entry->reg_val) :
- reg_entry->reg_val);
+ (u64)(reg_entry->reg_val));
opal_fadump_set_regval_regnum(regs,
be32_to_cpu(reg_entry->reg_type),
be32_to_cpu(reg_entry->reg_num),
^ permalink raw reply related
* Re: [PATCH v2] powerpc: make ALTIVEC select PPC_FPU
From: Randy Dunlap @ 2021-04-21 20:59 UTC (permalink / raw)
To: Christophe Leroy, linux-kernel; +Cc: linuxppc-dev, kernel test robot
In-Reply-To: <60ac6ff1-6bfa-d335-ac0e-336fe3e50587@csgroup.eu>
On 4/20/21 10:19 PM, Christophe Leroy wrote:
>
>
> Le 21/04/2021 à 04:56, Randy Dunlap a écrit :
>> On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled,
>> there are build errors:
>>
>> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
>> enable_kernel_fp();
>> ../arch/powerpc/lib/sstep.c: In function 'do_vec_load':
>> ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration]
>> 637 | put_vr(rn, &u.v);
>> | ^~~~~~
>> ../arch/powerpc/lib/sstep.c: In function 'do_vec_store':
>> ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration]
>> 660 | get_vr(rn, &u.v);
>> | ^~~~~~
>>
>> In theory ALTIVEC is independent of PPC_FPU but in practice nobody
>> is going to build such a machine, so make ALTIVEC require PPC_FPU
>> by selecting it.
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Cc: Segher Boessenkool <segher@kernel.crashing.org>
>> Cc: lkp@intel.com
>> ---
>> v2: change ALTIVEC depends on PPC_FPU to select (Christophe and Michael)
>>
>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>> arch/powerpc/platforms/Kconfig.cputype | 2 ++
>> 2 files changed, 3 insertions(+)
>>
>> --- linux-next-20210416.orig/arch/powerpc/platforms/86xx/Kconfig
>> +++ linux-next-20210416/arch/powerpc/platforms/86xx/Kconfig
>> @@ -4,6 +4,7 @@ menuconfig PPC_86xx
>> bool "86xx-based boards"
>> depends on PPC_BOOK3S_32
>> select FSL_SOC
>> + select PPC_FPU
>
> Now that ALTIVEC selects PPC_FPU by itself, I don't think you need that.
>
>> select ALTIVEC
>> help
>> The Freescale E600 SoCs have 74xx cores.
>> --- linux-next-20210416.orig/arch/powerpc/platforms/Kconfig.cputype
>> +++ linux-next-20210416/arch/powerpc/platforms/Kconfig.cputype
>> @@ -186,6 +186,7 @@ config E300C3_CPU
>> config G4_CPU
>> bool "G4 (74xx)"
>> depends on PPC_BOOK3S_32
>> + select PPC_FPU
>
> Same
Of course. v3 coming up.
Thanks.
>> select ALTIVEC
>> endchoice
>> @@ -310,6 +311,7 @@ config PHYS_64BIT
>> config ALTIVEC
>> bool "AltiVec Support"
>> depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 || (PPC_E500MC && PPC64)
>> + select PPC_FPU
>> help
>> This option enables kernel support for the Altivec extensions to the
>> PowerPC processor. The kernel currently supports saving and restoring
>>
--
~Randy
^ permalink raw reply
* [PATCH v3] powerpc: make ALTIVEC select PPC_FPU
From: Randy Dunlap @ 2021-04-21 21:06 UTC (permalink / raw)
To: linux-kernel; +Cc: kernel test robot, Randy Dunlap, linuxppc-dev
On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled,
there are build errors:
drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
enable_kernel_fp();
../arch/powerpc/lib/sstep.c: In function 'do_vec_load':
../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration]
637 | put_vr(rn, &u.v);
| ^~~~~~
../arch/powerpc/lib/sstep.c: In function 'do_vec_store':
../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration]
660 | get_vr(rn, &u.v);
| ^~~~~~
In theory ALTIVEC is independent of PPC_FPU but in practice nobody
is going to build such a machine, so make ALTIVEC require PPC_FPU
by selecting it.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: lkp@intel.com
---
v2: change ALTIVEC depends on PPC_FPU to select (Christophe and Michael)
v3: other platforms don't need to select PPC_FPU since they select ALTIVEC
(Christophe; thanks)
arch/powerpc/platforms/Kconfig.cputype | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20210416.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-next-20210416/arch/powerpc/platforms/Kconfig.cputype
@@ -310,6 +310,7 @@ config PHYS_64BIT
config ALTIVEC
bool "AltiVec Support"
depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 || (PPC_E500MC && PPC64)
+ select PPC_FPU
help
This option enables kernel support for the Altivec extensions to the
PowerPC processor. The kernel currently supports saving and restoring
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
From: Christophe Leroy @ 2021-04-21 13:10 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Ian Rogers, Song Liu, open list:DOCUMENTATION, Zi Shen Lim,
Alexei Starovoitov, Russell King, David S. Miller, Paul Mackerras,
Sandipan Das, H. Peter Anvin, sparclinux, Shubham Bansal,
Mahesh Bandewar, Will Deacon, linux-riscv, linux-s390,
Ilya Leoshkevich, paulburton, Jonathan Corbet,
Mauro Carvalho Chehab, Masahiro Yamada, X86 ML, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Quentin Monnet,
Dmitry Vyukov, Catalin Marinas, Naveen N . Rao, Jakub Kicinski,
Tobias Klauser, grantseltzer, Xi Wang, Albert Ou, Kees Cook,
Vasily Gorbik, Luke Nelson, Heiko Carstens, KP Singh, iecedge,
Simon Horman, Borislav Petkov, Alexander Viro, Paul Walmsley,
Jianlin Lv, Nicolas Dichtel, Ingo Molnar, linux-arm-kernel,
Wang YanQing, tsbogend, Daniel Borkmann, Hideaki YOSHIFUJI,
Network Development, David Ahern, linux-mips, LKML, Yonghong Song,
Björn Töpel, Palmer Dabbelt, Thomas Gleixner, bpf,
ppc-dev, Martin KaFai Lau
In-Reply-To: <CAADnVQ+oQT6C7Qv7P5TV-x7im54omKoCYYKtYhcnhb1Uv3LPMQ@mail.gmail.com>
Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit :
> On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
>>> On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet <quentin@isovalent.com> wrote:
>>>>
>>>> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann <daniel@iogearbox.net>
>>>>> On 4/15/21 11:32 AM, Jianlin Lv wrote:
>>>>>> For debugging JITs, dumping the JITed image to kernel log is discouraged,
>>>>>> "bpftool prog dump jited" is much better way to examine JITed dumps.
>>>>>> This patch get rid of the code related to bpf_jit_enable=2 mode and
>>>>>> update the proc handler of bpf_jit_enable, also added auxiliary
>>>>>> information to explain how to use bpf_jit_disasm tool after this change.
>>>>>>
>>>>>> Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
>>>>
>>>> Hello,
>>>>
>>>> For what it's worth, I have already seen people dump the JIT image in
>>>> kernel logs in Qemu VMs running with just a busybox, not for kernel
>>>> development, but in a context where buiding/using bpftool was not
>>>> possible.
>>>
>>> If building/using bpftool is not possible then majority of selftests won't
>>> be exercised. I don't think such environment is suitable for any kind
>>> of bpf development. Much so for JIT debugging.
>>> While bpf_jit_enable=2 is nothing but the debugging tool for JIT developers.
>>> I'd rather nuke that code instead of carrying it from kernel to kernel.
>>>
>>
>> When I implemented JIT for PPC32, it was extremely helpfull.
>>
>> As far as I understand, for the time being bpftool is not usable in my environment because it
>> doesn't support cross compilation when the target's endianess differs from the building host
>> endianess, see discussion at
>> https://lore.kernel.org/bpf/21e66a09-514f-f426-b9e2-13baab0b938b@csgroup.eu/
>>
>> That's right that selftests can't be exercised because they don't build.
>>
>> The question might be candid as I didn't investigate much about the replacement of "bpf_jit_enable=2
>> debugging mode" by bpftool, how do we use bpftool exactly for that ? Especially when using the BPF
>> test module ?
>
> the kernel developers can add any amount of printk and dumps to debug
> their code,
> but such debugging aid should not be part of the production kernel.
> That sysctl was two things at once: debugging tool for kernel devs and
> introspection for users.
> bpftool jit dump solves the 2nd part. It provides JIT introspection to users.
> Debugging of the kernel can be done with any amount of auxiliary code
> including calling print_hex_dump() during jiting.
>
I get the following message when trying the command suggested in the patch message:
root@vgoip:~# ./bpftool prog dump jited
Error: No libbfd support
Christophe
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
From: Quentin Monnet @ 2021-04-21 15:27 UTC (permalink / raw)
To: Christophe Leroy, Alexei Starovoitov
Cc: Ian Rogers, Song Liu, open list:DOCUMENTATION, Zi Shen Lim,
Alexei Starovoitov, Russell King, David S. Miller, Paul Mackerras,
Sandipan Das, H. Peter Anvin, sparclinux, Shubham Bansal,
Mahesh Bandewar, Will Deacon, linux-riscv, linux-s390,
Ilya Leoshkevich, paulburton, Jonathan Corbet,
Mauro Carvalho Chehab, Masahiro Yamada, X86 ML, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Ingo Molnar,
Dmitry Vyukov, Catalin Marinas, Naveen N . Rao, Jakub Kicinski,
Tobias Klauser, grantseltzer, Xi Wang, Albert Ou, Kees Cook,
Vasily Gorbik, Luke Nelson, Heiko Carstens, KP Singh, iecedge,
Simon Horman, Borislav Petkov, Alexander Viro, Paul Walmsley,
Jianlin Lv, Nicolas Dichtel, Palmer Dabbelt, linux-arm-kernel,
Wang YanQing, tsbogend, Daniel Borkmann, Hideaki YOSHIFUJI,
Network Development, David Ahern, linux-mips, LKML, Yonghong Song,
Björn Töpel, Thomas Gleixner, bpf, ppc-dev,
Martin KaFai Lau
In-Reply-To: <7dc31256-eb1d-dc93-5e55-2de27475e0c6@csgroup.eu>
2021-04-21 15:10 UTC+0200 ~ Christophe Leroy <christophe.leroy@csgroup.eu>
>
>
> Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit :
>> On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
>> <christophe.leroy@csgroup.eu> wrote:
>>>
>>>
>>>
>>> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
>>>> On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet
>>>> <quentin@isovalent.com> wrote:
>>>>>
>>>>> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann <daniel@iogearbox.net>
>>>>>> On 4/15/21 11:32 AM, Jianlin Lv wrote:
>>>>>>> For debugging JITs, dumping the JITed image to kernel log is
>>>>>>> discouraged,
>>>>>>> "bpftool prog dump jited" is much better way to examine JITed dumps.
>>>>>>> This patch get rid of the code related to bpf_jit_enable=2 mode and
>>>>>>> update the proc handler of bpf_jit_enable, also added auxiliary
>>>>>>> information to explain how to use bpf_jit_disasm tool after this
>>>>>>> change.
>>>>>>>
>>>>>>> Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
>>>>>
>>>>> Hello,
>>>>>
>>>>> For what it's worth, I have already seen people dump the JIT image in
>>>>> kernel logs in Qemu VMs running with just a busybox, not for kernel
>>>>> development, but in a context where buiding/using bpftool was not
>>>>> possible.
>>>>
>>>> If building/using bpftool is not possible then majority of selftests
>>>> won't
>>>> be exercised. I don't think such environment is suitable for any kind
>>>> of bpf development. Much so for JIT debugging.
>>>> While bpf_jit_enable=2 is nothing but the debugging tool for JIT
>>>> developers.
>>>> I'd rather nuke that code instead of carrying it from kernel to kernel.
>>>>
>>>
>>> When I implemented JIT for PPC32, it was extremely helpfull.
>>>
>>> As far as I understand, for the time being bpftool is not usable in
>>> my environment because it
>>> doesn't support cross compilation when the target's endianess differs
>>> from the building host
>>> endianess, see discussion at
>>> https://lore.kernel.org/bpf/21e66a09-514f-f426-b9e2-13baab0b938b@csgroup.eu/
>>>
>>>
>>> That's right that selftests can't be exercised because they don't build.
>>>
>>> The question might be candid as I didn't investigate much about the
>>> replacement of "bpf_jit_enable=2
>>> debugging mode" by bpftool, how do we use bpftool exactly for that ?
>>> Especially when using the BPF
>>> test module ?
>>
>> the kernel developers can add any amount of printk and dumps to debug
>> their code,
>> but such debugging aid should not be part of the production kernel.
>> That sysctl was two things at once: debugging tool for kernel devs and
>> introspection for users.
>> bpftool jit dump solves the 2nd part. It provides JIT introspection to
>> users.
>> Debugging of the kernel can be done with any amount of auxiliary code
>> including calling print_hex_dump() during jiting.
>>
>
> I get the following message when trying the command suggested in the
> patch message:
>
> root@vgoip:~# ./bpftool prog dump jited
> Error: No libbfd support
>
> Christophe
Hi Christophe,
Bpftool relies on libbfd to disassemble the JIT-ed instructions, but
this is an optional dependency and your version of bpftool has been
compiled without it.
You could try to install it on your system (it is usually shipped with
binutils, package "binutils-dev" on Ubuntu for example). If you want to
cross-compile bpftool, the libbfd version provided by your distribution
may not include support for the target architecture. In that case you
would have to build libbfd yourself to make sure it supports it.
Then you can clean up the results from the libbfd probing:
$ make -C tools/build/feature/ clean
and recompile bpftool.
I hope this helps,
Quentin
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
From: John Fastabend @ 2021-04-21 16:29 UTC (permalink / raw)
To: Christophe Leroy, Alexei Starovoitov
Cc: Ian Rogers, Song Liu, open list:DOCUMENTATION, Zi Shen Lim,
Alexei Starovoitov, Russell King, David S. Miller, Paul Mackerras,
Sandipan Das, H. Peter Anvin, sparclinux, Shubham Bansal,
Mahesh Bandewar, Will Deacon, linux-riscv, linux-s390,
Ilya Leoshkevich, paulburton, Jonathan Corbet,
Mauro Carvalho Chehab, Masahiro Yamada, X86 ML, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Quentin Monnet,
Dmitry Vyukov, Catalin Marinas, Naveen N . Rao, Jakub Kicinski,
Tobias Klauser, grantseltzer, Xi Wang, Albert Ou, Kees Cook,
Vasily Gorbik, Luke Nelson, Heiko Carstens, KP Singh, iecedge,
Simon Horman, Borislav Petkov, Alexander Viro, Paul Walmsley,
Jianlin Lv, Nicolas Dichtel, Ingo Molnar, linux-arm-kernel,
Wang YanQing, tsbogend, Daniel Borkmann, Hideaki YOSHIFUJI,
Network Development, David Ahern, linux-mips, LKML, Yonghong Song,
Björn Töpel, Palmer Dabbelt, Thomas Gleixner, bpf,
ppc-dev, Martin KaFai Lau
In-Reply-To: <7dc31256-eb1d-dc93-5e55-2de27475e0c6@csgroup.eu>
Christophe Leroy wrote:
>
>
> Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit :
> > On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >>
> >> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
> >>> On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet <quentin@isovalent.com> wrote:
> >>>>
> >>>> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann <daniel@iogearbox.net>
> >>>>> On 4/15/21 11:32 AM, Jianlin Lv wrote:
> >>>>>> For debugging JITs, dumping the JITed image to kernel log is discouraged,
> >>>>>> "bpftool prog dump jited" is much better way to examine JITed dumps.
> >>>>>> This patch get rid of the code related to bpf_jit_enable=2 mode and
> >>>>>> update the proc handler of bpf_jit_enable, also added auxiliary
> >>>>>> information to explain how to use bpf_jit_disasm tool after this change.
> >>>>>>
> >>>>>> Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
> >>>>
> >>>> Hello,
> >>>>
> >>>> For what it's worth, I have already seen people dump the JIT image in
> >>>> kernel logs in Qemu VMs running with just a busybox, not for kernel
> >>>> development, but in a context where buiding/using bpftool was not
> >>>> possible.
> >>>
> >>> If building/using bpftool is not possible then majority of selftests won't
> >>> be exercised. I don't think such environment is suitable for any kind
> >>> of bpf development. Much so for JIT debugging.
> >>> While bpf_jit_enable=2 is nothing but the debugging tool for JIT developers.
> >>> I'd rather nuke that code instead of carrying it from kernel to kernel.
> >>>
> >>
> >> When I implemented JIT for PPC32, it was extremely helpfull.
> >>
> >> As far as I understand, for the time being bpftool is not usable in my environment because it
> >> doesn't support cross compilation when the target's endianess differs from the building host
> >> endianess, see discussion at
> >> https://lore.kernel.org/bpf/21e66a09-514f-f426-b9e2-13baab0b938b@csgroup.eu/
> >>
> >> That's right that selftests can't be exercised because they don't build.
> >>
> >> The question might be candid as I didn't investigate much about the replacement of "bpf_jit_enable=2
> >> debugging mode" by bpftool, how do we use bpftool exactly for that ? Especially when using the BPF
> >> test module ?
> >
> > the kernel developers can add any amount of printk and dumps to debug
> > their code,
> > but such debugging aid should not be part of the production kernel.
> > That sysctl was two things at once: debugging tool for kernel devs and
> > introspection for users.
> > bpftool jit dump solves the 2nd part. It provides JIT introspection to users.
> > Debugging of the kernel can be done with any amount of auxiliary code
> > including calling print_hex_dump() during jiting.
> >
>
> I get the following message when trying the command suggested in the patch message:
>
> root@vgoip:~# ./bpftool prog dump jited
> Error: No libbfd support
>
> Christophe
Seems your bpftool prog was built without libbfd, can you rebuild with libbfd
installed.
.John
^ permalink raw reply
* [powerpc:next-test 245/263] arch/powerpc/include/asm/mmu_context.h:287:19: error: redefinition of 'pte_to_hpte_pkey_bits'
From: kernel test robot @ 2021-04-21 22:24 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4609 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: f76c7820fc6ef641b75b5142aea72f1485c73bb1
commit: e4e8bc1df691ba5ba749d1e2b67acf9827e51a35 [245/263] powerpc/kvm: Fix PR KVM with KUAP/MEM_KEYS enabled
config: powerpc64-randconfig-p001-20210421 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=e4e8bc1df691ba5ba749d1e2b67acf9827e51a35
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout e4e8bc1df691ba5ba749d1e2b67acf9827e51a35
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from arch/powerpc/include/asm/book3s/64/pkeys.h:6,
from arch/powerpc/kvm/book3s_64_mmu_host.c:15:
arch/powerpc/include/asm/book3s/64/hash-pkey.h: In function 'hash__vmflag_to_pte_pkey_bits':
>> arch/powerpc/include/asm/book3s/64/hash-pkey.h:10:23: error: 'VM_PKEY_BIT0' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT0'?
10 | return (((vm_flags & VM_PKEY_BIT0) ? H_PTE_PKEY_BIT0 : 0x0UL) |
| ^~~~~~~~~~~~
| H_PTE_PKEY_BIT0
arch/powerpc/include/asm/book3s/64/hash-pkey.h:10:23: note: each undeclared identifier is reported only once for each function it appears in
>> arch/powerpc/include/asm/book3s/64/hash-pkey.h:11:16: error: 'VM_PKEY_BIT1' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT1'?
11 | ((vm_flags & VM_PKEY_BIT1) ? H_PTE_PKEY_BIT1 : 0x0UL) |
| ^~~~~~~~~~~~
| H_PTE_PKEY_BIT1
>> arch/powerpc/include/asm/book3s/64/hash-pkey.h:12:16: error: 'VM_PKEY_BIT2' undeclared (first use in this function)
12 | ((vm_flags & VM_PKEY_BIT2) ? H_PTE_PKEY_BIT2 : 0x0UL) |
| ^~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/hash-pkey.h:13:16: error: 'VM_PKEY_BIT3' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT3'?
13 | ((vm_flags & VM_PKEY_BIT3) ? H_PTE_PKEY_BIT3 : 0x0UL) |
| ^~~~~~~~~~~~
| H_PTE_PKEY_BIT3
>> arch/powerpc/include/asm/book3s/64/hash-pkey.h:14:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT4'?
14 | ((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT4 : 0x0UL));
| ^~~~~~~~~~~~
| H_PTE_PKEY_BIT4
In file included from arch/powerpc/kvm/book3s_64_mmu_host.c:17:
arch/powerpc/include/asm/mmu_context.h: At top level:
>> arch/powerpc/include/asm/mmu_context.h:287:19: error: redefinition of 'pte_to_hpte_pkey_bits'
287 | static inline u64 pte_to_hpte_pkey_bits(u64 pteflags, unsigned long flags)
| ^~~~~~~~~~~~~~~~~~~~~
In file included from arch/powerpc/include/asm/book3s/64/pkeys.h:6,
from arch/powerpc/kvm/book3s_64_mmu_host.c:15:
arch/powerpc/include/asm/book3s/64/hash-pkey.h:17:19: note: previous definition of 'pte_to_hpte_pkey_bits' was here
17 | static inline u64 pte_to_hpte_pkey_bits(u64 pteflags, unsigned long flags)
| ^~~~~~~~~~~~~~~~~~~~~
vim +/pte_to_hpte_pkey_bits +287 arch/powerpc/include/asm/mmu_context.h
87bbabbed8a770 Ram Pai 2018-01-18 286
d94b827e89dc3f Aneesh Kumar K.V 2020-11-27 @287 static inline u64 pte_to_hpte_pkey_bits(u64 pteflags, unsigned long flags)
a6590ca55f1f49 Ram Pai 2018-01-18 288 {
a6590ca55f1f49 Ram Pai 2018-01-18 289 return 0x0UL;
a6590ca55f1f49 Ram Pai 2018-01-18 290 }
a6590ca55f1f49 Ram Pai 2018-01-18 291
:::::: The code at line 287 was first introduced by commit
:::::: d94b827e89dc3f92cd871d10f4992a6bd3c861e5 powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation
:::::: TO: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34521 bytes --]
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS d20f726744a0312b4b6613333bda7da9bc52fb75
From: kernel test robot @ 2021-04-22 1:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: d20f726744a0312b4b6613333bda7da9bc52fb75 Automatic merge of 'next' into merge (2021-04-21 22:57)
elapsed time: 724m
configs tested: 178
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
riscv allmodconfig
x86_64 allyesconfig
i386 allyesconfig
riscv allyesconfig
arm lart_defconfig
mips malta_qemu_32r6_defconfig
mips malta_defconfig
sh shx3_defconfig
um defconfig
powerpc ppc44x_defconfig
mips workpad_defconfig
powerpc currituck_defconfig
powerpc mpc837x_mds_defconfig
powerpc xes_mpc85xx_defconfig
riscv allnoconfig
powerpc pcm030_defconfig
arm s3c6400_defconfig
xtensa iss_defconfig
mips loongson3_defconfig
powerpc iss476-smp_defconfig
arm alldefconfig
arm omap2plus_defconfig
arm tct_hammer_defconfig
mips rs90_defconfig
arm integrator_defconfig
arm footbridge_defconfig
h8300 h8300h-sim_defconfig
xtensa defconfig
alpha defconfig
mips cavium_octeon_defconfig
sh secureedge5410_defconfig
powerpc eiger_defconfig
mips bmips_be_defconfig
m68k sun3_defconfig
arm sunxi_defconfig
sparc defconfig
powerpc asp8347_defconfig
ia64 tiger_defconfig
mips nlm_xlr_defconfig
mips decstation_64_defconfig
m68k hp300_defconfig
mips xway_defconfig
powerpc storcenter_defconfig
mips ci20_defconfig
arm lpc18xx_defconfig
mips bmips_stb_defconfig
arm mvebu_v7_defconfig
powerpc allmodconfig
xtensa nommu_kc705_defconfig
arm ezx_defconfig
mips rbtx49xx_defconfig
arm exynos_defconfig
sh se7619_defconfig
sh urquell_defconfig
m68k apollo_defconfig
arm mvebu_v5_defconfig
powerpc holly_defconfig
m68k m5272c3_defconfig
arm cm_x300_defconfig
arm bcm2835_defconfig
arm keystone_defconfig
ia64 bigsur_defconfig
s390 debug_defconfig
x86_64 alldefconfig
m68k amcore_defconfig
mips capcella_defconfig
um kunit_defconfig
arm oxnas_v6_defconfig
arc vdk_hs38_defconfig
powerpc mgcoge_defconfig
arc nsim_700_defconfig
powerpc wii_defconfig
powerpc ppc64_defconfig
m68k mac_defconfig
arm multi_v7_defconfig
mips maltaup_defconfig
mips bcm47xx_defconfig
powerpc canyonlands_defconfig
arm magician_defconfig
mips jazz_defconfig
arm s3c2410_defconfig
powerpc mpc836x_mds_defconfig
powerpc skiroot_defconfig
mips maltaaprp_defconfig
powerpc mpc836x_rdk_defconfig
powerpc maple_defconfig
sh se7206_defconfig
sh sdk7786_defconfig
powerpc ksi8560_defconfig
arc axs103_defconfig
arm clps711x_defconfig
powerpc mpc834x_itxgp_defconfig
arc nsimosci_hs_smp_defconfig
m68k sun3x_defconfig
sh rsk7201_defconfig
i386 alldefconfig
arc axs103_smp_defconfig
sh sh2007_defconfig
mips loongson1b_defconfig
powerpc mpc8313_rdb_defconfig
powerpc fsp2_defconfig
arm mv78xx0_defconfig
powerpc mpc83xx_defconfig
xtensa alldefconfig
sh se7722_defconfig
openrisc alldefconfig
powerpc acadia_defconfig
mips e55_defconfig
sh migor_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210421
x86_64 randconfig-a002-20210421
x86_64 randconfig-a001-20210421
x86_64 randconfig-a005-20210421
x86_64 randconfig-a006-20210421
x86_64 randconfig-a003-20210421
i386 randconfig-a005-20210421
i386 randconfig-a002-20210421
i386 randconfig-a001-20210421
i386 randconfig-a006-20210421
i386 randconfig-a004-20210421
i386 randconfig-a003-20210421
i386 randconfig-a012-20210421
i386 randconfig-a014-20210421
i386 randconfig-a011-20210421
i386 randconfig-a013-20210421
i386 randconfig-a015-20210421
i386 randconfig-a016-20210421
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210421
x86_64 randconfig-a016-20210421
x86_64 randconfig-a011-20210421
x86_64 randconfig-a014-20210421
x86_64 randconfig-a013-20210421
x86_64 randconfig-a012-20210421
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD REGRESSION f76c7820fc6ef641b75b5142aea72f1485c73bb1
From: kernel test robot @ 2021-04-22 1:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: f76c7820fc6ef641b75b5142aea72f1485c73bb1 powerpc/powernv: Fix type of opal_mpipl_query_tag() addr argument
Error/Warning reports:
https://lore.kernel.org/linuxppc-dev/202104220600.1Zf0gKVF-lkp@intel.com
Error/Warning in current branch:
arch/powerpc/include/asm/book3s/64/hash-pkey.h:10:23: error: 'VM_PKEY_BIT0' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT0'?
arch/powerpc/include/asm/book3s/64/hash-pkey.h:11:16: error: 'VM_PKEY_BIT1' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT1'?
arch/powerpc/include/asm/book3s/64/hash-pkey.h:12:16: error: 'VM_PKEY_BIT2' undeclared (first use in this function)
arch/powerpc/include/asm/book3s/64/hash-pkey.h:13:16: error: 'VM_PKEY_BIT3' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT3'?
arch/powerpc/include/asm/book3s/64/hash-pkey.h:14:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'H_PTE_PKEY_BIT4'?
arch/powerpc/include/asm/mmu_context.h:287:19: error: redefinition of 'pte_to_hpte_pkey_bits'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
`-- powerpc64-randconfig-p001-20210421
|-- arch-powerpc-include-asm-book3s-hash-pkey.h:error:VM_PKEY_BIT0-undeclared-(first-use-in-this-function)
|-- arch-powerpc-include-asm-book3s-hash-pkey.h:error:VM_PKEY_BIT1-undeclared-(first-use-in-this-function)
|-- arch-powerpc-include-asm-book3s-hash-pkey.h:error:VM_PKEY_BIT2-undeclared-(first-use-in-this-function)
|-- arch-powerpc-include-asm-book3s-hash-pkey.h:error:VM_PKEY_BIT3-undeclared-(first-use-in-this-function)
|-- arch-powerpc-include-asm-book3s-hash-pkey.h:error:VM_PKEY_BIT4-undeclared-(first-use-in-this-function)
`-- arch-powerpc-include-asm-mmu_context.h:error:redefinition-of-pte_to_hpte_pkey_bits
elapsed time: 721m
configs tested: 162
configs skipped: 3
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
riscv allmodconfig
x86_64 allyesconfig
i386 allyesconfig
riscv allyesconfig
arm lart_defconfig
mips malta_qemu_32r6_defconfig
mips malta_defconfig
sh shx3_defconfig
powerpc ppc44x_defconfig
um defconfig
mips workpad_defconfig
powerpc currituck_defconfig
powerpc mpc837x_mds_defconfig
powerpc xes_mpc85xx_defconfig
riscv allnoconfig
powerpc pcm030_defconfig
arm s3c6400_defconfig
xtensa iss_defconfig
mips loongson3_defconfig
powerpc iss476-smp_defconfig
arm alldefconfig
arm omap2plus_defconfig
arm tct_hammer_defconfig
mips rs90_defconfig
arm integrator_defconfig
arm footbridge_defconfig
h8300 h8300h-sim_defconfig
xtensa defconfig
alpha defconfig
sparc defconfig
powerpc asp8347_defconfig
ia64 tiger_defconfig
mips nlm_xlr_defconfig
mips decstation_64_defconfig
m68k hp300_defconfig
mips xway_defconfig
powerpc storcenter_defconfig
mips ci20_defconfig
arm lpc18xx_defconfig
mips bmips_stb_defconfig
arm mvebu_v7_defconfig
powerpc allmodconfig
xtensa nommu_kc705_defconfig
arm ezx_defconfig
powerpc eiger_defconfig
mips rbtx49xx_defconfig
arm exynos_defconfig
sh se7619_defconfig
sh sdk7780_defconfig
sh titan_defconfig
arm cm_x300_defconfig
arm bcm2835_defconfig
arm keystone_defconfig
ia64 bigsur_defconfig
s390 debug_defconfig
x86_64 alldefconfig
m68k amcore_defconfig
mips capcella_defconfig
um kunit_defconfig
arm oxnas_v6_defconfig
arc vdk_hs38_defconfig
powerpc mgcoge_defconfig
arc nsim_700_defconfig
powerpc wii_defconfig
mips maltaup_defconfig
mips bcm47xx_defconfig
powerpc canyonlands_defconfig
arm magician_defconfig
mips jazz_defconfig
arm s3c2410_defconfig
powerpc mpc836x_mds_defconfig
powerpc skiroot_defconfig
mips maltaaprp_defconfig
powerpc mpc836x_rdk_defconfig
powerpc maple_defconfig
sh se7206_defconfig
sh sdk7786_defconfig
powerpc ksi8560_defconfig
arc axs103_defconfig
arm clps711x_defconfig
powerpc mpc834x_itxgp_defconfig
arc nsimosci_hs_smp_defconfig
m68k sun3x_defconfig
sh rsk7201_defconfig
i386 alldefconfig
arc axs103_smp_defconfig
m68k apollo_defconfig
sh sh2007_defconfig
sh se7722_defconfig
openrisc alldefconfig
powerpc acadia_defconfig
mips e55_defconfig
sh migor_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210421
x86_64 randconfig-a002-20210421
x86_64 randconfig-a001-20210421
x86_64 randconfig-a005-20210421
x86_64 randconfig-a006-20210421
x86_64 randconfig-a003-20210421
i386 randconfig-a005-20210421
i386 randconfig-a002-20210421
i386 randconfig-a001-20210421
i386 randconfig-a006-20210421
i386 randconfig-a004-20210421
i386 randconfig-a003-20210421
i386 randconfig-a012-20210421
i386 randconfig-a014-20210421
i386 randconfig-a011-20210421
i386 randconfig-a013-20210421
i386 randconfig-a015-20210421
i386 randconfig-a016-20210421
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210421
x86_64 randconfig-a016-20210421
x86_64 randconfig-a011-20210421
x86_64 randconfig-a014-20210421
x86_64 randconfig-a013-20210421
x86_64 randconfig-a012-20210421
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 39352430aaa05fbe4ba710231c70b334513078f2
From: kernel test robot @ 2021-04-22 1:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 39352430aaa05fbe4ba710231c70b334513078f2 powerpc: Move copy_inst_from_kernel_nofault()
elapsed time: 721m
configs tested: 162
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
riscv allmodconfig
x86_64 allyesconfig
i386 allyesconfig
riscv allyesconfig
arm lart_defconfig
mips malta_qemu_32r6_defconfig
mips malta_defconfig
sh shx3_defconfig
powerpc ppc44x_defconfig
um defconfig
mips workpad_defconfig
powerpc currituck_defconfig
powerpc mpc837x_mds_defconfig
powerpc xes_mpc85xx_defconfig
riscv allnoconfig
powerpc pcm030_defconfig
arm s3c6400_defconfig
xtensa iss_defconfig
mips loongson3_defconfig
powerpc iss476-smp_defconfig
arm alldefconfig
arm omap2plus_defconfig
arm tct_hammer_defconfig
mips rs90_defconfig
arm integrator_defconfig
arm footbridge_defconfig
h8300 h8300h-sim_defconfig
xtensa defconfig
alpha defconfig
sparc defconfig
powerpc asp8347_defconfig
ia64 tiger_defconfig
mips nlm_xlr_defconfig
mips decstation_64_defconfig
m68k hp300_defconfig
mips xway_defconfig
powerpc storcenter_defconfig
mips ci20_defconfig
arm lpc18xx_defconfig
mips bmips_stb_defconfig
arm mvebu_v7_defconfig
powerpc allmodconfig
xtensa nommu_kc705_defconfig
arm ezx_defconfig
powerpc eiger_defconfig
mips rbtx49xx_defconfig
arm exynos_defconfig
sh se7619_defconfig
arm cm_x300_defconfig
arm bcm2835_defconfig
arm keystone_defconfig
ia64 bigsur_defconfig
s390 debug_defconfig
x86_64 alldefconfig
m68k amcore_defconfig
mips capcella_defconfig
um kunit_defconfig
arm oxnas_v6_defconfig
arc vdk_hs38_defconfig
powerpc mgcoge_defconfig
arc nsim_700_defconfig
powerpc wii_defconfig
mips maltaup_defconfig
mips bcm47xx_defconfig
powerpc canyonlands_defconfig
powerpc tqm5200_defconfig
powerpc mpc834x_itxgp_defconfig
mips loongson1b_defconfig
arm magician_defconfig
mips jazz_defconfig
arm s3c2410_defconfig
powerpc mpc836x_mds_defconfig
powerpc skiroot_defconfig
mips maltaaprp_defconfig
powerpc mpc836x_rdk_defconfig
powerpc maple_defconfig
sh se7206_defconfig
sh sdk7786_defconfig
powerpc ksi8560_defconfig
arc axs103_defconfig
arm clps711x_defconfig
arc nsimosci_hs_smp_defconfig
m68k sun3x_defconfig
sh rsk7201_defconfig
i386 alldefconfig
arc axs103_smp_defconfig
m68k apollo_defconfig
sh sh2007_defconfig
sh se7722_defconfig
openrisc alldefconfig
powerpc acadia_defconfig
mips e55_defconfig
sh migor_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210421
x86_64 randconfig-a002-20210421
x86_64 randconfig-a001-20210421
x86_64 randconfig-a005-20210421
x86_64 randconfig-a006-20210421
x86_64 randconfig-a003-20210421
i386 randconfig-a005-20210421
i386 randconfig-a002-20210421
i386 randconfig-a001-20210421
i386 randconfig-a006-20210421
i386 randconfig-a004-20210421
i386 randconfig-a003-20210421
i386 randconfig-a012-20210421
i386 randconfig-a014-20210421
i386 randconfig-a011-20210421
i386 randconfig-a013-20210421
i386 randconfig-a015-20210421
i386 randconfig-a016-20210421
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210421
x86_64 randconfig-a016-20210421
x86_64 randconfig-a011-20210421
x86_64 randconfig-a014-20210421
x86_64 randconfig-a013-20210421
x86_64 randconfig-a012-20210421
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: mmu.c:undefined reference to `patch__hash_page_A0'
From: Randy Dunlap @ 2021-04-22 2:16 UTC (permalink / raw)
To: Christophe Leroy, kernel test robot; +Cc: PowerPC, kbuild-all, linux-kernel
In-Reply-To: <fce1f2a1-a4ea-03d1-20ab-f0c716884819@csgroup.eu>
On 4/21/21 1:43 AM, Christophe Leroy wrote:
>
>
> Le 18/04/2021 à 19:15, Randy Dunlap a écrit :
>> On 4/18/21 3:43 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 18/04/2021 à 02:02, Randy Dunlap a écrit :
>>>> HI--
>>>>
>>>> I no longer see this build error.
>>>
>>> Fixed by https://github.com/torvalds/linux/commit/acdad8fb4a1574323db88f98a38b630691574e16
>>>
>>>> However:
>>>>
...
>>>>
>>>> I do see this build error:
>>>>
>>>> powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress':
>>>> decompress.c:(.text+0x1f0): undefined reference to `__decompress'
>>>>
>>>> when either
>>>> CONFIG_KERNEL_LZO=y
>>>> or
>>>> CONFIG_KERNEL_LZMA=y
>>>>
>>>> but the build succeeds when either
>>>> CONFIG_KERNEL_GZIP=y
>>>> or
>>>> CONFIG_KERNEL_XZ=y
>>>>
>>>> I guess that is due to arch/powerpc/boot/decompress.c doing this:
>>>>
>>>> #ifdef CONFIG_KERNEL_GZIP
>>>> # include "decompress_inflate.c"
>>>> #endif
>>>>
>>>> #ifdef CONFIG_KERNEL_XZ
>>>> # include "xz_config.h"
>>>> # include "../../../lib/decompress_unxz.c"
>>>> #endif
>>>>
>>>>
>>>> It would be nice to require one of KERNEL_GZIP or KERNEL_XZ
>>>> to be set/enabled (maybe unless a uImage is being built?).
>>>
>>>
>>> Can you test by https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a74fce4dfc9fa32da6ce3470bbedcecf795de1ec.1591189069.git.christophe.leroy@csgroup.eu/ ?
>>
>> Hi Christophe,
>>
>> I get build errors for both LZO and LZMA:
>>
>
> Can you check with the following changes on top of my patch:
>
> diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
> index a8dbde4b32d4..f06f925385c0 100644
> --- a/lib/decompress_unlzo.c
> +++ b/lib/decompress_unlzo.c
> @@ -23,13 +23,15 @@
> #include <linux/decompress/unlzo.h>
> #endif
>
> -#include <linux/lzo.h>
> #ifdef __KERNEL__
> #include <linux/types.h>
> +#endif
> +#include <linux/lzo.h>
> +#ifdef __KERNEL__
> #include <linux/decompress/mm.h>
> +#include <linux/compiler.h>
> #endif
>
> -#include <linux/compiler.h>
> #include <asm/unaligned.h>
>
> static const unsigned char lzop_magic[] = {
Hi Christophe,
Sorry for the delay -- it's been a very busy day here.
For CONFIG_KERNEL_LZMA=y, I get a couple of warnings:
BOOTCC arch/powerpc/boot/decompress.o
In file included from ../arch/powerpc/boot/decompress.c:38:
../arch/powerpc/boot/../../../lib/decompress_unlzma.c: In function 'unlzma':
../arch/powerpc/boot/../../../lib/decompress_unlzma.c:582:21: warning: pointer targets in passing argument 3 of 'rc_init' differ in signedness [-Wpointer-sign]
582 | rc_init(&rc, fill, inbuf, in_len);
| ^~~~~
| |
| unsigned char *
../arch/powerpc/boot/../../../lib/decompress_unlzma.c:107:18: note: expected 'char *' but argument is of type 'unsigned char *'
107 | char *buffer, long buffer_size)
| ~~~~~~^~~~~~
and for CONFIG_KERNEL_LZO=y, this one warning:
BOOTCC arch/powerpc/boot/decompress.o
In file included from ../arch/powerpc/boot/decompress.c:43:
../arch/powerpc/boot/../../../lib/decompress_unlzo.c: In function 'parse_header':
../arch/powerpc/boot/../../../lib/decompress_unlzo.c:51:5: warning: variable 'level' set but not used [-Wunused-but-set-variable]
51 | u8 level = 0;
| ^~~~~
Note: the patch above did not apply cleanly for me so any problems
above could be due to my mangling the patch.
The patch that I used is below.
Thanks.
---
---
lib/decompress_unlzo.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- linux-next-20210421.orig/lib/decompress_unlzo.c
+++ linux-next-20210421/lib/decompress_unlzo.c
@@ -23,13 +23,16 @@
#include <linux/decompress/unlzo.h>
#endif
-#include <linux/lzo.h>
#ifdef __KERNEL__
#include <linux/types.h>
-#include <linux/decompress/mm.h>
#endif
+#include <linux/lzo.h>
+#ifdef __KERNEL__
+#include <linux/decompress/mm.h>
#include <linux/compiler.h>
+#endif
+
#include <asm/unaligned.h>
static const unsigned char lzop_magic[] = {
^ permalink raw reply
* Re: [PATCH] powerpc: Initialize local variable fdt to NULL in elf64_load()
From: Daniel Axtens @ 2021-04-22 2:21 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, robh, dan.carpenter
Cc: devicetree, linuxppc-dev, kbuild-all, bauerman, lkp
In-Reply-To: <87eefag241.fsf@linkitivity.dja.id.au>
Daniel Axtens <dja@axtens.net> writes:
> Hi Lakshmi,
>
>> On 4/15/21 12:14 PM, Lakshmi Ramasubramanian wrote:
>>
>> Sorry - missed copying device-tree and powerpc mailing lists.
>>
>>> There are a few "goto out;" statements before the local variable "fdt"
>>> is initialized through the call to of_kexec_alloc_and_setup_fdt() in
>>> elf64_load(). This will result in an uninitialized "fdt" being passed
>>> to kvfree() in this function if there is an error before the call to
>>> of_kexec_alloc_and_setup_fdt().
>>>
>>> Initialize the local variable "fdt" to NULL.
>>>
> I'm a huge fan of initialising local variables! But I'm struggling to
> find the code path that will lead to an uninit fdt being returned...
OK, so perhaps this was putting it too strongly. I have been bitten
by uninitialised things enough in C that I may have taken a slightly
overly-agressive view of fixing them in the source rather than the
compiler. I do think compiler-level mitigations are better, and I take
the point that we don't want to defeat compiler checking.
(Does anyone - and by anyone I mean any large distro - compile with
local variables inited by the compiler?)
I was reading the version in powerpc/next, clearly I should have looked
at linux-next. Having said that, I think I will leave the rest of the
bikeshedding to the rest of you, you all seem to have it in hand :)
Kind regards,
Daniel
>
> The out label reads in part:
>
> /* Make kimage_file_post_load_cleanup free the fdt buffer for us. */
> return ret ? ERR_PTR(ret) : fdt;
>
> As far as I can tell, any time we get a non-zero ret, we're going to
> return an error pointer rather than the uninitialised value...
>
> (btw, it does look like we might leak fdt if we have an error after we
> successfully kmalloc it.)
>
> Am I missing something? Can you link to the report for the kernel test
> robot or from Dan?
>
> FWIW, I think it's worth including this patch _anyway_ because initing
> local variables is good practice, but I'm just not sure on the
> justification.
>
> Kind regards,
> Daniel
>
>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> ---
>>> arch/powerpc/kexec/elf_64.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>>> index 5a569bb51349..0051440c1f77 100644
>>> --- a/arch/powerpc/kexec/elf_64.c
>>> +++ b/arch/powerpc/kexec/elf_64.c
>>> @@ -32,7 +32,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>>> int ret;
>>> unsigned long kernel_load_addr;
>>> unsigned long initrd_load_addr = 0, fdt_load_addr;
>>> - void *fdt;
>>> + void *fdt = NULL;
>>> const void *slave_code;
>>> struct elfhdr ehdr;
>>> char *modified_cmdline = NULL;
>>>
>>
>> thanks,
>> -lakshmi
^ permalink raw reply
* RE: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Robin Gong @ 2021-04-22 3:33 UTC (permalink / raw)
To: Lucas Stach, Shengjiu Wang
Cc: sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
Linux-ALSA, linuxppc-dev@lists.ozlabs.org, Timur Tabi, Xiubo Li,
Fabio Estevam, s.hauer@pengutronix.de, Takashi Iwai,
Liam Girdwood, dri-devel@lists.freedesktop.org, linux-kernel,
Nicolin Chen, Mark Brown, dl-linux-imx, kernel@pengutronix.de,
perex@perex.cz, shawnguo@kernel.org, S.j. Wang,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
On 2021/04/22 Lucas Stach <l.stach@pengutronix.de> wrote:
> > But the timer of runtime_auto_suspend decide when enter runtime
> > suspend rather than hardware, while transfer data size and transfer
> > rate on IP bus decide when the dma interrupt happen.
> >
> But it isn't the hardware that decides to drop the rpm refcount to 0 and
> starting the autosuspend timer, it's the driver.
Yes, driver should keep rpm refcount never to 0 in such case. But I think that case
Is a common case in dma cyclic with runtime_auto_suspend, so some dma driver
also add pm_runtime_get_sync/ pm_runtime_put_autosuspend in interrupt handler
like qcom/bam_dma.c for safe rather than only pm_runtime_mark_last_busy().
>
> > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
> > pm_runtime_mark_last_busy in interrupt handler to hope the
> > runtime_auto_suspend timer expiry later than interrupt coming, but if
> > the transfer data size is larger in cyclic and transfer rate is very
> > slow like 115200 or lower on uart, the fix autosuspend timer
> > 100ms/200ms maybe not enough, hence, runtime suspend may execute
> > meanwhile the dma interrupt maybe triggered and caught by GIC(but
> > interrupt handler prevent by spin_lock_irqsave in pm_suspend_timer_fn() ),
> and then interrupt handler start to run after runtime suspend.
>
> If your driver code drops the rpm refcount to 0 and starts the autosuspend
> timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is
> not there to paper over driver bugs, but to amortize cost of actually
> suspending and resuming the hardware. Your driver code must still work even
> if the timeout is 0, i.e. the hardware is immediately suspended after you drop
> the rpm refcount to 0.
>
> If you still have transfers queued/in-flight the driver code must keep a rpm
> reference.
Yes, that's what I said for fix before as below.
'I have a simple workaround that disable runtime suspend in issue_pending worker by
calling pm_runtime_forbid() and then enable runtime auto suspend in dmaengine_terminate_all
so that we could easily regard that edma channel is always in runtime resume between
issue_pending and channel terminated and ignore the above interrupt handler/scu-pd limitation'
^ permalink raw reply
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Lijun Pan @ 2021-04-22 5:06 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: netdev, Lijun Pan, Tom Falcon, Paul Mackerras, Dany Madden,
Jakub Kicinski, linuxppc-dev, David Miller
In-Reply-To: <20210421064527.GA2648262@us.ibm.com>
On Wed, Apr 21, 2021 at 2:25 AM Sukadev Bhattiprolu
<sukadev@linux.ibm.com> wrote:
>
> Lijun Pan [ljp@linux.vnet.ibm.com] wrote:
> >
> >
> > > On Apr 20, 2021, at 4:35 PM, Dany Madden <drt@linux.ibm.com> wrote:
> > >
> > > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > > FATAL reset fails and a transmission timeout reset follows, the CRQ is
> > > still inactive, ibmvnic's attempt to set link down will also fail. If
> > > ibmvnic abandons the reset because of this failed set link down and this
> > > is the last reset in the workqueue, then this adapter will be left in an
> > > inoperable state.
> > >
> > > Instead, make the driver ignore this link down failure and continue to
> > > free and re-register CRQ so that the adapter has an opportunity to
> > > recover.
> >
> > This v2 does not adddress the concerns mentioned in v1.
> > And I think it is better to exit with error from do_reset, and schedule a thorough
> > do_hard_reset if the the adapter is already in unstable state.
>
> We had a FATAL error and when handling it, we failed to send a
> link-down message to the VIOS. So what we need to try next is to
> reset the connection with the VIOS. For this we must talk to the
> firmware using the H_FREE_CRQ and H_REG_CRQ hcalls. do_reset()
> does just that in ibmvnic_reset_crq().
>
> Now, sure we can attempt a "thorough hard reset" which also does
> the same hcalls to reestablish the connection. Is there any
> other magic in do_hard_reset()? But in addition, it also frees lot
> more Linux kernel buffers and reallocates them for instance.
Working around everything in do_reset will make the code very difficult
to manage. Ultimately do_reset can do anything I am afraid, and do_hard_reset
can be removed completely or merged into do_reset.
>
> If we are having a communication problem with the VIOS, what is
> the point of freeing and reallocating Linux kernel buffers? Beside
> being inefficient, it would expose us to even more errors during
> reset under heavy workloads?
No real customer runs the system under that heavy load created by
HTX stress test, which can tear down any working system.
>
> From what I understand so far, do_reset() is complicated because
> it is attempting some optimizations. If we are going to fall back
> to hard reset for every error we might as well drop the do_reset()
> and just do the "thorough hard reset" every time right?
I think such optimizations are catered for passing HTX tests. Whether
the optimization benefits the adapter, say making the adapter more stable,
I doubt it. I think there should be a trade off between optimization
and stability.
^ permalink raw reply
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Lijun Pan @ 2021-04-22 5:12 UTC (permalink / raw)
To: Rick Lindsley
Cc: netdev, Lijun Pan, Tom Falcon, Paul Mackerras, Dany Madden,
Jakub Kicinski, Sukadev Bhattiprolu, linuxppc-dev, David Miller
In-Reply-To: <51a63be8-9b24-3f72-71d0-111959649059@linux.vnet.ibm.com>
On Wed, Apr 21, 2021 at 3:06 AM Rick Lindsley
<ricklind@linux.vnet.ibm.com> wrote:
>
> On 4/20/21 2:42 PM, Lijun Pan wrote:
> >
> > This v2 does not adddress the concerns mentioned in v1.
> > And I think it is better to exit with error from do_reset, and schedule a thorough
> > do_hard_reset if the the adapter is already in unstable state.
>
> But the point is that the testing and analysis has indicated that doing a full
> hard reset is not necessary. We are about to take the very action which will fix
> this situation, but currently do not.
The testing was done on this patch. It was not performed on a full hard reset.
So I don't think you could even compare the two results.
>
> Please describe the advantage in deferring it further by routing it through
> do_hard_reset(). I don't see one.
It is not deferred. It exits with error and calls do_hard_reset.
See my reply to Suka's.
^ permalink raw reply
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Lijun Pan @ 2021-04-22 5:30 UTC (permalink / raw)
To: Dany Madden
Cc: Thomas Falcon, netdev, Paul Mackerras, Jakub Kicinski,
Sukadev Bhattiprolu, linuxppc-dev, David S. Miller
In-Reply-To: <20210420213517.24171-1-drt@linux.ibm.com>
On Tue, Apr 20, 2021 at 4:37 PM Dany Madden <drt@linux.ibm.com> wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive, ibmvnic's attempt to set link down will also fail. If
> ibmvnic abandons the reset because of this failed set link down and this
> is the last reset in the workqueue, then this adapter will be left in an
> inoperable state.
>
> Instead, make the driver ignore this link down failure and continue to
> free and re-register CRQ so that the adapter has an opportunity to
> recover.
>
> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Dany Madden <drt@linux.ibm.com>
> Reviewed-by: Rick Lindsley <ricklind@linux.ibm.com>
> Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
One thing I would like to point out as already pointed out by Nathan Lynch is
that those review-by tags given by the same groups of people from the same
company loses credibility over time if you never critique or ask
questions on the list.
^ permalink raw reply
* [PATCH v5 0/9] Speedup mremap on ppc64
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
Hi,
This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
the platform to support updating higher-level page tables without
updating page table entries. This also needs to invalidate the Page Walk
Cache on architecture supporting the same.
Changes from v4:
* Change function name and arguments based on review feedback.
Changes from v3:
* Fix build error reported by kernel test robot
* Address review feedback.
Changes from v2:
* switch from using mmu_gather to flush_pte_tlb_pwc_range()
Changes from v1:
* Rebase to recent upstream
* Fix build issues with tlb_gather_mmu changes
Aneesh Kumar K.V (9):
selftest/mremap_test: Update the test to handle pagesize other than 4K
selftest/mremap_test: Avoid crash with static build
mm/mremap: Use pmd/pud_poplulate to update page table entries
powerpc/mm/book3s64: Fix possible build error
powerpc/mm/book3s64: Update tlb flush routines to take a page walk
cache flush argument
mm/mremap: Use range flush that does TLB and page walk cache flush
mm/mremap: Move TLB flush outside page table lock
mm/mremap: Allow arch runtime override
powerpc/mm: Enable move pmd/pud
.../include/asm/book3s/64/tlbflush-radix.h | 19 +--
arch/powerpc/include/asm/book3s/64/tlbflush.h | 29 ++++-
arch/powerpc/include/asm/tlb.h | 6 +
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +-
arch/powerpc/mm/book3s64/radix_tlb.c | 55 ++++----
arch/powerpc/platforms/Kconfig.cputype | 2 +
mm/mremap.c | 40 ++++--
tools/testing/selftests/vm/mremap_test.c | 118 ++++++++++--------
8 files changed, 170 insertions(+), 103 deletions(-)
--
2.30.2
^ permalink raw reply
* [PATCH v5 1/9] selftest/mremap_test: Update the test to handle pagesize other than 4K
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 113 ++++++++++++-----------
1 file changed, 61 insertions(+), 52 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index 9c391d016922..c9a5461eb786 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -45,14 +45,15 @@ enum {
_4MB = 4ULL << 20,
_1GB = 1ULL << 30,
_2GB = 2ULL << 30,
- PTE = _4KB,
PMD = _2MB,
PUD = _1GB,
};
+#define PTE page_size
+
#define MAKE_TEST(source_align, destination_align, size, \
overlaps, should_fail, test_name) \
-{ \
+(struct test){ \
.name = test_name, \
.config = { \
.src_alignment = source_align, \
@@ -252,12 +253,17 @@ static int parse_args(int argc, char **argv, unsigned int *threshold_mb,
return 0;
}
+#define MAX_TEST 13
+#define MAX_PERF_TEST 3
int main(int argc, char **argv)
{
int failures = 0;
int i, run_perf_tests;
unsigned int threshold_mb = VALIDATION_DEFAULT_THRESHOLD;
unsigned int pattern_seed;
+ struct test test_cases[MAX_TEST];
+ struct test perf_test_cases[MAX_PERF_TEST];
+ int page_size;
time_t t;
pattern_seed = (unsigned int) time(&t);
@@ -268,56 +274,59 @@ int main(int argc, char **argv)
ksft_print_msg("Test configs:\n\tthreshold_mb=%u\n\tpattern_seed=%u\n\n",
threshold_mb, pattern_seed);
- struct test test_cases[] = {
- /* Expected mremap failures */
- MAKE_TEST(_4KB, _4KB, _4KB, OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source and Destination Regions Overlapping"),
- MAKE_TEST(_4KB, _1KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Destination Address Misaligned (1KB-aligned)"),
- MAKE_TEST(_1KB, _4KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source Address Misaligned (1KB-aligned)"),
-
- /* Src addr PTE aligned */
- MAKE_TEST(PTE, PTE, _8KB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "8KB mremap - Source PTE-aligned, Destination PTE-aligned"),
-
- /* Src addr 1MB aligned */
- MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination PTE-aligned"),
- MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned"),
-
- /* Src addr PMD aligned */
- MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PMD-aligned"),
-
- /* Src addr PUD aligned */
- MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
-
- struct test perf_test_cases[] = {
- /*
- * mremap 1GB region - Page table level aligned time
- * comparison.
- */
- MAKE_TEST(PTE, PTE, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PTE-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PMD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
+ page_size = sysconf(_SC_PAGESIZE);
+
+ /* Expected mremap failures */
+ test_cases[0] = MAKE_TEST(page_size, page_size, page_size,
+ OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source and Destination Regions Overlapping");
+
+ test_cases[1] = MAKE_TEST(page_size, page_size/4, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Destination Address Misaligned (1KB-aligned)");
+ test_cases[2] = MAKE_TEST(page_size/4, page_size, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source Address Misaligned (1KB-aligned)");
+
+ /* Src addr PTE aligned */
+ test_cases[3] = MAKE_TEST(PTE, PTE, PTE * 2,
+ NON_OVERLAPPING, EXPECT_SUCCESS,
+ "8KB mremap - Source PTE-aligned, Destination PTE-aligned");
+
+ /* Src addr 1MB aligned */
+ test_cases[4] = MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination PTE-aligned");
+ test_cases[5] = MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned");
+
+ /* Src addr PMD aligned */
+ test_cases[6] = MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PTE-aligned");
+ test_cases[7] = MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination 1MB-aligned");
+ test_cases[8] = MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PMD-aligned");
+
+ /* Src addr PUD aligned */
+ test_cases[9] = MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PTE-aligned");
+ test_cases[10] = MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination 1MB-aligned");
+ test_cases[11] = MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PMD-aligned");
+ test_cases[12] = MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PUD-aligned");
+
+ perf_test_cases[0] = MAKE_TEST(page_size, page_size, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PTE-aligned, Destination PTE-aligned");
+ /*
+ * mremap 1GB region - Page table level aligned time
+ * comparison.
+ */
+ perf_test_cases[1] = MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PMD-aligned, Destination PMD-aligned");
+ perf_test_cases[2] = MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PUD-aligned, Destination PUD-aligned");
run_perf_tests = (threshold_mb == VALIDATION_NO_THRESHOLD) ||
(threshold_mb * _1MB >= _1GB);
--
2.30.2
^ permalink raw reply related
* [PATCH v5 2/9] selftest/mremap_test: Avoid crash with static build
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Reviewed-by: Kalesh Singh <kaleshsingh@google.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index c9a5461eb786..0624d1bd71b5 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -75,9 +75,10 @@ static void *get_source_mapping(struct config c)
retry:
addr += c.src_alignment;
src_addr = mmap((void *) addr, c.region_size, PROT_READ | PROT_WRITE,
- MAP_FIXED | MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+ MAP_FIXED_NOREPLACE | MAP_ANONYMOUS | MAP_SHARED,
+ -1, 0);
if (src_addr == MAP_FAILED) {
- if (errno == EPERM)
+ if (errno == EPERM || errno == EEXIST)
goto retry;
goto error;
}
--
2.30.2
^ permalink raw reply related
* [PATCH v5 3/9] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index ec8f840399ed..574287f9bb39 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -26,6 +26,7 @@
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
#include "internal.h"
@@ -257,9 +258,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd_clear(old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
+ pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- /* Set the new pmd */
- set_pmd_at(mm, new_addr, new_pmd, pmd);
flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
@@ -306,8 +306,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
- /* Set the new pud */
- set_pud_at(mm, new_addr, new_pud, pud);
+ pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
--
2.30.2
^ permalink raw reply related
* [PATCH v5 4/9] powerpc/mm/book3s64: Fix possible build error
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
Update _tlbiel_pid() such that we can avoid build errors like below when
using this function in other places.
arch/powerpc/mm/book3s64/radix_tlb.c: In function ‘__radix__flush_tlb_range_psize’:
arch/powerpc/mm/book3s64/radix_tlb.c:114:2: warning: ‘asm’ operand 3 probably does not match constraints
114 | asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
| ^~~
arch/powerpc/mm/book3s64/radix_tlb.c:114:2: error: impossible constraint in ‘asm’
make[4]: *** [scripts/Makefile.build:271: arch/powerpc/mm/book3s64/radix_tlb.o] Error 1
m
With this fix, we can also drop the __always_inline in __radix_flush_tlb_range_psize
which was added by commit e12d6d7d46a6 ("powerpc/mm/radix: mark __radix__flush_tlb_range_psize() as __always_inline")
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/radix_tlb.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 409e61210789..817a02ef6032 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -291,22 +291,30 @@ static inline void fixup_tlbie_lpid(unsigned long lpid)
/*
* We use 128 set in radix mode and 256 set in hpt mode.
*/
-static __always_inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
+static inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
{
int set;
asm volatile("ptesync": : :"memory");
- /*
- * Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
- * also flush the entire Page Walk Cache.
- */
- __tlbiel_pid(pid, 0, ric);
+ switch (ric) {
+ case RIC_FLUSH_PWC:
- /* For PWC, only one flush is needed */
- if (ric == RIC_FLUSH_PWC) {
+ /* For PWC, only one flush is needed */
+ __tlbiel_pid(pid, 0, RIC_FLUSH_PWC);
ppc_after_tlbiel_barrier();
return;
+ case RIC_FLUSH_TLB:
+ __tlbiel_pid(pid, 0, RIC_FLUSH_TLB);
+ break;
+ case RIC_FLUSH_ALL:
+ default:
+ /*
+ * Flush the first set of the TLB, and if
+ * we're doing a RIC_FLUSH_ALL, also flush
+ * the entire Page Walk Cache.
+ */
+ __tlbiel_pid(pid, 0, RIC_FLUSH_ALL);
}
if (!cpu_has_feature(CPU_FTR_ARCH_31)) {
@@ -1176,7 +1184,7 @@ void radix__tlb_flush(struct mmu_gather *tlb)
}
}
-static __always_inline void __radix__flush_tlb_range_psize(struct mm_struct *mm,
+static void __radix__flush_tlb_range_psize(struct mm_struct *mm,
unsigned long start, unsigned long end,
int psize, bool also_pwc)
{
--
2.30.2
^ permalink raw reply related
* [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
No functional change in this patch
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
.../include/asm/book3s/64/tlbflush-radix.h | 19 +++++++-----
arch/powerpc/include/asm/book3s/64/tlbflush.h | 23 ++++++++++++---
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +--
arch/powerpc/mm/book3s64/radix_tlb.c | 29 +++++++------------
4 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 8b33601cdb9d..171441a43b35 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -56,15 +56,18 @@ static inline void radix__flush_all_lpid_guest(unsigned int lpid)
}
#endif
-extern void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end);
-extern void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize);
-extern void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end);
-extern void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
+void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ bool flush_pwc);
+void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ bool flush_pwc);
+void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
+ unsigned long end, int psize, bool flush_pwc);
+void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end);
-extern void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end);
+void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end);
+
extern void radix__local_flush_tlb_mm(struct mm_struct *mm);
extern void radix__local_flush_all_mm(struct mm_struct *mm);
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index 215973b4cb26..f9f8a3a264f7 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -45,13 +45,30 @@ static inline void tlbiel_all_lpid(bool radix)
hash__tlbiel_all(TLB_INVAL_SCOPE_LPID);
}
+static inline void flush_pmd_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ bool flush_pwc)
+{
+ if (radix_enabled())
+ return radix__flush_pmd_tlb_range(vma, start, end, flush_pwc);
+ return hash__flush_tlb_range(vma, start, end);
+}
#define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
+{
+ return flush_pmd_tlb_pwc_range(vma, start, end, false);
+}
+
+static inline void flush_hugetlb_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ bool flush_pwc)
{
if (radix_enabled())
- return radix__flush_pmd_tlb_range(vma, start, end);
+ return radix__flush_hugetlb_tlb_range(vma, start, end, flush_pwc);
return hash__flush_tlb_range(vma, start, end);
}
@@ -60,9 +77,7 @@ static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
unsigned long start,
unsigned long end)
{
- if (radix_enabled())
- return radix__flush_hugetlb_tlb_range(vma, start, end);
- return hash__flush_tlb_range(vma, start, end);
+ return flush_hugetlb_tlb_pwc_range(vma, start, end, false);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
diff --git a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
index cb91071eef52..e62f5679b119 100644
--- a/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
+++ b/arch/powerpc/mm/book3s64/radix_hugetlbpage.c
@@ -26,13 +26,13 @@ void radix__local_flush_hugetlb_page(struct vm_area_struct *vma, unsigned long v
}
void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma, unsigned long start,
- unsigned long end)
+ unsigned long end, bool flush_pwc)
{
int psize;
struct hstate *hstate = hstate_file(vma->vm_file);
psize = hstate_get_psize(hstate);
- radix__flush_tlb_range_psize(vma->vm_mm, start, end, psize);
+ radix__flush_tlb_pwc_range_psize(vma->vm_mm, start, end, psize, flush_pwc);
}
/*
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
index 817a02ef6032..5a59e19f9e53 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -1090,7 +1090,7 @@ void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
{
#ifdef CONFIG_HUGETLB_PAGE
if (is_vm_hugetlb_page(vma))
- return radix__flush_hugetlb_tlb_range(vma, start, end);
+ return radix__flush_hugetlb_tlb_range(vma, start, end, false);
#endif
__radix__flush_tlb_range(vma->vm_mm, start, end);
@@ -1151,9 +1151,6 @@ void radix__flush_all_lpid_guest(unsigned int lpid)
_tlbie_lpid_guest(lpid, RIC_FLUSH_ALL);
}
-static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize);
-
void radix__tlb_flush(struct mmu_gather *tlb)
{
int psize = 0;
@@ -1177,10 +1174,8 @@ void radix__tlb_flush(struct mmu_gather *tlb)
else
radix__flush_all_mm(mm);
} else {
- if (!tlb->freed_tables)
- radix__flush_tlb_range_psize(mm, start, end, psize);
- else
- radix__flush_tlb_pwc_range_psize(mm, start, end, psize);
+ radix__flush_tlb_pwc_range_psize(mm, start,
+ end, psize, tlb->freed_tables);
}
}
@@ -1254,16 +1249,10 @@ static void __radix__flush_tlb_range_psize(struct mm_struct *mm,
preempt_enable();
}
-void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize)
+void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
+ unsigned long end, int psize, bool flush_pwc)
{
- return __radix__flush_tlb_range_psize(mm, start, end, psize, false);
-}
-
-static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
- unsigned long end, int psize)
-{
- __radix__flush_tlb_range_psize(mm, start, end, psize, true);
+ __radix__flush_tlb_range_psize(mm, start, end, psize, flush_pwc);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -1315,9 +1304,11 @@ void radix__flush_tlb_collapsed_pmd(struct mm_struct *mm, unsigned long addr)
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end,
+ bool flush_pwc)
{
- radix__flush_tlb_range_psize(vma->vm_mm, start, end, MMU_PAGE_2M);
+ __radix__flush_tlb_range_psize(vma->vm_mm, start,
+ end, MMU_PAGE_2M, flush_pwc);
}
EXPORT_SYMBOL(radix__flush_pmd_tlb_range);
--
2.30.2
^ permalink raw reply related
* [PATCH v5 6/9] mm/mremap: Use range flush that does TLB and page walk cache flush
From: Aneesh Kumar K.V @ 2021-04-22 5:43 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: Aneesh Kumar K.V, npiggin, kaleshsingh, joel, linuxppc-dev
In-Reply-To: <20210422054323.150993-1-aneesh.kumar@linux.ibm.com>
Some architectures do have the concept of page walk cache which need
to be flush when updating higher levels of page tables. A fast mremap
that involves moving page table pages instead of copying pte entries
should flush page walk cache since the old translation cache is no more
valid.
Add new helper flush_pte_tlb_pwc_range() which invalidates both TLB and
page walk cache where TLB entries are mapped with page size PAGE_SIZE.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/book3s/64/tlbflush.h | 10 ++++++++++
mm/mremap.c | 14 ++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index f9f8a3a264f7..e84fee9db106 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -80,6 +80,16 @@ static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
return flush_hugetlb_tlb_pwc_range(vma, start, end, false);
}
+#define flush_pte_tlb_pwc_range flush_tlb_pwc_range
+static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ if (radix_enabled())
+ return radix__flush_tlb_pwc_range_psize(vma->vm_mm, start,
+ end, mmu_virtual_psize, true);
+ return hash__flush_tlb_range(vma, start, end);
+}
+
static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
diff --git a/mm/mremap.c b/mm/mremap.c
index 574287f9bb39..109560977944 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -210,6 +210,16 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
drop_rmap_locks(vma);
}
+#ifndef flush_pte_tlb_pwc_range
+#define flush_pte_tlb_pwc_range flush_pte_tlb_pwc_range
+static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end)
+{
+ return flush_tlb_range(vma, start, end);
+}
+#endif
+
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
@@ -260,7 +270,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
@@ -307,7 +317,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
- flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+ flush_pte_tlb_pwc_range(vma, old_addr, old_addr + PUD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
--
2.30.2
^ permalink raw reply related
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