linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Rik van Riel <riel@surriel.com>, Michal Hocko <mhocko@kernel.org>,
	<linux-kernel@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up
Date: Mon, 28 Dec 2020 11:36:19 -0800	[thread overview]
Message-ID: <20201228193619.GA317390@carbon.dhcp.thefacebook.com> (raw)
In-Reply-To: <20201223221039.GH392325@kernel.org>

On Thu, Dec 24, 2020 at 12:10:39AM +0200, Mike Rapoport wrote:
> On Wed, Dec 23, 2020 at 08:35:37AM -0800, Roman Gushchin wrote:
> > On Tue, Dec 22, 2020 at 08:06:06PM -0800, Andrew Morton wrote:
> > > On Mon, 21 Dec 2020 09:05:51 -0800 Roman Gushchin <guro@fb.com> wrote:
> > > 
> > > > Subject: [PATCH v3 1/2] mm: cma: allocate cma areas bottom-up
> > > 
> > > i386 allmodconfig:
> > > 
> > > In file included from ./include/vdso/const.h:5,
> > >                  from ./include/linux/const.h:4,
> > >                  from ./include/linux/bits.h:5,
> > >                  from ./include/linux/bitops.h:6,
> > >                  from ./include/linux/kernel.h:11,
> > >                  from ./include/asm-generic/bug.h:20,
> > >                  from ./arch/x86/include/asm/bug.h:93,
> > >                  from ./include/linux/bug.h:5,
> > >                  from ./include/linux/mmdebug.h:5,
> > >                  from ./include/linux/mm.h:9,
> > >                  from ./include/linux/memblock.h:13,
> > >                  from mm/cma.c:24:
> > > mm/cma.c: In function ‘cma_declare_contiguous_nid’:
> > > ./include/uapi/linux/const.h:20:19: warning: conversion from ‘long long unsigned int’ to ‘phys_addr_t’ {aka ‘unsigned int’} changes value from ‘4294967296’ to ‘0’ [-Woverflow]
> > >  #define __AC(X,Y) (X##Y)
> > >                    ^~~~~~
> > > ./include/uapi/linux/const.h:21:18: note: in expansion of macro ‘__AC’
> > >  #define _AC(X,Y) __AC(X,Y)
> > >                   ^~~~
> > > ./include/linux/sizes.h:46:18: note: in expansion of macro ‘_AC’
> > >  #define SZ_4G    _AC(0x100000000, ULL)
> > >                   ^~~
> > > mm/cma.c:349:53: note: in expansion of macro ‘SZ_4G’
> > >     addr = memblock_alloc_range_nid(size, alignment, SZ_4G,
> > >                                                      ^~~~~
> > > 
> > 
> > I thought that (!memblock_bottom_up() && memblock_end >= SZ_4G + size)
> > can't be true on a 32-bit platform, so the whole if clause can be compiled out.
> > Maybe it's because memblock_end can be equal to SZ_4G and if the size == 0...
> > 
> > I have no better idea than wrapping everything into
> > #if BITS_PER_LONG > 32
> > #endif.
> 
> 32-bit systems can have more than 32 bit in the physical address.
> I think a better option would be to use CONFIG_PHYS_ADDR_T_64BIT

I agree. An updated fixup below.

Andrew, can you, please, replace the previous fixup with this one?

Thanks!

--

diff --git a/mm/cma.c b/mm/cma.c
index 4fe74c9d83b0..0ba69cd16aeb 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -344,12 +344,14 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
                 * Avoid using first 4GB to not interfere with constrained zones
                 * like DMA/DMA32.
                 */
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
                if (!memblock_bottom_up() && memblock_end >= SZ_4G + size) {
                        memblock_set_bottom_up(true);
                        addr = memblock_alloc_range_nid(size, alignment, SZ_4G,
                                                        limit, nid, true);
                        memblock_set_bottom_up(false);
                }
+#endif
 
                if (!addr) {
                        addr = memblock_alloc_range_nid(size, alignment, base,


      reply	other threads:[~2020-12-28 19:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 20:12 Roman Gushchin
2020-12-17 20:12 ` [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end Roman Gushchin
2020-12-19 14:52   ` Wonhyuk Yang
2020-12-19 17:05     ` Roman Gushchin
2020-12-20  6:49   ` Mike Rapoport
2021-01-22  4:37     ` Thiago Jung Bauermann
2021-01-24  2:09       ` Andrew Morton
2021-01-24  7:34         ` Mike Rapoport
2021-01-26  0:30           ` Thiago Jung Bauermann
2021-02-08 23:58           ` Thiago Jung Bauermann
2021-02-28  4:18   ` Florian Fainelli
2021-02-28  9:00     ` Mike Rapoport
2021-02-28 18:19       ` Florian Fainelli
2021-02-28 23:08         ` Serge Semin
2021-03-01  3:50           ` Florian Fainelli
2021-03-01  9:22             ` Serge Semin
2021-03-02  4:09               ` Florian Fainelli
2021-03-01  9:45             ` Mike Rapoport
2021-03-02  3:55               ` Roman Gushchin
2020-12-20  6:48 ` [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up Mike Rapoport
2020-12-21 17:05   ` Roman Gushchin
2020-12-23  4:06     ` Andrew Morton
2020-12-23 16:35       ` Roman Gushchin
2020-12-23 22:10         ` Mike Rapoport
2020-12-28 19:36           ` Roman Gushchin [this message]

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=20201228193619.GA317390@carbon.dhcp.thefacebook.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox