Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp35649536rwd; Mon, 10 Jul 2023 10:21:34 -0700 (PDT) X-Google-Smtp-Source: APBJJlFqYsU496h0p+sdFjAgvc7ADma2xDCx9D/tI0OSTW6HK/KE15KvnORGGagbFTqrRhDnq2jC X-Received: by 2002:a5d:5303:0:b0:313:edaa:24fd with SMTP id e3-20020a5d5303000000b00313edaa24fdmr11556722wrv.21.1689009694395; Mon, 10 Jul 2023 10:21:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689009694; cv=none; d=google.com; s=arc-20160816; b=UJI961uPpzIQt4cNouLXCBAtn5d0HlkPTy0P5Ul5B6nPO9vgmSLVmuF7ftLdQLtnX+ mIqSL5oYmNsqiqupmNGQzZnOVNHqyKdVwRajVmKt/tBWN9UGL+v1ZStIwtCEgFzlOsLw 5bJx9cKvkO4PzwNH+59J1SBIBI87igD7/on+C2NTy+MVyZYoZw9twmdZf0duS0hRRabc q6VBmsdBOscY5B/4t+M7kP4HjAw1HCxYvIzqUi/6Vb8BXdN+rNle2Ciaov9O5OfroT7Y mYdLmq2UoEbq8gL6kTMJBmdHBbAVKkJEGVZJNhLMIjHy+oeryyuZhc/kX4sc03WPmH3+ ylGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature:dkim-signature; bh=aoEB1v5p+JaOAwcNX2Xgzr1h4ME0r6a9ORk8q4gaqfA=; fh=efMLUKzq78ltYsW+PNApKU17u1ILLudw/uYxjeRO9zc=; b=LyZxsMcvZxiw2pJdxgwcKnFDXV9Dzmj+80vSmsG226DhTZckw1LVYqjPVr8TBqF9qy JeFz2Ps7pyjKrgzox9JVXZnllpK/t/VhUHLErBKggv/04Nudrgmnbq0u/0nblHItIdG6 dDaWeTZfIhuEwMTlOBBv3on4AogJmZPs4hAms42NI0xkdhTMHkkdP5KEhDx18HbpP2mZ EX+H4mhz/BTmw9MzPp8MPNxziV6qzFLNWXXOwupIqW67ecdyU6QUYQm2mSiCDbUT141u rXX18kzel/Jk/MlbRjoAUhxBuKXeZ0kwkvP8iokHsAPlDpU+CorsPiFUU3RvKb1jjGh3 otfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=N7TPH1KC; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z21-20020a170906715500b0098df1cbe2aesi10023439ejj.1008.2023.07.10.10.21.09; Mon, 10 Jul 2023 10:21:34 -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; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=N7TPH1KC; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231851AbjGJQ7D (ORCPT + 99 others); Mon, 10 Jul 2023 12:59:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231760AbjGJQ7C (ORCPT ); Mon, 10 Jul 2023 12:59:02 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53DE0E3; Mon, 10 Jul 2023 09:59:01 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id F35561FF3A; Mon, 10 Jul 2023 16:58:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1689008340; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aoEB1v5p+JaOAwcNX2Xgzr1h4ME0r6a9ORk8q4gaqfA=; b=N7TPH1KC7YSj0Zua71hmaHWdcoFviJJDjfikzYhcw5goXZDLQApt2kUczL79MWRUyShJek ZGisHTHmFbYXSTNwgtRmePcMZ8P7vl6g+97RgHE5a42L321+uRnz6vrOnJy6YFcvGKCln9 VeDEaFe85Udv/3GhxKbJijI3M8sgN9w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1689008340; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aoEB1v5p+JaOAwcNX2Xgzr1h4ME0r6a9ORk8q4gaqfA=; b=C+oxvZRvkLlfpxjHxPnh6LEulwCPDr02dhoPjIWSByTBD/bdcoR8O1OLvlk9AiCGr9hY4v qiiXRYlVJ1yAkpAA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B295D13A05; Mon, 10 Jul 2023 16:58:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id knYaJtM4rGQDCgAAMHmgww (envelope-from ); Mon, 10 Jul 2023 16:58:59 +0000 From: Gabriel Krisman Bertazi To: Lu Hongfei Cc: Jens Axboe , Pavel Begunkov , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, opensource.kernel@vivo.com Subject: Re: [PATCH] io_uring: Redefined the meaning of io_alloc_async_data's return value References: <20230710090957.10463-1-luhongfei@vivo.com> Date: Mon, 10 Jul 2023 12:58:58 -0400 In-Reply-To: <20230710090957.10463-1-luhongfei@vivo.com> (Lu Hongfei's message of "Mon, 10 Jul 2023 17:09:56 +0800") Message-ID: <87o7kjr9d9.fsf@suse.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,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 Lu Hongfei writes: > Usually, successful memory allocation returns true and failure returns false, > which is more in line with the intuitive perception of most people. So it > is necessary to redefine the meaning of io_alloc_async_data's return value. > > This could enhance the readability of the code and reduce the possibility > of confusion. just want to say, this is the kind of patch that causes bugs in downstream kernels. It is not fixing anything, and when we backport a future bugfix around it, it is easy to miss it and slightly break the semantics. That's my downstream problem, of course. But at least it would be good practice to change the symbol, making the change hard to miss. Or make the function return int instead of bool, which preserves the interface and is a common C idiom. Or leave it as it is, which is quite readable already.. thx, > Signed-off-by: Lu Hongfei > --- > io_uring/io_uring.c | 13 +++++++++---- > io_uring/net.c | 4 ++-- > io_uring/rw.c | 2 +- > io_uring/timeout.c | 2 +- > io_uring/uring_cmd.c | 2 +- > 5 files changed, 14 insertions(+), 9 deletions(-) > > diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > index e8096d502a7c..19f14b7b417d 100644 > --- a/io_uring/io_uring.c > +++ b/io_uring/io_uring.c > @@ -1753,14 +1753,19 @@ unsigned int io_file_get_flags(struct file *file) > return res; > } > > +/* > + * Alloc async data to the req. > + * > + * Returns 'true' if the allocation is successful, 'false' otherwise. > + */ > bool io_alloc_async_data(struct io_kiocb *req) > { > WARN_ON_ONCE(!io_cold_defs[req->opcode].async_size); > req->async_data = kmalloc(io_cold_defs[req->opcode].async_size, GFP_KERNEL); > - if (req->async_data) { > - req->flags |= REQ_F_ASYNC_DATA; > + if (!req->async_data) > return false; > - } > + > + req->flags |= REQ_F_ASYNC_DATA; > return true; > } > > @@ -1777,7 +1782,7 @@ int io_req_prep_async(struct io_kiocb *req) > if (WARN_ON_ONCE(req_has_async_data(req))) > return -EFAULT; > if (!def->manual_alloc) { > - if (io_alloc_async_data(req)) > + if (!io_alloc_async_data(req)) > return -EAGAIN; > } > return cdef->prep_async(req); > diff --git a/io_uring/net.c b/io_uring/net.c > index eb1f51ddcb23..49e659d3a874 100644 > --- a/io_uring/net.c > +++ b/io_uring/net.c > @@ -152,7 +152,7 @@ static struct io_async_msghdr *io_msg_alloc_async(struct io_kiocb *req, > } > } > > - if (!io_alloc_async_data(req)) { > + if (io_alloc_async_data(req)) { > hdr = req->async_data; > hdr->free_iov = NULL; > return hdr; > @@ -1494,7 +1494,7 @@ int io_connect(struct io_kiocb *req, unsigned int issue_flags) > } > if (req_has_async_data(req)) > return -EAGAIN; > - if (io_alloc_async_data(req)) { > + if (!io_alloc_async_data(req)) { > ret = -ENOMEM; > goto out; > } > diff --git a/io_uring/rw.c b/io_uring/rw.c > index 1bce2208b65c..90d4be57a811 100644 > --- a/io_uring/rw.c > +++ b/io_uring/rw.c > @@ -523,7 +523,7 @@ static int io_setup_async_rw(struct io_kiocb *req, const struct iovec *iovec, > if (!req_has_async_data(req)) { > struct io_async_rw *iorw; > > - if (io_alloc_async_data(req)) { > + if (!io_alloc_async_data(req)) { > kfree(iovec); > return -ENOMEM; > } > diff --git a/io_uring/timeout.c b/io_uring/timeout.c > index fb0547b35dcd..35a756d22781 100644 > --- a/io_uring/timeout.c > +++ b/io_uring/timeout.c > @@ -534,7 +534,7 @@ static int __io_timeout_prep(struct io_kiocb *req, > > if (WARN_ON_ONCE(req_has_async_data(req))) > return -EFAULT; > - if (io_alloc_async_data(req)) > + if (!io_alloc_async_data(req)) > return -ENOMEM; > > data = req->async_data; > diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c > index 476c7877ce58..716a28495bf3 100644 > --- a/io_uring/uring_cmd.c > +++ b/io_uring/uring_cmd.c > @@ -139,7 +139,7 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags) > ret = file->f_op->uring_cmd(ioucmd, issue_flags); > if (ret == -EAGAIN) { > if (!req_has_async_data(req)) { > - if (io_alloc_async_data(req)) > + if (!io_alloc_async_data(req)) > return -ENOMEM; > io_uring_cmd_prep_async(req); > } -- Gabriel Krisman Bertazi