Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp6950344rwl; Mon, 9 Jan 2023 15:36:47 -0800 (PST) X-Google-Smtp-Source: AMrXdXsV5ylcmr449GQfbtCU0HaFOnMme5rAOk0TIibRPZTkhwzHMHm7pBX8PWE4QEo8PBBGOPc7 X-Received: by 2002:a05:6402:f02:b0:46f:a2c2:405b with SMTP id i2-20020a0564020f0200b0046fa2c2405bmr69280212eda.37.1673307407672; Mon, 09 Jan 2023 15:36:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673307407; cv=none; d=google.com; s=arc-20160816; b=mNfPo1UHL68f99FTc+X4Wu01HQhCWXFW9llZpVuu3z9GAV21M4ODHjouJvz6AOLtSF T9Ky6ErYi3ClzUxkB+SL0VoazxYWGSmIhxowT/zzvV22fPC+isWG8iWYu+1e7ZJFWBND y+IE6r+4uwTaKS1g6SqLqzk7rf11cCX9GoEIGtoprpC0E9jI9emYtKsOZhy7IhfEZri1 sU4igG5+UAQ2z4n9EBvKJzJ9ZdRRgsmZdI1/hb8xvfc0VEWkKusXRLk/dXqnLCRAzX0y vlduaRfHKzZ91OVRz2/DOLM7kPnnIHjD8m/RvHrkIvqWW818ZaoZ8BW1pX+l/oP8FUcu QuXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=mdo2/wDqCM6o38jdj1jQCw6QRnTv8QbOLw7MxYlHlrk=; b=oo1f4FS/hDj8W+zm2UKmchaNuNeRwn+HlPzjUpoFjdcyRjAqznWsYJlzI/wwGJkApF Om01lUEGW0r4md9zBZsx7svy7ESLMsvK1zUs+rI1BmYhitKt+rbaOImP0vUT9FBxwito U0niE6aDkSWICxY2YfQWWdovjCyvz1UTjCDNAvqVaz7GrSzsOGnlUaP9+gg3yfvJCOTj uX2s+oIO69k8Csp/hx75xiVYLSdAp4UjZZLV4AETn/W8RFazId+Q19ql/PtFl2fyn2Ft b+bgfartY4qCHTrCY7M5uGTzHQAhWuDIogjH9KjG+307ez0+Ca8vIiejE59PYBuHU1p0 5u6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=16g0R6uN; 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 m15-20020a50998f000000b004825e4a6946si9785647edb.371.2023.01.09.15.36.34; Mon, 09 Jan 2023 15:36:47 -0800 (PST) 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=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=16g0R6uN; 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 S237534AbjAIW5P (ORCPT + 55 others); Mon, 9 Jan 2023 17:57:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235136AbjAIW5N (ORCPT ); Mon, 9 Jan 2023 17:57:13 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C899D11148 for ; Mon, 9 Jan 2023 14:57:10 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id cp9-20020a17090afb8900b00226a934e0e5so121675pjb.1 for ; Mon, 09 Jan 2023 14:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mdo2/wDqCM6o38jdj1jQCw6QRnTv8QbOLw7MxYlHlrk=; b=16g0R6uNNKJzKpGNX1lPaagFx4n+ocJT15a6CdoHNRa3kXLdm6l+X8tfKfzip4O9jL Yx+m9c63FhJXRDdVtlpHrKcAbabIPQouM2gr+v0XMy5vTKHj4VsH3CPzwF1bUWbwotNw KN5ErzbzOn9FYZdNIAv81d6HVQGw3Eajg7Ab4eJ1Q9kXLwN5JNxyjSeGtLh5npdkpksS SwjDmHsj0OK8Rjo+CUmHIxDJKovAiZ66EMy2Bi6LW2PDGeoYVleAk0fUx4zyoA9jkJI6 WIxcVTURovOsbweHx5PapLCSaZWH9/pzAywtrDuhZle66SzY1c7kNobHrQjZulVuFbQ9 GeEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mdo2/wDqCM6o38jdj1jQCw6QRnTv8QbOLw7MxYlHlrk=; b=pxa9Tic8toAPJz9p/HMm7A474QOQOhUETU8bcAhTbyJ+SG31sI6jQSDcfQ/WLVdVxl BtOAYjpl5hkc7muSBpwMdTc0s2E218R4zikT7+MFVO3wAUBT6cqRud6Blr3md2y8Jamr 6JpbU+sBoMwl6KdAfGQBjUIit2f/3oHR/KuLT6KHFSRZ1WvN20AjrL0w0rBCAVV5Uffj y+YaPFDTZjfG6c4AoiVPOadVkYnIIPy4NlbeqvL7gZtmXOfEtMEWNrjY/ugAXOuQ0UIx hxKiWlB9RlpChgzl226/Hl7by+NeTSy3XBUXB+oAKue+1veFIEZD6H248nxEj81ydiVS G2Dw== X-Gm-Message-State: AFqh2kp8vbaIAx4sO39TuvEq1UE8ieE6oesZRFbFoGlWkmhns0AY4Fko ctBVKvePI7Fn7xYFfnG5TmWOnQ== X-Received: by 2002:a17:902:b611:b0:189:f277:3834 with SMTP id b17-20020a170902b61100b00189f2773834mr14677883pls.6.1673305030113; Mon, 09 Jan 2023 14:57:10 -0800 (PST) Received: from [192.168.1.136] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id c6-20020a170902c1c600b00177f4ef7970sm6681389plc.11.2023.01.09.14.57.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jan 2023 14:57:09 -0800 (PST) Message-ID: Date: Mon, 9 Jan 2023 15:57:08 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v4 7/7] iov_iter, block: Make bio structs pin pages rather than ref'ing if appropriate To: David Howells Cc: Jan Kara , Al Viro , Christoph Hellwig , Matthew Wilcox , Logan Gunthorpe , Christoph Hellwig , Jeff Layton , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230109173513.htfqbkrtqm52pnye@quack3> <167305160937.1521586.133299343565358971.stgit@warthog.procyon.org.uk> <167305166150.1521586.10220949115402059720.stgit@warthog.procyon.org.uk> <2008444.1673300255@warthog.procyon.org.uk> <2084839.1673303046@warthog.procyon.org.uk> Content-Language: en-US From: Jens Axboe In-Reply-To: <2084839.1673303046@warthog.procyon.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 1/9/23 3:24?PM, David Howells wrote: > Would you be okay with me flipping the logic of BIO_NO_PAGE_REF, so I end up > with: > > static void bio_release_page(struct bio *bio, struct page *page) > { > if (bio_flagged(bio, BIO_PAGE_PINNED)) > unpin_user_page(page); > if (bio_flagged(bio, BIO_PAGE_REFFED)) > put_page(page); > } > > See attached patch. I think it makes more sense to have NO_REF check, to be honest, as that means the general path doesn't have to set that flag. But I don't feel too strongly about that part. > diff --git a/block/bio.c b/block/bio.c > index 5f96fcae3f75..5b9f9fc62345 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -243,6 +243,11 @@ static void bio_free(struct bio *bio) > * Users of this function have their own bio allocation. Subsequently, > * they must remember to pair any call to bio_init() with bio_uninit() > * when IO has completed, or when the bio is released. > + * > + * We set the initial assumption that pages attached to the bio will be > + * released with put_page() by setting BIO_PAGE_REFFED, but this should be set > + * to BIO_PAGE_PINNED if the page should be unpinned instead; if the pages > + * should not be put or unpinned, these flags should be cleared. > */ > void bio_init(struct bio *bio, struct block_device *bdev, struct bio_vec *table, > unsigned short max_vecs, blk_opf_t opf) > @@ -274,6 +279,7 @@ void bio_init(struct bio *bio, struct block_device *bdev, struct bio_vec *table, > #ifdef CONFIG_BLK_DEV_INTEGRITY > bio->bi_integrity = NULL; > #endif > + bio_set_flag(bio, BIO_PAGE_REFFED); This is first set to zero, then you set the flag. Why not just initialize it like that to begin with? > @@ -302,6 +308,8 @@ void bio_reset(struct bio *bio, struct block_device *bdev, blk_opf_t opf) > { > bio_uninit(bio); > memset(bio, 0, BIO_RESET_BYTES); > + bio_set_flag(bio, BIO_PAGE_REFFED); > + bio_clear_flag(bio, BIO_PAGE_PINNED); > atomic_set(&bio->__bi_remaining, 1); > bio->bi_bdev = bdev; > if (bio->bi_bdev) You just memset bi_flags here, surely we don't need to clear BIO_PAGE_PINNED after that? > @@ -814,6 +822,8 @@ static int __bio_clone(struct bio *bio, struct bio *bio_src, gfp_t gfp) > bio_set_flag(bio, BIO_CLONED); > bio->bi_ioprio = bio_src->bi_ioprio; > bio->bi_iter = bio_src->bi_iter; > + bio_clear_flag(bio, BIO_PAGE_REFFED); > + bio_clear_flag(bio, BIO_PAGE_PINNED); Maybe it would make sense to have a set/clear mask operation? Not strictly required for this patch, but probably worth checking after the fact. > @@ -1273,12 +1295,20 @@ static int __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter) > * result to ensure the bio's total size is correct. The remainder of > * the iov data will be picked up in the next bio iteration. > */ > - size = iov_iter_get_pages(iter, pages, > - UINT_MAX - bio->bi_iter.bi_size, > - nr_pages, &offset, gup_flags); > + size = iov_iter_extract_pages(iter, &pages, > + UINT_MAX - bio->bi_iter.bi_size, > + nr_pages, gup_flags, > + &offset, &cleanup_mode); > if (unlikely(size <= 0)) > return size ? size : -EFAULT; > > + bio_clear_flag(bio, BIO_PAGE_REFFED); > + bio_clear_flag(bio, BIO_PAGE_PINNED); > + if (cleanup_mode & FOLL_GET) > + bio_set_flag(bio, BIO_PAGE_REFFED); > + if (cleanup_mode & FOLL_PIN) > + bio_set_flag(bio, BIO_PAGE_PINNED); > + > nr_pages = DIV_ROUND_UP(offset + size, PAGE_SIZE); The cleanup_mode pass-back isn't the prettiest thing in the world, and that's a lot of arguments. Maybe it'd be slightly better if we just have gup_flags be an output parameter too? Also not great to first clear both flags, then set them with the two added branches... > diff --git a/include/linux/bio.h b/include/linux/bio.h > index 22078a28d7cb..1c6f051f6ff2 100644 > --- a/include/linux/bio.h > +++ b/include/linux/bio.h > @@ -482,7 +482,8 @@ void zero_fill_bio(struct bio *bio); > > static inline void bio_release_pages(struct bio *bio, bool mark_dirty) > { > - if (!bio_flagged(bio, BIO_NO_PAGE_REF)) > + if (bio_flagged(bio, BIO_PAGE_REFFED) || > + bio_flagged(bio, BIO_PAGE_PINNED)) > __bio_release_pages(bio, mark_dirty); > } Same here on a mask check, but perhaps it ends up generating the same code? -- Jens Axboe