<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arc/mm, branch linux-4.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-09-27T12:43:19Z</updated>
<entry>
<title>ARC: Re-enable MMU upon Machine Check exception</title>
<updated>2017-09-27T12:43:19Z</updated>
<author>
<name>Jose Abreu</name>
</author>
<published>2017-09-01T16:00:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f37af5560a9206a983ce8022a1bd617dd5f2e3ae'/>
<id>urn:sha1:f37af5560a9206a983ce8022a1bd617dd5f2e3ae</id>
<content type='text'>
commit 1ee55a8f7f6b7ca4c0c59e0b4b4e3584a085c2d3 upstream.

I recently came upon a scenario where I would get a double fault
machine check exception tiriggered by a kernel module.
However the ensuing crash stacktrace (ksym lookup) was not working
correctly.

Turns out that machine check auto-disables MMU while modules are allocated
in kernel vaddr spapce.

This patch re-enables the MMU before start printing the stacktrace
making stacktracing of modules work upon a fatal exception.

Signed-off-by: Jose Abreu &lt;joabreu@synopsys.com&gt;
Reviewed-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
[vgupta: moved code into low level handler to avoid in 2 places]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge tag 'arc-4.13-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc</title>
<updated>2017-08-21T20:30:36Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2017-08-21T20:30:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=05ab303b4f9e7121b120c08081546a25e067b4f4'/>
<id>urn:sha1:05ab303b4f9e7121b120c08081546a25e067b4f4</id>
<content type='text'>
Pull ARC fixes from Vineet Gupta:

 - PAE40 related updates

 - SLC errata for region ops

 - intc line masking by default

* tag 'arc-4.13-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  arc: Mask individual IRQ lines during core INTC init
  ARCv2: PAE40: set MSB even if !CONFIG_ARC_HAS_PAE40 but PAE exists in SoC
  ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses
  ARC: dma: implement dma_unmap_page and sg variant
  ARCv2: SLC: Make sure busy bit is set properly for region ops
  ARC: [plat-sim] Include this platform unconditionally
  ARC: [plat-axs10x]: prepare dts files for enabling PAE40 on axs103
  ARC: defconfig: Cleanup from old Kconfig options
</content>
</entry>
<entry>
<title>ARCv2: PAE40: set MSB even if !CONFIG_ARC_HAS_PAE40 but PAE exists in SoC</title>
<updated>2017-08-04T08:26:35Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2017-08-03T12:15:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b5ddb6d54729d814356937572d6c9b599f10c29f'/>
<id>urn:sha1:b5ddb6d54729d814356937572d6c9b599f10c29f</id>
<content type='text'>
PAE40 confiuration in hardware extends some of the address registers
for TLB/cache ops to 2 words.

So far kernel was NOT setting the higher word if feature was not enabled
in software which is wrong. Those need to be set to 0 in such case.

Normally this would be done in the cache flush / tlb ops, however since
these registers only exist conditionally, this would have to be
conditional to a flag being set on boot which is expensive/ugly -
specially for the more common case of PAE exists but not in use.
Optimize that by zero'ing them once at boot - nobody will write to
them afterwards

Cc: stable@vger.kernel.org   #4.4+
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses</title>
<updated>2017-08-04T08:26:34Z</updated>
<author>
<name>Alexey Brodkin</name>
</author>
<published>2017-08-01T09:58:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7d79cee2c6540ea64dd917a14e2fd63d4ac3d3c0'/>
<id>urn:sha1:7d79cee2c6540ea64dd917a14e2fd63d4ac3d3c0</id>
<content type='text'>
It is necessary to explicitly set both SLC_AUX_RGN_START1 and SLC_AUX_RGN_END1
which hold MSB bits of the physical address correspondingly of region start
and end otherwise SLC region operation is executed in unpredictable manner

Without this patch, SLC flushes on HSDK (IOC disabled) were taking
seconds.

Cc: stable@vger.kernel.org   #4.4+
Reported-by: Vladimir Kondratiev &lt;vladimir.kondratiev@intel.com&gt;
Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
[vgupta: PAR40 regs only written if PAE40 exist]
</content>
</entry>
<entry>
<title>ARC: dma: implement dma_unmap_page and sg variant</title>
<updated>2017-08-04T08:26:33Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2017-07-18T19:14:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e332fec2f2c996f8d5447b0946ca43bb0ae4b42'/>
<id>urn:sha1:2e332fec2f2c996f8d5447b0946ca43bb0ae4b42</id>
<content type='text'>
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARCv2: SLC: Make sure busy bit is set properly for region ops</title>
<updated>2017-08-04T08:20:07Z</updated>
<author>
<name>Alexey Brodkin</name>
</author>
<published>2017-07-07T09:25:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b37174d95b0251611a80ef60abf03752e9d66d67'/>
<id>urn:sha1:b37174d95b0251611a80ef60abf03752e9d66d67</id>
<content type='text'>
c70c473396cb "ARCv2: SLC: Make sure busy bit is set properly on SLC flushing"
fixes problem for entire SLC operation where the problem was initially
caught. But given a nature of the issue it is perfectly possible for
busy bit to be read incorrectly even when region operation was started.

So extending initial fix for regional operation as well.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: stable@vger.kernel.org   #4.10
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>dma-coherent: introduce interface for default DMA pool</title>
<updated>2017-07-20T14:09:10Z</updated>
<author>
<name>Vladimir Murzin</name>
</author>
<published>2017-07-20T10:19:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=43fc509c3efb5c973991ee24c449ab2a0d71dd1e'/>
<id>urn:sha1:43fc509c3efb5c973991ee24c449ab2a0d71dd1e</id>
<content type='text'>
Christoph noticed [1] that default DMA pool in current form overload
the DMA coherent infrastructure. In reply, Robin suggested [2] to
split the per-device vs. global pool interfaces, so allocation/release
from default DMA pool is driven by dma ops implementation.

This patch implements Robin's idea and provide interface to
allocate/release/mmap the default (aka global) DMA pool.

To make it clear that existing *_from_coherent routines work on
per-device pool rename them to *_from_dev_coherent.

[1] https://lkml.org/lkml/2017/7/7/370
[2] https://lkml.org/lkml/2017/7/7/431

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: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Suggested-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Tested-by: Andras Szemzo &lt;sza@esh.hu&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Vladimir Murzin &lt;vladimir.murzin@arm.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>mm: larger stack guard gap, between vmas</title>
<updated>2017-06-19T13:50:20Z</updated>
<author>
<name>Hugh Dickins</name>
</author>
<published>2017-06-19T11:03:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1be7107fbe18eed3e319a6c3e83c78254b693acb'/>
<id>urn:sha1:1be7107fbe18eed3e319a6c3e83c78254b693acb</id>
<content type='text'>
Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Original-patch-by: Michal Hocko &lt;mhocko@suse.com&gt;
Signed-off-by: Hugh Dickins &lt;hughd@google.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Tested-by: Helge Deller &lt;deller@gmx.de&gt; # parisc
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'arc-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc</title>
<updated>2017-05-09T17:10:15Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2017-05-09T17:10:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4a1e31c68e9f40be32838944931178b0d9ed9162'/>
<id>urn:sha1:4a1e31c68e9f40be32838944931178b0d9ed9162</id>
<content type='text'>
Pull ARC updates from Vineet Gupta:

 - AXS10x platform clk updates for I2S, PGU

 - add region based cache flush operation for ARCv2 cores

 - enforce PAE40 dependency on HIGHMEM

 - ptrace support for additional regs in ARCv2 cores

 - fix build failure in linux-next dut to a header include ordering
   change

* tag 'arc-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  Revert "ARCv2: Allow enabling PAE40 w/o HIGHMEM"
  ARC: mm: fix build failure in linux-next for UP builds
  ARCv2: ptrace: provide regset for accumulator/r30 regs
  elf: Add ARCv2 specific core note section
  ARCv2: mm: micro-optimize region flush generated code
  ARCv2: mm: Merge 2 updates to DC_CTRL for region flush
  ARCv2: mm: Implement cache region flush operations
  ARC: mm: Move full_page computation into cache version agnostic wrapper
  arc: axs10x: Fix ARC PGU default clock frequency
  arc: axs10x: Add DT bindings for I2S audio playback
</content>
</entry>
<entry>
<title>ARCv2: mm: Merge 2 updates to DC_CTRL for region flush</title>
<updated>2017-05-02T23:16:07Z</updated>
<author>
<name>Vineet Gupta</name>
</author>
<published>2017-05-02T22:28:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ee40bd1e0c3fb83d810f258952692ffdebc14726'/>
<id>urn:sha1:ee40bd1e0c3fb83d810f258952692ffdebc14726</id>
<content type='text'>
Region Flush has a weird programming model.

 1. Flush or Invalidate is selected by DC_CTRL.RGN_OP
 2 Flush-n-Invalidate is done by DC_CTRL.IM

Given the code structuring before, case #2 above was generating two
seperate updates to DC_CTRL which was pointless.

| 80a342b0 &lt;__dma_cache_wback_inv_l1&gt;:
| 80a342b0:	clri	r4
| 80a342b4:	lr	r2,[dc_ctrl]
| 80a342b8:	bset_s	r2,r2,0x6
| 80a342ba:	sr	r2,[dc_ctrl]	&lt;-- FIRST
|
| 80a342be:	bmskn	r3,r0,0x5
|
| 80a342c2:	lr	r2,[dc_ctrl]
| 80a342c6:	and	r2,r2,0xfffff1ff
| 80a342ce:	bset_s	r2,r2,0x9
| 80a342d0:	sr	r2,[dc_ctrl]	&lt;-- SECOND
|
| 80a342d4:	add_s	r1,r1,0x3f
| 80a342d6:	bmsk_s	r0,r0,0x5
| 80a342d8:	add_s	r0,r0,r1
| 80a342da:	add_s	r0,r0,r3
| 80a342dc:	sr	r0,[78]
| 80a342e0:	sr	r3,[77]
|...
|...

So move setting of DC_CTRL.RGN_OP into __before_dc_op() and combine with
any other update.

| 80b63324 &lt;__dma_cache_wback_inv_l1&gt;:
| 80b63324:	clri	r3
| 80b63328:	lr	r2,[dc_ctrl]
| 80b6332c:	and	r2,r2,0xfffff1ff
| 80b63334:	or	r2,r2,576
| 80b63338:	sr	r2,[dc_ctrl]
|
| 80b6333c:	add_s	r1,r1,0x3f
| 80b6333e:	bmskn	r2,r0,0x5
| 80b63342:	add_s	r0,r0,r1
| 80b63344:	sr	r0,[78]
| 80b63348:	sr	r2,[77]

Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
</feed>
