On 04/06/2020 08:09 AM, Jordan Niethe wrote:
A future revision of the ISA will introduce prefixed instructions. A
prefixed instruction is composed of a 4-byte prefix followed by a
4-byte suffix.
All prefixes have the major opcode 1. A prefix will never be a valid
word instruction. A suffix ma
>> Would you like to reconsider the shown condition check?
>
> Thanks for the finding. This is truly a software issue that need to
> be fixed.
I was unsure if I noticed another programming mistake.
> Would you submit a patch for it
Do other contributors know the affected software module better
On Thu, Apr 9, 2020 at 4:13 PM Oliver O'Halloran wrote:
>
> If the platform decides to block enabling the device nothing is printed
> currently. This can lead to some confusion since the dmesg output will
> usually print an error with no context e.g.
>
> e1000e: probe of 0022:01:00.0 faile
If the platform decides to block enabling the device nothing is printed
currently. This can lead to some confusion since the dmesg output will
usually print an error with no context e.g.
e1000e: probe of 0022:01:00.0 failed with error -22
This shouldn't be spammy since pci_enable_device()
Le 06/04/2020 à 10:09, Jordan Niethe a écrit :
To execute an instruction out of line after a breakpoint, the NIP is set
to the address of struct bpt::instr. Here a copy of the instruction that
was replaced with a breakpoint is kept, along with a trap so normal flow
can be resumed after XOLing.
Em Thu, 9 Apr 2020 10:37:52 +1000
Andrew Donnellan escreveu:
> On 9/4/20 1:46 am, Mauro Carvalho Chehab wrote:
> > The User API chapter contains two sub-chapters. Mark them as
> > such.
> >
> > Signed-off-by: Mauro Carvalho Chehab
>
> Thanks.
>
> Though the other subsections in this file us
On Thu, Apr 9, 2020 at 3:04 PM Balamuruhan S wrote:
>
> On Wed, 2020-04-08 at 12:18 +1000, Jordan Niethe wrote:
> > On Tue, Apr 7, 2020 at 9:31 PM Balamuruhan S wrote:
> > > On Mon, 2020-04-06 at 18:09 +1000, Jordan Niethe wrote:
> > > > Currently in xmon, mread() is used for reading instructions
On Wed, 2020-04-08 at 12:18 +1000, Jordan Niethe wrote:
> On Tue, Apr 7, 2020 at 9:31 PM Balamuruhan S wrote:
> > On Mon, 2020-04-06 at 18:09 +1000, Jordan Niethe wrote:
> > > Currently in xmon, mread() is used for reading instructions. In
> > > preparation for prefixed instructions, create and us
On Thu, Apr 9, 2020 at 4:21 AM Segher Boessenkool
wrote:
>
> Hi!
>
> On Mon, Apr 06, 2020 at 06:09:20PM +1000, Jordan Niethe wrote:
> > +static inline int ppc_inst_opcode(u32 x)
> > +{
> > + return x >> 26;
> > +}
>
> Maybe you should have "primary opcode" in this function name?
Thanks, that i
On Mon, Apr 06, 2020 at 09:19:20AM +0530, Bharata B Rao wrote:
> Memory unplug has a few bugs which I had attempted to fix ealier
> at https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-July/194087.html
>
> Now with Leonardo's patch for PAPR changes that add a separate flag bit
> to LMB flags fo
> On Apr 7, 2020, at 9:30 AM, Steven Rostedt wrote:
>
> On Tue, 7 Apr 2020 09:01:10 -0400
> Qian Cai wrote:
>
>> + Steven
>>
>>> On Apr 7, 2020, at 8:42 AM, Michael Ellerman wrote:
>>>
>>> Qian Cai writes:
Ever since 1st Apr, linux-next starts to trigger a NULL pointer NIP on
>>>
On 04/08/2020 10:46 AM, Baoquan He wrote:
> Add Pingfan to CC since he usually handles ppc related bugs for RHEL.
>
> On 04/07/20 at 03:54pm, David Hildenbrand wrote:
>> In commit 53cdc1cb29e8 ("drivers/base/memory.c: indicate all memory
>> blocks as removable"), the user space interface to com
A bug is observed on pseries by taking the following steps on rhel:
-1. drmgr -c mem -r -q 5
-2. echo c > /proc/sysrq-trigger
And then, the failure looks like:
kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
This patch prepares for the incoming patch which swaps the order of KOBJ_
uevent and dt's updating.
It has no functional effect, just groups lmb operation and memblock's in
order to insert dt updating operation easily, and makes it easier to
review.
Signed-off-by: Pingfan Liu
Cc: Michael Ellerma
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> This is always GFP_KERNEL - for long term mappings with other properties
> vmap should be used.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 2 +-
> drivers/media/common/vide
On 04/08/2020 05:45 PM, Gerald Schaefer wrote:
> On Wed, 8 Apr 2020 12:41:51 +0530
> Anshuman Khandual wrote:
>
> [...]
>>>
Some thing like this instead.
pte_t pte = READ_ONCE(*ptep);
pte = pte_mkhuge(__pte((pte_val(pte) | RANDOM_ORVALUE) & PMD_MASK));
We c
On 9/4/20 1:46 am, Mauro Carvalho Chehab wrote:
The User API chapter contains two sub-chapters. Mark them as
such.
Signed-off-by: Mauro Carvalho Chehab
Thanks.
Though the other subsections in this file use - rather than ^,
what's the difference?
Acked-by: Andrew Donnellan
---
On Wed, Apr 08, 2020 at 10:21:29PM +1000, Michael Ellerman wrote:
>
> We should be able to just allocate the rtas_args on the stack, it's only
> ~80 odd bytes. And then we can use rtas_call_unlocked() which doesn't
> take the global lock.
Do we instantiate a 64-bit RTAS these days, or is it still
On Wed, 2020-04-08 at 22:21 +1000, Michael Ellerman wrote:
[...]
> > According with LoPAR, for both of these rtas-calls, we have:
> >
> > For the PowerPC External Interrupt option: The call must be reentrant
> > to the number of processors on the platform.
> > For the PowerPC External Interrupt op
On Wed, Apr 8, 2020 at 9:19 AM Markus Elfring wrote:
>
> Hello,
>
> I have taken another look at the implementation of the function
> “fsl_udc_probe”.
> A software analysis approach points the following source code out for
> further development considerations.
> https://elixir.bootlin.com/linux/v
Implement rtas_call_reentrant() for reentrant rtas-calls:
"ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
items 2 and 3 say:
2 - For the PowerPC External Interrupt option: The * call must be
reentrant to the number
Function count_pmc() needs a memory barrier to ensure that PMC reads are
fully consistent. The lack of it can occasionally fail pmc56_overflow test,
since depending on the workload on the system, PMC5 & 6 can have past val-
ues from the time the counters are frozen and turned back on. These past
va
By using count_pmc() to reset PMCs instead of write_pmc(), an extra count
is performed on ebb_state.stats.pmc_count[PMC_INDEX(pmc)]. This extra
pmc_count can occasionally invalidate results, such as the ones from
cycles_test shown hereafter. The ebb_check_count() failed with an above
the upper limi
This patchseries addresses a few fixes on powerpc selftests (first and
second patch are being resent).
The first fix has to do with the extra counts on PMCs resets, which not
only are shown on the trace_logs, but can also invalidate the results of a
few selftests. On the other hand, the second fix
From: Gustavo Romero
When disabling freezing counters by setting MMCR0 FC bit to 0, the MMCR0
PMAE bit must also be enabled if a Performance Monitor Alert (and the cor-
responding Performance Monitor Interrupt) is still desired to be received
when an enabled condition or event occurs.
This is th
On Wed, Apr 08, 2020 at 05:45:55PM +0200, Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Reviewed-by: Mathieu Poirier #
> hwtracing/coresig
On Wed, Apr 08, 2020 at 08:58:16PM +0200, Arnd Bergmann wrote:
> A 1024 byte variable on the stack will warn on any 32-bit architecture
> during compile-testing, and is generally a bad idea anyway:
>
> fsl/dpio/dpio-service.c: In function
> 'dpaa2_io_service_enqueue_multiple_desc_fq':
> fsl/dpio/
Building dpio for 32 bit shows a new compiler warning from converting
a pointer to a u64:
drivers/soc/fsl/dpio/qbman-portal.c: In function
'qbman_swp_enqueue_multiple_desc_direct':
drivers/soc/fsl/dpio/qbman-portal.c:870:14: warning: cast from pointer to
integer of different size [-Wpointer-to-i
A 1024 byte variable on the stack will warn on any 32-bit architecture
during compile-testing, and is generally a bad idea anyway:
fsl/dpio/dpio-service.c: In function
'dpaa2_io_service_enqueue_multiple_desc_fq':
fsl/dpio/dpio-service.c:495:1: error: the frame size of 1032 bytes is larger
than 1
Le 08/04/2020 à 20:11, Segher Boessenkool a écrit :
On Mon, Apr 06, 2020 at 12:25:27PM +0200, Christophe Leroy wrote:
if (ppc_inst_prefixed(x) != ppc_inst_prefixed(y))
return false;
else if (ppc_inst_prefixed(x))
return !memcmp(&x, &y, sizeof(st
On Wed, 2020-04-08 at 22:13 +1000, Michael Ellerman wrote:
[...]
> Added context:
>
> printk(KERN_EMERG "Sending IPI to other CPUs\n");
>
> if (crash_wake_offline)
> ncpus = num_present_cpus() - 1;
>
> >
> > crash_send_ipi(crash_ipi_callback);
> > smp_wmb();
>
Hi!
On Mon, Apr 06, 2020 at 06:09:20PM +1000, Jordan Niethe wrote:
> +static inline int ppc_inst_opcode(u32 x)
> +{
> + return x >> 26;
> +}
Maybe you should have "primary opcode" in this function name?
Segher
On Mon, Apr 06, 2020 at 12:25:27PM +0200, Christophe Leroy wrote:
> > if (ppc_inst_prefixed(x) != ppc_inst_prefixed(y))
> > return false;
> > else if (ppc_inst_prefixed(x))
> > return !memcmp(&x, &y, sizeof(struct ppc_inst));
>
> Are we sure memcmp() is a good candi
On Wed, 2020-04-08 at 22:21 +1000, Michael Ellerman wrote:
> We should be able to just allocate the rtas_args on the stack, it's only
> ~80 odd bytes. And then we can use rtas_call_unlocked() which doesn't
> take the global lock.
At this point, would it be a problem using kmalloc?
Best regards,
On Wed, 2020-04-08 at 22:21 +1000, Michael Ellerman wrote:
[...]
> > On the other hand, busting the rtas.lock could be dangerous, because
> > it's code we can't control.
> >
> > According with LoPAR, for both of these rtas-calls, we have:
> >
> > For the PowerPC External Interrupt option: The cal
Hello,
Since the PowerPC updates 5.7-1 we have the following issue during the
linking of vmlinux:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
reference from the function .early_init_mmu() to the function
.init.text:.radix__early_init_mmu()
The fu
On Wed, Apr 08, 2020 at 05:03:24PM +0100, Russell King - ARM Linux admin wrote:
> I haven't read all your patches yet.
>
> Have you tested it on 32-bit ARM, where the module area is located
> _below_ PAGE_OFFSET and outside of the vmalloc area?
I have not tested it. However existing in-kernel us
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> Peter noticed that with some dumb luck you can toast the kernel address
> space with exported vmalloc symbols.
>
> I used this as an opportunity to decruft the vmalloc.c API and make it
> much more systematic. This
https://bugzilla.kernel.org/show_bug.cgi?id=207129
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Yes, precisely summarized! Thanks for your efforts!
CONFIG_KASAN though only is x86_64 not x86 AFAIK.
--
You are receiving this mail because:
You are watching the assignee of the bug.
When CONFIG_KASAN is selected, the stack usage is increased.
In the same way as x86 and arm64 architectures, increase
THREAD_SHIFT when CONFIG_KASAN is selected.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207129
Reported-by:
Signed-off
On Wed, Apr 08, 2020 at 05:45:57PM +0200, Mauro Carvalho Chehab wrote:
> Some filesystem references got broken by a previous patch
> series I submitted. Address those.
>
> Signed-off-by: Mauro Carvalho Chehab
For
> fs/affs/Kconfig | 2 +-
Acked-by: D
Some filesystem references got broken by a previous patch
series I submitted. Address those.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/sysfs-devices-node | 2 +-
Documentation/ABI/testing/procfs-smaps_rollup | 2 +-
Documentation/admin-guide/
Several references got broken due to txt to ReST conversion.
Several of them can be automatically fixed with:
scripts/documentation-file-ref-check --fix
Reviewed-by: Mathieu Poirier #
hwtracing/coresight/Kconfig
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/memory-barriers.t
The User API chapter contains two sub-chapters. Mark them as
such.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/powerpc/cxl.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/powerpc/cxl.rst b/Documentation/powerpc/cxl.rst
index 920546d81326..d2d77057610e 100644
--
Hi Jon,
I have a large list of patches this time for the Documentation/. So, I'm
starting sending them a little earier. Yet, those are meant to be applied
after the end of the merge window. They're based on today's linux-next,
with has only 49 patches pending to be applied upstream touching
Docume
On Wed, Apr 08, 2020 at 08:48:33PM +0800, Hillf Danton wrote:
> > - void *addr = vm_map_ram(pages, num, -1, pgprot);
> > + void *addr = vmap(pages, num, VM_MAP);
>
> A merge glitch?
>
> void *vmap(struct page **pages, unsigned int count,
> unsigned long flags, pgprot_t prot)
Yes, th
On 4/8/20 8:36 AM, Christoph Hellwig wrote:
> On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
> config ZSMALLOC_PGTABLE_MAPPING
> bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y
It's a bool so
On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
diff --git a/mm/Kconfig b/mm/Kconfig
index 36949a9425b8..
On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
> > > > config ZSMALLOC_PGTABLE_MAPPING
> > > > bool "Use page table mapping to access object in zsmalloc"
> > > > - depends on ZSMALLOC
> > > > + depends on ZSMALLOC=y
> > >
> > > It's a bool so this shouldn't ma
On Wed, Apr 08, 2020 at 01:38:36PM +0100, Mark Rutland wrote:
> > +static inline pgprot_t pgprot_nx(pgprot_t prot)
> > +{
> > + return __pgprot(pgprot_val(prot) | _PAGE_NX);
> > +}
> > +#define pgprot_nx pgprot_nx
> > +
> > #ifdef CONFIG_X86_PAE
>
> I reckon for arm64 we can do similar in our :
Hi Michael,
On 4/7/20 10:13 PM, Michael Ellerman wrote:
> bugzilla-dae...@bugzilla.kernel.org writes:
>> https://bugzilla.kernel.org/show_bug.cgi?id=206203
>>
>> Erhard F. (erhar...@mailbox.org) changed:
>>
>>What|Removed |Added
>> --
On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
> > Hi,
> >
> > On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > index 36949a9425b8..614cc786b519 100644
> > > --- a/mm/Kconfi
On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
> Hi,
>
> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 36949a9425b8..614cc786b519 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -702,7 +702,7 @@ config ZSMALLOC
> >
> > conf
Hi,
On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>
> config ZSMALLOC_PGTABLE_MAPPING
> bool "Use page table mapping to access object
On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arm/configs/omap2plus_defconfig | 2 +-
> include/linux/zsmalloc.h | 2 +-
> mm/Kconfig | 2 +-
> mm/zsmalloc.c
https://bugzilla.kernel.org/show_bug.cgi?id=207129
--- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) ---
Ok, so as a summary:
- With CONFIG_THREAD_SHIFT = 13 and CONFIG_DEBUG_STACKOVERFLOW, the system gets
stuck
- With CONFIG_THREAD_SHIFT = 13 and without CONFIG_DEBUG_STACKOVERFLOW, s
Hello,
I have taken another look at the implementation of the function “fsl_udc_probe”.
A software analysis approach points the following source code out for
further development considerations.
https://elixir.bootlin.com/linux/v5.6.2/source/drivers/usb/gadget/udc/fsl_udc_core.c#L2443
https://git.k
On 08.04.20 13:59, Christoph Hellwig wrote:
> stack_alloc can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/s390/kernel/setup.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/s390/kernel/setup.c b/arch/
On 08.04.20 13:59, Christoph Hellwig wrote:
> alloc_vm_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/kernel/irq.c | 5 ++---
wrong subject (power vs s390)
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arc
On Wed, Apr 08, 2020 at 01:59:00PM +0200, Christoph Hellwig wrote:
> vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
> with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Greg Kroah-Hartman
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
> > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
> >> Benjamin Herrenschmidt writes:
> > IBM still put 40x cores inside POWER chips no ?
>
> Oh yeah that's true. I guess most folks don't know t
Daniel Axtens writes:
> Raphael Moreira Zinsly writes:
...
>> +#define hwsync()({ asm volatile("hwsync" ::: "memory"); })
>
> This doesn't compile on the clang version I tried as it doesn't
> recognise 'hwsync'. Does
> asm volatile("sync" ::: "memory");
> do the same thing?
Both hwsync and
On Wed, 8 Apr 2020 13:59:00 +0200
>
> vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
> with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/staging/android/ion/ion_heap.c | 4 ++--
> 1 file chang
On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote:
> To help enforcing the W^X protection don't allow remapping existing
> pages as executable.
>
> Based on patch from Peter Zijlstra .
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/include/asm/pgtable_types.h | 6 ++
>
On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> If this code was broken for non-coherent caches a crude powerpc hack
> isn't going to help anyone else. Remove the hack as it is the last
> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
Well Ben added
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> Peter noticed that with some dumb luck you can toast the kernel address
> space with exported vmalloc symbols.
>
> I used this as an opportunity to decruft the vmalloc.c API and make it
> much more systematic. This
On Wed, Apr 08, 2020 at 02:21:04PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> > This is always GFP_KERNEL - for long term mappings with other properties
> > vmap should be used.
>
> PAGE_KERNEL != GFP_KERNEL :-)
Yep. The compiler complain
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote:
> This is always GFP_KERNEL - for long term mappings with other properties
> vmap should be used.
PAGE_KERNEL != GFP_KERNEL :-)
> - return vm_map_ram(mock->pages, mock->npages, 0, PAGE_KERNEL);
> + return vm_map_ram(mock-
Leonardo Bras writes:
> Hello Nick, Michael,
>
> On Fri, 2020-04-03 at 16:41 +1000, Nicholas Piggin wrote:
> [...]
>> > > PAPR says we are not allowed to have multiple CPUs calling RTAS at once,
>> > > except for a very small list of RTAS calls. So if we bust the RTAS lock
>> > > there's a risk we
On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote:
> arch_alloc_vmap_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/vmap_stack.h | 6 ++
> 1 file changed, 2 insertion
On Wed, 8 Apr 2020 12:41:51 +0530
Anshuman Khandual wrote:
[...]
> >
> >>
> >> Some thing like this instead.
> >>
> >> pte_t pte = READ_ONCE(*ptep);
> >> pte = pte_mkhuge(__pte((pte_val(pte) | RANDOM_ORVALUE) & PMD_MASK));
> >>
> >> We cannot use mk_pte_phys() as it is defined only on some pla
Leonardo Bras writes:
> Currently, if printk lock (logbuf_lock) is held by other thread during
> crash, there is a chance of deadlocking the crash on next printk, and
> blocking a possibly desired kdump.
>
> After sending IPI to all other CPUs, make printk enter in NMI context,
> as it will use pe
Benjamin Herrenschmidt writes:
> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> Benjamin Herrenschmidt writes:
>> > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
>> > > I have no attachment to 40x, and I'd certainly be happy to have
>> > > less
>> > > code in the tree,
stack_alloc can use a slightly higher level vmalloc function.
Signed-off-by: Christoph Hellwig
---
arch/s390/kernel/setup.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 36445dd40fdb..0f0b140b5558 100644
---
Open code it in __bpf_map_area_alloc, which is the only caller. Also
clean up __bpf_map_area_alloc to have a single vmalloc call with
slightly different flags instead of the current two different calls.
For this to compile for the nommu case add a __vmalloc_node_range stub
to nommu.c.
Signed-off
arch_alloc_vmap_stack can use a slightly higher level vmalloc function.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/vmap_stack.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/vmap_stack.h
b/arch/arm64/include/asm/vmap_stack.h
in
alloc_vm_stack can use a slightly higher level vmalloc function.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index a25ed47087ee..4518fb1d6bf4 100644
-
Just use __vmalloc_node instead which gets and extra argument. To be
able to to use __vmalloc_node in all caller make it available outside
of vmalloc and implement it in nommu.c.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 4 ++--
kernel/bpf/syscall.c| 5 ++---
mm/nommu
No need to export the very low-level __vmalloc_node_range when the
test module can use a slightly higher level variant.
Signed-off-by: Christoph Hellwig
---
lib/test_vmalloc.c | 26 +++---
mm/vmalloc.c | 17 -
2 files changed, 15 insertions(+), 28 deleti
The pgprot argument to __vmalloc is always PROT_KERNEL now, so remove
it.
Signed-off-by: Christoph Hellwig
---
arch/x86/hyperv/hv_init.c | 3 +--
arch/x86/include/asm/kvm_host.h| 3 +--
arch/x86/kvm/svm.c | 3 +--
drivers/block/drbd/drbd_bitmap.c
This is always PAGE_KERNEL now.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 466a449b3a15..de7952959e82 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@
The real version just had a few callers that can open code it and
remove one layer of indirection. The nommu stub was public but only
had a single caller, so remove it and avoid a CONFIG_MMU ifdef in
vmalloc.h.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 9 -
mm/nomm
If this code was broken for non-coherent caches a crude powerpc hack
isn't going to help anyone else. Remove the hack as it is the last
user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_scatter.c | 11 +--
1
To help enforcing the W^X protection don't allow remapping existing
pages as executable.
Based on patch from Peter Zijlstra .
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/pgtable_types.h | 6 ++
include/asm-generic/pgtable.h| 4
mm/vmalloc.c
This is always GFP_KERNEL - for long term mappings with other properties
vmap should be used.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 2 +-
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 +--
drivers/media/common/videobuf2/videobuf2-vmall
This function just has a single caller, open code it there.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b0c7cdc8701a..258220b203f1 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@
Switch all callers to map_kernel_range, which symmetric to the unmap
side (as well as the _noflush versions).
Signed-off-by: Christoph Hellwig
---
Documentation/core-api/cachetlb.rst | 2 +-
include/linux/vmalloc.h | 10 --
mm/vmalloc.c| 21 +++---
None of the callers needs the number of pages, and a 0 / -errno return
value is a lot more intuitive.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a3d810def567..ca8dc5d42580 100644
---
This allows to unexport map_vm_area and unmap_kernel_range, which are
rather deep internal and should not be available to modules.
Signed-off-by: Christoph Hellwig
---
mm/Kconfig | 2 +-
mm/vmalloc.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
This matches the map_kernel_range_noflush API. Also change to pass
a size instead of the end, similar to the noflush version.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 55df5
These have non-static aliases claled map_kernel_range_noflush and
unmap_kernel_range_noflush that just differ slightly in the calling
conventions that pass addr + size instead of an end.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 98 +---
Rename the Kconfig variable to clarify the scope.
Signed-off-by: Christoph Hellwig
---
arch/arm/configs/omap2plus_defconfig | 2 +-
include/linux/zsmalloc.h | 2 +-
mm/Kconfig | 2 +-
mm/zsmalloc.c| 8
4 files changed, 7 inse
Ever use of addr in vb_free casts to unsigned long first, and the caller
has an unsigned long version of the address available anyway. Just pass
that and avoid all the casts.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
There are no modular users of this function.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d1534d610b48..3375f9508ef6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2029,7 +2029,6 @@ void unmap_kernel_rang
Switch the two remaining callers to use __get_vm_area_caller instead.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/pci_64.c | 3 ++-
arch/sh/kernel/cpu/sh4/sq.c | 3 ++-
include/linux/vmalloc.h | 2 --
mm/vmalloc.c | 8
4 files changed, 4 insertions(+),
Factor code shared between pci_64 and electra_cf into a ioremap_pbh
helper that follows the normal ioremap semantics, and returns a
useful __iomem pointer. Note that it opencodes __ioremap_at as
we know from the callers the slab is available. Switch pci_64
to also store the result as __iomem poin
These helpers are only used for remapping the ISA I/O base. Replace
the mapping side with a remap_isa_range helper in isa-bridge.c that
hard codes all the known arguments, and just remove __iounmap_at in
favour of open coding it in the only caller.
Signed-off-by: Christoph Hellwig
---
arch/powe
Replace the open coded instance of vmap with the actual function. In
the non-contiguous (IOMMU) case this requires an extra find_vm_area,
but given that this isn't a fast path function that is a small price
to pay.
Signed-off-by: Christoph Hellwig
---
kernel/dma/remap.c | 48 ---
Just use vmap instead of messing with vmalloc internals.
Signed-off-by: Christoph Hellwig
---
drivers/staging/media/ipu3/ipu3-css-pool.h | 4 +--
drivers/staging/media/ipu3/ipu3-dmamap.c | 30 ++
2 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/stagi
vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
Signed-off-by: Christoph Hellwig
---
drivers/staging/android/ion/ion_heap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
1 - 100 of 115 matches
Mail list logo
