On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc:
On Mon, 07 Sep 2020 21:27:08 PDT (-0700), masahi...@kernel.org wrote:
There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
The difference between vmlinux.lds and module.lds is that the latter
is needed for external
On Mon, 24 Aug 2020 21:55:57 -0700, Joe Perches wrote:
> There are many comma separated statements in the kernel.
> See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
>
> Convert the comma separated statements that are in if/do/while blocks
> to use braces and
randconfig-a005-20200907
x86_64 randconfig-a001-20200907
x86_64 randconfig-a002-20200907
i386 randconfig-a004-20200908
i386 randconfig-a005-20200908
i386 randconfig-a006-20200908
i386 randconfig-a002-20200908
i386
-20200907
x86_64 randconfig-a005-20200907
x86_64 randconfig-a001-20200907
x86_64 randconfig-a002-20200907
i386 randconfig-a004-20200908
i386 randconfig-a005-20200908
i386 randconfig-a006-20200908
i386
randconfig-a004-20200908
i386 randconfig-a005-20200908
i386 randconfig-a006-20200908
i386 randconfig-a002-20200908
i386 randconfig-a001-20200908
i386 randconfig-a003-20200908
i386
randconfig-a003-20200907
x86_64 randconfig-a005-20200907
x86_64 randconfig-a001-20200907
x86_64 randconfig-a002-20200907
i386 randconfig-a004-20200908
i386 randconfig-a005-20200908
i386 randconfig-a006
Tyrel,
> Update ibmvfc.h structs to use the preferred __packed and __aligned()
> attribute macros defined in include/linux/compiler_attributes.h in place
> of __attribute__().
Applied 1+2 to my 5.10 staging tree. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Christophe Leroy writes:
> Le 08/09/2020 à 14:58, Michael Ellerman a écrit :
>> When we added the VDSO32 kconfig symbol, which controls building of
>> the 32-bit VDSO, we made it depend on CPU_BIG_ENDIAN (for 64-bit).
>>
>> That was because back then COMPAT was always enabled for 64-bit, so
>>
On Tue, Jun 30, 2020 at 01:47:39PM -0300, Thadeu Lima de Souza Cascardo wrote:
> As pointed out by Michael Ellerman, the ptrace ABI on powerpc does not
> allow or require the return code to be set on syscall entry when
> skipping the syscall. It will always return ENOSYS and the return code
> must
On Sat, 22 Aug 2020 17:40:45 +0200, Christian Lamparter wrote:
> Meraki was founded in 2006. The start-up quickly rose to prominence
> by being based in part on the MIT Roofnet Project.
> In December 2012, Cisco Systems, Inc. bought Meraki.
> The "Meraki" branding is still around to this day.
>
>
On Mon, Sep 07, 2020 at 04:35:40PM +0530, Vaibhav Jain wrote:
> The newly introduced 'perf_stats' attribute uses the default access
> mode of 0444 letting non-root users access performance stats of an
> nvdimm and potentially force the kernel into issuing large number of
> expensive HCALLs. Since
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan
Hello,
On Tue, Sep 8, 2020 at 9:12 AM Michael Ellerman wrote:
> Christian Lamparter writes:
> > On 2020-06-23 15:03, Michael Ellerman wrote:
> >> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
> >> warnings about our dts files, such as:
> >>
> >>
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen wrote:
> On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic page table folding.
>
> Would
On Tue, Sep 08, 2020 at 12:50:44PM -0400, Qian Cai wrote:
> > No, you're talking nonsense. We must not free @mm when
> > 'current->active_mm == mm', never.
>
> Yes, you are right. It still trigger this below on powerpc with today's
> linux-next by fuzzing for a while (saw a few times on recent
On Tue, 8 Sep 2020 07:22:39 +0200
Christophe Leroy wrote:
>
>
> Le 07/09/2020 à 22:12, Mike Rapoport a écrit :
> > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote:
> >> This is v2 of an RFC previously discussed here:
> >>
On Tue, 25 Aug 2020 21:02:24 +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, imx_es8328_probe() doesn't have
> a corresponding put_device(). Thus add a jump target to fix the exception
> handling for this function implementation.
Applied to
Le 08/09/2020 à 17:48, Alexander Gordeev a écrit :
On Tue, Sep 08, 2020 at 07:19:38AM +0200, Christophe Leroy wrote:
[...]
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 67ebc22cf83d..d9e7d16c2263 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@
61231: bb bb bb bb bb bb bb bb
[12802.557947][T191552] Padding 3163b13a: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
5a 5a 5a 5a 5a 5a
[12802.558076][T191552] Padding 92412b1a: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
5a 5a 5a 5a 5a 5a
On Tue, Sep 08, 2020 at 07:19:38AM +0200, Christophe Leroy wrote:
[...]
> >diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> >index 67ebc22cf83d..d9e7d16c2263 100644
> >--- a/include/linux/pgtable.h
> >+++ b/include/linux/pgtable.h
> >@@ -656,31 +656,35 @@ static inline int
On Fri, 4 Sep 2020 18:01:15 +0200
Gerald Schaefer wrote:
[...]
>
> BTW2, a quick test with this change (so far) made the issues on s390
> go away:
>
> @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void)
> spin_unlock(ptl);
>
> #ifndef CONFIG_PPC_BOOK3S_64
> -
On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> x86:
> add/remove: 0/0 grow/shrink: 2/0 up/down: 10/0 (10)
> Function old new delta
> vmemmap_populate 587 592 +5
> munlock_vma_pages_range 556 561
On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> code") introduced a subtle but severe bug on s390 with gup_fast, due to
> dynamic page table folding.
Would it be fair to say that the "fake" page table entries s390
allocates
On Tue, Sep 08, 2020 at 07:14:38AM +0200, Christophe Leroy wrote:
[...]
> You forgot arch/powerpc/mm/book3s64/subpage_prot.c it seems.
If this one would be okay?
diff --git a/arch/powerpc/mm/book3s64/subpage_prot.c
b/arch/powerpc/mm/book3s64/subpage_prot.c
index 60c6ea16..3690d22 100644
---
On Tue, Sep 08, 2020 at 10:16:49AM +0200, Christophe Leroy wrote:
> >Yes, and also two more sources :/
> > arch/powerpc/mm/kasan/8xx.c
> > arch/powerpc/mm/kasan/kasan_init_32.c
> >
> >But these two are not quite obvious wrt pgd_addr_end() used
> >while traversing pmds. Could you please
On Tue, 8 Sep 2020 14:40:10 +0200
Christophe Leroy wrote:
>
>
> Le 08/09/2020 à 14:09, Christian Borntraeger a écrit :
> >
> >
> > On 08.09.20 07:06, Christophe Leroy wrote:
> >>
> >>
> >> Le 07/09/2020 à 20:00, Gerald Schaefer a écrit :
> >>> From: Alexander Gordeev
> >>>
> >>> Commit
On Mon, Sep 07, 2020 at 08:00:57PM +0200, Gerald Schaefer wrote:
> From: Alexander Gordeev
>
> Unlike all other page-table abstractions pXd_addr_end() do not take
> into account a particular table entry in which context the functions
> are called. On architectures with dynamic page-tables
Le 08/09/2020 à 14:58, Michael Ellerman a écrit :
When we added the VDSO32 kconfig symbol, which controls building of
the 32-bit VDSO, we made it depend on CPU_BIG_ENDIAN (for 64-bit).
That was because back then COMPAT was always enabled for 64-bit, so
depending on it would have left the
When we added the VDSO32 kconfig symbol, which controls building of
the 32-bit VDSO, we made it depend on CPU_BIG_ENDIAN (for 64-bit).
That was because back then COMPAT was always enabled for 64-bit, so
depending on it would have left the 32-bit VDSO always enabled, which
we didn't want.
But
Le 08/09/2020 à 14:09, Christian Borntraeger a écrit :
On 08.09.20 07:06, Christophe Leroy wrote:
Le 07/09/2020 à 20:00, Gerald Schaefer a écrit :
From: Alexander Gordeev
Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
code") introduced a subtle but severe
On Tue, Sep 08, 2020 at 10:06:56PM +1000, Alexey Kardashevskiy wrote:
> On 08/09/2020 15:44, Christoph Hellwig wrote:
>> On Tue, Sep 08, 2020 at 11:51:06AM +1000, Alexey Kardashevskiy wrote:
>>> What is dma_get_required_mask() for anyway? What "requires" what here?
>>
>> Yes, it is a really odd
On 08.09.20 07:06, Christophe Leroy wrote:
>
>
> Le 07/09/2020 à 20:00, Gerald Schaefer a écrit :
>> From: Alexander Gordeev
>>
>> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
>> code") introduced a subtle but severe bug on s390 with gup_fast, due to
>> dynamic
On 08/09/2020 15:44, Christoph Hellwig wrote:
On Tue, Sep 08, 2020 at 11:51:06AM +1000, Alexey Kardashevskiy wrote:
What is dma_get_required_mask() for anyway? What "requires" what here?
Yes, it is a really odd API. It comes from classic old PCI where
64-bit addressing required an
On 9/8/20 3:51 AM, Alexey Kardashevskiy wrote:
> There are 2 problems with it:
> 1. "<" vs expected "<<"
> 2. the shift number is an IOMMU page number mask, not an address mask
> as the IOMMU page shift is missing.
>
> This did not hit us before f1565c24b596 ("powerpc: use the generic
>
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
> Exception fixup doesn't require the heady full regs saving,
heavy
> do it from do_page_fault() directly.
>
> For that, split bad_page_fault() in two parts.
>
> As bad_page_fault() can
Le 08/09/2020 à 10:43, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
The verification and message introduced by commit 374f3f5979f9
("powerpc/mm/hash: Handle user access of kernel address gracefully")
applies to all platforms, it should not be
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
> search_exception_tables() is an heavy operation, we have to avoid it.
> When KUAP is selected, we'll know the fault has been blocked by KUAP.
> Otherwise, it behaves just as if the address was already in the TLBs
> and no fault
Le 08/09/2020 à 10:29, Christophe Leroy a écrit :
Le 08/09/2020 à 09:48, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of September 7, 2020 9:34 pm:
On Mon, 2020-09-07 at 11:20 +0200, Christophe Leroy wrote:
Le 05/09/2020 à 19:43, Nicholas Piggin a écrit :
Make
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
> Check address earlier to simplify the following test.
Good logic reduction.
Reviewed-by: Nicholas Piggin
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/mm/fault.c | 10 +-
> 1 file changed, 5 insertions(+),
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
> To make it more readable, separate page_fault_is_write() and
> page_fault_is_bad()
> to avoir several levels of #ifdefs
Reviewed-by: Nicholas Piggin
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/mm/fault.c | 8
Excerpts from Christophe Leroy's message of August 7, 2020 3:15 am:
> The verification and message introduced by commit 374f3f5979f9
> ("powerpc/mm/hash: Handle user access of kernel address gracefully")
> applies to all platforms, it should not be limited to BOOK3S.
>
> Make the BOOK3S version
Le 08/09/2020 à 09:48, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of September 7, 2020 9:34 pm:
On Mon, 2020-09-07 at 11:20 +0200, Christophe Leroy wrote:
Le 05/09/2020 à 19:43, Nicholas Piggin a écrit :
Make interrupt handlers all just take the pt_regs * argument
Le 08/09/2020 à 09:46, Alexander Gordeev a écrit :
On Tue, Sep 08, 2020 at 07:14:38AM +0200, Christophe Leroy wrote:
You forgot arch/powerpc/mm/book3s64/subpage_prot.c it seems.
Yes, and also two more sources :/
arch/powerpc/mm/kasan/8xx.c
Excerpts from Christophe Leroy's message of September 7, 2020 9:34 pm:
> On Mon, 2020-09-07 at 11:20 +0200, Christophe Leroy wrote:
>>
>> Le 05/09/2020 à 19:43, Nicholas Piggin a écrit :
>> > Make interrupt handlers all just take the pt_regs * argument and load
>> > DAR/DSISR etc from that. Make
On Tue, Sep 08, 2020 at 07:14:38AM +0200, Christophe Leroy wrote:
> You forgot arch/powerpc/mm/book3s64/subpage_prot.c it seems.
Yes, and also two more sources :/
arch/powerpc/mm/kasan/8xx.c
arch/powerpc/mm/kasan/kasan_init_32.c
But these two are not quite obvious wrt
Excerpts from Christophe Leroy's message of September 7, 2020 7:20 pm:
>
>
> Le 05/09/2020 à 19:43, Nicholas Piggin a écrit :
>> Make interrupt handlers all just take the pt_regs * argument and load
>> DAR/DSISR etc from that. Make those that return a value return long.
>
> I like this, it will
Sachin Sant writes:
>> On 01-Sep-2020, at 6:16 PM, Michael Ellerman wrote:
>>
>> In commit 9b725a90a8f1 ("powerpc/64s: Disallow PROT_SAO in LPARs by
>> default") PROT_SAO was disabled in guests/LPARs by default. So skip
>> the test if we are running in a guest to avoid a spurious failure.
>>
Christian Lamparter writes:
> On 2020-06-23 15:03, Michael Ellerman wrote:
>> With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
>> warnings about our dts files, such as:
>>
>>arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
>>Warning (pci_bridge): /plb/pciex@d:
On Tue, Sep 8, 2020 at 6:29 AM Masahiro Yamada wrote:
> There was a request to preprocess the module linker script like we
> do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
>
> The difference between vmlinux.lds and module.lds is that the latter
> is needed for external module
Le 03/09/2020 à 23:35, Andrew Morton a écrit :
On Wed, 2 Sep 2020 11:09:11 +0200 Laurent Dufour wrote:
register_mem_sect_under_nodem() is checking the memory block's node id only
if the system state is "SYSTEM_BOOTING". On PowerPC, the memory blocks are
registered while the system state is
Alexey Kardashevskiy writes:
> There are 2 problems with it:
> 1. "<" vs expected "<<"
> 2. the shift number is an IOMMU page number mask, not an address mask
> as the IOMMU page shift is missing.
>
> This did not hit us before f1565c24b596 ("powerpc: use the generic
> dma_ops_bypass mode")
52 matches
Mail list logo
