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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 57B47C48BDF for ; Fri, 18 Jun 2021 21:10:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 37F1461261 for ; Fri, 18 Jun 2021 21:10:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234457AbhFRVNI (ORCPT ); Fri, 18 Jun 2021 17:13:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234443AbhFRVNG (ORCPT ); Fri, 18 Jun 2021 17:13:06 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4046C06175F for ; Fri, 18 Jun 2021 14:10:55 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id p7so18694701lfg.4 for ; Fri, 18 Jun 2021 14:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IggsOVtZWaDfaAjVQj4i9sjHXM/g9u+SuRPy3G5buhU=; b=IdCDb8XLNd4gSRp6kXJhby/ljjp+PXKky4uW7qFCR1/rkcVRP08toOusxumJVYjA6X kUQdieqI0aumZ0iOyCbaZQ+jH9t0sOwuxFGVbSA2DavBqJkBHAM5Sz5MMTfl4icGYGrK jR9+83dk7r+H/+jzIxFclci70l2r7nrmDRCcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IggsOVtZWaDfaAjVQj4i9sjHXM/g9u+SuRPy3G5buhU=; b=DngshTrvnece4RS83qtMp4RxTq+GQDIDd/k7MUashoJuTFJpLGqWv1y0CIC9p0Dzr6 UFyfPxibhncio8qnSoFlVsgJHTRP6DS0p9xPs1uRqniNyskbjgUpBZn90RQfnUaFq7p9 pNkZuJlDUpYfZdnboiiay5Cg+YkykapPR/NGqFy64fF1exwE0qluhWBacRrJkoTtlSof v20kRXDb6m9/Q0iZUso4zY3X5QJj+1A/UWqNPXYePbuUj39rmEd0GKe689B36bdt02jw y6X9RaSDBsZd2N/mGKuoJBOY3Z2CSXJwspgxeKmsafO9d4wIIy2GbxPRgWZyEXhJokiu KuRQ== X-Gm-Message-State: AOAM533pYqbyBPRpaoFAt8j/0H3p7onqn7Zh4n+M8cC/4B/KB6KRZL7R lrWHSyq6ZA1STrjBUgDjakopOFedmS+PgK6r X-Google-Smtp-Source: ABdhPJxGrq+GysvwcycMmNQGdowu4Iv49trN+15ga/7AxBzuGr13PP8BXg9CTeGDRcXdcqEzn0tw9g== X-Received: by 2002:a19:4949:: with SMTP id l9mr4527240lfj.642.1624050654042; Fri, 18 Jun 2021 14:10:54 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id v2sm45767lfd.224.2021.06.18.14.10.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jun 2021 14:10:53 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id h15so214615lfv.12 for ; Fri, 18 Jun 2021 14:10:52 -0700 (PDT) X-Received: by 2002:a05:6512:baa:: with SMTP id b42mr4514578lfv.487.1624050652225; Fri, 18 Jun 2021 14:10:52 -0700 (PDT) MIME-Version: 1.0 References: <6caae597eb20da5ea23e53e8e64ce0c4f4d9c6d2.1623972519.git.osandov@fb.com> In-Reply-To: From: Linus Torvalds Date: Fri, 18 Jun 2021 14:10:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RESEND x3 v9 1/9] iov_iter: add copy_struct_from_iter() To: Al Viro Cc: Omar Sandoval , linux-fsdevel , linux-btrfs , Linux API , Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jun 18, 2021 at 1:58 PM Al Viro wrote: > > On Fri, Jun 18, 2021 at 01:32:26PM -0700, Omar Sandoval wrote: > > > RWF_ENCODED is intended to be used like this: > > > > struct encoded_iov encoded_iov = { > > /* compression metadata */ ... > > }; > > char compressed_data[] = ...; > > struct iovec iov[] = { > > { &encoded_iov, sizeof(encoded_iov) }, > > { compressed_data, sizeof(compressed_data) }, > > }; > > pwritev2(fd, iov, 2, -1, RWF_ENCODED); > > > > Basically, we squirrel away the compression metadata in the first > > element of the iovec array, and we use iov[0].iov_len so that we can > > support future extensions of struct encoded_iov in the style of > > copy_struct_from_user(). > > Yecchhh... Al, this has been true since the beginning, and was the whole point of the set. > Just put the size of the encoded part first and be done with that. > Magical effect of the iovec sizes is a bloody bad idea. That makes everything uglier and more complicated, honestly. Then you'd have to do it in _two_ operations ("get the size, then get the rest"), *AND* you'd have to worry about all the corner-cases (ie people putting the structure in pieces across multiple iov entries. So it would be slower, more complex, and much more likely to have bugs. So no. Not acceptable. The "in the first iov" is simple, efficient, and avoids all the problems. The size *is* encoded already - in the iov itself. Encoding it anywhere else is much worse. The only issue I have is that the issue itself is kind of ugly - regardless of any iov issues. And the "encryption" side of it doesn't actually seem to be relevant or solvable using this model anyway, so that side is questionable. The alternative would be to have an ioctl rather than make this be about the IO operations (and then that encoded data would be explicitly separate). Which I suggested originally, but apparently people who want to use this had some real reasons not to. But encoding the structure without having the rule of "first iov only" is entirely unacceptable to me. See above. It's objectively much much worse. Linus