From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751716AbeAZNav (ORCPT ); Fri, 26 Jan 2018 08:30:51 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:36544 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751493AbeAZNau (ORCPT ); Fri, 26 Jan 2018 08:30:50 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20180126133048euoutp02dd823b4306556a6db7b64efa7a27924d~NX1Bb6jmi2708627086euoutp02P X-AuditID: cbfec7f1-f793a6d00000326b-87-5a6b2d87f292 Subject: Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory To: Russell King - ARM Linux Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Bartlomiej Zolnierkiewicz , Inki Dae From: Marek Szyprowski Message-id: <589aa8ab-5bfc-e065-51f9-3a403c346d92@samsung.com> Date: Fri, 26 Jan 2018 14:30:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-version: 1.0 In-reply-to: <20180126113226.GX17719@n2100.armlinux.org.uk> Content-type: text/plain; charset="utf-8"; format="flowed" Content-transfer-encoding: 7bit Content-language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsWy7djPc7rtutlRBkf3cFhsnLGe1eL9sh5G i0n3J7BYbHp8jdXi8q45bBaHpu5ltHj58QSLA7vHmnlrGD0uX7vI7LF5Sb1H35ZVjB6fN8kF sEZx2aSk5mSWpRbp2yVwZbR+38lecE+komvbCbYGxjkCXYycHBICJhI7rz9jh7DFJC7cW8/W xcjFISSwlFFi650jzBDOZ0aJe5/2sXQxcoB1XDyZBRFfxiix6+JzqI7njBIHbp1lAxklLBAt sfXEO0YQWwSo4djBLywgRcwCHxklDr/YwwySYBMwlOh62wXWwCtgJ/FmcgOYzSKgKnH87HYw W1QgRuL/xpnsEDWCEj8m32MBsTkFrCWWn/8INodZwEri2b9WVghbXmLzmrdQcXGJ5tabYIsl BK6zSRw7NQ/qUReJfz3/GCFsYYlXx7dAxWUkLk/uZoGw+xklmlq1IewZjBLn3vJC2NYSh49f hFrGJzFp23RmSLDwSnS0CUGUeEh8er6HFcJ2lFhx6wgjJIQOMUqs6uxgn8AoPwvJP7OQ/DAL yQ+zkPywgJFlFaNIamlxbnpqsZFecWJucWleul5yfu4mRmCiOf3v+McdjO9PWB1iFOBgVOLh vXE7M0qINbGsuDIXaCkHs5IIrxlndpQQb0piZVVqUX58UWlOavEhRmkOFiVxXtuotkghgfTE ktTs1NSC1CKYLBMHp1QD4xH+DC1eH9YJ+suu2pjusWo9eikvTKW91mbVm/xv8hpbfU/eDWex qHm9oO+ZcObDJO/t1cUqz2rMOV7sdlC9+cuSI3KB+/17f+vOiXMLd9r9Xtyi/EB6yb6L0X6l AZ9Dt22d89vn+t+06l/avyaeYX7/8lDle34R9w+7HRddL1XUXyYqf+blFiWW4oxEQy3mouJE AJ1iwlMwAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsVy+t/xq7ptutlRBtd+q1lsnLGe1eL9sh5G i0n3J7BYbHp8jdXi8q45bBaHpu5ltHj58QSLA7vHmnlrGD0uX7vI7LF5Sb1H35ZVjB6fN8kF sEZx2aSk5mSWpRbp2yVwZbR+38lecE+komvbCbYGxjkCXYwcHBICJhIXT2Z1MXICmWISF+6t Z+ti5OIQEljCKLGo4TkThPOcUaLj/wNmkCphgWiJM4e/sYLYIkDNxw5+YQEpYhb4yCixf287 M0THEUaJ+etamECq2AQMJbredrGB2LwCdhJvJjeA2SwCqhLHz24Hs0UFYiQWNB9ihqgRlPgx +R4LiM0pYC2x/PxHsDizgJnEl5eHWSFseYnNa95CxcUlmltvskxgFJyFpH0WkpZZSFpmIWlZ wMiyilEktbQ4Nz232EivODG3uDQvXS85P3cTIzAqth37uWUHY9e74EOMAhyMSjy8N25nRgmx JpYVV+YeYpTgYFYS4TXjzI4S4k1JrKxKLcqPLyrNSS0+xCjNwaIkztu7Z3WkkEB6Yklqdmpq QWoRTJaJg1OqgbGf2/DV0YVM3prHyv5HOZZbnt7bt8nt1P65s0uPZRprnU76u+PhfaudIQdX yslM2Btr0x31mDOvYeLEWxKvOj5NaquqNP/Re+75VZlzi194+n31l+HcODdBxnbrTmOxqxUF V67PS+Ta9FR/bmNO6FTlDK4ugabM7Xzll+XqcliUg5XWi5+ffVqJpTgj0VCLuag4EQAVq8ah hgIAAA== X-CMS-MailID: 20180126133046eucas1p1ea63164f21be343a36ce9e8b95db34f1 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180126111453eucas1p1330d8561386c3cf2bb457bc22c0d99a8 X-RootMTR: 20180126111453eucas1p1330d8561386c3cf2bb457bc22c0d99a8 References: <20180126111441.29353-1-m.szyprowski@samsung.com> <20180126113226.GX17719@n2100.armlinux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Russell, On 2018-01-26 12:32, Russell King - ARM Linux wrote: > On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote: >> glibc in calls cacheflush syscall on the whole textrels section of the >> relocated binaries. However, relocation usually doesn't touch all pages >> of that section, so not all of them are read to memory when calling this >> syscall. However flush_cache_user_range() function will unconditionally >> touch all pages from the provided range, resulting additional overhead >> related to reading all clean pages. Optimize this by calling >> flush_cache_user_range() only on the pages that are already in the >> memory. > What ensures that another CPU doesn't remove a page while we're > flushing it? That will trigger a data abort, which will want to > take the mmap_sem, causing a deadlock. I thought that taking mmap_sem will prevent pages from being removed. mmap_sem has been already taken in the previous implementation of that syscall, until code simplification done by commit 97c72d89ce0e ("ARM: cacheflush: don't bother rounding to nearest vma"). >> Signed-off-by: Marek Szyprowski >> --- >> arch/arm/kernel/traps.c | 25 +++++++++++++++++++------ >> 1 file changed, 19 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c >> index 5e3633c24e63..a5ec262ab30e 100644 >> --- a/arch/arm/kernel/traps.c >> +++ b/arch/arm/kernel/traps.c >> @@ -564,23 +564,36 @@ static int bad_syscall(int n, struct pt_regs *regs) >> static inline int >> __do_cache_op(unsigned long start, unsigned long end) >> { >> - int ret; >> + struct vm_area_struct *vma = NULL; >> + int ret = 0; >> >> + down_read(¤t->mm->mmap_sem); >> do { >> unsigned long chunk = min(PAGE_SIZE, end - start); >> >> + if (!vma || vma->vm_end <= start) { >> + vma = find_vma(current->mm, start); >> + if (!vma) { >> + ret = -EFAULT; >> + goto done; >> + } >> + } >> + >> if (fatal_signal_pending(current)) >> return 0; >> >> - ret = flush_cache_user_range(start, start + chunk); >> - if (ret) >> - return ret; >> + if (follow_page(vma, start, 0)) { >> + ret = flush_cache_user_range(start, start + chunk); >> + if (ret) >> + goto done; >> + } >> >> cond_resched(); >> start += chunk; >> } while (start < end); >> - >> - return 0; >> +done: >> + up_read(¤t->mm->mmap_sem); >> + return ret; >> } >> >> static inline int >> -- >> 2.15.0 >> Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland