<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers, branch v4.17.13</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.17.13</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.17.13'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-08-06T14:18:22+00:00</updated>
<entry>
<title>scsi: sg: fix minor memory leak in error path</title>
<updated>2018-08-06T14:18:22+00:00</updated>
<author>
<name>Tony Battersby</name>
<email>tonyb@cybernetics.com</email>
</author>
<published>2018-07-12T20:30:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bced7cbdcc36743e357480f067cea89d97c10e3d'/>
<id>urn:sha1:bced7cbdcc36743e357480f067cea89d97c10e3d</id>
<content type='text'>
commit c170e5a8d222537e98aa8d4fddb667ff7a2ee114 upstream.

Fix a minor memory leak when there is an error opening a /dev/sg device.

Fixes: cc833acbee9d ("sg: O_EXCL and other lock handling")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Tony Battersby &lt;tonyb@cybernetics.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy</title>
<updated>2018-08-06T14:18:22+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@bootlin.com</email>
</author>
<published>2018-07-24T13:33:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9d61d4bdf223006219b182c8e473ae7dc127b74b'/>
<id>urn:sha1:9d61d4bdf223006219b182c8e473ae7dc127b74b</id>
<content type='text'>
commit de2d8db395c32d121d02871819444b631f73e0b6 upstream.

drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.

Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that plane, new_plane_state and
old_plane_state are initialized.

Explicitly initialize those variables to NULL to make gcc happy.

Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Reviewed-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180724133300.32023-1-boris.brezillon@bootlin.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/atomic: Check old_plane_state-&gt;crtc in drm_atomic_helper_async_check()</title>
<updated>2018-08-06T14:18:22+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@bootlin.com</email>
</author>
<published>2018-07-24T13:32:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3859ebae85c7263a438a8d836e5934d3f31aae93'/>
<id>urn:sha1:3859ebae85c7263a438a8d836e5934d3f31aae93</id>
<content type='text'>
commit 603ba2dfb338b307aebe95fe344c479a59b3a175 upstream.

Async plane update is supposed to work only when updating the FB or FB
position of an already enabled plane. That does not apply to requests
where the plane was previously disabled or assigned to a different
CTRC.

Check old_plane_state-&gt;crtc value to make sure async plane update is
allowed.

Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.net&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180724133215.31917-1-boris.brezillon@bootlin.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/vc4: Reset -&gt;{x, y}_scaling[1] when dealing with uniplanar formats</title>
<updated>2018-08-06T14:18:21+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@bootlin.com</email>
</author>
<published>2018-07-24T13:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=53a1cb1c35dfc0a2b16acd9f9da3459c5da05c3e'/>
<id>urn:sha1:53a1cb1c35dfc0a2b16acd9f9da3459c5da05c3e</id>
<content type='text'>
commit a6a00918d4ad8718c3ccde38c02cec17f116b2fd upstream.

This is needed to ensure -&gt;is_unity is correct when the plane was
previously configured to output a multi-planar format with scaling
enabled, and is then being reconfigured to output a uniplanar format.

Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.net&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180724133601.32114-1-boris.brezillon@bootlin.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: padlock-aes - Fix Nano workaround data corruption</title>
<updated>2018-08-06T14:18:21+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2018-07-13T08:12:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3f9bc0411d111469f389c02d5048fb02054df58c'/>
<id>urn:sha1:3f9bc0411d111469f389c02d5048fb02054df58c</id>
<content type='text'>
commit 46d8c4b28652d35dc6cfb5adf7f54e102fc04384 upstream.

This was detected by the self-test thanks to Ard's chunking patch.

I finally got around to testing this out on my ancient Via box.  It
turns out that the workaround got the assembly wrong and we end up
doing count + initial cycles of the loop instead of just count.

This obviously causes corruption, either by overwriting the source
that is yet to be processed, or writing over the end of the buffer.

On CPUs that don't require the workaround only ECB is affected.
On Nano CPUs both ECB and CBC are affected.

This patch fixes it by doing the subtraction prior to the assembly.

Fixes: a76c1c23d0c3 ("crypto: padlock-aes - work around Nano CPU...")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Jamie Heilman &lt;jamie@audible.transient.net&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>RDMA/uverbs: Expand primary and alt AV port checks</title>
<updated>2018-08-06T14:18:21+00:00</updated>
<author>
<name>Jack Morgenstein</name>
<email>jackm@dev.mellanox.co.il</email>
</author>
<published>2018-07-11T08:23:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d432f2f0bf992b5f5c46022c72a1ba6eccb2b86a'/>
<id>urn:sha1:d432f2f0bf992b5f5c46022c72a1ba6eccb2b86a</id>
<content type='text'>
commit addb8a6559f0f8b5a37582b7ca698358445a55bf upstream.

The commit cited below checked that the port numbers provided in the
primary and alt AVs are legal.

That is sufficient to prevent a kernel panic. However, it is not
sufficient for correct operation.

In Linux, AVs (both primary and alt) must be completely self-described.
We do not accept an AV from userspace without an embedded port number.
(This has been the case since kernel 3.14 commit dbf727de7440
("IB/core: Use GID table in AH creation and dmac resolution")).

For the primary AV, this embedded port number must match the port number
specified with IB_QP_PORT.

We also expect the port number embedded in the alt AV to match the
alt_port_num value passed by the userspace driver in the modify_qp command
base structure.

Add these checks to modify_qp.

Cc: &lt;stable@vger.kernel.org&gt; # 4.16
Fixes: 5d4c05c3ee36 ("RDMA/uverbs: Sanitize user entered port numbers prior to access it")
Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>brcmfmac: fix regression in parsing NVRAM for multiple devices</title>
<updated>2018-08-06T14:18:21+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2018-07-22T21:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=afda82507fe24703bfb03a65d7d9a440f0049c5c'/>
<id>urn:sha1:afda82507fe24703bfb03a65d7d9a440f0049c5c</id>
<content type='text'>
commit 299b6365a3b7cf7f5ea1c945a420e9ee4841d6f7 upstream.

NVRAM is designed to work with Broadcom's SDK Linux kernel which fakes
PCI domain 0 for all internal MMIO devices. Since official Linux kernel
uses platform devices for that purpose there is a mismatch in numbering
PCI domains.

There used to be a fix for that problem but it was accidentally dropped
during the last firmware loading rework. That resulted in brcmfmac not
being able to extract device specific NVRAM content and all kind of
calibration problems.

Reported-by: Aditya Xavier &lt;adityaxavier@gmail.com&gt;
Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: add more card IDs for 9000 series</title>
<updated>2018-08-06T14:18:21+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2018-07-17T10:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b5c014661a4159f7bbbaf583ce3a224dea216484'/>
<id>urn:sha1:b5c014661a4159f7bbbaf583ce3a224dea216484</id>
<content type='text'>
commit 0a5257bc6d89c2ae69b9bf955679cb4f89261874 upstream.

Add new device IDs for the 9000 series.

Cc: stable@vger.kernel.org # 4.14
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>virtio_balloon: fix another race between migration and ballooning</title>
<updated>2018-08-06T14:18:20+00:00</updated>
<author>
<name>Jiang Biao</name>
<email>jiang.biao2@zte.com.cn</email>
</author>
<published>2018-07-18T02:29:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c301e0b0a0f2bb030e70aca196155f3f52dea89d'/>
<id>urn:sha1:c301e0b0a0f2bb030e70aca196155f3f52dea89d</id>
<content type='text'>
commit 89da619bc18d79bca5304724c11d4ba3b67ce2c6 upstream.

Kernel panic when with high memory pressure, calltrace looks like,

PID: 21439 TASK: ffff881be3afedd0 CPU: 16 COMMAND: "java"
 #0 [ffff881ec7ed7630] machine_kexec at ffffffff81059beb
 #1 [ffff881ec7ed7690] __crash_kexec at ffffffff81105942
 #2 [ffff881ec7ed7760] crash_kexec at ffffffff81105a30
 #3 [ffff881ec7ed7778] oops_end at ffffffff816902c8
 #4 [ffff881ec7ed77a0] no_context at ffffffff8167ff46
 #5 [ffff881ec7ed77f0] __bad_area_nosemaphore at ffffffff8167ffdc
 #6 [ffff881ec7ed7838] __node_set at ffffffff81680300
 #7 [ffff881ec7ed7860] __do_page_fault at ffffffff8169320f
 #8 [ffff881ec7ed78c0] do_page_fault at ffffffff816932b5
 #9 [ffff881ec7ed78f0] page_fault at ffffffff8168f4c8
    [exception RIP: _raw_spin_lock_irqsave+47]
    RIP: ffffffff8168edef RSP: ffff881ec7ed79a8 RFLAGS: 00010046
    RAX: 0000000000000246 RBX: ffffea0019740d00 RCX: ffff881ec7ed7fd8
    RDX: 0000000000020000 RSI: 0000000000000016 RDI: 0000000000000008
    RBP: ffff881ec7ed79a8 R8: 0000000000000246 R9: 000000000001a098
    R10: ffff88107ffda000 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000008 R14: ffff881ec7ed7a80 R15: ffff881be3afedd0
    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

It happens in the pagefault and results in double pagefault
during compacting pages when memory allocation fails.

Analysed the vmcore, the page leads to second pagefault is corrupted
with _mapcount=-256, but private=0.

It's caused by the race between migration and ballooning, and lock
missing in virtballoon_migratepage() of virtio_balloon driver.
This patch fix the bug.

Fixes: e22504296d4f64f ("virtio_balloon: introduce migration primitives to balloon pages")
Cc: stable@vger.kernel.org
Signed-off-by: Jiang Biao &lt;jiang.biao2@zte.com.cn&gt;
Signed-off-by: Huang Chong &lt;huang.chong@zte.com.cn&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: ems_usb: Fix memory leak on ems_usb_disconnect()</title>
<updated>2018-08-06T14:18:20+00:00</updated>
<author>
<name>Anton Vasilyev</name>
<email>vasilyev@ispras.ru</email>
</author>
<published>2018-07-27T15:50:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e8445da5dfe0e8cf9fa426dc30061093e66a61bb'/>
<id>urn:sha1:e8445da5dfe0e8cf9fa426dc30061093e66a61bb</id>
<content type='text'>
commit 72c05f32f4a5055c9c8fe889bb6903ec959c0aad upstream.

ems_usb_probe() allocates memory for dev-&gt;tx_msg_buffer, but there
is no its deallocation in ems_usb_disconnect().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev &lt;vasilyev@ispras.ru&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
