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=-7.2 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 BA152C433F5 for ; Fri, 10 Sep 2021 03:23:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A058F61026 for ; Fri, 10 Sep 2021 03:23:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230028AbhIJDYW (ORCPT ); Thu, 9 Sep 2021 23:24:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbhIJDYU (ORCPT ); Thu, 9 Sep 2021 23:24:20 -0400 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C425C061574 for ; Thu, 9 Sep 2021 20:23:10 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id b10so593340ioq.9 for ; Thu, 09 Sep 2021 20:23:10 -0700 (PDT) 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=fS/gR13+AKdfezCz28++1Ca4/7qZ+GYaCjPbEeBXIPY=; b=gdqp/JXhJeD1F2Z+eIhcH+/OsDfko22xIFfFSjhmF2S3sahK/IeQz7m0QAKtp7Lqgv VdDUWsY60fZblKMUnJ6S6EtgaplJKMMpIWC3U0mV3NjrDcKqh4U/KXu0FU0vhO3+lrLO MeytRKpdiWTzjlEBH8q49aSa+VEOtjdgkwI7M+lXJwUp0UBXC/s1Bzp1J6WULwV8Tp0R 2FOTahVG3SDkIb3nqZEkTlyM0O90+ZW1gAqhGNWVLLCR/blsEt03ERjaMSlho+0e74K1 Xk1OOwe4yYq1pZG/o2uRpmA8I2Z2oUNsFJ5kCYpqi4Do20DyQTSxIxd19RmzcppnkLP8 UbiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=fS/gR13+AKdfezCz28++1Ca4/7qZ+GYaCjPbEeBXIPY=; b=Y2wV6bzZ4n9nwQ2HZmcDc51s5vN6zmfZI4wgtJBpmkol5xsYwX5Lvrtv1rv7otUkOz NfMgDAIp1cdsLvK41sFC6Dn6A3eoC4WVawYcPZ8VOMFGfX0SyxUNy2zP/pvH4CXlGePL EciSEJLXZ7ycIPmA786T2ncSmSl156ZgAWSkGlBg+0yyCEplG2ona92Wkd/n5B5CzNox 1yn5+djdgmcWETdEiViS3FUwUCk/fScvywLFV2f5PH8O/kuvaX6bRZmRpLXi9pGFVDzs 7/Ys5dzpNM/ulSwRPttRT9ZJP8iFd3n32R98o5lRo7iMWCOAlJ/iyq1RtGp1VMoqHqfH amBg== X-Gm-Message-State: AOAM530Bed/MJdiHS+a3RmbFY+X9+noUdwsFTSEWwqD6UD0y291cnqoc 4rFMUyHFRaZXbPzHN8MGD0deRA== X-Google-Smtp-Source: ABdhPJz2rZMCNGrPg1/QvbFfCQp0I7vEfik3keDmvED/I7ny+b/ACLuAQEVvjwKpH74bSNgDAqcvBQ== X-Received: by 2002:a05:6638:1613:: with SMTP id x19mr2636902jas.77.1631244189785; Thu, 09 Sep 2021 20:23:09 -0700 (PDT) Received: from [192.168.1.116] ([66.219.217.159]) by smtp.gmail.com with ESMTPSA id x21sm1766764ioh.55.2021.09.09.20.23.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 20:23:09 -0700 (PDT) Subject: Re: [git pull] iov_iter fixes To: Al Viro Cc: Linus Torvalds , Pavel Begunkov , Linux Kernel Mailing List , linux-fsdevel References: <5971af96-78b7-8304-3e25-00dc2da3c538@kernel.dk> <88f83037-0842-faba-b68f-1d4574fb45cb@kernel.dk> <8d9e4f7c-bcf4-2751-9978-6283cabeda52@kernel.dk> From: Jens Axboe Message-ID: <641dbf64-b1c4-41f1-6522-e3b0ac9328c2@kernel.dk> Date: Thu, 9 Sep 2021 21:23:08 -0600 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/9/21 9:15 PM, Al Viro wrote: > On Thu, Sep 09, 2021 at 09:06:58PM -0600, Jens Axboe wrote: >> On 9/9/21 8:48 PM, Al Viro wrote: >>> On Thu, Sep 09, 2021 at 07:35:13PM -0600, Jens Axboe wrote: >>> >>>> Yep ok I follow you now. And yes, if we get a partial one but one that >>>> has more consumed than what was returned, that would not work well. I'm >>>> guessing that a) we've never seen that, or b) we always end up with >>>> either correctly advanced OR fully advanced, and the fully advanced case >>>> would then just return 0 next time and we'd just get a short IO back to >>>> userspace. >>>> >>>> The safer way here would likely be to import the iovec again. We're >>>> still in the context of the original submission, and the sqe hasn't been >>>> consumed in the ring yet, so that can be done safely. >>> >>> ... until you end up with something assuming that you've got the same >>> iovec from userland the second time around. >>> >>> IOW, generally it's a bad idea to do that kind of re-imports. >> >> That's really no different than having one thread do the issue, and >> another modify the iovec while it happens. It's only an issue if you >> don't validate it, just like you did the first time you imported. No >> assumptions need to be made here. > > It's not "need to be made", it's "will be mistakenly made by > somebody several years down the road"... If the application changes the iovec passed in while it hasn't been consumed yet, it's buggy. Period. We obviously need to ensure that we only do this re-import IFF we're in the same original submit context still. -- Jens Axboe