From: Mike Rapoport <rppt@kernel.org>
To: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux@armlinux.org.uk, linux@roeck-us.net,
matthias.bgg@gmail.com, rmk+kernel@armlinux.org.uk,
wangkefeng.wang@huawei.com, yj.chiang@mediatek.com
Subject: Re: [PATCH] arm: remove [_text, _stext) from kernel code resource
Date: Wed, 8 Dec 2021 11:43:23 +0200 [thread overview]
Message-ID: <YbB+O80Th2QI8sTl@kernel.org> (raw)
In-Reply-To: <20211208022623.15103-1-mark-pk.tsai@mediatek.com>
On Wed, Dec 08, 2021 at 10:26:23AM +0800, Mark-PK Tsai wrote:
> > On Fri, Dec 03, 2021 at 10:14:16PM +0800, Mark-PK Tsai wrote:
> > > Remove the [_text, _stext) from Kernel Code.
> > > Although there are some startup code in head.text, they
> > > are freed to the buddy system after kernel boot.
> >
> > Hmm, I don't see it is being freed anywhere. Can you elaborate when and how
> > the range [_text, _stext) is freed?
>
> arm_memblock_init() reserve [KERNEL_START, KERNEL_END) which are defined as following.
>
> #define KERNEL_START _stext
> #define KERNEL_END _end
>
> free_low_memory_core_early() free all the non-reserved range in lowmem,
> so the range [_text, _stext) is also freed here.
Right, I've misread KERNEL_START as if it was _text...
> >
> > > And we have memory protection mechanism use this
> > > which have false alarm when some other IPs doing dma
> > > if the dma page frame is in the [_text, _stext).
> > >
> > > Below are my iomem resource and reserved memory information:
> > > console:/ # grep Kernel /proc/iomem
> > > 20208000-219fffff : Kernel code
> > > 21b00000-21c2e76f : Kernel data
> > >
> > > console:/ # cat /sys/kernel/debug/memblock/reserved
> > > 0: 0x20201000..0x20207fff
> > > 1: 0x20300000..0x21c2e76f
> >
> > What are the addresses of _text and _stext in your configuration?
>
> va pa
> c0008000 20208000 _text
> c0100000 20300000 _stext
>
> >
> > What these dumps are supposed to show here?
> >
>
> Below is the dump info after applied this patch.
>
> console:/ # grep Kernel /proc/iomem
> 20300000-219fffff : Kernel code
> 21b00000-21c2e76f : Kernel data
>
> console:/ # cat /sys/kernel/debug/memblock/reserved
> 0: 0x20201000..0x20207fff
> 1: 0x20300000..0x21c2e76f
>
> The difference is that Kernel Code resource match the reserved memblock 1
> which is reserved in arm_memblock_init().
For that I'd extend the reservation in arm_memblock_init() to include
[_text, _stext).
Even if the code there is not needed after init, at least we'll keep this
consistent with other architectures.
--
Sincerely yours,
Mike.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux@armlinux.org.uk, linux@roeck-us.net,
matthias.bgg@gmail.com, rmk+kernel@armlinux.org.uk,
wangkefeng.wang@huawei.com, yj.chiang@mediatek.com
Subject: Re: [PATCH] arm: remove [_text, _stext) from kernel code resource
Date: Wed, 8 Dec 2021 11:43:23 +0200 [thread overview]
Message-ID: <YbB+O80Th2QI8sTl@kernel.org> (raw)
In-Reply-To: <20211208022623.15103-1-mark-pk.tsai@mediatek.com>
On Wed, Dec 08, 2021 at 10:26:23AM +0800, Mark-PK Tsai wrote:
> > On Fri, Dec 03, 2021 at 10:14:16PM +0800, Mark-PK Tsai wrote:
> > > Remove the [_text, _stext) from Kernel Code.
> > > Although there are some startup code in head.text, they
> > > are freed to the buddy system after kernel boot.
> >
> > Hmm, I don't see it is being freed anywhere. Can you elaborate when and how
> > the range [_text, _stext) is freed?
>
> arm_memblock_init() reserve [KERNEL_START, KERNEL_END) which are defined as following.
>
> #define KERNEL_START _stext
> #define KERNEL_END _end
>
> free_low_memory_core_early() free all the non-reserved range in lowmem,
> so the range [_text, _stext) is also freed here.
Right, I've misread KERNEL_START as if it was _text...
> >
> > > And we have memory protection mechanism use this
> > > which have false alarm when some other IPs doing dma
> > > if the dma page frame is in the [_text, _stext).
> > >
> > > Below are my iomem resource and reserved memory information:
> > > console:/ # grep Kernel /proc/iomem
> > > 20208000-219fffff : Kernel code
> > > 21b00000-21c2e76f : Kernel data
> > >
> > > console:/ # cat /sys/kernel/debug/memblock/reserved
> > > 0: 0x20201000..0x20207fff
> > > 1: 0x20300000..0x21c2e76f
> >
> > What are the addresses of _text and _stext in your configuration?
>
> va pa
> c0008000 20208000 _text
> c0100000 20300000 _stext
>
> >
> > What these dumps are supposed to show here?
> >
>
> Below is the dump info after applied this patch.
>
> console:/ # grep Kernel /proc/iomem
> 20300000-219fffff : Kernel code
> 21b00000-21c2e76f : Kernel data
>
> console:/ # cat /sys/kernel/debug/memblock/reserved
> 0: 0x20201000..0x20207fff
> 1: 0x20300000..0x21c2e76f
>
> The difference is that Kernel Code resource match the reserved memblock 1
> which is reserved in arm_memblock_init().
For that I'd extend the reservation in arm_memblock_init() to include
[_text, _stext).
Even if the code there is not needed after init, at least we'll keep this
consistent with other architectures.
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux@armlinux.org.uk, linux@roeck-us.net,
matthias.bgg@gmail.com, rmk+kernel@armlinux.org.uk,
wangkefeng.wang@huawei.com, yj.chiang@mediatek.com
Subject: Re: [PATCH] arm: remove [_text, _stext) from kernel code resource
Date: Wed, 8 Dec 2021 11:43:23 +0200 [thread overview]
Message-ID: <YbB+O80Th2QI8sTl@kernel.org> (raw)
In-Reply-To: <20211208022623.15103-1-mark-pk.tsai@mediatek.com>
On Wed, Dec 08, 2021 at 10:26:23AM +0800, Mark-PK Tsai wrote:
> > On Fri, Dec 03, 2021 at 10:14:16PM +0800, Mark-PK Tsai wrote:
> > > Remove the [_text, _stext) from Kernel Code.
> > > Although there are some startup code in head.text, they
> > > are freed to the buddy system after kernel boot.
> >
> > Hmm, I don't see it is being freed anywhere. Can you elaborate when and how
> > the range [_text, _stext) is freed?
>
> arm_memblock_init() reserve [KERNEL_START, KERNEL_END) which are defined as following.
>
> #define KERNEL_START _stext
> #define KERNEL_END _end
>
> free_low_memory_core_early() free all the non-reserved range in lowmem,
> so the range [_text, _stext) is also freed here.
Right, I've misread KERNEL_START as if it was _text...
> >
> > > And we have memory protection mechanism use this
> > > which have false alarm when some other IPs doing dma
> > > if the dma page frame is in the [_text, _stext).
> > >
> > > Below are my iomem resource and reserved memory information:
> > > console:/ # grep Kernel /proc/iomem
> > > 20208000-219fffff : Kernel code
> > > 21b00000-21c2e76f : Kernel data
> > >
> > > console:/ # cat /sys/kernel/debug/memblock/reserved
> > > 0: 0x20201000..0x20207fff
> > > 1: 0x20300000..0x21c2e76f
> >
> > What are the addresses of _text and _stext in your configuration?
>
> va pa
> c0008000 20208000 _text
> c0100000 20300000 _stext
>
> >
> > What these dumps are supposed to show here?
> >
>
> Below is the dump info after applied this patch.
>
> console:/ # grep Kernel /proc/iomem
> 20300000-219fffff : Kernel code
> 21b00000-21c2e76f : Kernel data
>
> console:/ # cat /sys/kernel/debug/memblock/reserved
> 0: 0x20201000..0x20207fff
> 1: 0x20300000..0x21c2e76f
>
> The difference is that Kernel Code resource match the reserved memblock 1
> which is reserved in arm_memblock_init().
For that I'd extend the reservation in arm_memblock_init() to include
[_text, _stext).
Even if the code there is not needed after init, at least we'll keep this
consistent with other architectures.
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2021-12-08 9:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 14:14 [PATCH] arm: remove [_text, _stext) from kernel code resource Mark-PK Tsai
2021-12-03 14:14 ` Mark-PK Tsai
2021-12-03 14:14 ` Mark-PK Tsai
2021-12-07 15:57 ` Mike Rapoport
2021-12-07 15:57 ` Mike Rapoport
2021-12-07 15:57 ` Mike Rapoport
2021-12-08 2:26 ` Mark-PK Tsai
2021-12-08 2:26 ` Mark-PK Tsai
2021-12-08 2:26 ` Mark-PK Tsai
2021-12-08 9:43 ` Mike Rapoport [this message]
2021-12-08 9:43 ` Mike Rapoport
2021-12-08 9:43 ` Mike Rapoport
2021-12-08 10:22 ` Mark-PK Tsai
2021-12-08 10:22 ` Mark-PK Tsai
2021-12-08 10:22 ` Mark-PK Tsai
2021-12-16 15:14 ` Mark-PK Tsai
2021-12-16 15:14 ` Mark-PK Tsai
2021-12-16 15:14 ` Mark-PK Tsai
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=YbB+O80Th2QI8sTl@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linux@roeck-us.net \
--cc=mark-pk.tsai@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=wangkefeng.wang@huawei.com \
--cc=yj.chiang@mediatek.com \
/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.