<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/Documentation/features/debug/KASAN, branch v6.6.132</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>LoongArch: Add KASAN (Kernel Address Sanitizer) support</title>
<updated>2023-09-06T14:54:16+00:00</updated>
<author>
<name>Qing Zhang</name>
<email>zhangqing@loongson.cn</email>
</author>
<published>2023-09-06T14:54:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5aa4ac64e6add3e40d5049e31275b2822daf885d'/>
<id>5aa4ac64e6add3e40d5049e31275b2822daf885d</id>
<content type='text'>
1/8 of kernel addresses reserved for shadow memory. But for LoongArch,
There are a lot of holes between different segments and valid address
space (256T available) is insufficient to map all these segments to kasan
shadow memory with the common formula provided by kasan core, saying
(addr &gt;&gt; KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET

So LoongArch has a arch-specific mapping formula, different segments are
mapped individually, and only limited space lengths of these specific
segments are mapped to shadow.

At early boot stage the whole shadow region populated with just one
physical page (kasan_early_shadow_page). Later, this page is reused as
readonly zero shadow for some memory that kasan currently don't track.
After mapping the physical memory, pages for shadow memory are allocated
and mapped.

Functions like memset()/memcpy()/memmove() do a lot of memory accesses.
If bad pointer passed to one of these function it is important to be
caught. Compiler's instrumentation cannot do this since these functions
are written in assembly.

KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions in
mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in names, so we could call non-instrumented variant
if needed.

Signed-off-by: Qing Zhang &lt;zhangqing@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
1/8 of kernel addresses reserved for shadow memory. But for LoongArch,
There are a lot of holes between different segments and valid address
space (256T available) is insufficient to map all these segments to kasan
shadow memory with the common formula provided by kasan core, saying
(addr &gt;&gt; KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET

So LoongArch has a arch-specific mapping formula, different segments are
mapped individually, and only limited space lengths of these specific
segments are mapped to shadow.

At early boot stage the whole shadow region populated with just one
physical page (kasan_early_shadow_page). Later, this page is reused as
readonly zero shadow for some memory that kasan currently don't track.
After mapping the physical memory, pages for shadow memory are allocated
and mapped.

Functions like memset()/memcpy()/memmove() do a lot of memory accesses.
If bad pointer passed to one of these function it is important to be
caught. Compiler's instrumentation cannot do this since these functions
are written in assembly.

KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions in
mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in names, so we could call non-instrumented variant
if needed.

Signed-off-by: Qing Zhang &lt;zhangqing@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/features: Use loongarch instead of loong</title>
<updated>2022-12-05T09:50:12+00:00</updated>
<author>
<name>Tiezhu Yang</name>
<email>yangtiezhu@loongson.cn</email>
</author>
<published>2022-12-04T12:18:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=cc8c418b4fc09ed58ddd27b8e90ec797e9ca1e67'/>
<id>cc8c418b4fc09ed58ddd27b8e90ec797e9ca1e67</id>
<content type='text'>
The official arch name is LoongArch [1], we should use small letter
loongarch instead of loong in Documentation/features, just use the
features-refresh.sh to refresh all the related files.

[1] https://www.kernel.org/doc/html/latest/loongarch/index.html

Fixes: 5860800e8696 ("Documentation/features: Update the arch support status files")
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Link: https://lore.kernel.org/r/1670156327-9631-3-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The official arch name is LoongArch [1], we should use small letter
loongarch instead of loong in Documentation/features, just use the
features-refresh.sh to refresh all the related files.

[1] https://www.kernel.org/doc/html/latest/loongarch/index.html

Fixes: 5860800e8696 ("Documentation/features: Update the arch support status files")
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Link: https://lore.kernel.org/r/1670156327-9631-3-git-send-email-yangtiezhu@loongson.cn
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/features: Update feature lists for 6.1</title>
<updated>2022-12-03T10:54:20+00:00</updated>
<author>
<name>Wei Li</name>
<email>liwei391@huawei.com</email>
</author>
<published>2022-12-03T09:37:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=7f2e60ff51caf511b9215e0b9fc47ee620ecbb66'/>
<id>7f2e60ff51caf511b9215e0b9fc47ee620ecbb66</id>
<content type='text'>
Run the refresh script to document the recent feature additions
on loong, um and csky as of v6.1-rc7.

Signed-off-by: Wei Li &lt;liwei391@huawei.com&gt;
Link: https://lore.kernel.org/r/20221203093750.4145802-1-liwei391@huawei.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Run the refresh script to document the recent feature additions
on loong, um and csky as of v6.1-rc7.

Signed-off-by: Wei Li &lt;liwei391@huawei.com&gt;
Link: https://lore.kernel.org/r/20221203093750.4145802-1-liwei391@huawei.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/features: Update the arch support status files</title>
<updated>2022-06-09T15:35:57+00:00</updated>
<author>
<name>Zheng Zengkai</name>
<email>zhengzengkai@huawei.com</email>
</author>
<published>2022-06-09T02:56:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5860800e8696d2cbbd1a0dd60b433549d176e668'/>
<id>5860800e8696d2cbbd1a0dd60b433549d176e668</id>
<content type='text'>
The arch support status files don't match reality as of v5.19-rc1,
use the features-refresh.sh to refresh all the arch-support.txt files
in place.  The main effect is to add entries for the new loong
architecture.

Signed-off-by: Zheng Zengkai &lt;zhengzengkai@huawei.com&gt;
Link: https://lore.kernel.org/r/20220609025656.143460-1-zhengzengkai@huawei.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The arch support status files don't match reality as of v5.19-rc1,
use the features-refresh.sh to refresh all the arch-support.txt files
in place.  The main effect is to add entries for the new loong
architecture.

Signed-off-by: Zheng Zengkai &lt;zhengzengkai@huawei.com&gt;
Link: https://lore.kernel.org/r/20220609025656.143460-1-zhengzengkai@huawei.com
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'remove-h8300' of git://git.infradead.org/users/hch/misc into asm-generic</title>
<updated>2022-04-04T12:42:49+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2022-04-04T12:42:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fba2689ee77e63b05e203b3f26079ef915e55660'/>
<id>fba2689ee77e63b05e203b3f26079ef915e55660</id>
<content type='text'>
* 'remove-h8300' of git://git.infradead.org/users/hch/misc:
  remove the h8300 architecture

This is clearly the least actively maintained architecture we have at
the moment, and probably the least useful. It is now the only one that
does not support MMUs at all, and most of the boards only support 4MB
of RAM, out of which the defconfig kernel needs more than half just
for .text/.data.

Guenter Roeck did the original patch to remove the architecture in 2013
after it had already been obsolete for a while, and Yoshinori Sato brought
it back in a much more modern form in 2015. Looking at the git history
since the reinstantiation, it's clear that almost all commits in the tree
are build fixes or cross-architecture cleanups:

$ git log --no-merges --format=%an v4.5.. arch/h8300/  | sort | uniq
-c | sort -rn | head -n 12
     25 Masahiro Yamada
     18 Christoph Hellwig
     14 Mike Rapoport
      9 Arnd Bergmann
      8 Mark Rutland
      7 Peter Zijlstra
      6 Kees Cook
      6 Ingo Molnar
      6 Al Viro
      5 Randy Dunlap
      4 Yury Norov

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'remove-h8300' of git://git.infradead.org/users/hch/misc:
  remove the h8300 architecture

This is clearly the least actively maintained architecture we have at
the moment, and probably the least useful. It is now the only one that
does not support MMUs at all, and most of the boards only support 4MB
of RAM, out of which the defconfig kernel needs more than half just
for .text/.data.

Guenter Roeck did the original patch to remove the architecture in 2013
after it had already been obsolete for a while, and Yoshinori Sato brought
it back in a much more modern form in 2015. Looking at the git history
since the reinstantiation, it's clear that almost all commits in the tree
are build fixes or cross-architecture cleanups:

$ git log --no-merges --format=%an v4.5.. arch/h8300/  | sort | uniq
-c | sort -rn | head -n 12
     25 Masahiro Yamada
     18 Christoph Hellwig
     14 Mike Rapoport
      9 Arnd Bergmann
      8 Mark Rutland
      7 Peter Zijlstra
      6 Kees Cook
      6 Ingo Molnar
      6 Al Viro
      5 Randy Dunlap
      4 Yury Norov

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nds32: Remove the architecture</title>
<updated>2022-03-07T12:54:59+00:00</updated>
<author>
<name>Alan Kao</name>
<email>alankao@andestech.com</email>
</author>
<published>2022-03-02T07:42:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f'/>
<id>aec499c75cf8e0b599be4d559e6922b613085f8f</id>
<content type='text'>
The nds32 architecture, also known as AndeStar V3, is a custom 32-bit
RISC target designed by Andes Technologies. Support was added to the
kernel in 2016 as the replacement RISC-V based V5 processors were
already announced, and maintained by (current or former) Andes
employees.

As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.

While the port is still in a reasonably good shape, it only gets
worse over time without active maintainers, so it seems best
to remove it before it becomes unusable. As always, if it turns
out that there are mainline users after all, and they volunteer
to maintain the port in the future, the removal can be reverted.

Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/
Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/
Link: https://www.andestech.com/en/products-solutions/andestar-architecture/
Signed-off-by: Alan Kao &lt;alankao@andestech.com&gt;
[arnd: rewrite changelog to provide more background]
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The nds32 architecture, also known as AndeStar V3, is a custom 32-bit
RISC target designed by Andes Technologies. Support was added to the
kernel in 2016 as the replacement RISC-V based V5 processors were
already announced, and maintained by (current or former) Andes
employees.

As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.

While the port is still in a reasonably good shape, it only gets
worse over time without active maintainers, so it seems best
to remove it before it becomes unusable. As always, if it turns
out that there are mainline users after all, and they volunteer
to maintain the port in the future, the removal can be reverted.

Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/
Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/
Link: https://www.andestech.com/en/products-solutions/andestar-architecture/
Signed-off-by: Alan Kao &lt;alankao@andestech.com&gt;
[arnd: rewrite changelog to provide more background]
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>remove the h8300 architecture</title>
<updated>2022-02-23T07:52:50+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2022-02-23T07:47:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1c4b5ecb7ea190fa3e9f9d6891e6c90b60e04f24'/>
<id>1c4b5ecb7ea190fa3e9f9d6891e6c90b60e04f24</id>
<content type='text'>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation: features: remove c6x references</title>
<updated>2021-02-25T18:25:57+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2021-02-25T14:27:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4f3c8320c78cdd11c8fdd23c33787407f719322e'/>
<id>4f3c8320c78cdd11c8fdd23c33787407f719322e</id>
<content type='text'>
The references to arch/c6x are obsolete now that the architecture
is gone. Remove them.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/20210225142841.3385428-1-arnd@kernel.org
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The references to arch/c6x are obsolete now that the architecture
is gone. Remove them.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/20210225142841.3385428-1-arnd@kernel.org
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 9017/2: Enable KASan for ARM</title>
<updated>2020-10-27T12:11:11+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2020-10-25T22:56:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=421015713b306e47af95d4d61cdfbd96d462e4cb'/>
<id>421015713b306e47af95d4d61cdfbd96d462e4cb</id>
<content type='text'>
This patch enables the kernel address sanitizer for ARM. XIP_KERNEL
has not been tested and is therefore not allowed for now.

Cc: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Cc: Alexander Potapenko &lt;glider@google.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: kasan-dev@googlegroups.com
Acked-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Tested-by: Ard Biesheuvel &lt;ardb@kernel.org&gt; # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt; # Brahma SoCs
Tested-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt; # i.MX6Q
Signed-off-by: Abbott Liu &lt;liuwenliang@huawei.com&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch enables the kernel address sanitizer for ARM. XIP_KERNEL
has not been tested and is therefore not allowed for now.

Cc: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Cc: Alexander Potapenko &lt;glider@google.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: kasan-dev@googlegroups.com
Acked-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Tested-by: Ard Biesheuvel &lt;ardb@kernel.org&gt; # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt; # Brahma SoCs
Tested-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt; # i.MX6Q
Signed-off-by: Abbott Liu &lt;liuwenliang@huawei.com&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arch: remove unicore32 port</title>
<updated>2020-07-01T09:09:13+00:00</updated>
<author>
<name>Mike Rapoport</name>
<email>rppt@linux.ibm.com</email>
</author>
<published>2020-06-10T06:45:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fb37409a01b011a664347702f44dbf13fa7c7486'/>
<id>fb37409a01b011a664347702f44dbf13fa7c7486</id>
<content type='text'>
The unicore32 port do not seem maintained for a long time now, there is no
upstream toolchain that can create unicore32 binaries and all the links to
prebuilt toolchains for unicore32 are dead. Even compilers that were
available are not supported by the kernel anymore.

Guenter Roeck says:

  I have stopped building unicore32 images since v4.19 since there is no
  available compiler that is still supported by the kernel. I am surprised
  that support for it has not been removed from the kernel.

Remove unicore32 port.

Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The unicore32 port do not seem maintained for a long time now, there is no
upstream toolchain that can create unicore32 binaries and all the links to
prebuilt toolchains for unicore32 are dead. Even compilers that were
available are not supported by the kernel anymore.

Guenter Roeck says:

  I have stopped building unicore32 images since v4.19 since there is no
  available compiler that is still supported by the kernel. I am surprised
  that support for it has not been removed from the kernel.

Remove unicore32 port.

Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
