January 2019 - Linux-stable-mirror

[PATCH v2 04/29] alpha: wire up io_pgetevents system call

by Arnd Bergmann

The io_pgetevents system call was added in linux-4.18 but has no entry for alpha: warning: #warning syscall io_pgetevents not implemented [-Wcpp] Assign a the next system call number here. Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/alpha/kernel/syscalls/syscall.tbl | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index 7b56a53be5e3..e09558edae73 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -451,3 +451,4 @@ 520 common preadv2 sys_preadv2 521 common pwritev2 sys_pwritev2 522 common statx sys_statx +523 common io_pgetevents sys_io_pgetevents -- 2.20.0

5 years, 9 months

1
0
0 0

[PATCH] FIXUP: proc: Provide details on speculation flaw mitigations

by Gwendal Grignou

Prevent an empty line in /proc/self/status, allow iotop to work. iotop does not like empty lines, fails with: File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line 196, in parse_proc_pid_status key, value = line.split(':\t', 1) ValueError: need more than 1 value to unpack [reading /proc/self/status] Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 0c142916a8c7d..f11df9ab4256e 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -334,7 +334,7 @@ static inline void task_seccomp(struct seq_file *m, struct task_struct *p) #ifdef CONFIG_SECCOMP seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode); #endif - seq_printf(m, "\nSpeculation_Store_Bypass:\t"); + seq_printf(m, "Speculation_Store_Bypass:\t"); switch (arch_prctl_spec_ctrl_get(p, PR_SPEC_STORE_BYPASS)) { case -EINVAL: seq_printf(m, "unknown"); -- 2.20.1.97.g81188d93c3-goog

5 years, 9 months

5
13
0 0

[PATCH v4.9.y] proc: Remove empty line in /proc/self/status

by Guenter Roeck

If CONFIG_SECCOMP=n, /proc/self/status includes an empty line. This causes the iotop application to bail out with an error message. File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line 196, in parse_proc_pid_status key, value = line.split(':\t', 1) ValueError: need more than 1 value to unpack The problem is seen in v4.9.y but not upstream because commit af884cd4a5ae6 ("proc: report no_new_privs state") has not been backported to v4.9.y. The backport of commit fae1fa0fc6cc ("proc: Provide details on speculation flaw mitigations") tried to address the resulting differences but was wrong, introducing the problem. Fixes: 51ef9af2a35b ("proc: Provide details on speculation flaw mitigations") Cc: Kees Cook <keescook(a)chromium.org> Cc: Gwendal Grignou <gwendal(a)chromium.org> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- This patch only applies to v4.9.y. v4.4.y also needs to be fixed (see https://www.spinics.net/lists/stable/msg279131.html), but the fix is slightly different. v4.14.y and later are not affected. fs/proc/array.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 94f83e74db24..712b44c63701 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -346,8 +346,9 @@ static inline void task_seccomp(struct seq_file *m, struct task_struct *p) { #ifdef CONFIG_SECCOMP seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode); + seq_putc(m, '\n'); #endif - seq_printf(m, "\nSpeculation_Store_Bypass:\t"); + seq_printf(m, "Speculation_Store_Bypass:\t"); switch (arch_prctl_spec_ctrl_get(p, PR_SPEC_STORE_BYPASS)) { case -EINVAL: seq_printf(m, "unknown"); -- 2.7.4

5 years, 9 months

3
2
0 0

[PATCH] sched/fair: Fix bandwidth timer clock drift condition

by Alakesh Haloi

[ Upstream commit 512ac999d2755d2b7109e996a76b6fb8b888631d ] I noticed that cgroup task groups constantly get throttled even if they have low CPU usage, this causes some jitters on the response time to some of our business containers when enabling CPU quotas. It's very simple to reproduce: mkdir /sys/fs/cgroup/cpu/test cd /sys/fs/cgroup/cpu/test echo 100000 > cpu.cfs_quota_us echo $$ > tasks then repeat: cat cpu.stat | grep nr_throttled # nr_throttled will increase steadily After some analysis, we found that cfs_rq::runtime_remaining will be cleared by expire_cfs_rq_runtime() due to two equal but stale "cfs_{b|q}->runtime_expires" after period timer is re-armed. The current condition to judge clock drift in expire_cfs_rq_runtime() is wrong, the two runtime_expires are actually the same when clock drift happens, so this condtion can never hit. The orginal design was correctly done by this commit: a9cf55b28610 ("sched: Expire invalid runtime") ... but was changed to be the current implementation due to its locking bug. This patch introduces another way, it adds a new field in both structures cfs_rq and cfs_bandwidth to record the expiration update sequence, and uses them to figure out if clock drift happens (true if they are equal). Signed-off-by: Xunlei Pang <xlpang(a)linux.alibaba.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> [alakeshh: backport: Fixed merge conflicts: - sched.h: Fix the indentation and order in which the variables are declared to match with coding style of the existing code in 4.14 Struct members of same type were declared in separate lines in upstream patch which has been changed back to having multiple members of same type in the same line. e.g. int a; int b; -> int a, b; ] Signed-off-by: Alakesh Haloi <alakeshh(a)amazon.com> Reviewed-by: 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> Cc: <stable(a)vger.kernel.org> # 4.14.x Fixes: 51f2176d74ac ("sched/fair: Fix unlocked reads of some cfs_b->quota/period") Link: http://lkml.kernel.org/r/20180620101834.24455-1-xlpang@linux.alibaba.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> --- kernel/sched/fair.c | 14 ++++++++------ kernel/sched/sched.h | 4 +++- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7240bb4a4090..e03fb6b2eb94 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4088,6 +4088,7 @@ void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b) now = sched_clock_cpu(smp_processor_id()); cfs_b->runtime = cfs_b->quota; cfs_b->runtime_expires = now + ktime_to_ns(cfs_b->period); + cfs_b->expires_seq++; } static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg) @@ -4110,6 +4111,7 @@ static int assign_cfs_rq_runtime(struct cfs_rq *cfs_rq) struct task_group *tg = cfs_rq->tg; struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg); u64 amount = 0, min_amount, expires; + int expires_seq; /* note: this is a positive sum as runtime_remaining <= 0 */ min_amount = sched_cfs_bandwidth_slice() - cfs_rq->runtime_remaining; @@ -4126,6 +4128,7 @@ static int assign_cfs_rq_runtime(struct cfs_rq *cfs_rq) cfs_b->idle = 0; } } + expires_seq = cfs_b->expires_seq; expires = cfs_b->runtime_expires; raw_spin_unlock(&cfs_b->lock); @@ -4135,8 +4138,10 @@ static int assign_cfs_rq_runtime(struct cfs_rq *cfs_rq) * spread between our sched_clock and the one on which runtime was * issued. */ - if ((s64)(expires - cfs_rq->runtime_expires) > 0) + if (cfs_rq->expires_seq != expires_seq) { + cfs_rq->expires_seq = expires_seq; cfs_rq->runtime_expires = expires; + } return cfs_rq->runtime_remaining > 0; } @@ -4162,12 +4167,9 @@ static void expire_cfs_rq_runtime(struct cfs_rq *cfs_rq) * has not truly expired. * * Fortunately we can check determine whether this the case by checking - * whether the global deadline has advanced. It is valid to compare - * cfs_b->runtime_expires without any locks since we only care about - * exact equality, so a partial write will still work. + * whether the global deadline(cfs_b->expires_seq) has advanced. */ - - if (cfs_rq->runtime_expires != cfs_b->runtime_expires) { + if (cfs_rq->expires_seq == cfs_b->expires_seq) { /* extend local deadline, drift is bounded above by 2 ticks */ cfs_rq->runtime_expires += TICK_NSEC; } else { diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index b3ba6e5e99f2..452b56923c6d 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -281,8 +281,9 @@ struct cfs_bandwidth { u64 quota, runtime; s64 hierarchical_quota; u64 runtime_expires; + int expires_seq; - int idle, period_active; + short idle, period_active; struct hrtimer period_timer, slack_timer; struct list_head throttled_cfs_rq; @@ -488,6 +489,7 @@ struct cfs_rq { #ifdef CONFIG_CFS_BANDWIDTH int runtime_enabled; + int expires_seq; u64 runtime_expires; s64 runtime_remaining; -- 2.14.4

5 years, 9 months

2
1
0 0

[PATCH 3.18,4.4,4.9] media: em28xx: Fix misplaced reset of dev->v4l::field_count

by Ben Hutchings

The backport of commit afeaade90db4 "media: em28xx: make v4l2-compliance happier by starting sequence on zero" added a reset on em28xx_v4l2::field_count to em28xx_ctrl_notify(), but it should be done in em28xx_start_analog_streaming(). Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk> Cc: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> --- All stable branches from 3.18 to 4.14 inclusive have this problem. This patch applies without fuzz to 3.18, 4.4 and 4.9. I'll send a slightly different version for 4.14. Ben. drivers/media/usb/em28xx/em28xx-video.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 5818872ba47d..e4135f7909bd 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -931,6 +931,8 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq, unsigned int count) em28xx_videodbg("%s\n", __func__); + dev->v4l2->field_count = 0; + /* Make sure streaming is not already in progress for this type of filehandle (e.g. video, vbi) */ rc = res_get(dev, vq->type); @@ -1141,8 +1143,6 @@ static void em28xx_ctrl_notify(struct v4l2_ctrl *ctrl, void *priv) { struct em28xx *dev = priv; - dev->v4l2->field_count = 0; - /* * In the case of non-AC97 volume controls, we still need * to do some setups at em28xx, in order to mute/unmute

5 years, 9 months

2
1
0 0

[PATCH 4.14] media: em28xx: Fix misplaced reset of dev->v4l::field_count

by Ben Hutchings

The backport of commit afeaade90db4 "media: em28xx: make v4l2-compliance happier by starting sequence on zero" added a reset on em28xx_v4l2::field_count to em28xx_enable_analog_tuner() but it should be done in em28xx_start_analog_streaming(). Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk> Cc: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> --- drivers/media/usb/em28xx/em28xx-video.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 92a74bc34527..bd8de78e0ffd 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -900,8 +900,6 @@ static int em28xx_enable_analog_tuner(struct em28xx *dev) if (!mdev || !v4l2->decoder) return 0; - dev->v4l2->field_count = 0; - /* * This will find the tuner that is connected into the decoder. * Technically, this is not 100% correct, as the device may be @@ -1074,6 +1072,8 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq, unsigned int count) em28xx_videodbg("%s\n", __func__); + dev->v4l2->field_count = 0; + /* Make sure streaming is not already in progress for this type of filehandle (e.g. video, vbi) */ rc = res_get(dev, vq->type);

5 years, 9 months

2
1
0 0

[PATCH 4.14] mmc: sdhci-msm: Disable CDR function on TX

by Georgi Djakov

From: Loic Poulain <loic.poulain(a)linaro.org> commit a89e7bcb18081c611eb6cf50edd440fa4983a71a upstream. The Clock Data Recovery (CDR) circuit allows to automatically adjust the RX sampling-point/phase for high frequency cards (SDR104, HS200...). CDR is automatically enabled during DLL configuration. However, according to the APQ8016 reference manual, this function must be disabled during TX and tuning phase in order to prevent any interferences during tuning challenges and unexpected phase alteration during TX transfers. This patch enables/disables CDR according to the current transfer mode. This fixes sporadic write transfer issues observed with some SDR104 and HS200 cards. Inspired by sdhci-msm downstream patch: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/… Reported-by: Leonid Segal <leonid.s(a)variscite.com> Reported-by: Manabu Igusa <migusa(a)arrowjapan.com> Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Acked-by: Georgi Djakov <georgi.djakov(a)linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> [georgi: backport to v4.14] Signed-off-by: Georgi Djakov <georgi.djakov(a)linaro.org> --- drivers/mmc/host/sdhci-msm.c | 51 +++++++++++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index 92c483ec6cb2..192844b50c69 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -138,6 +138,8 @@ struct sdhci_msm_host { bool calibration_done; u8 saved_tuning_phase; bool use_cdclp533; + bool use_cdr; + u32 transfer_mode; }; static unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host *host, @@ -815,6 +817,23 @@ static int sdhci_msm_hs400_dll_calibration(struct sdhci_host *host) return ret; } +static void sdhci_msm_set_cdr(struct sdhci_host *host, bool enable) +{ + u32 config, oldconfig = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG); + + config = oldconfig; + if (enable) { + config |= CORE_CDR_EN; + config &= ~CORE_CDR_EXT_EN; + } else { + config &= ~CORE_CDR_EN; + config |= CORE_CDR_EXT_EN; + } + + if (config != oldconfig) + writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG); +} + static int sdhci_msm_execute_tuning(struct mmc_host *mmc, u32 opcode) { struct sdhci_host *host = mmc_priv(mmc); @@ -832,8 +851,14 @@ static int sdhci_msm_execute_tuning(struct mmc_host *mmc, u32 opcode) if (host->clock <= CORE_FREQ_100MHZ || !(ios.timing == MMC_TIMING_MMC_HS400 || ios.timing == MMC_TIMING_MMC_HS200 || - ios.timing == MMC_TIMING_UHS_SDR104)) + ios.timing == MMC_TIMING_UHS_SDR104)) { + msm_host->use_cdr = false; + sdhci_msm_set_cdr(host, false); return 0; + } + + /* Clock-Data-Recovery used to dynamically adjust RX sampling point */ + msm_host->use_cdr = true; /* * For HS400 tuning in HS200 timing requires: @@ -1092,6 +1117,29 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock) __sdhci_msm_set_clock(host, clock); } +static void sdhci_msm_write_w(struct sdhci_host *host, u16 val, int reg) +{ + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host); + + switch (reg) { + case SDHCI_TRANSFER_MODE: + msm_host->transfer_mode = val; + break; + case SDHCI_COMMAND: + if (!msm_host->use_cdr) + break; + if ((msm_host->transfer_mode & SDHCI_TRNS_READ) && + (SDHCI_GET_CMD(val) != MMC_SEND_TUNING_BLOCK_HS200) && + (SDHCI_GET_CMD(val) != MMC_SEND_TUNING_BLOCK)) + sdhci_msm_set_cdr(host, true); + else + sdhci_msm_set_cdr(host, false); + break; + } + writew(val, host->ioaddr + reg); +} + static const struct of_device_id sdhci_msm_dt_match[] = { { .compatible = "qcom,sdhci-msm-v4" }, {}, @@ -1107,6 +1155,7 @@ static const struct sdhci_ops sdhci_msm_ops = { .set_bus_width = sdhci_set_bus_width, .set_uhs_signaling = sdhci_msm_set_uhs_signaling, .voltage_switch = sdhci_msm_voltage_switch, + .write_w = sdhci_msm_write_w, }; static const struct sdhci_pltfm_data sdhci_msm_pdata = {

5 years, 9 months

2
2
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Hans de Goede

Hi, On 1/17/19 8:30 PM, Mogens Jensen wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, January 17, 2019 12:05 PM, Hans de Goede <hdegoede(a)redhat.com> wrote: > >> Hi, >> >> On 17-01-19 10:12, Dean Wallace wrote: >> >>> Hi Hans, Mogens, >>> On 17-01-19, Mogens Jensen wrote: >>> >>>> Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the quirk seems to have fixed the problem caused by commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), as sound is now working if running "speaker-test" on my system which is clean ALSA. >> >> Note being "clean ALSA" is really not a good thing now a days, >> for lots of things we depend on pulseaudio (like setting >> up UCM mixer profiles). >> > I'm using UCM mixer profile from: > > https://github.com/plbossart/UCM/tree/master/chtmax98090 > > This is enabled with: > > alsaucm -c chtmax98090 set _verb HiFi set _enadev Speakers > >>>> Unfortunately, SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver is unusable on Clapper Chromebooks as audio played from everything but "speaker-test" as video players or web browsers is extremly low and sounds like played at 10x speed. At the same time kernel log is spammed with messages like this: >>>> max98090 i2c-193C9890:00: PLL unlocked >>>> intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01 >>>> writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U... >>>> writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u... >>>> This is probably not related to the problem discussed in this thread, but the result is that I have to use the legacy driver SND_SOC_INTEL_BYT_MAX98090_MACH and therefore still has to revert commit 648e921888ad for sound to work. >>>> Is it possible to create a fix for SND_SOC_INTEL_BYT_MAX98090_MACH on kernel 4.19? Kernel 4.19 is a long term release so it would be very nice to have fix for this version upstream. >>> >>> I have been reverting "clk: x86: Stop marking clocks as CLK_IS_CRITICAL" >>> and the patch that initially added the quirk for swanky because of sound >>> instability issues as you described. I'm compiling vanilla Archlinux >>> kernel with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH, using pulseaudio, >>> and have sound in all my apps. >>> Baytrail sound has always been a little touchy, especially using headset >>> with mic, but since the clk patch breaking sound and the quirk patch to >>> fix it, there is a lot more instability. Just running pavucontrol, or >>> plugging in headset sets it off. It's a head scratcher. >> >> Mogens, Dean, can you please try the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH >> driver, without reverting any patches, with the attached patch on top and >> see if that helps? >> >> Thanks & Regards, >> >> Hans > > I have applied the patch to kernel 4.19.15 and unfortunately this has not solved the problems. > > Audio generated from "speaker-test" is normal, but from everything else is very low and played at 10x speed. However, I'm not seeing the "max98090 i2c-193C9890:00: PLL unlocked" message in kernel log anymore, but it's still spammed with "writing to lpe: ...". Hmm, I've a feeling the problem is your using alsa directly, do you have dmix enabled ? You probably need dmix since the SST sound support only supports 48KHz AFAIK. Can you perhaps give things a try with pulseaudio ? Regards, Hans

5 years, 9 months

1
0
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Dean Wallace

Hi Hans, Mogens, On 17-01-19, Mogens Jensen wrote: > Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the quirk seems to have fixed the problem caused by commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), as sound is now working if running "speaker-test" on my system which is clean ALSA. > > Unfortunately, SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver is unusable on Clapper Chromebooks as audio played from everything but "speaker-test" as video players or web browsers is extremly low and sounds like played at 10x speed. At the same time kernel log is spammed with messages like this: > > max98090 i2c-193C9890:00: PLL unlocked > intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01 > writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U... > writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u... > > This is probably not related to the problem discussed in this thread, but the result is that I have to use the legacy driver SND_SOC_INTEL_BYT_MAX98090_MACH and therefore still has to revert commit 648e921888ad for sound to work. > > Is it possible to create a fix for SND_SOC_INTEL_BYT_MAX98090_MACH on kernel 4.19? Kernel 4.19 is a long term release so it would be very nice to have fix for this version upstream. I have been reverting "clk: x86: Stop marking clocks as CLK_IS_CRITICAL" and the patch that initially added the quirk for swanky because of sound instability issues as you described. I'm compiling vanilla Archlinux kernel with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH, using pulseaudio, and have sound in all my apps. Baytrail sound has always been a little touchy, especially using headset with mic, but since the clk patch breaking sound and the quirk patch to fix it, there is a lot more instability. Just running pavucontrol, or plugging in headset sets it off. It's a head scratcher. -Dean

5 years, 9 months

3
4
0 0

Re: [PATCH v3 1/2] fs: don't let getdents return bogus names

by Jann Horn

On Fri, Jan 18, 2019 at 4:01 PM Sasha Levin <sashal(a)kernel.org> wrote: > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 1da177e4c3f4 Linux-2.6.12-rc2. > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150, v4.4.170, v3.18.132. > > v4.20.2: Build OK! > v4.19.15: Build OK! > v4.14.93: Build OK! > v4.9.150: Failed to apply! Possible dependencies: > 0460b2a28b4b ("readdir: move compat syscalls from compat.c") > > v4.4.170: Failed to apply! Possible dependencies: > 0460b2a28b4b ("readdir: move compat syscalls from compat.c") > 1f60fbe72749 ("ext4: allow readdir()'s of large empty directories to be interrupted") > 63b6df14134d ("give readdir(2)/getdents(2)/etc. uniform exclusion with lseek()") > > v3.18.132: Failed to apply! Possible dependencies: > 0460b2a28b4b ("readdir: move compat syscalls from compat.c") > 1f60fbe72749 ("ext4: allow readdir()'s of large empty directories to be interrupted") > 63b6df14134d ("give readdir(2)/getdents(2)/etc. uniform exclusion with lseek()") > ac7576f4b1da ("vfs: make first argument of dir_context.actor typed") > > > How should we proceed with this patch? Once it's landed, for the older kernels, a manual backport probably makes the most sense, I think.

5 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2019