Excerpts from Stephen Rothwell's message of March 24, 2021 6:58 am:
> Hi all,
>
> On Thu, 18 Mar 2021 20:56:07 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the akpm-current tree, today's linux-next build (sparc
>> defconfig) failed like this:
>>
>> In file included from
Hi all,
On Thu, 18 Mar 2021 20:56:07 +1100 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> In file included from arch/sparc/include/asm/pgtable_32.h:25:0,
> from
Hi all,
After merging the akpm-current tree, today's linux-next build (sparc
defconfig) failed like this:
In file included from arch/sparc/include/asm/pgtable_32.h:25:0,
from arch/sparc/include/asm/pgtable.h:7,
from include/linux/pgtable.h:6,
On Wed, Mar 10, 2021 at 11:55 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> arch/sparc/mm/init_64.c:2495:4: error: implicit declaration of function
> 'register_page_bootmem_info_node'; did you
On Tue, Mar 9, 2021 at 7:16 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
Hi Stephen,
Sorry about the failure! Indeed, I had guarded this in the header, but
not in the .c file. I sent a v2.5
Hi all,
After merging the akpm-current tree, today's linux-next build (sparc64
defconfig) failed like this:
arch/sparc/mm/init_64.c:2495:4: error: implicit declaration of function
'register_page_bootmem_info_node'; did you mean 'register_page_bootmem_info'?
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/shmem.c:2365:12: warning: 'enum mcopy_atomic_mode' declared inside parameter
list will not be visible outside of this definition or declaration
2365 | enum
Hi all,
On Tue, 2 Feb 2021 20:03:24 +1100 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> In file included from arch/x86/include/asm/page.h:76,
> from arch/x86/include/asm/thread_info.h:12,
On 2/3/21 2:22 PM, Arnd Bergmann wrote:
> On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap wrote:
>>
>> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
>>> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
>>> wrote:
>>>
983cb10d3f90 ("mm/gup: do not migrate zero page")
I have applied
> >
> > Stephen, do you want to send a new patch based on the current
> > linux-next, or do you want me to send an updated version?
>
> I'll send another one and include it in linux-next today.
I appreciate it.
Pasha
Hi Pavel,
On Wed, 3 Feb 2021 18:21:07 -0500 Pavel Tatashin
wrote:
>
> Stephen, do you want to send a new patch based on the current
> linux-next, or do you want me to send an updated version?
I'll send another one and include it in linux-next today.
--
Cheers,
Stephen Rothwell
Stephen, do you want to send a new patch based on the current
linux-next, or do you want me to send an updated version?
Thank you,
Pasha
On Wed, Feb 3, 2021 at 5:36 PM Pavel Tatashin wrote:
>
> > > After the most recent build errors, I tried to apply Pavel's patch
> > >
> > >
> > After the most recent build errors, I tried to apply Pavel's patch
> >
> > https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
> > but patch said that it was already applied (by Andrew I think),
> > so I bailed out (gave up).
>
> As far as I
On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap wrote:
>
> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> > On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
> > wrote:
> >
> >>
> >> 983cb10d3f90 ("mm/gup: do not migrate zero page")
> >>
> >> I have applied the following patch for today:
> >>
> >>
On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
> wrote:
>
>>
>> 983cb10d3f90 ("mm/gup: do not migrate zero page")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell
>> Date: Tue, 2 Feb 2021 19:49:00 +1100
>> Subject:
On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell wrote:
>
> 983cb10d3f90 ("mm/gup: do not migrate zero page")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Tue, 2 Feb 2021 19:49:00 +1100
> Subject: [PATCH] make is_pinnable_page a macro
>
> As it is
Hi Pavel,
On Tue, Feb 2, 2021 at 1:34 PM Pavel Tatashin wrote:
> The fix is here:
> https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
Thanks, that fixed the m68k/m5272c3_defconfig build.
> On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven
>
Hi Geert,
The fix is here:
https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
Thank you,
Pasha
On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven wrote:
>
> On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell
> wrote:
> > After merging the
On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> In file included from arch/x86/include/asm/page.h:76,
> from arch/x86/include/asm/thread_info.h:12,
>
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allnoconfig) failed like this:
In file included from arch/x86/include/asm/page.h:76,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:56,
On Wed, Jan 27, 2021 at 11:21:18PM +1100, Stephen Rothwell wrote:
> Caused by commit
>
> 5567a1a4b1c3 ("ramfs: support O_TMPFILE")
Can this be merged or sent to Al, please? It's ancient patch.
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/ramfs/inode.c:175:13: error: initialization of 'int (*)(struct
user_namespace *, struct inode *, struct dentry *, umode_t)' {aka 'int
(*)(struct user_namespace *, struct inode
Hi Dan,
On Tue, 19 Jan 2021 21:48:52 -0800 Dan Williams
wrote:
>
> On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > mm/memory_hotplug.c: In
On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
> mm/memory_hotplug.c:772:24: error: 'ZONE_DEVICE'
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
mm/memory_hotplug.c:772:24: error: 'ZONE_DEVICE' undeclared (first use in this
function)
772 | if (zone_idx(zone) ==
On Mon, 2020-12-21 at 13:55 +1100, Stephen Rothwell wrote:
> Hi Kuan-Ying,
>
> On Mon, 21 Dec 2020 10:31:38 +0800 Kuan-Ying Lee
> wrote:
> >
> > On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> > >
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > >
Hi Kuan-Ying,
On Mon, 21 Dec 2020 10:31:38 +0800 Kuan-Ying Lee
wrote:
>
> On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > mm/kasan/quarantine.c: In function
On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/kasan/quarantine.c: In function 'quarantine_put':
> mm/kasan/quarantine.c:207:15: error: 'info' undeclared
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
mm/kasan/quarantine.c: In function 'quarantine_put':
mm/kasan/quarantine.c:207:15: error: 'info' undeclared (first use in this
function)
207 | qlink_free(>quarantine_link, cache);
On Thu, 3 Dec 2020 at 09:37, Rui Salvaterra wrote:
>
> Thanks for the heads-up, I think I know where the problem is.
Then again, maybe not. I don't have a PowerPC machine to test, at the
moment, and all my x86(-64) machines work fine. If no one beats me to
it, I can debug on an iBook G4, but
Hi, Stephen,
On Thu, 3 Dec 2020 at 09:08, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
[…]
>
> Caused by commit
>
> a6d52df2d8bc ("zram: break the strict dependency from lzo")
>
> I have
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
WARNING: unmet direct dependencies detected for CRYPTO_LZO
Depends on [m]: CRYPTO [=m]
Selected by [y]:
- ZRAM_DEF_COMP_LZORLE [=y] &&
Selected by [m]:
- UBIFS_FS [=m] &&
On Wed, Nov 4, 2020 at 9:05 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/numa.h:25,
> from include/linux/nodemask.h:96,
>
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/numa.h:25,
from include/linux/nodemask.h:96,
from include/linux/mount.h:15,
from fs/pnode.c:9:
On Thu, Oct 29, 2020 at 03:08:09PM +1100, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> lib/math/div64.c: In function 'mul_u64_u64_div_u64':
> lib/math/div64.c:202:6: error: implicit declaration of
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
lib/math/div64.c: In function 'mul_u64_u64_div_u64':
lib/math/div64.c:202:6: error: implicit declaration of function 'ilog2'
[-Werror=implicit-function-declaration]
202 | if
On Fri, Oct 16, 2020 at 12:45 PM Miklos Szeredi wrote:
[..]
> > This is broken... it needs to be converted to 'struct range'. I'll take
> > care of that when I respin the series. Sorry for the thrash it seems
> > this is a new memremap_pages() user since the conversion patches
> > landed.
>
> Hi
On Thu, Sep 24, 2020 at 3:40 AM Williams, Dan J
wrote:
>
> On Tue, 2020-09-08 at 20:09 +1000, Stephen Rothwell wrote:
[...]
> > From: Stephen Rothwell
> > Date: Tue, 8 Sep 2020 20:00:20 +1000
> > Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to
> > 'struct
> > range'"
> >
> >
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/readahead.c: In function 'page_cache_sync_ra':
mm/readahead.c:565:8: error: 'filp' undeclared (first use in this function);
did you mean 'file'?
565 | if (!filp)
|
On Tue, 2020-09-08 at 20:09 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/xen/unpopulated-alloc.c: In function 'fill_list':
> drivers/xen/unpopulated-alloc.c:30:9: error: 'struct
On Tue, Sep 08, 2020 at 08:09:50PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/xen/unpopulated-alloc.c: In function 'fill_list':
> drivers/xen/unpopulated-alloc.c:30:9: error:
On Tue, Sep 08, 2020 at 08:09:50PM +1000, Stephen Rothwell wrote:
[..]
> fs/fuse/virtio_fs.c: In function 'virtio_fs_setup_dax':
> fs/fuse/virtio_fs.c:838:9: error: 'struct dev_pagemap' has no member named
> 'res'; did you mean 'ref'?
> 838 | pgmap->res = (struct resource){
> |
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/xen/unpopulated-alloc.c: In function 'fill_list':
drivers/xen/unpopulated-alloc.c:30:9: error: 'struct dev_pagemap' has no member
named 'res'; did you mean 'ref'?
30 |
Hi Mike,
On Thu, 27 Aug 2020 15:45:49 +0300 Mike Rapoport wrote:
>
> On Thu, Aug 27, 2020 at 06:20:58PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (mips
> > cavium_octeon_defconfig) failed like this:
> >
> >
On Thu, Aug 27, 2020 at 06:20:58PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (mips
> cavium_octeon_defconfig) failed like this:
>
> arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared (first
> use in this
Hi all,
After merging the akpm-current tree, today's linux-next build (mips
cavium_octeon_defconfig) failed like this:
arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared (first use
in this function); did you mean ‘sem’?
Caused by commit
52e1a745395d ("arch, drivers: replace
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
allnoconfig) failed like this:
mm/memory.c: In function '__apply_to_page_range':
mm/memory.c:2358:13: error: 'ARCH_PAGE_TABLE_SYNC_MASK' undeclared (first use
in this function)
2358 | if (mask &
On 7/21/20 3:57 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build
> (sparc64 defconfig) failed like this:
>
> mm/hugetlb.c: In function 'free_gigantic_page':
> mm/hugetlb.c:1233:18: error: 'hugetlb_cma' undeclared (first use in this
>
Hi all,
After merging the akpm-current tree, today's linux-next build
(sparc64 defconfig) failed like this:
mm/hugetlb.c: In function 'free_gigantic_page':
mm/hugetlb.c:1233:18: error: 'hugetlb_cma' undeclared (first use in this
function); did you mean 'hugetlb_lock'?
Hi all,
[Also reported by Randy Dunlap.]
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/migrate.c: In function 'migrate_pages':
mm/migrate.c:1528:19: error: 'THP_MIGRATION_SUCCESS' undeclared (first use in
this function); did you
On Fri, Jun 26, 2020 at 05:06:03PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> mm/slab.c: In function '___cache_free':
> mm/slab.c:3471:2: error: implicit declaration of function
Hi all,
After merging the akpm-current tree, today's linux-next build (sparc
defconfig) failed like this:
mm/slab.c: In function '___cache_free':
mm/slab.c:3471:2: error: implicit declaration of function '__free_one'; did you
mean '__free_page'? [-Werror=implicit-function-declaration]
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
Caused by commit
a1e988dda7bb ("drivers/tty/serial/sh-sci.c: suppress uninitialized var
warning")
interacting with commit
2d0e6f87039d ("compiler: Remove uninitialized_var()
Hi Andrew,
On Tue, 9 Jun 2020 21:01:37 -0700 Andrew Morton
wrote:
>
> I've sent this in as well:
>
> From: Andrew Morton
> Subject: arch/sparc/mm/srmmu.c: fix build
>
> "mm: consolidate pte_index() and pte_offset_*() definitions" was supposed
> to remove
On Wed, 10 Jun 2020 13:44:25 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (sparc
> > defconfig) failed like this:
> >
> > In file included from
Hi all,
On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> In file included from include/linux/mm.h:32:0,
> from include/linux/memblock.h:13,
>
Hi all,
After merging the akpm-current tree, today's linux-next build (sparc
defconfig) failed like this:
In file included from include/linux/mm.h:32:0,
from include/linux/memblock.h:13,
from arch/sparc/mm/srmmu.c:14:
include/linux/pgtable.h:74:27: error:
On Fri, 8 May 2020 07:51:23 -0700 Ira Weiny wrote:
> This should probably be squashed into that patch though...
>
> Andrew do you want a V3.1?
Is OK, I'll always fold foo-fix.patch into foo.patch before sending it onwards.
On Thu, May 07, 2020 at 07:08:08PM -0700, Andrew Morton wrote:
> On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell
> wrote:
>
> > Hi all,
> >
> > On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the akpm-current tree, today's linux-next build (arm
> >
Hi Andrew,
On Thu, 7 May 2020 19:08:08 -0700 Andrew Morton
wrote:
>
> This? It's based on Ira's v3 series but should work.
>
>
> From: Andrew Morton
> Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
>
> fix CONFIG_HIGHMEM=n build on various architectures
>
> Reported-by:
On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > collie_defconfig and many others) failed like this:
> >
> >
Hi all,
On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
wrote:
>
> After merging the akpm-current tree, today's linux-next build (arm
> collie_defconfig and many others) failed like this:
>
> arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
> arch/arm/mm/dma-mapping.c:892:6:
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
collie_defconfig and many others) failed like this:
arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
arch/arm/mm/dma-mapping.c:892:6: error: implicit declaration of function
'kunmap_high'
On Fri, Aug 30, 2019 at 11:55:30PM +1000, Stephen Rothwell wrote:
> Caused by commit
>
> 1c8999b3963d ("mm: introduce MADV_COLD")
> (and following commits)
>
> interacting with commit
>
> 923bfc561e75 ("pagewalk: separate function pointers from iterator data")
>
> from the hmm tree.
Yes,
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/madvise.c: In function 'madvise_cold_page_range':
mm/madvise.c:459:4: error: 'struct mm_walk' has no member named 'pmd_entry'
459 | .pmd_entry =
On Fri, Aug 16, 2019 at 10:16:03PM +1000, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/kmemleak.c: In function 'kmemleak_disable':
> mm/kmemleak.c:1884:2: error: 'kmemleak_early_log' undeclared (first use
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
mm/kmemleak.c: In function 'kmemleak_disable':
mm/kmemleak.c:1884:2: error: 'kmemleak_early_log' undeclared (first use in this
function); did you mean 'kmemleak_alloc'?
Hi Stephen,
> On Aug 7, 2019, at 12:24 AM, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/kernel.h:11,
> from
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/kernel.h:11,
from kernel/events/uprobes.c:12:
kernel/events/uprobes.c: In function 'uprobe_write_opcode':
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/madvise.c: In function 'madvise_cold_or_pageout_pte_range':
mm/madvise.c:346:7: error: implicit declaration of function 'is_huge_zero_pmd';
did you mean 'is_huge_zero_pud'?
On Fri, 12 Jul 2019 12:59:45 +0200 Arnd Bergmann wrote:
> On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton
> wrote:
> >
> >
> > From: Yang Shi
> > Subject: mm: shrinker: make shrinker not depend on memcg kmem
> >
> > Currently shrinker is just allocated and can work when memcg kmem is
> >
On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton wrote:
>
>
> From: Yang Shi
> Subject: mm: shrinker: make shrinker not depend on memcg kmem
>
> Currently shrinker is just allocated and can work when memcg kmem is
> enabled. But, THP deferred split shrinker is not slab shrinker, it
> doesn't make
On Wed, 10 Jul 2019 09:05:09 +0200 Michal Hocko wrote:
> > return false;
> > }
> > +static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> > + int nid, int shrinker_id)
> > +{
> > +}
> > #endif
>
> Can we get the full series resent
On Tue 09-07-19 13:42:33, Andrew Morton wrote:
> On Tue, 9 Jul 2019 21:15:59 +1000 Stephen Rothwell
> wrote:
>
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > arm-linux-gnueabi-ld: mm/list_lru.o: in
On Tue, 9 Jul 2019 21:15:59 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arm-linux-gnueabi-ld: mm/list_lru.o: in function `list_lru_add':
> list_lru.c:(.text+0x1a0): undefined
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
arm-linux-gnueabi-ld: mm/list_lru.o: in function `list_lru_add':
list_lru.c:(.text+0x1a0): undefined reference to `memcg_set_shrinker_bit'
Caused by commit
ca37e9e5f18d
Hi Marco,
On Fri, 5 Jul 2019 11:27:58 +0200 Marco Elver wrote:
>
> Apologies for the breakage -- thanks for the fix! Shall I send a v+1
> or will your patch persist?
I assume Andrew will grab it and squash it into the original patch
before sending it to Linus.
--
Cheers,
Stephen Rothwell
On Fri, 5 Jul 2019 at 10:49, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/compiler.h:257,
> from arch/arm/kernel/asm-offsets.c:10:
>
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/compiler.h:257,
from arch/arm/kernel/asm-offsets.c:10:
include/linux/kasan-checks.h:14:15: error: unknown type name 'bool'
static
Hi Christoph,
On Wed, 26 Jun 2019 15:13:18 +0200 Christoph Hellwig wrote:
>
> As that function is in code only there to provide compile coverage
> something like this should fix the problem:
>
>
> diff --git a/arch/sparc/include/asm/pgtable_64.h
> b/arch/sparc/include/asm/pgtable_64.h
> index
As that function is in code only there to provide compile coverage
something like this should fix the problem:
diff --git a/arch/sparc/include/asm/pgtable_64.h
b/arch/sparc/include/asm/pgtable_64.h
index 547ff96fb228..1599de730532 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++
Hi all,
After merging the akpm tree, today's linux-next build (sparc64 defconfig)
failed like this:
In file included from arch/sparc/include/asm/page_64.h:130:0,
from arch/sparc/include/asm/page.h:8,
from arch/sparc/include/asm/thread_info_64.h:27,
Hi Anshuman,
On Wed, 26 Jun 2019 17:32:18 +0530 Anshuman Khandual
wrote:
>
> I believe this might be caused by a patch for powerpc enabling
> HAVE_ARCH_HUGE_VMAP
> without an arch_ioremap_p4d_supported() definition.
Ah, OK.
> All it needs is a powerpc definition for
Hello Stephen,
On 06/26/2019 05:11 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ld: lib/ioremap.o: in function `.ioremap_huge_init':
> ioremap.c:(.init.text+0x3c): undefined reference to
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ld: lib/ioremap.o: in function `.ioremap_huge_init':
ioremap.c:(.init.text+0x3c): undefined reference to
`.arch_ioremap_p4d_supported'
Caused by commit
749940680d0b
On Mon, 24 Jun 2019 21:00:43 +1000 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> mm/util.c: In function '__account_locked_vm':
> mm/util.c:372:2: error: implicit declaration of function
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/util.c: In function '__account_locked_vm':
mm/util.c:372:2: error: implicit declaration of function
'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'?
On Wed, Jun 19, 2019 at 7:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from usr/include/linux/byteorder/big_endian.hdrtest.c:1:
>
On 20.06.19 11:42, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/base/memory.c: In function 'find_memory_block':
> drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in
Hi all,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/base/memory.c: In function 'find_memory_block':
drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in this
function); did you mean 'uint'?
return
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from usr/include/linux/byteorder/big_endian.hdrtest.c:1:
./usr/include/linux/byteorder/big_endian.h:6:2: error: #error "Unsupported
endianness, check your toolchain"
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
Caused by commit
a826492f28d9 ("mm: move ioremap page table mapping function to mm/")
I have applied the following patch for today (which makes it build at
least):
From: Stephen
Hi all,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/mm/extable.c:6:
include/linux/uaccess.h:302:29: error: static declaration of 'probe_user_read'
follows non-static declaration
static __always_inline
On Thu, Apr 18, 2019 at 09:02:47AM +1000, Stephen Rothwell wrote:
> Hi Kees,
>
> On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> > >
> > > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > > wrote:
> > > >
> > > > Hi Andrew,
Hi Kees,
On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > wrote:
> > >
> > > Hi Andrew,
> > >
> > > After merging the akpm-current tree, today's linux-next build (arm
> > >
On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> wrote:
> >
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > fs/binfmt_elf.c: In function
On Wed, Apr 17, 2019 at 5:28 PM Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > wrote:
> > > [...]
> > > Caused by commit
> > >
> > > 3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct
> >
On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell wrote:
>
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/binfmt_elf.c: In function 'load_elf_binary':
> fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/binfmt_elf.c: In function 'load_elf_binary':
fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this
function); did you mean 'interpreter'?
if
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/vmscan.c: In function 'snapshot_refaults':
mm/vmscan.c:2969:14: error: implicit declaration of function
'lruvec_page_state_local'; did you mean 'lruvec_page_state'?
1 - 100 of 676 matches
Mail list logo
