4.9.85-stable review
Greg Kroah-Hartman
maintainercover 4.9.85-stable review
This is the start of the stable review cycle for the 4.9.85 release. There are 39 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 Feb 28 20:16:31 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.9.85-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.85-rc1
Dan Williams <[email protected]>
x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface
Dan Williams <[email protected]>
mm: fail get_vaddr_frames() for filesystem-dax mappings
Jan H. Schönherr <[email protected]>
mm: Fix devm_memremap_pages() collision handling
Dan Williams <[email protected]>
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
Dan Williams <[email protected]>
IB/core: disable memory registration of filesystem-dax vmas
Dan Williams <[email protected]>
v4l2: disable filesystem-dax mapping support
Dan Williams <[email protected]>
mm: introduce get_user_pages_longterm
Dan Williams <[email protected]>
device-dax: implement ->split() to catch invalid munmap attempts
Dan Williams <[email protected]>
libnvdimm: fix integer overflow static analysis warning
Jan Kara <[email protected]>
fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
Ross Zwisler <[email protected]>
mm: avoid spurious 'bad pmd' warning messages
Eric Biggers <[email protected]>
X.509: fix NULL dereference when restricting key with unsupported_sig
Eric Biggers <[email protected]>
binder: add missing binder_unlock()
Kai-Heng Feng <[email protected]>
drm/amdgpu: add new device to use atpx quirk
Alex Deucher <[email protected]>
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
Alex Deucher <[email protected]>
drm/amdgpu: add atpx quirk handling (v2)
Alex Deucher <[email protected]>
drm/amdgpu: Add dpm quirk for Jet PRO (v2)
Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
Jack Pham <[email protected]>
usb: gadget: f_fs: Process all descriptors during bind
Bin Liu <[email protected]>
Revert "usb: musb: host: don't start next rx urb if current one failed"
Karsten Koop <[email protected]>
usb: ldusb: add PIDs for new CASSY devices supported by this driver
Thinh Nguyen <[email protected]>
usb: dwc3: gadget: Set maxpacket size for ep0 IN
Kai-Heng Feng <[email protected]>
drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
Jack Stocker <[email protected]>
Add delay-init quirk for Corsair K70 RGB keyboards
Michael Weiser <[email protected]>
arm64: Disable unhandled signal log messages by default
AMAN DEEP <[email protected]>
usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Shigeru Yoshida <[email protected]>
ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Casey Leedom <[email protected]>
PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
Shanker Donthineni <[email protected]>
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
Arnd Bergmann <[email protected]>
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
Lars-Peter Clausen <[email protected]>
iio: adis_lib: Initialize trigger before requesting interrupt
Stefan Windfeldt-Prytz <[email protected]>
iio: buffer: check if a buffer has been set up when poll is called
Leon Romanovsky <[email protected]>
RDMA/uverbs: Protect from command mask overflow
Eric Biggers <[email protected]>
PKCS#7: fix certificate chain verification
Eric Biggers <[email protected]>
X.509: fix BUG_ON() when hash algorithm is unsupported
Arnd Bergmann <[email protected]>
cfg80211: fix cfg80211_beacon_dup
Tyrel Datwyler <[email protected]>
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
Max Filippov <[email protected]>
xtensa: fix high memory/reserved memory collision
Paolo Abeni <[email protected]>
netfilter: drop outermost socket lock in getsockopt()
-------------
Diffstat:
Makefile | 4 +- arch/arm64/kernel/traps.c | 2 +- arch/x86/entry/entry_64.S | 13 +++++ arch/x86/oprofile/nmi_int.c | 2 +- arch/xtensa/mm/init.c | 70 +++++++++++++++++++++--- crypto/asymmetric_keys/pkcs7_verify.c | 2 +- crypto/asymmetric_keys/public_key.c | 4 +- crypto/asymmetric_keys/restrict.c | 7 ++- drivers/android/binder.c | 4 +- drivers/dax/dax.c | 12 ++++ drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 58 +++++++++++++++++--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 - drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 ++ drivers/gpu/drm/drm_edid.c | 3 + drivers/hid/hid-core.c | 3 + drivers/hid/hid-ids.h | 3 + drivers/iio/imu/adis_trigger.c | 7 ++- drivers/iio/industrialio-buffer.c | 2 +- drivers/infiniband/core/umem.c | 2 +- drivers/infiniband/core/uverbs_main.c | 27 ++++++--- drivers/irqchip/irq-gic-v3.c | 2 +- drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ---- drivers/nvdimm/bus.c | 11 ++-- drivers/nvdimm/pfn_devs.c | 15 ++++- drivers/pci/quirks.c | 39 +++++++------ drivers/scsi/ibmvscsi/ibmvfc.h | 2 +- drivers/usb/core/quirks.c | 3 + drivers/usb/dwc3/gadget.c | 2 + drivers/usb/gadget/function/f_fs.c | 6 +- drivers/usb/host/ohci-hcd.c | 10 +++- drivers/usb/host/ohci-hub.c | 4 +- drivers/usb/host/ohci-q.c | 17 +++--- drivers/usb/misc/ldusb.c | 6 ++ drivers/usb/musb/musb_host.c | 8 +-- drivers/usb/renesas_usbhs/fifo.c | 5 ++ fs/dax.c | 1 + include/linux/dax.h | 5 -- include/linux/fs.h | 20 +++++++ include/linux/kernel.h | 1 + include/linux/mm.h | 13 +++++ kernel/memremap.c | 13 +++-- mm/frame_vector.c | 12 ++++ mm/gup.c | 64 ++++++++++++++++++++++ mm/memory.c | 40 ++++++++++---- net/ipv4/ip_sockglue.c | 7 +-- net/ipv6/ipv6_sockglue.c | 10 +--- net/mac80211/cfg.c | 2 +- 48 files changed, 433 insertions(+), 132 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/39 netfilter: drop outermost socket lock in getsockopt()
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace:
======================================================
WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted
------------------------------------------------------
syzkaller233489/4179 is trying to acquire lock:
(rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20net/core/rtnetlink.c:74
but task is already holding lock:
(&xt[i].mutex){+.+.}, at: [<00000000328553a2>]xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
which lock already depends on the new lock.
===
Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now.
v1 -> v2: fix bad subj, added relavant 'fixes' tag
--- net/ipv4/ip_sockglue.c | 7 +------ net/ipv6/ipv6_sockglue.c | 10 ++-------- 2 files changed, 3 insertions(+), 14 deletions(-)
net/ipv4/ip_sockglue.c +1 -6
@@ -1552,10 +1552,7 @@ int ip_getsockopt(struct sock *sk, int lif (get_user (len, optlen))return -EFAULT ; -lock_sock (sk); - err =nf_getsockopt (sk,PF_INET , optname, optval, - &len); -release_sock (sk); + err =nf_getsockopt (sk,PF_INET , optname, optval, &len);if (err >=0 ) err =put_user (len, optlen);return err;
@@ -1587,9 +1584,7 @@ int compat_ip_getsockopt(struct sock *skif (get_user (len, optlen))return -EFAULT ; -lock_sock (sk); err =compat_nf_getsockopt (sk,PF_INET , optname, optval, &len); -release_sock (sk);if (err >=0 ) err =put_user (len, optlen);return err;
net/ipv6/ipv6_sockglue.c +2 -8
@@ -1343,10 +1343,7 @@ int ipv6_getsockopt(struct sock *sk, intif (get_user (len, optlen))return -EFAULT ; -lock_sock (sk); - err =nf_getsockopt (sk,PF_INET6 , optname, optval, - &len); -release_sock (sk); + err =nf_getsockopt (sk,PF_INET6 , optname, optval, &len);if (err >=0 ) err =put_user (len, optlen); }
@@ -1385,10 +1382,7 @@ int compat_ipv6_getsockopt(struct sock *if (get_user (len, optlen))return -EFAULT ; -lock_sock (sk); - err =compat_nf_getsockopt (sk,PF_INET6 , - optname, optval, &len); -release_sock (sk); + err =compat_nf_getsockopt (sk,PF_INET6 , optname, optval, &len);if (err >=0 ) err =put_user (len, optlen); }
Greg Kroah-Hartman
maintainerPATCH 2/39 xtensa: fix high memory/reserved memory collision
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream.
Xtensa memory initialization code frees high memory pages without checking whether they are in the reserved memory regions or not. That results in invalid value of totalram_pages and duplicate page usage by CMA and highmem. It produces a bunch of BUGs at startup looking like this:
BUG: Bad page state in process swapper pfn:70800 page:be60c000 count:0 mapcount:-127 mapping: (null) index:0x1 flags: 0x80000000() raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a page dumped because: nonzero mapcount Modules linked in: CPU: 0 PID: 1 Comm: swapper Tainted: G B 4.16.0-rc1-00015-g7928b2cbe55b-dirty #23 Stack: bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000 a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000 a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e Call Trace: [<a1065734>] bad_page+0xac/0xd0 [<a106578c>] free_pages_check_bad+0x34/0x4c [<a1066166>] __free_pages_ok+0xae/0x14c [<a1066b58>] __free_pages+0x30/0x64 [<a1365de5>] init_cma_reserved_pageblock+0x35/0x44 [<a13682dc>] cma_init_reserved_areas+0xf4/0x148 [<a10034b8>] do_one_initcall+0x80/0xf8 [<a1361c16>] kernel_init_freeable+0xda/0x13c [<a125b59d>] kernel_init+0x9/0xd0 [<a1004304>] ret_from_kernel_thread+0xc/0x18
Only free high memory pages that are not reserved.
--- arch/xtensa/mm/init.c | 70 +++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 63 insertions(+), 7 deletions(-)
arch/xtensa/mm/init.c +63 -7
@@ -77,19 +77,75 @@ void __init zones_init(void)free_area_init_node (0 , zones_size,ARCH_PFN_OFFSET ,NULL ); } +#ifdef CONFIG_HIGHMEM +static void __init free_area_high (unsigned long pfn,unsigned long end) +{ +for (; pfn < end; pfn++) +free_highmem_page (pfn_to_page (pfn)); +} + +static void __init free_highpages (void ) +{ +unsigned long max_low = max_low_pfn; +struct memblock_region *mem, *res; + +reset_all_zones_managed_pages (); +/* set highmem page free */ +for_each_memblock (memory, mem) { +unsigned long start =memblock_region_memory_base_pfn (mem); +unsigned long end =memblock_region_memory_end_pfn (mem); + +/* Ignore complete lowmem entries */ +if (end <= max_low) +continue ; + +if (memblock_is_nomap (mem)) +continue ; + +/* Truncate partial highmem entries */ +if (start < max_low) + start = max_low; + +/* Find and exclude any reserved regions */ +for_each_memblock (reserved, res) { +unsigned long res_start, res_end; + + res_start =memblock_region_reserved_base_pfn (res); + res_end =memblock_region_reserved_end_pfn (res); + +if (res_end < start) +continue ; +if (res_start < start) + res_start = start; +if (res_start > end) + res_start = end; +if (res_end > end) + res_end = end; +if (res_start != start) +free_area_high (start, res_start); + start = res_end; +if (start == end) +break ; + } + +/* And now free anything which remains */ +if (start < end) +free_area_high (start, end); + } +} +#else +static void __init free_highpages (void ) +{ +} +#endif +/* * Initialize memory pages. */ void __init mem_init (void ) { -#ifdef CONFIG_HIGHMEM -unsigned long tmp; - -reset_all_zones_managed_pages (); -for (tmp = max_low_pfn; tmp < max_pfn; tmp++) -free_highmem_page (pfn_to_page (tmp)); -#endif +free_highpages (); max_mapnr = max_pfn -ARCH_PFN_OFFSET ; high_memory = (void *)__va (max_low_pfn <<PAGE_SHIFT );
Greg Kroah-Hartman
maintainerPATCH 3/39 scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyrel Datwyler <[email protected]>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3 bytes reserved field. The ibmvfc driver mistakenly defined this field as 4 bytes resulting in the rsp_code field being defined in what should be the start of the second reserved field and thus always being reported as zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code deduplication, and ease of maintaining standardized structures in a single place. However, for now simply fixup the definition in ibmvfc for backporting to distros on older kernels. Wiring up with libfc will be done in a followup patch.
--- drivers/scsi/ibmvscsi/ibmvfc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/ibmvscsi/ibmvfc.h +1 -1
@@ -367,7 +367,7 @@ enum ibmvfc_fcp_rsp_info_codes { };struct ibmvfc_fcp_rsp_info { -__be16 reserved; +u8 reserved[3 ];u8 rsp_code;u8 reserved2[4 ]; }__attribute__((packed,aligned (2 )));
Greg Kroah-Hartman
maintainerPATCH 4/39 cfg80211: fix cfg80211_beacon_dup
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
Quoted 1 line
From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
--- net/mac80211/cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/cfg.c +1 -1
@@ -2792,7 +2792,7 @@ cfg80211_beacon_dup(struct cfg80211_beac }if (beacon->probe_resp_len) { new_beacon->probe_resp_len = beacon->probe_resp_len; - beacon->probe_resp = pos; + new_beacon->probe_resp = pos;memcpy (pos, beacon->probe_resp, beacon->probe_resp_len); pos += beacon->probe_resp_len; }
Greg Kroah-Hartman
maintainerPATCH 5/39 X.509: fix BUG_ON() when hash algorithm is unsupported
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 437499eea4291ae9621e8763a41df027c110a1ef upstream.
The X.509 parser mishandles the case where the certificate's signature's hash algorithm is not available in the crypto API. In this case, x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this part seems to be intentional. However, public_key_verify_signature() is still called via x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'.
Fix this by making public_key_verify_signature() return -ENOPKG if the hash buffer has not been allocated.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled:
openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
--- crypto/asymmetric_keys/public_key.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
crypto/asymmetric_keys/public_key.c +3 -1
@@ -93,9 +93,11 @@ int public_key_verify_signature(const stBUG_ON (!pkey);BUG_ON (!sig); -BUG_ON (!sig->digest);BUG_ON (!sig->s); +if (!sig->digest) +return -ENOPKG ; + alg_name = sig->pkey_algo;if (strcmp (sig->pkey_algo,"rsa" ) ==0 ) {/* The data wangled by the RSA algorithm is typically padded
Greg Kroah-Hartman
maintainerPATCH 6/39 PKCS#7: fix certificate chain verification
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 971b42c038dc83e3327872d294fe7131bab152fc upstream.
When pkcs7_verify_sig_chain() is building the certificate chain for a SignerInfo using the certificates in the PKCS#7 message, it is passing the wrong arguments to public_key_verify_signature(). Consequently, when the next certificate is supposed to be used to verify the previous certificate, the next certificate is actually used to verify itself.
An attacker can use this bug to create a bogus certificate chain that has no cryptographic relationship between the beginning and end.
Fortunately I couldn't quite find a way to use this to bypass the overall signature verification, though it comes very close. Here's the
reasoning: due to the bug, every certificate in the chain beyond the first actually has to be self-signed (where "self-signed" here refers to the actual key and signature; an attacker might still manipulate the certificate fields such that the self_signed flag doesn't actually get set, and thus the chain doesn't end immediately). But to pass trust validation (pkcs7_validate_trust()), either the SignerInfo or one of the certificates has to actually be signed by a trusted key. Since only self-signed certificates can be added to the chain, the only way for an attacker to introduce a trusted signature is to include a self-signed trusted certificate.
But, when pkcs7_validate_trust_one() reaches that certificate, instead of trying to verify the signature on that certificate, it will actually look up the corresponding trusted key, which will succeed, and then try to verify the *previous* certificate, which will fail. Thus, disaster is narrowly averted (as far as I could tell).
--- crypto/asymmetric_keys/pkcs7_verify.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/asymmetric_keys/pkcs7_verify.c +1 -1
@@ -261,7 +261,7 @@ static int pkcs7_verify_sig_chain(struct sinfo->index);return 0 ; } - ret =public_key_verify_signature (p->pub, p->sig); + ret =public_key_verify_signature (p->pub, x509->sig);if (ret <0 )return ret; x509->signer = p;
Greg Kroah-Hartman
maintainerPATCH 7/39 RDMA/uverbs: Protect from command mask overflow
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
commit 3f802b162dbf4a558ff98986449eddc717826209 upstream.
The command number is not bounds checked against the command mask before it is shifted, resulting in an ubsan hit. This does not cause malfunction since the command number is eventually bounds checked, but we can make this ubsan clean by moving the bounds check to before the mask check.
================================================================================
UBSAN: Undefined behaviour in drivers/infiniband/core/uverbs_main.c:647:21 shift exponent 207 is too large for 64-bit type 'long long unsigned int' CPU: 0 PID: 446 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #61 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0xde/0x164 ? dma_virt_map_sg+0x22c/0x22c ubsan_epilogue+0xe/0x81 __ubsan_handle_shift_out_of_bounds+0x293/0x2f7 ? debug_check_no_locks_freed+0x340/0x340 ? __ubsan_handle_load_invalid_value+0x19b/0x19b ? lock_acquire+0x440/0x440 ? lock_acquire+0x19d/0x440 ? __might_fault+0xf4/0x240 ? ib_uverbs_write+0x68d/0xe20 ib_uverbs_write+0x68d/0xe20 ? __lock_acquire+0xcf7/0x3940 ? uverbs_devnode+0x110/0x110 ? cyc2ns_read_end+0x10/0x10 ? sched_clock_cpu+0x18/0x200 ? sched_clock_cpu+0x18/0x200 __vfs_write+0x10d/0x700 ? uverbs_devnode+0x110/0x110 ? kernel_read+0x170/0x170 ? __fget+0x35b/0x5d0 ? security_file_permission+0x93/0x260 vfs_write+0x1b0/0x550 SyS_write+0xc7/0x1a0 ? SyS_read+0x1a0/0x1a0 ? trace_hardirqs_on_thunk+0x1a/0x1c entry_SYSCALL_64_fastpath+0x18/0x85 RIP: 0033:0x448e29 RSP: 002b:00007f033f567c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f033f5686bc RCX: 0000000000448e29 RDX: 0000000000000060 RSI: 0000000020001000 RDI: 0000000000000012 RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000056a0 R14: 00000000006e8740 R15: 0000000000000000 ================================================================================
--- drivers/infiniband/core/uverbs_main.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-)
drivers/infiniband/core/uverbs_main.c +20 -7
@@ -735,12 +735,21 @@ static int verify_command_mask(struct ibreturn -1 ; } +static bool verify_command_idx (u32 command,bool extended) +{ +if (extended) +return command <ARRAY_SIZE (uverbs_ex_cmd_table); + +return command <ARRAY_SIZE (uverbs_cmd_table); +} +static ssize_t ib_uverbs_write (struct file *filp,const char __user *buf,size_t count,loff_t *pos) {struct ib_uverbs_file *file = filp->private_data;struct ib_device *ib_dev;struct ib_uverbs_cmd_hdr hdr; +bool extended_command;__u32 command;__u32 flags;int srcu_key;
@@ -770,6 +779,15 @@ static ssize_t ib_uverbs_write(struct fi } command = hdr.command &IB_USER_VERBS_CMD_COMMAND_MASK ; + flags = (hdr.command & +IB_USER_VERBS_CMD_FLAGS_MASK ) >>IB_USER_VERBS_CMD_FLAGS_SHIFT ; + + extended_command = flags &IB_USER_VERBS_CMD_FLAG_EXTENDED ; +if (!verify_command_idx (command, extended_command)) { + ret = -EINVAL ; + goto out; + } +if (verify_command_mask (ib_dev, command)) { ret = -EOPNOTSUPP ; goto out;
@@ -781,12 +799,8 @@ static ssize_t ib_uverbs_write(struct fi goto out; } - flags = (hdr.command & -IB_USER_VERBS_CMD_FLAGS_MASK ) >>IB_USER_VERBS_CMD_FLAGS_SHIFT ; -if (!flags) { -if (command >=ARRAY_SIZE (uverbs_cmd_table) || - !uverbs_cmd_table[command]) { +if (!uverbs_cmd_table[command]) { ret = -EINVAL ; goto out; }
@@ -807,8 +821,7 @@ static ssize_t ib_uverbs_write(struct fistruct ib_udata uhw;size_t written_count = count; -if (command >=ARRAY_SIZE (uverbs_ex_cmd_table) || - !uverbs_ex_cmd_table[command]) { +if (!uverbs_ex_cmd_table[command]) { ret = -ENOSYS ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 8/39 iio: buffer: check if a buffer has been set up when poll is called
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Windfeldt-Prytz <[email protected]>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0. Without this check there will be a null pointer dereference when calling poll on a iio driver without an iio buffer.
--- drivers/iio/industrialio-buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/industrialio-buffer.c +1 -1
@@ -174,7 +174,7 @@ unsigned int iio_buffer_poll(struct filestruct iio_dev *indio_dev = filp->private_data;struct iio_buffer *rb = indio_dev->buffer; -if (!indio_dev->info) +if (!indio_dev->info || rb ==NULL )return 0 ;poll_wait (filp, &rb->pollq, wait);
Greg Kroah-Hartman
maintainerPATCH 9/39 iio: adis_lib: Initialize trigger before requesting interrupt
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lars-Peter Clausen <[email protected]>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an interrupt associated with the trigger. The interrupt uses the generic iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after the interrupt has been requested. But an interrupt can fire as soon as it has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure and dereference the ops field. If the ops field is not yet initialized this will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so typically this issue did not surface unless e.g. due to a hardware misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic interrupts in their power-on reset configuration and unfortunately the interrupt can not be masked in the device. This makes the race condition much more visible and the following crash has been observed occasionally when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c0004000 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257 Hardware name: Xilinx Zynq Platform task: ef04f640 task.stack: ef050000 PC is at iio_trigger_notify_done+0x30/0x68 LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20 pc : [<c042d868>] lr : [<c042d924>] psr: 60000193 sp : ef051bb8 ip : 00000000 fp : ef106400 r10: c081d80a r9 : ef3bfa00 r8 : 00000087 r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00 r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 18c5387d Table: 0000404a DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0xef050210) [<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118) [<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58) [<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c) [<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130) [<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34) [<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c) [<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34) [<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4) [<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c) [<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before requesting the interrupt.
--- drivers/iio/imu/adis_trigger.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/iio/imu/adis_trigger.c +4 -3
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adisif (adis->trig ==NULL )return -ENOMEM ; + adis->trig->dev.parent = &adis->spi->dev; + adis->trig->ops = &adis_trigger_ops; +iio_trigger_set_drvdata (adis->trig, adis); + ret = request_irq(adis->spi->irq, &iio_trigger_generic_data_rdy_poll, IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adisif (ret) goto error_free_trig; - adis->trig->dev.parent = &adis->spi->dev; - adis->trig->ops = &adis_trigger_ops; -iio_trigger_set_drvdata (adis->trig, adis); ret =iio_trigger_register (adis->trig); indio_dev->trig =iio_trigger_get (adis->trig);
Greg Kroah-Hartman
maintainerPATCH 10/39 x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU data from CPU 0 to all other CPUs, which when building a non-SMP kernel turns into a memcpy() with identical source and destination pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the GCC warning is welcome. Others turned out to be false-positives, and GCC was changed to not warn about those any more. This is a corner case that is a false-positive but the GCC developers feel it's better to keep warning about it.
In this case, it seems best to work around it by telling GCC a little more clearly that this code path is never hit with an IS_ENABLED() configuration check.
--- arch/x86/oprofile/nmi_int.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/oprofile/nmi_int.c +1 -1
@@ -472,7 +472,7 @@ static int nmi_setup(void) goto fail;for_each_possible_cpu (cpu) { -if (!cpu) +if (!IS_ENABLED (CONFIG_SMP ) || !cpu)continue ; memcpy(per_cpu(cpu_msrs, cpu).counters,
Greg Kroah-Hartman
maintainerPATCH 11/39 irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shanker Donthineni <[email protected]>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only memory accesses before and after the barrier. Since writes to system registers are not memory operations, barrier DMB is not sufficient for observability of memory accesses that occur before ICC_SGI1R_EL1 writes.
A DSB instruction ensures that no instructions that appear in program order after the DSB instruction, can execute until the DSB instruction has completed.
--- drivers/irqchip/irq-gic-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/irqchip/irq-gic-v3.c +1 -1
@@ -616,7 +616,7 @@ static void gic_raise_softirq(const stru* Ensure that stores to Normal memory are visible to the * other CPUs before issuing the IPI. */ -smp_wmb (); +wmb ();for_each_cpu (cpu, mask) {unsigned long cluster_id =cpu_logical_map (cpu) & ~0xffUL ;
Greg Kroah-Hartman
maintainerPATCH 12/39 PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Casey Leedom <[email protected]>
commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.
We've run into a problem where our device is attached to a Virtual Machine and the use of the new pci_set_vpd_size() API doesn't help. The VM kernel has been informed that the accesses are okay, but all of the actual VPD Capability Accesses are trapped down into the KVM Hypervisor where it goes ahead and imposes the silent denials.
The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored to establish a PCI Quirk for our T3-based adapters. This commit extends that PCI Quirk to cover Chelsio T4 devices and later.
The advantage of this approach is that the VPD Size gets set early in the Base OS/Hypervisor Boot and doesn't require that the cxgb4 driver even be available in the Base OS/Hypervisor. Thus PF4 can be exported to a Virtual Machine and everything should work.
--- drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 -------- drivers/pci/quirks.c | 35 +++++++++++++++++------------ 2 files changed, 21 insertions(+), 24 deletions(-)
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c +0 -10
@@ -2596,7 +2596,6 @@ void t4_get_regs(struct adapter *adap, v }#define EEPROM_STAT_ADDR 0x7bfc -#define VPD_SIZE 0x800#define VPD_BASE 0x400#define VPD_BASE_OLD 0#define VPD_LEN 1024
@@ -2634,15 +2633,6 @@ int t4_get_raw_vpd_params(struct adapterif (!vpd)return -ENOMEM ; -/* We have two VPD data structures stored in the adapter VPD area. -* By default, Linux calculates the size of the VPD area by traversing -* the first VPD area at offset 0x0, so we need to tell the OS what -* our real VPD size is. -*/ - ret =pci_set_vpd_size (adapter->pdev,VPD_SIZE ); -if (ret <0 ) - goto out; -/* Card information normally starts at VPD_BASE but early cards had * it at 0. */
drivers/pci/quirks.c +21 -14
@@ -3369,22 +3369,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INstatic void quirk_chelsio_extend_vpd (struct pci_dev *dev) { -pci_set_vpd_size (dev,8192 ); +int chip = (dev->device &0xf000 ) >>12 ; +int func = (dev->device &0x0f00 ) >>8 ; +int prod = (dev->device &0x00ff ) >>0 ; + +/* +* If this is a T3-based adapter, there's a 1KB VPD area at offset +* 0xc00 which contains the preferred VPD values. If this is a T4 or +* later based adapter, the special VPD is at offset 0x400 for the +* Physical Functions (the SR-IOV Virtual Functions have no VPD +* Capabilities). The PCI VPD Access core routines will normally +* compute the size of the VPD by parsing the VPD Data Structure at +* offset 0x000. This will result in silent failures when attempting +* to accesses these other VPD areas which are beyond those computed +* limits. +*/ +if (chip ==0x0 && prod >=0x20 ) +pci_set_vpd_size (dev,8192 ); +else if (chip >=0x4 && func <0x8 ) +pci_set_vpd_size (dev,2048 ); } -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x20 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x21 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x22 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x23 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x24 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x25 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x26 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x30 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x31 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x32 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x35 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x36 , quirk_chelsio_extend_vpd); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,0x37 , quirk_chelsio_extend_vpd); +DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_CHELSIO ,PCI_ANY_ID , + quirk_chelsio_extend_vpd);#ifdef CONFIG_ACPI /*
Greg Kroah-Hartman
maintainerPATCH 13/39 ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
commit b2685bdacdaab065c172b97b55ab46c6be77a037 upstream.
Running io_watchdog_func() while ohci_urb_enqueue() is running can cause a race condition where ohci->prev_frame_no is corrupted and the watchdog can mis-detect following error:
ohci-platform 664a0800.usb: frame counter not updating; disabled ohci-platform 664a0800.usb: HC died; cleaning up
Specifically, following scenario causes a race condition:
1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) and enters the critical section
2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it returns false
3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number read by ohci_frame_no(ohci)
4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, flags) and exits the critical section
6. Later, ohci_urb_enqueue() is called
7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) and enters the critical section
8. The timer scheduled on step 4 expires and io_watchdog_func() runs
9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags) and waits on it because ohci_urb_enqueue() is already in the critical section on step 7
10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it returns false
11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number read by ohci_frame_no(ohci) because the frame number proceeded between step 3 and 6
12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, flags) and exits the critical section, then wake up io_watchdog_func() which is waiting on step 9
14. io_watchdog_func() enters the critical section
15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no variable to the frame number
16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
On step 16, because this calling of io_watchdog_func() is scheduled on step 4, the frame number set in ohci->prev_frame_no is expected to the number set on step 3. However, ohci->prev_frame_no is overwritten on step 11. Because step 16 is executed soon after step 11, the frame number might not proceed, so ohci->prev_frame_no must equals to frame_no.
To address above scenario, this patch introduces a special sentinel value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when the watchdog is not pending or running. When ohci_urb_enqueue() schedules the watchdog (step 4 and 12 above), it compares ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is not overwritten while io_watchdog_func() is running.
--- drivers/usb/host/ohci-hcd.c | 10 +++++++--- drivers/usb/host/ohci-hub.c | 4 +++- 2 files changed, 10 insertions(+), 4 deletions(-)
drivers/usb/host/ohci-hcd.c +7 -3
@@ -73,6 +73,7 @@ static const char hcd_name [] = "ohci_hc#define STATECHANGE_DELAY msecs_to_jiffies(300)#define IO_WATCHDOG_DELAY msecs_to_jiffies(275) +#define IO_WATCHDOG_OFF 0xffffff00#include "ohci.h" #include "pci-quirks.h"
@@ -230,7 +231,7 @@ static int ohci_urb_enqueue ( }/* Start up the I/O watchdog timer, if it's not running */ -if (!timer_pending (&ohci->io_watchdog) && +if (ohci->prev_frame_no ==IO_WATCHDOG_OFF &&list_empty (&ohci->eds_in_use) && !(ohci->flags &OHCI_QUIRK_QEMU )) { ohci->prev_frame_no =ohci_frame_no (ohci);
@@ -501,6 +502,7 @@ static int ohci_init (struct ohci_hcd *osetup_timer (&ohci->io_watchdog, io_watchdog_func, (unsigned long ) ohci); + ohci->prev_frame_no =IO_WATCHDOG_OFF ; ohci->hcca =dma_alloc_coherent (hcd->self.controller,sizeof (*ohci->hcca), &ohci->hcca_dma,GFP_KERNEL );
@@ -730,7 +732,7 @@ static void io_watchdog_func(unsigned lou32 head;struct ed *ed;struct td *td, *td_start, *td_next; -unsigned frame_no; +unsigned frame_no, prev_frame_no =IO_WATCHDOG_OFF ;unsigned long flags;spin_lock_irqsave (&ohci->lock, flags);
@@ -835,7 +837,7 @@ static void io_watchdog_func(unsigned lo } }if (!list_empty (&ohci->eds_in_use)) { - ohci->prev_frame_no = frame_no; + prev_frame_no = frame_no; ohci->prev_wdh_cnt = ohci->wdh_cnt; ohci->prev_donehead =ohci_readl (ohci, &ohci->regs->donehead);
@@ -845,6 +847,7 @@ static void io_watchdog_func(unsigned lo } done: + ohci->prev_frame_no = prev_frame_no;spin_unlock_irqrestore (&ohci->lock, flags); }
@@ -973,6 +976,7 @@ static void ohci_stop (struct usb_hcd *hif (quirk_nec (ohci))flush_work (&ohci->nec_work);del_timer_sync (&ohci->io_watchdog); + ohci->prev_frame_no =IO_WATCHDOG_OFF ;ohci_writel (ohci,OHCI_INTR_MIE , &ohci->regs->intrdisable);ohci_usb_reset (ohci);
drivers/usb/host/ohci-hub.c +3 -1
@@ -310,8 +310,10 @@ static int ohci_bus_suspend (struct usb_ rc =ohci_rh_suspend (ohci,0 );spin_unlock_irq (&ohci->lock); -if (rc ==0 ) +if (rc ==0 ) {del_timer_sync (&ohci->io_watchdog); + ohci->prev_frame_no =IO_WATCHDOG_OFF ; + }return rc; }
Greg Kroah-Hartman
maintainerPATCH 14/39 usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: AMAN DEEP <[email protected]>
commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
There is a race condition between finish_unlinks->finish_urb() function and usb_kill_urb() in ohci controller case. The finish_urb calls spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call, then if during this time, usb_kill_urb is called for another endpoint, then new ed will be added to ed_rm_list at beginning for unlink, and ed_rm_list will point to newly added.
When finish_urb() is completed in finish_unlinks() and ed->td_list becomes empty as in below code (in finish_unlinks() function):
if (list_empty(&ed->td_list)) {
*last = ed->ed_next;
ed->ed_next = NULL;
} else if (ohci->rh_state == OHCI_RH_RUNNING) {
*last = ed->ed_next;
ed->ed_next = NULL;
ed_schedule(ohci, ed);
}The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next and previously added ed by usb_kill_urb will be left unreferenced by ed_rm_list. This causes usb_kill_urb() hang forever waiting for finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal of ed from ed_rm_list in the beginning during usb_kill_urb and later last* is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
--- drivers/usb/host/ohci-q.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
drivers/usb/host/ohci-q.c +10 -7
@@ -1018,6 +1018,8 @@ skip_ed:* have modified this list. normally it's just prepending * entries (which we'd ignore), but paranoia won't hurt. */ + *last = ed->ed_next; + ed->ed_next =NULL ; modified =0 ;/* unlink urbs as requested, but rescan the list after
@@ -1076,21 +1078,22 @@ rescan_this: goto rescan_this;/* -* If no TDs are queued, take ED off the ed_rm_list. +* If no TDs are queued, ED is now idle. * Otherwise, if the HC is running, reschedule. -* If not, leave it on the list for further dequeues. +* If the HC isn't running, add ED back to the +* start of the list for later processing. */ if (list_empty (&ed->td_list)) { - *last = ed->ed_next; - ed->ed_next =NULL ; ed->state =ED_IDLE ;list_del (&ed->in_use_list); }else if (ohci->rh_state ==OHCI_RH_RUNNING ) { - *last = ed->ed_next; - ed->ed_next =NULL ;ed_schedule (ohci, ed); }else { - last = &ed->ed_next; + ed->ed_next = ohci->ed_rm_list; + ohci->ed_rm_list = ed; +/* Don't loop on the same ED */ +if (last == &ohci->ed_rm_list) + last = &ed->ed_next; }if (modified)
Greg Kroah-Hartman
maintainerPATCH 15/39 arm64: Disable unhandled signal log messages by default
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Weiser <[email protected]>
commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
aarch64 unhandled signal kernel messages are very verbose, suggesting them to be more of a debugging aid:
sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G W 4.15.0-rc3+ #3 Hardware name: linux,dummy-virt (DT) pstate: 60000000 (nZCv daif -PAN -UAO) pc : 0x4003f4 lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008 x9 : 000000000000000f x8 : ffffffffffffffff x7 : 0004000000000000 x6 : ffffffffffffffff x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000004003e4 x2 : 0000fffffe94a1e8 x1 : 000000000000000a x0 : 0000000000000000
Disable them by default, so they can be enabled using /proc/sys/debug/exception-trace.
--- arch/arm64/kernel/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/traps.c +1 -1
@@ -50,7 +50,7 @@ static const char *handler[]= { "Error" }; -int show_unhandled_signals =1 ; +int show_unhandled_signals =0 ;/* * Dump out the contents of some kernel memory nicely...
Greg Kroah-Hartman
maintainerPATCH 16/39 Add delay-init quirk for Corsair K70 RGB keyboards
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jack Stocker <[email protected]>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
--- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/core/quirks.c +3 -0
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu { USB_DEVICE(0x1a0a, 0x0200), .driver_info = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, + /* Corsair K70 RGB */ + { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT }, + /* Corsair Strafe RGB */ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Greg Kroah-Hartman
maintainerPATCH 17/39 drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support 6bpc instead of 8 bpc.
Hence, use 6 bpc quirk for this panel.
--- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/drm_edid.c +3 -0
@@ -107,6 +107,9 @@ static const struct edid_quirk {/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */ { "AEO", 0, EDID_QUIRK_FORCE_6BPC }, +/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */ + { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC }, +/* Belinea 10 15 55 */ { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 }, { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Greg Kroah-Hartman
maintainerPATCH 18/39 usb: dwc3: gadget: Set maxpacket size for ep0 IN
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thinh Nguyen <[email protected]>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver only updates the OUT direction control endpoint structure during ConnectDone event. DWC3 driver needs to update the endpoint max packet size for control IN endpoint as well. If the max packet size is not properly set, then the driver will incorrectly calculate the data transfer size and fail to send ZLP for HS/FS 3-stage control read transfer.
The fix is simply to update the max packet size for the ep0 IN direction during ConnectDone event.
--- drivers/usb/dwc3/gadget.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/dwc3/gadget.c +2 -0
@@ -2528,6 +2528,8 @@ static void dwc3_gadget_conndone_interrubreak ; } + dwc->eps[1 ]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket; +/* Enable USB2 LPM Capability */ if ((dwc->revision > DWC3_REVISION_194A) &&
Greg Kroah-Hartman
maintainerPATCH 19/39 usb: ldusb: add PIDs for new CASSY devices supported by this driver
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karsten Koop <[email protected]>
commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
This patch adds support for new CASSY devices to the ldusb driver. The PIDs are also added to the ignore list in hid-quirks.
--- drivers/hid/hid-core.c | 3 +++ drivers/hid/hid-ids.h | 3 +++ drivers/usb/misc/ldusb.c | 6 ++++++ 3 files changed, 12 insertions(+)
drivers/hid/hid-core.c +3 -0
@@ -2443,6 +2443,9 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) }, + { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) }, { HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
drivers/hid/hid-ids.h +3 -0
@@ -608,6 +608,9 @@#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033#define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035#define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038 +#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040 +#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042 +#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043#define USB_DEVICE_ID_LD_JWM 0x1080#define USB_DEVICE_ID_LD_DMMP 0x1081#define USB_DEVICE_ID_LD_UMIP 0x1090
drivers/usb/misc/ldusb.c +6 -0
@@ -46,6 +46,9 @@#define USB_DEVICE_ID_LD_MICROCASSYTIME 0x1033/* USB Product ID of Micro-CASSY Time (reserved) */ #define USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE 0x1035/* USB Product ID of Micro-CASSY Temperature */ #define USB_DEVICE_ID_LD_MICROCASSYPH 0x1038/* USB Product ID of Micro-CASSY pH */ +#define USB_DEVICE_ID_LD_POWERANALYSERCASSY 0x1040/* USB Product ID of Power Analyser CASSY */ +#define USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY 0x1042/* USB Product ID of Converter Controller CASSY */ +#define USB_DEVICE_ID_LD_MACHINETESTCASSY 0x1043/* USB Product ID of Machine Test CASSY */ #define USB_DEVICE_ID_LD_JWM 0x1080/* USB Product ID of Joule and Wattmeter */ #define USB_DEVICE_ID_LD_DMMP 0x1081/* USB Product ID of Digital Multimeter P (reserved) */ #define USB_DEVICE_ID_LD_UMIP 0x1090/* USB Product ID of UMI P */
@@ -88,6 +91,9 @@ static const struct usb_device_id ld_usb { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTIME) }, { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYTEMPERATURE) }, { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MICROCASSYPH) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_POWERANALYSERCASSY) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_CONVERTERCONTROLLERCASSY) }, + { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MACHINETESTCASSY) }, { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_JWM) }, { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_DMMP) }, { USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_UMIP) },
Greg Kroah-Hartman
maintainerPATCH 20/39 Revert "usb: musb: host: dont start next rx urb if current one failed"
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bin Liu <[email protected]>
commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream.
This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed") along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set") try to solve the issue described in [1], but the latter alone is sufficient, and the former causes the issue as in [2], so now revert it.
[1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
[2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
--- drivers/usb/musb/musb_host.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
drivers/usb/musb/musb_host.c +1 -7
@@ -418,13 +418,7 @@ static void musb_advance_schedule(struct } } -/* -* The pipe must be broken if current urb->status is set, so don't -* start next urb. -* TODO: to minimize the risk of regression, only check urb->status -* for RX, until we have a test case to understand the behavior of TX. -*/ -if ((!status || !is_in) && qh && qh->is_ready) { +if (qh !=NULL && qh->is_ready) {musb_dbg (musb,"... next ep%d %cX urb %p" , hw_ep->epnum, is_in ?'R' :'T' ,next_urb (qh));musb_start_urb (musb, is_in, qh);
Greg Kroah-Hartman
maintainerPATCH 21/39 usb: gadget: f_fs: Process all descriptors during bind
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jack Pham <[email protected]>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated to prepare for binding with the gadget in order to allocate endpoints and optionally set up OS descriptors. However, the high- and super-speed descriptors are only parsed based on whether the gadget_is_dualspeed() and gadget_is_superspeed() calls are true, respectively.
This is a problem in case a userspace program always provides all of the {full,high,super,OS} descriptors when configuring a function. Then, for example if a gadget device is not capable of SuperSpeed, the call to ffs_do_descs() for the SS descriptors is skipped, resulting in an incorrect offset calculation for the vla_ptr when moving on to the OS descriptors that follow. This causes ffs_do_os_descs() to fail as it is now looking at the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally, so remove the checks for gadget speed.
--- drivers/usb/gadget/function/f_fs.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/usb/gadget/function/f_fs.c +2 -4
@@ -2956,10 +2956,8 @@ static int _ffs_func_bind(struct usb_construct ffs_data *ffs = func->ffs;const int full = !!func->ffs->fs_descs_count; -const int high =gadget_is_dualspeed (func->gadget) && - func->ffs->hs_descs_count; -const int super =gadget_is_superspeed (func->gadget) && - func->ffs->ss_descs_count; +const int high = !!func->ffs->hs_descs_count; +const int super = !!func->ffs->ss_descs_count;int fs_len, hs_len, ss_len, ret, i;struct ffs_ep *eps_ptr;
Greg Kroah-Hartman
maintainerPATCH 22/39 usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
This fixes an issue that a gadget driver (usb_f_fs) is possible to stop rx transactions after the usb-dmac is used because the following functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not start the transaction because the "running" flag is 0.
--- drivers/usb/renesas_usbhs/fifo.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/renesas_usbhs/fifo.c +5 -0
@@ -1001,6 +1001,10 @@ static int usbhsf_dma_prepare_pop_with_uif ((uintptr_t )pkt->buf & (USBHS_USB_DMAC_XFER_SIZE -1 )) goto usbhsf_pio_prepare_pop; +/* return at this time if the pipe is running */ +if (usbhs_pipe_is_running (pipe)) +return 0 ; +usbhs_pipe_config_change_bfre (pipe,1 ); ret =usbhsf_fifo_select (pipe, fifo,0 );
@@ -1191,6 +1195,7 @@ static int usbhsf_dma_pop_done_with_usb_usbhsf_fifo_clear (pipe, fifo); pkt->actual =usbhs_dma_calc_received_size (pkt, chan, rcv_len); +usbhs_pipe_running (pipe,0 );usbhsf_dma_stop (pipe, fifo);usbhsf_dma_unmap (pkt);usbhsf_fifo_unselect (pipe, pipe->fifo);
Greg Kroah-Hartman
maintainerPATCH 23/39 drm/amdgpu: Add dpm quirk for Jet PRO (v2)
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.
Fixes stability issues.
v2: clamp sclk to 600 Mhz
--- drivers/gpu/drm/amd/amdgpu/si_dpm.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/amd/amdgpu/si_dpm.c +5 -0
@@ -3507,6 +3507,11 @@ static void si_apply_state_adjust_rules( max_sclk =75000 ; max_mclk =80000 ; } +if ((adev->pdev->revision ==0xC3 ) || + (adev->pdev->device ==0x6665 )) { + max_sclk =60000 ; + max_mclk =80000 ; + } }else if (adev->asic_type ==CHIP_OLAND ) { if ((adev->pdev->revision == 0xC7) || (adev->pdev->revision == 0x80) ||
Greg Kroah-Hartman
maintainerPATCH 24/39 drm/amdgpu: add atpx quirk handling (v2)
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 052c299080cd6859f82a8154a7a673fafabe644c upstream.
Add quirks for handling PX/HG systems. In this case, add a quirk for a weston dGPU that only seems to properly power down using ATPX power control rather than HG (_PR3).
v2: append a new weston XT
--- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 57 ++++++++++++++++++++--- 1 file changed, 50 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +50 -7
@@ -14,6 +14,16 @@#include "amd_acpi.h" +#define AMDGPU_PX_QUIRK_FORCE_ATPX (1 << 0) + +struct amdgpu_px_quirk { +u32 chip_vendor; +u32 chip_device; +u32 subsys_vendor; +u32 subsys_device; +u32 px_quirk_flags; +}; +struct amdgpu_atpx_functions {bool px_params;bool power_cntl;
@@ -35,6 +45,7 @@ struct amdgpu_atpx { static struct amdgpu_atpx_priv { bool atpx_detected; bool bridge_pm_usable; + unsigned int quirks; /* handle for device - and atpx */ acpi_handle dhandle; acpi_handle other_handle;
@@ -205,13 +216,19 @@ static int amdgpu_atpx_validate(struct a atpx->is_hybrid = false;if (valid_bits &ATPX_MS_HYBRID_GFX_SUPPORTED ) { -printk ("ATPX Hybrid Graphics\n" ); -/* -* Disable legacy PM methods only when pcie port PM is usable, -* otherwise the device might fail to power off or power on. -*/ - atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable; - atpx->is_hybrid = true; +if (amdgpu_atpx_priv.quirks &AMDGPU_PX_QUIRK_FORCE_ATPX ) { +printk ("ATPX Hybrid Graphics, forcing to ATPX\n" ); + atpx->functions.power_cntl = true; + atpx->is_hybrid = false; + }else { +printk ("ATPX Hybrid Graphics\n" ); +/* +* Disable legacy PM methods only when pcie port PM is usable, +* otherwise the device might fail to power off or power on. +*/ + atpx->functions.power_cntl = !amdgpu_atpx_priv.bridge_pm_usable; + atpx->is_hybrid = true; + } } atpx->dgpu_req_power_for_displays = false;
@@ -547,6 +564,30 @@ static const struct vga_switcheroo_handl .get_client_id = amdgpu_atpx_get_client_id, }; +static const struct amdgpu_px_quirk amdgpu_px_quirk_list[] = { +/* HG _PR3 doesn't seem to work on this A+A weston board */ + {0x1002 ,0x6900 ,0x1002 ,0x0124 ,AMDGPU_PX_QUIRK_FORCE_ATPX }, + {0x1002 ,0x6900 ,0x1028 ,0x0812 ,AMDGPU_PX_QUIRK_FORCE_ATPX }, + {0 ,0 ,0 ,0 ,0 }, +}; + +static void amdgpu_atpx_get_quirks (struct pci_dev *pdev) +{ +const struct amdgpu_px_quirk *p = amdgpu_px_quirk_list; + +/* Apply PX quirks */ +while (p && p->chip_device !=0 ) { +if (pdev->vendor == p->chip_vendor && + pdev->device == p->chip_device && + pdev->subsystem_vendor == p->subsys_vendor && + pdev->subsystem_device == p->subsys_device) { + amdgpu_atpx_priv.quirks |= p->px_quirk_flags; +break ; + } + ++p; + } +} +/** * amdgpu_atpx_detect - detect whether we have PX *
@@ -570,6 +611,7 @@ static bool amdgpu_atpx_detect(void) parent_pdev =pci_upstream_bridge (pdev); d3_supported |= parent_pdev && parent_pdev->bridge_d3; +amdgpu_atpx_get_quirks (pdev); }while ((pdev =pci_get_class (PCI_CLASS_DISPLAY_OTHER <<8 , pdev)) !=NULL ) {
@@ -579,6 +621,7 @@ static bool amdgpu_atpx_detect(void) parent_pdev =pci_upstream_bridge (pdev); d3_supported |= parent_pdev && parent_pdev->bridge_d3; +amdgpu_atpx_get_quirks (pdev); }if (has_atpx && vga_count ==2 ) {
Greg Kroah-Hartman
maintainerPATCH 25/39 drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
We only support vga_switcheroo and runtime pm on PX/HG systems so forcing runpm to 1 doesn't do anything useful anyway.
Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so that the cleanup path is correct as well. This mirrors what radeon does as well.
v2: rework the patch originally sent by Lukas (Alex)
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -- 1 file changed, 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +0 -2
@@ -1678,8 +1678,6 @@ int amdgpu_device_init(struct amdgpu_dev* ignore it */ vga_client_register (adev->pdev, adev,NULL , amdgpu_vga_set_decode); -if (amdgpu_runtime_pm ==1 ) - runtime = true;if (amdgpu_device_is_px (ddev)) runtime = true;vga_switcheroo_register_client (adev->pdev, &amdgpu_switcheroo_ops, runtime);
Greg Kroah-Hartman
maintainerPATCH 26/39 drm/amdgpu: add new device to use atpx quirk
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.
The affected system (0x0813) is pretty similar to another one (0x0812), it also needs to use ATPX power control.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c +1 -0
@@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk amdg/* HG _PR3 doesn't seem to work on this A+A weston board */ { 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX }, { 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX }, + { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX }, { 0, 0, 0, 0, 0 }, };
Greg Kroah-Hartman
maintainerPATCH 27/39 binder: add missing binder_unlock()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
When commit 4be5a2810489 ("binder: check for binder_thread allocation failure in binder_poll()") was applied to 4.4-stable and 4.9-stable it was forgotten to release the global binder lock in the new error path. The global binder lock wasn't removed until v4.14, by commit a60b890f607d ("binder: remove global binder lock").
Fix the new error path to release the lock.
--- drivers/android/binder.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/android/binder.c +3 -1
@@ -2628,8 +2628,10 @@ static unsigned int binder_poll(struct fbinder_lock (__func__); thread =binder_get_thread (proc); -if (!thread) +if (!thread) { +binder_unlock (__func__);return POLLERR ; + } wait_for_proc_work = thread->transaction_stack ==NULL &&list_empty (&thread->todo) && thread->return_error ==BR_OK ;
Greg Kroah-Hartman
maintainerPATCH 28/39 X.509: fix NULL dereference when restricting key with unsupported_sig
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream.
The asymmetric key type allows an X.509 certificate to be added even if its signature's hash algorithm is not available in the crypto API. In that case 'payload.data[asym_auth]' will be NULL. But the key restriction code failed to check for this case before trying to use the signature, resulting in a NULL pointer dereference in key_or_keyring_common() or in restrict_link_by_signature().
Fix this by returning -ENOPKG when the signature is unsupported.
Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and keyctl has support for the 'restrict_keyring' command:
keyctl new_session
keyctl restrict_keyring @s asymmetric builtin_trusted openssl req -new -sha512 -x509 -batch -nodes -outform der \
| keyctl padd asymmetric desc @s
--- crypto/asymmetric_keys/restrict.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
crypto/asymmetric_keys/restrict.c +5 -2
@@ -66,8 +66,9 @@ __setup("ca_keys=", ca_keys_setup);* * Returns 0 if the new certificate was accepted, -ENOKEY if we couldn't find a * matching parent certificate in the trusted list, -EKEYREJECTED if the -* signature check fails or the key is blacklisted and some other error if -* there is a matching certificate but the signature check cannot be performed. +* signature check fails or the key is blacklisted, -ENOPKG if the signature +* uses unsupported crypto, or some other error if there is a matching +* certificate but the signature check cannot be performed. */ int restrict_link_by_signature(struct key *trust_keyring, const struct key_type *type,
@@ -86,6 +87,8 @@ int restrict_link_by_signature(struct kereturn -EOPNOTSUPP ; sig = payload->data[asym_auth]; +if (!sig) +return -ENOPKG ;if (!sig->auth_ids[0 ] && !sig->auth_ids[1 ])return -ENOKEY ;
Greg Kroah-Hartman
maintainerPATCH 29/39 mm: avoid spurious bad pmd warning messages
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Zwisler <[email protected]>
commit d0f0931de936a0a468d7e59284d39581c16d3a73 upstream.
When the pmd_devmap() checks were added by 5c7fb56e5e3f ("mm, dax:
dax-pmd vs thp-pmd vs hugetlbfs-pmd") to add better support for DAX huge pages, they were all added to the end of if() statements after existing pmd_trans_huge() checks. So, things like:
- if (pmd_trans_huge(*pmd))
+ if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
When further checks were added after pmd_trans_unstable() checks by commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map") they were also added at the end of the conditional:
+ if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
This ordering is fine for pmd_trans_huge(), but doesn't work for pmd_trans_unstable(). This is because DAX huge pages trip the bad_pmd() check inside of pmd_none_or_trans_huge_or_clear_bad() (called by pmd_trans_unstable()), which prints out a warning and returns 1. So, we do end up doing the right thing, but only after spamming dmesg with suspicious looking messages:
mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
Reorder these checks in a helper so that pmd_devmap() is checked first, avoiding the error messages, and add a comment explaining why the ordering is important.
--- mm/memory.c | 40 ++++++++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 10 deletions(-)
mm/memory.c +30 -10
@@ -2848,6 +2848,17 @@ static int __do_fault(struct fault_env *return ret; } +/* +* The ordering of these checks is important for pmds with _PAGE_DEVMAP set. +* If we check pmd_trans_unstable() first we will trip the bad_pmd() check +* inside of pmd_none_or_trans_huge_or_clear_bad(). This will end up correctly +* returning 1 but not before it spams dmesg with the pmd_clear_bad() output. +*/ +static int pmd_devmap_trans_unstable (pmd_t *pmd) +{ +return pmd_devmap (*pmd) ||pmd_trans_unstable (pmd); +} +static int pte_alloc_one_map (struct fault_env *fe) {struct vm_area_struct *vma = fe->vma;
@@ -2871,18 +2882,27 @@ static int pte_alloc_one_map(struct faul map_pte:/* * If a huge pmd materialized under us just retry later. Use -* pmd_trans_unstable() instead of pmd_trans_huge() to ensure the pmd -* didn't become pmd_trans_huge under us and then back to pmd_none, as -* a result of MADV_DONTNEED running immediately after a huge pmd fault -* in a different thread of this mm, in turn leading to a misleading -* pmd_trans_huge() retval. All we have to ensure is that it is a -* regular pmd that we can walk with pte_offset_map() and we can do that -* through an atomic read in C, which is what pmd_trans_unstable() -* provides. +* pmd_trans_unstable() via pmd_devmap_trans_unstable() instead of +* pmd_trans_huge() to ensure the pmd didn't become pmd_trans_huge +* under us and then back to pmd_none, as a result of MADV_DONTNEED +* running immediately after a huge pmd fault in a different thread of +* this mm, in turn leading to a misleading pmd_trans_huge() retval. +* All we have to ensure is that it is a regular pmd that we can walk +* with pte_offset_map() and we can do that through an atomic read in +* C, which is what pmd_trans_unstable() provides. */ -if (pmd_trans_unstable (fe->pmd) ||pmd_devmap (*fe->pmd)) +if (pmd_devmap_trans_unstable (fe->pmd))return VM_FAULT_NOPAGE ; +/* +* At this point we know that our vmf->pmd points to a page of ptes +* and it cannot become pmd_none(), pmd_devmap() or pmd_trans_huge() +* for the duration of the fault. If a racing MADV_DONTNEED runs and +* we zap the ptes pointed to by our vmf->pmd, the vmf->ptl will still +* be valid and we will re-check to make sure the vmf->pte isn't +* pte_none() under vmf->ptl protection when we return to +* alloc_set_pte(). +*/ fe->pte =pte_offset_map_lock (vma->vm_mm, fe->pmd, fe->address, &fe->ptl);return 0 ;
@@ -3456,7 +3476,7 @@ static int handle_pte_fault(struct fault fe->pte =NULL ; }else {/* See comment in pte_alloc_one_map() */ -if (pmd_trans_unstable (fe->pmd) ||pmd_devmap (*fe->pmd)) +if (pmd_devmap_trans_unstable (fe->pmd))return 0 ;/* * A regular pmd is established and it can't morph into a huge
Greg Kroah-Hartman
maintainerPATCH 30/39 fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 1eb643d02b21412e603b42cdd96010a2ac31c05f upstream.
dax_writeback_mapping_range() fails to update iteration index when searching radix tree for entries needing cache flushing. Thus each pagevec worth of entries is searched starting from the start which is inefficient and prone to livelocks. Update index properly.
--- fs/dax.c | 1 + 1 file changed, 1 insertion(+)
fs/dax.c +1 -0
@@ -785,6 +785,7 @@ int dax_writeback_mapping_range(struct aif (ret <0 )return ret; } + start_index = indices[pvec.nr -1 ] +1 ; }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 31/39 libnvdimm: fix integer overflow static analysis warning
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream.
Dan reports:
The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the following static checker warning:
drivers/nvdimm/bus.c:1018 __nd_ioctl()
warn: integer overflows 'buf_len'
From a casual review, this seems like it might be a real bug. On the first iteration we load some data into in_env[]. On the second iteration we read a use controlled "in_size" from nd_cmd_in_size(). It can go up to UINT_MAX - 1. A high number means we will fill the whole in_env[] buffer. But we potentially keep looping and adding more to in_len so now it can be any value.
It simple enough to change, but it feels weird that we keep looping even though in_env is totally full. Shouldn't we just return an error if we don't have space for desc->in_num.
We keep looping because the size of the total input is allowed to be bigger than the 'envelope' which is a subset of the payload that tells us how much data to expect. For safety explicitly check that buf_len does not overflow which is what the checker flagged.
--- drivers/nvdimm/bus.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/nvdimm/bus.c +6 -5
@@ -812,16 +812,17 @@ static int __nd_ioctl(struct nvdimm_bus int read_only, unsigned int ioctl_cmd, unsigned long arg) { struct nvdimm_bus_descriptor *nd_desc = nvdimm_bus->nd_desc; -size_t buf_len =0 , in_len =0 , out_len =0 ;static char out_env[ND_CMD_MAX_ENVELOPE ];static char in_env[ND_CMD_MAX_ENVELOPE ];const struct nd_cmd_desc *desc =NULL ;unsigned int cmd =_IOC_NR (ioctl_cmd);void __user *p = (void __user *) arg;struct device *dev = &nvdimm_bus->dev; -struct nd_cmd_pkg pkg;const char *cmd_name, *dimm_name; +u32 in_len =0 , out_len =0 ;unsigned long cmd_mask; +struct nd_cmd_pkg pkg; +u64 buf_len =0 ;void *buf;int rc, i;
@@ -882,7 +883,7 @@ static int __nd_ioctl(struct nvdimm_bus }if (cmd ==ND_CMD_CALL ) { -dev_dbg (dev,"%s:%s, idx: %llu, in: %zu, out: %zu, len %zu\n" , +dev_dbg (dev,"%s:%s, idx: %llu, in: %u, out: %u, len %llu\n" , __func__, dimm_name, pkg.nd_command, in_len, out_len, buf_len);
@@ -912,9 +913,9 @@ static int __nd_ioctl(struct nvdimm_bus out_len += out_size; } - buf_len = out_len + in_len; + buf_len = (u64 ) out_len + (u64 ) in_len;if (buf_len >ND_IOCTL_MAX_BUFLEN ) { -dev_dbg (dev,"%s:%s cmd: %s buf_len: %zu > %d\n" , __func__, +dev_dbg (dev,"%s:%s cmd: %s buf_len: %llu > %d\n" , __func__, dimm_name, cmd_name, buf_len,ND_IOCTL_MAX_BUFLEN );return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 32/39 device-dax: implement ->split() to catch invalid munmap attempts
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 9702cffdbf2129516db679e4467db81e1cd287da upstream.
Similar to how device-dax enforces that the 'address', 'offset', and 'len' parameters to mmap() be aligned to the device's fundamental alignment, the same constraints apply to munmap(). Implement ->split() to fail munmap calls that violate the alignment constraint.
Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path with crash signatures of the form:
vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
next (null) prev (null) mm ffff8800b61150c0
prot 8000000000000027 anon_vma (null) vm_ops ffffffffa0091240
pgoff 0 file ffff8800b638ef80 private_data (null)
flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:2014!
[..]
RIP: 0010:__split_huge_pud+0x12a/0x180
[..]
Call Trace:
unmap_page_range+0x245/0xa40
? __vma_adjust+0x301/0x990
unmap_vmas+0x4c/0xa0
unmap_region+0xae/0x120
? __vma_rb_erase+0x11a/0x230
do_munmap+0x276/0x410
vm_munmap+0x6a/0xa0
SyS_munmap+0x1d/0x30--- drivers/dax/dax.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/dax/dax.c +12 -0
@@ -453,9 +453,21 @@ static int dax_dev_pmd_fault(struct vm_areturn rc; } +static int dax_dev_split (struct vm_area_struct *vma,unsigned long addr) +{ +struct file *filp = vma->vm_file; +struct dax_dev *dax_dev = filp->private_data; +struct dax_region *dax_region = dax_dev->region; + +if (!IS_ALIGNED (addr, dax_region->align)) +return -EINVAL ; +return 0 ; +} +static const struct vm_operations_struct dax_dev_vm_ops = { .fault = dax_dev_fault, .pmd_fault = dax_dev_pmd_fault, + .split = dax_dev_split, };static int dax_mmap (struct file *filp,struct vm_area_struct *vma)
Greg Kroah-Hartman
maintainerPATCH 33/39 mm: introduce get_user_pages_longterm
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.
Patch series "introduce get_user_pages_longterm()", v2.
Here is a new get_user_pages api for cases where a driver intends to keep an elevated page count indefinitely. This is distinct from usages like iov_iter_get_pages where the elevated page counts are transient. The iov_iter_get_pages cases immediately turn around and submit the pages to a device driver which will put_page when the i/o operation completes (under kernel control).
In the longterm case userspace is responsible for dropping the page reference at some undefined point in the future. This is untenable for filesystem-dax case where the filesystem is in control of the lifetime of the block / page and needs reasonable limits on how long it can wait for pages in a mapping to become idle.
Fixing filesystems to actually wait for dax pages to be idle before blocks from a truncate/hole-punch operation are repurposed is saved for a later patch series.
Also, allowing longterm registration of dax mappings is a future patch series that introduces a "map with lease" semantic where the kernel can revoke a lease and force userspace to drop its page references.
I have also tagged these for -stable to purposely break cases that might assume that longterm memory registrations for filesystem-dax mappings were supported by the kernel. The behavior regression this policy change implies is one of the reasons we maintain the "dax enabled.
Warning: EXPERIMENTAL, use at your own risk" notification when mounting a filesystem in dax mode.
It is worth noting the device-dax interface does not suffer the same constraints since it does not support file space management operations like hole-punch.
This patch (of 4):
Until there is a solution to the dma-to-dax vs truncate problem it is not safe to allow long standing memory registrations against filesytem-dax vmas. Device-dax vmas do not have this problem and are explicitly allowed.
This is temporary until a "memory registration with layout-lease" mechanism can be implemented for the affected sub-systems (RDMA and V4L2).
--- include/linux/dax.h | 5 ---- include/linux/fs.h | 20 ++++++++++++++++ include/linux/mm.h | 13 ++++++++++ mm/gup.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 97 insertions(+), 5 deletions(-)
include/linux/dax.h +0 -5
@@ -61,11 +61,6 @@ static inline int dax_pmd_fault(struct vint dax_pfn_mkwrite (struct vm_area_struct *,struct vm_fault *);#define dax_mkwrite (vma, vmf, gb) dax_fault(vma, vmf, gb) -static inline bool vma_is_dax (struct vm_area_struct *vma) -{ -return vma->vm_file &&IS_DAX (vma->vm_file->f_mapping->host); -} -static inline bool dax_mapping (struct address_space *mapping) {return mapping->host &&IS_DAX (mapping->host);
include/linux/fs.h +20 -0
@@ -18,6 +18,7 @@#include <linux/bug.h> #include <linux/mutex.h> #include <linux/rwsem.h> +#include <linux/mm_types.h> #include <linux/capability.h> #include <linux/semaphore.h> #include <linux/fiemap.h>
@@ -3033,6 +3034,25 @@ static inline bool io_is_direct(struct freturn (filp->f_flags &O_DIRECT ) ||IS_DAX (filp->f_mapping->host); } +static inline bool vma_is_dax (struct vm_area_struct *vma) +{ +return vma->vm_file &&IS_DAX (vma->vm_file->f_mapping->host); +} + +static inline bool vma_is_fsdax (struct vm_area_struct *vma) +{ +struct inode *inode; + +if (!vma->vm_file) +return false; +if (!vma_is_dax (vma)) +return false; + inode =file_inode (vma->vm_file); +if (inode->i_mode ==S_IFCHR ) +return false;/* device-dax */ +return true; +} +static inline int iocb_flags (struct file *file) {int res =0 ;
include/linux/mm.h +13 -0
@@ -1288,6 +1288,19 @@ long __get_user_pages_unlocked(struct ta struct page **pages, unsigned int gup_flags);long get_user_pages_unlocked (unsigned long start,unsigned long nr_pages,struct page **pages,unsigned int gup_flags); +#ifdef CONFIG_FS_DAX +long get_user_pages_longterm (unsigned long start,unsigned long nr_pages, +unsigned int gup_flags,struct page **pages, +struct vm_area_struct **vmas); +#else +static inline long get_user_pages_longterm (unsigned long start, +unsigned long nr_pages,unsigned int gup_flags, +struct page **pages,struct vm_area_struct **vmas) +{ +return get_user_pages (start, nr_pages, gup_flags, pages, vmas); +} +#endif /* CONFIG_FS_DAX */ +int get_user_pages_fast (unsigned long start,int nr_pages,int write,struct page **pages);
mm/gup.c +64 -0
70 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 34/39 v4l2: disable filesystem-dax mapping support
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit b70131de648c2b997d22f4653934438013f407a1 upstream.
V4L2 memory registrations are incompatible with filesystem-dax that needs the ability to revoke dma access to a mapping at will, or otherwise allow the kernel to wait for completion of DMA. The filesystem-dax implementation breaks the traditional solution of truncate of active file backed mappings since there is no page-cache page we can orphan to sustain ongoing DMA.
If v4l2 wants to support long lived DMA mappings it needs to arrange to hold a file lease or use some other mechanism so that the kernel can coordinate revoking DMA access when the filesystem needs to truncate mappings.
--- drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/media/v4l2-core/videobuf-dma-sg.c +3 -2
@@ -185,12 +185,13 @@ static int videobuf_dma_init_user_lockeddprintk (1 ,"init user [0x%lx+0x%lx => %d pages]\n" , data, size, dma->nr_pages); - err =get_user_pages (data &PAGE_MASK , dma->nr_pages, + err =get_user_pages_longterm (data &PAGE_MASK , dma->nr_pages, flags, dma->pages,NULL );if (err != dma->nr_pages) { dma->nr_pages = (err >=0 ) ? err :0 ; -dprintk (1 ,"get_user_pages: err=%d [%d]\n" , err, dma->nr_pages); +dprintk (1 ,"get_user_pages_longterm: err=%d [%d]\n" , err, + dma->nr_pages);return err <0 ? err : -EINVAL ; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 35/39 IB/core: disable memory registration of filesystem-dax vmas
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 5f1d43de54164dcfb9bfa542fcc92c1e1a1b6c1d upstream.
Until there is a solution to the dma-to-dax vs truncate problem it is not safe to allow RDMA to create long standing memory registrations against filesytem-dax vmas.
--- drivers/infiniband/core/umem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/core/umem.c +1 -1
@@ -193,7 +193,7 @@ struct ib_umem *ib_umem_get(struct ib_uc sg_list_start = umem->sg_head.sgl;while (npages) { - ret =get_user_pages (cur_base, + ret =get_user_pages_longterm (cur_base, min_t(unsigned long, npages,PAGE_SIZE /sizeof (struct page *)), gup_flags, page_list, vma_list);
Greg Kroah-Hartman
maintainerPATCH 36/39 libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 41fce90f26333c4fa82e8e43b9ace86c4e8a0120 upstream.
The following namespace configuration attempt:
# ndctl create-namespace -e namespace0.0 -m devdax -a 1G -f
libndctl: ndctl_dax_enable: dax0.1: failed to enable
Error: namespace0.0: failed to enablefailed to reconfigure namespace: No such device or address
...fails when the backing memory range is not physically aligned to 1G:
# cat /proc/iomem | grep Persistent
210000000-30fffffff : Persistent Memory (legacy)In the above example the 4G persistent memory range starts and ends on a 256MB boundary.
We handle this case correctly when needing to handle cases that violate section alignment (128MB) collisions against "System RAM", and we simply need to extend that padding/truncation for the 1GB alignment use case.
--- drivers/nvdimm/pfn_devs.c | 15 ++++++++++++--- include/linux/kernel.h | 1 + 2 files changed, 13 insertions(+), 3 deletions(-)
drivers/nvdimm/pfn_devs.c +12 -3
@@ -563,6 +563,12 @@ static struct vmem_altmap *__nvdimm_setureturn altmap; } +static u64 phys_pmem_align_down (struct nd_pfn *nd_pfn,u64 phys) +{ +return min_t (u64,PHYS_SECTION_ALIGN_DOWN (phys), +ALIGN_DOWN (phys, nd_pfn->align)); +} +static int nd_pfn_init (struct nd_pfn *nd_pfn) {u32 dax_label_reserve =is_nd_dax (&nd_pfn->dev) ?SZ_128K :0 ;
@@ -618,13 +624,16 @@ static int nd_pfn_init(struct nd_pfn *nd start = nsio->res.start; size =PHYS_SECTION_ALIGN_UP (start + size) - start;if (region_intersects (start, size,IORESOURCE_SYSTEM_RAM , -IORES_DESC_NONE ) ==REGION_MIXED ) { +IORES_DESC_NONE ) ==REGION_MIXED + || !IS_ALIGNED (start +resource_size (&nsio->res), + nd_pfn->align)) { size =resource_size (&nsio->res); - end_trunc = start + size -PHYS_SECTION_ALIGN_DOWN (start + size); + end_trunc = start + size -phys_pmem_align_down (nd_pfn, + start + size); }if (start_pad + end_trunc) -dev_info (&nd_pfn->dev,"%s section collision, truncate %d bytes\n" , +dev_info (&nd_pfn->dev,"%s alignment collision, truncate %d bytes\n" ,dev_name (&ndns->dev), start_pad + end_trunc);/*
include/linux/kernel.h +1 -0
@@ -46,6 +46,7 @@#define REPEAT_BYTE (x) ((~0ul / 0xff) * (x))#define ALIGN (x, a) __ALIGN_KERNEL((x), (a)) +#define ALIGN_DOWN (x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))#define __ALIGN_MASK (x, mask) __ALIGN_KERNEL_MASK((x), (mask))#define PTR_ALIGN (p, a) ((typeof(p))ALIGN((unsigned long)(p), (a)))#define IS_ALIGNED (x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
Greg Kroah-Hartman
maintainerPATCH 37/39 mm: Fix devm_memremap_pages() collision handling
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan H. Schönherr <[email protected]>
commit 77dd66a3c67c93ab401ccc15efff25578be281fd upstream.
If devm_memremap_pages() detects a collision while adding entries to the radix-tree, we call pgmap_radix_release(). Unfortunately, the function removes *all* entries for the range -- including the entries that caused the collision in the first place.
Modify pgmap_radix_release() to take an additional argument to indicate where to stop, so that only newly added entries are removed from the tree.
--- kernel/memremap.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
kernel/memremap.c +8 -5
@@ -194,7 +194,7 @@ void put_zone_device_page(struct page *p }EXPORT_SYMBOL (put_zone_device_page); -static void pgmap_radix_release (struct resource *res) +static void pgmap_radix_release (struct resource *res,resource_size_t end_key) {resource_size_t key, align_start, align_size, align_end;
@@ -203,8 +203,11 @@ static void pgmap_radix_release(struct r align_end = align_start + align_size -1 ;mutex_lock (&pgmap_lock); -for (key = res->start; key <= res->end; key +=SECTION_SIZE ) +for (key = res->start; key <= res->end; key +=SECTION_SIZE ) { +if (key >= end_key) +break ;radix_tree_delete (&pgmap_radix, key >>PA_SECTION_SHIFT ); + }mutex_unlock (&pgmap_lock); }
@@ -255,7 +258,7 @@ static void devm_memremap_pages_release(unlock_device_hotplug ();untrack_pfn (NULL ,PHYS_PFN (align_start), align_size); -pgmap_radix_release (res); +pgmap_radix_release (res,-1 );dev_WARN_ONCE (dev, pgmap->altmap && pgmap->altmap->alloc,"%s: failed to free all reserved pages\n" , __func__); }
@@ -289,7 +292,7 @@ struct dev_pagemap *find_dev_pagemap(resvoid *devm_memremap_pages (struct device *dev,struct resource *res,struct percpu_ref *ref,struct vmem_altmap *altmap) { -resource_size_t key, align_start, align_size, align_end; +resource_size_t key =0 , align_start, align_size, align_end;pgprot_t pgprot =PAGE_KERNEL ;struct dev_pagemap *pgmap;struct page_map *page_map;
@@ -392,7 +395,7 @@ void *devm_memremap_pages(struct deviceuntrack_pfn (NULL ,PHYS_PFN (align_start), align_size); err_pfn_remap: err_radix: -pgmap_radix_release (res); +pgmap_radix_release (res, key);devres_free (page_map);return ERR_PTR (error); }
Greg Kroah-Hartman
maintainerPATCH 38/39 mm: fail get_vaddr_frames() for filesystem-dax mappings
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit b7f0554a56f21fb3e636a627450a9add030889be upstream.
Until there is a solution to the dma-to-dax vs truncate problem it is not safe to allow V4L2, Exynos, and other frame vector users to create long standing / irrevocable memory registrations against filesytem-dax vmas.
--- mm/frame_vector.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
mm/frame_vector.c +12 -0
@@ -52,6 +52,18 @@ int get_vaddr_frames(unsigned long start ret = -EFAULT ; goto out; } + +/* +* While get_vaddr_frames() could be used for transient (kernel +* controlled lifetime) pinning of memory pages all current +* users establish long term (userspace controlled lifetime) +* page pinning. Treat get_vaddr_frames() like +* get_user_pages_longterm() and disallow it for filesystem-dax +* mappings. +*/ +if (vma_is_fsdax (vma)) +return -EOPNOTSUPP ; +if (!(vma->vm_flags & (VM_IO |VM_PFNMAP ))) { vec->got_ref = true; vec->is_pfns = false;
Greg Kroah-Hartman
maintainerPATCH 39/39 x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 8e1eb3fa009aa7c0b944b3c8b26b07de0efb3200 upstream.
At entry userspace may have (maliciously) populated the extra registers outside the syscall calling convention with arbitrary values that could be useful in a speculative execution (Spectre style) attack.
Clear these registers to minimize the kernel's attack surface.
Note, this only clears the extra registers and not the unused registers for syscalls less than 6 arguments, since those registers are likely to be clobbered well before their values could be put to use under speculation.
Note, Linus found that the XOR instructions can be executed with minimized cost if interleaved with the PUSH instructions, and Ingo's analysis found that R10 and R11 should be included in the register clearing beyond the typical 'extra' syscall calling convention registers.
--- arch/x86/entry/entry_64.S | 13 +++++++++++++ 1 file changed, 13 insertions(+)
arch/x86/entry/entry_64.S +13 -0
@@ -176,13 +176,26 @@ GLOBAL(entry_SYSCALL_64_after_swapgs) pushq %r8 /* pt_regs->r8 */ pushq %r9 /* pt_regs->r9 */ pushq %r10 /* pt_regs->r10 */ + /* + * Clear extra registers that a speculation attack might + * otherwise want to exploit. Interleave XOR with PUSH + * for better uop scheduling: + */ + xorq %r10, %r10 /* nospec r10 */ pushq %r11 /* pt_regs->r11 */ + xorq %r11, %r11 /* nospec r11 */ pushq %rbx /* pt_regs->rbx */ + xorl %ebx, %ebx /* nospec rbx */ pushq %rbp /* pt_regs->rbp */ + xorl %ebp, %ebp /* nospec rbp */ pushq %r12 /* pt_regs->r12 */ + xorq %r12, %r12 /* nospec r12 */ pushq %r13 /* pt_regs->r13 */ + xorq %r13, %r13 /* nospec r13 */ pushq %r14 /* pt_regs->r14 */ + xorq %r14, %r14 /* nospec r14 */ pushq %r15 /* pt_regs->r15 */ + xorq %r15, %r15 /* nospec r15 */ /* IRQs are off. */ movq %rsp, %rdi
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.85 release. There are 39 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 Feb 28 20:16:31 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.9.85-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.85 release. There are 39 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 Feb 28 20:16:31 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.9.85-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.9.85-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8a6c3b05a45b5e6deea2156d191d1e90aec6d083
git describe: v4.9.84-40-g8a6c3b05a45b
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.84-40-g8a6c3b05a45b
No regressions (compared to build v4.9.84)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 41, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1
x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1
x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1
--
Linaro QA (beta)
https://qa-reports.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.85 release. There are 39 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 Feb 28 20:16:31 UTC 2018. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.85 release. There are 39 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 Feb 28 20:16:31 UTC 2018. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0Details are available at http://kerneltests.org/builders.
Yeah, I got one right! :)