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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 CF4ECC169C4 for ; Thu, 31 Jan 2019 05:12:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9787F218AC for ; Thu, 31 Jan 2019 05:12:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548911522; bh=GIje4IagvFcLkyQY0xZUYSVnN7ly4UjDIjgrcQoAReY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=o0nECgnv51K8aikkg+aAIJIqRFuBlgCdZz32m6sqMg8MouNiq2Tv0i4IiK5lIw/vu wt+o0GX+xgAbMiz0Ru3ch/xHYG5ZkNvBM/wugyIhHgEnd6z9vTnFNWig4qW66fd09I qvO18PBpLrzd2vmXsP91iF3TKh4wlbiZdOA5AFbQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725867AbfAaFMB (ORCPT ); Thu, 31 Jan 2019 00:12:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:38288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfAaFMB (ORCPT ); Thu, 31 Jan 2019 00:12:01 -0500 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BACC6218D2 for ; Thu, 31 Jan 2019 05:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548911521; bh=GIje4IagvFcLkyQY0xZUYSVnN7ly4UjDIjgrcQoAReY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DQbVybqI8QhBEjIAfpyp4rEMBIn8yucQ1RMiXjryFMZ575twk+EVkAnYIu5S17OGQ L1FrQUa+V9aiYS6x4rOvMySZy8nfM+NuFF6B55UO+/k0/4xUVMsl6DBtvGMRT/ht6g LVZMMW0HLNvw1JEysUn4IeQKC+OC+Mul1FoWjeqY= Received: by mail-wm1-f54.google.com with SMTP id a62so1063099wmh.4 for ; Wed, 30 Jan 2019 21:12:00 -0800 (PST) X-Gm-Message-State: AJcUukd0mjx7r0LTie2y1QpF0bGPs0aRAtVizWoMmbsn8gtNeQUGNlyc 0A52PANDW2U9gu0D9jFr4s/GunbFstv1GGBl0PiY1Q== X-Google-Smtp-Source: ALg8bN4MMxZVBzAEq8mD387Va/Xm33kI65QtmHg324U84VkFfNFRU8aR3W/UlI7gm+muezmTxbrOaPFp/l7mAQvVXsc= X-Received: by 2002:a1c:b1d5:: with SMTP id a204mr29293975wmf.32.1548911519071; Wed, 30 Jan 2019 21:11:59 -0800 (PST) MIME-Version: 1.0 References: <20190123153536.7081-1-axboe@kernel.dk> <20190123153536.7081-6-axboe@kernel.dk> <20190128145700.GA9795@lst.de> In-Reply-To: From: Andy Lutomirski Date: Wed, 30 Jan 2019 21:11:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/18] Add io_uring IO interface To: Jens Axboe Cc: Andy Lutomirski , Christoph Hellwig , Linux FS Devel , linux-aio@kvack.org, linux-block@vger.kernel.org, Jeff Moyer , Avi Kivity , Linux API , linux-man Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org >>> On Jan 28, 2019, at 5:20 PM, Jens Axboe wrote: >>> >>> On 1/28/19 5:47 PM, Andy Lutomirski wrote: >>> On Mon, Jan 28, 2019 at 6:57 AM Christoph Hellwig wrote: >>> >>> [please make sure linux-api and linux-man are CCed on new syscalls >>> so that we get API experts to review them] >> >>>> +static int io_import_iovec(struct io_ring_ctx *ctx, int rw, >>>> + const struct io_uring_sqe *sqe, >>>> + struct iovec **iovec, struct iov_iter *iter) >>>> +{ >>>> + void __user *buf = u64_to_user_ptr(sqe->addr); >>>> + >>>> +#ifdef CONFIG_COMPAT >>>> + if (ctx->compat) >>>> + return compat_import_iovec(rw, buf, sqe->len, UIO_FASTIOV, >>>> + iovec, iter); >>>> +#endif >>> >>> I think we can just check in_compat_syscall() here, which means we >>> can kill the ->compat member, and the separate compat version of the >>> setup syscall. >> >> Since this whole API is new, I don't suppose you could introduce a >> struct iovec64 or similar and just make the ABI be identical for >> 64-bit and 32-bit code? > > Sure, that would be straight forward. Is there a strong reason to do > so outside of "that would be nice"? It's not like it's a huge amount > of code. Here are some minor-ish benefits: - It avoids having a code path that is only used with 32 bit code on 64 bit kernels and is therefore rarely tested. (In this particular case, the code path doesn't diverge much, but for most compat syscalls, it's almost an entirely separate implementation of the main syscall code.) - It makes life easier for tools like strace. - It minimizes the chance of making a giant mess on x32, which isn't really native or compat. --Andy