<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.9.186</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.186</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.186'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-07-21T07:06:08+00:00</updated>
<entry>
<title>s390/qdio: don't touch the dsci in tiqdio_add_input_queues()</title>
<updated>2019-07-21T07:06:08+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2019-06-18T11:12:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2aa57f707fe9f187bd731475c1ec85147afc5bdb'/>
<id>urn:sha1:2aa57f707fe9f187bd731475c1ec85147afc5bdb</id>
<content type='text'>
commit ac6639cd3db607d386616487902b4cc1850a7be5 upstream.

Current code sets the dsci to 0x00000080. Which doesn't make any sense,
as the indicator area is located in the _left-most_ byte.

Worse: if the dsci is the _shared_ indicator, this potentially clears
the indication of activity for a _different_ device.
tiqdio_thinint_handler() will then have no reason to call that device's
IRQ handler, and the device ends up stalling.

Fixes: d0c9d4a89fff ("[S390] qdio: set correct bit in dsci")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/qdio: (re-)initialize tiqdio list entries</title>
<updated>2019-07-21T07:06:08+00:00</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2019-06-18T09:25:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=355dbc42bfb47a9033d740b69c1ea4dcfbe009f8'/>
<id>urn:sha1:355dbc42bfb47a9033d740b69c1ea4dcfbe009f8</id>
<content type='text'>
commit e54e4785cb5cb4896cf4285964aeef2125612fb2 upstream.

When tiqdio_remove_input_queues() removes a queue from the tiq_list as
part of qdio_shutdown(), it doesn't re-initialize the queue's list entry
and the prev/next pointers go stale.

If a subsequent qdio_establish() fails while sending the ESTABLISH cmd,
it calls qdio_shutdown() again in QDIO_IRQ_STATE_ERR state and
tiqdio_remove_input_queues() will attempt to remove the queue entry a
second time. This dereferences the stale pointers, and bad things ensue.
Fix this by re-initializing the list entry after removing it from the
list.

For good practice also initialize the list entry when the queue is first
allocated, and remove the quirky checks that papered over this omission.
Note that prior to
commit e521813468f7 ("s390/qdio: fix access to uninitialized qdio_q fields"),
these checks were bogus anyway.

setup_queues_misc() clears the whole queue struct, and thus needs to
re-init the prev/next pointers as well.

Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm verity: use message limit for data block corruption message</title>
<updated>2019-07-21T07:06:07+00:00</updated>
<author>
<name>Milan Broz</name>
<email>gmazyland@gmail.com</email>
</author>
<published>2019-06-20T11:00:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7357febe9ec5a854f59dd6e6df50e279e54a8e5a'/>
<id>urn:sha1:7357febe9ec5a854f59dd6e6df50e279e54a8e5a</id>
<content type='text'>
[ Upstream commit 2eba4e640b2c4161e31ae20090a53ee02a518657 ]

DM verity should also use DMERR_LIMIT to limit repeat data block
corruption messages.

Signed-off-by: Milan Broz &lt;gmazyland@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sis900: fix TX completion</title>
<updated>2019-07-21T07:06:06+00:00</updated>
<author>
<name>Sergej Benilov</name>
<email>sergej.benilov@googlemail.com</email>
</author>
<published>2019-06-20T09:02:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=338d1d62fcb4aa48575e20243aa7eff528a0ee78'/>
<id>urn:sha1:338d1d62fcb4aa48575e20243aa7eff528a0ee78</id>
<content type='text'>
[ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ]

Since commit 605ad7f184b60cfaacbc038aa6c55ee68dee3c89 "tcp: refine TSO autosizing",
outbound throughput is dramatically reduced for some connections, as sis900
is doing TX completion within idle states only.

Make TX completion happen after every transmitted packet.

Test:
netperf

before patch:
&gt; netperf -H remote -l -2000000 -- -s 1000000
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380 327680 327680    253.44      0.06

after patch:
&gt; netperf -H remote -l -10000000 -- -s 1000000
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380 327680 327680    5.38       14.89

Thx to Dave Miller and Eric Dumazet for helpful hints

Signed-off-by: Sergej Benilov &lt;sergej.benilov@googlemail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ppp: mppe: Add softdep to arc4</title>
<updated>2019-07-21T07:06:06+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2019-06-19T13:34:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a31ba8ec66cca7fe08f6f4a0d5e63eb36b503664'/>
<id>urn:sha1:a31ba8ec66cca7fe08f6f4a0d5e63eb36b503664</id>
<content type='text'>
[ Upstream commit aad1dcc4f011ea409850e040363dff1e59aa4175 ]

The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a
softdep line, so that the corresponding module gets prepared
gracefully.  Without this, a simple inclusion to initrd via dracut
failed due to the missing dependency, for example.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>be2net: fix link failure after ethtool offline test</title>
<updated>2019-07-21T07:06:06+00:00</updated>
<author>
<name>Petr Oros</name>
<email>poros@redhat.com</email>
</author>
<published>2019-06-19T12:29:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=79568282985283f21b5597fa2aef3bde5cbf1f6a'/>
<id>urn:sha1:79568282985283f21b5597fa2aef3bde5cbf1f6a</id>
<content type='text'>
[ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ]

Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.

Changes in v2:
- added fixes header

Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros &lt;poros@redhat.com&gt;
Reviewed-by: Ivan Vecera &lt;ivecera@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>e1000e: start network tx queue only when link is up</title>
<updated>2019-07-21T07:06:04+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@yandex-team.ru</email>
</author>
<published>2019-04-17T08:13:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=66eab69c92351a269d13163393cce4295a7287bb'/>
<id>urn:sha1:66eab69c92351a269d13163393cce4295a7287bb</id>
<content type='text'>
commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 upstream.

Driver does not want to keep packets in Tx queue when link is lost.
But present code only reset NIC to flush them, but does not prevent
queuing new packets. Moreover reset sequence itself could generate
new packets via netconsole and NIC falls into endless reset loop.

This patch wakes Tx queue only when NIC is ready to send packets.

This is proper fix for problem addressed by commit 0f9e980bf5ee
("e1000e: fix cyclic resets at link up with active tx").

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Suggested-by: Alexander Duyck &lt;alexander.duyck@gmail.com&gt;
Tested-by: Joseph Yasi &lt;joe.yasi@gmail.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@redhat.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "e1000e: fix cyclic resets at link up with active tx"</title>
<updated>2019-07-21T07:06:04+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@yandex-team.ru</email>
</author>
<published>2019-04-17T08:13:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6abcd179e303987ace685e98c6f69117ed16afd'/>
<id>urn:sha1:a6abcd179e303987ace685e98c6f69117ed16afd</id>
<content type='text'>
commit caff422ea81e144842bc44bab408d85ac449377b upstream.

This reverts commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61.

That change cased false-positive warning about hardware hang:

e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
   TDH                  &lt;0&gt;
   TDT                  &lt;1&gt;
   next_to_use          &lt;1&gt;
   next_to_clean        &lt;0&gt;
buffer_info[next_to_clean]:
   time_stamp           &lt;fffba7a7&gt;
   next_to_watch        &lt;0&gt;
   jiffies              &lt;fffbb140&gt;
   next_to_watch.status &lt;0&gt;
MAC Status             &lt;40080080&gt;
PHY Status             &lt;7949&gt;
PHY 1000BASE-T Status  &lt;0&gt;
PHY Extended Status    &lt;3000&gt;
PCI Status             &lt;10&gt;
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Besides warning everything works fine.
Original issue will be fixed property in following patch.

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Reported-by: Joseph Yasi &lt;joe.yasi@gmail.com&gt;
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203175
Tested-by: Joseph Yasi &lt;joe.yasi@gmail.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@redhat.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>VMCI: Fix integer overflow in VMCI handle arrays</title>
<updated>2019-07-21T07:06:03+00:00</updated>
<author>
<name>Vishnu DASA</name>
<email>vdasa@vmware.com</email>
</author>
<published>2019-05-24T15:13:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6f56992a4e66b699f072459e3333946078f6cc83'/>
<id>urn:sha1:6f56992a4e66b699f072459e3333946078f6cc83</id>
<content type='text'>
commit 1c2eb5b2853c9f513690ba6b71072d8eb65da16a upstream.

The VMCI handle array has an integer overflow in
vmci_handle_arr_append_entry when it tries to expand the array. This can be
triggered from a guest, since the doorbell link hypercall doesn't impose a
limit on the number of doorbell handles that a VM can create in the
hypervisor, and these handles are stored in a handle array.

In this change, we introduce a mandatory max capacity for handle
arrays/lists to avoid excessive memory usage.

Signed-off-by: Vishnu Dasa &lt;vdasa@vmware.com&gt;
Reviewed-by: Adit Ranadive &lt;aditr@vmware.com&gt;
Reviewed-by: Jorgen Hansen &lt;jhansen@vmware.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>carl9170: fix misuse of device driver API</title>
<updated>2019-07-21T07:06:03+00:00</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2019-06-08T14:49:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eea15538d96700b70b07f5725c11a4a92fc2c4a8'/>
<id>urn:sha1:eea15538d96700b70b07f5725c11a4a92fc2c4a8</id>
<content type='text'>
commit feb09b2933275a70917a869989ea2823e7356be8 upstream.

This patch follows Alan Stern's recent patch:
"p54: Fix race between disconnect and firmware loading"

that overhauled carl9170 buggy firmware loading and driver
unbinding procedures.

Since the carl9170 code was adapted from p54 it uses the
same functions and is likely to have the same problem, but
it's just that the syzbot hasn't reproduce them (yet).

a summary from the changes (copied from the p54 patch):
 * Call usb_driver_release_interface() rather than
   device_release_driver().

 * Lock udev (the interface's parent) before unbinding the
   driver instead of locking udev-&gt;parent.

 * During the firmware loading process, take a reference
   to the USB interface instead of the USB device.

 * Don't take an unnecessary reference to the device during
   probe (and then don't drop it during disconnect).

and

 * Make sure to prevent use-after-free bugs by explicitly
   setting the driver context to NULL after signaling the
   completion.

Cc: &lt;stable@vger.kernel.org&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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