<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.14.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-02-25T10:08:04+00:00</updated>
<entry>
<title>Linux 4.14.22</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-02-25T10:08:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=55b195735142c1a8ffccb21a4af0b1bd8bd4d1eb'/>
<id>urn:sha1:55b195735142c1a8ffccb21a4af0b1bd8bd4d1eb</id>
<content type='text'>
</content>
</entry>
<entry>
<title>vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Michal Hocko</name>
<email>mhocko@suse.com</email>
</author>
<published>2018-02-21T22:46:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c902ff1e4b2535a43980302d573020a16be29a2e'/>
<id>urn:sha1:c902ff1e4b2535a43980302d573020a16be29a2e</id>
<content type='text'>
commit 698d0831ba87b92ae10b15e8203cfd59f5a59a35 upstream.

Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly").

saa7146_vmalloc_build_pgtable uses vmalloc_32 and it is reasonable to
expect that the resulting page is not in highmem.  The above commit
aimed to add __GFP_HIGHMEM only for those requests which do not specify
any zone modifier gfp flag.  vmalloc_32 relies on GFP_VMALLOC32 which
should do the right thing.  Except it has been missed that GFP_VMALLOC32
is an alias for GFP_KERNEL on 32b architectures.  Thanks to Matthew to
notice this.

Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32
for !64b arches (as a bailout).  This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.

Debugged by Matthew Wilcox.

[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Reported-by: Kai Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: Laura Abbott &lt;labbott@redhat.com&gt;
Cc: &lt;stable@vger.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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: me: add cannon point device ids for 4th device</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Tomas Winkler</name>
<email>tomas.winkler@intel.com</email>
</author>
<published>2018-02-18T09:05:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eff339b5d25029ce5aed6c85c59f1708b22ef9b2'/>
<id>urn:sha1:eff339b5d25029ce5aed6c85c59f1708b22ef9b2</id>
<content type='text'>
commit 2a4ac172c2f257d28c47b90c9e381bec31edcc44 upstream.

Add cannon point device ids for 4th (itouch) device.

Cc: &lt;stable@vger.kernel.org&gt; 4.14+
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mei: me: add cannon point device ids</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Alexander Usyskin</name>
<email>alexander.usyskin@intel.com</email>
</author>
<published>2018-02-18T09:05:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=06320148eecdd7377c4e512b1d694a26b7b61cd8'/>
<id>urn:sha1:06320148eecdd7377c4e512b1d694a26b7b61cd8</id>
<content type='text'>
commit f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c upstream.

Add CNP LP and CNP H device ids for cannon lake
and coffee lake platforms.

Cc: &lt;stable@vger.kernel.org&gt; 4.14+
Signed-off-by: Alexander Usyskin &lt;alexander.usyskin@intel.com&gt;
Signed-off-by: Tomas Winkler &lt;tomas.winkler@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: s5p-sss - Fix kernel Oops in AES-ECB mode</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Kamil Konieczny</name>
<email>k.konieczny@partner.samsung.com</email>
</author>
<published>2018-02-07T15:52:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95c0853883973c9c065959a33208751dcf8c57d1'/>
<id>urn:sha1:95c0853883973c9c065959a33208751dcf8c57d1</id>
<content type='text'>
commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.

In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.

Signed-off-by: Kamil Konieczny &lt;k.konieczny@partner.samsung.com&gt;
Reported-by: Anand Moon &lt;linux.amoon@gmail.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Tested-by: Anand Moon &lt;linux.amoon@gmail.com&gt;
Cc: stable@vger.kernel.org # can be applied after commit 8f9702aad138
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: fix intel_backlight_device_register declaration</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-11-27T15:10:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc4cb30f2cd5f42631f81cb7afb7f5b325f5a23a'/>
<id>urn:sha1:fc4cb30f2cd5f42631f81cb7afb7f5b325f5a23a</id>
<content type='text'>
commit ac29fc66855b79c2960c63a4a66952d5b721d698 upstream.

The alternative intel_backlight_device_register() definition apparently
never got used, but I have now run into a case of i915 being compiled
without CONFIG_BACKLIGHT_CLASS_DEVICE, resulting in a number of
identical warnings:

drivers/gpu/drm/i915/intel_drv.h:1739:12: error: 'intel_backlight_device_register' defined but not used [-Werror=unused-function]

This marks the function as 'inline', which was surely the original
intention here.

Fixes: 1ebaa0b9c2d4 ("drm/i915: Move backlight registration to connector registration")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-1-arnd@arndb.de
(cherry picked from commit 2de2d0b063b08becb2c67a2c338c44e37bdcffee)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: talitos - fix Kernel Oops on hashing an empty file</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>LEROY Christophe</name>
<email>christophe.leroy@c-s.fr</email>
</author>
<published>2018-01-26T16:09:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=68a2a52047602994f5ded220f172da9e7e17a310'/>
<id>urn:sha1:68a2a52047602994f5ded220f172da9e7e17a310</id>
<content type='text'>
commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.

Performing the hash of an empty file leads to a kernel Oops

[   44.504600] Unable to handle kernel paging request for data at address 0x0000000c
[   44.512819] Faulting instruction address: 0xc02d2be8
[   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
[   44.529171] BE PREEMPT CMPC885
[   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
[   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 00000000
[   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  (4.15.0-rc8-00211-g3a968610b6ea)
[   44.554223] MSR:  00009032 &lt;EE,ME,IR,DR,RI&gt;  CR: 48222822  XER: 20000000
[   44.560855] DAR: 0000000c DSISR: c0000000
[   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
[   44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
[   44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
[   44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
[   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
[   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
[   44.608868] Call Trace:
[   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
[   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
[   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
[   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
[   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
[   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
[   44.645530] Instruction dump:
[   44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
[   44.656122] 40befe50 2f990001 409e0210 813f01bc &lt;8129000c&gt; b39e003a 7d29c214 913e003c

This patch fixes that Oops by checking if src is NULL.

Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close</title>
<updated>2018-02-25T10:08:04+00:00</updated>
<author>
<name>Jia-Ju Bai</name>
<email>baijiaju1990@163.com</email>
</author>
<published>2017-12-12T08:49:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e94fc847bd6e405e7c2b8849e52c102070777387'/>
<id>urn:sha1:e94fc847bd6e405e7c2b8849e52c102070777387</id>
<content type='text'>
[ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ]

The driver may sleep under a spinlock.
The function call path is:
rr_close (acquire the spinlock)
  free_irq --&gt; may sleep

To fix it, free_irq is moved to the place without holding the spinlock.

This bug is found by my static analysis tool(DSAC) and checked by my code review.

Signed-off-by: Jia-Ju Bai &lt;baijiaju1990@163.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/perf/imc: Fix nest-imc cpuhotplug callback failure</title>
<updated>2018-02-25T10:08:03+00:00</updated>
<author>
<name>Anju T Sudhakar</name>
<email>anju@linux.vnet.ibm.com</email>
</author>
<published>2017-12-05T05:30:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=385aeea7128918b57f7a4dd70c0fa55c50c6daa3'/>
<id>urn:sha1:385aeea7128918b57f7a4dd70c0fa55c50c6daa3</id>
<content type='text'>
[ Upstream commit ad2b6e01024ef23bddc3ce0bcb115ecd8c520b7e ]

Oops is observed during boot:

  Faulting instruction address: 0xc000000000248340
  cpu 0x0: Vector: 380 (Data Access Out of Range) at [c000000ff66fb850]
      pc: c000000000248340: event_function_call+0x50/0x1f0
      lr: c00000000024878c: perf_remove_from_context+0x3c/0x100
      sp: c000000ff66fbad0
     msr: 9000000000009033
     dar: 7d20e2a6f92d03c0
    pid = 14, comm = cpuhp/0

While registering the cpuhotplug callbacks for nest-imc, if we fail in
the cpuhotplug online path for any random node in a multi node
system (because the opal call to stop nest-imc counters fails for that
node), ppc_nest_imc_cpu_offline() will get invoked for other nodes who
successfully returned from cpuhotplug online path.

This call trace is generated since in the ppc_nest_imc_cpu_offline()
path we are trying to migrate the event context, when nest-imc
counters are not even initialized.

Patch to add a check to ensure that nest-imc is registered before
migrating the event context.

Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support")
Signed-off-by: Anju T Sudhakar &lt;anju@linux.vnet.ibm.com&gt;
Reviewed-by: Madhavan Srinivasan &lt;maddy@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: rcar: Fix use-after-free in probe error path</title>
<updated>2018-02-25T10:08:03+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2017-12-07T10:15:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=473900cd523a9d11a03a2eb5fec2e2ef029fb21b'/>
<id>urn:sha1:473900cd523a9d11a03a2eb5fec2e2ef029fb21b</id>
<content type='text'>
[ Upstream commit 0c31f1d7be1b5c4858b1d714dcefa25f41428cab ]

If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
during probe on r8a7791/koelsch:

  rcar-pcie fe000000.pcie: PCIe link down
  Unable to handle kernel paging request at virtual address 6b6b6b6b

(seeing this message requires earlycon and keep_bootcon).

Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
embedded rcar_pcie object, so pci_free_resource_list() must not be called
afterwards.

To fix this, move the call to pci_free_resource_list() up, and update the
label name accordingly.

Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is inserted")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
