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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30B86C636CC for ; Thu, 16 Feb 2023 16:11:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229656AbjBPQL2 (ORCPT ); Thu, 16 Feb 2023 11:11:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbjBPQL1 (ORCPT ); Thu, 16 Feb 2023 11:11:27 -0500 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CA224D622 for ; Thu, 16 Feb 2023 08:11:26 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id y2so826503iot.4 for ; Thu, 16 Feb 2023 08:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vAhrdbinbCScFKrN/jJtdasED0sinl5gepWbixHt3Sw=; b=HWocl2yodqCYB2rWMZAbYWtVZTQnME1F6Kpzzlt+ki5xQbnQTYdq3X44/kfzHeoNIq G4fg70VWYDCoBkg+/Ucb7Wh0BlNbwyXa5uTy/V/QlRp2xkw/VexMP85eZQ2IFe45CQON wuLoNooU6WvhJaEPQlWN36aRPfMDlh8qyKAsVLUA5Fkk4MUAhsbAPUjhW31v49yFTtdB LqXeoxVRXbxX9myedLPQSs0ZJY/0tX0/yL5F3SfE7mDwJb0eRGYnmmkAEcmct1wmxAhO BP/Xz7qkQx/MbhlJFcw0AdZbaQg4SVLMV1RT5XHyg67wqWuFVVTUAfk1Ok8iZULRcjDc aKbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vAhrdbinbCScFKrN/jJtdasED0sinl5gepWbixHt3Sw=; b=3XO8TLFntNV73P7gosKvJfoYnRJomZ8F0qqGrvQ2INEj+Z3QZLfK7TnUqFb7Z37xOS Py7FAxjj3dBPmj4s1rcW02wtxprrGgUZWA+gIOEfDvKsw8hOuhx0cXC9ZYXRAsu6QV2l yuqecgU8GB2Ofd2NMkOfzfeJE9xkjGu728MacmtDPmIiHur4IhnPuzV66zJMwdLPnKkK EXgAKLuJqW3hpJRRXbU4k9fueDYECJW7lB1wQmsElBKoaONiCJU7uaNXU6r1oGLJq0WU tY1cBJPDeR+hYM91Rv+bA/E/Mk7tOoj5wDLKjy5k3yV6rsQ5mw3v7YeyoMOs4d5y5yZ4 WFsw== X-Gm-Message-State: AO0yUKX0nyZqM2j/rfdtZFxPHcG+qf5rK90sGCLjYudEVKjUmOAVzkFd /G4Fh+42ra/o3EPNz7uI9jnkIA== X-Google-Smtp-Source: AK7set+IhFH7lYLD68zlKx3De9BcABqrBJ3Hy9pw4Yk/NxRbD7Hq/8XbV/HU89bKdBBug+ruFOrCBw== X-Received: by 2002:a05:6602:5cd:b0:73a:6c75:5a85 with SMTP id w13-20020a05660205cd00b0073a6c755a85mr3796551iox.0.1676563885344; Thu, 16 Feb 2023 08:11:25 -0800 (PST) Received: from [192.168.1.94] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id g19-20020a02c553000000b00374fa5b600csm689443jaj.0.2023.02.16.08.11.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Feb 2023 08:11:24 -0800 (PST) Message-ID: <47f1f4f3-36c8-a1f0-2d07-3f03454dfb35@kernel.dk> Date: Thu, 16 Feb 2023 09:11:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH v2] io_uring: Adjust mapping wrt architecture aliasing requirements Content-Language: en-US To: Helge Deller , io-uring@vger.kernel.org, linux-parisc@vger.kernel.org, John David Anglin References: From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On 2/16/23 1:09?AM, Helge Deller wrote: > Some architectures have memory cache aliasing requirements (e.g. parisc) > if memory is shared between userspace and kernel. This patch fixes the > kernel to return an aliased address when asked by userspace via mmap(). > > Signed-off-by: Helge Deller > --- > v2: Do not allow to map to a user-provided addresss. This forces > programs to write portable code, as usually on x86 mapping to any > address will succeed, while it will fail for most provided address if > used on stricter architectures. > > diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > index 862e05e6691d..01fe7437a071 100644 > --- a/io_uring/io_uring.c > +++ b/io_uring/io_uring.c > @@ -72,6 +72,7 @@ > #include > #include > #include > +#include > > #define CREATE_TRACE_POINTS > #include > @@ -3059,6 +3060,54 @@ static __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma) > return remap_pfn_range(vma, vma->vm_start, pfn, sz, vma->vm_page_prot); > } > > +static unsigned long io_uring_mmu_get_unmapped_area(struct file *filp, > + unsigned long addr, unsigned long len, > + unsigned long pgoff, unsigned long flags) > +{ > + const unsigned long mmap_end = arch_get_mmap_end(addr, len, flags); > + struct vm_unmapped_area_info info; > + void *ptr; > + > + /* > + * Do not allow to map to user-provided address to avoid breaking the > + * aliasing rules. Userspace is not able to guess the offset address of > + * kernel kmalloc()ed memory area. > + */ > + if (addr) > + return -EINVAL; Can we relax this so that if the address is correctly aligned, it will allow it? The reported issue with sqpoll-cancel-hang.t is due to it crashing because it's a weird syzbot thing that does mmap() with MAP_FIXED and an address given. -- Jens Axboe