LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 4.4 00/31] 4.4.282-rc1 review
@ 2021-08-24 17:07 Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 01/31] ASoC: intel: atom: Fix reference to PCM buffer address Sasha Levin
                   ` (34 more replies)
  0 siblings, 35 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, torvalds, akpm, linux, shuah, patches, lkft-triage, pavel


This is the start of the stable review cycle for the 4.4.282 release.
There are 31 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu 26 Aug 2021 05:07:41 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
        https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-4.4.y&id2=v4.4.281
or in the git tree and branch at:
        git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

Thanks,
Sasha

-------------
Pseudo-Shortlog of commits:

Dave Gerlach (1):
  ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218

Dinghao Liu (1):
  net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32

Dongliang Mu (1):
  ipack: tpci200: fix many double free issues in tpci200_pci_probe

Doug Anderson (1):
  mmc: dw_mmc: Wait for data transfer after response errors.

Greg Kroah-Hartman (1):
  i2c: dev: zero out array used for i2c reads from userspace

Harshvardhan Jha (1):
  scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry()

Jaehoon Chung (1):
  mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default

Jaroslav Kysela (1):
  ALSA: hda - fix the 'Capture Switch' value change notifications

Maxim Levitsky (1):
  KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl
    (CVE-2021-3653)

Maximilian Heyne (1):
  xen/events: Fix race in set_evtchn_to_irq

Nathan Chancellor (1):
  vmlinux.lds.h: Handle clang's module.{c,d}tor sections

Ole Bjørn Midtbø (1):
  Bluetooth: hidp: use correct wait queue when removing ctrl_wait

Pavel Skripkin (1):
  net: 6pack: fix slab-out-of-bounds in decode_data

Peter Ujfalusi (1):
  dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller
    is not yet available

Randy Dunlap (2):
  x86/tools: Fix objdump version check again
  dccp: add do-while-0 stubs for dccp_pr_debug macros

Sasha Levin (1):
  Linux 4.4.282-rc1

Sreekanth Reddy (1):
  scsi: core: Avoid printing an error if target_alloc() returns -ENXIO

Takashi Iwai (2):
  ASoC: intel: atom: Fix reference to PCM buffer address
  ASoC: intel: atom: Fix breakage for PCM buffer address setup

Takeshi Misawa (1):
  net: Fix memory leak in ieee802154_raw_deliver

Thomas Gleixner (8):
  PCI/MSI: Enable and mask MSI-X early
  PCI/MSI: Do not set invalid bits in MSI mask
  PCI/MSI: Correct misleading comments
  PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown()
  PCI/MSI: Protect msi_desc::masked for multi-MSI
  PCI/MSI: Mask all unused MSI-X entries
  PCI/MSI: Enforce that MSI-X table entry is masked for update
  PCI/MSI: Enforce MSI[X] entry updates to be visible

Vincent Whitchurch (1):
  mmc: dw_mmc: Fix hang on data CRC error

Yu Kuai (1):
  dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe()

 Makefile                                      |   4 +-
 arch/arm/boot/dts/am43x-epos-evm.dts          |   2 +-
 arch/x86/include/asm/svm.h                    |   2 +
 arch/x86/kvm/svm.c                            |   6 +-
 arch/x86/tools/chkobjdump.awk                 |   1 +
 drivers/base/core.c                           |   1 +
 drivers/dma/of-dma.c                          |   9 +-
 drivers/dma/sh/usb-dmac.c                     |   2 +-
 drivers/i2c/i2c-dev.c                         |   5 +-
 drivers/ipack/carriers/tpci200.c              |  36 ++---
 drivers/mmc/host/dw_mmc.c                     |  48 +++++--
 .../ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c   |   4 +-
 drivers/net/hamradio/6pack.c                  |   6 +
 drivers/pci/msi.c                             | 129 +++++++++++-------
 drivers/scsi/megaraid/megaraid_mm.c           |  21 ++-
 drivers/scsi/scsi_scan.c                      |   3 +-
 drivers/xen/events/events_base.c              |  20 ++-
 include/asm-generic/vmlinux.lds.h             |   1 +
 include/linux/device.h                        |   1 +
 include/linux/msi.h                           |   2 +-
 net/bluetooth/hidp/core.c                     |   2 +-
 net/dccp/dccp.h                               |   6 +-
 net/ieee802154/socket.c                       |   7 +-
 sound/pci/hda/hda_generic.c                   |  10 +-
 sound/soc/intel/atom/sst-mfld-platform-pcm.c  |   3 +-
 25 files changed, 219 insertions(+), 112 deletions(-)

-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 01/31] ASoC: intel: atom: Fix reference to PCM buffer address
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 02/31] i2c: dev: zero out array used for i2c reads from userspace Sasha Levin
                   ` (33 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Takashi Iwai, Cezary Rojewski, Pierre-Louis Bossart, Mark Brown,
	Greg Kroah-Hartman

From: Takashi Iwai <tiwai@suse.de>

commit 2e6b836312a477d647a7920b56810a5a25f6c856 upstream.

PCM buffers might be allocated dynamically when the buffer
preallocation failed or a larger buffer is requested, and it's not
guaranteed that substream->dma_buffer points to the actually used
buffer.  The address should be retrieved from runtime->dma_addr,
instead of substream->dma_buffer (and shouldn't use virt_to_phys).

Also, remove the line overriding runtime->dma_area superfluously,
which was already set up at the PCM buffer allocation.

Cc: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210728112353.6675-3-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 sound/soc/intel/atom/sst-mfld-platform-pcm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index edb244331e6e..64079423b298 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -134,7 +134,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream,
 	snd_pcm_uframes_t period_size;
 	ssize_t periodbytes;
 	ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
-	u32 buffer_addr = virt_to_phys(substream->dma_buffer.area);
+	u32 buffer_addr = substream->runtime->dma_addr;
 
 	channels = substream->runtime->channels;
 	period_size = substream->runtime->period_size;
@@ -240,7 +240,6 @@ static int sst_platform_alloc_stream(struct snd_pcm_substream *substream,
 	/* set codec params and inform SST driver the same */
 	sst_fill_pcm_params(substream, &param);
 	sst_fill_alloc_params(substream, &alloc_params);
-	substream->runtime->dma_area = substream->dma_buffer.area;
 	str_params.sparams = param;
 	str_params.aparams = alloc_params;
 	str_params.codec = SST_CODEC_TYPE_PCM;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 02/31] i2c: dev: zero out array used for i2c reads from userspace
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 01/31] ASoC: intel: atom: Fix reference to PCM buffer address Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 03/31] net: Fix memory leak in ieee802154_raw_deliver Sasha Levin
                   ` (32 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Greg Kroah-Hartman, Eric Dumazet, Wolfram Sang

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86ff25ed6cd8240d18df58930bd8848b19fce308 upstream.

If an i2c driver happens to not provide the full amount of data that a
user asks for, it is possible that some uninitialized data could be sent
to userspace.  While all in-kernel drivers look to be safe, just be sure
by initializing the buffer to zero before it is passed to the i2c driver
so that any future drivers will not have this issue.

Also properly copy the amount of data recvieved to the userspace buffer,
as pointed out by Dan Carpenter.

Reported-by: Eric Dumazet <edumazet@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/i2c/i2c-dev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 7584f292e2fd..d0340b134e72 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -148,7 +148,7 @@ static ssize_t i2cdev_read(struct file *file, char __user *buf, size_t count,
 	if (count > 8192)
 		count = 8192;
 
-	tmp = kmalloc(count, GFP_KERNEL);
+	tmp = kzalloc(count, GFP_KERNEL);
 	if (tmp == NULL)
 		return -ENOMEM;
 
@@ -157,7 +157,8 @@ static ssize_t i2cdev_read(struct file *file, char __user *buf, size_t count,
 
 	ret = i2c_master_recv(client, tmp, count);
 	if (ret >= 0)
-		ret = copy_to_user(buf, tmp, count) ? -EFAULT : ret;
+		if (copy_to_user(buf, tmp, ret))
+			ret = -EFAULT;
 	kfree(tmp);
 	return ret;
 }
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 03/31] net: Fix memory leak in ieee802154_raw_deliver
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 01/31] ASoC: intel: atom: Fix reference to PCM buffer address Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 02/31] i2c: dev: zero out array used for i2c reads from userspace Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 04/31] xen/events: Fix race in set_evtchn_to_irq Sasha Levin
                   ` (31 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Takeshi Misawa, syzbot+1f68113fa907bf0695a8, Alexander Aring,
	Stefan Schmidt, Sasha Levin

From: Takeshi Misawa <jeliantsurux@gmail.com>

[ Upstream commit 1090340f7ee53e824fd4eef66a4855d548110c5b ]

If IEEE-802.15.4-RAW is closed before receive skb, skb is leaked.
Fix this, by freeing sk_receive_queue in sk->sk_destruct().

syzbot report:
BUG: memory leak
unreferenced object 0xffff88810f644600 (size 232):
  comm "softirq", pid 0, jiffies 4294967032 (age 81.270s)
  hex dump (first 32 bytes):
    10 7d 4b 12 81 88 ff ff 10 7d 4b 12 81 88 ff ff  .}K......}K.....
    00 00 00 00 00 00 00 00 40 7c 4b 12 81 88 ff ff  ........@|K.....
  backtrace:
    [<ffffffff83651d4a>] skb_clone+0xaa/0x2b0 net/core/skbuff.c:1496
    [<ffffffff83fe1b80>] ieee802154_raw_deliver net/ieee802154/socket.c:369 [inline]
    [<ffffffff83fe1b80>] ieee802154_rcv+0x100/0x340 net/ieee802154/socket.c:1070
    [<ffffffff8367cc7a>] __netif_receive_skb_one_core+0x6a/0xa0 net/core/dev.c:5384
    [<ffffffff8367cd07>] __netif_receive_skb+0x27/0xa0 net/core/dev.c:5498
    [<ffffffff8367cdd9>] netif_receive_skb_internal net/core/dev.c:5603 [inline]
    [<ffffffff8367cdd9>] netif_receive_skb+0x59/0x260 net/core/dev.c:5662
    [<ffffffff83fe6302>] ieee802154_deliver_skb net/mac802154/rx.c:29 [inline]
    [<ffffffff83fe6302>] ieee802154_subif_frame net/mac802154/rx.c:102 [inline]
    [<ffffffff83fe6302>] __ieee802154_rx_handle_packet net/mac802154/rx.c:212 [inline]
    [<ffffffff83fe6302>] ieee802154_rx+0x612/0x620 net/mac802154/rx.c:284
    [<ffffffff83fe59a6>] ieee802154_tasklet_handler+0x86/0xa0 net/mac802154/main.c:35
    [<ffffffff81232aab>] tasklet_action_common.constprop.0+0x5b/0x100 kernel/softirq.c:557
    [<ffffffff846000bf>] __do_softirq+0xbf/0x2ab kernel/softirq.c:345
    [<ffffffff81232f4c>] do_softirq kernel/softirq.c:248 [inline]
    [<ffffffff81232f4c>] do_softirq+0x5c/0x80 kernel/softirq.c:235
    [<ffffffff81232fc1>] __local_bh_enable_ip+0x51/0x60 kernel/softirq.c:198
    [<ffffffff8367a9a4>] local_bh_enable include/linux/bottom_half.h:32 [inline]
    [<ffffffff8367a9a4>] rcu_read_unlock_bh include/linux/rcupdate.h:745 [inline]
    [<ffffffff8367a9a4>] __dev_queue_xmit+0x7f4/0xf60 net/core/dev.c:4221
    [<ffffffff83fe2db4>] raw_sendmsg+0x1f4/0x2b0 net/ieee802154/socket.c:295
    [<ffffffff8363af16>] sock_sendmsg_nosec net/socket.c:654 [inline]
    [<ffffffff8363af16>] sock_sendmsg+0x56/0x80 net/socket.c:674
    [<ffffffff8363deec>] __sys_sendto+0x15c/0x200 net/socket.c:1977
    [<ffffffff8363dfb6>] __do_sys_sendto net/socket.c:1989 [inline]
    [<ffffffff8363dfb6>] __se_sys_sendto net/socket.c:1985 [inline]
    [<ffffffff8363dfb6>] __x64_sys_sendto+0x26/0x30 net/socket.c:1985

Fixes: 9ec767160357 ("net: add IEEE 802.15.4 socket family implementation")
Reported-and-tested-by: syzbot+1f68113fa907bf0695a8@syzkaller.appspotmail.com
Signed-off-by: Takeshi Misawa <jeliantsurux@gmail.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20210805075414.GA15796@DESKTOP
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/ieee802154/socket.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index cb6c0772ea36..42ab1b61b513 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -983,6 +983,11 @@ static const struct proto_ops ieee802154_dgram_ops = {
 #endif
 };
 
+static void ieee802154_sock_destruct(struct sock *sk)
+{
+	skb_queue_purge(&sk->sk_receive_queue);
+}
+
 /* Create a socket. Initialise the socket, blank the addresses
  * set the state.
  */
@@ -1023,7 +1028,7 @@ static int ieee802154_create(struct net *net, struct socket *sock,
 	sock->ops = ops;
 
 	sock_init_data(sock, sk);
-	/* FIXME: sk->sk_destruct */
+	sk->sk_destruct = ieee802154_sock_destruct;
 	sk->sk_family = PF_IEEE802154;
 
 	/* Checksums on by default */
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 04/31] xen/events: Fix race in set_evtchn_to_irq
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (2 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 03/31] net: Fix memory leak in ieee802154_raw_deliver Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 05/31] x86/tools: Fix objdump version check again Sasha Levin
                   ` (30 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Maximilian Heyne, Boris Ostrovsky, Sasha Levin

From: Maximilian Heyne <mheyne@amazon.de>

[ Upstream commit 88ca2521bd5b4e8b83743c01a2d4cb09325b51e9 ]

There is a TOCTOU issue in set_evtchn_to_irq. Rows in the evtchn_to_irq
mapping are lazily allocated in this function. The check whether the row
is already present and the row initialization is not synchronized. Two
threads can at the same time allocate a new row for evtchn_to_irq and
add the irq mapping to the their newly allocated row. One thread will
overwrite what the other has set for evtchn_to_irq[row] and therefore
the irq mapping is lost. This will trigger a BUG_ON later in
bind_evtchn_to_cpu:

  INFO: pci 0000:1a:15.4: [1d0f:8061] type 00 class 0x010802
  INFO: nvme 0000:1a:12.1: enabling device (0000 -> 0002)
  INFO: nvme nvme77: 1/0/0 default/read/poll queues
  CRIT: kernel BUG at drivers/xen/events/events_base.c:427!
  WARN: invalid opcode: 0000 [#1] SMP NOPTI
  WARN: Workqueue: nvme-reset-wq nvme_reset_work [nvme]
  WARN: RIP: e030:bind_evtchn_to_cpu+0xc2/0xd0
  WARN: Call Trace:
  WARN:  set_affinity_irq+0x121/0x150
  WARN:  irq_do_set_affinity+0x37/0xe0
  WARN:  irq_setup_affinity+0xf6/0x170
  WARN:  irq_startup+0x64/0xe0
  WARN:  __setup_irq+0x69e/0x740
  WARN:  ? request_threaded_irq+0xad/0x160
  WARN:  request_threaded_irq+0xf5/0x160
  WARN:  ? nvme_timeout+0x2f0/0x2f0 [nvme]
  WARN:  pci_request_irq+0xa9/0xf0
  WARN:  ? pci_alloc_irq_vectors_affinity+0xbb/0x130
  WARN:  queue_request_irq+0x4c/0x70 [nvme]
  WARN:  nvme_reset_work+0x82d/0x1550 [nvme]
  WARN:  ? check_preempt_wakeup+0x14f/0x230
  WARN:  ? check_preempt_curr+0x29/0x80
  WARN:  ? nvme_irq_check+0x30/0x30 [nvme]
  WARN:  process_one_work+0x18e/0x3c0
  WARN:  worker_thread+0x30/0x3a0
  WARN:  ? process_one_work+0x3c0/0x3c0
  WARN:  kthread+0x113/0x130
  WARN:  ? kthread_park+0x90/0x90
  WARN:  ret_from_fork+0x3a/0x50

This patch sets evtchn_to_irq rows via a cmpxchg operation so that they
will be set only once. The row is now cleared before writing it to
evtchn_to_irq in order to not create a race once the row is visible for
other threads.

While at it, do not require the page to be zeroed, because it will be
overwritten with -1's in clear_evtchn_to_irq_row anyway.

Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
Fixes: d0b075ffeede ("xen/events: Refactor evtchn_to_irq array to be dynamically allocated")
Link: https://lore.kernel.org/r/20210812130930.127134-1-mheyne@amazon.de
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/xen/events/events_base.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index f27118923390..0c5b187dc7a0 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -134,12 +134,12 @@ static void disable_dynirq(struct irq_data *data);
 
 static DEFINE_PER_CPU(unsigned int, irq_epoch);
 
-static void clear_evtchn_to_irq_row(unsigned row)
+static void clear_evtchn_to_irq_row(int *evtchn_row)
 {
 	unsigned col;
 
 	for (col = 0; col < EVTCHN_PER_ROW; col++)
-		WRITE_ONCE(evtchn_to_irq[row][col], -1);
+		WRITE_ONCE(evtchn_row[col], -1);
 }
 
 static void clear_evtchn_to_irq_all(void)
@@ -149,7 +149,7 @@ static void clear_evtchn_to_irq_all(void)
 	for (row = 0; row < EVTCHN_ROW(xen_evtchn_max_channels()); row++) {
 		if (evtchn_to_irq[row] == NULL)
 			continue;
-		clear_evtchn_to_irq_row(row);
+		clear_evtchn_to_irq_row(evtchn_to_irq[row]);
 	}
 }
 
@@ -157,6 +157,7 @@ static int set_evtchn_to_irq(unsigned evtchn, unsigned irq)
 {
 	unsigned row;
 	unsigned col;
+	int *evtchn_row;
 
 	if (evtchn >= xen_evtchn_max_channels())
 		return -EINVAL;
@@ -169,11 +170,18 @@ static int set_evtchn_to_irq(unsigned evtchn, unsigned irq)
 		if (irq == -1)
 			return 0;
 
-		evtchn_to_irq[row] = (int *)get_zeroed_page(GFP_KERNEL);
-		if (evtchn_to_irq[row] == NULL)
+		evtchn_row = (int *) __get_free_pages(GFP_KERNEL, 0);
+		if (evtchn_row == NULL)
 			return -ENOMEM;
 
-		clear_evtchn_to_irq_row(row);
+		clear_evtchn_to_irq_row(evtchn_row);
+
+		/*
+		 * We've prepared an empty row for the mapping. If a different
+		 * thread was faster inserting it, we can drop ours.
+		 */
+		if (cmpxchg(&evtchn_to_irq[row], NULL, evtchn_row) != NULL)
+			free_page((unsigned long) evtchn_row);
 	}
 
 	WRITE_ONCE(evtchn_to_irq[row][col], irq);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 05/31] x86/tools: Fix objdump version check again
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (3 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 04/31] xen/events: Fix race in set_evtchn_to_irq Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 06/31] PCI/MSI: Enable and mask MSI-X early Sasha Levin
                   ` (29 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Randy Dunlap, Thomas Gleixner, Masami Hiramatsu, Sasha Levin

From: Randy Dunlap <rdunlap@infradead.org>

[ Upstream commit 839ad22f755132838f406751439363c07272ad87 ]

Skip (omit) any version string info that is parenthesized.

Warning: objdump version 15) is older than 2.19
Warning: Skipping posttest.

where 'objdump -v' says:
GNU objdump (GNU Binutils; SUSE Linux Enterprise 15) 2.35.1.20201123-7.18

Fixes: 8bee738bb1979 ("x86: Fix objdump version check in chkobjdump.awk for different formats.")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210731000146.2720-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/x86/tools/chkobjdump.awk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/tools/chkobjdump.awk b/arch/x86/tools/chkobjdump.awk
index fd1ab80be0de..a4cf678cf5c8 100644
--- a/arch/x86/tools/chkobjdump.awk
+++ b/arch/x86/tools/chkobjdump.awk
@@ -10,6 +10,7 @@ BEGIN {
 
 /^GNU objdump/ {
 	verstr = ""
+	gsub(/\(.*\)/, "");
 	for (i = 3; i <= NF; i++)
 		if (match($(i), "^[0-9]")) {
 			verstr = $(i);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 06/31] PCI/MSI: Enable and mask MSI-X early
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (4 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 05/31] x86/tools: Fix objdump version check again Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 07/31] PCI/MSI: Do not set invalid bits in MSI mask Sasha Levin
                   ` (28 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Thomas Gleixner, Marc Zyngier, Ashok Raj, Bjorn Helgaas,
	Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit 438553958ba19296663c6d6583d208dfb6792830 upstream.

The ordering of MSI-X enable in hardware is dysfunctional:

 1) MSI-X is disabled in the control register
 2) Various setup functions
 3) pci_msi_setup_msi_irqs() is invoked which ends up accessing
    the MSI-X table entries
 4) MSI-X is enabled and masked in the control register with the
    comment that enabling is required for some hardware to access
    the MSI-X table

Step #4 obviously contradicts #3. The history of this is an issue with the
NIU hardware. When #4 was introduced the table access actually happened in
msix_program_entries() which was invoked after enabling and masking MSI-X.

This was changed in commit d71d6432e105 ("PCI/MSI: Kill redundant call of
irq_set_msi_desc() for MSI-X interrupts") which removed the table write
from msix_program_entries().

Interestingly enough nobody noticed and either NIU still works or it did
not get any testing with a kernel 3.19 or later.

Nevertheless this is inconsistent and there is no reason why MSI-X can't be
enabled and masked in the control register early on, i.e. move step #4
above to step #1. This preserves the NIU workaround and has no side effects
on other hardware.

Fixes: d71d6432e105 ("PCI/MSI: Kill redundant call of irq_set_msi_desc() for MSI-X interrupts")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.344136412@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 5d5e61d6c548..58bef2f6126b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -737,18 +737,25 @@ static int msix_capability_init(struct pci_dev *dev,
 	u16 control;
 	void __iomem *base;
 
-	/* Ensure MSI-X is disabled while it is set up */
-	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
+	/*
+	 * Some devices require MSI-X to be enabled before the MSI-X
+	 * registers can be accessed.  Mask all the vectors to prevent
+	 * interrupts coming in before they're fully set up.
+	 */
+	pci_msix_clear_and_set_ctrl(dev, 0, PCI_MSIX_FLAGS_MASKALL |
+				    PCI_MSIX_FLAGS_ENABLE);
 
 	pci_read_config_word(dev, dev->msix_cap + PCI_MSIX_FLAGS, &control);
 	/* Request & Map MSI-X table region */
 	base = msix_map_region(dev, msix_table_size(control));
-	if (!base)
-		return -ENOMEM;
+	if (!base) {
+		ret = -ENOMEM;
+		goto out_disable;
+	}
 
 	ret = msix_setup_entries(dev, base, entries, nvec);
 	if (ret)
-		return ret;
+		goto out_disable;
 
 	ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
 	if (ret)
@@ -759,14 +766,6 @@ static int msix_capability_init(struct pci_dev *dev,
 	if (ret)
 		goto out_free;
 
-	/*
-	 * Some devices require MSI-X to be enabled before we can touch the
-	 * MSI-X registers.  We need to mask all the vectors to prevent
-	 * interrupts coming in before they're fully set up.
-	 */
-	pci_msix_clear_and_set_ctrl(dev, 0,
-				PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_ENABLE);
-
 	msix_program_entries(dev, entries);
 
 	ret = populate_msi_sysfs(dev);
@@ -801,6 +800,9 @@ out_avail:
 out_free:
 	free_msi_irqs(dev);
 
+out_disable:
+	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
+
 	return ret;
 }
 
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 07/31] PCI/MSI: Do not set invalid bits in MSI mask
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (5 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 06/31] PCI/MSI: Enable and mask MSI-X early Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 08/31] PCI/MSI: Correct misleading comments Sasha Levin
                   ` (27 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Thomas Gleixner, Marc Zyngier, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit 361fd37397f77578735907341579397d5bed0a2d upstream.

msi_mask_irq() takes a mask and a flags argument. The mask argument is used
to mask out bits from the cached mask and the flags argument to set bits.

Some places invoke it with a flags argument which sets bits which are not
used by the device, i.e. when the device supports up to 8 vectors a full
unmask in some places sets the mask to 0xFFFFFF00. While devices probably
do not care, it's still bad practice.

Fixes: 7ba1930db02f ("PCI MSI: Unmask MSI if setup failed")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.568173099@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 58bef2f6126b..4680632b9e65 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -624,21 +624,21 @@ static int msi_capability_init(struct pci_dev *dev, int nvec)
 	/* Configure MSI capability structure */
 	ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
 	if (ret) {
-		msi_mask_irq(entry, mask, ~mask);
+		msi_mask_irq(entry, mask, 0);
 		free_msi_irqs(dev);
 		return ret;
 	}
 
 	ret = msi_verify_entries(dev);
 	if (ret) {
-		msi_mask_irq(entry, mask, ~mask);
+		msi_mask_irq(entry, mask, 0);
 		free_msi_irqs(dev);
 		return ret;
 	}
 
 	ret = populate_msi_sysfs(dev);
 	if (ret) {
-		msi_mask_irq(entry, mask, ~mask);
+		msi_mask_irq(entry, mask, 0);
 		free_msi_irqs(dev);
 		return ret;
 	}
@@ -891,7 +891,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
 	/* Return the device with MSI unmasked as initial states */
 	mask = msi_mask(desc->msi_attrib.multi_cap);
 	/* Keep cached state to be restored */
-	__pci_msi_desc_mask_irq(desc, mask, ~mask);
+	__pci_msi_desc_mask_irq(desc, mask, 0);
 
 	/* Restore dev->irq to its default pin-assertion irq */
 	dev->irq = desc->msi_attrib.default_irq;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 08/31] PCI/MSI: Correct misleading comments
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (6 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 07/31] PCI/MSI: Do not set invalid bits in MSI mask Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 09/31] PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown() Sasha Levin
                   ` (26 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Thomas Gleixner, Marc Zyngier, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit 689e6b5351573c38ccf92a0dd8b3e2c2241e4aff upstream.

The comments about preserving the cached state in pci_msi[x]_shutdown() are
misleading as the MSI descriptors are freed right after those functions
return. So there is nothing to restore. Preparatory change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.621609423@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 4680632b9e65..84ccff0f4b1b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -890,7 +890,6 @@ void pci_msi_shutdown(struct pci_dev *dev)
 
 	/* Return the device with MSI unmasked as initial states */
 	mask = msi_mask(desc->msi_attrib.multi_cap);
-	/* Keep cached state to be restored */
 	__pci_msi_desc_mask_irq(desc, mask, 0);
 
 	/* Restore dev->irq to its default pin-assertion irq */
@@ -988,10 +987,8 @@ void pci_msix_shutdown(struct pci_dev *dev)
 		return;
 
 	/* Return the device with MSI-X masked as initial states */
-	for_each_pci_msi_entry(entry, dev) {
-		/* Keep cached states to be restored */
+	for_each_pci_msi_entry(entry, dev)
 		__pci_msix_desc_mask_irq(entry, 1);
-	}
 
 	pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
 	pci_intx_for_msi(dev, 1);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 09/31] PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown()
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (7 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 08/31] PCI/MSI: Correct misleading comments Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 10/31] PCI/MSI: Protect msi_desc::masked for multi-MSI Sasha Levin
                   ` (25 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Thomas Gleixner, Marc Zyngier, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit d28d4ad2a1aef27458b3383725bb179beb8d015c upstream.

No point in using the raw write function from shutdown. Preparatory change
to introduce proper serialization for the msi_desc::masked cache.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.674391354@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 84ccff0f4b1b..e3865e274389 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -890,7 +890,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
 
 	/* Return the device with MSI unmasked as initial states */
 	mask = msi_mask(desc->msi_attrib.multi_cap);
-	__pci_msi_desc_mask_irq(desc, mask, 0);
+	msi_mask_irq(desc, mask, 0);
 
 	/* Restore dev->irq to its default pin-assertion irq */
 	dev->irq = desc->msi_attrib.default_irq;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 10/31] PCI/MSI: Protect msi_desc::masked for multi-MSI
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (8 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 09/31] PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown() Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 11/31] PCI/MSI: Mask all unused MSI-X entries Sasha Levin
                   ` (24 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Thomas Gleixner, Marc Zyngier, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit 77e89afc25f30abd56e76a809ee2884d7c1b63ce upstream.

Multi-MSI uses a single MSI descriptor and there is a single mask register
when the device supports per vector masking. To avoid reading back the mask
register the value is cached in the MSI descriptor and updates are done by
clearing and setting bits in the cache and writing it to the device.

But nothing protects msi_desc::masked and the mask register from being
modified concurrently on two different CPUs for two different Linux
interrupts which belong to the same multi-MSI descriptor.

Add a lock to struct device and protect any operation on the mask and the
mask register with it.

This makes the update of msi_desc::masked unconditional, but there is no
place which requires a modification of the hardware register without
updating the masked cache.

msi_mask_irq() is now an empty wrapper which will be cleaned up in follow
up changes.

The problem goes way back to the initial support of multi-MSI, but picking
the commit which introduced the mask cache is a valid cut off point
(2.6.30).

Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.726833414@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/base/core.c    |  1 +
 drivers/pci/msi.c      | 19 ++++++++++---------
 include/linux/device.h |  1 +
 include/linux/msi.h    |  2 +-
 4 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 7e419aaf3c24..23517100c9a5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -710,6 +710,7 @@ void device_initialize(struct device *dev)
 	device_pm_init(dev);
 	set_dev_node(dev, -1);
 #ifdef CONFIG_GENERIC_MSI_IRQ
+	raw_spin_lock_init(&dev->msi_lock);
 	INIT_LIST_HEAD(&dev->msi_list);
 #endif
 }
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e3865e274389..dffa5c5bcc76 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -187,24 +187,25 @@ static inline __attribute_const__ u32 msi_mask(unsigned x)
  * reliably as devices without an INTx disable bit will then generate a
  * level IRQ which will never be cleared.
  */
-u32 __pci_msi_desc_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
+void __pci_msi_desc_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
 {
-	u32 mask_bits = desc->masked;
+	raw_spinlock_t *lock = &desc->dev->msi_lock;
+	unsigned long flags;
 
 	if (pci_msi_ignore_mask || !desc->msi_attrib.maskbit)
-		return 0;
+		return;
 
-	mask_bits &= ~mask;
-	mask_bits |= flag;
+	raw_spin_lock_irqsave(lock, flags);
+	desc->masked &= ~mask;
+	desc->masked |= flag;
 	pci_write_config_dword(msi_desc_to_pci_dev(desc), desc->mask_pos,
-			       mask_bits);
-
-	return mask_bits;
+			       desc->masked);
+	raw_spin_unlock_irqrestore(lock, flags);
 }
 
 static void msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
 {
-	desc->masked = __pci_msi_desc_mask_irq(desc, mask, flag);
+	__pci_msi_desc_mask_irq(desc, mask, flag);
 }
 
 /*
diff --git a/include/linux/device.h b/include/linux/device.h
index eb891c9c4b62..df0199e768d4 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -794,6 +794,7 @@ struct device {
 	struct dev_pin_info	*pins;
 #endif
 #ifdef CONFIG_GENERIC_MSI_IRQ
+	raw_spinlock_t		msi_lock;
 	struct list_head	msi_list;
 #endif
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index d0d50cf00b4d..037f47fe76e6 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -128,7 +128,7 @@ void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 
 u32 __pci_msix_desc_mask_irq(struct msi_desc *desc, u32 flag);
-u32 __pci_msi_desc_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
+void __pci_msi_desc_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
 void pci_msi_mask_irq(struct irq_data *data);
 void pci_msi_unmask_irq(struct irq_data *data);
 
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 11/31] PCI/MSI: Mask all unused MSI-X entries
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (9 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 10/31] PCI/MSI: Protect msi_desc::masked for multi-MSI Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 12/31] PCI/MSI: Enforce that MSI-X table entry is masked for update Sasha Levin
                   ` (23 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Thomas Gleixner, Marc Zyngier, Bjorn Helgaas, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit 7d5ec3d3612396dc6d4b76366d20ab9fc06f399f upstream.

When MSI-X is enabled the ordering of calls is:

  msix_map_region();
  msix_setup_entries();
  pci_msi_setup_msi_irqs();
  msix_program_entries();

This has a few interesting issues:

 1) msix_setup_entries() allocates the MSI descriptors and initializes them
    except for the msi_desc:masked member which is left zero initialized.

 2) pci_msi_setup_msi_irqs() allocates the interrupt descriptors and sets
    up the MSI interrupts which ends up in pci_write_msi_msg() unless the
    interrupt chip provides its own irq_write_msi_msg() function.

 3) msix_program_entries() does not do what the name suggests. It solely
    updates the entries array (if not NULL) and initializes the masked
    member for each MSI descriptor by reading the hardware state and then
    masks the entry.

Obviously this has some issues:

 1) The uninitialized masked member of msi_desc prevents the enforcement
    of masking the entry in pci_write_msi_msg() depending on the cached
    masked bit. Aside of that half initialized data is a NONO in general

 2) msix_program_entries() only ensures that the actually allocated entries
    are masked. This is wrong as experimentation with crash testing and
    crash kernel kexec has shown.

    This limited testing unearthed that when the production kernel had more
    entries in use and unmasked when it crashed and the crash kernel
    allocated a smaller amount of entries, then a full scan of all entries
    found unmasked entries which were in use in the production kernel.

    This is obviously a device or emulation issue as the device reset
    should mask all MSI-X table entries, but obviously that's just part
    of the paper specification.

Cure this by:

 1) Masking all table entries in hardware
 2) Initializing msi_desc::masked in msix_setup_entries()
 3) Removing the mask dance in msix_program_entries()
 4) Renaming msix_program_entries() to msix_update_entries() to
    reflect the purpose of that function.

As the masking of unused entries has never been done the Fixes tag refers
to a commit in:
   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.403833459@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index dffa5c5bcc76..9cc4a598c652 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -208,6 +208,12 @@ static void msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
 	__pci_msi_desc_mask_irq(desc, mask, flag);
 }
 
+static void __iomem *pci_msix_desc_addr(struct msi_desc *desc)
+{
+	return desc->mask_base +
+		desc->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
+}
+
 /*
  * This internal function does not flush PCI writes to the device.
  * All users must ensure that they read from the device before either
@@ -678,6 +684,7 @@ static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
 			      struct msix_entry *entries, int nvec)
 {
 	struct msi_desc *entry;
+	void __iomem *addr;
 	int i;
 
 	for (i = 0; i < nvec; i++) {
@@ -698,29 +705,35 @@ static int msix_setup_entries(struct pci_dev *dev, void __iomem *base,
 		entry->mask_base		= base;
 		entry->nvec_used		= 1;
 
+		addr = pci_msix_desc_addr(entry);
+		entry->masked = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL);
 		list_add_tail(&entry->list, dev_to_msi_list(&dev->dev));
 	}
 
 	return 0;
 }
 
-static void msix_program_entries(struct pci_dev *dev,
-				 struct msix_entry *entries)
+static void msix_update_entries(struct pci_dev *dev, struct msix_entry *entries)
 {
 	struct msi_desc *entry;
-	int i = 0;
 
 	for_each_pci_msi_entry(entry, dev) {
-		int offset = entries[i].entry * PCI_MSIX_ENTRY_SIZE +
-						PCI_MSIX_ENTRY_VECTOR_CTRL;
-
-		entries[i].vector = entry->irq;
-		entry->masked = readl(entry->mask_base + offset);
-		msix_mask_irq(entry, 1);
-		i++;
+		if (entries) {
+			entries->vector = entry->irq;
+			entries++;
+		}
 	}
 }
 
+static void msix_mask_all(void __iomem *base, int tsize)
+{
+	u32 ctrl = PCI_MSIX_ENTRY_CTRL_MASKBIT;
+	int i;
+
+	for (i = 0; i < tsize; i++, base += PCI_MSIX_ENTRY_SIZE)
+		writel(ctrl, base + PCI_MSIX_ENTRY_VECTOR_CTRL);
+}
+
 /**
  * msix_capability_init - configure device's MSI-X capability
  * @dev: pointer to the pci_dev data structure of MSI-X device function
@@ -734,9 +747,9 @@ static void msix_program_entries(struct pci_dev *dev,
 static int msix_capability_init(struct pci_dev *dev,
 				struct msix_entry *entries, int nvec)
 {
-	int ret;
-	u16 control;
 	void __iomem *base;
+	int ret, tsize;
+	u16 control;
 
 	/*
 	 * Some devices require MSI-X to be enabled before the MSI-X
@@ -748,12 +761,16 @@ static int msix_capability_init(struct pci_dev *dev,
 
 	pci_read_config_word(dev, dev->msix_cap + PCI_MSIX_FLAGS, &control);
 	/* Request & Map MSI-X table region */
-	base = msix_map_region(dev, msix_table_size(control));
+	tsize = msix_table_size(control);
+	base = msix_map_region(dev, tsize);
 	if (!base) {
 		ret = -ENOMEM;
 		goto out_disable;
 	}
 
+	/* Ensure that all table entries are masked. */
+	msix_mask_all(base, tsize);
+
 	ret = msix_setup_entries(dev, base, entries, nvec);
 	if (ret)
 		goto out_disable;
@@ -767,7 +784,7 @@ static int msix_capability_init(struct pci_dev *dev,
 	if (ret)
 		goto out_free;
 
-	msix_program_entries(dev, entries);
+	msix_update_entries(dev, entries);
 
 	ret = populate_msi_sysfs(dev);
 	if (ret)
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 12/31] PCI/MSI: Enforce that MSI-X table entry is masked for update
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (10 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 11/31] PCI/MSI: Mask all unused MSI-X entries Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 13/31] PCI/MSI: Enforce MSI[X] entry updates to be visible Sasha Levin
                   ` (22 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Thomas Gleixner, Kevin Tian, Marc Zyngier, Bjorn Helgaas,
	Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit da181dc974ad667579baece33c2c8d2d1e4558d5 upstream.

The specification (PCIe r5.0, sec 6.1.4.5) states:

    For MSI-X, a function is permitted to cache Address and Data values
    from unmasked MSI-X Table entries. However, anytime software unmasks a
    currently masked MSI-X Table entry either by clearing its Mask bit or
    by clearing the Function Mask bit, the function must update any Address
    or Data values that it cached from that entry. If software changes the
    Address or Data value of an entry while the entry is unmasked, the
    result is undefined.

The Linux kernel's MSI-X support never enforced that the entry is masked
before the entry is modified hence the Fixes tag refers to a commit in:
      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Enforce the entry to be masked across the update.

There is no point in enforcing this to be handled at all possible call
sites as this is just pointless code duplication and the common update
function is the obvious place to enforce this.

Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
Reported-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.462096385@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 9cc4a598c652..208d7b179914 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -320,13 +320,26 @@ void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 	if (dev->current_state != PCI_D0) {
 		/* Don't touch the hardware now */
 	} else if (entry->msi_attrib.is_msix) {
-		void __iomem *base;
-		base = entry->mask_base +
-			entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
+		void __iomem *base = pci_msix_desc_addr(entry);
+		bool unmasked = !(entry->masked & PCI_MSIX_ENTRY_CTRL_MASKBIT);
+
+		/*
+		 * The specification mandates that the entry is masked
+		 * when the message is modified:
+		 *
+		 * "If software changes the Address or Data value of an
+		 * entry while the entry is unmasked, the result is
+		 * undefined."
+		 */
+		if (unmasked)
+			__pci_msix_desc_mask_irq(entry, PCI_MSIX_ENTRY_CTRL_MASKBIT);
 
 		writel(msg->address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
 		writel(msg->address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
 		writel(msg->data, base + PCI_MSIX_ENTRY_DATA);
+
+		if (unmasked)
+			__pci_msix_desc_mask_irq(entry, 0);
 	} else {
 		int pos = dev->msi_cap;
 		u16 msgctl;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 13/31] PCI/MSI: Enforce MSI[X] entry updates to be visible
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (11 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 12/31] PCI/MSI: Enforce that MSI-X table entry is masked for update Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 14/31] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Sasha Levin
                   ` (21 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Thomas Gleixner, Marc Zyngier, Bjorn Helgaas, Greg Kroah-Hartman

From: Thomas Gleixner <tglx@linutronix.de>

commit b9255a7cb51754e8d2645b65dd31805e282b4f3e upstream.

Nothing enforces the posted writes to be visible when the function
returns. Flush them even if the flush might be redundant when the entry is
masked already as the unmask will flush as well. This is either setup or a
rare affinity change event so the extra flush is not the end of the world.

While this is more a theoretical issue especially the logic in the X86
specific msi_set_affinity() function relies on the assumption that the
update has reached the hardware when the function returns.

Again, as this never has been enforced the Fixes tag refers to a commit in:
   git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Fixes: f036d4ea5fa7 ("[PATCH] ia32 Message Signalled Interrupt support")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.515188147@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/pci/msi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 208d7b179914..e9c98f1576dd 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -340,6 +340,9 @@ void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 
 		if (unmasked)
 			__pci_msix_desc_mask_irq(entry, 0);
+
+		/* Ensure that the writes are visible in the device */
+		readl(base + PCI_MSIX_ENTRY_DATA);
 	} else {
 		int pos = dev->msi_cap;
 		u16 msgctl;
@@ -360,6 +363,8 @@ void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 			pci_write_config_word(dev, pos + PCI_MSI_DATA_32,
 					      msg->data);
 		}
+		/* Ensure that the writes are visible in the device */
+		pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &msgctl);
 	}
 	entry->msg = *msg;
 }
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 14/31] vmlinux.lds.h: Handle clang's module.{c,d}tor sections
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (12 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 13/31] PCI/MSI: Enforce MSI[X] entry updates to be visible Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 15/31] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653) Sasha Levin
                   ` (20 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Nathan Chancellor, Nick Desaulniers, Fangrui Song, Marco Elver,
	Kees Cook, Greg Kroah-Hartman

From: Nathan Chancellor <nathan@kernel.org>

commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.

A recent change in LLVM causes module_{c,d}tor sections to appear when
CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN
flag, so it is in a separate section even with -fno-function-sections
(default)".

Place them in the TEXT_TEXT section so that these technologies continue
to work with the newer compiler versions. All of the KASAN and KCSAN
KUnit tests continue to pass after this change.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1432
Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210731023107.1932981-1-nathan@kernel.org
[nc: Fix conflicts due to lack of cf68fffb66d60 and 266ff2a8f51f0]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c8535bc1826f..84c03e9647a1 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -427,6 +427,7 @@
 		*(.text.unlikely .text.unlikely.*)			\
 		*(.text.unknown .text.unknown.*)			\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 	MEM_KEEP(init.text)						\
 	MEM_KEEP(exit.text)						\
 
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 15/31] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (13 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 14/31] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 16/31] dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() Sasha Levin
                   ` (19 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Maxim Levitsky, Paolo Bonzini, Greg Kroah-Hartman

From: Maxim Levitsky <mlevitsk@redhat.com>

[ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]

* Invert the mask of bits that we pick from L2 in
  nested_vmcb02_prepare_control

* Invert and explicitly use VIRQ related bits bitmask in svm_clear_vintr

This fixes a security issue that allowed a malicious L1 to run L2 with
AVIC enabled, which allowed the L2 to exploit the uninitialized and enabled
AVIC to read/write the host physical memory at some offsets.

Fixes: 3d6368ef580a ("KVM: SVM: Add VMRUN handler")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/include/asm/svm.h | 2 ++
 arch/x86/kvm/svm.c         | 6 +++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 6136d99f537b..c1adb2ed6d41 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -108,6 +108,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
 #define V_IGN_TPR_SHIFT 20
 #define V_IGN_TPR_MASK (1 << V_IGN_TPR_SHIFT)
 
+#define V_IRQ_INJECTION_BITS_MASK (V_IRQ_MASK | V_INTR_PRIO_MASK | V_IGN_TPR_MASK)
+
 #define V_INTR_MASKING_SHIFT 24
 #define V_INTR_MASKING_MASK (1 << V_INTR_MASKING_SHIFT)
 
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 931acac69703..77bee73faebc 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2564,7 +2564,11 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
 	svm->nested.intercept            = nested_vmcb->control.intercept;
 
 	svm_flush_tlb(&svm->vcpu);
-	svm->vmcb->control.int_ctl = nested_vmcb->control.int_ctl | V_INTR_MASKING_MASK;
+	svm->vmcb->control.int_ctl = nested_vmcb->control.int_ctl &
+			(V_TPR_MASK | V_IRQ_INJECTION_BITS_MASK);
+
+	svm->vmcb->control.int_ctl |= V_INTR_MASKING_MASK;
+
 	if (nested_vmcb->control.int_ctl & V_INTR_MASKING_MASK)
 		svm->vcpu.arch.hflags |= HF_VINTR_MASK;
 	else
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 16/31] dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe()
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (14 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 15/31] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653) Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 17/31] ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218 Sasha Levin
                   ` (18 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Yu Kuai, Hulk Robot, Vinod Koul, Sasha Levin

From: Yu Kuai <yukuai3@huawei.com>

[ Upstream commit 1da569fa7ec8cb0591c74aa3050d4ea1397778b4 ]

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by moving the error_pm label above the pm_runtime_put() in
the error path.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20210706124521.1371901-1-yukuai3@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/sh/usb-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index cc8fc601ed47..416057d9f0b6 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -863,8 +863,8 @@ static int usb_dmac_probe(struct platform_device *pdev)
 
 error:
 	of_dma_controller_free(pdev->dev.of_node);
-	pm_runtime_put(&pdev->dev);
 error_pm:
+	pm_runtime_put(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return ret;
 }
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 17/31] ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (15 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 16/31] dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 18/31] dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available Sasha Levin
                   ` (17 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Dave Gerlach, Kevin Hilman, Tony Lindgren, Sasha Levin

From: Dave Gerlach <d-gerlach@ti.com>

[ Upstream commit 20a6b3fd8e2e2c063b25fbf2ee74d86b898e5087 ]

Based on the latest timing specifications for the TPS65218 from the data
sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
from November 2014, we must change the i2c bus speed to better fit within
the minimum high SCL time required for proper i2c transfer.

When running at 400khz, measurements show that SCL spends
0.8125 uS/1.666 uS high/low which violates the requirement for minimum
high period of SCL provided in datasheet Table 7.6 which is 1 uS.
Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.

Without this patch occasionally a voltage set operation from the kernel
will appear to have worked but the actual voltage reflected on the PMIC
will not have updated, causing problems especially with cpufreq that may
update to a higher OPP without actually raising the voltage on DCDC2,
leading to a hang.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index a74b09f17a1a..e7cd99793bc6 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -411,7 +411,7 @@
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
-	clock-frequency = <400000>;
+	clock-frequency = <100000>;
 
 	tps65218: tps65218@24 {
 		reg = <0x24>;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 18/31] dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (16 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 17/31] ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218 Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 19/31] scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry() Sasha Levin
                   ` (16 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Peter Ujfalusi, Vinod Koul, Sasha Levin

From: Peter Ujfalusi <peter.ujfalusi@gmail.com>

[ Upstream commit eda97cb095f2958bbad55684a6ca3e7d7af0176a ]

If the router_xlate can not find the controller in the available DMA
devices then it should return with -EPORBE_DEFER in a same way as the
of_dma_request_slave_channel() does.

The issue can be reproduced if the event router is registered before the
DMA controller itself and a driver would request for a channel before the
controller is registered.
In of_dma_request_slave_channel():
1. of_dma_find_controller() would find the dma_router
2. ofdma->of_dma_xlate() would fail and returned NULL
3. -ENODEV is returned as error code

with this patch we would return in this case the correct -EPROBE_DEFER and
the client can try to request the channel later.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210717190021.21897-1-peter.ujfalusi@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/dma/of-dma.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 86c591481dfe..4a5dbf30605a 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -68,8 +68,12 @@ static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
 		return NULL;
 
 	ofdma_target = of_dma_find_controller(&dma_spec_target);
-	if (!ofdma_target)
-		return NULL;
+	if (!ofdma_target) {
+		ofdma->dma_router->route_free(ofdma->dma_router->dev,
+					      route_data);
+		chan = ERR_PTR(-EPROBE_DEFER);
+		goto err;
+	}
 
 	chan = ofdma_target->of_dma_xlate(&dma_spec_target, ofdma_target);
 	if (IS_ERR_OR_NULL(chan)) {
@@ -80,6 +84,7 @@ static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
 		chan->route_data = route_data;
 	}
 
+err:
 	/*
 	 * Need to put the node back since the ofdma->of_dma_route_allocate
 	 * has taken it for generating the new, translated dma_spec
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 19/31] scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry()
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (17 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 18/31] dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 20/31] scsi: core: Avoid printing an error if target_alloc() returns -ENXIO Sasha Levin
                   ` (15 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Harshvardhan Jha, Sumit Saxena, Martin K . Petersen, Sasha Levin

From: Harshvardhan Jha <harshvardhan.jha@oracle.com>

[ Upstream commit 77541f78eadfe9fdb018a7b8b69f0f2af2cf4b82 ]

The list_for_each_entry() iterator, "adapter" in this code, can never be
NULL.  If we exit the loop without finding the correct adapter then
"adapter" points invalid memory that is an offset from the list head.  This
will eventually lead to memory corruption and presumably a kernel crash.

Link: https://lore.kernel.org/r/20210708074642.23599-1-harshvardhan.jha@oracle.com
Acked-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Harshvardhan Jha <harshvardhan.jha@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/scsi/megaraid/megaraid_mm.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mm.c b/drivers/scsi/megaraid/megaraid_mm.c
index a70692779a16..34067dfd2841 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -246,7 +246,7 @@ mraid_mm_get_adapter(mimd_t __user *umimd, int *rval)
 	mimd_t		mimd;
 	uint32_t	adapno;
 	int		iterator;
-
+	bool		is_found;
 
 	if (copy_from_user(&mimd, umimd, sizeof(mimd_t))) {
 		*rval = -EFAULT;
@@ -262,12 +262,16 @@ mraid_mm_get_adapter(mimd_t __user *umimd, int *rval)
 
 	adapter = NULL;
 	iterator = 0;
+	is_found = false;
 
 	list_for_each_entry(adapter, &adapters_list_g, list) {
-		if (iterator++ == adapno) break;
+		if (iterator++ == adapno) {
+			is_found = true;
+			break;
+		}
 	}
 
-	if (!adapter) {
+	if (!is_found) {
 		*rval = -ENODEV;
 		return NULL;
 	}
@@ -735,6 +739,7 @@ ioctl_done(uioc_t *kioc)
 	uint32_t	adapno;
 	int		iterator;
 	mraid_mmadp_t*	adapter;
+	bool		is_found;
 
 	/*
 	 * When the kioc returns from driver, make sure it still doesn't
@@ -757,19 +762,23 @@ ioctl_done(uioc_t *kioc)
 		iterator	= 0;
 		adapter		= NULL;
 		adapno		= kioc->adapno;
+		is_found	= false;
 
 		con_log(CL_ANN, ( KERN_WARNING "megaraid cmm: completed "
 					"ioctl that was timedout before\n"));
 
 		list_for_each_entry(adapter, &adapters_list_g, list) {
-			if (iterator++ == adapno) break;
+			if (iterator++ == adapno) {
+				is_found = true;
+				break;
+			}
 		}
 
 		kioc->timedout = 0;
 
-		if (adapter) {
+		if (is_found)
 			mraid_mm_dealloc_kioc( adapter, kioc );
-		}
+
 	}
 	else {
 		wake_up(&wait_q);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 20/31] scsi: core: Avoid printing an error if target_alloc() returns -ENXIO
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (18 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 19/31] scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry() Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 21/31] Bluetooth: hidp: use correct wait queue when removing ctrl_wait Sasha Levin
                   ` (14 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Sreekanth Reddy, Martin K . Petersen, Sasha Levin

From: Sreekanth Reddy <sreekanth.reddy@broadcom.com>

[ Upstream commit 70edd2e6f652f67d854981fd67f9ad0f1deaea92 ]

Avoid printing a 'target allocation failed' error if the driver
target_alloc() callback function returns -ENXIO. This return value
indicates that the corresponding H:C:T:L entry is empty.

Removing this error reduces the scan time if the user issues SCAN_WILD_CARD
scan operation through sysfs parameter on a host with a lot of empty
H:C:T:L entries.

Avoiding the printk on -ENXIO matches the behavior of the other callback
functions during scanning.

Link: https://lore.kernel.org/r/20210726115402.1936-1-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/scsi/scsi_scan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 647a057a9b6c..5e34c7ed483c 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -457,7 +457,8 @@ static struct scsi_target *scsi_alloc_target(struct device *parent,
 		error = shost->hostt->target_alloc(starget);
 
 		if(error) {
-			dev_printk(KERN_ERR, dev, "target allocation failed, error %d\n", error);
+			if (error != -ENXIO)
+				dev_err(dev, "target allocation failed, error %d\n", error);
 			/* don't want scsi_target_reap to do the final
 			 * put because it will be under the host lock */
 			scsi_target_destroy(starget);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 21/31] Bluetooth: hidp: use correct wait queue when removing ctrl_wait
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (19 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 20/31] scsi: core: Avoid printing an error if target_alloc() returns -ENXIO Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 22/31] dccp: add do-while-0 stubs for dccp_pr_debug macros Sasha Levin
                   ` (13 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Ole Bjørn Midtbø, Marcel Holtmann, Sasha Levin

From: Ole Bjørn Midtbø <omidtbo@cisco.com>

[ Upstream commit cca342d98bef68151a80b024f7bf5f388d1fbdea ]

A different wait queue was used when removing ctrl_wait than when adding
it. This effectively made the remove operation without locking compared
to other operations on the wait queue ctrl_wait was part of. This caused
issues like below where dead000000000100 is LIST_POISON1 and
dead000000000200 is LIST_POISON2.

 list_add corruption. next->prev should be prev (ffffffc1b0a33a08), \
	but was dead000000000200. (next=ffffffc03ac77de0).
 ------------[ cut here ]------------
 CPU: 3 PID: 2138 Comm: bluetoothd Tainted: G           O    4.4.238+ #9
 ...
 ---[ end trace 0adc2158f0646eac ]---
 Call trace:
 [<ffffffc000443f78>] __list_add+0x38/0xb0
 [<ffffffc0000f0d04>] add_wait_queue+0x4c/0x68
 [<ffffffc00020eecc>] __pollwait+0xec/0x100
 [<ffffffc000d1556c>] bt_sock_poll+0x74/0x200
 [<ffffffc000bdb8a8>] sock_poll+0x110/0x128
 [<ffffffc000210378>] do_sys_poll+0x220/0x480
 [<ffffffc0002106f0>] SyS_poll+0x80/0x138
 [<ffffffc00008510c>] __sys_trace_return+0x0/0x4

 Unable to handle kernel paging request at virtual address dead000000000100
 ...
 CPU: 4 PID: 5387 Comm: kworker/u15:3 Tainted: G        W  O    4.4.238+ #9
 ...
 Call trace:
  [<ffffffc0000f079c>] __wake_up_common+0x7c/0xa8
  [<ffffffc0000f0818>] __wake_up+0x50/0x70
  [<ffffffc000be11b0>] sock_def_wakeup+0x58/0x60
  [<ffffffc000de5e10>] l2cap_sock_teardown_cb+0x200/0x224
  [<ffffffc000d3f2ac>] l2cap_chan_del+0xa4/0x298
  [<ffffffc000d45ea0>] l2cap_conn_del+0x118/0x198
  [<ffffffc000d45f8c>] l2cap_disconn_cfm+0x6c/0x78
  [<ffffffc000d29934>] hci_event_packet+0x564/0x2e30
  [<ffffffc000d19b0c>] hci_rx_work+0x10c/0x360
  [<ffffffc0000c2218>] process_one_work+0x268/0x460
  [<ffffffc0000c2678>] worker_thread+0x268/0x480
  [<ffffffc0000c94e0>] kthread+0x118/0x128
  [<ffffffc000085070>] ret_from_fork+0x10/0x20
  ---[ end trace 0adc2158f0646ead ]---

Signed-off-by: Ole Bjørn Midtbø <omidtbo@cisco.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/bluetooth/hidp/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 552e00b07196..9ec37c6c8c4a 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1282,7 +1282,7 @@ static int hidp_session_thread(void *arg)
 
 	/* cleanup runtime environment */
 	remove_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait);
-	remove_wait_queue(sk_sleep(session->intr_sock->sk), &ctrl_wait);
+	remove_wait_queue(sk_sleep(session->ctrl_sock->sk), &ctrl_wait);
 	wake_up_interruptible(&session->report_queue);
 	hidp_del_timer(session);
 
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 22/31] dccp: add do-while-0 stubs for dccp_pr_debug macros
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (20 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 21/31] Bluetooth: hidp: use correct wait queue when removing ctrl_wait Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 23/31] net: 6pack: fix slab-out-of-bounds in decode_data Sasha Levin
                   ` (12 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Randy Dunlap, dccp, David S. Miller, Jakub Kicinski,
	Gerrit Renker, Sasha Levin

From: Randy Dunlap <rdunlap@infradead.org>

[ Upstream commit 86aab09a4870bb8346c9579864588c3d7f555299 ]

GCC complains about empty macros in an 'if' statement, so convert
them to 'do {} while (0)' macros.

Fixes these build warnings:

net/dccp/output.c: In function 'dccp_xmit_packet':
../net/dccp/output.c:283:71: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
  283 |                 dccp_pr_debug("transmit_skb() returned err=%d\n", err);
net/dccp/ackvec.c: In function 'dccp_ackvec_update_old':
../net/dccp/ackvec.c:163:80: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
  163 |                                               (unsigned long long)seqno, state);

Fixes: dc841e30eaea ("dccp: Extend CCID packet dequeueing interface")
Fixes: 380240864451 ("dccp ccid-2: Update code for the Ack Vector input/registration routine")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: dccp@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/dccp/dccp.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/dccp/dccp.h b/net/dccp/dccp.h
index b0e28d24e1a7..e50fc19690c8 100644
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -44,9 +44,9 @@ extern bool dccp_debug;
 #define dccp_pr_debug_cat(format, a...)   DCCP_PRINTK(dccp_debug, format, ##a)
 #define dccp_debug(fmt, a...)		  dccp_pr_debug_cat(KERN_DEBUG fmt, ##a)
 #else
-#define dccp_pr_debug(format, a...)
-#define dccp_pr_debug_cat(format, a...)
-#define dccp_debug(format, a...)
+#define dccp_pr_debug(format, a...)	  do {} while (0)
+#define dccp_pr_debug_cat(format, a...)	  do {} while (0)
+#define dccp_debug(format, a...)	  do {} while (0)
 #endif
 
 extern struct inet_hashinfo dccp_hashinfo;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 23/31] net: 6pack: fix slab-out-of-bounds in decode_data
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (21 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 22/31] dccp: add do-while-0 stubs for dccp_pr_debug macros Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 24/31] net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32 Sasha Levin
                   ` (11 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Pavel Skripkin, syzbot+fc8cd9a673d4577fb2e4, Dan Carpenter,
	David S . Miller, Sasha Levin

From: Pavel Skripkin <paskripkin@gmail.com>

[ Upstream commit 19d1532a187669ce86d5a2696eb7275310070793 ]

Syzbot reported slab-out-of bounds write in decode_data().
The problem was in missing validation checks.

Syzbot's reproducer generated malicious input, which caused
decode_data() to be called a lot in sixpack_decode(). Since
rx_count_cooked is only 400 bytes and noone reported before,
that 400 bytes is not enough, let's just check if input is malicious
and complain about buffer overrun.

Fail log:
==================================================================
BUG: KASAN: slab-out-of-bounds in drivers/net/hamradio/6pack.c:843
Write of size 1 at addr ffff888087c5544e by task kworker/u4:0/7

CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.6.0-rc3-syzkaller #0
...
Workqueue: events_unbound flush_to_ldisc
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x197/0x210 lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
 __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506
 kasan_report+0x12/0x20 mm/kasan/common.c:641
 __asan_report_store1_noabort+0x17/0x20 mm/kasan/generic_report.c:137
 decode_data.part.0+0x23b/0x270 drivers/net/hamradio/6pack.c:843
 decode_data drivers/net/hamradio/6pack.c:965 [inline]
 sixpack_decode drivers/net/hamradio/6pack.c:968 [inline]

Reported-and-tested-by: syzbot+fc8cd9a673d4577fb2e4@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/hamradio/6pack.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 732c68ed166a..cce901add654 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -874,6 +874,12 @@ static void decode_data(struct sixpack *sp, unsigned char inbyte)
 		return;
 	}
 
+	if (sp->rx_count_cooked + 2 >= sizeof(sp->cooked_buf)) {
+		pr_err("6pack: cooked buffer overrun, data loss\n");
+		sp->rx_count = 0;
+		return;
+	}
+
 	buf = sp->raw_buf;
 	sp->cooked_buf[sp->rx_count_cooked++] =
 		buf[0] | ((buf[1] << 2) & 0xc0);
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 24/31] net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (22 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 23/31] net: 6pack: fix slab-out-of-bounds in decode_data Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors Sasha Levin
                   ` (10 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Dinghao Liu, Jakub Kicinski, Sasha Levin

From: Dinghao Liu <dinghao.liu@zju.edu.cn>

[ Upstream commit 0a298d133893c72c96e2156ed7cb0f0c4a306a3e ]

qlcnic_83xx_unlock_flash() is called on all paths after we call
qlcnic_83xx_lock_flash(), except for one error path on failure
of QLCRD32(), which may cause a deadlock. This bug is suggested
by a static analysis tool, please advise.

Fixes: 81d0aeb0a4fff ("qlcnic: flash template based firmware reset recovery")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Link: https://lore.kernel.org/r/20210816131405.24024-1-dinghao.liu@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
index 75ac5cc2fc23..fc9c1e6f0ff5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -3156,8 +3156,10 @@ int qlcnic_83xx_flash_read32(struct qlcnic_adapter *adapter, u32 flash_addr,
 
 		indirect_addr = QLC_83XX_FLASH_DIRECT_DATA(addr);
 		ret = QLCRD32(adapter, indirect_addr, &err);
-		if (err == -EIO)
+		if (err == -EIO) {
+			qlcnic_83xx_unlock_flash(adapter);
 			return err;
+		}
 
 		word = ret;
 		*(u32 *)p_data  = word;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors.
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (23 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 24/31] net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32 Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-26 11:59   ` Nobuhiro Iwamatsu
  2021-08-24 17:07 ` [PATCH 4.4 26/31] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default Sasha Levin
                   ` (9 subsequent siblings)
  34 siblings, 1 reply; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Doug Anderson, Enric Balletbo i Serra, Alim Akhtar,
	Jaehoon Chung, Ulf Hansson, Sasha Levin

From: Doug Anderson <dianders@chromium.org>

[ Upstream commit 46d179525a1f6d16957dcb4624517bc04142b3e7 ]

According to the DesignWare state machine description, after we get a
"response error" or "response CRC error" we move into data transfer
mode. That means that we don't necessarily need to special case
trying to deal with the failure right away. We can wait until we are
notified that the data transfer is complete (with or without errors)
and then we can deal with the failure.

It may sound strange to defer dealing with a command that we know will
fail anyway, but this appears to fix a bug. During tuning (CMD19) on
a specific card on an rk3288-based system, we found that we could get
a "response CRC error". Sending the stop command after the "response
CRC error" would then throw the system into a confused state causing
all future tuning phases to report failure.

When in the confused state, the controller would show these (hex codes
are interrupt status register):
 CMD ERR: 0x00000046 (cmd=19)
 CMD ERR: 0x0000004e (cmd=12)
 DATA ERR: 0x00000208
 DATA ERR: 0x0000020c
 CMD ERR: 0x00000104 (cmd=19)
 CMD ERR: 0x00000104 (cmd=12)
 DATA ERR: 0x00000208
 DATA ERR: 0x0000020c
 ...
 ...

It is inherently difficult to deal with the complexity of trying to
correctly send a stop command while a data transfer is taking place
since you need to deal with different corner cases caused by the fact
that the data transfer could complete (with errors or without errors)
during various places in sending the stop command (dw_mci_stop_dma,
send_stop_abort, etc)

Instead of adding a bunch of extra complexity to deal with this, it
seems much simpler to just use the more straightforward (and less
error-prone) path of letting the data transfer finish. There
shouldn't be any huge benefit to sending the stop command slightly
earlier, anyway.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Alim Akhtar <alim.akhtar@gmail.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/mmc/host/dw_mmc.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 581f5d0271f4..afdf539e06e9 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1744,6 +1744,33 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			}
 
 			if (cmd->data && err) {
+				/*
+				 * During UHS tuning sequence, sending the stop
+				 * command after the response CRC error would
+				 * throw the system into a confused state
+				 * causing all future tuning phases to report
+				 * failure.
+				 *
+				 * In such case controller will move into a data
+				 * transfer state after a response error or
+				 * response CRC error. Let's let that finish
+				 * before trying to send a stop, so we'll go to
+				 * STATE_SENDING_DATA.
+				 *
+				 * Although letting the data transfer take place
+				 * will waste a bit of time (we already know
+				 * the command was bad), it can't cause any
+				 * errors since it's possible it would have
+				 * taken place anyway if this tasklet got
+				 * delayed. Allowing the transfer to take place
+				 * avoids races and keeps things simple.
+				 */
+				if ((err != -ETIMEDOUT) &&
+				    (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
+					state = STATE_SENDING_DATA;
+					continue;
+				}
+
 				dw_mci_stop_dma(host);
 				send_stop_abort(host, data);
 				state = STATE_SENDING_STOP;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 26/31] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (24 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 27/31] mmc: dw_mmc: Fix hang on data CRC error Sasha Levin
                   ` (8 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Jaehoon Chung, Heiko Stuebner, Shawn Lin, Ulf Hansson, Sasha Levin

From: Jaehoon Chung <jh80.chung@samsung.com>

[ Upstream commit e13c3c081845b51e8ba71a90e91c52679cfdbf89 ]

stop_cmdr should be set to values relevant to stop command.
It migth be assigned to values whatever there is mrq->stop or not.
Then it doesn't need to use dw_mci_prepare_command().
It's enough to use the prep_stop_abort for preparing stop command.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/mmc/host/dw_mmc.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index afdf539e06e9..72ab0623293c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -380,7 +380,7 @@ static void dw_mci_start_command(struct dw_mci *host,
 
 static inline void send_stop_abort(struct dw_mci *host, struct mmc_data *data)
 {
-	struct mmc_command *stop = data->stop ? data->stop : &host->stop_abort;
+	struct mmc_command *stop = &host->stop_abort;
 
 	dw_mci_start_command(host, stop, host->stop_cmdr);
 }
@@ -1202,10 +1202,7 @@ static void __dw_mci_start_request(struct dw_mci *host,
 		spin_unlock_irqrestore(&host->irq_lock, irqflags);
 	}
 
-	if (mrq->stop)
-		host->stop_cmdr = dw_mci_prepare_command(slot->mmc, mrq->stop);
-	else
-		host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
+	host->stop_cmdr = dw_mci_prep_stop_abort(host, cmd);
 }
 
 static void dw_mci_start_request(struct dw_mci *host,
@@ -1797,8 +1794,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			if (test_and_clear_bit(EVENT_DATA_ERROR,
 					       &host->pending_events)) {
 				dw_mci_stop_dma(host);
-				if (data->stop ||
-				    !(host->data_status & (SDMMC_INT_DRTO |
+				if (!(host->data_status & (SDMMC_INT_DRTO |
 							   SDMMC_INT_EBE)))
 					send_stop_abort(host, data);
 				state = STATE_DATA_ERROR;
@@ -1835,8 +1831,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			if (test_and_clear_bit(EVENT_DATA_ERROR,
 					       &host->pending_events)) {
 				dw_mci_stop_dma(host);
-				if (data->stop ||
-				    !(host->data_status & (SDMMC_INT_DRTO |
+				if (!(host->data_status & (SDMMC_INT_DRTO |
 							   SDMMC_INT_EBE)))
 					send_stop_abort(host, data);
 				state = STATE_DATA_ERROR;
@@ -1913,7 +1908,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			host->cmd = NULL;
 			host->data = NULL;
 
-			if (mrq->stop)
+			if (!mrq->sbc && mrq->stop)
 				dw_mci_command_complete(host, mrq->stop);
 			else
 				host->cmd_status = 0;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 27/31] mmc: dw_mmc: Fix hang on data CRC error
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (25 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 26/31] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 28/31] ALSA: hda - fix the 'Capture Switch' value change notifications Sasha Levin
                   ` (7 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Vincent Whitchurch, Jaehoon Chung, Ulf Hansson, Sasha Levin

From: Vincent Whitchurch <vincent.whitchurch@axis.com>

[ Upstream commit 25f8203b4be1937c4939bb98623e67dcfd7da4d1 ]

When a Data CRC interrupt is received, the driver disables the DMA, then
sends the stop/abort command and then waits for Data Transfer Over.

However, sometimes, when a data CRC error is received in the middle of a
multi-block write transfer, the Data Transfer Over interrupt is never
received, and the driver hangs and never completes the request.

The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the
DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed
"before assertion of SWR".  Do these operations in the recommended
order.  With this change the Data Transfer Over is always received
correctly in my tests.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/mmc/host/dw_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 72ab0623293c..7bfe9ce03944 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1768,8 +1768,8 @@ static void dw_mci_tasklet_func(unsigned long priv)
 					continue;
 				}
 
-				dw_mci_stop_dma(host);
 				send_stop_abort(host, data);
+				dw_mci_stop_dma(host);
 				state = STATE_SENDING_STOP;
 				break;
 			}
@@ -1793,10 +1793,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			 */
 			if (test_and_clear_bit(EVENT_DATA_ERROR,
 					       &host->pending_events)) {
-				dw_mci_stop_dma(host);
 				if (!(host->data_status & (SDMMC_INT_DRTO |
 							   SDMMC_INT_EBE)))
 					send_stop_abort(host, data);
+				dw_mci_stop_dma(host);
 				state = STATE_DATA_ERROR;
 				break;
 			}
@@ -1830,10 +1830,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
 			 */
 			if (test_and_clear_bit(EVENT_DATA_ERROR,
 					       &host->pending_events)) {
-				dw_mci_stop_dma(host);
 				if (!(host->data_status & (SDMMC_INT_DRTO |
 							   SDMMC_INT_EBE)))
 					send_stop_abort(host, data);
+				dw_mci_stop_dma(host);
 				state = STATE_DATA_ERROR;
 				break;
 			}
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 28/31] ALSA: hda - fix the 'Capture Switch' value change notifications
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (26 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 27/31] mmc: dw_mmc: Fix hang on data CRC error Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 29/31] ipack: tpci200: fix many double free issues in tpci200_pci_probe Sasha Levin
                   ` (6 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Jaroslav Kysela, stable, Takashi Iwai, Sasha Levin

From: Jaroslav Kysela <perex@perex.cz>

[ Upstream commit a2befe9380dd04ee76c871568deca00eedf89134 ]

The original code in the cap_put_caller() function does not
handle correctly the positive values returned from the passed
function for multiple iterations. It means that the change
notifications may be lost.

Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851
Cc: <stable@kernel.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/pci/hda/hda_generic.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c
index 7fed8d1bb79c..5c708d9851b8 100644
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -3442,7 +3442,7 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol,
 	struct hda_gen_spec *spec = codec->spec;
 	const struct hda_input_mux *imux;
 	struct nid_path *path;
-	int i, adc_idx, err = 0;
+	int i, adc_idx, ret, err = 0;
 
 	imux = &spec->input_mux;
 	adc_idx = kcontrol->id.index;
@@ -3452,9 +3452,13 @@ static int cap_put_caller(struct snd_kcontrol *kcontrol,
 		if (!path || !path->ctls[type])
 			continue;
 		kcontrol->private_value = path->ctls[type];
-		err = func(kcontrol, ucontrol);
-		if (err < 0)
+		ret = func(kcontrol, ucontrol);
+		if (ret < 0) {
+			err = ret;
 			break;
+		}
+		if (ret > 0)
+			err = 1;
 	}
 	mutex_unlock(&codec->control_mutex);
 	if (err >= 0 && spec->cap_sync_hook)
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 29/31] ipack: tpci200: fix many double free issues in tpci200_pci_probe
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (27 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 28/31] ALSA: hda - fix the 'Capture Switch' value change notifications Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 30/31] ASoC: intel: atom: Fix breakage for PCM buffer address setup Sasha Levin
                   ` (5 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Dongliang Mu, Greg Kroah-Hartman, Sasha Levin

From: Dongliang Mu <mudongliangabcd@gmail.com>

[ Upstream commit 57a1681095f912239c7fb4d66683ab0425973838 ]

The function tpci200_register called by tpci200_install and
tpci200_unregister called by tpci200_uninstall are in pair. However,
tpci200_unregister has some cleanup operations not in the
tpci200_register. So the error handling code of tpci200_pci_probe has
many different double free issues.

Fix this problem by moving those cleanup operations out of
tpci200_unregister, into tpci200_pci_remove and reverting
the previous commit 9272e5d0028d ("ipack/carriers/tpci200:
Fix a double free in tpci200_pci_probe").

Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe")
Cc: stable@vger.kernel.org
Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/ipack/carriers/tpci200.c | 36 ++++++++++++++++----------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c
index 7ba1a94497f5..4294523bede5 100644
--- a/drivers/ipack/carriers/tpci200.c
+++ b/drivers/ipack/carriers/tpci200.c
@@ -94,16 +94,13 @@ static void tpci200_unregister(struct tpci200_board *tpci200)
 	free_irq(tpci200->info->pdev->irq, (void *) tpci200);
 
 	pci_iounmap(tpci200->info->pdev, tpci200->info->interface_regs);
-	pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
 
 	pci_release_region(tpci200->info->pdev, TPCI200_IP_INTERFACE_BAR);
 	pci_release_region(tpci200->info->pdev, TPCI200_IO_ID_INT_SPACES_BAR);
 	pci_release_region(tpci200->info->pdev, TPCI200_MEM16_SPACE_BAR);
 	pci_release_region(tpci200->info->pdev, TPCI200_MEM8_SPACE_BAR);
-	pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR);
 
 	pci_disable_device(tpci200->info->pdev);
-	pci_dev_put(tpci200->info->pdev);
 }
 
 static void tpci200_enable_irq(struct tpci200_board *tpci200,
@@ -524,7 +521,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 	tpci200->info = kzalloc(sizeof(struct tpci200_infos), GFP_KERNEL);
 	if (!tpci200->info) {
 		ret = -ENOMEM;
-		goto out_err_info;
+		goto err_tpci200;
 	}
 
 	pci_dev_get(pdev);
@@ -535,7 +532,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to allocate PCI Configuration Memory");
 		ret = -EBUSY;
-		goto out_err_pci_request;
+		goto err_tpci200_info;
 	}
 	tpci200->info->cfg_regs = ioremap_nocache(
 			pci_resource_start(pdev, TPCI200_CFG_MEM_BAR),
@@ -543,7 +540,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 	if (!tpci200->info->cfg_regs) {
 		dev_err(&pdev->dev, "Failed to map PCI Configuration Memory");
 		ret = -EFAULT;
-		goto out_err_ioremap;
+		goto err_request_region;
 	}
 
 	/* Disable byte swapping for 16 bit IP module access. This will ensure
@@ -566,7 +563,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 	if (ret) {
 		dev_err(&pdev->dev, "error during tpci200 install\n");
 		ret = -ENODEV;
-		goto out_err_install;
+		goto err_cfg_regs;
 	}
 
 	/* Register the carrier in the industry pack bus driver */
@@ -578,7 +575,7 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 		dev_err(&pdev->dev,
 			"error registering the carrier on ipack driver\n");
 		ret = -EFAULT;
-		goto out_err_bus_register;
+		goto err_tpci200_install;
 	}
 
 	/* save the bus number given by ipack to logging purpose */
@@ -589,19 +586,16 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
 		tpci200_create_device(tpci200, i);
 	return 0;
 
-out_err_bus_register:
+err_tpci200_install:
 	tpci200_uninstall(tpci200);
-	/* tpci200->info->cfg_regs is unmapped in tpci200_uninstall */
-	tpci200->info->cfg_regs = NULL;
-out_err_install:
-	if (tpci200->info->cfg_regs)
-		iounmap(tpci200->info->cfg_regs);
-out_err_ioremap:
+err_cfg_regs:
+	pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
+err_request_region:
 	pci_release_region(pdev, TPCI200_CFG_MEM_BAR);
-out_err_pci_request:
-	pci_dev_put(pdev);
+err_tpci200_info:
 	kfree(tpci200->info);
-out_err_info:
+	pci_dev_put(pdev);
+err_tpci200:
 	kfree(tpci200);
 	return ret;
 }
@@ -611,6 +605,12 @@ static void __tpci200_pci_remove(struct tpci200_board *tpci200)
 	ipack_bus_unregister(tpci200->info->ipack_bus);
 	tpci200_uninstall(tpci200);
 
+	pci_iounmap(tpci200->info->pdev, tpci200->info->cfg_regs);
+
+	pci_release_region(tpci200->info->pdev, TPCI200_CFG_MEM_BAR);
+
+	pci_dev_put(tpci200->info->pdev);
+
 	kfree(tpci200->info);
 	kfree(tpci200);
 }
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 30/31] ASoC: intel: atom: Fix breakage for PCM buffer address setup
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (28 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 29/31] ipack: tpci200: fix many double free issues in tpci200_pci_probe Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-24 17:07 ` [PATCH 4.4 31/31] Linux 4.4.282-rc1 Sasha Levin
                   ` (4 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Takashi Iwai, Hans de Goede, Mark Brown, Sasha Levin

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 65ca89c2b12cca0d473f3dd54267568ad3af55cc ]

The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM
buffer address") changed the reference of PCM buffer address to
substream->runtime->dma_addr as the buffer address may change
dynamically.  However, I forgot that the dma_addr field is still not
set up for the CONTINUOUS buffer type (that this driver uses) yet in
5.14 and earlier kernels, and it resulted in garbage I/O.  The problem
will be fixed in 5.15, but we need to address it quickly for now.

The fix is to deduce the address again from the DMA pointer with
virt_to_phys(), but from the right one, substream->runtime->dma_area.

Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address")
Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: <stable@vger.kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com
Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/intel/atom/sst-mfld-platform-pcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index 64079423b298..d0d338533eb6 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -134,7 +134,7 @@ static void sst_fill_alloc_params(struct snd_pcm_substream *substream,
 	snd_pcm_uframes_t period_size;
 	ssize_t periodbytes;
 	ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
-	u32 buffer_addr = substream->runtime->dma_addr;
+	u32 buffer_addr = virt_to_phys(substream->runtime->dma_area);
 
 	channels = substream->runtime->channels;
 	period_size = substream->runtime->period_size;
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 4.4 31/31] Linux 4.4.282-rc1
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (29 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 30/31] ASoC: intel: atom: Fix breakage for PCM buffer address setup Sasha Levin
@ 2021-08-24 17:07 ` Sasha Levin
  2021-08-25  7:33 ` [PATCH 4.4 00/31] 4.4.282-rc1 review Pavel Machek
                   ` (3 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-24 17:07 UTC (permalink / raw)
  To: linux-kernel, stable; +Cc: Sasha Levin

Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index abc388047b47..6de2701bdca0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 281
-EXTRAVERSION =
+SUBLEVEL = 282
+EXTRAVERSION = -rc1
 NAME = Blurry Fish Butt
 
 # *DOCUMENTATION*
-- 
2.30.2


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 00/31] 4.4.282-rc1 review
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (30 preceding siblings ...)
  2021-08-24 17:07 ` [PATCH 4.4 31/31] Linux 4.4.282-rc1 Sasha Levin
@ 2021-08-25  7:33 ` Pavel Machek
  2021-08-25 20:27 ` Guenter Roeck
                   ` (2 subsequent siblings)
  34 siblings, 0 replies; 38+ messages in thread
From: Pavel Machek @ 2021-08-25  7:33 UTC (permalink / raw)
  To: Sasha Levin
  Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
	lkft-triage, pavel

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Hi!

> This is the start of the stable review cycle for the 4.4.282 release.
> There are 31 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y

Tested-by: Pavel Machek (CIP) <pavel@denx.de>

Best regards,
                                                                Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 00/31] 4.4.282-rc1 review
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (31 preceding siblings ...)
  2021-08-25  7:33 ` [PATCH 4.4 00/31] 4.4.282-rc1 review Pavel Machek
@ 2021-08-25 20:27 ` Guenter Roeck
  2021-08-25 21:18 ` Daniel Díaz
  2021-08-25 22:38 ` Shuah Khan
  34 siblings, 0 replies; 38+ messages in thread
From: Guenter Roeck @ 2021-08-25 20:27 UTC (permalink / raw)
  To: Sasha Levin
  Cc: linux-kernel, stable, torvalds, akpm, shuah, patches, lkft-triage, pavel

On Tue, Aug 24, 2021 at 01:07:12PM -0400, Sasha Levin wrote:
> 
> This is the start of the stable review cycle for the 4.4.282 release.
> There are 31 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu 26 Aug 2021 05:07:41 PM UTC.
> Anything received after that time might be too late.
> 

Build results:
	total: 160 pass: 160 fail: 0
Qemu test results:
	total: 338 pass: 338 fail: 0

Tested-by: Guenter Roeck <linux@roeck-us.net>

Guenter

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 00/31] 4.4.282-rc1 review
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (32 preceding siblings ...)
  2021-08-25 20:27 ` Guenter Roeck
@ 2021-08-25 21:18 ` Daniel Díaz
  2021-08-25 22:38 ` Shuah Khan
  34 siblings, 0 replies; 38+ messages in thread
From: Daniel Díaz @ 2021-08-25 21:18 UTC (permalink / raw)
  To: Sasha Levin, linux-kernel, stable
  Cc: torvalds, patches, lkft-triage, pavel, akpm, shuah, linux

Hello!

On 8/24/21 12:07 PM, Sasha Levin wrote:
> This is the start of the stable review cycle for the 4.4.282 release.
> There are 31 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu 26 Aug 2021 05:07:41 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>          https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-4.4.y&id2=v4.4.281
> or in the git tree and branch at:
>          git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
> 
> Thanks,
> Sasha

Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Build
* kernel: 4.4.282-rc1
* git: ['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
* git branch: linux-4.4.y
* git commit: a11850845e9394a250678b2ec8b714825343f776
* git describe: v4.4.281-31-ga11850845e93
* test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.281-31-ga11850845e93

## No regressions (compared to v4.4.281)

## No fixes (compared to v4.4.281)

## Test result summary
total: 41546, pass: 33742, fail: 202, skip: 6656, xfail: 946

## Build Summary
* arm: 97 total, 97 passed, 0 failed
* arm64: 27 total, 27 passed, 0 failed
* i386: 14 total, 14 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 14 total, 14 passed, 0 failed

## Test suites summary
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* ssuite
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.diaz@linaro.org

-- 
Linaro LKFT
https://lkft.linaro.org

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 00/31] 4.4.282-rc1 review
  2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
                   ` (33 preceding siblings ...)
  2021-08-25 21:18 ` Daniel Díaz
@ 2021-08-25 22:38 ` Shuah Khan
  34 siblings, 0 replies; 38+ messages in thread
From: Shuah Khan @ 2021-08-25 22:38 UTC (permalink / raw)
  To: Sasha Levin, linux-kernel, stable
  Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel, Shuah Khan

On 8/24/21 11:07 AM, Sasha Levin wrote:
> 
> This is the start of the stable review cycle for the 4.4.282 release.
> There are 31 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu 26 Aug 2021 05:07:41 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>          https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-4.4.y&id2=v4.4.281
> or in the git tree and branch at:
>          git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
> 
> Thanks,
> Sasha
> 


Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors.
  2021-08-24 17:07 ` [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors Sasha Levin
@ 2021-08-26 11:59   ` Nobuhiro Iwamatsu
  2021-08-26 12:31     ` Sasha Levin
  0 siblings, 1 reply; 38+ messages in thread
From: Nobuhiro Iwamatsu @ 2021-08-26 11:59 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Linux Kernel Mailing List, stable, Doug Anderson,
	Enric Balletbo i Serra, Alim Akhtar, Jaehoon Chung, Ulf Hansson

Hi,


2021年8月25日(水) 2:39 Sasha Levin <sashal@kernel.org>:
>
> From: Doug Anderson <dianders@chromium.org>
>
> [ Upstream commit 46d179525a1f6d16957dcb4624517bc04142b3e7 ]
>
> According to the DesignWare state machine description, after we get a
> "response error" or "response CRC error" we move into data transfer
> mode. That means that we don't necessarily need to special case
> trying to deal with the failure right away. We can wait until we are
> notified that the data transfer is complete (with or without errors)
> and then we can deal with the failure.
>
> It may sound strange to defer dealing with a command that we know will
> fail anyway, but this appears to fix a bug. During tuning (CMD19) on
> a specific card on an rk3288-based system, we found that we could get
> a "response CRC error". Sending the stop command after the "response
> CRC error" would then throw the system into a confused state causing
> all future tuning phases to report failure.
>
> When in the confused state, the controller would show these (hex codes
> are interrupt status register):
>  CMD ERR: 0x00000046 (cmd=19)
>  CMD ERR: 0x0000004e (cmd=12)
>  DATA ERR: 0x00000208
>  DATA ERR: 0x0000020c
>  CMD ERR: 0x00000104 (cmd=19)
>  CMD ERR: 0x00000104 (cmd=12)
>  DATA ERR: 0x00000208
>  DATA ERR: 0x0000020c
>  ...
>  ...
>
> It is inherently difficult to deal with the complexity of trying to
> correctly send a stop command while a data transfer is taking place
> since you need to deal with different corner cases caused by the fact
> that the data transfer could complete (with errors or without errors)
> during various places in sending the stop command (dw_mci_stop_dma,
> send_stop_abort, etc)
>
> Instead of adding a bunch of extra complexity to deal with this, it
> seems much simpler to just use the more straightforward (and less
> error-prone) path of letting the data transfer finish. There
> shouldn't be any huge benefit to sending the stop command slightly
> earlier, anyway.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Cc: Alim Akhtar <alim.akhtar@gmail.com>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

This commit also requires the following modifications:
  ba2d139b02ba68: mmc: dw_mmc: Fix occasional hang after tuning on eMMC

Please apply this commit too.

Best regards,
  Nobuhiro


> ---
>  drivers/mmc/host/dw_mmc.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 581f5d0271f4..afdf539e06e9 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1744,6 +1744,33 @@ static void dw_mci_tasklet_func(unsigned long priv)
>                         }
>
>                         if (cmd->data && err) {
> +                               /*
> +                                * During UHS tuning sequence, sending the stop
> +                                * command after the response CRC error would
> +                                * throw the system into a confused state
> +                                * causing all future tuning phases to report
> +                                * failure.
> +                                *
> +                                * In such case controller will move into a data
> +                                * transfer state after a response error or
> +                                * response CRC error. Let's let that finish
> +                                * before trying to send a stop, so we'll go to
> +                                * STATE_SENDING_DATA.
> +                                *
> +                                * Although letting the data transfer take place
> +                                * will waste a bit of time (we already know
> +                                * the command was bad), it can't cause any
> +                                * errors since it's possible it would have
> +                                * taken place anyway if this tasklet got
> +                                * delayed. Allowing the transfer to take place
> +                                * avoids races and keeps things simple.
> +                                */
> +                               if ((err != -ETIMEDOUT) &&
> +                                   (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
> +                                       state = STATE_SENDING_DATA;
> +                                       continue;
> +                               }
> +
>                                 dw_mci_stop_dma(host);
>                                 send_stop_abort(host, data);
>                                 state = STATE_SENDING_STOP;
> --
> 2.30.2
>


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors.
  2021-08-26 11:59   ` Nobuhiro Iwamatsu
@ 2021-08-26 12:31     ` Sasha Levin
  0 siblings, 0 replies; 38+ messages in thread
From: Sasha Levin @ 2021-08-26 12:31 UTC (permalink / raw)
  To: Nobuhiro Iwamatsu
  Cc: Linux Kernel Mailing List, stable, Doug Anderson,
	Enric Balletbo i Serra, Alim Akhtar, Jaehoon Chung, Ulf Hansson

On Thu, Aug 26, 2021 at 08:59:53PM +0900, Nobuhiro Iwamatsu wrote:
>Hi,
>
>
>2021年8月25日(水) 2:39 Sasha Levin <sashal@kernel.org>:
>>
>> From: Doug Anderson <dianders@chromium.org>
>>
>> [ Upstream commit 46d179525a1f6d16957dcb4624517bc04142b3e7 ]
>>
>> According to the DesignWare state machine description, after we get a
>> "response error" or "response CRC error" we move into data transfer
>> mode. That means that we don't necessarily need to special case
>> trying to deal with the failure right away. We can wait until we are
>> notified that the data transfer is complete (with or without errors)
>> and then we can deal with the failure.
>>
>> It may sound strange to defer dealing with a command that we know will
>> fail anyway, but this appears to fix a bug. During tuning (CMD19) on
>> a specific card on an rk3288-based system, we found that we could get
>> a "response CRC error". Sending the stop command after the "response
>> CRC error" would then throw the system into a confused state causing
>> all future tuning phases to report failure.
>>
>> When in the confused state, the controller would show these (hex codes
>> are interrupt status register):
>>  CMD ERR: 0x00000046 (cmd=19)
>>  CMD ERR: 0x0000004e (cmd=12)
>>  DATA ERR: 0x00000208
>>  DATA ERR: 0x0000020c
>>  CMD ERR: 0x00000104 (cmd=19)
>>  CMD ERR: 0x00000104 (cmd=12)
>>  DATA ERR: 0x00000208
>>  DATA ERR: 0x0000020c
>>  ...
>>  ...
>>
>> It is inherently difficult to deal with the complexity of trying to
>> correctly send a stop command while a data transfer is taking place
>> since you need to deal with different corner cases caused by the fact
>> that the data transfer could complete (with errors or without errors)
>> during various places in sending the stop command (dw_mci_stop_dma,
>> send_stop_abort, etc)
>>
>> Instead of adding a bunch of extra complexity to deal with this, it
>> seems much simpler to just use the more straightforward (and less
>> error-prone) path of letting the data transfer finish. There
>> shouldn't be any huge benefit to sending the stop command slightly
>> earlier, anyway.
>>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> Cc: Alim Akhtar <alim.akhtar@gmail.com>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>This commit also requires the following modifications:
>  ba2d139b02ba68: mmc: dw_mmc: Fix occasional hang after tuning on eMMC
>
>Please apply this commit too.

Will do, thanks!

-- 
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2021-08-26 12:31 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-24 17:07 [PATCH 4.4 00/31] 4.4.282-rc1 review Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 01/31] ASoC: intel: atom: Fix reference to PCM buffer address Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 02/31] i2c: dev: zero out array used for i2c reads from userspace Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 03/31] net: Fix memory leak in ieee802154_raw_deliver Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 04/31] xen/events: Fix race in set_evtchn_to_irq Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 05/31] x86/tools: Fix objdump version check again Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 06/31] PCI/MSI: Enable and mask MSI-X early Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 07/31] PCI/MSI: Do not set invalid bits in MSI mask Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 08/31] PCI/MSI: Correct misleading comments Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 09/31] PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown() Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 10/31] PCI/MSI: Protect msi_desc::masked for multi-MSI Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 11/31] PCI/MSI: Mask all unused MSI-X entries Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 12/31] PCI/MSI: Enforce that MSI-X table entry is masked for update Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 13/31] PCI/MSI: Enforce MSI[X] entry updates to be visible Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 14/31] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 15/31] KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653) Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 16/31] dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 17/31] ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218 Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 18/31] dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 19/31] scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry() Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 20/31] scsi: core: Avoid printing an error if target_alloc() returns -ENXIO Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 21/31] Bluetooth: hidp: use correct wait queue when removing ctrl_wait Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 22/31] dccp: add do-while-0 stubs for dccp_pr_debug macros Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 23/31] net: 6pack: fix slab-out-of-bounds in decode_data Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 24/31] net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32 Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 25/31] mmc: dw_mmc: Wait for data transfer after response errors Sasha Levin
2021-08-26 11:59   ` Nobuhiro Iwamatsu
2021-08-26 12:31     ` Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 26/31] mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 27/31] mmc: dw_mmc: Fix hang on data CRC error Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 28/31] ALSA: hda - fix the 'Capture Switch' value change notifications Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 29/31] ipack: tpci200: fix many double free issues in tpci200_pci_probe Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 30/31] ASoC: intel: atom: Fix breakage for PCM buffer address setup Sasha Levin
2021-08-24 17:07 ` [PATCH 4.4 31/31] Linux 4.4.282-rc1 Sasha Levin
2021-08-25  7:33 ` [PATCH 4.4 00/31] 4.4.282-rc1 review Pavel Machek
2021-08-25 20:27 ` Guenter Roeck
2021-08-25 21:18 ` Daniel Díaz
2021-08-25 22:38 ` Shuah Khan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).