4.14.128-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 1/53 drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
In reply to Greg Kroah-HartmanFrom: Dave Airlie <[email protected]>
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine <[email protected]> Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
Author: Daniel Vetter <[email protected]>
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie <[email protected]>
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the previous attempts
- drop the part touching the drm hw lock, that should be a separate patch.
v2: move DRM_VM dependency into legacy config.
v3: fix missing dep (kbuild robot)
--- drivers/gpu/drm/nouveau/Kconfig | 13 ++++++++++++- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +++++-- 2 files changed, 17 insertions(+), 3 deletions(-)
drivers/gpu/drm/nouveau/Kconfig +12 -1
@@ -16,10 +16,21 @@ config DRM_NOUVEAU select INPUT if ACPI && X86 select THERMAL if ACPI && X86 select ACPI_VIDEO if ACPI && X86 - select DRM_VM help Choose this option for open-source NVIDIA support. +config NOUVEAU_LEGACY_CTX_SUPPORT + bool "Nouveau legacy context support" + depends on DRM_NOUVEAU + select DRM_VM + default y + help + There was a version of the nouveau DDX that relied on legacy + ctx ioctls not erroring out. But that was back in time a long + ways, so offer a way to disable it now. For uapi compat with + old nouveau ddx this should be on by default, but modern distros + should consider turning it off. + config NOUVEAU_PLATFORM_DRIVER bool "Nouveau (NVIDIA) SoC GPUs" depends on DRM_NOUVEAU && ARCH_TEGRA
drivers/gpu/drm/nouveau/nouveau_drm.c +5 -2
@@ -967,8 +967,11 @@ nouveau_driver_fops = {static struct drm_driver driver_stub = { .driver_features = -DRIVER_GEM |DRIVER_MODESET |DRIVER_PRIME |DRIVER_RENDER | -DRIVER_KMS_LEGACY_CONTEXT , +DRIVER_GEM |DRIVER_MODESET |DRIVER_PRIME |DRIVER_RENDER +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) + |DRIVER_KMS_LEGACY_CONTEXT +#endif + , .load = nouveau_drm_load, .unload = nouveau_drm_unload,
Greg Kroah-Hartman
maintainerPATCH 10/53 fs/ocfs2: fix race in ocfs2_dentry_attach_lock()
In reply to Greg Kroah-HartmanFrom: Wengang Wang <[email protected]>
commit be99ca2716972a712cde46092c54dee5e6192bf8 upstream.
ocfs2_dentry_attach_lock() can be executed in parallel threads against the same dentry. Make that race safe. The race is like this:
thread A thread B
(A1) enter ocfs2_dentry_attach_lock,
seeing dentry->d_fsdata is NULL,
and no alias found byocfs2_find_local_alias, so kmalloc
a new ocfs2_dentry_lock structure
to local variable "dl", dl1
.....
(B1) enter ocfs2_dentry_attach_lock, seeing dentry->d_fsdata is NULL, and no alias found by ocfs2_find_local_alias so kmalloc a new ocfs2_dentry_lock structure to local variable "dl", dl2.
......
(A2) set dentry->d_fsdata with dl1,
call ocfs2_dentry_lock() and increasedl1->dl_lockres.l_ro_holders to 1 on
success.
......
(B2) set dentry->d_fsdata with dl2
call ocfs2_dentry_lock() and increase
dl2->dl_lockres.l_ro_holders to 1 on
success.
......(A3) call ocfs2_dentry_unlock()
and decreasedl2->dl_lockres.l_ro_holders to 0
on success.
....
(B3) call ocfs2_dentry_unlock(),
decreasing
dl2->dl_lockres.l_ro_holders, but
see it's zero now, panic--- fs/ocfs2/dcache.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
fs/ocfs2/dcache.c +12 -0
@@ -310,6 +310,18 @@ int ocfs2_dentry_attach_lock(struct dent out_attach:spin_lock (&dentry_attach_lock); +if (unlikely (dentry->d_fsdata && !alias)) { +/* d_fsdata is set by a racing thread which is doing +* the same thing as this thread is doing. Leave the racing +* thread going ahead and we return here. +*/ +spin_unlock (&dentry_attach_lock); +iput (dl->dl_inode); +ocfs2_lock_res_free (&dl->dl_lockres); +kfree (dl); +return 0 ; + } + dentry->d_fsdata = dl; dl->dl_count++;spin_unlock (&dentry_attach_lock);
Greg Kroah-Hartman
maintainerPATCH 11/53 mm/vmscan.c: fix trying to reclaim unevictable LRU page
In reply to Greg Kroah-HartmanFrom: Minchan Kim <[email protected]>
commit a58f2cef26e1ca44182c8b22f4f4395e702a5795 upstream.
There was the below bug report from Wu Fangsuo.
On the CMA allocation path, isolate_migratepages_range() could isolate unevictable LRU pages and reclaim_clean_page_from_list() can try to reclaim them if they are clean file-backed pages.
page:ffffffbf02f33b40 count:86 mapcount:84 mapping:ffffffc08fa7a810 index:0x24
flags: 0x19040c(referenced|uptodate|arch_1|mappedtodisk|unevictable|mlocked)
raw: 000000000019040c ffffffc08fa7a810 0000000000000024 0000005600000053
raw: ffffffc009b05b20 ffffffc009b05b20 0000000000000000 ffffffc09bf3ee80
page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page))
page->mem_cgroup:ffffffc09bf3ee80
------------[ cut here ]------------
kernel BUG at /home/build/farmland/adroid9.0/kernel/linux/mm/vmscan.c:1350!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 7125 Comm: syz-executor Tainted: G S 4.14.81 #3
Hardware name: ASR AQUILAC EVB (DT)
task: ffffffc00a54cd00 task.stack: ffffffc009b00000
PC is at shrink_page_list+0x1998/0x3240
LR is at shrink_page_list+0x1998/0x3240
pc : [<ffffff90083a2158>] lr : [<ffffff90083a2158>] pstate: 60400045
sp : ffffffc009b05940
..
shrink_page_list+0x1998/0x3240
reclaim_clean_pages_from_list+0x3c0/0x4f0
alloc_contig_range+0x3bc/0x650
cma_alloc+0x214/0x668
ion_cma_allocate+0x98/0x1d8
ion_alloc+0x200/0x7e0
ion_ioctl+0x18c/0x378
do_vfs_ioctl+0x17c/0x1780
SyS_ioctl+0xac/0xc0Wu found it's due to commit ad6b67041a45 ("mm: remove SWAP_MLOCK in ttu"). Before that, unevictable pages go to cull_mlocked so that we can't reach the VM_BUG_ON_PAGE line.
To fix the issue, this patch filters out unevictable LRU pages from the reclaim_clean_pages_from_list in CMA.
--- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/vmscan.c +1 -1
@@ -1393,7 +1393,7 @@ unsigned long reclaim_clean_pages_from_llist_for_each_entry_safe (page, next, page_list, lru) {if (page_is_file_cache (page) && !PageDirty (page) && - !__PageMovable (page)) { + !__PageMovable (page) && !PageUnevictable (page)) {ClearPageActive (page);list_move (&page->lru, &clean_pages); }
Greg Kroah-Hartman
maintainerPATCH 13/53 ptrace: restore smp_rmb() in __ptrace_may_access()
In reply to Greg Kroah-HartmanFrom: Jann Horn <[email protected]>
commit f6581f5b55141a95657ef5742cf6a6bfa20a109f upstream.
Restore the read memory barrier in __ptrace_may_access() that was deleted a couple years ago. Also add comments on this barrier and the one it pairs with to explain why they're there (as far as I understand).
--- kernel/cred.c | 9 +++++++++ kernel/ptrace.c | 10 ++++++++++ 2 files changed, 19 insertions(+)
kernel/cred.c +9 -0
@@ -448,6 +448,15 @@ int commit_creds(struct cred *new)if (task->mm)set_dumpable (task->mm, suid_dumpable); task->pdeath_signal =0 ; +/* +* If a task drops privileges and becomes nondumpable, +* the dumpability change must become visible before +* the credential change; otherwise, a __ptrace_may_access() +* racing with this change may be able to attach to a task it +* shouldn't be able to attach to (as if the task had dropped +* privileges without becoming nondumpable). +* Pairs with a read barrier in __ptrace_may_access(). +*/ smp_wmb (); }
kernel/ptrace.c +10 -0
@@ -323,6 +323,16 @@ static int __ptrace_may_access(struct tareturn -EPERM ; ok:rcu_read_unlock (); +/* +* If a task drops privileges and becomes nondumpable (through a syscall +* like setresuid()) while we are trying to access it, we must ensure +* that the dumpability is read after the credentials; otherwise, +* we may be able to attach to a task that we shouldn't be able to +* attach to (as if the task had dropped privileges without becoming +* nondumpable). +* Pairs with a write barrier in commit_creds(). +*/ +smp_rmb (); mm = task->mm; if (mm && ((get_dumpable(mm) != SUID_DUMP_USER) &&
Greg Kroah-Hartman
maintainerPATCH 14/53 media: v4l2-ioctl: clear fields in s_parm
In reply to Greg Kroah-HartmanFrom: Hans Verkuil <[email protected]>
commit 8a7c5594c02022ca5fa7fb603e11b3e1feb76ed5 upstream.
Zero the reserved capture/output array.
Zero the extendedmode (it is never used in drivers).
Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY, as that is the only valid flag.
--- drivers/media/v4l2-core/v4l2-ioctl.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
drivers/media/v4l2-core/v4l2-ioctl.c +16 -1
@@ -1945,7 +1945,22 @@ static int v4l_s_parm(const struct v4l2_struct v4l2_streamparm *p = arg;int ret =check_fmt (file, p->type); -return ret ? ret : ops->vidioc_s_parm (file, fh, p); +if (ret) +return ret; + +/* Note: extendedmode is never used in drivers */ +if (V4L2_TYPE_IS_OUTPUT (p->type)) { +memset (p->parm.output.reserved,0 , +sizeof (p->parm.output.reserved)); + p->parm.output.extendedmode =0 ; + p->parm.output.outputmode &=V4L2_MODE_HIGHQUALITY ; + }else { +memset (p->parm.capture.reserved,0 , +sizeof (p->parm.capture.reserved)); + p->parm.capture.extendedmode =0 ; + p->parm.capture.capturemode &=V4L2_MODE_HIGHQUALITY ; + } +return ops->vidioc_s_parm (file, fh, p); } static int v4l_queryctrl(const struct v4l2_ioctl_ops *ops,
Greg Kroah-Hartman
maintainerPATCH 15/53 iommu/arm-smmu: Avoid constant zero in TLBI writes
In reply to Greg Kroah-HartmanFrom: Robin Murphy <[email protected]>
commit 4e4abae311e4b44aaf61f18a826fd7136037f199 upstream.
Apparently, some Qualcomm arm64 platforms which appear to expose their SMMU global register space are still, in fact, using a hypervisor to mediate it by trapping and emulating register accesses. Sadly, some deployed versions of said trapping code have bugs wherein they go horribly wrong for stores using r31 (i.e. XZR/WZR) as the source register.
While this can be mitigated for GCC today by tweaking the constraints for the implementation of writel_relaxed(), to avoid any potential arms race with future compilers more aggressively optimising register allocation, the simple way is to just remove all the problematic constant zeros. For the write-only TLB operations, the actual value is irrelevant anyway and any old nearby variable will provide a suitable GPR to encode. The one point at which we really do need a zero to clear a context bank happens before any of the TLB maintenance where crashes have been reported, so is apparently not a problem... :/
--- drivers/iommu/arm-smmu.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/iommu/arm-smmu.c +12 -3
@@ -56,6 +56,15 @@#include "io-pgtable.h" #include "arm-smmu-regs.h" +/* +* Apparently, some Qualcomm arm64 platforms which appear to expose their SMMU +* global register space are still, in fact, using a hypervisor to mediate it +* by trapping and emulating register accesses. Sadly, some deployed versions +* of said trapping code have bugs wherein they go horribly wrong for stores +* using r31 (i.e. XZR/WZR) as the source register. +*/ +#define QCOM_DUMMY_VAL -1 +#define ARM_MMU500_ACTLR_CPRE (1 << 1)#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
@@ -404,7 +413,7 @@ static void __arm_smmu_tlb_sync(struct a {unsigned int spin_cnt, delay; -writel_relaxed (0 , sync); +writel_relaxed (QCOM_DUMMY_VAL , sync);for (delay =1 ; delay <TLB_LOOP_TIMEOUT ; delay *=2 ) {for (spin_cnt =TLB_SPIN_COUNT ; spin_cnt >0 ; spin_cnt--) {if (!(readl_relaxed (status) & sTLBGSTATUS_GSACTIVE))
@@ -1635,8 +1644,8 @@ static void arm_smmu_device_reset(struct }/* Invalidate the TLB, just in case */ -writel_relaxed (0 , gr0_base +ARM_SMMU_GR0_TLBIALLH ); -writel_relaxed (0 , gr0_base +ARM_SMMU_GR0_TLBIALLNSNH ); +writel_relaxed (QCOM_DUMMY_VAL , gr0_base +ARM_SMMU_GR0_TLBIALLH ); +writel_relaxed (QCOM_DUMMY_VAL , gr0_base +ARM_SMMU_GR0_TLBIALLNSNH ); reg =readl_relaxed (ARM_SMMU_GR0_NS (smmu) + ARM_SMMU_GR0_sCR0);
Greg Kroah-Hartman
maintainerPATCH 17/53 bcache: fix stack corruption by PRECEDING_KEY()
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 31b90956b124240aa8c63250243ae1a53585c5e2 upstream.
Recently people report bcache code compiled with gcc9 is broken, one of the buggy behavior I observe is that two adjacent 4KB I/Os should merge into one but they don't. Finally it turns out to be a stack corruption caused by macro PRECEDING_KEY().
See how PRECEDING_KEY() is defined in bset.h,
437 #define PRECEDING_KEY(_k) \
438 ({ \
439 struct bkey *_ret = NULL; \
440 \
441 if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \
442 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \
443 \
444 if (!_ret->low) \
445 _ret->high--; \
446 _ret->low--; \
447 } \
448 \
449 _ret; \450 })
At line 442, _ret points to address of a on-stack variable combined by KEY(), the life range of this on-stack variable is in line 442-446, once _ret is returned to bch_btree_insert_key(), the returned address points to an invalid stack address and this address is overwritten in the following called bch_btree_iter_init(). Then argument 'search' of bch_btree_iter_init() points to some address inside stackframe of bch_btree_iter_init(), exact address depends on how the compiler allocates stack space. Now the stack is corrupted.
--- drivers/md/bcache/bset.c | 16 +++++++++++++--- drivers/md/bcache/bset.h | 34 ++++++++++++++++++++-------------- 2 files changed, 33 insertions(+), 17 deletions(-)
drivers/md/bcache/bset.c +13 -3
@@ -825,12 +825,22 @@ unsigned bch_btree_insert_key(struct btrstruct bset *i =bset_tree_last (b)->data;struct bkey *m, *prev =NULL ;struct btree_iter iter; +struct bkey preceding_key_on_stack =ZERO_KEY ; +struct bkey *preceding_key_p = &preceding_key_on_stack;BUG_ON (b->ops->is_extents && !KEY_SIZE (k)); - m =bch_btree_iter_init (b, &iter, b->ops->is_extents - ?PRECEDING_KEY (&START_KEY (k)) - :PRECEDING_KEY (k)); +/* +* If k has preceding key, preceding_key_p will be set to address +* of k's preceding key; otherwise preceding_key_p will be set +* to NULL inside preceding_key(). +*/ +if (b->ops->is_extents) +preceding_key (&START_KEY (k), &preceding_key_p); +else +preceding_key (k, &preceding_key_p); + + m =bch_btree_iter_init (b, &iter, preceding_key_p);if (b->ops->insert_fixup (b, k, &iter, replace_key))return status;
drivers/md/bcache/bset.h +20 -14
@@ -418,20 +418,26 @@ static inline bool bch_cut_back(const streturn __bch_cut_back (where, k); } -#define PRECEDING_KEY (_k) \ -({ \ - struct bkey *_ret = NULL; \ - \ - if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \ - _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \ - \ - if (!_ret->low) \ - _ret->high--; \ - _ret->low--; \ - } \ - \ - _ret; \ -}) +/* +* Pointer '*preceding_key_p' points to a memory object to store preceding +* key of k. If the preceding key does not exist, set '*preceding_key_p' to +* NULL. So the caller of preceding_key() needs to take care of memory +* which '*preceding_key_p' pointed to before calling preceding_key(). +* Currently the only caller of preceding_key() is bch_btree_insert_key(), +* and it points to an on-stack variable, so the memory release is handled +* by stackframe itself. +*/ +static inline void preceding_key (struct bkey *k,struct bkey **preceding_key_p) +{ +if (KEY_INODE (k) ||KEY_OFFSET (k)) { + (**preceding_key_p) =KEY (KEY_INODE (k),KEY_OFFSET (k),0 ); +if (!(*preceding_key_p)->low) + (*preceding_key_p)->high--; + (*preceding_key_p)->low--; + }else { + (*preceding_key_p) =NULL ; + } +}static inline bool bch_ptr_invalid (struct btree_keys *b,const struct bkey *k) {
Greg Kroah-Hartman
maintainerPATCH 2/53 nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled
In reply to Greg Kroah-HartmanFrom: Thomas Backlund <[email protected]>
Not-entirely-upstream-sha1-but-equivalent: bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132) causes the build to fail with:
ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
This does not happend upstream as the offending code got removed in:bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the drm_legacy_mmap() call.
Also, as Sven Joachim pointed out, we need to make the check in CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done for basically all other gpu drivers, especially in upstream kernels drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421.
NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is backported as the build error affects nouveau only.
legacy contexts. (v3)")
--- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/nouveau/nouveau_ttm.c +4 -0
@@ -273,7 +273,11 @@ nouveau_ttm_mmap(struct file *filp, strustruct nouveau_drm *drm =nouveau_drm (file_priv->minor->dev); if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT )return drm_legacy_mmap (filp, vma); +#else +return -EINVAL ; +#endif return ttm_bo_mmap (filp, vma, &drm->ttm.bdev); }
Greg Kroah-Hartman
maintainerPATCH 20/53 ASoC: fsl_asrc: Fix the issue about unsupported rate
In reply to Greg Kroah-HartmanFrom: S.j. Wang <[email protected]>
commit b06c58c2a1eed571ea2a6640fdb85b7b00196b1e upstream.
When the output sample rate is [8kHz, 30kHz], the limitation of the supported ratio range is [1/24, 8]. In the driver we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding issue with divider.
output sample rate")
--- sound/soc/fsl/fsl_asrc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/fsl/fsl_asrc.c +2 -2
@@ -286,8 +286,8 @@ static int fsl_asrc_config_pair(struct freturn -EINVAL ; } -if ((outrate >8000 && outrate <30000 ) && - (outrate/inrate >24 || inrate/outrate >8 )) { +if ((outrate >=8000 && outrate <=30000 ) && + (outrate >24 * inrate || inrate >8 * outrate)) {pair_err ("exceed supported ratio range [1/24, 8] for \ inrate/outrate: %d/%d\n" , inrate, outrate);return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 21/53 drm/i915/sdvo: Implement proper HDMI audio support for SDVO
In reply to Greg Kroah-HartmanFrom: Ville Syrjälä <[email protected]>
commit d74408f528261f900dddb9778f61b5c5a7a6249c upstream.
Our SDVO audio support is pretty bogus. We can't push audio over the SDVO bus, so trying to enable audio in the SDVO control register doesn't do anything. In fact it looks like the SDVO encoder will always mix in the audio coming over HDA, and there's no (at least documented) way to disable that from our side. So HDMI audio does work currently on gen4 but only by luck really. On gen3 it got broken by the referenced commit. And what has always been missing on every platform is the ELD.
To pass the ELD to the audio driver we need to write it to magic buffer in the SDVO encoder hardware which then gets pulled out via HDA in the other end. Ie. pretty much the same thing we had for native HDMI before we started to just pass the ELD between the drivers. This sort of explains why we even have that silly hardware buffer with native HDMI.
$ cat /proc/asound/card0/eld#1.0 -monitor_present 0 -eld_valid 0 +monitor_present 1 +eld_valid 1 +monitor_name LG TV +connection_type HDMI +...
This also fixes our state readout since we can now query the SDVO encoder about the state of the "ELD valid" and "presence detect" bits. As mentioned those don't actually control whether audio gets sent over the HDMI cable, but it's the best we can do. And with the state checker appeased we can re-enable HDMI audio for gen3.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976
--- drivers/gpu/drm/i915/intel_sdvo.c | 58 ++++++++++++++++++++++++++------- drivers/gpu/drm/i915/intel_sdvo_regs.h | 3 + 2 files changed, 50 insertions(+), 11 deletions(-)
drivers/gpu/drm/i915/intel_sdvo.c +47 -11
@@ -928,6 +928,13 @@ static bool intel_sdvo_set_colorimetry(sreturn intel_sdvo_set_value (intel_sdvo,SDVO_CMD_SET_COLORIMETRY , &mode,1 ); } +static bool intel_sdvo_set_audio_state (struct intel_sdvo *intel_sdvo, +u8 audio_state) +{ +return intel_sdvo_set_value (intel_sdvo,SDVO_CMD_SET_AUDIO_STAT , + &audio_state,1 ); +} +#if 0 static void intel_sdvo_dump_hdmi_buf (struct intel_sdvo *intel_sdvo) {
@@ -1359,11 +1366,6 @@ static void intel_sdvo_pre_enable(structelse sdvox |=SDVO_PIPE_SEL (crtc->pipe); -if (crtc_state->has_audio) { -WARN_ON_ONCE (INTEL_GEN (dev_priv) <4 ); - sdvox |=SDVO_AUDIO_ENABLE ; - } -if (INTEL_GEN (dev_priv) >=4 ) {/* done in crtc_mode_set as the dpll_md reg must be written early */ } else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
@@ -1492,8 +1494,13 @@ static void intel_sdvo_get_config(structif (sdvox &HDMI_COLOR_RANGE_16_235 ) pipe_config->limited_color_range = true; -if (sdvox &SDVO_AUDIO_ENABLE ) - pipe_config->has_audio = true; +if (intel_sdvo_get_value (intel_sdvo,SDVO_CMD_GET_AUDIO_STAT , + &val,1 )) { +u8 mask =SDVO_AUDIO_ELD_VALID |SDVO_AUDIO_PRESENCE_DETECT ; + +if ((val & mask) == mask) + pipe_config->has_audio = true; + }if (intel_sdvo_get_value (intel_sdvo,SDVO_CMD_GET_ENCODE , &val,1 )) {
@@ -1506,6 +1513,32 @@ static void intel_sdvo_get_config(struct pipe_config->pixel_multiplier, encoder_pixel_multiplier); } +static void intel_sdvo_disable_audio (struct intel_sdvo *intel_sdvo) +{ +intel_sdvo_set_audio_state (intel_sdvo,0 ); +} + +static void intel_sdvo_enable_audio (struct intel_sdvo *intel_sdvo, +const struct intel_crtc_state *crtc_state, +const struct drm_connector_state *conn_state) +{ +const struct drm_display_mode *adjusted_mode = + &crtc_state->base.adjusted_mode; +struct drm_connector *connector = conn_state->connector; +u8 *eld = connector->eld; + + eld[6 ] =drm_av_sync_delay (connector, adjusted_mode) /2 ; + +intel_sdvo_set_audio_state (intel_sdvo,0 ); + +intel_sdvo_write_infoframe (intel_sdvo,SDVO_HBUF_INDEX_ELD , +SDVO_HBUF_TX_DISABLED , + eld,drm_eld_size (eld)); + +intel_sdvo_set_audio_state (intel_sdvo,SDVO_AUDIO_ELD_VALID | +SDVO_AUDIO_PRESENCE_DETECT ); +} +static void intel_disable_sdvo (struct intel_encoder *encoder,struct intel_crtc_state *old_crtc_state,struct drm_connector_state *conn_state)
@@ -1515,6 +1548,9 @@ static void intel_disable_sdvo(struct instruct intel_crtc *crtc =to_intel_crtc (encoder->base.crtc);u32 temp; +if (old_crtc_state->has_audio) +intel_sdvo_disable_audio (intel_sdvo); +intel_sdvo_set_active_outputs (intel_sdvo,0 );if (0 ) intel_sdvo_set_encoder_power_state(intel_sdvo,
@@ -1598,6 +1634,9 @@ static void intel_enable_sdvo(struct intintel_sdvo_set_encoder_power_state (intel_sdvo,DRM_MODE_DPMS_ON );intel_sdvo_set_active_outputs (intel_sdvo, intel_sdvo->attached_output); + +if (pipe_config->has_audio) +intel_sdvo_enable_audio (intel_sdvo, pipe_config, conn_state); } static enum drm_mode_status
@@ -2468,7 +2507,6 @@ static bool intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int device) {struct drm_encoder *encoder = &intel_sdvo->base.base; -struct drm_i915_private *dev_priv =to_i915 (encoder->dev);struct drm_connector *connector;struct intel_encoder *intel_encoder =to_intel_encoder (encoder);struct intel_connector *intel_connector;
@@ -2504,9 +2542,7 @@ intel_sdvo_dvi_init(struct intel_sdvo *i encoder->encoder_type =DRM_MODE_ENCODER_TMDS ; connector->connector_type =DRM_MODE_CONNECTOR_DVID ; -/* gen3 doesn't do the hdmi bits in the SDVO register */ -if (INTEL_GEN (dev_priv) >=4 && -intel_sdvo_is_hdmi_connector (intel_sdvo, device)) { +if (intel_sdvo_is_hdmi_connector (intel_sdvo, device)) { connector->connector_type =DRM_MODE_CONNECTOR_HDMIA ; intel_sdvo->is_hdmi = true; }
drivers/gpu/drm/i915/intel_sdvo_regs.h +3 -0
@@ -707,6 +707,9 @@ struct intel_sdvo_enhancements_arg {#define SDVO_CMD_GET_AUDIO_ENCRYPT_PREFER 0x90#define SDVO_CMD_SET_AUDIO_STAT 0x91#define SDVO_CMD_GET_AUDIO_STAT 0x92 +#define SDVO_AUDIO_ELD_VALID (1 << 0) +#define SDVO_AUDIO_PRESENCE_DETECT (1 << 1) +#define SDVO_AUDIO_CP_READY (1 << 2)#define SDVO_CMD_SET_HBUF_INDEX 0x93#define SDVO_HBUF_INDEX_ELD 0#define SDVO_HBUF_INDEX_AVI_IF 1
Greg Kroah-Hartman
maintainerPATCH 3/53 HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth
In reply to Greg Kroah-HartmanFrom: Jason Gerecke <[email protected]>
commit 6441fc781c344df61402be1fde582c4491fa35fa upstream.
The button numbering of the 2nd-gen Intuos Pro is not consistent between the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the center modeswitch button (BTN_8). The Bluetooth codepath, however, has the center modeswitch button as BTN_0 and the the eight ExpressKeys as BTN_1 - BTN_8. To ensure userspace button mappings do not change depending on how the tablet is connected, modify the Bluetooth codepath to report buttons in the same order as USB.
To ensure the mode switch LED continues to toggle in response to the mode switch button, the wacom_is_led_toggled function also requires a small update.
--- drivers/hid/wacom_wac.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/hid/wacom_wac.c +7 -4
@@ -1340,7 +1340,7 @@ static void wacom_intuos_pro2_bt_pad(strstruct input_dev *pad_input = wacom->pad_input;unsigned char *data = wacom->data; -int buttons = (data[282 ] <<1 ) | ((data[281 ] >>6 ) &0x01 ); +int buttons = data[282 ] | ((data[281 ] &0x40 ) <<2 );int ring = data[285 ] &0x7F ;bool ringstatus = data[285 ] &0x80 ;bool prox = buttons || ringstatus;
@@ -3650,7 +3650,7 @@ static void wacom_24hd_update_leds(strucstatic bool wacom_is_led_toggled (struct wacom *wacom,int button_count,int mask,int group) { -int button_per_group; +int group_button;/* * 21UX2 has LED group 1 to the left and LED group 0
@@ -3660,9 +3660,12 @@ static bool wacom_is_led_toggled(structif (wacom->wacom_wac.features.type ==WACOM_21UX2 ) group =1 - group; - button_per_group = button_count/wacom->led.count; + group_button = group * (button_count/wacom->led.count); -return mask & (1 << (group * button_per_group)); +if (wacom->wacom_wac.features.type ==INTUOSP2_BT ) + group_button =8 ; + +return mask & (1 << group_button); } static void wacom_update_led(struct wacom *wacom, int button_count, int mask,
Greg Kroah-Hartman
maintainerPATCH 4/53 HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary
In reply to Greg Kroah-HartmanFrom: Jason Gerecke <[email protected]>
commit 69dbdfffef20c715df9f381b2cee4e9e0a4efd93 upstream.
The Bluetooth interface of the 2nd-gen Intuos Pro batches together four independent "frames" of finger data into a single report. Each frame is essentially equivalent to a single USB report, with the up-to-10 fingers worth of information being spread across two frames. At the moment the driver only calls input_sync after processing all four frames have been processed, which can result in the driver sending multiple updates for a single slot within the same SYN_REPORT. This can confuse userspace, so modify the driver to sync more often if necessary (i.e., after reporting the state of all fingers).
--- drivers/hid/wacom_wac.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/hid/wacom_wac.c +8 -2
@@ -1328,11 +1328,17 @@ static void wacom_intuos_pro2_bt_touch(sif (wacom->num_contacts_left <=0 ) { wacom->num_contacts_left =0 ; wacom->shared->touch_down =wacom_wac_finger_count_touches (wacom); +input_sync (touch_input); } } -input_report_switch (touch_input,SW_MUTE_DEVICE , !(data[281 ] >>7 )); -input_sync (touch_input); +if (wacom->num_contacts_left ==0 ) { +// Be careful that we don't accidentally call input_sync with +// only a partial set of fingers of processed +input_report_switch (touch_input,SW_MUTE_DEVICE , !(data[281 ] >>7 )); +input_sync (touch_input); + } + }static void wacom_intuos_pro2_bt_pad (struct wacom_wac *wacom)
Greg Kroah-Hartman
maintainerPATCH 5/53 ALSA: oxfw: allow PCM capture for Stanton SCS.1m
In reply to Greg Kroah-HartmanFrom: Takashi Sakamoto <[email protected]>
commit d8fa87c368f5b4096c4746894fdcc195da285df1 upstream.
Stanton SCS.1m can transfer isochronous packet with Multi Bit Linear Audio data channels, therefore it allows software to capture PCM substream. However, ALSA oxfw driver doesn't.
This commit changes the driver to add one PCM substream for capture direction.
--- sound/firewire/oxfw/oxfw.c | 3 --- 1 file changed, 3 deletions(-)
sound/firewire/oxfw/oxfw.c +0 -3
@@ -176,9 +176,6 @@ static int detect_quirks(struct snd_oxfw oxfw->midi_input_ports =0 ; oxfw->midi_output_ports =0 ; -/* Output stream exists but no data channels are useful. */ - oxfw->has_output = false; -return snd_oxfw_scs1x_add (oxfw); }
Greg Kroah-Hartman
maintainerPATCH 6/53 ALSA: hda/realtek - Update headset mode for ALC256
In reply to Greg Kroah-HartmanFrom: Kailang Yang <[email protected]>
commit 717f43d81afc1250300479075952a0e36d74ded3 upstream.
ALC255 and ALC256 were some difference for hidden register. This update was suitable for ALC256.
--- sound/pci/hda/patch_realtek.c | 75 +++++++++++++++++++++++++++++++++--------- 1 file changed, 60 insertions(+), 15 deletions(-)
sound/pci/hda/patch_realtek.c +60 -15
@@ -3936,18 +3936,19 @@ static struct coef_fw alc225_pre_hsmode[static void alc_headset_mode_unplugged (struct hda_codec *codec) {static struct coef_fw coef0255[] = { +WRITE_COEF (0x1b ,0x0c0b ),/* LDO and MISC control */ WRITE_COEF (0x45 ,0xd089 ),/* UAJ function set to menual mode */ UPDATE_COEFEX (0x57 ,0x05 ,1 <<14 ,0 ),/* Direct Drive HP Amp control(Set to verb control)*/ WRITE_COEF (0x06 ,0x6104 ),/* Set MIC2 Vref gate with HP */ WRITE_COEFEX (0x57 ,0x03 ,0x8aa6 ),/* Direct Drive HP Amp control */ {} }; -static struct coef_fw coef0255_1[] = { -WRITE_COEF (0x1b ,0x0c0b ),/* LDO and MISC control */ - {} - };static struct coef_fw coef0256[] = {WRITE_COEF (0x1b ,0x0c4b ),/* LDO and MISC control */ +WRITE_COEF (0x45 ,0xd089 ),/* UAJ function set to menual mode */ +WRITE_COEF (0x06 ,0x6104 ),/* Set MIC2 Vref gate with HP */ +WRITE_COEFEX (0x57 ,0x03 ,0x09a3 ),/* Direct Drive HP Amp control */ +UPDATE_COEFEX (0x57 ,0x05 ,1 <<14 ,0 ),/* Direct Drive HP Amp control(Set to verb control)*/ {} };static struct coef_fw coef0233[] = {
@@ -4010,13 +4011,11 @@ static void alc_headset_mode_unplugged(sswitch (codec->core.vendor_id) {case 0x10ec0255 : -alc_process_coef_fw (codec, coef0255_1);alc_process_coef_fw (codec, coef0255);break ;case 0x10ec0236 :case 0x10ec0256 :alc_process_coef_fw (codec, coef0256); -alc_process_coef_fw (codec, coef0255);break ;case 0x10ec0234 :case 0x10ec0274 :
@@ -4066,6 +4065,12 @@ static void alc_headset_mode_mic_in(stru WRITE_COEF(0x06, 0x6100), /* Set MIC2 Vref gate to normal */ {} }; +static struct coef_fw coef0256[] = { +UPDATE_COEFEX (0x57 ,0x05 ,1 <<14 ,1 <<14 ),/* Direct Drive HP Amp control(Set to verb control)*/ +WRITE_COEFEX (0x57 ,0x03 ,0x09a3 ), +WRITE_COEF (0x06 ,0x6100 ),/* Set MIC2 Vref gate to normal */ + {} + };static struct coef_fw coef0233[] = {UPDATE_COEF (0x35 ,0 ,1 <<14 ),WRITE_COEF (0x06 ,0x2100 ),
@@ -4113,14 +4118,19 @@ static void alc_headset_mode_mic_in(stru };switch (codec->core.vendor_id) { -case 0x10ec0236 :case 0x10ec0255 : -case 0x10ec0256 :alc_write_coef_idx (codec,0x45 ,0xc489 );snd_hda_set_pin_ctl_cache (codec, hp_pin,0 );alc_process_coef_fw (codec, coef0255);snd_hda_set_pin_ctl_cache (codec, mic_pin,PIN_VREF50 );break ; +case 0x10ec0236 : +case 0x10ec0256 : +alc_write_coef_idx (codec,0x45 ,0xc489 ); +snd_hda_set_pin_ctl_cache (codec, hp_pin,0 ); +alc_process_coef_fw (codec, coef0256); +snd_hda_set_pin_ctl_cache (codec, mic_pin,PIN_VREF50 ); +break ;case 0x10ec0234 :case 0x10ec0274 :case 0x10ec0294 :
@@ -4199,6 +4209,14 @@ static void alc_headset_mode_default(str WRITE_COEF(0x49, 0x0049), {} }; +static struct coef_fw coef0256[] = { +WRITE_COEF (0x45 ,0xc489 ), +WRITE_COEFEX (0x57 ,0x03 ,0x0da3 ), +WRITE_COEF (0x49 ,0x0049 ), +UPDATE_COEFEX (0x57 ,0x05 ,1 <<14 ,0 ),/* Direct Drive HP Amp control(Set to verb control)*/ +WRITE_COEF (0x06 ,0x6100 ), + {} + };static struct coef_fw coef0233[] = {WRITE_COEF (0x06 ,0x2100 ),WRITE_COEF (0x32 ,0x4ea3 ),
@@ -4246,11 +4264,16 @@ static void alc_headset_mode_default(stralc_process_coef_fw (codec, alc225_pre_hsmode);alc_process_coef_fw (codec, coef0225);break ; -case 0x10ec0236 :case 0x10ec0255 : -case 0x10ec0256 :alc_process_coef_fw (codec, coef0255);break ; +case 0x10ec0236 : +case 0x10ec0256 : +alc_write_coef_idx (codec,0x1b ,0x0e4b ); +alc_write_coef_idx (codec,0x45 ,0xc089 ); +msleep (50 ); +alc_process_coef_fw (codec, coef0256); +break ;case 0x10ec0234 :case 0x10ec0274 :case 0x10ec0294 :
@@ -4294,8 +4317,7 @@ static void alc_headset_mode_ctia(struct };static struct coef_fw coef0256[] = {WRITE_COEF (0x45 ,0xd489 ),/* Set to CTIA type */ -WRITE_COEF (0x1b ,0x0c6b ), -WRITE_COEFEX (0x57 ,0x03 ,0x8ea6 ), +WRITE_COEF (0x1b ,0x0e6b ), {} };static struct coef_fw coef0233[] = {
@@ -4410,8 +4432,7 @@ static void alc_headset_mode_omtp(struct };static struct coef_fw coef0256[] = {WRITE_COEF (0x45 ,0xe489 ),/* Set to OMTP Type */ -WRITE_COEF (0x1b ,0x0c6b ), -WRITE_COEFEX (0x57 ,0x03 ,0x8ea6 ), +WRITE_COEF (0x1b ,0x0e6b ), {} };static struct coef_fw coef0233[] = {
@@ -4540,13 +4561,37 @@ static void alc_determine_headset_type(s };switch (codec->core.vendor_id) { -case 0x10ec0236 :case 0x10ec0255 : +alc_process_coef_fw (codec, coef0255); +msleep (300 ); + val =alc_read_coef_idx (codec,0x46 ); + is_ctia = (val &0x0070 ) ==0x0070 ; +break ; +case 0x10ec0236 :case 0x10ec0256 : +alc_write_coef_idx (codec,0x1b ,0x0e4b ); +alc_write_coef_idx (codec,0x06 ,0x6104 ); +alc_write_coefex_idx (codec,0x57 ,0x3 ,0x09a3 ); + +snd_hda_codec_write (codec,0x21 ,0 , +AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_MUTE ); +msleep (80 ); +snd_hda_codec_write (codec,0x21 ,0 , +AC_VERB_SET_PIN_WIDGET_CONTROL ,0x0 ); +alc_process_coef_fw (codec, coef0255);msleep (300 ); val =alc_read_coef_idx (codec,0x46 ); is_ctia = (val &0x0070 ) ==0x0070 ; + +alc_write_coefex_idx (codec,0x57 ,0x3 ,0x0da3 ); +alc_update_coefex_idx (codec,0x57 ,0x5 ,1 <<14 ,0 ); + +snd_hda_codec_write (codec,0x21 ,0 , +AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_OUT ); +msleep (80 ); +snd_hda_codec_write (codec,0x21 ,0 , +AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_UNMUTE );break ;case 0x10ec0234 :case 0x10ec0274 :
Greg Kroah-Hartman
maintainerPATCH 7/53 ALSA: firewire-motu: fix destruction of data for isochronous resources
In reply to Greg Kroah-HartmanFrom: Takashi Sakamoto <[email protected]>
commit 0e3fb6995bfabb23c172e8b883bf5ac57102678e upstream.
The data for isochronous resources is not destroyed in expected place. This commit fixes the bug.
--- sound/firewire/motu/motu-stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/firewire/motu/motu-stream.c +1 -1
@@ -345,7 +345,7 @@ static void destroy_stream(struct snd_mo }amdtp_stream_destroy (stream); -fw_iso_resources_free (resources); +fw_iso_resources_destroy (resources); }int snd_motu_stream_init_duplex (struct snd_motu *motu)
Greg Kroah-Hartman
maintainerPATCH 8/53 libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.
We've received a bugreport that using LPM with ST1000LM024 drives leads to system lockups. So it seems that these models are buggy in more then 1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.
--- drivers/ata/libata-core.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/ata/libata-core.c +6 -3
@@ -4472,9 +4472,12 @@ static const struct ata_blacklist_entry {"ST3320[68]13AS" ,"SD1[5-9]" ,ATA_HORKAGE_NONCQ | ATA_HORKAGE_FIRMWARE_WARN }, -/* drives which fail FPDMA_AA activation (some may freeze afterwards) */ - { "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA }, - { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA }, +/* drives which fail FPDMA_AA activation (some may freeze afterwards) +the ST disks also have LPM issues */ + { "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA | + ATA_HORKAGE_NOLPM, }, + { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA | + ATA_HORKAGE_NOLPM, }, { "VB0250EAVER", "HPG7", ATA_HORKAGE_BROKEN_FPDMA_AA },/* Blacklist entries taken from Silicon Image 3124/3132
Greg Kroah-Hartman
maintainercover 4.14.128-stable review
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.14.128-rc1
Baruch Siach <[email protected]>
rtc: pcf8523: don't return invalid date when battery is low
Andrey Ryabinin <[email protected]>
x86/kasan: Fix boot with 5-level paging and KASAN
Borislav Petkov <[email protected]>
x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback
Borislav Petkov <[email protected]>
RAS/CEC: Fix binary search function
Daniele Palmas <[email protected]>
USB: serial: option: add Telit 0x1260 and 0x1261 compositions
Jörgen Storvist <[email protected]>
USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode
Chris Packham <[email protected]>
USB: serial: pl2303: add Allied Telesis VT-Kit3
Kai-Heng Feng <[email protected]>
USB: usb-storage: Add new ID to ums-realtek
Marco Zatta <[email protected]>
USB: Fix chipmunk-like voice when using Logitech C270 for recording audio.
Douglas Anderson <[email protected]>
usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression)
Martin Schiller <[email protected]>
usb: dwc2: Fix DMA cache alignment issues
Murray McAllister <[email protected]>
drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()
Murray McAllister <[email protected]>
drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read
Christian Borntraeger <[email protected]>
KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
Paolo Bonzini <[email protected]>
KVM: x86/pmu: do not mask the value that is written to fixed PMUs
Bernd Eckstein <[email protected]>
usbnet: ipheth: fix racing condition
Kees Cook <[email protected]>
selftests/timers: Add missing fflush(stdout) calls
Qian Cai <[email protected]>
libnvdimm: Fix compilation warnings with W=1
Colin Ian King <[email protected]>
scsi: bnx2fc: fix incorrect cast to u64 on shift operation
Steffen Dirkwinkel <[email protected]>
platform/x86: pmc_atom: Add several Beckhoff Automation boards to critclk_systems DMI table
Hans de Goede <[email protected]>
platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table
Christoph Hellwig <[email protected]>
nvme: remove the ifdef around nvme_nvm_ioctl
Mark Rutland <[email protected]>
arm64/mm: Inhibit huge-vmap with ptdump
James Smart <[email protected]>
scsi: lpfc: add check for loss of ndlp when sending RRQ
YueHaibing <[email protected]>
scsi: qedi: remove set but not used variables 'cdev' and 'udev'
YueHaibing <[email protected]>
scsi: qedi: remove memset/memcpy to nfunc and use func instead
Young Xiao <[email protected]>
Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var
Vasily Gorbik <[email protected]>
s390/kasan: fix strncpy_from_user kasan checks
Takashi Iwai <[email protected]>
Revert "ALSA: seq: Protect in-kernel ioctl calls with mutex"
Takashi Iwai <[email protected]>
ALSA: seq: Fix race of get-subscription call vs port-delete ioctls
Takashi Iwai <[email protected]>
ALSA: seq: Protect in-kernel ioctl calls with mutex
Peter Zijlstra <[email protected]>
x86/uaccess, kcov: Disable stack protector
Ville Syrjälä <[email protected]>
drm/i915/sdvo: Implement proper HDMI audio support for SDVO
S.j. Wang <[email protected]>
ASoC: fsl_asrc: Fix the issue about unsupported rate
S.j. Wang <[email protected]>
ASoC: cs42xx8: Add regcache mask dirty
Tejun Heo <[email protected]>
cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css()
Coly Li <[email protected]>
bcache: fix stack corruption by PRECEDING_KEY()
Russell King <[email protected]>
i2c: acorn: fix i2c warning
Robin Murphy <[email protected]>
iommu/arm-smmu: Avoid constant zero in TLBI writes
Hans Verkuil <[email protected]>
media: v4l2-ioctl: clear fields in s_parm
Jann Horn <[email protected]>
ptrace: restore smp_rmb() in __ptrace_may_access()
Eric W. Biederman <[email protected]>
signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
Minchan Kim <[email protected]>
mm/vmscan.c: fix trying to reclaim unevictable LRU page
Wengang Wang <[email protected]>
fs/ocfs2: fix race in ocfs2_dentry_attach_lock()
Shakeel Butt <[email protected]>
mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
Hans de Goede <[email protected]>
libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
Takashi Sakamoto <[email protected]>
ALSA: firewire-motu: fix destruction of data for isochronous resources
Kailang Yang <[email protected]>
ALSA: hda/realtek - Update headset mode for ALC256
Takashi Sakamoto <[email protected]>
ALSA: oxfw: allow PCM capture for Stanton SCS.1m
Jason Gerecke <[email protected]>
HID: wacom: Sync INTUOSP2_BT touch state after each frame if necessary
Jason Gerecke <[email protected]>
HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth
Thomas Backlund <[email protected]>
nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled
Dave Airlie <[email protected]>
drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
-------------
Diffstat:
Makefile | 4 +- arch/arm64/mm/mmu.c | 11 +++- arch/s390/include/asm/uaccess.h | 2 + arch/s390/kvm/kvm-s390.c | 35 +++++++----- arch/x86/kernel/cpu/microcode/core.c | 2 +- arch/x86/kvm/pmu_intel.c | 13 +++-- arch/x86/mm/kasan_init_64.c | 2 +- drivers/ata/libata-core.c | 9 ++- drivers/gpu/drm/i915/intel_sdvo.c | 58 +++++++++++++++---- drivers/gpu/drm/i915/intel_sdvo_regs.h | 3 + drivers/gpu/drm/nouveau/Kconfig | 13 ++++- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ++ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 7 ++- drivers/hid/wacom_wac.c | 21 +++++-- drivers/i2c/busses/i2c-acorn.c | 1 + drivers/iommu/arm-smmu.c | 15 ++++- drivers/md/bcache/bset.c | 16 +++++- drivers/md/bcache/bset.h | 34 ++++++----- drivers/media/v4l2-core/v4l2-ioctl.c | 17 +++++- drivers/misc/kgdbts.c | 4 +- drivers/net/usb/ipheth.c | 3 +- drivers/nvdimm/bus.c | 4 +- drivers/nvdimm/label.c | 2 + drivers/nvdimm/label.h | 2 - drivers/nvme/host/core.c | 2 - drivers/platform/x86/pmc_atom.c | 33 +++++++++++ drivers/ras/cec.c | 34 ++++++----- drivers/rtc/rtc-pcf8523.c | 32 ++++++++--- drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +- drivers/scsi/lpfc/lpfc_els.c | 5 +- drivers/scsi/qedi/qedi_dbg.c | 32 +++-------- drivers/scsi/qedi/qedi_iscsi.c | 4 -- drivers/usb/core/quirks.c | 3 + drivers/usb/dwc2/hcd.c | 39 ++++++++----- drivers/usb/dwc2/hcd.h | 20 ++++--- drivers/usb/dwc2/hcd_intr.c | 5 +- drivers/usb/dwc2/hcd_queue.c | 10 ++-- drivers/usb/serial/option.c | 6 ++ drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 3 + drivers/usb/storage/unusual_realtek.h | 5 ++ fs/ocfs2/dcache.c | 12 ++++ include/linux/cgroup.h | 10 +++- include/linux/cpuhotplug.h | 1 + kernel/Makefile | 1 + kernel/cred.c | 9 +++ kernel/ptrace.c | 20 ++++++- mm/list_lru.c | 2 +- mm/vmscan.c | 2 +- sound/core/seq/seq_clientmgr.c | 10 +--- sound/core/seq/seq_ports.c | 13 +++-- sound/core/seq/seq_ports.h | 5 +- sound/firewire/motu/motu-stream.c | 2 +- sound/firewire/oxfw/oxfw.c | 3 - sound/pci/hda/patch_realtek.c | 75 ++++++++++++++++++++----- sound/soc/codecs/cs42xx8.c | 1 + sound/soc/fsl/fsl_asrc.c | 4 +- tools/testing/selftests/timers/adjtick.c | 1 + tools/testing/selftests/timers/leapcrash.c | 1 + tools/testing/selftests/timers/mqueue-lat.c | 1 + tools/testing/selftests/timers/nanosleep.c | 1 + tools/testing/selftests/timers/nsleep-lat.c | 1 + tools/testing/selftests/timers/raw_skew.c | 1 + tools/testing/selftests/timers/set-tai.c | 1 + tools/testing/selftests/timers/set-tz.c | 2 + tools/testing/selftests/timers/threadtest.c | 1 + tools/testing/selftests/timers/valid-adjtimex.c | 2 + 68 files changed, 503 insertions(+), 204 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 23/53 ALSA: seq: Protect in-kernel ioctl calls with mutex
[ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]
ALSA OSS sequencer calls the ioctl function indirectly via snd_seq_kernel_client_ctl(). While we already applied the protection against races between the normal ioctls and writes via the client's ioctl_mutex, this code path was left untouched. And this seems to be the cause of still remaining some rare UAF as spontaneously triggered by syzkaller.
For the sake of robustness, wrap the ioctl_mutex also for the call via snd_seq_kernel_client_ctl(), too.
--- sound/core/seq/seq_clientmgr.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
sound/core/seq/seq_clientmgr.c +7 -2
@@ -2348,14 +2348,19 @@ int snd_seq_kernel_client_ctl(int clientid, unsigned int cmd, void *arg) {const struct ioctl_handler *handler;struct snd_seq_client *client; +int err; client =clientptr (clientid);if (client ==NULL )return -ENXIO ;for (handler = ioctl_handlers; handler->cmd >0 ; ++handler) { -if (handler->cmd == cmd) -return handler->func (client, arg); +if (handler->cmd == cmd) { +mutex_lock (&client->ioctl_mutex); + err = handler->func (client, arg); +mutex_unlock (&client->ioctl_mutex); +return err; + } } pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 32/53 nvme: remove the ifdef around nvme_nvm_ioctl
In reply to Greg Kroah-Hartman[ Upstream commit 3f98bcc58cd5f1e4668db289dcab771874cc0920 ]
We already have a proper stub if lightnvm is not enabled, so don't bother with the ifdef.
--- drivers/nvme/host/core.c | 2 -- 1 file changed, 2 deletions(-)
drivers/nvme/host/core.c +0 -2
@@ -1042,10 +1042,8 @@ static int nvme_ioctl(struct block_device *bdev, fmode_t mode,case NVME_IOCTL_SUBMIT_IO :return nvme_submit_io (ns, (void __user *)arg);default : -#ifdef CONFIG_NVM if (ns->ndev)return nvme_nvm_ioctl (ns, cmd, arg); -#endif if (is_sed_ioctl (cmd))return sed_ioctl (ns->ctrl->opal_dev, cmd, (void __user *) arg);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 33/53 platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table
In reply to Greg Kroah-Hartman[ Upstream commit 3d0818f5eba80fbe4c0addbfe6ddb2d19dc82cd4 ]
The Lex 3I380D industrial PC has 4 ethernet controllers on board which need pmc_plt_clk0 - 3 to function, add it to the critclk_systems DMI table, so that drivers/clk/x86/clk-pmc-atom.c will mark the clocks as CLK_CRITICAL and they will not get turned off.
--- drivers/platform/x86/pmc_atom.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/platform/x86/pmc_atom.c +9 -0
@@ -428,12 +428,21 @@ static int pmc_dbgfs_register(struct pmc_dev *pmc)*/ static const struct dmi_system_id critclk_systems[] = { { +/* pmc_plt_clk0 is used for an external HSIC USB HUB */ .ident ="MPL CEC1x" , .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"MPL AG" ),DMI_MATCH (DMI_PRODUCT_NAME ,"CEC10 Family" ), }, }, + { +/* pmc_plt_clk0 - 3 are used for the 4 ethernet controllers */ + .ident ="Lex 3I380D" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Lex BayTrail" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"3I380D" ), + }, + }, {/*sentinel*/ } };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 34/53 platform/x86: pmc_atom: Add several Beckhoff Automation boards to critclk_systems DMI table
In reply to Greg Kroah-Hartman[ Upstream commit d6423bd03031c020121da26c41a26bd5cc6d0da3 ]
There are several Beckhoff Automation industrial PC boards which use pmc_plt_clk* clocks for ethernet controllers. This adds affected boards to critclk_systems DMI table so the clocks are marked as CLK_CRITICAL and not turned off.
--- drivers/platform/x86/pmc_atom.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/platform/x86/pmc_atom.c +24 -0
@@ -443,6 +443,30 @@ static const struct dmi_system_id critclk_systems[] = { DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"), }, }, + { + /* pmc_plt_clk* - are used for ethernet controllers */ + .ident = "Beckhoff CB3163", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"), + DMI_MATCH(DMI_BOARD_NAME, "CB3163"), + }, + }, + { + /* pmc_plt_clk* - are used for ethernet controllers */ + .ident = "Beckhoff CB6263", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"), + DMI_MATCH(DMI_BOARD_NAME, "CB6263"), + }, + }, + { + /* pmc_plt_clk* - are used for ethernet controllers */ + .ident = "Beckhoff CB6363", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"), + DMI_MATCH(DMI_BOARD_NAME, "CB6363"), + }, + }, { /*sentinel*/ } };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 35/53 scsi: bnx2fc: fix incorrect cast to u64 on shift operation
In reply to Greg Kroah-Hartman[ Upstream commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 ]
Currently an int is being shifted and the result is being cast to a u64 which leads to undefined behaviour if the shift is more than 31 bits. Fix this by casting the integer value 1 to u64 before the shift operation.
Addresses-Coverity: ("Bad shift operation")
--- drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/bnx2fc/bnx2fc_hwi.c +1 -1
@@ -830,7 +830,7 @@ ret_err_rqe: ((u64 )err_entry->data.err_warn_bitmap_hi <<32 ) | (u64 )err_entry->data.err_warn_bitmap_lo;for (i =0 ; i <BNX2FC_NUM_ERR_BITS ; i++) { -if (err_warn_bit_map & (u64) (1 << i)) { +if (err_warn_bit_map & ((u64 )1 << i)) { err_warn = i;break ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 37/53 selftests/timers: Add missing fflush(stdout) calls
In reply to Greg Kroah-Hartman[ Upstream commit fe48319243a626c860fd666ca032daacc2ba84a5 ]
When running under a pipe, some timer tests would not report output in real-time because stdout flushes were missing after printf()s that lacked a newline. This adds them to restore real-time status output that humans can enjoy.
--- tools/testing/selftests/timers/adjtick.c | 1 + tools/testing/selftests/timers/leapcrash.c | 1 + tools/testing/selftests/timers/mqueue-lat.c | 1 + tools/testing/selftests/timers/nanosleep.c | 1 + tools/testing/selftests/timers/nsleep-lat.c | 1 + tools/testing/selftests/timers/raw_skew.c | 1 + tools/testing/selftests/timers/set-tai.c | 1 + tools/testing/selftests/timers/set-tz.c | 2 ++ tools/testing/selftests/timers/threadtest.c | 1 + tools/testing/selftests/timers/valid-adjtimex.c | 2 ++ 10 files changed, 12 insertions(+)
tools/testing/selftests/timers/adjtick.c +1 -0
@@ -136,6 +136,7 @@ int check_tick_adj(long tickval) eppm =get_ppm_drift ();printf ("%lld usec, %lld ppm" , systick + (systick * eppm /MILLION ), eppm); +fflush (stdout); tx1.modes =0 ;adjtimex (&tx1);
tools/testing/selftests/timers/leapcrash.c +1 -0
@@ -101,6 +101,7 @@ int main(void) }clear_time_state ();printf ("." ); +fflush (stdout); }printf ("[OK]\n" );return ksft_exit_pass ();
tools/testing/selftests/timers/mqueue-lat.c +1 -0
@@ -102,6 +102,7 @@ int main(int argc, char **argv)int ret;printf ("Mqueue latency : " ); +fflush (stdout); ret =mqueue_lat_test ();if (ret <0 ) {
tools/testing/selftests/timers/nanosleep.c +1 -0
@@ -142,6 +142,7 @@ int main(int argc, char **argv)continue ;printf ("Nanosleep %-31s " ,clockstring (clockid)); +fflush (stdout); length =10 ;while (length <= (NSEC_PER_SEC *10 )) {
tools/testing/selftests/timers/nsleep-lat.c +1 -0
@@ -155,6 +155,7 @@ int main(int argc, char **argv)continue ;printf ("nsleep latency %-26s " ,clockstring (clockid)); +fflush (stdout); length =10 ;while (length <= (NSEC_PER_SEC *10 )) {
tools/testing/selftests/timers/raw_skew.c +1 -0
@@ -112,6 +112,7 @@ int main(int argv, char **argc)printf ("WARNING: ADJ_OFFSET in progress, this will cause inaccurate results\n" );printf ("Estimating clock drift: " ); +fflush (stdout);sleep (120 );get_monotonic_and_raw (&mon, &raw);
tools/testing/selftests/timers/set-tai.c +1 -0
@@ -55,6 +55,7 @@ int main(int argc, char **argv)printf ("tai offset started at %i\n" , ret);printf ("Checking tai offsets can be properly set: " ); +fflush (stdout);for (i =1 ; i <=60 ; i++) { ret =set_tai (i); ret =get_tai ();
tools/testing/selftests/timers/set-tz.c +2 -0
@@ -65,6 +65,7 @@ int main(int argc, char **argv)printf ("tz_minuteswest started at %i, dst at %i\n" , min, dst);printf ("Checking tz_minuteswest can be properly set: " ); +fflush (stdout);for (i =-15 *60 ; i <15 *60 ; i +=30 ) { ret =set_tz (i, dst); ret =get_tz_min ();
@@ -76,6 +77,7 @@ int main(int argc, char **argv)printf ("[OK]\n" );printf ("Checking invalid tz_minuteswest values are caught: " ); +fflush (stdout);if (!set_tz (-15 *60 -1 , dst)) {printf ("[FAILED] %i didn't return failure!\n" ,-15 *60 -1 );
tools/testing/selftests/timers/threadtest.c +1 -0
@@ -163,6 +163,7 @@ int main(int argc, char **argv)strftime (buf,255 ,"%a, %d %b %Y %T %z" ,localtime (&start));printf ("%s\n" , buf);printf ("Testing consistency with %i threads for %ld seconds: " , thread_count, runtime); +fflush (stdout);/* spawn */ for (i =0 ; i < thread_count; i++)
tools/testing/selftests/timers/valid-adjtimex.c +2 -0
@@ -123,6 +123,7 @@ int validate_freq(void)/* Set the leap second insert flag */ printf ("Testing ADJ_FREQ... " ); +fflush (stdout);for (i =0 ; i <NUM_FREQ_VALID ; i++) { tx.modes =ADJ_FREQUENCY ; tx.freq = valid_freq[i];
@@ -250,6 +251,7 @@ int set_bad_offset(long sec, long usec, int use_nano)int validate_set_offset (void ) {printf ("Testing ADJ_SETOFFSET... " ); +fflush (stdout);/* Test valid values */ if (set_offset (NSEC_PER_SEC -1 ,1 ))
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 36/53 libnvdimm: Fix compilation warnings with W=1
In reply to Greg Kroah-Hartman[ Upstream commit c01dafad77fea8d64c4fdca0a6031c980842ad65 ]
Several places (dimm_devs.c, core.c etc) include label.h but only label.c uses NSINDEX_SIGNATURE, so move its definition to label.c instead.
In file included from drivers/nvdimm/dimm_devs.c:23:drivers/nvdimm/label.h:41:19: warning: 'NSINDEX_SIGNATURE' defined but not used [-Wunused-const-variable=]
Also, some places abuse "/**" which is only reserved for the kernel-doc.
drivers/nvdimm/bus.c:648: warning: cannot understand function prototype:
'struct attribute_group nd_device_attribute_group = ' drivers/nvdimm/bus.c:677: warning: cannot understand function prototype:
'struct attribute_group nd_numa_attribute_group = '
Those are just some member assignments for the "struct attribute_group" instances and it can't be expressed in the kernel-doc.
--- drivers/nvdimm/bus.c | 4 ++-- drivers/nvdimm/label.c | 2 ++ drivers/nvdimm/label.h | 2 -- 3 files changed, 4 insertions(+), 4 deletions(-)
drivers/nvdimm/bus.c +2 -2
@@ -608,7 +608,7 @@ static struct attribute *nd_device_attributes[] = { NULL, }; -/** +/* * nd_device_attribute_group - generic attributes for all devices on an nd bus */ struct attribute_group nd_device_attribute_group = {
@@ -637,7 +637,7 @@ static umode_t nd_numa_attr_visible(struct kobject *kobj, struct attribute *a,return a->mode; } -/** +/* * nd_numa_attribute_group - NUMA attributes for all devices on an nd bus */ struct attribute_group nd_numa_attribute_group = {
drivers/nvdimm/label.c +2 -0
@@ -25,6 +25,8 @@ static guid_t nvdimm_btt2_guid;static guid_t nvdimm_pfn_guid;static guid_t nvdimm_dax_guid; +static const char NSINDEX_SIGNATURE [] ="NAMESPACE_INDEX\0" ; +static u32 best_seq (u32 a,u32 b) { a &=NSINDEX_SEQ_MASK ;
drivers/nvdimm/label.h +0 -2
@@ -38,8 +38,6 @@ enum { ND_NSINDEX_INIT = 0x1, }; -static const char NSINDEX_SIGNATURE [] ="NAMESPACE_INDEX\0" ; -/** * struct nd_namespace_index - label set superblock * @sig: NAMESPACE_INDEX\0
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 39/53 KVM: x86/pmu: do not mask the value that is written to fixed PMUs
In reply to Greg Kroah-Hartman[ Upstream commit 2924b52117b2812e9633d5ea337333299166d373 ]
According to the SDM, for MSR_IA32_PERFCTR0/1 "the lower-order 32 bits of each MSR may be written with any value, and the high-order 8 bits are sign-extended according to the value of bit 31", but the fixed counters in real hardware are limited to the width of the fixed counters ("bits beyond the width of the fixed-function counter are reserved and must be written as zeros"). Fix KVM to do the same.
--- arch/x86/kvm/pmu_intel.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
arch/x86/kvm/pmu_intel.c +8 -5
@@ -235,11 +235,14 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) }break ;default : -if ((pmc =get_gp_pmc (pmu, msr,MSR_IA32_PERFCTR0 )) || - (pmc =get_fixed_pmc (pmu, msr))) { -if (!msr_info->host_initiated) - data = (s64 )(s32 )data; - pmc->counter += data -pmc_read_counter (pmc); +if ((pmc =get_gp_pmc (pmu, msr,MSR_IA32_PERFCTR0 ))) { +if (msr_info->host_initiated) + pmc->counter = data; +else + pmc->counter = (s32 )data; +return 0 ; + }else if ((pmc =get_fixed_pmc (pmu, msr))) { + pmc->counter = data;return 0 ; }else if ((pmc =get_gp_pmc (pmu, msr,MSR_P6_EVNTSEL0 ))) {if (data == pmc->eventsel)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 40/53 KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION
In reply to Greg Kroah-Hartman[ Upstream commit 19ec166c3f39fe1d3789888a74cc95544ac266d4 ]
kselftests exposed a problem in the s390 handling for memory slots. Right now we only do proper memory slot handling for creation of new memory slots. Neither MOVE, nor DELETION are handled properly. Let us implement those.
--- arch/s390/kvm/kvm-s390.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-)
arch/s390/kvm/kvm-s390.c +21 -14
@@ -3913,21 +3913,28 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,const struct kvm_memory_slot *new, enum kvm_mr_change change) { - int rc; - -/* If the basics of the memslot do not change, we do not want -* to update the gmap. Every update causes several unnecessary -* segment translation exceptions. This is usually handled just -* fine by the normal fault handler + gmap, but it will also -* cause faults on the prefix page of running guest CPUs. -*/ -if (old->userspace_addr == mem->userspace_addr && - old->base_gfn *PAGE_SIZE == mem->guest_phys_addr && - old->npages *PAGE_SIZE == mem->memory_size) -return ; + int rc = 0; - rc =gmap_map_segment (kvm->arch.gmap, mem->userspace_addr, - mem->guest_phys_addr, mem->memory_size); +switch (change) { +case KVM_MR_DELETE : + rc =gmap_unmap_segment (kvm->arch.gmap, old->base_gfn *PAGE_SIZE , + old->npages *PAGE_SIZE ); +break ; +case KVM_MR_MOVE : + rc =gmap_unmap_segment (kvm->arch.gmap, old->base_gfn *PAGE_SIZE , + old->npages *PAGE_SIZE ); +if (rc) +break ; +/* FALLTHROUGH */ +case KVM_MR_CREATE : + rc =gmap_map_segment (kvm->arch.gmap, mem->userspace_addr, + mem->guest_phys_addr, mem->memory_size); +break ; +case KVM_MR_FLAGS_ONLY : +break ; +default : +WARN (1 ,"Unknown KVM MR CHANGE: %d\n" , change); + }if (rc)pr_warn ("failed to commit memory region\n" );return ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 41/53 drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read
In reply to Greg Kroah-HartmanFrom: Murray McAllister <[email protected]>
commit 5ed7f4b5eca11c3c69e7c8b53e4321812bc1ee1e upstream.
If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
of SVGA3D_INVALID_ID, and a shader type of SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc() when the offset is calculated.
--- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +2 -1
@@ -2495,7 +2495,8 @@ static int vmw_cmd_dx_set_shader(struct cmd =container_of (header,typeof (*cmd), header); -if (cmd->body.type >=SVGA3D_SHADERTYPE_DX10_MAX ) { +if (cmd->body.type >=SVGA3D_SHADERTYPE_DX10_MAX || + cmd->body.type <SVGA3D_SHADERTYPE_MIN ) {DRM_ERROR ("Illegal shader type %u.\n" , (unsigned ) cmd->body.type);return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 24/53 ALSA: seq: Fix race of get-subscription call vs port-delete ioctls
In reply to Greg Kroah-Hartman[ Upstream commit 2eabc5ec8ab4d4748a82050dfcb994119b983750 ]
The snd_seq_ioctl_get_subscription() retrieves the port subscriber information as a pointer, while the object isn't protected, hence it may be deleted before the actual reference. This race was spotted by syzkaller and may lead to a UAF.
The fix is simply copying the data in the lookup function that performs in the rwsem to protect against the deletion.
--- sound/core/seq/seq_clientmgr.c | 10 ++-------- sound/core/seq/seq_ports.c | 13 ++++++++----- sound/core/seq/seq_ports.h | 5 +++-- 3 files changed, 13 insertions(+), 15 deletions(-)
sound/core/seq/seq_clientmgr.c +2 -8
@@ -1904,20 +1904,14 @@ static int snd_seq_ioctl_get_subscription(struct snd_seq_client *client,int result;struct snd_seq_client *sender =NULL ;struct snd_seq_client_port *sport =NULL ; -struct snd_seq_subscribers *p; result = -EINVAL ;if ((sender =snd_seq_client_use_ptr (subs->sender.client)) ==NULL ) goto __end;if ((sport =snd_seq_port_use_ptr (sender, subs->sender.port)) ==NULL ) goto __end; - p =snd_seq_port_get_subscription (&sport->c_src, &subs->dest); -if (p) { - result =0 ; - *subs = p->info; - }else - result = -ENOENT ; - + result =snd_seq_port_get_subscription (&sport->c_src, &subs->dest, + subs); __end:if (sport)snd_seq_port_unlock (sport);
sound/core/seq/seq_ports.c +8 -5
@@ -635,20 +635,23 @@ int snd_seq_port_disconnect(struct snd_seq_client *connector,/* get matched subscriber */ -struct snd_seq_subscribers *snd_seq_port_get_subscription (struct snd_seq_port_subs_info *src_grp, -struct snd_seq_addr *dest_addr) +int snd_seq_port_get_subscription (struct snd_seq_port_subs_info *src_grp, +struct snd_seq_addr *dest_addr, +struct snd_seq_port_subscribe *subs) { -struct snd_seq_subscribers *s, *found =NULL ; +struct snd_seq_subscribers *s; +int err = -ENOENT ;down_read (&src_grp->list_mutex);list_for_each_entry (s, &src_grp->list_head, src_list) {if (addr_match (dest_addr, &s->info.dest)) { - found = s; + *subs = s->info; + err =0 ;break ; } }up_read (&src_grp->list_mutex); -return found; +return err; }/*
sound/core/seq/seq_ports.h +3 -2
@@ -135,7 +135,8 @@ int snd_seq_port_subscribe(struct snd_seq_client_port *port, struct snd_seq_port_subscribe *info);/* get matched subscriber */ -struct snd_seq_subscribers *snd_seq_port_get_subscription (struct snd_seq_port_subs_info *src_grp, -struct snd_seq_addr *dest_addr); +int snd_seq_port_get_subscription (struct snd_seq_port_subs_info *src_grp, +struct snd_seq_addr *dest_addr, +struct snd_seq_port_subscribe *subs);#endif
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 42/53 drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()
In reply to Greg Kroah-HartmanFrom: Murray McAllister <[email protected]>
commit bcd6aa7b6cbfd6f985f606c6f76046d782905820 upstream.
If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after vmw_cmd_res_check(), leading to a null pointer dereference in vmw_view_add().
--- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +4 -0
@@ -2735,6 +2735,10 @@ static int vmw_cmd_dx_view_define(structif (view_type == vmw_view_max)return -EINVAL ; cmd =container_of (header,typeof (*cmd), header); +if (unlikely (cmd->sid ==SVGA3D_INVALID_ID )) { +DRM_ERROR ("Invalid surface id.\n" ); +return -EINVAL ; + } ret =vmw_cmd_res_check (dev_priv, sw_context, vmw_res_surface, user_surface_converter, &cmd->sid, &srf_node);
Greg Kroah-Hartman
maintainerPATCH 43/53 usb: dwc2: Fix DMA cache alignment issues
In reply to Greg Kroah-HartmanFrom: Martin Schiller <[email protected]>
commit 4a4863bf2e7932e584a3a462d3c6daf891142ddc upstream.
Insert a padding between data and the stored_xfer_buffer pointer to ensure they are not on the same cache line.
Otherwise, the stored_xfer_buffer gets corrupted for IN URBs on non-cache-coherent systems. (In my case: Lantiq xRX200 MIPS)
--- drivers/usb/dwc2/hcd.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/usb/dwc2/hcd.c +7 -3
@@ -2652,8 +2652,10 @@ static void dwc2_free_dma_aligned_bufferreturn ;/* Restore urb->transfer_buffer from the end of the allocated area */ -memcpy (&stored_xfer_buffer, urb->transfer_buffer + - urb->transfer_buffer_length,sizeof (urb->transfer_buffer)); +memcpy (&stored_xfer_buffer, +PTR_ALIGN (urb->transfer_buffer + urb->transfer_buffer_length, +dma_get_cache_alignment ()), +sizeof (urb->transfer_buffer));if (usb_urb_dir_in (urb)) memcpy(stored_xfer_buffer, urb->transfer_buffer,
@@ -2680,6 +2682,7 @@ static int dwc2_alloc_dma_aligned_buffer* DMA */ kmalloc_size = urb->transfer_buffer_length + + (dma_get_cache_alignment () -1 ) +sizeof (urb->transfer_buffer); kmalloc_ptr =kmalloc (kmalloc_size, mem_flags);
@@ -2690,7 +2693,8 @@ static int dwc2_alloc_dma_aligned_buffer* Position value of original urb->transfer_buffer pointer to the end * of allocation for later referencing */ -memcpy (kmalloc_ptr + urb->transfer_buffer_length, +memcpy (PTR_ALIGN (kmalloc_ptr + urb->transfer_buffer_length, +dma_get_cache_alignment ()), &urb->transfer_buffer,sizeof (urb->transfer_buffer));if (usb_urb_dir_out (urb))
Greg Kroah-Hartman
maintainerPATCH 44/53 usb: dwc2: host: Fix wMaxPacketSize handling (fix webcam regression)
In reply to Greg Kroah-HartmanFrom: Douglas Anderson <[email protected]>
commit babd183915e91a64e976b9e8ab682bb56624df76 upstream.
In commit abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet size") the API to usb_endpoint_maxp() changed. It used to just return wMaxPacketSize but after that commit it returned wMaxPacketSize with the high bits (the multiplier) masked off. If you wanted to get the multiplier it was now up to your code to call the new usb_endpoint_maxp_mult() which was introduced in
commit 541b6fe63023 ("usb: add helper to extract bits 12:11 of wMaxPacketSize").
Prior to the API change most host drivers were updated, but no update was made to dwc2. Presumably it was assumed that dwc2 was too simplistic to use the multiplier and thus just didn't support a certain class of USB devices. However, it turns out that dwc2 did use the multiplier and many devices using it were working quite nicely. That means that many USB devices have been broken since the API change. One such device is a Logitech HD Pro Webcam C920.
Specifically, though dwc2 didn't directly call usb_endpoint_maxp(), it did call usb_maxpacket() which in turn called usb_endpoint_maxp().
Let's update dwc2 to work properly with the new API.
--- drivers/usb/dwc2/hcd.c | 29 +++++++++++++++++------------ drivers/usb/dwc2/hcd.h | 20 +++++++++++--------- drivers/usb/dwc2/hcd_intr.c | 5 +++-- drivers/usb/dwc2/hcd_queue.c | 10 ++++++---- 4 files changed, 37 insertions(+), 27 deletions(-)
drivers/usb/dwc2/hcd.c +17 -12
@@ -2779,7 +2779,7 @@ static int dwc2_assign_and_init_hc(struc chan->dev_addr =dwc2_hcd_get_dev_addr (&urb->pipe_info); chan->ep_num =dwc2_hcd_get_ep_num (&urb->pipe_info); chan->speed = qh->dev_speed; - chan->max_packet =dwc2_max_packet (qh->maxp); + chan->max_packet = qh->maxp; chan->xfer_started =0 ; chan->halt_status =DWC2_HC_XFER_NO_HALT_STATUS ;
@@ -2857,7 +2857,7 @@ static int dwc2_assign_and_init_hc(struc* This value may be modified when the transfer is started * to reflect the actual transfer length */ - chan->multi_count =dwc2_hb_mult (qh->maxp); + chan->multi_count = qh->maxp_mult;if (hsotg->params.dma_desc_enable) { chan->desc_list_addr = qh->desc_list_dma;
@@ -3956,19 +3956,21 @@ static struct dwc2_hcd_urb *dwc2_hcd_urbstatic void dwc2_hcd_urb_set_pipeinfo (struct dwc2_hsotg *hsotg,struct dwc2_hcd_urb *urb,u8 dev_addr, -u8 ep_num,u8 ep_type,u8 ep_dir,u16 mps) +u8 ep_num,u8 ep_type,u8 ep_dir, +u16 maxp,u16 maxp_mult) {if (dbg_perio () || ep_type ==USB_ENDPOINT_XFER_BULK || ep_type ==USB_ENDPOINT_XFER_CONTROL )dev_vdbg (hsotg->dev, -"addr=%d, ep_num=%d, ep_dir=%1x, ep_type=%1x, mps=%d\n" , - dev_addr, ep_num, ep_dir, ep_type, mps); +"addr=%d, ep_num=%d, ep_dir=%1x, ep_type=%1x, maxp=%d (%d mult)\n" , + dev_addr, ep_num, ep_dir, ep_type, maxp, maxp_mult); urb->pipe_info.dev_addr = dev_addr; urb->pipe_info.ep_num = ep_num; urb->pipe_info.pipe_type = ep_type; urb->pipe_info.pipe_dir = ep_dir; - urb->pipe_info.mps = mps; + urb->pipe_info.maxp = maxp; + urb->pipe_info.maxp_mult = maxp_mult; }/*
@@ -4059,8 +4061,9 @@ void dwc2_hcd_dump_state(struct dwc2_hsodwc2_hcd_is_pipe_in (&urb->pipe_info) ? "IN" : "OUT");dev_dbg (hsotg->dev, -" Max packet size: %d\n" , -dwc2_hcd_get_mps (&urb->pipe_info)); +" Max packet size: %d (%d mult)\n" , +dwc2_hcd_get_maxp (&urb->pipe_info), +dwc2_hcd_get_maxp_mult (&urb->pipe_info));dev_dbg (hsotg->dev," transfer_buffer: %p\n" , urb->buf);
@@ -4673,8 +4676,10 @@ static void dwc2_dump_urb_info(struct us }dev_vdbg (hsotg->dev," Speed: %s\n" , speed); -dev_vdbg (hsotg->dev," Max packet size: %d\n" , -usb_maxpacket (urb->dev, urb->pipe,usb_pipeout (urb->pipe))); +dev_vdbg (hsotg->dev," Max packet size: %d (%d mult)\n" , +usb_endpoint_maxp (&urb->ep->desc), +usb_endpoint_maxp_mult (&urb->ep->desc)); +dev_vdbg (hsotg->dev," Data buffer length: %d\n" , urb->transfer_buffer_length); dev_vdbg(hsotg->dev, " Transfer buffer: %p, Transfer DMA: %08lx\n",
@@ -4757,8 +4762,8 @@ static int _dwc2_hcd_urb_enqueue(structdwc2_hcd_urb_set_pipeinfo (hsotg, dwc2_urb,usb_pipedevice (urb->pipe),usb_pipeendpoint (urb->pipe), ep_type,usb_pipein (urb->pipe), -usb_maxpacket (urb->dev, urb->pipe, - !(usb_pipein (urb->pipe)))); +usb_endpoint_maxp (&ep->desc), +usb_endpoint_maxp_mult (&ep->desc)); buf = urb->transfer_buffer;
drivers/usb/dwc2/hcd.h +11 -9
@@ -170,7 +170,8 @@ struct dwc2_hcd_pipe_info {u8 ep_num;u8 pipe_type;u8 pipe_dir; -u16 mps; +u16 maxp; +u16 maxp_mult; };struct dwc2_hcd_iso_packet_desc {
@@ -263,6 +264,7 @@ struct dwc2_hs_transfer_time {* - USB_ENDPOINT_XFER_ISOC * @ep_is_in: Endpoint direction * @maxp: Value from wMaxPacketSize field of Endpoint Descriptor +* @maxp_mult: Multiplier for maxp * @dev_speed: Device speed. One of the following values: * - USB_SPEED_LOW * - USB_SPEED_FULL
@@ -335,6 +337,7 @@ struct dwc2_qh {u8 ep_type;u8 ep_is_in;u16 maxp; +u16 maxp_mult;u8 dev_speed;u8 data_toggle;u8 ping_state;
@@ -489,9 +492,14 @@ static inline u8 dwc2_hcd_get_pipe_type(return pipe->pipe_type; } -static inline u16 dwc2_hcd_get_mps (struct dwc2_hcd_pipe_info *pipe) +static inline u16 dwc2_hcd_get_maxp (struct dwc2_hcd_pipe_info *pipe) +{ +return pipe->maxp; +} + +static inline u16 dwc2_hcd_get_maxp_mult (struct dwc2_hcd_pipe_info *pipe) { -return pipe->mps; +return pipe->maxp_mult; }static inline u8 dwc2_hcd_get_dev_addr (struct dwc2_hcd_pipe_info *pipe)
@@ -606,12 +614,6 @@ static inline bool dbg_urb(struct urb *ustatic inline bool dbg_perio (void ) {return false; }#endif -/* High bandwidth multiplier as encoded in highspeed endpoint descriptors */ -#define dwc2_hb_mult (wmaxpacketsize) (1 + (((wmaxpacketsize) >> 11) & 0x03)) - -/* Packet size for any kind of endpoint descriptor */ -#define dwc2_max_packet (wmaxpacketsize) ((wmaxpacketsize) & 0x07ff) -/* * Returns true if frame1 index is greater than frame2 index. The comparison * is done modulo FRLISTEN_64_SIZE. This accounts for the rollover of the
drivers/usb/dwc2/hcd_intr.c +3 -2
@@ -1579,8 +1579,9 @@ static void dwc2_hc_ahberr_intr(struct ddev_err (hsotg->dev," Speed: %s\n" , speed); -dev_err (hsotg->dev," Max packet size: %d\n" , -dwc2_hcd_get_mps (&urb->pipe_info)); +dev_err (hsotg->dev," Max packet size: %d (mult %d)\n" , +dwc2_hcd_get_maxp (&urb->pipe_info), +dwc2_hcd_get_maxp_mult (&urb->pipe_info));dev_err (hsotg->dev," Data buffer length: %d\n" , urb->length);dev_err (hsotg->dev," Transfer buffer: %p, Transfer DMA: %08lx\n" , urb->buf, (unsigned long )urb->dma);
drivers/usb/dwc2/hcd_queue.c +6 -4
@@ -703,7 +703,7 @@ static void dwc2_hs_pmap_unschedule(strustatic int dwc2_uframe_schedule_split (struct dwc2_hsotg *hsotg,struct dwc2_qh *qh) { -int bytecount =dwc2_hb_mult (qh->maxp) *dwc2_max_packet (qh->maxp); +int bytecount = qh->maxp_mult * qh->maxp;int ls_search_slice;int err =0 ;int host_interval_in_sched;
@@ -1327,7 +1327,7 @@ static int dwc2_check_max_xfer_size(struu32 max_channel_xfer_size;int status =0 ; - max_xfer_size =dwc2_max_packet (qh->maxp) *dwc2_hb_mult (qh->maxp); + max_xfer_size = qh->maxp * qh->maxp_mult; max_channel_xfer_size = hsotg->params.max_transfer_size;if (max_xfer_size > max_channel_xfer_size) {
@@ -1460,8 +1460,9 @@ static void dwc2_qh_init(struct dwc2_hsou32 prtspd = (hprt &HPRT0_SPD_MASK ) >>HPRT0_SPD_SHIFT ;bool do_split = (prtspd ==HPRT0_SPD_HIGH_SPEED && dev_speed !=USB_SPEED_HIGH ); -int maxp =dwc2_hcd_get_mps (&urb->pipe_info); -int bytecount =dwc2_hb_mult (maxp) *dwc2_max_packet (maxp); +int maxp =dwc2_hcd_get_maxp (&urb->pipe_info); +int maxp_mult =dwc2_hcd_get_maxp_mult (&urb->pipe_info); +int bytecount = maxp_mult * maxp;char *speed, *type;/* Initialize QH */
@@ -1473,6 +1474,7 @@ static void dwc2_qh_init(struct dwc2_hso qh->data_toggle =DWC2_HC_PID_DATA0 ; qh->maxp = maxp; + qh->maxp_mult = maxp_mult;INIT_LIST_HEAD (&qh->qtd_list);INIT_LIST_HEAD (&qh->qh_list_entry);
Greg Kroah-Hartman
maintainerPATCH 45/53 USB: Fix chipmunk-like voice when using Logitech C270 for recording audio.
In reply to Greg Kroah-HartmanFrom: Marco Zatta <[email protected]>
commit bd21f0222adab64974b7d1b4b8c7ce6b23e9ea4d upstream.
This patch fixes the chipmunk-like voice that manifets randomly when using the integrated mic of the Logitech Webcam HD C270.
The issue was solved initially for this device by commit 2394d67e446b ("USB: add RESET_RESUME for webcams shown to be quirky") but it was then reintroduced by e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams"). This patch is to have the fix back.
--- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -70,6 +70,9 @@ static const struct usb_device_id usb_qu/* Cherry Stream G230 2.0 (G85-231) and 3.0 (G85-232) */ { USB_DEVICE(0x046a, 0x0023), .driver_info = USB_QUIRK_RESET_RESUME }, + /* Logitech HD Webcam C270 */ + { USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME }, + /* Logitech HD Pro Webcams C920, C920-C, C925e and C930e */ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT }, { USB_DEVICE(0x046d, 0x0841), .driver_info = USB_QUIRK_DELAY_INIT },
Greg Kroah-Hartman
maintainerPATCH 47/53 USB: serial: pl2303: add Allied Telesis VT-Kit3
In reply to Greg Kroah-HartmanFrom: Chris Packham <[email protected]>
commit c5f81656a18b271976a86724dadd8344e54de74e upstream.
This is adds the vendor and device id for the AT-VT-Kit3 which is a pl2303-based device.
--- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 3 +++ 2 files changed, 4 insertions(+)
drivers/usb/serial/pl2303.c +1 -0
@@ -109,6 +109,7 @@ static const struct usb_device_id id_tab { USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) }, { USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) }, { USB_DEVICE(SMART_VENDOR_ID, SMART_PRODUCT_ID) }, + { USB_DEVICE(AT_VENDOR_ID, AT_VTKIT3_PRODUCT_ID) }, { } /* Terminating entry */ };
drivers/usb/serial/pl2303.h +3 -0
@@ -160,3 +160,6 @@#define SMART_VENDOR_ID 0x0b8c#define SMART_PRODUCT_ID 0x2303 +/* Allied Telesis VT-Kit3 */ +#define AT_VENDOR_ID 0x0caa +#define AT_VTKIT3_PRODUCT_ID 0x3001
Greg Kroah-Hartman
maintainerPATCH 48/53 USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode
In reply to Greg Kroah-HartmanFrom: Jörgen Storvist <[email protected]>
commit 5417a7e482962952e622eabd60cd3600dd65dedf upstream.
Added IDs for Simcom SIM7500/SIM7600 series cellular module in RNDIS mode. Reserved the interface for ADB.
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9011 Rev=03.18 S: Manufacturer=SimTech, Incorporated S: Product=SimTech, Incorporated S: SerialNumber=0123456789ABCDEF C: #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=ff Driver=rndis_host I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -1775,6 +1775,8 @@ static const struct usb_device_id option { USB_DEVICE(ALINK_VENDOR_ID, SIMCOM_PRODUCT_SIM7100E), .driver_info = RSVD(5) | RSVD(6) }, { USB_DEVICE_INTERFACE_CLASS(0x1e0e, 0x9003, 0xff) }, /* Simcom SIM7500/SIM7600 MBIM mode */ + { USB_DEVICE_INTERFACE_CLASS(0x1e0e, 0x9011, 0xff), /* Simcom SIM7500/SIM7600 RNDIS mode */ + .driver_info = RSVD(7) }, { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X060S_X200), .driver_info = NCTRL(0) | NCTRL(1) | RSVD(4) }, { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D),
Greg Kroah-Hartman
maintainerPATCH 49/53 USB: serial: option: add Telit 0x1260 and 0x1261 compositions
In reply to Greg Kroah-HartmanFrom: Daniele Palmas <[email protected]>
commit f3dfd4072c3ee6e287f501a18b5718b185d6a940 upstream.
Added support for Telit LE910Cx 0x1260 and 0x1261 compositions.
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -1174,6 +1174,10 @@ static const struct usb_device_id option { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1213, 0xff) }, { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1214), .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) | RSVD(3) }, + { USB_DEVICE(TELIT_VENDOR_ID, 0x1260), + .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) }, + { USB_DEVICE(TELIT_VENDOR_ID, 0x1261), + .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) }, { USB_DEVICE(TELIT_VENDOR_ID, 0x1900), /* Telit LN940 (QMI) */ .driver_info = NCTRL(0) | RSVD(1) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1901, 0xff), /* Telit LN940 (MBIM) */
Greg Kroah-Hartman
maintainerPATCH 50/53 RAS/CEC: Fix binary search function
In reply to Greg Kroah-HartmanFrom: Borislav Petkov <[email protected]>
commit f3c74b38a55aefe1004200d15a83f109b510068c upstream.
Switch to using Donald Knuth's binary search algorithm (The Art of Computer Programming, vol. 3, section 6.2.1). This should've been done from the very beginning but the author must've been smoking something very potent at the time.
The problem with the current one was that it would return the wrong element index in certain situations:
https://lkml.kernel.org/r/CAM_iQpVd02zkVJ846cj-Fg1yUNuz6tY5q1Vpj4LrXmE06dPYYg@mail.gmail.com
and the noodling code after the loop was fishy at best.
So switch to using Knuth's binary search. The final result is much cleaner and straightforward.
--- drivers/ras/cec.c | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-)
drivers/ras/cec.c +20 -14
@@ -185,32 +185,38 @@ static void cec_timer_fn(unsigned long d*/ static int __find_elem (struct ce_array *ca,u64 pfn,unsigned int *to) { +int min =0 , max = ca->n -1 ;u64 this_pfn; -int min =0 , max = ca->n; -while (min < max) { -int tmp = (max + min) >>1 ; +while (min <= max) { +int i = (min + max) >>1 ; - this_pfn =PFN (ca->array[tmp]); + this_pfn =PFN (ca->array[i]);if (this_pfn < pfn) - min = tmp +1 ; + min = i +1 ;else if (this_pfn > pfn) - max = tmp; -else { - min = tmp; -break ; + max = i -1 ; +else if (this_pfn == pfn) { +if (to) + *to = i; + +return i; } } +/* +* When the loop terminates without finding @pfn, min has the index of +* the element slot where the new @pfn should be inserted. The loop +* terminates when min > max, which means the min index points to the +* bigger element while the max index to the smaller element, in-between +* which the new @pfn belongs to. +* +* For more details, see exercise 1, Section 6.2.1 in TAOCP, vol. 3. +*/ if (to) *to = min; - this_pfn =PFN (ca->array[min]); - -if (this_pfn == pfn) -return min; -return -ENOKEY ; }
Greg Kroah-Hartman
maintainerPATCH 51/53 x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback
In reply to Greg Kroah-HartmanFrom: Borislav Petkov <[email protected]>
commit 78f4e932f7760d965fb1569025d1576ab77557c5 upstream.
Adric Blake reported the following warning during suspend-resume:
Enabling non-boot CPUs ...
x86: Booting SMP configuration:
smpboot: Booting Node 0 Processor 1 APIC 0x2
unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0000000000000000) \
at rIP: 0xffffffff8d267924 (native_write_msr+0x4/0x20)
Call Trace: intel_set_tfa intel_pmu_cpu_starting ? x86_pmu_dead_cpu x86_pmu_starting_cpu cpuhp_invoke_callback ? _raw_spin_lock_irqsave notify_cpu_starting start_secondary secondary_startup_64 microcode: sig=0x806ea, pf=0x80, revision=0x96 microcode: updated to revision 0xb4, date = 2019-04-01 CPU1 is up
The MSR in question is MSR_TFA_RTM_FORCE_ABORT and that MSR is emulated by microcode. The log above shows that the microcode loader callback happens after the PMU restoration, leading to the conjecture that because the microcode hasn't been updated yet, that MSR is not present yet, leading to the #GP.
Add a microcode loader-specific hotplug vector which comes before the PERF vectors and thus executes earlier and makes sure the MSR is present.
--- arch/x86/kernel/cpu/microcode/core.c | 2 +- include/linux/cpuhotplug.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/core.c +1 -1
@@ -873,7 +873,7 @@ int __init microcode_init(void) goto out_ucode_group;register_syscore_ops (&mc_syscore_ops); -cpuhp_setup_state_nocalls (CPUHP_AP_ONLINE_DYN ,"x86/microcode:online" , +cpuhp_setup_state_nocalls (CPUHP_AP_MICROCODE_LOADER ,"x86/microcode:online" , mc_cpu_online, mc_cpu_down_prep);pr_info ("Microcode Update Driver: v%s." ,DRIVER_VERSION );
include/linux/cpuhotplug.h +1 -0
@@ -100,6 +100,7 @@ enum cpuhp_state {CPUHP_AP_IRQ_ARMADA_XP_STARTING ,CPUHP_AP_IRQ_BCM2836_STARTING ,CPUHP_AP_ARM_MVEBU_COHERENCY , +CPUHP_AP_MICROCODE_LOADER ,CPUHP_AP_PERF_X86_AMD_UNCORE_STARTING ,CPUHP_AP_PERF_X86_STARTING , CPUHP_AP_PERF_X86_AMD_IBS_STARTING,
Greg Kroah-Hartman
maintainerPATCH 25/53 Revert "ALSA: seq: Protect in-kernel ioctl calls with mutex"
In reply to Greg Kroah-Hartman[ Upstream commit f0654ba94e33699b295ce4f3dc73094db6209035 ]
This reverts commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32.
The fix attempt was incorrect, leading to the mutex deadlock through the close of OSS sequencer client. The proper fix needs more consideration, so let's revert it now.
--- sound/core/seq/seq_clientmgr.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
sound/core/seq/seq_clientmgr.c +2 -7
@@ -2342,19 +2342,14 @@ int snd_seq_kernel_client_ctl(int clientid, unsigned int cmd, void *arg) {const struct ioctl_handler *handler;struct snd_seq_client *client; -int err; client =clientptr (clientid);if (client ==NULL )return -ENXIO ;for (handler = ioctl_handlers; handler->cmd >0 ; ++handler) { -if (handler->cmd == cmd) { -mutex_lock (&client->ioctl_mutex); - err = handler->func (client, arg); -mutex_unlock (&client->ioctl_mutex); -return err; - } +if (handler->cmd == cmd) +return handler->func (client, arg); } pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 53/53 rtc: pcf8523: dont return invalid date when battery is low
In reply to Greg Kroah-HartmanFrom: Baruch Siach <[email protected]>
commit ecb4a353d3afd45b9bb30c85d03ee113a0589079 upstream.
The RTC_VL_READ ioctl reports the low battery condition. Still, pcf8523_rtc_read_time() happily returns invalid dates in this case. Check the battery health on pcf8523_rtc_read_time() to avoid that.
--- drivers/rtc/rtc-pcf8523.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/rtc/rtc-pcf8523.c +24 -8
@@ -82,6 +82,18 @@ static int pcf8523_write(struct i2c_cliereturn 0 ; } +static int pcf8523_voltage_low (struct i2c_client *client) +{ +u8 value; +int err; + + err =pcf8523_read (client,REG_CONTROL3 , &value); +if (err <0 ) +return err; + +return !!(value ®_CONTROL3_BLF ); +} +static int pcf8523_select_capacitance (struct i2c_client *client,bool high) {u8 value;
@@ -164,6 +176,14 @@ static int pcf8523_rtc_read_time(structstruct i2c_msg msgs[2 ];int err; + err =pcf8523_voltage_low (client); +if (err <0 ) { +return err; + }else if (err >0 ) { +dev_err (dev,"low voltage detected, time is unreliable\n" ); +return -EINVAL ; + } + msgs[0 ].addr = client->addr; msgs[0 ].flags =0 ; msgs[0 ].len =1 ;
@@ -248,17 +268,13 @@ static int pcf8523_rtc_ioctl(struct devi unsigned long arg) {struct i2c_client *client =to_i2c_client (dev); -u8 value; -int ret =0 , err; +int ret;switch (cmd) {case RTC_VL_READ : - err =pcf8523_read (client,REG_CONTROL3 , &value); -if (err <0 ) -return err; - -if (value ®_CONTROL3_BLF ) - ret =1 ; + ret =pcf8523_voltage_low (client); +if (ret <0 ) +return ret;if (copy_to_user ((void __user *)arg, &ret,sizeof (int )))return -EFAULT ;
Greg Kroah-Hartman
maintainerPATCH 26/53 s390/kasan: fix strncpy_from_user kasan checks
In reply to Greg Kroah-Hartman[ Upstream commit 01eb42afb45719cb41bb32c278e068073738899d ]
arch/s390/lib/uaccess.c is built without kasan instrumentation. Kasan checks are performed explicitly in copy_from_user/copy_to_user functions. But since those functions could be inlined, calls from files like uaccess.c with instrumentation disabled won't generate kasan reports. This is currently the case with strncpy_from_user function which was revealed by newly added kasan test. Avoid inlining of copy_from_user/copy_to_user when the kernel is built with kasan support to make sure kasan checks are fully functional.
--- arch/s390/include/asm/uaccess.h | 2 ++ 1 file changed, 2 insertions(+)
arch/s390/include/asm/uaccess.h +2 -0
@@ -67,8 +67,10 @@ raw_copy_from_user(void *to, const void __user *from, unsigned long n);unsigned long __must_check raw_copy_to_user (void __user *to,const void *from,unsigned long n); +#ifndef CONFIG_KASAN #define INLINE_COPY_FROM_USER #define INLINE_COPY_TO_USER +#endif #ifdef CONFIG_HAVE_MARCH_Z10_FEATURES
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 27/53 Drivers: misc: fix out-of-bounds access in function param_set_kgdbts_var
In reply to Greg Kroah-Hartman[ Upstream commit b281218ad4311a0342a40cb02fb17a363df08b48 ]
There is an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero.
See commit dada6a43b040 ("kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()") for details.
--- drivers/misc/kgdbts.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/misc/kgdbts.c +2 -2
@@ -1134,7 +1134,7 @@ static void kgdbts_put_char(u8 chr)static int param_set_kgdbts_var (const char *kmessage,struct kernel_param *kp) { -int len =strlen (kmessage); +size_t len =strlen (kmessage);if (len >=MAX_CONFIG_LEN ) {printk (KERN_ERR "kgdbts: config string too long\n" );
@@ -1154,7 +1154,7 @@ static int param_set_kgdbts_var(const char *kmessage, struct kernel_param *kp)strcpy (config, kmessage);/* Chop out \n char as a result of echo */ -if (config[len -1 ] =='\n' ) +if (len && config[len -1 ] =='\n' ) config[len -1 ] ='\0' ;/* Go and configure with the new params. */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 29/53 scsi: qedi: remove set but not used variables cdev and udev
In reply to Greg Kroah-Hartman[ Upstream commit d0adee5d12752256ff0c87ad7f002f21fe49d618 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/qedi/qedi_iscsi.c: In function 'qedi_ep_connect':drivers/scsi/qedi/qedi_iscsi.c:813:23: warning: variable 'udev' set but not used [-Wunused-but-set-variable] drivers/scsi/qedi/qedi_iscsi.c:812:18: warning: variable 'cdev' set but not used [-Wunused-but-set-variable]
These have never been used since introduction.
--- drivers/scsi/qedi/qedi_iscsi.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/scsi/qedi/qedi_iscsi.c +0 -4
@@ -817,8 +817,6 @@ qedi_ep_connect(struct Scsi_Host *shost, struct sockaddr *dst_addr,struct qedi_endpoint *qedi_ep;struct sockaddr_in *addr;struct sockaddr_in6 *addr6; -struct qed_dev *cdev =NULL ; -struct qedi_uio_dev *udev =NULL ;struct iscsi_path path_req;u32 msg_type =ISCSI_KEVENT_IF_DOWN ;u32 iscsi_cid =QEDI_CID_RESERVED ;
@@ -838,8 +836,6 @@ qedi_ep_connect(struct Scsi_Host *shost, struct sockaddr *dst_addr, } qedi =iscsi_host_priv (shost); - cdev = qedi->cdev; - udev = qedi->udev;if (test_bit (QEDI_IN_OFFLINE , &qedi->flags) ||test_bit (QEDI_IN_RECOVERY , &qedi->flags)) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 30/53 scsi: lpfc: add check for loss of ndlp when sending RRQ
In reply to Greg Kroah-Hartman[ Upstream commit c8cb261a072c88ca1aff0e804a30db4c7606521b ]
There was a missing qualification of a valid ndlp structure when calling to send an RRQ for an abort. Add the check.
--- drivers/scsi/lpfc/lpfc_els.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_els.c +4 -1
@@ -7065,7 +7065,10 @@ int lpfc_send_rrq(struct lpfc_hba *phba, struct lpfc_node_rrq *rrq) { struct lpfc_nodelist *ndlp = lpfc_findnode_did(rrq->vport, - rrq->nlp_DID); + rrq->nlp_DID); +if (!ndlp) +return 1 ; +if (lpfc_test_rrq_active (phba, ndlp, rrq->xritag))return lpfc_issue_els_rrq (rrq->vport, ndlp, rrq->nlp_DID, rrq);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 22/53 x86/uaccess, kcov: Disable stack protector
In reply to Greg Kroah-Hartman[ Upstream commit 40ea97290b08be2e038b31cbb33097d1145e8169 ]
New tooling noticed this mishap:
kernel/kcov.o: warning: objtool: write_comp_data()+0x138: call to __stack_chk_fail() with UACCESS enabled kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc()+0xd9: call to __stack_chk_fail() with UACCESS enabled
All the other instrumentation (KASAN,UBSAN) also have stack protector disabled.
--- kernel/Makefile | 1 + 1 file changed, 1 insertion(+)
kernel/Makefile +1 -0
@@ -30,6 +30,7 @@ KCOV_INSTRUMENT_extable.o := n # Don't self-instrument. KCOV_INSTRUMENT_kcov.o := n KASAN_SANITIZE_kcov.o := n +CFLAGS_kcov.o := $(call cc-option, -fno-conserve-stack -fno-stack-protector) # cond_syscall is currently not LTO compatible CFLAGS_sys_ni.o = $(DISABLE_LTO)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 31/53 arm64/mm: Inhibit huge-vmap with ptdump
In reply to Greg Kroah-Hartman[ Upstream commit 7ba36eccb3f83983a651efd570b4f933ecad1b5c ]
The arm64 ptdump code can race with concurrent modification of the kernel page tables. At the time this was added, this was sound as:
* Modifications to leaf entries could result in stale information being logged, but would not result in a functional problem.
* Boot time modifications to non-leaf entries (e.g. freeing of initmem) were performed when the ptdump code cannot be invoked.
* At runtime, modifications to non-leaf entries only occurred in the vmalloc region, and these were strictly additive, as intermediate entries were never freed.
However, since commit:
commit 324420bf91f6 ("arm64: add support for ioremap() block mappings")
... it has been possible to create huge mappings in the vmalloc area at runtime, and as part of this existing intermediate levels of table my be removed and freed.
It's possible for the ptdump code to race with this, and continue to walk tables which have been freed (and potentially poisoned or reallocated). As a result of this, the ptdump code may dereference bogus addresses, which could be fatal.
Since huge-vmap is a TLB and memory optimization, we can disable it when the runtime ptdump code is in use to avoid this problem.
--- arch/arm64/mm/mmu.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
arch/arm64/mm/mmu.c +8 -3
@@ -899,13 +899,18 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)int __init arch_ioremap_pud_supported (void ) { -/* only 4k granule supports level 1 block mappings */ -return IS_ENABLED (CONFIG_ARM64_4K_PAGES ); +/* +* Only 4k granule supports level 1 block mappings. +* SW table walks can't handle removal of intermediate entries. +*/ +return IS_ENABLED (CONFIG_ARM64_4K_PAGES ) && + !IS_ENABLED (CONFIG_ARM64_PTDUMP_DEBUGFS ); }int __init arch_ioremap_pmd_supported (void ) { -return 1 ; +/* See arch_ioremap_pud_supported() */ +return !IS_ENABLED (CONFIG_ARM64_PTDUMP_DEBUGFS ); }int pud_set_huge (pud_t *pud,phys_addr_t phys,pgprot_t prot)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 28/53 scsi: qedi: remove memset/memcpy to nfunc and use func instead
In reply to Greg Kroah-Hartman[ Upstream commit c09581a52765a85f19fc35340127396d5e3379cc ]
KASAN reports this:
BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi] Read of size 31 at addr ffffffffc12b0ae0 by task syz-executor.0/2429 CPU: 0 PID: 2429 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 print_address_description+0x1c4/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 memcpy+0x1f/0x50 mm/kasan/common.c:130 qedi_dbg_err+0xda/0x330 [qedi] ? 0xffffffffc12d0000 qedi_init+0x118/0x1000 [qedi] ? 0xffffffffc12d0000 ? 0xffffffffc12d0000 ? 0xffffffffc12d0000 do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2d57e55c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bfa0 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 00000000200003c0 RDI: 0000000000000003 RBP: 00007f2d57e55c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2d57e566bc R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004 The buggy address belongs to the variable: __func__.67584+0x0/0xffffffffffffd520 [qedi] Memory state around the buggy address: ffffffffc12b0980: fa fa fa fa 00 04 fa fa fa fa fa fa 00 00 05 fa ffffffffc12b0a00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 05 fa fa
Quoted 1 line
ffffffffc12b0a80: fa fa fa fa 00 06 fa fa fa fa fa fa 00 02 fa fa
^
ffffffffc12b0b00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 00 03 fa
ffffffffc12b0b80: fa fa fa fa 00 00 02 fa fa fa fa fa 00 00 04 fa
Currently the qedi_dbg_* family of functions can overrun the end of the source string if it is less than the destination buffer length because of the use of a fixed sized memcpy. Remove the memset/memcpy calls to nfunc and just use func instead as it is always a null terminated string.
--- drivers/scsi/qedi/qedi_dbg.c | 32 ++++++++------------------------ 1 file changed, 8 insertions(+), 24 deletions(-)
drivers/scsi/qedi/qedi_dbg.c +8 -24
@@ -16,10 +16,6 @@ qedi_dbg_err(struct qedi_dbg_ctx *qedi, const char *func, u32 line, {va_list va;struct va_format vaf; -char nfunc[32 ]; - -memset (nfunc,0 ,sizeof (nfunc)); -memcpy (nfunc, func,sizeof (nfunc) -1 );va_start (va, fmt);
@@ -28,9 +24,9 @@ qedi_dbg_err(struct qedi_dbg_ctx *qedi, const char *func, u32 line,if (likely (qedi) &&likely (qedi->pdev))pr_err ("[%s]:[%s:%d]:%d: %pV" ,dev_name (&qedi->pdev->dev), - nfunc, line, qedi->host_no, &vaf); + func, line, qedi->host_no, &vaf);else -pr_err ("[0000:00:00.0]:[%s:%d]: %pV" , nfunc, line, &vaf); +pr_err ("[0000:00:00.0]:[%s:%d]: %pV" , func, line, &vaf);va_end (va); }
@@ -41,10 +37,6 @@ qedi_dbg_warn(struct qedi_dbg_ctx *qedi, const char *func, u32 line, {va_list va;struct va_format vaf; -char nfunc[32 ]; - -memset (nfunc,0 ,sizeof (nfunc)); -memcpy (nfunc, func,sizeof (nfunc) -1 );va_start (va, fmt);
@@ -56,9 +48,9 @@ qedi_dbg_warn(struct qedi_dbg_ctx *qedi, const char *func, u32 line,if (likely (qedi) &&likely (qedi->pdev))pr_warn ("[%s]:[%s:%d]:%d: %pV" ,dev_name (&qedi->pdev->dev), - nfunc, line, qedi->host_no, &vaf); + func, line, qedi->host_no, &vaf);else -pr_warn ("[0000:00:00.0]:[%s:%d]: %pV" , nfunc, line, &vaf); +pr_warn ("[0000:00:00.0]:[%s:%d]: %pV" , func, line, &vaf); ret:va_end (va);
@@ -70,10 +62,6 @@ qedi_dbg_notice(struct qedi_dbg_ctx *qedi, const char *func, u32 line, {va_list va;struct va_format vaf; -char nfunc[32 ]; - -memset (nfunc,0 ,sizeof (nfunc)); -memcpy (nfunc, func,sizeof (nfunc) -1 );va_start (va, fmt);
@@ -85,10 +73,10 @@ qedi_dbg_notice(struct qedi_dbg_ctx *qedi, const char *func, u32 line,if (likely (qedi) &&likely (qedi->pdev))pr_notice ("[%s]:[%s:%d]:%d: %pV" , -dev_name (&qedi->pdev->dev), nfunc, line, +dev_name (&qedi->pdev->dev), func, line, qedi->host_no, &vaf);else -pr_notice ("[0000:00:00.0]:[%s:%d]: %pV" , nfunc, line, &vaf); +pr_notice ("[0000:00:00.0]:[%s:%d]: %pV" , func, line, &vaf); ret:va_end (va);
@@ -100,10 +88,6 @@ qedi_dbg_info(struct qedi_dbg_ctx *qedi, const char *func, u32 line, {va_list va;struct va_format vaf; -char nfunc[32 ]; - -memset (nfunc,0 ,sizeof (nfunc)); -memcpy (nfunc, func,sizeof (nfunc) -1 );va_start (va, fmt);
@@ -115,9 +99,9 @@ qedi_dbg_info(struct qedi_dbg_ctx *qedi, const char *func, u32 line,if (likely (qedi) &&likely (qedi->pdev))pr_info ("[%s]:[%s:%d]:%d: %pV" ,dev_name (&qedi->pdev->dev), - nfunc, line, qedi->host_no, &vaf); + func, line, qedi->host_no, &vaf);else -pr_info ("[0000:00:00.0]:[%s:%d]: %pV" , nfunc, line, &vaf); +pr_info ("[0000:00:00.0]:[%s:%d]: %pV" , func, line, &vaf); ret:va_end (va);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 52/53 x86/kasan: Fix boot with 5-level paging and KASAN
In reply to Greg Kroah-HartmanFrom: Andrey Ryabinin <[email protected]>
commit f3176ec9420de0c385023afa3e4970129444ac2f upstream.
Since commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") kernel doesn't boot with KASAN on 5-level paging machines. The bug is actually in early_p4d_offset() and introduced by commit 12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging")
early_p4d_offset() tries to convert pgd_val(*pgd) value to a physical address. This doesn't make sense because pgd_val() already contains the physical address.
It did work prior to commit d52888aa2753 because the result of "__pa_nodebug(pgd_val(*pgd)) & PTE_PFN_MASK" was the same as "pgd_val(*pgd) & PTE_PFN_MASK". __pa_nodebug() just set some high bits which were masked out by applying PTE_PFN_MASK.
After the change of the PAGE_OFFSET offset in commit d52888aa2753 __pa_nodebug(pgd_val(*pgd)) started to return a value with more high bits set and PTE_PFN_MASK wasn't enough to mask out all of them. So it returns a wrong not even canonical address and crashes on the attempt to dereference it.
Switch back to pgd_val() & PTE_PFN_MASK to cure the issue.
--- arch/x86/mm/kasan_init_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/mm/kasan_init_64.c +1 -1
@@ -194,7 +194,7 @@ static inline p4d_t *early_p4d_offset(pgif (!IS_ENABLED (CONFIG_X86_5LEVEL ))return (p4d_t *)pgd; - p4d =__pa_nodebug (pgd_val (*pgd)) &PTE_PFN_MASK ; + p4d =pgd_val (*pgd) &PTE_PFN_MASK ; p4d += __START_KERNEL_map - phys_base;return (p4d_t *)p4d +p4d_index (addr); }
Greg Kroah-Hartman
maintainerPATCH 46/53 USB: usb-storage: Add new ID to ums-realtek
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit 1a6dd3fea131276a4fc44ae77b0f471b0b473577 upstream.
There is one more Realtek card reader requires ums-realtek to work correctly.
Add the device ID to support it.
--- drivers/usb/storage/unusual_realtek.h | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/storage/unusual_realtek.h +5 -0
@@ -29,6 +29,11 @@ UNUSUAL_DEV(0x0bda, 0x0138, 0x0000, 0x99 "USB Card Reader", USB_SC_DEVICE, USB_PR_DEVICE, init_realtek_cr, 0), +UNUSUAL_DEV (0x0bda ,0x0153 ,0x0000 ,0x9999 , +"Realtek" , +"USB Card Reader" , +USB_SC_DEVICE ,USB_PR_DEVICE , init_realtek_cr,0 ), + UNUSUAL_DEV(0x0bda, 0x0158, 0x0000, 0x9999, "Realtek", "USB Card Reader",
Greg Kroah-Hartman
maintainerPATCH 38/53 usbnet: ipheth: fix racing condition
In reply to Greg Kroah-Hartman[ Upstream commit 94d250fae48e6f873d8362308f5c4d02cd1b1fd2 ]
Fix a racing condition in ipheth.c that can lead to slow performance.
Bug: In ipheth_tx(), netif_wake_queue() may be called on the callback ipheth_sndbulk_callback(), _before_ netif_stop_queue() is called. When this happens, the queue is stopped longer than it needs to be, thus reducing network performance.
Fix: Move netif_stop_queue() in front of usb_submit_urb(). Now the order is always correct. In case, usb_submit_urb() fails, the queue is woken up again as callback will not fire.
Testing: This racing condition is usually not noticeable, as it has to occur very frequently to slowdown the network. The callback from the USB is usually triggered slow enough, so the situation does not appear. However, on a Ubuntu Linux on VMWare Workstation, running on Windows 10, the we loose the race quite often and the following speedup can be noticed:
Without this patch: Download: 4.10 Mbit/s, Upload: 4.01 Mbit/s With this patch: Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
--- drivers/net/usb/ipheth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/usb/ipheth.c +2 -1
@@ -437,17 +437,18 @@ static int ipheth_tx(struct sk_buff *skb, struct net_device *net) dev); dev->tx_urb->transfer_flags |=URB_NO_TRANSFER_DMA_MAP ; +netif_stop_queue (net); retval =usb_submit_urb (dev->tx_urb,GFP_ATOMIC );if (retval) {dev_err (&dev->intf->dev,"%s: usb_submit_urb: %d\n" , __func__, retval); dev->net->stats.tx_errors++;dev_kfree_skb_any (skb); +netif_wake_queue (net); }else { dev->net->stats.tx_packets++; dev->net->stats.tx_bytes += skb->len;dev_consume_skb_any (skb); -netif_stop_queue (net); }return NETDEV_TX_OK ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 9/53 mm/list_lru.c: fix memory leak in __memcg_init_list_lru_node
In reply to Greg Kroah-HartmanFrom: Shakeel Butt <[email protected]>
commit 3510955b327176fd4cbab5baa75b449f077722a2 upstream.
Syzbot reported following memory leak:
ffffffffda RBX: 0000000000000003 RCX: 0000000000441f79
BUG: memory leak
unreferenced object 0xffff888114f26040 (size 32):
comm "syz-executor626", pid 7056, jiffies 4294948701 (age 39.410s)
hex dump (first 32 bytes):
40 60 f2 14 81 88 ff ff 40 60 f2 14 81 88 ff ff @`......@`......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
slab_post_alloc_hook mm/slab.h:439 [inline]
slab_alloc mm/slab.c:3326 [inline]
kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
kmalloc include/linux/slab.h:547 [inline]
__memcg_init_list_lru_node+0x58/0xf0 mm/list_lru.c:352
memcg_init_list_lru_node mm/list_lru.c:375 [inline]
memcg_init_list_lru mm/list_lru.c:459 [inline]
__list_lru_init+0x193/0x2a0 mm/list_lru.c:626
alloc_super+0x2e0/0x310 fs/super.c:269
sget_userns+0x94/0x2a0 fs/super.c:609
sget+0x8d/0xb0 fs/super.c:660
mount_nodev+0x31/0xb0 fs/super.c:1387
fuse_mount+0x2d/0x40 fs/fuse/inode.c:1236
legacy_get_tree+0x27/0x80 fs/fs_context.c:661
vfs_get_tree+0x2e/0x120 fs/super.c:1476
do_new_mount fs/namespace.c:2790 [inline]
do_mount+0x932/0xc50 fs/namespace.c:3110
ksys_mount+0xab/0x120 fs/namespace.c:3319
__do_sys_mount fs/namespace.c:3333 [inline]
__se_sys_mount fs/namespace.c:3330 [inline]
__x64_sys_mount+0x26/0x30 fs/namespace.c:3330
do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x44/0xa9This is a simple off by one bug on the error path.
--- mm/list_lru.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/list_lru.c +1 -1
@@ -313,7 +313,7 @@ static int __memcg_init_list_lru_node(st }return 0 ; fail: -__memcg_destroy_list_lru_node (memcg_lrus, begin, i -1 ); +__memcg_destroy_list_lru_node (memcg_lrus, begin, i);return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 19/53 ASoC: cs42xx8: Add regcache mask dirty
In reply to Greg Kroah-HartmanFrom: S.j. Wang <[email protected]>
commit ad6eecbfc01c987e0253371f274c3872042e4350 upstream.
Add regcache_mark_dirty before regcache_sync for power of codec may be lost at suspend, then all the register need to be reconfigured.
support for CS42448/CS42888")
--- sound/soc/codecs/cs42xx8.c | 1 + 1 file changed, 1 insertion(+)
sound/soc/codecs/cs42xx8.c +1 -0
@@ -559,6 +559,7 @@ static int cs42xx8_runtime_resume(structmsleep (5 );regcache_cache_only (cs42xx8->regmap, false); +regcache_mark_dirty (cs42xx8->regmap); ret =regcache_sync (cs42xx8->regmap);if (ret) {
Greg Kroah-Hartman
maintainerPATCH 18/53 cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css()
In reply to Greg Kroah-HartmanFrom: Tejun Heo <[email protected]>
commit 18fa84a2db0e15b02baa5d94bdb5bd509175d2f6 upstream.
A PF_EXITING task can stay associated with an offline css. If such task calls task_get_css(), it can get stuck indefinitely. This can be triggered by BSD process accounting which writes to a file with PF_EXITING set when racing against memcg disable as in the backtrace at the end.
After this change, task_get_css() may return a css which was already offline when the function was called. None of the existing users are affected by this change.
INFO: rcu_sched self-detected stall on CPU INFO: rcu_sched detected stalls on CPUs/tasks: ... NMI backtrace for cpu 0 ... Call Trace: <IRQ> dump_stack+0x46/0x68 nmi_cpu_backtrace.cold.2+0x13/0x57 nmi_trigger_cpumask_backtrace+0xba/0xca rcu_dump_cpu_stacks+0x9e/0xce rcu_check_callbacks.cold.74+0x2af/0x433 update_process_times+0x28/0x60 tick_sched_timer+0x34/0x70 __hrtimer_run_queues+0xee/0x250 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x56/0x110 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:balance_dirty_pages_ratelimited+0x28f/0x3d0 ... btrfs_file_write_iter+0x31b/0x563 __vfs_write+0xfa/0x140 __kernel_write+0x4f/0x100 do_acct_process+0x495/0x580 acct_process+0xb9/0xdb do_exit+0x748/0xa00 do_group_exit+0x3a/0xa0 get_signal+0x254/0x560 do_signal+0x23/0x5c0 exit_to_usermode_loop+0x5d/0xa0 prepare_exit_to_usermode+0x53/0x80 retint_user+0x8/0x8
--- include/linux/cgroup.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
include/linux/cgroup.h +8 -2
@@ -484,7 +484,7 @@ static inline struct cgroup_subsys_state* * Find the css for the (@task, @subsys_id) combination, increment a * reference on and return it. This function is guaranteed to return a -* valid css. +* valid css. The returned css may already have been offlined. */ static inline struct cgroup_subsys_state *task_get_css (struct task_struct *task,int subsys_id)
@@ -494,7 +494,13 @@ task_get_css(struct task_struct *task, ircu_read_lock ();while (true) { css =task_css (task, subsys_id); -if (likely (css_tryget_online (css))) +/* +* Can't use css_tryget_online() here. A task which has +* PF_EXITING set may stay associated with an offline css. +* If such task calls this function, css_tryget_online() +* will keep failing. +*/ +if (likely (css_tryget (css)))break ;cpu_relax (); }
Greg Kroah-Hartman
maintainerPATCH 16/53 i2c: acorn: fix i2c warning
In reply to Greg Kroah-HartmanFrom: Russell King <[email protected]>
commit ca21f851cc9643af049226d57fabc3c883ea648e upstream.
The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name" warning in the I2C core driver, resulting in the RTC being inaccessible. Fix this.
--- drivers/i2c/busses/i2c-acorn.c | 1 + 1 file changed, 1 insertion(+)
drivers/i2c/busses/i2c-acorn.c +1 -0
@@ -83,6 +83,7 @@ static struct i2c_algo_bit_data ioc_datastatic struct i2c_adapter ioc_ops = { .nr =0 , + .name ="ioc" , .algo_data = &ioc_data, };
Greg Kroah-Hartman
maintainerPATCH 12/53 signal/ptrace: Dont leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
In reply to Greg Kroah-Hartman[ Upstream commit f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 ]
Recently syzbot in conjunction with KMSAN reported that ptrace_peek_siginfo can copy an uninitialized siginfo to userspace. Inspecting ptrace_peek_siginfo confirms this.
The problem is that off when initialized from args.off can be initialized to a negaive value. At which point the "if (off >= 0)" test to see if off became negative fails because off started off negative.
Prevent the core problem by adding a variable found that is only true if a siginfo is found and copied to a temporary in preparation for being copied to userspace.
Prevent args.off from being truncated when being assigned to off by testing that off is <= the maximum possible value of off. Convert off to an unsigned long so that we should not have to truncate args.off, we have well defined overflow behavior so if we add another check we won't risk fighting undefined compiler behavior, and so that we have a type whose maximum value is easy to test for.
--- kernel/ptrace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
kernel/ptrace.c +8 -2
@@ -704,6 +704,10 @@ static int ptrace_peek_siginfo(struct task_struct *child,if (arg.nr <0 )return -EINVAL ; +/* Ensure arg.off fits in an unsigned long */ +if (arg.off >ULONG_MAX ) +return 0 ; +if (arg.flags &PTRACE_PEEKSIGINFO_SHARED ) pending = &child->signal->shared_pending;else
@@ -711,18 +715,20 @@ static int ptrace_peek_siginfo(struct task_struct *child,for (i =0 ; i < arg.nr; ) {siginfo_t info; -s32 off = arg.off + i; +unsigned long off = arg.off + i; +bool found = false;spin_lock_irq (&child->sighand->siglock);list_for_each_entry (q, &pending->list, list) {if (!off--) { + found = true;copy_siginfo (&info, &q->info);break ; } }spin_unlock_irq (&child->sighand->siglock); -if (off >=0 )/* beyond the end of the list */ +if (!found)/* beyond the end of the list */ break ;#ifdef CONFIG_COMPAT
Signature · 1 line
2.20.1
stable-rc/linux-4.14.y boot: 105 boots: 0 failed, 105 passed (v4.14.127-54-g1ed3ad23f285)
stable-rc/linux-4.14.y boot: 105 boots: 0 failed, 105 passed (v4.14.127-54-g1ed3ad23f285)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.127-54-g1ed3ad23f285/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.127-54-g1ed3ad23f285/
Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.127-54-g1ed3ad23f285
Git Commit: 1ed3ad23f2853e59a94e55528b42112d3e00c842
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 59 unique boards, 24 SoC families, 15 builds out of 201
---
For more info write to <[email protected]>
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
NOTE:
Backported patch media: v4l2-ioctl: clear fields in s_parm fixed v4l2-compliance test case VIDIOC_G-S_PARM
Summary
------------------------------------------------------------------------
kernel: 4.14.128-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 16102d7ed8409bff0d3b105d08bb2ca26343c539
git describe: v4.14.127-54-g16102d7ed840
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.127-54-g16102d7ed840
No regressions (compared to build v4.14.127)
Fixes (compared to build v4.14.127)
------------------------------------------------------------------------
v4l2-compliance:
* VIDIOC_G-S_PARM
Ran 22198 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-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-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
Build results:
total: 172 pass: 172 fail: 0 Qemu test results: total: 348 pass: 348 fail: 0
Guenter
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
I am still waiting on the test results for 4.14-128-rc1. The builds are all passing, but waiting for the tests to complete. We have been having some issues with our test farm this week and so the results are delayed, but should be available later today, I hope.
Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 16 lines · Jon Hunter
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 3 lines
thanks,
greg k-h
I am still waiting on the test results for 4.14-128-rc1. The builds are all passing, but waiting for the tests to complete. We have been having some issues with our test farm this week and so the results are delayed, but should be available later today, I hope.
No worries, thanks for testing all of these and letting me know.
greg k-h
Jon Hunter
maintainerQuoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Jon Hunter
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
greg k-h
I am still waiting on the test results for 4.14-128-rc1. The builds are all passing, but waiting for the tests to complete. We have been having some issues with our test farm this week and so the results are delayed, but should be available later today, I hope.
No worries, thanks for testing all of these and letting me know.
All tests passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 failLinux version: 4.14.128-rc1-g16102d7ed840
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 32 lines · Jon Hunter
Quoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Jon Hunter
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.128 release. There are 53 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 Wed 19 Jun 2019 09:06:21 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
greg k-h
I am still waiting on the test results for 4.14-128-rc1. The builds are all passing, but waiting for the tests to complete. We have been having some issues with our test farm this week and so the results are delayed, but should be available later today, I hope.
No worries, thanks for testing all of these and letting me know.
All tests passing for Tegra ...
Quoted 8 lines
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 24 tests: 24 pass, 0 failLinux version: 4.14.128-rc1-g16102d7ed840
Boards tested: tegra124-jetson-tk1, tegra20-ventana,tegra210-p2371-2180, tegra30-cardhu-a04
Great, thanks!