--- /dev/null
+From 1b6604896e78969baffc1b6cc6bc175f95929ac4 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Thu, 13 May 2021 21:56:48 +0900
+Subject: ALSA: dice: fix stream format at middle sampling rate for Alesis iO 26
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 1b6604896e78969baffc1b6cc6bc175f95929ac4 upstream.
+
+Alesis iO 26 FireWire has two pairs of digital optical interface. It
+delivers PCM frames from the interfaces by second isochronous packet
+streaming. Although both of the interfaces are available at 44.1/48.0
+kHz, first one of them is only available at 88.2/96.0 kHz. It reduces
+the number of PCM samples to 4 in Multi Bit Linear Audio data channel
+of data blocks on the second isochronous packet streaming.
+
+This commit fixes hardcoded stream formats.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 28b208f600a3 ("ALSA: dice: add parameters of stream formats for models produced by Alesis")
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Link: https://lore.kernel.org/r/20210513125652.110249-2-o-takashi@sakamocchi.jp
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/firewire/dice/dice-alesis.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/firewire/dice/dice-alesis.c
++++ b/sound/firewire/dice/dice-alesis.c
+@@ -16,7 +16,7 @@ alesis_io14_tx_pcm_chs[MAX_STREAMS][SND_
+ static const unsigned int
+ alesis_io26_tx_pcm_chs[MAX_STREAMS][SND_DICE_RATE_MODE_COUNT] = {
+ {10, 10, 4}, /* Tx0 = Analog + S/PDIF. */
+- {16, 8, 0}, /* Tx1 = ADAT1 + ADAT2. */
++ {16, 4, 0}, /* Tx1 = ADAT1 + ADAT2 (available at low rate). */
+ };
+
+ int snd_dice_detect_alesis_formats(struct snd_dice *dice)
--- /dev/null
+From 4c6fe8c547e3c9e8c15dabdd23c569ee0df3adb1 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Tue, 18 May 2021 10:26:12 +0900
+Subject: ALSA: dice: fix stream format for TC Electronic Konnekt Live at high sampling transfer frequency
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 4c6fe8c547e3c9e8c15dabdd23c569ee0df3adb1 upstream.
+
+At high sampling transfer frequency, TC Electronic Konnekt Live
+transfers/receives 6 audio data frames in multi bit linear audio data
+channel of data block in CIP payload. Current hard-coded stream format
+is wrong.
+
+Cc: <stable@vger.kernel.org>
+Fixes: f1f0f330b1d0 ("ALSA: dice: add parameters of stream formats for models produced by TC Electronic")
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Link: https://lore.kernel.org/r/20210518012612.37268-1-o-takashi@sakamocchi.jp
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/firewire/dice/dice-tcelectronic.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/firewire/dice/dice-tcelectronic.c
++++ b/sound/firewire/dice/dice-tcelectronic.c
+@@ -38,8 +38,8 @@ static const struct dice_tc_spec konnekt
+ };
+
+ static const struct dice_tc_spec konnekt_live = {
+- .tx_pcm_chs = {{16, 16, 16}, {0, 0, 0} },
+- .rx_pcm_chs = {{16, 16, 16}, {0, 0, 0} },
++ .tx_pcm_chs = {{16, 16, 6}, {0, 0, 0} },
++ .rx_pcm_chs = {{16, 16, 6}, {0, 0, 0} },
+ .has_midi = true,
+ };
+
--- /dev/null
+From c1f0616124c455c5c762b6f123e40bba5df759e6 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sun, 16 May 2021 18:17:55 +0200
+Subject: ALSA: intel8x0: Don't update period unless prepared
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit c1f0616124c455c5c762b6f123e40bba5df759e6 upstream.
+
+The interrupt handler of intel8x0 calls snd_intel8x0_update() whenever
+the hardware sets the corresponding status bit for each stream. This
+works fine for most cases as long as the hardware behaves properly.
+But when the hardware gives a wrong bit set, this leads to a zero-
+division Oops, and reportedly, this seems what happened on a VM.
+
+For fixing the crash, this patch adds a internal flag indicating that
+the stream is ready to be updated, and check it (as well as the flag
+being in suspended) to ignore such spurious update.
+
+Cc: <stable@vger.kernel.org>
+Reported-and-tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Link: https://lore.kernel.org/r/s5h5yzi7uh0.wl-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/intel8x0.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/sound/pci/intel8x0.c
++++ b/sound/pci/intel8x0.c
+@@ -354,6 +354,7 @@ struct ichdev {
+ unsigned int ali_slot; /* ALI DMA slot */
+ struct ac97_pcm *pcm;
+ int pcm_open_flag;
++ unsigned int prepared:1;
+ unsigned int suspended: 1;
+ };
+
+@@ -714,6 +715,9 @@ static inline void snd_intel8x0_update(s
+ int status, civ, i, step;
+ int ack = 0;
+
++ if (!ichdev->prepared || ichdev->suspended)
++ return;
++
+ spin_lock_irqsave(&chip->reg_lock, flags);
+ status = igetbyte(chip, port + ichdev->roff_sr);
+ civ = igetbyte(chip, port + ICH_REG_OFF_CIV);
+@@ -907,6 +911,7 @@ static int snd_intel8x0_hw_params(struct
+ if (ichdev->pcm_open_flag) {
+ snd_ac97_pcm_close(ichdev->pcm);
+ ichdev->pcm_open_flag = 0;
++ ichdev->prepared = 0;
+ }
+ err = snd_ac97_pcm_open(ichdev->pcm, params_rate(hw_params),
+ params_channels(hw_params),
+@@ -928,6 +933,7 @@ static int snd_intel8x0_hw_free(struct s
+ if (ichdev->pcm_open_flag) {
+ snd_ac97_pcm_close(ichdev->pcm);
+ ichdev->pcm_open_flag = 0;
++ ichdev->prepared = 0;
+ }
+ return snd_pcm_lib_free_pages(substream);
+ }
+@@ -1002,6 +1008,7 @@ static int snd_intel8x0_pcm_prepare(stru
+ ichdev->pos_shift = (runtime->sample_bits > 16) ? 2 : 1;
+ }
+ snd_intel8x0_setup_periods(chip, ichdev);
++ ichdev->prepared = 1;
+ return 0;
+ }
+
--- /dev/null
+From 05ca447630334c323c9e2b788b61133ab75d60d3 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 18 May 2021 10:39:39 +0200
+Subject: ALSA: line6: Fix racy initialization of LINE6 MIDI
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 05ca447630334c323c9e2b788b61133ab75d60d3 upstream.
+
+The initialization of MIDI devices that are found on some LINE6
+drivers are currently done in a racy way; namely, the MIDI buffer
+instance is allocated and initialized in each private_init callback
+while the communication with the interface is already started via
+line6_init_cap_control() call before that point. This may lead to
+Oops in line6_data_received() when a spurious event is received, as
+reported by syzkaller.
+
+This patch moves the MIDI initialization to line6_init_cap_control()
+as well instead of the too-lately-called private_init for avoiding the
+race. Also this reduces slightly more lines, so it's a win-win
+change.
+
+Reported-by: syzbot+0d2b3feb0a2887862e06@syzkallerlkml..appspotmail.com
+Link: https://lore.kernel.org/r/000000000000a4be9405c28520de@google.com
+Link: https://lore.kernel.org/r/20210517132725.GA50495@hyeyoo
+Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210518083939.1927-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/line6/driver.c | 4 ++++
+ sound/usb/line6/pod.c | 5 -----
+ sound/usb/line6/variax.c | 6 ------
+ 3 files changed, 4 insertions(+), 11 deletions(-)
+
+--- a/sound/usb/line6/driver.c
++++ b/sound/usb/line6/driver.c
+@@ -690,6 +690,10 @@ static int line6_init_cap_control(struct
+ line6->buffer_message = kmalloc(LINE6_MIDI_MESSAGE_MAXLEN, GFP_KERNEL);
+ if (!line6->buffer_message)
+ return -ENOMEM;
++
++ ret = line6_init_midi(line6);
++ if (ret < 0)
++ return ret;
+ } else {
+ ret = line6_hwdep_init(line6);
+ if (ret < 0)
+--- a/sound/usb/line6/pod.c
++++ b/sound/usb/line6/pod.c
+@@ -376,11 +376,6 @@ static int pod_init(struct usb_line6 *li
+ if (err < 0)
+ return err;
+
+- /* initialize MIDI subsystem: */
+- err = line6_init_midi(line6);
+- if (err < 0)
+- return err;
+-
+ /* initialize PCM subsystem: */
+ err = line6_init_pcm(line6, &pod_pcm_properties);
+ if (err < 0)
+--- a/sound/usb/line6/variax.c
++++ b/sound/usb/line6/variax.c
+@@ -159,7 +159,6 @@ static int variax_init(struct usb_line6
+ const struct usb_device_id *id)
+ {
+ struct usb_line6_variax *variax = line6_to_variax(line6);
+- int err;
+
+ line6->process_message = line6_variax_process_message;
+ line6->disconnect = line6_variax_disconnect;
+@@ -172,11 +171,6 @@ static int variax_init(struct usb_line6
+ if (variax->buffer_activate == NULL)
+ return -ENOMEM;
+
+- /* initialize MIDI subsystem: */
+- err = line6_init_midi(&variax->line6);
+- if (err < 0)
+- return err;
+-
+ /* initiate startup procedure: */
+ schedule_delayed_work(&line6->startup_work,
+ msecs_to_jiffies(VARIAX_STARTUP_DELAY1));
--- /dev/null
+From 71795ee590111e3636cc3c148289dfa9fa0a5fc3 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Thu, 29 Apr 2021 10:51:34 -0400
+Subject: btrfs: avoid RCU stalls while running delayed iputs
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 71795ee590111e3636cc3c148289dfa9fa0a5fc3 upstream.
+
+Generally a delayed iput is added when we might do the final iput, so
+usually we'll end up sleeping while processing the delayed iputs
+naturally. However there's no guarantee of this, especially for small
+files. In production we noticed 5 instances of RCU stalls while testing
+a kernel release overnight across 1000 machines, so this is relatively
+common:
+
+ host count: 5
+ rcu: INFO: rcu_sched self-detected stall on CPU
+ rcu: ....: (20998 ticks this GP) idle=59e/1/0x4000000000000002 softirq=12333372/12333372 fqs=3208
+ (t=21031 jiffies g=27810193 q=41075) NMI backtrace for cpu 1
+ CPU: 1 PID: 1713 Comm: btrfs-cleaner Kdump: loaded Not tainted 5.6.13-0_fbk12_rc1_5520_gec92bffc1ec9 #1
+ Call Trace:
+ <IRQ> dump_stack+0x50/0x70
+ nmi_cpu_backtrace.cold.6+0x30/0x65
+ ? lapic_can_unplug_cpu.cold.30+0x40/0x40
+ nmi_trigger_cpumask_backtrace+0xba/0xca
+ rcu_dump_cpu_stacks+0x99/0xc7
+ rcu_sched_clock_irq.cold.90+0x1b2/0x3a3
+ ? trigger_load_balance+0x5c/0x200
+ ? tick_sched_do_timer+0x60/0x60
+ ? tick_sched_do_timer+0x60/0x60
+ update_process_times+0x24/0x50
+ tick_sched_timer+0x37/0x70
+ __hrtimer_run_queues+0xfe/0x270
+ hrtimer_interrupt+0xf4/0x210
+ smp_apic_timer_interrupt+0x5e/0x120
+ apic_timer_interrupt+0xf/0x20 </IRQ>
+ RIP: 0010:queued_spin_lock_slowpath+0x17d/0x1b0
+ RSP: 0018:ffffc9000da5fe48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
+ RAX: 0000000000000000 RBX: ffff889fa81d0cd8 RCX: 0000000000000029
+ RDX: ffff889fff86c0c0 RSI: 0000000000080000 RDI: ffff88bfc2da7200
+ RBP: ffff888f2dcdd768 R08: 0000000001040000 R09: 0000000000000000
+ R10: 0000000000000001 R11: ffffffff82a55560 R12: ffff88bfc2da7200
+ R13: 0000000000000000 R14: ffff88bff6c2a360 R15: ffffffff814bd870
+ ? kzalloc.constprop.57+0x30/0x30
+ list_lru_add+0x5a/0x100
+ inode_lru_list_add+0x20/0x40
+ iput+0x1c1/0x1f0
+ run_delayed_iput_locked+0x46/0x90
+ btrfs_run_delayed_iputs+0x3f/0x60
+ cleaner_kthread+0xf2/0x120
+ kthread+0x10b/0x130
+
+Fix this by adding a cond_resched_lock() to the loop processing delayed
+iputs so we can avoid these sort of stalls.
+
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Rik van Riel <riel@surriel.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -3571,6 +3571,7 @@ void btrfs_run_delayed_iputs(struct btrf
+ inode = list_first_entry(&fs_info->delayed_iputs,
+ struct btrfs_inode, delayed_iput);
+ run_delayed_iput_locked(fs_info, inode);
++ cond_resched_lock(&fs_info->delayed_iput_lock);
+ }
+ spin_unlock(&fs_info->delayed_iput_lock);
+ }
--- /dev/null
+From d201d7631ca170b038e7f8921120d05eec70d7c5 Mon Sep 17 00:00:00 2001
+From: Ronnie Sahlberg <lsahlber@redhat.com>
+Date: Wed, 19 May 2021 08:40:11 +1000
+Subject: cifs: fix memory leak in smb2_copychunk_range
+
+From: Ronnie Sahlberg <lsahlber@redhat.com>
+
+commit d201d7631ca170b038e7f8921120d05eec70d7c5 upstream.
+
+When using smb2_copychunk_range() for large ranges we will
+run through several iterations of a loop calling SMB2_ioctl()
+but never actually free the returned buffer except for the final
+iteration.
+This leads to memory leaks everytime a large copychunk is requested.
+
+Fixes: 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files")
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/smb2ops.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -1673,6 +1673,8 @@ smb2_copychunk_range(const unsigned int
+ cpu_to_le32(min_t(u32, len, tcon->max_bytes_chunk));
+
+ /* Request server copy to target from src identified by key */
++ kfree(retbuf);
++ retbuf = NULL;
+ rc = SMB2_ioctl(xid, tcon, trgtfile->fid.persistent_fid,
+ trgtfile->fid.volatile_fid, FSCTL_SRV_COPYCHUNK_WRITE,
+ true /* is_fsctl */, (char *)pcchunk,
ptrace-make-ptrace-fail-if-the-tracee-changed-its-pi.patch
nvmet-seset-ns-file-when-open-fails.patch
locking-mutex-clear-mutex_flags-if-wait_list-is-empt.patch
+btrfs-avoid-rcu-stalls-while-running-delayed-iputs.patch
+cifs-fix-memory-leak-in-smb2_copychunk_range.patch
+alsa-dice-fix-stream-format-for-tc-electronic-konnekt-live-at-high-sampling-transfer-frequency.patch
+alsa-intel8x0-don-t-update-period-unless-prepared.patch
+alsa-line6-fix-racy-initialization-of-line6-midi.patch
+alsa-dice-fix-stream-format-at-middle-sampling-rate-for-alesis-io-26.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
