<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.14.220</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.220</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.220'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-02-07T13:47:41+00:00</updated>
<entry>
<title>Linux 4.14.220</title>
<updated>2021-02-07T13:47:41+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-02-07T13:47:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00bec5497b5ce36a10c47a09d527805239e102d1'/>
<id>urn:sha1:00bec5497b5ce36a10c47a09d527805239e102d1</id>
<content type='text'>
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/20210205140649.733510103@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kthread: Extract KTHREAD_IS_PER_CPU</title>
<updated>2021-02-07T13:47:41+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2021-01-12T10:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a9b2e4a94eee352e0b3e863045e7379d83131ee2'/>
<id>urn:sha1:a9b2e4a94eee352e0b3e863045e7379d83131ee2</id>
<content type='text'>
[ Upstream commit ac687e6e8c26181a33270efd1a2e2241377924b0 ]

There is a need to distinguish geniune per-cpu kthreads from kthreads
that happen to have a single CPU affinity.

Geniune per-cpu kthreads are kthreads that are CPU affine for
correctness, these will obviously have PF_KTHREAD set, but must also
have PF_NO_SETAFFINITY set, lest userspace modify their affinity and
ruins things.

However, these two things are not sufficient, PF_NO_SETAFFINITY is
also set on other tasks that have their affinities controlled through
other means, like for instance workqueues.

Therefore another bit is needed; it turns out kthread_create_per_cpu()
already has such a bit: KTHREAD_IS_PER_CPU, which is used to make
kthread_park()/kthread_unpark() work correctly.

Expose this flag and remove the implicit setting of it from
kthread_create_on_cpu(); the io_uring usage of it seems dubious at
best.

Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Valentin Schneider &lt;valentin.schneider@arm.com&gt;
Tested-by: Valentin Schneider &lt;valentin.schneider@arm.com&gt;
Link: https://lkml.kernel.org/r/20210121103506.557620262@infradead.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>objtool: Don't fail on missing symbol table</title>
<updated>2021-02-07T13:47:41+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2021-01-14T22:14:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=536aea4013d50a4768262430e30c047818e57380'/>
<id>urn:sha1:536aea4013d50a4768262430e30c047818e57380</id>
<content type='text'>
[ Upstream commit 1d489151e9f9d1647110277ff77282fe4d96d09b ]

Thanks to a recent binutils change which doesn't generate unused
symbols, it's now possible for thunk_64.o be completely empty without
CONFIG_PREEMPTION: no text, no data, no symbols.

We could edit the Makefile to only build that file when
CONFIG_PREEMPTION is enabled, but that will likely create confusion
if/when the thunks end up getting used by some other code again.

Just ignore it and move on.

Reported-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Reviewed-by: Miroslav Benes &lt;mbenes@suse.cz&gt;
Tested-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Link: https://github.com/ClangBuiltLinux/linux/issues/1254
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ibmvfc: Set default timeout to avoid crash during migration</title>
<updated>2021-02-07T13:47:41+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2021-01-12T15:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85969e0bb3e6bdb9230882f98715422b353ef701'/>
<id>urn:sha1:85969e0bb3e6bdb9230882f98715422b353ef701</id>
<content type='text'>
[ Upstream commit 764907293edc1af7ac857389af9dc858944f53dc ]

While testing live partition mobility, we have observed occasional crashes
of the Linux partition. What we've seen is that during the live migration,
for specific configurations with large amounts of memory, slow network
links, and workloads that are changing memory a lot, the partition can end
up being suspended for 30 seconds or longer. This resulted in the following
scenario:

CPU 0                          CPU 1
-------------------------------  ----------------------------------
scsi_queue_rq                    migration_store
 -&gt; blk_mq_start_request          -&gt; rtas_ibm_suspend_me
  -&gt; blk_add_timer                 -&gt; on_each_cpu(rtas_percpu_suspend_me
              _______________________________________V
             |
             V
    -&gt; IPI from CPU 1
     -&gt; rtas_percpu_suspend_me
                                     -&gt; __rtas_suspend_last_cpu

-- Linux partition suspended for &gt; 30 seconds --
                                      -&gt; for_each_online_cpu(cpu)
                                           plpar_hcall_norets(H_PROD
 -&gt; scsi_dispatch_cmd
                                      -&gt; scsi_times_out
                                       -&gt; scsi_abort_command
                                        -&gt; queue_delayed_work
  -&gt; ibmvfc_queuecommand_lck
   -&gt; ibmvfc_send_event
    -&gt; ibmvfc_send_crq
     - returns H_CLOSED
   &lt;- returns SCSI_MLQUEUE_HOST_BUSY
-&gt; __blk_mq_requeue_request

                                      -&gt; scmd_eh_abort_handler
                                       -&gt; scsi_try_to_abort_cmd
                                         - returns SUCCESS
                                       -&gt; scsi_queue_insert

Normally, the SCMD_STATE_COMPLETE bit would protect against the command
completion and the timeout, but that doesn't work here, since we don't
check that at all in the SCSI_MLQUEUE_HOST_BUSY path.

In this case we end up calling scsi_queue_insert on a request that has
already been queued, or possibly even freed, and we crash.

The patch below simply increases the default I/O timeout to avoid this race
condition. This is also the timeout value that nearly all IBM SAN storage
recommends setting as the default value.

Link: https://lore.kernel.org/r/1610463998-19791-1-git-send-email-brking@linux.vnet.ibm.com
Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mac80211: fix fast-rx encryption check</title>
<updated>2021-02-07T13:47:41+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2020-12-18T18:47:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85f610963786f7a3853445918eb2cdcd177fd76d'/>
<id>urn:sha1:85f610963786f7a3853445918eb2cdcd177fd76d</id>
<content type='text'>
[ Upstream commit 622d3b4e39381262da7b18ca1ed1311df227de86 ]

When using WEP, the default unicast key needs to be selected, instead of
the STA PTK.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Link: https://lore.kernel.org/r/20201218184718.93650-5-nbd@nbd.name
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: libfc: Avoid invoking response handler twice if ep is already completed</title>
<updated>2021-02-07T13:47:40+00:00</updated>
<author>
<name>Javed Hasan</name>
<email>jhasan@marvell.com</email>
</author>
<published>2020-12-15T19:47:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2ab7ca11035a7024398e7d4439691fb9a58a11c'/>
<id>urn:sha1:d2ab7ca11035a7024398e7d4439691fb9a58a11c</id>
<content type='text'>
[ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ]

A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.

Sequence of events:

	 rport ba0200: Port timeout, state PLOGI
	 rport ba0200: Port entered PLOGI state from PLOGI state
	 xid 1052: Exchange timer armed : 20000 msecs      xid timer armed here
	 rport ba0200: Received LOGO request while in state PLOGI
	 rport ba0200: Delete port
	 rport ba0200: work event 3
	 rport ba0200: lld callback ev 3
	 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
	 bnx2fc: ba0200 - rport not created Yet!!
	 /* Here we reset any outstanding exchanges before
	 freeing rport using the exch_mgr_reset() */
	 xid 1052: Exchange timer canceled
	 /* Here we got two responses for one xid */
	 xid 1052: invoking resp(), esb 20000000 state 3
	 xid 1052: invoking resp(), esb 20000000 state 3
	 xid 1052: fc_rport_plogi_resp() : ep-&gt;resp_active 2
	 xid 1052: fc_rport_plogi_resp() : ep-&gt;resp_active 2

Skip the response if the exchange is already completed.

Link: https://lore.kernel.org/r/20201215194731.2326-1-jhasan@marvell.com
Signed-off-by: Javed Hasan &lt;jhasan@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_transport_srp: Don't block target in failfast state</title>
<updated>2021-02-07T13:47:40+00:00</updated>
<author>
<name>Martin Wilck</name>
<email>mwilck@suse.com</email>
</author>
<published>2021-01-11T14:25:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad19a1fd55edb5ea7822a7f12f96fa02ffd97195'/>
<id>urn:sha1:ad19a1fd55edb5ea7822a7f12f96fa02ffd97195</id>
<content type='text'>
[ Upstream commit 72eeb7c7151302ef007f1acd018cbf6f30e50321 ]

If the port is in SRP_RPORT_FAIL_FAST state when srp_reconnect_rport() is
entered, a transition to SDEV_BLOCK would be illegal, and a kernel WARNING
would be triggered. Skip scsi_target_block() in this case.

Link: https://lore.kernel.org/r/20210111142541.21534-1-mwilck@suse.com
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin Wilck &lt;mwilck@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86: __always_inline __{rd,wr}msr()</title>
<updated>2021-02-07T13:47:40+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2021-01-07T10:14:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72e7afeba7725b8457f24955ba3d81459f8d709a'/>
<id>urn:sha1:72e7afeba7725b8457f24955ba3d81459f8d709a</id>
<content type='text'>
[ Upstream commit 66a425011c61e71560c234492d204e83cfb73d1d ]

When the compiler choses to not inline the trivial MSR helpers:

  vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0xce: call to __wrmsr.constprop.14() leaves .noinstr.text section

Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt; # build-tested
Link: https://lore.kernel.org/r/X/bf3gV+BW7kGEsB@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: cpcap-usb: Fix warning for missing regulator_disable</title>
<updated>2021-02-07T13:47:40+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2020-12-30T10:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ded3ebe604e1339daf4a61063e12df5acf31d45'/>
<id>urn:sha1:3ded3ebe604e1339daf4a61063e12df5acf31d45</id>
<content type='text'>
[ Upstream commit 764257d9069a9c19758b626cc1ba4ae079335d9e ]

On deferred probe, we will get the following splat:

cpcap-usb-phy cpcap-usb-phy.0: could not initialize VBUS or ID IIO: -517
WARNING: CPU: 0 PID: 21 at drivers/regulator/core.c:2123 regulator_put+0x68/0x78
...
(regulator_put) from [&lt;c068ebf0&gt;] (release_nodes+0x1b4/0x1fc)
(release_nodes) from [&lt;c068a9a4&gt;] (really_probe+0x104/0x4a0)
(really_probe) from [&lt;c068b034&gt;] (driver_probe_device+0x58/0xb4)

Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Link: https://lore.kernel.org/r/20201230102105.11826-1-tony@atomide.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>driver core: Extend device_is_dependent()</title>
<updated>2021-02-07T13:47:40+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2021-01-15T18:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=41f4dfb4d5002b187f28ccdb5dd9451bf370c9c7'/>
<id>urn:sha1:41f4dfb4d5002b187f28ccdb5dd9451bf370c9c7</id>
<content type='text'>
commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream

If the device passed as the target (second argument) to
device_is_dependent() is not completely registered (that is, it has
been initialized, but not added yet), but the parent pointer of it
is set, it may be missing from the list of the parent's children
and device_for_each_child() called by device_is_dependent() cannot
be relied on to catch that dependency.

For this reason, modify device_is_dependent() to check the ancestors
of the target device by following its parent pointer in addition to
the device_for_each_child() walk.

Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Reported-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Tested-by: Stephan Gerhold &lt;stephan@gerhold.net&gt;
Reviewed-by: Saravana Kannan &lt;saravanak@google.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
Cc: stable &lt;stable@vger.kernel.org&gt;
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>
</feed>
