4.18.18-stable review
Greg Kroah-Hartman
maintainercover 4.18.18-stable review
This is the start of the stable review cycle for the 4.18.18 release. There are 34 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 Sat Nov 10 21:51:21 UTC 2018. 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.18.18-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.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.18.18-rc1
Sebastian Andrzej Siewior <[email protected]>
x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
Christoph Hellwig <[email protected]>
x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
Nathan Chancellor <[email protected]>
x86/time: Correct the attribute on jiffies' definition
Peter Zijlstra <[email protected]>
x86/percpu: Fix this_cpu_read()
Zhimin Gu <[email protected]>
x86, hibernate: Fix nosave_regions setup for hibernation
Peter Zijlstra <[email protected]>
x86/tsc: Force inlining of cyc2ns bits
Phil Auld <[email protected]>
sched/fair: Fix throttle_list starvation with low CFS quota
Boris Brezillon <[email protected]>
drm/sun4i: Fix an ulong overflow in the dotclock driver
Mikhail Nikiforov <[email protected]>
Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
Masami Hiramatsu <[email protected]>
tracing: Fix synthetic event to allow semicolon at end
Masami Hiramatsu <[email protected]>
tracing: Fix synthetic event to accept unsigned modifier
Ming Lei <[email protected]>
block: don't deal with discard limit in blkdev_issue_discard()
Alan Stern <[email protected]>
USB: fix the usbfs flag sanitization for control transfers
Heikki Krogerus <[email protected]>
usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms
Wan Ahmad Zainie <[email protected]>
usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable
Gustavo A. R. Silva <[email protected]>
usb: gadget: storage: Fix Spectre v1 vulnerability
Shuah Khan (Samsung OSG) <[email protected]>
usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
Oliver Neukum <[email protected]>
cdc-acm: fix race between reset and control messaging
Tobias Herzog <[email protected]>
cdc-acm: correct counting of UART states in serial state notification
Tobias Herzog <[email protected]>
cdc-acm: do not reset notification buffer index upon urb unlinking
Gustavo A. R. Silva <[email protected]>
IB/ucm: Fix Spectre v1 vulnerability
Gustavo A. R. Silva <[email protected]>
RDMA/ucma: Fix Spectre v1 vulnerability
Eugeniy Paltsev <[email protected]>
drm: fb-helper: Reject all pixel format changing requests
Clint Taylor <[email protected]>
drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
Kai-Heng Feng <[email protected]>
drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
Gustavo A. R. Silva <[email protected]>
ptp: fix Spectre v1 vulnerability
Eric Sandeen <[email protected]>
fscache: Fix out of bound read in long cookie keys
Al Viro <[email protected]>
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
David Howells <[email protected]>
fscache: Fix incomplete initialisation of inline key space
Chen-Yu Tsai <[email protected]>
clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting
Linus Walleij <[email protected]>
gpio: mxs: Get rid of external API call
Daniel Borkmann <[email protected]>
bpf: fix partial copy of map_ptr when dst is scalar
Amir Goldstein <[email protected]>
vfs: swap names of {do,vfs}_clone_file_range()
Alan Chiang <[email protected]>
eeprom: at24: Add support for address-width property
-------------
Diffstat:
Makefile | 4 +- arch/x86/include/asm/fpu/internal.h | 2 +- arch/x86/include/asm/percpu.h | 8 +-- arch/x86/kernel/pci-swiotlb.c | 2 - arch/x86/kernel/setup.c | 2 +- arch/x86/kernel/time.c | 2 +- arch/x86/kernel/tsc.c | 6 +- block/blk-lib.c | 28 +------- drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 10 ++- drivers/gpio/gpio-mxs.c | 4 +- drivers/gpu/drm/drm_edid.c | 5 +- drivers/gpu/drm/drm_fb_helper.c | 91 ++++++++------------------ drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++- drivers/infiniband/core/ucm.c | 3 + drivers/infiniband/core/ucma.c | 3 + drivers/input/mouse/elan_i2c_core.c | 1 + drivers/misc/eeprom/at24.c | 17 +++++ drivers/ptp/ptp_chardev.c | 4 ++ drivers/usb/class/cdc-acm.c | 16 ++--- drivers/usb/core/devio.c | 4 +- drivers/usb/gadget/function/f_mass_storage.c | 3 + drivers/usb/host/xhci-pci.c | 6 +- drivers/usb/roles/intel-xhci-usb-role-switch.c | 2 + drivers/usb/usbip/vhci_hcd.c | 57 +++++++++++----- fs/cachefiles/namei.c | 2 +- fs/fscache/cookie.c | 31 +++------ fs/fscache/internal.h | 1 - fs/fscache/main.c | 4 +- fs/ioctl.c | 2 +- fs/nfsd/vfs.c | 3 +- fs/overlayfs/copy_up.c | 2 +- fs/read_write.c | 17 ++++- include/drm/drm_edid.h | 6 +- include/linux/bpf_verifier.h | 3 + include/linux/fs.h | 17 +---- kernel/bpf/verifier.c | 10 +-- kernel/sched/fair.c | 22 ++++++- kernel/sched/sched.h | 2 + kernel/trace/trace_events_hist.c | 32 +++++++-- 39 files changed, 246 insertions(+), 200 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/34 eeprom: at24: Add support for address-width property
4.18-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit a2b3bf4846e5eed62ea6abb096af2c950961033c ]
Provide a flexible way to determine the addressing bits of eeprom. Pass the addressing bits to driver through address-width property.
--- drivers/misc/eeprom/at24.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/misc/eeprom/at24.c +17 -0
@@ -478,6 +478,23 @@ static void at24_properties_to_pdata(struct device *dev,if (device_property_present (dev,"no-read-rollover" )) chip->flags |=AT24_FLAG_NO_RDROL ; + err =device_property_read_u32 (dev,"address-width" , &val); +if (!err) { +switch (val) { +case 8 : +if (chip->flags &AT24_FLAG_ADDR16 ) +dev_warn (dev,"Override address width to be 8, while default is 16\n" ); + chip->flags &= ~AT24_FLAG_ADDR16 ; +break ; +case 16 : + chip->flags |=AT24_FLAG_ADDR16 ; +break ; +default : +dev_warn (dev,"Bad \"address-width\" property: %u\n" , + val); + } + } + err =device_property_read_u32 (dev,"size" , &val);if (!err) chip->byte_len = val;
Signature · 1 line
2.17.1
Greg Kroah-Hartman
maintainerPATCH 2/34 vfs: swap names of {do,vfs}_clone_file_range()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
commit a725356b6659469d182d662f22d770d83d3bc7b5 upstream.
Commit 031a072a0b8a ("vfs: call vfs_clone_file_range() under freeze protection") created a wrapper do_clone_file_range() around vfs_clone_file_range() moving the freeze protection to former, so overlayfs could call the latter.
The more common vfs practice is to call do_xxx helpers from vfs_xxx helpers, where freeze protecction is taken in the vfs_xxx helper, so this anomality could be a source of confusion.
It seems that commit 8ede205541ff ("ovl: add reflink/copyfile/dedup support") may have fallen a victim to this confusion - ovl_clone_file_range() calls the vfs_clone_file_range() helper in the hope of getting freeze protection on upper fs, but in fact results in overlayfs allowing to bypass upper fs freeze protection.
Swap the names of the two helpers to conform to common vfs practice and call the correct helpers from overlayfs and nfsd.
--- fs/ioctl.c | 2 +- fs/nfsd/vfs.c | 3 ++- fs/overlayfs/copy_up.c | 2 +- fs/read_write.c | 17 +++++++++++++++-- include/linux/fs.h | 17 +++-------------- 5 files changed, 22 insertions(+), 19 deletions(-)
fs/ioctl.c +1 -1
@@ -229,7 +229,7 @@ static long ioctl_file_clone(struct file *dst_file, unsigned long srcfd, ret = -EXDEV ;if (src_file.file->f_path.mnt != dst_file->f_path.mnt) goto fdput; - ret =do_clone_file_range (src_file.file, off, dst_file, destoff, olen); + ret =vfs_clone_file_range (src_file.file, off, dst_file, destoff, olen); fdput:fdput (src_file);return ret;
fs/nfsd/vfs.c +2 -1
@@ -541,7 +541,8 @@ __be32 nfsd4_set_nfs4_label(struct svc_rqst *rqstp, struct svc_fh *fhp,__be32 nfsd4_clone_file_range (struct file *src,u64 src_pos,struct file *dst,u64 dst_pos,u64 count) { -return nfserrno (do_clone_file_range (src, src_pos, dst, dst_pos, count)); +return nfserrno (vfs_clone_file_range (src, src_pos, dst, dst_pos, + count)); } ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
fs/overlayfs/copy_up.c +1 -1
@@ -156,7 +156,7 @@ static int ovl_copy_up_data(struct path *old, struct path *new, loff_t len) }/* Try to use clone_file_range to clone up within the same fs */ - error =vfs_clone_file_range (old_file,0 , new_file,0 , len); + error =do_clone_file_range (old_file,0 , new_file,0 , len);if (!error) goto out;/* Couldn't clone, so now we try to copy the data */
fs/read_write.c +15 -2
@@ -1818,8 +1818,8 @@ int vfs_clone_file_prep_inodes(struct inode *inode_in, loff_t pos_in, }EXPORT_SYMBOL (vfs_clone_file_prep_inodes); -int vfs_clone_file_range (struct file *file_in,loff_t pos_in, -struct file *file_out,loff_t pos_out,u64 len) +int do_clone_file_range (struct file *file_in,loff_t pos_in, +struct file *file_out,loff_t pos_out,u64 len) {struct inode *inode_in =file_inode (file_in);struct inode *inode_out =file_inode (file_out);
@@ -1866,6 +1866,19 @@ int vfs_clone_file_range(struct file *file_in, loff_t pos_in,return ret; } +EXPORT_SYMBOL (do_clone_file_range); + +int vfs_clone_file_range (struct file *file_in,loff_t pos_in, +struct file *file_out,loff_t pos_out,u64 len) +{ +int ret; + +file_start_write (file_out); + ret =do_clone_file_range (file_in, pos_in, file_out, pos_out, len); +file_end_write (file_out); + +return ret; +}EXPORT_SYMBOL (vfs_clone_file_range);/*
include/linux/fs.h +3 -14
@@ -1813,8 +1813,10 @@ extern ssize_t vfs_copy_file_range(struct file *, loff_t , struct file *,extern int vfs_clone_file_prep_inodes (struct inode *inode_in,loff_t pos_in,struct inode *inode_out,loff_t pos_out,u64 *len,bool is_dedupe); +extern int do_clone_file_range (struct file *file_in,loff_t pos_in, +struct file *file_out,loff_t pos_out,u64 len);extern int vfs_clone_file_range (struct file *file_in,loff_t pos_in, -struct file *file_out,loff_t pos_out,u64 len); +struct file *file_out,loff_t pos_out,u64 len);extern int vfs_dedupe_file_range_compare (struct inode *src,loff_t srcoff,struct inode *dest,loff_t destoff,loff_t len,bool *is_same);
@@ -2755,19 +2757,6 @@ static inline void file_end_write(struct file *file)__sb_end_write (file_inode (file)->i_sb,SB_FREEZE_WRITE ); } -static inline int do_clone_file_range (struct file *file_in,loff_t pos_in, -struct file *file_out,loff_t pos_out, -u64 len) -{ -int ret; - -file_start_write (file_out); - ret =vfs_clone_file_range (file_in, pos_in, file_out, pos_out, len); -file_end_write (file_out); - -return ret; -} -/* * get_write_access() gets write permission for a file. * put_write_access() releases this write permission.
Signature · 1 line
2.17.1
Greg Kroah-Hartman
maintainerPATCH 3/34 bpf: fix partial copy of map_ptr when dst is scalar
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
commit 0962590e553331db2cc0aef2dc35c57f6300dbbe upstream.
ALU operations on pointers such as scalar_reg += map_value_ptr are handled in adjust_ptr_min_max_vals(). Problem is however that map_ptr and range in the register state share a union, so transferring state through dst_reg->range = ptr_reg->range is just buggy as any new map_ptr in the dst_reg is then truncated (or null) for subsequent checks. Fix this by adding a raw member and use it for copying state over to dst_reg.
--- include/linux/bpf_verifier.h | 3 +++ kernel/bpf/verifier.c | 10 ++++++---- 2 files changed, 9 insertions(+), 4 deletions(-)
include/linux/bpf_verifier.h +3 -0
@@ -50,6 +50,9 @@ struct bpf_reg_state {* PTR_TO_MAP_VALUE_OR_NULL */ struct bpf_map *map_ptr; + +/* Max size from any of the above. */ +unsigned long raw; };/* Fixed part of pointer offset, pointer types only */ s32 off;
kernel/bpf/verifier.c +6 -4
@@ -2731,7 +2731,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, dst_reg->umax_value = umax_ptr; dst_reg->var_off = ptr_reg->var_off; dst_reg->off = ptr_reg->off + smin_val; - dst_reg->range = ptr_reg->range; + dst_reg->raw = ptr_reg->raw;break ; }/* A new variable offset is created. Note that off_reg->off
@@ -2761,10 +2761,11 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, } dst_reg->var_off =tnum_add (ptr_reg->var_off, off_reg->var_off); dst_reg->off = ptr_reg->off; + dst_reg->raw = ptr_reg->raw;if (reg_is_pkt_pointer (ptr_reg)) { dst_reg->id = ++env->id_gen;/* something was added to pkt_ptr, set range to zero */ - dst_reg->range =0 ; + dst_reg->raw =0 ; }break ;case BPF_SUB :
@@ -2793,7 +2794,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, dst_reg->var_off = ptr_reg->var_off; dst_reg->id = ptr_reg->id; dst_reg->off = ptr_reg->off - smin_val; - dst_reg->range = ptr_reg->range; + dst_reg->raw = ptr_reg->raw;break ; }/* A new variable offset is created. If the subtrahend is known
@@ -2819,11 +2820,12 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, } dst_reg->var_off =tnum_sub (ptr_reg->var_off, off_reg->var_off); dst_reg->off = ptr_reg->off; + dst_reg->raw = ptr_reg->raw;if (reg_is_pkt_pointer (ptr_reg)) { dst_reg->id = ++env->id_gen;/* something was added to pkt_ptr, set range to zero */ if (smin_val <0 ) - dst_reg->range =0 ; + dst_reg->raw =0 ; }break ;case BPF_AND :
Signature · 1 line
2.17.1
Greg Kroah-Hartman
maintainerPATCH 4/34 gpio: mxs: Get rid of external API call
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 833eacc7b5913da9896bacd30db7d490aa777868 ]
The MXS driver was calling back into the GPIO API from its irqchip. This is not very elegant, as we are a driver, let's just shortcut back into the gpio_chip .get() function instead.
This is a tricky case since the .get() callback is not in this file, instead assigned by bgpio_init(). Calling the function direcly in the gpio_chip is however the lesser evil.
--- drivers/gpio/gpio-mxs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/gpio/gpio-mxs.c +1 -3
@@ -18,8 +18,6 @@#include <linux/platform_device.h> #include <linux/slab.h> #include <linux/gpio/driver.h> -/* FIXME: for gpio_get_value(), replace this by direct register read */ -#include <linux/gpio.h> #include <linux/module.h> #define MXS_SET 0x4
@@ -86,7 +84,7 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type) port->both_edges &= ~pin_mask;switch (type) {case IRQ_TYPE_EDGE_BOTH : - val =gpio_get_value (port->gc.base + d->hwirq); + val = port->gc.get (&port->gc, d->hwirq);if (val) edge =GPIO_INT_FALL_EDGE ;else
Signature · 1 line
2.17.1
Greg Kroah-Hartman
maintainerPATCH 5/34 clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <[email protected]>
commit 80a6ec7d5e1653208eb53f6738620dab98f6f50e upstream.
The default mid-level PLL bias current setting interferes with sigma delta modulation. This manifests as decreased audio quality at lower sampling rates, which sounds like radio broadcast quality, and distortion noises at sampling rates at 48 kHz or above.
Changing the bias current settings to the lowest gets rid of the noise.
for audio PLL")
--- drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/clk/sunxi-ng/ccu-sun4i-a10.c +9 -1
@@ -1434,8 +1434,16 @@ static void __init sun4i_ccu_init(structreturn ; } -/* Force the PLL-Audio-1x divider to 1 */ val =readl (reg +SUN4I_PLL_AUDIO_REG ); + +/* +* Force VCO and PLL bias current to lowest setting. Higher +* settings interfere with sigma-delta modulation and result +* in audible noise and distortions when using SPDIF or I2S. +*/ + val &= ~GENMASK (25 ,16 ); + +/* Force the PLL-Audio-1x divider to 1 */ val &= ~GENMASK (29 ,26 );writel (val | (1 <<26 ), reg +SUN4I_PLL_AUDIO_REG );
Greg Kroah-Hartman
maintainerPATCH 6/34 fscache: Fix incomplete initialisation of inline key space
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 1ff22883b0b2f7a73eb2609ffe879c9fd96f6328 upstream.
The inline key in struct rxrpc_cookie is insufficiently initialized, zeroing only 3 of the 4 slots, therefore an index_key_len between 13 and 15 bytes will end up hashing uninitialized memory because the memcpy only partially fills the last buf[] element.
Fix this by clearing fscache_cookie objects on allocation rather than using the slab constructor to initialise them. We're going to pretty much fill in the entire struct anyway, so bringing it into our dcache writably shouldn't incur much overhead.
This removes the need to do clearance in fscache_set_key() (where we aren't doing it correctly anyway).
Also, we don't need to set cookie->key_len in fscache_set_key() as we already did it in the only caller, so remove that.
--- fs/fscache/cookie.c | 23 ++++------------------- fs/fscache/internal.h | 1 - fs/fscache/main.c | 4 +--- 3 files changed, 5 insertions(+), 23 deletions(-)
fs/fscache/cookie.c +4 -19
@@ -70,19 +70,6 @@ void fscache_free_cookie(struct fscache_ }/* -* initialise an cookie jar slab element prior to any use -*/ -void fscache_cookie_init_once (void *_cookie) -{ -struct fscache_cookie *cookie = _cookie; - -memset (cookie,0 ,sizeof (*cookie)); -spin_lock_init (&cookie->lock); -spin_lock_init (&cookie->stores_lock); -INIT_HLIST_HEAD (&cookie->backing_objects); -} - -/* * Set the index key in a cookie. The cookie struct has space for a 12-byte * key plus length and hash, but if that's not big enough, it's instead a * pointer to a buffer containing 3 bytes of hash, 1 byte of length and then
@@ -95,8 +82,6 @@ static int fscache_set_key(struct fscachu32 *buf;int i; - cookie->key_len = index_key_len; -if (index_key_len >sizeof (cookie->inline_key)) { buf =kzalloc (index_key_len,GFP_KERNEL );if (!buf)
@@ -104,9 +89,6 @@ static int fscache_set_key(struct fscach cookie->key = buf; }else { buf = (u32 *)cookie->inline_key; - buf[0 ] =0 ; - buf[1 ] =0 ; - buf[2 ] =0 ; }memcpy (buf, index_key, index_key_len);
@@ -161,7 +143,7 @@ struct fscache_cookie *fscache_alloc_coostruct fscache_cookie *cookie;/* allocate and initialise a cookie */ - cookie =kmem_cache_alloc (fscache_cookie_jar,GFP_KERNEL ); + cookie =kmem_cache_zalloc (fscache_cookie_jar,GFP_KERNEL );if (!cookie)return NULL ;
@@ -192,6 +174,9 @@ struct fscache_cookie *fscache_alloc_coo cookie->netfs_data = netfs_data; cookie->flags = (1 <<FSCACHE_COOKIE_NO_DATA_YET ); cookie->type = def->type; +spin_lock_init (&cookie->lock); +spin_lock_init (&cookie->stores_lock); +INIT_HLIST_HEAD (&cookie->backing_objects);/* radix tree insertion won't use the preallocation pool unless it's * told it may not wait */
fs/fscache/internal.h +0 -1
@@ -51,7 +51,6 @@ extern struct fscache_cache *fscache_selextern struct kmem_cache *fscache_cookie_jar;extern void fscache_free_cookie (struct fscache_cookie *); -extern void fscache_cookie_init_once (void *); extern struct fscache_cookie *fscache_alloc_cookie(struct fscache_cookie *, const struct fscache_cookie_def *, const void *, size_t,
fs/fscache/main.c +1 -3
@@ -143,9 +143,7 @@ static int __init fscache_init(void) fscache_cookie_jar =kmem_cache_create ("fscache_cookie_jar" ,sizeof (struct fscache_cookie ), -0 , -0 , - fscache_cookie_init_once); +0 ,0 ,NULL );if (!fscache_cookie_jar) {pr_notice ("Failed to allocate a cookie jar\n" ); ret = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 7/34 cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream.
the victim might've been rmdir'ed just before the lock_rename(); unlike the normal callers, we do not look the source up after the parents are locked - we know it beforehand and just recheck that it's still the child of what used to be its parent. Unfortunately, the check is too weak - we don't spot a dead directory since its ->d_parent is unchanged, dentry is positive, etc. So we sail all the way to ->rename(), with hosting filesystems _not_ expecting to be asked renaming an rmdir'ed subdirectory.
The fix is easy, fortunately - the lock on parent is sufficient for making IS_DEADDIR() on child safe.
--- fs/cachefiles/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/cachefiles/namei.c +1 -1
@@ -343,7 +343,7 @@ try_again: trap =lock_rename (cache->graveyard, dir);/* do some checks before getting the grave dentry */ -if (rep->d_parent != dir) { +if (rep->d_parent != dir ||IS_DEADDIR (d_inode (rep))) {/* the entry was probably culled when we dropped the parent dir * lock */ unlock_rename (cache->graveyard, dir);
Greg Kroah-Hartman
maintainerPATCH 8/34 fscache: Fix out of bound read in long cookie keys
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Sandeen <[email protected]>
commit fa520c47eaa15b9baa8ad66ac18da4a31679693b upstream.
fscache_set_key() can incur an out-of-bounds read, reported by KASAN:
BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x5b3/0x680 [fscache] Read of size 4 at addr ffff88084ff056d4 by task mount.nfs/32615
and also reported by syzbot at https://lkml.org/lkml/2018/7/8/236
BUG: KASAN: slab-out-of-bounds in fscache_set_key fs/fscache/cookie.c:120 [inline] BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x7a9/0x880 fs/fscache/cookie.c:171 Read of size 4 at addr ffff8801d3cc8bb4 by task syz-executor907/4466
This happens for any index_key_len which is not divisible by 4 and is larger than the size of the inline key, because the code allocates exactly index_key_len for the key buffer, but the hashing loop is stepping through it 4 bytes (u32) at a time in the buf[] array.
Fix this by calculating how many u32 buffers we'll need by using DIV_ROUND_UP, and then using kcalloc() to allocate a precleared allocation buffer to hold the index_key, then using that same count as the hashing index limit.
--- fs/fscache/cookie.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
fs/fscache/cookie.c +7 -3
@@ -70,7 +70,7 @@ void fscache_free_cookie(struct fscache_ }/* -* Set the index key in a cookie. The cookie struct has space for a 12-byte +* Set the index key in a cookie. The cookie struct has space for a 16-byte * key plus length and hash, but if that's not big enough, it's instead a * pointer to a buffer containing 3 bytes of hash, 1 byte of length and then * the key data.
@@ -80,10 +80,13 @@ static int fscache_set_key(struct fscach {unsigned long long h;u32 *buf; +int bufs;int i; + bufs =DIV_ROUND_UP (index_key_len,sizeof (*buf)); +if (index_key_len >sizeof (cookie->inline_key)) { - buf =kzalloc (index_key_len,GFP_KERNEL ); + buf =kcalloc (bufs,sizeof (*buf),GFP_KERNEL );if (!buf)return -ENOMEM ; cookie->key = buf;
@@ -98,7 +101,8 @@ static int fscache_set_key(struct fscach*/ h = (unsigned long )cookie->parent; h += index_key_len + cookie->type; -for (i =0 ; i < (index_key_len +sizeof (u32) -1 ) /sizeof (u32); i++) + +for (i =0 ; i < bufs; i++) h += buf[i]; cookie->key_hash = h ^ (h >>32 );
Greg Kroah-Hartman
maintainerPATCH 9/34 ptp: fix Spectre v1 vulnerability
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba upstream.
pin_index can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue 'ops->pin_config' [r] (local cap)
Fix this by sanitizing pin_index before using it to index ops->pin_config, and before passing it as an argument to function ptp_set_pinfunc(), in which it is used to index info->pin_config.
Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
--- drivers/ptp/ptp_chardev.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/ptp/ptp_chardev.c +4 -0
@@ -24,6 +24,8 @@#include <linux/slab.h> #include <linux/timekeeping.h> +#include <linux/nospec.h> +#include "ptp_private.h" static int ptp_disable_pinfunc(struct ptp_clock_info *ops,
@@ -248,6 +250,7 @@ long ptp_ioctl(struct posix_clock *pc, u err = -EINVAL ;break ; } + pin_index =array_index_nospec (pin_index, ops->n_pins);if (mutex_lock_interruptible (&ptp->pincfg_mux))return -ERESTARTSYS ; pd = ops->pin_config[pin_index];
@@ -266,6 +269,7 @@ long ptp_ioctl(struct posix_clock *pc, u err = -EINVAL ;break ; } + pin_index =array_index_nospec (pin_index, ops->n_pins);if (mutex_lock_interruptible (&ptp->pincfg_mux))return -ERESTARTSYS ; err =ptp_set_pinfunc (ptp, pin_index, pd.func, pd.chan);
Greg Kroah-Hartman
maintainerPATCH 10/34 drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
commit 0711a43b6d84ff9189adfbf83c8bbf56eef794bf upstream.
There's another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc instead of 8 bpc.
Apply 6 bpc quirk for the panel to fix it.
--- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/drm_edid.c +3 -0
@@ -113,6 +113,9 @@ static const struct edid_quirk {/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */ { "AEO", 0, EDID_QUIRK_FORCE_6BPC }, +/* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc panel */ + { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC }, +/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */ { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
Greg Kroah-Hartman
maintainerPATCH 11/34 drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clint Taylor <[email protected]>
commit 9068e02f58740778d8270840657f1e250a2cc60f upstream.
HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct definitions in the header for the mask to work correctly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
--- drivers/gpu/drm/drm_edid.c | 2 +- include/drm/drm_edid.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/drm_edid.c +1 -1
@@ -4282,7 +4282,7 @@ static void drm_parse_ycbcr420_deep_colostruct drm_hdmi_info *hdmi = &connector->display_info.hdmi; dc_mask = db[7 ] &DRM_EDID_YCBCR420_DC_MASK ; - hdmi->y420_dc_modes |= dc_mask; + hdmi->y420_dc_modes = dc_mask; } static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
include/drm/drm_edid.h +3 -3
@@ -214,9 +214,9 @@ struct detailed_timing {#define DRM_EDID_HDMI_DC_Y444 (1 << 3)/* YCBCR 420 deep color modes */ -#define DRM_EDID_YCBCR420_DC_48 (1 << 6) -#define DRM_EDID_YCBCR420_DC_36 (1 << 5) -#define DRM_EDID_YCBCR420_DC_30 (1 << 4) +#define DRM_EDID_YCBCR420_DC_48 (1 << 2) +#define DRM_EDID_YCBCR420_DC_36 (1 << 1) +#define DRM_EDID_YCBCR420_DC_30 (1 << 0)#define DRM_EDID_YCBCR420_DC_MASK (DRM_EDID_YCBCR420_DC_48 | \ DRM_EDID_YCBCR420_DC_36 | \ DRM_EDID_YCBCR420_DC_30)
Greg Kroah-Hartman
maintainerPATCH 12/34 drm: fb-helper: Reject all pixel format changing requests
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eugeniy Paltsev <[email protected]>
commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream.
drm fbdev emulation doesn't support changing the pixel format at all, so reject all pixel format changing requests.
--- drivers/gpu/drm/drm_fb_helper.c | 91 +++++++++++----------------------------- 1 file changed, 26 insertions(+), 65 deletions(-)
drivers/gpu/drm/drm_fb_helper.c +26 -65
@@ -1561,6 +1561,25 @@ unlock: }EXPORT_SYMBOL (drm_fb_helper_ioctl); +static bool drm_fb_pixel_format_equal (const struct fb_var_screeninfo *var_1, +const struct fb_var_screeninfo *var_2) +{ +return var_1->bits_per_pixel == var_2->bits_per_pixel && + var_1->grayscale == var_2->grayscale && + var_1->red.offset == var_2->red.offset && + var_1->red.length == var_2->red.length && + var_1->red.msb_right == var_2->red.msb_right && + var_1->green.offset == var_2->green.offset && + var_1->green.length == var_2->green.length && + var_1->green.msb_right == var_2->green.msb_right && + var_1->blue.offset == var_2->blue.offset && + var_1->blue.length == var_2->blue.length && + var_1->blue.msb_right == var_2->blue.msb_right && + var_1->transp.offset == var_2->transp.offset && + var_1->transp.length == var_2->transp.length && + var_1->transp.msb_right == var_2->transp.msb_right; +} +/** * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var * @var: screeninfo to check
@@ -1571,7 +1590,6 @@ int drm_fb_helper_check_var(struct fb_va {struct drm_fb_helper *fb_helper = info->par;struct drm_framebuffer *fb = fb_helper->fb; -int depth;if (var->pixclock !=0 ||in_dbg_master ())return -EINVAL ;
@@ -1591,72 +1609,15 @@ int drm_fb_helper_check_var(struct fb_vareturn -EINVAL ; } -switch (var->bits_per_pixel) { -case 16 : - depth = (var->green.length ==6 ) ?16 :15 ; -break ; -case 32 : - depth = (var->transp.length >0 ) ?32 :24 ; -break ; -default : - depth = var->bits_per_pixel; -break ; - } - -switch (depth) { -case 8 : - var->red.offset =0 ; - var->green.offset =0 ; - var->blue.offset =0 ; - var->red.length =8 ; - var->green.length =8 ; - var->blue.length =8 ; - var->transp.length =0 ; - var->transp.offset =0 ; -break ; -case 15 : - var->red.offset =10 ; - var->green.offset =5 ; - var->blue.offset =0 ; - var->red.length =5 ; - var->green.length =5 ; - var->blue.length =5 ; - var->transp.length =1 ; - var->transp.offset =15 ; -break ; -case 16 : - var->red.offset =11 ; - var->green.offset =5 ; - var->blue.offset =0 ; - var->red.length =5 ; - var->green.length =6 ; - var->blue.length =5 ; - var->transp.length =0 ; - var->transp.offset =0 ; -break ; -case 24 : - var->red.offset =16 ; - var->green.offset =8 ; - var->blue.offset =0 ; - var->red.length =8 ; - var->green.length =8 ; - var->blue.length =8 ; - var->transp.length =0 ; - var->transp.offset =0 ; -break ; -case 32 : - var->red.offset =16 ; - var->green.offset =8 ; - var->blue.offset =0 ; - var->red.length =8 ; - var->green.length =8 ; - var->blue.length =8 ; - var->transp.length =8 ; - var->transp.offset =24 ; -break ; -default : +/* +* drm fbdev emulation doesn't support changing the pixel format at all, +* so reject all pixel format changing requests. +*/ +if (!drm_fb_pixel_format_equal (var, &info->var)) { +DRM_DEBUG ("fbdev emulation doesn't support changing the pixel format\n" );return -EINVAL ; } +return 0 ; }EXPORT_SYMBOL (drm_fb_helper_check_var);
Greg Kroah-Hartman
maintainerPATCH 13/34 RDMA/ucma: Fix Spectre v1 vulnerability
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit a3671a4f973ee9d9621d60166cc3b037c397d604 upstream.
hdr.cmd can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/infiniband/core/ucma.c:1686 ucma_write() warn: potential spectre issue 'ucma_cmd_table' [r] (local cap)
Fix this by sanitizing hdr.cmd before using it to index ucm_cmd_table.
Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
--- drivers/infiniband/core/ucma.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/infiniband/core/ucma.c +3 -0
@@ -44,6 +44,8 @@#include <linux/module.h> #include <linux/nsproxy.h> +#include <linux/nospec.h> +#include <rdma/rdma_user_cm.h> #include <rdma/ib_marshall.h> #include <rdma/rdma_cm.h>
@@ -1676,6 +1678,7 @@ static ssize_t ucma_write(struct file *fif (hdr.cmd >=ARRAY_SIZE (ucma_cmd_table))return -EINVAL ; + hdr.cmd =array_index_nospec (hdr.cmd,ARRAY_SIZE (ucma_cmd_table));if (hdr.in +sizeof (hdr) > len)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 14/34 IB/ucm: Fix Spectre v1 vulnerability
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit 0295e39595e1146522f2722715dba7f7fba42217 upstream.
hdr.cmd can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/infiniband/core/ucm.c:1127 ib_ucm_write() warn: potential spectre issue 'ucm_cmd_table' [r] (local cap)
Fix this by sanitizing hdr.cmd before using it to index ucm_cmd_table.
Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
--- drivers/infiniband/core/ucm.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/infiniband/core/ucm.c +3 -0
@@ -46,6 +46,8 @@#include <linux/mutex.h> #include <linux/slab.h> +#include <linux/nospec.h> +#include <linux/uaccess.h> #include <rdma/ib.h>
@@ -1123,6 +1125,7 @@ static ssize_t ib_ucm_write(struct fileif (hdr.cmd >=ARRAY_SIZE (ucm_cmd_table))return -EINVAL ; + hdr.cmd =array_index_nospec (hdr.cmd,ARRAY_SIZE (ucm_cmd_table));if (hdr.in +sizeof (hdr) > len)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 15/34 cdc-acm: do not reset notification buffer index upon urb unlinking
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tobias Herzog <[email protected]>
commit dae3ddba36f8c337fb59cef07d564da6fc9b7551 upstream.
Resetting the write index of the notification buffer on urb unlink (e.g. closing a cdc-acm device from userspace) may lead to wrong interpretation of further received notifications, in case the index is not 0 when urb unlink happens (i.e. when parts of a notification already have been transferred). On the device side there is no "reset" of the notification transimission and thus we would get out of sync with the device.
--- drivers/usb/class/cdc-acm.c | 1 - 1 file changed, 1 deletion(-)
drivers/usb/class/cdc-acm.c +0 -1
@@ -354,7 +354,6 @@ static void acm_ctrl_irq(struct urb *urbcase -ENOENT :case -ESHUTDOWN :/* this urb is terminated, clean up */ - acm->nb_index =0 ;dev_dbg (&acm->control->dev,"%s - urb shutting down with status: %d\n" , __func__, status);
Greg Kroah-Hartman
maintainerPATCH 16/34 cdc-acm: correct counting of UART states in serial state notification
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tobias Herzog <[email protected]>
commit f976d0e5747ca65ccd0fb2a4118b193d70aa1836 upstream.
The usb standard ("Universal Serial Bus Class Definitions for Communication Devices") distiguishes between "consistent signals" (DSR, DCD), and "irregular signals" (break, ring, parity error, framing error, overrun). The bits of "irregular signals" are set, if this error/event occurred on the device side and are immeadeatly unset, if the serial state notification was sent.
Like other drivers of real serial ports do, just the occurence of those events should be counted in serial_icounter_struct (but no 1->0 transitions).
--- drivers/usb/class/cdc-acm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/usb/class/cdc-acm.c +7 -7
@@ -309,17 +309,17 @@ static void acm_process_notification(strif (difference &ACM_CTRL_DSR ) acm->iocount.dsr++; -if (difference &ACM_CTRL_BRK ) - acm->iocount.brk++; -if (difference &ACM_CTRL_RI ) - acm->iocount.rng++;if (difference &ACM_CTRL_DCD ) acm->iocount.dcd++; -if (difference &ACM_CTRL_FRAMING ) +if (newctrl &ACM_CTRL_BRK ) + acm->iocount.brk++; +if (newctrl &ACM_CTRL_RI ) + acm->iocount.rng++; +if (newctrl &ACM_CTRL_FRAMING ) acm->iocount.frame++; -if (difference &ACM_CTRL_PARITY ) +if (newctrl &ACM_CTRL_PARITY ) acm->iocount.parity++; -if (difference &ACM_CTRL_OVERRUN ) +if (newctrl &ACM_CTRL_OVERRUN ) acm->iocount.overrun++;spin_unlock (&acm->read_lock);
Greg Kroah-Hartman
maintainerPATCH 17/34 cdc-acm: fix race between reset and control messaging
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 9397940ed812b942c520e0c25ed4b2c64d57e8b9 upstream.
If a device splits up a control message and a reset() happens between the parts, the message is lost and already recieved parts must be dropped.
--- drivers/usb/class/cdc-acm.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/class/cdc-acm.c +1 -0
@@ -1641,6 +1641,7 @@ static int acm_pre_reset(struct usb_intestruct acm *acm =usb_get_intfdata (intf);clear_bit (EVENT_RX_STALL , &acm->flags); + acm->nb_index =0 ;/* pending control transfers are lost */ return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 18/34 usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuah Khan (Samsung OSG) <[email protected]>
commit 81f7567c51ad97668d1c3a48e8ecc482e64d4161 upstream.
vhci_hub_control() accesses port_status array with out of bounds port value. Fix it to reference port_status[] only with a valid rhport value when invalid_rhport flag is true.
The invalid_rhport flag is set early on after detecting in port value is within the bounds or not.
The following is used reproduce the problem and verify the fix:
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000
--- drivers/usb/usbip/vhci_hcd.c | 57 +++++++++++++++++++++++++++++++------------ 1 file changed, 42 insertions(+), 15 deletions(-)
drivers/usb/usbip/vhci_hcd.c +42 -15
@@ -318,8 +318,9 @@ static int vhci_hub_control(struct usb_hstruct vhci_hcd *vhci_hcd;struct vhci *vhci;int retval =0 ; -int rhport; +int rhport =-1 ;unsigned long flags; +bool invalid_rhport = false;u32 prev_port_status[VHCI_HC_PORTS ];
@@ -334,9 +335,19 @@ static int vhci_hub_control(struct usb_husbip_dbg_vhci_rh ("typeReq %x wValue %x wIndex %x\n" , typeReq, wValue, wIndex); -if (wIndex >VHCI_HC_PORTS ) -pr_err ("invalid port number %d\n" , wIndex); - rhport = wIndex -1 ; +/* +* wIndex can be 0 for some request types (typeReq). rhport is +* in valid range when wIndex >= 1 and < VHCI_HC_PORTS. +* +* Reference port_status[] only with valid rhport when +* invalid_rhport is false. +*/ +if (wIndex <1 || wIndex >VHCI_HC_PORTS ) { + invalid_rhport = true; +if (wIndex >VHCI_HC_PORTS ) +pr_err ("invalid port number %d\n" , wIndex); + }else + rhport = wIndex -1 ; vhci_hcd =hcd_to_vhci_hcd (hcd); vhci = vhci_hcd->vhci;
@@ -345,8 +356,9 @@ static int vhci_hub_control(struct usb_h/* store old status and compare now and old later */ if (usbip_dbg_flag_vhci_rh) { -memcpy (prev_port_status, vhci_hcd->port_status, -sizeof (prev_port_status)); +if (!invalid_rhport) +memcpy (prev_port_status, vhci_hcd->port_status, +sizeof (prev_port_status)); }switch (typeReq) {
@@ -354,8 +366,10 @@ static int vhci_hub_control(struct usb_husbip_dbg_vhci_rh (" ClearHubFeature\n" );break ;case ClearPortFeature: -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + }switch (wValue) {case USB_PORT_FEAT_SUSPEND :if (hcd->speed ==HCD_USB3 ) {
@@ -415,9 +429,10 @@ static int vhci_hub_control(struct usb_hbreak ;case GetPortStatus:usbip_dbg_vhci_rh (" GetPortStatus port %x\n" , wIndex); -if (wIndex <1 ) { +if (invalid_rhport) {pr_err ("invalid port number %d\n" , wIndex); retval = -EPIPE ; + goto error; }/* we do not care about resume. */
@@ -513,16 +528,20 @@ static int vhci_hub_control(struct usb_h goto error; } -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + } vhci_hcd->port_status[rhport] |=USB_PORT_STAT_SUSPEND ;break ;case USB_PORT_FEAT_POWER :usbip_dbg_vhci_rh (" SetPortFeature: USB_PORT_FEAT_POWER\n" ); -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + }if (hcd->speed ==HCD_USB3 ) vhci_hcd->port_status[rhport] |=USB_SS_PORT_STAT_POWER ;else
@@ -531,8 +550,10 @@ static int vhci_hub_control(struct usb_hcase USB_PORT_FEAT_BH_PORT_RESET :usbip_dbg_vhci_rh (" SetPortFeature: USB_PORT_FEAT_BH_PORT_RESET\n" ); -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + }/* Applicable only for USB3.0 hub */ if (hcd->speed !=HCD_USB3 ) { pr_err("USB_PORT_FEAT_BH_PORT_RESET req not "
@@ -543,8 +564,10 @@ static int vhci_hub_control(struct usb_hcase USB_PORT_FEAT_RESET :usbip_dbg_vhci_rh (" SetPortFeature: USB_PORT_FEAT_RESET\n" ); -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + }/* if it's already enabled, disable */ if (hcd->speed ==HCD_USB3 ) { vhci_hcd->port_status[rhport] =0 ;
@@ -565,8 +588,10 @@ static int vhci_hub_control(struct usb_hdefault :usbip_dbg_vhci_rh (" SetPortFeature: default %d\n" , wValue); -if (rhport <0 ) +if (invalid_rhport) { +pr_err ("invalid port number %d\n" , wIndex); goto error; + }if (hcd->speed ==HCD_USB3 ) {if ((vhci_hcd->port_status[rhport] &USB_SS_PORT_STAT_POWER ) !=0 ) {
@@ -608,7 +633,7 @@ error:if (usbip_dbg_flag_vhci_rh) {pr_debug ("port %d\n" , rhport);/* Only dump valid port status */ -if (rhport >=0 ) { +if (!invalid_rhport) {dump_port_status_diff (prev_port_status[rhport], vhci_hcd->port_status[rhport], hcd->speed ==HCD_USB3 );
@@ -618,8 +643,10 @@ error:spin_unlock_irqrestore (&vhci->lock, flags); -if ((vhci_hcd->port_status[rhport] &PORT_C_MASK ) !=0 ) +if (!invalid_rhport && + (vhci_hcd->port_status[rhport] &PORT_C_MASK ) !=0 ) {usb_hcd_poll_rh_status (hcd); + }return retval; }
Greg Kroah-Hartman
maintainerPATCH 19/34 usb: gadget: storage: Fix Spectre v1 vulnerability
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit 9ae24af3669111d418242caec8dd4ebd9ba26860 upstream.
num can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn:
potential spectre issue 'fsg_opts->common->luns' [r] (local cap)
Fix this by sanitizing num before using it to index fsg_opts->common->luns
Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
--- drivers/usb/gadget/function/f_mass_storage.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/gadget/function/f_mass_storage.c +3 -0
@@ -222,6 +222,8 @@#include <linux/usb/gadget.h> #include <linux/usb/composite.h> +#include <linux/nospec.h> +#include "configfs.h"
@@ -3171,6 +3173,7 @@ static struct config_group *fsg_lun_make fsg_opts =to_fsg_opts (&group->cg_item);if (num >=FSG_MAX_LUNS )return ERR_PTR (-ERANGE ); + num =array_index_nospec (num,FSG_MAX_LUNS );mutex_lock (&fsg_opts->lock);if (fsg_opts->refcnt || fsg_opts->common->luns[num]) {
Greg Kroah-Hartman
maintainerPATCH 20/34 usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wan Ahmad Zainie <[email protected]>
commit 009b1948e153ae448f62f1887e2b58d0e05db51b upstream.
Add missing pm_runtime_disable() to remove(), in order to avoid an Unbalanced pm_runtime_enable when the module is removed and re-probed.
Error log:
root@intel-corei7-64:~# modprobe -r intel_xhci_usb_role_switch root@intel-corei7-64:~# modprobe intel_xhci_usb_role_switch intel_xhci_usb_sw intel_xhci_usb_sw: Unbalanced pm_runtime_enable!
--- drivers/usb/roles/intel-xhci-usb-role-switch.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/roles/intel-xhci-usb-role-switch.c +2 -0
@@ -161,6 +161,8 @@ static int intel_xhci_usb_remove(struct {struct intel_xhci_usb_data *data =platform_get_drvdata (pdev); +pm_runtime_disable (&pdev->dev); +usb_role_switch_unregister (data->role_sw);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 21/34 usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heikki Krogerus <[email protected]>
commit c02588a352defaf985fc1816eb6232663159e1b8 upstream.
Intel Apollo Lake has the same internal USB role mux as Intel Cherry Trail.
--- drivers/usb/host/xhci-pci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-pci.c +4 -2
@@ -179,10 +179,12 @@ static void xhci_pci_quirks(struct devic xhci->quirks |=XHCI_PME_STUCK_QUIRK ; }if (pdev->vendor ==PCI_VENDOR_ID_INTEL && - pdev->device ==PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ) { + pdev->device ==PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ) xhci->quirks |=XHCI_SSIC_PORT_UNUSED ; +if (pdev->vendor ==PCI_VENDOR_ID_INTEL && + (pdev->device ==PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI || + pdev->device ==PCI_DEVICE_ID_INTEL_APL_XHCI )) xhci->quirks |=XHCI_INTEL_USB_ROLE_SW ; - } if (pdev->vendor == PCI_VENDOR_ID_INTEL && (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
Greg Kroah-Hartman
maintainerPATCH 22/34 USB: fix the usbfs flag sanitization for control transfers
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream.
Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the transfer flags for URBs submitted from userspace via usbfs. However, the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be allowed for a control transfer was added in the wrong place, before the code has properly determined the direction of the control transfer. (Control transfers are special because for them, the direction is set by the bRequestType byte of the Setup packet rather than direction bit of the endpoint address.)
This patch moves code which sets up the allow_short flag for control transfers down after is_in has been set to the correct value.
--- drivers/usb/core/devio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/core/devio.c +2 -2
@@ -1473,8 +1473,6 @@ static int proc_do_submiturb(struct usb_ u =0 ;switch (uurb->type) {case USBDEVFS_URB_TYPE_CONTROL : -if (is_in) - allow_short = true;if (!usb_endpoint_xfer_control (&ep->desc))return -EINVAL ;/* min 8 byte setup packet */
@@ -1504,6 +1502,8 @@ static int proc_do_submiturb(struct usb_ is_in =0 ; uurb->endpoint &= ~USB_DIR_IN ; } +if (is_in) + allow_short = true; snoop(&ps->dev->dev, "control urb: bRequestType=%02x " "bRequest=%02x wValue=%04x " "wIndex=%04x wLength=%04x\n",
Greg Kroah-Hartman
maintainerPATCH 23/34 block: dont deal with discard limit in blkdev_issue_discard()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <[email protected]>
commit 744889b7cbb56a64f957e65ade7cb65fe3f35714 upstream.
blk_queue_split() does respect this limit via bio splitting, so no need to do that in blkdev_issue_discard(), then we can align to normal bio submit(bio_add_page() & submit_bio()).
More importantly, this patch fixes one issue introduced in a22c4d7e34402cc ("block: re-add discard_granularity and alignment checks"), in which zero discard bio may be generated in case of zero alignment.
--- block/blk-lib.c | 28 ++-------------------------- 1 file changed, 2 insertions(+), 26 deletions(-)
block/blk-lib.c +2 -26
@@ -29,9 +29,7 @@ int __blkdev_issue_discard(struct block_ {struct request_queue *q =bdev_get_queue (bdev);struct bio *bio = *biop; -unsigned int granularity;unsigned int op; -int alignment;sector_t bs_mask;if (!q)
@@ -54,38 +52,16 @@ int __blkdev_issue_discard(struct block_if ((sector | nr_sects) & bs_mask)return -EINVAL ; -/* Zero-sector (unknown) and one-sector granularities are the same. */ - granularity =max (q->limits.discard_granularity >>9 ,1U ); - alignment = (bdev_discard_alignment (bdev) >>9 ) % granularity; -while (nr_sects) { -unsigned int req_sects; -sector_t end_sect, tmp; +unsigned int req_sects = nr_sects; +sector_t end_sect; -/* -* Issue in chunks of the user defined max discard setting, -* ensuring that bi_size doesn't overflow -*/ - req_sects =min_t (sector_t, nr_sects, - q->limits.max_discard_sectors);if (!req_sects) goto fail;if (req_sects >UINT_MAX >>9 ) req_sects =UINT_MAX >>9 ; -/* -* If splitting a request, and the next starting sector would be -* misaligned, stop the discard at the previous aligned sector. -*/ end_sect = sector + req_sects; - tmp = end_sect; -if (req_sects < nr_sects && -sector_div (tmp, granularity) != alignment) { - end_sect = end_sect - alignment; -sector_div (end_sect, granularity); - end_sect = end_sect * granularity + alignment; - req_sects = end_sect - sector; - } bio =next_bio (bio,0 , gfp_mask); bio->bi_iter.bi_sector = sector;
Greg Kroah-Hartman
maintainerPATCH 24/34 tracing: Fix synthetic event to accept unsigned modifier
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu <[email protected]>
commit 282447ba6b00c64678ffdf964f44e5c8b1c68377 upstream.
Fix synthetic event to accept unsigned modifier for its field type correctly.
Currently, synthetic_events interface returns error for "unsigned" modifiers as below;
# echo "myevent unsigned long var" >> synthetic_events sh: write error: Invalid argument
This is because argv_split() breaks "unsigned long" into "unsigned" and "long", but parse_synth_field() doesn't expected it.
With this fix, synthetic_events can handle the "unsigned long" correctly like as below;
# echo "myevent unsigned long var" >> synthetic_events # cat synthetic_events myevent unsigned long var
--- kernel/trace/trace_events_hist.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-)
kernel/trace/trace_events_hist.c +24 -6
@@ -747,16 +747,30 @@ static void free_synth_field(struct syntkfree (field); } -static struct synth_field *parse_synth_field (char *field_type, -char *field_name) +static struct synth_field *parse_synth_field (int argc,char **argv, +int *consumed) {struct synth_field *field; +const char *prefix =NULL ; +char *field_type = argv[0 ], *field_name;int len, ret =0 ;char *array;if (field_type[0 ] ==';' ) field_type++; +if (!strcmp (field_type,"unsigned" )) { +if (argc <3 ) +return ERR_PTR (-EINVAL ); + prefix ="unsigned " ; + field_type = argv[1 ]; + field_name = argv[2 ]; + *consumed =3 ; + }else { + field_name = argv[1 ]; + *consumed =2 ; + } + len =strlen (field_name);if (field_name[len -1 ] ==';' ) field_name[len -1 ] ='\0' ;
@@ -769,11 +783,15 @@ static struct synth_field *parse_synth_f array =strchr (field_name,'[' );if (array) len +=strlen (array); +if (prefix) + len +=strlen (prefix); field->type =kzalloc (len,GFP_KERNEL );if (!field->type) { ret = -ENOMEM ; goto free; } +if (prefix) +strcat (field->type, prefix);strcat (field->type, field_type);if (array) {strcat (field->type, array);
@@ -1018,7 +1036,7 @@ static int create_synth_event(int argc,struct synth_field *field, *fields[SYNTH_FIELDS_MAX ];struct synth_event *event =NULL ;bool delete_event = false; -int i, n_fields =0 , ret =0 ; +int i, consumed =0 , n_fields =0 , ret =0 ;char *name;mutex_lock (&synth_event_mutex);
@@ -1070,13 +1088,13 @@ static int create_synth_event(int argc, goto err; } - field =parse_synth_field (argv[i], argv[i +1 ]); + field =parse_synth_field (argc - i, &argv[i], &consumed);if (IS_ERR (field)) { ret =PTR_ERR (field); goto err; } - fields[n_fields] = field; - i++; n_fields++; + fields[n_fields++] = field; + i += consumed -1 ; }if (i < argc) {
Greg Kroah-Hartman
maintainerPATCH 25/34 tracing: Fix synthetic event to allow semicolon at end
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu <[email protected]>
commit a360d9e4016c1fcf41553b37ad496870dc5723d0 upstream.
Fix synthetic event to allow independent semicolon at end.
The synthetic_events interface accepts a semicolon after the last word if there is no space.
# echo "myevent u64 var;" >> synthetic_events
But if there is a space, it returns an error.
# echo "myevent u64 var ;" > synthetic_events sh: write error: Invalid argument
This behavior is difficult for users to understand. Let's allow the last independent semicolon too.
--- kernel/trace/trace_events_hist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_events_hist.c +1 -1
@@ -1097,7 +1097,7 @@ static int create_synth_event(int argc, i += consumed -1 ; } -if (i < argc) { +if (i < argc &&strcmp (argv[i],";" ) !=0 ) { ret = -EINVAL ; goto err; }
Greg Kroah-Hartman
maintainerPATCH 26/34 Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikhail Nikiforov <[email protected]>
commit 13c1c5e4d7f887cba36c5e3df3faa22071c1469f upstream.
Add ELAN061C to the ACPI table to support Elan touchpad found in Lenovo IdeaPad 330-15IGM.
--- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/mouse/elan_i2c_core.c +1 -0
@@ -1346,6 +1346,7 @@ static const struct acpi_device_id elan_ { "ELAN0611", 0 }, { "ELAN0612", 0 }, { "ELAN0618", 0 }, + { "ELAN061C", 0 }, { "ELAN061D", 0 }, { "ELAN0622", 0 }, { "ELAN1000", 0 },
Greg Kroah-Hartman
maintainerPATCH 27/34 drm/sun4i: Fix an ulong overflow in the dotclock driver
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit e84cb605e02f1b3d0aee8d7157419cd8aaa06038 upstream.
The calculated ideal rate can easily overflow an unsigned long, thus making the best div selection buggy as soon as no ideal match is found before the overflow occurs.
--- drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/gpu/drm/sun4i/sun4i_dotclock.c +11 -1
@@ -81,9 +81,19 @@ static long sun4i_dclk_round_rate(structint i;for (i = tcon->dclk_min_div; i <= tcon->dclk_max_div; i++) { -unsigned long ideal = rate * i; +u64 ideal = (u64 )rate * i;unsigned long rounded; +/* +* ideal has overflowed the max value that can be stored in an +* unsigned long, and every clk operation we might do on a +* truncated u64 value will give us incorrect results. +* Let's just stop there since bigger dividers will result in +* the same overflow issue. +*/ +if (ideal >ULONG_MAX ) + goto out; + rounded =clk_hw_round_rate (clk_hw_get_parent (hw), ideal);
Greg Kroah-Hartman
maintainerPATCH 28/34 sched/fair: Fix throttle_list starvation with low CFS quota
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phil Auld <[email protected]>
commit baa9be4ffb55876923dc9716abc0a448e510ba30 upstream.
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000, distribute_cfs_runtime may not empty the throttled_list before it runs out of runtime to distribute. In that case, due to the change from c06f04c7048 to put throttled entries at the head of the list, later entries on the list will starve. Essentially, the same X processes will get pulled off the list, given CPU time and then, when expired, get put back on the head of the list where distribute_cfs_runtime will give runtime to the same set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can decide to put the throttled entry on the tail or the head of the list. The bit is set/cleared by the callers of distribute_cfs_runtime while they hold cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on the live system. In some cases you can simply look at the throttled list and see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582 crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582Sometimes it is easier to see by finding a process getting starved and looking at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},--- kernel/sched/fair.c | 22 +++++++++++++++++++--- kernel/sched/sched.h | 2 ++ 2 files changed, 21 insertions(+), 3 deletions(-)
kernel/sched/fair.c +19 -3
@@ -4797,9 +4797,13 @@ static void throttle_cfs_rq(struct cfs_r/* * Add to the _head_ of the list, so that an already-started -* distribute_cfs_runtime will not see us +* distribute_cfs_runtime will not see us. If disribute_cfs_runtime is +* not running add to the tail so that later runqueues don't get starved. */ -list_add_rcu (&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq); +if (cfs_b->distribute_running) +list_add_rcu (&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq); +else +list_add_tail_rcu (&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq);/* * If we're the first throttled task, make sure the bandwidth
@@ -4943,14 +4947,16 @@ static int do_sched_cfs_period_timer(str* in us over-using our runtime if it is all used during this loop, but * only by limited amounts in that extreme case. */ -while (throttled && cfs_b->runtime >0 ) { +while (throttled && cfs_b->runtime >0 && !cfs_b->distribute_running) { runtime = cfs_b->runtime; + cfs_b->distribute_running =1 ;raw_spin_unlock (&cfs_b->lock);/* we can't nest cfs_b->lock while distributing bandwidth */ runtime =distribute_cfs_runtime (cfs_b, runtime, runtime_expires);raw_spin_lock (&cfs_b->lock); + cfs_b->distribute_running =0 ; throttled = !list_empty (&cfs_b->throttled_cfs_rq); cfs_b->runtime -=min (runtime, cfs_b->runtime);
@@ -5061,6 +5067,11 @@ static void do_sched_cfs_slack_timer(str/* confirm we're still not at a refresh boundary */ raw_spin_lock (&cfs_b->lock); +if (cfs_b->distribute_running) { +raw_spin_unlock (&cfs_b->lock); +return ; + } +if (runtime_refresh_within (cfs_b, min_bandwidth_expiration)) {raw_spin_unlock (&cfs_b->lock);return ;
@@ -5070,6 +5081,9 @@ static void do_sched_cfs_slack_timer(str runtime = cfs_b->runtime; expires = cfs_b->runtime_expires; +if (runtime) + cfs_b->distribute_running =1 ; +raw_spin_unlock (&cfs_b->lock);if (!runtime)
@@ -5080,6 +5094,7 @@ static void do_sched_cfs_slack_timer(strraw_spin_lock (&cfs_b->lock);if (expires == cfs_b->runtime_expires) cfs_b->runtime -=min (runtime, cfs_b->runtime); + cfs_b->distribute_running =0 ;raw_spin_unlock (&cfs_b->lock); }
@@ -5188,6 +5203,7 @@ void init_cfs_bandwidth(struct cfs_bandw cfs_b->period_timer.function = sched_cfs_period_timer;hrtimer_init (&cfs_b->slack_timer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL ); cfs_b->slack_timer.function = sched_cfs_slack_timer; + cfs_b->distribute_running =0 ; }static void init_cfs_rq_runtime (struct cfs_rq *cfs_rq)
kernel/sched/sched.h +2 -0
@@ -346,6 +346,8 @@ struct cfs_bandwidth {int nr_periods;int nr_throttled;u64 throttled_time; + +bool distribute_running;#endif };
Greg Kroah-Hartman
maintainerPATCH 29/34 x86/tsc: Force inlining of cyc2ns bits
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 4907c68abd3f60f650f98d5a69d4ec77c0bde44f upstream.
Looking at the asm for native_sched_clock() I noticed we don't inline enough. Mostly caused by sharing code with cyc2ns_read_begin(), which we didn't used to do. So mark all that __force_inline to make it DTRT.
--- arch/x86/kernel/tsc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/x86/kernel/tsc.c +3 -3
@@ -60,7 +60,7 @@ struct cyc2ns { static DEFINE_PER_CPU_ALIGNED(struct cyc2ns, cyc2ns); -void cyc2ns_read_begin (struct cyc2ns_data *data) +void __always_inline cyc2ns_read_begin(struct cyc2ns_data *data) {int seq, idx;
@@ -77,7 +77,7 @@ void cyc2ns_read_begin(struct cyc2ns_dat }while (unlikely (seq !=this_cpu_read (cyc2ns.seq.sequence))); } -void cyc2ns_read_end (void ) +void __always_inline cyc2ns_read_end(void) {preempt_enable_notrace (); }
@@ -123,7 +123,7 @@ static void __init cyc2ns_init(int cpu)seqcount_init (&c2n->seq); } -static inline unsigned long long cycles_2_ns (unsigned long long cyc) +static __always_inline unsigned long long cycles_2_ns (unsigned long long cyc) {struct cyc2ns_data data;unsigned long long ns;
Greg Kroah-Hartman
maintainerPATCH 30/34 x86, hibernate: Fix nosave_regions setup for hibernation
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhimin Gu <[email protected]>
commit cc55f7537db6af371e9c1c6a71161ee40f918824 upstream.
On 32bit systems, nosave_regions(non RAM areas) located between max_low_pfn and max_pfn are not excluded from hibernation snapshot currently, which may result in a machine check exception when trying to access these unsafe regions during hibernation:
[ 612.800453] Disabling lock debugging due to kernel taint
[ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136
[ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560}
[ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086
[ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24
[ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt
[ 612.853380] Kernel panic - not syncing: Fatal machine check
[ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff)This is because on 32bit systems, pages above max_low_pfn are regarded as high memeory, and accessing unsafe pages might cause expected MCE. On the problematic 32bit system, there are reserved memory above low memory, which triggered the MCE:
e820 memory mapping:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable
Fix this problem by changing pfn limit from max_low_pfn to max_pfn. This fix does not impact 64bit system because on 64bit max_low_pfn is the same as max_pfn.
--- arch/x86/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/setup.c +1 -1
@@ -1258,7 +1258,7 @@ void __init setup_arch(char **cmdline_p) x86_init.hyper.guest_late_init ();e820__reserve_resources (); -e820__register_nosave_regions (max_low_pfn); +e820__register_nosave_regions (max_pfn); x86_init.resources.reserve_resources ();
Re: [PATCH 4.18 30/34] x86, hibernate: Fix nosave_regions setup for hibernation
Quoted 2 lines · Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know.
For the record, this and
[PATCH 4.14 27/31] x86, hibernate: Fix nosave_regions setup
makes sense to me.
Best regards,
Pavel
Quoted 81 lines
------------------
From: Zhimin Gu <[email protected]>
commit
cc55f7537db6af371e9c1c6a71161ee40f918824upstream.On 32bit systems,
nosave_regions(non RAM areas)located betweenmax_low_pfnandmax_pfnare not excluded from hibernation snapshot currently, which may result in a machine check exception when trying to access these unsafe regions during hibernation:[ 612.800453] Disabling lock debugging due to kernel taint [ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136 [ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560} [ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086 [ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24 [ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt [ 612.853380] Kernel panic - not syncing: Fatal machine check [ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff)This is because on 32bit systems, pages above
max_low_pfnare regarded as high memeory, and accessing unsafe pages might cause expected MCE. On the problematic 32bit system, there are reserved memory above low memory, which triggered the MCE:e820 memory mapping:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usableFix this problem by changing pfn limit from
max_low_pfntomax_pfn. This fix does not impact 64bit system because on 64bitmax_low_pfnis the same asmax_pfn.Signed-off-by Zhimin Gu <[email protected]>Acked-by Pavel Machek <[email protected]>Signed-off-by Chen Yu <[email protected]>Acked-by Thomas Gleixner <[email protected]>Cc All applicable <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/x86/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/x86/kernel/setup.c +1
-1@@ -1258,7 +1258,7 @@ void __init setup_arch(char **cmdline_p) x86_init.hyper.guest_late_init ();e820__reserve_resources (); -e820__register_nosave_regions (max_low_pfn); +e820__register_nosave_regions (max_pfn); x86_init.resources.reserve_resources ();
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Greg Kroah-Hartman
maintainerPATCH 31/34 x86/percpu: Fix this_cpu_read()
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit b59167ac7bafd804c91e49ad53c6d33a7394d4c8 upstream.
Eric reported that a sequence count loop using this_cpu_read() got optimized out. This is wrong, this_cpu_read() must imply READ_ONCE() because the interface is IRQ-safe, therefore an interrupt can have changed the per-cpu value.
--- arch/x86/include/asm/percpu.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/include/asm/percpu.h +4 -4
@@ -185,22 +185,22 @@ do { \typeof (var) pfo_ret__; \switch (sizeof (var)) { \case 1 : \ - asm(op "b "__percpu_arg(1)",%0" \ + asm volatile(op "b "__percpu_arg(1)",%0"\ : "=q" (pfo_ret__) \ : "m" (var)); \ break; \ case 2: \ - asm(op "w "__percpu_arg(1)",%0" \ + asm volatile(op "w "__percpu_arg(1)",%0"\ : "=r" (pfo_ret__) \ : "m" (var)); \ break; \ case 4: \ - asm(op "l "__percpu_arg(1)",%0" \ + asm volatile(op "l "__percpu_arg(1)",%0"\ : "=r" (pfo_ret__) \ : "m" (var)); \ break; \ case 8: \ - asm(op "q "__percpu_arg(1)",%0" \ + asm volatile(op "q "__percpu_arg(1)",%0"\ : "=r" (pfo_ret__) \: " m" (var)); \ break; \
Greg Kroah-Hartman
maintainerPATCH 32/34 x86/time: Correct the attribute on jiffies definition
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 53c13ba8ed39e89f21a0b98f4c8a241bb44e483d upstream.
Clang warns that the declaration of jiffies in include/linux/jiffies.h doesn't match the definition in arch/x86/time/kernel.c:
arch/x86/kernel/time.c:29:42: warning: section does not match previous declaration [-Wsection]
__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
^
./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
__section__(".data..cacheline_aligned")))
^
./include/linux/jiffies.h:81:31: note: previous attribute is here
extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
^
./arch/x86/include/asm/cache.h:20:2: note: expanded from macro '__cacheline_aligned_in_smp'
__page_aligned_data
^
./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
#define __page_aligned_data __section(.data..page_aligned) __aligned(PAGE_SIZE)
^
./include/linux/compiler_attributes.h:233:56: note: expanded from macro '__section'
#define __section(S) __attribute__((__section__(#S)))
^1 warning generated.
The declaration was changed in commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp") but wasn't updated here. Make them match so Clang no longer warns.
--- arch/x86/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/time.c +1 -1
@@ -25,7 +25,7 @@#include <asm/time.h> #ifdef CONFIG_X86_64 -__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES; +__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = INITIAL_JIFFIES;#endif unsigned long profile_pc (struct pt_regs *regs)
Greg Kroah-Hartman
maintainerPATCH 33/34 x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 upstream.
We already build the swiotlb code for 32-bit kernels with PAE support, but the code to actually use swiotlb has only been enabled for 64-bit kernels for an unknown reason.
Before Linux v4.18 we paper over this fact because the networking code, the SCSI layer and some random block drivers implemented their own bounce buffering scheme.
[ mingo: Changelog fixes. ]
--- arch/x86/kernel/pci-swiotlb.c | 2 -- 1 file changed, 2 deletions(-)
arch/x86/kernel/pci-swiotlb.c +0 -2
@@ -42,10 +42,8 @@ IOMMU_INIT_FINISH(pci_swiotlb_detect_oveint __init pci_swiotlb_detect_4gb (void ) {/* don't initialize swiotlb if iommu=off (no_iommu=1) */ -#ifdef CONFIG_X86_64 if (!no_iommu && max_possible_pfn >MAX_DMA32_PFN ) swiotlb =1 ; -#endif /* * If SME is active then swiotlb will be set to 1 so that bounce
Greg Kroah-Hartman
maintainerPATCH 34/34 x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
In reply to Greg Kroah-Hartman4.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit 2224d616528194b02424c91c2ee254b3d29942c3 upstream.
Booting an i486 with "no387 nofxsr" ends with with the following crash:
math_emulate: 0060:c101987d
Kernel panic - not syncing: Math emulation needed in kernel
on the first context switch in user land.
The reason is that copy_fpregs_to_fpstate() tries FNSAVE which does not work as the FPU is turned off.
This bug was introduced in:
f1c8cd0176078 ("x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active")
Add a check for X86_FEATURE_FPU before trying to save FPU registers (we have such a check in switch_fpu_finish() already).
--- arch/x86/include/asm/fpu/internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/fpu/internal.h +1 -1
@@ -528,7 +528,7 @@ static inline void fpregs_activate(strucstatic inline void switch_fpu_prepare (struct fpu *old_fpu,int cpu) { -if (old_fpu->initialized) { +if (static_cpu_has (X86_FEATURE_FPU ) && old_fpu->initialized) {if (!copy_fpregs_to_fpstate (old_fpu)) old_fpu->last_cpu =-1 ;else
stable-rc/linux-4.18.y boot: 91 boots: 0 failed, 76 passed with 15 offline (v4.18.17-35-g46c86a0ac4a1)
stable-rc/linux-4.18.y boot: 91 boots: 0 failed, 76 passed with 15 offline (v4.18.17-35-g46c86a0ac4a1)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.18.y/kernel/v4.18.17-35-g46c86a0ac4a1/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.18.y/kernel/v4.18.17-35-g46c86a0ac4a1/
Tree: stable-rc
Branch: linux-4.18.y
Git Describe: v4.18.17-35-g46c86a0ac4a1
Git Commit: 46c86a0ac4a119d8aaa02055e233b2ee550a016e
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 56 unique boards, 20 SoC families, 15 builds out of 187
Offline Platforms:
arm:
omap2plus_defconfig:
am335x-boneblack: 1 offline lab
sunxi_defconfig:
sun5i-r8-chip: 1 offline lab
tegra_defconfig:
tegra124-jetson-tk1: 1 offline lab
bcm2835_defconfig:
bcm2835-rpi-b: 1 offline lab
sama5_defconfig:
at91-sama5d4_xplained: 1 offline lab
multi_v7_defconfig:
alpine-db: 1 offline lab
am335x-boneblack: 1 offline lab
at91-sama5d4_xplained: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab
sun5i-r8-chip: 1 offline lab
tegra124-jetson-tk1: 1 offline lab
arm64:
defconfig:
apq8016-sbc: 1 offline lab
juno-r2: 1 offline lab
meson-gxl-s905d-p230: 1 offline lab
mt7622-rfb1: 1 offline lab---
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.18.18 release. There are 34 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 Sat Nov 10 21:51:21 UTC 2018. 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.18.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.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.
Summary
------------------------------------------------------------------------
kernel: 4.18.18-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: 46c86a0ac4a119d8aaa02055e233b2ee550a016e
git describe: v4.18.17-35-g46c86a0ac4a1
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.17-35-g46c86a0ac4a1
No regressions (compared to build v4.18.17)
No fixes (compared to build v4.18.17)
Ran 21302 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
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-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-nptl-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-pty-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.18 release. There are 34 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 Sat Nov 10 21:51:21 UTC 2018. 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.18.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 3 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.18 release. There are 34 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 Sat Nov 10 21:51:21 UTC 2018. Anything received after that time might be too late.
Build results:
total: 136 pass: 136 fail: 0 Qemu test results: total: 295 pass: 295 fail: 0
Details are available at https://kerneltests.org/builders/.
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.18 release. There are 34 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 Sat Nov 10 21:51:21 UTC 2018. 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.18.18-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.18.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my new test system. I don't have a reference for dmesg regressions and I haven't noticed any problems.
thanks,
-- Shuah