* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Gerald Schaefer @ 2020-09-09 11:36 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <d4199cd4-e042-7a05-8a78-703eae958589@arm.com>
On Wed, 9 Sep 2020 13:38:25 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
> On 09/04/2020 08:56 PM, Gerald Schaefer wrote:
> > On Fri, 4 Sep 2020 12:18:05 +0530
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >
> >>
> >>
> >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> >>> This patch series includes fixes for debug_vm_pgtable test code so that
> >>> they follow page table updates rules correctly. The first two patches introduce
> >>> changes w.r.t ppc64. The patches are included in this series for completeness. We can
> >>> merge them via ppc64 tree if required.
> >>>
> >>> Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
> >>> page table update rules.
> >>>
> >>> These tests are broken w.r.t page table update rules and results in kernel
> >>> crash as below.
> >>>
> >>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
> >>> cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
> >>> pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
> >>> lr: c0000000005eeeec: pte_update+0x11c/0x190
> >>> sp: c000000c6d1e7950
> >>> msr: 8000000002029033
> >>> current = 0xc000000c6d172c80
> >>> paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
> >>> pid = 1, comm = swapper/0
> >>> kernel BUG at arch/powerpc/mm/pgtable.c:304!
> >>> [link register ] c0000000005eeeec pte_update+0x11c/0x190
> >>> [c000000c6d1e7950] 0000000000000001 (unreliable)
> >>> [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
> >>> [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
> >>> [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
> >>> [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
> >>> [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
> >>> [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
> >>> [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
> >>>
> >>> With DEBUG_VM disabled
> >>>
> >>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
> >>> [ 20.530183] Faulting instruction address: 0xc0000000000df330
> >>> cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
> >>> pc: c0000000000df330: memset+0x68/0x104
> >>> lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
> >>> sp: c000000c6d19f990
> >>> msr: 8000000002009033
> >>> dar: 0
> >>> current = 0xc000000c6d177480
> >>> paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
> >>> pid = 1, comm = swapper/0
> >>> [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
> >>> [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
> >>> [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
> >>> [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
> >>> [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
> >>> [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
> >>> [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
> >>> [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
> >>>
> >>> Changes from v3:
> >>> * Address review feedback
> >>> * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure.
> >>
> >> This version
> >>
> >> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE)
> >> - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed
> >> - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well
> >
> > When I quickly tested v3, it worked fine, but now it turned out to
> > only work fine "sometimes", both v3 and v4. I need to look into it
> > further, but so far it seems related to the hugetlb_advanced_tests().
> >
> > I guess there was already some discussion on this test, but we did
> > not receive all of the thread(s). Please always add at least
> > linux-s390@vger.kernel.org and maybe myself and Vasily Gorbik <gor@linux.ibm.com>
> > for further discussions.
>
> IIRC, the V3 series previously had all these addresses copied properly
> but this version once again missed copying all required addresses.
I also had issues with the de.ibm.com address, which might also have
made some mails disappear, and others might simply have been overlooked
be me. Don't bother, my bad.
>
> >
> > That being said, sorry for duplications, this might already have been
> > discussed. Preliminary analysis showed that it only seems to go wrong
> > for certain random vaddr values. I cannot make any sense of that yet,
> > but what seems strange to me is that the hugetlb_advanced_tests()
> > take a (real) pte_t pointer as input, and also use that for all
> > kinds of operations (set_huge_pte_at, huge_ptep_get_and_clear, etc.).
> >
> > Although all the hugetlb code in the kernel is (mis)using pte_t
> > pointers instead of the correct pmd/pud_t pointers like THP, that
> > is just for historic reasons. The pointers will actually never point
> > to a real pte_t (i.e. page table entry), but of course to a pmd
> > or pud entry, depending on hugepage size.
>
> HugeTLB logically operates on a PTE entry irrespective of it's real
> page table level position. Nonetheless, IIUC, vaddr here should have
> been aligned to real page table level in which the entry is being
> mapped currently.
That goes back to the time where only x86 had hugepages, and they
have the same layout for pte/pmd/etc entries, so it simply didn't
matter that the code (mis)used pte pointers / entries. But even for
x86, the hugetlb pte pointers would never have pointed to real ptes,
but pmds instead. That's why I call it misuse.
s390 is very sensitive to page table level, and we can also determine
the level from the entry value, which is used for some primitives.
Others have implicit assumptions and calculations, which go wrong
if a wrong level is passed in, like in this case for
huge_ptep_get_and_clear(). Simply aligning vaddr / pfn will not
be enough to fix this for s390, it has to be a pmd/pud pointer.
Or, as you already mentioned, the result of huge_pte_alloc().
Furthermore, the pmd and pte layout are different, so we simply cannot
use any pte_xxx primitives for hugepages. That was the reason for
introducing huge_ptep_get(), which will do an implicit conversion
from the real pmd/pud entry to a "fake" pte entry, which can then
be used with such pte_xxx primitives. Before writing it back in
set_huge_pte_at() we then do the reverse conversion to a proper
pmd/pud again.
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: Michael Ellerman @ 2020-09-09 11:24 UTC (permalink / raw)
To: David Hildenbrand, Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
Vishal Verma, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Juergen Gross, Pankaj Gupta, Libor Pechacek, linux-nvdimm,
Rafael J. Wysocki, linux-kernel, Wei Yang, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <3bc5b464-3229-d442-714a-ec33b5728ac6@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>> mergeable. Prepare for that.
>>
>> What are these random "flags", and how do we know what should be passed
>> to them?
>>
>> Why not make this an enumerated type so that we know it all works
>> properly, like the GPF_* flags are? Passing around a random unsigned
>> long feels very odd/broken...
>
> Agreed, an enum (mhp_flags) seems to give a better hint what can
> actually be passed. Thanks!
You probably know this but ...
Just using a C enum doesn't get you any type safety.
You can get some checking via sparse by using __bitwise, which is what
gfp_t does. You don't actually have to use an enum for that, it works
with #defines also.
Or you can wrap the flag in a struct, the way atomic_t does, and then
the compiler will prevent passing plain integers in place of your custom
type.
cheers
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Gerald Schaefer @ 2020-09-09 11:16 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-s390@vger.kernel.org, Anshuman Khandual, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <87wo134h3s.fsf@linux.ibm.com>
On Wed, 09 Sep 2020 11:38:39 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> Gerald Schaefer <gerald.schaefer@linux.ibm.com> writes:
>
> > On Fri, 4 Sep 2020 18:01:15 +0200
> > Gerald Schaefer <gerald.schaefer@linux.ibm.com> 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
> >> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
> >> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, prot);
> >> #endif
> >>
> >> spin_lock(&mm->page_table_lock);
> >>
> >> That would more match the "pte_t pointer" usage for hugetlb code,
> >> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
> >> but I think the root cause is the pte_t pointer.
> >>
> >> Not entirely sure though if that would really be the correct fix.
> >> I somehow lost whatever little track I had about what these tests
> >> really want to check, and if that would still be valid with that
> >> change.
> >
> > Uh oh, wasn't aware that this (or some predecessor) already went
> > upstream, and broke our debug kernel today.
>
> Not sure i followed the above. Are you finding that s390 kernel crash
> after this patch series or the original patchset? As noted in my patch
> the hugetlb test is broken and we should fix that. A quick fix is to
> comment out that test for s390 too as i have done for PPC64.
We see it with both, it basically is broken since there is a hugetlb
test using real pte pointers. It doesn't always show, depending on
random vaddr, so it slipped through earlier testing.
I guess we also would have had one or the other chance to notice
that earlier, through better review, or better reading of previous
mails. I must admit that I neglected this a bit.
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Gerald Schaefer @ 2020-09-09 11:10 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <ac85fd77-bca1-3318-de0e-eea40558cbbd@arm.com>
On Wed, 9 Sep 2020 13:45:48 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
[...]
> >
> > That would more match the "pte_t pointer" usage for hugetlb code,
> > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
> > but I think the root cause is the pte_t pointer.
>
> Ideally, the pte_t pointer used here should be from huge_pte_alloc()
> not from pte_alloc_map_lock() as the case currently.
Ah, good point. I assumed that this would also always return casted
pmd etc. pointers, and never pte pointers. Unfortunately, that doesn't
seem to be true for all architectures, e.g. ia64, parisc, (some) powerpc,
where they really do a pte_alloc_map() for some reason.
I guess that means you cannot simply cast the pmd pointer, as suggested,
although I really do not understand how any architecture can work with
real ptes for hugepages. But that's fair, s390 also does some things that
nobody would expect or understand for other architectures...
So, for using huge_pte_alloc() you'd also need some size, maybe
iterating over hstates with for_each_hstate() could be an option,
if they are already initialized at that point. Then you have the
size(s) with huge_page_size(hstate) and can actually call the
hugetlb tests for all supported sizes, and with proper pointer
from huge_pte_alloc().
^ permalink raw reply
* Re: Flushing transparent hugepages
From: Aneesh Kumar K.V @ 2020-09-09 10:26 UTC (permalink / raw)
To: Matthew Wilcox, linux-arch
Cc: Thomas Bogendoerfer, Will Deacon, Vineet Gupta, Russell King,
linux-mips, linux-mm, Paul Mackerras, Catalin Marinas, sparclinux,
linux-snps-arc, linuxppc-dev, David S. Miller, linux-arm-kernel
In-Reply-To: <20200818150736.GQ17456@casper.infradead.org>
Matthew Wilcox <willy@infradead.org> writes:
> PowerPC has special handling of hugetlbfs pages. Well, that's what
> the config option says, but actually it handles THP as well. If
> the config option is enabled.
>
> #ifdef CONFIG_HUGETLB_PAGE
> if (PageCompound(page)) {
> flush_dcache_icache_hugepage(page);
> return;
> }
> #endif
I do have a change posted sometime back to avoid that confusion.
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200320103256.229365-1-aneesh.kumar@linux.ibm.com/
But IIUC we use the head page flags (PG_arch_1) to track whether we need
the flush or not.
>
> By the way, THPs can be mapped askew -- that is, at an offset which
> means you can't use a PMD to map a PMD sized page.
>
> Anyway, we don't really have consensus between the various architectures
> on how to handle either THPs or hugetlb pages. It's not contemplated
> in Documentation/core-api/cachetlb.rst so there's no real surprise
> we've diverged.
>
> What would you _like_ to see? Would you rather flush_dcache_page()
> were called once for each subpage, or would you rather maintain
> the page-needs-flushing state once per compound page? We could also
> introduce flush_dcache_thp() if some architectures would prefer it one
> way and one the other, although that brings into question what to do
> for hugetlbfs pages.
>
> It might not be a bad idea to centralise the handling of all this stuff
> somewhere. Sounds like the kind of thing Arnd would like to do ;-) I'll
> settle for getting enough clear feedback about what the various arch
> maintainers want that I can write a documentation update for cachetlb.rst.
^ permalink raw reply
* Re: [PATCH kernel] powerpc/dma: Fix dma_map_ops::get_required_mask
From: Alexey Kardashevskiy @ 2020-09-09 9:36 UTC (permalink / raw)
To: Christoph Hellwig, Cédric Le Goater, Michael Ellerman,
Oliver OHalloran, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200909075849.GA12282@lst.de>
On 09/09/2020 17:58, Christoph Hellwig wrote:
> On Tue, Sep 08, 2020 at 11:10:03PM +1000, Alexey Kardashevskiy wrote:
>>>> a-ha, this makes more sense, thanks. Then I guess we need to revert that
>>>> one bit from yours f1565c24b596, do not we?
>>>
>>> Why? The was the original intent of the API, but now we also use
>>> internally to check the addressing capabilities.
>>
>> The bigger mask the better, no? As it is now, it's limited by the window
>> size which happens to be bigger than 4GB but smaller then full 64bit (48bit
>> on my system)
>
> Yes, the bigger mask is better. But I don't see why you'd want to
> revert the dma bypass code for that entirely.
>
I want dma_get_required_mask() to return the bigger mask always.
Now it depends on (in dma_alloc_direct()):
1. dev->dma_ops_bypass: set via pci_set_(coherent_)dma_mask();
2. dev->coherent_dma_mask - the same;
3. dev->bus_dma_limit - usually not set at all.
So until we set the mask, dma_get_required_mask() returns smaller mask.
So aacraid and likes (which calls dma_get_required_mask() before setting
it) will remain prone for breaks.
[forgot to cc: other folks last time, fixed now]
--
Alexey
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Anshuman Khandual @ 2020-09-09 8:38 UTC (permalink / raw)
To: Gerald Schaefer
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <20200904195346.6d57ff9f@thinkpad>
On 09/04/2020 11:23 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 18:01:15 +0200
> Gerald Schaefer <gerald.schaefer@linux.ibm.com> wrote:
>
>> On Fri, 4 Sep 2020 17:26:47 +0200
>> Gerald Schaefer <gerald.schaefer@linux.ibm.com> wrote:
>>
>>> On Fri, 4 Sep 2020 12:18:05 +0530
>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>
>>>>
>>>>
>>>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
>>>>> This patch series includes fixes for debug_vm_pgtable test code so that
>>>>> they follow page table updates rules correctly. The first two patches introduce
>>>>> changes w.r.t ppc64. The patches are included in this series for completeness. We can
>>>>> merge them via ppc64 tree if required.
>>>>>
>>>>> Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
>>>>> page table update rules.
>>>>>
>>>>> These tests are broken w.r.t page table update rules and results in kernel
>>>>> crash as below.
>>>>>
>>>>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>>>> cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
>>>>> pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
>>>>> lr: c0000000005eeeec: pte_update+0x11c/0x190
>>>>> sp: c000000c6d1e7950
>>>>> msr: 8000000002029033
>>>>> current = 0xc000000c6d172c80
>>>>> paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
>>>>> pid = 1, comm = swapper/0
>>>>> kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>>>> [link register ] c0000000005eeeec pte_update+0x11c/0x190
>>>>> [c000000c6d1e7950] 0000000000000001 (unreliable)
>>>>> [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
>>>>> [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
>>>>> [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
>>>>> [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>>>> [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
>>>>> [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
>>>>> [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>>>
>>>>> With DEBUG_VM disabled
>>>>>
>>>>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
>>>>> [ 20.530183] Faulting instruction address: 0xc0000000000df330
>>>>> cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
>>>>> pc: c0000000000df330: memset+0x68/0x104
>>>>> lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>>>> sp: c000000c6d19f990
>>>>> msr: 8000000002009033
>>>>> dar: 0
>>>>> current = 0xc000000c6d177480
>>>>> paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
>>>>> pid = 1, comm = swapper/0
>>>>> [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>>>> [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
>>>>> [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
>>>>> [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
>>>>> [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>>>> [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
>>>>> [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
>>>>> [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>>>
>>>>> Changes from v3:
>>>>> * Address review feedback
>>>>> * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure.
>>>>
>>>> This version
>>>>
>>>> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE)
>>>> - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed
>>>> - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well
>>>
>>> When I quickly tested v3, it worked fine, but now it turned out to
>>> only work fine "sometimes", both v3 and v4. I need to look into it
>>> further, but so far it seems related to the hugetlb_advanced_tests().
>>>
>>> I guess there was already some discussion on this test, but we did
>>> not receive all of the thread(s). Please always add at least
>>> linux-s390@vger.kernel.org and maybe myself and Vasily Gorbik <gor@linux.ibm.com>
>>> for further discussions.
>>
>> BTW, with myself I mean the new address gerald.schaefer@linux.ibm.com.
>> The old gerald.schaefer@de.ibm.com seems to work (again), but is not
>> very reliable.
>>
>> 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
>> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, prot);
>> #endif
>>
>> spin_lock(&mm->page_table_lock);
>>
>> That would more match the "pte_t pointer" usage for hugetlb code,
>> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
>> but I think the root cause is the pte_t pointer.
>>
>> Not entirely sure though if that would really be the correct fix.
>> I somehow lost whatever little track I had about what these tests
>> really want to check, and if that would still be valid with that
>> change.
>
> Another potential issue, apparently not for s390, but maybe for
> others, is that the vaddr passed to hugetlb_advanced_tests() is
> also not pmd/pud size aligned, like you did in pmd/pud_advanced_tests().
>
> I guess for the hugetlb_advanced_tests() you need to choose if
> you want to test pmd or pud hugepages, and accordingly prepare
> the *ptep, pfn and vaddr input. If you only check for CONFIG_HUGETLB_PAGE,
> then probably only pmd hugepages would be safe, there might be
> architectures only supporting one hugepage size.
I guess preparing for PMD based HugeTLB tests should be sufficient
for now, which can be improved later on to cover other levels.
>
> So, for s390, at least the ptep input value is a problem. Still
> need to better understand how it goes wrong, but it seems to be
> fixed when using proper pmdp, and also works with pudp.
>
> For others, especially the apparent issues on ppc64, the other
> non-hugepage aligned input pfn and vaddr might also be an issue,
> e.g. power at least seems to use the vaddr in its set_huge_pte_at()
> implementation for some pmd_off(mm, addr) calculation.
>
> Again, sorry if this was already discussed, I missed most of it
> and honestly didn't properly look at the scarce mails that we did
> receive...
Sure, will consider these points and try improve tests afterwards.
^ permalink raw reply
* Re: [RFC PATCH v2 2/3] mm: make pXd_addr_end() functions page-table entry aware
From: Christophe Leroy @ 2020-09-09 8:38 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Peter Zijlstra, Catalin Marinas, Dave Hansen, linux-mm,
Paul Mackerras, linux-sparc, Claudio Imbrenda, Will Deacon,
linux-arch, linux-s390, Arnd Bergmann, Christian Borntraeger,
Richard Weinberger, linux-x86, Russell King, Jason Gunthorpe,
Ingo Molnar, Andrey Ryabinin, Gerald Schaefer, Jeff Dike,
Vasily Gorbik, John Hubbard, Heiko Carstens, linux-um,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner, linux-arm,
Linus Torvalds, LKML, Andrew Morton, linux-power, Mike Rapoport
In-Reply-To: <20200908141554.GA20558@oc3871087118.ibm.com>
On Tue, 2020-09-08 at 16:15 +0200, Alexander Gordeev wrote:
> 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 clarify a bit?
> > >
> > >
> > >diff --git a/arch/powerpc/mm/kasan/8xx.c b/arch/powerpc/mm/kasan/8xx.c
> > >index 2784224..89c5053 100644
> > >--- a/arch/powerpc/mm/kasan/8xx.c
> > >+++ b/arch/powerpc/mm/kasan/8xx.c
> > >@@ -15,8 +15,8 @@
> > > for (k_cur = k_start; k_cur != k_end; k_cur = k_next, pmd += 2, block += SZ_8M) {
> > > pte_basic_t *new;
> > >- k_next = pgd_addr_end(k_cur, k_end);
> > >- k_next = pgd_addr_end(k_next, k_end);
> > >+ k_next = pmd_addr_end(k_cur, k_end);
> > >+ k_next = pmd_addr_end(k_next, k_end);
> >
> > No, I don't think so.
> > On powerpc32 we have only two levels, so pgd and pmd are more or
> > less the same.
> > But pmd_addr_end() as defined in include/asm-generic/pgtable-nopmd.h
> > is a no-op, so I don't think it will work.
> >
> > It is likely that this function should iterate on pgd, then you get
> > pmd = pmd_offset(pud_offset(p4d_offset(pgd)));
>
> It looks like the code iterates over single pmd table while using
> pgd_addr_end() only to skip all the middle levels and bail out
> from the loop.
>
> I would be wary for switching from pmds to pgds, since we are
> trying to minimize impact (especially functional) and the
> rework does not seem that obvious.
>
I've just tested the following change, it works and should fix the
oddity:
diff --git a/arch/powerpc/mm/kasan/8xx.c b/arch/powerpc/mm/kasan/8xx.c
index 2784224054f8..8e53ddf57b84 100644
--- a/arch/powerpc/mm/kasan/8xx.c
+++ b/arch/powerpc/mm/kasan/8xx.c
@@ -9,11 +9,12 @@
static int __init
kasan_init_shadow_8M(unsigned long k_start, unsigned long k_end, void
*block)
{
- pmd_t *pmd = pmd_off_k(k_start);
+ pgd_t *pgd = pgd_offset_k(k_start);
unsigned long k_cur, k_next;
- for (k_cur = k_start; k_cur != k_end; k_cur = k_next, pmd += 2, block
+= SZ_8M) {
+ for (k_cur = k_start; k_cur != k_end; k_cur = k_next, pgd += 2, block
+= SZ_8M) {
pte_basic_t *new;
+ pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd, k_cur), k_cur),
k_cur);
k_next = pgd_addr_end(k_cur, k_end);
k_next = pgd_addr_end(k_next, k_end);
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c
b/arch/powerpc/mm/kasan/kasan_init_32.c
index fb294046e00e..e5f524fa71a7 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -30,13 +30,12 @@ static void __init kasan_populate_pte(pte_t *ptep,
pgprot_t prot)
int __init kasan_init_shadow_page_tables(unsigned long k_start,
unsigned long k_end)
{
- pmd_t *pmd;
+ pgd_t *pgd = pgd_offset_k(k_start);
unsigned long k_cur, k_next;
- pmd = pmd_off_k(k_start);
-
- for (k_cur = k_start; k_cur != k_end; k_cur = k_next, pmd++) {
+ for (k_cur = k_start; k_cur != k_end; k_cur = k_next, pgd++) {
pte_t *new;
+ pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd, k_cur), k_cur),
k_cur);
k_next = pgd_addr_end(k_cur, k_end);
if ((void *)pmd_page_vaddr(*pmd) != kasan_early_shadow_pte)
@@ -189,16 +188,18 @@ void __init kasan_early_init(void)
unsigned long addr = KASAN_SHADOW_START;
unsigned long end = KASAN_SHADOW_END;
unsigned long next;
- pmd_t *pmd = pmd_off_k(addr);
+ pgd_t *pgd = pgd_offset_k(addr);
BUILD_BUG_ON(KASAN_SHADOW_START & ~PGDIR_MASK);
kasan_populate_pte(kasan_early_shadow_pte, PAGE_KERNEL);
do {
+ pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd, addr), addr),
addr);
+
next = pgd_addr_end(addr, end);
pmd_populate_kernel(&init_mm, pmd, kasan_early_shadow_pte);
- } while (pmd++, addr = next, addr != end);
+ } while (pgd++, addr = next, addr != end);
if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE))
kasan_early_hash_table();
---
Christophe
^ permalink raw reply related
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Anshuman Khandual @ 2020-09-09 8:15 UTC (permalink / raw)
To: Gerald Schaefer
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <20200904180115.07ee5f00@thinkpad>
On 09/04/2020 09:31 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 17:26:47 +0200
> Gerald Schaefer <gerald.schaefer@linux.ibm.com> wrote:
>
>> On Fri, 4 Sep 2020 12:18:05 +0530
>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>
>>>
>>>
>>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
>>>> This patch series includes fixes for debug_vm_pgtable test code so that
>>>> they follow page table updates rules correctly. The first two patches introduce
>>>> changes w.r.t ppc64. The patches are included in this series for completeness. We can
>>>> merge them via ppc64 tree if required.
>>>>
>>>> Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
>>>> page table update rules.
>>>>
>>>> These tests are broken w.r.t page table update rules and results in kernel
>>>> crash as below.
>>>>
>>>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>>> cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
>>>> pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
>>>> lr: c0000000005eeeec: pte_update+0x11c/0x190
>>>> sp: c000000c6d1e7950
>>>> msr: 8000000002029033
>>>> current = 0xc000000c6d172c80
>>>> paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
>>>> pid = 1, comm = swapper/0
>>>> kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>>> [link register ] c0000000005eeeec pte_update+0x11c/0x190
>>>> [c000000c6d1e7950] 0000000000000001 (unreliable)
>>>> [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
>>>> [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
>>>> [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
>>>> [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>>> [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
>>>> [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
>>>> [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>>
>>>> With DEBUG_VM disabled
>>>>
>>>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
>>>> [ 20.530183] Faulting instruction address: 0xc0000000000df330
>>>> cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
>>>> pc: c0000000000df330: memset+0x68/0x104
>>>> lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>>> sp: c000000c6d19f990
>>>> msr: 8000000002009033
>>>> dar: 0
>>>> current = 0xc000000c6d177480
>>>> paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
>>>> pid = 1, comm = swapper/0
>>>> [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>>> [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
>>>> [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
>>>> [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
>>>> [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>>> [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
>>>> [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
>>>> [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>>
>>>> Changes from v3:
>>>> * Address review feedback
>>>> * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure.
>>>
>>> This version
>>>
>>> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE)
>>> - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed
>>> - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well
>>
>> When I quickly tested v3, it worked fine, but now it turned out to
>> only work fine "sometimes", both v3 and v4. I need to look into it
>> further, but so far it seems related to the hugetlb_advanced_tests().
>>
>> I guess there was already some discussion on this test, but we did
>> not receive all of the thread(s). Please always add at least
>> linux-s390@vger.kernel.org and maybe myself and Vasily Gorbik <gor@linux.ibm.com>
>> for further discussions.
>
> BTW, with myself I mean the new address gerald.schaefer@linux.ibm.com.
> The old gerald.schaefer@de.ibm.com seems to work (again), but is not
> very reliable.
Sure, noted.
>
> 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
> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, prot);
> #endif
>
> spin_lock(&mm->page_table_lock);
>
> That would more match the "pte_t pointer" usage for hugetlb code,
> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
> but I think the root cause is the pte_t pointer.
Ideally, the pte_t pointer used here should be from huge_pte_alloc()
not from pte_alloc_map_lock() as the case currently.
>
> Not entirely sure though if that would really be the correct fix.
> I somehow lost whatever little track I had about what these tests
> really want to check, and if that would still be valid with that
> change.
>
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Anshuman Khandual @ 2020-09-09 8:08 UTC (permalink / raw)
To: Gerald Schaefer
Cc: linux-s390@vger.kernel.org, Aneesh Kumar K.V, linux-mm,
Vineet Gupta, akpm, linux-snps-arc@lists.infradead.org,
linuxppc-dev, linux-riscv, Gerald Schaefer
In-Reply-To: <20200904172647.002113d3@thinkpad>
On 09/04/2020 08:56 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 12:18:05 +0530
> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>>
>>
>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
>>> This patch series includes fixes for debug_vm_pgtable test code so that
>>> they follow page table updates rules correctly. The first two patches introduce
>>> changes w.r.t ppc64. The patches are included in this series for completeness. We can
>>> merge them via ppc64 tree if required.
>>>
>>> Hugetlb test is disabled on ppc64 because that needs larger change to satisfy
>>> page table update rules.
>>>
>>> These tests are broken w.r.t page table update rules and results in kernel
>>> crash as below.
>>>
>>> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>> cpu 0x0: Vector: 700 (Program Check) at [c000000c6d1e76c0]
>>> pc: c00000000009a5ec: assert_pte_locked+0x14c/0x380
>>> lr: c0000000005eeeec: pte_update+0x11c/0x190
>>> sp: c000000c6d1e7950
>>> msr: 8000000002029033
>>> current = 0xc000000c6d172c80
>>> paca = 0xc000000003ba0000 irqmask: 0x03 irq_happened: 0x01
>>> pid = 1, comm = swapper/0
>>> kernel BUG at arch/powerpc/mm/pgtable.c:304!
>>> [link register ] c0000000005eeeec pte_update+0x11c/0x190
>>> [c000000c6d1e7950] 0000000000000001 (unreliable)
>>> [c000000c6d1e79b0] c0000000005eee14 pte_update+0x44/0x190
>>> [c000000c6d1e7a10] c000000001a2ca9c pte_advanced_tests+0x160/0x3d8
>>> [c000000c6d1e7ab0] c000000001a2d4fc debug_vm_pgtable+0x7e8/0x1338
>>> [c000000c6d1e7ba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>> [c000000c6d1e7c80] c0000000019e4fac kernel_init_freeable+0x4dc/0x5a4
>>> [c000000c6d1e7db0] c000000000012474 kernel_init+0x24/0x160
>>> [c000000c6d1e7e20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>
>>> With DEBUG_VM disabled
>>>
>>> [ 20.530152] BUG: Kernel NULL pointer dereference on read at 0x00000000
>>> [ 20.530183] Faulting instruction address: 0xc0000000000df330
>>> cpu 0x33: Vector: 380 (Data SLB Access) at [c000000c6d19f700]
>>> pc: c0000000000df330: memset+0x68/0x104
>>> lr: c00000000009f6d8: hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>> sp: c000000c6d19f990
>>> msr: 8000000002009033
>>> dar: 0
>>> current = 0xc000000c6d177480
>>> paca = 0xc00000001ec4f400 irqmask: 0x03 irq_happened: 0x01
>>> pid = 1, comm = swapper/0
>>> [link register ] c00000000009f6d8 hash__pmdp_huge_get_and_clear+0xe8/0x1b0
>>> [c000000c6d19f990] c00000000009f748 hash__pmdp_huge_get_and_clear+0x158/0x1b0 (unreliable)
>>> [c000000c6d19fa10] c0000000019ebf30 pmd_advanced_tests+0x1f0/0x378
>>> [c000000c6d19fab0] c0000000019ed088 debug_vm_pgtable+0x79c/0x1244
>>> [c000000c6d19fba0] c0000000000116ec do_one_initcall+0xac/0x5f0
>>> [c000000c6d19fc80] c0000000019a4fac kernel_init_freeable+0x4dc/0x5a4
>>> [c000000c6d19fdb0] c000000000012474 kernel_init+0x24/0x160
>>> [c000000c6d19fe20] c00000000000cbd0 ret_from_kernel_thread+0x5c/0x6c
>>>
>>> Changes from v3:
>>> * Address review feedback
>>> * Move page table depost and withdraw patch after adding pmdlock to avoid bisect failure.
>>
>> This version
>>
>> - Builds on x86, arm64, s390, arc, powerpc and riscv (defconfig with DEBUG_VM_PGTABLE)
>> - Runs on arm64 and x86 without any regression, atleast nothing that I have noticed
>> - Will be great if this could get tested on s390, arc, riscv, ppc32 platforms as well
>
> When I quickly tested v3, it worked fine, but now it turned out to
> only work fine "sometimes", both v3 and v4. I need to look into it
> further, but so far it seems related to the hugetlb_advanced_tests().
>
> I guess there was already some discussion on this test, but we did
> not receive all of the thread(s). Please always add at least
> linux-s390@vger.kernel.org and maybe myself and Vasily Gorbik <gor@linux.ibm.com>
> for further discussions.
IIRC, the V3 series previously had all these addresses copied properly
but this version once again missed copying all required addresses.
>
> That being said, sorry for duplications, this might already have been
> discussed. Preliminary analysis showed that it only seems to go wrong
> for certain random vaddr values. I cannot make any sense of that yet,
> but what seems strange to me is that the hugetlb_advanced_tests()
> take a (real) pte_t pointer as input, and also use that for all
> kinds of operations (set_huge_pte_at, huge_ptep_get_and_clear, etc.).
>
> Although all the hugetlb code in the kernel is (mis)using pte_t
> pointers instead of the correct pmd/pud_t pointers like THP, that
> is just for historic reasons. The pointers will actually never point
> to a real pte_t (i.e. page table entry), but of course to a pmd
> or pud entry, depending on hugepage size.
HugeTLB logically operates on a PTE entry irrespective of it's real
page table level position. Nonetheless, IIUC, vaddr here should have
been aligned to real page table level in which the entry is being
mapped currently.
>
> What is passed in as ptep to hugetlb_advanced_tests() seems to be
> the result from the previous ptep = pte_alloc_map(mm, pmdp, vaddr),
> so I would expect that it points to a real page table entry. Need
> to investigate further, but IIUC, using such a pointer for adding
> large pte entries (i.e. pmd/pud entries) at least feels very wrong
> to me, and I assume it is related to the issues we see on s390.
Will look into this further.
>
> We actually see different issues, e.g. once a panic directly in
> hugetlb_advanced_tests() -> huge_ptep_get_and_clear(), but also
> indirect symptoms after debug_vm_pgtable() completes, like this:
>
> [ 10.533901] BUG task_struct (Not tainted): Padding overwritten. 0x0000000019f798c7-0x0000000019f798c7 @offset=30087
>
> Last but not least, what I said about the pte vs. pmd/pud of
> course also should apply to the hugetlb_basic_tests(), although
> they are not directly using a pte_t pointer, and especially
> also not writing to it. Still, the pte_aligned pfn parameter
> is not guaranteed to also be pmd/pud_aligned, which doesn't
> feel right.
hugetlb_basic_tests() does not directly operate on real page table
entries. But I do see the point wrt using pmd_aligned pfn instead.
I will look into this in detail and send out something after this
series settles down.
>
> So, for now, until this is sorted out, I guess we also need
> to exclude s390 at least from the hugetlb_advanced_tests().
> The hugetlb_basic_tests() seem to work fine so far (probably
> by chance :-))
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-09 7:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
linux-acpi, xen-devel, Heiko Carstens, Len Brown, Nathan Lynch,
Vasily Gorbik, Leonardo Bras, Haiyang Zhang, Stephen Hemminger,
Dan Williams, Christian Borntraeger, Juergen Gross, Pankaj Gupta,
Libor Pechacek, linux-nvdimm, Rafael J. Wysocki, linux-kernel,
Wei Yang, Vishal Verma, Oliver O'Halloran, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200909071759.GD435421@kroah.com>
On 09.09.20 09:17, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>> We soon want to pass flags, e.g., to mark added System RAM resources.
>> mergeable. Prepare for that.
>
> What are these random "flags", and how do we know what should be passed
> to them?
>
> Why not make this an enumerated type so that we know it all works
> properly, like the GPF_* flags are? Passing around a random unsigned
> long feels very odd/broken...
Agreed, an enum (mhp_flags) seems to give a better hint what can
actually be passed. Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: Greg Kroah-Hartman @ 2020-09-09 7:17 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
linux-acpi, xen-devel, Heiko Carstens, Len Brown, Nathan Lynch,
Vasily Gorbik, Leonardo Bras, Haiyang Zhang, Stephen Hemminger,
Dan Williams, Christian Borntraeger, Juergen Gross, Pankaj Gupta,
Libor Pechacek, linux-nvdimm, Rafael J. Wysocki, linux-kernel,
Wei Yang, Vishal Verma, Oliver O'Halloran, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200908201012.44168-4-david@redhat.com>
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that we know it all works
properly, like the GPF_* flags are? Passing around a random unsigned
long feels very odd/broken...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification
From: Christophe Leroy @ 2020-09-09 6:20 UTC (permalink / raw)
To: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <871rjb5vv4.fsf@linux.ibm.com>
Le 09/09/2020 à 08:04, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>
>> 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 was generated.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> arch/powerpc/mm/fault.c | 20 +++++---------------
>> 1 file changed, 5 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index 525e0c2b5406..edde169ba3a6 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -214,24 +214,14 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code,
>> if (address >= TASK_SIZE)
>> return true;
>>
>> - if (!is_exec && (error_code & DSISR_PROTFAULT) &&
>> - !search_exception_tables(regs->nip)) {
>> + // Read/write fault blocked by KUAP is bad, it can never succeed.
>> + if (bad_kuap_fault(regs, address, is_write)) {
>> pr_crit_ratelimited("Kernel attempted to access user page (%lx) - exploit attempt? (uid: %d)\n",
>> - address,
>> - from_kuid(&init_user_ns, current_uid()));
>> - }
>> -
>> - // Fault on user outside of certain regions (eg. copy_tofrom_user()) is bad
>> - if (!search_exception_tables(regs->nip))
>> - return true;
>
> We still need to keep this ? Without that we detect the lack of
> exception tables pretty late.
Is that a problem at all to detect the lack of exception tables late ?
That case is very unlikely and will lead to failure anyway. So, is it
worth impacting performance of the likely case which will always have an
exception table and where we expect the exception to run as fast as
possible ?
The other architectures I have looked at (arm64 and x86) only have the
exception table search together with the down_read_trylock(&mm->mmap_sem).
Christophe
^ permalink raw reply
* Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
From: Alexey Kardashevskiy @ 2020-09-09 6:16 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman
Cc: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20200807101854.844619-1-clg@kaod.org>
On 07/08/2020 20:18, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still present, the RTAS call which isolates the PCI slot
> returns error 9001 "valid outstanding translations" and the removal of
> the IO adapter fails. This is because when the PHBs are scanned, Linux
> maps automatically the INTx interrupts in the Linux interrupt number
> space but these are never removed.
>
> To solve this problem, we introduce a PPC platform specific
> pcibios_remove_bus() routine which clears all interrupt mappings when
> the bus is removed. This also clears the associated page table entries
> of the ESB pages when using XIVE.
>
> For this purpose, we record the logical interrupt numbers of the
> mapped interrupt under the PHB structure and let pcibios_remove_bus()
> do the clean up.
>
> Since some PCI adapters, like GPUs, use the "interrupt-map" property
> to describe interrupt mappings other than the legacy INTx interrupts,
> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
> number of interrupt mappings is computed from the "interrupt-map"
> property and the mapping array is allocated accordingly.
>
> Cc: "Oliver O'Halloran" <oohall@gmail.com>
> Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
I thought we could reuse some of the common OF code for the DT parsing
but we cannot (easily) so it is good as it is:
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Changes since v2:
>
> - merged 2 patches.
>
> arch/powerpc/include/asm/pci-bridge.h | 6 ++
> arch/powerpc/kernel/pci-common.c | 114 ++++++++++++++++++++++++++
> 2 files changed, 120 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
> index b92e81b256e5..ca75cf264ddf 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -48,6 +48,9 @@ struct pci_controller_ops {
>
> /*
> * Structure of a PCI controller (host bridge)
> + *
> + * @irq_count: number of interrupt mappings
> + * @irq_map: interrupt mappings
> */
> struct pci_controller {
> struct pci_bus *bus;
> @@ -127,6 +130,9 @@ struct pci_controller {
>
> void *private_data;
> struct npu *npu;
> +
> + unsigned int irq_count;
> + unsigned int *irq_map;
> };
>
> /* These are used for config access before all the PCI probing
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index be108616a721..deb831f0ae13 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,115 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +/*
> + * Assumption is made on the interrupt parent. All interrupt-map
> + * entries are considered to have the same parent.
> + */
> +static int pcibios_irq_map_count(struct pci_controller *phb)
> +{
> + const __be32 *imap;
> + int imaplen;
> + struct device_node *parent;
> + u32 intsize, addrsize, parintsize, paraddrsize;
> +
> + if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
> + return 0;
> + if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
> + return 0;
> +
> + imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
> + if (!imap) {
> + pr_debug("%pOF : no interrupt-map\n", phb->dn);
> + return 0;
> + }
> + imaplen /= sizeof(u32);
> + pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
> +
> + if (imaplen < (addrsize + intsize + 1))
> + return 0;
> +
> + imap += intsize + addrsize;
> + parent = of_find_node_by_phandle(be32_to_cpup(imap));
> + if (!parent) {
> + pr_debug("%pOF : no imap parent found !\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
> + pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
> + paraddrsize = 0;
> +
> + return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
> +}
> +
> +static void pcibios_irq_map_init(struct pci_controller *phb)
> +{
> + phb->irq_count = pcibios_irq_map_count(phb);
> + if (phb->irq_count < PCI_NUM_INTX)
> + phb->irq_count = PCI_NUM_INTX;
> +
> + pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
> +
> + phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
> + GFP_KERNEL);
> +}
> +
> +static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
> +{
> + struct pci_controller *phb = pci_bus_to_host(pdev->bus);
> + int i;
> +
> + if (!phb->irq_map)
> + return;
> +
> + for (i = 0; i < phb->irq_count; i++) {
> + /*
> + * Look for an empty or an equivalent slot, as INTx
> + * interrupts can be shared between adapters.
> + */
> + if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
> + phb->irq_map[i] = virq;
> + break;
> + }
> + }
> +
> + if (i == phb->irq_count)
> + pr_err("PCI:%s all platform interrupts mapped\n",
> + pci_name(pdev));
> +}
> +
> +/*
> + * Clearing the mapped interrupts will also clear the underlying
> + * mappings of the ESB pages of the interrupts when under XIVE. It is
> + * a requirement of PowerVM to clear all memory mappings before
> + * removing a PHB.
> + */
> +static void pci_irq_map_dispose(struct pci_bus *bus)
> +{
> + struct pci_controller *phb = pci_bus_to_host(bus);
> + int i;
> +
> + if (!phb->irq_map)
> + return;
> +
> + pr_debug("PCI: Clearing interrupt mappings for PHB %04x:%02x...\n",
> + pci_domain_nr(bus), bus->number);
> + for (i = 0; i < phb->irq_count; i++)
> + irq_dispose_mapping(phb->irq_map[i]);
> +
> + kfree(phb->irq_map);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> + pci_irq_map_dispose(bus);
> +}
> +EXPORT_SYMBOL_GPL(pcibios_remove_bus);
> +
> /*
> * Reads the interrupt pin to determine if interrupt is use by card.
> * If the interrupt is used, then gets the interrupt line from the
> @@ -401,6 +510,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>
> pci_dev->irq = virq;
>
> + /* Record all interrut mappings for later removal of a PHB */
> + pci_irq_map_register(pci_dev, virq);
> return 0;
> }
>
> @@ -1554,6 +1665,9 @@ void pcibios_scan_phb(struct pci_controller *hose)
>
> pr_debug("PCI: Scanning PHB %pOF\n", node);
>
> + /* Allocate interrupt mappings array */
> + pcibios_irq_map_init(hose);
> +
> /* Get some IO space for the new PHB */
> pcibios_setup_phb_io_space(hose);
>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes
From: Aneesh Kumar K.V @ 2020-09-09 6:08 UTC (permalink / raw)
To: Gerald Schaefer, Anshuman Khandual
Cc: linux-s390@vger.kernel.org, linux-mm, Vineet Gupta, akpm,
linux-snps-arc@lists.infradead.org, linuxppc-dev, linux-riscv,
Gerald Schaefer
In-Reply-To: <20200908173906.30fffaa0@thinkpad>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> writes:
> On Fri, 4 Sep 2020 18:01:15 +0200
> Gerald Schaefer <gerald.schaefer@linux.ibm.com> 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
>> - hugetlb_advanced_tests(mm, vma, ptep, pte_aligned, vaddr, prot);
>> + hugetlb_advanced_tests(mm, vma, (pte_t *) pmdp, pmd_aligned, vaddr, prot);
>> #endif
>>
>> spin_lock(&mm->page_table_lock);
>>
>> That would more match the "pte_t pointer" usage for hugetlb code,
>> i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
>> but I think the root cause is the pte_t pointer.
>>
>> Not entirely sure though if that would really be the correct fix.
>> I somehow lost whatever little track I had about what these tests
>> really want to check, and if that would still be valid with that
>> change.
>
> Uh oh, wasn't aware that this (or some predecessor) already went
> upstream, and broke our debug kernel today.
Not sure i followed the above. Are you finding that s390 kernel crash
after this patch series or the original patchset? As noted in my patch
the hugetlb test is broken and we should fix that. A quick fix is to
comment out that test for s390 too as i have done for PPC64.
-aneesh
^ permalink raw reply
* Re: [PATCH v1 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification
From: Aneesh Kumar K.V @ 2020-09-09 6:04 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b07bac7a882c69deb9e6c8f234a68b3022f29072.1596734105.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> 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 was generated.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/fault.c | 20 +++++---------------
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 525e0c2b5406..edde169ba3a6 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -214,24 +214,14 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code,
> if (address >= TASK_SIZE)
> return true;
>
> - if (!is_exec && (error_code & DSISR_PROTFAULT) &&
> - !search_exception_tables(regs->nip)) {
> + // Read/write fault blocked by KUAP is bad, it can never succeed.
> + if (bad_kuap_fault(regs, address, is_write)) {
> pr_crit_ratelimited("Kernel attempted to access user page (%lx) - exploit attempt? (uid: %d)\n",
> - address,
> - from_kuid(&init_user_ns, current_uid()));
> - }
> -
> - // Fault on user outside of certain regions (eg. copy_tofrom_user()) is bad
> - if (!search_exception_tables(regs->nip))
> - return true;
We still need to keep this ? Without that we detect the lack of
exception tables pretty late.
> -
> - // Read/write fault in a valid region (the exception table search passed
> - // above), but blocked by KUAP is bad, it can never succeed.
> - if (bad_kuap_fault(regs, address, is_write))
> + address, from_kuid(&init_user_ns, current_uid()));
> return true;
> + }
>
> - // What's left? Kernel fault on user in well defined regions (extable
> - // matched), and allowed by KUAP in the faulting context.
> + // What's left? Kernel fault on user and allowed by KUAP in the faulting context.
> return false;
> }
>
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: Jürgen Groß @ 2020-09-09 5:18 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, linux-nvdimm,
Jason Gunthorpe, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Pankaj Gupta, Libor Pechacek, Greg Kroah-Hartman,
Rafael J. Wysocki, Wei Yang, Vishal Verma, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <20200908201012.44168-4-david@redhat.com>
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-osalvador@suse.de
>
> Acked-by: Wei Liu <wei.liu@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Wei Yang <richardw.yang@linux.intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Dave Jiang <dave.jiang@intel.com>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: "Oliver O'Halloran" <oohall@gmail.com>
> Cc: Pingfan Liu <kernelfans@gmail.com>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Cc: Libor Pechacek <lpechacek@suse.cz>
> Cc: Anton Blanchard <anton@ozlabs.org>
> Cc: Leonardo Bras <leobras.c@gmail.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-acpi@vger.kernel.org
> Cc: linux-nvdimm@lists.01.org
> Cc: linux-hyperv@vger.kernel.org
> Cc: linux-s390@vger.kernel.org
> Cc: virtualization@lists.linux-foundation.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com> (Xen related part)
Juergen
> ---
> arch/powerpc/platforms/powernv/memtrace.c | 2 +-
> arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
> drivers/acpi/acpi_memhotplug.c | 2 +-
> drivers/base/memory.c | 2 +-
> drivers/dax/kmem.c | 2 +-
> drivers/hv/hv_balloon.c | 2 +-
> drivers/s390/char/sclp_cmd.c | 2 +-
> drivers/virtio/virtio_mem.c | 2 +-
> drivers/xen/balloon.c | 2 +-
> include/linux/memory_hotplug.h | 10 ++++++----
> mm/memory_hotplug.c | 15 ++++++++-------
> 11 files changed, 23 insertions(+), 20 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
> index 13b369d2cc454..a7475d18c671c 100644
> --- a/arch/powerpc/platforms/powernv/memtrace.c
> +++ b/arch/powerpc/platforms/powernv/memtrace.c
> @@ -224,7 +224,7 @@ static int memtrace_online(void)
> ent->mem = 0;
> }
>
> - if (add_memory(ent->nid, ent->start, ent->size)) {
> + if (add_memory(ent->nid, ent->start, ent->size, 0)) {
> pr_err("Failed to add trace memory to node %d\n",
> ent->nid);
> ret += 1;
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 5d545b78111f9..54a888ea7f751 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -606,7 +606,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
> block_sz = memory_block_size_bytes();
>
> /* Add the memory */
> - rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
> + rc = __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
> if (rc) {
> invalidate_lmb_associativity_index(lmb);
> return rc;
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index e294f44a78504..d91b3584d4b2b 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
> if (node < 0)
> node = memory_add_physaddr_to_nid(info->start_addr);
>
> - result = __add_memory(node, info->start_addr, info->length);
> + result = __add_memory(node, info->start_addr, info->length, 0);
>
> /*
> * If the memory block has been used by the kernel, add_memory()
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 4db3c660de831..2287bcf86480e 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct device_attribute *attr,
>
> nid = memory_add_physaddr_to_nid(phys_addr);
> ret = __add_memory(nid, phys_addr,
> - MIN_MEMORY_BLOCK_SIZE * sections_per_block);
> + MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
>
> if (ret)
> goto out;
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 7dcb2902e9b1b..8e66b28ef5bc6 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
> @@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax)
> * this as RAM automatically.
> */
> rc = add_memory_driver_managed(numa_node, range.start,
> - range_len(&range), kmem_name);
> + range_len(&range), kmem_name, 0);
>
> res->flags |= IORESOURCE_BUSY;
> if (rc) {
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 32e3bc0aa665a..0194bed1a5736 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
>
> nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
> ret = add_memory(nid, PFN_PHYS((start_pfn)),
> - (HA_CHUNK << PAGE_SHIFT));
> + (HA_CHUNK << PAGE_SHIFT), 0);
>
> if (ret) {
> pr_err("hot_add memory failed error is %d\n", ret);
> diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
> index a864b21af602a..a6a908244c742 100644
> --- a/drivers/s390/char/sclp_cmd.c
> +++ b/drivers/s390/char/sclp_cmd.c
> @@ -406,7 +406,7 @@ static void __init add_memory_merged(u16 rn)
> if (!size)
> goto skip_add;
> for (addr = start; addr < start + size; addr += block_size)
> - add_memory(0, addr, block_size);
> + add_memory(0, addr, block_size, 0);
> skip_add:
> first_rn = rn;
> num = 1;
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 834b7c13ef3dc..314ab753139d1 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -424,7 +424,7 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, unsigned long mb_id)
>
> dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id);
> return add_memory_driver_managed(nid, addr, memory_block_size_bytes(),
> - vm->resource_name);
> + vm->resource_name, 0);
> }
>
> /*
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 51427c752b37b..7bac38764513d 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void)
> mutex_unlock(&balloon_mutex);
> /* add_memory_resource() requires the device_hotplug lock */
> lock_device_hotplug();
> - rc = add_memory_resource(nid, resource);
> + rc = add_memory_resource(nid, resource, 0);
> unlock_device_hotplug();
> mutex_lock(&balloon_mutex);
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 51a877fec8da8..5cd48332ce119 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -345,11 +345,13 @@ extern void set_zone_contiguous(struct zone *zone);
> extern void clear_zone_contiguous(struct zone *zone);
>
> extern void __ref free_area_init_core_hotplug(int nid);
> -extern int __add_memory(int nid, u64 start, u64 size);
> -extern int add_memory(int nid, u64 start, u64 size);
> -extern int add_memory_resource(int nid, struct resource *resource);
> +extern int __add_memory(int nid, u64 start, u64 size, unsigned long flags);
> +extern int add_memory(int nid, u64 start, u64 size, unsigned long flags);
> +extern int add_memory_resource(int nid, struct resource *resource,
> + unsigned long flags);
> extern int add_memory_driver_managed(int nid, u64 start, u64 size,
> - const char *resource_name);
> + const char *resource_name,
> + unsigned long flags);
> extern void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
> unsigned long nr_pages,
> struct vmem_altmap *altmap, int migratetype);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 8e1cd18b5cf14..64b07f006bc10 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1039,7 +1039,8 @@ static int online_memory_block(struct memory_block *mem, void *arg)
> *
> * we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG
> */
> -int __ref add_memory_resource(int nid, struct resource *res)
> +int __ref add_memory_resource(int nid, struct resource *res,
> + unsigned long flags)
> {
> struct mhp_params params = { .pgprot = PAGE_KERNEL };
> u64 start, size;
> @@ -1118,7 +1119,7 @@ int __ref add_memory_resource(int nid, struct resource *res)
> }
>
> /* requires device_hotplug_lock, see add_memory_resource() */
> -int __ref __add_memory(int nid, u64 start, u64 size)
> +int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags)
> {
> struct resource *res;
> int ret;
> @@ -1127,18 +1128,18 @@ int __ref __add_memory(int nid, u64 start, u64 size)
> if (IS_ERR(res))
> return PTR_ERR(res);
>
> - ret = add_memory_resource(nid, res);
> + ret = add_memory_resource(nid, res, flags);
> if (ret < 0)
> release_memory_resource(res);
> return ret;
> }
>
> -int add_memory(int nid, u64 start, u64 size)
> +int add_memory(int nid, u64 start, u64 size, unsigned long flags)
> {
> int rc;
>
> lock_device_hotplug();
> - rc = __add_memory(nid, start, size);
> + rc = __add_memory(nid, start, size, flags);
> unlock_device_hotplug();
>
> return rc;
> @@ -1167,7 +1168,7 @@ EXPORT_SYMBOL_GPL(add_memory);
> * "System RAM ($DRIVER)".
> */
> int add_memory_driver_managed(int nid, u64 start, u64 size,
> - const char *resource_name)
> + const char *resource_name, unsigned long flags)
> {
> struct resource *res;
> int rc;
> @@ -1185,7 +1186,7 @@ int add_memory_driver_managed(int nid, u64 start, u64 size,
> goto out_unlock;
> }
>
> - rc = add_memory_resource(nid, res);
> + rc = add_memory_resource(nid, res, flags);
> if (rc < 0)
> release_memory_resource(res);
>
>
^ permalink raw reply
* Re: [PATCH v2] kbuild: preprocess module linker script
From: Palmer Dabbelt @ 2020-09-09 4:27 UTC (permalink / raw)
To: masahiroy
Cc: linux-ia64, catalin.marinas, paulus, linux-riscv, will,
anton.ivanov, linux-arch, richard, masahiroy, linux, geert,
fenghua.yu, aou, Arnd Bergmann, linux-kbuild, jdike, jeyu,
linux-um, linux-m68k, michal.lkml, Paul Walmsley,
linux-arm-kernel, tony.luck, linux-kernel, linuxppc-dev
In-Reply-To: <20200908042708.2511528-1-masahiroy@kernel.org>
On Mon, 07 Sep 2020 21:27:08 PDT (-0700), masahiroy@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 module builds, thus must be cleaned up by
> 'make mrproper' instead of 'make clean'. Also, it must be created
> by 'make modules_prepare'.
>
> You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
> 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
> arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
> scripts/module.lds.S.
>
> scripts/module.lds is fine because 'make clean' keeps all the
> build artifacts under scripts/.
>
> You can add arch-specific sections in <asm/module.lds.h>.
for the arch/riscv stuff
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Thanks!
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Tested-by: Jessica Yu <jeyu@kernel.org>
> Acked-by: Will Deacon <will@kernel.org>
> ---
>
> Changes in v2:
> - Fix the race between the two targets 'scripts' and 'asm-generic'
>
> Makefile | 10 ++++++----
> arch/arm/Makefile | 4 ----
> .../{kernel/module.lds => include/asm/module.lds.h} | 2 ++
> arch/arm64/Makefile | 4 ----
> .../{kernel/module.lds => include/asm/module.lds.h} | 2 ++
> arch/ia64/Makefile | 1 -
> arch/ia64/{module.lds => include/asm/module.lds.h} | 0
> arch/m68k/Makefile | 1 -
> .../{kernel/module.lds => include/asm/module.lds.h} | 0
> arch/powerpc/Makefile | 1 -
> .../{kernel/module.lds => include/asm/module.lds.h} | 0
> arch/riscv/Makefile | 3 ---
> .../{kernel/module.lds => include/asm/module.lds.h} | 3 ++-
> arch/um/include/asm/Kbuild | 1 +
> include/asm-generic/Kbuild | 1 +
> include/asm-generic/module.lds.h | 10 ++++++++++
> scripts/.gitignore | 1 +
> scripts/Makefile | 3 +++
> scripts/Makefile.modfinal | 5 ++---
> scripts/{module-common.lds => module.lds.S} | 3 +++
> scripts/package/builddeb | 2 +-
> 21 files changed, 34 insertions(+), 23 deletions(-)
> rename arch/arm/{kernel/module.lds => include/asm/module.lds.h} (72%)
> rename arch/arm64/{kernel/module.lds => include/asm/module.lds.h} (76%)
> rename arch/ia64/{module.lds => include/asm/module.lds.h} (100%)
> rename arch/m68k/{kernel/module.lds => include/asm/module.lds.h} (100%)
> rename arch/powerpc/{kernel/module.lds => include/asm/module.lds.h} (100%)
> rename arch/riscv/{kernel/module.lds => include/asm/module.lds.h} (84%)
> create mode 100644 include/asm-generic/module.lds.h
> rename scripts/{module-common.lds => module.lds.S} (93%)
>
> diff --git a/Makefile b/Makefile
> index 37739ee53f27..97b1dae1783b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -505,7 +505,6 @@ KBUILD_CFLAGS_KERNEL :=
> KBUILD_AFLAGS_MODULE := -DMODULE
> KBUILD_CFLAGS_MODULE := -DMODULE
> KBUILD_LDFLAGS_MODULE :=
> -export KBUILD_LDS_MODULE := $(srctree)/scripts/module-common.lds
> KBUILD_LDFLAGS :=
> CLANG_FLAGS :=
>
> @@ -1395,7 +1394,7 @@ endif
> # using awk while concatenating to the final file.
>
> PHONY += modules
> -modules: $(if $(KBUILD_BUILTIN),vmlinux) modules_check
> +modules: $(if $(KBUILD_BUILTIN),vmlinux) modules_check modules_prepare
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
>
> PHONY += modules_check
> @@ -1412,6 +1411,7 @@ targets += modules.order
> # Target to prepare building external modules
> PHONY += modules_prepare
> modules_prepare: prepare
> + $(Q)$(MAKE) $(build)=scripts scripts/module.lds
>
> # Target to install modules
> PHONY += modules_install
> @@ -1743,7 +1743,9 @@ help:
> @echo ' clean - remove generated files in module directory only'
> @echo ''
>
> -PHONY += prepare
> +# no-op for external module builds
> +PHONY += prepare modules_prepare
> +
> endif # KBUILD_EXTMOD
>
> # Single targets
> @@ -1776,7 +1778,7 @@ MODORDER := .modules.tmp
> endif
>
> PHONY += single_modpost
> -single_modpost: $(single-no-ko)
> +single_modpost: $(single-no-ko) modules_prepare
> $(Q){ $(foreach m, $(single-ko), echo $(extmod-prefix)$m;) } > $(MODORDER)
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 4e877354515f..a0cb15de9677 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -16,10 +16,6 @@ LDFLAGS_vmlinux += --be8
> KBUILD_LDFLAGS_MODULE += --be8
> endif
>
> -ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> -KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
> -endif
> -
> GZFLAGS :=-9
> #KBUILD_CFLAGS +=-pipe
>
> diff --git a/arch/arm/kernel/module.lds b/arch/arm/include/asm/module.lds.h
> similarity index 72%
> rename from arch/arm/kernel/module.lds
> rename to arch/arm/include/asm/module.lds.h
> index 79cb6af565e5..0e7cb4e314b4 100644
> --- a/arch/arm/kernel/module.lds
> +++ b/arch/arm/include/asm/module.lds.h
> @@ -1,5 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> +#ifdef CONFIG_ARM_MODULE_PLTS
> SECTIONS {
> .plt : { BYTE(0) }
> .init.plt : { BYTE(0) }
> }
> +#endif
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index b45f0124cc16..76667ad47980 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -115,10 +115,6 @@ endif
>
> CHECKFLAGS += -D__aarch64__
>
> -ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
> -KBUILD_LDS_MODULE += $(srctree)/arch/arm64/kernel/module.lds
> -endif
> -
> ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
> KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
> CC_FLAGS_FTRACE := -fpatchable-function-entry=2
> diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/include/asm/module.lds.h
> similarity index 76%
> rename from arch/arm64/kernel/module.lds
> rename to arch/arm64/include/asm/module.lds.h
> index 22e36a21c113..691f15af788e 100644
> --- a/arch/arm64/kernel/module.lds
> +++ b/arch/arm64/include/asm/module.lds.h
> @@ -1,5 +1,7 @@
> +#ifdef CONFIG_ARM64_MODULE_PLTS
> SECTIONS {
> .plt (NOLOAD) : { BYTE(0) }
> .init.plt (NOLOAD) : { BYTE(0) }
> .text.ftrace_trampoline (NOLOAD) : { BYTE(0) }
> }
> +#endif
> diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
> index 2876a7df1b0a..703b1c4f6d12 100644
> --- a/arch/ia64/Makefile
> +++ b/arch/ia64/Makefile
> @@ -20,7 +20,6 @@ CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
>
> OBJCOPYFLAGS := --strip-all
> LDFLAGS_vmlinux := -static
> -KBUILD_LDS_MODULE += $(srctree)/arch/ia64/module.lds
> KBUILD_AFLAGS_KERNEL := -mconstant-gp
> EXTRA :=
>
> diff --git a/arch/ia64/module.lds b/arch/ia64/include/asm/module.lds.h
> similarity index 100%
> rename from arch/ia64/module.lds
> rename to arch/ia64/include/asm/module.lds.h
> diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
> index 4438ffb4bbe1..ea14f2046fb4 100644
> --- a/arch/m68k/Makefile
> +++ b/arch/m68k/Makefile
> @@ -75,7 +75,6 @@ KBUILD_CPPFLAGS += -D__uClinux__
> endif
>
> KBUILD_LDFLAGS := -m m68kelf
> -KBUILD_LDS_MODULE += $(srctree)/arch/m68k/kernel/module.lds
>
> ifdef CONFIG_SUN3
> LDFLAGS_vmlinux = -N
> diff --git a/arch/m68k/kernel/module.lds b/arch/m68k/include/asm/module.lds.h
> similarity index 100%
> rename from arch/m68k/kernel/module.lds
> rename to arch/m68k/include/asm/module.lds.h
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 3e8da9cf2eb9..8935658fcd06 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -65,7 +65,6 @@ UTS_MACHINE := $(subst $(space),,$(machine-y))
> ifdef CONFIG_PPC32
> KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> else
> -KBUILD_LDS_MODULE += $(srctree)/arch/powerpc/kernel/module.lds
> ifeq ($(call ld-ifversion, -ge, 225000000, y),y)
> # Have the linker provide sfpr if possible.
> # There is a corresponding test in arch/powerpc/lib/Makefile
> diff --git a/arch/powerpc/kernel/module.lds b/arch/powerpc/include/asm/module.lds.h
> similarity index 100%
> rename from arch/powerpc/kernel/module.lds
> rename to arch/powerpc/include/asm/module.lds.h
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index fb6e37db836d..8edaa8bd86d6 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -53,9 +53,6 @@ endif
> ifeq ($(CONFIG_CMODEL_MEDANY),y)
> KBUILD_CFLAGS += -mcmodel=medany
> endif
> -ifeq ($(CONFIG_MODULE_SECTIONS),y)
> - KBUILD_LDS_MODULE += $(srctree)/arch/riscv/kernel/module.lds
> -endif
> ifeq ($(CONFIG_PERF_EVENTS),y)
> KBUILD_CFLAGS += -fno-omit-frame-pointer
> endif
> diff --git a/arch/riscv/kernel/module.lds b/arch/riscv/include/asm/module.lds.h
> similarity index 84%
> rename from arch/riscv/kernel/module.lds
> rename to arch/riscv/include/asm/module.lds.h
> index 295ecfb341a2..4254ff2ff049 100644
> --- a/arch/riscv/kernel/module.lds
> +++ b/arch/riscv/include/asm/module.lds.h
> @@ -1,8 +1,9 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> /* Copyright (C) 2017 Andes Technology Corporation */
> -
> +#ifdef CONFIG_MODULE_SECTIONS
> SECTIONS {
> .plt (NOLOAD) : { BYTE(0) }
> .got (NOLOAD) : { BYTE(0) }
> .got.plt (NOLOAD) : { BYTE(0) }
> }
> +#endif
> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
> index 8d435f8a6dec..1c63b260ecc4 100644
> --- a/arch/um/include/asm/Kbuild
> +++ b/arch/um/include/asm/Kbuild
> @@ -16,6 +16,7 @@ generic-y += kdebug.h
> generic-y += mcs_spinlock.h
> generic-y += mm-arch-hooks.h
> generic-y += mmiowb.h
> +generic-y += module.lds.h
> generic-y += param.h
> generic-y += pci.h
> generic-y += percpu.h
> diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
> index 74b0612601dd..7cd4e627e00e 100644
> --- a/include/asm-generic/Kbuild
> +++ b/include/asm-generic/Kbuild
> @@ -40,6 +40,7 @@ mandatory-y += mmiowb.h
> mandatory-y += mmu.h
> mandatory-y += mmu_context.h
> mandatory-y += module.h
> +mandatory-y += module.lds.h
> mandatory-y += msi.h
> mandatory-y += pci.h
> mandatory-y += percpu.h
> diff --git a/include/asm-generic/module.lds.h b/include/asm-generic/module.lds.h
> new file mode 100644
> index 000000000000..f210d5c1b78b
> --- /dev/null
> +++ b/include/asm-generic/module.lds.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_MODULE_LDS_H
> +#define __ASM_GENERIC_MODULE_LDS_H
> +
> +/*
> + * <asm/module.lds.h> can specify arch-specific sections for linking modules.
> + * Empty for the asm-generic header.
> + */
> +
> +#endif /* __ASM_GENERIC_MODULE_LDS_H */
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 0d1c8e217cd7..a6c11316c969 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -8,3 +8,4 @@ asn1_compiler
> extract-cert
> sign-file
> insert-sys-cert
> +/module.lds
> diff --git a/scripts/Makefile b/scripts/Makefile
> index bc018e4b733e..b5418ec587fb 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -29,6 +29,9 @@ endif
> # The following programs are only built on demand
> hostprogs += unifdef
>
> +# The module linker script is preprocessed on demand
> +targets += module.lds
> +
> subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
> subdir-$(CONFIG_MODVERSIONS) += genksyms
> subdir-$(CONFIG_SECURITY_SELINUX) += selinux
> diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> index 411c1e600e7d..ae01baf96f4e 100644
> --- a/scripts/Makefile.modfinal
> +++ b/scripts/Makefile.modfinal
> @@ -33,11 +33,10 @@ quiet_cmd_ld_ko_o = LD [M] $@
> cmd_ld_ko_o = \
> $(LD) -r $(KBUILD_LDFLAGS) \
> $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
> - $(addprefix -T , $(KBUILD_LDS_MODULE)) \
> - -o $@ $(filter %.o, $^); \
> + -T scripts/module.lds -o $@ $(filter %.o, $^); \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> -$(modules): %.ko: %.o %.mod.o $(KBUILD_LDS_MODULE) FORCE
> +$(modules): %.ko: %.o %.mod.o scripts/module.lds FORCE
> +$(call if_changed,ld_ko_o)
>
> targets += $(modules) $(modules:.ko=.mod.o)
> diff --git a/scripts/module-common.lds b/scripts/module.lds.S
> similarity index 93%
> rename from scripts/module-common.lds
> rename to scripts/module.lds.S
> index d61b9e8678e8..69b9b71a6a47 100644
> --- a/scripts/module-common.lds
> +++ b/scripts/module.lds.S
> @@ -24,3 +24,6 @@ SECTIONS {
>
> __jump_table 0 : ALIGN(8) { KEEP(*(__jump_table)) }
> }
> +
> +/* bring in arch-specific sections */
> +#include <asm/module.lds.h>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 6df3c9f8b2da..44f212e37935 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -55,7 +55,7 @@ deploy_kernel_headers () {
> cd $srctree
> find . arch/$SRCARCH -maxdepth 1 -name Makefile\*
> find include scripts -type f -o -type l
> - find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms -o -name Platform
> + find arch/$SRCARCH -name Kbuild.platforms -o -name Platform
> find $(find arch/$SRCARCH -name include -o -name scripts -type d) -type f
> ) > debian/hdrsrcfiles
^ permalink raw reply
* Re: [PATCH 00/29] treewide: Convert comma separated statements
From: Martin K. Petersen @ 2020-09-09 2:09 UTC (permalink / raw)
To: linuxppc-dev, linux-ide, dri-devel, linux-hwmon, Joe Perches,
oprofile-list, linux-fsdevel, linux-media, linaro-mm-sig,
drbd-dev, intel-gfx, linux-arm-kernel, linux-input, linux-nfs,
netdev, reiserfs-devel, linux-bcache, Jiri Kosina
Cc: devel, linux-s390, linux-fbdev, linux-ia64, linux-scsi,
Martin K . Petersen, linux-doc, linux-pm, linux-kernel,
linux-block, linux-mtd, linux-kselftest, linux-alpha, sparclinux
In-Reply-To: <cover.1598331148.git.joe@perches.com>
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 semicolons.
>
> Many comma separated statements still exist but those are changes for
> another day.
>
> [...]
Applied to 5.10/scsi-queue, thanks!
[01/29] coding-style.rst: Avoid comma statements
(no commit info)
[02/29] alpha: Avoid comma separated statements
(no commit info)
[03/29] ia64: Avoid comma separated statements
(no commit info)
[04/29] sparc: Avoid comma separated statements
(no commit info)
[05/29] ata: Avoid comma separated statements
(no commit info)
[06/29] drbd: Avoid comma separated statements
(no commit info)
[07/29] lp: Avoid comma separated statements
(no commit info)
[08/29] dma-buf: Avoid comma separated statements
(no commit info)
[09/29] drm/gma500: Avoid comma separated statements
(no commit info)
[10/29] drm/i915: Avoid comma separated statements
(no commit info)
[11/29] hwmon: (scmi-hwmon): Avoid comma separated statements
(no commit info)
[12/29] Input: MT - Avoid comma separated statements
(no commit info)
[13/29] bcache: Avoid comma separated statements
(no commit info)
[14/29] media: Avoid comma separated statements
(no commit info)
[15/29] mtd: Avoid comma separated statements
(no commit info)
[16/29] 8390: Avoid comma separated statements
(no commit info)
[17/29] fs_enet: Avoid comma separated statements
(no commit info)
[18/29] wan: sbni: Avoid comma separated statements
(no commit info)
[19/29] s390/tty3270: Avoid comma separated statements
(no commit info)
[20/29] scsi: arm: Avoid comma separated statements
https://git.kernel.org/mkp/scsi/c/a08a07326510
[21/29] media: atomisp: Avoid comma separated statements
(no commit info)
[22/29] video: fbdev: Avoid comma separated statements
(no commit info)
[23/29] fuse: Avoid comma separated statements
(no commit info)
[24/29] reiserfs: Avoid comma separated statements
(no commit info)
[25/29] lib/zlib: Avoid comma separated statements
(no commit info)
[26/29] lib: zstd: Avoid comma separated statements
(no commit info)
[27/29] ipv6: fib6: Avoid comma separated statements
(no commit info)
[28/29] sunrpc: Avoid comma separated statements
(no commit info)
[29/29] tools: Avoid comma separated statements
(no commit info)
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 1caa0de62d8cfeb6874fba2a6af5fbe67ebfca70
From: kernel test robot @ 2020-09-09 2:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 1caa0de62d8cfeb6874fba2a6af5fbe67ebfca70 powerpc/64: Make VDSO32 track COMPAT on 64-bit
elapsed time: 744m
configs tested: 157
configs skipped: 13
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
parisc defconfig
powerpc mvme5100_defconfig
sh microdev_defconfig
c6x dsk6455_defconfig
powerpc allmodconfig
arm omap2plus_defconfig
powerpc adder875_defconfig
mips ar7_defconfig
arm omap1_defconfig
sh se7619_defconfig
mips malta_qemu_32r6_defconfig
powerpc ep8248e_defconfig
xtensa defconfig
arm pxa910_defconfig
arm spear3xx_defconfig
mips malta_kvm_guest_defconfig
m68k m5407c3_defconfig
c6x allyesconfig
mips gpr_defconfig
sh se7780_defconfig
powerpc allnoconfig
c6x evmc6457_defconfig
m68k q40_defconfig
sparc allyesconfig
sh sh7763rdp_defconfig
arm zeus_defconfig
sh se7705_defconfig
riscv nommu_k210_defconfig
arm spear13xx_defconfig
arc haps_hs_smp_defconfig
m68k m5275evb_defconfig
h8300 defconfig
c6x evmc6474_defconfig
mips sb1250_swarm_defconfig
mips tb0287_defconfig
riscv alldefconfig
m68k amcore_defconfig
arm h5000_defconfig
sh lboxre2_defconfig
arm qcom_defconfig
sh sh7724_generic_defconfig
mips loongson1b_defconfig
parisc generic-32bit_defconfig
arm spear6xx_defconfig
ia64 tiger_defconfig
microblaze mmu_defconfig
powerpc mpc512x_defconfig
arm collie_defconfig
arm hackkit_defconfig
powerpc linkstation_defconfig
arm footbridge_defconfig
mips bmips_stb_defconfig
arm rpc_defconfig
mips nlm_xlr_defconfig
m68k stmark2_defconfig
h8300 alldefconfig
sh sh7785lcr_defconfig
arc axs103_defconfig
xtensa allyesconfig
s390 debug_defconfig
c6x evmc6678_defconfig
arm shannon_defconfig
arm pleb_defconfig
arc axs101_defconfig
nios2 allyesconfig
sh apsh4ad0a_defconfig
c6x evmc6472_defconfig
riscv rv32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
x86_64 randconfig-a006-20200907
x86_64 randconfig-a004-20200907
x86_64 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-20200908
i386 randconfig-a002-20200908
i386 randconfig-a001-20200908
i386 randconfig-a003-20200908
i386 randconfig-a004-20200907
i386 randconfig-a005-20200907
i386 randconfig-a006-20200907
i386 randconfig-a002-20200907
i386 randconfig-a003-20200907
i386 randconfig-a001-20200907
x86_64 randconfig-a013-20200908
x86_64 randconfig-a016-20200908
x86_64 randconfig-a011-20200908
x86_64 randconfig-a012-20200908
x86_64 randconfig-a015-20200908
x86_64 randconfig-a014-20200908
i386 randconfig-a016-20200907
i386 randconfig-a015-20200907
i386 randconfig-a011-20200907
i386 randconfig-a013-20200907
i386 randconfig-a014-20200907
i386 randconfig-a012-20200907
i386 randconfig-a016-20200908
i386 randconfig-a015-20200908
i386 randconfig-a011-20200908
i386 randconfig-a013-20200908
i386 randconfig-a014-20200908
i386 randconfig-a012-20200908
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20200908
x86_64 randconfig-a006-20200908
x86_64 randconfig-a003-20200908
x86_64 randconfig-a001-20200908
x86_64 randconfig-a005-20200908
x86_64 randconfig-a002-20200908
x86_64 randconfig-a013-20200907
x86_64 randconfig-a011-20200907
x86_64 randconfig-a016-20200907
x86_64 randconfig-a012-20200907
x86_64 randconfig-a015-20200907
x86_64 randconfig-a014-20200907
---
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 dc462267d2d7aacffc3c1d99b02d7a7c59db7c66
From: kernel test robot @ 2020-09-09 2:05 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: dc462267d2d7aacffc3c1d99b02d7a7c59db7c66 powerpc/64s: handle ISA v3.1 local copy-paste context switches
elapsed time: 744m
configs tested: 151
configs skipped: 12
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
parisc defconfig
powerpc mvme5100_defconfig
sh microdev_defconfig
c6x dsk6455_defconfig
powerpc allmodconfig
arm omap2plus_defconfig
powerpc adder875_defconfig
mips ar7_defconfig
arm omap1_defconfig
sh se7619_defconfig
mips malta_qemu_32r6_defconfig
powerpc ep8248e_defconfig
xtensa defconfig
arm pxa910_defconfig
arm spear3xx_defconfig
mips malta_kvm_guest_defconfig
m68k m5407c3_defconfig
c6x allyesconfig
mips gpr_defconfig
sh se7780_defconfig
powerpc allnoconfig
c6x evmc6457_defconfig
m68k q40_defconfig
sparc allyesconfig
sh sh7763rdp_defconfig
arm zeus_defconfig
sh se7705_defconfig
riscv nommu_k210_defconfig
arm spear13xx_defconfig
arc haps_hs_smp_defconfig
m68k m5275evb_defconfig
h8300 defconfig
c6x evmc6474_defconfig
mips sb1250_swarm_defconfig
arm qcom_defconfig
sh sh7724_generic_defconfig
mips loongson1b_defconfig
parisc generic-32bit_defconfig
arm spear6xx_defconfig
ia64 tiger_defconfig
microblaze mmu_defconfig
powerpc mpc512x_defconfig
arm collie_defconfig
arm hackkit_defconfig
powerpc linkstation_defconfig
arm footbridge_defconfig
mips tb0287_defconfig
mips bmips_stb_defconfig
arm rpc_defconfig
mips nlm_xlr_defconfig
m68k stmark2_defconfig
h8300 alldefconfig
sh sh7785lcr_defconfig
arc axs103_defconfig
arm shannon_defconfig
arm pleb_defconfig
arc axs101_defconfig
nios2 allyesconfig
sh apsh4ad0a_defconfig
c6x evmc6472_defconfig
riscv rv32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
x86_64 randconfig-a006-20200907
x86_64 randconfig-a004-20200907
x86_64 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-20200908
i386 randconfig-a002-20200908
i386 randconfig-a001-20200908
i386 randconfig-a003-20200908
i386 randconfig-a004-20200907
i386 randconfig-a005-20200907
i386 randconfig-a006-20200907
i386 randconfig-a002-20200907
i386 randconfig-a003-20200907
i386 randconfig-a001-20200907
x86_64 randconfig-a013-20200908
x86_64 randconfig-a016-20200908
x86_64 randconfig-a011-20200908
x86_64 randconfig-a012-20200908
x86_64 randconfig-a015-20200908
x86_64 randconfig-a014-20200908
i386 randconfig-a016-20200907
i386 randconfig-a015-20200907
i386 randconfig-a011-20200907
i386 randconfig-a013-20200907
i386 randconfig-a014-20200907
i386 randconfig-a012-20200907
i386 randconfig-a016-20200908
i386 randconfig-a015-20200908
i386 randconfig-a011-20200908
i386 randconfig-a013-20200908
i386 randconfig-a014-20200908
i386 randconfig-a012-20200908
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20200908
x86_64 randconfig-a006-20200908
x86_64 randconfig-a003-20200908
x86_64 randconfig-a001-20200908
x86_64 randconfig-a005-20200908
x86_64 randconfig-a002-20200908
x86_64 randconfig-a013-20200907
x86_64 randconfig-a011-20200907
x86_64 randconfig-a016-20200907
x86_64 randconfig-a012-20200907
x86_64 randconfig-a015-20200907
x86_64 randconfig-a014-20200907
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 1ae9eb3074160f102fc2eb13d7b3d776e9b9e462
From: kernel test robot @ 2020-09-09 2:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 1ae9eb3074160f102fc2eb13d7b3d776e9b9e462 Hack: Fix dts/fsl builds
elapsed time: 746m
configs tested: 155
configs skipped: 12
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
parisc defconfig
powerpc mvme5100_defconfig
sh microdev_defconfig
c6x dsk6455_defconfig
powerpc allmodconfig
arm omap2plus_defconfig
powerpc adder875_defconfig
mips ar7_defconfig
arm omap1_defconfig
sh se7619_defconfig
mips malta_qemu_32r6_defconfig
powerpc ep8248e_defconfig
xtensa defconfig
arm pxa910_defconfig
arm spear3xx_defconfig
mips malta_kvm_guest_defconfig
m68k m5407c3_defconfig
c6x allyesconfig
mips gpr_defconfig
sh se7780_defconfig
powerpc allnoconfig
c6x evmc6457_defconfig
m68k q40_defconfig
sparc allyesconfig
sh sh7763rdp_defconfig
arm zeus_defconfig
sh se7705_defconfig
riscv nommu_k210_defconfig
arm spear13xx_defconfig
arc haps_hs_smp_defconfig
m68k m5275evb_defconfig
h8300 defconfig
c6x evmc6474_defconfig
mips sb1250_swarm_defconfig
mips tb0287_defconfig
riscv alldefconfig
m68k amcore_defconfig
arm h5000_defconfig
sh lboxre2_defconfig
arm qcom_defconfig
sh sh7724_generic_defconfig
mips loongson1b_defconfig
parisc generic-32bit_defconfig
arm spear6xx_defconfig
ia64 tiger_defconfig
microblaze mmu_defconfig
powerpc mpc512x_defconfig
arm collie_defconfig
arm hackkit_defconfig
powerpc linkstation_defconfig
arm footbridge_defconfig
mips bmips_stb_defconfig
arm rpc_defconfig
mips nlm_xlr_defconfig
m68k stmark2_defconfig
h8300 alldefconfig
sh sh7785lcr_defconfig
arc axs103_defconfig
arm shannon_defconfig
arm pleb_defconfig
arc axs101_defconfig
nios2 allyesconfig
sh apsh4ad0a_defconfig
c6x evmc6472_defconfig
riscv rv32_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
x86_64 randconfig-a006-20200907
x86_64 randconfig-a004-20200907
x86_64 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-20200908
i386 randconfig-a002-20200908
i386 randconfig-a001-20200908
i386 randconfig-a003-20200908
i386 randconfig-a004-20200907
i386 randconfig-a005-20200907
i386 randconfig-a006-20200907
i386 randconfig-a002-20200907
i386 randconfig-a003-20200907
i386 randconfig-a001-20200907
x86_64 randconfig-a013-20200908
x86_64 randconfig-a016-20200908
x86_64 randconfig-a011-20200908
x86_64 randconfig-a012-20200908
x86_64 randconfig-a015-20200908
x86_64 randconfig-a014-20200908
i386 randconfig-a016-20200907
i386 randconfig-a015-20200907
i386 randconfig-a011-20200907
i386 randconfig-a013-20200907
i386 randconfig-a014-20200907
i386 randconfig-a012-20200907
i386 randconfig-a016-20200908
i386 randconfig-a015-20200908
i386 randconfig-a011-20200908
i386 randconfig-a013-20200908
i386 randconfig-a014-20200908
i386 randconfig-a012-20200908
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20200908
x86_64 randconfig-a006-20200908
x86_64 randconfig-a003-20200908
x86_64 randconfig-a001-20200908
x86_64 randconfig-a005-20200908
x86_64 randconfig-a002-20200908
x86_64 randconfig-a013-20200907
x86_64 randconfig-a011-20200907
x86_64 randconfig-a016-20200907
x86_64 randconfig-a012-20200907
x86_64 randconfig-a015-20200907
x86_64 randconfig-a014-20200907
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 952478355a3e375c9bc70a8f237900bf88c3f531
From: kernel test robot @ 2020-09-09 2:05 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: 952478355a3e375c9bc70a8f237900bf88c3f531 Automatic merge of 'master', 'next' and 'fixes' (2020-09-08 10:21)
elapsed time: 745m
configs tested: 169
configs skipped: 14
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 allmodconfig
arm allyesconfig
mips ip27_defconfig
arm milbeaut_m10v_defconfig
alpha defconfig
arc alldefconfig
m68k m5272c3_defconfig
mips decstation_r4k_defconfig
mips ip28_defconfig
mips malta_defconfig
powerpc holly_defconfig
arm mvebu_v7_defconfig
arc nsimosci_hs_defconfig
sh sh7763rdp_defconfig
sh r7785rp_defconfig
mips rs90_defconfig
m68k m5275evb_defconfig
arm exynos_defconfig
mips malta_kvm_guest_defconfig
m68k m5407c3_defconfig
c6x allyesconfig
mips gpr_defconfig
sh se7780_defconfig
powerpc allnoconfig
m68k q40_defconfig
arm zeus_defconfig
sh se7705_defconfig
riscv nommu_k210_defconfig
arm spear13xx_defconfig
sh secureedge5410_defconfig
um kunit_defconfig
sh se7721_defconfig
arm moxart_defconfig
mips cu1000-neo_defconfig
arc hsdk_defconfig
powerpc allmodconfig
s390 defconfig
powerpc ppc6xx_defconfig
arm hackkit_defconfig
powerpc linkstation_defconfig
arm footbridge_defconfig
xtensa defconfig
mips tb0287_defconfig
mips bmips_stb_defconfig
arm rpc_defconfig
mips nlm_xlr_defconfig
m68k stmark2_defconfig
mips rt305x_defconfig
arm s3c2410_defconfig
riscv allmodconfig
arm shannon_defconfig
c6x evmc6457_defconfig
arm pleb_defconfig
powerpc ps3_defconfig
arc vdk_hs38_defconfig
arm trizeps4_defconfig
powerpc mpc885_ads_defconfig
sh apsh4a3a_defconfig
arc axs101_defconfig
sh apsh4ad0a_defconfig
s390 zfcpdump_defconfig
arm mainstone_defconfig
powerpc ppc64e_defconfig
sh shmin_defconfig
mips ci20_defconfig
powerpc allyesconfig
arm magician_defconfig
arm assabet_defconfig
m68k mac_defconfig
xtensa common_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
x86_64 randconfig-a006-20200907
x86_64 randconfig-a004-20200907
x86_64 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-20200908
i386 randconfig-a002-20200908
i386 randconfig-a001-20200908
i386 randconfig-a003-20200908
i386 randconfig-a004-20200907
i386 randconfig-a005-20200907
i386 randconfig-a006-20200907
i386 randconfig-a002-20200907
i386 randconfig-a003-20200907
i386 randconfig-a001-20200907
i386 randconfig-a004-20200909
i386 randconfig-a005-20200909
i386 randconfig-a006-20200909
i386 randconfig-a002-20200909
i386 randconfig-a001-20200909
i386 randconfig-a003-20200909
x86_64 randconfig-a013-20200908
x86_64 randconfig-a016-20200908
x86_64 randconfig-a011-20200908
x86_64 randconfig-a012-20200908
x86_64 randconfig-a015-20200908
x86_64 randconfig-a014-20200908
i386 randconfig-a016-20200907
i386 randconfig-a015-20200907
i386 randconfig-a011-20200907
i386 randconfig-a013-20200907
i386 randconfig-a014-20200907
i386 randconfig-a012-20200907
i386 randconfig-a016-20200908
i386 randconfig-a015-20200908
i386 randconfig-a011-20200908
i386 randconfig-a013-20200908
i386 randconfig-a014-20200908
i386 randconfig-a012-20200908
riscv allyesconfig
riscv allnoconfig
riscv defconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20200908
x86_64 randconfig-a006-20200908
x86_64 randconfig-a003-20200908
x86_64 randconfig-a001-20200908
x86_64 randconfig-a005-20200908
x86_64 randconfig-a002-20200908
x86_64 randconfig-a013-20200909
x86_64 randconfig-a016-20200909
x86_64 randconfig-a011-20200909
x86_64 randconfig-a012-20200909
x86_64 randconfig-a015-20200909
x86_64 randconfig-a014-20200909
x86_64 randconfig-a013-20200907
x86_64 randconfig-a011-20200907
x86_64 randconfig-a016-20200907
x86_64 randconfig-a012-20200907
x86_64 randconfig-a015-20200907
x86_64 randconfig-a014-20200907
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v3 1/2] scsi: ibmvfc: use compiler attribute defines instead of __attribute__()
From: Martin K. Petersen @ 2020-09-09 2:04 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: martin.petersen, linux-scsi, linux-kernel, james.bottomley,
brking, linuxppc-dev
In-Reply-To: <20200904232936.840193-1-tyreld@linux.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] powerpc/64: Make VDSO32 track COMPAT on 64-bit
From: Michael Ellerman @ 2020-09-08 23:32 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev; +Cc: msuchanek
In-Reply-To: <f5ca915b-81b5-aa7b-727e-e43681ab825f@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> 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
>> depending on it would have left the 32-bit VDSO always enabled, which
>> we didn't want.
>>
>> But since then we have made COMPAT selectable, and off by default for
>> ppc64le, so VDSO32 should really depend on that.
>>
>> For most people this makes no difference, none of the defconfigs
>> change, it's only if someone is building ppc64le with COMPAT=y, they
>> will now also get VDSO32. If they've enabled COMPAT in order to run
>> 32-bit binaries they presumably also want the 32-bit VDSO.
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> Michael, please note that christophe.leroy@c-s.fr is a deprecated
> address that will one day not work anymore. Please use the new one
> whenever possible.
OK, I had the old one in my ~/.mailrc, fixed now.
cheers
^ 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