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
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
> >
> >
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
---
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.
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,
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:
+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
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,
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
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
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
> > > ---
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
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
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
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
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 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:
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
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
>>
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
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
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
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
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 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
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
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, 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
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 +-
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(, , sizeof(struct ppc_inst));
>
> Are we sure memcmp() is a good
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
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
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,
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
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(, ,
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 #
>
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();
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':
>
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
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
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.
>
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 +-
>
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
---
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
On Fri, Apr 03, 2020 at 03:51:18PM +1100, Oliver O'Halloran wrote:
> On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > EEH device state is currently removed (by eeh_remove_device()) during
> > the device release handler, which is invoked as the device's reference
> > count drops to zero.
On Fri, Apr 03, 2020 at 05:08:32PM +1100, Oliver O'Halloran wrote:
> On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > When EEH device state was released asynchronously by the device
> > release handler, it was possible for an outstanding reference to
> > prevent it's release and it was
On Fri, Apr 03, 2020 at 04:45:47PM +1100, Oliver O'Halloran wrote:
> On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > Because the bus notifier calls eeh_rmv_from_parent_pe() (via
> > eeh_remove_device()) when a VF is removed, the call in
> > remove_sriov_vf_pdns() is redundant.
>
>
Hi Ben,
On Wed, Apr 8, 2020 at 1:34 AM Benjamin Herrenschmidt
wrote:
> 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
On Wed, Apr 8, 2020 at 4:22 PM Sam Bobroff wrote:
>
> On Fri, Apr 03, 2020 at 05:08:32PM +1100, Oliver O'Halloran wrote:
> > On Mon, 2020-03-30 at 15:56 +1100, Sam Bobroff wrote:
> > > When EEH device state was released asynchronously by the device
> > > release handler, it was possible for an
Le 08/04/2020 à 04:13, Andrew Donnellan a écrit :
On 7/4/20 9:56 pm, Frederic Barrat wrote:
Improve the error message shown if a capi adapter is plugged on a
capi-incompatible slot directly under the PHB (no intermediate switch).
Fixes: 5632874311db ("cxl: Add support for POWER9 DD2")
Cc:
On 04/07/2020 09:24 PM, Gerald Schaefer wrote:
> On Sun, 5 Apr 2020 17:58:14 +0530
> Anshuman Khandual wrote:
>
> [...]
>>>
>>> Could be fixed like this (the first de-reference is a bit special,
>>> because at that point *ptep does not really point to a large (pmd) entry
>>> yet, it is
Le 08/04/2020 à 01:32, Benjamin Herrenschmidt a écrit :
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
Use of_property_read_u32 to read the "reg" and "i2c-address" property
instead of using of_get_property to check the return values.
Signed-off-by: Aishwarya R
---
drivers/i2c/busses/i2c-powermac.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Hi Abhishek,
On Fri, Apr 03, 2020 at 04:27:01AM -0500, Abhishek Goel wrote:
> This patch provides kernel framework fro opal support of save restore
> of sprs in idle stop loop. Opal support for stop states is needed to
> selectively enable stop states or to introduce a quirk quickly in case
> a
Le 31/03/2020 à 05:19, Christopher M Riedl a écrit :
On March 24, 2020 11:10 AM Christophe Leroy wrote:
Le 23/03/2020 à 05:52, Christopher M. Riedl a écrit :
When code patching a STRICT_KERNEL_RWX kernel the page containing the
address to be patched is temporarily mapped with permissive
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
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.
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
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
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
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
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
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
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
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
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 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: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 ++
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
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
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 +--
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
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 +--
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 -
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 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
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
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 ++---
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
On 23/03/2020 18:53, Alexey Kardashevskiy wrote:
> Here is an attempt to support bigger DMA space for devices
> supporting DMA masks less than 59 bits (GPUs come into mind
> first). POWER9 PHBs have an option to map 2 windows at 0
> and select a windows based on DMA address being below or above
Hi Pratik,
On Wed, Mar 04, 2020 at 09:26:48PM +0530, Pratik Rajesh Sampat wrote:
> A concept patch in Skiboot to illustrate the case wherein handling of
> stop states for different DD versions of a CPU can be achieved by a
> simple modification in the list of cpu_features.
> As an example
Hi Pratik,
On Wed, Mar 04, 2020 at 09:31:21PM +0530, Pratik Rajesh Sampat wrote:
> Design patch to introduce the idea of having a dependency structure for
> idle-stop. The structure encapsulates the following:
> 1. Bitmask for version of idle-stop
> 2. Bitmask for propterties like ENABLE/DISABLE
Hi Pratik,
On Wed, Mar 04, 2020 at 09:31:23PM +0530, Pratik Rajesh Sampat wrote:
> Design patch that introduces the capability for firmware to handle the
> stop states instead. A bit is set based on the discovery of the feature
> and correspondingly also the responsibility to handle the stop
Hi Cascardo,
Thanks for following-up on this.
Unfortunately I don't think I can merge this fix.
Thadeu Lima de Souza Cascardo writes:
> If a tracer sets the syscall number to an invalid one, allow the return
> value set by the tracer to be returned the tracee.
The problem is this patch not
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 also removes any chance to create vmalloc
mappings outside the designated areas
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
1 - 100 of 115 matches
Mail list logo
