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=-5.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 41D73C433DB for ; Fri, 12 Feb 2021 15:15:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 61CEC64E2D for ; Fri, 12 Feb 2021 15:15:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 61CEC64E2D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D5F9A8D0061; Fri, 12 Feb 2021 10:15:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE9488D0060; Fri, 12 Feb 2021 10:15:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD9758D0061; Fri, 12 Feb 2021 10:15:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0074.hostedemail.com [216.40.44.74]) by kanga.kvack.org (Postfix) with ESMTP id A05BF8D0060 for ; Fri, 12 Feb 2021 10:15:13 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5A6082C88 for ; Fri, 12 Feb 2021 15:15:13 +0000 (UTC) X-FDA: 77809964106.25.2BB7849 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by imf27.hostedemail.com (Postfix) with ESMTP id 7B78D80192DD for ; Fri, 12 Feb 2021 15:15:11 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id n14so9643606iog.3 for ; Fri, 12 Feb 2021 07:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=g5Qd6pYvAFJWK+gEpErCm9aESy14N4Z1oHpZ+sVfQOc=; b=ZcR5ap78jvA6h4aOH14zmB9wDCk19/qv8W8niAZWhnr5nTtMlT5d34/JWNHzD3v1AN tSzLbKUDQgvxlx/6Zfo2NLgykz9WakzKRsH0XsZdVbetee3kCrE5FcWerGgykKAYs4V1 gsm7PFrHz00eeKr4SfYWOTy21mM6LE7gmcI/nKHfQ+R7+1VcLAMtuim2BV+nV0NMexb7 pyy8tRcbD6T5kfxRwbKC86XdXOO3v0HVhyxihLdEbUof0SdGglfQoccXTc5tCeeTYk40 43gbCcFB5TXZSk6eyEvmhDtLTAlDAXw8Txg1Zwsn5atVic24ktAGhTPNldgKS2PDhBES bCqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g5Qd6pYvAFJWK+gEpErCm9aESy14N4Z1oHpZ+sVfQOc=; b=MLLiMWHcBAWsxRVDBauNp5BWsSHP3DfjAdvUQjOgDWUebDqwiaOPHM1UKV2JBbgoQa QeYyIl8pD3JL3M55+tm1Tzla6z96st4N2FvWZFqMBourkuGIMpX/9DScaw6SZBURf3wM fgYwkoig17YnqTtiluBy4/hfFKfM3YnU8xckD+vyegq1V6pBQ6f4njsIxNHjjox8+Bm8 XbEaD4NDCQKxKQ66CEEdulAmv4ZR2xgUx6qZhtHb32SzoMkD9lwaK7WX6YocTSG5AbXQ 7+DaQ7DyV//foPgG7rJbJIwZXCaK8P/T/uj1fy/ACJShhmc/Sra8ZwSHX35jOilfWm49 h2aA== X-Gm-Message-State: AOAM532k3mKLk6x9RyXuYOeE2g9W1PaNU2AOnGE2Tk2KOnUWegxO8o41 LpQsXWWA1vrVe1GqMm5LZQvx/g== X-Google-Smtp-Source: ABdhPJwvDDD3TWSoAEVShUKZDLa92YwusU8s2w4HHwA6v00UG/7bVDm4Y184knqYvr/k3y56NDnCJA== X-Received: by 2002:a05:6638:ccc:: with SMTP id e12mr3175973jak.6.1613142911672; Fri, 12 Feb 2021 07:15:11 -0800 (PST) Received: from [192.168.1.30] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id i19sm4256080ioh.38.2021.02.12.07.15.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 07:15:11 -0800 (PST) Subject: Re: Memory keys and io_uring. To: "Aneesh Kumar K.V" , Dave Hansen , Michael Ellerman Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <877dndzs8c.fsf@linux.ibm.com> From: Jens Axboe Message-ID: Date: Fri, 12 Feb 2021 08:15:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <877dndzs8c.fsf@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Stat-Signature: zrhwq7y885jm4re5k5a66xk9up6y97my X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7B78D80192DD Received-SPF: none (kernel.dk>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-io1-f43.google.com; client-ip=209.85.166.43 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613142911-556308 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2/11/21 11:59 PM, Aneesh Kumar K.V wrote: > > Hi, > > I am trying to estabilish the behaviour we should expect when passing a > buffer with memory keys attached to io_uring syscalls. As show in the > blow test > > /* > * gcc -Wall -O2 -D_GNU_SOURCE -o pkey_uring pkey_uring.c -luring > */ > #include > #include > #include > #include > #include > #include > #include "liburing.h" > > #define PAGE_SIZE (64 << 10) > > int main(int argc, char *argv[]) > { > int fd, ret, pkey; > struct io_uring ring; > struct io_uring_sqe *sqe; > struct io_uring_cqe *cqe; > struct iovec iovec; > void *buf; > > if (argc < 2) { > printf("%s: file\n", argv[0]); > return 1; > } > > ret = io_uring_queue_init(1, &ring, IORING_SETUP_SQPOLL); > if (ret < 0) { > fprintf(stderr, "queue_init: %s\n", strerror(-ret)); > return 1; > } > > fd = open(argv[1], O_RDONLY | O_DIRECT); > if (fd < 0) { > perror("open"); > return 1; > } > > if (posix_memalign(&buf, PAGE_SIZE, PAGE_SIZE)) > return 1; > iovec.iov_base = buf; > iovec.iov_len = PAGE_SIZE; > > //mprotect(buf, PAGE_SIZE, PROT_NONE); > pkey = pkey_alloc(0, PKEY_DISABLE_WRITE); > pkey_mprotect(buf, PAGE_SIZE, PROT_READ | PROT_WRITE, pkey); > > > sqe = io_uring_get_sqe(&ring); > if (!sqe) { > perror("io_uring_get_sqe"); > return 1; > } > io_uring_prep_readv(sqe, fd, &iovec, 1, 0); > > ret = io_uring_submit(&ring); > if (ret != 1) { > fprintf(stderr, "io_uring_submit: %s\n", strerror(-ret)); > return 1; > } > > ret = io_uring_wait_cqe(&ring, &cqe); > > if (cqe->res < 0) > fprintf(stderr, "iouring submit failed %s\n", strerror(-cqe->res)); > else > fprintf(stderr, "iouring submit success\n"); > > io_uring_cqe_seen(&ring, cqe); > > /* > * let's access this via a read syscall > */ > ret = read(fd, buf, PAGE_SIZE); > if (ret < 0) > fprintf(stderr, "read failed : %s\n", strerror(errno)); > > close(fd); > io_uring_queue_exit(&ring); > > return 0; > } > > A read syscall do fail with EFAULT. But we allow read via io_uring > syscalls. Is that ok? Considering memory keys are thread-specific we > could debate that kernel thread can be considered to be the one that got all access > allowed via keys or we could update that access is denied via kernel > thread for any key value other than default key (key 0). Other option > is to inherit the memory key restrictions when doing > io_uring_submit() and use the same when accessing the userspace from > kernel thread. > > Any thoughts here with respect to what should be behaviour? It this a powerpc thing? I get -EFAULT on x86 for both reads, io_uring and regular syscall. That includes SQPOLL, not using SQPOLL, or explicitly setting IOSQE_ASYNC on the sqe. -- Jens Axboe