- Linux-stable-mirror - lists.linaro.org

Re: [alsa-devel] [PATCH] ASoC: rockchip: add missing INTERLEAVED PCM attribute

by Doug Anderson

Hi, On Sep 10, 2018 at 4:39 PM Katsuhiro Suzuki <katsuhiro(a)katsuster.net> wrote: > > This patch adds SNDRV_PCM_INFO_INTERLEAVED into PCM hardware info. > > Signed-off-by: Katsuhiro Suzuki <katsuhiro(a)katsuster.net> > --- > sound/soc/rockchip/rockchip_pcm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) I just tracked down that audio was broken on 4.19 and needs this change to work. Stable: can you please pick it? Specifically I believe you'd want to treat it as if it had: Fixes: 75b31192fe6a ("ASoC: rockchip: add config for rockchip dmaengine pcm register") -Doug

6 years, 6 months

3
3
0 0

[PATCH AUTOSEL 4.9 01/28] HID: logitech: check the return value of create_singlethread_workqueue

by Sasha Levin

From: Kangjie Lu <kjlu(a)umn.edu> [ Upstream commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2 ] create_singlethread_workqueue may fail and return NULL. The fix checks if it is NULL to avoid NULL pointer dereference. Also, the fix moves the call of create_singlethread_workqueue earlier to avoid resource-release issues. Signed-off-by: Kangjie Lu <kjlu(a)umn.edu> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/hid-logitech-hidpp.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 2e2515a4c070..3198faf5cff4 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -1282,6 +1282,13 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index) kfree(data); return -ENOMEM; } + data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue"); + if (!data->wq) { + kfree(data->effect_ids); + kfree(data); + return -ENOMEM; + } + data->hidpp = hidpp; data->feature_index = feature_index; data->version = version; @@ -1326,7 +1333,6 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index) /* ignore boost value at response.fap.params[2] */ /* init the hardware command queue */ - data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue"); atomic_set(&data->workqueue_size, 0); /* initialize with zero autocenter to get wheel in usable state */ -- 2.19.1

6 years, 6 months

1
0
0 0

[PATCH AUTOSEL 4.14 01/35] HID: logitech: check the return value of create_singlethread_workqueue

by Sasha Levin

From: Kangjie Lu <kjlu(a)umn.edu> [ Upstream commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2 ] create_singlethread_workqueue may fail and return NULL. The fix checks if it is NULL to avoid NULL pointer dereference. Also, the fix moves the call of create_singlethread_workqueue earlier to avoid resource-release issues. Signed-off-by: Kangjie Lu <kjlu(a)umn.edu> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/hid-logitech-hidpp.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 614054af904a..b83d4173fc7f 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -1907,6 +1907,13 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index) kfree(data); return -ENOMEM; } + data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue"); + if (!data->wq) { + kfree(data->effect_ids); + kfree(data); + return -ENOMEM; + } + data->hidpp = hidpp; data->feature_index = feature_index; data->version = version; @@ -1951,7 +1958,6 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index) /* ignore boost value at response.fap.params[2] */ /* init the hardware command queue */ - data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue"); atomic_set(&data->workqueue_size, 0); /* initialize with zero autocenter to get wheel in usable state */ -- 2.19.1

6 years, 6 months

1
0
0 0

[PATCH AUTOSEL 4.19 01/52] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay

by Sasha Levin

From: "Leonidas P. Papadakos" <papadakospan(a)gmail.com> [ Upstream commit 924726888f660b2a86382a5dd051ec9ca1b18190 ] The rk3328-roc-cc board exhibits tx stability issues with large packets, as does the rock64 board, which was fixed with this patch https://patchwork.kernel.org/patch/10178969/ A similar patch was merged for the rk3328-roc-cc here https://patchwork.kernel.org/patch/10804863/ but it doesn't include the tx/rx_delay tweaks, and I find that they help with an issue where large transfers would bring the ethernet link down, causing a link reset regularly. Signed-off-by: Leonidas P. Papadakos <papadakospan(a)gmail.com> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts index 246c317f6a68..91061d9cf78b 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts @@ -94,8 +94,8 @@ snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; snps,reset-active-low; snps,reset-delays-us = <0 10000 50000>; - tx_delay = <0x25>; - rx_delay = <0x11>; + tx_delay = <0x24>; + rx_delay = <0x18>; status = "okay"; }; -- 2.19.1

6 years, 6 months

1
1
0 0

FAILED: patch "[PATCH] sched/fair: Limit sched_cfs_period_timer() loop to avoid hard" failed to apply to 5.0-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.0-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2e8e19226398db8265a8e675fcc0118b9e80c9e8 Mon Sep 17 00:00:00 2001 From: Phil Auld <pauld(a)redhat.com> Date: Tue, 19 Mar 2019 09:00:05 -0400 Subject: [PATCH] sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup With extremely short cfs_period_us setting on a parent task group with a large number of children the for loop in sched_cfs_period_timer() can run until the watchdog fires. There is no guarantee that the call to hrtimer_forward_now() will ever return 0. The large number of children can make do_sched_cfs_period_timer() take longer than the period. NMI watchdog: Watchdog detected hard LOCKUP on cpu 24 RIP: 0010:tg_nop+0x0/0x10 <IRQ> walk_tg_tree_from+0x29/0xb0 unthrottle_cfs_rq+0xe0/0x1a0 distribute_cfs_runtime+0xd3/0xf0 sched_cfs_period_timer+0xcb/0x160 ? sched_cfs_slack_timer+0xd0/0xd0 __hrtimer_run_queues+0xfb/0x270 hrtimer_interrupt+0x122/0x270 smp_apic_timer_interrupt+0x6a/0x140 apic_timer_interrupt+0xf/0x20 </IRQ> To prevent this we add protection to the loop that detects when the loop has run too many times and scales the period and quota up, proportionally, so that the timer can complete before then next period expires. This preserves the relative runtime quota while preventing the hard lockup. A warning is issued reporting this state and the new values. Signed-off-by: Phil Auld <pauld(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Cc: Anton Blanchard <anton(a)ozlabs.org> Cc: Ben Segall <bsegall(a)google.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lkml.kernel.org/r/20190319130005.25492-1-pauld@redhat.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 40bd1e27b1b7..a4d9e14bf138 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4885,6 +4885,8 @@ static enum hrtimer_restart sched_cfs_slack_timer(struct hrtimer *timer) return HRTIMER_NORESTART; } +extern const u64 max_cfs_quota_period; + static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer) { struct cfs_bandwidth *cfs_b = @@ -4892,6 +4894,7 @@ static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer) unsigned long flags; int overrun; int idle = 0; + int count = 0; raw_spin_lock_irqsave(&cfs_b->lock, flags); for (;;) { @@ -4899,6 +4902,28 @@ static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer) if (!overrun) break; + if (++count > 3) { + u64 new, old = ktime_to_ns(cfs_b->period); + + new = (old * 147) / 128; /* ~115% */ + new = min(new, max_cfs_quota_period); + + cfs_b->period = ns_to_ktime(new); + + /* since max is 1s, this is limited to 1e9^2, which fits in u64 */ + cfs_b->quota *= new; + cfs_b->quota = div64_u64(cfs_b->quota, old); + + pr_warn_ratelimited( + "cfs_period_timer[cpu%d]: period too short, scaling up (new cfs_period_us %lld, cfs_quota_us = %lld)\n", + smp_processor_id(), + div_u64(new, NSEC_PER_USEC), + div_u64(cfs_b->quota, NSEC_PER_USEC)); + + /* reset count so we don't come right back in here */ + count = 0; + } + idle = do_sched_cfs_period_timer(cfs_b, overrun, flags); } if (idle)

6 years, 6 months

4
5
0 0

Re: Re: [PATCH v4] signal: trace_signal_deliver when signal_group_exit

by weizhenliang

On 04/24, Christian Brauner wrote: >On Wed, Apr 24, 2019 at 08:52:38PM +0800, Zhenliang Wei wrote: >> >> Acked-by: Christian Brauner <christian(a)brauner.io> > >I think we're supposed to use more Reviewed-bys so feel free (or Andrew) to change this to: > >Reviewed-by: Christian Brauner <christian(a)brauner.io> Ok, I will change this in patch v5. >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -2441,6 +2441,8 @@ bool get_signal(struct ksignal *ksig) >> if (signal_group_exit(signal)) { >> ksig->info.si_signo = signr = SIGKILL; >> sigdelset(&current->pending.signal, SIGKILL); >> + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, >> + &sighand->action[signr - 1]); > >Hm, sorry for being the really nitpicky person here. Just for the sake of consistency how about we do either: > >+ trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, >+ &sighand->action[SIGKILL - 1]); > >or > >+ trace_signal_deliver(signr, SEND_SIG_NOINFO, >+ &sighand->action[signr - 1]); > >I'm not going to argue about this though. Can just also leave it as is. Thank you for your comments and learn from rigorous people! I will take: + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, + &sighand->action[SIGKILL - 1]); Any other suggestions about the patch? Wei

6 years, 6 months

1
0
0 0

[PATCH v4] signal: trace_signal_deliver when signal_group_exit

by Zhenliang Wei

In the fixes commit, removing SIGKILL from each thread signal mask and executing "goto fatal" directly will skip the call to "trace_signal_deliver". At this point, the delivery tracking of the SIGKILL signal will be inaccurate. Therefore, we need to add trace_signal_deliver before "goto fatal" after executing sigdelset. Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info. Acked-by: Christian Brauner <christian(a)brauner.io> Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT") Reported-by: kbuild test robot <lkp(a)intel.com> Signed-off-by: Zhenliang Wei <weizhenliang(a)huawei.com> --- kernel/signal.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/signal.c b/kernel/signal.c index 227ba170298e..3edf526db7c6 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2441,6 +2441,8 @@ bool get_signal(struct ksignal *ksig) if (signal_group_exit(signal)) { ksig->info.si_signo = signr = SIGKILL; sigdelset(&current->pending.signal, SIGKILL); + trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO, + &sighand->action[signr - 1]); recalc_sigpending(); goto fatal; } -- 2.14.1.windows.1

6 years, 6 months

3
2
0 0

[PATCH v1] mmc: sdhci: Handle auto-command errors

by Kaiyen Chang

Existing data command CRC error handling on kernel 4.20 stable branch is non-standard and does not work with some Intel host controllers. Specifically, the assumption that the host controller will continue operating normally after the error interrupt, is not valid. So we suggest cherry-pick the 3 patches listed below to kernel 4.20 stable branch, which can change the driver to handle the error in the same manner as a data CRC error. 4bf7809: mmc: sdhci: Fix data command CRC error handling 869f8a6: mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR af849c8: mmc: sdhci: Handle auto-command errors All of the patches above have landed on kernel 5.0 stable branch.

6 years, 6 months

4
5
0 0

[RESEND, PATCH 3/3] fuse: Add FOPEN_STREAM and use stream_open() if filesystem returned that from open handler

by Kirill Smelkov

Starting from 9c225f2655 (vfs: atomic f_pos accesses as per POSIX) files opened even via nonseekable_open gate read and write via lock and do not allow them to be run simultaneously. This can create read vs write deadlock if a filesystem is trying to implement a socket-like file which is intended to be simultaneously used for both read and write from filesystem client. See 10dce8af3422 ("fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock") for details and e.g. 581d21a2d0 (xenbus: fix deadlock on writes to /proc/xen/xenbus) for a similar deadlock example on /proc/xen/xenbus. To avoid such deadlock it was tempting to adjust fuse_finish_open to use stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE, and in particular GVFS which actually uses offset in its read and write handlers https://codesearch.debian.net/search?q=-%3Enonseekable+%3D https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfuse… https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfuse… https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfuse… so if we would do such a change it will break a real user. -> Add another flag (FOPEN_STREAM) for filesystem servers to indicate that the opened handler is having stream-like semantics; does not use file position and thus the kernel is free to issue simultaneous read and write request on opened file handle. This patch together with stream_open (10dce8af3422) should be added to stable kernels starting from v3.14+ (the kernel where 9c225f2655 first appeared). This will allow to patch OSSPD and other FUSE filesystems that provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE in open handler and this way avoid the deadlock on all kernel versions. This should work because fuse_finish_open ignores unknown open flags returned from a filesystem and so passing FOPEN_STREAM to a kernel that is not aware of this flag cannot hurt. In turn the kernel that is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE is sufficient to implement streams without read vs write deadlock. Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Yongzhi Pan <panyongzhi(a)gmail.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: David Vrabel <david.vrabel(a)citrix.com> Cc: Juergen Gross <jgross(a)suse.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Kirill Tkhai <ktkhai(a)virtuozzo.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Julia Lawall <Julia.Lawall(a)lip6.fr> Cc: Nikolaus Rath <Nikolaus(a)rath.org> Cc: Han-Wen Nienhuys <hanwen(a)google.com> Cc: stable(a)vger.kernel.org # v3.14+ Signed-off-by: Kirill Smelkov <kirr(a)nexedi.com> --- ( resending the same patch with updated description to reference stream_open that was landed to master as 10dce8af3422; also added cc stable ) fs/fuse/file.c | 4 +++- include/uapi/linux/fuse.h | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 06096b60f1df..44de96cb7871 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -178,7 +178,9 @@ void fuse_finish_open(struct inode *inode, struct file *file) if (!(ff->open_flags & FOPEN_KEEP_CACHE)) invalidate_inode_pages2(inode->i_mapping); - if (ff->open_flags & FOPEN_NONSEEKABLE) + if (ff->open_flags & FOPEN_STREAM) + stream_open(inode, file); + else if (ff->open_flags & FOPEN_NONSEEKABLE) nonseekable_open(inode, file); if (fc->atomic_o_trunc && (file->f_flags & O_TRUNC)) { struct fuse_inode *fi = get_fuse_inode(inode); diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h index 2ac598614a8f..26abf0a571c7 100644 --- a/include/uapi/linux/fuse.h +++ b/include/uapi/linux/fuse.h @@ -229,11 +229,13 @@ struct fuse_file_lock { * FOPEN_KEEP_CACHE: don't invalidate the data cache on open * FOPEN_NONSEEKABLE: the file is not seekable * FOPEN_CACHE_DIR: allow caching this directory + * FOPEN_STREAM: the file is stream-like */ #define FOPEN_DIRECT_IO (1 << 0) #define FOPEN_KEEP_CACHE (1 << 1) #define FOPEN_NONSEEKABLE (1 << 2) #define FOPEN_CACHE_DIR (1 << 3) +#define FOPEN_STREAM (1 << 4) /** * INIT request/reply flags -- 2.21.0.765.geec228f530

6 years, 6 months

1
0
0 0

Backport of commit a75bb4eb9e565b9f5115e2e8c07377ce32cbe69a

by Nathan Chancellor

Hi Greg and Sasha, Please apply this commit to 4.4 through 5.0 (patches are threaded in reply to this one), which will prevent Clang from emitting references to compiler runtime functions and doing some performance-killing optimization when using CONFIG_CC_OPTIMIZE_FOR_SIZE. Please let me know if I did something wrong or if there are any objections. Cheers, Nathan

6 years, 6 months

5
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror