<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.14.222</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.222</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.222'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-02-23T13:00:34+00:00</updated>
<entry>
<title>Linux 4.14.222</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-02-23T13:00:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3242aa3a635c0958671ee1e4b0958dcc7c4e5c79'/>
<id>urn:sha1:3242aa3a635c0958671ee1e4b0958dcc7c4e5c79</id>
<content type='text'>
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Jason Self &lt;jason@bluehome.net&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Link: https://lore.kernel.org/r/20210222121027.174911182@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kvm: check tlbs_dirty directly</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Lai Jiangshan</name>
<email>laijs@linux.alibaba.com</email>
</author>
<published>2020-12-17T15:41:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3017f5e12bbfe19add7dc921caddc2a1c0066814'/>
<id>urn:sha1:3017f5e12bbfe19add7dc921caddc2a1c0066814</id>
<content type='text'>
commit 88bf56d04bc3564542049ec4ec168a8b60d0b48c upstream

In kvm_mmu_notifier_invalidate_range_start(), tlbs_dirty is used as:
        need_tlb_flush |= kvm-&gt;tlbs_dirty;
with need_tlb_flush's type being int and tlbs_dirty's type being long.

It means that tlbs_dirty is always used as int and the higher 32 bits
is useless.  We need to check tlbs_dirty in a correct way and this
change checks it directly without propagating it to need_tlb_flush.

Note: it's _extremely_ unlikely this neglecting of higher 32 bits can
cause problems in practice.  It would require encountering tlbs_dirty
on a 4 billion count boundary, and KVM would need to be using shadow
paging or be running a nested guest.

Cc: stable@vger.kernel.org
Fixes: a4ee1ca4a36e ("KVM: MMU: delay flush all tlbs on sync_page path")
Signed-off-by: Lai Jiangshan &lt;laijs@linux.alibaba.com&gt;
Message-Id: &lt;20201217154118.16497-1-jiangshanlai@gmail.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: u_ether: Fix MTU size mismatch with RX packet size</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Manish Narani</name>
<email>manish.narani@xilinx.com</email>
</author>
<published>2020-11-17T07:13:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2afb9a5a42ab910589d3a3da96d365cb7085ff8b'/>
<id>urn:sha1:2afb9a5a42ab910589d3a3da96d365cb7085ff8b</id>
<content type='text'>
commit 0a88fa221ce911c331bf700d2214c5b2f77414d3 upstream

Fix the MTU size issue with RX packet size as the host sends the packet
with extra bytes containing ethernet header. This causes failure when
user sets the MTU size to the maximum i.e. 15412. In this case the
ethernet packet received will be of length 15412 plus the ethernet header
length. This patch fixes the issue where there is a check that RX packet
length must not be more than max packet length.

Fixes: bba787a860fa ("usb: gadget: ether: Allow jumbo frames")
Signed-off-by: Manish Narani &lt;manish.narani@xilinx.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/1605597215-122027-1-git-send-email-manish.narani@xilinx.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: Gadget Ethernet: Re-enable Jumbo frames.</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>John Greb</name>
<email>h3x4m3r0n@gmail.com</email>
</author>
<published>2018-05-06T20:01:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c7a2cf336a2fb94e6c78b9ae4331581a311d01f'/>
<id>urn:sha1:2c7a2cf336a2fb94e6c78b9ae4331581a311d01f</id>
<content type='text'>
commit eea52743eb5654ec6f52b0e8b4aefec952543697 upstream

Fixes: &lt;b3e3893e1253&gt; ("net: use core MTU range checking")
which patched only one of two functions used to setup the
USB Gadget Ethernet driver, causing a serious performance
regression in the ability to increase mtu size above 1500.

Signed-off-by: John Greb &lt;h3x4m3r0n@gmail.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix crash during driver load on big endian machines</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Arun Easi</name>
<email>aeasi@marvell.com</email>
</author>
<published>2020-12-02T13:23:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=944a2bc49082d73ca6fc700cc16ca3863b228617'/>
<id>urn:sha1:944a2bc49082d73ca6fc700cc16ca3863b228617</id>
<content type='text'>
commit 8de309e7299a00b3045fb274f82b326f356404f0 upstream

Crash stack:
	[576544.715489] Unable to handle kernel paging request for data at address 0xd00000000f970000
	[576544.715497] Faulting instruction address: 0xd00000000f880f64
	[576544.715503] Oops: Kernel access of bad area, sig: 11 [#1]
	[576544.715506] SMP NR_CPUS=2048 NUMA pSeries
	:
	[576544.715703] NIP [d00000000f880f64] .qla27xx_fwdt_template_valid+0x94/0x100 [qla2xxx]
	[576544.715722] LR [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
	[576544.715726] Call Trace:
	[576544.715731] [c0000004d0ffb000] [c0000006fe02c350] 0xc0000006fe02c350 (unreliable)
	[576544.715750] [c0000004d0ffb080] [d00000000f7952dc] .qla24xx_load_risc_flash+0x2fc/0x590 [qla2xxx]
	[576544.715770] [c0000004d0ffb170] [d00000000f7aa034] .qla81xx_load_risc+0x84/0x1a0 [qla2xxx]
	[576544.715789] [c0000004d0ffb210] [d00000000f79f7c8] .qla2x00_setup_chip+0xc8/0x910 [qla2xxx]
	[576544.715808] [c0000004d0ffb300] [d00000000f7a631c] .qla2x00_initialize_adapter+0x4dc/0xb00 [qla2xxx]
	[576544.715826] [c0000004d0ffb3e0] [d00000000f78ce28] .qla2x00_probe_one+0xf08/0x2200 [qla2xxx]

Link: https://lore.kernel.org/r/20201202132312.19966-8-njavali@marvell.com
Fixes: f73cb695d3ec ("[SCSI] qla2xxx: Add support for ISP2071.")
Cc: stable@vger.kernel.org
Reviewed-by: Himanshu Madhani &lt;himanshu.madhani@oracle.com&gt;
Signed-off-by: Arun Easi &lt;aeasi@marvell.com&gt;
Signed-off-by: Nilesh Javali &lt;njavali@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xen-blkback: fix error handling in xen_blkbk_map()</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@suse.com</email>
</author>
<published>2021-02-15T07:56:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5571633988e02a1107720544a57ab4878c4446be'/>
<id>urn:sha1:5571633988e02a1107720544a57ab4878c4446be</id>
<content type='text'>
commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 upstream.

The function uses a goto-based loop, which may lead to an earlier error
getting discarded by a later iteration. Exit this ad-hoc loop when an
error was encountered.

The out-of-memory error path additionally fails to fill a structure
field looked at by xen_blkbk_unmap_prepare() before inspecting the
handle which does get properly set (to BLKBACK_INVALID_HANDLE).

Since the earlier exiting from the ad-hoc loop requires the same field
filling (invalidation) as that on the out-of-memory path, fold both
paths. While doing so, drop the pr_alert(), as extra log messages aren't
going to help the situation (the kernel will log oom conditions already
anyway).

This is XSA-365.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Julien Grall &lt;julien@xen.org&gt;
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>xen-scsiback: don't "handle" error by BUG()</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@suse.com</email>
</author>
<published>2021-02-15T07:55:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7910839db1ca4d0cd4789872621a023f985e50e0'/>
<id>urn:sha1:7910839db1ca4d0cd4789872621a023f985e50e0</id>
<content type='text'>
commit 7c77474b2d22176d2bfb592ec74e0f2cb71352c9 upstream.

In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.

This is part of XSA-362.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
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>xen-netback: don't "handle" error by BUG()</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@suse.com</email>
</author>
<published>2021-02-15T07:55:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ca595810e8fbc541c388abdb4d2ed9ef20a2e06'/>
<id>urn:sha1:9ca595810e8fbc541c388abdb4d2ed9ef20a2e06</id>
<content type='text'>
commit 3194a1746e8aabe86075fd3c5e7cf1f4632d7f16 upstream.

In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.

This is part of XSA-362.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
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>xen-blkback: don't "handle" error by BUG()</title>
<updated>2021-02-23T13:00:34+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@suse.com</email>
</author>
<published>2021-02-15T07:54:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd8ec8c708953323feb7c6177d894d39a23b08e4'/>
<id>urn:sha1:fd8ec8c708953323feb7c6177d894d39a23b08e4</id>
<content type='text'>
commit 5a264285ed1cd32e26d9de4f3c8c6855e467fd63 upstream.

In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.

This is part of XSA-362.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
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>xen/arm: don't ignore return errors from set_phys_to_machine</title>
<updated>2021-02-23T13:00:33+00:00</updated>
<author>
<name>Stefano Stabellini</name>
<email>stefano.stabellini@xilinx.com</email>
</author>
<published>2021-02-15T07:53:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4514b5e3445540384fd647ce26afae2300274c6a'/>
<id>urn:sha1:4514b5e3445540384fd647ce26afae2300274c6a</id>
<content type='text'>
commit 36bf1dfb8b266e089afa9b7b984217f17027bf35 upstream.

set_phys_to_machine can fail due to lack of memory, see the kzalloc call
in arch/arm/xen/p2m.c:__set_phys_to_machine_multi.

Don't ignore the potential return error in set_foreign_p2m_mapping,
returning it to the caller instead.

This is part of XSA-361.

Signed-off-by: Stefano Stabellini &lt;stefano.stabellini@xilinx.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Julien Grall &lt;jgrall@amazon.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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