From: <gregkh@linuxfoundation.org>
To: davem@davemloft.net, gregkh@linuxfoundation.org, mroos@linux.ee
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "sparc64: Take ctx_alloc_lock properly in hugetlb_setup()." has been added to the 4.4-stable tree
Date: Mon, 20 Jun 2016 10:48:55 -0700 [thread overview]
Message-ID: <146644493517875@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
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=summary
The filename of the patch is:
sparc64-take-ctx_alloc_lock-properly-in-hugetlb_setup.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@vger.kernel.org> know about it.
>From foo@baz Mon Jun 20 10:48:29 PDT 2016
From: "David S. Miller" <davem@davemloft.net>
Date: Wed, 25 May 2016 12:51:20 -0700
Subject: sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
From: "David S. Miller" <davem@davemloft.net>
[ Upstream commit 9ea46abe22550e3366ff7cee2f8391b35b12f730 ]
On cheetahplus chips we take the ctx_alloc_lock in order to
modify the TLB lookup parameters for the indexed TLBs, which
are stored in the context register.
This is called with interrupts disabled, however ctx_alloc_lock
is an IRQ safe lock, therefore we must take acquire/release it
properly with spin_{lock,unlock}_irq().
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/mm/init_64.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2821,9 +2821,10 @@ void hugetlb_setup(struct pt_regs *regs)
* the Data-TLB for huge pages.
*/
if (tlb_type == cheetah_plus) {
+ bool need_context_reload = false;
unsigned long ctx;
- spin_lock(&ctx_alloc_lock);
+ spin_lock_irq(&ctx_alloc_lock);
ctx = mm->context.sparc64_ctx_val;
ctx &= ~CTX_PGSZ_MASK;
ctx |= CTX_PGSZ_BASE << CTX_PGSZ0_SHIFT;
@@ -2842,9 +2843,12 @@ void hugetlb_setup(struct pt_regs *regs)
* also executing in this address space.
*/
mm->context.sparc64_ctx_val = ctx;
- on_each_cpu(context_reload, mm, 0);
+ need_context_reload = true;
}
- spin_unlock(&ctx_alloc_lock);
+ spin_unlock_irq(&ctx_alloc_lock);
+
+ if (need_context_reload)
+ on_each_cpu(context_reload, mm, 0);
}
}
#endif
Patches currently in stable-queue which might be from davem@davemloft.net are
queue-4.4/sparc64-fix-bootup-regressions-on-some-kconfig-combinations.patch
queue-4.4/bpf-inode-disallow-userns-mounts.patch
queue-4.4/vxlan-accept-user-specified-mtu-value-when-create-new-vxlan-link.patch
queue-4.4/sfc-on-mc-reset-clear-pio-buffer-linkage-in-txqs.patch
queue-4.4/ipv6-skip-xfrm-lookup-if-dst_entry-in-socket-cache-is-valid.patch
queue-4.4/l2tp-fix-configuration-passed-to-setup_udp_tunnel_sock.patch
queue-4.4/switchdev-pass-pointer-to-fib_info-instead-of-copy.patch
queue-4.4/vxlan-relax-mtu-constraints.patch
queue-4.4/sparc-fix-system-call-tracing-register-handling.patch
queue-4.4/vxlan-gre-geneve-set-a-large-mtu-on-ovs-created-tunnel-devices.patch
queue-4.4/tcp-record-tlp-and-er-timer-stats-in-v6-stats.patch
queue-4.4/sparc64-fix-return-from-trap-window-fill-crashes.patch
queue-4.4/bpf-use-mount_nodev-not-mount_ns-to-mount-the-bpf-filesystem.patch
queue-4.4/netlink-fix-dump-skb-leak-double-free.patch
queue-4.4/sparc-pci-fix-for-panic-while-enabling-sr-iov.patch
queue-4.4/team-don-t-call-netdev_change_features-under-team-lock.patch
queue-4.4/sparc64-reduce-tlb-flushes-during-hugepte-changes.patch
queue-4.4/udp-prevent-skbs-lingering-in-tunnel-socket-queues.patch
queue-4.4/bridge-don-t-insert-unnecessary-local-fdb-entry-on-changing-mac-address.patch
queue-4.4/tipc-fix-nametable-publication-field-in-nl-compat.patch
queue-4.4/sparc64-fix-sparc64_set_context-stack-handling.patch
queue-4.4/sparc64-take-ctx_alloc_lock-properly-in-hugetlb_setup.patch
queue-4.4/tipc-check-nl-sock-before-parsing-nested-attributes.patch
queue-4.4/geneve-relax-mtu-constraints.patch
queue-4.4/uapi-glibc-compat-fix-compilation-when-__use_misc-in-glibc.patch
queue-4.4/sparc-harden-signal-return-frame-checks.patch
queue-4.4/tuntap-correctly-wake-up-process-during-uninit.patch
queue-4.4/sparc64-fix-numa-node-distance-initialization.patch
reply other threads:[~2016-06-20 18:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=146644493517875@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=davem@davemloft.net \
--cc=mroos@linux.ee \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).