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

Patch "staging: android: ion: Add __GFP_NOWARN for system contig heap" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ion: Add __GFP_NOWARN for system contig heap to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001 From: Laura Abbott <labbott(a)redhat.com> Date: Fri, 5 Jan 2018 11:14:08 -0800 Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap From: Laura Abbott <labbott(a)redhat.com> commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream. syzbot reported a warning from Ion: WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926 ... __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252 alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036 alloc_pages include/linux/gfp.h:492 [inline] ion_system_contig_heap_allocate+0x40/0x2c0 drivers/staging/android/ion/ion_system_heap.c:374 ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline] ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420 ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 This is a warning about attempting to allocate order > MAX_ORDER. This is coming from a userspace Ion allocation request. Since userspace is free to request however much memory it wants (and the kernel is free to deny its allocation), silence the allocation attempt with __GFP_NOWARN in case it fails. Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Laura Abbott <labbott(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ion/ion_system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/android/ion/ion_system_heap.c +++ b/drivers/staging/android/ion/ion_system_heap.c @@ -321,7 +321,7 @@ static int ion_system_contig_heap_alloca if (align > (PAGE_SIZE << order)) return -EINVAL; - page = alloc_pages(low_order_gfp_flags, order); + page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order); if (!page) return -ENOMEM; Patches currently in stable-queue which might be from labbott(a)redhat.com are queue-3.18/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch

7 years, 3 months

1
0
0 0

Patch "selinux: skip bounded transition processing if the policy isn't loaded" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selinux: skip bounded transition processing if the policy isn't loaded to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001 From: Paul Moore <paul(a)paul-moore.com> Date: Tue, 5 Dec 2017 17:17:43 -0500 Subject: selinux: skip bounded transition processing if the policy isn't loaded From: Paul Moore <paul(a)paul-moore.com> commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream. We can't do anything reasonable in security_bounded_transition() if we don't have a policy loaded, and in fact we could run into problems with some of the code inside expecting a policy. Fix these problems like we do many others in security/selinux/ss/services.c by checking to see if the policy is loaded (ss_initialized) and returning quickly if it isn't. Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/selinux/ss/services.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -823,6 +823,9 @@ int security_bounded_transition(u32 old_ int index; int rc; + if (!ss_initialized) + return 0; + read_lock(&policy_rwlock); rc = -EINVAL; Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-3.18/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch queue-3.18/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch

7 years, 3 months

1
0
0 0

Patch "selinux: ensure the context is NUL terminated in security_context_to_sid_core()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selinux: ensure the context is NUL terminated in security_context_to_sid_core() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001 From: Paul Moore <paul(a)paul-moore.com> Date: Tue, 28 Nov 2017 18:51:12 -0500 Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core() From: Paul Moore <paul(a)paul-moore.com> commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream. The syzbot/syzkaller automated tests found a problem in security_context_to_sid_core() during early boot (before we load the SELinux policy) where we could potentially feed context strings without NUL terminators into the strcmp() function. We already guard against this during normal operation (after the SELinux policy has been loaded) by making a copy of the context strings and explicitly adding a NUL terminator to the end. The patch extends this protection to the early boot case (no loaded policy) by moving the context copy earlier in security_context_to_sid_core(). Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Reviewed-By: William Roberts <william.c.roberts(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/selinux/ss/services.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -1239,27 +1239,25 @@ static int security_context_to_sid_core( if (!scontext_len) return -EINVAL; + /* Copy the string to allow changes and ensure a NUL terminator */ + scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags); + if (!scontext2) + return -ENOMEM; + if (!ss_initialized) { int i; for (i = 1; i < SECINITSID_NUM; i++) { - if (!strcmp(initial_sid_to_string[i], scontext)) { + if (!strcmp(initial_sid_to_string[i], scontext2)) { *sid = i; - return 0; + goto out; } } *sid = SECINITSID_KERNEL; - return 0; + goto out; } *sid = SECSID_NULL; - /* Copy the string so that we can modify the copy as we parse it. */ - scontext2 = kmalloc(scontext_len + 1, gfp_flags); - if (!scontext2) - return -ENOMEM; - memcpy(scontext2, scontext, scontext_len); - scontext2[scontext_len] = 0; - if (force) { /* Save another copy for storing in uninterpreted form */ rc = -ENOMEM; Patches currently in stable-queue which might be from paul(a)paul-moore.com are queue-3.18/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch queue-3.18/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch

7 years, 3 months

1
0
0 0

Patch "Provide a function to create a NUL-terminated string from unterminated data" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Provide a function to create a NUL-terminated string from unterminated data to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f35157417215ec138c920320c746fdb3e04ef1d5 Mon Sep 17 00:00:00 2001 From: David Howells <dhowells(a)redhat.com> Date: Tue, 4 Jul 2017 17:25:02 +0100 Subject: Provide a function to create a NUL-terminated string from unterminated data From: David Howells <dhowells(a)redhat.com> commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream. Provide a function, kmemdup_nul(), that will create a NUL-terminated string from an unterminated character array where the length is known in advance. This is better than kstrndup() in situations where we already know the string length as the strnlen() in kstrndup() is superfluous. Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/string.h | 1 + mm/util.c | 24 ++++++++++++++++++++++++ 2 files changed, 25 insertions(+) --- a/include/linux/string.h +++ b/include/linux/string.h @@ -121,6 +121,7 @@ void *memchr_inv(const void *s, int c, s extern char *kstrdup(const char *s, gfp_t gfp); extern char *kstrndup(const char *s, size_t len, gfp_t gfp); extern void *kmemdup(const void *src, size_t len, gfp_t gfp); +extern char *kmemdup_nul(const char *s, size_t len, gfp_t gfp); extern char **argv_split(gfp_t gfp, const char *str, int *argcp); extern void argv_free(char **argv); --- a/mm/util.c +++ b/mm/util.c @@ -42,6 +42,8 @@ EXPORT_SYMBOL(kstrdup); * @s: the string to duplicate * @max: read at most @max chars from @s * @gfp: the GFP mask used in the kmalloc() call when allocating memory + * + * Note: Use kmemdup_nul() instead if the size is known exactly. */ char *kstrndup(const char *s, size_t max, gfp_t gfp) { @@ -80,6 +82,28 @@ void *kmemdup(const void *src, size_t le EXPORT_SYMBOL(kmemdup); /** + * kmemdup_nul - Create a NUL-terminated string from unterminated data + * @s: The data to stringify + * @len: The size of the data + * @gfp: the GFP mask used in the kmalloc() call when allocating memory + */ +char *kmemdup_nul(const char *s, size_t len, gfp_t gfp) +{ + char *buf; + + if (!s) + return NULL; + + buf = kmalloc_track_caller(len + 1, gfp); + if (buf) { + memcpy(buf, s, len); + buf[len] = '\0'; + } + return buf; +} +EXPORT_SYMBOL(kmemdup_nul); + +/** * memdup_user - duplicate memory region from user space * * @src: source address in user space Patches currently in stable-queue which might be from dhowells(a)redhat.com are queue-3.18/provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch

7 years, 3 months

1
0
0 0

Patch "netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Mon, 5 Feb 2018 14:41:45 -0800 Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert From: Cong Wang <xiyou.wangcong(a)gmail.com> commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream. rateest_hash is supposed to be protected by xt_rateest_mutex, and, as suggested by Eric, lookup and insert should be atomic, so we should acquire the xt_rateest_mutex once for both. So introduce a non-locking helper for internal use and keep the locking one for external. Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com> Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target") Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Reviewed-by: Florian Westphal <fw(a)strlen.de> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/net/netfilter/xt_RATEEST.c +++ b/net/netfilter/xt_RATEEST.c @@ -40,23 +40,31 @@ static void xt_rateest_hash_insert(struc hlist_add_head(&est->list, &rateest_hash[h]); } -struct xt_rateest *xt_rateest_lookup(const char *name) +static struct xt_rateest *__xt_rateest_lookup(const char *name) { struct xt_rateest *est; unsigned int h; h = xt_rateest_hash(name); - mutex_lock(&xt_rateest_mutex); hlist_for_each_entry(est, &rateest_hash[h], list) { if (strcmp(est->name, name) == 0) { est->refcnt++; - mutex_unlock(&xt_rateest_mutex); return est; } } - mutex_unlock(&xt_rateest_mutex); + return NULL; } + +struct xt_rateest *xt_rateest_lookup(const char *name) +{ + struct xt_rateest *est; + + mutex_lock(&xt_rateest_mutex); + est = __xt_rateest_lookup(name); + mutex_unlock(&xt_rateest_mutex); + return est; +} EXPORT_SYMBOL_GPL(xt_rateest_lookup); void xt_rateest_put(struct xt_rateest *est) @@ -104,8 +112,10 @@ static int xt_rateest_tg_checkentry(cons rnd_inited = true; } - est = xt_rateest_lookup(info->name); + mutex_lock(&xt_rateest_mutex); + est = __xt_rateest_lookup(info->name); if (est) { + mutex_unlock(&xt_rateest_mutex); /* * If estimator parameters are specified, they must match the * existing estimator. @@ -143,11 +153,13 @@ static int xt_rateest_tg_checkentry(cons info->est = est; xt_rateest_hash_insert(est); + mutex_unlock(&xt_rateest_mutex); return 0; err2: kfree(est); err1: + mutex_unlock(&xt_rateest_mutex); return ret; } Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-3.18/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch queue-3.18/xfrm-check-id-proto-in-validate_tmpl.patch

7 years, 3 months

1
0
0 0

Patch "netfilter: x_tables: fix int overflow in xt_alloc_table_info()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: x_tables: fix int overflow in xt_alloc_table_info() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001 From: Dmitry Vyukov <dvyukov(a)google.com> Date: Thu, 28 Dec 2017 09:48:54 +0100 Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info() From: Dmitry Vyukov <dvyukov(a)google.com> commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream. syzkaller triggered OOM kills by passing ipt_replace.size = -1 to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in xt_alloc_table_info() causes int overflow and the size check passes when it should not. SMP_ALIGN() is no longer needed leftover. Remove SMP_ALIGN() call in xt_alloc_table_info(). Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/x_tables.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -38,8 +38,6 @@ MODULE_LICENSE("GPL"); MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>"); MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module"); -#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) - struct compat_delta { unsigned int offset; /* offset in kernel */ int delta; /* delta in 32bit user land */ @@ -951,7 +949,7 @@ struct xt_table_info *xt_alloc_table_inf int cpu; /* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */ - if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages) + if ((size >> PAGE_SHIFT) + 2 > totalram_pages) return NULL; newinfo = kzalloc(XT_TABLE_INFO_SZ, GFP_KERNEL); Patches currently in stable-queue which might be from dvyukov(a)google.com are queue-3.18/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch queue-3.18/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch

7 years, 3 months

1
0
0 0

Patch "netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target} to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet(a)google.com> Date: Wed, 24 Jan 2018 17:16:09 -0800 Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target} From: Eric Dumazet <edumazet(a)google.com> commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream. It looks like syzbot found its way into netfilter territory. Issue here is that @name comes from user space and might not be null terminated. Out-of-bound reads happen, KASAN is not happy. v2 added similar fix for xt_request_find_target(), as Florian advised. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/x_tables.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -209,6 +209,9 @@ xt_request_find_match(uint8_t nfproto, c { struct xt_match *match; + if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN) + return ERR_PTR(-EINVAL); + match = xt_find_match(nfproto, name, revision); if (IS_ERR(match)) { request_module("%st_%s", xt_prefix[nfproto], name); @@ -251,6 +254,9 @@ struct xt_target *xt_request_find_target { struct xt_target *target; + if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN) + return ERR_PTR(-EINVAL); + target = xt_find_target(af, name, revision); if (IS_ERR(target)) { request_module("%st_%s", xt_prefix[af], name); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-3.18/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch queue-3.18/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch

7 years, 3 months

1
0
0 0

Patch "netfilter: on sockopt() acquire sock lock only in the required scope" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: on sockopt() acquire sock lock only in the required scope to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-on-sockopt-acquire-sock-lock-only-in-the-required-scope.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3f34cfae1238848fd53f25e5c8fd59da57901f4b Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Tue, 30 Jan 2018 19:01:40 +0100 Subject: netfilter: on sockopt() acquire sock lock only in the required scope From: Paolo Abeni <pabeni(a)redhat.com> commit 3f34cfae1238848fd53f25e5c8fd59da57901f4b upstream. Syzbot reported several deadlocks in the netfilter area caused by rtnl lock and socket lock being acquired with a different order on different code paths, leading to backtraces like the following one: ====================================================== WARNING: possible circular locking dependency detected 4.15.0-rc9+ #212 Not tainted ------------------------------------------------------ syzkaller041579/3682 is trying to acquire lock: (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] lock_sock include/net/sock.h:1463 [inline] (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 but task is already holding lock: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}: __mutex_lock_common kernel/locking/mutex.c:756 [inline] __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607 tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106 xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845 check_target net/ipv6/netfilter/ip6_tables.c:538 [inline] find_check_entry.isra.7+0x935/0xcf0 net/ipv6/netfilter/ip6_tables.c:580 translate_table+0xf52/0x1690 net/ipv6/netfilter/ip6_tables.c:749 do_replace net/ipv6/netfilter/ip6_tables.c:1165 [inline] do_ip6t_set_ctl+0x370/0x5f0 net/ipv6/netfilter/ip6_tables.c:1691 nf_sockopt net/netfilter/nf_sockopt.c:106 [inline] nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115 ipv6_setsockopt+0x115/0x150 net/ipv6/ipv6_sockglue.c:928 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 -> #0 (sk_lock-AF_INET6){+.+.}: lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914 lock_sock_nested+0xc2/0x110 net/core/sock.c:2780 lock_sock include/net/sock.h:1463 [inline] do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167 ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922 udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422 sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978 SYSC_setsockopt net/socket.c:1849 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1828 entry_SYSCALL_64_fastpath+0x29/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(sk_lock-AF_INET6); lock(rtnl_mutex); lock(sk_lock-AF_INET6); *** DEADLOCK *** 1 lock held by syzkaller041579/3682: #0: (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 The problem, as Florian noted, is that nf_setsockopt() is always called with the socket held, even if the lock itself is required only for very tight scopes and only for some operation. This patch addresses the issues moving the lock_sock() call only where really needed, namely in ipv*_getorigdst(), so that nf_setsockopt() does not need anymore to acquire both locks. Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Reported-by: syzbot+a4c2dc980ac1af699b36(a)syzkaller.appspotmail.com Suggested-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/ip_sockglue.c | 14 ++++---------- net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 6 +++++- net/ipv6/ipv6_sockglue.c | 17 +++++------------ net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 18 ++++++++++++------ 4 files changed, 26 insertions(+), 29 deletions(-) --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -1090,11 +1090,8 @@ int ip_setsockopt(struct sock *sk, int l if (err == -ENOPROTOOPT && optname != IP_HDRINCL && optname != IP_IPSEC_POLICY && optname != IP_XFRM_POLICY && - !ip_mroute_opt(optname)) { - lock_sock(sk); + !ip_mroute_opt(optname)) err = nf_setsockopt(sk, PF_INET, optname, optval, optlen); - release_sock(sk); - } #endif return err; } @@ -1119,12 +1116,9 @@ int compat_ip_setsockopt(struct sock *sk if (err == -ENOPROTOOPT && optname != IP_HDRINCL && optname != IP_IPSEC_POLICY && optname != IP_XFRM_POLICY && - !ip_mroute_opt(optname)) { - lock_sock(sk); - err = compat_nf_setsockopt(sk, PF_INET, optname, - optval, optlen); - release_sock(sk); - } + !ip_mroute_opt(optname)) + err = compat_nf_setsockopt(sk, PF_INET, optname, optval, + optlen); #endif return err; } --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -269,15 +269,19 @@ getorigdst(struct sock *sk, int optval, struct nf_conntrack_tuple tuple; memset(&tuple, 0, sizeof(tuple)); + + lock_sock(sk); tuple.src.u3.ip = inet->inet_rcv_saddr; tuple.src.u.tcp.port = inet->inet_sport; tuple.dst.u3.ip = inet->inet_daddr; tuple.dst.u.tcp.port = inet->inet_dport; tuple.src.l3num = PF_INET; tuple.dst.protonum = sk->sk_protocol; + release_sock(sk); /* We only do TCP and SCTP at the moment: is there a better way? */ - if (sk->sk_protocol != IPPROTO_TCP && sk->sk_protocol != IPPROTO_SCTP) { + if (tuple.dst.protonum != IPPROTO_TCP && + tuple.dst.protonum != IPPROTO_SCTP) { pr_debug("SO_ORIGINAL_DST: Not a TCP/SCTP socket\n"); return -ENOPROTOOPT; } --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -875,12 +875,8 @@ int ipv6_setsockopt(struct sock *sk, int #ifdef CONFIG_NETFILTER /* we need to exclude all possible ENOPROTOOPTs except default case */ if (err == -ENOPROTOOPT && optname != IPV6_IPSEC_POLICY && - optname != IPV6_XFRM_POLICY) { - lock_sock(sk); - err = nf_setsockopt(sk, PF_INET6, optname, optval, - optlen); - release_sock(sk); - } + optname != IPV6_XFRM_POLICY) + err = nf_setsockopt(sk, PF_INET6, optname, optval, optlen); #endif return err; } @@ -910,12 +906,9 @@ int compat_ipv6_setsockopt(struct sock * #ifdef CONFIG_NETFILTER /* we need to exclude all possible ENOPROTOOPTs except default case */ if (err == -ENOPROTOOPT && optname != IPV6_IPSEC_POLICY && - optname != IPV6_XFRM_POLICY) { - lock_sock(sk); - err = compat_nf_setsockopt(sk, PF_INET6, optname, - optval, optlen); - release_sock(sk); - } + optname != IPV6_XFRM_POLICY) + err = compat_nf_setsockopt(sk, PF_INET6, optname, optval, + optlen); #endif return err; } --- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c +++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c @@ -240,20 +240,27 @@ static struct nf_hook_ops ipv6_conntrack static int ipv6_getorigdst(struct sock *sk, int optval, void __user *user, int *len) { - const struct inet_sock *inet = inet_sk(sk); + struct nf_conntrack_tuple tuple = { .src.l3num = NFPROTO_IPV6 }; const struct ipv6_pinfo *inet6 = inet6_sk(sk); + const struct inet_sock *inet = inet_sk(sk); const struct nf_conntrack_tuple_hash *h; struct sockaddr_in6 sin6; - struct nf_conntrack_tuple tuple = { .src.l3num = NFPROTO_IPV6 }; struct nf_conn *ct; + __be32 flow_label; + int bound_dev_if; + lock_sock(sk); tuple.src.u3.in6 = sk->sk_v6_rcv_saddr; tuple.src.u.tcp.port = inet->inet_sport; tuple.dst.u3.in6 = sk->sk_v6_daddr; tuple.dst.u.tcp.port = inet->inet_dport; tuple.dst.protonum = sk->sk_protocol; + bound_dev_if = sk->sk_bound_dev_if; + flow_label = inet6->flow_label; + release_sock(sk); - if (sk->sk_protocol != IPPROTO_TCP && sk->sk_protocol != IPPROTO_SCTP) + if (tuple.dst.protonum != IPPROTO_TCP && + tuple.dst.protonum != IPPROTO_SCTP) return -ENOPROTOOPT; if (*len < 0 || (unsigned int) *len < sizeof(sin6)) @@ -271,14 +278,13 @@ ipv6_getorigdst(struct sock *sk, int opt sin6.sin6_family = AF_INET6; sin6.sin6_port = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u.tcp.port; - sin6.sin6_flowinfo = inet6->flow_label & IPV6_FLOWINFO_MASK; + sin6.sin6_flowinfo = flow_label & IPV6_FLOWINFO_MASK; memcpy(&sin6.sin6_addr, &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.in6, sizeof(sin6.sin6_addr)); nf_ct_put(ct); - sin6.sin6_scope_id = ipv6_iface_scope_id(&sin6.sin6_addr, - sk->sk_bound_dev_if); + sin6.sin6_scope_id = ipv6_iface_scope_id(&sin6.sin6_addr, bound_dev_if); return copy_to_user(user, &sin6, sizeof(sin6)) ? -EFAULT : 0; } Patches currently in stable-queue which might be from pabeni(a)redhat.com are queue-3.18/netfilter-on-sockopt-acquire-sock-lock-only-in-the-required-scope.patch

7 years, 3 months

1
0
0 0

Patch "netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001 From: Dmitry Vyukov <dvyukov(a)google.com> Date: Tue, 30 Jan 2018 15:21:34 +0100 Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check() From: Dmitry Vyukov <dvyukov(a)google.com> commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream. Commit 136e92bbec0a switched local_nodes from an array to a bitmask but did not add proper bounds checks. As the result clusterip_config_init_nodelist() can both over-read ipt_clusterip_tgt_info.local_nodes and over-write clusterip_config.local_nodes. Add bounds checks for both. Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data") Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/net/ipv4/netfilter/ipt_CLUSTERIP.c +++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c @@ -365,7 +365,7 @@ static int clusterip_tg_check(const stru struct ipt_clusterip_tgt_info *cipinfo = par->targinfo; const struct ipt_entry *e = par->entryinfo; struct clusterip_config *config; - int ret; + int ret, i; if (cipinfo->hash_mode != CLUSTERIP_HASHMODE_SIP && cipinfo->hash_mode != CLUSTERIP_HASHMODE_SIP_SPT && @@ -379,8 +379,18 @@ static int clusterip_tg_check(const stru pr_info("Please specify destination IP\n"); return -EINVAL; } - - /* FIXME: further sanity checks */ + if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) { + pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes); + return -EINVAL; + } + for (i = 0; i < cipinfo->num_local_nodes; i++) { + if (cipinfo->local_nodes[i] - 1 >= + sizeof(config->local_nodes) * 8) { + pr_info("bad local_nodes[%d] %u\n", + i, cipinfo->local_nodes[i]); + return -EINVAL; + } + } config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1); if (!config) { Patches currently in stable-queue which might be from dvyukov(a)google.com are queue-3.18/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch queue-3.18/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch

7 years, 3 months

1
0
0 0

Patch "net: avoid skb_warn_bad_offload on IS_ERR" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: avoid skb_warn_bad_offload on IS_ERR to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-avoid-skb_warn_bad_offload-on-is_err.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001 From: Willem de Bruijn <willemb(a)google.com> Date: Tue, 12 Dec 2017 11:39:04 -0500 Subject: net: avoid skb_warn_bad_offload on IS_ERR From: Willem de Bruijn <willemb(a)google.com> commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream. skb_warn_bad_offload warns when packets enter the GSO stack that require skb_checksum_help or vice versa. Do not warn on arbitrary bad packets. Packet sockets can craft many. Syzkaller was able to demonstrate another one with eth_type games. In particular, suppress the warning when segmentation returns an error, which is for reasons other than checksum offload. See also commit 36c92474498a ("net: WARN if skb_checksum_help() is called on skb requiring segmentation") for context on this warning. Signed-off-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2478,7 +2478,7 @@ struct sk_buff *__skb_gso_segment(struct segs = skb_mac_gso_segment(skb, features); - if (unlikely(skb_needs_check(skb, tx_path))) + if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs))) skb_warn_bad_offload(skb); return segs; Patches currently in stable-queue which might be from willemb(a)google.com are queue-3.18/net-avoid-skb_warn_bad_offload-on-is_err.patch

7 years, 3 months

1
0
0 0

Patch "mm, vmscan: Make unregister_shrinker() no-op if register_shrinker() failed." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-vmscan-make-unregister_shrinker-no-op-if-register_shrinker-failed.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bb422a738f6566f7439cd347d54e321e4fe92a9f Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Mon, 18 Dec 2017 20:31:41 +0900 Subject: mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> commit bb422a738f6566f7439cd347d54e321e4fe92a9f upstream. Syzbot caught an oops at unregister_shrinker() because combination of commit 1d3d4437eae1bb29 ("vmscan: per-node deferred work") and fault injection made register_shrinker() fail and the caller of register_shrinker() did not check for failure. ---------- [ 554.881422] FAULT_INJECTION: forcing a failure. [ 554.881422] name failslab, interval 1, probability 0, space 0, times 0 [ 554.881438] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 [ 554.881443] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 554.881445] Call Trace: [ 554.881459] dump_stack+0x194/0x257 [ 554.881474] ? arch_local_irq_restore+0x53/0x53 [ 554.881486] ? find_held_lock+0x35/0x1d0 [ 554.881507] should_fail+0x8c0/0xa40 [ 554.881522] ? fault_create_debugfs_attr+0x1f0/0x1f0 [ 554.881537] ? check_noncircular+0x20/0x20 [ 554.881546] ? find_next_zero_bit+0x2c/0x40 [ 554.881560] ? ida_get_new_above+0x421/0x9d0 [ 554.881577] ? find_held_lock+0x35/0x1d0 [ 554.881594] ? __lock_is_held+0xb6/0x140 [ 554.881628] ? check_same_owner+0x320/0x320 [ 554.881634] ? lock_downgrade+0x990/0x990 [ 554.881649] ? find_held_lock+0x35/0x1d0 [ 554.881672] should_failslab+0xec/0x120 [ 554.881684] __kmalloc+0x63/0x760 [ 554.881692] ? lock_downgrade+0x990/0x990 [ 554.881712] ? register_shrinker+0x10e/0x2d0 [ 554.881721] ? trace_event_raw_event_module_request+0x320/0x320 [ 554.881737] register_shrinker+0x10e/0x2d0 [ 554.881747] ? prepare_kswapd_sleep+0x1f0/0x1f0 [ 554.881755] ? _down_write_nest_lock+0x120/0x120 [ 554.881765] ? memcpy+0x45/0x50 [ 554.881785] sget_userns+0xbcd/0xe20 (...snipped...) [ 554.898693] kasan: CONFIG_KASAN_INLINE enabled [ 554.898724] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 554.898732] general protection fault: 0000 [#1] SMP KASAN [ 554.898737] Dumping ftrace buffer: [ 554.898741] (ftrace buffer empty) [ 554.898743] Modules linked in: [ 554.898752] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82 [ 554.898755] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 554.898760] task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000 [ 554.898772] RIP: 0010:__list_del_entry_valid+0x7e/0x150 [ 554.898775] RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246 [ 554.898780] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 554.898784] RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0 [ 554.898788] RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004 [ 554.898791] R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000 [ 554.898795] R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98 [ 554.898800] FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 [ 554.898804] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 554.898807] CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0 [ 554.898813] DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 [ 554.898816] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 [ 554.898818] Call Trace: [ 554.898828] unregister_shrinker+0x79/0x300 [ 554.898837] ? perf_trace_mm_vmscan_writepage+0x750/0x750 [ 554.898844] ? down_write+0x87/0x120 [ 554.898851] ? deactivate_super+0x139/0x1b0 [ 554.898857] ? down_read+0x150/0x150 [ 554.898864] ? check_same_owner+0x320/0x320 [ 554.898875] deactivate_locked_super+0x64/0xd0 [ 554.898883] deactivate_super+0x141/0x1b0 ---------- Since allowing register_shrinker() callers to call unregister_shrinker() when register_shrinker() failed can simplify error recovery path, this patch makes unregister_shrinker() no-op when register_shrinker() failed. Also, reset shrinker->nr_deferred in case unregister_shrinker() was by error called twice. Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Cc: Glauber Costa <glauber(a)scylladb.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/vmscan.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -220,10 +220,13 @@ EXPORT_SYMBOL(register_shrinker); */ void unregister_shrinker(struct shrinker *shrinker) { + if (!shrinker->nr_deferred) + return; down_write(&shrinker_rwsem); list_del(&shrinker->list); up_write(&shrinker_rwsem); kfree(shrinker->nr_deferred); + shrinker->nr_deferred = NULL; } EXPORT_SYMBOL(unregister_shrinker); Patches currently in stable-queue which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are queue-3.18/mm-vmscan-make-unregister_shrinker-no-op-if-register_shrinker-failed.patch

7 years, 3 months

1
0
0 0

Patch "crypto: x86/twofish-3way - Fix %rbp usage" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: x86/twofish-3way - Fix %rbp usage to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-x86-twofish-3way-fix-rbp-usage.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d8c7fe9f2a486a6e5f0d5229ca43807af5ab22c6 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 18 Dec 2017 16:40:26 -0800 Subject: crypto: x86/twofish-3way - Fix %rbp usage From: Eric Biggers <ebiggers(a)google.com> commit d8c7fe9f2a486a6e5f0d5229ca43807af5ab22c6 upstream. Using %rbp as a temporary register breaks frame pointer convention and breaks stack traces when unwinding from an interrupt in the crypto code. In twofish-3way, we can't simply replace %rbp with another register because there are none available. Instead, we use the stack to hold the values that %rbp, %r11, and %r12 were holding previously. Each of these values represents the half of the output from the previous Feistel round that is being passed on unchanged to the following round. They are only used once per round, when they are exchanged with %rax, %rbx, and %rcx. As a result, we free up 3 registers (one per block) and can reassign them so that %rbp is not used, and additionally %r14 and %r15 are not used so they do not need to be saved/restored. There may be a small overhead caused by replacing 'xchg REG, REG' with the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per round. But, counterintuitively, when I tested "ctr-twofish-3way" on a Haswell processor, the new version was actually about 2% faster. (Perhaps 'xchg' is not as well optimized as plain moves.) Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Reviewed-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 118 ++++++++++++++------------- 1 file changed, 63 insertions(+), 55 deletions(-) --- a/arch/x86/crypto/twofish-x86_64-asm_64-3way.S +++ b/arch/x86/crypto/twofish-x86_64-asm_64-3way.S @@ -55,29 +55,31 @@ #define RAB1bl %bl #define RAB2bl %cl +#define CD0 0x0(%rsp) +#define CD1 0x8(%rsp) +#define CD2 0x10(%rsp) + +# used only before/after all rounds #define RCD0 %r8 #define RCD1 %r9 #define RCD2 %r10 -#define RCD0d %r8d -#define RCD1d %r9d -#define RCD2d %r10d - -#define RX0 %rbp -#define RX1 %r11 -#define RX2 %r12 - -#define RX0d %ebp -#define RX1d %r11d -#define RX2d %r12d - -#define RY0 %r13 -#define RY1 %r14 -#define RY2 %r15 - -#define RY0d %r13d -#define RY1d %r14d -#define RY2d %r15d +# used only during rounds +#define RX0 %r8 +#define RX1 %r9 +#define RX2 %r10 + +#define RX0d %r8d +#define RX1d %r9d +#define RX2d %r10d + +#define RY0 %r11 +#define RY1 %r12 +#define RY2 %r13 + +#define RY0d %r11d +#define RY1d %r12d +#define RY2d %r13d #define RT0 %rdx #define RT1 %rsi @@ -85,6 +87,8 @@ #define RT0d %edx #define RT1d %esi +#define RT1bl %sil + #define do16bit_ror(rot, op1, op2, T0, T1, tmp1, tmp2, ab, dst) \ movzbl ab ## bl, tmp2 ## d; \ movzbl ab ## bh, tmp1 ## d; \ @@ -92,6 +96,11 @@ op1##l T0(CTX, tmp2, 4), dst ## d; \ op2##l T1(CTX, tmp1, 4), dst ## d; +#define swap_ab_with_cd(ab, cd, tmp) \ + movq cd, tmp; \ + movq ab, cd; \ + movq tmp, ab; + /* * Combined G1 & G2 function. Reordered with help of rotates to have moves * at begining. @@ -110,15 +119,15 @@ /* G1,2 && G2,2 */ \ do16bit_ror(32, xor, xor, Tx2, Tx3, RT0, RT1, ab ## 0, x ## 0); \ do16bit_ror(16, xor, xor, Ty3, Ty0, RT0, RT1, ab ## 0, y ## 0); \ - xchgq cd ## 0, ab ## 0; \ + swap_ab_with_cd(ab ## 0, cd ## 0, RT0); \ \ do16bit_ror(32, xor, xor, Tx2, Tx3, RT0, RT1, ab ## 1, x ## 1); \ do16bit_ror(16, xor, xor, Ty3, Ty0, RT0, RT1, ab ## 1, y ## 1); \ - xchgq cd ## 1, ab ## 1; \ + swap_ab_with_cd(ab ## 1, cd ## 1, RT0); \ \ do16bit_ror(32, xor, xor, Tx2, Tx3, RT0, RT1, ab ## 2, x ## 2); \ do16bit_ror(16, xor, xor, Ty3, Ty0, RT0, RT1, ab ## 2, y ## 2); \ - xchgq cd ## 2, ab ## 2; + swap_ab_with_cd(ab ## 2, cd ## 2, RT0); #define enc_round_end(ab, x, y, n) \ addl y ## d, x ## d; \ @@ -168,6 +177,16 @@ decrypt_round3(ba, dc, (n*2)+1); \ decrypt_round3(ba, dc, (n*2)); +#define push_cd() \ + pushq RCD2; \ + pushq RCD1; \ + pushq RCD0; + +#define pop_cd() \ + popq RCD0; \ + popq RCD1; \ + popq RCD2; + #define inpack3(in, n, xy, m) \ movq 4*(n)(in), xy ## 0; \ xorq w+4*m(CTX), xy ## 0; \ @@ -223,11 +242,8 @@ ENTRY(__twofish_enc_blk_3way) * %rdx: src, RIO * %rcx: bool, if true: xor output */ - pushq %r15; - pushq %r14; pushq %r13; pushq %r12; - pushq %rbp; pushq %rbx; pushq %rcx; /* bool xor */ @@ -235,40 +251,36 @@ ENTRY(__twofish_enc_blk_3way) inpack_enc3(); - encrypt_cycle3(RAB, RCD, 0); - encrypt_cycle3(RAB, RCD, 1); - encrypt_cycle3(RAB, RCD, 2); - encrypt_cycle3(RAB, RCD, 3); - encrypt_cycle3(RAB, RCD, 4); - encrypt_cycle3(RAB, RCD, 5); - encrypt_cycle3(RAB, RCD, 6); - encrypt_cycle3(RAB, RCD, 7); + push_cd(); + encrypt_cycle3(RAB, CD, 0); + encrypt_cycle3(RAB, CD, 1); + encrypt_cycle3(RAB, CD, 2); + encrypt_cycle3(RAB, CD, 3); + encrypt_cycle3(RAB, CD, 4); + encrypt_cycle3(RAB, CD, 5); + encrypt_cycle3(RAB, CD, 6); + encrypt_cycle3(RAB, CD, 7); + pop_cd(); popq RIO; /* dst */ - popq %rbp; /* bool xor */ + popq RT1; /* bool xor */ - testb %bpl, %bpl; + testb RT1bl, RT1bl; jnz .L__enc_xor3; outunpack_enc3(mov); popq %rbx; - popq %rbp; popq %r12; popq %r13; - popq %r14; - popq %r15; ret; .L__enc_xor3: outunpack_enc3(xor); popq %rbx; - popq %rbp; popq %r12; popq %r13; - popq %r14; - popq %r15; ret; ENDPROC(__twofish_enc_blk_3way) @@ -278,35 +290,31 @@ ENTRY(twofish_dec_blk_3way) * %rsi: dst * %rdx: src, RIO */ - pushq %r15; - pushq %r14; pushq %r13; pushq %r12; - pushq %rbp; pushq %rbx; pushq %rsi; /* dst */ inpack_dec3(); - decrypt_cycle3(RAB, RCD, 7); - decrypt_cycle3(RAB, RCD, 6); - decrypt_cycle3(RAB, RCD, 5); - decrypt_cycle3(RAB, RCD, 4); - decrypt_cycle3(RAB, RCD, 3); - decrypt_cycle3(RAB, RCD, 2); - decrypt_cycle3(RAB, RCD, 1); - decrypt_cycle3(RAB, RCD, 0); + push_cd(); + decrypt_cycle3(RAB, CD, 7); + decrypt_cycle3(RAB, CD, 6); + decrypt_cycle3(RAB, CD, 5); + decrypt_cycle3(RAB, CD, 4); + decrypt_cycle3(RAB, CD, 3); + decrypt_cycle3(RAB, CD, 2); + decrypt_cycle3(RAB, CD, 1); + decrypt_cycle3(RAB, CD, 0); + pop_cd(); popq RIO; /* dst */ outunpack_dec3(); popq %rbx; - popq %rbp; popq %r12; popq %r13; - popq %r14; - popq %r15; ret; ENDPROC(twofish_dec_blk_3way) Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/crypto-x86-twofish-3way-fix-rbp-usage.patch

7 years, 3 months

1
0
0 0

[PATCH] Avoid that ATA error handling hangs

by Bart Van Assche

Avoid that the recently introduced call_rcu() call in the SCSI core causes the RCU core to complain about double call_rcu() calls. Reported-by: Natanael Copa <ncopa(a)alpinelinux.org> Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=198861 Fixes: 3bd6f43f5cb3 ("scsi: core: Ensure that the SCSI error handler gets woken up") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Natanael Copa <ncopa(a)alpinelinux.org> Cc: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: <stable(a)vger.kernel.org> --- drivers/scsi/scsi_error.c | 5 +++-- include/scsi/scsi_cmnd.h | 3 +++ include/scsi/scsi_host.h | 2 -- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index ae325985eac1..ac9ce099530e 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -229,7 +229,8 @@ static void scsi_eh_reset(struct scsi_cmnd *scmd) static void scsi_eh_inc_host_failed(struct rcu_head *head) { - struct Scsi_Host *shost = container_of(head, typeof(*shost), rcu); + struct scsi_cmnd *scmd = container_of(head, typeof(*scmd), rcu); + struct Scsi_Host *shost = scmd->device->host; unsigned long flags; spin_lock_irqsave(shost->host_lock, flags); @@ -265,7 +266,7 @@ void scsi_eh_scmd_add(struct scsi_cmnd *scmd) * Ensure that all tasks observe the host state change before the * host_failed change. */ - call_rcu(&shost->rcu, scsi_eh_inc_host_failed); + call_rcu(&scmd->rcu, scsi_eh_inc_host_failed); } /** diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h index d8d4a902a88d..2280b2351739 100644 --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -68,6 +68,9 @@ struct scsi_cmnd { struct list_head list; /* scsi_cmnd participates in queue lists */ struct list_head eh_entry; /* entry for the host eh_cmd_q */ struct delayed_work abort_work; + + struct rcu_head rcu; + int eh_eflags; /* Used by error handlr */ /* diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h index 1a1df0d21ee3..a8b7bf879ced 100644 --- a/include/scsi/scsi_host.h +++ b/include/scsi/scsi_host.h @@ -571,8 +571,6 @@ struct Scsi_Host { struct blk_mq_tag_set tag_set; }; - struct rcu_head rcu; - atomic_t host_busy; /* commands actually active on low-level */ atomic_t host_blocked; -- 2.16.2

7 years, 3 months

5
8
0 0

[PATCH] ARM: orion: fix orion_ge00_switch_board_info initialization

by Arnd Bergmann

A section type mismatch warning shows up when building with LTO, since orion_ge00_mvmdio_bus_name was put in __initconst but not marked const itself: include/linux/of.h: In function 'spear_setup_of_timer': arch/arm/mach-spear/time.c:207:34: error: 'timer_of_match' causes a section type conflict with 'orion_ge00_mvmdio_bus_name' static const struct of_device_id timer_of_match[] __initconst = { ^ arch/arm/plat-orion/common.c:475:32: note: 'orion_ge00_mvmdio_bus_name' was declared here static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii"; ^ As pointed out by Andrew Lunn, it should in fact be 'const' but not '__initconst' because the string is never copied but may be accessed after the init sections are freed. To fix that, I get rid of the extra symbol and rewrite the initialization in a simpler way that assigns both the bus_id and modalias statically. I spotted another theoretical bug in the same place, where d->netdev[i] may be an out of bounds access, this can be fixed by moving the device assignment into the loop. Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- v2: complete rewrite --- arch/arm/plat-orion/common.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c index aff6994950ba..a2399fd66e97 100644 --- a/arch/arm/plat-orion/common.c +++ b/arch/arm/plat-orion/common.c @@ -472,28 +472,27 @@ void __init orion_ge11_init(struct mv643xx_eth_platform_data *eth_data, /***************************************************************************** * Ethernet switch ****************************************************************************/ -static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii"; -static __initdata struct mdio_board_info - orion_ge00_switch_board_info; +static __initdata struct mdio_board_info orion_ge00_switch_board_info = { + .bus_id = "orion-mii", + .modalias = "mv88e6085", +}; void __init orion_ge00_switch_init(struct dsa_chip_data *d) { - struct mdio_board_info *bd; unsigned int i; if (!IS_BUILTIN(CONFIG_PHYLIB)) return; - for (i = 0; i < ARRAY_SIZE(d->port_names); i++) - if (!strcmp(d->port_names[i], "cpu")) + for (i = 0; i < ARRAY_SIZE(d->port_names); i++) { + if (!strcmp(d->port_names[i], "cpu")) { + d->netdev[i] = &orion_ge00.dev; break; + } + } - bd = &orion_ge00_switch_board_info; - bd->bus_id = orion_ge00_mvmdio_bus_name; - bd->mdio_addr = d->sw_addr; - d->netdev[i] = &orion_ge00.dev; - strcpy(bd->modalias, "mv88e6085"); - bd->platform_data = d; + orion_ge00_switch_board_info.mdio_addr = d->sw_addr; + orion_ge00_switch_board_info.platform_data = d; mdiobus_register_board_info(&orion_ge00_switch_board_info, 1); } -- 2.9.0

7 years, 3 months

2
2
0 0

[PATCH] ipv6 sit: work around bogus gcc-8 -Wrestrict warning

by Arnd Bergmann

gcc-8 has a new warning that detects overlapping input and output arguments in memcpy(). It triggers for sit_init_net() calling ipip6_tunnel_clone_6rd(), which is actually correct: net/ipv6/sit.c: In function 'sit_init_net': net/ipv6/sit.c:192:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] The problem here is that the logic detecting the memcpy() arguments finds them to be the same, but the conditional that tests for the input and output of ipip6_tunnel_clone_6rd() to be identical is not a compile-time constant. We know that netdev_priv(t->dev) is the same as t for a tunnel device, and comparing "dev" directly here lets the compiler figure out as well that 'dev == sitn->fb_tunnel_dev' when called from sit_init_net(), so it no longer warns. This code is old, so Cc stable to make sure that we don't get the warning for older kernels built with new gcc. Cc: stable(a)vger.kernel.org Cc: Martin Sebor <msebor(a)gmail.com> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83456 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- net/ipv6/sit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c index 3873d3877135..3a1775a62973 100644 --- a/net/ipv6/sit.c +++ b/net/ipv6/sit.c @@ -182,7 +182,7 @@ static void ipip6_tunnel_clone_6rd(struct net_device *dev, struct sit_net *sitn) #ifdef CONFIG_IPV6_SIT_6RD struct ip_tunnel *t = netdev_priv(dev); - if (t->dev == sitn->fb_tunnel_dev) { + if (dev == sitn->fb_tunnel_dev) { ipv6_addr_set(&t->ip6rd.prefix, htonl(0x20020000), 0, 0, 0); t->ip6rd.relay_prefix = 0; t->ip6rd.prefixlen = 16; -- 2.9.0

7 years, 3 months

1
0
0 0

[Linux-stable-mirror] [PATCH] crypto: sunxi-ss: Add MODULE_ALIAS to sun4i-ss

by Peter Robinson

The MODULE_ALIAS is required to enable the sun4i-ss driver to load automatically when built at a module. Tested on a Cubietruck. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: <stable(a)vger.kernel.org> Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- drivers/crypto/sunxi-ss/sun4i-ss-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c index 1547cbe13dc2..a81d89b3b7d8 100644 --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c @@ -451,6 +451,7 @@ static struct platform_driver sun4i_ss_driver = { module_platform_driver(sun4i_ss_driver); +MODULE_ALIAS("platform:sun4i-ss"); MODULE_DESCRIPTION("Allwinner Security System cryptographic accelerator"); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Corentin LABBE <clabbe.montjoie(a)gmail.com>"); -- 2.14.3

7 years, 3 months

2
1
0 0

[PATCH 4.15 000/163] 4.15.5-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.15.5 release. There are 163 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 Fri Feb 23 12:44:46 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.15.5-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.15.5-rc1 yinbo.zhu <yinbo.zhu(a)nxp.com> mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb yinbo.zhu <yinbo.zhu(a)nxp.com> mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec Arnd Bergmann <arnd(a)arndb.de> media: r820t: fix r820t_write_reg for KASAN Linus Walleij <linus.walleij(a)linaro.org> ARM: dts: Delete bogus reference to the charlcd Matthias Brugger <matthias.bgg(a)gmail.com> arm: dts: mt2701: Add reset-cells Matthias Brugger <matthias.bgg(a)gmail.com> arm: dts: mt7623: Update ethsys binding Arnd Bergmann <arnd(a)arndb.de> ARM: dts: s5pv210: add interrupt-parent for ohci Bjorn Andersson <bjorn.andersson(a)linaro.org> arm64: dts: msm8916: Add missing #phy-cells Arnd Bergmann <arnd(a)arndb.de> ARM: pxa/tosa-bt: add MODULE_LICENSE tag Arnd Bergmann <arnd(a)arndb.de> ARM: dts: exynos: fix RTC interrupt for exynos5410 Tony Luck <tony.luck(a)intel.com> x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages James Hogan <jhogan(a)kernel.org> usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT Mikulas Patocka <mpatocka(a)redhat.com> mvpp2: fix multicast address filter Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Fix racy pool initializations Daniel Mack <daniel(a)zonque.org> ALSA: usb: add more device quirks for USB DSD devices Lassi Ylikojola <lassi.ylikojola(a)gmail.com> ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 Jan-Marek Glogowski <glogow(a)fbihome.de> ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Add headset mode support for Dell laptop Kirill Marinushkin <k.marinushkin(a)gmail.com> ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute Hui Wang <hui.wang(a)canonical.com> ALSA: hda - Fix headset mic detection problem for two Dell machines Stefan Agner <stefan(a)agner.ch> mtd: nand: vf610: set correct ooblayout Greg Kurz <groug(a)kaod.org> 9p/trans_virtio: discard zero-length reply Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix unexpected -EEXIST when creating new inode Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix use-after-free on root->orphan_block_rsv Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix extent state leak from tree log Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix crash due to not cleaning up tree log block's dirty bits Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix deadlock in run_delalloc_nocow NeilBrown <neilb(a)suse.com> dm: correctly handle chained bios in dec_pending() Florian Westphal <fw(a)strlen.de> iscsi-target: make sure to wake up sleeping login worker David Disseldorp <ddiss(a)suse.de> target/iscsi: avoid NULL dereference in CHAP auth error path Jens Axboe <axboe(a)kernel.dk> blk-wbt: account flush requests correctly Chuck Lever <chuck.lever(a)oracle.com> xprtrdma: Fix BUG after a device removal Chuck Lever <chuck.lever(a)oracle.com> xprtrdma: Fix calculation of ri_max_send_sges Will Deacon <will.deacon(a)arm.com> arm64: proc: Set PTE_NG for table entries to avoid traversing them twice Larry Finger <Larry.Finger(a)lwfinger.net> rtlwifi: rtl8821ae: Fix connection lost problem correctly Dan Williams <dan.j.williams(a)intel.com> mpls, nospec: Sanitize array index in mpls_label_ok() Steven Rostedt (VMware) <rostedt(a)goodmis.org> tracing: Fix parsing of globs with a wildcard at the beginning Miklos Szeredi <mszeredi(a)redhat.com> seq_file: fix incomplete reset on read from zero offset Joao Martins <joao.m.martins(a)oracle.com> xenbus: track caller request id Simon Gaiser <simon(a)invisiblethingslab.com> xen: Fix {set,clear}_foreign_p2m_mapping on autotranslating guests Ilya Dryomov <idryomov(a)gmail.com> rbd: whitelist RBD_FEATURE_OPERATIONS feature bit Nicolas Pitre <nicolas.pitre(a)linaro.org> console/dummy: leave .con_font_get set to NULL Johan Hovold <johan(a)kernel.org> video: fbdev: atmel_lcdfb: fix display-timings lookup Johan Hovold <johan(a)kernel.org> PCI: keystone: Fix interrupt-controller-node lookup Lukas Wunner <lukas(a)wunner.de> PCI: pciehp: Assume NoCompl+ for Thunderbolt ports Ray Jui <ray.jui(a)broadcom.com> PCI: iproc: Fix NULL pointer dereference for BCMA Dongdong Liu <liudongdong3(a)huawei.com> PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode Marcin Nowakowski <marcin.nowakowski(a)mips.com> MIPS: Fix incorrect mem=X@Y handling James Hogan <jhogan(a)kernel.org> MIPS: CPS: Fix MIPS_ISA_LEVEL_RAW fallout Corentin Labbe <clabbe.montjoie(a)gmail.com> MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN Jan H. Schönherr <jschoenh(a)amazon.de> mm: Fix memory size alignment in devm_memremap_pages_release() Arnd Bergmann <arnd(a)arndb.de> mm: hide a #warning for COMPILE_TEST Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com> ext4: correct documentation for grpid mount option Zhouyi Zhou <zhouzhouyi(a)gmail.com> ext4: save error to disk in __ext4_grp_locked_error() Harshad Shirwadkar <harshads(a)google.com> ext4: fix a race in the ext4 shutdown path Tobin C. Harding <me(a)tobin.cc> jbd2: fix sphinx kernel-doc build warnings Lukas Wunner <lukas(a)wunner.de> Revert "apple-gmux: lock iGP IO to protect from vgaarb changes" Sagi Grimberg <sagi(a)grimberg.me> mlx5: fix mlx5_get_vector_affinity to start from completion vector 0 Jerome Brunet <jbrunet(a)baylibre.com> Revert "mmc: meson-gx: include tx phase in the tuning process" Phil Elwell <phil(a)raspberrypi.org> mmc: bcm2835: Don't overwrite max frequency unconditionally Linus Walleij <linus.walleij(a)linaro.org> mmc: sdhci: Implement an SDHCI-specific bounce buffer Alexander Potapenko <glider(a)google.com> mbcache: initialize entry->e_referenced in mb_cache_entry_create() Stewart Smith <stewart(a)linux.vnet.ibm.com> rtc-opal: Fix handling of firmware error codes, prevent busy loops Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com> x86/smpboot: Fix uncore_pci_remove() indexing bug when hot-removing a physical CPU Julia Lawall <Julia.Lawall(a)lip6.fr> drm/radeon: adjust tested variable Alex Deucher <alexander.deucher(a)amd.com> drm/radeon: Add dpm quirk for Jet PRO (v2) Shanker Donthineni <shankerd(a)codeaurora.org> arm64: Add missing Falkor part number for branch predictor hardening Keith Packard <keithp(a)keithp.com> drm: Check for lessee in DROP_MASTER ioctl Daniel Vetter <daniel.vetter(a)ffwll.ch> drm/ast: Load lut in crtc_commit Andrey Grodzovsky <andrey.grodzovsky(a)amd.com> drm/amd/powerplay: Fix smu_table_entry.handle type Ray Strode <rstrode(a)redhat.com> drm/qxl: reapply cursor after resetting primary Ray Strode <rstrode(a)redhat.com> drm/qxl: unref cursor bo when finished with it Tom St Denis <tom.stdenis(a)amd.com> drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap() (v2) Felix Kuehling <Felix.Kuehling(a)amd.com> drm/ttm: Don't add swapped BOs to swap-LRU list Ingo Molnar <mingo(a)kernel.org> x86/entry/64: Fix CR3 restore in paranoid_exit() Gustavo A. R. Silva <garsilva(a)embeddedor.com> x86/cpu: Change type of x86_cache_size variable to unsigned int Dan Carpenter <dan.carpenter(a)oracle.com> x86/spectre: Fix an error message Jia Zhang <qianyue.zj(a)alibaba-inc.com> x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping Rui Wang <rui.y.wang(a)intel.com> selftests/x86/mpx: Fix incorrect bounds with old _sigfault Andy Lutomirski <luto(a)kernel.org> x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() Peter Zijlstra <peterz(a)infradead.org> x86/speculation: Add <asm/msr-index.h> dependency Will Deacon <will.deacon(a)arm.com> nospec: Move array_index_nospec() parameter checking into separate macro Dan Williams <dan.j.williams(a)intel.com> x86/speculation: Fix up array_index_nospec_mask() asm constraint Peter Zijlstra <peterz(a)infradead.org> x86/debug: Use UD2 for WARN() Josh Poimboeuf <jpoimboe(a)redhat.com> x86/debug, objtool: Annotate WARN()-related UD2 as reachable Josh Poimboeuf <jpoimboe(a)redhat.com> objtool: Fix segfault in ignore_unreachable_insn() Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c Andreas Gruenbacher <agruenba(a)redhat.com> gfs2: Fixes to "Implement iomap for block_map" Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory Ingo Molnar <mingo(a)kernel.org> selftests/x86/pkeys: Remove unused functions Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Clean up and document sscanf() usage Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Fix vDSO selftest segfault for vsyscall=none Borislav Petkov <bp(a)suse.de> x86/entry/64: Remove the unused 'icebp' macro Josh Poimboeuf <jpoimboe(a)redhat.com> x86/entry/64: Fix paranoid_entry() frame pointer warning Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Indent PUSH_AND_CLEAR_REGS and POP_REGS properly Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Use PUSH_AND_CLEAN_REGS in more cases Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Interleave XOR register clearing with PUSH instructions Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Merge the POP_C_REGS and POP_EXTRA_REGS macros into a single POP_REGS macro Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Merge SAVE_C_REGS and SAVE_EXTRA_REGS, remove unused extensions Dan Williams <dan.j.williams(a)intel.com> x86/entry/64: Clear registers for exceptions/interrupts, to reduce speculation attack surface Andrey Ryabinin <aryabinin(a)virtuozzo.com> platform/x86: wmi: fix off-by-one write in wmi_dev_probe() Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> PM: cpuidle: Fix cpuidle_poll_state_init() prototype Lukas Wunner <lukas(a)wunner.de> PM / runtime: Update links_count also if !CONFIG_SRCU Ingo Molnar <mingo(a)kernel.org> x86/speculation: Clean up various Spectre related details KarimAllah Ahmed <karahmed(a)amazon.de> KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap KarimAllah Ahmed <karahmed(a)amazon.de> X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs David Woodhouse <dwmw(a)amazon.co.uk> KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods David Woodhouse <dwmw(a)amazon.co.uk> Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" David Woodhouse <dwmw(a)amazon.co.uk> x86/speculation: Correct Speculation Control microcode blacklist again David Woodhouse <dwmw(a)amazon.co.uk> x86/speculation: Update Speculation Control microcode blacklist Nadav Amit <namit(a)vmware.com> x86/mm/pti: Fix PTI comment in entry_SYSCALL_64() Balbir Singh <bsingharora(a)gmail.com> powerpc/mm/radix: Split linear mapping on hot-unplug Artem Savkov <artem.savkov(a)gmail.com> crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate Artem Savkov <artem.savkov(a)gmail.com> crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate Geert Uytterhoeven <geert(a)linux-m68k.org> compiler-gcc.h: __nostackprotector needs gcc-4.4 and up Geert Uytterhoeven <geert(a)linux-m68k.org> compiler-gcc.h: Introduce __optimize function attribute Dan Williams <dan.j.williams(a)intel.com> x86/entry/64/compat: Clear registers for compat syscalls, to reduce speculation attack surface Dan Williams <dan.j.williams(a)intel.com> x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface Michal Hocko <mhocko(a)suse.com> mm, memory_hotplug: fix memmap initialization Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> x86: PM: Make APM idle driver initialize polling state Juergen Gross <jgross(a)suse.com> x86/xen: init %gs very early to avoid page faults with stack protector Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> x86/kexec: Make kexec (mostly) work in 5-level paging mode Lucas De Marchi <lucas.demarchi(a)intel.com> x86/gpu: add CFL to early quirks Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix spics gpio controller's warning Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix dmas cells Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear600: Add missing interrupt-parent of rtc Sean Wang <sean.wang(a)mediatek.com> arm: dts: mt7623: fix card detection issue on bananapi-r2 Arnd Bergmann <arnd(a)arndb.de> ARM: dts: nomadik: add interrupt-parent for clcd Patrice Chotard <patrice.chotard(a)st.com> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property Arnd Bergmann <arnd(a)arndb.de> ARM: lpc3250: fix uda1380 gpio numbers Bjorn Andersson <bjorn.andersson(a)linaro.org> arm64: dts: msm8916: Correct ipc references for smsm Eugene Syromiatnikov <esyr(a)redhat.com> s390: fix handling of -1 in set{,fs}[gu]id16 syscalls Christian König <ckoenig.leichtzumerken(a)gmail.com> dma-buf: fix reservation_object_wait_timeout_rcu once more v2 Cédric Le Goater <clg(a)kaod.org> powerpc/xive: Use hw CPU ids when configuring the CPU queues Alexey Kardashevskiy <aik(a)ozlabs.ru> powerpc/mm: Flush radix process translations when setting MMU type Nathan Fontenot <nfont(a)linux.vnet.ibm.com> powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove Nicholas Piggin <npiggin(a)gmail.com> powerpc/vas: Don't set uses_vas for kernel windows Sukadev Bhattiprolu <sukadev(a)linux.vnet.ibm.com> powerpc/kernel: Block interrupts when updating TIDR Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> trace_uprobe: Display correct offset in uprobe_events Gang He <ghe(a)suse.com> ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE Brian Norris <briannorris(a)chromium.org> mwifiex: resolve reset vs. remove()/shutdown() deadlocks Bjorn Andersson <bjorn.andersson(a)linaro.org> PM / devfreq: Propagate error from devfreq_add_device() Christian König <ckoenig.leichtzumerken(a)gmail.com> swiotlb: suppress warning when __GFP_NOWARN is set Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix rxe_qp_cleanup() Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix a race condition in rxe_requester() Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix a race condition related to the QP error state Arnd Bergmann <arnd(a)arndb.de> kselftest: fix OOM in memory compaction test Anders Roxell <anders.roxell(a)linaro.org> selftests: seccomp: fix compile error seccomp_bpf Michael J. Ruhl <michael.j.ruhl(a)intel.com> IB/core: Avoid a potential OOPs for an unused optional parameter Bodong Wang <bodong(a)mellanox.com> IB/core: Fix ib_wc structure size to remain in 64 bytes boundary Bart Van Assche <bart.vanassche(a)wdc.com> IB/core: Fix two kernel warnings triggered by rxe registration Jack Morgenstein <jackm(a)dev.mellanox.co.il> IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports Mike Marciniszyn <mike.marciniszyn(a)intel.com> IB/qib: Fix comparison error with qperf compare/swap test Jack Morgenstein <jackm(a)dev.mellanox.co.il> IB/umad: Fix use of unprotected device pointer Steffen Weber <steffen.weber(a)gmail.com> scsi: smartpqi: allow static build ("built-in") ------------- Diffstat: Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- Documentation/filesystems/ext4.txt | 2 +- Makefile | 4 +- arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 - arch/arm/boot/dts/exynos5410.dtsi | 1 - arch/arm/boot/dts/lpc3250-ea3250.dts | 4 +- arch/arm/boot/dts/lpc3250-phy3250.dts | 4 +- arch/arm/boot/dts/mt2701.dtsi | 2 + arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +- arch/arm/boot/dts/s5pv210.dtsi | 1 + arch/arm/boot/dts/spear1310-evb.dts | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 +- arch/arm/boot/dts/spear13xx.dtsi | 6 +- arch/arm/boot/dts/spear600.dtsi | 1 + arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 1 + arch/arm/boot/dts/stih407.dtsi | 3 +- arch/arm/boot/dts/stih410.dtsi | 3 +- arch/arm/mach-pxa/tosa-bt.c | 4 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 +- arch/arm64/kernel/cpu_errata.c | 9 + arch/arm64/kvm/hyp/switch.c | 4 +- arch/arm64/mm/proc.S | 14 +- arch/mips/Kconfig | 12 +- arch/mips/kernel/cps-vec.S | 17 +- arch/mips/kernel/setup.c | 16 +- arch/powerpc/include/asm/topology.h | 5 + arch/powerpc/kernel/process.c | 15 +- arch/powerpc/mm/numa.c | 5 - arch/powerpc/mm/pgtable-radix.c | 95 ++++- arch/powerpc/mm/pgtable_64.c | 2 + arch/powerpc/mm/tlb-radix.c | 2 - arch/powerpc/platforms/powernv/vas-window.c | 16 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 + arch/powerpc/sysdev/xive/spapr.c | 16 +- arch/s390/kernel/compat_linux.c | 8 +- arch/x86/entry/calling.h | 107 +++-- arch/x86/entry/entry_64.S | 92 +---- arch/x86/entry/entry_64_compat.S | 30 ++ arch/x86/events/intel/core.c | 2 +- arch/x86/events/intel/lbr.c | 2 +- arch/x86/events/intel/p6.c | 2 +- arch/x86/include/asm/acpi.h | 2 +- arch/x86/include/asm/barrier.h | 2 +- arch/x86/include/asm/bug.h | 19 +- arch/x86/include/asm/nospec-branch.h | 14 +- arch/x86/include/asm/page_64.h | 4 - arch/x86/include/asm/paravirt.h | 4 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/include/asm/pgtable_32.h | 2 +- arch/x86/include/asm/processor.h | 7 +- arch/x86/include/asm/tlbflush.h | 27 +- arch/x86/kernel/amd_nb.c | 2 +- arch/x86/kernel/apic/apic.c | 6 +- arch/x86/kernel/apm_32.c | 1 + arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/amd.c | 28 +- arch/x86/kernel/cpu/bugs.c | 34 +- arch/x86/kernel/cpu/centaur.c | 4 +- arch/x86/kernel/cpu/common.c | 10 +- arch/x86/kernel/cpu/cyrix.c | 2 +- arch/x86/kernel/cpu/intel.c | 31 +- arch/x86/kernel/cpu/intel_rdt.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 + arch/x86/kernel/cpu/mcheck/mce.c | 17 +- arch/x86/kernel/cpu/microcode/intel.c | 6 +- arch/x86/kernel/cpu/mtrr/generic.c | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 +- arch/x86/kernel/cpu/proc.c | 8 +- arch/x86/kernel/early-quirks.c | 1 + arch/x86/kernel/head_32.S | 4 +- arch/x86/kernel/mpparse.c | 2 +- arch/x86/kernel/paravirt.c | 6 +- arch/x86/kernel/relocate_kernel_64.S | 8 + arch/x86/kernel/smpboot.c | 1 - arch/x86/kernel/traps.c | 2 +- arch/x86/kvm/mmu.c | 10 +- arch/x86/kvm/vmx.c | 7 +- arch/x86/lib/cpu.c | 2 +- arch/x86/mm/init_64.c | 2 +- arch/x86/mm/ioremap.c | 2 +- arch/x86/mm/kmmio.c | 2 +- arch/x86/mm/pgtable_32.c | 2 +- arch/x86/mm/tlb.c | 6 +- arch/x86/platform/uv/tlb_uv.c | 2 +- arch/x86/xen/mmu_pv.c | 6 +- arch/x86/xen/p2m.c | 6 + arch/x86/xen/xen-head.S | 16 + block/blk-wbt.c | 10 +- drivers/base/core.c | 3 + drivers/block/rbd.c | 4 +- drivers/char/hw_random/via-rng.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/longhaul.c | 6 +- drivers/cpufreq/p4-clockmod.c | 2 +- drivers/cpufreq/powernow-k7.c | 2 +- drivers/cpufreq/powernv-cpufreq.c | 4 +- drivers/cpufreq/speedstep-centrino.c | 4 +- drivers/cpufreq/speedstep-lib.c | 6 +- drivers/crypto/padlock-aes.c | 2 +- drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 6 +- drivers/devfreq/devfreq.c | 2 +- drivers/dma-buf/reservation.c | 8 +- drivers/edac/amd64_edac.c | 2 +- drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.h | 2 +- drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/drm_auth.c | 6 + drivers/gpu/drm/qxl/qxl_display.c | 63 ++- drivers/gpu/drm/qxl/qxl_drv.h | 2 + drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/gpu/drm/radeon/si_dpm.c | 5 + drivers/gpu/drm/ttm/ttm_bo.c | 3 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 +- drivers/hwmon/coretemp.c | 6 +- drivers/hwmon/hwmon-vid.c | 2 +- drivers/hwmon/k10temp.c | 2 +- drivers/hwmon/k8temp.c | 2 +- drivers/infiniband/core/device.c | 20 +- drivers/infiniband/core/sysfs.c | 1 - drivers/infiniband/core/user_mad.c | 2 +- drivers/infiniband/core/uverbs_std_types.c | 2 +- drivers/infiniband/hw/mlx4/main.c | 13 +- drivers/infiniband/hw/qib/qib_rc.c | 6 +- drivers/infiniband/sw/rxe/rxe_loc.h | 1 - drivers/infiniband/sw/rxe/rxe_qp.c | 12 +- drivers/infiniband/sw/rxe/rxe_req.c | 9 +- drivers/infiniband/sw/rxe/rxe_resp.c | 2 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 + drivers/infiniband/sw/rxe/rxe_verbs.h | 3 + drivers/md/dm.c | 3 +- drivers/media/tuners/r820t.c | 13 +- drivers/mmc/host/bcm2835.c | 3 +- drivers/mmc/host/meson-gx-mmc.c | 19 +- drivers/mmc/host/sdhci-of-esdhc.c | 8 + drivers/mmc/host/sdhci.c | 164 +++++++- drivers/mmc/host/sdhci.h | 3 + drivers/mtd/nand/vf610_nfc.c | 6 +- drivers/net/ethernet/marvell/mvpp2.c | 11 +- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 + drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +- .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + drivers/pci/dwc/pci-keystone.c | 5 +- drivers/pci/host/pcie-iproc-platform.c | 7 + drivers/pci/host/pcie-iproc.c | 8 +- drivers/pci/host/pcie-iproc.h | 2 + drivers/pci/hotplug/pciehp_hpc.c | 7 + drivers/pci/quirks.c | 2 +- drivers/platform/x86/apple-gmux.c | 48 +-- drivers/platform/x86/wmi.c | 2 +- drivers/rtc/rtc-opal.c | 12 +- drivers/scsi/smartpqi/Makefile | 2 +- drivers/target/iscsi/iscsi_target_auth.c | 3 +- drivers/target/iscsi/iscsi_target_nego.c | 3 + drivers/usb/Kconfig | 8 + drivers/usb/host/Kconfig | 8 - drivers/video/console/dummycon.c | 1 - drivers/video/fbdev/atmel_lcdfb.c | 8 +- drivers/video/fbdev/geode/video_gx.c | 2 +- drivers/xen/xenbus/xenbus.h | 1 + drivers/xen/xenbus/xenbus_comms.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 + fs/btrfs/inode.c | 41 +- fs/btrfs/tree-log.c | 32 +- fs/ext4/inode.c | 16 +- fs/ext4/super.c | 1 + fs/gfs2/bmap.c | 43 +- fs/jbd2/transaction.c | 5 +- fs/mbcache.c | 1 + fs/ocfs2/dlmglue.c | 9 + fs/seq_file.c | 5 +- include/drm/i915_pciids.h | 6 + include/linux/compiler-gcc.h | 7 +- include/linux/compiler.h | 4 + include/linux/cpuidle.h | 2 +- include/linux/jbd2.h | 431 +++++++++++++-------- include/linux/mlx5/driver.h | 2 +- include/linux/mm_inline.h | 6 - include/linux/nospec.h | 36 +- include/rdma/ib_verbs.h | 2 +- include/trace/events/xen.h | 2 +- kernel/memremap.c | 3 +- kernel/trace/trace_events_filter.c | 9 +- kernel/trace/trace_uprobe.c | 2 +- lib/swiotlb.c | 15 +- mm/memory-failure.c | 2 - mm/memory.c | 2 +- mm/page_alloc.c | 22 +- net/9p/trans_virtio.c | 3 +- net/mpls/af_mpls.c | 24 +- net/sunrpc/xprtrdma/rpc_rdma.c | 2 +- net/sunrpc/xprtrdma/verbs.c | 8 +- sound/core/seq/seq_clientmgr.c | 8 +- sound/pci/hda/patch_realtek.c | 72 ++++ sound/usb/mixer.c | 18 +- sound/usb/pcm.c | 9 + sound/usb/quirks.c | 7 +- tools/objtool/check.c | 12 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 4 +- tools/testing/selftests/vm/compaction_test.c | 2 + tools/testing/selftests/x86/Makefile | 24 +- tools/testing/selftests/x86/mpx-mini-test.c | 32 +- tools/testing/selftests/x86/protection_keys.c | 28 -- tools/testing/selftests/x86/single_step_syscall.c | 5 +- tools/testing/selftests/x86/test_mremap_vdso.c | 4 + tools/testing/selftests/x86/test_vdso.c | 55 ++- tools/testing/selftests/x86/test_vsyscall.c | 11 +- 207 files changed, 1625 insertions(+), 897 deletions(-)

7 years, 3 months

4
150
0 0

[PATCH v4 1/4] crypto: caam - Fix null dereference at error path

by Rui Miguel Silva

caam_remove already removes the debugfs entry, so we need to remove the one immediately before calling caam_remove. This fix a NULL dereference at error paths is caam_probe fail. Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support") Tested-by: Ryan Harkin <ryan.harkin(a)linaro.org> Cc: "Horia Geantă" <horia.geanta(a)nxp.com> Cc: Aymen Sghaier <aymen.sghaier(a)nxp.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de> Cc: <stable(a)vger.kernel.org> # 4.12+ Reviewed-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Rui Miguel Silva <rui.silva(a)linaro.org> --- drivers/crypto/caam/ctrl.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c index e843cf410373..361e750f9cba 100644 --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -815,9 +815,6 @@ static int caam_probe(struct platform_device *pdev) return 0; caam_remove: -#ifdef CONFIG_DEBUG_FS - debugfs_remove_recursive(ctrlpriv->dfs_root); -#endif caam_remove(pdev); return ret; -- 2.16.2

7 years, 3 months

1
0
0 0

[PATCH 4.14 000/167] 4.14.21-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.21 release. There are 167 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 Fri Feb 23 12:44:42 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.14.21-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.14.21-rc1 Amir Goldstein <amir73il(a)gmail.com> ovl: hash directory inodes for fsnotify Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> ASoC: acpi: fix machine driver selection based on quirk yinbo.zhu <yinbo.zhu(a)nxp.com> mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb yinbo.zhu <yinbo.zhu(a)nxp.com> mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec yangbo lu <yangbo.lu(a)nxp.com> mmc: sdhci-of-esdhc: disable SD clock for clock value 0 Arnd Bergmann <arnd(a)arndb.de> media: r820t: fix r820t_write_reg for KASAN Linus Walleij <linus.walleij(a)linaro.org> ARM: dts: Delete bogus reference to the charlcd Matthias Brugger <matthias.bgg(a)gmail.com> arm: dts: mt2701: Add reset-cells Matthias Brugger <matthias.bgg(a)gmail.com> arm: dts: mt7623: Update ethsys binding Arnd Bergmann <arnd(a)arndb.de> ARM: dts: s5pv210: add interrupt-parent for ohci Bjorn Andersson <bjorn.andersson(a)linaro.org> arm64: dts: msm8916: Add missing #phy-cells Arnd Bergmann <arnd(a)arndb.de> ARM: pxa/tosa-bt: add MODULE_LICENSE tag Arnd Bergmann <arnd(a)arndb.de> ARM: dts: exynos: fix RTC interrupt for exynos5410 Arnd Bergmann <arnd(a)arndb.de> Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS Hannes Reinecke <hare(a)suse.de> scsi: core: check for device state in __scsi_remove_target() Tony Luck <tony.luck(a)intel.com> x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages James Hogan <jhogan(a)kernel.org> usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT Mikulas Patocka <mpatocka(a)redhat.com> mvpp2: fix multicast address filter Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Fix racy pool initializations Daniel Mack <daniel(a)zonque.org> ALSA: usb: add more device quirks for USB DSD devices Lassi Ylikojola <lassi.ylikojola(a)gmail.com> ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 Jan-Marek Glogowski <glogow(a)fbihome.de> ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Add headset mode support for Dell laptop Kirill Marinushkin <k.marinushkin(a)gmail.com> ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute Hui Wang <hui.wang(a)canonical.com> ALSA: hda - Fix headset mic detection problem for two Dell machines Stefan Agner <stefan(a)agner.ch> mtd: nand: vf610: set correct ooblayout Greg Kurz <groug(a)kaod.org> 9p/trans_virtio: discard zero-length reply Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix unexpected -EEXIST when creating new inode Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix use-after-free on root->orphan_block_rsv Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix extent state leak from tree log Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix crash due to not cleaning up tree log block's dirty bits Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix deadlock in run_delalloc_nocow NeilBrown <neilb(a)suse.com> dm: correctly handle chained bios in dec_pending() Florian Westphal <fw(a)strlen.de> iscsi-target: make sure to wake up sleeping login worker David Disseldorp <ddiss(a)suse.de> target/iscsi: avoid NULL dereference in CHAP auth error path Jens Axboe <axboe(a)kernel.dk> blk-wbt: account flush requests correctly Chuck Lever <chuck.lever(a)oracle.com> xprtrdma: Fix BUG after a device removal Chuck Lever <chuck.lever(a)oracle.com> xprtrdma: Fix calculation of ri_max_send_sges Ray Strode <rstrode(a)redhat.com> drm/qxl: reapply cursor after resetting primary Gerd Hoffmann <kraxel(a)redhat.com> qxl: alloc & use shadow for dumb buffers Will Deacon <will.deacon(a)arm.com> arm64: proc: Set PTE_NG for table entries to avoid traversing them twice Larry Finger <Larry.Finger(a)lwfinger.net> rtlwifi: rtl8821ae: Fix connection lost problem correctly Dan Williams <dan.j.williams(a)intel.com> mpls, nospec: Sanitize array index in mpls_label_ok() Steven Rostedt (VMware) <rostedt(a)goodmis.org> tracing: Fix parsing of globs with a wildcard at the beginning Miklos Szeredi <mszeredi(a)redhat.com> seq_file: fix incomplete reset on read from zero offset Joao Martins <joao.m.martins(a)oracle.com> xenbus: track caller request id Simon Gaiser <simon(a)invisiblethingslab.com> xen: Fix {set,clear}_foreign_p2m_mapping on autotranslating guests Ilya Dryomov <idryomov(a)gmail.com> rbd: whitelist RBD_FEATURE_OPERATIONS feature bit Nicolas Pitre <nicolas.pitre(a)linaro.org> console/dummy: leave .con_font_get set to NULL Johan Hovold <johan(a)kernel.org> video: fbdev: atmel_lcdfb: fix display-timings lookup Johan Hovold <johan(a)kernel.org> PCI: keystone: Fix interrupt-controller-node lookup Ray Jui <ray.jui(a)broadcom.com> PCI: iproc: Fix NULL pointer dereference for BCMA Dongdong Liu <liudongdong3(a)huawei.com> PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode Marcin Nowakowski <marcin.nowakowski(a)mips.com> MIPS: Fix incorrect mem=X@Y handling Corentin Labbe <clabbe.montjoie(a)gmail.com> MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN Jan H. Schönherr <jschoenh(a)amazon.de> mm: Fix memory size alignment in devm_memremap_pages_release() Arnd Bergmann <arnd(a)arndb.de> mm: hide a #warning for COMPILE_TEST Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com> ext4: correct documentation for grpid mount option Zhouyi Zhou <zhouzhouyi(a)gmail.com> ext4: save error to disk in __ext4_grp_locked_error() Harshad Shirwadkar <harshads(a)google.com> ext4: fix a race in the ext4 shutdown path Tobin C. Harding <me(a)tobin.cc> jbd2: fix sphinx kernel-doc build warnings Lukas Wunner <lukas(a)wunner.de> Revert "apple-gmux: lock iGP IO to protect from vgaarb changes" Sagi Grimberg <sagi(a)grimberg.me> mlx5: fix mlx5_get_vector_affinity to start from completion vector 0 Jerome Brunet <jbrunet(a)baylibre.com> Revert "mmc: meson-gx: include tx phase in the tuning process" Phil Elwell <phil(a)raspberrypi.org> mmc: bcm2835: Don't overwrite max frequency unconditionally Linus Walleij <linus.walleij(a)linaro.org> mmc: sdhci: Implement an SDHCI-specific bounce buffer Alexander Potapenko <glider(a)google.com> mbcache: initialize entry->e_referenced in mb_cache_entry_create() Stewart Smith <stewart(a)linux.vnet.ibm.com> rtc-opal: Fix handling of firmware error codes, prevent busy loops Julia Lawall <Julia.Lawall(a)lip6.fr> drm/radeon: adjust tested variable Alex Deucher <alexander.deucher(a)amd.com> drm/radeon: Add dpm quirk for Jet PRO (v2) Shanker Donthineni <shankerd(a)codeaurora.org> arm64: Add missing Falkor part number for branch predictor hardening Daniel Vetter <daniel.vetter(a)ffwll.ch> drm/ast: Load lut in crtc_commit Andrey Grodzovsky <andrey.grodzovsky(a)amd.com> drm/amd/powerplay: Fix smu_table_entry.handle type Ray Strode <rstrode(a)redhat.com> drm/qxl: unref cursor bo when finished with it Tom St Denis <tom.stdenis(a)amd.com> drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap() (v2) Felix Kuehling <Felix.Kuehling(a)amd.com> drm/ttm: Don't add swapped BOs to swap-LRU list Ingo Molnar <mingo(a)kernel.org> x86/entry/64: Fix CR3 restore in paranoid_exit() Gustavo A. R. Silva <garsilva(a)embeddedor.com> x86/cpu: Change type of x86_cache_size variable to unsigned int Dan Carpenter <dan.carpenter(a)oracle.com> x86/spectre: Fix an error message Jia Zhang <qianyue.zj(a)alibaba-inc.com> x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping Rui Wang <rui.y.wang(a)intel.com> selftests/x86/mpx: Fix incorrect bounds with old _sigfault Andy Lutomirski <luto(a)kernel.org> x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() Michal Hocko <mhocko(a)suse.com> kmemcheck: rip it out for real Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> kmemcheck: rip it out Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> kmemcheck: remove whats left of NOTRACK flags Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> kmemcheck: remove annotations Peter Zijlstra <peterz(a)infradead.org> x86/speculation: Add <asm/msr-index.h> dependency Will Deacon <will.deacon(a)arm.com> nospec: Move array_index_nospec() parameter checking into separate macro Dan Williams <dan.j.williams(a)intel.com> x86/speculation: Fix up array_index_nospec_mask() asm constraint Peter Zijlstra <peterz(a)infradead.org> x86/debug: Use UD2 for WARN() Josh Poimboeuf <jpoimboe(a)redhat.com> x86/debug, objtool: Annotate WARN()-related UD2 as reachable Josh Poimboeuf <jpoimboe(a)redhat.com> objtool: Fix segfault in ignore_unreachable_insn() Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c Ingo Molnar <mingo(a)kernel.org> selftests/x86/pkeys: Remove unused functions Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Clean up and document sscanf() usage Dominik Brodowski <linux(a)dominikbrodowski.net> selftests/x86: Fix vDSO selftest segfault for vsyscall=none Borislav Petkov <bp(a)suse.de> x86/entry/64: Remove the unused 'icebp' macro Josh Poimboeuf <jpoimboe(a)redhat.com> x86/entry/64: Fix paranoid_entry() frame pointer warning Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Indent PUSH_AND_CLEAR_REGS and POP_REGS properly Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Use PUSH_AND_CLEAN_REGS in more cases Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Interleave XOR register clearing with PUSH instructions Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Merge the POP_C_REGS and POP_EXTRA_REGS macros into a single POP_REGS macro Dominik Brodowski <linux(a)dominikbrodowski.net> x86/entry/64: Merge SAVE_C_REGS and SAVE_EXTRA_REGS, remove unused extensions Dan Williams <dan.j.williams(a)intel.com> x86/entry/64: Clear registers for exceptions/interrupts, to reduce speculation attack surface Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> PM: cpuidle: Fix cpuidle_poll_state_init() prototype Lukas Wunner <lukas(a)wunner.de> PM / runtime: Update links_count also if !CONFIG_SRCU Ingo Molnar <mingo(a)kernel.org> x86/speculation: Clean up various Spectre related details KarimAllah Ahmed <karahmed(a)amazon.de> KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap KarimAllah Ahmed <karahmed(a)amazon.de> X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs David Woodhouse <dwmw(a)amazon.co.uk> KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods David Woodhouse <dwmw(a)amazon.co.uk> Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" David Woodhouse <dwmw(a)amazon.co.uk> x86/speculation: Correct Speculation Control microcode blacklist again David Woodhouse <dwmw(a)amazon.co.uk> x86/speculation: Update Speculation Control microcode blacklist Nadav Amit <namit(a)vmware.com> x86/mm/pti: Fix PTI comment in entry_SYSCALL_64() Balbir Singh <bsingharora(a)gmail.com> powerpc/mm/radix: Split linear mapping on hot-unplug Artem Savkov <artem.savkov(a)gmail.com> crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate Artem Savkov <artem.savkov(a)gmail.com> crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate Geert Uytterhoeven <geert(a)linux-m68k.org> compiler-gcc.h: __nostackprotector needs gcc-4.4 and up Geert Uytterhoeven <geert(a)linux-m68k.org> compiler-gcc.h: Introduce __optimize function attribute Dan Williams <dan.j.williams(a)intel.com> x86/entry/64/compat: Clear registers for compat syscalls, to reduce speculation attack surface Dan Williams <dan.j.williams(a)intel.com> x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> x86: PM: Make APM idle driver initialize polling state Juergen Gross <jgross(a)suse.com> x86/xen: init %gs very early to avoid page faults with stack protector Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> x86/kexec: Make kexec (mostly) work in 5-level paging mode Lucas De Marchi <lucas.demarchi(a)intel.com> x86/gpu: add CFL to early quirks Anuj Phogat <anuj.phogat(a)gmail.com> drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5 Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> drm/i915: add GT number to intel_device_info Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix spics gpio controller's warning Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix dmas cells Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear600: Add missing interrupt-parent of rtc Sean Wang <sean.wang(a)mediatek.com> arm: dts: mt7623: fix card detection issue on bananapi-r2 Arnd Bergmann <arnd(a)arndb.de> ARM: dts: nomadik: add interrupt-parent for clcd Patrice Chotard <patrice.chotard(a)st.com> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property Arnd Bergmann <arnd(a)arndb.de> ARM: lpc3250: fix uda1380 gpio numbers Bjorn Andersson <bjorn.andersson(a)linaro.org> arm64: dts: msm8916: Correct ipc references for smsm Eugene Syromiatnikov <esyr(a)redhat.com> s390: fix handling of -1 in set{,fs}[gu]id16 syscalls Christian König <ckoenig.leichtzumerken(a)gmail.com> dma-buf: fix reservation_object_wait_timeout_rcu once more v2 Benjamin Herrenschmidt <benh(a)kernel.crashing.org> powerpc: Fix DABR match on hash based systems Cédric Le Goater <clg(a)kaod.org> powerpc/xive: Use hw CPU ids when configuring the CPU queues Alexey Kardashevskiy <aik(a)ozlabs.ru> powerpc/mm: Flush radix process translations when setting MMU type Nathan Fontenot <nfont(a)linux.vnet.ibm.com> powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all Gang He <ghe(a)suse.com> ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE Brian Norris <briannorris(a)chromium.org> mwifiex: resolve reset vs. remove()/shutdown() deadlocks Bjorn Andersson <bjorn.andersson(a)linaro.org> PM / devfreq: Propagate error from devfreq_add_device() Christian König <ckoenig.leichtzumerken(a)gmail.com> swiotlb: suppress warning when __GFP_NOWARN is set Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix rxe_qp_cleanup() Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix a race condition in rxe_requester() Bart Van Assche <bart.vanassche(a)wdc.com> RDMA/rxe: Fix a race condition related to the QP error state Arnd Bergmann <arnd(a)arndb.de> kselftest: fix OOM in memory compaction test Anders Roxell <anders.roxell(a)linaro.org> selftests: seccomp: fix compile error seccomp_bpf Michael J. Ruhl <michael.j.ruhl(a)intel.com> IB/core: Avoid a potential OOPs for an unused optional parameter Bodong Wang <bodong(a)mellanox.com> IB/core: Fix ib_wc structure size to remain in 64 bytes boundary Bart Van Assche <bart.vanassche(a)wdc.com> IB/core: Fix two kernel warnings triggered by rxe registration Jack Morgenstein <jackm(a)dev.mellanox.co.il> IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports Mike Marciniszyn <mike.marciniszyn(a)intel.com> IB/qib: Fix comparison error with qperf compare/swap test Jack Morgenstein <jackm(a)dev.mellanox.co.il> IB/umad: Fix use of unprotected device pointer Steffen Weber <steffen.weber(a)gmail.com> scsi: smartpqi: allow static build ("built-in") Randy Dunlap <rdunlap(a)infradead.org> tracing: Prevent PROFILE_ALL_BRANCHES when FORTIFY_SOURCE=y ------------- Diffstat: Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733 --------------------- Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- Documentation/filesystems/ext4.txt | 2 +- MAINTAINERS | 10 - Makefile | 4 +- arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 - arch/arm/boot/dts/exynos5410.dtsi | 1 - arch/arm/boot/dts/lpc3250-ea3250.dts | 4 +- arch/arm/boot/dts/lpc3250-phy3250.dts | 4 +- arch/arm/boot/dts/mt2701.dtsi | 2 + arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +- arch/arm/boot/dts/s5pv210.dtsi | 1 + arch/arm/boot/dts/spear1310-evb.dts | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 +- arch/arm/boot/dts/spear13xx.dtsi | 6 +- arch/arm/boot/dts/spear600.dtsi | 1 + arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 1 + arch/arm/boot/dts/stih407.dtsi | 3 +- arch/arm/boot/dts/stih410.dtsi | 3 +- arch/arm/include/asm/dma-iommu.h | 1 - arch/arm/include/asm/pgalloc.h | 2 +- arch/arm/mach-pxa/tosa-bt.c | 4 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/arm64/kernel/cpu_errata.c | 9 + arch/arm64/kvm/hyp/switch.c | 4 +- arch/arm64/mm/proc.S | 14 +- arch/mips/Kconfig | 12 +- arch/mips/kernel/setup.c | 16 +- arch/openrisc/include/asm/dma-mapping.h | 1 - arch/powerpc/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/topology.h | 5 + arch/powerpc/kernel/exceptions-64s.S | 2 +- arch/powerpc/kernel/head_32.S | 2 +- arch/powerpc/mm/numa.c | 5 - arch/powerpc/mm/pgtable-radix.c | 95 ++- arch/powerpc/mm/pgtable_64.c | 2 + arch/powerpc/mm/tlb-radix.c | 2 - arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 + arch/powerpc/sysdev/xive/spapr.c | 16 +- arch/s390/kernel/compat_linux.c | 8 +- arch/sh/kernel/dwarf.c | 4 +- arch/sh/kernel/process.c | 2 +- arch/sparc/mm/init_64.c | 4 +- arch/unicore32/include/asm/pgalloc.h | 2 +- arch/x86/Kconfig | 3 +- arch/x86/Makefile | 5 - arch/x86/entry/calling.h | 107 ++- arch/x86/entry/entry_64.S | 92 +-- arch/x86/entry/entry_64_compat.S | 30 + arch/x86/events/intel/core.c | 2 +- arch/x86/events/intel/lbr.c | 2 +- arch/x86/events/intel/p6.c | 2 +- arch/x86/include/asm/acpi.h | 2 +- arch/x86/include/asm/barrier.h | 2 +- arch/x86/include/asm/bug.h | 19 +- arch/x86/include/asm/dma-mapping.h | 1 - arch/x86/include/asm/kmemcheck.h | 43 -- arch/x86/include/asm/nospec-branch.h | 14 +- arch/x86/include/asm/page_64.h | 4 - arch/x86/include/asm/paravirt.h | 4 +- arch/x86/include/asm/paravirt_types.h | 2 +- arch/x86/include/asm/pgtable.h | 5 - arch/x86/include/asm/pgtable_32.h | 2 +- arch/x86/include/asm/pgtable_types.h | 13 - arch/x86/include/asm/processor.h | 7 +- arch/x86/include/asm/string_32.h | 9 - arch/x86/include/asm/string_64.h | 8 - arch/x86/include/asm/tlbflush.h | 27 +- arch/x86/include/asm/xor.h | 5 +- arch/x86/kernel/acpi/apei.c | 2 +- arch/x86/kernel/amd_nb.c | 2 +- arch/x86/kernel/apic/apic.c | 6 +- arch/x86/kernel/apm_32.c | 1 + arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/amd.c | 28 +- arch/x86/kernel/cpu/bugs.c | 34 +- arch/x86/kernel/cpu/centaur.c | 4 +- arch/x86/kernel/cpu/common.c | 10 +- arch/x86/kernel/cpu/cyrix.c | 2 +- arch/x86/kernel/cpu/intel.c | 46 +- arch/x86/kernel/cpu/intel_rdt.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 + arch/x86/kernel/cpu/mcheck/mce.c | 17 +- arch/x86/kernel/cpu/microcode/intel.c | 6 +- arch/x86/kernel/cpu/mtrr/generic.c | 2 +- arch/x86/kernel/cpu/mtrr/main.c | 4 +- arch/x86/kernel/cpu/proc.c | 8 +- arch/x86/kernel/early-quirks.c | 1 + arch/x86/kernel/espfix_64.c | 2 +- arch/x86/kernel/head_32.S | 4 +- arch/x86/kernel/mpparse.c | 2 +- arch/x86/kernel/paravirt.c | 6 +- arch/x86/kernel/relocate_kernel_64.S | 8 + arch/x86/kernel/traps.c | 7 +- arch/x86/kvm/mmu.c | 10 +- arch/x86/kvm/vmx.c | 7 +- arch/x86/lib/cpu.c | 2 +- arch/x86/mm/Makefile | 2 - arch/x86/mm/fault.c | 6 - arch/x86/mm/init.c | 8 +- arch/x86/mm/init_64.c | 4 +- arch/x86/mm/ioremap.c | 2 +- arch/x86/mm/kmemcheck/Makefile | 1 - arch/x86/mm/kmemcheck/error.c | 228 ------- arch/x86/mm/kmemcheck/error.h | 16 - arch/x86/mm/kmemcheck/kmemcheck.c | 658 ------------------ arch/x86/mm/kmemcheck/opcode.c | 107 --- arch/x86/mm/kmemcheck/opcode.h | 10 - arch/x86/mm/kmemcheck/pte.c | 23 - arch/x86/mm/kmemcheck/pte.h | 11 - arch/x86/mm/kmemcheck/selftest.c | 71 -- arch/x86/mm/kmemcheck/selftest.h | 7 - arch/x86/mm/kmemcheck/shadow.c | 173 ----- arch/x86/mm/kmemcheck/shadow.h | 19 - arch/x86/mm/kmmio.c | 2 +- arch/x86/mm/pageattr.c | 10 +- arch/x86/mm/pgtable.c | 2 +- arch/x86/mm/pgtable_32.c | 2 +- arch/x86/mm/tlb.c | 6 +- arch/x86/platform/efi/efi_64.c | 2 +- arch/x86/platform/uv/tlb_uv.c | 2 +- arch/x86/xen/mmu_pv.c | 6 +- arch/x86/xen/p2m.c | 6 + arch/x86/xen/xen-head.S | 16 + block/blk-wbt.c | 10 +- crypto/xor.c | 7 +- drivers/base/core.c | 3 + drivers/block/rbd.c | 4 +- drivers/bluetooth/Kconfig | 2 +- drivers/char/hw_random/via-rng.c | 2 +- drivers/char/random.c | 1 - drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/longhaul.c | 6 +- drivers/cpufreq/p4-clockmod.c | 2 +- drivers/cpufreq/powernow-k7.c | 2 +- drivers/cpufreq/powernv-cpufreq.c | 4 +- drivers/cpufreq/speedstep-centrino.c | 4 +- drivers/cpufreq/speedstep-lib.c | 6 +- drivers/crypto/padlock-aes.c | 2 +- drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 6 +- drivers/devfreq/devfreq.c | 2 +- drivers/dma-buf/reservation.c | 8 +- drivers/edac/amd64_edac.c | 2 +- drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.h | 2 +- drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_pci.c | 193 ++++-- drivers/gpu/drm/qxl/qxl_cmd.c | 6 +- drivers/gpu/drm/qxl/qxl_display.c | 112 +++- drivers/gpu/drm/qxl/qxl_drv.h | 4 + drivers/gpu/drm/qxl/qxl_dumb.c | 1 + drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/gpu/drm/radeon/si_dpm.c | 5 + drivers/gpu/drm/ttm/ttm_bo.c | 3 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 +- drivers/hwmon/coretemp.c | 6 +- drivers/hwmon/hwmon-vid.c | 2 +- drivers/hwmon/k10temp.c | 2 +- drivers/hwmon/k8temp.c | 2 +- drivers/infiniband/core/device.c | 20 +- drivers/infiniband/core/sysfs.c | 1 - drivers/infiniband/core/user_mad.c | 2 +- drivers/infiniband/core/uverbs_std_types.c | 2 +- drivers/infiniband/hw/mlx4/main.c | 13 +- drivers/infiniband/hw/qib/qib_rc.c | 6 +- drivers/infiniband/sw/rxe/rxe_loc.h | 1 - drivers/infiniband/sw/rxe/rxe_qp.c | 12 +- drivers/infiniband/sw/rxe/rxe_req.c | 9 +- drivers/infiniband/sw/rxe/rxe_resp.c | 2 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 + drivers/infiniband/sw/rxe/rxe_verbs.h | 3 + drivers/md/dm.c | 3 +- drivers/media/tuners/r820t.c | 13 +- drivers/misc/c2port/core.c | 2 - drivers/mmc/host/bcm2835.c | 3 +- drivers/mmc/host/meson-gx-mmc.c | 19 +- drivers/mmc/host/sdhci-of-esdhc.c | 64 +- drivers/mmc/host/sdhci.c | 164 ++++- drivers/mmc/host/sdhci.h | 3 + drivers/mtd/nand/vf610_nfc.c | 6 +- drivers/net/ethernet/marvell/mvpp2.c | 11 +- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 + drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +- .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + drivers/pci/dwc/pci-keystone.c | 5 +- drivers/pci/host/pcie-iproc-platform.c | 7 + drivers/pci/host/pcie-iproc.c | 8 +- drivers/pci/host/pcie-iproc.h | 2 + drivers/pci/quirks.c | 2 +- drivers/platform/x86/apple-gmux.c | 48 +- drivers/rtc/rtc-opal.c | 12 +- drivers/scsi/scsi_sysfs.c | 5 +- drivers/scsi/smartpqi/Makefile | 2 +- drivers/target/iscsi/iscsi_target_auth.c | 3 +- drivers/target/iscsi/iscsi_target_nego.c | 3 + drivers/usb/Kconfig | 8 + drivers/usb/host/Kconfig | 8 - drivers/video/console/dummycon.c | 1 - drivers/video/fbdev/atmel_lcdfb.c | 8 +- drivers/video/fbdev/geode/video_gx.c | 2 +- drivers/xen/xenbus/xenbus.h | 1 + drivers/xen/xenbus/xenbus_comms.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 + fs/btrfs/inode.c | 41 +- fs/btrfs/tree-log.c | 32 +- fs/dcache.c | 2 - fs/ext4/inode.c | 16 +- fs/ext4/super.c | 1 + fs/jbd2/transaction.c | 5 +- fs/mbcache.c | 1 + fs/ocfs2/dlmglue.c | 9 + fs/overlayfs/inode.c | 37 +- fs/overlayfs/super.c | 1 + fs/overlayfs/util.c | 4 +- fs/seq_file.c | 5 +- include/drm/i915_pciids.h | 160 +++-- include/linux/c2port.h | 4 - include/linux/compiler-gcc.h | 7 +- include/linux/compiler.h | 4 + include/linux/cpuidle.h | 2 +- include/linux/dma-mapping.h | 8 +- include/linux/filter.h | 2 - include/linux/gfp.h | 9 - include/linux/interrupt.h | 15 - include/linux/jbd2.h | 431 +++++++----- include/linux/kmemcheck.h | 172 ----- include/linux/mlx5/driver.h | 2 +- include/linux/mm_inline.h | 6 - include/linux/mm_types.h | 8 - include/linux/net.h | 3 - include/linux/nospec.h | 36 +- include/linux/ring_buffer.h | 3 - include/linux/skbuff.h | 3 - include/linux/slab.h | 6 - include/linux/thread_info.h | 5 +- include/net/inet_sock.h | 3 - include/net/inet_timewait_sock.h | 4 - include/net/sock.h | 3 - include/rdma/ib_verbs.h | 2 +- include/trace/events/mmflags.h | 1 - include/trace/events/xen.h | 2 +- init/do_mounts.c | 3 +- init/main.c | 1 - kernel/bpf/core.c | 6 - kernel/fork.c | 12 +- kernel/locking/lockdep.c | 3 - kernel/memremap.c | 3 +- kernel/signal.c | 3 +- kernel/softirq.c | 10 - kernel/sysctl.c | 10 - kernel/trace/Kconfig | 2 +- kernel/trace/ring_buffer.c | 3 - kernel/trace/trace_events_filter.c | 9 +- lib/Kconfig.debug | 6 +- lib/Kconfig.kmemcheck | 94 --- lib/swiotlb.c | 15 +- mm/Kconfig.debug | 1 - mm/Makefile | 2 - mm/kmemcheck.c | 126 ---- mm/kmemleak.c | 9 - mm/memory-failure.c | 2 - mm/memory.c | 2 +- mm/page_alloc.c | 14 - mm/slab.c | 16 +- mm/slab.h | 7 +- mm/slab_common.c | 2 +- mm/slub.c | 31 +- net/9p/trans_virtio.c | 3 +- net/core/skbuff.c | 5 - net/core/sock.c | 2 - net/ipv4/inet_timewait_sock.c | 3 - net/ipv4/tcp_input.c | 1 - net/mpls/af_mpls.c | 24 +- net/socket.c | 1 - net/sunrpc/xprtrdma/rpc_rdma.c | 2 +- net/sunrpc/xprtrdma/verbs.c | 8 +- scripts/kernel-doc | 2 - sound/core/seq/seq_clientmgr.c | 8 +- sound/pci/hda/patch_realtek.c | 72 ++ sound/soc/intel/common/sst-match-acpi.c | 8 +- sound/usb/mixer.c | 18 +- sound/usb/pcm.c | 9 + sound/usb/quirks.c | 7 +- tools/include/linux/kmemcheck.h | 9 - tools/objtool/check.c | 12 +- tools/perf/builtin-kmem.c | 1 - tools/testing/selftests/seccomp/seccomp_bpf.c | 4 +- tools/testing/selftests/vm/compaction_test.c | 2 + tools/testing/selftests/x86/Makefile | 22 +- tools/testing/selftests/x86/mpx-mini-test.c | 32 +- tools/testing/selftests/x86/protection_keys.c | 28 - tools/testing/selftests/x86/single_step_syscall.c | 5 +- tools/testing/selftests/x86/test_mremap_vdso.c | 4 + tools/testing/selftests/x86/test_vdso.c | 55 +- tools/testing/selftests/x86/test_vsyscall.c | 11 +- 300 files changed, 1959 insertions(+), 3842 deletions(-)

7 years, 3 months

4
150
0 0

[PATCH 4.4 00/33] 4.4.117-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.117 release. There are 33 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 Fri Feb 23 12:43:54 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.4.117-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.4.117-rc1 Arnd Bergmann <arnd(a)arndb.de> media: r820t: fix r820t_write_reg for KASAN Arnd Bergmann <arnd(a)arndb.de> ARM: dts: s5pv210: add interrupt-parent for ohci Arnd Bergmann <arnd(a)arndb.de> ARM: pxa/tosa-bt: add MODULE_LICENSE tag Linus Torvalds <torvalds(a)linux-foundation.org> vfs: don't do RCU lookup of empty pathnames Arnd Bergmann <arnd(a)arndb.de> x86: fix build warnign with 32-bit PAE NeilBrown <neilb(a)suse.com> dm: correctly handle chained bios in dec_pending() Mikulas Patocka <mpatocka(a)redhat.com> mvpp2: fix multicast address filter Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Fix racy pool initializations Lassi Ylikojola <lassi.ylikojola(a)gmail.com> ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 Jan-Marek Glogowski <glogow(a)fbihome.de> ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 Kirill Marinushkin <k.marinushkin(a)gmail.com> ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute Hui Wang <hui.wang(a)canonical.com> ALSA: hda - Fix headset mic detection problem for two Dell machines Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix unexpected -EEXIST when creating new inode Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix crash due to not cleaning up tree log block's dirty bits Liu Bo <bo.li.liu(a)oracle.com> Btrfs: fix deadlock in run_delalloc_nocow Larry Finger <Larry.Finger(a)lwfinger.net> rtlwifi: rtl8821ae: Fix connection lost problem correctly Nicolas Pitre <nicolas.pitre(a)linaro.org> console/dummy: leave .con_font_get set to NULL Johan Hovold <johan(a)kernel.org> video: fbdev: atmel_lcdfb: fix display-timings lookup Arnd Bergmann <arnd(a)arndb.de> mm: hide a #warning for COMPILE_TEST Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com> ext4: correct documentation for grpid mount option Zhouyi Zhou <zhouzhouyi(a)gmail.com> ext4: save error to disk in __ext4_grp_locked_error() Stewart Smith <stewart(a)linux.vnet.ibm.com> rtc-opal: Fix handling of firmware error codes, prevent busy loops Julia Lawall <Julia.Lawall(a)lip6.fr> drm/radeon: adjust tested variable Gustavo A. R. Silva <garsilva(a)embeddedor.com> x86/cpu: Change type of x86_cache_size variable to unsigned int David Woodhouse <dwmw(a)amazon.co.uk> KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Fix regression by incorrect ioctl_mutex usages Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix spics gpio controller's warning Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear13xx: Fix dmas cells Viresh Kumar <viresh.kumar(a)linaro.org> arm: spear600: Add missing interrupt-parent of rtc Patrice Chotard <patrice.chotard(a)st.com> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property Eugene Syromiatnikov <esyr(a)redhat.com> s390: fix handling of -1 in set{,fs}[gu]id16 syscalls Bjorn Andersson <bjorn.andersson(a)linaro.org> PM / devfreq: Propagate error from devfreq_add_device() Jack Morgenstein <jackm(a)dev.mellanox.co.il> IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports ------------- Diffstat: Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- Documentation/filesystems/ext4.txt | 2 +- Makefile | 4 ++-- arch/arm/boot/dts/s5pv210.dtsi | 1 + arch/arm/boot/dts/spear1310-evb.dts | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 ++-- arch/arm/boot/dts/spear13xx.dtsi | 6 ++--- arch/arm/boot/dts/spear600.dtsi | 1 + arch/arm/boot/dts/stih407.dtsi | 3 ++- arch/arm/boot/dts/stih410.dtsi | 3 ++- arch/arm/mach-pxa/tosa-bt.c | 4 ++++ arch/s390/kernel/compat_linux.c | 8 +++---- arch/x86/include/asm/processor.h | 2 +- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/cpu/microcode/intel.c | 2 +- arch/x86/kernel/cpu/proc.c | 4 ++-- arch/x86/kvm/mmu.c | 10 ++++---- drivers/devfreq/devfreq.c | 2 +- drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/infiniband/hw/mlx4/main.c | 13 ++++------ drivers/md/dm.c | 3 ++- drivers/media/tuners/r820t.c | 13 ++++++---- drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++--- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 ++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + drivers/rtc/rtc-opal.c | 12 ++++++++-- drivers/video/console/dummycon.c | 1 - drivers/video/fbdev/atmel_lcdfb.c | 8 ++++++- fs/btrfs/inode.c | 5 +++- fs/btrfs/tree-log.c | 27 +++++++++++++++++++++ fs/ext4/super.c | 1 + fs/namei.c | 3 +++ include/linux/kaiser.h | 2 +- mm/memory.c | 2 +- sound/core/seq/seq_clientmgr.c | 23 ++++++++++-------- sound/pci/hda/patch_realtek.c | 28 ++++++++++++++++++++++ sound/usb/mixer.c | 18 ++++++++------ sound/usb/pcm.c | 9 +++++++ 39 files changed, 181 insertions(+), 71 deletions(-)

7 years, 3 months

5
34
0 0

Re: [PATCH 4.9 34/77] powerpc: fix build errors in stable tree

by Michael Ellerman

Yves-Alexis Perez <corsac(a)debian.org> writes: > On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote: >> So I guess this patch is OK for now, but we do need a full back port of >> 222f20f to 4.9. > > Hi, > > in the light of this, do you know the full status of protections against > Meltdown on powerpc/ppc64el architecures on 4.9? With the patches I just sent, for pseries and powernv, the mitigation should be in place. On machines with updated firmware we'll use the hardware-assisted L1 flush, otherwise we fallback to doing it in software. cheers

7 years, 3 months

1
0
0 0

[RFC v2] ALSA: hda: Add a power_save blacklist

by Hans de Goede

On some boards setting power_save to a non 0 value leads to clicking / popping sounds when ever we enter/leave powersaving mode. Ideally we would figure out how to avoid these sounds, but that is not always feasible. This commit adds a blacklist for devices where powersaving is known to cause problems and disables it on these devices. Note I tried to put this blacklist in userspace first: https://github.com/systemd/systemd/pull/8128 But the systemd maintainers rightfully pointed out that it would be impossible to then later remove entries once we actually find a way to make power-saving work on listed boards without issues. Having this list in the kernel will allow removal of the blacklist entry in the same commit which fixes the clicks / plops. The blacklist only applies to the default power_save module-option value, if an user explicitly sets the module-option then the blacklist is not used. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198611 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in RFC v2: -Only use the blacklist if the power_save module-option is not explicitly set by the user --- sound/pci/hda/hda_intel.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c71dcacea807..7c588b0d6c96 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -181,7 +181,7 @@ static const struct kernel_param_ops param_ops_xint = { }; #define param_check_xint param_check_int -static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; +static int power_save = -1; module_param(power_save, xint, 0644); MODULE_PARM_DESC(power_save, "Automatic power-saving timeout " "(in second, 0 = disable)."); @@ -2186,6 +2186,22 @@ static int azx_probe(struct pci_dev *pci, return err; } +/* On some boards setting power_save to a non 0 value leads to clicking / + * popping sounds when ever we enter/leave powersaving mode. Ideally we would + * figure out how to avoid these sounds, but that is not always feasible. + * So we keep a list of devices where we disable powersaving as its known + * to causes problems on these devices. + */ +static struct snd_pci_quirk power_save_blacklist[] = { + /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ + SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0), + /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ + SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0), + /* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */ + SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0), + {} +}; + /* number of codec slots for each chipset: 0 = default slots (i.e. 4) */ static unsigned int azx_max_codecs[AZX_NUM_DRIVERS] = { [AZX_DRIVER_NVIDIA] = 8, @@ -2197,6 +2213,7 @@ static int azx_probe_continue(struct azx *chip) struct hda_intel *hda = container_of(chip, struct hda_intel, chip); struct hdac_bus *bus = azx_bus(chip); struct pci_dev *pci = chip->pci; + const struct snd_pci_quirk *q; int dev = chip->dev_index; int err; @@ -2278,6 +2295,16 @@ static int azx_probe_continue(struct azx *chip) chip->running = 1; azx_add_card_list(chip); + + if (power_save == -1) { + power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; + q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist); + if (q && power_save) { + dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n", + q->subvendor, q->subdevice); + power_save = 0; + } + } snd_hda_set_power_save(&chip->bus, power_save * 1000); if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo) pm_runtime_put_autosuspend(&pci->dev); -- 2.14.3

7 years, 3 months

2
1
0 0

patch "mei: me: add cannon point device ids" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add cannon point device ids to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Sun, 18 Feb 2018 11:05:15 +0200 Subject: mei: me: add cannon point device ids Add CNP LP and CNP H device ids for cannon lake and coffee lake platforms. Cc: <stable(a)vger.kernel.org> 4.14+ Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 3 +++ drivers/misc/mei/pci-me.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index 0ccccbaf530d..bda3bd8f3141 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -132,6 +132,9 @@ #define MEI_DEV_ID_KBP 0xA2BA /* Kaby Point */ #define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */ +#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */ +#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */ + /* * MEI HW Section */ diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index 4a0ccda4d04b..f915000e5bf9 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -98,6 +98,9 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_KBP, MEI_ME_PCH8_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)}, + /* required last entry */ {0, } }; -- 2.16.2

7 years, 3 months

1
0
0 0

patch "mei: me: add cannon point device ids for 4th device" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add cannon point device ids for 4th device to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 2a4ac172c2f257d28c47b90c9e381bec31edcc44 Mon Sep 17 00:00:00 2001 From: Tomas Winkler <tomas.winkler(a)intel.com> Date: Sun, 18 Feb 2018 11:05:16 +0200 Subject: mei: me: add cannon point device ids for 4th device Add cannon point device ids for 4th (itouch) device. Cc: <stable(a)vger.kernel.org> 4.14+ Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index bda3bd8f3141..e4b10b2d1a08 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -133,7 +133,9 @@ #define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */ #define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */ +#define MEI_DEV_ID_CNP_LP_4 0x9DE4 /* Cannon Point LP 4 (iTouch) */ #define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */ +#define MEI_DEV_ID_CNP_H_4 0xA364 /* Cannon Point H 4 (iTouch) */ /* * MEI HW Section diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index f915000e5bf9..ea4e152270a3 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -99,7 +99,9 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP_4, MEI_ME_PCH8_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)}, /* required last entry */ {0, } -- 2.16.2

7 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] PCI: keystone: Fix interrupt-controller-node lookup" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Fri, 17 Nov 2017 14:38:31 +0100 Subject: [PATCH] PCI: keystone: Fix interrupt-controller-node lookup Fix child-node lookup during initialisation which was using the wrong OF-helper and ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent pci node could end up being prematurely freed as of_find_node_by_name() drops a reference to its first argument. Any matching child interrupt-controller node was also leaked. Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver") Cc: stable <stable(a)vger.kernel.org> # 3.18 Acked-by: Murali Karicheri <m-karicheri2(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> [lorenzo.pieralisi(a)arm.com: updated commit subject] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c index 5bee3af47588..39405598b22d 100644 --- a/drivers/pci/dwc/pci-keystone.c +++ b/drivers/pci/dwc/pci-keystone.c @@ -178,7 +178,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie, } /* interrupt controller is in a child node */ - *np_temp = of_find_node_by_name(np_pcie, controller); + *np_temp = of_get_child_by_name(np_pcie, controller); if (!(*np_temp)) { dev_err(dev, "Node for %s is absent\n", controller); return -EINVAL; @@ -187,6 +187,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie, temp = of_irq_count(*np_temp); if (!temp) { dev_err(dev, "No IRQ entries in %s\n", controller); + of_node_put(*np_temp); return -EINVAL; } @@ -204,6 +205,8 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie, break; } + of_node_put(*np_temp); + if (temp) { *num_irqs = temp; return 0;

7 years, 3 months

2
1
0 0

Re: [PATCH 4.9 34/77] powerpc: fix build errors in stable tree

by Greg Kroah-Hartman

On Thu, Feb 22, 2018 at 10:33:50AM +0100, Yves-Alexis Perez wrote: > On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote: > > So I guess this patch is OK for now, but we do need a full back port of > > 222f20f to 4.9. > > Hi, > > in the light of this, do you know the full status of protections against > Meltdown on powerpc/ppc64el architecures on 4.9? Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the files there say? thanks, greg k-h

7 years, 3 months

1
0
0 0

[RFC] ALSA: hda: Add a power_save blacklist

by Hans de Goede

On some boards setting power_save to a non 0 value leads to clicking / popping sounds when ever we enter/leave powersaving mode. Ideally we would figure out how to avoid these sounds, but that is not always feasible. This commit adds a blacklist for devices where powersaving is known to cause problems and disables it on these devices. Note I tried to put this blacklist in userspace first: https://github.com/systemd/systemd/pull/8128 But the systemd maintainers rightfully pointed out that it would be impossible to then later remove entries once we actually find a way to make power-saving work on listed boards without issues. Having this list in the kernel will allow removal of the blacklist entry in the same commit which fixes the clicks / plops. I've chosen to also apply the blacklist to changes made through /sys/module/snd_hda_intel/parameters/power_save, since tools such as powertop and TLP do this automatically. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1533858 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- About the choice to also apply this to changes made through /sys/module/snd_hda_intel/parameters/power_save, one could argue that this will get in the way of users who want the power-saving anyways and are willing to live with the clicks/plops. An alternative approach would be to only apply this to the value of the module-parameter at boot and then only when it matches CONFIG_SND_HDA_POWER_SAVE_DEFAULT. I'm open to changing this for v2. --- sound/pci/hda/hda_intel.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c71dcacea807..ea612aeb1663 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -936,6 +936,34 @@ static unsigned int azx_get_pos_skl(struct azx *chip, struct azx_dev *azx_dev) return azx_get_pos_posbuf(chip, azx_dev); } +/* On some boards setting power_save to a non 0 value leads to clicking / + * popping sounds when ever we enter/leave powersaving mode. Ideally we would + * figure out how to avoid these sounds, but that is not always feasible. + * So we keep a list of devices where we disable powersaving as its known to + * causes problems on these devices. + */ +static struct snd_pci_quirk power_save_blacklist[] = { + /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ + SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0), + /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ + SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0), + /* https://bugzilla.redhat.com/show_bug.cgi?id=1533858 */ + SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0), + {} +}; + +static void check_power_save_blacklist(struct azx *chip) +{ + const struct snd_pci_quirk *q; + + q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist); + if (q && power_save) { + dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n", + q->subvendor, q->subdevice); + power_save = 0; + } +} + #ifdef CONFIG_PM static DEFINE_MUTEX(card_list_lock); static LIST_HEAD(card_list); @@ -972,6 +1000,7 @@ static int param_set_xint(const char *val, const struct kernel_param *kp) chip = &hda->chip; if (!hda->probe_continued || chip->disabled) continue; + check_power_save_blacklist(chip); snd_hda_set_power_save(&chip->bus, power_save * 1000); } mutex_unlock(&card_list_lock); @@ -2278,6 +2307,7 @@ static int azx_probe_continue(struct azx *chip) chip->running = 1; azx_add_card_list(chip); + check_power_save_blacklist(chip); snd_hda_set_power_save(&chip->bus, power_save * 1000); if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo) pm_runtime_put_autosuspend(&pci->dev); -- 2.14.3

7 years, 3 months

1
0
0 0

[PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file

by Christophe Leroy

Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721 Performing the hash of an empty file leads to a kernel Oops [ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c [ 44.512819] Faulting instruction address: 0xc02d2be8 [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1] [ 44.529171] BE PREEMPT CMPC885 [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81 [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000 [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea) [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000 [ 44.560855] DAR: 0000000c DSISR: c0000000 [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000 [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008 [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10 [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0 [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700 [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700 [ 44.608868] Call Trace: [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable) [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210 [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138 [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84 [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4 [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38 [ 44.645530] Instruction dump: [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000 [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c This patch fixes that Oops by checking if src is NULL. Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic") Cc: <stable(a)vger.kernel.org> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> --- drivers/crypto/talitos.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index dff88838dce7..42913116620a 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1124,6 +1124,11 @@ int talitos_sg_map(struct device *dev, struct scatterlist *src, struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); + if (!src) { + *ptr = zero_entry; + return 1; + } + to_talitos_ptr_len(ptr, len, is_sec1); to_talitos_ptr_ext_set(ptr, 0, is_sec1); -- 2.13.3

7 years, 3 months

3
2
0 0

Re: [PATCH 4.10 070/111] audit: fix auditd/kernel connection state tracking

by Peter Zijlstra

On Tue, Mar 28, 2017 at 02:30:56PM +0200, Greg Kroah-Hartman wrote: > 4.10-stable review patch. If anyone has any objections, please let me know. > + if (!(auditd_test_task(current) || > + (current == __mutex_owner(&audit_cmd_mutex)))) { > + long stime = audit_backlog_wait_time; Since I cannot find the original email on lkml, NAK on this. __mutex_owner() is not a general purpose helper function.

7 years, 3 months

3
8
0 0

[patch 16/16] mm: don't defer struct page initialization for Xen pv guests

by akpm＠linux-foundation.org

From: Juergen Gross <jgross(a)suse.com> Subject: mm: don't defer struct page initialization for Xen pv guests f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page tables instead of asking the hypervisor to do so. The result is a crash like the following: [ 0.004000] BUG: unable to handle kernel paging request at ffff8801ead19008 [ 0.004000] IP: xen_set_pud+0x4e/0xd0 [ 0.004000] PGD 1c0a067 P4D 1c0a067 PUD 23a0067 PMD 1e9de0067 PTE 80100001ead19065 [ 0.004000] Oops: 0003 [#1] PREEMPT SMP [ 0.004000] Modules linked in: [ 0.004000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-default+ #271 [ 0.004000] Hardware name: Dell Inc. Latitude E6440/0159N7, BIOS A07 06/26/2014 [ 0.004000] task: ffffffff81c10480 task.stack: ffffffff81c00000 [ 0.004000] RIP: e030:xen_set_pud+0x4e/0xd0 [ 0.004000] RSP: e02b:ffffffff81c03cd8 EFLAGS: 00010246 [ 0.004000] RAX: 002ffff800000800 RBX: ffff88020fd31000 RCX: 0000000000000000 [ 0.004000] RDX: ffffea0000000000 RSI: 00000001b8308067 RDI: ffff8801ead19008 [ 0.004000] RBP: ffff8801ead19008 R08: aaaaaaaaaaaaaaaa R09: 00000000063f4c80 [ 0.004000] R10: aaaaaaaaaaaaaaaa R11: 0720072007200720 R12: 00000001b8308067 [ 0.004000] R13: ffffffff81c8a9cc R14: ffff88018fd31000 R15: 000077ff80000000 [ 0.004000] FS: 0000000000000000(0000) GS:ffff88020f600000(0000) knlGS:0000000000000000 [ 0.004000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.004000] CR2: ffff8801ead19008 CR3: 0000000001c09000 CR4: 0000000000042660 [ 0.004000] Call Trace: [ 0.004000] __pmd_alloc+0x128/0x140 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] ioremap_page_range+0x3f4/0x410 [ 0.004000] ? acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] __ioremap_caller+0x1c3/0x2e0 [ 0.004000] acpi_os_map_iomem+0x175/0x1b0 [ 0.004000] acpi_tb_acquire_table+0x39/0x66 [ 0.004000] acpi_tb_validate_table+0x44/0x7c [ 0.004000] acpi_tb_verify_temp_table+0x45/0x304 [ 0.004000] ? acpi_ut_acquire_mutex+0x12a/0x1c2 [ 0.004000] acpi_reallocate_root_table+0x12d/0x141 [ 0.004000] acpi_early_init+0x4d/0x10a [ 0.004000] start_kernel+0x3eb/0x4a1 [ 0.004000] ? set_init_arg+0x55/0x55 [ 0.004000] xen_start_kernel+0x528/0x532 [ 0.004000] Code: 48 01 e8 48 0f 42 15 a2 fd be 00 48 01 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 c1 e0 06 48 01 d0 48 8b 00 f6 c4 02 75 5d <4c> 89 65 00 5b 5d 41 5c c3 65 8b 05 52 9f fe 7e 89 c0 48 0f a3 [ 0.004000] RIP: xen_set_pud+0x4e/0xd0 RSP: ffffffff81c03cd8 [ 0.004000] CR2: ffff8801ead19008 [ 0.004000] ---[ end trace 38eca2e56f1b642e ]--- Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Pavel said: : This is unique for Xen, so this particular issue won't effect other : configurations. I am going to investigate if there is a way to : re-enable deferred page initialization on xen guests. [akpm(a)linux-foundation.org: explicitly include xen.h] Link: http://lkml.kernel.org/r/20180216154101.22865-1-jgross@suse.com Fixes: f7f99100d8d95d ("mm: stop zeroing memory during allocation in vmemmap") Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Cc: Steven Sistare <steven.sistare(a)oracle.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Bob Picco <bob.picco(a)oracle.com> Cc: <stable(a)vger.kernel.org> [4.15.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff -puN mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests mm/page_alloc.c --- a/mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests +++ a/mm/page_alloc.c @@ -46,6 +46,7 @@ #include <linux/stop_machine.h> #include <linux/sort.h> #include <linux/pfn.h> +#include <xen/xen.h> #include <linux/backing-dev.h> #include <linux/fault-inject.h> #include <linux/page-isolation.h> @@ -347,6 +348,9 @@ static inline bool update_defer_init(pg_ /* Always populate low zones for address-constrained allocations */ if (zone_end < pgdat_end_pfn(pgdat)) return true; + /* Xen PV domains need page structures early */ + if (xen_pv_domain()) + return true; (*nr_initialised)++; if ((*nr_initialised > pgdat->static_init_pgcnt) && (pfn & (PAGES_PER_SECTION - 1)) == 0) { _

7 years, 3 months

1
0
0 0

[patch 14/16] vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems

by akpm＠linux-foundation.org

From: Michal Hocko <mhocko(a)suse.com> Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly"). saa7146_vmalloc_build_pgtable uses vmalloc_32 and it is reasonable to expect that the resulting page is not in highmem. The above commit aimed to add __GFP_HIGHMEM only for those requests which do not specify any zone modifier gfp flag. vmalloc_32 relies on GFP_VMALLOC32 which should do the right thing. Except it has been missed that GFP_VMALLOC32 is an alias for GFP_KERNEL on 32b architectures. Thanks to Matthew to notice this. Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32 for !64b arches (as a bailout). This should do the right thing and use ZONE_NORMAL which should be always below 4G on 32b systems. Debugged by Matthew Wilcox. [akpm(a)linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”) Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Laura Abbott <labbott(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff -puN mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems mm/vmalloc.c --- a/mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems +++ a/mm/vmalloc.c @@ -1943,11 +1943,15 @@ void *vmalloc_exec(unsigned long size) } #if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32) -#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL +#define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL) #elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA) -#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL +#define GFP_VMALLOC32 (GFP_DMA | GFP_KERNEL) #else -#define GFP_VMALLOC32 GFP_KERNEL +/* + * 64b systems should always have either DMA or DMA32 zones. For others + * GFP_DMA32 should do the right thing and use the normal zone. + */ +#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL #endif /** _

7 years, 3 months

1
0
0 0

[patch 08/16] mm, swap, frontswap: fix THP swap if frontswap enabled

by akpm＠linux-foundation.org

From: Huang Ying <huang.ying.caritas(a)gmail.com> Subject: mm, swap, frontswap: fix THP swap if frontswap enabled It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page) and frontswap (via zswap) are both enabled, when memory goes low so that swap is triggered, segfault and memory corruption will occur in random user space applications as follow, kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000] #0 0x00007fc08889ae0d _int_malloc (libc.so.6) #1 0x00007fc08889c2f3 malloc (libc.so.6) #2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt) #3 0x0000560e6005e75c n/a (urxvt) #4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt) #5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt) #6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt) #7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt) #8 0x0000560e6005cb55 ev_run (urxvt) #9 0x0000560e6003b9b9 main (urxvt) #10 0x00007fc08883af4a __libc_start_main (libc.so.6) #11 0x0000560e6003f9da _start (urxvt) After bisection, it was found the first bad commit is bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out"). The root cause is as follows: When the pages are written to swap device during swapping out in swap_writepage(), zswap (fontswap) is tried to compress the pages to improve performance. But zswap (frontswap) will treat THP as a normal page, so only the head page is saved. After swapping in, tail pages will not be restored to their original contents, causing memory corruption in the applications. This is fixed by refusing to save page in the frontswap store functions if the page is a THP. So that the THP will be swapped out to swap device. Another choice is to split THP if frontswap is enabled. But it is found that the frontswap enabling isn't flexible. For example, if CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if zswap itself isn't enabled. Frontswap has multiple backends, to make it easy for one backend to enable THP support, the THP checking is put in backend frontswap store functions instead of the general interfaces. Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out") Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Suggested-by: Minchan Kim <minchan(a)kernel.org> [put THP checking in backend] Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Cc: Dan Streetman <ddstreet(a)ieee.org> Cc: Seth Jennings <sjenning(a)redhat.com> Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: Shaohua Li <shli(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: Juergen Gross <jgross(a)suse.com> Cc: <stable(a)vger.kernel.org> [4.14] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/xen/tmem.c | 4 ++++ mm/zswap.c | 6 ++++++ 2 files changed, 10 insertions(+) diff -puN drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 drivers/xen/tmem.c --- a/drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 +++ a/drivers/xen/tmem.c @@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned int pool = tmem_frontswap_poolid; int ret; + /* THP isn't supported */ + if (PageTransHuge(page)) + return -1; + if (pool < 0) return -1; if (ind64 != ind) diff -puN mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 mm/zswap.c --- a/mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 +++ a/mm/zswap.c @@ -1007,6 +1007,12 @@ static int zswap_frontswap_store(unsigne u8 *src, *dst; struct zswap_header zhdr = { .swpentry = swp_entry(type, offset) }; + /* THP isn't supported */ + if (PageTransHuge(page)) { + ret = -EINVAL; + goto reject; + } + if (!zswap_enabled || !tree) { ret = -ENODEV; goto reject; _

7 years, 3 months

1
0
0 0

[patch 03/16] Kbuild: always define endianess in kconfig.h

by akpm＠linux-foundation.org

From: Arnd Bergmann <arnd(a)arndb.de> Subject: Kbuild: always define endianess in kconfig.h Build testing with LTO found a couple of files that get compiled differently depending on whether asm/byteorder.h gets included early enough or not. In particular, include/asm-generic/qrwlock_types.h is affected by this, but there are probably others as well. The symptom is a series of LTO link time warnings, including these: net/netlabel/netlabel_unlabeled.h:223: error: type of 'netlbl_unlhsh_add' does not match original declaration [-Werror=lto-type-mismatch] int netlbl_unlhsh_add(struct net *net, net/netlabel/netlabel_unlabeled.c:377: note: 'netlbl_unlhsh_add' was previously declared here include/net/ipv6.h:360: error: type of 'ipv6_renew_options_kern' does not match original declaration [-Werror=lto-type-mismatch] ipv6_renew_options_kern(struct sock *sk, net/ipv6/exthdrs.c:1162: note: 'ipv6_renew_options_kern' was previously declared here net/core/dev.c:761: note: 'dev_get_by_name_rcu' was previously declared here struct net_device *dev_get_by_name_rcu(struct net *net, const char *name) net/core/dev.c:761: note: code may be misoptimized unless -fno-strict-aliasing is used drivers/gpu/drm/i915/i915_drv.h:3377: error: type of 'i915_gem_object_set_to_wc_domain' does not match original declaration [-Werror=lto-type-mismatch] i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write); drivers/gpu/drm/i915/i915_gem.c:3639: note: 'i915_gem_object_set_to_wc_domain' was previously declared here include/linux/debugfs.h:92:9: error: type of 'debugfs_attr_read' does not match original declaration [-Werror=lto-type-mismatch] ssize_t debugfs_attr_read(struct file *file, char __user *buf, fs/debugfs/file.c:318: note: 'debugfs_attr_read' was previously declared here include/linux/rwlock_api_smp.h:30: error: type of '_raw_read_unlock' does not match original declaration [-Werror=lto-type-mismatch] void __lockfunc _raw_read_unlock(rwlock_t *lock) __releases(lock); kernel/locking/spinlock.c:246:26: note: '_raw_read_unlock' was previously declared here include/linux/fs.h:3308:5: error: type of 'simple_attr_open' does not match original declaration [-Werror=lto-type-mismatch] int simple_attr_open(struct inode *inode, struct file *file, fs/libfs.c:795: note: 'simple_attr_open' was previously declared here All of the above are caused by include/asm-generic/qrwlock_types.h failing to include asm/byteorder.h after commit e0d02285f16e ("locking/qrwlock: Use 'struct qrwlock' instead of 'struct __qrwlock'") in linux-4.15. Similar bugs may or may not exist in older kernels as well, but there is no easy way to test those with link-time optimizations, and kernels before 4.14 are harder to fix because they don't have Babu's patch series We had similar issues with CONFIG_ symbols in the past and ended up always including the configuration headers though linux/kconfig.h. This works around the issue through that same file, defining either __BIG_ENDIAN or __LITTLE_ENDIAN depending on CONFIG_CPU_BIG_ENDIAN, which is now always set on all architectures since commit 4c97a0c8fee3 ("arch: define CPU_BIG_ENDIAN for all fixed big endian archs"). Link: http://lkml.kernel.org/r/20180202154104.1522809-2-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Babu Moger <babu.moger(a)amd.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Nicolas Pitre <nico(a)linaro.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Will Deacon <will.deacon(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kconfig.h | 6 ++++++ 1 file changed, 6 insertions(+) diff -puN include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh include/linux/kconfig.h --- a/include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh +++ a/include/linux/kconfig.h @@ -4,6 +4,12 @@ #include <generated/autoconf.h> +#ifdef CONFIG_CPU_BIG_ENDIAN +#define __BIG_ENDIAN 4321 +#else +#define __LITTLE_ENDIAN 1234 +#endif + #define __ARG_PLACEHOLDER_1 0, #define __take_second_arg(__ignored, val, ...) val _

7 years, 3 months

1
0
0 0

[PATCH] radeon: hide pointless #warning when compile testing

by Arnd Bergmann

In randconfig testing, we sometimes get this warning: drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create': drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp] #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \ This is rather annoying since almost all other code produces no build-time output unless we have found a real bug. We already fixed this in the amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for compile testing") by adding a CONFIG_COMPILE_TEST check last year and agreed to do the same here, but both Michel and I then forgot about it until I came across the issue again now. For stable kernels, as this is one of very few remaining randconfig warnings in 4.14. Cc: stable(a)vger.kernel.org Link: https://patchwork.kernel.org/patch/9550009/ Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/gpu/drm/radeon/radeon_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 093594976126..54c2b4fc5ead 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -238,9 +238,10 @@ int radeon_bo_create(struct radeon_device *rdev, * may be slow * See https://bugs.freedesktop.org/show_bug.cgi?id=88758 */ - +#ifndef CONFIG_COMPILE_TEST #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \ thanks to write-combining +#endif if (bo->flags & RADEON_GEM_GTT_WC) DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for " -- 2.9.0

7 years, 3 months

2
1
0 0

[Linux-stable-mirror] [GIT PULL] arm64 spectre and meltdown mitigations for -stable

by Will Deacon

Hi Greg, I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree? I understand that Ard (cc'd) is using this stack to create a version for 4.14 too. Note that there are two commits in here that are already in stable: 9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references so you can skip those when applying. Please shout if you run into trouble. Thanks, Will --->8 The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff: Linux 4.15 (2018-01-28 13:20:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-spectre-meltdown-for-4.15-stable for you to fetch changes up to a4c4410bae3dc1f00ab3bfb9d425740bf197b5b6: [Variant 2/Spectre-v2] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround (2018-02-07 15:48:57 +0000) ---------------------------------------------------------------- arm64 Spectre and Meltdown mitigations based on v4.15 ---------------------------------------------------------------- Catalin Marinas (1): [Variant 3/Meltdown] arm64: kpti: Fix the interaction between ASID switching and software PAN Dan Williams (1): [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references James Morse (1): [Variant 2/Spectre-v2] arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early Jayachandran C (3): [Variant 3/Meltdown] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs [Variant 3/Meltdown] arm64: Turn on KPTI only on CPUs that need it [Variant 2/Spectre-v2] arm64: Branch predictor hardening for Cavium ThunderX2 Marc Zyngier (20): [Variant 3/Meltdown] arm64: Force KPTI to be disabled on Cavium ThunderX [Variant 2/Spectre-v2] arm64: Move post_ttbr_update_workaround to C code [Variant 2/Spectre-v2] arm64: Move BP hardening to check_and_switch_context [Variant 2/Spectre-v2] arm64: KVM: Use per-CPU vector when BP hardening is enabled [Variant 2/Spectre-v2] arm64: KVM: Increment PC after handling an SMC trap [Variant 2/Spectre-v2] arm/arm64: KVM: Consolidate the PSCI include files [Variant 2/Spectre-v2] arm/arm64: KVM: Add PSCI_VERSION helper [Variant 2/Spectre-v2] arm/arm64: KVM: Add smccc accessors to PSCI code [Variant 2/Spectre-v2] arm/arm64: KVM: Implement PSCI 1.0 support [Variant 2/Spectre-v2] arm/arm64: KVM: Advertise SMCCC v1.1 [Variant 2/Spectre-v2] arm64: KVM: Make PSCI_VERSION a fast path [Variant 2/Spectre-v2] arm/arm64: KVM: Turn kvm_psci_version into a static inline [Variant 2/Spectre-v2] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support [Variant 2/Spectre-v2] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling [Variant 2/Spectre-v2] firmware/psci: Expose PSCI conduit [Variant 2/Spectre-v2] firmware/psci: Expose SMCCC version through psci_ops [Variant 2/Spectre-v2] arm/arm64: smccc: Make function identifiers an unsigned quantity [Variant 2/Spectre-v2] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive [Variant 2/Spectre-v2] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support [Variant 2/Spectre-v2] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround Mark Rutland (1): [Variant 1/Spectre-v1] Documentation: Document array_index_nospec Robin Murphy (3): [Variant 1/Spectre-v1] arm64: Implement array_index_mask_nospec() [Variant 1/Spectre-v1] arm64: Make USER_DS an inclusive limit [Variant 1/Spectre-v1] arm64: Use pointer masking to limit uaccess speculation Shanker Donthineni (1): [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor Stephen Boyd (1): [Variant 3/Meltdown] arm64: cpu_errata: Add Kryo to Falkor 1003 errata Suzuki K Poulose (2): [Variant 3/Meltdown] arm64: capabilities: Handle duplicate entries for a capability [Variant 2/Spectre-v2] arm64: Run enable method for errata work arounds on late CPUs Will Deacon (41): [Variant 3/Meltdown] arm64: mm: Use non-global mappings for kernel space [Variant 3/Meltdown] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN [Variant 3/Meltdown] arm64: mm: Move ASID from TTBR0 to TTBR1 [Variant 3/Meltdown] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 [Variant 3/Meltdown] arm64: mm: Rename post_ttbr0_update_workaround [Variant 3/Meltdown] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN [Variant 3/Meltdown] arm64: mm: Allocate ASIDs in pairs [Variant 3/Meltdown] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper [Variant 3/Meltdown] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI [Variant 3/Meltdown] arm64: entry: Add exception trampoline page for exceptions from EL0 [Variant 3/Meltdown] arm64: mm: Map entry trampoline into trampoline and kernel page tables [Variant 3/Meltdown] arm64: entry: Explicitly pass exception level to kernel_ventry macro [Variant 3/Meltdown] arm64: entry: Hook up entry trampoline to exception vectors [Variant 3/Meltdown] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code [Variant 3/Meltdown] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks [Variant 3/Meltdown] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 [Variant 3/Meltdown] arm64: kaslr: Put kernel vectors address in separate data page [Variant 3/Meltdown] arm64: use RET instruction for exiting the trampoline [Variant 3/Meltdown] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 [Variant 3/Meltdown] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry [Variant 3/Meltdown] arm64: Take into account ID_AA64PFR0_EL1.CSV3 [Variant 3/Meltdown] arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR [Variant 3/Meltdown] arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() [Variant 3/Meltdown] arm64: mm: Permit transitioning from Global to Non-Global without BBM [Variant 3/Meltdown] arm64: kpti: Add ->enable callback to remap swapper using nG mappings [Variant 3/Meltdown] arm64: entry: Reword comment about post_ttbr_update_workaround [Variant 3/Meltdown] arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives [Variant 3/Meltdown] perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0() [Variant 1/Spectre-v1] arm64: barrier: Add CSDB macros to control data-value prediction [Variant 1/Spectre-v1] arm64: entry: Ensure branch through syscall table is bounded under speculation [Variant 1/Spectre-v1] arm64: uaccess: Prevent speculative use of the current addr_limit [Variant 1/Spectre-v1] arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user [Variant 1/Spectre-v1] arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user [Variant 1/Spectre-v1] arm64: futex: Mask __user pointers prior to dereference [Variant 2/Spectre-v2] arm64: cpufeature: Pass capability structure to ->enable callback [Variant 2/Spectre-v2] drivers/firmware: Expose psci_get_version through psci_ops structure [Variant 2/Spectre-v2] arm64: Add skeleton to harden the branch predictor against aliasing attacks [Variant 2/Spectre-v2] arm64: entry: Apply BP hardening for high-priority synchronous exceptions [Variant 2/Spectre-v2] arm64: entry: Apply BP hardening for suspicious interrupts from EL0 [Variant 2/Spectre-v2] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for affected Cortex-A CPUs Documentation/arm64/silicon-errata.txt | 2 +- Documentation/speculation.txt | 90 +++++++++++++ arch/arm/include/asm/kvm_host.h | 6 + arch/arm/include/asm/kvm_mmu.h | 10 ++ arch/arm/include/asm/kvm_psci.h | 27 ---- arch/arm/kvm/handle_exit.c | 4 +- arch/arm64/Kconfig | 46 +++++-- arch/arm64/include/asm/asm-uaccess.h | 36 +++-- arch/arm64/include/asm/assembler.h | 54 +++----- arch/arm64/include/asm/barrier.h | 22 +++ arch/arm64/include/asm/cpucaps.h | 5 +- arch/arm64/include/asm/cputype.h | 9 ++ arch/arm64/include/asm/efi.h | 12 +- arch/arm64/include/asm/fixmap.h | 5 + arch/arm64/include/asm/futex.h | 9 +- arch/arm64/include/asm/kvm_asm.h | 2 + arch/arm64/include/asm/kvm_host.h | 5 + arch/arm64/include/asm/kvm_mmu.h | 38 ++++++ arch/arm64/include/asm/kvm_psci.h | 27 ---- arch/arm64/include/asm/mmu.h | 48 +++++++ arch/arm64/include/asm/mmu_context.h | 12 +- arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/include/asm/pgtable-prot.h | 35 +++-- arch/arm64/include/asm/pgtable.h | 1 + arch/arm64/include/asm/proc-fns.h | 6 - arch/arm64/include/asm/processor.h | 3 + arch/arm64/include/asm/sysreg.h | 2 + arch/arm64/include/asm/tlbflush.h | 16 ++- arch/arm64/include/asm/uaccess.h | 181 +++++++++++++++++-------- arch/arm64/kernel/Makefile | 4 + arch/arm64/kernel/arm64ksyms.c | 4 +- arch/arm64/kernel/asm-offsets.c | 6 +- arch/arm64/kernel/bpi.S | 83 ++++++++++++ arch/arm64/kernel/cpu-reset.S | 2 +- arch/arm64/kernel/cpu_errata.c | 239 ++++++++++++++++++++++++++++++++- arch/arm64/kernel/cpufeature.c | 138 +++++++++++++++---- arch/arm64/kernel/entry.S | 228 ++++++++++++++++++++++++++----- arch/arm64/kernel/head.S | 2 +- arch/arm64/kernel/process.c | 12 +- arch/arm64/kernel/sleep.S | 2 +- arch/arm64/kernel/vmlinux.lds.S | 22 ++- arch/arm64/kvm/handle_exit.c | 14 +- arch/arm64/kvm/hyp/entry.S | 12 ++ arch/arm64/kvm/hyp/hyp-entry.S | 20 ++- arch/arm64/kvm/hyp/switch.c | 13 +- arch/arm64/lib/clear_user.S | 10 +- arch/arm64/lib/copy_from_user.S | 4 +- arch/arm64/lib/copy_in_user.S | 9 +- arch/arm64/lib/copy_to_user.S | 4 +- arch/arm64/mm/cache.S | 4 +- arch/arm64/mm/context.c | 48 ++++--- arch/arm64/mm/fault.c | 36 ++++- arch/arm64/mm/mmu.c | 35 +++++ arch/arm64/mm/proc.S | 224 +++++++++++++++++++++++++++--- arch/arm64/xen/hypercall.S | 4 +- drivers/firmware/psci.c | 57 +++++++- drivers/perf/arm_spe_pmu.c | 9 ++ include/kvm/arm_psci.h | 51 +++++++ include/linux/arm-smccc.h | 165 ++++++++++++++++++++++- include/linux/nospec.h | 72 ++++++++++ include/linux/psci.h | 14 ++ include/uapi/linux/psci.h | 3 + virt/kvm/arm/arm.c | 10 +- virt/kvm/arm/psci.c | 143 ++++++++++++++++---- 64 files changed, 2049 insertions(+), 368 deletions(-) create mode 100644 Documentation/speculation.txt delete mode 100644 arch/arm/include/asm/kvm_psci.h delete mode 100644 arch/arm64/include/asm/kvm_psci.h create mode 100644 arch/arm64/kernel/bpi.S create mode 100644 include/kvm/arm_psci.h create mode 100644 include/linux/nospec.h

7 years, 3 months

3
10
0 0

Patch "mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Fri, 1 Dec 2017 15:09:34 +0800 Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream. When system wakes up from sleep on ls1046ardb, the SD operation fails with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset() rather than in probe. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -489,10 +489,18 @@ static void esdhc_pltfm_set_bus_width(st static void esdhc_reset(struct sdhci_host *host, u8 mask) { + u32 val; + sdhci_reset(host, mask); sdhci_writel(host, host->ier, SDHCI_INT_ENABLE); sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE); + + if (mask & SDHCI_RESET_ALL) { + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + } } #ifdef CONFIG_PM_SLEEP @@ -584,10 +592,6 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); - val = sdhci_readl(host, ESDHC_TBCTL); - val &= ~ESDHC_TB_EN; - sdhci_writel(host, val, ESDHC_TBCTL); - host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.9/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.9/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Wed, 8 Nov 2017 17:09:50 +0800 Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream. The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is used to reset for all. The driver should make sure it's cleared before card initialization, otherwise the initialization would fail. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -584,6 +584,10 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.9/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.9/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "media: r820t: fix r820t_write_reg for KASAN" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: r820t: fix r820t_write_reg for KASAN to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-r820t-fix-r820t_write_reg-for-kasan.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 30 Nov 2017 06:08:05 -0500 Subject: media: r820t: fix r820t_write_reg for KASAN From: Arnd Bergmann <arnd(a)arndb.de> commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/tuners/r820t.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv return 0; } -static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) +static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) { - return r820t_write(priv, reg, &val, 1); + u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */ + + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read_cache_reg(struct r820t_priv *priv, int reg) @@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r return -EINVAL; } -static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, +static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, u8 bit_mask) { + u8 tmp = val; int rc = r820t_read_cache_reg(priv, reg); if (rc < 0) return rc; - val = (rc & ~bit_mask) | (val & bit_mask); + tmp = (rc & ~bit_mask) | (tmp & bit_mask); - return r820t_write(priv, reg, &val, 1); + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.9/mm-hide-a-warning-for-compile_test.patch queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.9/arm-spear13xx-fix-dmas-cells.patch queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "arm64: dts: msm8916: Add missing #phy-cells" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dts: msm8916: Add missing #phy-cells to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-msm8916-add-missing-phy-cells.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Tue, 7 Nov 2017 19:45:01 -0800 Subject: arm64: dts: msm8916: Add missing #phy-cells From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream. Add a missing #phy-cells to the dsi-phy, to silence dtc warning. Cc: Archit Taneja <architt(a)codeaurora.org> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Reviewed-by: Archit Taneja <architt(a)codeaurora.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -796,6 +796,7 @@ "dsi_phy_regulator"; #clock-cells = <1>; + #phy-cells = <0>; clocks = <&gcc GCC_MDSS_AHB_CLK>; clock-names = "iface_clk"; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.9/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.9/arm64-dts-msm8916-add-missing-phy-cells.patch queue-4.9/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 3 months

1
0
0 0

Patch "ARM: pxa/tosa-bt: add MODULE_LICENSE tag" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: pxa/tosa-bt: add MODULE_LICENSE tag to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-pxa-tosa-bt-add-module_license-tag.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 15:40:37 +0100 Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag From: Arnd Bergmann <arnd(a)arndb.de> commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream. Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-pxa/tosa-bt.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/arm/mach-pxa/tosa-bt.c +++ b/arch/arm/mach-pxa/tosa-bt.c @@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr }, }; module_platform_driver(tosa_bt_driver); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Dmitry Baryshkov"); +MODULE_DESCRIPTION("Bluetooth built-in chip control"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.9/mm-hide-a-warning-for-compile_test.patch queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.9/arm-spear13xx-fix-dmas-cells.patch queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: s5pv210: add interrupt-parent for ohci" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: s5pv210: add interrupt-parent for ohci to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:10:11 +0100 Subject: ARM: dts: s5pv210: add interrupt-parent for ohci From: Arnd Bergmann <arnd(a)arndb.de> commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/s5pv210.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/s5pv210.dtsi +++ b/arch/arm/boot/dts/s5pv210.dtsi @@ -463,6 +463,7 @@ compatible = "samsung,exynos4210-ohci"; reg = <0xec300000 0x100>; interrupts = <23>; + interrupt-parent = <&vic1>; clocks = <&clocks CLK_USB_HOST>; clock-names = "usbhost"; #address-cells = <1>; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.9/mm-hide-a-warning-for-compile_test.patch queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.9/arm-spear13xx-fix-dmas-cells.patch queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: exynos: fix RTC interrupt for exynos5410" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: exynos: fix RTC interrupt for exynos5410 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 21 Dec 2017 22:30:07 +0100 Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410 From: Arnd Bergmann <arnd(a)arndb.de> commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream. According to the comment added to exynos_dt_pmu_match[] in commit 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"), the RTC is not able to wake up the system through the PMU on Exynos5410, unlike Exynos5420. However, when the RTC DT node got added, it was a straight copy of the Exynos5420 node, which now causes a warning from dtc. This removes the incorrect interrupt-parent, which should get the interrupt working and avoid the warning. Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/exynos5410.dtsi | 1 - 1 file changed, 1 deletion(-) --- a/arch/arm/boot/dts/exynos5410.dtsi +++ b/arch/arm/boot/dts/exynos5410.dtsi @@ -274,7 +274,6 @@ &rtc { clocks = <&clock CLK_RTC>; clock-names = "rtc"; - interrupt-parent = <&pmu_system_controller>; status = "disabled"; }; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.9/mm-hide-a-warning-for-compile_test.patch queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.9/arm-spear13xx-fix-dmas-cells.patch queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "arm: dts: mt2701: Add reset-cells" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt2701: Add reset-cells to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt2701-add-reset-cells.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001 From: Matthias Brugger <matthias.bgg(a)gmail.com> Date: Fri, 1 Dec 2017 13:07:08 +0100 Subject: arm: dts: mt2701: Add reset-cells From: Matthias Brugger <matthias.bgg(a)gmail.com> commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream. The hifsys and ethsys needs the definition of the reset-cells property. Fix this. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt2701.dtsi | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/boot/dts/mt2701.dtsi +++ b/arch/arm/boot/dts/mt2701.dtsi @@ -197,12 +197,14 @@ compatible = "mediatek,mt2701-hifsys", "syscon"; reg = <0 0x1a000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; ethsys: syscon@1b000000 { compatible = "mediatek,mt2701-ethsys", "syscon"; reg = <0 0x1b000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; bdpsys: syscon@1c000000 { Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are queue-4.9/arm-dts-mt2701-add-reset-cells.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: Delete bogus reference to the charlcd" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: Delete bogus reference to the charlcd to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-delete-bogus-reference-to-the-charlcd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Tue, 2 Jan 2018 08:57:17 +0100 Subject: ARM: dts: Delete bogus reference to the charlcd From: Linus Walleij <linus.walleij(a)linaro.org> commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream. The EB MP board probably has a character LCD but the board manual does not really state which IRQ it has assigned to this device. The invalid assignment was a mistake by me during submission of the DTSI where I was looking for the reference, didn't find it and didn't fill it in. Delete this for now: it can probably be fixed but that requires access to the actual board for some trial-and-error experiments. Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 ----- 1 file changed, 5 deletions(-) --- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi +++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi @@ -150,11 +150,6 @@ interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>; }; -&charlcd { - interrupt-parent = <&intc>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; -}; - &serial0 { interrupt-parent = <&intc>; interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>; Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Fri, 1 Dec 2017 15:09:34 +0800 Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream. When system wakes up from sleep on ls1046ardb, the SD operation fails with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset() rather than in probe. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -589,10 +589,18 @@ static void esdhc_pltfm_set_bus_width(st static void esdhc_reset(struct sdhci_host *host, u8 mask) { + u32 val; + sdhci_reset(host, mask); sdhci_writel(host, host->ier, SDHCI_INT_ENABLE); sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE); + + if (mask & SDHCI_RESET_ALL) { + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + } } /* The SCFG, Supplemental Configuration Unit, provides SoC specific @@ -785,10 +793,6 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); - val = sdhci_readl(host, ESDHC_TBCTL); - val &= ~ESDHC_TB_EN; - sdhci_writel(host, val, ESDHC_TBCTL); - host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.15/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.15/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Wed, 8 Nov 2017 17:09:50 +0800 Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream. The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is used to reset for all. The driver should make sure it's cleared before card initialization, otherwise the initialization would fail. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -785,6 +785,10 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.15/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.15/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "media: r820t: fix r820t_write_reg for KASAN" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: r820t: fix r820t_write_reg for KASAN to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-r820t-fix-r820t_write_reg-for-kasan.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 30 Nov 2017 06:08:05 -0500 Subject: media: r820t: fix r820t_write_reg for KASAN From: Arnd Bergmann <arnd(a)arndb.de> commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/tuners/r820t.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv return 0; } -static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) +static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) { - return r820t_write(priv, reg, &val, 1); + u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */ + + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read_cache_reg(struct r820t_priv *priv, int reg) @@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r return -EINVAL; } -static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, +static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, u8 bit_mask) { + u8 tmp = val; int rc = r820t_read_cache_reg(priv, reg); if (rc < 0) return rc; - val = (rc & ~bit_mask) | (val & bit_mask); + tmp = (rc & ~bit_mask) | (tmp & bit_mask); - return r820t_write(priv, reg, &val, 1); + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.15/mm-hide-a-warning-for-compile_test.patch queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "arm64: dts: msm8916: Add missing #phy-cells" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dts: msm8916: Add missing #phy-cells to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-msm8916-add-missing-phy-cells.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Tue, 7 Nov 2017 19:45:01 -0800 Subject: arm64: dts: msm8916: Add missing #phy-cells From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream. Add a missing #phy-cells to the dsi-phy, to silence dtc warning. Cc: Archit Taneja <architt(a)codeaurora.org> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Reviewed-by: Archit Taneja <architt(a)codeaurora.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -906,6 +906,7 @@ "dsi_phy_regulator"; #clock-cells = <1>; + #phy-cells = <0>; clocks = <&gcc GCC_MDSS_AHB_CLK>; clock-names = "iface_clk"; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.15/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.15/arm64-dts-msm8916-add-missing-phy-cells.patch queue-4.15/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 3 months

1
0
0 0

Patch "ARM: pxa/tosa-bt: add MODULE_LICENSE tag" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: pxa/tosa-bt: add MODULE_LICENSE tag to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-pxa-tosa-bt-add-module_license-tag.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 15:40:37 +0100 Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag From: Arnd Bergmann <arnd(a)arndb.de> commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream. Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-pxa/tosa-bt.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/arm/mach-pxa/tosa-bt.c +++ b/arch/arm/mach-pxa/tosa-bt.c @@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr }, }; module_platform_driver(tosa_bt_driver); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Dmitry Baryshkov"); +MODULE_DESCRIPTION("Bluetooth built-in chip control"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.15/mm-hide-a-warning-for-compile_test.patch queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: s5pv210: add interrupt-parent for ohci" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: s5pv210: add interrupt-parent for ohci to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:10:11 +0100 Subject: ARM: dts: s5pv210: add interrupt-parent for ohci From: Arnd Bergmann <arnd(a)arndb.de> commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/s5pv210.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/s5pv210.dtsi +++ b/arch/arm/boot/dts/s5pv210.dtsi @@ -463,6 +463,7 @@ compatible = "samsung,exynos4210-ohci"; reg = <0xec300000 0x100>; interrupts = <23>; + interrupt-parent = <&vic1>; clocks = <&clocks CLK_USB_HOST>; clock-names = "usbhost"; #address-cells = <1>; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.15/mm-hide-a-warning-for-compile_test.patch queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "arm: dts: mt7623: Update ethsys binding" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt7623: Update ethsys binding to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt7623-update-ethsys-binding.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 76a09ce214addb8ddc0f6d50dc1106a5f829e713 Mon Sep 17 00:00:00 2001 From: Matthias Brugger <matthias.bgg(a)gmail.com> Date: Fri, 1 Dec 2017 13:07:07 +0100 Subject: arm: dts: mt7623: Update ethsys binding From: Matthias Brugger <matthias.bgg(a)gmail.com> commit 76a09ce214addb8ddc0f6d50dc1106a5f829e713 upstream. The ethsys binding misses the reset-cells, this patch adds this property. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt7623.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -758,6 +758,7 @@ "syscon"; reg = <0 0x1b000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; eth: ethernet@1b100000 { Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are queue-4.15/arm-dts-mt7623-update-ethsys-binding.patch queue-4.15/arm-dts-mt2701-add-reset-cells.patch queue-4.15/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 3 months

1
0
0 0

Patch "arm: dts: mt2701: Add reset-cells" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt2701: Add reset-cells to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt2701-add-reset-cells.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001 From: Matthias Brugger <matthias.bgg(a)gmail.com> Date: Fri, 1 Dec 2017 13:07:08 +0100 Subject: arm: dts: mt2701: Add reset-cells From: Matthias Brugger <matthias.bgg(a)gmail.com> commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream. The hifsys and ethsys needs the definition of the reset-cells property. Fix this. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt2701.dtsi | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/boot/dts/mt2701.dtsi +++ b/arch/arm/boot/dts/mt2701.dtsi @@ -604,6 +604,7 @@ compatible = "mediatek,mt2701-hifsys", "syscon"; reg = <0 0x1a000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; usb0: usb@1a1c0000 { @@ -688,6 +689,7 @@ compatible = "mediatek,mt2701-ethsys", "syscon"; reg = <0 0x1b000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; eth: ethernet@1b100000 { Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are queue-4.15/arm-dts-mt7623-update-ethsys-binding.patch queue-4.15/arm-dts-mt2701-add-reset-cells.patch queue-4.15/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: exynos: fix RTC interrupt for exynos5410" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: exynos: fix RTC interrupt for exynos5410 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 21 Dec 2017 22:30:07 +0100 Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410 From: Arnd Bergmann <arnd(a)arndb.de> commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream. According to the comment added to exynos_dt_pmu_match[] in commit 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"), the RTC is not able to wake up the system through the PMU on Exynos5410, unlike Exynos5420. However, when the RTC DT node got added, it was a straight copy of the Exynos5420 node, which now causes a warning from dtc. This removes the incorrect interrupt-parent, which should get the interrupt working and avoid the warning. Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/exynos5410.dtsi | 1 - 1 file changed, 1 deletion(-) --- a/arch/arm/boot/dts/exynos5410.dtsi +++ b/arch/arm/boot/dts/exynos5410.dtsi @@ -333,7 +333,6 @@ &rtc { clocks = <&clock CLK_RTC>; clock-names = "rtc"; - interrupt-parent = <&pmu_system_controller>; status = "disabled"; }; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.15/mm-hide-a-warning-for-compile_test.patch queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: Delete bogus reference to the charlcd" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: Delete bogus reference to the charlcd to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-delete-bogus-reference-to-the-charlcd.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Tue, 2 Jan 2018 08:57:17 +0100 Subject: ARM: dts: Delete bogus reference to the charlcd From: Linus Walleij <linus.walleij(a)linaro.org> commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream. The EB MP board probably has a character LCD but the board manual does not really state which IRQ it has assigned to this device. The invalid assignment was a mistake by me during submission of the DTSI where I was looking for the reference, didn't find it and didn't fill it in. Delete this for now: it can probably be fixed but that requires access to the actual board for some trial-and-error experiments. Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 ----- 1 file changed, 5 deletions(-) --- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi +++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi @@ -150,11 +150,6 @@ interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>; }; -&charlcd { - interrupt-parent = <&intc>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; -}; - &serial0 { interrupt-parent = <&intc>; interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>; Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.15/mmc-sdhci-implement-an-sdhci-specific-bounce-buffer.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "scsi: core: check for device state in __scsi_remove_target()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: core: check for device state in __scsi_remove_target() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-core-check-for-device-state-in-__scsi_remove_target.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 81b6c999897919d5a16fedc018fe375dbab091c5 Mon Sep 17 00:00:00 2001 From: Hannes Reinecke <hare(a)suse.de> Date: Wed, 13 Dec 2017 14:21:37 +0100 Subject: scsi: core: check for device state in __scsi_remove_target() From: Hannes Reinecke <hare(a)suse.de> commit 81b6c999897919d5a16fedc018fe375dbab091c5 upstream. As it turned out device_get() doesn't use kref_get_unless_zero(), so we will be always getting a device pointer. Consequently, we need to check for the device state in __scsi_remove_target() to avoid tripping over deleted objects. Fixes: fbce4d97fd43 ("scsi: fixup kernel warning during rmmod()") Reported-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com> Reviewed-by: Ewan D. Milne <emilne(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Max Ivanov <ivanov.maxim(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/scsi_sysfs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1383,7 +1383,10 @@ static void __scsi_remove_target(struct * check. */ if (sdev->channel != starget->channel || - sdev->id != starget->id || + sdev->id != starget->id) + continue; + if (sdev->sdev_state == SDEV_DEL || + sdev->sdev_state == SDEV_CANCEL || !get_device(&sdev->sdev_gendev)) continue; spin_unlock_irqrestore(shost->host_lock, flags); Patches currently in stable-queue which might be from hare(a)suse.de are queue-4.14/scsi-core-check-for-device-state-in-__scsi_remove_target.patch

7 years, 3 months

1
0
0 0

Patch "ovl: hash directory inodes for fsnotify" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ovl: hash directory inodes for fsnotify to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ovl-hash-directory-inodes-for-fsnotify.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 31747eda41ef3c30c09c5c096b380bf54013746a Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Sun, 14 Jan 2018 18:35:40 +0200 Subject: ovl: hash directory inodes for fsnotify From: Amir Goldstein <amir73il(a)gmail.com> commit 31747eda41ef3c30c09c5c096b380bf54013746a upstream. fsnotify pins a watched directory inode in cache, but if directory dentry is released, new lookup will allocate a new dentry and a new inode. Directory events will be notified on the new inode, while fsnotify listener is watching the old pinned inode. Hash all directory inodes to reuse the pinned inode on lookup. Pure upper dirs are hashes by real upper inode, merge and lower dirs are hashed by real lower inode. The reference to lower inode was being held by the lower dentry object in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry may drop lower inode refcount to zero. Add a refcount on behalf of the overlay inode to prevent that. As a by-product, hashing directory inodes also detects multiple redirected dirs to the same lower dir and uncovered redirected dir target on and returns -ESTALE on lookup. The reported issue dates back to initial version of overlayfs, but this patch depends on ovl_inode code that was introduced in kernel v4.13. Cc: <stable(a)vger.kernel.org> #v4.13 Reported-by: Niklas Cassel <niklas.cassel(a)axis.com> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Tested-by: Niklas Cassel <niklas.cassel(a)axis.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/overlayfs/inode.c | 37 +++++++++++++++++++++++++++---------- fs/overlayfs/super.c | 1 + fs/overlayfs/util.c | 4 ++-- 3 files changed, 30 insertions(+), 12 deletions(-) --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -579,6 +579,16 @@ static int ovl_inode_set(struct inode *i static bool ovl_verify_inode(struct inode *inode, struct dentry *lowerdentry, struct dentry *upperdentry) { + if (S_ISDIR(inode->i_mode)) { + /* Real lower dir moved to upper layer under us? */ + if (!lowerdentry && ovl_inode_lower(inode)) + return false; + + /* Lookup of an uncovered redirect origin? */ + if (!upperdentry && ovl_inode_upper(inode)) + return false; + } + /* * Allow non-NULL lower inode in ovl_inode even if lowerdentry is NULL. * This happens when finding a copied up overlay inode for a renamed @@ -606,6 +616,8 @@ struct inode *ovl_get_inode(struct dentr struct inode *inode; /* Already indexed or could be indexed on copy up? */ bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry)); + struct dentry *origin = indexed ? lowerdentry : NULL; + bool is_dir; if (WARN_ON(upperdentry && indexed && !lowerdentry)) return ERR_PTR(-EIO); @@ -614,15 +626,19 @@ struct inode *ovl_get_inode(struct dentr realinode = d_inode(lowerdentry); /* - * Copy up origin (lower) may exist for non-indexed upper, but we must - * not use lower as hash key in that case. - * Hash inodes that are or could be indexed by origin inode and - * non-indexed upper inodes that could be hard linked by upper inode. + * Copy up origin (lower) may exist for non-indexed non-dir upper, but + * we must not use lower as hash key in that case. + * Hash non-dir that is or could be indexed by origin inode. + * Hash dir that is or could be merged by origin inode. + * Hash pure upper and non-indexed non-dir by upper inode. */ - if (!S_ISDIR(realinode->i_mode) && (upperdentry || indexed)) { - struct inode *key = d_inode(indexed ? lowerdentry : - upperdentry); - unsigned int nlink; + is_dir = S_ISDIR(realinode->i_mode); + if (is_dir) + origin = lowerdentry; + + if (upperdentry || origin) { + struct inode *key = d_inode(origin ?: upperdentry); + unsigned int nlink = is_dir ? 1 : realinode->i_nlink; inode = iget5_locked(dentry->d_sb, (unsigned long) key, ovl_inode_test, ovl_inode_set, key); @@ -643,8 +659,9 @@ struct inode *ovl_get_inode(struct dentr goto out; } - nlink = ovl_get_nlink(lowerdentry, upperdentry, - realinode->i_nlink); + /* Recalculate nlink for non-dir due to indexing */ + if (!is_dir) + nlink = ovl_get_nlink(lowerdentry, upperdentry, nlink); set_nlink(inode, nlink); } else { inode = new_inode(dentry->d_sb); --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -200,6 +200,7 @@ static void ovl_destroy_inode(struct ino struct ovl_inode *oi = OVL_I(inode); dput(oi->__upperdentry); + iput(oi->lower); kfree(oi->redirect); ovl_dir_cache_free(inode); mutex_destroy(&oi->lock); --- a/fs/overlayfs/util.c +++ b/fs/overlayfs/util.c @@ -253,7 +253,7 @@ void ovl_inode_init(struct inode *inode, if (upperdentry) OVL_I(inode)->__upperdentry = upperdentry; if (lowerdentry) - OVL_I(inode)->lower = d_inode(lowerdentry); + OVL_I(inode)->lower = igrab(d_inode(lowerdentry)); ovl_copyattr(d_inode(upperdentry ?: lowerdentry), inode); } @@ -269,7 +269,7 @@ void ovl_inode_update(struct inode *inod */ smp_wmb(); OVL_I(inode)->__upperdentry = upperdentry; - if (!S_ISDIR(upperinode->i_mode) && inode_unhashed(inode)) { + if (inode_unhashed(inode)) { inode->i_private = upperinode; __insert_inode_hash(inode, (unsigned long) upperinode); } Patches currently in stable-queue which might be from amir73il(a)gmail.com are queue-4.14/ovl-hash-directory-inodes-for-fsnotify.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Fri, 1 Dec 2017 15:09:34 +0800 Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream. When system wakes up from sleep on ls1046ardb, the SD operation fails with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset() rather than in probe. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -589,10 +589,18 @@ static void esdhc_pltfm_set_bus_width(st static void esdhc_reset(struct sdhci_host *host, u8 mask) { + u32 val; + sdhci_reset(host, mask); sdhci_writel(host, host->ier, SDHCI_INT_ENABLE); sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE); + + if (mask & SDHCI_RESET_ALL) { + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + } } /* The SCFG, Supplemental Configuration Unit, provides SoC specific @@ -785,10 +793,6 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); - val = sdhci_readl(host, ESDHC_TBCTL); - val &= ~ESDHC_TB_EN; - sdhci_writel(host, val, ESDHC_TBCTL); - host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.14/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001 From: "yinbo.zhu" <yinbo.zhu(a)nxp.com> Date: Wed, 8 Nov 2017 17:09:50 +0800 Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec From: yinbo.zhu <yinbo.zhu(a)nxp.com> commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream. The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is used to reset for all. The driver should make sure it's cleared before card initialization, otherwise the initialization would fail. Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -785,6 +785,10 @@ static void esdhc_init(struct platform_d pltfm_host = sdhci_priv(host); esdhc = sdhci_pltfm_priv(pltfm_host); + val = sdhci_readl(host, ESDHC_TBCTL); + val &= ~ESDHC_TB_EN; + sdhci_writel(host, val, ESDHC_TBCTL); + host_ver = sdhci_readw(host, SDHCI_HOST_VERSION); esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.14/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: disable SD clock for clock value 0" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: disable SD clock for clock value 0 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-disable-sd-clock-for-clock-value-0.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From dd3f6983b4a468efca9e8caa0e2b4aa20946d801 Mon Sep 17 00:00:00 2001 From: yangbo lu <yangbo.lu(a)nxp.com> Date: Thu, 21 Sep 2017 16:43:31 +0800 Subject: mmc: sdhci-of-esdhc: disable SD clock for clock value 0 From: yangbo lu <yangbo.lu(a)nxp.com> commit dd3f6983b4a468efca9e8caa0e2b4aa20946d801 upstream. SD clock should be disabled for clock value 0. It's not right to just return. This may cause failure of signal voltage switching. Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 58 +++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 28 deletions(-) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -458,6 +458,33 @@ static unsigned int esdhc_of_get_min_clo return clock / 256 / 16; } +static void esdhc_clock_enable(struct sdhci_host *host, bool enable) +{ + u32 val; + ktime_t timeout; + + val = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); + + if (enable) + val |= ESDHC_CLOCK_SDCLKEN; + else + val &= ~ESDHC_CLOCK_SDCLKEN; + + sdhci_writel(host, val, ESDHC_SYSTEM_CONTROL); + + /* Wait max 20 ms */ + timeout = ktime_add_ms(ktime_get(), 20); + val = ESDHC_CLOCK_STABLE; + while (!(sdhci_readl(host, ESDHC_PRSSTAT) & val)) { + if (ktime_after(ktime_get(), timeout)) { + pr_err("%s: Internal clock never stabilised.\n", + mmc_hostname(host->mmc)); + break; + } + udelay(10); + } +} + static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) { struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); @@ -469,8 +496,10 @@ static void esdhc_of_set_clock(struct sd host->mmc->actual_clock = 0; - if (clock == 0) + if (clock == 0) { + esdhc_clock_enable(host, false); return; + } /* Workaround to start pre_div at 2 for VNN < VENDOR_V_23 */ if (esdhc->vendor_ver < VENDOR_V_23) @@ -558,33 +587,6 @@ static void esdhc_pltfm_set_bus_width(st sdhci_writel(host, ctrl, ESDHC_PROCTL); } -static void esdhc_clock_enable(struct sdhci_host *host, bool enable) -{ - u32 val; - ktime_t timeout; - - val = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); - - if (enable) - val |= ESDHC_CLOCK_SDCLKEN; - else - val &= ~ESDHC_CLOCK_SDCLKEN; - - sdhci_writel(host, val, ESDHC_SYSTEM_CONTROL); - - /* Wait max 20 ms */ - timeout = ktime_add_ms(ktime_get(), 20); - val = ESDHC_CLOCK_STABLE; - while (!(sdhci_readl(host, ESDHC_PRSSTAT) & val)) { - if (ktime_after(ktime_get(), timeout)) { - pr_err("%s: Internal clock never stabilised.\n", - mmc_hostname(host->mmc)); - break; - } - udelay(10); - } -} - static void esdhc_reset(struct sdhci_host *host, u8 mask) { sdhci_reset(host, mask); Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch queue-4.14/mmc-sdhci-of-esdhc-disable-sd-clock-for-clock-value-0.patch

7 years, 3 months

1
0
0 0

Patch "media: r820t: fix r820t_write_reg for KASAN" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: r820t: fix r820t_write_reg for KASAN to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-r820t-fix-r820t_write_reg-for-kasan.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 30 Nov 2017 06:08:05 -0500 Subject: media: r820t: fix r820t_write_reg for KASAN From: Arnd Bergmann <arnd(a)arndb.de> commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/tuners/r820t.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv return 0; } -static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) +static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) { - return r820t_write(priv, reg, &val, 1); + u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */ + + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read_cache_reg(struct r820t_priv *priv, int reg) @@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r return -EINVAL; } -static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, +static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, u8 bit_mask) { + u8 tmp = val; int rc = r820t_read_cache_reg(priv, reg); if (rc < 0) return rc; - val = (rc & ~bit_mask) | (val & bit_mask); + tmp = (rc & ~bit_mask) | (tmp & bit_mask); - return r820t_write(priv, reg, &val, 1); + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mm-hide-a-warning-for-compile_test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 05e89fb576f580ac95e7a5d00bdb34830b09671a Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 11 Oct 2017 15:47:54 +0200 Subject: Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS From: Arnd Bergmann <arnd(a)arndb.de> commit 05e89fb576f580ac95e7a5d00bdb34830b09671a upstream. It is no longer possible to build BT_HCIUART into the kernel when SERIAL_DEV_BUS is a loadable module, even if none of the SERIAL_DEV_BUS based implementations are selected: drivers/bluetooth/hci_ldisc.o: In function `hci_uart_set_flow_control': hci_ldisc.c:(.text+0xb40): undefined reference to `serdev_device_set_flow_control' hci_ldisc.c:(.text+0xb5c): undefined reference to `serdev_device_set_tiocm' This adds a dependency to avoid the broken configuration. Fixes: 7841d554809b ("Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/bluetooth/Kconfig +++ b/drivers/bluetooth/Kconfig @@ -66,6 +66,7 @@ config BT_HCIBTSDIO config BT_HCIUART tristate "HCI UART driver" + depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS depends on TTY help Bluetooth HCI UART driver. @@ -80,7 +81,6 @@ config BT_HCIUART config BT_HCIUART_SERDEV bool depends on SERIAL_DEV_BUS && BT_HCIUART - depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART default y config BT_HCIUART_H4 Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mm-hide-a-warning-for-compile_test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ASoC: acpi: fix machine driver selection based on quirk" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: acpi: fix machine driver selection based on quirk to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-acpi-fix-machine-driver-selection-based-on-quirk.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Date: Fri, 5 Jan 2018 14:55:33 -0600 Subject: ASoC: acpi: fix machine driver selection based on quirk MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> commit 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 upstream. The ACPI/machine-driver code refactoring introduced in 4.13 introduced a regression for cases where we need a DMI-based quirk to select the machine driver (the BIOS reports an invalid HID). The fix is just to make sure the results of the quirk are actually used. Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data') Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691 Tested-by: Nicole Færber <nicole.faerber(a)dpin.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/common/sst-match-acpi.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/sound/soc/intel/common/sst-match-acpi.c +++ b/sound/soc/intel/common/sst-match-acpi.c @@ -83,11 +83,9 @@ struct sst_acpi_mach *sst_acpi_find_mach for (mach = machines; mach->id[0]; mach++) { if (sst_acpi_check_hid(mach->id) == true) { - if (mach->machine_quirk == NULL) - return mach; - - if (mach->machine_quirk(mach) != NULL) - return mach; + if (mach->machine_quirk) + mach = mach->machine_quirk(mach); + return mach; } } return NULL; Patches currently in stable-queue which might be from pierre-louis.bossart(a)linux.intel.com are queue-4.14/asoc-acpi-fix-machine-driver-selection-based-on-quirk.patch

7 years, 3 months

1
0
0 0

Patch "arm64: dts: msm8916: Add missing #phy-cells" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dts: msm8916: Add missing #phy-cells to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-msm8916-add-missing-phy-cells.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Tue, 7 Nov 2017 19:45:01 -0800 Subject: arm64: dts: msm8916: Add missing #phy-cells From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream. Add a missing #phy-cells to the dsi-phy, to silence dtc warning. Cc: Archit Taneja <architt(a)codeaurora.org> Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Reviewed-by: Archit Taneja <architt(a)codeaurora.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -901,6 +901,7 @@ "dsi_phy_regulator"; #clock-cells = <1>; + #phy-cells = <0>; clocks = <&gcc GCC_MDSS_AHB_CLK>; clock-names = "iface_clk"; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.14/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.14/arm64-dts-msm8916-add-missing-phy-cells.patch queue-4.14/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 3 months

1
0
0 0

Patch "ARM: pxa/tosa-bt: add MODULE_LICENSE tag" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: pxa/tosa-bt: add MODULE_LICENSE tag to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-pxa-tosa-bt-add-module_license-tag.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 15:40:37 +0100 Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag From: Arnd Bergmann <arnd(a)arndb.de> commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream. Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-pxa/tosa-bt.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/arm/mach-pxa/tosa-bt.c +++ b/arch/arm/mach-pxa/tosa-bt.c @@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr }, }; module_platform_driver(tosa_bt_driver); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Dmitry Baryshkov"); +MODULE_DESCRIPTION("Bluetooth built-in chip control"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mm-hide-a-warning-for-compile_test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: s5pv210: add interrupt-parent for ohci" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: s5pv210: add interrupt-parent for ohci to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:10:11 +0100 Subject: ARM: dts: s5pv210: add interrupt-parent for ohci From: Arnd Bergmann <arnd(a)arndb.de> commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/s5pv210.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/s5pv210.dtsi +++ b/arch/arm/boot/dts/s5pv210.dtsi @@ -463,6 +463,7 @@ compatible = "samsung,exynos4210-ohci"; reg = <0xec300000 0x100>; interrupts = <23>; + interrupt-parent = <&vic1>; clocks = <&clocks CLK_USB_HOST>; clock-names = "usbhost"; #address-cells = <1>; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mm-hide-a-warning-for-compile_test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "arm: dts: mt7623: Update ethsys binding" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt7623: Update ethsys binding to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt7623-update-ethsys-binding.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 76a09ce214addb8ddc0f6d50dc1106a5f829e713 Mon Sep 17 00:00:00 2001 From: Matthias Brugger <matthias.bgg(a)gmail.com> Date: Fri, 1 Dec 2017 13:07:07 +0100 Subject: arm: dts: mt7623: Update ethsys binding From: Matthias Brugger <matthias.bgg(a)gmail.com> commit 76a09ce214addb8ddc0f6d50dc1106a5f829e713 upstream. The ethsys binding misses the reset-cells, this patch adds this property. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt7623.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -753,6 +753,7 @@ "syscon"; reg = <0 0x1b000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; eth: ethernet@1b100000 { Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are queue-4.14/arm-dts-mt7623-update-ethsys-binding.patch queue-4.14/arm-dts-mt2701-add-reset-cells.patch queue-4.14/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 3 months

1
0
0 0

Patch "arm: dts: mt2701: Add reset-cells" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt2701: Add reset-cells to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt2701-add-reset-cells.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001 From: Matthias Brugger <matthias.bgg(a)gmail.com> Date: Fri, 1 Dec 2017 13:07:08 +0100 Subject: arm: dts: mt2701: Add reset-cells From: Matthias Brugger <matthias.bgg(a)gmail.com> commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream. The hifsys and ethsys needs the definition of the reset-cells property. Fix this. Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt2701.dtsi | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/boot/dts/mt2701.dtsi +++ b/arch/arm/boot/dts/mt2701.dtsi @@ -593,6 +593,7 @@ compatible = "mediatek,mt2701-hifsys", "syscon"; reg = <0 0x1a000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; usb0: usb@1a1c0000 { @@ -677,6 +678,7 @@ compatible = "mediatek,mt2701-ethsys", "syscon"; reg = <0 0x1b000000 0 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; eth: ethernet@1b100000 { Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are queue-4.14/arm-dts-mt7623-update-ethsys-binding.patch queue-4.14/arm-dts-mt2701-add-reset-cells.patch queue-4.14/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: exynos: fix RTC interrupt for exynos5410" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: exynos: fix RTC interrupt for exynos5410 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 21 Dec 2017 22:30:07 +0100 Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410 From: Arnd Bergmann <arnd(a)arndb.de> commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream. According to the comment added to exynos_dt_pmu_match[] in commit 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"), the RTC is not able to wake up the system through the PMU on Exynos5410, unlike Exynos5420. However, when the RTC DT node got added, it was a straight copy of the Exynos5420 node, which now causes a warning from dtc. This removes the incorrect interrupt-parent, which should get the interrupt working and avoid the warning. Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/exynos5410.dtsi | 1 - 1 file changed, 1 deletion(-) --- a/arch/arm/boot/dts/exynos5410.dtsi +++ b/arch/arm/boot/dts/exynos5410.dtsi @@ -333,7 +333,6 @@ &rtc { clocks = <&clock CLK_RTC>; clock-names = "rtc"; - interrupt-parent = <&pmu_system_controller>; status = "disabled"; }; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mm-hide-a-warning-for-compile_test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: Delete bogus reference to the charlcd" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: Delete bogus reference to the charlcd to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-delete-bogus-reference-to-the-charlcd.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001 From: Linus Walleij <linus.walleij(a)linaro.org> Date: Tue, 2 Jan 2018 08:57:17 +0100 Subject: ARM: dts: Delete bogus reference to the charlcd From: Linus Walleij <linus.walleij(a)linaro.org> commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream. The EB MP board probably has a character LCD but the board manual does not really state which IRQ it has assigned to this device. The invalid assignment was a mistake by me during submission of the DTSI where I was looking for the reference, didn't find it and didn't fill it in. Delete this for now: it can probably be fixed but that requires access to the actual board for some trial-and-error experiments. Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 ----- 1 file changed, 5 deletions(-) --- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi +++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi @@ -150,11 +150,6 @@ interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>; }; -&charlcd { - interrupt-parent = <&intc>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; -}; - &serial0 { interrupt-parent = <&intc>; interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>; Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch queue-4.14/mmc-sdhci-implement-an-sdhci-specific-bounce-buffer.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 3 months

1
0
0 0

Patch "ARM: pxa/tosa-bt: add MODULE_LICENSE tag" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: pxa/tosa-bt: add MODULE_LICENSE tag to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-pxa-tosa-bt-add-module_license-tag.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 15:40:37 +0100 Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag From: Arnd Bergmann <arnd(a)arndb.de> commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream. Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/mach-pxa/tosa-bt.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/arm/mach-pxa/tosa-bt.c +++ b/arch/arm/mach-pxa/tosa-bt.c @@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr }, }; module_platform_driver(tosa_bt_driver); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Dmitry Baryshkov"); +MODULE_DESCRIPTION("Bluetooth built-in chip control"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.4/mm-hide-a-warning-for-compile_test.patch queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.4/arm-spear13xx-fix-dmas-cells.patch

7 years, 3 months

1
0
0 0

Patch "media: r820t: fix r820t_write_reg for KASAN" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: r820t: fix r820t_write_reg for KASAN to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-r820t-fix-r820t_write_reg-for-kasan.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 30 Nov 2017 06:08:05 -0500 Subject: media: r820t: fix r820t_write_reg for KASAN From: Arnd Bergmann <arnd(a)arndb.de> commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/tuners/r820t.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -410,9 +410,11 @@ static int r820t_write(struct r820t_priv return 0; } -static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) +static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) { - return r820t_write(priv, reg, &val, 1); + u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */ + + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read_cache_reg(struct r820t_priv *priv, int reg) @@ -425,17 +427,18 @@ static int r820t_read_cache_reg(struct r return -EINVAL; } -static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, +static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, u8 bit_mask) { + u8 tmp = val; int rc = r820t_read_cache_reg(priv, reg); if (rc < 0) return rc; - val = (rc & ~bit_mask) | (val & bit_mask); + tmp = (rc & ~bit_mask) | (tmp & bit_mask); - return r820t_write(priv, reg, &val, 1); + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.4/mm-hide-a-warning-for-compile_test.patch queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.4/arm-spear13xx-fix-dmas-cells.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: s5pv210: add interrupt-parent for ohci" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: s5pv210: add interrupt-parent for ohci to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:10:11 +0100 Subject: ARM: dts: s5pv210: add interrupt-parent for ohci From: Arnd Bergmann <arnd(a)arndb.de> commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/s5pv210.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/s5pv210.dtsi +++ b/arch/arm/boot/dts/s5pv210.dtsi @@ -461,6 +461,7 @@ compatible = "samsung,exynos4210-ohci"; reg = <0xec300000 0x100>; interrupts = <23>; + interrupt-parent = <&vic1>; clocks = <&clocks CLK_USB_HOST>; clock-names = "usbhost"; #address-cells = <1>; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch queue-4.4/mm-hide-a-warning-for-compile_test.patch queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-4.4/arm-spear13xx-fix-dmas-cells.patch

7 years, 3 months

1
0
0 0

Patch "media: r820t: fix r820t_write_reg for KASAN" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: r820t: fix r820t_write_reg for KASAN to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-r820t-fix-r820t_write_reg-for-kasan.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 30 Nov 2017 06:08:05 -0500 Subject: media: r820t: fix r820t_write_reg for KASAN From: Arnd Bergmann <arnd(a)arndb.de> commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/tuners/r820t.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -410,9 +410,11 @@ static int r820t_write(struct r820t_priv return 0; } -static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) +static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val) { - return r820t_write(priv, reg, &val, 1); + u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */ + + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read_cache_reg(struct r820t_priv *priv, int reg) @@ -425,17 +427,18 @@ static int r820t_read_cache_reg(struct r return -EINVAL; } -static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, +static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val, u8 bit_mask) { + u8 tmp = val; int rc = r820t_read_cache_reg(priv, reg); if (rc < 0) return rc; - val = (rc & ~bit_mask) | (val & bit_mask); + tmp = (rc & ~bit_mask) | (tmp & bit_mask); - return r820t_write(priv, reg, &val, 1); + return r820t_write(priv, reg, &tmp, 1); } static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len) Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-3.18/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-3.18/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-3.18/arm-spear13xx-fix-dmas-cells.patch

7 years, 3 months

1
0
0 0

Patch "ARM: dts: s5pv210: add interrupt-parent for ohci" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: s5pv210: add interrupt-parent for ohci to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:10:11 +0100 Subject: ARM: dts: s5pv210: add interrupt-parent for ohci From: Arnd Bergmann <arnd(a)arndb.de> commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/s5pv210.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/s5pv210.dtsi +++ b/arch/arm/boot/dts/s5pv210.dtsi @@ -461,6 +461,7 @@ compatible = "samsung,exynos4210-ohci"; reg = <0xec300000 0x100>; interrupts = <23>; + interrupt-parent = <&vic1>; clocks = <&clocks CLK_USB_HOST>; clock-names = "usbhost"; #address-cells = <1>; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-3.18/media-r820t-fix-r820t_write_reg-for-kasan.patch queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-3.18/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch queue-3.18/arm-spear13xx-fix-dmas-cells.patch

7 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] ovl: hash directory inodes for fsnotify" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 31747eda41ef3c30c09c5c096b380bf54013746a Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Sun, 14 Jan 2018 18:35:40 +0200 Subject: [PATCH] ovl: hash directory inodes for fsnotify fsnotify pins a watched directory inode in cache, but if directory dentry is released, new lookup will allocate a new dentry and a new inode. Directory events will be notified on the new inode, while fsnotify listener is watching the old pinned inode. Hash all directory inodes to reuse the pinned inode on lookup. Pure upper dirs are hashes by real upper inode, merge and lower dirs are hashed by real lower inode. The reference to lower inode was being held by the lower dentry object in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry may drop lower inode refcount to zero. Add a refcount on behalf of the overlay inode to prevent that. As a by-product, hashing directory inodes also detects multiple redirected dirs to the same lower dir and uncovered redirected dir target on and returns -ESTALE on lookup. The reported issue dates back to initial version of overlayfs, but this patch depends on ovl_inode code that was introduced in kernel v4.13. Cc: <stable(a)vger.kernel.org> #v4.13 Reported-by: Niklas Cassel <niklas.cassel(a)axis.com> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Tested-by: Niklas Cassel <niklas.cassel(a)axis.com> diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index 00b6b294272a..94d2f8a8b779 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -606,6 +606,16 @@ static int ovl_inode_set(struct inode *inode, void *data) static bool ovl_verify_inode(struct inode *inode, struct dentry *lowerdentry, struct dentry *upperdentry) { + if (S_ISDIR(inode->i_mode)) { + /* Real lower dir moved to upper layer under us? */ + if (!lowerdentry && ovl_inode_lower(inode)) + return false; + + /* Lookup of an uncovered redirect origin? */ + if (!upperdentry && ovl_inode_upper(inode)) + return false; + } + /* * Allow non-NULL lower inode in ovl_inode even if lowerdentry is NULL. * This happens when finding a copied up overlay inode for a renamed @@ -633,6 +643,8 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry, struct inode *inode; /* Already indexed or could be indexed on copy up? */ bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry)); + struct dentry *origin = indexed ? lowerdentry : NULL; + bool is_dir; if (WARN_ON(upperdentry && indexed && !lowerdentry)) return ERR_PTR(-EIO); @@ -641,15 +653,19 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry, realinode = d_inode(lowerdentry); /* - * Copy up origin (lower) may exist for non-indexed upper, but we must - * not use lower as hash key in that case. - * Hash inodes that are or could be indexed by origin inode and - * non-indexed upper inodes that could be hard linked by upper inode. + * Copy up origin (lower) may exist for non-indexed non-dir upper, but + * we must not use lower as hash key in that case. + * Hash non-dir that is or could be indexed by origin inode. + * Hash dir that is or could be merged by origin inode. + * Hash pure upper and non-indexed non-dir by upper inode. */ - if (!S_ISDIR(realinode->i_mode) && (upperdentry || indexed)) { - struct inode *key = d_inode(indexed ? lowerdentry : - upperdentry); - unsigned int nlink; + is_dir = S_ISDIR(realinode->i_mode); + if (is_dir) + origin = lowerdentry; + + if (upperdentry || origin) { + struct inode *key = d_inode(origin ?: upperdentry); + unsigned int nlink = is_dir ? 1 : realinode->i_nlink; inode = iget5_locked(dentry->d_sb, (unsigned long) key, ovl_inode_test, ovl_inode_set, key); @@ -670,8 +686,9 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry, goto out; } - nlink = ovl_get_nlink(lowerdentry, upperdentry, - realinode->i_nlink); + /* Recalculate nlink for non-dir due to indexing */ + if (!is_dir) + nlink = ovl_get_nlink(lowerdentry, upperdentry, nlink); set_nlink(inode, nlink); } else { inode = new_inode(dentry->d_sb); @@ -685,7 +702,7 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry, ovl_set_flag(OVL_IMPURE, inode); /* Check for non-merge dir that may have whiteouts */ - if (S_ISDIR(realinode->i_mode)) { + if (is_dir) { struct ovl_entry *oe = dentry->d_fsdata; if (((upperdentry && lowerdentry) || oe->numlower > 1) || diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index 76440feb79f6..1a436fa92a04 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -211,6 +211,7 @@ static void ovl_destroy_inode(struct inode *inode) struct ovl_inode *oi = OVL_I(inode); dput(oi->__upperdentry); + iput(oi->lower); kfree(oi->redirect); ovl_dir_cache_free(inode); mutex_destroy(&oi->lock); diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c index d6bb1c9f5e7a..06119f34a69d 100644 --- a/fs/overlayfs/util.c +++ b/fs/overlayfs/util.c @@ -257,7 +257,7 @@ void ovl_inode_init(struct inode *inode, struct dentry *upperdentry, if (upperdentry) OVL_I(inode)->__upperdentry = upperdentry; if (lowerdentry) - OVL_I(inode)->lower = d_inode(lowerdentry); + OVL_I(inode)->lower = igrab(d_inode(lowerdentry)); ovl_copyattr(d_inode(upperdentry ?: lowerdentry), inode); } @@ -273,7 +273,7 @@ void ovl_inode_update(struct inode *inode, struct dentry *upperdentry) */ smp_wmb(); OVL_I(inode)->__upperdentry = upperdentry; - if (!S_ISDIR(upperinode->i_mode) && inode_unhashed(inode)) { + if (inode_unhashed(inode)) { inode->i_private = upperinode; __insert_inode_hash(inode, (unsigned long) upperinode); }

7 years, 3 months

4
3
0 0

[PATCH] ASoC: acpi: fix machine driver selection based on quirk

by Pierre-Louis Bossart

The ACPI/machine-driver code refactoring introduced in 4.13 introduced a regression for cases where we need a DMI-based quirk to select the machine driver (the BIOS reports an invalid HID). The fix is just to make sure the results of the quirk are actually used. back-ported to 4.14-stable from commit 5c256045b87b ("ASoC: acpi: fix machine driver selection based on quirk") which did not apply cleanly. Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data') Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691 Tested-by: Nicole Færber <nicole.faerber(a)dpin.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/intel/common/sst-match-acpi.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sound/soc/intel/common/sst-match-acpi.c b/sound/soc/intel/common/sst-match-acpi.c index 56d26f36a3cb..b4a929562218 100644 --- a/sound/soc/intel/common/sst-match-acpi.c +++ b/sound/soc/intel/common/sst-match-acpi.c @@ -83,11 +83,9 @@ struct sst_acpi_mach *sst_acpi_find_machine(struct sst_acpi_mach *machines) for (mach = machines; mach->id[0]; mach++) { if (sst_acpi_check_hid(mach->id) == true) { - if (mach->machine_quirk == NULL) - return mach; - - if (mach->machine_quirk(mach) != NULL) - return mach; + if (mach->machine_quirk) + mach = mach->machine_quirk(mach); + return mach; } } return NULL; -- 2.14.1

7 years, 3 months

2
1
0 0

Some sdhci-of-esdhc patches for 4.14

by Rasmus Villemoes

Hi, Please consider adding dd3f6983b4a4 mmc: sdhci-of-esdhc: disable SD clock for clock value 0 97618aca1440 mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec f2bc600008bd mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb (present in mainline since 4.15-rc1, 4.16-rc1 and 4.16-rc1, respectively) to 4.14-stable. The third removes all the code added by the second, but the clearing of the ESDHC_TB_EN bit from esdhc_init() (whose sole user is esdhc_probe) still happens during esdhc_probe() due to esdhc_probe() -> sdhci_add_host() -> __sdhci_add_host() -> sdhci_init(soft=0) -> sdhci_do_reset(host, mask=SDHCI_RESET_ALL) -> host->ops->reset(host, mask); Presumably they could/should have been squashed, but I suppose -stable prefers keeping a 1-1 correspondence with mainline when possible. Thanks, Rasmus

7 years, 3 months

2
1
0 0

Re: stable-rc build: 3 warnings 0 failures (stable-rc/v4.14.20-119-g1b1ab1d)

by Arnd Bergmann

On Tue, Feb 20, 2018 at 1:47 PM, Olof's autobuilder <build(a)lixom.net> wrote: > Warnings: > > arm64.allmodconfig: > drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=] Hi Greg, please add 16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN") This is an old bug, but hasn't shown up before as the stack warning limit was turned off in allmodconfig kernels. The fix is also on the backport lists I sent for 4.9 and 4.4. Arnd

7 years, 3 months

2
1
0 0

Re: [Linux-stable-mirror] stable-rc/linux-4.15.y build: 185 builds: 0 failed, 185 passed, 46 warnings (v4.15.1-61-g7ab5513e4cbc)

by Arnd Bergmann

On Mon, Feb 5, 2018 at 9:49 PM, kernelci.org bot <bot(a)kernelci.org> wrote: > > stable-rc/linux-4.15.y build: 185 builds: 0 failed, 185 passed, 46 warnings (v4.15.1-61-g7ab5513e4cbc) Hi Greg, FYI, the device tree compiler warnings are all fixed in linux-4.16-rc1. These are basically fixes that we ended up not submitting last minute for the release after one of them (the USB PHY one, if you remember) had blown up. Anyway, I think the risk is rather low for any of them (they are mostly platforms that are not widely used, and the fixes make things work that didn't), so to get a clean build, feel free to pick up the remaining patches from mainline now or after -rc1: > Warnings Detected: > > Warnings summary: > 2 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b4100000 > 2 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing property '#dma-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/serial@b4100000:dmas[4]) cdd104099141 ("arm: spear13xx: Fix dmas cells") > 2 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 > 2 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing property '#gpio-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/spi@e0100000:cs-gpios[6]) f8975cb1b8a3 ("arm: spear13xx: Fix spics gpio controller's warning") > 2 arch/arm/boot/dts/exynos5410-smdk5410.dtb: Warning (interrupts_property): Missing interrupt-controller or interrupt-map property in /soc/system-controller@10040000 > 2 arch/arm/boot/dts/exynos5410-smdk5410.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/system-controller@10040000 > 2 arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): Missing interrupt-controller or interrupt-map property in /soc/system-controller@10040000 > 2 arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/system-controller@10040000 5628a8ca1414 ("ARM: dts: exynos: fix RTC interrupt for exynos5410") > 2 WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o 3343647813fd ("ARM: pxa/tosa-bt: add MODULE_LICENSE tag") > 1 arch/arm64/boot/dts/qcom/msm8916-mtp.dtb: Warning (phys_property): Missing property '#phy-cells' in node /soc/mdss@1a00000/dsi-phy@1a98300 or bad phandle (referred from /soc/mdss@1a00000/dsi@1a98000:phys[0]) > 1 arch/arm64/boot/dts/qcom/apq8016-sbc.dtb: Warning (phys_property): Missing property '#phy-cells' in node /soc/mdss@1a00000/dsi-phy@1a98300 or bad phandle (referred from /soc/mdss@1a00000/dsi@1a98000:phys[0]) b0ab681285aa ("arm64: dts: msm8916: Add missing #phy-cells") > 1 arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@1:cooling-device[0]) > 1 arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@0:cooling-device[0]) acbf76ee0506 ("arm64: dts: add #cooling-cells to CPU nodes") > 1 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 > 1 arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 > 1 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 7ac1f59c09a6 ("ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property") > 1 arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 > 1 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 e8bfa0422469 ("ARM: dts: nomadik: add interrupt-parent for clcd") > 1 arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property): Missing interrupt-parent for /ahb/apb/rtc@fc900000 6ffb5b4f248f ("arm: spear600: Add missing interrupt-parent of rtc") > 1 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 > 1 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 > 1 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 > 1 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 > 1 arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 5c1037196b9e ("ARM: dts: s5pv210: add interrupt-parent for ohci") > 1 arch/arm/boot/dts/mt7623n-rfb-nand.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0]) > 1 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0]) 76a09ce214ad ("arm: dts: mt7623: Update ethsys binding") > 1 arch/arm/boot/dts/mt2701-evb.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0]) ae72e95b5e4d ("arm: dts: mt2701: Add reset-cells") > 1 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 > 1 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 > 1 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 > 1 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 ca32e0c4bf9c ("ARM: lpc3250: fix uda1380 gpio numbers") > 1 arch/arm/boot/dts/arm-realview-eb-a9mp.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 > 1 arch/arm/boot/dts/arm-realview-eb-a9mp-bbrevd.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 > 1 arch/arm/boot/dts/arm-realview-eb-11mp.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 > 1 arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 > 1 arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 > 1 arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000 586b2a4befad ("ARM: dts: Delete bogus reference to the charlcd") Arnd

7 years, 3 months

2
1
0 0

[PATCH] [stable 4.14 patch] x86: fix KMEMCHECK warning about FRAME_POINTER

by Arnd Bergmann

When KMEMCHECK is enabled without UNWINDER_FRAME_POINTER, we get a Kconfig warning, presumably harmless: warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK && LOCKDEP && UNWINDER_FRAME_POINTER) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS || !UNWINDER_ORC && !UNWINDER_GUESS) In newer mainline kernels, the KMEMCHECK option has been removed, so this no longer happens. Adding the unwinder as a direct dependency for KMEMCHECK works for 4.14-stable as well and documents the dependency better. Fixes: 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection") Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 17de6acc0eab..3fc58c1a166b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -111,7 +111,7 @@ config X86 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KASAN if X86_64 select HAVE_ARCH_KGDB - select HAVE_ARCH_KMEMCHECK + select HAVE_ARCH_KMEMCHECK if !UNWINDER_ORC && !UNWINDER_GUESS select HAVE_ARCH_MMAP_RND_BITS if MMU select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT select HAVE_ARCH_COMPAT_MMAP_BASES if MMU && COMPAT -- 2.9.0

7 years, 3 months

2
1
0 0

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

by Max Ivanov

> As already explained in the previous mail, there is a fixup for this in > commit 81b6c9998979 ('scsi: core: check for device state in > __scsi_remove_target()'). > Please check if this is applied, too. I tested commit 81b6c9998979 cherry-picked on top of 4.14.20 and it indeed solves the problem. Can it be backported to 4.14 LTS, please?

7 years, 3 months

2
1
0 0

Patch "vfs: don't do RCU lookup of empty pathnames" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfs: don't do RCU lookup of empty pathnames to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sun, 2 Apr 2017 17:10:08 -0700 Subject: vfs: don't do RCU lookup of empty pathnames From: Linus Torvalds <torvalds(a)linux-foundation.org> commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream. Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Eric Biggers <ebiggers3(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/namei.c +++ b/fs/namei.c @@ -1851,6 +1851,9 @@ static int path_init(int dfd, const char { int retval = 0; + if (!*s) + flags &= ~LOOKUP_RCU; + nd->last_type = LAST_ROOT; /* if there are only slashes... */ nd->flags = flags | LOOKUP_JUMPED; nd->depth = 0; Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are queue-3.18/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch

7 years, 3 months

2
1
0 0

Apply "vfs: don't do RCU lookup of empty pathnames" to stable

by Eric Biggers

Hi Greg, here's another one. When you have a chance can you please apply commit c0eb027e5aef ("vfs: don't do RCU lookup of empty pathnames") to the stable trees? I can reproduce the use-after-free on 4.4-stable and 4.9-stable, and it is fixed by the patch. And I wasn't able to check 3.18 because KASAN isn't available there, but I think the bug there as well. Thanks, Eric

7 years, 3 months

2
2
0 0

[PATCH 1/2] [stable-4.9] x86: fix build without CONFIG_X86_VSYSCALL_EMULATION

by Arnd Bergmann

I ran into a 4.9 build regression in randconfig testing, starting with the KAISER patches: arch/x86/mm/kaiser.c: In function 'kaiser_init': arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' undeclared (first use in this function); did you mean 'massage_pgprot'? This is easy enough to fix, we just need to make the declaration visible outside of the #ifdef. This works because the code using it is optimized away when vsyscall_enabled() returns false at compile time. Fixes: 9a0be5afbfbb ("vsyscall: Fix permissions for emulate mode with KAISER/PTI") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/x86/include/asm/vsyscall.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h index 9ee85066f407..c98c21b7f4cd 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,7 +13,6 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); -extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) @@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) static inline bool vsyscall_enabled(void) { return false; } #endif +extern unsigned long vsyscall_pgprot; + #endif /* _ASM_X86_VSYSCALL_H */ -- 2.9.0

7 years, 3 months

5
8
0 0

Patch "vfs: don't do RCU lookup of empty pathnames" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfs: don't do RCU lookup of empty pathnames to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sun, 2 Apr 2017 17:10:08 -0700 Subject: vfs: don't do RCU lookup of empty pathnames From: Linus Torvalds <torvalds(a)linux-foundation.org> commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream. Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Eric Biggers <ebiggers3(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/namei.c +++ b/fs/namei.c @@ -2138,6 +2138,9 @@ static const char *path_init(struct name int retval = 0; const char *s = nd->name->name; + if (!*s) + flags &= ~LOOKUP_RCU; + nd->last_type = LAST_ROOT; /* if there are only slashes... */ nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT; nd->depth = 0; Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are queue-4.9/x86-spectre-fix-an-error-message.patch queue-4.9/nospec-move-array_index_nospec-parameter-checking-into-separate-macro.patch queue-4.9/x86-nvmx-properly-set-spec_ctrl-and-pred_cmd-before-merging-msrs.patch queue-4.9/x86-speculation-add-asm-msr-index.h-dependency.patch queue-4.9/x86-cpu-rename-cpu_data.x86_mask-to-cpu_data.x86_stepping.patch queue-4.9/x86-cpu-change-type-of-x86_cache_size-variable-to-unsigned-int.patch queue-4.9/x86-speculation-update-speculation-control-microcode-blacklist.patch queue-4.9/x86-speculation-correct-speculation-control-microcode-blacklist-again.patch queue-4.9/ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch queue-4.9/selftests-x86-do-not-rely-on-int-0x80-in-single_step_syscall.c.patch queue-4.9/selftests-x86-mpx-fix-incorrect-bounds-with-old-_sigfault.patch queue-4.9/mm-hide-a-warning-for-compile_test.patch queue-4.9/selftests-x86-pkeys-remove-unused-functions.patch queue-4.9/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch queue-4.9/x86-speculation-fix-up-array_index_nospec_mask-asm-constraint.patch queue-4.9/kvm-x86-reduce-retpoline-performance-impact-in-slot_handle_level_range-by-always-inlining-iterator-helper-methods.patch queue-4.9/selftests-x86-do-not-rely-on-int-0x80-in-test_mremap_vdso.c.patch queue-4.9/x86-speculation-clean-up-various-spectre-related-details.patch queue-4.9/x86-entry-64-compat-clear-registers-for-compat-syscalls-to-reduce-speculation-attack-surface.patch

7 years, 3 months

1
0
0 0

Patch "dm: correctly handle chained bios in dec_pending()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm: correctly handle chained bios in dec_pending() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dm-correctly-handle-chained-bios-in-dec_pending.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: dm: correctly handle chained bios in dec_pending() From: NeilBrown <neilb(a)suse.com> commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream. dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -809,7 +809,8 @@ static void dec_pending(struct dm_io *io } else { /* done with normal IO or empty flush */ trace_block_bio_complete(md->queue, bio, io_error); - bio->bi_error = io_error; + if (io_error) + bio->bi_error = io_error; bio_endio(bio); } } Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.9/dm-correctly-handle-chained-bios-in-dec_pending.patch

7 years, 3 months

1
0
0 0

Patch "vfs: don't do RCU lookup of empty pathnames" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfs: don't do RCU lookup of empty pathnames to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sun, 2 Apr 2017 17:10:08 -0700 Subject: vfs: don't do RCU lookup of empty pathnames From: Linus Torvalds <torvalds(a)linux-foundation.org> commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream. Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com> Acked-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Eric Biggers <ebiggers3(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/namei.c +++ b/fs/namei.c @@ -2000,6 +2000,9 @@ static const char *path_init(struct name int retval = 0; const char *s = nd->name->name; + if (!*s) + flags &= ~LOOKUP_RCU; + nd->last_type = LAST_ROOT; /* if there are only slashes... */ nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT; nd->depth = 0; Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are queue-4.4/x86-cpu-change-type-of-x86_cache_size-variable-to-unsigned-int.patch queue-4.4/mm-hide-a-warning-for-compile_test.patch queue-4.4/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch queue-4.4/kvm-x86-reduce-retpoline-performance-impact-in-slot_handle_level_range-by-always-inlining-iterator-helper-methods.patch

7 years, 3 months

1
0
0 0

Patch "dm: correctly handle chained bios in dec_pending()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm: correctly handle chained bios in dec_pending() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dm-correctly-handle-chained-bios-in-dec_pending.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: dm: correctly handle chained bios in dec_pending() From: NeilBrown <neilb(a)suse.com> commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream. dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -974,7 +974,8 @@ static void dec_pending(struct dm_io *io } else { /* done with normal IO or empty flush */ trace_block_bio_complete(md->queue, bio, io_error); - bio->bi_error = io_error; + if (io_error) + bio->bi_error = io_error; bio_endio(bio); } } Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.4/dm-correctly-handle-chained-bios-in-dec_pending.patch

7 years, 3 months

1
0
0 0

Patch "x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-mm-hwpoison-don-t-unconditionally-unmap-kernel-1-1-pages.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd0e786d9d09024f67bd71ec094b110237dc3840 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Thu, 25 Jan 2018 14:23:48 -0800 Subject: x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages From: Tony Luck <tony.luck(a)intel.com> commit fd0e786d9d09024f67bd71ec094b110237dc3840 upstream. In the following commit: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") ... we added code to memory_failure() to unmap the page from the kernel 1:1 virtual address space to avoid speculative access to the page logging additional errors. But memory_failure() may not always succeed in taking the page offline, especially if the page belongs to the kernel. This can happen if there are too many corrected errors on a page and either mcelog(8) or drivers/ras/cec.c asks to take a page offline. Since we remove the 1:1 mapping early in memory_failure(), we can end up with the page unmapped, but still in use. On the next access the kernel crashes :-( There are also various debug paths that call memory_failure() to simulate occurrence of an error. Since there is no actual error in memory, we don't need to map out the page for those cases. Revert most of the previous attempt and keep the solution local to arch/x86/kernel/cpu/mcheck/mce.c. Unmap the page only when: 1) there is a real error 2) memory_failure() succeeds. All of this only applies to 64-bit systems. 32-bit kernel doesn't map all of memory into kernel space. It isn't worth adding the code to unmap the piece that is mapped because nobody would run a 32-bit kernel on a machine that has recoverable machine checks. Signed-off-by: Tony Luck <tony.luck(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave <dave.hansen(a)intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Robert (Persistent Memory) <elliott(a)hpe.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Cc: stable(a)vger.kernel.org #v4.14 Fixes: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/page_64.h | 4 ---- arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 +++++++++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 17 +++++++++++------ include/linux/mm_inline.h | 6 ------ mm/memory-failure.c | 2 -- 5 files changed, 26 insertions(+), 18 deletions(-) --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -52,10 +52,6 @@ static inline void clear_page(void *page void copy_page(void *to, void *from); -#ifdef CONFIG_X86_MCE -#define arch_unmap_kpfn arch_unmap_kpfn -#endif - #endif /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_VSYSCALL_EMULATION --- a/arch/x86/kernel/cpu/mcheck/mce-internal.h +++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h @@ -115,4 +115,19 @@ static inline void mce_unregister_inject extern struct mca_config mca_cfg; +#ifndef CONFIG_X86_64 +/* + * On 32-bit systems it would be difficult to safely unmap a poison page + * from the kernel 1:1 map because there are no non-canonical addresses that + * we can use to refer to the address without risking a speculative access. + * However, this isn't much of an issue because: + * 1) Few unmappable pages are in the 1:1 map. Most are in HIGHMEM which + * are only mapped into the kernel as needed + * 2) Few people would run a 32-bit kernel on a machine that supports + * recoverable errors because they have too much memory to boot 32-bit. + */ +static inline void mce_unmap_kpfn(unsigned long pfn) {} +#define mce_unmap_kpfn mce_unmap_kpfn +#endif + #endif /* __X86_MCE_INTERNAL_H__ */ --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -106,6 +106,10 @@ static struct irq_work mce_irq_work; static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs); +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn); +#endif + /* * CPU/chipset specific EDAC code can register a notifier call here to print * MCE errors in a human-readable form. @@ -582,7 +586,8 @@ static int srao_decode_notifier(struct n if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) { pfn = mce->addr >> PAGE_SHIFT; - memory_failure(pfn, MCE_VECTOR, 0); + if (memory_failure(pfn, MCE_VECTOR, 0)) + mce_unmap_kpfn(pfn); } return NOTIFY_OK; @@ -1049,12 +1054,13 @@ static int do_memory_failure(struct mce ret = memory_failure(m->addr >> PAGE_SHIFT, MCE_VECTOR, flags); if (ret) pr_err("Memory error not recovered"); + else + mce_unmap_kpfn(m->addr >> PAGE_SHIFT); return ret; } -#if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE) - -void arch_unmap_kpfn(unsigned long pfn) +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn) { unsigned long decoy_addr; @@ -1065,7 +1071,7 @@ void arch_unmap_kpfn(unsigned long pfn) * We would like to just call: * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1); * but doing that would radically increase the odds of a - * speculative access to the posion page because we'd have + * speculative access to the poison page because we'd have * the virtual address of the kernel 1:1 mapping sitting * around in registers. * Instead we get tricky. We create a non-canonical address @@ -1090,7 +1096,6 @@ void arch_unmap_kpfn(unsigned long pfn) if (set_memory_np(decoy_addr, 1)) pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); - } #endif --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -127,10 +127,4 @@ static __always_inline enum lru_list pag #define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) -#ifdef arch_unmap_kpfn -extern void arch_unmap_kpfn(unsigned long pfn); -#else -static __always_inline void arch_unmap_kpfn(unsigned long pfn) { } -#endif - #endif --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1146,8 +1146,6 @@ int memory_failure(unsigned long pfn, in return 0; } - arch_unmap_kpfn(pfn); - orig_head = hpage = compound_head(p); num_poisoned_pages_inc(); Patches currently in stable-queue which might be from tony.luck(a)intel.com are queue-4.15/x86-cpu-rename-cpu_data.x86_mask-to-cpu_data.x86_stepping.patch queue-4.15/x86-mm-mm-hwpoison-don-t-unconditionally-unmap-kernel-1-1-pages.patch

7 years, 3 months

1
0
0 0

Patch "x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-mm-hwpoison-don-t-unconditionally-unmap-kernel-1-1-pages.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd0e786d9d09024f67bd71ec094b110237dc3840 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Thu, 25 Jan 2018 14:23:48 -0800 Subject: x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages From: Tony Luck <tony.luck(a)intel.com> commit fd0e786d9d09024f67bd71ec094b110237dc3840 upstream. In the following commit: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") ... we added code to memory_failure() to unmap the page from the kernel 1:1 virtual address space to avoid speculative access to the page logging additional errors. But memory_failure() may not always succeed in taking the page offline, especially if the page belongs to the kernel. This can happen if there are too many corrected errors on a page and either mcelog(8) or drivers/ras/cec.c asks to take a page offline. Since we remove the 1:1 mapping early in memory_failure(), we can end up with the page unmapped, but still in use. On the next access the kernel crashes :-( There are also various debug paths that call memory_failure() to simulate occurrence of an error. Since there is no actual error in memory, we don't need to map out the page for those cases. Revert most of the previous attempt and keep the solution local to arch/x86/kernel/cpu/mcheck/mce.c. Unmap the page only when: 1) there is a real error 2) memory_failure() succeeds. All of this only applies to 64-bit systems. 32-bit kernel doesn't map all of memory into kernel space. It isn't worth adding the code to unmap the piece that is mapped because nobody would run a 32-bit kernel on a machine that has recoverable machine checks. Signed-off-by: Tony Luck <tony.luck(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave <dave.hansen(a)intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Robert (Persistent Memory) <elliott(a)hpe.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Cc: stable(a)vger.kernel.org #v4.14 Fixes: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/page_64.h | 4 ---- arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 +++++++++++++++ arch/x86/kernel/cpu/mcheck/mce.c | 17 +++++++++++------ include/linux/mm_inline.h | 6 ------ mm/memory-failure.c | 2 -- 5 files changed, 26 insertions(+), 18 deletions(-) --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -52,10 +52,6 @@ static inline void clear_page(void *page void copy_page(void *to, void *from); -#ifdef CONFIG_X86_MCE -#define arch_unmap_kpfn arch_unmap_kpfn -#endif - #endif /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_VSYSCALL_EMULATION --- a/arch/x86/kernel/cpu/mcheck/mce-internal.h +++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h @@ -115,4 +115,19 @@ static inline void mce_unregister_inject extern struct mca_config mca_cfg; +#ifndef CONFIG_X86_64 +/* + * On 32-bit systems it would be difficult to safely unmap a poison page + * from the kernel 1:1 map because there are no non-canonical addresses that + * we can use to refer to the address without risking a speculative access. + * However, this isn't much of an issue because: + * 1) Few unmappable pages are in the 1:1 map. Most are in HIGHMEM which + * are only mapped into the kernel as needed + * 2) Few people would run a 32-bit kernel on a machine that supports + * recoverable errors because they have too much memory to boot 32-bit. + */ +static inline void mce_unmap_kpfn(unsigned long pfn) {} +#define mce_unmap_kpfn mce_unmap_kpfn +#endif + #endif /* __X86_MCE_INTERNAL_H__ */ --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -106,6 +106,10 @@ static struct irq_work mce_irq_work; static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs); +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn); +#endif + /* * CPU/chipset specific EDAC code can register a notifier call here to print * MCE errors in a human-readable form. @@ -582,7 +586,8 @@ static int srao_decode_notifier(struct n if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) { pfn = mce->addr >> PAGE_SHIFT; - memory_failure(pfn, MCE_VECTOR, 0); + if (memory_failure(pfn, MCE_VECTOR, 0)) + mce_unmap_kpfn(pfn); } return NOTIFY_OK; @@ -1049,12 +1054,13 @@ static int do_memory_failure(struct mce ret = memory_failure(m->addr >> PAGE_SHIFT, MCE_VECTOR, flags); if (ret) pr_err("Memory error not recovered"); + else + mce_unmap_kpfn(m->addr >> PAGE_SHIFT); return ret; } -#if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE) - -void arch_unmap_kpfn(unsigned long pfn) +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn) { unsigned long decoy_addr; @@ -1065,7 +1071,7 @@ void arch_unmap_kpfn(unsigned long pfn) * We would like to just call: * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1); * but doing that would radically increase the odds of a - * speculative access to the posion page because we'd have + * speculative access to the poison page because we'd have * the virtual address of the kernel 1:1 mapping sitting * around in registers. * Instead we get tricky. We create a non-canonical address @@ -1090,7 +1096,6 @@ void arch_unmap_kpfn(unsigned long pfn) if (set_memory_np(decoy_addr, 1)) pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); - } #endif --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -127,10 +127,4 @@ static __always_inline enum lru_list pag #define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) -#ifdef arch_unmap_kpfn -extern void arch_unmap_kpfn(unsigned long pfn); -#else -static __always_inline void arch_unmap_kpfn(unsigned long pfn) { } -#endif - #endif --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1146,8 +1146,6 @@ int memory_failure(unsigned long pfn, in return 0; } - arch_unmap_kpfn(pfn); - orig_head = hpage = compound_head(p); num_poisoned_pages_inc(); Patches currently in stable-queue which might be from tony.luck(a)intel.com are queue-4.14/x86-cpu-rename-cpu_data.x86_mask-to-cpu_data.x86_stepping.patch queue-4.14/x86-mm-mm-hwpoison-don-t-unconditionally-unmap-kernel-1-1-pages.patch

7 years, 3 months

1
0
0 0

Re: [PATCH - 4.4-stable] dm: correctly handle chained bios in dec_pending()

by Greg KH

On Wed, Feb 21, 2018 at 07:06:39AM +1100, NeilBrown wrote: > > Commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream. Thanks for this, and the 4.9 backport, both now applied. greg k-h

7 years, 3 months

1
0
0 0

FAILED: patch "[PATCH] x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fd0e786d9d09024f67bd71ec094b110237dc3840 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Thu, 25 Jan 2018 14:23:48 -0800 Subject: [PATCH] x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages In the following commit: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") ... we added code to memory_failure() to unmap the page from the kernel 1:1 virtual address space to avoid speculative access to the page logging additional errors. But memory_failure() may not always succeed in taking the page offline, especially if the page belongs to the kernel. This can happen if there are too many corrected errors on a page and either mcelog(8) or drivers/ras/cec.c asks to take a page offline. Since we remove the 1:1 mapping early in memory_failure(), we can end up with the page unmapped, but still in use. On the next access the kernel crashes :-( There are also various debug paths that call memory_failure() to simulate occurrence of an error. Since there is no actual error in memory, we don't need to map out the page for those cases. Revert most of the previous attempt and keep the solution local to arch/x86/kernel/cpu/mcheck/mce.c. Unmap the page only when: 1) there is a real error 2) memory_failure() succeeds. All of this only applies to 64-bit systems. 32-bit kernel doesn't map all of memory into kernel space. It isn't worth adding the code to unmap the piece that is mapped because nobody would run a 32-bit kernel on a machine that has recoverable machine checks. Signed-off-by: Tony Luck <tony.luck(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave <dave.hansen(a)intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Robert (Persistent Memory) <elliott(a)hpe.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Cc: stable(a)vger.kernel.org #v4.14 Fixes: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") Signed-off-by: Ingo Molnar <mingo(a)kernel.org> diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h index 4baa6bceb232..d652a3808065 100644 --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -52,10 +52,6 @@ static inline void clear_page(void *page) void copy_page(void *to, void *from); -#ifdef CONFIG_X86_MCE -#define arch_unmap_kpfn arch_unmap_kpfn -#endif - #endif /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_VSYSCALL_EMULATION diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h b/arch/x86/kernel/cpu/mcheck/mce-internal.h index aa0d5df9dc60..e956eb267061 100644 --- a/arch/x86/kernel/cpu/mcheck/mce-internal.h +++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h @@ -115,4 +115,19 @@ static inline void mce_unregister_injector_chain(struct notifier_block *nb) { } extern struct mca_config mca_cfg; +#ifndef CONFIG_X86_64 +/* + * On 32-bit systems it would be difficult to safely unmap a poison page + * from the kernel 1:1 map because there are no non-canonical addresses that + * we can use to refer to the address without risking a speculative access. + * However, this isn't much of an issue because: + * 1) Few unmappable pages are in the 1:1 map. Most are in HIGHMEM which + * are only mapped into the kernel as needed + * 2) Few people would run a 32-bit kernel on a machine that supports + * recoverable errors because they have too much memory to boot 32-bit. + */ +static inline void mce_unmap_kpfn(unsigned long pfn) {} +#define mce_unmap_kpfn mce_unmap_kpfn +#endif + #endif /* __X86_MCE_INTERNAL_H__ */ diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 75f405ac085c..8ff94d1e2dce 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -105,6 +105,10 @@ static struct irq_work mce_irq_work; static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs); +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn); +#endif + /* * CPU/chipset specific EDAC code can register a notifier call here to print * MCE errors in a human-readable form. @@ -590,7 +594,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val, if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) { pfn = mce->addr >> PAGE_SHIFT; - memory_failure(pfn, 0); + if (!memory_failure(pfn, 0)) + mce_unmap_kpfn(pfn); } return NOTIFY_OK; @@ -1057,12 +1062,13 @@ static int do_memory_failure(struct mce *m) ret = memory_failure(m->addr >> PAGE_SHIFT, flags); if (ret) pr_err("Memory error not recovered"); + else + mce_unmap_kpfn(m->addr >> PAGE_SHIFT); return ret; } -#if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE) - -void arch_unmap_kpfn(unsigned long pfn) +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn) { unsigned long decoy_addr; @@ -1073,7 +1079,7 @@ void arch_unmap_kpfn(unsigned long pfn) * We would like to just call: * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1); * but doing that would radically increase the odds of a - * speculative access to the posion page because we'd have + * speculative access to the poison page because we'd have * the virtual address of the kernel 1:1 mapping sitting * around in registers. * Instead we get tricky. We create a non-canonical address @@ -1098,7 +1104,6 @@ void arch_unmap_kpfn(unsigned long pfn) if (set_memory_np(decoy_addr, 1)) pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); - } #endif diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index c30b32e3c862..10191c28fc04 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -127,10 +127,4 @@ static __always_inline enum lru_list page_lru(struct page *page) #define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) -#ifdef arch_unmap_kpfn -extern void arch_unmap_kpfn(unsigned long pfn); -#else -static __always_inline void arch_unmap_kpfn(unsigned long pfn) { } -#endif - #endif diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 4b80ccee4535..8291b75f42c8 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1139,8 +1139,6 @@ int memory_failure(unsigned long pfn, int flags) return 0; } - arch_unmap_kpfn(pfn); - orig_head = hpage = compound_head(p); num_poisoned_pages_inc();

7 years, 3 months

3
2
0 0

[PATCH] i2c: designware: must wait for enable

by Ben Gardner

One I2C bus on my Atom E3845 board has been broken since 4.9. It has two devices, both declared by ACPI and with built-in drivers. There are two back-to-back transactions originating from the kernel, one targeting each device. The first transaction works, the second one locks up the I2C controller. The controller never recovers. These kernel logs show up whenever an I2C transaction is attempted after this failure. i2c-designware-pci 0000:00:18.3: timeout in disabling adapter i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready Waiting for the I2C controller status to indicate that it is enabled before programming it fixes the issue. I have tested this patch on 4.14 and 4.15. Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary") Cc: linux-stable <stable(a)vger.kernel.org> #4.13+ Cc: José Roberto de Souza <jose.souza(a)intel.com> Signed-off-by: Ben Gardner <gardner.ben(a)gmail.com> --- drivers/i2c/busses/i2c-designware-master.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index ae69188..55926ef 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -209,7 +209,7 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev) i2c_dw_disable_int(dev); /* Enable the adapter */ - __i2c_dw_enable(dev, true); + __i2c_dw_enable_and_wait(dev, true); /* Clear and enable interrupts */ dw_readl(dev, DW_IC_CLR_INTR); -- 2.7.4

7 years, 4 months

3
2
0 0

[PATCH] mm: don't defer struct page initialization for Xen pv guests

by Juergen Gross

Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. Avoid this problem by not deferring struct page initialization when running as Xen pv guest. Cc: <stable(a)vger.kernel.org> #4.15 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- mm/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 81e18ceef579..681d504b9a40 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_data_t *pgdat, /* Always populate low zones for address-constrained allocations */ if (zone_end < pgdat_end_pfn(pgdat)) return true; + /* Xen PV domains need page structures early */ + if (xen_pv_domain()) + return true; (*nr_initialised)++; if ((*nr_initialised > pgdat->static_init_pgcnt) && (pfn & (PAGES_PER_SECTION - 1)) == 0) { -- 2.13.6

7 years, 4 months

5
7
0 0

[Linux-stable-mirror] [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> 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 Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") Reported-by: Paolo Valente <paolo.valente(a)linaro.org> Cc: Paolo Valente <paolo.valente(a)linaro.org> Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/asymmetric_keys/public_key.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c index de996586762a..e929fe1e4106 100644 --- a/crypto/asymmetric_keys/public_key.c +++ b/crypto/asymmetric_keys/public_key.c @@ -79,9 +79,11 @@ int public_key_verify_signature(const struct public_key *pkey, BUG_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 -- 2.16.0.rc1.238.g530d649a79-goog

7 years, 4 months

2
2
0 0

[PATCH] x86: oprofile: nmi_int: fix bogus gcc-8 warning

by Arnd Bergmann

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. Cc:stable as we also want old kernels to build cleanly with gcc-8. Cc: Martin Sebor <msebor(a)gcc.gnu.org> Cc: stable(a)vger.kernel.org Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/x86/oprofile/nmi_int.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/oprofile/nmi_int.c b/arch/x86/oprofile/nmi_int.c index 174c59774cc9..1d6d14db96c0 100644 --- a/arch/x86/oprofile/nmi_int.c +++ b/arch/x86/oprofile/nmi_int.c @@ -460,7 +460,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, @@ -470,7 +470,6 @@ static int nmi_setup(void) memcpy(per_cpu(cpu_msrs, cpu).controls, per_cpu(cpu_msrs, 0).controls, sizeof(struct op_msr) * model->num_controls); - mux_clone(cpu); } -- 2.9.0

7 years, 4 months

1
0
0 0

Patch "usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-move-usb_uhci_big_endian_-out-of-usb_support.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ec897569ad7dbc6d595873a487c3fac23f463f76 Mon Sep 17 00:00:00 2001 From: James Hogan <jhogan(a)kernel.org> Date: Wed, 31 Jan 2018 22:24:45 +0000 Subject: usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT From: James Hogan <jhogan(a)kernel.org> commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream. Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is conditional upon USB && USB_SUPPORT, so that it can be freely selected by platform Kconfig symbols in architecture code. For example once the MIPS_GENERIC platform selects are fixed in commit 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS 32r6_defconfig warns like so: warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB) warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB) Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Corentin Labbe <clabbe.montjoie(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Paul Burton <paul.burton(a)mips.com> Cc: linux-usb(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Patchwork: https://patchwork.linux-mips.org/patch/18559/ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/Kconfig | 8 ++++++++ drivers/usb/host/Kconfig | 8 -------- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO config USB_EHCI_BIG_ENDIAN_DESC bool +config USB_UHCI_BIG_ENDIAN_MMIO + bool + default y if SPARC_LEON + +config USB_UHCI_BIG_ENDIAN_DESC + bool + default y if SPARC_LEON + menuconfig USB_SUPPORT bool "USB support" depends on HAS_IOMEM --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -628,14 +628,6 @@ config USB_UHCI_PLATFORM bool default y if ARCH_VT8500 -config USB_UHCI_BIG_ENDIAN_MMIO - bool - default y if SPARC_LEON - -config USB_UHCI_BIG_ENDIAN_DESC - bool - default y if SPARC_LEON - config USB_FHCI_HCD tristate "Freescale QE USB Host Controller support" depends on OF_GPIO && QE_GPIO && QUICC_ENGINE Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.9/usb-move-usb_uhci_big_endian_-out-of-usb_support.patch queue-4.9/mips-fix-typo-big_endian-to-cpu_big_endian.patch

7 years, 4 months

1
0
0 0

Patch "usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-move-usb_uhci_big_endian_-out-of-usb_support.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ec897569ad7dbc6d595873a487c3fac23f463f76 Mon Sep 17 00:00:00 2001 From: James Hogan <jhogan(a)kernel.org> Date: Wed, 31 Jan 2018 22:24:45 +0000 Subject: usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT From: James Hogan <jhogan(a)kernel.org> commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream. Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is conditional upon USB && USB_SUPPORT, so that it can be freely selected by platform Kconfig symbols in architecture code. For example once the MIPS_GENERIC platform selects are fixed in commit 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS 32r6_defconfig warns like so: warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB) warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB) Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Corentin Labbe <clabbe.montjoie(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Paul Burton <paul.burton(a)mips.com> Cc: linux-usb(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Patchwork: https://patchwork.linux-mips.org/patch/18559/ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/Kconfig | 8 ++++++++ drivers/usb/host/Kconfig | 8 -------- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO config USB_EHCI_BIG_ENDIAN_DESC bool +config USB_UHCI_BIG_ENDIAN_MMIO + bool + default y if SPARC_LEON + +config USB_UHCI_BIG_ENDIAN_DESC + bool + default y if SPARC_LEON + menuconfig USB_SUPPORT bool "USB support" depends on HAS_IOMEM --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -625,14 +625,6 @@ config USB_UHCI_ASPEED bool default y if ARCH_ASPEED -config USB_UHCI_BIG_ENDIAN_MMIO - bool - default y if SPARC_LEON - -config USB_UHCI_BIG_ENDIAN_DESC - bool - default y if SPARC_LEON - config USB_FHCI_HCD tristate "Freescale QE USB Host Controller support" depends on OF_GPIO && QE_GPIO && QUICC_ENGINE Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.15/usb-move-usb_uhci_big_endian_-out-of-usb_support.patch queue-4.15/mips-fix-typo-big_endian-to-cpu_big_endian.patch queue-4.15/mips-fix-incorrect-mem-x-y-handling.patch queue-4.15/mips-cps-fix-mips_isa_level_raw-fallout.patch

7 years, 4 months

1
0
0 0

Patch "usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-move-usb_uhci_big_endian_-out-of-usb_support.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ec897569ad7dbc6d595873a487c3fac23f463f76 Mon Sep 17 00:00:00 2001 From: James Hogan <jhogan(a)kernel.org> Date: Wed, 31 Jan 2018 22:24:45 +0000 Subject: usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT From: James Hogan <jhogan(a)kernel.org> commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream. Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is conditional upon USB && USB_SUPPORT, so that it can be freely selected by platform Kconfig symbols in architecture code. For example once the MIPS_GENERIC platform selects are fixed in commit 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS 32r6_defconfig warns like so: warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB) warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB) Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Corentin Labbe <clabbe.montjoie(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Paul Burton <paul.burton(a)mips.com> Cc: linux-usb(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Patchwork: https://patchwork.linux-mips.org/patch/18559/ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/Kconfig | 8 ++++++++ drivers/usb/host/Kconfig | 8 -------- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO config USB_EHCI_BIG_ENDIAN_DESC bool +config USB_UHCI_BIG_ENDIAN_MMIO + bool + default y if SPARC_LEON + +config USB_UHCI_BIG_ENDIAN_DESC + bool + default y if SPARC_LEON + menuconfig USB_SUPPORT bool "USB support" depends on HAS_IOMEM --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -637,14 +637,6 @@ config USB_UHCI_ASPEED bool default y if ARCH_ASPEED -config USB_UHCI_BIG_ENDIAN_MMIO - bool - default y if SPARC_LEON - -config USB_UHCI_BIG_ENDIAN_DESC - bool - default y if SPARC_LEON - config USB_FHCI_HCD tristate "Freescale QE USB Host Controller support" depends on OF_GPIO && QE_GPIO && QUICC_ENGINE Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.14/usb-move-usb_uhci_big_endian_-out-of-usb_support.patch queue-4.14/mips-fix-typo-big_endian-to-cpu_big_endian.patch queue-4.14/mips-fix-incorrect-mem-x-y-handling.patch

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: [PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 9afb8ab524c7..06b22624ab7a 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request, int validx, int *value_ret) { struct snd_usb_audio *chip = cval->head.mixer->chip; - unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = uac2_ctl_value_size(cval->val_type); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -390,16 +393,17 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request, val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; }

7 years, 4 months

1
0
0 0

Re: Patch "MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN" has been added to the 4.15-stable tree

by Greg KH

On Tue, Feb 20, 2018 at 03:32:44PM +0000, James Hogan wrote: > Hi Greg, > > On Tue, Feb 20, 2018 at 12:10:06PM +0100, gregkh(a)linuxfoundation.org wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN > > > > to the 4.15-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > > > The filename of the patch is: > > mips-fix-typo-big_endian-to-cpu_big_endian.patch > > and it can be found in the queue-4.15 subdirectory. > > > > If you, or anyone else, feels it should not be added to the stable tree, > > please let <stable(a)vger.kernel.org> know about it. > > FYI this will introduce the following harmless kconfig warnings which > are fixed by commit ec897569ad7d ("usb: Move USB_UHCI_BIG_ENDIAN_* out > of USB_SUPPORT"): > > warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB) > warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB) > > If anybody cares about such warnings, that patch could be applied also. I'll go queue that up too, thanks. greg k-h

7 years, 4 months

1
0
0 0

Patch "target/iscsi: avoid NULL dereference in CHAP auth error path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: avoid NULL dereference in CHAP auth error path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce512d79d0466a604793addb6b769d12ee326822 Mon Sep 17 00:00:00 2001 From: David Disseldorp <ddiss(a)suse.de> Date: Wed, 13 Dec 2017 18:22:30 +0100 Subject: target/iscsi: avoid NULL dereference in CHAP auth error path From: David Disseldorp <ddiss(a)suse.de> commit ce512d79d0466a604793addb6b769d12ee326822 upstream. If chap_server_compute_md5() fails early, e.g. via CHAP_N mismatch, then crypto_free_shash() is called with a NULL pointer which gets dereferenced in crypto_shash_tfm(). Fixes: 69110e3cedbb ("iscsi-target: Use shash and ahash") Suggested-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: David Disseldorp <ddiss(a)suse.de> Cc: stable(a)vger.kernel.org # 4.6+ Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_auth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target_auth.c +++ b/drivers/target/iscsi/iscsi_target_auth.c @@ -413,7 +413,8 @@ static int chap_server_compute_md5( auth_ret = 0; out: kzfree(desc); - crypto_free_shash(tfm); + if (tfm) + crypto_free_shash(tfm); kfree(challenge); kfree(challenge_binhex); return auth_ret; Patches currently in stable-queue which might be from ddiss(a)suse.de are queue-4.9/target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch

7 years, 4 months

1
0
0 0

Patch "rtlwifi: rtl8821ae: Fix connection lost problem correctly" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl8821ae: Fix connection lost problem correctly to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c713fb071edc0efc01a955f65a006b0e1795d2eb Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Mon, 5 Feb 2018 12:38:11 -0600 Subject: rtlwifi: rtl8821ae: Fix connection lost problem correctly From: Larry Finger <Larry.Finger(a)lwfinger.net> commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream. There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Tested-by: James Cameron <quozl(a)laptop.org> # x86_64 OLPC NL3 Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1128,7 +1128,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1170,7 +1170,8 @@ static void _rtl8821ae_enable_aspm_back_ } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.9/rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch

7 years, 4 months

1
0
0 0

Patch "mvpp2: fix multicast address filter" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mvpp2: fix multicast address filter to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mvpp2-fix-multicast-address-filter.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Sun, 11 Feb 2018 18:10:28 -0500 Subject: mvpp2: fix multicast address filter From: Mikulas Patocka <mpatocka(a)redhat.com> commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream. IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/marvell/mvpp2.c +++ b/drivers/net/ethernet/marvell/mvpp2.c @@ -5657,6 +5657,7 @@ static void mvpp2_set_rx_mode(struct net int id = port->id; bool allmulti = dev->flags & IFF_ALLMULTI; +retry: mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti); @@ -5664,9 +5665,13 @@ static void mvpp2_set_rx_mode(struct net /* Remove all port->id's mcast enries */ mvpp2_prs_mcast_del_all(priv, id); - if (allmulti && !netdev_mc_empty(dev)) { - netdev_for_each_mc_addr(ha, dev) - mvpp2_prs_mac_da_accept(priv, id, ha->addr, true); + if (!allmulti) { + netdev_for_each_mc_addr(ha, dev) { + if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) { + allmulti = true; + goto retry; + } + } } } Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.9/mvpp2-fix-multicast-address-filter.patch

7 years, 4 months

1
0
0 0

Patch "mtd: nand: vf610: set correct ooblayout" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: vf610: set correct ooblayout to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-vf610-set-correct-ooblayout.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ea56fb282368ea08c2a313af6b55cb597aec4db1 Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Fri, 9 Feb 2018 13:21:42 +0100 Subject: mtd: nand: vf610: set correct ooblayout From: Stefan Agner <stefan(a)agner.ch> commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream. With commit 3cf32d180227 ("mtd: nand: vf610: switch to mtd_ooblayout_ops") the driver started to use the NAND cores default large page ooblayout. However, shortly after commit 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") changed the default layout to the old hamming layout, which is not what vf610_nfc is using. Specify the default large page layout explicitly. Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") Cc: <stable(a)vger.kernel.org> # v4.12+ Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/vf610_nfc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/mtd/nand/vf610_nfc.c +++ b/drivers/mtd/nand/vf610_nfc.c @@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platfo if (mtd->oobsize > 64) mtd->oobsize = 64; - /* - * mtd->ecclayout is not specified here because we're using the - * default large page ECC layout defined in NAND core. - */ + /* Use default large page ECC layout defined in NAND core */ + mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops); if (chip->ecc.strength == 32) { nfc->ecc_mode = ECC_60_BYTE; chip->ecc.bytes = 60; Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.9/mtd-nand-vf610-set-correct-ooblayout.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix unexpected -EEXIST when creating new inode" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix unexpected -EEXIST when creating new inode to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-unexpected-eexist-when-creating-new-inode.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:56 -0700 Subject: Btrfs: fix unexpected -EEXIST when creating new inode From: Liu Bo <bo.li.liu(a)oracle.com> commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream. The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: <stable(a)vger.kernel.org> v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -28,6 +28,7 @@ #include "hash.h" #include "compression.h" #include "qgroup.h" +#include "inode-map.h" /* magic values for the inode_only field in btrfs_log_inode: * @@ -5661,6 +5662,23 @@ again: path); } + if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) { + struct btrfs_root *root = wc.replay_dest; + + btrfs_release_path(path); + + /* + * We have just replayed everything, and the highest + * objectid of fs roots probably has changed in case + * some inode_item's got replayed. + * + * root->objectid_mutex is not acquired as log replay + * could only happen during mount. + */ + ret = btrfs_find_highest_objectid(root, + &root->highest_objectid); + } + key.offset = found_key.offset - 1; wc.replay_dest->log_root = NULL; free_extent_buffer(log->node); Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix extent state leak from tree log" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix extent state leak from tree log to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-extent-state-leak-from-tree-log.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 55237a5f2431a72435e3ed39e4306e973c0446b7 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:52 -0700 Subject: Btrfs: fix extent state leak from tree log From: Liu Bo <bo.li.liu(a)oracle.com> commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream. It's possible that btrfs_sync_log() bails out after one of the two btrfs_write_marked_extents() which convert extent state's state bit into EXTENT_NEED_WAIT from EXTENT_DIRTY/EXTENT_NEW, however only EXTENT_DIRTY and EXTENT_NEW are searched by free_log_tree() so that those extent states with EXTENT_NEED_WAIT lead to memory leak. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -3013,13 +3013,14 @@ static void free_log_tree(struct btrfs_t while (1) { ret = find_first_extent_bit(&log->dirty_log_pages, - 0, &start, &end, EXTENT_DIRTY | EXTENT_NEW, + 0, &start, &end, + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT, NULL); if (ret) break; clear_extent_bits(&log->dirty_log_pages, start, end, - EXTENT_DIRTY | EXTENT_NEW); + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT); } /* Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix deadlock in run_delalloc_nocow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix deadlock in run_delalloc_nocow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-in-run_delalloc_nocow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:50 -0700 Subject: Btrfs: fix deadlock in run_delalloc_nocow From: Liu Bo <bo.li.liu(a)oracle.com> commit e89166990f11c3f21e1649d760dd35f9e410321c upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1320,8 +1320,11 @@ next_slot: leaf = path->nodes[0]; if (path->slots[0] >= btrfs_header_nritems(leaf)) { ret = btrfs_next_leaf(root, path); - if (ret < 0) + if (ret < 0) { + if (cow_start != (u64)-1) + cur_offset = cow_start; goto error; + } if (ret > 0) break; leaf = path->nodes[0]; Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e8f1bc1493855e32b7a2a019decc3c353d94daf6 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:53 -0700 Subject: Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly From: Liu Bo <bo.li.liu(a)oracle.com> commit e8f1bc1493855e32b7a2a019decc3c353d94daf6 upstream. This regression is introduced in commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction"). There are two problems, a) it is ->destroy_inode() that does the final free on inode, not ->evict_inode(), b) clear_inode() must be called before ->evict_inode() returns. This could end up hitting BUG_ON(inode->i_state != (I_FREEING | I_CLEAR)); in evict() because I_CLEAR is set in clear_inode(). Fixes: commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction") Cc: <stable(a)vger.kernel.org> # v4.7-rc6+ Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5229,7 +5229,7 @@ void btrfs_evict_inode(struct inode *ino trace_btrfs_inode_evict(inode); if (!root) { - kmem_cache_free(btrfs_inode_cachep, BTRFS_I(inode)); + clear_inode(inode); return; } Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix crash due to not cleaning up tree log block's dirty bits" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix crash due to not cleaning up tree log block's dirty bits to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:51 -0700 Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits From: Liu Bo <bo.li.liu(a)oracle.com> commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2463,6 +2463,9 @@ static noinline int walk_down_log_tree(s next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != @@ -2542,6 +2545,9 @@ static noinline int walk_up_log_tree(str next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID); @@ -2618,6 +2624,9 @@ static int walk_log_tree(struct btrfs_tr clean_tree_block(trans, log->fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(log->root_key.objectid != Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute From: Kirill Marinushkin <k.marinushkin(a)gmail.com> commit 447cae58cecd69392b74a4a42cd0ab9cabd816af upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/mixer.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -344,17 +344,20 @@ static int get_ctl_value_v2(struct usb_m int validx, int *value_ret) { struct snd_usb_audio *chip = cval->head.mixer->chip; - unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = uac2_ctl_value_size(cval->val_type); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -387,16 +390,17 @@ error: val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; } Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are queue-4.9/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: seq: Fix racy pool initializations" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix racy pool initializations to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-racy-pool-initializations.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d15d662e89fc667b90cd294b0eb45694e33144da Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Feb 2018 15:20:51 +0100 Subject: ALSA: seq: Fix racy pool initializations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 <long7573(a)126.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -999,7 +999,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1014,11 +1014,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch queue-4.9/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch queue-4.9/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch queue-4.9/alsa-seq-fix-racy-pool-initializations.patch queue-4.9/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch queue-4.9/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 Mon Sep 17 00:00:00 2001 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Date: Fri, 9 Feb 2018 16:51:36 +0200 Subject: ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 upstream. Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/pcm.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -357,6 +357,15 @@ static int set_sync_ep_implicit_fb_quirk alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x1397, 0x0002): + ep = 0x81; + iface = usb_ifnum_to_if(dev, 1); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; } if (attr == USB_ENDPOINT_SYNC_ASYNC && Patches currently in stable-queue which might be from lassi.ylikojola(a)gmail.com are queue-4.9/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek: PCI quirk for Fujitsu U7x7" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 Mon Sep 17 00:00:00 2001 From: Jan-Marek Glogowski <glogow(a)fbihome.de> Date: Wed, 14 Feb 2018 11:29:15 +0100 Subject: ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 From: Jan-Marek Glogowski <glogow(a)fbihome.de> commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 upstream. These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by: Jan-Marek Glogowski <glogow(a)fbihome.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3130,6 +3130,19 @@ static void alc269_fixup_pincfg_no_hp_to spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; } +static void alc269_fixup_pincfg_U7x7_headset_mic(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + unsigned int cfg_headphone = snd_hda_codec_get_pincfg(codec, 0x21); + unsigned int cfg_headset_mic = snd_hda_codec_get_pincfg(codec, 0x19); + + if (cfg_headphone && cfg_headset_mic == 0x411111f0) + snd_hda_codec_set_pincfg(codec, 0x19, + (cfg_headphone & ~AC_DEFCFG_DEVICE) | + (AC_JACK_MIC_IN << AC_DEFCFG_DEVICE_SHIFT)); +} + static void alc269_fixup_hweq(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -4819,6 +4832,7 @@ enum { ALC269_FIXUP_LIFEBOOK_EXTMIC, ALC269_FIXUP_LIFEBOOK_HP_PIN, ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT, + ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC, ALC269_FIXUP_AMIC, ALC269_FIXUP_DMIC, ALC269VB_FIXUP_AMIC, @@ -5010,6 +5024,10 @@ static const struct hda_fixup alc269_fix .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_pincfg_no_hp_to_lineout, }, + [ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_pincfg_U7x7_headset_mic, + }, [ALC269_FIXUP_AMIC] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { @@ -5733,6 +5751,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT), SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN), SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", ALC269_FIXUP_LIFEBOOK_HP_PIN), + SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC), SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", ALC269_FIXUP_LIFEBOOK_EXTMIC), SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", ALC283_FIXUP_HEADSET_MIC), Patches currently in stable-queue which might be from glogow(a)fbihome.de are queue-4.9/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d Mon Sep 17 00:00:00 2001 From: Kailang Yang <kailang(a)realtek.com> Date: Fri, 2 Feb 2018 15:26:46 +0800 Subject: ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform From: Kailang Yang <kailang(a)realtek.com> commit 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d upstream. Thinkpad Dock device support for ALC298 platform. It need to use SSID for the quirk table. Because IdeaPad also has ALC298 platform. Use verb for the quirk table will confuse. Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4455,6 +4455,28 @@ static void alc_fixup_tpt440_dock(struct } } +static void alc_fixup_tpt470_dock(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + static const struct hda_pintbl pincfgs[] = { + { 0x17, 0x21211010 }, /* dock headphone */ + { 0x19, 0x21a11010 }, /* dock mic */ + { } + }; + struct alc_spec *spec = codec->spec; + + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x17, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x19, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + snd_hda_apply_pincfgs(codec, pincfgs); + } +} + static void alc_shutup_dell_xps13(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; @@ -4877,6 +4899,7 @@ enum { ALC292_FIXUP_TPT460, ALC298_FIXUP_SPK_VOLUME, ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER, + ALC298_FIXUP_TPT470_DOCK, }; static const struct hda_fixup alc269_fixups[] = { @@ -5568,6 +5591,12 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE }, + [ALC298_FIXUP_TPT470_DOCK] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_tpt470_dock, + .chained = true, + .chain_id = ALC293_FIXUP_LENOVO_SPK_NOISE + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5729,8 +5758,16 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x2218, "Thinkpad X1 Carbon 2nd", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x2231, "Thinkpad T560", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x2245, "Thinkpad T470", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2246, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2247, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224b, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x3112, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), @@ -5749,7 +5786,12 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x5050, "Thinkpad T560p", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5051, "Thinkpad L460", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5053, "Thinkpad T460", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x505d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x505f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x5062, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */ Patches currently in stable-queue which might be from kailang(a)realtek.com are queue-4.9/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch

7 years, 4 months

1
0
0 0

Patch "9p/trans_virtio: discard zero-length reply" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 9p/trans_virtio: discard zero-length reply to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: 9p-trans_virtio-discard-zero-length-reply.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 26d99834f89e76514076d9cd06f61e56e6a509b8 Mon Sep 17 00:00:00 2001 From: Greg Kurz <groug(a)kaod.org> Date: Mon, 22 Jan 2018 22:02:05 +0100 Subject: 9p/trans_virtio: discard zero-length reply From: Greg Kurz <groug(a)kaod.org> commit 26d99834f89e76514076d9cd06f61e56e6a509b8 upstream. When a 9p request is successfully flushed, the server is expected to just mark it as used without sending a 9p reply (ie, without writing data into the buffer). In this case, virtqueue_get_buf() will return len == 0 and we must not report a REQ_STATUS_RCVD status to the client, otherwise the client will erroneously assume the request has not been flushed. Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kurz <groug(a)kaod.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/trans_virtio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -160,7 +160,8 @@ static void req_done(struct virtqueue *v spin_unlock_irqrestore(&chan->lock, flags); /* Wakeup if anyone waiting for VirtIO ring space. */ wake_up(chan->vc_wq); - p9_client_cb(chan->client, req, REQ_STATUS_RCVD); + if (len) + p9_client_cb(chan->client, req, REQ_STATUS_RCVD); } } Patches currently in stable-queue which might be from groug(a)kaod.org are queue-4.9/9p-trans_virtio-discard-zero-length-reply.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda - Fix headset mic detection problem for two Dell machines" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Fix headset mic detection problem for two Dell machines to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3f2f7c553d077be6a30cb96b2976a2c940bf5335 Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Mon, 29 Jan 2018 14:23:15 +0800 Subject: ALSA: hda - Fix headset mic detection problem for two Dell machines From: Hui Wang <hui.wang(a)canonical.com> commit 3f2f7c553d077be6a30cb96b2976a2c940bf5335 upstream. One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5994,6 +5994,11 @@ static const struct snd_hda_pin_quirk al {0x14, 0x90170110}, {0x21, 0x02211020}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0x90a60130}, + {0x14, 0x90170110}, + {0x14, 0x01011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, @@ -6049,6 +6054,10 @@ static const struct snd_hda_pin_quirk al {0x12, 0x90a60120}, {0x14, 0x90170110}, {0x21, 0x0321101f}), + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0290, 0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC290_STANDARD_PINS, {0x15, 0x04211040}, Patches currently in stable-queue which might be from hui.wang(a)canonical.com are queue-4.9/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch

7 years, 4 months

1
0
0 0

Patch "rtlwifi: rtl8821ae: Fix connection lost problem correctly" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl8821ae: Fix connection lost problem correctly to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c713fb071edc0efc01a955f65a006b0e1795d2eb Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Mon, 5 Feb 2018 12:38:11 -0600 Subject: rtlwifi: rtl8821ae: Fix connection lost problem correctly From: Larry Finger <Larry.Finger(a)lwfinger.net> commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream. There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Tested-by: James Cameron <quozl(a)laptop.org> # x86_64 OLPC NL3 Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1127,7 +1127,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1169,7 +1169,8 @@ static void _rtl8821ae_enable_aspm_back_ } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.4/rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch

7 years, 4 months

1
0
0 0

Patch "mvpp2: fix multicast address filter" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mvpp2: fix multicast address filter to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mvpp2-fix-multicast-address-filter.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Sun, 11 Feb 2018 18:10:28 -0500 Subject: mvpp2: fix multicast address filter From: Mikulas Patocka <mpatocka(a)redhat.com> commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream. IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/marvell/mvpp2.c +++ b/drivers/net/ethernet/marvell/mvpp2.c @@ -5666,6 +5666,7 @@ static void mvpp2_set_rx_mode(struct net int id = port->id; bool allmulti = dev->flags & IFF_ALLMULTI; +retry: mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti); @@ -5673,9 +5674,13 @@ static void mvpp2_set_rx_mode(struct net /* Remove all port->id's mcast enries */ mvpp2_prs_mcast_del_all(priv, id); - if (allmulti && !netdev_mc_empty(dev)) { - netdev_for_each_mc_addr(ha, dev) - mvpp2_prs_mac_da_accept(priv, id, ha->addr, true); + if (!allmulti) { + netdev_for_each_mc_addr(ha, dev) { + if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) { + allmulti = true; + goto retry; + } + } } } Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.4/mvpp2-fix-multicast-address-filter.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix unexpected -EEXIST when creating new inode" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix unexpected -EEXIST when creating new inode to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-unexpected-eexist-when-creating-new-inode.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:56 -0700 Subject: Btrfs: fix unexpected -EEXIST when creating new inode From: Liu Bo <bo.li.liu(a)oracle.com> commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream. The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: <stable(a)vger.kernel.org> v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -26,6 +26,7 @@ #include "print-tree.h" #include "backref.h" #include "hash.h" +#include "inode-map.h" /* magic values for the inode_only field in btrfs_log_inode: * @@ -5523,6 +5524,23 @@ again: path); } + if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) { + struct btrfs_root *root = wc.replay_dest; + + btrfs_release_path(path); + + /* + * We have just replayed everything, and the highest + * objectid of fs roots probably has changed in case + * some inode_item's got replayed. + * + * root->objectid_mutex is not acquired as log replay + * could only happen during mount. + */ + ret = btrfs_find_highest_objectid(root, + &root->highest_objectid); + } + key.offset = found_key.offset - 1; wc.replay_dest->log_root = NULL; free_extent_buffer(log->node); Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.4/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.4/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.4/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix crash due to not cleaning up tree log block's dirty bits" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix crash due to not cleaning up tree log block's dirty bits to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:51 -0700 Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits From: Liu Bo <bo.li.liu(a)oracle.com> commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2445,6 +2445,9 @@ static noinline int walk_down_log_tree(s next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != @@ -2524,6 +2527,9 @@ static noinline int walk_up_log_tree(str next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID); @@ -2600,6 +2606,9 @@ static int walk_log_tree(struct btrfs_tr clean_tree_block(trans, log->fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(log->root_key.objectid != Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.4/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.4/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.4/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix deadlock in run_delalloc_nocow" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix deadlock in run_delalloc_nocow to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-in-run_delalloc_nocow.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:50 -0700 Subject: Btrfs: fix deadlock in run_delalloc_nocow From: Liu Bo <bo.li.liu(a)oracle.com> commit e89166990f11c3f21e1649d760dd35f9e410321c upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1292,8 +1292,11 @@ next_slot: leaf = path->nodes[0]; if (path->slots[0] >= btrfs_header_nritems(leaf)) { ret = btrfs_next_leaf(root, path); - if (ret < 0) + if (ret < 0) { + if (cow_start != (u64)-1) + cur_offset = cow_start; goto error; + } if (ret > 0) break; leaf = path->nodes[0]; Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.4/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.4/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.4/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 Mon Sep 17 00:00:00 2001 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Date: Fri, 9 Feb 2018 16:51:36 +0200 Subject: ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 upstream. Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/pcm.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -348,6 +348,15 @@ static int set_sync_ep_implicit_fb_quirk alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x1397, 0x0002): + ep = 0x81; + iface = usb_ifnum_to_if(dev, 1); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; } if (attr == USB_ENDPOINT_SYNC_ASYNC && altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC && Patches currently in stable-queue which might be from lassi.ylikojola(a)gmail.com are queue-4.4/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute From: Kirill Marinushkin <k.marinushkin(a)gmail.com> commit 447cae58cecd69392b74a4a42cd0ab9cabd816af upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/mixer.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -343,17 +343,20 @@ static int get_ctl_value_v2(struct usb_m int validx, int *value_ret) { struct snd_usb_audio *chip = cval->head.mixer->chip; - unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = uac2_ctl_value_size(cval->val_type); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -386,16 +389,17 @@ error: val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; } Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are queue-4.4/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek: PCI quirk for Fujitsu U7x7" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 Mon Sep 17 00:00:00 2001 From: Jan-Marek Glogowski <glogow(a)fbihome.de> Date: Wed, 14 Feb 2018 11:29:15 +0100 Subject: ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 From: Jan-Marek Glogowski <glogow(a)fbihome.de> commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 upstream. These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by: Jan-Marek Glogowski <glogow(a)fbihome.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3130,6 +3130,19 @@ static void alc269_fixup_pincfg_no_hp_to spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; } +static void alc269_fixup_pincfg_U7x7_headset_mic(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + unsigned int cfg_headphone = snd_hda_codec_get_pincfg(codec, 0x21); + unsigned int cfg_headset_mic = snd_hda_codec_get_pincfg(codec, 0x19); + + if (cfg_headphone && cfg_headset_mic == 0x411111f0) + snd_hda_codec_set_pincfg(codec, 0x19, + (cfg_headphone & ~AC_DEFCFG_DEVICE) | + (AC_JACK_MIC_IN << AC_DEFCFG_DEVICE_SHIFT)); +} + static void alc269_fixup_hweq(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -4782,6 +4795,7 @@ enum { ALC269_FIXUP_LIFEBOOK_EXTMIC, ALC269_FIXUP_LIFEBOOK_HP_PIN, ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT, + ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC, ALC269_FIXUP_AMIC, ALC269_FIXUP_DMIC, ALC269VB_FIXUP_AMIC, @@ -4972,6 +4986,10 @@ static const struct hda_fixup alc269_fix .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_pincfg_no_hp_to_lineout, }, + [ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_pincfg_U7x7_headset_mic, + }, [ALC269_FIXUP_AMIC] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { @@ -5687,6 +5705,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT), SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN), SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", ALC269_FIXUP_LIFEBOOK_HP_PIN), + SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC), SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", ALC269_FIXUP_LIFEBOOK_EXTMIC), SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", ALC269_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", ALC283_FIXUP_BXBT2807_MIC), Patches currently in stable-queue which might be from glogow(a)fbihome.de are queue-4.4/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: seq: Fix racy pool initializations" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix racy pool initializations to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-racy-pool-initializations.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d15d662e89fc667b90cd294b0eb45694e33144da Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Feb 2018 15:20:51 +0100 Subject: ALSA: seq: Fix racy pool initializations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 <long7573(a)126.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -1012,7 +1012,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1027,11 +1027,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch queue-4.4/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch queue-4.4/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch queue-4.4/alsa-seq-fix-racy-pool-initializations.patch queue-4.4/alsa-seq-fix-regression-by-incorrect-ioctl_mutex-usages.patch queue-4.4/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda - Fix headset mic detection problem for two Dell machines" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Fix headset mic detection problem for two Dell machines to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3f2f7c553d077be6a30cb96b2976a2c940bf5335 Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Mon, 29 Jan 2018 14:23:15 +0800 Subject: ALSA: hda - Fix headset mic detection problem for two Dell machines From: Hui Wang <hui.wang(a)canonical.com> commit 3f2f7c553d077be6a30cb96b2976a2c940bf5335 upstream. One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5976,6 +5976,11 @@ static const struct snd_hda_pin_quirk al {0x14, 0x90170110}, {0x21, 0x02211020}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0x90a60130}, + {0x14, 0x90170110}, + {0x14, 0x01011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, @@ -6031,6 +6036,10 @@ static const struct snd_hda_pin_quirk al {0x12, 0x90a60120}, {0x14, 0x90170110}, {0x21, 0x0321101f}), + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0290, 0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC290_STANDARD_PINS, {0x15, 0x04211040}, Patches currently in stable-queue which might be from hui.wang(a)canonical.com are queue-4.4/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch

7 years, 4 months

1
0
0 0

Patch "xprtrdma: Fix calculation of ri_max_send_sges" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xprtrdma: Fix calculation of ri_max_send_sges to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xprtrdma-fix-calculation-of-ri_max_send_sges.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1179e2c27efe21167ec9d882b14becefba2ee990 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Wed, 31 Jan 2018 12:34:05 -0500 Subject: xprtrdma: Fix calculation of ri_max_send_sges From: Chuck Lever <chuck.lever(a)oracle.com> commit 1179e2c27efe21167ec9d882b14becefba2ee990 upstream. Commit 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") introduced the rpcrdma_ia::ri_max_send_sges field. This fixes a problem where xprtrdma would not work if the device's max_sge capability was small (low single digits). At least RPCRDMA_MIN_SEND_SGES are needed for the inline parts of each RPC. ri_max_send_sges is set to this value: ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES; Then when marshaling each RPC, rpcrdma_args_inline uses that value to determine whether the device has enough Send SGEs to convey an NFS WRITE payload inline, or whether instead a Read chunk is required. More recently, commit ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments") used the ri_max_send_sges value to calculate the size of an array, but that commit erroneously assumed ri_max_send_sges contains a value similar to the device's max_sge, and not one that was reduced by the minimum SGE count. This assumption results in the calculated size of the sendctx's Send SGE array to be too small. When the array is used to marshal an RPC, the code can write Send SGEs into the following sendctx element in that array, corrupting it. When the device's max_sge is large, this issue is entirely harmless; but it results in an oops in the provider's post_send method, if dev.attrs.max_sge is small. So let's straighten this out: ri_max_send_sges will now contain a value with the same meaning as dev.attrs.max_sge, which makes the code easier to understand, and enables rpcrdma_sendctx_create to calculate the size of the SGE array correctly. Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Fixes: 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Tested-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Cc: stable(a)vger.kernel.org # v4.10+ Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtrdma/rpc_rdma.c | 2 +- net/sunrpc/xprtrdma/verbs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -143,7 +143,7 @@ static bool rpcrdma_args_inline(struct r if (xdr->page_len) { remaining = xdr->page_len; offset = offset_in_page(xdr->page_base); - count = 0; + count = RPCRDMA_MIN_SEND_SGES; while (remaining) { remaining -= min_t(unsigned int, PAGE_SIZE - offset, remaining); --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -509,7 +509,7 @@ rpcrdma_ep_create(struct rpcrdma_ep *ep, pr_warn("rpcrdma: HCA provides only %d send SGEs\n", max_sge); return -ENOMEM; } - ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES; + ia->ri_max_send_sges = max_sge; if (ia->ri_device->attrs.max_qp_wr <= RPCRDMA_BACKWARD_WRS) { dprintk("RPC: %s: insufficient wqe's available\n", Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are queue-4.15/xprtrdma-fix-bug-after-a-device-removal.patch queue-4.15/xprtrdma-fix-calculation-of-ri_max_send_sges.patch

7 years, 4 months

1
0
0 0

Patch "xprtrdma: Fix BUG after a device removal" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xprtrdma: Fix BUG after a device removal to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xprtrdma-fix-bug-after-a-device-removal.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89e8d8fcdc6751e86ccad794b052fe67e6ad619 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Wed, 31 Jan 2018 12:34:13 -0500 Subject: xprtrdma: Fix BUG after a device removal From: Chuck Lever <chuck.lever(a)oracle.com> commit e89e8d8fcdc6751e86ccad794b052fe67e6ad619 upstream. Michal Kalderon reports a BUG that occurs just after device removal: [ 169.112490] rpcrdma: removing device qedr0 for 192.168.110.146:20049 [ 169.143909] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 169.181837] IP: rpcrdma_dma_unmap_regbuf+0xa/0x60 [rpcrdma] The RPC/RDMA client transport attempts to allocate some resources on demand. Registered buffers are one such resource. These are allocated (or re-allocated) by xprt_rdma_allocate to hold RPC Call and Reply messages. A hardware resource is associated with each of these buffers, as they can be used for a Send or Receive Work Request. If a device is removed from under an NFS/RDMA mount, the transport layer is responsible for releasing all hardware resources before the device can be finally unplugged. A BUG results when the NFS mount hasn't yet seen much activity: the transport tries to release resources that haven't yet been allocated. rpcrdma_free_regbuf() already checks for this case, so just move that check to cover the DEVICE_REMOVAL case as well. Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA ...") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Tested-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtrdma/verbs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -1476,6 +1476,9 @@ __rpcrdma_dma_map_regbuf(struct rpcrdma_ static void rpcrdma_dma_unmap_regbuf(struct rpcrdma_regbuf *rb) { + if (!rb) + return; + if (!rpcrdma_regbuf_is_mapped(rb)) return; @@ -1491,9 +1494,6 @@ rpcrdma_dma_unmap_regbuf(struct rpcrdma_ void rpcrdma_free_regbuf(struct rpcrdma_regbuf *rb) { - if (!rb) - return; - rpcrdma_dma_unmap_regbuf(rb); kfree(rb); } Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are queue-4.15/xprtrdma-fix-bug-after-a-device-removal.patch queue-4.15/xprtrdma-fix-calculation-of-ri_max_send_sges.patch

7 years, 4 months

1
0
0 0

Patch "target/iscsi: avoid NULL dereference in CHAP auth error path" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: avoid NULL dereference in CHAP auth error path to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce512d79d0466a604793addb6b769d12ee326822 Mon Sep 17 00:00:00 2001 From: David Disseldorp <ddiss(a)suse.de> Date: Wed, 13 Dec 2017 18:22:30 +0100 Subject: target/iscsi: avoid NULL dereference in CHAP auth error path From: David Disseldorp <ddiss(a)suse.de> commit ce512d79d0466a604793addb6b769d12ee326822 upstream. If chap_server_compute_md5() fails early, e.g. via CHAP_N mismatch, then crypto_free_shash() is called with a NULL pointer which gets dereferenced in crypto_shash_tfm(). Fixes: 69110e3cedbb ("iscsi-target: Use shash and ahash") Suggested-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: David Disseldorp <ddiss(a)suse.de> Cc: stable(a)vger.kernel.org # 4.6+ Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_auth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target_auth.c +++ b/drivers/target/iscsi/iscsi_target_auth.c @@ -421,7 +421,8 @@ static int chap_server_compute_md5( auth_ret = 0; out: kzfree(desc); - crypto_free_shash(tfm); + if (tfm) + crypto_free_shash(tfm); kfree(challenge); kfree(challenge_binhex); return auth_ret; Patches currently in stable-queue which might be from ddiss(a)suse.de are queue-4.15/target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch

7 years, 4 months

1
0
0 0

Patch "mvpp2: fix multicast address filter" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mvpp2: fix multicast address filter to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mvpp2-fix-multicast-address-filter.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Sun, 11 Feb 2018 18:10:28 -0500 Subject: mvpp2: fix multicast address filter From: Mikulas Patocka <mpatocka(a)redhat.com> commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream. IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/marvell/mvpp2.c +++ b/drivers/net/ethernet/marvell/mvpp2.c @@ -7127,6 +7127,7 @@ static void mvpp2_set_rx_mode(struct net int id = port->id; bool allmulti = dev->flags & IFF_ALLMULTI; +retry: mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti); @@ -7134,9 +7135,13 @@ static void mvpp2_set_rx_mode(struct net /* Remove all port->id's mcast enries */ mvpp2_prs_mcast_del_all(priv, id); - if (allmulti && !netdev_mc_empty(dev)) { - netdev_for_each_mc_addr(ha, dev) - mvpp2_prs_mac_da_accept(priv, id, ha->addr, true); + if (!allmulti) { + netdev_for_each_mc_addr(ha, dev) { + if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) { + allmulti = true; + goto retry; + } + } } } Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.15/mvpp2-fix-multicast-address-filter.patch queue-4.15/blk-wbt-account-flush-requests-correctly.patch

7 years, 4 months

1
0
0 0

Patch "mtd: nand: vf610: set correct ooblayout" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: vf610: set correct ooblayout to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-vf610-set-correct-ooblayout.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ea56fb282368ea08c2a313af6b55cb597aec4db1 Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Fri, 9 Feb 2018 13:21:42 +0100 Subject: mtd: nand: vf610: set correct ooblayout From: Stefan Agner <stefan(a)agner.ch> commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream. With commit 3cf32d180227 ("mtd: nand: vf610: switch to mtd_ooblayout_ops") the driver started to use the NAND cores default large page ooblayout. However, shortly after commit 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") changed the default layout to the old hamming layout, which is not what vf610_nfc is using. Specify the default large page layout explicitly. Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") Cc: <stable(a)vger.kernel.org> # v4.12+ Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/vf610_nfc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/mtd/nand/vf610_nfc.c +++ b/drivers/mtd/nand/vf610_nfc.c @@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platfo if (mtd->oobsize > 64) mtd->oobsize = 64; - /* - * mtd->ecclayout is not specified here because we're using the - * default large page ECC layout defined in NAND core. - */ + /* Use default large page ECC layout defined in NAND core */ + mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops); if (chip->ecc.strength == 32) { nfc->ecc_mode = ECC_60_BYTE; chip->ecc.bytes = 60; Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.15/mtd-nand-vf610-set-correct-ooblayout.patch

7 years, 4 months

1
0
0 0

Patch "iscsi-target: make sure to wake up sleeping login worker" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: make sure to wake up sleeping login worker to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1c130ae00b769a2e2df41bad3d6051ee8234b636 Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw(a)strlen.de> Date: Fri, 19 Jan 2018 14:36:29 +0100 Subject: iscsi-target: make sure to wake up sleeping login worker From: Florian Westphal <fw(a)strlen.de> commit 1c130ae00b769a2e2df41bad3d6051ee8234b636 upstream. Mike Christie reports: Starting in 4.14 iscsi logins will fail around 50% of the time. Problem appears to be that iscsi_target_sk_data_ready() callback may return without doing anything in case it finds the login work queue is still blocked in sock_recvmsg(). Nicholas Bellinger says: It would indicate users providing their own ->sk_data_ready() callback must be responsible for waking up a kthread context blocked on sock_recvmsg(..., MSG_WAITALL), when a second ->sk_data_ready() is received before the first sock_recvmsg(..., MSG_WAITALL) completes. So, do this and invoke the original data_ready() callback -- in case of tcp sockets this takes care of waking the thread. Disclaimer: I do not understand why this problem did not show up before tcp prequeue removal. (Drop WARN_ON usage - nab) Reported-by: Mike Christie <mchristi(a)redhat.com> Bisected-by: Mike Christie <mchristi(a)redhat.com> Tested-by: Mike Christie <mchristi(a)redhat.com> Diagnosed-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Fixes: e7942d0633c4 ("tcp: remove prequeue support") Signed-off-by: Florian Westphal <fw(a)strlen.de> Cc: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_nego.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/target/iscsi/iscsi_target_nego.c +++ b/drivers/target/iscsi/iscsi_target_nego.c @@ -432,6 +432,9 @@ static void iscsi_target_sk_data_ready(s if (test_and_set_bit(LOGIN_FLAGS_READ_ACTIVE, &conn->login_flags)) { write_unlock_bh(&sk->sk_callback_lock); pr_debug("Got LOGIN_FLAGS_READ_ACTIVE=1, conn: %p >>>>\n", conn); + if (iscsi_target_sk_data_ready == conn->orig_data_ready) + return; + conn->orig_data_ready(sk); return; } Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.15/iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch

7 years, 4 months

1
0
0 0

Patch "dm: correctly handle chained bios in dec_pending()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm: correctly handle chained bios in dec_pending() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dm-correctly-handle-chained-bios-in-dec_pending.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: dm: correctly handle chained bios in dec_pending() From: NeilBrown <neilb(a)suse.com> commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream. dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -817,7 +817,8 @@ static void dec_pending(struct dm_io *io queue_io(md, bio); } else { /* done with normal IO or empty flush */ - bio->bi_status = io_error; + if (io_error) + bio->bi_status = io_error; bio_endio(bio); } } Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.15/dm-correctly-handle-chained-bios-in-dec_pending.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix use-after-free on root->orphan_block_rsv" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix use-after-free on root->orphan_block_rsv to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:54 -0700 Subject: Btrfs: fix use-after-free on root->orphan_block_rsv From: Liu Bo <bo.li.liu(a)oracle.com> commit 1a932ef4e47984dee227834667b5ff5a334e4805 upstream. I got these from running generic/475, WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs] Call Trace: btrfs_orphan_release_metadata+0x9f/0x200 [btrfs] btrfs_orphan_del+0x10d/0x170 [btrfs] btrfs_setattr+0x500/0x640 [btrfs] notify_change+0x7ae/0x870 do_truncate+0xca/0x130 vfs_truncate+0x2ee/0x3d0 do_sys_truncate+0xaf/0xf0 SyS_truncate+0xe/0x10 entry_SYSCALL_64_fastpath+0x1f/0x96 The race is between btrfs_orphan_commit_root and btrfs_orphan_del, t1 t2 btrfs_orphan_commit_root btrfs_orphan_del spin_lock check (&root->orphan_inodes) root->orphan_block_rsv = NULL; spin_unlock atomic_dec(&root->orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3369,6 +3369,11 @@ int btrfs_orphan_add(struct btrfs_trans_ ret = btrfs_orphan_reserve_metadata(trans, inode); ASSERT(!ret); if (ret) { + /* + * dec doesn't need spin_lock as ->orphan_block_rsv + * would be released only if ->orphan_inodes is + * zero. + */ atomic_dec(&root->orphan_inodes); clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3383,12 +3388,17 @@ int btrfs_orphan_add(struct btrfs_trans_ if (insert >= 1) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); if (ret) { - atomic_dec(&root->orphan_inodes); if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); btrfs_orphan_release_metadata(inode); } + /* + * btrfs_orphan_commit_root may race with us and set + * ->orphan_block_rsv to zero, in order to avoid that, + * decrease ->orphan_inodes after everything is done. + */ + atomic_dec(&root->orphan_inodes); if (ret != -EEXIST) { clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags); @@ -3420,28 +3430,26 @@ static int btrfs_orphan_del(struct btrfs { struct btrfs_root *root = inode->root; int delete_item = 0; - int release_rsv = 0; int ret = 0; - spin_lock(&root->orphan_lock); if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags)) delete_item = 1; + if (delete_item && trans) + ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode)); + if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags)) - release_rsv = 1; - spin_unlock(&root->orphan_lock); + btrfs_orphan_release_metadata(inode); - if (delete_item) { + /* + * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv + * to zero, in order to avoid that, decrease ->orphan_inodes after + * everything is done. + */ + if (delete_item) atomic_dec(&root->orphan_inodes); - if (trans) - ret = btrfs_del_orphan_item(trans, root, - btrfs_ino(inode)); - } - - if (release_rsv) - btrfs_orphan_release_metadata(inode); return ret; } Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix unexpected -EEXIST when creating new inode" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix unexpected -EEXIST when creating new inode to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-unexpected-eexist-when-creating-new-inode.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:56 -0700 Subject: Btrfs: fix unexpected -EEXIST when creating new inode From: Liu Bo <bo.li.liu(a)oracle.com> commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream. The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: <stable(a)vger.kernel.org> v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -28,6 +28,7 @@ #include "hash.h" #include "compression.h" #include "qgroup.h" +#include "inode-map.h" /* magic values for the inode_only field in btrfs_log_inode: * @@ -5715,6 +5716,23 @@ again: path); } + if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) { + struct btrfs_root *root = wc.replay_dest; + + btrfs_release_path(path); + + /* + * We have just replayed everything, and the highest + * objectid of fs roots probably has changed in case + * some inode_item's got replayed. + * + * root->objectid_mutex is not acquired as log replay + * could only happen during mount. + */ + ret = btrfs_find_highest_objectid(root, + &root->highest_objectid); + } + key.offset = found_key.offset - 1; wc.replay_dest->log_root = NULL; free_extent_buffer(log->node); Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix extent state leak from tree log" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix extent state leak from tree log to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-extent-state-leak-from-tree-log.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 55237a5f2431a72435e3ed39e4306e973c0446b7 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:52 -0700 Subject: Btrfs: fix extent state leak from tree log From: Liu Bo <bo.li.liu(a)oracle.com> commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream. It's possible that btrfs_sync_log() bails out after one of the two btrfs_write_marked_extents() which convert extent state's state bit into EXTENT_NEED_WAIT from EXTENT_DIRTY/EXTENT_NEW, however only EXTENT_DIRTY and EXTENT_NEW are searched by free_log_tree() so that those extent states with EXTENT_NEED_WAIT lead to memory leak. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -3049,13 +3049,14 @@ static void free_log_tree(struct btrfs_t while (1) { ret = find_first_extent_bit(&log->dirty_log_pages, - 0, &start, &end, EXTENT_DIRTY | EXTENT_NEW, + 0, &start, &end, + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT, NULL); if (ret) break; clear_extent_bits(&log->dirty_log_pages, start, end, - EXTENT_DIRTY | EXTENT_NEW); + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT); } /* Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix crash due to not cleaning up tree log block's dirty bits" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix crash due to not cleaning up tree log block's dirty bits to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:51 -0700 Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits From: Liu Bo <bo.li.liu(a)oracle.com> commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2494,6 +2494,9 @@ static noinline int walk_down_log_tree(s clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != @@ -2574,6 +2577,9 @@ static noinline int walk_up_log_tree(str clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID); @@ -2652,6 +2658,9 @@ static int walk_log_tree(struct btrfs_tr clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(log->root_key.objectid != Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix deadlock in run_delalloc_nocow" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix deadlock in run_delalloc_nocow to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-in-run_delalloc_nocow.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:50 -0700 Subject: Btrfs: fix deadlock in run_delalloc_nocow From: Liu Bo <bo.li.liu(a)oracle.com> commit e89166990f11c3f21e1649d760dd35f9e410321c upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1330,8 +1330,11 @@ next_slot: leaf = path->nodes[0]; if (path->slots[0] >= btrfs_header_nritems(leaf)) { ret = btrfs_next_leaf(root, path); - if (ret < 0) + if (ret < 0) { + if (cow_start != (u64)-1) + cur_offset = cow_start; goto error; + } if (ret > 0) break; leaf = path->nodes[0]; Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e8f1bc1493855e32b7a2a019decc3c353d94daf6 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:53 -0700 Subject: Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly From: Liu Bo <bo.li.liu(a)oracle.com> commit e8f1bc1493855e32b7a2a019decc3c353d94daf6 upstream. This regression is introduced in commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction"). There are two problems, a) it is ->destroy_inode() that does the final free on inode, not ->evict_inode(), b) clear_inode() must be called before ->evict_inode() returns. This could end up hitting BUG_ON(inode->i_state != (I_FREEING | I_CLEAR)); in evict() because I_CLEAR is set in clear_inode(). Fixes: commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction") Cc: <stable(a)vger.kernel.org> # v4.7-rc6+ Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5266,7 +5266,7 @@ void btrfs_evict_inode(struct inode *ino trace_btrfs_inode_evict(inode); if (!root) { - kmem_cache_free(btrfs_inode_cachep, BTRFS_I(inode)); + clear_inode(inode); return; } Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "blk-wbt: account flush requests correctly" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-wbt: account flush requests correctly to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: blk-wbt-account-flush-requests-correctly.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5235553d821433e1f4fa720fd025d2c4b7ee9994 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Mon, 5 Feb 2018 13:16:56 -0700 Subject: blk-wbt: account flush requests correctly From: Jens Axboe <axboe(a)kernel.dk> commit 5235553d821433e1f4fa720fd025d2c4b7ee9994 upstream. Mikulas reported a workload that saw bad performance, and figured out what it was due to various other types of requests being accounted as reads. Flush requests, for instance. Due to the high latency of those, we heavily throttle the writes to keep the latencies in balance. But they really should be accounted as writes. Fix this by checking the exact type of the request. If it's a read, account as a read, if it's a write or a flush, account as a write. Any other request we disregard. Previously everything would have been mistakenly accounted as reads. Reported-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-wbt.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -697,7 +697,15 @@ u64 wbt_default_latency_nsec(struct requ static int wbt_data_dir(const struct request *rq) { - return rq_data_dir(rq); + const int op = req_op(rq); + + if (op == REQ_OP_READ) + return READ; + else if (op == REQ_OP_WRITE || op == REQ_OP_FLUSH) + return WRITE; + + /* don't account */ + return -1; } int wbt_init(struct request_queue *q) Patches currently in stable-queue which might be from axboe(a)kernel.dk are queue-4.15/blk-wbt-account-flush-requests-correctly.patch

7 years, 4 months

1
0
0 0

Patch "arm64: proc: Set PTE_NG for table entries to avoid traversing them twice" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: proc: Set PTE_NG for table entries to avoid traversing them twice to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-proc-set-pte_ng-for-table-entries-to-avoid-traversing-them-twice.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd Mon Sep 17 00:00:00 2001 From: Will Deacon <will.deacon(a)arm.com> Date: Tue, 13 Feb 2018 13:14:09 +0000 Subject: arm64: proc: Set PTE_NG for table entries to avoid traversing them twice From: Will Deacon <will.deacon(a)arm.com> commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream. When KASAN is enabled, the swapper page table contains many identical mappings of the zero page, which can lead to a stall during boot whilst the G -> nG code continually walks the same page table entries looking for global mappings. This patch sets the nG bit (bit 11, which is IGNORED) in table entries after processing the subtree so we can easily skip them if we see them a second time. Tested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/mm/proc.S | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -189,7 +189,8 @@ ENDPROC(idmap_cpu_replace_ttbr1) dc cvac, cur_\()\type\()p // Ensure any existing dirty dmb sy // lines are written back before ldr \type, [cur_\()\type\()p] // loading the entry - tbz \type, #0, next_\()\type // Skip invalid entries + tbz \type, #0, skip_\()\type // Skip invalid and + tbnz \type, #11, skip_\()\type // non-global entries .endm .macro __idmap_kpti_put_pgtable_ent_ng, type @@ -249,8 +250,9 @@ ENTRY(idmap_kpti_install_ng_mappings) add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8) do_pgd: __idmap_kpti_get_pgtable_ent pgd tbnz pgd, #1, walk_puds - __idmap_kpti_put_pgtable_ent_ng pgd next_pgd: + __idmap_kpti_put_pgtable_ent_ng pgd +skip_pgd: add cur_pgdp, cur_pgdp, #8 cmp cur_pgdp, end_pgdp b.ne do_pgd @@ -278,8 +280,9 @@ walk_puds: add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8) do_pud: __idmap_kpti_get_pgtable_ent pud tbnz pud, #1, walk_pmds - __idmap_kpti_put_pgtable_ent_ng pud next_pud: + __idmap_kpti_put_pgtable_ent_ng pud +skip_pud: add cur_pudp, cur_pudp, 8 cmp cur_pudp, end_pudp b.ne do_pud @@ -298,8 +301,9 @@ walk_pmds: add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8) do_pmd: __idmap_kpti_get_pgtable_ent pmd tbnz pmd, #1, walk_ptes - __idmap_kpti_put_pgtable_ent_ng pmd next_pmd: + __idmap_kpti_put_pgtable_ent_ng pmd +skip_pmd: add cur_pmdp, cur_pmdp, #8 cmp cur_pmdp, end_pmdp b.ne do_pmd @@ -317,7 +321,7 @@ walk_ptes: add end_ptep, cur_ptep, #(PTRS_PER_PTE * 8) do_pte: __idmap_kpti_get_pgtable_ent pte __idmap_kpti_put_pgtable_ent_ng pte -next_pte: +skip_pte: add cur_ptep, cur_ptep, #8 cmp cur_ptep, end_ptep b.ne do_pte Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.15/nospec-move-array_index_nospec-parameter-checking-into-separate-macro.patch queue-4.15/arm64-proc-set-pte_ng-for-table-entries-to-avoid-traversing-them-twice.patch queue-4.15/x86-mm-rename-flush_tlb_single-and-flush_tlb_one-to-__flush_tlb_one_.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute From: Kirill Marinushkin <k.marinushkin(a)gmail.com> commit 447cae58cecd69392b74a4a42cd0ab9cabd816af upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/mixer.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_m int validx, int *value_ret) { struct snd_usb_audio *chip = cval->head.mixer->chip; - unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = uac2_ctl_value_size(cval->val_type); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -390,16 +393,17 @@ error: val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; } Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are queue-4.15/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 Mon Sep 17 00:00:00 2001 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Date: Fri, 9 Feb 2018 16:51:36 +0200 Subject: ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 upstream. Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/pcm.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -357,6 +357,15 @@ static int set_sync_ep_implicit_fb_quirk alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x1397, 0x0002): + ep = 0x81; + iface = usb_ifnum_to_if(dev, 1); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; } if (attr == USB_ENDPOINT_SYNC_ASYNC && Patches currently in stable-queue which might be from lassi.ylikojola(a)gmail.com are queue-4.15/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb: add more device quirks for USB DSD devices" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb: add more device quirks for USB DSD devices to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7c74866baef1827e18f8269aec85030063520bd4 Mon Sep 17 00:00:00 2001 From: Daniel Mack <daniel(a)zonque.org> Date: Sun, 11 Feb 2018 09:50:27 -0400 Subject: ALSA: usb: add more device quirks for USB DSD devices From: Daniel Mack <daniel(a)zonque.org> commit 7c74866baef1827e18f8269aec85030063520bd4 upstream. Add some more devices that need quirks to handle DSD modes correctly. Signed-off-by: Daniel Mack <daniel(a)zonque.org> Reported-and-tested-by: Thomas Gresens <tgresens(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/quirks.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1363,8 +1363,11 @@ u64 snd_usb_interface_dsd_format_quirks( return SNDRV_PCM_FMTBIT_DSD_U32_BE; break; - /* Amanero Combo384 USB interface with native DSD support */ - case USB_ID(0x16d0, 0x071a): + /* Amanero Combo384 USB based DACs with native DSD support */ + case USB_ID(0x16d0, 0x071a): /* Amanero - Combo384 */ + case USB_ID(0x2ab6, 0x0004): /* T+A DAC8DSD-V2.0, MP1000E-V2.0, MP2000R-V2.0, MP2500R-V2.0, MP3100HV-V2.0 */ + case USB_ID(0x2ab6, 0x0005): /* T+A USB HD Audio 1 */ + case USB_ID(0x2ab6, 0x0006): /* T+A USB HD Audio 2 */ if (fp->altsetting == 2) { switch (le16_to_cpu(chip->dev->descriptor.bcdDevice)) { case 0x199: Patches currently in stable-queue which might be from daniel(a)zonque.org are queue-4.15/alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: seq: Fix racy pool initializations" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix racy pool initializations to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-racy-pool-initializations.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d15d662e89fc667b90cd294b0eb45694e33144da Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Feb 2018 15:20:51 +0100 Subject: ALSA: seq: Fix racy pool initializations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 <long7573(a)126.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -1003,7 +1003,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1018,11 +1018,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.15/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch queue-4.15/alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch queue-4.15/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch queue-4.15/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch queue-4.15/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.15/alsa-seq-fix-racy-pool-initializations.patch queue-4.15/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch queue-4.15/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek: PCI quirk for Fujitsu U7x7" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 Mon Sep 17 00:00:00 2001 From: Jan-Marek Glogowski <glogow(a)fbihome.de> Date: Wed, 14 Feb 2018 11:29:15 +0100 Subject: ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 From: Jan-Marek Glogowski <glogow(a)fbihome.de> commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 upstream. These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by: Jan-Marek Glogowski <glogow(a)fbihome.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3378,6 +3378,19 @@ static void alc269_fixup_pincfg_no_hp_to spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; } +static void alc269_fixup_pincfg_U7x7_headset_mic(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + unsigned int cfg_headphone = snd_hda_codec_get_pincfg(codec, 0x21); + unsigned int cfg_headset_mic = snd_hda_codec_get_pincfg(codec, 0x19); + + if (cfg_headphone && cfg_headset_mic == 0x411111f0) + snd_hda_codec_set_pincfg(codec, 0x19, + (cfg_headphone & ~AC_DEFCFG_DEVICE) | + (AC_JACK_MIC_IN << AC_DEFCFG_DEVICE_SHIFT)); +} + static void alc269_fixup_hweq(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -5251,6 +5264,7 @@ enum { ALC269_FIXUP_LIFEBOOK_EXTMIC, ALC269_FIXUP_LIFEBOOK_HP_PIN, ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT, + ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC, ALC269_FIXUP_AMIC, ALC269_FIXUP_DMIC, ALC269VB_FIXUP_AMIC, @@ -5457,6 +5471,10 @@ static const struct hda_fixup alc269_fix .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_pincfg_no_hp_to_lineout, }, + [ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_pincfg_U7x7_headset_mic, + }, [ALC269_FIXUP_AMIC] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { @@ -6331,6 +6349,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT), SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN), SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", ALC269_FIXUP_LIFEBOOK_HP_PIN), + SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC), SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", ALC269_FIXUP_LIFEBOOK_EXTMIC), SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", ALC700_FIXUP_INTEL_REFERENCE), SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", ALC269_FIXUP_INV_DMIC), Patches currently in stable-queue which might be from glogow(a)fbihome.de are queue-4.15/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d Mon Sep 17 00:00:00 2001 From: Kailang Yang <kailang(a)realtek.com> Date: Fri, 2 Feb 2018 15:26:46 +0800 Subject: ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform From: Kailang Yang <kailang(a)realtek.com> commit 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d upstream. Thinkpad Dock device support for ALC298 platform. It need to use SSID for the quirk table. Because IdeaPad also has ALC298 platform. Use verb for the quirk table will confuse. Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4850,6 +4850,28 @@ static void alc_fixup_tpt440_dock(struct } } +static void alc_fixup_tpt470_dock(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + static const struct hda_pintbl pincfgs[] = { + { 0x17, 0x21211010 }, /* dock headphone */ + { 0x19, 0x21a11010 }, /* dock mic */ + { } + }; + struct alc_spec *spec = codec->spec; + + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x17, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x19, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + snd_hda_apply_pincfgs(codec, pincfgs); + } +} + static void alc_shutup_dell_xps13(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; @@ -5324,6 +5346,7 @@ enum { ALC700_FIXUP_INTEL_REFERENCE, ALC274_FIXUP_DELL_BIND_DACS, ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, + ALC298_FIXUP_TPT470_DOCK, }; static const struct hda_fixup alc269_fixups[] = { @@ -6149,6 +6172,12 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id = ALC274_FIXUP_DELL_BIND_DACS }, + [ALC298_FIXUP_TPT470_DOCK] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_tpt470_dock, + .chained = true, + .chain_id = ALC293_FIXUP_LENOVO_SPK_NOISE + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6330,8 +6359,16 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x2218, "Thinkpad X1 Carbon 2nd", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x2231, "Thinkpad T560", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x2245, "Thinkpad T470", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2246, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2247, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224b, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION), @@ -6352,7 +6389,12 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x5050, "Thinkpad T560p", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5051, "Thinkpad L460", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5053, "Thinkpad T460", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x505d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x505f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x5062, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */ Patches currently in stable-queue which might be from kailang(a)realtek.com are queue-4.15/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.15/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek - Add headset mode support for Dell laptop" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek - Add headset mode support for Dell laptop to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40e2c4e5a7efcd50983aacbddd3c617e776018bf Mon Sep 17 00:00:00 2001 From: Kailang Yang <kailang(a)realtek.com> Date: Fri, 2 Feb 2018 15:13:09 +0800 Subject: ALSA: hda/realtek - Add headset mode support for Dell laptop From: Kailang Yang <kailang(a)realtek.com> commit 40e2c4e5a7efcd50983aacbddd3c617e776018bf upstream. This platform had two Dmic and single Dmic. This update was for single Dmic. This commit was for two Dmic. Fixes: 75ee94b20b46 ("ALSA: hda - fix headset mic problem for Dell machines...") Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6199,6 +6199,8 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME), SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE), + SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB), + SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB), SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), Patches currently in stable-queue which might be from kailang(a)realtek.com are queue-4.15/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.15/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch

7 years, 4 months

1
0
0 0

Patch "9p/trans_virtio: discard zero-length reply" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 9p/trans_virtio: discard zero-length reply to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: 9p-trans_virtio-discard-zero-length-reply.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 26d99834f89e76514076d9cd06f61e56e6a509b8 Mon Sep 17 00:00:00 2001 From: Greg Kurz <groug(a)kaod.org> Date: Mon, 22 Jan 2018 22:02:05 +0100 Subject: 9p/trans_virtio: discard zero-length reply From: Greg Kurz <groug(a)kaod.org> commit 26d99834f89e76514076d9cd06f61e56e6a509b8 upstream. When a 9p request is successfully flushed, the server is expected to just mark it as used without sending a 9p reply (ie, without writing data into the buffer). In this case, virtqueue_get_buf() will return len == 0 and we must not report a REQ_STATUS_RCVD status to the client, otherwise the client will erroneously assume the request has not been flushed. Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kurz <groug(a)kaod.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/trans_virtio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -160,7 +160,8 @@ static void req_done(struct virtqueue *v spin_unlock_irqrestore(&chan->lock, flags); /* Wakeup if anyone waiting for VirtIO ring space. */ wake_up(chan->vc_wq); - p9_client_cb(chan->client, req, REQ_STATUS_RCVD); + if (len) + p9_client_cb(chan->client, req, REQ_STATUS_RCVD); } } Patches currently in stable-queue which might be from groug(a)kaod.org are queue-4.15/9p-trans_virtio-discard-zero-length-reply.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda - Fix headset mic detection problem for two Dell machines" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Fix headset mic detection problem for two Dell machines to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3f2f7c553d077be6a30cb96b2976a2c940bf5335 Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Mon, 29 Jan 2018 14:23:15 +0800 Subject: ALSA: hda - Fix headset mic detection problem for two Dell machines From: Hui Wang <hui.wang(a)canonical.com> commit 3f2f7c553d077be6a30cb96b2976a2c940bf5335 upstream. One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6613,6 +6613,11 @@ static const struct snd_hda_pin_quirk al {0x14, 0x90170110}, {0x21, 0x02211020}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0x90a60130}, + {0x14, 0x90170110}, + {0x14, 0x01011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS", ALC256_FIXUP_ASUS_MIC, {0x14, 0x90170110}, @@ -6681,6 +6686,10 @@ static const struct snd_hda_pin_quirk al {0x12, 0x90a60120}, {0x14, 0x90170110}, {0x21, 0x0321101f}), + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0290, 0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC290_STANDARD_PINS, {0x15, 0x04211040}, Patches currently in stable-queue which might be from hui.wang(a)canonical.com are queue-4.15/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch

7 years, 4 months

1
0
0 0

Patch "xprtrdma: Fix calculation of ri_max_send_sges" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xprtrdma: Fix calculation of ri_max_send_sges to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xprtrdma-fix-calculation-of-ri_max_send_sges.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1179e2c27efe21167ec9d882b14becefba2ee990 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Wed, 31 Jan 2018 12:34:05 -0500 Subject: xprtrdma: Fix calculation of ri_max_send_sges From: Chuck Lever <chuck.lever(a)oracle.com> commit 1179e2c27efe21167ec9d882b14becefba2ee990 upstream. Commit 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") introduced the rpcrdma_ia::ri_max_send_sges field. This fixes a problem where xprtrdma would not work if the device's max_sge capability was small (low single digits). At least RPCRDMA_MIN_SEND_SGES are needed for the inline parts of each RPC. ri_max_send_sges is set to this value: ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES; Then when marshaling each RPC, rpcrdma_args_inline uses that value to determine whether the device has enough Send SGEs to convey an NFS WRITE payload inline, or whether instead a Read chunk is required. More recently, commit ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments") used the ri_max_send_sges value to calculate the size of an array, but that commit erroneously assumed ri_max_send_sges contains a value similar to the device's max_sge, and not one that was reduced by the minimum SGE count. This assumption results in the calculated size of the sendctx's Send SGE array to be too small. When the array is used to marshal an RPC, the code can write Send SGEs into the following sendctx element in that array, corrupting it. When the device's max_sge is large, this issue is entirely harmless; but it results in an oops in the provider's post_send method, if dev.attrs.max_sge is small. So let's straighten this out: ri_max_send_sges will now contain a value with the same meaning as dev.attrs.max_sge, which makes the code easier to understand, and enables rpcrdma_sendctx_create to calculate the size of the SGE array correctly. Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Fixes: 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Tested-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Cc: stable(a)vger.kernel.org # v4.10+ Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtrdma/rpc_rdma.c | 2 +- net/sunrpc/xprtrdma/verbs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -142,7 +142,7 @@ static bool rpcrdma_args_inline(struct r if (xdr->page_len) { remaining = xdr->page_len; offset = offset_in_page(xdr->page_base); - count = 0; + count = RPCRDMA_MIN_SEND_SGES; while (remaining) { remaining -= min_t(unsigned int, PAGE_SIZE - offset, remaining); --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -523,7 +523,7 @@ rpcrdma_ep_create(struct rpcrdma_ep *ep, pr_warn("rpcrdma: HCA provides only %d send SGEs\n", max_sge); return -ENOMEM; } - ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES; + ia->ri_max_send_sges = max_sge; if (ia->ri_device->attrs.max_qp_wr <= RPCRDMA_BACKWARD_WRS) { dprintk("RPC: %s: insufficient wqe's available\n", Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are queue-4.14/xprtrdma-fix-bug-after-a-device-removal.patch queue-4.14/xprtrdma-fix-calculation-of-ri_max_send_sges.patch

7 years, 4 months

1
0
0 0

Patch "xprtrdma: Fix BUG after a device removal" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xprtrdma: Fix BUG after a device removal to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xprtrdma-fix-bug-after-a-device-removal.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89e8d8fcdc6751e86ccad794b052fe67e6ad619 Mon Sep 17 00:00:00 2001 From: Chuck Lever <chuck.lever(a)oracle.com> Date: Wed, 31 Jan 2018 12:34:13 -0500 Subject: xprtrdma: Fix BUG after a device removal From: Chuck Lever <chuck.lever(a)oracle.com> commit e89e8d8fcdc6751e86ccad794b052fe67e6ad619 upstream. Michal Kalderon reports a BUG that occurs just after device removal: [ 169.112490] rpcrdma: removing device qedr0 for 192.168.110.146:20049 [ 169.143909] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 169.181837] IP: rpcrdma_dma_unmap_regbuf+0xa/0x60 [rpcrdma] The RPC/RDMA client transport attempts to allocate some resources on demand. Registered buffers are one such resource. These are allocated (or re-allocated) by xprt_rdma_allocate to hold RPC Call and Reply messages. A hardware resource is associated with each of these buffers, as they can be used for a Send or Receive Work Request. If a device is removed from under an NFS/RDMA mount, the transport layer is responsible for releasing all hardware resources before the device can be finally unplugged. A BUG results when the NFS mount hasn't yet seen much activity: the transport tries to release resources that haven't yet been allocated. rpcrdma_free_regbuf() already checks for this case, so just move that check to cover the DEVICE_REMOVAL case as well. Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA ...") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Tested-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sunrpc/xprtrdma/verbs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -1331,6 +1331,9 @@ __rpcrdma_dma_map_regbuf(struct rpcrdma_ static void rpcrdma_dma_unmap_regbuf(struct rpcrdma_regbuf *rb) { + if (!rb) + return; + if (!rpcrdma_regbuf_is_mapped(rb)) return; @@ -1346,9 +1349,6 @@ rpcrdma_dma_unmap_regbuf(struct rpcrdma_ void rpcrdma_free_regbuf(struct rpcrdma_regbuf *rb) { - if (!rb) - return; - rpcrdma_dma_unmap_regbuf(rb); kfree(rb); } Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are queue-4.14/xprtrdma-fix-bug-after-a-device-removal.patch queue-4.14/xprtrdma-fix-calculation-of-ri_max_send_sges.patch

7 years, 4 months

1
0
0 0

Patch "target/iscsi: avoid NULL dereference in CHAP auth error path" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled target/iscsi: avoid NULL dereference in CHAP auth error path to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce512d79d0466a604793addb6b769d12ee326822 Mon Sep 17 00:00:00 2001 From: David Disseldorp <ddiss(a)suse.de> Date: Wed, 13 Dec 2017 18:22:30 +0100 Subject: target/iscsi: avoid NULL dereference in CHAP auth error path From: David Disseldorp <ddiss(a)suse.de> commit ce512d79d0466a604793addb6b769d12ee326822 upstream. If chap_server_compute_md5() fails early, e.g. via CHAP_N mismatch, then crypto_free_shash() is called with a NULL pointer which gets dereferenced in crypto_shash_tfm(). Fixes: 69110e3cedbb ("iscsi-target: Use shash and ahash") Suggested-by: Markus Elfring <elfring(a)users.sourceforge.net> Signed-off-by: David Disseldorp <ddiss(a)suse.de> Cc: stable(a)vger.kernel.org # 4.6+ Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_auth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/target/iscsi/iscsi_target_auth.c +++ b/drivers/target/iscsi/iscsi_target_auth.c @@ -421,7 +421,8 @@ static int chap_server_compute_md5( auth_ret = 0; out: kzfree(desc); - crypto_free_shash(tfm); + if (tfm) + crypto_free_shash(tfm); kfree(challenge); kfree(challenge_binhex); return auth_ret; Patches currently in stable-queue which might be from ddiss(a)suse.de are queue-4.14/target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch

7 years, 4 months

1
0
0 0

Patch "rtlwifi: rtl8821ae: Fix connection lost problem correctly" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl8821ae: Fix connection lost problem correctly to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c713fb071edc0efc01a955f65a006b0e1795d2eb Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Mon, 5 Feb 2018 12:38:11 -0600 Subject: rtlwifi: rtl8821ae: Fix connection lost problem correctly From: Larry Finger <Larry.Finger(a)lwfinger.net> commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream. There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Tested-by: James Cameron <quozl(a)laptop.org> # x86_64 OLPC NL3 Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1122,7 +1122,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1164,7 +1164,8 @@ static void _rtl8821ae_enable_aspm_back_ } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.14/rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch

7 years, 4 months

1
0
0 0

Patch "qxl: alloc & use shadow for dumb buffers" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled qxl: alloc & use shadow for dumb buffers to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qxl-alloc-use-shadow-for-dumb-buffers.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62676d10b483a2ff6e8b08c5e7c7d63a831343f5 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann <kraxel(a)redhat.com> Date: Thu, 19 Oct 2017 08:21:50 +0200 Subject: qxl: alloc & use shadow for dumb buffers From: Gerd Hoffmann <kraxel(a)redhat.com> commit 62676d10b483a2ff6e8b08c5e7c7d63a831343f5 upstream. This patch changes the way the primary surface is used for dumb framebuffers. Instead of configuring the bo itself as primary surface a shadow bo is created and used instead. Framebuffers can share the shadow bo in case they have the same format and resolution. On atomic plane updates we don't have to update the primary surface in case we pageflip from one framebuffer to another framebuffer which shares the same shadow. This in turn avoids the flicker caused by the primary-destroy + primary-create cycle, which is very annonying when running wayland on qxl. The qxl driver never actually writes to the shadow bo. It sends qxl blit commands which update it though, and the spice server might actually execute them (and thereby write to the shadow) in case the local rendering is kicked for some reason. This happens for example in case qemu is asked to write out a dump of the guest display (screendump monitor command). Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Reviewed-by: Dave Airlie <airlied(a)redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20171019062150.28090-3-kraxel@… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/qxl/qxl_cmd.c | 6 +++- drivers/gpu/drm/qxl/qxl_display.c | 49 +++++++++++++++++++++++++++++++++++--- drivers/gpu/drm/qxl/qxl_drv.h | 2 + drivers/gpu/drm/qxl/qxl_dumb.c | 1 4 files changed, 54 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/qxl/qxl_cmd.c +++ b/drivers/gpu/drm/qxl/qxl_cmd.c @@ -388,7 +388,11 @@ void qxl_io_create_primary(struct qxl_de create->width = bo->surf.width; create->height = bo->surf.height; create->stride = bo->surf.stride; - create->mem = qxl_bo_physical_address(qdev, bo, offset); + if (bo->shadow) { + create->mem = qxl_bo_physical_address(qdev, bo->shadow, offset); + } else { + create->mem = qxl_bo_physical_address(qdev, bo, offset); + } QXL_INFO(qdev, "%s: mem = %llx, from %p\n", __func__, create->mem, bo->kptr); --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -305,7 +305,9 @@ static const struct drm_crtc_funcs qxl_c void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb) { struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb); + struct qxl_bo *bo = gem_to_qxl_bo(qxl_fb->obj); + WARN_ON(bo->shadow); drm_gem_object_unreference_unlocked(qxl_fb->obj); drm_framebuffer_cleanup(fb); kfree(qxl_fb); @@ -508,6 +510,7 @@ static void qxl_primary_atomic_update(st .x2 = qfb->base.width, .y2 = qfb->base.height }; + bool same_shadow = false; if (old_state->fb) { qfb_old = to_qxl_framebuffer(old_state->fb); @@ -519,15 +522,23 @@ static void qxl_primary_atomic_update(st if (bo == bo_old) return; + if (bo_old && bo_old->shadow && bo->shadow && + bo_old->shadow == bo->shadow) { + same_shadow = true; + } + if (bo_old && bo_old->is_primary) { - qxl_io_destroy_primary(qdev); + if (!same_shadow) + qxl_io_destroy_primary(qdev); bo_old->is_primary = false; } if (!bo->is_primary) { - qxl_io_create_primary(qdev, 0, bo); + if (!same_shadow) + qxl_io_create_primary(qdev, 0, bo); bo->is_primary = true; } + qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, &norect, 1, 1); } @@ -681,8 +692,9 @@ static void qxl_cursor_atomic_disable(st static int qxl_plane_prepare_fb(struct drm_plane *plane, struct drm_plane_state *new_state) { + struct qxl_device *qdev = plane->dev->dev_private; struct drm_gem_object *obj; - struct qxl_bo *user_bo; + struct qxl_bo *user_bo, *old_bo = NULL; int ret; if (!new_state->fb) @@ -691,6 +703,32 @@ static int qxl_plane_prepare_fb(struct d obj = to_qxl_framebuffer(new_state->fb)->obj; user_bo = gem_to_qxl_bo(obj); + if (plane->type == DRM_PLANE_TYPE_PRIMARY && + user_bo->is_dumb && !user_bo->shadow) { + if (plane->state->fb) { + obj = to_qxl_framebuffer(plane->state->fb)->obj; + old_bo = gem_to_qxl_bo(obj); + } + if (old_bo && old_bo->shadow && + user_bo->gem_base.size == old_bo->gem_base.size && + plane->state->crtc == new_state->crtc && + plane->state->crtc_w == new_state->crtc_w && + plane->state->crtc_h == new_state->crtc_h && + plane->state->src_x == new_state->src_x && + plane->state->src_y == new_state->src_y && + plane->state->src_w == new_state->src_w && + plane->state->src_h == new_state->src_h && + plane->state->rotation == new_state->rotation && + plane->state->zpos == new_state->zpos) { + drm_gem_object_get(&old_bo->shadow->gem_base); + user_bo->shadow = old_bo->shadow; + } else { + qxl_bo_create(qdev, user_bo->gem_base.size, + true, true, QXL_GEM_DOMAIN_VRAM, NULL, + &user_bo->shadow); + } + } + ret = qxl_bo_pin(user_bo, QXL_GEM_DOMAIN_CPU, NULL); if (ret) return ret; @@ -715,6 +753,11 @@ static void qxl_plane_cleanup_fb(struct obj = to_qxl_framebuffer(old_state->fb)->obj; user_bo = gem_to_qxl_bo(obj); qxl_bo_unpin(user_bo); + + if (user_bo->shadow && !user_bo->is_primary) { + drm_gem_object_put_unlocked(&user_bo->shadow->gem_base); + user_bo->shadow = NULL; + } } static const uint32_t qxl_cursor_plane_formats[] = { --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -113,6 +113,8 @@ struct qxl_bo { /* Constant after initialization */ struct drm_gem_object gem_base; bool is_primary; /* is this now a primary surface */ + bool is_dumb; + struct qxl_bo *shadow; bool hw_surf_alloc; struct qxl_surface surf; uint32_t surface_id; --- a/drivers/gpu/drm/qxl/qxl_dumb.c +++ b/drivers/gpu/drm/qxl/qxl_dumb.c @@ -63,6 +63,7 @@ int qxl_mode_dumb_create(struct drm_file &handle); if (r) return r; + qobj->is_dumb = true; args->pitch = pitch; args->handle = handle; return 0; Patches currently in stable-queue which might be from kraxel(a)redhat.com are queue-4.14/drm-qxl-reapply-cursor-after-resetting-primary.patch queue-4.14/qxl-alloc-use-shadow-for-dumb-buffers.patch

7 years, 4 months

1
0
0 0

Patch "mvpp2: fix multicast address filter" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mvpp2: fix multicast address filter to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mvpp2-fix-multicast-address-filter.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Sun, 11 Feb 2018 18:10:28 -0500 Subject: mvpp2: fix multicast address filter From: Mikulas Patocka <mpatocka(a)redhat.com> commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream. IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/marvell/mvpp2.c +++ b/drivers/net/ethernet/marvell/mvpp2.c @@ -6888,6 +6888,7 @@ static void mvpp2_set_rx_mode(struct net int id = port->id; bool allmulti = dev->flags & IFF_ALLMULTI; +retry: mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti); mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti); @@ -6895,9 +6896,13 @@ static void mvpp2_set_rx_mode(struct net /* Remove all port->id's mcast enries */ mvpp2_prs_mcast_del_all(priv, id); - if (allmulti && !netdev_mc_empty(dev)) { - netdev_for_each_mc_addr(ha, dev) - mvpp2_prs_mac_da_accept(priv, id, ha->addr, true); + if (!allmulti) { + netdev_for_each_mc_addr(ha, dev) { + if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) { + allmulti = true; + goto retry; + } + } } } Patches currently in stable-queue which might be from mpatocka(a)redhat.com are queue-4.14/mvpp2-fix-multicast-address-filter.patch queue-4.14/blk-wbt-account-flush-requests-correctly.patch

7 years, 4 months

1
0
0 0

Patch "mtd: nand: vf610: set correct ooblayout" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: vf610: set correct ooblayout to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-vf610-set-correct-ooblayout.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ea56fb282368ea08c2a313af6b55cb597aec4db1 Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Fri, 9 Feb 2018 13:21:42 +0100 Subject: mtd: nand: vf610: set correct ooblayout From: Stefan Agner <stefan(a)agner.ch> commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream. With commit 3cf32d180227 ("mtd: nand: vf610: switch to mtd_ooblayout_ops") the driver started to use the NAND cores default large page ooblayout. However, shortly after commit 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") changed the default layout to the old hamming layout, which is not what vf610_nfc is using. Specify the default large page layout explicitly. Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout") Cc: <stable(a)vger.kernel.org> # v4.12+ Signed-off-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/vf610_nfc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/mtd/nand/vf610_nfc.c +++ b/drivers/mtd/nand/vf610_nfc.c @@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platfo if (mtd->oobsize > 64) mtd->oobsize = 64; - /* - * mtd->ecclayout is not specified here because we're using the - * default large page ECC layout defined in NAND core. - */ + /* Use default large page ECC layout defined in NAND core */ + mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops); if (chip->ecc.strength == 32) { nfc->ecc_mode = ECC_60_BYTE; chip->ecc.bytes = 60; Patches currently in stable-queue which might be from stefan(a)agner.ch are queue-4.14/mtd-nand-vf610-set-correct-ooblayout.patch

7 years, 4 months

1
0
0 0

Patch "iscsi-target: make sure to wake up sleeping login worker" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iscsi-target: make sure to wake up sleeping login worker to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1c130ae00b769a2e2df41bad3d6051ee8234b636 Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw(a)strlen.de> Date: Fri, 19 Jan 2018 14:36:29 +0100 Subject: iscsi-target: make sure to wake up sleeping login worker From: Florian Westphal <fw(a)strlen.de> commit 1c130ae00b769a2e2df41bad3d6051ee8234b636 upstream. Mike Christie reports: Starting in 4.14 iscsi logins will fail around 50% of the time. Problem appears to be that iscsi_target_sk_data_ready() callback may return without doing anything in case it finds the login work queue is still blocked in sock_recvmsg(). Nicholas Bellinger says: It would indicate users providing their own ->sk_data_ready() callback must be responsible for waking up a kthread context blocked on sock_recvmsg(..., MSG_WAITALL), when a second ->sk_data_ready() is received before the first sock_recvmsg(..., MSG_WAITALL) completes. So, do this and invoke the original data_ready() callback -- in case of tcp sockets this takes care of waking the thread. Disclaimer: I do not understand why this problem did not show up before tcp prequeue removal. (Drop WARN_ON usage - nab) Reported-by: Mike Christie <mchristi(a)redhat.com> Bisected-by: Mike Christie <mchristi(a)redhat.com> Tested-by: Mike Christie <mchristi(a)redhat.com> Diagnosed-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Fixes: e7942d0633c4 ("tcp: remove prequeue support") Signed-off-by: Florian Westphal <fw(a)strlen.de> Cc: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/target/iscsi/iscsi_target_nego.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/target/iscsi/iscsi_target_nego.c +++ b/drivers/target/iscsi/iscsi_target_nego.c @@ -432,6 +432,9 @@ static void iscsi_target_sk_data_ready(s if (test_and_set_bit(LOGIN_FLAGS_READ_ACTIVE, &conn->login_flags)) { write_unlock_bh(&sk->sk_callback_lock); pr_debug("Got LOGIN_FLAGS_READ_ACTIVE=1, conn: %p >>>>\n", conn); + if (iscsi_target_sk_data_ready == conn->orig_data_ready) + return; + conn->orig_data_ready(sk); return; } Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.14/iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch

7 years, 4 months

1
0
0 0

Patch "drm/qxl: reapply cursor after resetting primary" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/qxl: reapply cursor after resetting primary to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-qxl-reapply-cursor-after-resetting-primary.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9428088c90b6f7d5edd2a1b0d742c75339b36f6e Mon Sep 17 00:00:00 2001 From: Ray Strode <rstrode(a)redhat.com> Date: Mon, 27 Nov 2017 16:50:10 -0500 Subject: drm/qxl: reapply cursor after resetting primary From: Ray Strode <rstrode(a)redhat.com> commit 9428088c90b6f7d5edd2a1b0d742c75339b36f6e upstream. QXL associates mouse state with its primary plane. Destroying a primary plane and putting a new one in place has the side effect of destroying the cursor as well. This commit changes the driver to reapply the cursor any time a new primary is created. It achieves this by keeping a reference to the cursor bo on the qxl_crtc struct. This fix is very similar to commit 4532b241a4b7 ("drm/qxl: reapply cursor after SetCrtc calls") which got implicitly reverted as part of implementing the atomic modeset feature. Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Dave Airlie <airlied(a)redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1512097 Fixes: 1277eed5fecb ("drm: qxl: Atomic phase 1: convert cursor to universal plane") Cc: stable(a)vger.kernel.org Signed-off-by: Ray Strode <rstrode(a)redhat.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/qxl/qxl_display.c | 59 ++++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/qxl/qxl_drv.h | 2 + 2 files changed, 61 insertions(+) --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -289,6 +289,7 @@ static void qxl_crtc_destroy(struct drm_ { struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc); + qxl_bo_unref(&qxl_crtc->cursor_bo); drm_crtc_cleanup(crtc); kfree(qxl_crtc); } @@ -495,6 +496,53 @@ static int qxl_primary_atomic_check(stru return 0; } +static int qxl_primary_apply_cursor(struct drm_plane *plane) +{ + struct drm_device *dev = plane->dev; + struct qxl_device *qdev = dev->dev_private; + struct drm_framebuffer *fb = plane->state->fb; + struct qxl_crtc *qcrtc = to_qxl_crtc(plane->state->crtc); + struct qxl_cursor_cmd *cmd; + struct qxl_release *release; + int ret = 0; + + if (!qcrtc->cursor_bo) + return 0; + + ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd), + QXL_RELEASE_CURSOR_CMD, + &release, NULL); + if (ret) + return ret; + + ret = qxl_release_list_add(release, qcrtc->cursor_bo); + if (ret) + goto out_free_release; + + ret = qxl_release_reserve_list(release, false); + if (ret) + goto out_free_release; + + cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release); + cmd->type = QXL_CURSOR_SET; + cmd->u.set.position.x = plane->state->crtc_x + fb->hot_x; + cmd->u.set.position.y = plane->state->crtc_y + fb->hot_y; + + cmd->u.set.shape = qxl_bo_physical_address(qdev, qcrtc->cursor_bo, 0); + + cmd->u.set.visible = 1; + qxl_release_unmap(qdev, release, &cmd->release_info); + + qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + qxl_release_fence_buffer_objects(release); + + return ret; + +out_free_release: + qxl_release_free(qdev, release); + return ret; +} + static void qxl_primary_atomic_update(struct drm_plane *plane, struct drm_plane_state *old_state) { @@ -510,6 +558,7 @@ static void qxl_primary_atomic_update(st .x2 = qfb->base.width, .y2 = qfb->base.height }; + int ret; bool same_shadow = false; if (old_state->fb) { @@ -531,6 +580,11 @@ static void qxl_primary_atomic_update(st if (!same_shadow) qxl_io_destroy_primary(qdev); bo_old->is_primary = false; + + ret = qxl_primary_apply_cursor(plane); + if (ret) + DRM_ERROR( + "could not set cursor after creating primary"); } if (!bo->is_primary) { @@ -571,6 +625,7 @@ static void qxl_cursor_atomic_update(str struct drm_device *dev = plane->dev; struct qxl_device *qdev = dev->dev_private; struct drm_framebuffer *fb = plane->state->fb; + struct qxl_crtc *qcrtc = to_qxl_crtc(plane->state->crtc); struct qxl_release *release; struct qxl_cursor_cmd *cmd; struct qxl_cursor *cursor; @@ -628,6 +683,10 @@ static void qxl_cursor_atomic_update(str cmd->u.set.shape = qxl_bo_physical_address(qdev, cursor_bo, 0); cmd->type = QXL_CURSOR_SET; + + qxl_bo_unref(&qcrtc->cursor_bo); + qcrtc->cursor_bo = cursor_bo; + cursor_bo = NULL; } else { ret = qxl_release_reserve_list(release, true); --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -135,6 +135,8 @@ struct qxl_bo_list { struct qxl_crtc { struct drm_crtc base; int index; + + struct qxl_bo *cursor_bo; }; struct qxl_output { Patches currently in stable-queue which might be from rstrode(a)redhat.com are queue-4.14/drm-qxl-unref-cursor-bo-when-finished-with-it.patch queue-4.14/drm-qxl-reapply-cursor-after-resetting-primary.patch

7 years, 4 months

1
0
0 0

Patch "dm: correctly handle chained bios in dec_pending()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dm: correctly handle chained bios in dec_pending() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dm-correctly-handle-chained-bios-in-dec_pending.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: dm: correctly handle chained bios in dec_pending() From: NeilBrown <neilb(a)suse.com> commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream. dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -815,7 +815,8 @@ static void dec_pending(struct dm_io *io queue_io(md, bio); } else { /* done with normal IO or empty flush */ - bio->bi_status = io_error; + if (io_error) + bio->bi_status = io_error; bio_endio(bio); } } Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.14/dm-correctly-handle-chained-bios-in-dec_pending.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix use-after-free on root->orphan_block_rsv" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix use-after-free on root->orphan_block_rsv to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:54 -0700 Subject: Btrfs: fix use-after-free on root->orphan_block_rsv From: Liu Bo <bo.li.liu(a)oracle.com> commit 1a932ef4e47984dee227834667b5ff5a334e4805 upstream. I got these from running generic/475, WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs] Call Trace: btrfs_orphan_release_metadata+0x9f/0x200 [btrfs] btrfs_orphan_del+0x10d/0x170 [btrfs] btrfs_setattr+0x500/0x640 [btrfs] notify_change+0x7ae/0x870 do_truncate+0xca/0x130 vfs_truncate+0x2ee/0x3d0 do_sys_truncate+0xaf/0xf0 SyS_truncate+0xe/0x10 entry_SYSCALL_64_fastpath+0x1f/0x96 The race is between btrfs_orphan_commit_root and btrfs_orphan_del, t1 t2 btrfs_orphan_commit_root btrfs_orphan_del spin_lock check (&root->orphan_inodes) root->orphan_block_rsv = NULL; spin_unlock atomic_dec(&root->orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3371,6 +3371,11 @@ int btrfs_orphan_add(struct btrfs_trans_ ret = btrfs_orphan_reserve_metadata(trans, inode); ASSERT(!ret); if (ret) { + /* + * dec doesn't need spin_lock as ->orphan_block_rsv + * would be released only if ->orphan_inodes is + * zero. + */ atomic_dec(&root->orphan_inodes); clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3385,12 +3390,17 @@ int btrfs_orphan_add(struct btrfs_trans_ if (insert >= 1) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); if (ret) { - atomic_dec(&root->orphan_inodes); if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); btrfs_orphan_release_metadata(inode); } + /* + * btrfs_orphan_commit_root may race with us and set + * ->orphan_block_rsv to zero, in order to avoid that, + * decrease ->orphan_inodes after everything is done. + */ + atomic_dec(&root->orphan_inodes); if (ret != -EEXIST) { clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags); @@ -3422,28 +3432,26 @@ static int btrfs_orphan_del(struct btrfs { struct btrfs_root *root = inode->root; int delete_item = 0; - int release_rsv = 0; int ret = 0; - spin_lock(&root->orphan_lock); if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags)) delete_item = 1; + if (delete_item && trans) + ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode)); + if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags)) - release_rsv = 1; - spin_unlock(&root->orphan_lock); + btrfs_orphan_release_metadata(inode); - if (delete_item) { + /* + * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv + * to zero, in order to avoid that, decrease ->orphan_inodes after + * everything is done. + */ + if (delete_item) atomic_dec(&root->orphan_inodes); - if (trans) - ret = btrfs_del_orphan_item(trans, root, - btrfs_ino(inode)); - } - - if (release_rsv) - btrfs_orphan_release_metadata(inode); return ret; } Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix unexpected -EEXIST when creating new inode" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix unexpected -EEXIST when creating new inode to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-unexpected-eexist-when-creating-new-inode.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:56 -0700 Subject: Btrfs: fix unexpected -EEXIST when creating new inode From: Liu Bo <bo.li.liu(a)oracle.com> commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream. The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: <stable(a)vger.kernel.org> v4.4-rc6+ Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -28,6 +28,7 @@ #include "hash.h" #include "compression.h" #include "qgroup.h" +#include "inode-map.h" /* magic values for the inode_only field in btrfs_log_inode: * @@ -5715,6 +5716,23 @@ again: path); } + if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) { + struct btrfs_root *root = wc.replay_dest; + + btrfs_release_path(path); + + /* + * We have just replayed everything, and the highest + * objectid of fs roots probably has changed in case + * some inode_item's got replayed. + * + * root->objectid_mutex is not acquired as log replay + * could only happen during mount. + */ + ret = btrfs_find_highest_objectid(root, + &root->highest_objectid); + } + key.offset = found_key.offset - 1; wc.replay_dest->log_root = NULL; free_extent_buffer(log->node); Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix extent state leak from tree log" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix extent state leak from tree log to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-extent-state-leak-from-tree-log.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 55237a5f2431a72435e3ed39e4306e973c0446b7 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:52 -0700 Subject: Btrfs: fix extent state leak from tree log From: Liu Bo <bo.li.liu(a)oracle.com> commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream. It's possible that btrfs_sync_log() bails out after one of the two btrfs_write_marked_extents() which convert extent state's state bit into EXTENT_NEED_WAIT from EXTENT_DIRTY/EXTENT_NEW, however only EXTENT_DIRTY and EXTENT_NEW are searched by free_log_tree() so that those extent states with EXTENT_NEED_WAIT lead to memory leak. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -3047,13 +3047,14 @@ static void free_log_tree(struct btrfs_t while (1) { ret = find_first_extent_bit(&log->dirty_log_pages, - 0, &start, &end, EXTENT_DIRTY | EXTENT_NEW, + 0, &start, &end, + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT, NULL); if (ret) break; clear_extent_bits(&log->dirty_log_pages, start, end, - EXTENT_DIRTY | EXTENT_NEW); + EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT); } /* Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix crash due to not cleaning up tree log block's dirty bits" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix crash due to not cleaning up tree log block's dirty bits to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:51 -0700 Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits From: Liu Bo <bo.li.liu(a)oracle.com> commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2494,6 +2494,9 @@ static noinline int walk_down_log_tree(s clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != @@ -2574,6 +2577,9 @@ static noinline int walk_up_log_tree(str clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID); @@ -2652,6 +2658,9 @@ static int walk_log_tree(struct btrfs_tr clean_tree_block(fs_info, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(log->root_key.objectid != Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix deadlock in run_delalloc_nocow" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix deadlock in run_delalloc_nocow to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-in-run_delalloc_nocow.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:50 -0700 Subject: Btrfs: fix deadlock in run_delalloc_nocow From: Liu Bo <bo.li.liu(a)oracle.com> commit e89166990f11c3f21e1649d760dd35f9e410321c upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1330,8 +1330,11 @@ next_slot: leaf = path->nodes[0]; if (path->slots[0] >= btrfs_header_nritems(leaf)) { ret = btrfs_next_leaf(root, path); - if (ret < 0) + if (ret < 0) { + if (cow_start != (u64)-1) + cur_offset = cow_start; goto error; + } if (ret > 0) break; leaf = path->nodes[0]; Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e8f1bc1493855e32b7a2a019decc3c353d94daf6 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:53 -0700 Subject: Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly From: Liu Bo <bo.li.liu(a)oracle.com> commit e8f1bc1493855e32b7a2a019decc3c353d94daf6 upstream. This regression is introduced in commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction"). There are two problems, a) it is ->destroy_inode() that does the final free on inode, not ->evict_inode(), b) clear_inode() must be called before ->evict_inode() returns. This could end up hitting BUG_ON(inode->i_state != (I_FREEING | I_CLEAR)); in evict() because I_CLEAR is set in clear_inode(). Fixes: commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction") Cc: <stable(a)vger.kernel.org> # v4.7-rc6+ Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5318,7 +5318,7 @@ void btrfs_evict_inode(struct inode *ino trace_btrfs_inode_evict(inode); if (!root) { - kmem_cache_free(btrfs_inode_cachep, BTRFS_I(inode)); + clear_inode(inode); return; } Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-4.14/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch queue-4.14/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-4.14/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch queue-4.14/btrfs-fix-extent-state-leak-from-tree-log.patch queue-4.14/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch queue-4.14/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "blk-wbt: account flush requests correctly" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-wbt: account flush requests correctly to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: blk-wbt-account-flush-requests-correctly.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5235553d821433e1f4fa720fd025d2c4b7ee9994 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Mon, 5 Feb 2018 13:16:56 -0700 Subject: blk-wbt: account flush requests correctly From: Jens Axboe <axboe(a)kernel.dk> commit 5235553d821433e1f4fa720fd025d2c4b7ee9994 upstream. Mikulas reported a workload that saw bad performance, and figured out what it was due to various other types of requests being accounted as reads. Flush requests, for instance. Due to the high latency of those, we heavily throttle the writes to keep the latencies in balance. But they really should be accounted as writes. Fix this by checking the exact type of the request. If it's a read, account as a read, if it's a write or a flush, account as a write. Any other request we disregard. Previously everything would have been mistakenly accounted as reads. Reported-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-wbt.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -698,7 +698,15 @@ u64 wbt_default_latency_nsec(struct requ static int wbt_data_dir(const struct request *rq) { - return rq_data_dir(rq); + const int op = req_op(rq); + + if (op == REQ_OP_READ) + return READ; + else if (op == REQ_OP_WRITE || op == REQ_OP_FLUSH) + return WRITE; + + /* don't account */ + return -1; } int wbt_init(struct request_queue *q) Patches currently in stable-queue which might be from axboe(a)kernel.dk are queue-4.14/blk-wbt-account-flush-requests-correctly.patch

7 years, 4 months

1
0
0 0

Patch "arm64: proc: Set PTE_NG for table entries to avoid traversing them twice" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: proc: Set PTE_NG for table entries to avoid traversing them twice to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-proc-set-pte_ng-for-table-entries-to-avoid-traversing-them-twice.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd Mon Sep 17 00:00:00 2001 From: Will Deacon <will.deacon(a)arm.com> Date: Tue, 13 Feb 2018 13:14:09 +0000 Subject: arm64: proc: Set PTE_NG for table entries to avoid traversing them twice From: Will Deacon <will.deacon(a)arm.com> commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream. When KASAN is enabled, the swapper page table contains many identical mappings of the zero page, which can lead to a stall during boot whilst the G -> nG code continually walks the same page table entries looking for global mappings. This patch sets the nG bit (bit 11, which is IGNORED) in table entries after processing the subtree so we can easily skip them if we see them a second time. Tested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/mm/proc.S | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -190,7 +190,8 @@ ENDPROC(idmap_cpu_replace_ttbr1) dc cvac, cur_\()\type\()p // Ensure any existing dirty dmb sy // lines are written back before ldr \type, [cur_\()\type\()p] // loading the entry - tbz \type, #0, next_\()\type // Skip invalid entries + tbz \type, #0, skip_\()\type // Skip invalid and + tbnz \type, #11, skip_\()\type // non-global entries .endm .macro __idmap_kpti_put_pgtable_ent_ng, type @@ -249,8 +250,9 @@ ENTRY(idmap_kpti_install_ng_mappings) add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8) do_pgd: __idmap_kpti_get_pgtable_ent pgd tbnz pgd, #1, walk_puds - __idmap_kpti_put_pgtable_ent_ng pgd next_pgd: + __idmap_kpti_put_pgtable_ent_ng pgd +skip_pgd: add cur_pgdp, cur_pgdp, #8 cmp cur_pgdp, end_pgdp b.ne do_pgd @@ -278,8 +280,9 @@ walk_puds: add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8) do_pud: __idmap_kpti_get_pgtable_ent pud tbnz pud, #1, walk_pmds - __idmap_kpti_put_pgtable_ent_ng pud next_pud: + __idmap_kpti_put_pgtable_ent_ng pud +skip_pud: add cur_pudp, cur_pudp, 8 cmp cur_pudp, end_pudp b.ne do_pud @@ -298,8 +301,9 @@ walk_pmds: add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8) do_pmd: __idmap_kpti_get_pgtable_ent pmd tbnz pmd, #1, walk_ptes - __idmap_kpti_put_pgtable_ent_ng pmd next_pmd: + __idmap_kpti_put_pgtable_ent_ng pmd +skip_pmd: add cur_pmdp, cur_pmdp, #8 cmp cur_pmdp, end_pmdp b.ne do_pmd @@ -317,7 +321,7 @@ walk_ptes: add end_ptep, cur_ptep, #(PTRS_PER_PTE * 8) do_pte: __idmap_kpti_get_pgtable_ent pte __idmap_kpti_put_pgtable_ent_ng pte -next_pte: +skip_pte: add cur_ptep, cur_ptep, #8 cmp cur_ptep, end_ptep b.ne do_pte Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.14/nospec-move-array_index_nospec-parameter-checking-into-separate-macro.patch queue-4.14/arm64-proc-set-pte_ng-for-table-entries-to-avoid-traversing-them-twice.patch queue-4.14/x86-mm-rename-flush_tlb_single-and-flush_tlb_one-to-__flush_tlb_one_.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute From: Kirill Marinushkin <k.marinushkin(a)gmail.com> commit 447cae58cecd69392b74a4a42cd0ab9cabd816af upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/mixer.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_m int validx, int *value_ret) { struct snd_usb_audio *chip = cval->head.mixer->chip; - unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = uac2_ctl_value_size(cval->val_type); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -390,16 +393,17 @@ error: val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; } Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are queue-4.14/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 Mon Sep 17 00:00:00 2001 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Date: Fri, 9 Feb 2018 16:51:36 +0200 Subject: ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204 From: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 upstream. Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by: Lassi Ylikojola <lassi.ylikojola(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/pcm.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -357,6 +357,15 @@ static int set_sync_ep_implicit_fb_quirk alts = &iface->altsetting[1]; goto add_sync_ep; + case USB_ID(0x1397, 0x0002): + ep = 0x81; + iface = usb_ifnum_to_if(dev, 1); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; } if (attr == USB_ENDPOINT_SYNC_ASYNC && Patches currently in stable-queue which might be from lassi.ylikojola(a)gmail.com are queue-4.14/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb: add more device quirks for USB DSD devices" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb: add more device quirks for USB DSD devices to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7c74866baef1827e18f8269aec85030063520bd4 Mon Sep 17 00:00:00 2001 From: Daniel Mack <daniel(a)zonque.org> Date: Sun, 11 Feb 2018 09:50:27 -0400 Subject: ALSA: usb: add more device quirks for USB DSD devices From: Daniel Mack <daniel(a)zonque.org> commit 7c74866baef1827e18f8269aec85030063520bd4 upstream. Add some more devices that need quirks to handle DSD modes correctly. Signed-off-by: Daniel Mack <daniel(a)zonque.org> Reported-and-tested-by: Thomas Gresens <tgresens(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/quirks.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1369,8 +1369,11 @@ u64 snd_usb_interface_dsd_format_quirks( return SNDRV_PCM_FMTBIT_DSD_U32_BE; break; - /* Amanero Combo384 USB interface with native DSD support */ - case USB_ID(0x16d0, 0x071a): + /* Amanero Combo384 USB based DACs with native DSD support */ + case USB_ID(0x16d0, 0x071a): /* Amanero - Combo384 */ + case USB_ID(0x2ab6, 0x0004): /* T+A DAC8DSD-V2.0, MP1000E-V2.0, MP2000R-V2.0, MP2500R-V2.0, MP3100HV-V2.0 */ + case USB_ID(0x2ab6, 0x0005): /* T+A USB HD Audio 1 */ + case USB_ID(0x2ab6, 0x0006): /* T+A USB HD Audio 2 */ if (fp->altsetting == 2) { switch (le16_to_cpu(chip->dev->descriptor.bcdDevice)) { case 0x199: Patches currently in stable-queue which might be from daniel(a)zonque.org are queue-4.14/alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: seq: Fix racy pool initializations" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix racy pool initializations to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-racy-pool-initializations.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d15d662e89fc667b90cd294b0eb45694e33144da Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Feb 2018 15:20:51 +0100 Subject: ALSA: seq: Fix racy pool initializations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 <long7573(a)126.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -999,7 +999,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1014,11 +1014,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.14/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch queue-4.14/alsa-usb-add-more-device-quirks-for-usb-dsd-devices.patch queue-4.14/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch queue-4.14/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch queue-4.14/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.14/alsa-seq-fix-racy-pool-initializations.patch queue-4.14/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch queue-4.14/alsa-usb-audio-add-implicit-fb-quirk-for-behringer-ufx1204.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek: PCI quirk for Fujitsu U7x7" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 Mon Sep 17 00:00:00 2001 From: Jan-Marek Glogowski <glogow(a)fbihome.de> Date: Wed, 14 Feb 2018 11:29:15 +0100 Subject: ALSA: hda/realtek: PCI quirk for Fujitsu U7x7 From: Jan-Marek Glogowski <glogow(a)fbihome.de> commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 upstream. These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by: Jan-Marek Glogowski <glogow(a)fbihome.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3355,6 +3355,19 @@ static void alc269_fixup_pincfg_no_hp_to spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; } +static void alc269_fixup_pincfg_U7x7_headset_mic(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + unsigned int cfg_headphone = snd_hda_codec_get_pincfg(codec, 0x21); + unsigned int cfg_headset_mic = snd_hda_codec_get_pincfg(codec, 0x19); + + if (cfg_headphone && cfg_headset_mic == 0x411111f0) + snd_hda_codec_set_pincfg(codec, 0x19, + (cfg_headphone & ~AC_DEFCFG_DEVICE) | + (AC_JACK_MIC_IN << AC_DEFCFG_DEVICE_SHIFT)); +} + static void alc269_fixup_hweq(struct hda_codec *codec, const struct hda_fixup *fix, int action) { @@ -5228,6 +5241,7 @@ enum { ALC269_FIXUP_LIFEBOOK_EXTMIC, ALC269_FIXUP_LIFEBOOK_HP_PIN, ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT, + ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC, ALC269_FIXUP_AMIC, ALC269_FIXUP_DMIC, ALC269VB_FIXUP_AMIC, @@ -5434,6 +5448,10 @@ static const struct hda_fixup alc269_fix .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_pincfg_no_hp_to_lineout, }, + [ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc269_fixup_pincfg_U7x7_headset_mic, + }, [ALC269_FIXUP_AMIC] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { @@ -6308,6 +6326,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT), SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN), SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", ALC269_FIXUP_LIFEBOOK_HP_PIN), + SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC), SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", ALC269_FIXUP_LIFEBOOK_EXTMIC), SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", ALC700_FIXUP_INTEL_REFERENCE), SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", ALC269_FIXUP_INV_DMIC), Patches currently in stable-queue which might be from glogow(a)fbihome.de are queue-4.14/alsa-hda-realtek-pci-quirk-for-fujitsu-u7x7.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d Mon Sep 17 00:00:00 2001 From: Kailang Yang <kailang(a)realtek.com> Date: Fri, 2 Feb 2018 15:26:46 +0800 Subject: ALSA: hda/realtek - Enable Thinkpad Dock device for ALC298 platform From: Kailang Yang <kailang(a)realtek.com> commit 61fcf8ece9b6b09450250c4ca40cc3b81a96a68d upstream. Thinkpad Dock device support for ALC298 platform. It need to use SSID for the quirk table. Because IdeaPad also has ALC298 platform. Use verb for the quirk table will confuse. Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4827,6 +4827,28 @@ static void alc_fixup_tpt440_dock(struct } } +static void alc_fixup_tpt470_dock(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + static const struct hda_pintbl pincfgs[] = { + { 0x17, 0x21211010 }, /* dock headphone */ + { 0x19, 0x21a11010 }, /* dock mic */ + { } + }; + struct alc_spec *spec = codec->spec; + + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->parse_flags = HDA_PINCFG_NO_HP_FIXUP; + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x17, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + /* Enable DOCK device */ + snd_hda_codec_write(codec, 0x19, 0, + AC_VERB_SET_CONFIG_DEFAULT_BYTES_3, 0); + snd_hda_apply_pincfgs(codec, pincfgs); + } +} + static void alc_shutup_dell_xps13(struct hda_codec *codec) { struct alc_spec *spec = codec->spec; @@ -5301,6 +5323,7 @@ enum { ALC700_FIXUP_INTEL_REFERENCE, ALC274_FIXUP_DELL_BIND_DACS, ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, + ALC298_FIXUP_TPT470_DOCK, }; static const struct hda_fixup alc269_fixups[] = { @@ -6126,6 +6149,12 @@ static const struct hda_fixup alc269_fix .chained = true, .chain_id = ALC274_FIXUP_DELL_BIND_DACS }, + [ALC298_FIXUP_TPT470_DOCK] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_tpt470_dock, + .chained = true, + .chain_id = ALC293_FIXUP_LENOVO_SPK_NOISE + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6307,8 +6336,16 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x2218, "Thinkpad X1 Carbon 2nd", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x222e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x2231, "Thinkpad T560", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x2245, "Thinkpad T470", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2246, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x2247, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224b, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION), @@ -6329,7 +6366,12 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x5050, "Thinkpad T560p", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5051, "Thinkpad L460", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x5053, "Thinkpad T460", ALC292_FIXUP_TPT460), + SND_PCI_QUIRK(0x17aa, 0x505d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x505f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x5062, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), + SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */ Patches currently in stable-queue which might be from kailang(a)realtek.com are queue-4.14/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.14/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda/realtek - Add headset mode support for Dell laptop" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda/realtek - Add headset mode support for Dell laptop to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40e2c4e5a7efcd50983aacbddd3c617e776018bf Mon Sep 17 00:00:00 2001 From: Kailang Yang <kailang(a)realtek.com> Date: Fri, 2 Feb 2018 15:13:09 +0800 Subject: ALSA: hda/realtek - Add headset mode support for Dell laptop From: Kailang Yang <kailang(a)realtek.com> commit 40e2c4e5a7efcd50983aacbddd3c617e776018bf upstream. This platform had two Dmic and single Dmic. This update was for single Dmic. This commit was for two Dmic. Fixes: 75ee94b20b46 ("ALSA: hda - fix headset mic problem for Dell machines...") Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6176,6 +6176,8 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME), SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE), + SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB), + SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB), SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), Patches currently in stable-queue which might be from kailang(a)realtek.com are queue-4.14/alsa-hda-realtek-add-headset-mode-support-for-dell-laptop.patch queue-4.14/alsa-hda-realtek-enable-thinkpad-dock-device-for-alc298-platform.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: hda - Fix headset mic detection problem for two Dell machines" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Fix headset mic detection problem for two Dell machines to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3f2f7c553d077be6a30cb96b2976a2c940bf5335 Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Mon, 29 Jan 2018 14:23:15 +0800 Subject: ALSA: hda - Fix headset mic detection problem for two Dell machines From: Hui Wang <hui.wang(a)canonical.com> commit 3f2f7c553d077be6a30cb96b2976a2c940bf5335 upstream. One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6585,6 +6585,11 @@ static const struct snd_hda_pin_quirk al {0x14, 0x90170110}, {0x21, 0x02211020}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0x90a60130}, + {0x14, 0x90170110}, + {0x14, 0x01011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS", ALC256_FIXUP_ASUS_MIC, {0x14, 0x90170110}, @@ -6653,6 +6658,10 @@ static const struct snd_hda_pin_quirk al {0x12, 0x90a60120}, {0x14, 0x90170110}, {0x21, 0x0321101f}), + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0290, 0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC290_STANDARD_PINS, {0x15, 0x04211040}, Patches currently in stable-queue which might be from hui.wang(a)canonical.com are queue-4.14/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-machines.patch

7 years, 4 months

1
0
0 0

Patch "9p/trans_virtio: discard zero-length reply" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled 9p/trans_virtio: discard zero-length reply to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: 9p-trans_virtio-discard-zero-length-reply.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 26d99834f89e76514076d9cd06f61e56e6a509b8 Mon Sep 17 00:00:00 2001 From: Greg Kurz <groug(a)kaod.org> Date: Mon, 22 Jan 2018 22:02:05 +0100 Subject: 9p/trans_virtio: discard zero-length reply From: Greg Kurz <groug(a)kaod.org> commit 26d99834f89e76514076d9cd06f61e56e6a509b8 upstream. When a 9p request is successfully flushed, the server is expected to just mark it as used without sending a 9p reply (ie, without writing data into the buffer). In this case, virtqueue_get_buf() will return len == 0 and we must not report a REQ_STATUS_RCVD status to the client, otherwise the client will erroneously assume the request has not been flushed. Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kurz <groug(a)kaod.org> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/trans_virtio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -160,7 +160,8 @@ static void req_done(struct virtqueue *v spin_unlock_irqrestore(&chan->lock, flags); /* Wakeup if anyone waiting for VirtIO ring space. */ wake_up(chan->vc_wq); - p9_client_cb(chan->client, req, REQ_STATUS_RCVD); + if (len) + p9_client_cb(chan->client, req, REQ_STATUS_RCVD); } } Patches currently in stable-queue which might be from groug(a)kaod.org are queue-4.14/9p-trans_virtio-discard-zero-length-reply.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix crash due to not cleaning up tree log block's dirty bits" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix crash due to not cleaning up tree log block's dirty bits to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:51 -0700 Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits From: Liu Bo <bo.li.liu(a)oracle.com> commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/tree-log.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2201,6 +2201,9 @@ static noinline int walk_down_log_tree(s clean_tree_block(trans, root, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != @@ -2279,6 +2282,9 @@ static noinline int walk_up_log_tree(str clean_tree_block(trans, root, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID); @@ -2355,6 +2361,9 @@ static int walk_log_tree(struct btrfs_tr clean_tree_block(trans, log, next); btrfs_wait_tree_block_writeback(next); btrfs_tree_unlock(next); + } else { + if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags)) + clear_extent_buffer_dirty(next); } WARN_ON(log->root_key.objectid != Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-3.18/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-3.18/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "Btrfs: fix deadlock in run_delalloc_nocow" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Btrfs: fix deadlock in run_delalloc_nocow to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-deadlock-in-run_delalloc_nocow.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:50 -0700 Subject: Btrfs: fix deadlock in run_delalloc_nocow From: Liu Bo <bo.li.liu(a)oracle.com> commit e89166990f11c3f21e1649d760dd35f9e410321c upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable(a)vger.kernel.org> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1256,8 +1256,11 @@ next_slot: leaf = path->nodes[0]; if (path->slots[0] >= btrfs_header_nritems(leaf)) { ret = btrfs_next_leaf(root, path); - if (ret < 0) + if (ret < 0) { + if (cow_start != (u64)-1) + cur_offset = cow_start; goto error; + } if (ret > 0) break; leaf = path->nodes[0]; Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are queue-3.18/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch queue-3.18/btrfs-fix-deadlock-in-run_delalloc_nocow.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001 From: Kirill Marinushkin <k.marinushkin(a)gmail.com> Date: Mon, 29 Jan 2018 06:37:55 +0100 Subject: ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute From: Kirill Marinushkin <k.marinushkin(a)gmail.com> commit 447cae58cecd69392b74a4a42cd0ab9cabd816af upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/mixer.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -328,17 +328,20 @@ static int get_ctl_value_v2(struct usb_m int validx, int *value_ret) { struct snd_usb_audio *chip = cval->mixer->chip; - unsigned char buf[2 + 3 * sizeof(__u16)]; /* enough space for one range */ + /* enough space for one range */ + unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)]; unsigned char *val; - int idx = 0, ret, size; + int idx = 0, ret, val_size, size; __u8 bRequest; + val_size = uac2_ctl_value_size(cval->val_type); + if (request == UAC_GET_CUR) { bRequest = UAC2_CS_CUR; - size = sizeof(__u16); + size = val_size; } else { bRequest = UAC2_CS_RANGE; - size = sizeof(buf); + size = sizeof(__u16) + 3 * val_size; } memset(buf, 0, sizeof(buf)); @@ -377,16 +380,17 @@ error: val = buf + sizeof(__u16); break; case UAC_GET_MAX: - val = buf + sizeof(__u16) * 2; + val = buf + sizeof(__u16) + val_size; break; case UAC_GET_RES: - val = buf + sizeof(__u16) * 3; + val = buf + sizeof(__u16) + val_size * 2; break; default: return -EINVAL; } - *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16))); + *value_ret = convert_signed_value(cval, + snd_usb_combine_bytes(val, val_size)); return 0; } Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are queue-3.18/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch

7 years, 4 months

1
0
0 0

Patch "ALSA: seq: Fix racy pool initializations" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix racy pool initializations to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-racy-pool-initializations.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d15d662e89fc667b90cd294b0eb45694e33144da Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Feb 2018 15:20:51 +0100 Subject: ALSA: seq: Fix racy pool initializations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 <long7573(a)126.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -1012,7 +1012,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1027,11 +1027,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-3.18/alsa-usb-audio-fix-uac2-get_ctl-request-with-a-range-attribute.patch queue-3.18/alsa-seq-fix-racy-pool-initializations.patch queue-3.18/alsa-seq-fix-regression-by-incorrect-ioctl_mutex-usages.patch

7 years, 4 months

1
0
0 0

[PATCH v2] MIPS: Drop spurious __unused in struct compat_flock

by James Hogan

MIPS' struct compat_flock doesn't match the 32-bit struct flock, as it has an extra short __unused before pad[4], which combined with alignment increases the size to 40 bytes compared with struct flock's 36 bytes. Since commit 8c6657cb50cb ("Switch flock copyin/copyout primitives to copy_{from,to}_user()"), put_compat_flock() writes the full compat_flock struct to userland, which results in corruption of the userland word after the struct flock when running 32-bit userlands on 64-bit kernels. This was observed to cause a bus error exception when starting Firefox on Debian 8 (Jessie). Reported-by: Peter Mamonov <pmamonov(a)gmail.com> Signed-off-by: James Hogan <jhogan(a)kernel.org> Tested-by: Peter Mamonov <pmamonov(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.13+ --- Resend mainly so it lands in patchwork. --- arch/mips/include/asm/compat.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h index 946681db8dc3..9a0fa66b81ac 100644 --- a/arch/mips/include/asm/compat.h +++ b/arch/mips/include/asm/compat.h @@ -86,7 +86,6 @@ struct compat_flock { compat_off_t l_len; s32 l_sysid; compat_pid_t l_pid; - short __unused; s32 pad[4]; }; -- 2.13.6

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:54 -0700 Subject: [PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv I got these from running generic/475, WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs] Call Trace: btrfs_orphan_release_metadata+0x9f/0x200 [btrfs] btrfs_orphan_del+0x10d/0x170 [btrfs] btrfs_setattr+0x500/0x640 [btrfs] notify_change+0x7ae/0x870 do_truncate+0xca/0x130 vfs_truncate+0x2ee/0x3d0 do_sys_truncate+0xaf/0xf0 SyS_truncate+0xe/0x10 entry_SYSCALL_64_fastpath+0x1f/0x96 The race is between btrfs_orphan_commit_root and btrfs_orphan_del, t1 t2 btrfs_orphan_commit_root btrfs_orphan_del spin_lock check (&root->orphan_inodes) root->orphan_block_rsv = NULL; spin_unlock atomic_dec(&root->orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 44a152d8f32f..29b491328f4e 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3387,6 +3387,11 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, ret = btrfs_orphan_reserve_metadata(trans, inode); ASSERT(!ret); if (ret) { + /* + * dec doesn't need spin_lock as ->orphan_block_rsv + * would be released only if ->orphan_inodes is + * zero. + */ atomic_dec(&root->orphan_inodes); clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3401,12 +3406,17 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, if (insert >= 1) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); if (ret) { - atomic_dec(&root->orphan_inodes); if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); btrfs_orphan_release_metadata(inode); } + /* + * btrfs_orphan_commit_root may race with us and set + * ->orphan_block_rsv to zero, in order to avoid that, + * decrease ->orphan_inodes after everything is done. + */ + atomic_dec(&root->orphan_inodes); if (ret != -EEXIST) { clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags); @@ -3438,28 +3448,26 @@ static int btrfs_orphan_del(struct btrfs_trans_handle *trans, { struct btrfs_root *root = inode->root; int delete_item = 0; - int release_rsv = 0; int ret = 0; - spin_lock(&root->orphan_lock); if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags)) delete_item = 1; + if (delete_item && trans) + ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode)); + if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags)) - release_rsv = 1; - spin_unlock(&root->orphan_lock); + btrfs_orphan_release_metadata(inode); - if (delete_item) { + /* + * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv + * to zero, in order to avoid that, decrease ->orphan_inodes after + * everything is done. + */ + if (delete_item) atomic_dec(&root->orphan_inodes); - if (trans) - ret = btrfs_del_orphan_item(trans, root, - btrfs_ino(inode)); - } - - if (release_rsv) - btrfs_orphan_release_metadata(inode); return ret; }

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:54 -0700 Subject: [PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv I got these from running generic/475, WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs] Call Trace: btrfs_orphan_release_metadata+0x9f/0x200 [btrfs] btrfs_orphan_del+0x10d/0x170 [btrfs] btrfs_setattr+0x500/0x640 [btrfs] notify_change+0x7ae/0x870 do_truncate+0xca/0x130 vfs_truncate+0x2ee/0x3d0 do_sys_truncate+0xaf/0xf0 SyS_truncate+0xe/0x10 entry_SYSCALL_64_fastpath+0x1f/0x96 The race is between btrfs_orphan_commit_root and btrfs_orphan_del, t1 t2 btrfs_orphan_commit_root btrfs_orphan_del spin_lock check (&root->orphan_inodes) root->orphan_block_rsv = NULL; spin_unlock atomic_dec(&root->orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 44a152d8f32f..29b491328f4e 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3387,6 +3387,11 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, ret = btrfs_orphan_reserve_metadata(trans, inode); ASSERT(!ret); if (ret) { + /* + * dec doesn't need spin_lock as ->orphan_block_rsv + * would be released only if ->orphan_inodes is + * zero. + */ atomic_dec(&root->orphan_inodes); clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3401,12 +3406,17 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, if (insert >= 1) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); if (ret) { - atomic_dec(&root->orphan_inodes); if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); btrfs_orphan_release_metadata(inode); } + /* + * btrfs_orphan_commit_root may race with us and set + * ->orphan_block_rsv to zero, in order to avoid that, + * decrease ->orphan_inodes after everything is done. + */ + atomic_dec(&root->orphan_inodes); if (ret != -EEXIST) { clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags); @@ -3438,28 +3448,26 @@ static int btrfs_orphan_del(struct btrfs_trans_handle *trans, { struct btrfs_root *root = inode->root; int delete_item = 0; - int release_rsv = 0; int ret = 0; - spin_lock(&root->orphan_lock); if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags)) delete_item = 1; + if (delete_item && trans) + ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode)); + if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags)) - release_rsv = 1; - spin_unlock(&root->orphan_lock); + btrfs_orphan_release_metadata(inode); - if (delete_item) { + /* + * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv + * to zero, in order to avoid that, decrease ->orphan_inodes after + * everything is done. + */ + if (delete_item) atomic_dec(&root->orphan_inodes); - if (trans) - ret = btrfs_del_orphan_item(trans, root, - btrfs_ino(inode)); - } - - if (release_rsv) - btrfs_orphan_release_metadata(inode); return ret; }

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001 From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Jan 2018 11:02:54 -0700 Subject: [PATCH] Btrfs: fix use-after-free on root->orphan_block_rsv I got these from running generic/475, WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs] Call Trace: btrfs_orphan_release_metadata+0x9f/0x200 [btrfs] btrfs_orphan_del+0x10d/0x170 [btrfs] btrfs_setattr+0x500/0x640 [btrfs] notify_change+0x7ae/0x870 do_truncate+0xca/0x130 vfs_truncate+0x2ee/0x3d0 do_sys_truncate+0xaf/0xf0 SyS_truncate+0xe/0x10 entry_SYSCALL_64_fastpath+0x1f/0x96 The race is between btrfs_orphan_commit_root and btrfs_orphan_del, t1 t2 btrfs_orphan_commit_root btrfs_orphan_del spin_lock check (&root->orphan_inodes) root->orphan_block_rsv = NULL; spin_unlock atomic_dec(&root->orphan_inodes); access root->orphan_block_rsv Accessing root->orphan_block_rsv must be done before decreasing root->orphan_inodes. cc: <stable(a)vger.kernel.org> v3.12+ Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count") Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 44a152d8f32f..29b491328f4e 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3387,6 +3387,11 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, ret = btrfs_orphan_reserve_metadata(trans, inode); ASSERT(!ret); if (ret) { + /* + * dec doesn't need spin_lock as ->orphan_block_rsv + * would be released only if ->orphan_inodes is + * zero. + */ atomic_dec(&root->orphan_inodes); clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); @@ -3401,12 +3406,17 @@ int btrfs_orphan_add(struct btrfs_trans_handle *trans, if (insert >= 1) { ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode)); if (ret) { - atomic_dec(&root->orphan_inodes); if (reserve) { clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags); btrfs_orphan_release_metadata(inode); } + /* + * btrfs_orphan_commit_root may race with us and set + * ->orphan_block_rsv to zero, in order to avoid that, + * decrease ->orphan_inodes after everything is done. + */ + atomic_dec(&root->orphan_inodes); if (ret != -EEXIST) { clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags); @@ -3438,28 +3448,26 @@ static int btrfs_orphan_del(struct btrfs_trans_handle *trans, { struct btrfs_root *root = inode->root; int delete_item = 0; - int release_rsv = 0; int ret = 0; - spin_lock(&root->orphan_lock); if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM, &inode->runtime_flags)) delete_item = 1; + if (delete_item && trans) + ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode)); + if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED, &inode->runtime_flags)) - release_rsv = 1; - spin_unlock(&root->orphan_lock); + btrfs_orphan_release_metadata(inode); - if (delete_item) { + /* + * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv + * to zero, in order to avoid that, decrease ->orphan_inodes after + * everything is done. + */ + if (delete_item) atomic_dec(&root->orphan_inodes); - if (trans) - ret = btrfs_del_orphan_item(trans, root, - btrfs_ino(inode)); - } - - if (release_rsv) - btrfs_orphan_release_metadata(inode); return ret; }

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] nvme-pci: Remap CMB SQ entries on every controller reset" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 815c6704bf9f1c59f3a6be380a4032b9c57b12f1 Mon Sep 17 00:00:00 2001 From: Keith Busch <keith.busch(a)intel.com> Date: Tue, 13 Feb 2018 05:44:44 -0700 Subject: [PATCH] nvme-pci: Remap CMB SQ entries on every controller reset The controller memory buffer is remapped into a kernel address on each reset, but the driver was setting the submission queue base address only on the very first queue creation. The remapped address is likely to change after a reset, so accessing the old address will hit a kernel bug. This patch fixes that by setting the queue's CMB base address each time the queue is created. Fixes: f63572dff1421 ("nvme: unmap CMB and remove sysfs file in reset path") Reported-by: Christian Black <christian.d.black(a)intel.com> Cc: Jon Derrick <jonathan.derrick(a)intel.com> Cc: <stable(a)vger.kernel.org> # 4.9+ Signed-off-by: Keith Busch <keith.busch(a)intel.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index ab9c19525fa8..b427157af74e 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1364,18 +1364,14 @@ static int nvme_cmb_qdepth(struct nvme_dev *dev, int nr_io_queues, static int nvme_alloc_sq_cmds(struct nvme_dev *dev, struct nvme_queue *nvmeq, int qid, int depth) { - if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { - unsigned offset = (qid - 1) * roundup(SQ_SIZE(depth), - dev->ctrl.page_size); - nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; - nvmeq->sq_cmds_io = dev->cmb + offset; - } else { - nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), - &nvmeq->sq_dma_addr, GFP_KERNEL); - if (!nvmeq->sq_cmds) - return -ENOMEM; - } + /* CMB SQEs will be mapped before creation */ + if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) + return 0; + nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), + &nvmeq->sq_dma_addr, GFP_KERNEL); + if (!nvmeq->sq_cmds) + return -ENOMEM; return 0; } @@ -1449,6 +1445,13 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, int qid) struct nvme_dev *dev = nvmeq->dev; int result; + if (dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { + unsigned offset = (qid - 1) * roundup(SQ_SIZE(nvmeq->q_depth), + dev->ctrl.page_size); + nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; + nvmeq->sq_cmds_io = dev->cmb + offset; + } + nvmeq->cq_vector = qid - 1; result = adapter_alloc_cq(dev, qid, nvmeq); if (result < 0)

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] nvme-pci: Remap CMB SQ entries on every controller reset" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 815c6704bf9f1c59f3a6be380a4032b9c57b12f1 Mon Sep 17 00:00:00 2001 From: Keith Busch <keith.busch(a)intel.com> Date: Tue, 13 Feb 2018 05:44:44 -0700 Subject: [PATCH] nvme-pci: Remap CMB SQ entries on every controller reset The controller memory buffer is remapped into a kernel address on each reset, but the driver was setting the submission queue base address only on the very first queue creation. The remapped address is likely to change after a reset, so accessing the old address will hit a kernel bug. This patch fixes that by setting the queue's CMB base address each time the queue is created. Fixes: f63572dff1421 ("nvme: unmap CMB and remove sysfs file in reset path") Reported-by: Christian Black <christian.d.black(a)intel.com> Cc: Jon Derrick <jonathan.derrick(a)intel.com> Cc: <stable(a)vger.kernel.org> # 4.9+ Signed-off-by: Keith Busch <keith.busch(a)intel.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index ab9c19525fa8..b427157af74e 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1364,18 +1364,14 @@ static int nvme_cmb_qdepth(struct nvme_dev *dev, int nr_io_queues, static int nvme_alloc_sq_cmds(struct nvme_dev *dev, struct nvme_queue *nvmeq, int qid, int depth) { - if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { - unsigned offset = (qid - 1) * roundup(SQ_SIZE(depth), - dev->ctrl.page_size); - nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; - nvmeq->sq_cmds_io = dev->cmb + offset; - } else { - nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), - &nvmeq->sq_dma_addr, GFP_KERNEL); - if (!nvmeq->sq_cmds) - return -ENOMEM; - } + /* CMB SQEs will be mapped before creation */ + if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) + return 0; + nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), + &nvmeq->sq_dma_addr, GFP_KERNEL); + if (!nvmeq->sq_cmds) + return -ENOMEM; return 0; } @@ -1449,6 +1445,13 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, int qid) struct nvme_dev *dev = nvmeq->dev; int result; + if (dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { + unsigned offset = (qid - 1) * roundup(SQ_SIZE(nvmeq->q_depth), + dev->ctrl.page_size); + nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; + nvmeq->sq_cmds_io = dev->cmb + offset; + } + nvmeq->cq_vector = qid - 1; result = adapter_alloc_cq(dev, qid, nvmeq); if (result < 0)

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] nvme-pci: Remap CMB SQ entries on every controller reset" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 815c6704bf9f1c59f3a6be380a4032b9c57b12f1 Mon Sep 17 00:00:00 2001 From: Keith Busch <keith.busch(a)intel.com> Date: Tue, 13 Feb 2018 05:44:44 -0700 Subject: [PATCH] nvme-pci: Remap CMB SQ entries on every controller reset The controller memory buffer is remapped into a kernel address on each reset, but the driver was setting the submission queue base address only on the very first queue creation. The remapped address is likely to change after a reset, so accessing the old address will hit a kernel bug. This patch fixes that by setting the queue's CMB base address each time the queue is created. Fixes: f63572dff1421 ("nvme: unmap CMB and remove sysfs file in reset path") Reported-by: Christian Black <christian.d.black(a)intel.com> Cc: Jon Derrick <jonathan.derrick(a)intel.com> Cc: <stable(a)vger.kernel.org> # 4.9+ Signed-off-by: Keith Busch <keith.busch(a)intel.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index ab9c19525fa8..b427157af74e 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1364,18 +1364,14 @@ static int nvme_cmb_qdepth(struct nvme_dev *dev, int nr_io_queues, static int nvme_alloc_sq_cmds(struct nvme_dev *dev, struct nvme_queue *nvmeq, int qid, int depth) { - if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { - unsigned offset = (qid - 1) * roundup(SQ_SIZE(depth), - dev->ctrl.page_size); - nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; - nvmeq->sq_cmds_io = dev->cmb + offset; - } else { - nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), - &nvmeq->sq_dma_addr, GFP_KERNEL); - if (!nvmeq->sq_cmds) - return -ENOMEM; - } + /* CMB SQEs will be mapped before creation */ + if (qid && dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) + return 0; + nvmeq->sq_cmds = dma_alloc_coherent(dev->dev, SQ_SIZE(depth), + &nvmeq->sq_dma_addr, GFP_KERNEL); + if (!nvmeq->sq_cmds) + return -ENOMEM; return 0; } @@ -1449,6 +1445,13 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, int qid) struct nvme_dev *dev = nvmeq->dev; int result; + if (dev->cmb && use_cmb_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) { + unsigned offset = (qid - 1) * roundup(SQ_SIZE(nvmeq->q_depth), + dev->ctrl.page_size); + nvmeq->sq_dma_addr = dev->cmb_bus_addr + offset; + nvmeq->sq_cmds_io = dev->cmb + offset; + } + nvmeq->cq_vector = qid - 1; result = adapter_alloc_cq(dev, qid, nvmeq); if (result < 0)

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] dm: correctly handle chained bios in dec_pending()" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: [PATCH] dm: correctly handle chained bios in dec_pending() dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index d6de00f367ef..68136806d365 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -903,7 +903,8 @@ static void dec_pending(struct dm_io *io, blk_status_t error) queue_io(md, bio); } else { /* done with normal IO or empty flush */ - bio->bi_status = io_error; + if (io_error) + bio->bi_status = io_error; bio_endio(bio); } }

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] dm: correctly handle chained bios in dec_pending()" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Thu, 15 Feb 2018 20:00:15 +1100 Subject: [PATCH] dm: correctly handle chained bios in dec_pending() dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com> Cc: stable(a)vger.kernel.org (v3.14+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index d6de00f367ef..68136806d365 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -903,7 +903,8 @@ static void dec_pending(struct dm_io *io, blk_status_t error) queue_io(md, bio); } else { /* done with normal IO or empty flush */ - bio->bi_status = io_error; + if (io_error) + bio->bi_status = io_error; bio_endio(bio); } }

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fd0e786d9d09024f67bd71ec094b110237dc3840 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Thu, 25 Jan 2018 14:23:48 -0800 Subject: [PATCH] x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages In the following commit: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") ... we added code to memory_failure() to unmap the page from the kernel 1:1 virtual address space to avoid speculative access to the page logging additional errors. But memory_failure() may not always succeed in taking the page offline, especially if the page belongs to the kernel. This can happen if there are too many corrected errors on a page and either mcelog(8) or drivers/ras/cec.c asks to take a page offline. Since we remove the 1:1 mapping early in memory_failure(), we can end up with the page unmapped, but still in use. On the next access the kernel crashes :-( There are also various debug paths that call memory_failure() to simulate occurrence of an error. Since there is no actual error in memory, we don't need to map out the page for those cases. Revert most of the previous attempt and keep the solution local to arch/x86/kernel/cpu/mcheck/mce.c. Unmap the page only when: 1) there is a real error 2) memory_failure() succeeds. All of this only applies to 64-bit systems. 32-bit kernel doesn't map all of memory into kernel space. It isn't worth adding the code to unmap the piece that is mapped because nobody would run a 32-bit kernel on a machine that has recoverable machine checks. Signed-off-by: Tony Luck <tony.luck(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Dave <dave.hansen(a)intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Robert (Persistent Memory) <elliott(a)hpe.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Cc: stable(a)vger.kernel.org #v4.14 Fixes: ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages") Signed-off-by: Ingo Molnar <mingo(a)kernel.org> diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h index 4baa6bceb232..d652a3808065 100644 --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -52,10 +52,6 @@ static inline void clear_page(void *page) void copy_page(void *to, void *from); -#ifdef CONFIG_X86_MCE -#define arch_unmap_kpfn arch_unmap_kpfn -#endif - #endif /* !__ASSEMBLY__ */ #ifdef CONFIG_X86_VSYSCALL_EMULATION diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h b/arch/x86/kernel/cpu/mcheck/mce-internal.h index aa0d5df9dc60..e956eb267061 100644 --- a/arch/x86/kernel/cpu/mcheck/mce-internal.h +++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h @@ -115,4 +115,19 @@ static inline void mce_unregister_injector_chain(struct notifier_block *nb) { } extern struct mca_config mca_cfg; +#ifndef CONFIG_X86_64 +/* + * On 32-bit systems it would be difficult to safely unmap a poison page + * from the kernel 1:1 map because there are no non-canonical addresses that + * we can use to refer to the address without risking a speculative access. + * However, this isn't much of an issue because: + * 1) Few unmappable pages are in the 1:1 map. Most are in HIGHMEM which + * are only mapped into the kernel as needed + * 2) Few people would run a 32-bit kernel on a machine that supports + * recoverable errors because they have too much memory to boot 32-bit. + */ +static inline void mce_unmap_kpfn(unsigned long pfn) {} +#define mce_unmap_kpfn mce_unmap_kpfn +#endif + #endif /* __X86_MCE_INTERNAL_H__ */ diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 75f405ac085c..8ff94d1e2dce 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -105,6 +105,10 @@ static struct irq_work mce_irq_work; static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs); +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn); +#endif + /* * CPU/chipset specific EDAC code can register a notifier call here to print * MCE errors in a human-readable form. @@ -590,7 +594,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val, if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) { pfn = mce->addr >> PAGE_SHIFT; - memory_failure(pfn, 0); + if (!memory_failure(pfn, 0)) + mce_unmap_kpfn(pfn); } return NOTIFY_OK; @@ -1057,12 +1062,13 @@ static int do_memory_failure(struct mce *m) ret = memory_failure(m->addr >> PAGE_SHIFT, flags); if (ret) pr_err("Memory error not recovered"); + else + mce_unmap_kpfn(m->addr >> PAGE_SHIFT); return ret; } -#if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE) - -void arch_unmap_kpfn(unsigned long pfn) +#ifndef mce_unmap_kpfn +static void mce_unmap_kpfn(unsigned long pfn) { unsigned long decoy_addr; @@ -1073,7 +1079,7 @@ void arch_unmap_kpfn(unsigned long pfn) * We would like to just call: * set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1); * but doing that would radically increase the odds of a - * speculative access to the posion page because we'd have + * speculative access to the poison page because we'd have * the virtual address of the kernel 1:1 mapping sitting * around in registers. * Instead we get tricky. We create a non-canonical address @@ -1098,7 +1104,6 @@ void arch_unmap_kpfn(unsigned long pfn) if (set_memory_np(decoy_addr, 1)) pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); - } #endif diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index c30b32e3c862..10191c28fc04 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -127,10 +127,4 @@ static __always_inline enum lru_list page_lru(struct page *page) #define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) -#ifdef arch_unmap_kpfn -extern void arch_unmap_kpfn(unsigned long pfn); -#else -static __always_inline void arch_unmap_kpfn(unsigned long pfn) { } -#endif - #endif diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 4b80ccee4535..8291b75f42c8 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1139,8 +1139,6 @@ int memory_failure(unsigned long pfn, int flags) return 0; } - arch_unmap_kpfn(pfn); - orig_head = hpage = compound_head(p); num_poisoned_pages_inc();

7 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] drm/qxl: reapply cursor after resetting primary" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 9428088c90b6f7d5edd2a1b0d742c75339b36f6e Mon Sep 17 00:00:00 2001 From: Ray Strode <rstrode(a)redhat.com> Date: Mon, 27 Nov 2017 16:50:10 -0500 Subject: [PATCH] drm/qxl: reapply cursor after resetting primary QXL associates mouse state with its primary plane. Destroying a primary plane and putting a new one in place has the side effect of destroying the cursor as well. This commit changes the driver to reapply the cursor any time a new primary is created. It achieves this by keeping a reference to the cursor bo on the qxl_crtc struct. This fix is very similar to commit 4532b241a4b7 ("drm/qxl: reapply cursor after SetCrtc calls") which got implicitly reverted as part of implementing the atomic modeset feature. Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Dave Airlie <airlied(a)redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1512097 Fixes: 1277eed5fecb ("drm: qxl: Atomic phase 1: convert cursor to universal plane") Cc: stable(a)vger.kernel.org Signed-off-by: Ray Strode <rstrode(a)redhat.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 7335d99244d5..9a9214ae0fb5 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -289,6 +289,7 @@ static void qxl_crtc_destroy(struct drm_crtc *crtc) { struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc); + qxl_bo_unref(&qxl_crtc->cursor_bo); drm_crtc_cleanup(crtc); kfree(qxl_crtc); } @@ -495,6 +496,53 @@ static int qxl_primary_atomic_check(struct drm_plane *plane, return 0; } +static int qxl_primary_apply_cursor(struct drm_plane *plane) +{ + struct drm_device *dev = plane->dev; + struct qxl_device *qdev = dev->dev_private; + struct drm_framebuffer *fb = plane->state->fb; + struct qxl_crtc *qcrtc = to_qxl_crtc(plane->state->crtc); + struct qxl_cursor_cmd *cmd; + struct qxl_release *release; + int ret = 0; + + if (!qcrtc->cursor_bo) + return 0; + + ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd), + QXL_RELEASE_CURSOR_CMD, + &release, NULL); + if (ret) + return ret; + + ret = qxl_release_list_add(release, qcrtc->cursor_bo); + if (ret) + goto out_free_release; + + ret = qxl_release_reserve_list(release, false); + if (ret) + goto out_free_release; + + cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release); + cmd->type = QXL_CURSOR_SET; + cmd->u.set.position.x = plane->state->crtc_x + fb->hot_x; + cmd->u.set.position.y = plane->state->crtc_y + fb->hot_y; + + cmd->u.set.shape = qxl_bo_physical_address(qdev, qcrtc->cursor_bo, 0); + + cmd->u.set.visible = 1; + qxl_release_unmap(qdev, release, &cmd->release_info); + + qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + qxl_release_fence_buffer_objects(release); + + return ret; + +out_free_release: + qxl_release_free(qdev, release); + return ret; +} + static void qxl_primary_atomic_update(struct drm_plane *plane, struct drm_plane_state *old_state) { @@ -510,6 +558,7 @@ static void qxl_primary_atomic_update(struct drm_plane *plane, .x2 = qfb->base.width, .y2 = qfb->base.height }; + int ret; bool same_shadow = false; if (old_state->fb) { @@ -531,6 +580,11 @@ static void qxl_primary_atomic_update(struct drm_plane *plane, if (!same_shadow) qxl_io_destroy_primary(qdev); bo_old->is_primary = false; + + ret = qxl_primary_apply_cursor(plane); + if (ret) + DRM_ERROR( + "could not set cursor after creating primary"); } if (!bo->is_primary) { @@ -571,6 +625,7 @@ static void qxl_cursor_atomic_update(struct drm_plane *plane, struct drm_device *dev = plane->dev; struct qxl_device *qdev = dev->dev_private; struct drm_framebuffer *fb = plane->state->fb; + struct qxl_crtc *qcrtc = to_qxl_crtc(plane->state->crtc); struct qxl_release *release; struct qxl_cursor_cmd *cmd; struct qxl_cursor *cursor; @@ -628,6 +683,10 @@ static void qxl_cursor_atomic_update(struct drm_plane *plane, cmd->u.set.shape = qxl_bo_physical_address(qdev, cursor_bo, 0); cmd->type = QXL_CURSOR_SET; + + qxl_bo_unref(&qcrtc->cursor_bo); + qcrtc->cursor_bo = cursor_bo; + cursor_bo = NULL; } else { ret = qxl_release_reserve_list(release, true); diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h index 08752c0ffb35..00a1a66b052a 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -111,6 +111,8 @@ struct qxl_bo_list { struct qxl_crtc { struct drm_crtc base; int index; + + struct qxl_bo *cursor_bo; }; struct qxl_output {

7 years, 4 months

3
2
0 0

[PATCH] arm64: proc: Set PTE_NG for table entries to avoid traversing them twice

by Will Deacon

Commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream. When KASAN is enabled, the swapper page table contains many identical mappings of the zero page, which can lead to a stall during boot whilst the G -> nG code continually walks the same page table entries looking for global mappings. This patch sets the nG bit (bit 11, which is IGNORED) in table entries after processing the subtree so we can easily skip them if we see them a second time. Cc: <stable(a)vger.kernel.org> # 4.14+ Tested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> --- arch/arm64/mm/proc.S | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 71baed7e592a..c0af47617299 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -205,7 +205,8 @@ ENDPROC(idmap_cpu_replace_ttbr1) dc cvac, cur_\()\type\()p // Ensure any existing dirty dmb sy // lines are written back before ldr \type, [cur_\()\type\()p] // loading the entry - tbz \type, #0, next_\()\type // Skip invalid entries + tbz \type, #0, skip_\()\type // Skip invalid and + tbnz \type, #11, skip_\()\type // non-global entries .endm .macro __idmap_kpti_put_pgtable_ent_ng, type @@ -265,8 +266,9 @@ ENTRY(idmap_kpti_install_ng_mappings) add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8) do_pgd: __idmap_kpti_get_pgtable_ent pgd tbnz pgd, #1, walk_puds - __idmap_kpti_put_pgtable_ent_ng pgd next_pgd: + __idmap_kpti_put_pgtable_ent_ng pgd +skip_pgd: add cur_pgdp, cur_pgdp, #8 cmp cur_pgdp, end_pgdp b.ne do_pgd @@ -294,8 +296,9 @@ walk_puds: add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8) do_pud: __idmap_kpti_get_pgtable_ent pud tbnz pud, #1, walk_pmds - __idmap_kpti_put_pgtable_ent_ng pud next_pud: + __idmap_kpti_put_pgtable_ent_ng pud +skip_pud: add cur_pudp, cur_pudp, 8 cmp cur_pudp, end_pudp b.ne do_pud @@ -314,8 +317,9 @@ walk_pmds: add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8) do_pmd: __idmap_kpti_get_pgtable_ent pmd tbnz pmd, #1, walk_ptes - __idmap_kpti_put_pgtable_ent_ng pmd next_pmd: + __idmap_kpti_put_pgtable_ent_ng pmd +skip_pmd: add cur_pmdp, cur_pmdp, #8 cmp cur_pmdp, end_pmdp b.ne do_pmd @@ -333,7 +337,7 @@ walk_ptes: add end_ptep, cur_ptep, #(PTRS_PER_PTE * 8) do_pte: __idmap_kpti_get_pgtable_ent pte __idmap_kpti_put_pgtable_ent_ng pte -next_pte: +skip_pte: add cur_ptep, cur_ptep, #8 cmp cur_ptep, end_ptep b.ne do_pte -- 2.1.4

7 years, 4 months

2
1
0 0

Patch "rtlwifi: rtl8821ae: Fix connection lost problem correctly" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl8821ae: Fix connection lost problem correctly to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c713fb071edc0efc01a955f65a006b0e1795d2eb Mon Sep 17 00:00:00 2001 From: Larry Finger <Larry.Finger(a)lwfinger.net> Date: Mon, 5 Feb 2018 12:38:11 -0600 Subject: rtlwifi: rtl8821ae: Fix connection lost problem correctly From: Larry Finger <Larry.Finger(a)lwfinger.net> commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream. There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Tested-by: James Cameron <quozl(a)laptop.org> # x86_64 OLPC NL3 Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1123,7 +1123,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1165,7 +1165,8 @@ static void _rtl8821ae_enable_aspm_back_ } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are queue-4.15/rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch

7 years, 4 months

1
0
0 0

[PATCH 2/2] Revert "usb: musb: host: don't start next rx urb if current one failed"

by Bin Liu

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 Cc: stable(a)vger.kernel.org # v4.7+ Signed-off-by: Bin Liu <b-liu(a)ti.com> --- drivers/usb/musb/musb_host.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 394b4ac86161..45ed32c2cba9 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -391,13 +391,7 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb, } } - /* - * 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); -- 1.9.1

7 years, 4 months

1
0
0 0

[PATCH] Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking

by Hans de Goede

Commit 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version") applied the USB_QUIRK_RESET_RESUME to all QCA USB Bluetooth modules. But it turns out that the resume problems are not caused by the QCA Rome chipset, on most platforms it resumes fine. The resume problems are actually a platform problem (likely the platform cutting all power when suspended). The USB_QUIRK_RESET_RESUME quirk also disables runtime suspend, so by matching on usb-ids, we're causing all boards with these chips to use extra power, to fix resume problems which only happen on some boards. This commit fixes this by applying the quirk based on DMI matching instead of on usb-ids, so that we match the platform and not the chipset. Here is the /sys/kernel/debug/usb/devices for the Bluetooth module: T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e300 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836 Fixes: 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume..") Cc: stable(a)vger.kernel.org Cc: Brian Norris <briannorris(a)chromium.org> Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Reported-and-tested-by: Kevin Fenzi <kevin(a)scrye.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/bluetooth/btusb.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 2a55380ad730..a4b62f0a93cc 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -21,6 +21,7 @@ * */ +#include <linux/dmi.h> #include <linux/module.h> #include <linux/usb.h> #include <linux/usb/quirks.h> @@ -379,6 +380,22 @@ static const struct usb_device_id blacklist_table[] = { { } /* Terminating entry */ }; +/* + * The Bluetooth USB module build into some devices needs to be reset on resume, + * this is a problem with the platform (likely shutting off all power) not with + * the module itself. So we use a DMI list to match known broken platforms. + */ +static const struct dmi_system_id btusb_needs_reset_resume_table[] = { + { + /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"), + }, + }, + {} +}; + #define BTUSB_MAX_ISOC_FRAMES 10 #define BTUSB_INTR_RUNNING 0 @@ -2945,6 +2962,9 @@ static int btusb_probe(struct usb_interface *intf, hdev->send = btusb_send_frame; hdev->notify = btusb_notify; + if (dmi_check_system(btusb_needs_reset_resume_table)) + interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME; + #ifdef CONFIG_PM err = btusb_config_oob_wake(hdev); if (err) @@ -3031,12 +3051,6 @@ static int btusb_probe(struct usb_interface *intf, if (id->driver_info & BTUSB_QCA_ROME) { data->setup_on_usb = btusb_setup_qca; hdev->set_bdaddr = btusb_set_bdaddr_ath3012; - - /* QCA Rome devices lose their updated firmware over suspend, - * but the USB hub doesn't notice any status change. - * explicitly request a device reset on resume. - */ - interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME; } #ifdef CONFIG_BT_HCIBTUSB_RTL -- 2.14.3

7 years, 4 months

2
1
0 0

Patch "kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kmemcheck-stop-using-gfp_notrack-and-slab_notrack.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 75f296d93bcebcfe375884ddac79e30263a31766 Mon Sep 17 00:00:00 2001 From: "Levin, Alexander (Sasha Levin)" <alexander.levin(a)verizon.com> Date: Wed, 15 Nov 2017 17:35:54 -0800 Subject: kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK From: Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> commit 75f296d93bcebcfe375884ddac79e30263a31766 upstream. Convert all allocations that used a NOTRACK flag to stop using it. Link: http://lkml.kernel.org/r/20171007030159.22241-3-alexander.levin@verizon.com Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Tim Hansen <devtimhansen(a)gmail.com> Cc: Vegard Nossum <vegardno(a)ifi.uio.no> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/include/asm/pgalloc.h | 2 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/pgalloc.h | 2 +- arch/sh/kernel/dwarf.c | 4 ++-- arch/sh/kernel/process.c | 2 +- arch/sparc/mm/init_64.c | 4 ++-- arch/unicore32/include/asm/pgalloc.h | 2 +- arch/x86/kernel/espfix_64.c | 2 +- arch/x86/mm/init.c | 3 +-- arch/x86/mm/init_64.c | 2 +- arch/x86/mm/pageattr.c | 10 +++++----- arch/x86/mm/pgtable.c | 2 +- arch/x86/platform/efi/efi_64.c | 2 +- crypto/xor.c | 7 +------ include/linux/thread_info.h | 5 ++--- init/do_mounts.c | 3 +-- kernel/fork.c | 12 ++++++------ kernel/signal.c | 3 +-- mm/kmemcheck.c | 2 +- mm/slab.c | 2 +- mm/slab.h | 5 ++--- mm/slab_common.c | 2 +- mm/slub.c | 4 +--- 23 files changed, 36 insertions(+), 48 deletions(-) --- a/arch/arm/include/asm/pgalloc.h +++ b/arch/arm/include/asm/pgalloc.h @@ -57,7 +57,7 @@ static inline void pud_populate(struct m extern pgd_t *pgd_alloc(struct mm_struct *mm); extern void pgd_free(struct mm_struct *mm, pgd_t *pgd); -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO) static inline void clean_pte_table(pte_t *pte) { --- a/arch/arm64/include/asm/pgalloc.h +++ b/arch/arm64/include/asm/pgalloc.h @@ -26,7 +26,7 @@ #define check_pgt_cache() do { } while (0) -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO) #define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t)) #if CONFIG_PGTABLE_LEVELS > 2 --- a/arch/powerpc/include/asm/pgalloc.h +++ b/arch/powerpc/include/asm/pgalloc.h @@ -18,7 +18,7 @@ static inline gfp_t pgtable_gfp_flags(st } #endif /* MODULE */ -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO) #ifdef CONFIG_PPC_BOOK3S #include <asm/book3s/pgalloc.h> --- a/arch/sh/kernel/dwarf.c +++ b/arch/sh/kernel/dwarf.c @@ -1172,11 +1172,11 @@ static int __init dwarf_unwinder_init(vo dwarf_frame_cachep = kmem_cache_create("dwarf_frames", sizeof(struct dwarf_frame), 0, - SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL); + SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL); dwarf_reg_cachep = kmem_cache_create("dwarf_regs", sizeof(struct dwarf_reg), 0, - SLAB_PANIC | SLAB_HWCACHE_ALIGN | SLAB_NOTRACK, NULL); + SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL); dwarf_frame_pool = mempool_create_slab_pool(DWARF_FRAME_MIN_REQ, dwarf_frame_cachep); --- a/arch/sh/kernel/process.c +++ b/arch/sh/kernel/process.c @@ -59,7 +59,7 @@ void arch_task_cache_init(void) task_xstate_cachep = kmem_cache_create("task_xstate", xstate_size, __alignof__(union thread_xstate), - SLAB_PANIC | SLAB_NOTRACK, NULL); + SLAB_PANIC, NULL); } #ifdef CONFIG_SH_FPU_EMU --- a/arch/sparc/mm/init_64.c +++ b/arch/sparc/mm/init_64.c @@ -2934,7 +2934,7 @@ void __flush_tlb_all(void) pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address) { - struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO); + struct page *page = alloc_page(GFP_KERNEL | __GFP_ZERO); pte_t *pte = NULL; if (page) @@ -2946,7 +2946,7 @@ pte_t *pte_alloc_one_kernel(struct mm_st pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long address) { - struct page *page = alloc_page(GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO); + struct page *page = alloc_page(GFP_KERNEL | __GFP_ZERO); if (!page) return NULL; if (!pgtable_page_ctor(page)) { --- a/arch/unicore32/include/asm/pgalloc.h +++ b/arch/unicore32/include/asm/pgalloc.h @@ -28,7 +28,7 @@ extern void free_pgd_slow(struct mm_stru #define pgd_alloc(mm) get_pgd_slow(mm) #define pgd_free(mm, pgd) free_pgd_slow(mm, pgd) -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO) /* * Allocate one PTE table. --- a/arch/x86/kernel/espfix_64.c +++ b/arch/x86/kernel/espfix_64.c @@ -57,7 +57,7 @@ # error "Need more virtual address space for the ESPFIX hack" #endif -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL | __GFP_ZERO) /* This contains the *bottom* address of the espfix stack */ DEFINE_PER_CPU_READ_MOSTLY(unsigned long, espfix_stack); --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -93,8 +93,7 @@ __ref void *alloc_low_pages(unsigned int unsigned int order; order = get_order((unsigned long)num << PAGE_SHIFT); - return (void *)__get_free_pages(GFP_ATOMIC | __GFP_NOTRACK | - __GFP_ZERO, order); + return (void *)__get_free_pages(GFP_ATOMIC | __GFP_ZERO, order); } if ((pgt_buf_end + num) > pgt_buf_top || !can_use_brk_pgt) { --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -184,7 +184,7 @@ static __ref void *spp_getpage(void) void *ptr; if (after_bootmem) - ptr = (void *) get_zeroed_page(GFP_ATOMIC | __GFP_NOTRACK); + ptr = (void *) get_zeroed_page(GFP_ATOMIC); else ptr = alloc_bootmem_pages(PAGE_SIZE); --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -753,7 +753,7 @@ static int split_large_page(struct cpa_d if (!debug_pagealloc_enabled()) spin_unlock(&cpa_lock); - base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0); + base = alloc_pages(GFP_KERNEL, 0); if (!debug_pagealloc_enabled()) spin_lock(&cpa_lock); if (!base) @@ -904,7 +904,7 @@ static void unmap_pud_range(p4d_t *p4d, static int alloc_pte_page(pmd_t *pmd) { - pte_t *pte = (pte_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK); + pte_t *pte = (pte_t *)get_zeroed_page(GFP_KERNEL); if (!pte) return -1; @@ -914,7 +914,7 @@ static int alloc_pte_page(pmd_t *pmd) static int alloc_pmd_page(pud_t *pud) { - pmd_t *pmd = (pmd_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK); + pmd_t *pmd = (pmd_t *)get_zeroed_page(GFP_KERNEL); if (!pmd) return -1; @@ -1120,7 +1120,7 @@ static int populate_pgd(struct cpa_data pgd_entry = cpa->pgd + pgd_index(addr); if (pgd_none(*pgd_entry)) { - p4d = (p4d_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK); + p4d = (p4d_t *)get_zeroed_page(GFP_KERNEL); if (!p4d) return -1; @@ -1132,7 +1132,7 @@ static int populate_pgd(struct cpa_data */ p4d = p4d_offset(pgd_entry, addr); if (p4d_none(*p4d)) { - pud = (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_NOTRACK); + pud = (pud_t *)get_zeroed_page(GFP_KERNEL); if (!pud) return -1; --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -7,7 +7,7 @@ #include <asm/fixmap.h> #include <asm/mtrr.h> -#define PGALLOC_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK | __GFP_ZERO) +#define PGALLOC_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) #ifdef CONFIG_HIGHPTE #define PGALLOC_USER_GFP __GFP_HIGHMEM --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86/platform/efi/efi_64.c @@ -211,7 +211,7 @@ int __init efi_alloc_page_tables(void) if (efi_enabled(EFI_OLD_MEMMAP)) return 0; - gfp_mask = GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO; + gfp_mask = GFP_KERNEL | __GFP_ZERO; efi_pgd = (pgd_t *)__get_free_pages(gfp_mask, PGD_ALLOCATION_ORDER); if (!efi_pgd) return -ENOMEM; --- a/crypto/xor.c +++ b/crypto/xor.c @@ -122,12 +122,7 @@ calibrate_xor_blocks(void) goto out; } - /* - * Note: Since the memory is not actually used for _anything_ but to - * test the XOR speed, we don't really want kmemcheck to warn about - * reading uninitialized bytes here. - */ - b1 = (void *) __get_free_pages(GFP_KERNEL | __GFP_NOTRACK, 2); + b1 = (void *) __get_free_pages(GFP_KERNEL, 2); if (!b1) { printk(KERN_WARNING "xor: Yikes! No memory available.\n"); return -ENOMEM; --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -44,10 +44,9 @@ enum { #endif #if IS_ENABLED(CONFIG_DEBUG_STACK_USAGE) || IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK | \ - __GFP_ZERO) +# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_ZERO) #else -# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT | __GFP_NOTRACK) +# define THREADINFO_GFP (GFP_KERNEL_ACCOUNT) #endif /* --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -380,8 +380,7 @@ static int __init do_mount_root(char *na void __init mount_block_root(char *name, int flags) { - struct page *page = alloc_page(GFP_KERNEL | - __GFP_NOTRACK_FALSE_POSITIVE); + struct page *page = alloc_page(GFP_KERNEL); char *fs_names = page_address(page); char *p; #ifdef CONFIG_BLOCK --- a/kernel/fork.c +++ b/kernel/fork.c @@ -469,7 +469,7 @@ void __init fork_init(void) /* create a slab on which task_structs can be allocated */ task_struct_cachep = kmem_cache_create("task_struct", arch_task_struct_size, align, - SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT, NULL); + SLAB_PANIC|SLAB_ACCOUNT, NULL); #endif /* do the arch specific task caches init */ @@ -2208,18 +2208,18 @@ void __init proc_caches_init(void) sighand_cachep = kmem_cache_create("sighand_cache", sizeof(struct sighand_struct), 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_TYPESAFE_BY_RCU| - SLAB_NOTRACK|SLAB_ACCOUNT, sighand_ctor); + SLAB_ACCOUNT, sighand_ctor); signal_cachep = kmem_cache_create("signal_cache", sizeof(struct signal_struct), 0, - SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT, + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); files_cachep = kmem_cache_create("files_cache", sizeof(struct files_struct), 0, - SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT, + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); fs_cachep = kmem_cache_create("fs_cache", sizeof(struct fs_struct), 0, - SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT, + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); /* * FIXME! The "sizeof(struct mm_struct)" currently includes the @@ -2230,7 +2230,7 @@ void __init proc_caches_init(void) */ mm_cachep = kmem_cache_create("mm_struct", sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN, - SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT, + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL); vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_ACCOUNT); mmap_init(); --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1038,8 +1038,7 @@ static int __send_signal(int sig, struct else override_rlimit = 0; - q = __sigqueue_alloc(sig, t, GFP_ATOMIC | __GFP_NOTRACK_FALSE_POSITIVE, - override_rlimit); + q = __sigqueue_alloc(sig, t, GFP_ATOMIC, override_rlimit); if (q) { list_add_tail(&q->list, &pending->list); switch ((unsigned long) info) { --- a/mm/kmemcheck.c +++ b/mm/kmemcheck.c @@ -18,7 +18,7 @@ void kmemcheck_alloc_shadow(struct page * With kmemcheck enabled, we need to allocate a memory area for the * shadow bits as well. */ - shadow = alloc_pages_node(node, flags | __GFP_NOTRACK, order); + shadow = alloc_pages_node(node, flags, order); if (!shadow) { if (printk_ratelimit()) pr_err("kmemcheck: failed to allocate shadow bitmap\n"); --- a/mm/slab.c +++ b/mm/slab.c @@ -1412,7 +1412,7 @@ static struct page *kmem_getpages(struct if (cachep->flags & SLAB_RECLAIM_ACCOUNT) flags |= __GFP_RECLAIMABLE; - page = __alloc_pages_node(nodeid, flags | __GFP_NOTRACK, cachep->gfporder); + page = __alloc_pages_node(nodeid, flags, cachep->gfporder); if (!page) { slab_out_of_memory(cachep, flags, nodeid); return NULL; --- a/mm/slab.h +++ b/mm/slab.h @@ -141,10 +141,10 @@ static inline unsigned long kmem_cache_f #if defined(CONFIG_SLAB) #define SLAB_CACHE_FLAGS (SLAB_MEM_SPREAD | SLAB_NOLEAKTRACE | \ SLAB_RECLAIM_ACCOUNT | SLAB_TEMPORARY | \ - SLAB_NOTRACK | SLAB_ACCOUNT) + SLAB_ACCOUNT) #elif defined(CONFIG_SLUB) #define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE | SLAB_RECLAIM_ACCOUNT | \ - SLAB_TEMPORARY | SLAB_NOTRACK | SLAB_ACCOUNT) + SLAB_TEMPORARY | SLAB_ACCOUNT) #else #define SLAB_CACHE_FLAGS (0) #endif @@ -163,7 +163,6 @@ static inline unsigned long kmem_cache_f SLAB_NOLEAKTRACE | \ SLAB_RECLAIM_ACCOUNT | \ SLAB_TEMPORARY | \ - SLAB_NOTRACK | \ SLAB_ACCOUNT) int __kmem_cache_shutdown(struct kmem_cache *); --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -44,7 +44,7 @@ static DECLARE_WORK(slab_caches_to_rcu_d SLAB_FAILSLAB | SLAB_KASAN) #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | \ - SLAB_NOTRACK | SLAB_ACCOUNT) + SLAB_ACCOUNT) /* * Merge control. If this is set then no merging of slab caches will occur. --- a/mm/slub.c +++ b/mm/slub.c @@ -1434,8 +1434,6 @@ static inline struct page *alloc_slab_pa struct page *page; int order = oo_order(oo); - flags |= __GFP_NOTRACK; - if (node == NUMA_NO_NODE) page = alloc_pages(flags, order); else @@ -3772,7 +3770,7 @@ static void *kmalloc_large_node(size_t s struct page *page; void *ptr = NULL; - flags |= __GFP_COMP | __GFP_NOTRACK; + flags |= __GFP_COMP; page = alloc_pages_node(node, flags, get_order(size)); if (page) ptr = page_address(page); Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are queue-4.14/kmemcheck-remove-annotations.patch queue-4.14/kmemcheck-remove-whats-left-of-notrack-flags.patch queue-4.14/kmemcheck-stop-using-gfp_notrack-and-slab_notrack.patch queue-4.14/kmemcheck-rip-it-out.patch

7 years, 4 months

1
0
0 0

Patch "kmemcheck: rip it out" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kmemcheck: rip it out to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kmemcheck-rip-it-out.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4675ff05de2d76d167336b368bd07f3fef6ed5a6 Mon Sep 17 00:00:00 2001 From: "Levin, Alexander (Sasha Levin)" <alexander.levin(a)verizon.com> Date: Wed, 15 Nov 2017 17:36:02 -0800 Subject: kmemcheck: rip it out From: Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> commit 4675ff05de2d76d167336b368bd07f3fef6ed5a6 upstream. Fix up makefiles, remove references, and git rm kmemcheck. Link: http://lkml.kernel.org/r/20171007030159.22241-4-alexander.levin@verizon.com Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Vegard Nossum <vegardno(a)ifi.uio.no> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Tim Hansen <devtimhansen(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/admin-guide/kernel-parameters.txt | 7 Documentation/dev-tools/index.rst | 1 Documentation/dev-tools/kmemcheck.rst | 733 ------------------------ MAINTAINERS | 10 arch/x86/Kconfig | 3 arch/x86/include/asm/kmemcheck.h | 42 - arch/x86/include/asm/string_32.h | 9 arch/x86/include/asm/string_64.h | 8 arch/x86/kernel/cpu/intel.c | 15 arch/x86/mm/Makefile | 2 arch/x86/mm/init.c | 5 arch/x86/mm/kmemcheck/Makefile | 1 arch/x86/mm/kmemcheck/error.c | 227 ------- arch/x86/mm/kmemcheck/error.h | 15 arch/x86/mm/kmemcheck/kmemcheck.c | 658 --------------------- arch/x86/mm/kmemcheck/opcode.c | 106 --- arch/x86/mm/kmemcheck/opcode.h | 9 arch/x86/mm/kmemcheck/pte.c | 22 arch/x86/mm/kmemcheck/pte.h | 10 arch/x86/mm/kmemcheck/selftest.c | 70 -- arch/x86/mm/kmemcheck/selftest.h | 6 arch/x86/mm/kmemcheck/shadow.c | 173 ----- arch/x86/mm/kmemcheck/shadow.h | 18 include/linux/interrupt.h | 15 include/linux/kmemcheck.h | 171 ----- kernel/softirq.c | 10 kernel/sysctl.c | 10 lib/Kconfig.debug | 6 lib/Kconfig.kmemcheck | 94 --- mm/Kconfig.debug | 1 mm/Makefile | 2 mm/kmemcheck.c | 125 ---- mm/slub.c | 5 scripts/kernel-doc | 2 tools/include/linux/kmemcheck.h | 8 35 files changed, 7 insertions(+), 2592 deletions(-) --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1841,13 +1841,6 @@ Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y, the default is off. - kmemcheck= [X86] Boot-time kmemcheck enable/disable/one-shot mode - Valid arguments: 0, 1, 2 - kmemcheck=0 (disabled) - kmemcheck=1 (enabled) - kmemcheck=2 (one-shot mode) - Default: 2 (one-shot mode) - kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs. Default is 0 (don't ignore, but inject #GP) --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -21,7 +21,6 @@ whole; patches welcome! kasan ubsan kmemleak - kmemcheck gdb-kernel-debugging kgdb kselftest --- a/Documentation/dev-tools/kmemcheck.rst +++ /dev/null @@ -1,733 +0,0 @@ -Getting started with kmemcheck -============================== - -Vegard Nossum <vegardno(a)ifi.uio.no> - - -Introduction ------------- - -kmemcheck is a debugging feature for the Linux Kernel. More specifically, it -is a dynamic checker that detects and warns about some uses of uninitialized -memory. - -Userspace programmers might be familiar with Valgrind's memcheck. The main -difference between memcheck and kmemcheck is that memcheck works for userspace -programs only, and kmemcheck works for the kernel only. The implementations -are of course vastly different. Because of this, kmemcheck is not as accurate -as memcheck, but it turns out to be good enough in practice to discover real -programmer errors that the compiler is not able to find through static -analysis. - -Enabling kmemcheck on a kernel will probably slow it down to the extent that -the machine will not be usable for normal workloads such as e.g. an -interactive desktop. kmemcheck will also cause the kernel to use about twice -as much memory as normal. For this reason, kmemcheck is strictly a debugging -feature. - - -Downloading ------------ - -As of version 2.6.31-rc1, kmemcheck is included in the mainline kernel. - - -Configuring and compiling -------------------------- - -kmemcheck only works for the x86 (both 32- and 64-bit) platform. A number of -configuration variables must have specific settings in order for the kmemcheck -menu to even appear in "menuconfig". These are: - -- ``CONFIG_CC_OPTIMIZE_FOR_SIZE=n`` - This option is located under "General setup" / "Optimize for size". - - Without this, gcc will use certain optimizations that usually lead to - false positive warnings from kmemcheck. An example of this is a 16-bit - field in a struct, where gcc may load 32 bits, then discard the upper - 16 bits. kmemcheck sees only the 32-bit load, and may trigger a - warning for the upper 16 bits (if they're uninitialized). - -- ``CONFIG_SLAB=y`` or ``CONFIG_SLUB=y`` - This option is located under "General setup" / "Choose SLAB - allocator". - -- ``CONFIG_FUNCTION_TRACER=n`` - This option is located under "Kernel hacking" / "Tracers" / "Kernel - Function Tracer" - - When function tracing is compiled in, gcc emits a call to another - function at the beginning of every function. This means that when the - page fault handler is called, the ftrace framework will be called - before kmemcheck has had a chance to handle the fault. If ftrace then - modifies memory that was tracked by kmemcheck, the result is an - endless recursive page fault. - -- ``CONFIG_DEBUG_PAGEALLOC=n`` - This option is located under "Kernel hacking" / "Memory Debugging" - / "Debug page memory allocations". - -In addition, I highly recommend turning on ``CONFIG_DEBUG_INFO=y``. This is also -located under "Kernel hacking". With this, you will be able to get line number -information from the kmemcheck warnings, which is extremely valuable in -debugging a problem. This option is not mandatory, however, because it slows -down the compilation process and produces a much bigger kernel image. - -Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory -Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows -a description of the kmemcheck configuration variables: - -- ``CONFIG_KMEMCHECK`` - This must be enabled in order to use kmemcheck at all... - -- ``CONFIG_KMEMCHECK_``[``DISABLED`` | ``ENABLED`` | ``ONESHOT``]``_BY_DEFAULT`` - This option controls the status of kmemcheck at boot-time. "Enabled" - will enable kmemcheck right from the start, "disabled" will boot the - kernel as normal (but with the kmemcheck code compiled in, so it can - be enabled at run-time after the kernel has booted), and "one-shot" is - a special mode which will turn kmemcheck off automatically after - detecting the first use of uninitialized memory. - - If you are using kmemcheck to actively debug a problem, then you - probably want to choose "enabled" here. - - The one-shot mode is mostly useful in automated test setups because it - can prevent floods of warnings and increase the chances of the machine - surviving in case something is really wrong. In other cases, the one- - shot mode could actually be counter-productive because it would turn - itself off at the very first error -- in the case of a false positive - too -- and this would come in the way of debugging the specific - problem you were interested in. - - If you would like to use your kernel as normal, but with a chance to - enable kmemcheck in case of some problem, it might be a good idea to - choose "disabled" here. When kmemcheck is disabled, most of the run- - time overhead is not incurred, and the kernel will be almost as fast - as normal. - -- ``CONFIG_KMEMCHECK_QUEUE_SIZE`` - Select the maximum number of error reports to store in an internal - (fixed-size) buffer. Since errors can occur virtually anywhere and in - any context, we need a temporary storage area which is guaranteed not - to generate any other page faults when accessed. The queue will be - emptied as soon as a tasklet may be scheduled. If the queue is full, - new error reports will be lost. - - The default value of 64 is probably fine. If some code produces more - than 64 errors within an irqs-off section, then the code is likely to - produce many, many more, too, and these additional reports seldom give - any more information (the first report is usually the most valuable - anyway). - - This number might have to be adjusted if you are not using serial - console or similar to capture the kernel log. If you are using the - "dmesg" command to save the log, then getting a lot of kmemcheck - warnings might overflow the kernel log itself, and the earlier reports - will get lost in that way instead. Try setting this to 10 or so on - such a setup. - -- ``CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT`` - Select the number of shadow bytes to save along with each entry of the - error-report queue. These bytes indicate what parts of an allocation - are initialized, uninitialized, etc. and will be displayed when an - error is detected to help the debugging of a particular problem. - - The number entered here is actually the logarithm of the number of - bytes that will be saved. So if you pick for example 5 here, kmemcheck - will save 2^5 = 32 bytes. - - The default value should be fine for debugging most problems. It also - fits nicely within 80 columns. - -- ``CONFIG_KMEMCHECK_PARTIAL_OK`` - This option (when enabled) works around certain GCC optimizations that - produce 32-bit reads from 16-bit variables where the upper 16 bits are - thrown away afterwards. - - The default value (enabled) is recommended. This may of course hide - some real errors, but disabling it would probably produce a lot of - false positives. - -- ``CONFIG_KMEMCHECK_BITOPS_OK`` - This option silences warnings that would be generated for bit-field - accesses where not all the bits are initialized at the same time. This - may also hide some real bugs. - - This option is probably obsolete, or it should be replaced with - the kmemcheck-/bitfield-annotations for the code in question. The - default value is therefore fine. - -Now compile the kernel as usual. - - -How to use ----------- - -Booting -~~~~~~~ - -First some information about the command-line options. There is only one -option specific to kmemcheck, and this is called "kmemcheck". It can be used -to override the default mode as chosen by the ``CONFIG_KMEMCHECK_*_BY_DEFAULT`` -option. Its possible settings are: - -- ``kmemcheck=0`` (disabled) -- ``kmemcheck=1`` (enabled) -- ``kmemcheck=2`` (one-shot mode) - -If SLUB debugging has been enabled in the kernel, it may take precedence over -kmemcheck in such a way that the slab caches which are under SLUB debugging -will not be tracked by kmemcheck. In order to ensure that this doesn't happen -(even though it shouldn't by default), use SLUB's boot option ``slub_debug``, -like this: ``slub_debug=-`` - -In fact, this option may also be used for fine-grained control over SLUB vs. -kmemcheck. For example, if the command line includes -``kmemcheck=1 slub_debug=,dentry``, then SLUB debugging will be used only -for the "dentry" slab cache, and with kmemcheck tracking all the other -caches. This is advanced usage, however, and is not generally recommended. - - -Run-time enable/disable -~~~~~~~~~~~~~~~~~~~~~~~ - -When the kernel has booted, it is possible to enable or disable kmemcheck at -run-time. WARNING: This feature is still experimental and may cause false -positive warnings to appear. Therefore, try not to use this. If you find that -it doesn't work properly (e.g. you see an unreasonable amount of warnings), I -will be happy to take bug reports. - -Use the file ``/proc/sys/kernel/kmemcheck`` for this purpose, e.g.:: - - $ echo 0 > /proc/sys/kernel/kmemcheck # disables kmemcheck - -The numbers are the same as for the ``kmemcheck=`` command-line option. - - -Debugging -~~~~~~~~~ - -A typical report will look something like this:: - - WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - ^ - - Pid: 1856, comm: ntpdate Not tainted 2.6.29-rc5 #264 945P-A - RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190 - RSP: 0018:ffff88003cdf7d98 EFLAGS: 00210002 - RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 - RDX: ffff88003e5d6018 RSI: ffff88003e5d6024 RDI: ffff88003cdf7e84 - RBP: ffff88003cdf7db8 R08: ffff88003e5d6000 R09: 0000000000000000 - R10: 0000000000000080 R11: 0000000000000000 R12: 000000000000000e - R13: ffff88003cdf7e78 R14: ffff88003d530710 R15: ffff88003d5a98c8 - FS: 0000000000000000(0000) GS:ffff880001982000(0063) knlGS:00000 - CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 - CR2: ffff88003f806ea0 CR3: 000000003c036000 CR4: 00000000000006a0 - DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 - DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 - [<ffffffff8104f04e>] dequeue_signal+0x8e/0x170 - [<ffffffff81050bd8>] get_signal_to_deliver+0x98/0x390 - [<ffffffff8100b87d>] do_notify_resume+0xad/0x7d0 - [<ffffffff8100c7b5>] int_signal+0x12/0x17 - [<ffffffffffffffff>] 0xffffffffffffffff - -The single most valuable information in this report is the RIP (or EIP on 32- -bit) value. This will help us pinpoint exactly which instruction that caused -the warning. - -If your kernel was compiled with ``CONFIG_DEBUG_INFO=y``, then all we have to do -is give this address to the addr2line program, like this:: - - $ addr2line -e vmlinux -i ffffffff8104ede8 - arch/x86/include/asm/string_64.h:12 - include/asm-generic/siginfo.h:287 - kernel/signal.c:380 - kernel/signal.c:410 - -The "``-e vmlinux``" tells addr2line which file to look in. **IMPORTANT:** -This must be the vmlinux of the kernel that produced the warning in the -first place! If not, the line number information will almost certainly be -wrong. - -The "``-i``" tells addr2line to also print the line numbers of inlined -functions. In this case, the flag was very important, because otherwise, -it would only have printed the first line, which is just a call to -``memcpy()``, which could be called from a thousand places in the kernel, and -is therefore not very useful. These inlined functions would not show up in -the stack trace above, simply because the kernel doesn't load the extra -debugging information. This technique can of course be used with ordinary -kernel oopses as well. - -In this case, it's the caller of ``memcpy()`` that is interesting, and it can be -found in ``include/asm-generic/siginfo.h``, line 287:: - - 281 static inline void copy_siginfo(struct siginfo *to, struct siginfo *from) - 282 { - 283 if (from->si_code < 0) - 284 memcpy(to, from, sizeof(*to)); - 285 else - 286 /* _sigchld is currently the largest know union member */ - 287 memcpy(to, from, __ARCH_SI_PREAMBLE_SIZE + sizeof(from->_sifields._sigchld)); - 288 } - -Since this was a read (kmemcheck usually warns about reads only, though it can -warn about writes to unallocated or freed memory as well), it was probably the -"from" argument which contained some uninitialized bytes. Following the chain -of calls, we move upwards to see where "from" was allocated or initialized, -``kernel/signal.c``, line 380:: - - 359 static void collect_signal(int sig, struct sigpending *list, siginfo_t *info) - 360 { - ... - 367 list_for_each_entry(q, &list->list, list) { - 368 if (q->info.si_signo == sig) { - 369 if (first) - 370 goto still_pending; - 371 first = q; - ... - 377 if (first) { - 378 still_pending: - 379 list_del_init(&first->list); - 380 copy_siginfo(info, &first->info); - 381 __sigqueue_free(first); - ... - 392 } - 393 } - -Here, it is ``&first->info`` that is being passed on to ``copy_siginfo()``. The -variable ``first`` was found on a list -- passed in as the second argument to -``collect_signal()``. We continue our journey through the stack, to figure out -where the item on "list" was allocated or initialized. We move to line 410:: - - 395 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask, - 396 siginfo_t *info) - 397 { - ... - 410 collect_signal(sig, pending, info); - ... - 414 } - -Now we need to follow the ``pending`` pointer, since that is being passed on to -``collect_signal()`` as ``list``. At this point, we've run out of lines from the -"addr2line" output. Not to worry, we just paste the next addresses from the -kmemcheck stack dump, i.e.:: - - [<ffffffff8104f04e>] dequeue_signal+0x8e/0x170 - [<ffffffff81050bd8>] get_signal_to_deliver+0x98/0x390 - [<ffffffff8100b87d>] do_notify_resume+0xad/0x7d0 - [<ffffffff8100c7b5>] int_signal+0x12/0x17 - - $ addr2line -e vmlinux -i ffffffff8104f04e ffffffff81050bd8 \ - ffffffff8100b87d ffffffff8100c7b5 - kernel/signal.c:446 - kernel/signal.c:1806 - arch/x86/kernel/signal.c:805 - arch/x86/kernel/signal.c:871 - arch/x86/kernel/entry_64.S:694 - -Remember that since these addresses were found on the stack and not as the -RIP value, they actually point to the _next_ instruction (they are return -addresses). This becomes obvious when we look at the code for line 446:: - - 422 int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info) - 423 { - ... - 431 signr = __dequeue_signal(&tsk->signal->shared_pending, - 432 mask, info); - 433 /* - 434 * itimer signal ? - 435 * - 436 * itimers are process shared and we restart periodic - 437 * itimers in the signal delivery path to prevent DoS - 438 * attacks in the high resolution timer case. This is - 439 * compliant with the old way of self restarting - 440 * itimers, as the SIGALRM is a legacy signal and only - 441 * queued once. Changing the restart behaviour to - 442 * restart the timer in the signal dequeue path is - 443 * reducing the timer noise on heavy loaded !highres - 444 * systems too. - 445 */ - 446 if (unlikely(signr == SIGALRM)) { - ... - 489 } - -So instead of looking at 446, we should be looking at 431, which is the line -that executes just before 446. Here we see that what we are looking for is -``&tsk->signal->shared_pending``. - -Our next task is now to figure out which function that puts items on this -``shared_pending`` list. A crude, but efficient tool, is ``git grep``:: - - $ git grep -n 'shared_pending' kernel/ - ... - kernel/signal.c:828: pending = group ? &t->signal->shared_pending : &t->pending; - kernel/signal.c:1339: pending = group ? &t->signal->shared_pending : &t->pending; - ... - -There were more results, but none of them were related to list operations, -and these were the only assignments. We inspect the line numbers more closely -and find that this is indeed where items are being added to the list:: - - 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, - 817 int group) - 818 { - ... - 828 pending = group ? &t->signal->shared_pending : &t->pending; - ... - 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && - 852 (is_si_special(info) || - 853 info->si_code >= 0))); - 854 if (q) { - 855 list_add_tail(&q->list, &pending->list); - ... - 890 } - -and:: - - 1309 int send_sigqueue(struct sigqueue *q, struct task_struct *t, int group) - 1310 { - .... - 1339 pending = group ? &t->signal->shared_pending : &t->pending; - 1340 list_add_tail(&q->list, &pending->list); - .... - 1347 } - -In the first case, the list element we are looking for, ``q``, is being -returned from the function ``__sigqueue_alloc()``, which looks like an -allocation function. Let's take a look at it:: - - 187 static struct sigqueue *__sigqueue_alloc(struct task_struct *t, gfp_t flags, - 188 int override_rlimit) - 189 { - 190 struct sigqueue *q = NULL; - 191 struct user_struct *user; - 192 - 193 /* - 194 * We won't get problems with the target's UID changing under us - 195 * because changing it requires RCU be used, and if t != current, the - 196 * caller must be holding the RCU readlock (by way of a spinlock) and - 197 * we use RCU protection here - 198 */ - 199 user = get_uid(__task_cred(t)->user); - 200 atomic_inc(&user->sigpending); - 201 if (override_rlimit || - 202 atomic_read(&user->sigpending) <= - 203 t->signal->rlim[RLIMIT_SIGPENDING].rlim_cur) - 204 q = kmem_cache_alloc(sigqueue_cachep, flags); - 205 if (unlikely(q == NULL)) { - 206 atomic_dec(&user->sigpending); - 207 free_uid(user); - 208 } else { - 209 INIT_LIST_HEAD(&q->list); - 210 q->flags = 0; - 211 q->user = user; - 212 } - 213 - 214 return q; - 215 } - -We see that this function initializes ``q->list``, ``q->flags``, and -``q->user``. It seems that now is the time to look at the definition of -``struct sigqueue``, e.g.:: - - 14 struct sigqueue { - 15 struct list_head list; - 16 int flags; - 17 siginfo_t info; - 18 struct user_struct *user; - 19 }; - -And, you might remember, it was a ``memcpy()`` on ``&first->info`` that -caused the warning, so this makes perfect sense. It also seems reasonable -to assume that it is the caller of ``__sigqueue_alloc()`` that has the -responsibility of filling out (initializing) this member. - -But just which fields of the struct were uninitialized? Let's look at -kmemcheck's report again:: - - WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - ^ - -These first two lines are the memory dump of the memory object itself, and -the shadow bytemap, respectively. The memory object itself is in this case -``&first->info``. Just beware that the start of this dump is NOT the start -of the object itself! The position of the caret (^) corresponds with the -address of the read (ffff88003e4a2024). - -The shadow bytemap dump legend is as follows: - -- i: initialized -- u: uninitialized -- a: unallocated (memory has been allocated by the slab layer, but has not - yet been handed off to anybody) -- f: freed (memory has been allocated by the slab layer, but has been freed - by the previous owner) - -In order to figure out where (relative to the start of the object) the -uninitialized memory was located, we have to look at the disassembly. For -that, we'll need the RIP address again:: - - RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190 - - $ objdump -d --no-show-raw-insn vmlinux | grep -C 8 ffffffff8104ede8: - ffffffff8104edc8: mov %r8,0x8(%r8) - ffffffff8104edcc: test %r10d,%r10d - ffffffff8104edcf: js ffffffff8104ee88 <__dequeue_signal+0x168> - ffffffff8104edd5: mov %rax,%rdx - ffffffff8104edd8: mov $0xc,%ecx - ffffffff8104eddd: mov %r13,%rdi - ffffffff8104ede0: mov $0x30,%eax - ffffffff8104ede5: mov %rdx,%rsi - ffffffff8104ede8: rep movsl %ds:(%rsi),%es:(%rdi) - ffffffff8104edea: test $0x2,%al - ffffffff8104edec: je ffffffff8104edf0 <__dequeue_signal+0xd0> - ffffffff8104edee: movsw %ds:(%rsi),%es:(%rdi) - ffffffff8104edf0: test $0x1,%al - ffffffff8104edf2: je ffffffff8104edf5 <__dequeue_signal+0xd5> - ffffffff8104edf4: movsb %ds:(%rsi),%es:(%rdi) - ffffffff8104edf5: mov %r8,%rdi - ffffffff8104edf8: callq ffffffff8104de60 <__sigqueue_free> - -As expected, it's the "``rep movsl``" instruction from the ``memcpy()`` -that causes the warning. We know about ``REP MOVSL`` that it uses the register -``RCX`` to count the number of remaining iterations. By taking a look at the -register dump again (from the kmemcheck report), we can figure out how many -bytes were left to copy:: - - RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 - -By looking at the disassembly, we also see that ``%ecx`` is being loaded -with the value ``$0xc`` just before (ffffffff8104edd8), so we are very -lucky. Keep in mind that this is the number of iterations, not bytes. And -since this is a "long" operation, we need to multiply by 4 to get the -number of bytes. So this means that the uninitialized value was encountered -at 4 * (0xc - 0x9) = 12 bytes from the start of the object. - -We can now try to figure out which field of the "``struct siginfo``" that -was not initialized. This is the beginning of the struct:: - - 40 typedef struct siginfo { - 41 int si_signo; - 42 int si_errno; - 43 int si_code; - 44 - 45 union { - .. - 92 } _sifields; - 93 } siginfo_t; - -On 64-bit, the int is 4 bytes long, so it must the union member that has -not been initialized. We can verify this using gdb:: - - $ gdb vmlinux - ... - (gdb) p &((struct siginfo *) 0)->_sifields - $1 = (union {...} *) 0x10 - -Actually, it seems that the union member is located at offset 0x10 -- which -means that gcc has inserted 4 bytes of padding between the members ``si_code`` -and ``_sifields``. We can now get a fuller picture of the memory dump:: - - _----------------------------=> si_code - / _--------------------=> (padding) - | / _------------=> _sifields(._kill._pid) - | | / _----=> _sifields(._kill._uid) - | | | / - -------|-------|-------|-------| - 80000000000000000000000000000000000000000088ffff0000000000000000 - i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u - -This allows us to realize another important fact: ``si_code`` contains the -value 0x80. Remember that x86 is little endian, so the first 4 bytes -"80000000" are really the number 0x00000080. With a bit of research, we -find that this is actually the constant ``SI_KERNEL`` defined in -``include/asm-generic/siginfo.h``:: - - 144 #define SI_KERNEL 0x80 /* sent by the kernel from somewhere */ - -This macro is used in exactly one place in the x86 kernel: In ``send_signal()`` -in ``kernel/signal.c``:: - - 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, - 817 int group) - 818 { - ... - 828 pending = group ? &t->signal->shared_pending : &t->pending; - ... - 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && - 852 (is_si_special(info) || - 853 info->si_code >= 0))); - 854 if (q) { - 855 list_add_tail(&q->list, &pending->list); - 856 switch ((unsigned long) info) { - ... - 865 case (unsigned long) SEND_SIG_PRIV: - 866 q->info.si_signo = sig; - 867 q->info.si_errno = 0; - 868 q->info.si_code = SI_KERNEL; - 869 q->info.si_pid = 0; - 870 q->info.si_uid = 0; - 871 break; - ... - 890 } - -Not only does this match with the ``.si_code`` member, it also matches the place -we found earlier when looking for where siginfo_t objects are enqueued on the -``shared_pending`` list. - -So to sum up: It seems that it is the padding introduced by the compiler -between two struct fields that is uninitialized, and this gets reported when -we do a ``memcpy()`` on the struct. This means that we have identified a false -positive warning. - -Normally, kmemcheck will not report uninitialized accesses in ``memcpy()`` calls -when both the source and destination addresses are tracked. (Instead, we copy -the shadow bytemap as well). In this case, the destination address clearly -was not tracked. We can dig a little deeper into the stack trace from above:: - - arch/x86/kernel/signal.c:805 - arch/x86/kernel/signal.c:871 - arch/x86/kernel/entry_64.S:694 - -And we clearly see that the destination siginfo object is located on the -stack:: - - 782 static void do_signal(struct pt_regs *regs) - 783 { - 784 struct k_sigaction ka; - 785 siginfo_t info; - ... - 804 signr = get_signal_to_deliver(&info, &ka, regs, NULL); - ... - 854 } - -And this ``&info`` is what eventually gets passed to ``copy_siginfo()`` as the -destination argument. - -Now, even though we didn't find an actual error here, the example is still a -good one, because it shows how one would go about to find out what the report -was all about. - - -Annotating false positives -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are a few different ways to make annotations in the source code that -will keep kmemcheck from checking and reporting certain allocations. Here -they are: - -- ``__GFP_NOTRACK_FALSE_POSITIVE`` - This flag can be passed to ``kmalloc()`` or ``kmem_cache_alloc()`` - (therefore also to other functions that end up calling one of - these) to indicate that the allocation should not be tracked - because it would lead to a false positive report. This is a "big - hammer" way of silencing kmemcheck; after all, even if the false - positive pertains to particular field in a struct, for example, we - will now lose the ability to find (real) errors in other parts of - the same struct. - - Example:: - - /* No warnings will ever trigger on accessing any part of x */ - x = kmalloc(sizeof *x, GFP_KERNEL | __GFP_NOTRACK_FALSE_POSITIVE); - -- ``kmemcheck_bitfield_begin(name)``/``kmemcheck_bitfield_end(name)`` and - ``kmemcheck_annotate_bitfield(ptr, name)`` - The first two of these three macros can be used inside struct - definitions to signal, respectively, the beginning and end of a - bitfield. Additionally, this will assign the bitfield a name, which - is given as an argument to the macros. - - Having used these markers, one can later use - kmemcheck_annotate_bitfield() at the point of allocation, to indicate - which parts of the allocation is part of a bitfield. - - Example:: - - struct foo { - int x; - - kmemcheck_bitfield_begin(flags); - int flag_a:1; - int flag_b:1; - kmemcheck_bitfield_end(flags); - - int y; - }; - - struct foo *x = kmalloc(sizeof *x); - - /* No warnings will trigger on accessing the bitfield of x */ - kmemcheck_annotate_bitfield(x, flags); - - Note that ``kmemcheck_annotate_bitfield()`` can be used even before the - return value of ``kmalloc()`` is checked -- in other words, passing NULL - as the first argument is legal (and will do nothing). - - -Reporting errors ----------------- - -As we have seen, kmemcheck will produce false positive reports. Therefore, it -is not very wise to blindly post kmemcheck warnings to mailing lists and -maintainers. Instead, I encourage maintainers and developers to find errors -in their own code. If you get a warning, you can try to work around it, try -to figure out if it's a real error or not, or simply ignore it. Most -developers know their own code and will quickly and efficiently determine the -root cause of a kmemcheck report. This is therefore also the most efficient -way to work with kmemcheck. - -That said, we (the kmemcheck maintainers) will always be on the lookout for -false positives that we can annotate and silence. So whatever you find, -please drop us a note privately! Kernel configs and steps to reproduce (if -available) are of course a great help too. - -Happy hacking! - - -Technical description ---------------------- - -kmemcheck works by marking memory pages non-present. This means that whenever -somebody attempts to access the page, a page fault is generated. The page -fault handler notices that the page was in fact only hidden, and so it calls -on the kmemcheck code to make further investigations. - -When the investigations are completed, kmemcheck "shows" the page by marking -it present (as it would be under normal circumstances). This way, the -interrupted code can continue as usual. - -But after the instruction has been executed, we should hide the page again, so -that we can catch the next access too! Now kmemcheck makes use of a debugging -feature of the processor, namely single-stepping. When the processor has -finished the one instruction that generated the memory access, a debug -exception is raised. From here, we simply hide the page again and continue -execution, this time with the single-stepping feature turned off. - -kmemcheck requires some assistance from the memory allocator in order to work. -The memory allocator needs to - - 1. Tell kmemcheck about newly allocated pages and pages that are about to - be freed. This allows kmemcheck to set up and tear down the shadow memory - for the pages in question. The shadow memory stores the status of each - byte in the allocation proper, e.g. whether it is initialized or - uninitialized. - - 2. Tell kmemcheck which parts of memory should be marked uninitialized. - There are actually a few more states, such as "not yet allocated" and - "recently freed". - -If a slab cache is set up using the SLAB_NOTRACK flag, it will never return -memory that can take page faults because of kmemcheck. - -If a slab cache is NOT set up using the SLAB_NOTRACK flag, callers can still -request memory with the __GFP_NOTRACK or __GFP_NOTRACK_FALSE_POSITIVE flags. -This does not prevent the page faults from occurring, however, but marks the -object in question as being initialized so that no warnings will ever be -produced for this object. - -Currently, the SLAB and SLUB allocators are supported by kmemcheck. --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7670,16 +7670,6 @@ F: include/linux/kdb.h F: include/linux/kgdb.h F: kernel/debug/ -KMEMCHECK -M: Vegard Nossum <vegardno(a)ifi.uio.no> -M: Pekka Enberg <penberg(a)kernel.org> -S: Maintained -F: Documentation/dev-tools/kmemcheck.rst -F: arch/x86/include/asm/kmemcheck.h -F: arch/x86/mm/kmemcheck/ -F: include/linux/kmemcheck.h -F: mm/kmemcheck.c - KMEMLEAK M: Catalin Marinas <catalin.marinas(a)arm.com> S: Maintained --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -111,7 +111,6 @@ config X86 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KASAN if X86_64 select HAVE_ARCH_KGDB - select HAVE_ARCH_KMEMCHECK select HAVE_ARCH_MMAP_RND_BITS if MMU select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT select HAVE_ARCH_COMPAT_MMAP_BASES if MMU && COMPAT @@ -1443,7 +1442,7 @@ config ARCH_DMA_ADDR_T_64BIT config X86_DIRECT_GBPAGES def_bool y - depends on X86_64 && !DEBUG_PAGEALLOC && !KMEMCHECK + depends on X86_64 && !DEBUG_PAGEALLOC ---help--- Certain kernel features effectively disable kernel linear 1 GB mappings (even if the CPU otherwise --- a/arch/x86/include/asm/kmemcheck.h +++ b/arch/x86/include/asm/kmemcheck.h @@ -1,43 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ASM_X86_KMEMCHECK_H -#define ASM_X86_KMEMCHECK_H - -#include <linux/types.h> -#include <asm/ptrace.h> - -#ifdef CONFIG_KMEMCHECK -bool kmemcheck_active(struct pt_regs *regs); - -void kmemcheck_show(struct pt_regs *regs); -void kmemcheck_hide(struct pt_regs *regs); - -bool kmemcheck_fault(struct pt_regs *regs, - unsigned long address, unsigned long error_code); -bool kmemcheck_trap(struct pt_regs *regs); -#else -static inline bool kmemcheck_active(struct pt_regs *regs) -{ - return false; -} - -static inline void kmemcheck_show(struct pt_regs *regs) -{ -} - -static inline void kmemcheck_hide(struct pt_regs *regs) -{ -} - -static inline bool kmemcheck_fault(struct pt_regs *regs, - unsigned long address, unsigned long error_code) -{ - return false; -} - -static inline bool kmemcheck_trap(struct pt_regs *regs) -{ - return false; -} -#endif /* CONFIG_KMEMCHECK */ - -#endif --- a/arch/x86/include/asm/string_32.h +++ b/arch/x86/include/asm/string_32.h @@ -179,8 +179,6 @@ static inline void *__memcpy3d(void *to, * No 3D Now! */ -#ifndef CONFIG_KMEMCHECK - #if (__GNUC__ >= 4) #define memcpy(t, f, n) __builtin_memcpy(t, f, n) #else @@ -189,13 +187,6 @@ static inline void *__memcpy3d(void *to, ? __constant_memcpy((t), (f), (n)) \ : __memcpy((t), (f), (n))) #endif -#else -/* - * kmemcheck becomes very happy if we use the REP instructions unconditionally, - * because it means that we know both memory operands in advance. - */ -#define memcpy(t, f, n) __memcpy((t), (f), (n)) -#endif #endif #endif /* !CONFIG_FORTIFY_SOURCE */ --- a/arch/x86/include/asm/string_64.h +++ b/arch/x86/include/asm/string_64.h @@ -33,7 +33,6 @@ extern void *memcpy(void *to, const void extern void *__memcpy(void *to, const void *from, size_t len); #ifndef CONFIG_FORTIFY_SOURCE -#ifndef CONFIG_KMEMCHECK #if (__GNUC__ == 4 && __GNUC_MINOR__ < 3) || __GNUC__ < 4 #define memcpy(dst, src, len) \ ({ \ @@ -46,13 +45,6 @@ extern void *__memcpy(void *to, const vo __ret; \ }) #endif -#else -/* - * kmemcheck becomes very happy if we use the REP instructions unconditionally, - * because it means that we know both memory operands in advance. - */ -#define memcpy(dst, src, len) __inline_memcpy((dst), (src), (len)) -#endif #endif /* !CONFIG_FORTIFY_SOURCE */ #define __HAVE_ARCH_MEMSET --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -250,21 +250,6 @@ static void early_init_intel(struct cpui if (c->x86 == 6 && c->x86_model < 15) clear_cpu_cap(c, X86_FEATURE_PAT); -#ifdef CONFIG_KMEMCHECK - /* - * P4s have a "fast strings" feature which causes single- - * stepping REP instructions to only generate a #DB on - * cache-line boundaries. - * - * Ingo Molnar reported a Pentium D (model 6) and a Xeon - * (model 2) with the same problem. - */ - if (c->x86 == 15) - if (msr_clear_bit(MSR_IA32_MISC_ENABLE, - MSR_IA32_MISC_ENABLE_FAST_STRING_BIT) > 0) - pr_info("kmemcheck: Disabling fast string operations\n"); -#endif - /* * If fast string is not enabled in IA32_MISC_ENABLE for any reason, * clear the fast string and enhanced fast string CPU capabilities. --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -29,8 +29,6 @@ obj-$(CONFIG_X86_PTDUMP) += debug_pageta obj-$(CONFIG_HIGHMEM) += highmem_32.o -obj-$(CONFIG_KMEMCHECK) += kmemcheck/ - KASAN_SANITIZE_kasan_init_$(BITS).o := n obj-$(CONFIG_KASAN) += kasan_init_$(BITS).o --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -170,12 +170,11 @@ static void enable_global_pages(void) static void __init probe_page_size_mask(void) { /* - * For CONFIG_KMEMCHECK or pagealloc debugging, identity mapping will - * use small pages. + * For pagealloc debugging, identity mapping will use small pages. * This will simplify cpa(), which otherwise needs to support splitting * large pages into small in interrupt context, etc. */ - if (boot_cpu_has(X86_FEATURE_PSE) && !debug_pagealloc_enabled() && !IS_ENABLED(CONFIG_KMEMCHECK)) + if (boot_cpu_has(X86_FEATURE_PSE) && !debug_pagealloc_enabled()) page_size_mask |= 1 << PG_LEVEL_2M; else direct_gbpages = 0; --- a/arch/x86/mm/kmemcheck/Makefile +++ /dev/null @@ -1 +0,0 @@ -obj-y := error.o kmemcheck.o opcode.o pte.o selftest.o shadow.o --- a/arch/x86/mm/kmemcheck/error.c +++ b/arch/x86/mm/kmemcheck/error.c @@ -1,228 +1 @@ // SPDX-License-Identifier: GPL-2.0 -#include <linux/interrupt.h> -#include <linux/kdebug.h> -#include <linux/kmemcheck.h> -#include <linux/kernel.h> -#include <linux/types.h> -#include <linux/ptrace.h> -#include <linux/stacktrace.h> -#include <linux/string.h> - -#include "error.h" -#include "shadow.h" - -enum kmemcheck_error_type { - KMEMCHECK_ERROR_INVALID_ACCESS, - KMEMCHECK_ERROR_BUG, -}; - -#define SHADOW_COPY_SIZE (1 << CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT) - -struct kmemcheck_error { - enum kmemcheck_error_type type; - - union { - /* KMEMCHECK_ERROR_INVALID_ACCESS */ - struct { - /* Kind of access that caused the error */ - enum kmemcheck_shadow state; - /* Address and size of the erroneous read */ - unsigned long address; - unsigned int size; - }; - }; - - struct pt_regs regs; - struct stack_trace trace; - unsigned long trace_entries[32]; - - /* We compress it to a char. */ - unsigned char shadow_copy[SHADOW_COPY_SIZE]; - unsigned char memory_copy[SHADOW_COPY_SIZE]; -}; - -/* - * Create a ring queue of errors to output. We can't call printk() directly - * from the kmemcheck traps, since this may call the console drivers and - * result in a recursive fault. - */ -static struct kmemcheck_error error_fifo[CONFIG_KMEMCHECK_QUEUE_SIZE]; -static unsigned int error_count; -static unsigned int error_rd; -static unsigned int error_wr; -static unsigned int error_missed_count; - -static struct kmemcheck_error *error_next_wr(void) -{ - struct kmemcheck_error *e; - - if (error_count == ARRAY_SIZE(error_fifo)) { - ++error_missed_count; - return NULL; - } - - e = &error_fifo[error_wr]; - if (++error_wr == ARRAY_SIZE(error_fifo)) - error_wr = 0; - ++error_count; - return e; -} - -static struct kmemcheck_error *error_next_rd(void) -{ - struct kmemcheck_error *e; - - if (error_count == 0) - return NULL; - - e = &error_fifo[error_rd]; - if (++error_rd == ARRAY_SIZE(error_fifo)) - error_rd = 0; - --error_count; - return e; -} - -void kmemcheck_error_recall(void) -{ - static const char *desc[] = { - [KMEMCHECK_SHADOW_UNALLOCATED] = "unallocated", - [KMEMCHECK_SHADOW_UNINITIALIZED] = "uninitialized", - [KMEMCHECK_SHADOW_INITIALIZED] = "initialized", - [KMEMCHECK_SHADOW_FREED] = "freed", - }; - - static const char short_desc[] = { - [KMEMCHECK_SHADOW_UNALLOCATED] = 'a', - [KMEMCHECK_SHADOW_UNINITIALIZED] = 'u', - [KMEMCHECK_SHADOW_INITIALIZED] = 'i', - [KMEMCHECK_SHADOW_FREED] = 'f', - }; - - struct kmemcheck_error *e; - unsigned int i; - - e = error_next_rd(); - if (!e) - return; - - switch (e->type) { - case KMEMCHECK_ERROR_INVALID_ACCESS: - printk(KERN_WARNING "WARNING: kmemcheck: Caught %d-bit read from %s memory (%p)\n", - 8 * e->size, e->state < ARRAY_SIZE(desc) ? - desc[e->state] : "(invalid shadow state)", - (void *) e->address); - - printk(KERN_WARNING); - for (i = 0; i < SHADOW_COPY_SIZE; ++i) - printk(KERN_CONT "%02x", e->memory_copy[i]); - printk(KERN_CONT "\n"); - - printk(KERN_WARNING); - for (i = 0; i < SHADOW_COPY_SIZE; ++i) { - if (e->shadow_copy[i] < ARRAY_SIZE(short_desc)) - printk(KERN_CONT " %c", short_desc[e->shadow_copy[i]]); - else - printk(KERN_CONT " ?"); - } - printk(KERN_CONT "\n"); - printk(KERN_WARNING "%*c\n", 2 + 2 - * (int) (e->address & (SHADOW_COPY_SIZE - 1)), '^'); - break; - case KMEMCHECK_ERROR_BUG: - printk(KERN_EMERG "ERROR: kmemcheck: Fatal error\n"); - break; - } - - __show_regs(&e->regs, 1); - print_stack_trace(&e->trace, 0); -} - -static void do_wakeup(unsigned long data) -{ - while (error_count > 0) - kmemcheck_error_recall(); - - if (error_missed_count > 0) { - printk(KERN_WARNING "kmemcheck: Lost %d error reports because " - "the queue was too small\n", error_missed_count); - error_missed_count = 0; - } -} - -static DECLARE_TASKLET(kmemcheck_tasklet, &do_wakeup, 0); - -/* - * Save the context of an error report. - */ -void kmemcheck_error_save(enum kmemcheck_shadow state, - unsigned long address, unsigned int size, struct pt_regs *regs) -{ - static unsigned long prev_ip; - - struct kmemcheck_error *e; - void *shadow_copy; - void *memory_copy; - - /* Don't report several adjacent errors from the same EIP. */ - if (regs->ip == prev_ip) - return; - prev_ip = regs->ip; - - e = error_next_wr(); - if (!e) - return; - - e->type = KMEMCHECK_ERROR_INVALID_ACCESS; - - e->state = state; - e->address = address; - e->size = size; - - /* Save regs */ - memcpy(&e->regs, regs, sizeof(*regs)); - - /* Save stack trace */ - e->trace.nr_entries = 0; - e->trace.entries = e->trace_entries; - e->trace.max_entries = ARRAY_SIZE(e->trace_entries); - e->trace.skip = 0; - save_stack_trace_regs(regs, &e->trace); - - /* Round address down to nearest 16 bytes */ - shadow_copy = kmemcheck_shadow_lookup(address - & ~(SHADOW_COPY_SIZE - 1)); - BUG_ON(!shadow_copy); - - memcpy(e->shadow_copy, shadow_copy, SHADOW_COPY_SIZE); - - kmemcheck_show_addr(address); - memory_copy = (void *) (address & ~(SHADOW_COPY_SIZE - 1)); - memcpy(e->memory_copy, memory_copy, SHADOW_COPY_SIZE); - kmemcheck_hide_addr(address); - - tasklet_hi_schedule_first(&kmemcheck_tasklet); -} - -/* - * Save the context of a kmemcheck bug. - */ -void kmemcheck_error_save_bug(struct pt_regs *regs) -{ - struct kmemcheck_error *e; - - e = error_next_wr(); - if (!e) - return; - - e->type = KMEMCHECK_ERROR_BUG; - - memcpy(&e->regs, regs, sizeof(*regs)); - - e->trace.nr_entries = 0; - e->trace.entries = e->trace_entries; - e->trace.max_entries = ARRAY_SIZE(e->trace_entries); - e->trace.skip = 1; - save_stack_trace(&e->trace); - - tasklet_hi_schedule_first(&kmemcheck_tasklet); -} --- a/arch/x86/mm/kmemcheck/error.h +++ b/arch/x86/mm/kmemcheck/error.h @@ -1,16 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ARCH__X86__MM__KMEMCHECK__ERROR_H -#define ARCH__X86__MM__KMEMCHECK__ERROR_H - -#include <linux/ptrace.h> - -#include "shadow.h" - -void kmemcheck_error_save(enum kmemcheck_shadow state, - unsigned long address, unsigned int size, struct pt_regs *regs); - -void kmemcheck_error_save_bug(struct pt_regs *regs); - -void kmemcheck_error_recall(void); - -#endif --- a/arch/x86/mm/kmemcheck/kmemcheck.c +++ /dev/null @@ -1,658 +0,0 @@ -/** - * kmemcheck - a heavyweight memory checker for the linux kernel - * Copyright (C) 2007, 2008 Vegard Nossum <vegardno(a)ifi.uio.no> - * (With a lot of help from Ingo Molnar and Pekka Enberg.) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License (version 2) as - * published by the Free Software Foundation. - */ - -#include <linux/init.h> -#include <linux/interrupt.h> -#include <linux/kallsyms.h> -#include <linux/kernel.h> -#include <linux/kmemcheck.h> -#include <linux/mm.h> -#include <linux/page-flags.h> -#include <linux/percpu.h> -#include <linux/ptrace.h> -#include <linux/string.h> -#include <linux/types.h> - -#include <asm/cacheflush.h> -#include <asm/kmemcheck.h> -#include <asm/pgtable.h> -#include <asm/tlbflush.h> - -#include "error.h" -#include "opcode.h" -#include "pte.h" -#include "selftest.h" -#include "shadow.h" - - -#ifdef CONFIG_KMEMCHECK_DISABLED_BY_DEFAULT -# define KMEMCHECK_ENABLED 0 -#endif - -#ifdef CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT -# define KMEMCHECK_ENABLED 1 -#endif - -#ifdef CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT -# define KMEMCHECK_ENABLED 2 -#endif - -int kmemcheck_enabled = KMEMCHECK_ENABLED; - -int __init kmemcheck_init(void) -{ -#ifdef CONFIG_SMP - /* - * Limit SMP to use a single CPU. We rely on the fact that this code - * runs before SMP is set up. - */ - if (setup_max_cpus > 1) { - printk(KERN_INFO - "kmemcheck: Limiting number of CPUs to 1.\n"); - setup_max_cpus = 1; - } -#endif - - if (!kmemcheck_selftest()) { - printk(KERN_INFO "kmemcheck: self-tests failed; disabling\n"); - kmemcheck_enabled = 0; - return -EINVAL; - } - - printk(KERN_INFO "kmemcheck: Initialized\n"); - return 0; -} - -early_initcall(kmemcheck_init); - -/* - * We need to parse the kmemcheck= option before any memory is allocated. - */ -static int __init param_kmemcheck(char *str) -{ - int val; - int ret; - - if (!str) - return -EINVAL; - - ret = kstrtoint(str, 0, &val); - if (ret) - return ret; - kmemcheck_enabled = val; - return 0; -} - -early_param("kmemcheck", param_kmemcheck); - -int kmemcheck_show_addr(unsigned long address) -{ - pte_t *pte; - - pte = kmemcheck_pte_lookup(address); - if (!pte) - return 0; - - set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT)); - __flush_tlb_one(address); - return 1; -} - -int kmemcheck_hide_addr(unsigned long address) -{ - pte_t *pte; - - pte = kmemcheck_pte_lookup(address); - if (!pte) - return 0; - - set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT)); - __flush_tlb_one(address); - return 1; -} - -struct kmemcheck_context { - bool busy; - int balance; - - /* - * There can be at most two memory operands to an instruction, but - * each address can cross a page boundary -- so we may need up to - * four addresses that must be hidden/revealed for each fault. - */ - unsigned long addr[4]; - unsigned long n_addrs; - unsigned long flags; - - /* Data size of the instruction that caused a fault. */ - unsigned int size; -}; - -static DEFINE_PER_CPU(struct kmemcheck_context, kmemcheck_context); - -bool kmemcheck_active(struct pt_regs *regs) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - - return data->balance > 0; -} - -/* Save an address that needs to be shown/hidden */ -static void kmemcheck_save_addr(unsigned long addr) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - - BUG_ON(data->n_addrs >= ARRAY_SIZE(data->addr)); - data->addr[data->n_addrs++] = addr; -} - -static unsigned int kmemcheck_show_all(void) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - unsigned int i; - unsigned int n; - - n = 0; - for (i = 0; i < data->n_addrs; ++i) - n += kmemcheck_show_addr(data->addr[i]); - - return n; -} - -static unsigned int kmemcheck_hide_all(void) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - unsigned int i; - unsigned int n; - - n = 0; - for (i = 0; i < data->n_addrs; ++i) - n += kmemcheck_hide_addr(data->addr[i]); - - return n; -} - -/* - * Called from the #PF handler. - */ -void kmemcheck_show(struct pt_regs *regs) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - - BUG_ON(!irqs_disabled()); - - if (unlikely(data->balance != 0)) { - kmemcheck_show_all(); - kmemcheck_error_save_bug(regs); - data->balance = 0; - return; - } - - /* - * None of the addresses actually belonged to kmemcheck. Note that - * this is not an error. - */ - if (kmemcheck_show_all() == 0) - return; - - ++data->balance; - - /* - * The IF needs to be cleared as well, so that the faulting - * instruction can run "uninterrupted". Otherwise, we might take - * an interrupt and start executing that before we've had a chance - * to hide the page again. - * - * NOTE: In the rare case of multiple faults, we must not override - * the original flags: - */ - if (!(regs->flags & X86_EFLAGS_TF)) - data->flags = regs->flags; - - regs->flags |= X86_EFLAGS_TF; - regs->flags &= ~X86_EFLAGS_IF; -} - -/* - * Called from the #DB handler. - */ -void kmemcheck_hide(struct pt_regs *regs) -{ - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - int n; - - BUG_ON(!irqs_disabled()); - - if (unlikely(data->balance != 1)) { - kmemcheck_show_all(); - kmemcheck_error_save_bug(regs); - data->n_addrs = 0; - data->balance = 0; - - if (!(data->flags & X86_EFLAGS_TF)) - regs->flags &= ~X86_EFLAGS_TF; - if (data->flags & X86_EFLAGS_IF) - regs->flags |= X86_EFLAGS_IF; - return; - } - - if (kmemcheck_enabled) - n = kmemcheck_hide_all(); - else - n = kmemcheck_show_all(); - - if (n == 0) - return; - - --data->balance; - - data->n_addrs = 0; - - if (!(data->flags & X86_EFLAGS_TF)) - regs->flags &= ~X86_EFLAGS_TF; - if (data->flags & X86_EFLAGS_IF) - regs->flags |= X86_EFLAGS_IF; -} - -void kmemcheck_show_pages(struct page *p, unsigned int n) -{ - unsigned int i; - - for (i = 0; i < n; ++i) { - unsigned long address; - pte_t *pte; - unsigned int level; - - address = (unsigned long) page_address(&p[i]); - pte = lookup_address(address, &level); - BUG_ON(!pte); - BUG_ON(level != PG_LEVEL_4K); - - set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT)); - set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_HIDDEN)); - __flush_tlb_one(address); - } -} - -bool kmemcheck_page_is_tracked(struct page *p) -{ - /* This will also check the "hidden" flag of the PTE. */ - return kmemcheck_pte_lookup((unsigned long) page_address(p)); -} - -void kmemcheck_hide_pages(struct page *p, unsigned int n) -{ - unsigned int i; - - for (i = 0; i < n; ++i) { - unsigned long address; - pte_t *pte; - unsigned int level; - - address = (unsigned long) page_address(&p[i]); - pte = lookup_address(address, &level); - BUG_ON(!pte); - BUG_ON(level != PG_LEVEL_4K); - - set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT)); - set_pte(pte, __pte(pte_val(*pte) | _PAGE_HIDDEN)); - __flush_tlb_one(address); - } -} - -/* Access may NOT cross page boundary */ -static void kmemcheck_read_strict(struct pt_regs *regs, - unsigned long addr, unsigned int size) -{ - void *shadow; - enum kmemcheck_shadow status; - - shadow = kmemcheck_shadow_lookup(addr); - if (!shadow) - return; - - kmemcheck_save_addr(addr); - status = kmemcheck_shadow_test(shadow, size); - if (status == KMEMCHECK_SHADOW_INITIALIZED) - return; - - if (kmemcheck_enabled) - kmemcheck_error_save(status, addr, size, regs); - - if (kmemcheck_enabled == 2) - kmemcheck_enabled = 0; - - /* Don't warn about it again. */ - kmemcheck_shadow_set(shadow, size); -} - -bool kmemcheck_is_obj_initialized(unsigned long addr, size_t size) -{ - enum kmemcheck_shadow status; - void *shadow; - - shadow = kmemcheck_shadow_lookup(addr); - if (!shadow) - return true; - - status = kmemcheck_shadow_test_all(shadow, size); - - return status == KMEMCHECK_SHADOW_INITIALIZED; -} - -/* Access may cross page boundary */ -static void kmemcheck_read(struct pt_regs *regs, - unsigned long addr, unsigned int size) -{ - unsigned long page = addr & PAGE_MASK; - unsigned long next_addr = addr + size - 1; - unsigned long next_page = next_addr & PAGE_MASK; - - if (likely(page == next_page)) { - kmemcheck_read_strict(regs, addr, size); - return; - } - - /* - * What we do is basically to split the access across the - * two pages and handle each part separately. Yes, this means - * that we may now see reads that are 3 + 5 bytes, for - * example (and if both are uninitialized, there will be two - * reports), but it makes the code a lot simpler. - */ - kmemcheck_read_strict(regs, addr, next_page - addr); - kmemcheck_read_strict(regs, next_page, next_addr - next_page); -} - -static void kmemcheck_write_strict(struct pt_regs *regs, - unsigned long addr, unsigned int size) -{ - void *shadow; - - shadow = kmemcheck_shadow_lookup(addr); - if (!shadow) - return; - - kmemcheck_save_addr(addr); - kmemcheck_shadow_set(shadow, size); -} - -static void kmemcheck_write(struct pt_regs *regs, - unsigned long addr, unsigned int size) -{ - unsigned long page = addr & PAGE_MASK; - unsigned long next_addr = addr + size - 1; - unsigned long next_page = next_addr & PAGE_MASK; - - if (likely(page == next_page)) { - kmemcheck_write_strict(regs, addr, size); - return; - } - - /* See comment in kmemcheck_read(). */ - kmemcheck_write_strict(regs, addr, next_page - addr); - kmemcheck_write_strict(regs, next_page, next_addr - next_page); -} - -/* - * Copying is hard. We have two addresses, each of which may be split across - * a page (and each page will have different shadow addresses). - */ -static void kmemcheck_copy(struct pt_regs *regs, - unsigned long src_addr, unsigned long dst_addr, unsigned int size) -{ - uint8_t shadow[8]; - enum kmemcheck_shadow status; - - unsigned long page; - unsigned long next_addr; - unsigned long next_page; - - uint8_t *x; - unsigned int i; - unsigned int n; - - BUG_ON(size > sizeof(shadow)); - - page = src_addr & PAGE_MASK; - next_addr = src_addr + size - 1; - next_page = next_addr & PAGE_MASK; - - if (likely(page == next_page)) { - /* Same page */ - x = kmemcheck_shadow_lookup(src_addr); - if (x) { - kmemcheck_save_addr(src_addr); - for (i = 0; i < size; ++i) - shadow[i] = x[i]; - } else { - for (i = 0; i < size; ++i) - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - } else { - n = next_page - src_addr; - BUG_ON(n > sizeof(shadow)); - - /* First page */ - x = kmemcheck_shadow_lookup(src_addr); - if (x) { - kmemcheck_save_addr(src_addr); - for (i = 0; i < n; ++i) - shadow[i] = x[i]; - } else { - /* Not tracked */ - for (i = 0; i < n; ++i) - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - - /* Second page */ - x = kmemcheck_shadow_lookup(next_page); - if (x) { - kmemcheck_save_addr(next_page); - for (i = n; i < size; ++i) - shadow[i] = x[i - n]; - } else { - /* Not tracked */ - for (i = n; i < size; ++i) - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - } - - page = dst_addr & PAGE_MASK; - next_addr = dst_addr + size - 1; - next_page = next_addr & PAGE_MASK; - - if (likely(page == next_page)) { - /* Same page */ - x = kmemcheck_shadow_lookup(dst_addr); - if (x) { - kmemcheck_save_addr(dst_addr); - for (i = 0; i < size; ++i) { - x[i] = shadow[i]; - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - } - } else { - n = next_page - dst_addr; - BUG_ON(n > sizeof(shadow)); - - /* First page */ - x = kmemcheck_shadow_lookup(dst_addr); - if (x) { - kmemcheck_save_addr(dst_addr); - for (i = 0; i < n; ++i) { - x[i] = shadow[i]; - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - } - - /* Second page */ - x = kmemcheck_shadow_lookup(next_page); - if (x) { - kmemcheck_save_addr(next_page); - for (i = n; i < size; ++i) { - x[i - n] = shadow[i]; - shadow[i] = KMEMCHECK_SHADOW_INITIALIZED; - } - } - } - - status = kmemcheck_shadow_test(shadow, size); - if (status == KMEMCHECK_SHADOW_INITIALIZED) - return; - - if (kmemcheck_enabled) - kmemcheck_error_save(status, src_addr, size, regs); - - if (kmemcheck_enabled == 2) - kmemcheck_enabled = 0; -} - -enum kmemcheck_method { - KMEMCHECK_READ, - KMEMCHECK_WRITE, -}; - -static void kmemcheck_access(struct pt_regs *regs, - unsigned long fallback_address, enum kmemcheck_method fallback_method) -{ - const uint8_t *insn; - const uint8_t *insn_primary; - unsigned int size; - - struct kmemcheck_context *data = this_cpu_ptr(&kmemcheck_context); - - /* Recursive fault -- ouch. */ - if (data->busy) { - kmemcheck_show_addr(fallback_address); - kmemcheck_error_save_bug(regs); - return; - } - - data->busy = true; - - insn = (const uint8_t *) regs->ip; - insn_primary = kmemcheck_opcode_get_primary(insn); - - kmemcheck_opcode_decode(insn, &size); - - switch (insn_primary[0]) { -#ifdef CONFIG_KMEMCHECK_BITOPS_OK - /* AND, OR, XOR */ - /* - * Unfortunately, these instructions have to be excluded from - * our regular checking since they access only some (and not - * all) bits. This clears out "bogus" bitfield-access warnings. - */ - case 0x80: - case 0x81: - case 0x82: - case 0x83: - switch ((insn_primary[1] >> 3) & 7) { - /* OR */ - case 1: - /* AND */ - case 4: - /* XOR */ - case 6: - kmemcheck_write(regs, fallback_address, size); - goto out; - - /* ADD */ - case 0: - /* ADC */ - case 2: - /* SBB */ - case 3: - /* SUB */ - case 5: - /* CMP */ - case 7: - break; - } - break; -#endif - - /* MOVS, MOVSB, MOVSW, MOVSD */ - case 0xa4: - case 0xa5: - /* - * These instructions are special because they take two - * addresses, but we only get one page fault. - */ - kmemcheck_copy(regs, regs->si, regs->di, size); - goto out; - - /* CMPS, CMPSB, CMPSW, CMPSD */ - case 0xa6: - case 0xa7: - kmemcheck_read(regs, regs->si, size); - kmemcheck_read(regs, regs->di, size); - goto out; - } - - /* - * If the opcode isn't special in any way, we use the data from the - * page fault handler to determine the address and type of memory - * access. - */ - switch (fallback_method) { - case KMEMCHECK_READ: - kmemcheck_read(regs, fallback_address, size); - goto out; - case KMEMCHECK_WRITE: - kmemcheck_write(regs, fallback_address, size); - goto out; - } - -out: - data->busy = false; -} - -bool kmemcheck_fault(struct pt_regs *regs, unsigned long address, - unsigned long error_code) -{ - pte_t *pte; - - /* - * XXX: Is it safe to assume that memory accesses from virtual 86 - * mode or non-kernel code segments will _never_ access kernel - * memory (e.g. tracked pages)? For now, we need this to avoid - * invoking kmemcheck for PnP BIOS calls. - */ - if (regs->flags & X86_VM_MASK) - return false; - if (regs->cs != __KERNEL_CS) - return false; - - pte = kmemcheck_pte_lookup(address); - if (!pte) - return false; - - WARN_ON_ONCE(in_nmi()); - - if (error_code & 2) - kmemcheck_access(regs, address, KMEMCHECK_WRITE); - else - kmemcheck_access(regs, address, KMEMCHECK_READ); - - kmemcheck_show(regs); - return true; -} - -bool kmemcheck_trap(struct pt_regs *regs) -{ - if (!kmemcheck_active(regs)) - return false; - - /* We're done. */ - kmemcheck_hide(regs); - return true; -} --- a/arch/x86/mm/kmemcheck/opcode.c +++ b/arch/x86/mm/kmemcheck/opcode.c @@ -1,107 +1 @@ // SPDX-License-Identifier: GPL-2.0 -#include <linux/types.h> - -#include "opcode.h" - -static bool opcode_is_prefix(uint8_t b) -{ - return - /* Group 1 */ - b == 0xf0 || b == 0xf2 || b == 0xf3 - /* Group 2 */ - || b == 0x2e || b == 0x36 || b == 0x3e || b == 0x26 - || b == 0x64 || b == 0x65 - /* Group 3 */ - || b == 0x66 - /* Group 4 */ - || b == 0x67; -} - -#ifdef CONFIG_X86_64 -static bool opcode_is_rex_prefix(uint8_t b) -{ - return (b & 0xf0) == 0x40; -} -#else -static bool opcode_is_rex_prefix(uint8_t b) -{ - return false; -} -#endif - -#define REX_W (1 << 3) - -/* - * This is a VERY crude opcode decoder. We only need to find the size of the - * load/store that caused our #PF and this should work for all the opcodes - * that we care about. Moreover, the ones who invented this instruction set - * should be shot. - */ -void kmemcheck_opcode_decode(const uint8_t *op, unsigned int *size) -{ - /* Default operand size */ - int operand_size_override = 4; - - /* prefixes */ - for (; opcode_is_prefix(*op); ++op) { - if (*op == 0x66) - operand_size_override = 2; - } - - /* REX prefix */ - if (opcode_is_rex_prefix(*op)) { - uint8_t rex = *op; - - ++op; - if (rex & REX_W) { - switch (*op) { - case 0x63: - *size = 4; - return; - case 0x0f: - ++op; - - switch (*op) { - case 0xb6: - case 0xbe: - *size = 1; - return; - case 0xb7: - case 0xbf: - *size = 2; - return; - } - - break; - } - - *size = 8; - return; - } - } - - /* escape opcode */ - if (*op == 0x0f) { - ++op; - - /* - * This is move with zero-extend and sign-extend, respectively; - * we don't have to think about 0xb6/0xbe, because this is - * already handled in the conditional below. - */ - if (*op == 0xb7 || *op == 0xbf) - operand_size_override = 2; - } - - *size = (*op & 1) ? operand_size_override : 1; -} - -const uint8_t *kmemcheck_opcode_get_primary(const uint8_t *op) -{ - /* skip prefixes */ - while (opcode_is_prefix(*op)) - ++op; - if (opcode_is_rex_prefix(*op)) - ++op; - return op; -} --- a/arch/x86/mm/kmemcheck/opcode.h +++ b/arch/x86/mm/kmemcheck/opcode.h @@ -1,10 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ARCH__X86__MM__KMEMCHECK__OPCODE_H -#define ARCH__X86__MM__KMEMCHECK__OPCODE_H - -#include <linux/types.h> - -void kmemcheck_opcode_decode(const uint8_t *op, unsigned int *size); -const uint8_t *kmemcheck_opcode_get_primary(const uint8_t *op); - -#endif --- a/arch/x86/mm/kmemcheck/pte.c +++ b/arch/x86/mm/kmemcheck/pte.c @@ -1,23 +1 @@ // SPDX-License-Identifier: GPL-2.0 -#include <linux/mm.h> - -#include <asm/pgtable.h> - -#include "pte.h" - -pte_t *kmemcheck_pte_lookup(unsigned long address) -{ - pte_t *pte; - unsigned int level; - - pte = lookup_address(address, &level); - if (!pte) - return NULL; - if (level != PG_LEVEL_4K) - return NULL; - if (!pte_hidden(*pte)) - return NULL; - - return pte; -} - --- a/arch/x86/mm/kmemcheck/pte.h +++ b/arch/x86/mm/kmemcheck/pte.h @@ -1,11 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ARCH__X86__MM__KMEMCHECK__PTE_H -#define ARCH__X86__MM__KMEMCHECK__PTE_H - -#include <linux/mm.h> - -#include <asm/pgtable.h> - -pte_t *kmemcheck_pte_lookup(unsigned long address); - -#endif --- a/arch/x86/mm/kmemcheck/selftest.c +++ b/arch/x86/mm/kmemcheck/selftest.c @@ -1,71 +1 @@ // SPDX-License-Identifier: GPL-2.0 -#include <linux/bug.h> -#include <linux/kernel.h> - -#include "opcode.h" -#include "selftest.h" - -struct selftest_opcode { - unsigned int expected_size; - const uint8_t *insn; - const char *desc; -}; - -static const struct selftest_opcode selftest_opcodes[] = { - /* REP MOVS */ - {1, "\xf3\xa4", "rep movsb <mem8>, <mem8>"}, - {4, "\xf3\xa5", "rep movsl <mem32>, <mem32>"}, - - /* MOVZX / MOVZXD */ - {1, "\x66\x0f\xb6\x51\xf8", "movzwq <mem8>, <reg16>"}, - {1, "\x0f\xb6\x51\xf8", "movzwq <mem8>, <reg32>"}, - - /* MOVSX / MOVSXD */ - {1, "\x66\x0f\xbe\x51\xf8", "movswq <mem8>, <reg16>"}, - {1, "\x0f\xbe\x51\xf8", "movswq <mem8>, <reg32>"}, - -#ifdef CONFIG_X86_64 - /* MOVZX / MOVZXD */ - {1, "\x49\x0f\xb6\x51\xf8", "movzbq <mem8>, <reg64>"}, - {2, "\x49\x0f\xb7\x51\xf8", "movzbq <mem16>, <reg64>"}, - - /* MOVSX / MOVSXD */ - {1, "\x49\x0f\xbe\x51\xf8", "movsbq <mem8>, <reg64>"}, - {2, "\x49\x0f\xbf\x51\xf8", "movsbq <mem16>, <reg64>"}, - {4, "\x49\x63\x51\xf8", "movslq <mem32>, <reg64>"}, -#endif -}; - -static bool selftest_opcode_one(const struct selftest_opcode *op) -{ - unsigned size; - - kmemcheck_opcode_decode(op->insn, &size); - - if (size == op->expected_size) - return true; - - printk(KERN_WARNING "kmemcheck: opcode %s: expected size %d, got %d\n", - op->desc, op->expected_size, size); - return false; -} - -static bool selftest_opcodes_all(void) -{ - bool pass = true; - unsigned int i; - - for (i = 0; i < ARRAY_SIZE(selftest_opcodes); ++i) - pass = pass && selftest_opcode_one(&selftest_opcodes[i]); - - return pass; -} - -bool kmemcheck_selftest(void) -{ - bool pass = true; - - pass = pass && selftest_opcodes_all(); - - return pass; -} --- a/arch/x86/mm/kmemcheck/selftest.h +++ b/arch/x86/mm/kmemcheck/selftest.h @@ -1,7 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ARCH_X86_MM_KMEMCHECK_SELFTEST_H -#define ARCH_X86_MM_KMEMCHECK_SELFTEST_H - -bool kmemcheck_selftest(void); - -#endif --- a/arch/x86/mm/kmemcheck/shadow.c +++ /dev/null @@ -1,173 +0,0 @@ -#include <linux/kmemcheck.h> -#include <linux/export.h> -#include <linux/mm.h> - -#include <asm/page.h> -#include <asm/pgtable.h> - -#include "pte.h" -#include "shadow.h" - -/* - * Return the shadow address for the given address. Returns NULL if the - * address is not tracked. - * - * We need to be extremely careful not to follow any invalid pointers, - * because this function can be called for *any* possible address. - */ -void *kmemcheck_shadow_lookup(unsigned long address) -{ - pte_t *pte; - struct page *page; - - if (!virt_addr_valid(address)) - return NULL; - - pte = kmemcheck_pte_lookup(address); - if (!pte) - return NULL; - - page = virt_to_page(address); - if (!page->shadow) - return NULL; - return page->shadow + (address & (PAGE_SIZE - 1)); -} - -static void mark_shadow(void *address, unsigned int n, - enum kmemcheck_shadow status) -{ - unsigned long addr = (unsigned long) address; - unsigned long last_addr = addr + n - 1; - unsigned long page = addr & PAGE_MASK; - unsigned long last_page = last_addr & PAGE_MASK; - unsigned int first_n; - void *shadow; - - /* If the memory range crosses a page boundary, stop there. */ - if (page == last_page) - first_n = n; - else - first_n = page + PAGE_SIZE - addr; - - shadow = kmemcheck_shadow_lookup(addr); - if (shadow) - memset(shadow, status, first_n); - - addr += first_n; - n -= first_n; - - /* Do full-page memset()s. */ - while (n >= PAGE_SIZE) { - shadow = kmemcheck_shadow_lookup(addr); - if (shadow) - memset(shadow, status, PAGE_SIZE); - - addr += PAGE_SIZE; - n -= PAGE_SIZE; - } - - /* Do the remaining page, if any. */ - if (n > 0) { - shadow = kmemcheck_shadow_lookup(addr); - if (shadow) - memset(shadow, status, n); - } -} - -void kmemcheck_mark_unallocated(void *address, unsigned int n) -{ - mark_shadow(address, n, KMEMCHECK_SHADOW_UNALLOCATED); -} - -void kmemcheck_mark_uninitialized(void *address, unsigned int n) -{ - mark_shadow(address, n, KMEMCHECK_SHADOW_UNINITIALIZED); -} - -/* - * Fill the shadow memory of the given address such that the memory at that - * address is marked as being initialized. - */ -void kmemcheck_mark_initialized(void *address, unsigned int n) -{ - mark_shadow(address, n, KMEMCHECK_SHADOW_INITIALIZED); -} -EXPORT_SYMBOL_GPL(kmemcheck_mark_initialized); - -void kmemcheck_mark_freed(void *address, unsigned int n) -{ - mark_shadow(address, n, KMEMCHECK_SHADOW_FREED); -} - -void kmemcheck_mark_unallocated_pages(struct page *p, unsigned int n) -{ - unsigned int i; - - for (i = 0; i < n; ++i) - kmemcheck_mark_unallocated(page_address(&p[i]), PAGE_SIZE); -} - -void kmemcheck_mark_uninitialized_pages(struct page *p, unsigned int n) -{ - unsigned int i; - - for (i = 0; i < n; ++i) - kmemcheck_mark_uninitialized(page_address(&p[i]), PAGE_SIZE); -} - -void kmemcheck_mark_initialized_pages(struct page *p, unsigned int n) -{ - unsigned int i; - - for (i = 0; i < n; ++i) - kmemcheck_mark_initialized(page_address(&p[i]), PAGE_SIZE); -} - -enum kmemcheck_shadow kmemcheck_shadow_test(void *shadow, unsigned int size) -{ -#ifdef CONFIG_KMEMCHECK_PARTIAL_OK - uint8_t *x; - unsigned int i; - - x = shadow; - - /* - * Make sure _some_ bytes are initialized. Gcc frequently generates - * code to access neighboring bytes. - */ - for (i = 0; i < size; ++i) { - if (x[i] == KMEMCHECK_SHADOW_INITIALIZED) - return x[i]; - } - - return x[0]; -#else - return kmemcheck_shadow_test_all(shadow, size); -#endif -} - -enum kmemcheck_shadow kmemcheck_shadow_test_all(void *shadow, unsigned int size) -{ - uint8_t *x; - unsigned int i; - - x = shadow; - - /* All bytes must be initialized. */ - for (i = 0; i < size; ++i) { - if (x[i] != KMEMCHECK_SHADOW_INITIALIZED) - return x[i]; - } - - return x[0]; -} - -void kmemcheck_shadow_set(void *shadow, unsigned int size) -{ - uint8_t *x; - unsigned int i; - - x = shadow; - for (i = 0; i < size; ++i) - x[i] = KMEMCHECK_SHADOW_INITIALIZED; -} --- a/arch/x86/mm/kmemcheck/shadow.h +++ b/arch/x86/mm/kmemcheck/shadow.h @@ -1,19 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ARCH__X86__MM__KMEMCHECK__SHADOW_H -#define ARCH__X86__MM__KMEMCHECK__SHADOW_H - -enum kmemcheck_shadow { - KMEMCHECK_SHADOW_UNALLOCATED, - KMEMCHECK_SHADOW_UNINITIALIZED, - KMEMCHECK_SHADOW_INITIALIZED, - KMEMCHECK_SHADOW_FREED, -}; - -void *kmemcheck_shadow_lookup(unsigned long address); - -enum kmemcheck_shadow kmemcheck_shadow_test(void *shadow, unsigned int size); -enum kmemcheck_shadow kmemcheck_shadow_test_all(void *shadow, - unsigned int size); -void kmemcheck_shadow_set(void *shadow, unsigned int size); - -#endif --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -594,21 +594,6 @@ static inline void tasklet_hi_schedule(s __tasklet_hi_schedule(t); } -extern void __tasklet_hi_schedule_first(struct tasklet_struct *t); - -/* - * This version avoids touching any other tasklets. Needed for kmemcheck - * in order not to take any page faults while enqueueing this tasklet; - * consider VERY carefully whether you really need this or - * tasklet_hi_schedule()... - */ -static inline void tasklet_hi_schedule_first(struct tasklet_struct *t) -{ - if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) - __tasklet_hi_schedule_first(t); -} - - static inline void tasklet_disable_nosync(struct tasklet_struct *t) { atomic_inc(&t->count); --- a/include/linux/kmemcheck.h +++ b/include/linux/kmemcheck.h @@ -1,172 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef LINUX_KMEMCHECK_H -#define LINUX_KMEMCHECK_H - -#include <linux/mm_types.h> -#include <linux/types.h> - -#ifdef CONFIG_KMEMCHECK -extern int kmemcheck_enabled; - -/* The slab-related functions. */ -void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int node); -void kmemcheck_free_shadow(struct page *page, int order); -void kmemcheck_slab_alloc(struct kmem_cache *s, gfp_t gfpflags, void *object, - size_t size); -void kmemcheck_slab_free(struct kmem_cache *s, void *object, size_t size); - -void kmemcheck_pagealloc_alloc(struct page *p, unsigned int order, - gfp_t gfpflags); - -void kmemcheck_show_pages(struct page *p, unsigned int n); -void kmemcheck_hide_pages(struct page *p, unsigned int n); - -bool kmemcheck_page_is_tracked(struct page *p); - -void kmemcheck_mark_unallocated(void *address, unsigned int n); -void kmemcheck_mark_uninitialized(void *address, unsigned int n); -void kmemcheck_mark_initialized(void *address, unsigned int n); -void kmemcheck_mark_freed(void *address, unsigned int n); - -void kmemcheck_mark_unallocated_pages(struct page *p, unsigned int n); -void kmemcheck_mark_uninitialized_pages(struct page *p, unsigned int n); -void kmemcheck_mark_initialized_pages(struct page *p, unsigned int n); - -int kmemcheck_show_addr(unsigned long address); -int kmemcheck_hide_addr(unsigned long address); - -bool kmemcheck_is_obj_initialized(unsigned long addr, size_t size); - -/* - * Bitfield annotations - * - * How to use: If you have a struct using bitfields, for example - * - * struct a { - * int x:8, y:8; - * }; - * - * then this should be rewritten as - * - * struct a { - * kmemcheck_bitfield_begin(flags); - * int x:8, y:8; - * kmemcheck_bitfield_end(flags); - * }; - * - * Now the "flags_begin" and "flags_end" members may be used to refer to the - * beginning and end, respectively, of the bitfield (and things like - * &x.flags_begin is allowed). As soon as the struct is allocated, the bit- - * fields should be annotated: - * - * struct a *a = kmalloc(sizeof(struct a), GFP_KERNEL); - * kmemcheck_annotate_bitfield(a, flags); - */ -#define kmemcheck_bitfield_begin(name) \ - int name##_begin[0]; - -#define kmemcheck_bitfield_end(name) \ - int name##_end[0]; - -#define kmemcheck_annotate_bitfield(ptr, name) \ - do { \ - int _n; \ - \ - if (!ptr) \ - break; \ - \ - _n = (long) &((ptr)->name##_end) \ - - (long) &((ptr)->name##_begin); \ - BUILD_BUG_ON(_n < 0); \ - \ - kmemcheck_mark_initialized(&((ptr)->name##_begin), _n); \ - } while (0) - -#define kmemcheck_annotate_variable(var) \ - do { \ - kmemcheck_mark_initialized(&(var), sizeof(var)); \ - } while (0) \ - -#else -#define kmemcheck_enabled 0 - -static inline void -kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int node) -{ -} - -static inline void -kmemcheck_free_shadow(struct page *page, int order) -{ -} - -static inline void -kmemcheck_slab_alloc(struct kmem_cache *s, gfp_t gfpflags, void *object, - size_t size) -{ -} - -static inline void kmemcheck_slab_free(struct kmem_cache *s, void *object, - size_t size) -{ -} - -static inline void kmemcheck_pagealloc_alloc(struct page *p, - unsigned int order, gfp_t gfpflags) -{ -} - -static inline bool kmemcheck_page_is_tracked(struct page *p) -{ - return false; -} - -static inline void kmemcheck_mark_unallocated(void *address, unsigned int n) -{ -} - -static inline void kmemcheck_mark_uninitialized(void *address, unsigned int n) -{ -} - -static inline void kmemcheck_mark_initialized(void *address, unsigned int n) -{ -} - -static inline void kmemcheck_mark_freed(void *address, unsigned int n) -{ -} - -static inline void kmemcheck_mark_unallocated_pages(struct page *p, - unsigned int n) -{ -} - -static inline void kmemcheck_mark_uninitialized_pages(struct page *p, - unsigned int n) -{ -} - -static inline void kmemcheck_mark_initialized_pages(struct page *p, - unsigned int n) -{ -} - -static inline bool kmemcheck_is_obj_initialized(unsigned long addr, size_t size) -{ - return true; -} - -#define kmemcheck_bitfield_begin(name) -#define kmemcheck_bitfield_end(name) -#define kmemcheck_annotate_bitfield(ptr, name) \ - do { \ - } while (0) - -#define kmemcheck_annotate_variable(var) \ - do { \ - } while (0) - -#endif /* CONFIG_KMEMCHECK */ - -#endif /* LINUX_KMEMCHECK_H */ --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -486,16 +486,6 @@ void __tasklet_hi_schedule(struct taskle } EXPORT_SYMBOL(__tasklet_hi_schedule); -void __tasklet_hi_schedule_first(struct tasklet_struct *t) -{ - BUG_ON(!irqs_disabled()); - - t->next = __this_cpu_read(tasklet_hi_vec.head); - __this_cpu_write(tasklet_hi_vec.head, t); - __raise_softirq_irqoff(HI_SOFTIRQ); -} -EXPORT_SYMBOL(__tasklet_hi_schedule_first); - static __latent_entropy void tasklet_action(struct softirq_action *a) { struct tasklet_struct *list; --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -30,7 +30,6 @@ #include <linux/proc_fs.h> #include <linux/security.h> #include <linux/ctype.h> -#include <linux/kmemcheck.h> #include <linux/kmemleak.h> #include <linux/fs.h> #include <linux/init.h> @@ -1174,15 +1173,6 @@ static struct ctl_table kern_table[] = { .extra2 = &one_thousand, }, #endif -#ifdef CONFIG_KMEMCHECK - { - .procname = "kmemcheck", - .data = &kmemcheck_enabled, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = proc_dointvec, - }, -#endif { .procname = "panic_on_warn", .data = &panic_on_warn, --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -504,7 +504,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT config DEBUG_SLAB bool "Debug slab memory allocations" - depends on DEBUG_KERNEL && SLAB && !KMEMCHECK + depends on DEBUG_KERNEL && SLAB help Say Y here to have the kernel do limited verification on memory allocation as well as poisoning memory on free to catch use of freed @@ -516,7 +516,7 @@ config DEBUG_SLAB_LEAK config SLUB_DEBUG_ON bool "SLUB debugging on by default" - depends on SLUB && SLUB_DEBUG && !KMEMCHECK + depends on SLUB && SLUB_DEBUG default n help Boot with debugging on by default. SLUB boots by default with @@ -730,8 +730,6 @@ config DEBUG_STACKOVERFLOW If in doubt, say "N". -source "lib/Kconfig.kmemcheck" - source "lib/Kconfig.kasan" endmenu # "Memory Debugging" --- a/lib/Kconfig.kmemcheck +++ /dev/null @@ -1,94 +0,0 @@ -config HAVE_ARCH_KMEMCHECK - bool - -if HAVE_ARCH_KMEMCHECK - -menuconfig KMEMCHECK - bool "kmemcheck: trap use of uninitialized memory" - depends on DEBUG_KERNEL - depends on !X86_USE_3DNOW - depends on SLUB || SLAB - depends on !CC_OPTIMIZE_FOR_SIZE - depends on !FUNCTION_TRACER - select FRAME_POINTER - select STACKTRACE - default n - help - This option enables tracing of dynamically allocated kernel memory - to see if memory is used before it has been given an initial value. - Be aware that this requires half of your memory for bookkeeping and - will insert extra code at *every* read and write to tracked memory - thus slow down the kernel code (but user code is unaffected). - - The kernel may be started with kmemcheck=0 or kmemcheck=1 to disable - or enable kmemcheck at boot-time. If the kernel is started with - kmemcheck=0, the large memory and CPU overhead is not incurred. - -choice - prompt "kmemcheck: default mode at boot" - depends on KMEMCHECK - default KMEMCHECK_ONESHOT_BY_DEFAULT - help - This option controls the default behaviour of kmemcheck when the - kernel boots and no kmemcheck= parameter is given. - -config KMEMCHECK_DISABLED_BY_DEFAULT - bool "disabled" - depends on KMEMCHECK - -config KMEMCHECK_ENABLED_BY_DEFAULT - bool "enabled" - depends on KMEMCHECK - -config KMEMCHECK_ONESHOT_BY_DEFAULT - bool "one-shot" - depends on KMEMCHECK - help - In one-shot mode, only the first error detected is reported before - kmemcheck is disabled. - -endchoice - -config KMEMCHECK_QUEUE_SIZE - int "kmemcheck: error queue size" - depends on KMEMCHECK - default 64 - help - Select the maximum number of errors to store in the queue. Since - errors can occur virtually anywhere and in any context, we need a - temporary storage area which is guarantueed not to generate any - other faults. The queue will be emptied as soon as a tasklet may - be scheduled. If the queue is full, new error reports will be - lost. - -config KMEMCHECK_SHADOW_COPY_SHIFT - int "kmemcheck: shadow copy size (5 => 32 bytes, 6 => 64 bytes)" - depends on KMEMCHECK - range 2 8 - default 5 - help - Select the number of shadow bytes to save along with each entry of - the queue. These bytes indicate what parts of an allocation are - initialized, uninitialized, etc. and will be displayed when an - error is detected to help the debugging of a particular problem. - -config KMEMCHECK_PARTIAL_OK - bool "kmemcheck: allow partially uninitialized memory" - depends on KMEMCHECK - default y - help - This option works around certain GCC optimizations that produce - 32-bit reads from 16-bit variables where the upper 16 bits are - thrown away afterwards. This may of course also hide some real - bugs. - -config KMEMCHECK_BITOPS_OK - bool "kmemcheck: allow bit-field manipulation" - depends on KMEMCHECK - default n - help - This option silences warnings that would be generated for bit-field - accesses where not all the bits are initialized at the same time. - This may also hide some real bugs. - -endif --- a/mm/Kconfig.debug +++ b/mm/Kconfig.debug @@ -11,7 +11,6 @@ config DEBUG_PAGEALLOC bool "Debug page memory allocations" depends on DEBUG_KERNEL depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC - depends on !KMEMCHECK select PAGE_EXTENSION select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC ---help--- --- a/mm/Makefile +++ b/mm/Makefile @@ -17,7 +17,6 @@ KCOV_INSTRUMENT_slub.o := n KCOV_INSTRUMENT_page_alloc.o := n KCOV_INSTRUMENT_debug-pagealloc.o := n KCOV_INSTRUMENT_kmemleak.o := n -KCOV_INSTRUMENT_kmemcheck.o := n KCOV_INSTRUMENT_memcontrol.o := n KCOV_INSTRUMENT_mmzone.o := n KCOV_INSTRUMENT_vmstat.o := n @@ -70,7 +69,6 @@ obj-$(CONFIG_KSM) += ksm.o obj-$(CONFIG_PAGE_POISONING) += page_poison.o obj-$(CONFIG_SLAB) += slab.o obj-$(CONFIG_SLUB) += slub.o -obj-$(CONFIG_KMEMCHECK) += kmemcheck.o obj-$(CONFIG_KASAN) += kasan/ obj-$(CONFIG_FAILSLAB) += failslab.o obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o --- a/mm/kmemcheck.c +++ b/mm/kmemcheck.c @@ -1,126 +1 @@ // SPDX-License-Identifier: GPL-2.0 -#include <linux/gfp.h> -#include <linux/mm_types.h> -#include <linux/mm.h> -#include <linux/slab.h> -#include "slab.h" -#include <linux/kmemcheck.h> - -void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int node) -{ - struct page *shadow; - int pages; - int i; - - pages = 1 << order; - - /* - * With kmemcheck enabled, we need to allocate a memory area for the - * shadow bits as well. - */ - shadow = alloc_pages_node(node, flags, order); - if (!shadow) { - if (printk_ratelimit()) - pr_err("kmemcheck: failed to allocate shadow bitmap\n"); - return; - } - - for(i = 0; i < pages; ++i) - page[i].shadow = page_address(&shadow[i]); - - /* - * Mark it as non-present for the MMU so that our accesses to - * this memory will trigger a page fault and let us analyze - * the memory accesses. - */ - kmemcheck_hide_pages(page, pages); -} - -void kmemcheck_free_shadow(struct page *page, int order) -{ - struct page *shadow; - int pages; - int i; - - if (!kmemcheck_page_is_tracked(page)) - return; - - pages = 1 << order; - - kmemcheck_show_pages(page, pages); - - shadow = virt_to_page(page[0].shadow); - - for(i = 0; i < pages; ++i) - page[i].shadow = NULL; - - __free_pages(shadow, order); -} - -void kmemcheck_slab_alloc(struct kmem_cache *s, gfp_t gfpflags, void *object, - size_t size) -{ - if (unlikely(!object)) /* Skip object if allocation failed */ - return; - - /* - * Has already been memset(), which initializes the shadow for us - * as well. - */ - if (gfpflags & __GFP_ZERO) - return; - - /* No need to initialize the shadow of a non-tracked slab. */ - if (s->flags & SLAB_NOTRACK) - return; - - if (!kmemcheck_enabled || gfpflags & __GFP_NOTRACK) { - /* - * Allow notracked objects to be allocated from - * tracked caches. Note however that these objects - * will still get page faults on access, they just - * won't ever be flagged as uninitialized. If page - * faults are not acceptable, the slab cache itself - * should be marked NOTRACK. - */ - kmemcheck_mark_initialized(object, size); - } else if (!s->ctor) { - /* - * New objects should be marked uninitialized before - * they're returned to the called. - */ - kmemcheck_mark_uninitialized(object, size); - } -} - -void kmemcheck_slab_free(struct kmem_cache *s, void *object, size_t size) -{ - /* TODO: RCU freeing is unsupported for now; hide false positives. */ - if (!s->ctor && !(s->flags & SLAB_TYPESAFE_BY_RCU)) - kmemcheck_mark_freed(object, size); -} - -void kmemcheck_pagealloc_alloc(struct page *page, unsigned int order, - gfp_t gfpflags) -{ - int pages; - - if (gfpflags & (__GFP_HIGHMEM | __GFP_NOTRACK)) - return; - - pages = 1 << order; - - /* - * NOTE: We choose to track GFP_ZERO pages too; in fact, they - * can become uninitialized by copying uninitialized memory - * into them. - */ - - /* XXX: Can use zone->node for node? */ - kmemcheck_alloc_shadow(page, order, gfpflags, -1); - - if (gfpflags & __GFP_ZERO) - kmemcheck_mark_initialized_pages(page, pages); - else - kmemcheck_mark_uninitialized_pages(page, pages); -} --- a/mm/slub.c +++ b/mm/slub.c @@ -1369,7 +1369,7 @@ static inline void *slab_free_hook(struc * So in order to make the debug calls that expect irqs to be * disabled we need to disable interrupts temporarily. */ -#if defined(CONFIG_KMEMCHECK) || defined(CONFIG_LOCKDEP) +#ifdef CONFIG_LOCKDEP { unsigned long flags; @@ -1397,8 +1397,7 @@ static inline void slab_free_freelist_ho * Compiler cannot detect this function can be removed if slab_free_hook() * evaluates to nothing. Thus, catch all relevant config debug options here. */ -#if defined(CONFIG_KMEMCHECK) || \ - defined(CONFIG_LOCKDEP) || \ +#if defined(CONFIG_LOCKDEP) || \ defined(CONFIG_DEBUG_KMEMLEAK) || \ defined(CONFIG_DEBUG_OBJECTS_FREE) || \ defined(CONFIG_KASAN) --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -2182,8 +2182,6 @@ sub dump_struct($$) { # strip comments: $members =~ s/\/\*.*?\*\///gos; $nested =~ s/\/\*.*?\*\///gos; - # strip kmemcheck_bitfield_{begin,end}.*; - $members =~ s/kmemcheck_bitfield_.*?;//gos; # strip attributes $members =~ s/__attribute__\s*$\([a-z,_\*\s\($]*\)\)//i; $members =~ s/__aligned\s*$[^;]*$//gos; --- a/tools/include/linux/kmemcheck.h +++ b/tools/include/linux/kmemcheck.h @@ -1,9 +1 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _LIBLOCKDEP_LINUX_KMEMCHECK_H_ -#define _LIBLOCKDEP_LINUX_KMEMCHECK_H_ - -static inline void kmemcheck_mark_initialized(void *address, unsigned int n) -{ -} - -#endif Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are queue-4.14/kmemcheck-remove-annotations.patch queue-4.14/kmemcheck-remove-whats-left-of-notrack-flags.patch queue-4.14/kmemcheck-stop-using-gfp_notrack-and-slab_notrack.patch queue-4.14/kmemcheck-rip-it-out.patch

7 years, 4 months

1
0
0 0

Patch "kmemcheck: remove whats left of NOTRACK flags" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kmemcheck: remove whats left of NOTRACK flags to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kmemcheck-remove-whats-left-of-notrack-flags.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d8be75663cec0069b85f80191abd2682ce4a512f Mon Sep 17 00:00:00 2001 From: "Levin, Alexander (Sasha Levin)" <alexander.levin(a)verizon.com> Date: Wed, 15 Nov 2017 17:35:58 -0800 Subject: kmemcheck: remove whats left of NOTRACK flags From: Levin, Alexander (Sasha Levin) <alexander.levin(a)verizon.com> commit d8be75663cec0069b85f80191abd2682ce4a512f upstream. Now that kmemcheck is gone, we don't need the NOTRACK flags. Link: http://lkml.kernel.org/r/20171007030159.22241-5-alexander.levin@verizon.com Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Tim Hansen <devtimhansen(a)gmail.com> Cc: Vegard Nossum <vegardno(a)ifi.uio.no> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/pgtable.h | 5 ----- arch/x86/include/asm/pgtable_types.h | 13 ------------- include/linux/gfp.h | 9 --------- include/linux/slab.h | 6 ------ include/trace/events/mmflags.h | 1 - mm/slub.c | 2 -- tools/perf/builtin-kmem.c | 1 - 7 files changed, 37 deletions(-) --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -668,11 +668,6 @@ static inline bool pte_accessible(struct return false; } -static inline int pte_hidden(pte_t pte) -{ - return pte_flags(pte) & _PAGE_HIDDEN; -} - static inline int pmd_present(pmd_t pmd) { /* --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -32,7 +32,6 @@ #define _PAGE_BIT_SPECIAL _PAGE_BIT_SOFTW1 #define _PAGE_BIT_CPA_TEST _PAGE_BIT_SOFTW1 -#define _PAGE_BIT_HIDDEN _PAGE_BIT_SOFTW3 /* hidden by kmemcheck */ #define _PAGE_BIT_SOFT_DIRTY _PAGE_BIT_SOFTW3 /* software dirty tracking */ #define _PAGE_BIT_DEVMAP _PAGE_BIT_SOFTW4 @@ -79,18 +78,6 @@ #define _PAGE_KNL_ERRATUM_MASK 0 #endif -#ifdef CONFIG_KMEMCHECK -#define _PAGE_HIDDEN (_AT(pteval_t, 1) << _PAGE_BIT_HIDDEN) -#else -#define _PAGE_HIDDEN (_AT(pteval_t, 0)) -#endif - -/* - * The same hidden bit is used by kmemcheck, but since kmemcheck - * works on kernel pages while soft-dirty engine on user space, - * they do not conflict with each other. - */ - #ifdef CONFIG_MEM_SOFT_DIRTY #define _PAGE_SOFT_DIRTY (_AT(pteval_t, 1) << _PAGE_BIT_SOFT_DIRTY) #else --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -37,7 +37,6 @@ struct vm_area_struct; #define ___GFP_THISNODE 0x40000u #define ___GFP_ATOMIC 0x80000u #define ___GFP_ACCOUNT 0x100000u -#define ___GFP_NOTRACK 0x200000u #define ___GFP_DIRECT_RECLAIM 0x400000u #define ___GFP_WRITE 0x800000u #define ___GFP_KSWAPD_RECLAIM 0x1000000u @@ -201,19 +200,11 @@ struct vm_area_struct; * __GFP_COMP address compound page metadata. * * __GFP_ZERO returns a zeroed page on success. - * - * __GFP_NOTRACK avoids tracking with kmemcheck. - * - * __GFP_NOTRACK_FALSE_POSITIVE is an alias of __GFP_NOTRACK. It's a means of - * distinguishing in the source between false positives and allocations that - * cannot be supported (e.g. page tables). */ #define __GFP_COLD ((__force gfp_t)___GFP_COLD) #define __GFP_NOWARN ((__force gfp_t)___GFP_NOWARN) #define __GFP_COMP ((__force gfp_t)___GFP_COMP) #define __GFP_ZERO ((__force gfp_t)___GFP_ZERO) -#define __GFP_NOTRACK ((__force gfp_t)___GFP_NOTRACK) -#define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK) /* Disable lockdep for GFP context tracking */ #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP) --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -78,12 +78,6 @@ #define SLAB_NOLEAKTRACE 0x00800000UL /* Avoid kmemleak tracing */ -/* Don't track use of uninitialized memory */ -#ifdef CONFIG_KMEMCHECK -# define SLAB_NOTRACK 0x01000000UL -#else -# define SLAB_NOTRACK 0x00000000UL -#endif #ifdef CONFIG_FAILSLAB # define SLAB_FAILSLAB 0x02000000UL /* Fault injection mark */ #else --- a/include/trace/events/mmflags.h +++ b/include/trace/events/mmflags.h @@ -46,7 +46,6 @@ {(unsigned long)__GFP_RECLAIMABLE, "__GFP_RECLAIMABLE"}, \ {(unsigned long)__GFP_MOVABLE, "__GFP_MOVABLE"}, \ {(unsigned long)__GFP_ACCOUNT, "__GFP_ACCOUNT"}, \ - {(unsigned long)__GFP_NOTRACK, "__GFP_NOTRACK"}, \ {(unsigned long)__GFP_WRITE, "__GFP_WRITE"}, \ {(unsigned long)__GFP_RECLAIM, "__GFP_RECLAIM"}, \ {(unsigned long)__GFP_DIRECT_RECLAIM, "__GFP_DIRECT_RECLAIM"},\ --- a/mm/slub.c +++ b/mm/slub.c @@ -5633,8 +5633,6 @@ static char *create_unique_id(struct kme *p++ = 'a'; if (s->flags & SLAB_CONSISTENCY_CHECKS) *p++ = 'F'; - if (!(s->flags & SLAB_NOTRACK)) - *p++ = 't'; if (s->flags & SLAB_ACCOUNT) *p++ = 'A'; if (p != name + 1) --- a/tools/perf/builtin-kmem.c +++ b/tools/perf/builtin-kmem.c @@ -655,7 +655,6 @@ static const struct { { "__GFP_RECLAIMABLE", "RC" }, { "__GFP_MOVABLE", "M" }, { "__GFP_ACCOUNT", "AC" }, - { "__GFP_NOTRACK", "NT" }, { "__GFP_WRITE", "WR" }, { "__GFP_RECLAIM", "R" }, { "__GFP_DIRECT_RECLAIM", "DR" }, Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are queue-4.14/kmemcheck-remove-annotations.patch queue-4.14/kmemcheck-remove-whats-left-of-notrack-flags.patch queue-4.14/kmemcheck-stop-using-gfp_notrack-and-slab_notrack.patch queue-4.14/kmemcheck-rip-it-out.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror