Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1856900pxb; Wed, 30 Mar 2022 11:20:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzDc4+O9kCBfDr4HfrZty0klshwkPWjZVgqD0hSQJewRmyfAm4th/wT605jSU1nwamJaJw X-Received: by 2002:a17:907:7892:b0:6df:f38f:bc65 with SMTP id ku18-20020a170907789200b006dff38fbc65mr910128ejc.101.1648664450552; Wed, 30 Mar 2022 11:20:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648664450; cv=none; d=google.com; s=arc-20160816; b=rUQP+S3x2iEtdUU1pUZgt/JPAvJ5TvUu7iljc9EmUwkJKIbuyxUQ9QDNr67C7c1DqY 1n2qoh7R0wY3vQfaaTNleKLKOR+Ykg9cTvQiPzt4CDnD8udXu0AaQa29T+8uiflZ95iJ Z3wucmF7rcXKIPCpVEYwhiv0B0oLyKbTnHyEuP+KdDl3jkChPW2JnvPwGnIBufj3XNwi b34nI+45vbHw0FV5R41xHEolc7B7AZ4yPZeifzphg+dhWXTrHTPgTLw2/3n2eL6YV6TZ s0XVYzWcZ08LQ2n54dbXJG8YHGtTNGhPB6JcDPcZK/5bDrvqmL0w7eliQPxO1cYdW+yd jd5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version:date :message-id:subject:references:in-reply-to:cc:to:from:dkim-signature; bh=S7jHDD9H3A3SYC5lPe9ohlnX79nRebzt30Q3Ep3X12o=; b=P1ZiVCgi/Hh5/7nsJKSfKdjJ/kdZKKMiYCh4ikrPjflLRUfMT+Zx6dfd9N9S28x4rC xVMr6J58O6q8H4LrVB5B8PQkzsmJ69Rw5k35TXQ6W/NCjUvqbm3mwhqv6luto89zhyuf 19d3pczL1cJnh17wUxVQh3O5OdyFEpuLmvcHFPTB2zEErfQjwPbWG4HhI1IfFNcwdiAV op5X8mlz111w2R0/fpJMlKegWj0Kafu6Gxd5Le3EBlreoMNVcGOdGxv5NUpjbBYkZdRs UiNzmIyrLDTYhUqWJ1IeLEPAyz+C0j81Ac6C4ZQrQ++KBKn/xFyoKV34+oqxWyFdCt8l E3IA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=OZ3cEQ5h; 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 la14-20020a170906ad8e00b006e0a811b828si19494808ejb.313.2022.03.30.11.20.24; Wed, 30 Mar 2022 11:20:50 -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=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=OZ3cEQ5h; 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 S1347248AbiC3Ovo (ORCPT + 99 others); Wed, 30 Mar 2022 10:51:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347246AbiC3OvZ (ORCPT ); Wed, 30 Mar 2022 10:51:25 -0400 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59D481659E for ; Wed, 30 Mar 2022 07:49:39 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id 14so9988662ily.11 for ; Wed, 30 Mar 2022 07:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=from:to:cc:in-reply-to:references:subject:message-id:date :mime-version:content-transfer-encoding; bh=S7jHDD9H3A3SYC5lPe9ohlnX79nRebzt30Q3Ep3X12o=; b=OZ3cEQ5h4qtPgX1AY6RLmB6gT57kvwRHQ79ygDaebLZjiOApKBgJvNSiNC+hGN40JU KFowpuzoi9RAMLTJX0fOxY1oyMHVZHloUrVLxLuOG/UlFNOYGVgGvwa2UU4emiJEzaf9 q/b6t2EDuopDh+F9mdxQX6O8ADsK4gowwAsRa9RVPJ5GdcZXQj2mX6/QUQhRN12B8hnH NkupImYcQse6AfeDQRluWPm9O4lLIm1PCY+Y0ru6sks+rFgKWBzTtmSTEYxmLYKnRe/x TPd8nXiKZe260b1aynJD8YblWjvbxaX/g0RFrXX3pPqJAeiHYOnhcG7UGyHQwei5xlG9 5gPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:in-reply-to:references:subject :message-id:date:mime-version:content-transfer-encoding; bh=S7jHDD9H3A3SYC5lPe9ohlnX79nRebzt30Q3Ep3X12o=; b=LOrTuaEmMIad9Vl/kW6mGbKJSwq3l/YqwyXde67ykZENWpevM0eOoEYGdbeXi+jbcE /A9NRaXMK0R4hMEtA/jUPt7NtQw+GTiDwecBIegT0T6fWVblaS5ifxCoG3+aTb+gMmxv KRj61cmRWZUDjGpdiBnzyUsDfG8XjDLZIeJl3+cMBp6QOEkom22Ce686WpCuRK0ZxDKC +9hga9qLFxSjc9WHWsVsGpzLbUok8GYOwu75siekFgP/d0IwalvGf0nUYxQPl1kh6XOA w3/Z+54W5/C8i6qz9ckvqEu4QsNReG/dYzcTKk/Q04dbVQ7iwkPAtNqzCY9Q7aHNnFAi hghQ== X-Gm-Message-State: AOAM532GD4NjjvIhaZXHYizQ3ZwlAZ5qtMO1Zx02kaQu1upzZYdN2lEF bSiTVxlvWIIfcjtLZ+ObNwDVRA== X-Received: by 2002:a05:6e02:1e0e:b0:2c6:18c3:9691 with SMTP id g14-20020a056e021e0e00b002c618c39691mr11475070ila.287.1648651778718; Wed, 30 Mar 2022 07:49:38 -0700 (PDT) Received: from [127.0.1.1] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id r9-20020a6b6009000000b006412abddbbbsm11434439iog.24.2022.03.30.07.49.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 07:49:38 -0700 (PDT) From: Jens Axboe To: Christoph Hellwig Cc: David Sterba , linux-btrfs@vger.kernel.org, linux-bcache@vger.kernel.org, dm-devel@redhat.com, linux-kernel@vger.kernel.org, Song Liu , Coly Li , Phillip Lougher , "Martin K. Petersen" , Mike Snitzer , target-devel@vger.kernel.org, Josef Bacik , linux-raid@vger.kernel.org, linux-block@vger.kernel.org In-Reply-To: <20220308061551.737853-1-hch@lst.de> References: <20220308061551.737853-1-hch@lst.de> Subject: Re: cleanup bio_kmalloc v2 Message-Id: <164865177761.37391.13379579175408786139.b4-ty@kernel.dk> Date: Wed, 30 Mar 2022 08:49:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Tue, 8 Mar 2022 07:15:46 +0100, Christoph Hellwig wrote: > this series finishes off the bio allocation interface cleanups by dealing > with the weirdest member of the famility. bio_kmalloc combines a kmalloc > for the bio and bio_vecs with a hidden bio_init call and magic cleanup > semantics. > > This series moves a few callers away from bio_kmalloc and then turns > bio_kmalloc into a simple wrapper for a slab allocation of a bio and the > inline biovecs. The callers need to manually call bio_init instead with > all that entails and the magic that turns bio_put into a kfree goes away > as well, allowing for a proper debug check in bio_put that catches > accidental use on a bio_init()ed bio. > > [...] Applied, thanks! [1/5] btrfs: simplify ->flush_bio handling commit: 6978ffddd5bba44e6b7614d52868cf4954e0529b [2/5] squashfs: always use bio_kmalloc in squashfs_bio_read commit: 88a39feabf25efbaec775ffb48ea240af198994e [3/5] target/pscsi: remove pscsi_get_bio commit: bbccc65bd7c1b22f050b65d8171fbdd8d72cf39c [4/5] block: turn bio_kmalloc into a simple kmalloc wrapper commit: 57c47b42f4545b5f8fa288f190c0d68f96bc477f [5/5] pktcdvd: stop using bio_reset commit: 1292fb59f283e76f55843d94f066c2f0b91dfb7e Best regards, -- Jens Axboe