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 arch/sparc/inclu
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 arch/sparc/include/asm/pgtable.
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,
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 th
> >
> > 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
pgpgWT1_z_R5H
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
> > >
> > > https://lore.ker
> > 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 c
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:
> >>
> >> From:
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: [P
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 curren
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
> w
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 akpm-cu
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,
>
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 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 fun
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' unde
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
> > > all
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 'qua
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 (first
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 only
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 re
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,
>
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 function
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 D
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'"
> >
> > S
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 dev
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: 'str
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 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:
> >
> > arch/mips/cavium-
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 function);
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
> functio
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 '__free_one';
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 arch/sparc/mm/srmmu.c:pte_offset_kerne
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 include/linux/mm.h:
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,
> fr
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:
> >
> > arch/arm/mm/dma-mappi
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: er
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,
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 i
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 kernel/events/uprobes.c:12:
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
> > enabled
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 t
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 please.
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 functi
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 referenc
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
pgp
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:
> includ
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
+++ b/arch/sparc
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 arch_ioremap_p4d_supported
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
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
>
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:
> ./usr/include/linux/byteorder/big_endian.h
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 t
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
> > > mu
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 'load_elf_bi
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 (f
On Wed, 13 Feb 2019 17:25:18 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_async_list_note':
> fs/io_uring.c:931:16: error: 'VM_MAX_READAHEAD' undeclar
Hi Anshuman,
On Tue, 8 Jan 2019 10:24:18 +0530 Anshuman Khandual
wrote:
>
> Just curious why the NUMA_NO_NODE definition did not get resolved from the
> local
> numa.h which had the same ones copied over from linux/numa.h but anyways the
> fix
> looks okay.
I assume that is /usr/include/numa
On 01/08/2019 07:41 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (native
> perf) failed like this:
>
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this
> function)
On Mon, Jul 23, 2018 at 07:42:31PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc (32 bit)
> defconfig) failed like this:
>
> In file included from kernel/crash_core.c:9:0:
> kernel/crash_core.c: In function 'crash_save_vmcoreinfo_init
On Fri, Jun 29, 2018 at 05:49:46PM +1000, Stephen Rothwell wrote:
> fs/proc/inode.c:110:2: note: in expansion of macro 'BUILD_BUG_ON'
> BUILD_BUG_ON(sizeof(struct proc_dir_entry) >= SIZEOF_PDE);
> ^~~~
>
> Caused by commit
>
> 527ae8759f10 ("proc: fixup PDE allocation bloat")
>
> I
Hi Andrew,
On Tue, 13 Mar 2018 12:44:34 -0700 Andrew Morton
wrote:
>
> On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell
> wrote:
>
> > After merging the akpm-current tree, today's linux-next build (lots of
> > configuations) failed like this:
> >
> > (from the i386 defconfig build)
> >
>
On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (lots of
> configuations) failed like this:
>
> (from the i386 defconfig build)
>
> In file included from include/linux/memcontrol.h:29:0,
>
On Fri 23-02-18 00:56:26, Stephen Rothwell wrote:
> Hi Michal,
>
> On Thu, 22 Feb 2018 08:11:00 +0100 Michal Hocko wrote:
> >
> > This is interesting. I thought that IS_ENABLED(CONFIG_HAVE_MEMBLOCK)
> > would have the same meaning as ifdef CONFIG_HAVE_MEMBLOCK so the branch
> > will never be cons
Hi Michal,
On Thu, 22 Feb 2018 08:11:00 +0100 Michal Hocko wrote:
>
> This is interesting. I thought that IS_ENABLED(CONFIG_HAVE_MEMBLOCK)
> would have the same meaning as ifdef CONFIG_HAVE_MEMBLOCK so the branch
> will never be considered. If that is not the case then I would rather
> reintroduc
On Thu 22-02-18 14:30:57, Stephen Rothwell wrote:
> Hi Andrew,
>
> [As reported by Randy for uml ...]
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> /home/sfr/next/next/mm/page_alloc.c: In function 'memmap_init_zone':
> /home/sfr/next/
On Sun, Nov 19, 2017 at 8:32 PM, Stephen Rothwell wrote:
> Hi Dan,
>
> On Sun, 19 Nov 2017 20:25:18 -0800 Dan Williams
> wrote:
>>
>> Ugh, yes. Looks correct. I might have confused my build success
>> notifications from 0day. I'll spin out a new branch to make sure this
>> is the last of it.
>
>
Hi Dan,
On Sun, 19 Nov 2017 20:25:18 -0800 Dan Williams
wrote:
>
> Ugh, yes. Looks correct. I might have confused my build success
> notifications from 0day. I'll spin out a new branch to make sure this
> is the last of it.
Thanks.
While I have your attention ... did you consider using the oth
On Sun, Nov 19, 2017 at 5:57 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/book3s/64/mmu
> -hash.h:24:0,
> from arch/powerpc/
I checked. __pmd() works.
BTW, my sparc32 fix was added in linux-next on August 11th
and __pmd() is there, too. This means __pmd() + my fix has survived
for almost a month in linux-next. It should be good.
--
Best Regards
Yan Zi
On 7 Sep 2017, at 23:43, Stephen Rothwell wrote:
> Hi all,
>
> On
Hi all,
On Fri, 8 Sep 2017 12:49:59 +1000 Stephen Rothwell
wrote:
>
> OK, so today I have applied this instead (which is the same as dropping
> mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
>
> From: Stephen Rothwell
> Date: Fri, 8 Sep 2017 12:40:39 +1000
> Subject: [PATCH] mm-thp-
Hi all,
On Thu, 07 Sep 2017 06:59:09 -0400 "Zi Yan" wrote:
>
> I think __pmd(0) can be used now. I fixed __pmd() in sparc32 at commit
> 9157259d16a8ee8116a98d32f29b797689327e8d, which is in 4.13 now.
> I should have told you this earlier, sorry about that.
>
> Just wonder if any other reason pre
On 7 Sep 2017, at 3:46, Andrew Morton wrote:
> On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell
> wrote:
>
>> Hi all,
>>
>> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell
>> wrote:
>>>
>>> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell
>>> wrote:
On Tue, 01 Aug 2017 09:08
On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell
> wrote:
> >
> > On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell
> > wrote:
> > >
> > > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan"
> > > wrote:
> > > >
> > > >
Hi all,
On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell
wrote:
>
> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell
> wrote:
> >
> > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" wrote:
> > >
> > > I found two possible fixes.
> > >
> > > 1. This uses C++ zero initializer, GCC is OK with
Hello Stephen,
On Thu, 2017-08-31 at 18:21 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from
> /home/sfr/next/next/include/uapi/linux/uuid.h:21:0,
>
Hi Christoph,
On Fri, 25 Aug 2017 11:34:19 +0200 Christoph Hellwig wrote:
>
> On Fri, Aug 25, 2017 at 06:12:54PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/block/zra
On Fri, Aug 25, 2017 at 06:12:54PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/block/zram/zram_drv.c: In function 'read_from_bdev_a
> sync':
> drivers/block/zram/zram_drv.c:461:5:
On Wed, 23 Aug 2017 20:41:59 +1000 Stephen Rothwell
wrote:
> After merging the akpm-current tree, today's linux-next build (mips
> defconfig) failed like this:
>
> In file included from include/linux/selection.h:11:0,
> from drivers/video/console/newport_con.c:16:
> include/lin
Hi all,
On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell
wrote:
>
> On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" wrote:
> >
> > I found two possible fixes.
> >
> > 1. This uses C++ zero initializer, GCC is OK with it.
> > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> >
Hi Zi,
On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" wrote:
>
> I found two possible fixes.
>
> 1. This uses C++ zero initializer, GCC is OK with it.
> I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
>
> --- a/include/linux/swapops.h~a
> +++ a/include/linux/swapops.h
> @@ -217
Hi Stephen,
I found two possible fixes.
1. This uses C++ zero initializer, GCC is OK with it.
I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
--- a/include/linux/swapops.h~a
+++ a/include/linux/swapops.h
@@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
static in
Hi Stephen,
The warning after removing __pmd() is caused by a gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
so (pmd_t) {0} causes warning in some GCC versions.
__pmd() is defined in alpha, arm, arm64, frv, ia64, m32r, m68k, microblaze,
mips, parisc,
powerpc, s390, sh, sparc, tile,
Hi all,
On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell
wrote:
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> In file included from mm/vmscan.c:55:0:
> include/linux/swapops.h: In function 'swp_entry_to_pmd':
> include/linux/swapops.h:226:
On Fri, Jun 16, 2017 at 10:17 AM, Andrew Morton
wrote:
> On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook wrote:
>
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote:
>> >
>> >> >> Caused by commit
>> >> >>
>> >> >> 088a5ecf7581 ("
On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote:
> >
> >> >> Caused by commit
> >> >>
> >> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified
> >> >> strin
Hi Kees,
On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook wrote:
>
> Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).
And that just made it in time for today's linux-next. I have removed
the patches from Andrew's tree.
--
Cheers,
Stephen Rothwell
On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay wrote:
> On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook
>> > wrote:
>> >
>> > > > > Caused by commit
>> > > > >
>> > > > > 088a5ecf7
On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook
> > wrote:
> >
> > > > > Caused by commit
> > > > >
> > > > > 088a5ecf7581 ("include/linux/string.h: add the option of
> > > > > fort
On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
wrote:
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote:
>
>> >> Caused by commit
>> >>
>> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified
>> >> string.h functions")
>> >>
>> >> We really need to fix all the known proble
On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote:
> >> Caused by commit
> >>
> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified
> >> string.h functions")
> >>
> >> We really need to fix all the known problems it detects *before*
> >> merging this commit ...
> >>
> >> I h
]
On Wed, Jun 14, 2017 at 10:56 PM, Michael Ellerman wrote:
> Daniel Micay writes:
>> ...
>>
>> The arch mailing list was pinged about this which is how the powerpc
>> folks got involved and fixed the issues there, including at least one
>> runtime one. Not sure where (if anywhere) those are que
1 - 100 of 236 matches
Mail list logo
