* Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible
From: Segher Boessenkool @ 2021-04-14 17:20 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras,
linux-kernel@vger.kernel.org, Nicholas Piggin
In-Reply-To: <efcabc9410cf4d03b203749a02e5a935@AcuMS.aculab.com>
On Wed, Apr 14, 2021 at 03:32:04PM +0000, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 14 April 2021 16:19
> ...
> > > Could the kernel use GCC builtin atomic functions instead ?
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> >
> > Certainly that should work fine for the simpler cases that the atomic
> > operations are meant to provide. But esp. for not-so-simple cases the
> > kernel may require some behaviour provided by the existing assembler
> > implementation, and not by the atomic builtins.
> >
> > I'm not saying this cannot work, just that some serious testing will be
> > needed. If it works it should be the best of all worlds, so then it is
> > a really good idea yes :-)
>
> I suspect they just add an extra layer of abstraction that makes it
> even more difficult to verify and could easily get broken by a compiler
> update (etc).
I would say it uses an existing facility, instead of creating a kernel-
specific one.
> The other issue is that the code needs to be correct with compiled
> with (for example) -O0.
> That could very easily break anything except the asm implementation
> if additional memory accesses and/or increased code size cause grief.
The compiler generates correct code. New versions of the compiler or
old, -O0 or not, under any phase of the moon.
Of course sometimes the compiler is broken, but there are pre-existing
ways of dealing with that, and there is no reason at all to think this
would break more often than random other code.
Segher
^ permalink raw reply
* Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
From: Jesper Dangaard Brouer @ 2021-04-14 19:13 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Arnd Bergmann, Grygorii Strashko, netdev, Ilias Apalodimas,
linux-mips, linux-kernel, linux-mm, brouer, Matteo Croce,
linuxppc-dev, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20210414115052.GS2531743@casper.infradead.org>
On Wed, 14 Apr 2021 12:50:52 +0100
Matthew Wilcox <willy@infradead.org> wrote:
> > That said, I think we need to have a quicker fix for the immediate
> > issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
> > it leaves[3] in struct page. In[3] you mention ppc32, does it only
> > happens on certain 32-bit archs?
>
> AFAICT it happens on mips32, ppc32, arm32 and arc. It doesn't happen
> on x86-32 because dma_addr_t is 32-bit aligned.
(If others want to reproduce). First I could not reproduce on ARM32.
Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
Details below signature.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
From file: arch/arm/Kconfig
config XEN
bool "Xen guest support on ARM"
depends on ARM && AEABI && OF
depends on CPU_V7 && !CPU_V6
depends on !GENERIC_ATOMIC64
depends on MMU
select ARCH_DMA_ADDR_T_64BIT
select ARM_PSCI
select SWIOTLB
select SWIOTLB_XEN
select PARAVIRT
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
My make compile command:
export VERSION=gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/
export CROSS_COMPILE="/home/${USER}/cross-compilers/${VERSION}/bin/arm-none-linux-gnueabihf-"
make -j8 ARCH=arm CROSS_COMPILE=$CROSS_COMPILE
Pahole output:
$ pahole -C page mm/page_alloc.o
struct page {
long unsigned int flags; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
union {
struct {
struct list_head lru; /* 8 8 */
struct address_space * mapping; /* 16 4 */
long unsigned int index; /* 20 4 */
long unsigned int private; /* 24 4 */
}; /* 8 20 */
struct {
dma_addr_t dma_addr; /* 8 8 */
}; /* 8 8 */
struct {
union {
struct list_head slab_list; /* 8 8 */
struct {
struct page * next; /* 8 4 */
short int pages; /* 12 2 */
short int pobjects; /* 14 2 */
}; /* 8 8 */
}; /* 8 8 */
struct kmem_cache * slab_cache; /* 16 4 */
void * freelist; /* 20 4 */
union {
void * s_mem; /* 24 4 */
long unsigned int counters; /* 24 4 */
struct {
unsigned int inuse:16; /* 24: 0 4 */
unsigned int objects:15; /* 24:16 4 */
unsigned int frozen:1; /* 24:31 4 */
}; /* 24 4 */
}; /* 24 4 */
}; /* 8 20 */
struct {
long unsigned int compound_head; /* 8 4 */
unsigned char compound_dtor; /* 12 1 */
unsigned char compound_order; /* 13 1 */
/* XXX 2 bytes hole, try to pack */
atomic_t compound_mapcount; /* 16 4 */
unsigned int compound_nr; /* 20 4 */
}; /* 8 16 */
struct {
long unsigned int _compound_pad_1; /* 8 4 */
atomic_t hpage_pinned_refcount; /* 12 4 */
struct list_head deferred_list; /* 16 8 */
}; /* 8 16 */
struct {
long unsigned int _pt_pad_1; /* 8 4 */
pgtable_t pmd_huge_pte; /* 12 4 */
long unsigned int _pt_pad_2; /* 16 4 */
union {
struct mm_struct * pt_mm; /* 20 4 */
atomic_t pt_frag_refcount; /* 20 4 */
}; /* 20 4 */
spinlock_t ptl; /* 24 4 */
}; /* 8 20 */
struct {
struct dev_pagemap * pgmap; /* 8 4 */
void * zone_device_data; /* 12 4 */
}; /* 8 8 */
struct callback_head callback_head __attribute__((__aligned__(4))); /* 8 8 */
} __attribute__((__aligned__(8))); /* 8 24 */
union {
atomic_t _mapcount; /* 32 4 */
unsigned int page_type; /* 32 4 */
unsigned int active; /* 32 4 */
int units; /* 32 4 */
}; /* 32 4 */
atomic_t _refcount; /* 36 4 */
/* size: 40, cachelines: 1, members: 4 */
/* sum members: 36, holes: 1, sum holes: 4 */
/* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
/* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible
From: Ira Weiny @ 2021-04-14 21:24 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, Aneesh Kumar K . V, Dan Williams,
linuxppc-dev
In-Reply-To: <87lf9kkfaj.fsf@vajain21.in.ibm.com>
On Wed, Apr 14, 2021 at 09:51:40PM +0530, Vaibhav Jain wrote:
> Thanks for looking into this patch Ira,
>
> Ira Weiny <ira.weiny@intel.com> writes:
>
> > On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
> >> Currently drc_pmem_qeury_stats() generates a dev_err in case
> >> "Enable Performance Information Collection" feature is disabled from
> >> HMC. The error is of the form below:
> >>
> >> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
> >> performance stats, Err:-10
> >>
> >> This error message confuses users as it implies a possible problem
> >> with the nvdimm even though its due to a disabled feature.
> >>
> >> So we fix this by explicitly handling the H_AUTHORITY error from the
> >> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
> >> error, saying that "Performance stats in-accessible".
> >>
> >> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from PHYP')
> >> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> >> ---
> >> arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> >> index 835163f54244..9216424f8be3 100644
> >> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> >> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> >> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
> >> dev_err(&p->pdev->dev,
> >> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
> >> return -ENOENT;
> >> + } else if (rc == H_AUTHORITY) {
> >> + dev_warn(&p->pdev->dev, "Performance stats in-accessible");
> >> + return -EPERM;
> >
> > Is this because of a disabled feature or because of permissions?
>
> Its because of a disabled feature that revokes permission for a guest to
> retrieve performance statistics.
>
> The feature is called "Enable Performance Information Collection" and
> once disabled the hcall H_SCM_PERFORMANCE_STATS returns an error
> H_AUTHORITY indicating that the guest doesn't have permission to retrieve
> performance statistics.
In that case would it be appropriate to have the error message indicate a
permission issue?
Something like 'permission denied'?
Ira
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible
From: Dan Williams @ 2021-04-14 21:32 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, Ira Weiny, linux-nvdimm, Aneesh Kumar K . V,
linuxppc-dev
In-Reply-To: <20210414124026.332472-1-vaibhav@linux.ibm.com>
On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain <vaibhav@linux.ibm.com> wrote:
>
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
> performance stats, Err:-10
>
> This error message confuses users as it implies a possible problem
> with the nvdimm even though its due to a disabled feature.
>
> So we fix this by explicitly handling the H_AUTHORITY error from the
> H_SCM_PERFORMANCE_STATS hcall and generating a warning instead of an
> error, saying that "Performance stats in-accessible".
>
> Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from PHYP')
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 835163f54244..9216424f8be3 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -277,6 +277,9 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
> dev_err(&p->pdev->dev,
> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
> return -ENOENT;
> + } else if (rc == H_AUTHORITY) {
> + dev_warn(&p->pdev->dev, "Performance stats in-accessible");
> + return -EPERM;
So userspace can spam the kernel log? Why is kernel log message needed
at all? EPERM told the caller what happened.
^ permalink raw reply
* Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
From: Matthew Wilcox @ 2021-04-14 21:35 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Arnd Bergmann, Grygorii Strashko, netdev, Ilias Apalodimas,
linux-mips, linux-kernel, linux-mm, Matteo Croce, linuxppc-dev,
Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20210414211322.3799afd4@carbon>
On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> (If others want to reproduce). First I could not reproduce on ARM32.
> Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
hmmm ... you should be able to provoke it by enabling ARM_LPAE,
which selects PHYS_ADDR_T_64BIT, and
config ARCH_DMA_ADDR_T_64BIT
def_bool 64BIT || PHYS_ADDR_T_64BIT
> struct page {
> long unsigned int flags; /* 0 4 */
>
> /* XXX 4 bytes hole, try to pack */
>
> union {
> struct {
> struct list_head lru; /* 8 8 */
> struct address_space * mapping; /* 16 4 */
> long unsigned int index; /* 20 4 */
> long unsigned int private; /* 24 4 */
> }; /* 8 20 */
> struct {
> dma_addr_t dma_addr; /* 8 8 */
> }; /* 8 8 */
[...]
> } __attribute__((__aligned__(8))); /* 8 24 */
> union {
> atomic_t _mapcount; /* 32 4 */
> unsigned int page_type; /* 32 4 */
> unsigned int active; /* 32 4 */
> int units; /* 32 4 */
> }; /* 32 4 */
> atomic_t _refcount; /* 36 4 */
>
> /* size: 40, cachelines: 1, members: 4 */
> /* sum members: 36, holes: 1, sum holes: 4 */
> /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
> /* last cacheline: 40 bytes */
> } __attribute__((__aligned__(8)));
If you also enable CONFIG_MEMCG or enough options to make
LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte
hole at the end.
^ permalink raw reply
* RE: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Robin Gong @ 2021-04-14 14: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, linux-kernel,
Timur Tabi, Xiubo Li, shawnguo@kernel.org, S.j. Wang,
Takashi Iwai, Liam Girdwood, dri-devel@lists.freedesktop.org,
perex@perex.cz, Nicolin Chen, Mark Brown, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
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_dma_cyclic/
device_tx_status...
pm_runtime_use_autosuspend(fsl_chan->dev);
pm_runtime_set_autosuspend_delay(fsl_chan->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.
>
> > > > - With FE-BE case, if the dma channel is requested in probe, then
> > > > there will be below issue, which is caused by that the dma channel
> > > > will be requested duplicately
> > >
> > > Why is this requested a second time? Is this just some missing
> > > cleanup on a deferred probe path?
> >
> > Not relate with deferred probe. With DMA1->ASRC->DMA2->ESAI case, the
> > DMA1->ASRC->DMA2 is in FE, ESAI is in BE. When ESAI drvier probe,
> > DMA3 channel is created with ESAI's "dma:tx" (DMA3 channel
> > is not used in this FE-BE case). When FE-BE startup, DMA2
> > channel is created, it needs the ESAI's "dma:tx", so below warning
> > comes out.
> >
> > > Regards,
> > > Lucas
> > >
> > > > [ 638.906268] sysfs: cannot create duplicate filename
> '/devices/soc0/soc/2000000.bus/2000000.spba-bus/2024000.esai/dma:tx'
> > > > [ 638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted
> > > > 5.7.0-rc1-12956-gfc64b2585593 #287 [ 638.927113] Hardware name:
> > > > Freescale i.MX6 Quad/DualLite (Device Tree) [ 638.933690]
> > > > [<c0110dd8>] (unwind_backtrace) from [<c010b8ec>]
> > > > (show_stack+0x10/0x14) [ 638.941464] [<c010b8ec>] (show_stack)
> > > > from [<c0557fc0>] (dump_stack+0xe4/0x118) [ 638.948808]
> > > > [<c0557fc0>] (dump_stack) from [<c032aeb4>]
> > > > (sysfs_warn_dup+0x50/0x64) [ 638.956406] [<c032aeb4>]
> > > > (sysfs_warn_dup) from [<c032b1a8>]
> > > > (sysfs_do_create_link_sd+0xc8/0xd4)
> > > > [ 638.965134] [<c032b1a8>] (sysfs_do_create_link_sd) from
> > > > [<c05dc668>] (dma_request_chan+0xb0/0x210) [ 638.974120]
> > > > [<c05dc668>] (dma_request_chan) from [<c05dc7d0>]
> > > > (dma_request_slave_channel+0x8/0x14)
> > > > [ 638.983111] [<c05dc7d0>] (dma_request_slave_channel) from
> > > > [<c09d5548>] (fsl_asrc_dma_hw_params+0x1e0/0x438)
> > > > [ 638.992881] [<c09d5548>] (fsl_asrc_dma_hw_params) from
> > > > [<c09c1654>] (soc_pcm_hw_params+0x4a0/0x6a8) [ 639.001952]
> > > > [<c09c1654>] (soc_pcm_hw_params) from [<c09c39d4>]
> > > > (dpcm_fe_dai_hw_params+0x70/0xe4) [ 639.010765] [<c09c39d4>]
> > > > (dpcm_fe_dai_hw_params) from [<c099b274>]
> > > > (snd_pcm_hw_params+0x158/0x418) [ 639.019750] [<c099b274>]
> > > > (snd_pcm_hw_params) from [<c099c5a0>]
> (snd_pcm_ioctl+0x734/0x183c) [ 639.028129] [<c099c5a0>] (snd_pcm_ioctl)
> from [<c029ff94>] (ksys_ioctl+0x2ac/0xb98) [ 639.035812] [<c029ff94>]
> (ksys_ioctl) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [ 639.043490]
> Exception stack(0xec529fa8 to 0xec529ff0)
> > > > [ 639.048565] 9fa0: bee84650 01321870
> 00000004 c25c4111 bee84650 0002000f
> > > > [ 639.056766] 9fc0: bee84650 01321870 01321820 00000036
> 00001f40
> > > > 00000000 0002c2f8 00000003 [ 639.064964] 9fe0: b6f483fc bee8451c
> > > > b6ee2655 b6e1dcf8 [ 639.070339] fsl-esai-dai 2024000.esai: Cannot
> > > > create DMA dma:tx symlink
> > > >
> > > > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > > > ---
> > > > sound/soc/fsl/imx-pcm-dma.c | 173
> > > > +++++++++++++++++++++++++++++++++---
> > > > 1 file changed, 159 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/sound/soc/fsl/imx-pcm-dma.c
> > > > b/sound/soc/fsl/imx-pcm-dma.c index 04a9bc749016..dae53b384df4
> > > > 100644
> > > > --- a/sound/soc/fsl/imx-pcm-dma.c
> > > > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > > > @@ -11,6 +11,7 @@
> > > > #include <linux/dmaengine.h>
> > > > #include <linux/types.h>
> > > > #include <linux/module.h>
> > > > +#include <linux/dma-mapping.h>
> > > >
> > > > #include <sound/core.h>
> > > > #include <sound/pcm.h>
> > > > @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void
> *param)
> > > > return true;
> > > > }
> > > >
> > > > -static const struct snd_dmaengine_pcm_config
> imx_dmaengine_pcm_config = {
> > > > - .prepare_slave_config =
> snd_dmaengine_pcm_prepare_slave_config,
> > > > - .compat_filter_fn = filter,
> > > > -};
> > > > +static int imx_pcm_hw_params(struct snd_soc_component
> *component,
> > > > + struct snd_pcm_substream *substream,
> > > > + struct snd_pcm_hw_params *params) {
> > > > + struct snd_pcm_runtime *runtime = substream->runtime;
> > > > + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > + struct snd_dmaengine_dai_dma_data *dma_data;
> > > > + struct dma_slave_config config;
> > > > + struct dma_chan *chan;
> > > > + int ret = 0;
> > > >
> > > > -int imx_pcm_dma_init(struct platform_device *pdev, size_t size)
> > > > + snd_pcm_set_runtime_buffer(substream,
> &substream->dma_buffer);
> > > > + runtime->dma_bytes = params_buffer_bytes(params);
> > > > +
> > > > + chan = snd_dmaengine_pcm_get_chan(substream);
> > > > + if (!chan)
> > > > + return -EINVAL;
> > > > +
> > > > + ret = snd_hwparams_to_dma_slave_config(substream, params,
> &config);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > + if (!dma_data)
> > > > + return -EINVAL;
> > > > +
> > > > + snd_dmaengine_pcm_set_config_from_dai_data(substream,
> > > > + dma_data,
> > > > + &config);
> > > > + return dmaengine_slave_config(chan, &config); }
> > > > +
> > > > +static int imx_pcm_hw_free(struct snd_soc_component *component,
> > > > + struct snd_pcm_substream *substream)
> > > > {
> > > > - struct snd_dmaengine_pcm_config *config;
> > > > + snd_pcm_set_runtime_buffer(substream, NULL);
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component
> *component,
> > > > + struct snd_pcm_substream
> > > > +*substream) {
> > > > + return snd_dmaengine_pcm_pointer(substream);
> > > > +}
> > > > +
> > > > +static int imx_pcm_trigger(struct snd_soc_component *component,
> > > > + struct snd_pcm_substream *substream, int
> > > > +cmd) {
> > > > + return snd_dmaengine_pcm_trigger(substream, cmd); }
> > > > +
> > > > +static int imx_pcm_open(struct snd_soc_component *component,
> > > > + struct snd_pcm_substream *substream) {
> > > > + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > + bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > > > + struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > + struct snd_dmaengine_dai_dma_data *dma_data;
> > > > + struct device *dev = component->dev;
> > > > + struct snd_pcm_hardware hw;
> > > > + struct dma_chan *chan;
> > > > + int ret;
> > > > +
> > > > + ret = snd_pcm_hw_constraint_integer(substream->runtime,
> > > > +
> SNDRV_PCM_HW_PARAM_PERIODS);
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "failed to set pcm hw params periods\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > + if (!dma_data)
> > > > + return -EINVAL;
> > > > +
> > > > + chan = dma_request_slave_channel(cpu_dai->dev, tx ? "tx" : "rx");
> > > > + if (!chan) {
> > > > + /* Try to request channel using compat_filter_fn */
> > > > + chan = snd_dmaengine_pcm_request_channel(filter,
> > > > +
> dma_data->filter_data);
> > > > + if (!chan)
> > > > + return -ENXIO;
> > > > + }
> > > >
> > > > - config = devm_kzalloc(&pdev->dev,
> > > > - sizeof(struct snd_dmaengine_pcm_config),
> GFP_KERNEL);
> > > > - if (!config)
> > > > - return -ENOMEM;
> > > > - *config = imx_dmaengine_pcm_config;
> > > > + ret = snd_dmaengine_pcm_open(substream, chan);
> > > > + if (ret)
> > > > + goto pcm_open_fail;
> > > >
> > > > - return devm_snd_dmaengine_pcm_register(&pdev->dev,
> > > > - config,
> > > > - SND_DMAENGINE_PCM_FLAG_COMPAT);
> > > > + memset(&hw, 0, sizeof(hw));
> > > > + hw.info = SNDRV_PCM_INFO_MMAP |
> SNDRV_PCM_INFO_MMAP_VALID |
> > > > + SNDRV_PCM_INFO_INTERLEAVED;
> > > > + hw.periods_min = 2;
> > > > + hw.periods_max = UINT_MAX;
> > > > + hw.period_bytes_min = 256;
> > > > + hw.period_bytes_max =
> dma_get_max_seg_size(chan->device->dev);
> > > > + hw.buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE;
> > > > + hw.fifo_size = dma_data->fifo_size;
> > > > +
> > > > + /* Refine the hw according to caps of DMA. */
> > > > + ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream,
> > > > +
> dma_data,
> > > > + &hw,
> > > > + chan);
> > > > + if (ret < 0)
> > > > + goto refine_runtime_hwparams_fail;
> > > > +
> > > > + snd_soc_set_runtime_hwparams(substream, &hw);
> > > > +
> > > > + /* Support allocate memory from IRAM */
> > > > + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_IRAM,
> > > > + chan->device->dev,
> > > > + hw.buffer_bytes_max,
> > > > + &substream->dma_buffer);
> > > > + if (ret < 0)
> > > > + goto alloc_pagas_fail;
> > > > +
> > > > + return 0;
> > > > +
> > > > +alloc_pagas_fail:
> > > > +refine_runtime_hwparams_fail:
> > > > + snd_dmaengine_pcm_close(substream);
> > > > +pcm_open_fail:
> > > > + dma_release_channel(chan);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int imx_pcm_close(struct snd_soc_component *component,
> > > > + struct snd_pcm_substream *substream) {
> > > > + if (substream) {
> > > > + snd_dma_free_pages(&substream->dma_buffer);
> > > > + substream->dma_buffer.area = NULL;
> > > > + substream->dma_buffer.addr = 0;
> > > > + }
> > > > +
> > > > + return snd_dmaengine_pcm_close_release_chan(substream);
> > > > +}
> > > > +
> > > > +static int imx_pcm_new(struct snd_soc_component *component,
> > > > + struct snd_soc_pcm_runtime *rtd) {
> > > > + struct snd_card *card = rtd->card->snd_card;
> > > > +
> > > > + return dma_coerce_mask_and_coherent(card->dev,
> > > > +DMA_BIT_MASK(32)); }
> > > > +
> > > > +static const struct snd_soc_component_driver imx_pcm_component = {
> > > > + .name = "imx-pcm-dma",
> > > > + .pcm_construct = imx_pcm_new,
> > > > + .open = imx_pcm_open,
> > > > + .close = imx_pcm_close,
> > > > + .hw_params = imx_pcm_hw_params,
> > > > + .hw_free = imx_pcm_hw_free,
> > > > + .trigger = imx_pcm_trigger,
> > > > + .pointer = imx_pcm_pointer,
> > > > +};
> > > > +
> > > > +int imx_pcm_dma_init(struct platform_device *pdev, size_t size) {
> > > > + return devm_snd_soc_register_component(&pdev->dev,
> > > > +
> &imx_pcm_component,
> > > > +NULL, 0);
> > > > }
> > > > EXPORT_SYMBOL_GPL(imx_pcm_dma_init);
> > > >
^ permalink raw reply
* RE: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
From: David Laight @ 2021-04-14 21:56 UTC (permalink / raw)
To: 'Matthew Wilcox', Jesper Dangaard Brouer
Cc: Arnd Bergmann, Grygorii Strashko, netdev@vger.kernel.org,
Ilias Apalodimas, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matteo Croce,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20210414213556.GY2531743@casper.infradead.org>
From: Matthew Wilcox
> Sent: 14 April 2021 22:36
>
> On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > (If others want to reproduce). First I could not reproduce on ARM32.
> > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
>
> hmmm ... you should be able to provoke it by enabling ARM_LPAE,
> which selects PHYS_ADDR_T_64BIT, and
>
> config ARCH_DMA_ADDR_T_64BIT
> def_bool 64BIT || PHYS_ADDR_T_64BIT
>
> > struct page {
> > long unsigned int flags; /* 0 4 */
> >
> > /* XXX 4 bytes hole, try to pack */
> >
> > union {
> > struct {
> > struct list_head lru; /* 8 8 */
> > struct address_space * mapping; /* 16 4 */
> > long unsigned int index; /* 20 4 */
> > long unsigned int private; /* 24 4 */
> > }; /* 8 20 */
> > struct {
> > dma_addr_t dma_addr
Adding __packed here will remove the 4 byte hole before the union
and the compiler seems clever enough to know that anything following
a 'long' must also be 'long' aligned.
So you don't get anything horrid like byte accesses.
On 64bit dma_addr will remain 64bit aligned.
On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access
won't make any difference.
So definitely the only simple fix.
David
> > ; /* 8 8 */
> > }; /* 8 8 */
> [...]
> > } __attribute__((__aligned__(8))); /* 8 24 */
> > union {
> > atomic_t _mapcount; /* 32 4 */
> > unsigned int page_type; /* 32 4 */
> > unsigned int active; /* 32 4 */
> > int units; /* 32 4 */
> > }; /* 32 4 */
> > atomic_t _refcount; /* 36 4 */
> >
> > /* size: 40, cachelines: 1, members: 4 */
> > /* sum members: 36, holes: 1, sum holes: 4 */
> > /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
> > /* last cacheline: 40 bytes */
> > } __attribute__((__aligned__(8)));
>
> If you also enable CONFIG_MEMCG or enough options to make
> LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte
> hole at the end.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* linux-next: build warning after merge of the powerpc tree
From: Stephen Rothwell @ 2021-04-14 23:36 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Yu Kuai, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/macintosh/via-pmu.c:190:12: warning: '__fake_sleep' defined but not used [-Wunused-variable]
190 | static int __fake_sleep;
| ^~~~~~~~~~~~
Introduced by commit
95d143923379 ("macintosh/via-pmu: Make some symbols static")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/5] powerpc/rtas: miscellaneous cleanups
From: Nathan Lynch @ 2021-04-15 0:23 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
Cc: tyreld, ajd, aik, aneesh.kumar, npiggin, brking
In-Reply-To: <231da5db-efdd-0ddd-9ad8-4ddd2bc03ddf@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 08/04/2021 à 16:06, Nathan Lynch a écrit :
>> This is a reroll of the series posted here:
>> https://lore.kernel.org/linuxppc-dev/20210114220004.1138993-1-nathanl@linux.ibm.com/
>>
>> Originally this work was prompted by failures on radix MMU PowerVM
>> guests when passing buffers to RTAS that lay outside of its idea of
>> the RMA. In v1 I approached this as a problem to be solved in Linux,
>> but RTAS development has since decided to change their code so that
>> the RMA restriction does not apply with radix.
>>
>> So in v2 I retain the cleanups and discard the more significant change
>> which accommodated the misbehaving RTAS versions.
>
> Is there a link with https://github.com/linuxppc/issues/issues/252 ?
>
No, not really.
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 0702e74703f57173e70cfab2a79a3e682e9e96ec
From: kernel test robot @ 2021-04-15 2:45 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: 0702e74703f57173e70cfab2a79a3e682e9e96ec Automatic merge of 'next' into merge (2021-04-12 13:33)
elapsed time: 4223m
configs tested: 180
configs skipped: 2
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
x86_64 allyesconfig
riscv allmodconfig
riscv allyesconfig
i386 allyesconfig
arc vdk_hs38_defconfig
sparc alldefconfig
m68k sun3x_defconfig
mips maltaup_xpa_defconfig
powerpc mpc83xx_defconfig
ia64 bigsur_defconfig
powerpc maple_defconfig
arm ep93xx_defconfig
mips e55_defconfig
ia64 gensparse_defconfig
powerpc mpc866_ads_defconfig
mips xway_defconfig
powerpc cm5200_defconfig
arm iop32x_defconfig
mips nlm_xlp_defconfig
arm lart_defconfig
arm shannon_defconfig
powerpc powernv_defconfig
arm realview_defconfig
alpha defconfig
mips tb0287_defconfig
arm pxa3xx_defconfig
sh se7722_defconfig
powerpc ep8248e_defconfig
x86_64 defconfig
arm h3600_defconfig
xtensa defconfig
um kunit_defconfig
arm omap2plus_defconfig
mips ip27_defconfig
m68k mvme16x_defconfig
arm ixp4xx_defconfig
sh rsk7264_defconfig
powerpc mpc834x_itxgp_defconfig
arm spear6xx_defconfig
mips bmips_stb_defconfig
mips malta_defconfig
arm bcm2835_defconfig
arm mvebu_v7_defconfig
sh sh7710voipgw_defconfig
mips vocore2_defconfig
arm sunxi_defconfig
mips ip28_defconfig
mips tb0219_defconfig
parisc defconfig
arm imx_v6_v7_defconfig
sh j2_defconfig
microblaze mmu_defconfig
powerpc ps3_defconfig
alpha alldefconfig
powerpc mpc8272_ads_defconfig
powerpc currituck_defconfig
mips ath25_defconfig
mips gpr_defconfig
mips ci20_defconfig
arc vdk_hs38_smp_defconfig
mips mpc30x_defconfig
powerpc allnoconfig
arm axm55xx_defconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
mips decstation_defconfig
powerpc tqm8548_defconfig
sh defconfig
mips rm200_defconfig
sparc sparc64_defconfig
arm magician_defconfig
arc alldefconfig
powerpc mpc7448_hpc2_defconfig
m68k m5307c3_defconfig
arm mmp2_defconfig
arm cns3420vb_defconfig
arm dove_defconfig
um allnoconfig
arc tb10x_defconfig
arc nsimosci_hs_defconfig
sh edosk7705_defconfig
powerpc sam440ep_defconfig
arm pxa_defconfig
arm hackkit_defconfig
mips loongson1c_defconfig
powerpc tqm8555_defconfig
arc nsimosci_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
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
i386 randconfig-a003-20210414
i386 randconfig-a006-20210414
i386 randconfig-a001-20210414
i386 randconfig-a005-20210414
i386 randconfig-a004-20210414
i386 randconfig-a002-20210414
i386 randconfig-a003-20210412
i386 randconfig-a001-20210412
i386 randconfig-a006-20210412
i386 randconfig-a005-20210412
i386 randconfig-a004-20210412
i386 randconfig-a002-20210412
x86_64 randconfig-a014-20210414
x86_64 randconfig-a015-20210414
x86_64 randconfig-a011-20210414
x86_64 randconfig-a013-20210414
x86_64 randconfig-a012-20210414
x86_64 randconfig-a016-20210414
x86_64 randconfig-a014-20210412
x86_64 randconfig-a015-20210412
x86_64 randconfig-a011-20210412
x86_64 randconfig-a013-20210412
x86_64 randconfig-a012-20210412
x86_64 randconfig-a016-20210412
i386 randconfig-a015-20210414
i386 randconfig-a014-20210414
i386 randconfig-a013-20210414
i386 randconfig-a012-20210414
i386 randconfig-a016-20210414
i386 randconfig-a011-20210414
i386 randconfig-a015-20210412
i386 randconfig-a014-20210412
i386 randconfig-a013-20210412
i386 randconfig-a012-20210412
i386 randconfig-a016-20210412
i386 randconfig-a011-20210412
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210414
x86_64 randconfig-a002-20210414
x86_64 randconfig-a005-20210414
x86_64 randconfig-a001-20210414
x86_64 randconfig-a006-20210414
x86_64 randconfig-a004-20210414
x86_64 randconfig-a003-20210412
x86_64 randconfig-a002-20210412
x86_64 randconfig-a001-20210412
x86_64 randconfig-a005-20210412
x86_64 randconfig-a006-20210412
x86_64 randconfig-a004-20210412
---
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 7098f8f0cf0387443fd8702f24a8a2521d5133f3
From: kernel test robot @ 2021-04-15 2:45 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: 7098f8f0cf0387443fd8702f24a8a2521d5133f3 powerpc/mm/radix: Make radix__change_memory_range() static
elapsed time: 728m
configs tested: 153
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm allyesconfig
arm allmodconfig
arm64 allyesconfig
arm64 defconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc mpc8272_ads_defconfig
arc nsimosci_hs_smp_defconfig
powerpc cm5200_defconfig
mips maltaup_defconfig
xtensa smp_lx200_defconfig
mips rs90_defconfig
ia64 zx1_defconfig
powerpc tqm8540_defconfig
powerpc tqm8560_defconfig
sh urquell_defconfig
arm mmp2_defconfig
arm cns3420vb_defconfig
powerpc g5_defconfig
arm palmz72_defconfig
mips tb0287_defconfig
arm pxa3xx_defconfig
sh se7722_defconfig
powerpc ep8248e_defconfig
x86_64 defconfig
s390 debug_defconfig
powerpc tqm8555_defconfig
powerpc makalu_defconfig
arm bcm2835_defconfig
sh migor_defconfig
mips maltasmvp_defconfig
xtensa cadence_csp_defconfig
sh ap325rxa_defconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
arm s3c2410_defconfig
sh rsk7264_defconfig
powerpc mpc834x_itxgp_defconfig
arm spear6xx_defconfig
mips bmips_stb_defconfig
mips malta_defconfig
arm zeus_defconfig
mips cu1830-neo_defconfig
arm gemini_defconfig
microblaze defconfig
riscv rv32_defconfig
m68k allmodconfig
riscv alldefconfig
arm exynos_defconfig
xtensa iss_defconfig
powerpc ksi8560_defconfig
powerpc ppa8548_defconfig
arm qcom_defconfig
powerpc pq2fads_defconfig
mips loongson1c_defconfig
powerpc bamboo_defconfig
mips cobalt_defconfig
xtensa virt_defconfig
powerpc64 defconfig
sh edosk7760_defconfig
mips decstation_64_defconfig
h8300 alldefconfig
powerpc arches_defconfig
powerpc mpc837x_rdb_defconfig
arm axm55xx_defconfig
m68k m5475evb_defconfig
mips decstation_defconfig
powerpc tqm8548_defconfig
arm at91_dt_defconfig
sparc alldefconfig
arm realview_defconfig
arc nsim_700_defconfig
m68k m5275evb_defconfig
arc tb10x_defconfig
powerpc motionpro_defconfig
m68k hp300_defconfig
sh landisk_defconfig
mips loongson1b_defconfig
powerpc acadia_defconfig
powerpc mpc834x_itx_defconfig
m68k q40_defconfig
m68k m5249evb_defconfig
um allnoconfig
arc nsimosci_hs_defconfig
sh edosk7705_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
s390 defconfig
parisc defconfig
s390 allmodconfig
parisc allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210414
i386 randconfig-a006-20210414
i386 randconfig-a004-20210414
i386 randconfig-a001-20210414
i386 randconfig-a005-20210414
i386 randconfig-a002-20210414
x86_64 randconfig-a014-20210414
x86_64 randconfig-a015-20210414
x86_64 randconfig-a011-20210414
x86_64 randconfig-a013-20210414
x86_64 randconfig-a012-20210414
x86_64 randconfig-a016-20210414
i386 randconfig-a015-20210414
i386 randconfig-a014-20210414
i386 randconfig-a013-20210414
i386 randconfig-a012-20210414
i386 randconfig-a016-20210414
i386 randconfig-a011-20210414
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
um allmodconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210414
x86_64 randconfig-a002-20210414
x86_64 randconfig-a005-20210414
x86_64 randconfig-a001-20210414
x86_64 randconfig-a006-20210414
x86_64 randconfig-a004-20210414
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
From: Anshuman Khandual @ 2021-04-15 4:40 UTC (permalink / raw)
To: Christophe Leroy, linux-mm, akpm
Cc: linux-s390, linux-ia64, linux-parisc, linux-xtensa, linux-sh,
linux-hexagon, x86, linux-um, linux-mips, linux-csky,
linux-kernel, linux-m68k, openrisc, linux-alpha, sparclinux,
linux-riscv, linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <ec7bbb30-dbbd-197b-4d65-eb3600fe6413@csgroup.eu>
On 4/14/21 11:40 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :
>>
>>
>> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>>>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>>>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>>>> for those platforms which would override generic default FIRST_USER_ADDRESS
>>>> value 0UL. This makes it much cleaner with reduced code.
>>>>
>>>> Cc: linux-alpha@vger.kernel.org
>>>> Cc: linux-snps-arc@lists.infradead.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-csky@vger.kernel.org
>>>> Cc: linux-hexagon@vger.kernel.org
>>>> Cc: linux-ia64@vger.kernel.org
>>>> Cc: linux-m68k@lists.linux-m68k.org
>>>> Cc: linux-mips@vger.kernel.org
>>>> Cc: openrisc@lists.librecores.org
>>>> Cc: linux-parisc@vger.kernel.org
>>>> Cc: linuxppc-dev@lists.ozlabs.org
>>>> Cc: linux-riscv@lists.infradead.org
>>>> Cc: linux-s390@vger.kernel.org
>>>> Cc: linux-sh@vger.kernel.org
>>>> Cc: sparclinux@vger.kernel.org
>>>> Cc: linux-um@lists.infradead.org
>>>> Cc: linux-xtensa@linux-xtensa.org
>>>> Cc: x86@kernel.org
>>>> Cc: linux-mm@kvack.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> ---
>>>> arch/alpha/include/asm/pgtable.h | 1 -
>>>> arch/arc/include/asm/pgtable.h | 6 ------
>>>> arch/arm/Kconfig | 1 +
>>>> arch/arm64/include/asm/pgtable.h | 2 --
>>>> arch/csky/include/asm/pgtable.h | 1 -
>>>> arch/hexagon/include/asm/pgtable.h | 3 ---
>>>> arch/ia64/include/asm/pgtable.h | 1 -
>>>> arch/m68k/include/asm/pgtable_mm.h | 1 -
>>>> arch/microblaze/include/asm/pgtable.h | 2 --
>>>> arch/mips/include/asm/pgtable-32.h | 1 -
>>>> arch/mips/include/asm/pgtable-64.h | 1 -
>>>> arch/nds32/Kconfig | 1 +
>>>> arch/nios2/include/asm/pgtable.h | 2 --
>>>> arch/openrisc/include/asm/pgtable.h | 1 -
>>>> arch/parisc/include/asm/pgtable.h | 2 --
>>>> arch/powerpc/include/asm/book3s/pgtable.h | 1 -
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>>>> arch/riscv/include/asm/pgtable.h | 2 --
>>>> arch/s390/include/asm/pgtable.h | 2 --
>>>> arch/sh/include/asm/pgtable.h | 2 --
>>>> arch/sparc/include/asm/pgtable_32.h | 1 -
>>>> arch/sparc/include/asm/pgtable_64.h | 3 ---
>>>> arch/um/include/asm/pgtable-2level.h | 1 -
>>>> arch/um/include/asm/pgtable-3level.h | 1 -
>>>> arch/x86/include/asm/pgtable_types.h | 2 --
>>>> arch/xtensa/include/asm/pgtable.h | 1 -
>>>> include/linux/mm.h | 4 ++++
>>>> mm/Kconfig | 4 ++++
>>>> 29 files changed, 10 insertions(+), 43 deletions(-)
>>>>
>>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>>> index 8ba434287387..47098ccd715e 100644
>>>> --- a/include/linux/mm.h
>>>> +++ b/include/linux/mm.h
>>>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>>>> void init_mm_internals(void);
>>>> +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
>>>
>>> I guess you didn't test it ..... :)
>>
>> In fact I did :) Though just booted it on arm64 and cross compiled on
>> multiple others platforms.
I guess for all platforms, ARCH_HAS_FIRST_USER_ADDRESS would have just
evaluated to be false hence falling back on the generic definition. So
this never complained during build any where or during boot on arm64.
>>
>>>
>>> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
>>
>> Right, meant that instead.
>>
>>>
>>>> +#define FIRST_USER_ADDRESS 0UL
>>>> +#endif
>>>
>>> But why do we need a config option at all for that ?
>>>
>>> Why not just:
>>>
>>> #ifndef FIRST_USER_ADDRESS
>>> #define FIRST_USER_ADDRESS 0UL
>>> #endif
>>
>> This sounds simpler. But just wondering, would not there be any possibility
>> of build problems due to compilation sequence between arch and generic code ?
>>
>
> For sure it has to be addresses carefully, but there are already a lot of stuff like that around pgtables.h
>
> For instance, pte_offset_kernel() has a generic definition in linux/pgtables.h based on whether it is already defined or not.
>
> Taking into account that FIRST_USER_ADDRESS is today in the architectures's asm/pgtables.h, I think putting the fallback definition in linux/pgtable.h would do the trick.
Agreed, <linux/pgtable.h> includes <asm/pgtable.h> at the beginning and
if the arch defines FIRST_USER_ADDRESS, the generic one afterwards would
be skipped. The following change builds on multiple platforms.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ad086e6d7155..5da96f5df48f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
select ARCH_HAS_ELF_RANDOMIZE
- select ARCH_HAS_FIRST_USER_ADDRESS
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 23ec4fcc0d0f..62313902d75d 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -8,7 +8,6 @@ config NDS32
def_bool y
select ARCH_32BIT_OFF_T
select ARCH_HAS_DMA_PREP_COHERENT
- select ARCH_HAS_FIRST_USER_ADDRESS
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_WANT_FRAME_POINTERS if FTRACE
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 47098ccd715e..8ba434287387 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -46,10 +46,6 @@ extern int sysctl_page_lock_unfairness;
void init_mm_internals(void);
-#ifndef ARCH_HAS_FIRST_USER_ADDRESS
-#define FIRST_USER_ADDRESS 0UL
-#endif
-
#ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly */
extern unsigned long max_mapnr;
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 5e772392a379..f3da6a5cc35a 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -28,6 +28,10 @@
#define USER_PGTABLES_CEILING 0UL
#endif
+#ifndef FIRST_USER_ADDRESS
+#define FIRST_USER_ADDRESS 0UL
+#endif
+
/*
* A page table page can be thought of an array like this: pXd_t[PTRS_PER_PxD]
*
diff --git a/mm/Kconfig b/mm/Kconfig
index 373fbe377075..4494501aa403 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -807,9 +807,6 @@ config VMAP_PFN
config ARCH_USES_HIGH_VMA_FLAGS
bool
-config ARCH_HAS_FIRST_USER_ADDRESS
- bool
-
config ARCH_HAS_PKEYS
bool
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] tools: do not include scripts/Kbuild.include
From: Masahiro Yamada @ 2021-04-15 7:27 UTC (permalink / raw)
To: linux-kbuild
Cc: Song Liu, kvm, Alexei Starovoitov, Paul Mackerras,
linux-kselftest, Shuah Khan, Janosch Frank, Daniel Borkmann,
clang-built-linux, Masahiro Yamada, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Harish, Yonghong Song,
KP Singh, Nathan Chancellor, netdev, Nick Desaulniers,
linux-kernel, Paolo Bonzini, bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20210415072700.147125-1-masahiroy@kernel.org>
Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler"), some kselftests fail to build.
The tools/ directory opted out Kbuild, and went in a different
direction. They copy any kind of files to the tools/ directory
in order to do whatever they want to do in their world.
tools/build/Build.include mimics scripts/Kbuild.include, but some
tool Makefiles included the Kbuild one to import a feature that is
missing in tools/build/Build.include:
- Commit ec04aa3ae87b ("tools/thermal: tmon: use "-fstack-protector"
only if supported") included scripts/Kbuild.include from
tools/thermal/tmon/Makefile to import the cc-option macro.
- Commit c2390f16fc5b ("selftests: kvm: fix for compilers that do
not support -no-pie") included scripts/Kbuild.include from
tools/testing/selftests/kvm/Makefile to import the try-run macro.
- Commit 9cae4ace80ef ("selftests/bpf: do not ignore clang
failures") included scripts/Kbuild.include from
tools/testing/selftests/bpf/Makefile to import the .DELETE_ON_ERROR
target.
- Commit 0695f8bca93e ("selftests/powerpc: Handle Makefile for
unrecognized option") included scripts/Kbuild.include from
tools/testing/selftests/powerpc/pmu/ebb/Makefile to import the
try-run macro.
Copy what they want there, and stop including scripts/Kbuild.include
from the tool Makefiles.
Link: https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f45a1@linux.ibm.com/
Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to scripts/Makefile.compiler")
Reported-by: Janosch Frank <frankja@linux.ibm.com>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
tools/testing/selftests/bpf/Makefile | 3 ++-
tools/testing/selftests/kvm/Makefile | 12 +++++++++++-
.../selftests/powerpc/pmu/ebb/Makefile | 11 ++++++++++-
tools/thermal/tmon/Makefile | 19 +++++++++++++++++--
4 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 044bfdcf5b74..d872b9f41543 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-include ../../../../scripts/Kbuild.include
include ../../../scripts/Makefile.arch
include ../../../scripts/Makefile.include
@@ -476,3 +475,5 @@ EXTRA_CLEAN := $(TEST_CUSTOM_PROGS) $(SCRATCH_DIR) $(HOST_SCRATCH_DIR) \
prog_tests/tests.h map_tests/tests.h verifier/tests.h \
feature \
$(addprefix $(OUTPUT)/,*.o *.skel.h no_alu32 bpf_gcc bpf_testmod.ko)
+
+.DELETE_ON_ERROR:
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index a6d61f451f88..8b45bc417d83 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -1,5 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
-include ../../../../scripts/Kbuild.include
+
+TMPOUT = .tmp_$$$$
+
+try-run = $(shell set -e; \
+ TMP=$(TMPOUT)/tmp; \
+ mkdir -p $(TMPOUT); \
+ trap "rm -rf $(TMPOUT)" EXIT; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi)
all:
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/Makefile b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
index af3df79d8163..d5d3e869df93 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/Makefile
+++ b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-include ../../../../../../scripts/Kbuild.include
noarg:
$(MAKE) -C ../../
@@ -8,6 +7,16 @@ noarg:
CFLAGS += -m64
TMPOUT = $(OUTPUT)/TMPDIR/
+
+try-run = $(shell set -e; \
+ TMP=$(TMPOUT)/tmp; \
+ mkdir -p $(TMPOUT); \
+ trap "rm -rf $(TMPOUT)" EXIT; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi)
+
# Toolchains may build PIE by default which breaks the assembly
no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
$(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie)
diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 59e417ec3e13..92a683e4866c 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -1,6 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
-# We need this for the "cc-option" macro.
-include ../../../scripts/Kbuild.include
+
+TMPOUT = .tmp_$$$$
+
+try-run = $(shell set -e; \
+ TMP=$(TMPOUT)/tmp; \
+ mkdir -p $(TMPOUT); \
+ trap "rm -rf $(TMPOUT)" EXIT; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi)
+
+__cc-option = $(call try-run,\
+ $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4))
+
+cc-option = $(call __cc-option, $(CC),\
+ $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS),$(1),$(2))
VERSION = 1.0
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 2/2] tools: do not include scripts/Kbuild.include
From: Paolo Bonzini @ 2021-04-15 7:40 UTC (permalink / raw)
To: Masahiro Yamada, linux-kbuild
Cc: Song Liu, kvm, Alexei Starovoitov, Paul Mackerras,
linux-kselftest, Shuah Khan, Janosch Frank, Daniel Borkmann,
Christian Borntraeger, John Fastabend, Andrii Nakryiko,
clang-built-linux, Harish, Yonghong Song, KP Singh,
Nathan Chancellor, netdev, Nick Desaulniers, linux-kernel, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20210415072700.147125-2-masahiroy@kernel.org>
On 15/04/21 09:27, Masahiro Yamada wrote:
> Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
> scripts/Makefile.compiler"), some kselftests fail to build.
>
> The tools/ directory opted out Kbuild, and went in a different
> direction. They copy any kind of files to the tools/ directory
> in order to do whatever they want to do in their world.
>
> tools/build/Build.include mimics scripts/Kbuild.include, but some
> tool Makefiles included the Kbuild one to import a feature that is
> missing in tools/build/Build.include:
>
> - Commit ec04aa3ae87b ("tools/thermal: tmon: use "-fstack-protector"
> only if supported") included scripts/Kbuild.include from
> tools/thermal/tmon/Makefile to import the cc-option macro.
>
> - Commit c2390f16fc5b ("selftests: kvm: fix for compilers that do
> not support -no-pie") included scripts/Kbuild.include from
> tools/testing/selftests/kvm/Makefile to import the try-run macro.
>
> - Commit 9cae4ace80ef ("selftests/bpf: do not ignore clang
> failures") included scripts/Kbuild.include from
> tools/testing/selftests/bpf/Makefile to import the .DELETE_ON_ERROR
> target.
>
> - Commit 0695f8bca93e ("selftests/powerpc: Handle Makefile for
> unrecognized option") included scripts/Kbuild.include from
> tools/testing/selftests/powerpc/pmu/ebb/Makefile to import the
> try-run macro.
>
> Copy what they want there, and stop including scripts/Kbuild.include
> from the tool Makefiles.
I think it would make sense to add try-run, cc-option and
.DELETE_ON_ERROR to tools/build/Build.include?
Paolo
> Link: https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f45a1@linux.ibm.com/
> Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to scripts/Makefile.compiler")
> Reported-by: Janosch Frank <frankja@linux.ibm.com>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> tools/testing/selftests/bpf/Makefile | 3 ++-
> tools/testing/selftests/kvm/Makefile | 12 +++++++++++-
> .../selftests/powerpc/pmu/ebb/Makefile | 11 ++++++++++-
> tools/thermal/tmon/Makefile | 19 +++++++++++++++++--
> 4 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 044bfdcf5b74..d872b9f41543 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -1,5 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> -include ../../../../scripts/Kbuild.include
> include ../../../scripts/Makefile.arch
> include ../../../scripts/Makefile.include
>
> @@ -476,3 +475,5 @@ EXTRA_CLEAN := $(TEST_CUSTOM_PROGS) $(SCRATCH_DIR) $(HOST_SCRATCH_DIR) \
> prog_tests/tests.h map_tests/tests.h verifier/tests.h \
> feature \
> $(addprefix $(OUTPUT)/,*.o *.skel.h no_alu32 bpf_gcc bpf_testmod.ko)
> +
> +.DELETE_ON_ERROR:
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index a6d61f451f88..8b45bc417d83 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -1,5 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -include ../../../../scripts/Kbuild.include
> +
> +TMPOUT = .tmp_$$$$
> +
> +try-run = $(shell set -e; \
> + TMP=$(TMPOUT)/tmp; \
> + mkdir -p $(TMPOUT); \
> + trap "rm -rf $(TMPOUT)" EXIT; \
> + if ($(1)) >/dev/null 2>&1; \
> + then echo "$(2)"; \
> + else echo "$(3)"; \
> + fi)
>
> all:
>
> diff --git a/tools/testing/selftests/powerpc/pmu/ebb/Makefile b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
> index af3df79d8163..d5d3e869df93 100644
> --- a/tools/testing/selftests/powerpc/pmu/ebb/Makefile
> +++ b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
> @@ -1,5 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> -include ../../../../../../scripts/Kbuild.include
>
> noarg:
> $(MAKE) -C ../../
> @@ -8,6 +7,16 @@ noarg:
> CFLAGS += -m64
>
> TMPOUT = $(OUTPUT)/TMPDIR/
> +
> +try-run = $(shell set -e; \
> + TMP=$(TMPOUT)/tmp; \
> + mkdir -p $(TMPOUT); \
> + trap "rm -rf $(TMPOUT)" EXIT; \
> + if ($(1)) >/dev/null 2>&1; \
> + then echo "$(2)"; \
> + else echo "$(3)"; \
> + fi)
> +
> # Toolchains may build PIE by default which breaks the assembly
> no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
> $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie)
> diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
> index 59e417ec3e13..92a683e4866c 100644
> --- a/tools/thermal/tmon/Makefile
> +++ b/tools/thermal/tmon/Makefile
> @@ -1,6 +1,21 @@
> # SPDX-License-Identifier: GPL-2.0
> -# We need this for the "cc-option" macro.
> -include ../../../scripts/Kbuild.include
> +
> +TMPOUT = .tmp_$$$$
> +
> +try-run = $(shell set -e; \
> + TMP=$(TMPOUT)/tmp; \
> + mkdir -p $(TMPOUT); \
> + trap "rm -rf $(TMPOUT)" EXIT; \
> + if ($(1)) >/dev/null 2>&1; \
> + then echo "$(2)"; \
> + else echo "$(3)"; \
> + fi)
> +
> +__cc-option = $(call try-run,\
> + $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4))
> +
> +cc-option = $(call __cc-option, $(CC),\
> + $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS),$(1),$(2))
>
> VERSION = 1.0
>
>
^ permalink raw reply
* Re: [PATCH 2/2] tools: do not include scripts/Kbuild.include
From: Masahiro Yamada @ 2021-04-15 8:04 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Song Liu, kvm, Alexei Starovoitov, Paul Mackerras,
open list:KERNEL SELFTEST FRAMEWORK, Shuah Khan, Janosch Frank,
Daniel Borkmann, clang-built-linux, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Harish, Yonghong Song,
Linux Kbuild mailing list, KP Singh, Nathan Chancellor,
Networking, Nick Desaulniers, Linux Kernel Mailing List, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <9d33ee98-9de3-2215-0c0b-cc856cec1b69@redhat.com>
On Thu, Apr 15, 2021 at 4:40 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 15/04/21 09:27, Masahiro Yamada wrote:
> > Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
> > scripts/Makefile.compiler"), some kselftests fail to build.
> >
> > The tools/ directory opted out Kbuild, and went in a different
> > direction. They copy any kind of files to the tools/ directory
> > in order to do whatever they want to do in their world.
> >
> > tools/build/Build.include mimics scripts/Kbuild.include, but some
> > tool Makefiles included the Kbuild one to import a feature that is
> > missing in tools/build/Build.include:
> >
> > - Commit ec04aa3ae87b ("tools/thermal: tmon: use "-fstack-protector"
> > only if supported") included scripts/Kbuild.include from
> > tools/thermal/tmon/Makefile to import the cc-option macro.
> >
> > - Commit c2390f16fc5b ("selftests: kvm: fix for compilers that do
> > not support -no-pie") included scripts/Kbuild.include from
> > tools/testing/selftests/kvm/Makefile to import the try-run macro.
> >
> > - Commit 9cae4ace80ef ("selftests/bpf: do not ignore clang
> > failures") included scripts/Kbuild.include from
> > tools/testing/selftests/bpf/Makefile to import the .DELETE_ON_ERROR
> > target.
> >
> > - Commit 0695f8bca93e ("selftests/powerpc: Handle Makefile for
> > unrecognized option") included scripts/Kbuild.include from
> > tools/testing/selftests/powerpc/pmu/ebb/Makefile to import the
> > try-run macro.
> >
> > Copy what they want there, and stop including scripts/Kbuild.include
> > from the tool Makefiles.
>
> I think it would make sense to add try-run, cc-option and
> .DELETE_ON_ERROR to tools/build/Build.include?
To be safe, I just copy-pasted what the makefiles need.
If someone wants to refactor the tool build system, that is fine,
but, to me, I do not see consistent rules or policy under tools/.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH 2/2] tools: do not include scripts/Kbuild.include
From: Christian Borntraeger @ 2021-04-15 8:06 UTC (permalink / raw)
To: Masahiro Yamada, linux-kbuild
Cc: Song Liu, kvm, Alexei Starovoitov, Paul Mackerras,
linux-kselftest, Shuah Khan, Janosch Frank, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, clang-built-linux, Harish,
Yonghong Song, KP Singh, Nathan Chancellor, netdev,
Nick Desaulniers, linux-kernel, Paolo Bonzini, bpf, linuxppc-dev,
Martin KaFai Lau
In-Reply-To: <20210415072700.147125-2-masahiroy@kernel.org>
On 15.04.21 09:27, Masahiro Yamada wrote:
> Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
> scripts/Makefile.compiler"), some kselftests fail to build.
>
> The tools/ directory opted out Kbuild, and went in a different
> direction. They copy any kind of files to the tools/ directory
> in order to do whatever they want to do in their world.
>
> tools/build/Build.include mimics scripts/Kbuild.include, but some
> tool Makefiles included the Kbuild one to import a feature that is
> missing in tools/build/Build.include:
>
> - Commit ec04aa3ae87b ("tools/thermal: tmon: use "-fstack-protector"
> only if supported") included scripts/Kbuild.include from
> tools/thermal/tmon/Makefile to import the cc-option macro.
>
> - Commit c2390f16fc5b ("selftests: kvm: fix for compilers that do
> not support -no-pie") included scripts/Kbuild.include from
> tools/testing/selftests/kvm/Makefile to import the try-run macro.
>
> - Commit 9cae4ace80ef ("selftests/bpf: do not ignore clang
> failures") included scripts/Kbuild.include from
> tools/testing/selftests/bpf/Makefile to import the .DELETE_ON_ERROR
> target.
>
> - Commit 0695f8bca93e ("selftests/powerpc: Handle Makefile for
> unrecognized option") included scripts/Kbuild.include from
> tools/testing/selftests/powerpc/pmu/ebb/Makefile to import the
> try-run macro.
>
> Copy what they want there, and stop including scripts/Kbuild.include
> from the tool Makefiles.
>
> Link: https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f45a1@linux.ibm.com/
> Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to scripts/Makefile.compiler")
> Reported-by: Janosch Frank <frankja@linux.ibm.com>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When applying this on top of d9f4ff50d2aa ("kbuild: spilt cc-option and friends to scripts/Makefile.compiler")
I still do get
# ==== Test Assertion Failure ====
# lib/kvm_util.c:142: vm->fd >= 0
# pid=315635 tid=315635 - Invalid argument
# 1 0x0000000001002f4b: vm_open at kvm_util.c:142
# 2 (inlined by) vm_create at kvm_util.c:258
# 3 0x00000000010015ef: test_add_max_memory_regions at set_memory_region_test.c:351
# 4 (inlined by) main at set_memory_region_test.c:397
# 5 0x000003ff971abb89: ?? ??:0
# 6 0x00000000010017ad: .annobin_abi_note.c.hot at crt1.o:?
# KVM_CREATE_VM ioctl failed, rc: -1 errno: 22
not ok 7 selftests: kvm: set_memory_region_test # exit=254
and the testcase compilation does not pickup the pgste option.
^ permalink raw reply
* Re: [PATCH 2/2] tools: do not include scripts/Kbuild.include
From: Paolo Bonzini @ 2021-04-15 8:25 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Song Liu, kvm, Alexei Starovoitov, Paul Mackerras,
open list:KERNEL SELFTEST FRAMEWORK, Shuah Khan, Janosch Frank,
Daniel Borkmann, clang-built-linux, John Fastabend,
Andrii Nakryiko, Christian Borntraeger, Harish, Yonghong Song,
Linux Kbuild mailing list, KP Singh, Nathan Chancellor,
Networking, Nick Desaulniers, Linux Kernel Mailing List, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <CAK7LNAQupbmeEVR0njSciv0X9FD+MofeB2Xm=wprEdNaO4TQKQ@mail.gmail.com>
On 15/04/21 10:04, Masahiro Yamada wrote:
> On Thu, Apr 15, 2021 at 4:40 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>> I think it would make sense to add try-run, cc-option and
>> .DELETE_ON_ERROR to tools/build/Build.include?
>
> To be safe, I just copy-pasted what the makefiles need.
> If someone wants to refactor the tool build system, that is fine,
> but, to me, I do not see consistent rules or policy under tools/.
"Please put this in a common file instead of introducing duplication" is
not asking for wholesale refactoring.
Paolo
^ permalink raw reply
* [PATCH] soc: fsl: qe: remove unused function
From: Jiapeng Chong @ 2021-04-15 8:34 UTC (permalink / raw)
To: qiang.zhao
Cc: Jiapeng Chong, linuxppc-dev, linux-kernel, linux-arm-kernel,
leoyang.li
Fix the following clang warning:
drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
'qe_ic_from_irq' [-Wunused-function].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
---
drivers/soc/fsl/qe/qe_ic.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 0390af9..b573712 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32 __iomem *base, unsigned int reg,
qe_iowrite32be(value, base + (reg >> 2));
}
-static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
-{
- return irq_get_chip_data(virq);
-}
-
static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
{
return irq_data_get_irq_chip_data(d);
--
1.8.3.1
^ permalink raw reply related
* linux-next: build warning after merge of the powerpc tree
From: Stephen Rothwell @ 2021-04-15 8:52 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Shivaprasad G Bhat
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
In file included from include/linux/device.h:15,
from arch/powerpc/include/asm/io.h:27,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from arch/powerpc/include/asm/hardirq.h:6,
from include/linux/hardirq.h:11,
from include/linux/highmem.h:10,
from include/linux/bio.h:8,
from include/linux/libnvdimm.h:14,
from arch/powerpc/platforms/pseries/papr_scm.c:12:
arch/powerpc/platforms/pseries/papr_scm.c: In function 'papr_scm_pmem_flush':
arch/powerpc/platforms/pseries/papr_scm.c:144:26: warning: format '%lld' expects argument of type 'long long int', but argument 3 has type 'long int' [-Wformat=]
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
| ^~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
19 | #define dev_fmt(fmt) fmt
| ^~~
arch/powerpc/platforms/pseries/papr_scm.c:144:3: note: in expansion of macro 'dev_err'
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
| ^~~~~~~
arch/powerpc/platforms/pseries/papr_scm.c:144:43: note: format string is defined here
144 | dev_err(&p->pdev->dev, "flush error: %lld", rc);
| ~~~^
| |
| long long int
| %ld
Introduced by commit
75b7c05ebf90 ("powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] mm: ptdump: Fix build failure
From: Christophe Leroy @ 2021-04-15 9:31 UTC (permalink / raw)
To: Andrew Morton, Steven Price; +Cc: linux-mm, linuxppc-dev, linux-kernel
CC mm/ptdump.o
In file included from <command-line>:
mm/ptdump.c: In function 'ptdump_pte_entry':
././include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_207' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
././include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert'
301 | prefix ## suffix(); \
| ^~~~~~
././include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert'
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/asm-generic/rwonce.h:36:2: note: in expansion of macro 'compiletime_assert'
36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
| ^~~~~~~~~~~~~~~~~~
./include/asm-generic/rwonce.h:49:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
49 | compiletime_assert_rwonce_type(x); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/ptdump.c:114:14: note: in expansion of macro 'READ_ONCE'
114 | pte_t val = READ_ONCE(*pte);
| ^~~~~~~~~
make[2]: *** [mm/ptdump.o] Error 1
READ_ONCE() cannot be used for reading PTEs. Use ptep_get()
instead. See commit 481e980a7c19 ("mm: Allow arches to provide ptep_get()")
and commit c0e1c8c22beb ("powerpc/8xx: Provide ptep_get() with 16k pages")
for details.
Fixes: 30d621f6723b ("mm: add generic ptdump")
Cc: Steven Price <steven.price@arm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
mm/ptdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/ptdump.c b/mm/ptdump.c
index 4354c1422d57..da751448d0e4 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -111,7 +111,7 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
unsigned long next, struct mm_walk *walk)
{
struct ptdump_state *st = walk->private;
- pte_t val = READ_ONCE(*pte);
+ pte_t val = ptep_get(pte);
if (st->effective_prot)
st->effective_prot(st, 4, pte_val(val));
--
2.25.0
^ permalink raw reply related
* linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Stephen Rothwell @ 2021-04-15 9:44 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Stephen Rothwell, Linux Next Mailing List, Nicholas Piggin,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/module.c
between commit:
2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
from the powerpc tree and commit:
4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
from the akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/kernel/module.c
index fab84024650c,cdb2d88c54e7..000000000000
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
return 0;
}
- #ifdef MODULES_VADDR
-void *module_alloc(unsigned long size)
+static __always_inline void *
+__module_alloc(unsigned long size, unsigned long start, unsigned long end)
{
- unsigned long start = VMALLOC_START;
- unsigned long end = VMALLOC_END;
-
-#ifdef MODULES_VADDR
- BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
- start = MODULES_VADDR;
- end = MODULES_END;
-#endif
-
+ /*
+ * Don't do huge page allocations for modules yet until more testing
+ * is done. STRICT_MODULE_RWX may require extra work to support this
+ * too.
+ */
+
return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
- PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
+ PAGE_KERNEL_EXEC,
+ VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE,
__builtin_return_address(0));
}
+
++
+void *module_alloc(unsigned long size)
+{
++ unsigned long start = VMALLOC_START;
++ unsigned long end = VMALLOC_END;
+ unsigned long limit = (unsigned long)_etext - SZ_32M;
+ void *ptr = NULL;
+
++#ifdef MODULES_VADDR
+ BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
++ start = MODULES_VADDR;
++ end = MODULES_END;
+
+ /* First try within 32M limit from _etext to avoid branch trampolines */
+ if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
- ptr = __module_alloc(size, limit, MODULES_END);
++ ptr = __module_alloc(size, limit, end);
+
+ if (!ptr)
- ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
++#endif
++ ptr = __module_alloc(size, start, end);
+
+ return ptr;
+}
- #endif
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Stephen Rothwell @ 2021-04-15 9:58 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Nicholas Piggin,
Linux Kernel Mailing List
In-Reply-To: <20210415194417.498e71b7@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]
Hi all,
On Thu, 15 Apr 2021 19:44:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/powerpc/kernel/module.c
>
> between commit:
>
> 2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
>
> from the powerpc tree and commit:
>
> 4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
>
> from the akpm-current tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/powerpc/kernel/module.c
> index fab84024650c,cdb2d88c54e7..000000000000
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
> return 0;
> }
>
> - #ifdef MODULES_VADDR
> -void *module_alloc(unsigned long size)
> +static __always_inline void *
> +__module_alloc(unsigned long size, unsigned long start, unsigned long end)
> {
> - unsigned long start = VMALLOC_START;
> - unsigned long end = VMALLOC_END;
> -
> -#ifdef MODULES_VADDR
> - BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> - start = MODULES_VADDR;
> - end = MODULES_END;
> -#endif
> -
> + /*
> + * Don't do huge page allocations for modules yet until more testing
> + * is done. STRICT_MODULE_RWX may require extra work to support this
> + * too.
> + */
> +
> return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
> - PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> + PAGE_KERNEL_EXEC,
> + VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
> + NUMA_NO_NODE,
> __builtin_return_address(0));
> }
> +
> ++
> +void *module_alloc(unsigned long size)
> +{
> ++ unsigned long start = VMALLOC_START;
> ++ unsigned long end = VMALLOC_END;
> + unsigned long limit = (unsigned long)_etext - SZ_32M;
> + void *ptr = NULL;
> +
> ++#ifdef MODULES_VADDR
> + BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> ++ start = MODULES_VADDR;
> ++ end = MODULES_END;
> +
> + /* First try within 32M limit from _etext to avoid branch trampolines */
> + if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
> - ptr = __module_alloc(size, limit, MODULES_END);
> ++ ptr = __module_alloc(size, limit, end);
> +
> + if (!ptr)
> - ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
> ++#endif
> ++ ptr = __module_alloc(size, start, end);
> +
> + return ptr;
> +}
> - #endif
Unfortunately, it also needs this:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 15 Apr 2021 19:53:58 +1000
Subject: [PATCH] merge fix up for powerpc merge fix
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/module.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index d8ab1ad2eb05..c060f99afd4d 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -110,7 +110,9 @@ void *module_alloc(unsigned long size)
{
unsigned long start = VMALLOC_START;
unsigned long end = VMALLOC_END;
+#ifdef MODULES_VADDR
unsigned long limit = (unsigned long)_etext - SZ_32M;
+#endif
void *ptr = NULL;
#ifdef MODULES_VADDR
--
2.30.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
From: Jianlin Lv @ 2021-04-15 9:32 UTC (permalink / raw)
To: bpf
Cc: irogers, songliubraving, catalin.marinas, linux-doc, zlim.lnx,
paul.walmsley, ast, andrii, paulus, sandipan, hpa, sparclinux,
illusionist.neo, maheshb, will, nicolas.dichtel, linux-s390, iii,
paulburton, corbet, mchehab+huawei, masahiroy, x86,
john.fastabend, linux, linux-riscv, borntraeger, mingo,
linux-arm-kernel, naveen.n.rao, kuba, tklauser, linux-mips,
grantseltzer, xi.wang, aou, keescook, gor, luke.r.nels,
linux-kernel, hca, kpsingh, iecedge, horms, bp, viro, yhs,
Jianlin.Lv, tglx, dvyukov, tsbogend, daniel, yoshfuji, netdev,
dsahern, udknight, kafai, bjorn, palmer, quentin, linuxppc-dev,
davem
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>
---
arch/arm/net/bpf_jit_32.c | 4 ----
arch/arm64/net/bpf_jit_comp.c | 4 ----
arch/mips/net/bpf_jit.c | 4 ----
arch/mips/net/ebpf_jit.c | 4 ----
arch/powerpc/net/bpf_jit_comp.c | 10 ----------
arch/powerpc/net/bpf_jit_comp64.c | 11 -----------
arch/riscv/net/bpf_jit_core.c | 3 ---
arch/s390/net/bpf_jit_comp.c | 4 ----
arch/sparc/net/bpf_jit_comp_32.c | 3 ---
arch/sparc/net/bpf_jit_comp_64.c | 13 -------------
arch/x86/net/bpf_jit_comp.c | 3 ---
arch/x86/net/bpf_jit_comp32.c | 3 ---
net/core/sysctl_net_core.c | 14 +++-----------
tools/bpf/bpf_jit_disasm.c | 2 +-
tools/bpf/bpftool/feature.c | 3 ---
15 files changed, 4 insertions(+), 81 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 897634d0a67c..92d669c0b2d3 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -1997,10 +1997,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
}
flush_icache_range((u32)header, (u32)(ctx.target + ctx.idx));
- if (bpf_jit_enable > 1)
- /* there are 2 passes here */
- bpf_jit_dump(prog->len, image_size, 2, ctx.target);
-
bpf_jit_binary_lock_ro(header);
prog->bpf_func = (void *)ctx.target;
prog->jited = 1;
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index f7b194878a99..a13b83ac4ca8 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -1090,10 +1090,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
goto out_off;
}
- /* And we're done. */
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, prog_size, 2, ctx.image);
-
bpf_flush_icache(header, ctx.image + ctx.idx);
if (!prog->is_func || extra_pass) {
diff --git a/arch/mips/net/bpf_jit.c b/arch/mips/net/bpf_jit.c
index 0af88622c619..b5221282dd88 100644
--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -1250,10 +1250,6 @@ void bpf_jit_compile(struct bpf_prog *fp)
/* Update the icache */
flush_icache_range((ptr)ctx.target, (ptr)(ctx.target + ctx.idx));
- if (bpf_jit_enable > 1)
- /* Dump JIT code */
- bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
-
fp->bpf_func = (void *)ctx.target;
fp->jited = 1;
diff --git a/arch/mips/net/ebpf_jit.c b/arch/mips/net/ebpf_jit.c
index 939dd06764bc..dac5a1fc2462 100644
--- a/arch/mips/net/ebpf_jit.c
+++ b/arch/mips/net/ebpf_jit.c
@@ -1910,10 +1910,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
flush_icache_range((unsigned long)ctx.target,
(unsigned long)&ctx.target[ctx.idx]);
- if (bpf_jit_enable > 1)
- /* Dump JIT code */
- bpf_jit_dump(prog->len, image_size, 2, ctx.target);
-
bpf_jit_binary_lock_ro(header);
prog->bpf_func = (void *)ctx.target;
prog->jited = 1;
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index e809cb5a1631..ebca629de2d1 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -646,18 +646,8 @@ void bpf_jit_compile(struct bpf_prog *fp)
bpf_jit_build_prologue(fp, code_base, &cgctx);
bpf_jit_build_body(fp, code_base, &cgctx, addrs);
bpf_jit_build_epilogue(code_base, &cgctx);
-
- if (bpf_jit_enable > 1)
- pr_info("Pass %d: shrink = %d, seen = 0x%x\n", pass,
- proglen - (cgctx.idx * 4), cgctx.seen);
}
- if (bpf_jit_enable > 1)
- /* Note that we output the base address of the code_base
- * rather than image, since opcodes are in code_base.
- */
- bpf_jit_dump(flen, proglen, pass, code_base);
-
bpf_flush_icache(code_base, code_base + (proglen/4));
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index aaf1a887f653..26243399ef2e 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -1215,20 +1215,9 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
bpf_jit_build_prologue(code_base, &cgctx);
bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass);
bpf_jit_build_epilogue(code_base, &cgctx);
-
- if (bpf_jit_enable > 1)
- pr_info("Pass %d: shrink = %d, seen = 0x%x\n", pass,
- proglen - (cgctx.idx * 4), cgctx.seen);
}
skip_codegen_passes:
- if (bpf_jit_enable > 1)
- /*
- * Note that we output the base address of the code_base
- * rather than image, since opcodes are in code_base.
- */
- bpf_jit_dump(flen, proglen, pass, code_base);
-
#ifdef PPC64_ELF_ABI_v1
/* Function descriptor nastiness: Address + TOC */
((u64 *)image)[0] = (u64)code_base;
diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
index 3630d447352c..856b84fb3947 100644
--- a/arch/riscv/net/bpf_jit_core.c
+++ b/arch/riscv/net/bpf_jit_core.c
@@ -142,9 +142,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
}
bpf_jit_build_epilogue(ctx);
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, image_size, pass, ctx->insns);
-
prog->bpf_func = (void *)ctx->insns;
prog->jited = 1;
prog->jited_len = image_size;
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index 63cae0476bb4..aa8b94ba694f 100644
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -1842,10 +1842,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
fp = orig_fp;
goto free_addrs;
}
- if (bpf_jit_enable > 1) {
- bpf_jit_dump(fp->len, jit.size, pass, jit.prg_buf);
- print_fn_code(jit.prg_buf, jit.size_prg);
- }
if (!fp->is_func || extra_pass) {
bpf_jit_binary_lock_ro(header);
} else {
diff --git a/arch/sparc/net/bpf_jit_comp_32.c b/arch/sparc/net/bpf_jit_comp_32.c
index b1dbf2fa8c0a..cb4c55422730 100644
--- a/arch/sparc/net/bpf_jit_comp_32.c
+++ b/arch/sparc/net/bpf_jit_comp_32.c
@@ -743,9 +743,6 @@ cond_branch: f_offset = addrs[i + filter[i].jf];
oldproglen = proglen;
}
- if (bpf_jit_enable > 1)
- bpf_jit_dump(flen, proglen, pass + 1, image);
-
if (image) {
fp->bpf_func = (void *)image;
fp->jited = 1;
diff --git a/arch/sparc/net/bpf_jit_comp_64.c b/arch/sparc/net/bpf_jit_comp_64.c
index 4b8d3c65d266..09ebd48c4f1b 100644
--- a/arch/sparc/net/bpf_jit_comp_64.c
+++ b/arch/sparc/net/bpf_jit_comp_64.c
@@ -1546,16 +1546,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
}
build_epilogue(&ctx);
- if (bpf_jit_enable > 1)
- pr_info("Pass %d: size = %u, seen = [%c%c%c%c%c%c]\n", pass,
- ctx.idx * 4,
- ctx.tmp_1_used ? '1' : ' ',
- ctx.tmp_2_used ? '2' : ' ',
- ctx.tmp_3_used ? '3' : ' ',
- ctx.saw_frame_pointer ? 'F' : ' ',
- ctx.saw_call ? 'C' : ' ',
- ctx.saw_tail_call ? 'T' : ' ');
-
if (ctx.idx * 4 == prev_image_size)
break;
prev_image_size = ctx.idx * 4;
@@ -1593,9 +1583,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
goto out_off;
}
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, image_size, pass, ctx.image);
-
bpf_flush_icache(header, (u8 *)header + (header->pages * PAGE_SIZE));
if (!prog->is_func || extra_pass) {
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 9eead60f0301..0a511f42a2a7 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -2311,9 +2311,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
cond_resched();
}
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, proglen, pass + 1, image);
-
if (image) {
if (!prog->is_func || extra_pass) {
bpf_tail_call_direct_fixup(prog);
diff --git a/arch/x86/net/bpf_jit_comp32.c b/arch/x86/net/bpf_jit_comp32.c
index 0a7a2870f111..8d36b4658076 100644
--- a/arch/x86/net/bpf_jit_comp32.c
+++ b/arch/x86/net/bpf_jit_comp32.c
@@ -2566,9 +2566,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
cond_resched();
}
- if (bpf_jit_enable > 1)
- bpf_jit_dump(prog->len, proglen, pass + 1, image);
-
if (image) {
bpf_jit_binary_lock_ro(header);
prog->bpf_func = (void *)image;
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index c8496c1142c9..990b1720c7a4 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -273,16 +273,8 @@ static int proc_dointvec_minmax_bpf_enable(struct ctl_table *table, int write,
tmp.data = &jit_enable;
ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (jit_enable < 2 ||
- (jit_enable == 2 && bpf_dump_raw_ok(current_cred()))) {
- *(int *)table->data = jit_enable;
- if (jit_enable == 2)
- pr_warn("bpf_jit_enable = 2 was set! NEVER use this in production, only for JIT debugging!\n");
- } else {
- ret = -EPERM;
- }
- }
+ if (write && !ret)
+ *(int *)table->data = jit_enable;
return ret;
}
@@ -389,7 +381,7 @@ static struct ctl_table net_core_table[] = {
.extra2 = SYSCTL_ONE,
# else
.extra1 = SYSCTL_ZERO,
- .extra2 = &two,
+ .extra2 = SYSCTL_ONE,
# endif
},
# ifdef CONFIG_HAVE_EBPF_JIT
diff --git a/tools/bpf/bpf_jit_disasm.c b/tools/bpf/bpf_jit_disasm.c
index c8ae95804728..efa4b17ae016 100644
--- a/tools/bpf/bpf_jit_disasm.c
+++ b/tools/bpf/bpf_jit_disasm.c
@@ -7,7 +7,7 @@
*
* To get the disassembly of the JIT code, do the following:
*
- * 1) `echo 2 > /proc/sys/net/core/bpf_jit_enable`
+ * 1) Insert bpf_jit_dump() and recompile the kernel to output JITed image into log
* 2) Load a BPF filter (e.g. `tcpdump -p -n -s 0 -i eth1 host 192.168.20.0/24`)
* 3) Run e.g. `bpf_jit_disasm -o` to read out the last JIT code
*
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index 40a88df275f9..98c7eec2923f 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -203,9 +203,6 @@ static void probe_jit_enable(void)
case 1:
printf("JIT compiler is enabled\n");
break;
- case 2:
- printf("JIT compiler is enabled with debugging traces in kernel logs\n");
- break;
case -1:
printf("Unable to retrieve JIT-compiler status\n");
break;
--
2.25.1
^ permalink raw reply related
* [PATCH bpf-next 2/2] docs: bpf: bpf_jit_enable mode changed
From: Jianlin Lv @ 2021-04-15 9:32 UTC (permalink / raw)
To: bpf
Cc: irogers, songliubraving, catalin.marinas, linux-doc, zlim.lnx,
paul.walmsley, ast, andrii, paulus, sandipan, hpa, sparclinux,
illusionist.neo, maheshb, will, nicolas.dichtel, linux-s390, iii,
paulburton, corbet, mchehab+huawei, masahiroy, x86,
john.fastabend, linux, linux-riscv, borntraeger, mingo,
linux-arm-kernel, naveen.n.rao, kuba, tklauser, linux-mips,
grantseltzer, xi.wang, aou, keescook, gor, luke.r.nels,
linux-kernel, hca, kpsingh, iecedge, horms, bp, viro, yhs,
Jianlin.Lv, tglx, dvyukov, tsbogend, daniel, yoshfuji, netdev,
dsahern, udknight, kafai, bjorn, palmer, quentin, linuxppc-dev,
davem
In-Reply-To: <20210415093250.3391257-1-Jianlin.Lv@arm.com>
Remove information about bpf_jit_enable=2 mode and added description for
how to use the bpf_jit_disasm tool after get rid of =2 mode.
Signed-off-by: Jianlin Lv <Jianlin.Lv@arm.com>
---
Documentation/admin-guide/sysctl/net.rst | 1 -
Documentation/networking/filter.rst | 25 ++++++------------------
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index c941b214e0b7..a39f99deac38 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -86,7 +86,6 @@ Values:
- 0 - disable the JIT (default value)
- 1 - enable the JIT
- - 2 - enable the JIT and ask the compiler to emit traces on kernel log.
bpf_jit_harden
--------------
diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst
index 251c6bd73d15..86954f922168 100644
--- a/Documentation/networking/filter.rst
+++ b/Documentation/networking/filter.rst
@@ -504,25 +504,12 @@ been previously enabled by root::
echo 1 > /proc/sys/net/core/bpf_jit_enable
-For JIT developers, doing audits etc, each compile run can output the generated
-opcode image into the kernel log via::
-
- echo 2 > /proc/sys/net/core/bpf_jit_enable
-
-Example output from dmesg::
-
- [ 3389.935842] flen=6 proglen=70 pass=3 image=ffffffffa0069c8f
- [ 3389.935847] JIT code: 00000000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68
- [ 3389.935849] JIT code: 00000010: 44 2b 4f 6c 4c 8b 87 d8 00 00 00 be 0c 00 00 00
- [ 3389.935850] JIT code: 00000020: e8 1d 94 ff e0 3d 00 08 00 00 75 16 be 17 00 00
- [ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00
- [ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3
-
-When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set to 1 and
-setting any other value than that will return in failure. This is even the case for
-setting bpf_jit_enable to 2, since dumping the final JIT image into the kernel log
-is discouraged and introspection through bpftool (under tools/bpf/bpftool/) is the
-generally recommended approach instead.
+When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set
+to 1 and setting any other value than that will return in failure.
+For debugging JITs, the introspection through bpftool (tools/bpf/bpftool/)
+is the generally recommended approach instead. For JIT developers, doing
+audits etc, you can insert bpf_jit_dump() and recompile the kernel to
+output the generated opcode image into the kernel log.
In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
generating disassembly out of the kernel log's hexdump::
--
2.25.1
^ permalink raw reply related
* Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Christophe Leroy @ 2021-04-15 10:07 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Nicholas Piggin
In-Reply-To: <20210415195814.0dc4ced9@canb.auug.org.au>
Le 15/04/2021 à 11:58, Stephen Rothwell a écrit :
> Hi all,
>
> On Thu, 15 Apr 2021 19:44:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> arch/powerpc/kernel/module.c
>>
>> between commit:
>>
>> 2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
>>
>> from the powerpc tree and commit:
>>
>> 4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging. You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>>
>> --
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc arch/powerpc/kernel/module.c
>> index fab84024650c,cdb2d88c54e7..000000000000
>> --- a/arch/powerpc/kernel/module.c
>> +++ b/arch/powerpc/kernel/module.c
>> @@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
>> return 0;
>> }
>>
>> - #ifdef MODULES_VADDR
>> -void *module_alloc(unsigned long size)
>> +static __always_inline void *
>> +__module_alloc(unsigned long size, unsigned long start, unsigned long end)
>> {
>> - unsigned long start = VMALLOC_START;
>> - unsigned long end = VMALLOC_END;
>> -
>> -#ifdef MODULES_VADDR
>> - BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
>> - start = MODULES_VADDR;
>> - end = MODULES_END;
>> -#endif
>> -
>> + /*
>> + * Don't do huge page allocations for modules yet until more testing
>> + * is done. STRICT_MODULE_RWX may require extra work to support this
>> + * too.
>> + */
>> +
>> return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
>> - PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
>> + PAGE_KERNEL_EXEC,
>> + VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
>> + NUMA_NO_NODE,
>> __builtin_return_address(0));
>> }
>> +
>> ++
>> +void *module_alloc(unsigned long size)
>> +{
>> ++ unsigned long start = VMALLOC_START;
>> ++ unsigned long end = VMALLOC_END;
>> + unsigned long limit = (unsigned long)_etext - SZ_32M;
>> + void *ptr = NULL;
>> +
>> ++#ifdef MODULES_VADDR
>> + BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
>> ++ start = MODULES_VADDR;
>> ++ end = MODULES_END;
The #endif should be here.
>> +
>> + /* First try within 32M limit from _etext to avoid branch trampolines */
>> + if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
>> - ptr = __module_alloc(size, limit, MODULES_END);
>> ++ ptr = __module_alloc(size, limit, end);
>> +
>> + if (!ptr)
>> - ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
>> ++#endif
>> ++ ptr = __module_alloc(size, start, end);
>> +
>> + return ptr;
>> +}
>> - #endif
>
> Unfortunately, it also needs this:
Before the #endif is too far.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 15 Apr 2021 19:53:58 +1000
> Subject: [PATCH] merge fix up for powerpc merge fix
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/kernel/module.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> index d8ab1ad2eb05..c060f99afd4d 100644
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@ -110,7 +110,9 @@ void *module_alloc(unsigned long size)
> {
> unsigned long start = VMALLOC_START;
> unsigned long end = VMALLOC_END;
> +#ifdef MODULES_VADDR
> unsigned long limit = (unsigned long)_etext - SZ_32M;
> +#endif
> void *ptr = NULL;
>
> #ifdef MODULES_VADDR
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox