All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Guenter Roeck <linux@roeck-us.net>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>,
	Rob Herring <robherring2@gmail.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: linux-next: Tree for Oct 15
Date: Tue, 16 Oct 2018 16:36:56 +0300	[thread overview]
Message-ID: <20181016133656.GA10925@rapoport-lnx> (raw)
In-Reply-To: <20181015151319.3a443f0421c20bd7ed055cb9@linux-foundation.org>

On Mon, Oct 15, 2018 at 03:13:19PM -0700, Andrew Morton wrote:
> On Tue, 16 Oct 2018 07:24:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > 
> > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > 
> > That is:
> > 
> > static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> >                                         phys_addr_t align, phys_addr_t start,
> >                                         phys_addr_t end, int nid,
> >                                         enum memblock_flags flags)
> > {
> >        if (WARN_ON_ONCE(!align))
> >                 align = SMP_CACHE_BYTES;
> > 
> > Looks like patch
> > 
> >   "memblock: stop using implicit alignment to SMP_CACHE_BYTES"
> > 
> > missed some places ...
> 
> To be expected, I guess.  I'm pretty relaxed about this ;) Let's do
> another sweep in a week or so, after which we'll have a couple of
> months to mop up any leftovers.

After some more grepping and spatching I've found these:

From 8b014bae53a78ab747dbb76b9aff7df4cefcb604 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Tue, 16 Oct 2018 16:03:00 +0300
Subject: [PATCH] memblock: fix missed uses of implicit aligment

A couple of memblock*alloc uses were missed during conversion from implicit
alignment setting with 'align = 0' to explictly using SMP_CACHE_BYTES.
Fix them now.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/powerpc/kernel/paca.c    | 2 +-
 drivers/firmware/efi/memmap.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f331a00..913bfca 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -198,7 +198,7 @@ void __init allocate_paca_ptrs(void)
 	paca_nr_cpu_ids = nr_cpu_ids;
 
 	paca_ptrs_size = sizeof(struct paca_struct *) * nr_cpu_ids;
-	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, 0));
+	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, SMP_CACHE_BYTES));
 	memset(paca_ptrs, 0x88, paca_ptrs_size);
 }
 
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index ef618bc..fa2904f 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -15,7 +15,7 @@
 
 static phys_addr_t __init __efi_memmap_alloc_early(unsigned long size)
 {
-	return memblock_phys_alloc(size, 0);
+	return memblock_phys_alloc(size, SMP_CACHE_BYTES);
 }
 
 static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)
-- 
2.7.4

 

-- 
Sincerely yours,
Mike.


WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Guenter Roeck <linux@roeck-us.net>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>,
	Rob Herring <robherring2@gmail.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: linux-next: Tree for Oct 15
Date: Tue, 16 Oct 2018 16:36:56 +0300	[thread overview]
Message-ID: <20181016133656.GA10925@rapoport-lnx> (raw)
In-Reply-To: <20181015151319.3a443f0421c20bd7ed055cb9@linux-foundation.org>

On Mon, Oct 15, 2018 at 03:13:19PM -0700, Andrew Morton wrote:
> On Tue, 16 Oct 2018 07:24:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > 
> > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > 
> > That is:
> > 
> > static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> >                                         phys_addr_t align, phys_addr_t start,
> >                                         phys_addr_t end, int nid,
> >                                         enum memblock_flags flags)
> > {
> >        if (WARN_ON_ONCE(!align))
> >                 align = SMP_CACHE_BYTES;
> > 
> > Looks like patch
> > 
> >   "memblock: stop using implicit alignment to SMP_CACHE_BYTES"
> > 
> > missed some places ...
> 
> To be expected, I guess.  I'm pretty relaxed about this ;) Let's do
> another sweep in a week or so, after which we'll have a couple of
> months to mop up any leftovers.

After some more grepping and spatching I've found these:

>From 8b014bae53a78ab747dbb76b9aff7df4cefcb604 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Tue, 16 Oct 2018 16:03:00 +0300
Subject: [PATCH] memblock: fix missed uses of implicit aligment

A couple of memblock*alloc uses were missed during conversion from implicit
alignment setting with 'align = 0' to explictly using SMP_CACHE_BYTES.
Fix them now.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/powerpc/kernel/paca.c    | 2 +-
 drivers/firmware/efi/memmap.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f331a00..913bfca 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -198,7 +198,7 @@ void __init allocate_paca_ptrs(void)
 	paca_nr_cpu_ids = nr_cpu_ids;
 
 	paca_ptrs_size = sizeof(struct paca_struct *) * nr_cpu_ids;
-	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, 0));
+	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, SMP_CACHE_BYTES));
 	memset(paca_ptrs, 0x88, paca_ptrs_size);
 }
 
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index ef618bc..fa2904f 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -15,7 +15,7 @@
 
 static phys_addr_t __init __efi_memmap_alloc_early(unsigned long size)
 {
-	return memblock_phys_alloc(size, 0);
+	return memblock_phys_alloc(size, SMP_CACHE_BYTES);
 }
 
 static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)
-- 
2.7.4

 

-- 
Sincerely yours,
Mike.

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: linux-next: Tree for Oct 15
Date: Tue, 16 Oct 2018 16:36:56 +0300	[thread overview]
Message-ID: <20181016133656.GA10925@rapoport-lnx> (raw)
In-Reply-To: <20181015151319.3a443f0421c20bd7ed055cb9@linux-foundation.org>

On Mon, Oct 15, 2018 at 03:13:19PM -0700, Andrew Morton wrote:
> On Tue, 16 Oct 2018 07:24:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > 
> > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > 
> > That is:
> > 
> > static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> >                                         phys_addr_t align, phys_addr_t start,
> >                                         phys_addr_t end, int nid,
> >                                         enum memblock_flags flags)
> > {
> >        if (WARN_ON_ONCE(!align))
> >                 align = SMP_CACHE_BYTES;
> > 
> > Looks like patch
> > 
> >   "memblock: stop using implicit alignment to SMP_CACHE_BYTES"
> > 
> > missed some places ...
> 
> To be expected, I guess.  I'm pretty relaxed about this ;) Let's do
> another sweep in a week or so, after which we'll have a couple of
> months to mop up any leftovers.

After some more grepping and spatching I've found these:

From 8b014bae53a78ab747dbb76b9aff7df4cefcb604 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Tue, 16 Oct 2018 16:03:00 +0300
Subject: [PATCH] memblock: fix missed uses of implicit aligment

A couple of memblock*alloc uses were missed during conversion from implicit
alignment setting with 'align = 0' to explictly using SMP_CACHE_BYTES.
Fix them now.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/powerpc/kernel/paca.c    | 2 +-
 drivers/firmware/efi/memmap.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f331a00..913bfca 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -198,7 +198,7 @@ void __init allocate_paca_ptrs(void)
 	paca_nr_cpu_ids = nr_cpu_ids;
 
 	paca_ptrs_size = sizeof(struct paca_struct *) * nr_cpu_ids;
-	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, 0));
+	paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, SMP_CACHE_BYTES));
 	memset(paca_ptrs, 0x88, paca_ptrs_size);
 }
 
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index ef618bc..fa2904f 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -15,7 +15,7 @@
 
 static phys_addr_t __init __efi_memmap_alloc_early(unsigned long size)
 {
-	return memblock_phys_alloc(size, 0);
+	return memblock_phys_alloc(size, SMP_CACHE_BYTES);
 }
 
 static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)
-- 
2.7.4

 

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2018-10-16 13:37 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15  8:25 linux-next: Tree for Oct 15 Stephen Rothwell
2018-10-15 18:26 ` Guenter Roeck
2018-10-15 20:12   ` Stephen Rothwell
2018-10-15 20:12     ` Stephen Rothwell
2018-10-15 20:24     ` Stephen Rothwell
2018-10-15 20:24       ` Stephen Rothwell
2018-10-15 22:13       ` Andrew Morton
2018-10-15 22:13         ` Andrew Morton
2018-10-16 13:36         ` Mike Rapoport [this message]
2018-10-16 13:36           ` Mike Rapoport
2018-10-16 13:36           ` Mike Rapoport
2018-10-16 20:41           ` Stephen Rothwell
2018-10-16 20:41             ` Stephen Rothwell
2018-10-15 20:35     ` Rob Herring
2018-10-15 20:35       ` Rob Herring
2018-10-15 21:18       ` Guenter Roeck
2018-10-15 21:18         ` Guenter Roeck
2018-10-15 21:48         ` Rob Herring
2018-10-15 21:48           ` Rob Herring
2018-10-15 22:10           ` Guenter Roeck
2018-10-15 22:10             ` Guenter Roeck
2018-10-15 22:13             ` Rob Herring
2018-10-15 22:13               ` Rob Herring
2018-10-15 22:28               ` Guenter Roeck
2018-10-15 22:28                 ` Guenter Roeck
2018-10-15 22:34               ` Guenter Roeck
2018-10-15 22:34                 ` Guenter Roeck
2018-10-15 22:52                 ` Rob Herring
2018-10-15 22:52                   ` Rob Herring
2018-10-16  1:00       ` Rob Herring
2018-10-16  1:00         ` Rob Herring
2018-10-16  1:34         ` David Miller
2018-10-16  1:34           ` David Miller
2018-10-15 19:39 ` Guenter Roeck
2018-10-15 20:33   ` Stephen Rothwell
2018-10-15 20:33     ` Stephen Rothwell
2018-10-15 21:35     ` Guenter Roeck
2018-10-15 21:35       ` Guenter Roeck
2018-10-15 22:22     ` Guenter Roeck
2018-10-15 22:22       ` Guenter Roeck
2018-10-16  2:02       ` Stephen Rothwell
2018-10-16  2:02         ` Stephen Rothwell
2018-10-16  2:19         ` Stephen Rothwell
2018-10-16  2:19           ` Stephen Rothwell
2018-10-16  3:12           ` Benjamin Herrenschmidt
2018-10-16  3:12             ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2021-10-15 10:06 Stephen Rothwell
2020-10-15  7:28 Stephen Rothwell
2019-10-15  5:16 Stephen Rothwell
2015-10-15  7:51 Stephen Rothwell
2014-10-15  4:29 Stephen Rothwell
2013-10-15 14:02 Thierry Reding
2013-10-16  5:21 ` Guenter Roeck
2013-10-16 15:50   ` Thierry Reding
2013-10-16 16:37     ` Guenter Roeck
2013-10-16 16:43       ` Thierry Reding
2012-10-15  2:41 Stephen Rothwell
2012-10-15  2:41 ` Stephen Rothwell
2008-10-15 10:58 linux-next tree " Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181016133656.GA10925@rapoport-lnx \
    --to=rppt@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=robherring2@gmail.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.