From patchwork Thu Aug 10 22:14:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hauke Mehrtens X-Patchwork-Id: 800348 X-Patchwork-Delegate: blogic@openwrt.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133; helo=bombadil.infradead.org; envelope-from=lede-dev-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="M5wJbsSA"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xT2Xw6K7kz9sNc for ; Fri, 11 Aug 2017 08:16:32 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Subject:Message-Id: Date:To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=EwJ9GAwuRvqWmbLm8onhSNG3kYkc2wnhyN59wVsh/hc=; b=M5wJbsSAdpFWL9 lsj2HEMpVbyH4IM8ybAUnXlS4i/j7TL/RGdhBls2N8iyuHR05X/N3qcvYpbQo/GGdjk26k6ii8xyv cbC4lYTWzKolTfJTNZJpQChslc2cxJEoVYhXtpRXYo9TT3mOmnbvQPjI6OhZa6uLcN5z3kS3xQzfh fObGlG0NrZx13vkDyNC16j6v702KV64R756P7suzk3zgWMBdADlm5bDB4cfi+DTKeApy62OGdQG1K FOniSOMy+1A/tZG+vZHIlWgXd6aSgR2BeycwsC+H3aTRwJ7CUsErHe2eGEjJRYSnBkDoY65xSBmFv Kgm2BZHwQeSn7c1BkXAA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dfvkK-000852-93; Thu, 10 Aug 2017 22:16:04 +0000 Received: from mx1.mailbox.org ([80.241.60.212]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dfvjt-0007UI-77 for lede-dev@lists.infradead.org; Thu, 10 Aug 2017 22:15:40 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 618D745FFB; Fri, 11 Aug 2017 00:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id nWPwnfi0QOQh; Fri, 11 Aug 2017 00:14:53 +0200 (CEST) From: Hauke Mehrtens To: lede-dev@lists.infradead.org Date: Fri, 11 Aug 2017 00:14:27 +0200 Message-Id: <20170810221427.23260-1-hauke@hauke-m.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170810_151537_633971_B3D6EF59 X-CRM114-Status: GOOD ( 18.57 ) X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.241.60.212 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Subject: [LEDE-DEV] [PATCH] kernel: fix VDSO problem on MIPS X-BeenThere: lede-dev@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Hauke Mehrtens MIME-Version: 1.0 Sender: "Lede-dev" Errors-To: lede-dev-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org This fixes the VDSO problems on the Lantiq VR9 MIPS SoC. The gettimeofday() sometimes returned old data because of a cache aliasing problems on MIPS CPUs, to work around this problem VDSO gettimeofday support was deactivated for MIPS in LEDE. This problem made ping show very high times like a delay of 4289967.657 ms. 1.000.000 calls to clock_gettime(CLOCK_MONOTONIC, &tp); take 1 second without VDSO support and 0.35 seconds with VDSO support on Lantiq VR9. Signed-off-by: Hauke Mehrtens --- ...MIPS-work-around-aliasing-issue-with-VDSO.patch | 63 ++++++++++++++++++++++ .../pending-4.4/206-mips-disable-vdso.patch | 21 -------- ...MIPS-work-around-aliasing-issue-with-VDSO.patch | 63 ++++++++++++++++++++++ .../pending-4.9/206-mips-disable-vdso.patch | 28 ---------- 4 files changed, 126 insertions(+), 49 deletions(-) create mode 100644 target/linux/generic/pending-4.4/206-MIPS-work-around-aliasing-issue-with-VDSO.patch delete mode 100644 target/linux/generic/pending-4.4/206-mips-disable-vdso.patch create mode 100644 target/linux/generic/pending-4.9/206-MIPS-work-around-aliasing-issue-with-VDSO.patch delete mode 100644 target/linux/generic/pending-4.9/206-mips-disable-vdso.patch diff --git a/target/linux/generic/pending-4.4/206-MIPS-work-around-aliasing-issue-with-VDSO.patch b/target/linux/generic/pending-4.4/206-MIPS-work-around-aliasing-issue-with-VDSO.patch new file mode 100644 index 0000000000..b62557b7b5 --- /dev/null +++ b/target/linux/generic/pending-4.4/206-MIPS-work-around-aliasing-issue-with-VDSO.patch @@ -0,0 +1,63 @@ +From a5513a09cbb946e9d031fb65d6c2ac7c32c9042c Mon Sep 17 00:00:00 2001 +From: James Hogan +Date: Thu, 10 Aug 2017 22:56:47 +0200 +Subject: MIPS: work around aliasing issue with VDSO + +I notice that the mips_vdso_data is updated by update_vsyscall() via +kseg0, however userland will be accessing it via the mapping 1 page +below the VDSO. + +If the kernel data happened to be placed such that the mips_vdso_data in +kseg0 and the user mapping had different page colours then you could +easily hit aliasing issues. A couple of well placed flushes or some more +careful placement of the VDSO data might well fix it, as could some +random patch changing the positioning of the data such that it +coincidentally lined up on the same colour. + +The patch unfortunately hacks arch_get_unmapped_area_common so that it +does the colour alignment on non-shared anonymous pages, as long as +non-zero pgoff is provided. Hopefully no userland code would try +mmap'ing anonymous memory with a file offset, and so it should be +harmless. + +It doesn't look like we can just pass MAP_SHARED to avoid the hack as +then pgoff will get cleared by get_unmapped_area()). +--- + arch/mips/kernel/vdso.c | 7 ++++++- + arch/mips/mm/mmap.c | 2 +- + 2 files changed, 7 insertions(+), 2 deletions(-) + +diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c +index f9dbfb14af33..9509b5122e70 100644 +--- a/arch/mips/kernel/vdso.c ++++ b/arch/mips/kernel/vdso.c +@@ -129,7 +129,12 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) + vvar_size = gic_size + PAGE_SIZE; + size = vvar_size + image->size; + +- base = get_unmapped_area(NULL, 0, size, 0, 0); ++ /* ++ * Hack to get the user mapping of the VDSO data page matching the cache ++ * colour of its kseg0 address. ++ */ ++ base = get_unmapped_area(NULL, 0, size, ++ (virt_to_phys(&vdso_data) - gic_size) >> PAGE_SHIFT, 0); + if (IS_ERR_VALUE(base)) { + ret = base; + goto out; +diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c +index d08ea3ff0f53..cb468b0ea45c 100644 +--- a/arch/mips/mm/mmap.c ++++ b/arch/mips/mm/mmap.c +@@ -80,7 +80,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, + } + + do_color_align = 0; +- if (filp || (flags & MAP_SHARED)) ++ if (filp || (flags & MAP_SHARED) || pgoff) + do_color_align = 1; + + /* requesting a specific address */ +-- +2.11.0 + diff --git a/target/linux/generic/pending-4.4/206-mips-disable-vdso.patch b/target/linux/generic/pending-4.4/206-mips-disable-vdso.patch deleted file mode 100644 index 51b1d041bf..0000000000 --- a/target/linux/generic/pending-4.4/206-mips-disable-vdso.patch +++ /dev/null @@ -1,21 +0,0 @@ -Disable MIPS VDSO until the cache issues have been sorted out. - -Signed-off-by: Felix Fietkau - ---- a/arch/mips/vdso/Makefile -+++ b/arch/mips/vdso/Makefile -@@ -28,11 +28,11 @@ aflags-vdso := $(ccflags-vdso) \ - # the comments on that file. - # - ifndef CONFIG_CPU_MIPSR6 -- ifeq ($(call ld-ifversion, -lt, 22500000, y),y) -- $(warning MIPS VDSO requires binutils >= 2.25) -+# ifeq ($(call ld-ifversion, -lt, 22500000, y),y) -+# $(warning MIPS VDSO requires binutils >= 2.25) - obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y)) - ccflags-vdso += -DDISABLE_MIPS_VDSO -- endif -+# endif - endif - - # VDSO linker flags. diff --git a/target/linux/generic/pending-4.9/206-MIPS-work-around-aliasing-issue-with-VDSO.patch b/target/linux/generic/pending-4.9/206-MIPS-work-around-aliasing-issue-with-VDSO.patch new file mode 100644 index 0000000000..b62557b7b5 --- /dev/null +++ b/target/linux/generic/pending-4.9/206-MIPS-work-around-aliasing-issue-with-VDSO.patch @@ -0,0 +1,63 @@ +From a5513a09cbb946e9d031fb65d6c2ac7c32c9042c Mon Sep 17 00:00:00 2001 +From: James Hogan +Date: Thu, 10 Aug 2017 22:56:47 +0200 +Subject: MIPS: work around aliasing issue with VDSO + +I notice that the mips_vdso_data is updated by update_vsyscall() via +kseg0, however userland will be accessing it via the mapping 1 page +below the VDSO. + +If the kernel data happened to be placed such that the mips_vdso_data in +kseg0 and the user mapping had different page colours then you could +easily hit aliasing issues. A couple of well placed flushes or some more +careful placement of the VDSO data might well fix it, as could some +random patch changing the positioning of the data such that it +coincidentally lined up on the same colour. + +The patch unfortunately hacks arch_get_unmapped_area_common so that it +does the colour alignment on non-shared anonymous pages, as long as +non-zero pgoff is provided. Hopefully no userland code would try +mmap'ing anonymous memory with a file offset, and so it should be +harmless. + +It doesn't look like we can just pass MAP_SHARED to avoid the hack as +then pgoff will get cleared by get_unmapped_area()). +--- + arch/mips/kernel/vdso.c | 7 ++++++- + arch/mips/mm/mmap.c | 2 +- + 2 files changed, 7 insertions(+), 2 deletions(-) + +diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c +index f9dbfb14af33..9509b5122e70 100644 +--- a/arch/mips/kernel/vdso.c ++++ b/arch/mips/kernel/vdso.c +@@ -129,7 +129,12 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) + vvar_size = gic_size + PAGE_SIZE; + size = vvar_size + image->size; + +- base = get_unmapped_area(NULL, 0, size, 0, 0); ++ /* ++ * Hack to get the user mapping of the VDSO data page matching the cache ++ * colour of its kseg0 address. ++ */ ++ base = get_unmapped_area(NULL, 0, size, ++ (virt_to_phys(&vdso_data) - gic_size) >> PAGE_SHIFT, 0); + if (IS_ERR_VALUE(base)) { + ret = base; + goto out; +diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c +index d08ea3ff0f53..cb468b0ea45c 100644 +--- a/arch/mips/mm/mmap.c ++++ b/arch/mips/mm/mmap.c +@@ -80,7 +80,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp, + } + + do_color_align = 0; +- if (filp || (flags & MAP_SHARED)) ++ if (filp || (flags & MAP_SHARED) || pgoff) + do_color_align = 1; + + /* requesting a specific address */ +-- +2.11.0 + diff --git a/target/linux/generic/pending-4.9/206-mips-disable-vdso.patch b/target/linux/generic/pending-4.9/206-mips-disable-vdso.patch deleted file mode 100644 index 9785f932e7..0000000000 --- a/target/linux/generic/pending-4.9/206-mips-disable-vdso.patch +++ /dev/null @@ -1,28 +0,0 @@ -From: Felix Fietkau -Subject: kernel: disable MIPS VDSO by default until the cache issues have been resolved - -lede-commit: 1185e645a773c86aa88cf04d0e2911dc62eb43f5 -Signed-off-by: Felix Fietkau ---- - arch/mips/vdso/Makefile | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile -index c3dc12a8b7d9..28f66e3bb2c3 100644 ---- a/arch/mips/vdso/Makefile -+++ b/arch/mips/vdso/Makefile -@@ -28,9 +28,9 @@ aflags-vdso := $(ccflags-vdso) \ - ifndef CONFIG_CPU_MIPSR6 - ifeq ($(call ld-ifversion, -lt, 225000000, y),y) - $(warning MIPS VDSO requires binutils >= 2.25) -- obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y)) -- ccflags-vdso += -DDISABLE_MIPS_VDSO - endif -+ obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y)) -+ ccflags-vdso += -DDISABLE_MIPS_VDSO - endif - - # VDSO linker flags. --- -2.11.0 -