From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4495CC35673 for ; Sun, 23 Feb 2020 23:30:28 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 17BFC206E2 for ; Sun, 23 Feb 2020 23:30:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Gfc7ZXNI"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ggVP7Lgw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 17BFC206E2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WJgCHZSDqqMii3Jf+D/IwvFaPC8rNE5KetI+UQKwo7Y=; b=Gfc7ZXNITkW0NG xyJVqBi70782QhTn2WBMZltXpfHj1mCBAn8JYFxtDJsWqf692oMQ5JC4uMRe88Mn9fI4l8DjB4NkS wflorAubWniJKnaRVIQBgElpfK5t7EGssJ0vphOAW+dc1wQIWZPXNuTHCvJ4kCm9NDZXHJNTJp6mO C2wpNLU7PDWi1YDi+V8zNAR1OyFUza6AhP5soPY7E4FUFbquW+o06r5N0f//oHANf60mDGVhE//eS IvcCZ17YHcoCGq5VxpSnPE5ZgeZx5UmliWHuSV8lGFPXTjqm5dHhG73Zp/9n+GMptuE/wnoMQ0cFl +Re2Yhgv/onU5POC5y7A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j60hY-0006Dr-1k; Sun, 23 Feb 2020 23:30:20 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j60hV-0006DB-EF for linux-arm-kernel@lists.infradead.org; Sun, 23 Feb 2020 23:30:18 +0000 Received: by mail-pf1-x444.google.com with SMTP id s1so4364786pfh.10 for ; Sun, 23 Feb 2020 15:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BHvuL1JKTAOYifV/CjMNtfxfmXNZrw8/BIhfR9Y1A9A=; b=ggVP7LgwmoN8STUuj3mWba1bX30zmHY8CmaaZqN2n8hkUiwVxT2D236tdCePXHrakm NWqrvN0EDjd0EWtssVj7Q4gBFU/Kw+hsM8BYTpC4HPrfm7jo0koB5Hn9ba9AIBWpbVsa TMGDevIFAV7aMSY7npz2JijEoOxrC0EB30XKK37QyJMdRKLenkQcfvQFnh9dJvMgPN+m tVhDBNkq80xeU8slJPd6VOtdBnWMXHQAThm+FTb3uAFXn/49OIjnM8molXwhHBuM4rtx BB0GJgitUHg7+D9005tqrB6LQq6oKEwaQQQkQXhqJ+/f6y6Gzefkjw9n9Z4D454X9bDv +XOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BHvuL1JKTAOYifV/CjMNtfxfmXNZrw8/BIhfR9Y1A9A=; b=aT+efV6H/TaQ7cYrYXbPUjmHpwi9UqSKOSNJW+TadqPao1Dg8Na5SNdOVMx06qPRUE 9CY4oTLV1TVA5F+TJ7j2S3Z3sk1niFbXUEkqdbqsFn8oVlsCcYnvvEwiJIFpimCs2AHA ZMf+bRe9CY1ySEDrsaC83YVd8+2w2TqGE2ezpX/2J9fDRwgL0HAwp6XOgImP93IGW8dl QmNZ/SdNl22egm4ANVKkc1IZwbfFFI29BDwKuE0fdwG1jXjNyFfgO7M/RKwDLCCAk4DT AZMNwU922f3ILljrUCT+mlkkA2tC1m3tZ6vM1o7PFbdMfpCZCVMVrLxiqY8IjEdemQjW JH+Q== X-Gm-Message-State: APjAAAVqBfwW6YLA2uAiLKndbwy/1DP/lFrtrd4lplXOqOdq8T6M14qT DyDk4DygBzMwUHTvVP3awqY= X-Google-Smtp-Source: APXvYqwkvpjyGn5lU3qH+jbJ8b//vzZVj3gZxwDU6iE+AEDPoIzSjbWJzvdR3JYo8IjRWKxmWZPH6Q== X-Received: by 2002:a63:cb52:: with SMTP id m18mr12736278pgi.291.1582500615701; Sun, 23 Feb 2020 15:30:15 -0800 (PST) Received: from gmail.com ([2601:600:817f:a132:df3e:521d:99d5:710d]) by smtp.gmail.com with ESMTPSA id c19sm10303501pfc.144.2020.02.23.15.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Feb 2020 15:30:14 -0800 (PST) Date: Sun, 23 Feb 2020 15:30:13 -0800 From: Andrei Vagin To: Vincenzo Frascino Subject: Re: [PATCH 5/5] arm64/vdso: Restrict splitting VVAR VMA Message-ID: <20200223233013.GB349924@gmail.com> References: <20200204175913.74901-1-avagin@gmail.com> <20200204175913.74901-6-avagin@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200223_153017_507507_CCD20757 X-CRM114-Status: GOOD ( 14.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Dmitry Safonov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 20, 2020 at 12:22:52PM +0000, Vincenzo Frascino wrote: > Hi Andrei, > > On 04/02/2020 17:59, Andrei Vagin wrote: > > Forbid splitting VVAR VMA resulting in a stricter ABI and reducing the > > amount of corner-cases to consider while working further on VDSO time > > namespace support. > > > > As the offset from timens to VVAR page is computed compile-time, the pages > > in VVAR should stay together and not being partically mremap()'ed. > > > > I agree on the concept, but why do we need to redefine mremap? > special_mapping_mremap() (mm/mmap.c +3317) seems doing already the same thing if > we leave mremap == NULL as is. > Hmmm. I have read the code of special_mapping_mremap() and I don't see where it restricts splitting the vvar mapping. Here is the code what I see in the source: static int special_mapping_mremap(struct vm_area_struct *new_vma) { struct vm_special_mapping *sm = new_vma->vm_private_data; if (WARN_ON_ONCE(current->mm != new_vma->vm_mm)) return -EFAULT; if (sm->mremap) return sm->mremap(sm, new_vma); return 0; } And I have checked that without this patch, I can remap only one page of the vvar mapping. Thanks, Andrei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: * X-Spam-Status: No, score=1.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70450C35670 for ; Sun, 23 Feb 2020 23:30:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 39AF720880 for ; Sun, 23 Feb 2020 23:30:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ggVP7Lgw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727181AbgBWXaR (ORCPT ); Sun, 23 Feb 2020 18:30:17 -0500 Received: from mail-pf1-f195.google.com ([209.85.210.195]:41552 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727148AbgBWXaQ (ORCPT ); Sun, 23 Feb 2020 18:30:16 -0500 Received: by mail-pf1-f195.google.com with SMTP id j9so4368460pfa.8 for ; Sun, 23 Feb 2020 15:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BHvuL1JKTAOYifV/CjMNtfxfmXNZrw8/BIhfR9Y1A9A=; b=ggVP7LgwmoN8STUuj3mWba1bX30zmHY8CmaaZqN2n8hkUiwVxT2D236tdCePXHrakm NWqrvN0EDjd0EWtssVj7Q4gBFU/Kw+hsM8BYTpC4HPrfm7jo0koB5Hn9ba9AIBWpbVsa TMGDevIFAV7aMSY7npz2JijEoOxrC0EB30XKK37QyJMdRKLenkQcfvQFnh9dJvMgPN+m tVhDBNkq80xeU8slJPd6VOtdBnWMXHQAThm+FTb3uAFXn/49OIjnM8molXwhHBuM4rtx BB0GJgitUHg7+D9005tqrB6LQq6oKEwaQQQkQXhqJ+/f6y6Gzefkjw9n9Z4D454X9bDv +XOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BHvuL1JKTAOYifV/CjMNtfxfmXNZrw8/BIhfR9Y1A9A=; b=iCOmSLsb3k6FKLzcQxCkOXcVaktreHXlCuMbD6hSsQu0ChDx8Wf4hjvynA5F6RWUVZ ehkOnTHv3BWnjSlrFM+ZKO/txfwAD5IfBHoyc0sYAPn5UllhwlHJkHTeMrffwCWhWwLG 6UJDdPoaC/hz879pMAZYDtdeRt0H7qM9FaaiEKArdoNIbjsYA7FyoF3mCVyguoKJh0Qn ug4QNTWVv/j9ZM8tkql9Ik0shIVUmADf8hEp7HLGrEm6mT3RpqjNct0O2Mx8VPapED9m GC7GuRZwLmLvdSt1T4iuNQvGuEkJtggTh03Kc7sLDhDzKoISD6BGyqLEyHZ7DiBief3k A/7A== X-Gm-Message-State: APjAAAX298xHrwyTPtfOu0M6vzcVgYpQHbDZ93BsiHzo9HilJR9rrcKp PIkdIj2yDwhSrow4TpWEak4= X-Google-Smtp-Source: APXvYqwkvpjyGn5lU3qH+jbJ8b//vzZVj3gZxwDU6iE+AEDPoIzSjbWJzvdR3JYo8IjRWKxmWZPH6Q== X-Received: by 2002:a63:cb52:: with SMTP id m18mr12736278pgi.291.1582500615701; Sun, 23 Feb 2020 15:30:15 -0800 (PST) Received: from gmail.com ([2601:600:817f:a132:df3e:521d:99d5:710d]) by smtp.gmail.com with ESMTPSA id c19sm10303501pfc.144.2020.02.23.15.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Feb 2020 15:30:14 -0800 (PST) Date: Sun, 23 Feb 2020 15:30:13 -0800 From: Andrei Vagin To: Vincenzo Frascino Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Dmitry Safonov Subject: Re: [PATCH 5/5] arm64/vdso: Restrict splitting VVAR VMA Message-ID: <20200223233013.GB349924@gmail.com> References: <20200204175913.74901-1-avagin@gmail.com> <20200204175913.74901-6-avagin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 20, 2020 at 12:22:52PM +0000, Vincenzo Frascino wrote: > Hi Andrei, > > On 04/02/2020 17:59, Andrei Vagin wrote: > > Forbid splitting VVAR VMA resulting in a stricter ABI and reducing the > > amount of corner-cases to consider while working further on VDSO time > > namespace support. > > > > As the offset from timens to VVAR page is computed compile-time, the pages > > in VVAR should stay together and not being partically mremap()'ed. > > > > I agree on the concept, but why do we need to redefine mremap? > special_mapping_mremap() (mm/mmap.c +3317) seems doing already the same thing if > we leave mremap == NULL as is. > Hmmm. I have read the code of special_mapping_mremap() and I don't see where it restricts splitting the vvar mapping. Here is the code what I see in the source: static int special_mapping_mremap(struct vm_area_struct *new_vma) { struct vm_special_mapping *sm = new_vma->vm_private_data; if (WARN_ON_ONCE(current->mm != new_vma->vm_mm)) return -EFAULT; if (sm->mremap) return sm->mremap(sm, new_vma); return 0; } And I have checked that without this patch, I can remap only one page of the vvar mapping. Thanks, Andrei