<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch, branch v4.14.156</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.156</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.156'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-11-24T07:23:34+00:00</updated>
<entry>
<title>powerpc/time: Fix clockevent_decrementer initalisation for PR KVM</title>
<updated>2019-11-24T07:23:34+00:00</updated>
<author>
<name>Michael Ellerman</name>
<email>mpe@ellerman.id.au</email>
</author>
<published>2018-10-17T12:39:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd3cac5198777cabf5ab6a8226148431e42a0ddf'/>
<id>urn:sha1:cd3cac5198777cabf5ab6a8226148431e42a0ddf</id>
<content type='text'>
[ Upstream commit b4d16ab58c41ff0125822464bdff074cebd0fe47 ]

In the recent commit 8b78fdb045de ("powerpc/time: Use
clockevents_register_device(), fixing an issue with large
decrementer") we changed the way we initialise the decrementer
clockevent(s).

We no longer initialise the mult &amp; shift values of
decrementer_clockevent itself.

This has the effect of breaking PR KVM, because it uses those values
in kvmppc_emulate_dec(). The symptom is guest kernels spin forever
mid-way through boot.

For now fix it by assigning back to decrementer_clockevent the mult
and shift values.

Fixes: 8b78fdb045de ("powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer")
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: omap5: Fix dual-role mode on Super-Speed port</title>
<updated>2019-11-24T07:23:33+00:00</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2018-12-05T17:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1dee3a3efdb877419639f3cafb1f91cfcf9c11ab'/>
<id>urn:sha1:1dee3a3efdb877419639f3cafb1f91cfcf9c11ab</id>
<content type='text'>
[ Upstream commit a763ecc15d0e37c3a15ff6825183061209832685 ]

OMAP5's Super-Speed USB port has a software mailbox register
that needs to be fed with VBUS and ID events from an external
VBUS/ID comparator.

Without this, Host role will not work correctly.

Fixes: 656c1a65ab55 ("ARM: dts: omap5: enable OTG role for DWC3 controller")
Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: 8802/1: Call syscall_trace_exit even when system call skipped</title>
<updated>2019-11-24T07:23:30+00:00</updated>
<author>
<name>Timothy E Baldwin</name>
<email>T.E.Baldwin99@members.leeds.ac.uk</email>
</author>
<published>2018-10-08T18:26:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57cae03f53fc4b6c647520532f4d5822f80bcdb3'/>
<id>urn:sha1:57cae03f53fc4b6c647520532f4d5822f80bcdb3</id>
<content type='text'>
[ Upstream commit f18aef742c8fbd68e280dff0a63ba0ca6ee8ad85 ]

On at least x86 and ARM64, and as documented in the ptrace man page
a skipped system call will still cause a syscall exit ptrace stop.

Previous to this commit 32-bit ARM did not, resulting in strace
being confused when seccomp skips system calls.

This change also impacts programs that use ptrace to skip system calls.

Fixes: ad75b51459ae ("ARM: 7579/1: arch/allow a scno of -1 to not cause a SIGILL")
Signed-off-by: Timothy E Baldwin &lt;T.E.Baldwin99@members.leeds.ac.uk&gt;
Signed-off-by: Eugene Syromyatnikov &lt;evgsyr@gmail.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Eugene Syromyatnikov &lt;evgsyr@gmail.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error</title>
<updated>2019-11-24T07:23:27+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2018-09-27T14:21:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1dda24adacd9fc99764a8767c927d3d33e630fc'/>
<id>urn:sha1:f1dda24adacd9fc99764a8767c927d3d33e630fc</id>
<content type='text'>
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]

The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():

  int crash_load_segments(struct kimage *image)
  {
    ...
    walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
                        image, determine_backup_region);

walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.

KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.

Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9ffff], not [0-0xa0000].

Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
CC: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
CC: Andrew Morton &lt;akpm@linux-foundation.org&gt;
CC: Brijesh Singh &lt;brijesh.singh@amd.com&gt;
CC: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
CC: Ingo Molnar &lt;mingo@redhat.com&gt;
CC: Lianbo Jiang &lt;lijiang@redhat.com&gt;
CC: Takashi Iwai &lt;tiwai@suse.de&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
CC: Vivek Goyal &lt;vgoyal@redhat.com&gt;
CC: baiyaowei@cmss.chinamobile.com
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
Link: http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.stgit@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/kasan: avoid vdso instrumentation</title>
<updated>2019-11-24T07:23:23+00:00</updated>
<author>
<name>Vasily Gorbik</name>
<email>gor@linux.ibm.com</email>
</author>
<published>2017-11-17T12:02:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c0be5255a16a4b0fa08363eb6acc72886052affe'/>
<id>urn:sha1:c0be5255a16a4b0fa08363eb6acc72886052affe</id>
<content type='text'>
[ Upstream commit 348498458505e202df41b6b9a78da448d39298b7 ]

vdso is mapped into user space processes, which won't have kasan
shodow mapped.

Reviewed-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/fsgsbase/64: Fix ptrace() to read the FS/GS base accurately</title>
<updated>2019-11-24T07:23:20+00:00</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@kernel.org</email>
</author>
<published>2018-09-18T23:08:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfbcef70a60178af1d18052e5a02e89a53ba8ab9'/>
<id>urn:sha1:bfbcef70a60178af1d18052e5a02e89a53ba8ab9</id>
<content type='text'>
[ Upstream commit 07e1d88adaaeab247b300926f78cc3f950dbeda3 ]

On 64-bit kernels ptrace can read the FS/GS base using the register access
APIs (PTRACE_PEEKUSER, etc.) or PTRACE_ARCH_PRCTL.

Make both of these mechanisms return the actual FS/GS base.

This will improve debuggability by providing the correct information
to ptracer such as GDB.

[ chang: Rebased and revised patch description. ]
[ mingo: Revised the changelog some more. ]

Signed-off-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: Chang S. Bae &lt;chang.seok.bae@intel.com&gt;
Cc: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Markus T Metzger &lt;markus.t.metzger@intel.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Ravi Shankar &lt;ravi.v.shankar@intel.com&gt;
Cc: Rik van Riel &lt;riel@surriel.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/1537312139-5580-2-git-send-email-chang.seok.bae@intel.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/olpc: Fix build error with CONFIG_MFD_CS5535=m</title>
<updated>2019-11-24T07:23:16+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-10-05T13:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4251e64c2287dad32381eee6357860184dc35044'/>
<id>urn:sha1:4251e64c2287dad32381eee6357860184dc35044</id>
<content type='text'>
[ Upstream commit fa112cf1e8bc693d5a666b1c479a2859c8b6e0f1 ]

When building a 32-bit config which has the above MFD item as module
but OLPC_XO1_PM is enabled =y - which is bool, btw - the kernel fails
building with:

  ld: arch/x86/platform/olpc/olpc-xo1-pm.o: in function `xo1_pm_remove':
  /home/boris/kernel/linux/arch/x86/platform/olpc/olpc-xo1-pm.c:159: undefined reference to `mfd_cell_disable'
  ld: arch/x86/platform/olpc/olpc-xo1-pm.o: in function `xo1_pm_probe':
  /home/boris/kernel/linux/arch/x86/platform/olpc/olpc-xo1-pm.c:133: undefined reference to `mfd_cell_enable'
  make: *** [Makefile:1030: vmlinux] Error 1

Force MFD_CS5535 to y if OLPC_XO1_PM is enabled.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20181005131750.GA5366@zn.tnic
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: PPC: Book3S PR: Exiting split hack mode needs to fixup both PC and LR</title>
<updated>2019-11-24T07:23:07+00:00</updated>
<author>
<name>Cameron Kaiser</name>
<email>spectre@floodgap.com</email>
</author>
<published>2018-07-31T14:39:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=145fd9a5f66212231b4d50153acefee579c187b6'/>
<id>urn:sha1:145fd9a5f66212231b4d50153acefee579c187b6</id>
<content type='text'>
[ Upstream commit 1006284c5e411872333967b1970c2ca46a9e225f ]

When an OS (currently only classic Mac OS) is running in KVM-PR and makes a
linked jump from code with split hack addressing enabled into code that does
not, LR is not correctly updated and reflects the previously munged PC.

To fix this, this patch undoes the address munge when exiting split
hack mode so that code relying on LR being a proper address will now
execute. This does not affect OS X or other operating systems running
on KVM-PR.

Signed-off-by: Cameron Kaiser &lt;spectre@floodgap.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@ozlabs.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer</title>
<updated>2019-11-24T07:23:05+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@ozlabs.org</email>
</author>
<published>2018-10-01T23:01:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=991d57ecd8bc0db05186a4ecb2341748b1b7e97e'/>
<id>urn:sha1:991d57ecd8bc0db05186a4ecb2341748b1b7e97e</id>
<content type='text'>
[ Upstream commit 8b78fdb045de60a4eb35460092bbd3cffa925353 ]

We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.

Signed-off-by: Anton Blanchard &lt;anton@ozlabs.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PM / hibernate: Check the success of generating md5 digest before hibernation</title>
<updated>2019-11-24T07:23:02+00:00</updated>
<author>
<name>Chen Yu</name>
<email>yu.c.chen@intel.com</email>
</author>
<published>2018-09-21T06:26:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7896a8171e18b1a738d710d69490f748202270b7'/>
<id>urn:sha1:7896a8171e18b1a738d710d69490f748202270b7</id>
<content type='text'>
[ Upstream commit 749fa17093ff67b31dea864531a3698b6a95c26c ]

Currently if get_e820_md5() fails, then it will hibernate nevertheless.
Actually the error code should be propagated to upper caller so that
the hibernation could be aware of the result and terminates the process
if md5 digest fails.

Suggested-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Signed-off-by: Chen Yu &lt;yu.c.chen@intel.com&gt;
Acked-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
