<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arc/include/asm/page.h, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-05-10T19:38:59Z</updated>
<entry>
<title>ARC: mm: PAE: use 40-bit physical page mask</title>
<updated>2021-05-10T19:38:59Z</updated>
<author>
<name>Vladimir Isaev</name>
</author>
<published>2021-04-27T12:12:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5f756d8c6265ebb1736a7787231f010a3b782e5'/>
<id>urn:sha1:c5f756d8c6265ebb1736a7787231f010a3b782e5</id>
<content type='text'>
32-bit PAGE_MASK can not be used as a mask for physical addresses
when PAE is enabled. PAGE_MASK_PHYS must be used for physical
addresses instead of PAGE_MASK.

Without this, init gets SIGSEGV if pte_modify was called:

| potentially unexpected fatal signal 11.
| Path: /bin/busybox
| CPU: 0 PID: 1 Comm: init Not tainted 5.12.0-rc5-00003-g1e43c377a79f-dirty
| Insn could not be fetched
|     @No matching VMA found
|  ECR: 0x00040000 EFA: 0x00000000 ERET: 0x00000000
| STAT: 0x80080082 [IE U     ]   BTA: 0x00000000
|  SP: 0x5f9ffe44  FP: 0x00000000 BLK: 0xaf3d4
| LPS: 0x000d093e LPE: 0x000d0950 LPC: 0x00000000
| r00: 0x00000002 r01: 0x5f9fff14 r02: 0x5f9fff20
| ...
| Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Signed-off-by: Vladimir Isaev &lt;isaev@synopsys.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>arch/arc: add copy_user_page() to &lt;asm/page.h&gt; to fix build error on ARC</title>
<updated>2021-01-05T20:59:40Z</updated>
<author>
<name>Randy Dunlap</name>
</author>
<published>2021-01-05T03:44:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a48c0a3360bf2bf4f40c980d0ec216e770e58ee'/>
<id>urn:sha1:8a48c0a3360bf2bf4f40c980d0ec216e770e58ee</id>
<content type='text'>
fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.

Provide copy_user_page() in &lt;asm/page.h&gt;.

../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: linux-snps-arc@lists.infradead.org
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
#Acked-by: Vineet Gupta &lt;vgupta@synopsys.com&gt; # v1
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
#Reviewed-by: Ira Weiny &lt;ira.weiny@intel.com&gt; # v2
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM</title>
<updated>2020-12-15T20:13:42Z</updated>
<author>
<name>Mike Rapoport</name>
</author>
<published>2020-12-15T03:10:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=050b2da268f8fc4f8123f6462c430a61547b2f7b'/>
<id>urn:sha1:050b2da268f8fc4f8123f6462c430a61547b2f7b</id>
<content type='text'>
Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
space on systems with 2 memory banks. While DISCONTIGMEM avoids wasting
memory on unpopulated memory map, it adds both memory and CPU overhead
relatively to FLATMEM. Moreover, DISCONTINGMEM is generally considered
deprecated.

The obvious replacement for DISCONTIGMEM would be SPARSEMEM, but it is also
less efficient than FLATMEM in pfn_to_page() and page_to_pfn() conversions.
Besides it requires tuning of SECTION_SIZE which is not trivial for
possible ARC memory configuration.

Since the memory map for both banks is always allocated from the "lowmem"
bank, it is possible to use FLATMEM for two-bank configuration and simply
free the unused hole in the memory map. All is required for that is to
provide ARC-specific pfn_valid() that will take into account actual
physical memory configuration and define HAVE_ARCH_PFN_VALID.

The resulting kernel image configured with defconfig + HIGHMEM=y is
smaller:

  $ size a/vmlinux b/vmlinux
     text    data     bss     dec     hex filename
  4673503 1245456  279756 6198715  5e95bb a/vmlinux
  4658706 1246864  279756 6185326  5e616e b/vmlinux

  $ ./scripts/bloat-o-meter a/vmlinux b/vmlinux
  add/remove: 28/30 grow/shrink: 42/399 up/down: 10986/-29025 (-18039)
  ...
  Total: Before=4709315, After = 4691276, chg -0.38%

Booting nSIM with haps_ns.dts results in the following memory usage
reports:

  a:
  Memory: 1559104K/1572864K available (3531K kernel code, 595K rwdata, 752K rodata, 136K init, 275K bss, 13760K reserved, 0K cma-reserved, 1048576K highmem)

  b:
  Memory: 1559112K/1572864K available (3519K kernel code, 594K rwdata, 752K rodata, 136K init, 280K bss, 13752K reserved, 0K cma-reserved, 1048576K highmem)

Link: https://lkml.kernel.org/r/20201101170454.9567-11-rppt@kernel.org
Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Greg Ungerer &lt;gerg@linux-m68k.org&gt;
Cc: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Matt Turner &lt;mattst88@gmail.com&gt;
Cc: Meelis Roos &lt;mroos@linux.ee&gt;
Cc: Michael Schmitz &lt;schmitzmic@gmail.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm/vma: define a default value for VM_DATA_DEFAULT_FLAGS</title>
<updated>2020-04-10T22:36:21Z</updated>
<author>
<name>Anshuman Khandual</name>
</author>
<published>2020-04-10T21:33:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c62da0c35d58518ddb26ff641d2485596567fd96'/>
<id>urn:sha1:c62da0c35d58518ddb26ff641d2485596567fd96</id>
<content type='text'>
There are many platforms with exact same value for VM_DATA_DEFAULT_FLAGS
This creates a default value for VM_DATA_DEFAULT_FLAGS in line with the
existing VM_STACK_DEFAULT_FLAGS.  While here, also define some more
macros with standard VMA access flag combinations that are used
frequently across many platforms.  Apart from simplification, this
reduces code duplication as well.

Signed-off-by: Anshuman Khandual &lt;anshuman.khandual@arm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Reviewed-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Mark Salter &lt;msalter@redhat.com&gt;
Cc: Guo Ren &lt;guoren@kernel.org&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Brian Cain &lt;bcain@codeaurora.org&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: Nick Hu &lt;nickhu@andestech.com&gt;
Cc: Ley Foon Tan &lt;ley.foon.tan@intel.com&gt;
Cc: Jonas Bonn &lt;jonas@southpole.se&gt;
Cc: "James E.J. Bottomley" &lt;James.Bottomley@HansenPartnership.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Guan Xuetao &lt;gxt@pku.edu.cn&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Jeff Dike &lt;jdike@addtoit.com&gt;
Cc: Chris Zankel &lt;chris@zankel.net&gt;
Link: http://lkml.kernel.org/r/1583391014-8170-2-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500</title>
<updated>2019-06-19T15:09:55Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2019-06-04T08:11:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d2912cb15bdda8ba4a5dd73396ad62641af2f520'/>
<id>urn:sha1:d2912cb15bdda8ba4a5dd73396ad62641af2f520</id>
<content type='text'>
Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Enrico Weigelt &lt;info@metux.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ARC: mm: allow mprotect to make stack mappings executable</title>
<updated>2018-07-11T18:03:06Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2018-07-11T17:42:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=93312b6da4df31e4102ce5420e6217135a16c7ea'/>
<id>urn:sha1:93312b6da4df31e4102ce5420e6217135a16c7ea</id>
<content type='text'>
mprotect(EXEC) was failing for stack mappings as default vm flags was
missing MAYEXEC.

This was triggered by glibc test suite nptl/tst-execstack testcase

What is surprising is that despite running LTP for years on, we didn't
catch this issue as it lacks a directed test case.

gcc dejagnu tests with nested functions also requiring exec stack work
fine though because they rely on the GNU_STACK segment spit out by
compiler and handled in kernel elf loader.

This glibc case is different as the stack is non exec to begin with and
a dlopen of shared lib with GNU_STACK segment triggers the exec stack
proceedings using a mprotect(PROT_EXEC) which was broken.

CC: stable@vger.kernel.org
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARC: mm: Decouple RAM base address from kernel link address</title>
<updated>2017-09-01T18:26:27Z</updated>
<author>
<name>Eugeniy Paltsev</name>
</author>
<published>2017-08-15T18:13:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ed68785f7f2b001a6911d64fbd10cfc6fa49b27'/>
<id>urn:sha1:9ed68785f7f2b001a6911d64fbd10cfc6fa49b27</id>
<content type='text'>
	[Needed for HSDK]

Currently the first page of system (hence RAM base) is assumed to be
@ CONFIG_LINUX_LINK_BASE, where kernel itself is linked.

However is case of HSDK platform, for reasons explained in that patch,
this is not true. kernel needs to be linked @ 0x9000_0000 while DDR
is still wired at 0x8000_0000. To properly account for this 256M of RAM,
we need to introduce a new option and base page frame accountiing off of
it.

Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
[vgupta: renamed  CONFIG_KERNEL_RAM_BASE_ADDRESS =&gt; CONFIG_LINUX_RAM_BASE
       : simplified changelog]
</content>
</entry>
<entry>
<title>ARC: pae: STRICT_MM_TYPECHECKS was broken</title>
<updated>2016-05-13T03:46:09Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2016-05-03T09:23:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5035cd5b666b7378e32e1985225aae5746a59ac9'/>
<id>urn:sha1:5035cd5b666b7378e32e1985225aae5746a59ac9</id>
<content type='text'>
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARC: support HIGHMEM even without PAE40</title>
<updated>2016-05-05T11:05:46Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2016-04-18T05:19:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=26f9d5fd82ca20fe536cb493ec7cf5628f8997e5'/>
<id>urn:sha1:26f9d5fd82ca20fe536cb493ec7cf5628f8997e5</id>
<content type='text'>
Initial HIGHMEM support on ARC was introduced for PAE40 where the low
memory (0x8000_0000 based) and high memory (0x1_0000_0000) were
physically contiguous. So CONFIG_FLATMEM sufficed (despite a peipheral
hole in the middle, which wasted a bit of struct page memory, but things
worked).

However w/o PAE, highmem was not possible and we could only reach
~1.75GB of DDR. Now there is a use case to access ~4GB of DDR w/o PAE40
The idea is to have low memory at canonical 0x8000_0000 and highmem
at 0 so enire 4GB address space is available for physical addressing
This needs additional platform/interconnect mapping to convert
the non contiguous physical addresses into linear bus adresses.

From Linux point of view, non contiguous divide means FLATMEM no
longer works and DISCONTIGMEM is needed to track the pfns in the 2
regions.

This scheme would also work for PAE40, only better in that we don't
waste struct page memory for the peripheral hole.

The DT description will be something like

    memory {
        ...
        reg = &lt;0x80000000 0x200000000   /* 512MB: lowmem */
               0x00000000 0x10000000&gt;;  /* 256MB: highmem */
   }

Signed-off-by: Noam Camus &lt;noamc@ezchip.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARC: Fix PAE40 boot failures due to PTE truncation</title>
<updated>2016-05-05T11:05:45Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2016-05-05T09:23:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2519d753676bdf2460fbbcde276d5b6ba8d6b695'/>
<id>urn:sha1:2519d753676bdf2460fbbcde276d5b6ba8d6b695</id>
<content type='text'>
So a benign looking cleanup which macro'ized PAGE_SHIFT shifts turned
out to be bad (since it was done non-sensically across the board).

It caused boot failures with PAE40 as forced cast to (unsigned long)
from newly introduced virt_to_pfn() was causing truncatiion of the
(long long) pte/paddr values.

It is OK to use this in accessors dealing with kernel virtual address,
pointers etc, but not for PTE values themelves.

Fixes: cJ2ff5cf2735c ("ARC: mm: Use virt_to_pfn() for addr &gt;&gt; PAGE_SHIFT pattern)
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
</feed>
