Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2602145pxp; Mon, 14 Mar 2022 00:08:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0rYvOJH91j7E8RnQNX41TR9DD6DiJgvciiInPF08RzV43c8cXrueRL5cHiu/mPAYkpBw1 X-Received: by 2002:a17:906:9bd7:b0:6d6:e920:8d04 with SMTP id de23-20020a1709069bd700b006d6e9208d04mr17629946ejc.547.1647241727148; Mon, 14 Mar 2022 00:08:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647241727; cv=none; d=google.com; s=arc-20160816; b=TUYu2DTm/VlaUbRLHDXwCJsgPRamjyMxBoXKan7IRIn0IwIP0EiAZ8UyyhtaUxXvjr 81qNPnWZiZPeIkDWCcRWu3C6LgbEuoZmHTP/xkfeKyccYyIgP6PoATl8qvJgKRJesKWk bDdPdQrcE7kQeCB6UEDP613iiQXzgcawW7dCG4WnbXuQoWyGMVhnFjZqePF34X4uKozF PsNutApoJvjHJxOPvyhEveoF0m4OTzc4w2ugVspfNhTOqrtWjsxYT5sV71AIPXi6/GCN 4bQDZLUIMhaOStnf6iAcbhCn3PvzHr282xbAz3YIuqygf6WjAXyffB+nl7gUthlc/Fux Vk2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=CN6xHbaKhCnYUfGVppONBXDIGvF+fEFz8RcZOoUmO88=; b=MBv1X2zFFnd4ByofQONrfA++OCljubsmnabRaOuvtCG9FEkj/42Kzu6IIA/0eBvMI7 Nbmaz3VvGWqdUvWANND1Fdt3nSTsUS/zPZRDH2bObYDqWochfu4FTQbbaQa1d/vnki57 /G88Y+7rG86cxQ1Mz0FtXoryZCjbz4x936yF/yYRc9g2ACvhf9zz/cuzbba0iVzcavUB /CRU9wldLqRuXnGd1MHezexbWgKxmlEqrOycibOOFEBvazdcDVhduDpULS/7c4c/vSF3 bzwNufsFN8SbJHRWNS0AX3yCNc8nGeAerDcsAdPogfZCt2Au24z1Hqxf05CjfbmKCcrP eE/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l15-20020a1709061c4f00b006d03c19857fsi8220409ejg.725.2022.03.14.00.08.15; Mon, 14 Mar 2022 00:08:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233556AbiCMEfo (ORCPT + 99 others); Sat, 12 Mar 2022 23:35:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229796AbiCMEfm (ORCPT ); Sat, 12 Mar 2022 23:35:42 -0500 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 552F810CA; Sat, 12 Mar 2022 20:34:35 -0800 (PST) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTFw9-00AXen-6W; Sun, 13 Mar 2022 04:34:33 +0000 Date: Sun, 13 Mar 2022 04:34:33 +0000 From: Al Viro To: Matthew Wilcox Cc: Max Kellermann , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] pipe_fs_i.h: add pipe_buf_init() Message-ID: References: <20220225185431.2617232-1-max.kellermann@gmail.com> <20220225185431.2617232-4-max.kellermann@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 13, 2022 at 02:48:10AM +0000, Matthew Wilcox wrote: > That's not equivalent. I think the better option here is to always > initialise flags to 0 (and not have a parameter for it): > > pipe_buf_init(buf, page, 0, 0, &anon_pipe_buf_ops); > if (is_packetized(filp)) > buf->flags = PIPE_BUF_FLAG_PACKET; > else > buf->flags = PIPE_BUF_FLAG_CAN_MERGE; Not equivalent in which sense? IDGI... Your variant is basically X = 0; if (Y == constant) X = 1; else X = 2; If gcc can optimize that to X = (Y == constant) ? 1 : 2; it should be able to do the same to X = 1; if (Y != constant) X = 2; What obstacles are there, besides a (false) assumption that X might alias Y? Which would apply to both variants... Granted, I'm half-asleep right now, so I might be missing something obvious...