Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5107844imu; Tue, 8 Jan 2019 11:38:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN6LR7+EO8AFB22E769K598ibof1QTtnjpFYGJryjeKew+YGuzsMYg8zT8WWltmjqX4ef+px X-Received: by 2002:a63:d34a:: with SMTP id u10mr2691318pgi.301.1546976300246; Tue, 08 Jan 2019 11:38:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546976300; cv=none; d=google.com; s=arc-20160816; b=iuQkUu2yVV6NSa+Aq/jh3zaFQ18wS2S2SDX/7IBXKukP8uyG6ZMynHlj6Z8vHcZsyL 4sutJWgj6QfqtLTQQhMzn+VP8cvhwir3uGCEHwAUWUmXjQeH8L/nQXhwopQB5IeteQTw qQ9px1U7LbznSru+7YG8kC0KXFUDGlqHoXlrjiV0lAPFo+RnGxzI1+Z5ZYpcgXC2SR8Z hsKFfO8koRtjAv8GMyZoz938jQB22bxgF0Nqj/YEac2ObRmepeS3R9P8acpmV3lI0yXF 224PElDYCloSXcHRz77l2ryK5K+3kWTFQfckos2Nf9rbOd6OImNRizxe0fqc40fOp/oA hdfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=oe1q4KE/2GlHXw7ltDYKj0A+6i3q9KXp3VaSAlVD/R8=; b=kuBgQ4av4pMDKYtkIR4+TuDlvvklvM2ov6cvEafQwTiGZrJg+gcRq1mbNvYgwWm7mt glxV1hd9GFbw/Q7IVtSOhtO32Lz1lB7swEE2aGziHZtPNjiX08SLIinLw3yAeNYrTo9q i8x2KoGJsdnWh+LWeGiJoM6IgIv3GUsUAdtuOR7VKIF03kFC7PTKykH11g5eL78ixL+Z iP8iH0SKsHk8NMxt4pa3FuM4ihh3ku5Trchzdk6DJBtpEqYMUkRP+DPgzc5tkclSlxF/ 6YOcbmrYCG7nakiX8vnwc0aY7qP7sinUyv6LJDDAPTi1HLrEtl88L7Bw1l58GSER4fLx tn3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p64si4823675pfg.79.2019.01.08.11.38.05; Tue, 08 Jan 2019 11:38:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732468AbfAHTgZ (ORCPT + 99 others); Tue, 8 Jan 2019 14:36:25 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:49910 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732434AbfAHTgF (ORCPT ); Tue, 8 Jan 2019 14:36:05 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id BFF6BA64; Tue, 8 Jan 2019 19:36:04 +0000 (UTC) Date: Tue, 8 Jan 2019 11:36:03 -0800 From: Andrew Morton To: Roman Penyaev Cc: Stephen Rothwell , Michal Hocko , "David S . Miller" , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] mm/vmalloc: Make vmalloc_32_user() align base kernel virtual address to SHMLBA Message-Id: <20190108113603.ea664e55869346bcb30c1433@linux-foundation.org> In-Reply-To: <20190108110944.23591-1-rpenyaev@suse.de> References: <20190108110944.23591-1-rpenyaev@suse.de> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019 12:09:44 +0100 Roman Penyaev wrote: > This patch repeats the original one from David S. Miller: > > 2dca6999eed5 ("mm, perf_event: Make vmalloc_user() align base kernel virtual address to SHMLBA") > > but for missed vmalloc_32_user() case, which also requires correct > alignment of virtual address on kernel side to avoid D-caches > aliases. A bit of copy-paste from original patch to recover in > memory of what is all about: > > When a vmalloc'd area is mmap'd into userspace, some kind of > co-ordination is necessary for this to work on platforms with cpu > D-caches which can have aliases. > > Otherwise kernel side writes won't be seen properly in userspace > and vice versa. > > If the kernel side mapping and the user side one have the same > alignment, modulo SHMLBA, this can work as long as VM_SHARED is > shared of VMA and for all current users this is true. VM_SHARED > will force SHMLBA alignment of the user side mmap on platforms with > D-cache aliasing matters. What are the user-visible runtime effects of this change? Is a -stable backport needed?