<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v4.14.82</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.82</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.82'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-11-21T08:24:17Z</updated>
<entry>
<title>CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM</title>
<updated>2018-11-21T08:24:17Z</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefanos@xilinx.com</email>
</author>
<published>2018-10-31T23:11:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9891f6816000e7addacb6f88986cc2d4f9004be0'/>
<id>urn:sha1:9891f6816000e7addacb6f88986cc2d4f9004be0</id>
<content type='text'>
commit f9005571701920551bcf54a500973fb61f2e1eda upstream.

xen_create_contiguous_region has now only an implementation if
CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
we do have an implementation of xen_create_contiguous_region which is
required for swiotlb-xen to work correctly (although it just sets
*dma_handle).

[backport: remove change to xen_remap_pfn]

Cc: &lt;stable@vger.kernel.org&gt; # 4.12
Fixes: 16624390816c ("xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds")
Signed-off-by: Stefano Stabellini &lt;stefanos@xilinx.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
CC: Jeff.Kubascik@dornerworks.com
CC: Jarvis.Roach@dornerworks.com
CC: Nathan.Studer@dornerworks.com
CC: vkuznets@redhat.com
CC: boris.ostrovsky@oracle.com
CC: jgross@suse.com
CC: julien.grall@arm.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>clockevents/drivers/i8253: Add support for PIT shutdown quirk</title>
<updated>2018-11-21T08:24:11Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2018-11-04T03:48:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=79d80b876396693e5b6d7d345963b83a2f917816'/>
<id>urn:sha1:79d80b876396693e5b6d7d345963b83a2f917816</id>
<content type='text'>
commit 35b69a420bfb56b7b74cb635ea903db05e357bec upstream.

Add support for platforms where pit_shutdown() doesn't work because of a
quirk in the PIT emulation. On these platforms setting the counter register
to zero causes the PIT to start running again, negating the shutdown.

Provide a global variable that controls whether the counter register is
zero'ed, which platform specific code can override.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "gregkh@linuxfoundation.org" &lt;gregkh@linuxfoundation.org&gt;
Cc: "devel@linuxdriverproject.org" &lt;devel@linuxdriverproject.org&gt;
Cc: "daniel.lezcano@linaro.org" &lt;daniel.lezcano@linaro.org&gt;
Cc: "virtualization@lists.linux-foundation.org" &lt;virtualization@lists.linux-foundation.org&gt;
Cc: "jgross@suse.com" &lt;jgross@suse.com&gt;
Cc: "akataria@vmware.com" &lt;akataria@vmware.com&gt;
Cc: "olaf@aepfle.de" &lt;olaf@aepfle.de&gt;
Cc: "apw@canonical.com" &lt;apw@canonical.com&gt;
Cc: vkuznets &lt;vkuznets@redhat.com&gt;
Cc: "jasowang@redhat.com" &lt;jasowang@redhat.com&gt;
Cc: "marcelo.cerri@canonical.com" &lt;marcelo.cerri@canonical.com&gt;
Cc: KY Srinivasan &lt;kys@microsoft.com&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1541303219-11142-2-git-send-email-mikelley@microsoft.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>watchdog/core: Add missing prototypes for weak functions</title>
<updated>2018-11-21T08:24:10Z</updated>
<author>
<name>Mathieu Malaterre</name>
<email>malat@debian.org</email>
</author>
<published>2018-06-06T19:42:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ca35750b5fb7bd3c4233a77b0b2de6f6a9c6cbdc'/>
<id>urn:sha1:ca35750b5fb7bd3c4233a77b0b2de6f6a9c6cbdc</id>
<content type='text'>
commit 81bd415c91eb966118d773dddf254aebf3022411 upstream.

The split out of the hard lockup detector exposed two new weak functions,
but no prototypes for them, which triggers the build warning:

  kernel/watchdog.c:109:12: warning: no previous prototype for ‘watchdog_nmi_enable’ [-Wmissing-prototypes]
  kernel/watchdog.c:115:13: warning: no previous prototype for ‘watchdog_nmi_disable’ [-Wmissing-prototypes]

Add the prototypes.

Fixes: 73ce0511c436 ("kernel/watchdog.c: move hardlockup detector to separate file")
Signed-off-by: Mathieu Malaterre &lt;malat@debian.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Babu Moger &lt;babu.moger@oracle.com&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180606194232.17653-1-malat@debian.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libceph: bump CEPH_MSG_MAX_DATA_LEN</title>
<updated>2018-11-21T08:24:07Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2018-09-26T16:03:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fc07f543a6d39399ba425c5bc588920fbdf65f39'/>
<id>urn:sha1:fc07f543a6d39399ba425c5bc588920fbdf65f39</id>
<content type='text'>
commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.

If the read is large enough, we end up spinning in the messenger:

  libceph: osd0 192.168.122.1:6801 io error
  libceph: osd0 192.168.122.1:6801 io error
  libceph: osd0 192.168.122.1:6801 io error

This is a receive side limit, so only reads were affected.

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>TC: Set DMA masks for devices</title>
<updated>2018-11-13T19:15:11Z</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@linux-mips.org</email>
</author>
<published>2018-10-03T12:21:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e7f6b41ad2aab1453f0ff64b014027209e8ea632'/>
<id>urn:sha1:e7f6b41ad2aab1453f0ff64b014027209e8ea632</id>
<content type='text'>
commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.

Fix a TURBOchannel support regression with commit 205e1b7f51e4
("dma-mapping: warn when there is no coherent_dma_mask") that caused
coherent DMA allocations to produce a warning such as:

defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
tc1: DEFTA at MMIO addr = 0x1e900000, IRQ = 20, Hardware addr = 08-00-2b-a3-a3-29
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dfx_dev_register+0x670/0x678
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
Stack : ffffffff8009ffc0 fffffffffffffec0 0000000000000000 ffffffff80647650
        0000000000000000 0000000000000000 ffffffff806f5f80 ffffffffffffffff
        0000000000000000 0000000000000000 0000000000000001 ffffffff8065d4e8
        98000000031b6300 ffffffff80563478 ffffffff805685b0 ffffffffffffffff
        0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
        0000000000000000 0000000000000009 ffffffff8053efd0 ffffffff806657d0
        0000000000000000 ffffffff803177f8 0000000000000000 ffffffff806d0000
        9800000003078000 980000000307b9e0 000000001e900000 ffffffff80067940
        0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
        ffffffff805176c0 ffffffff8004dc78 0000000000000000 ffffffff80067940
        ...
Call Trace:
[&lt;ffffffff8004dc78&gt;] show_stack+0xa0/0x130
[&lt;ffffffff80067940&gt;] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---

This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.

Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol supports a 34-bit (16GiB) DMA address
space, by interpreting the value presented in the address cycle across
the 32 `ad' lines as a 32-bit word rather than byte address[1].  The
architectural size of the TURBOchannel DMA address space exceeds the
maximum amount of RAM any actual TURBOchannel system in existence may
have, hence both masks are the same.

This removes the warning shown above.

References:

[1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
    Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/20835/
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Cc: stable@vger.kernel.org # 4.16+
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>signal: Guard against negative signal numbers in copy_siginfo_from_user32</title>
<updated>2018-11-13T19:15:07Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2018-10-11T01:29:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=51f62e827191f4ba02c2a001b9e6f25605bfa649'/>
<id>urn:sha1:51f62e827191f4ba02c2a001b9e6f25605bfa649</id>
<content type='text'>
commit a36700589b85443e28170be59fa11c8a104130a5 upstream.

While fixing an out of bounds array access in known_siginfo_layout
reported by the kernel test robot it became apparent that the same bug
exists in siginfo_layout and affects copy_siginfo_from_user32.

The straight forward fix that makes guards against making this mistake
in the future and should keep the code size small is to just take an
unsigned signal number instead of a signed signal number, as I did to
fix known_siginfo_layout.

Cc: stable@vger.kernel.org
Fixes: cc731525f26a ("signal: Remove kernel interal si_code magic")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UAPI: ndctl: Fix g++-unsupported initialisation in headers</title>
<updated>2018-11-13T19:14:57Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2018-09-06T09:19:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=be5658a1dce1664c9b1b414a2ce1a14eceea590a'/>
<id>urn:sha1:be5658a1dce1664c9b1b414a2ce1a14eceea590a</id>
<content type='text'>
[ Upstream commit 9607871f37dc3e717639694b8d0dc738f2a68efc ]

The following code in the linux/ndctl header file:

	static inline const char *nvdimm_bus_cmd_name(unsigned cmd)
	{
		static const char * const names[] = {
			[ND_CMD_ARS_CAP] = "ars_cap",
			[ND_CMD_ARS_START] = "ars_start",
			[ND_CMD_ARS_STATUS] = "ars_status",
			[ND_CMD_CLEAR_ERROR] = "clear_error",
			[ND_CMD_CALL] = "cmd_call",
		};

		if (cmd &lt; ARRAY_SIZE(names) &amp;&amp; names[cmd])
			return names[cmd];
		return "unknown";
	}

is broken in a number of ways:

 (1) ARRAY_SIZE() is not generally defined.

 (2) g++ does not support "non-trivial" array initialisers fully yet.

 (3) Every file that calls this function will acquire a copy of names[].

The same goes for nvdimm_cmd_name().

Fix all three by converting to a switch statement where each case returns a
string.  That way if cmd is a constant, the compiler can trivially reduce it
and, if not, the compiler can use a shared lookup table if it thinks that is
more efficient.

A better way would be to remove these functions and their arrays from the
header entirely.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack</title>
<updated>2018-11-13T19:14:54Z</updated>
<author>
<name>Will Deacon</name>
<email>will.deacon@arm.com</email>
</author>
<published>2018-09-05T14:34:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b66d0bb19f24702ca3b9ac8dc6f570d5be90ec7d'/>
<id>urn:sha1:b66d0bb19f24702ca3b9ac8dc6f570d5be90ec7d</id>
<content type='text'>
[ Upstream commit 22839869f21ab3850fbbac9b425ccc4c0023926f ]

The sigaltstack(2) system call fails with -ENOMEM if the new alternative
signal stack is found to be smaller than SIGMINSTKSZ. On architectures
such as arm64, where the native value for SIGMINSTKSZ is larger than
the compat value, this can result in an unexpected error being reported
to a compat task. See, for example:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904385

This patch fixes the problem by extending do_sigaltstack to take the
minimum signal stack size as an additional parameter, allowing the
native and compat system call entry code to pass in their respective
values. COMPAT_SIGMINSTKSZ is just defined as SIGMINSTKSZ if it has not
been defined by the architecture.

Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Reported-by: Steve McIntyre &lt;steve.mcintyre@arm.com&gt;
Tested-by: Steve McIntyre &lt;93sam@debian.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/edid: VSDB yCBCr420 Deep Color mode bit definitions</title>
<updated>2018-11-10T15:48:35Z</updated>
<author>
<name>Clint Taylor</name>
<email>clinton.a.taylor@intel.com</email>
</author>
<published>2018-10-05T21:52:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=20ff18553ed84b2bc57567e1ac51bf432719c289'/>
<id>urn:sha1:20ff18553ed84b2bc57567e1ac51bf432719c289</id>
<content type='text'>
commit 9068e02f58740778d8270840657f1e250a2cc60f upstream.

HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
definitions in the header for the mask to work correctly.

Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
Cc: &lt;stable@vger.kernel.org&gt; # v4.14+
Signed-off-by: Clint Taylor &lt;clinton.a.taylor@intel.com&gt;
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Shashank Sharma &lt;shashank.sharma@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bpf: fix partial copy of map_ptr when dst is scalar</title>
<updated>2018-11-10T15:48:34Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2018-11-01T21:30:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=eb9b195c53db75c694bf78576925fcb3eed9d0e1'/>
<id>urn:sha1:eb9b195c53db75c694bf78576925fcb3eed9d0e1</id>
<content type='text'>
commit 0962590e553331db2cc0aef2dc35c57f6300dbbe upstream.

ALU operations on pointers such as scalar_reg += map_value_ptr are
handled in adjust_ptr_min_max_vals(). Problem is however that map_ptr
and range in the register state share a union, so transferring state
through dst_reg-&gt;range = ptr_reg-&gt;range is just buggy as any new
map_ptr in the dst_reg is then truncated (or null) for subsequent
checks. Fix this by adding a raw member and use it for copying state
over to dst_reg.

Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: Edward Cree &lt;ecree@solarflare.com&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Edward Cree &lt;ecree@solarflare.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
