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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EC6EC83F17 for ; Thu, 10 Jul 2025 19:51:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2B066B009E; Thu, 10 Jul 2025 15:51:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F02F36B00A0; Thu, 10 Jul 2025 15:51:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3FD26B00A1; Thu, 10 Jul 2025 15:51:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D7FEA6B009E for ; Thu, 10 Jul 2025 15:51:39 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F39CBC110E for ; Thu, 10 Jul 2025 19:51:38 +0000 (UTC) X-FDA: 83649399876.03.CEDF6AF Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf03.hostedemail.com (Postfix) with ESMTP id 4029D20019 for ; Thu, 10 Jul 2025 19:51:37 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UKXXsY6x; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of kbusch@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752177097; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=73T0S68KeskRKZfk7ZSsugVOMozAx93ri4BHGIPlnOo=; b=t3LH077u1lbAmQc9K9EefxNl54dKQWlpA1lMzdlXv2Uwhe6BGFxZNuzXlrio3eBs5ZAPPg HIr+ack4ieqrlkbQfuqK6MANSYjmukXCB+nERcFjJW5BArNUx8VuOhEFBqPBv65Y2xpo6D 9JnZfQ4jhz75pBoRcBHwa0S5u22M3GI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UKXXsY6x; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of kbusch@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=kbusch@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752177097; a=rsa-sha256; cv=none; b=qvc67B2VF3iIhzR1RTzDkTr0VMnBbdsWk+pfFxV5om2jRCyEGP1DT2zewzUFPvpq3FfD2R ABX2XFbwlnevm/B9M79mAcxFI1lPY1xrxF70QS5q4FAPtXpOtkr4h9K6Np8vJjUBE7RV6N WwW4LisSb/PH3VGFMb0XoGkNYrVH1KI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id D47FD43499; Thu, 10 Jul 2025 19:51:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5FEDC4CEE3; Thu, 10 Jul 2025 19:51:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752177095; bh=z6Vb0hDPgvh+Zg/g3GJWRWckfO4hy+X/KmQVekry7Lw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UKXXsY6xEsTP5LTdTXEndWnZXO//ZS4oKNP3v80/LspWjeO5VekHTsvEKVCMNT55I 7FE1RKuJ1jJqZC/cvrzlqn/2RVRgM0ag1LoAdlefTEKXtSiJTbtWMrupEG042Lyhxg BlzxOf/ZD8JhYrD4XI16oH3GzpS2kI+5jWiZSORM7/kM45Vkb+FXAZEs2KIZKkXQZ8 ifQwAmGCJjdUvFvfczT72D2/0KFmr8xuy+5Ey5/5l0+xgu78pfOPIEnbmYKemYnhuj eRYn8v7ABRs98YPs/4V3p3prACHHX4zngKGSeXdw4A2laBWCa4WHk0bK902xW07DQK nCc3+jFjqc0lw== Date: Thu, 10 Jul 2025 13:51:33 -0600 From: Keith Busch To: Mike Snitzer Cc: Ming Lei , Jens Axboe , Jeff Layton , Chuck Lever , NeilBrown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, hch@infradead.org, linux-block@vger.kernel.org Subject: Re: [RFC PATCH v2 4/8] lib/iov_iter: remove piecewise bvec length checking in iov_iter_aligned_bvec Message-ID: References: <20250708160619.64800-1-snitzer@kernel.org> <20250708160619.64800-5-snitzer@kernel.org> <5819d6c5bb194613a14d2dcf05605e701683ba49.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4029D20019 X-Stat-Signature: 3iqwm9k1k1dfqnkhq1bcuwnbpo93ef4u X-Rspam-User: X-HE-Tag: 1752177097-988062 X-HE-Meta: U2FsdGVkX19XPgHq1K7jFSi5mMqdDnkRjFo00vwhlYS/Si3XXk2lhqNRzQeuNaHAYPhZH5Z6NetcK8dp5IhLVJuN78XFbKybIxymIBO3KLa3VNkC4D74p84jIrCjTsHiGeZsVROueYXo5gKdaezS1rWQ2po/1pa+2/+0Z20A6vWKRHj1r8rcWYcd92Yue9mmlHBfajyKz3HYdP2joZ1d2qbXHer5bO3X9PcxZ3hmyEw5MiOUSgcA6KUDZBTaWnXRGNCaDUP3/NjOjQGOI7Ue93ihJ+rp6ZDZSoKbzF4WR3PP4sLW0K1mEjcEE/vJqmxSXLbl6edmJihJNAKVMncLOYGB5RBIy2dTEWQf/aEMFW+XGghHa11PmSrdws0ZJB/peHe6Tg5W8j04DeFdBI4pzj/MVkZl+DBSkg6Il9cor7gIgHyGDU6ukIju0YuF+E0CPTl7RNdaLt9ULiQr1s78vl7lQkRzmaXAVbLsMiFBSYnilDEL+5XoUT1FMc2V0fBpEMwLLwarRt1edVlWCz6grKj1jChvhrGD4v2YVL2CmE1ymflA4fONLVP1zOgOhjkH9ncVormBXYBz62gK0XaRxo3jawkkE6KgEv45SBxZSMzUzo+PPHXWOatu4MVY0EtJGGUnIqZRhFWXGEerYMYKVJjDBNiUDwcEaXRouYp1CvPQbQr1XPr/tVxdu4wcAUwe6DtLGduGOvtTvvI39Q3PBBfbojCxnuW0lG/S3GeS/y3MnT6AvcI1W+3xOyMTG/v1r2q74sJdRlsSgA+BQ0Xbh4N/QibN+PFJtalnsVqgQxnjD4TYxdW6AOSKLkxqPE0Tyme1KRy9rFM4ipNtfbAte0+M08INe0h18LShFtwrSHCHRlIJRLHLZcgrgxlVDtnrnEXKGKbh8s70w6MHAJ5oq5fHgMTDHncbzChbl/2YCMxhAWl14+8m4YYWS4URORydYnQ1kpP+eR39s3qxSZY 37ikYFKn nlSSjKr1950hu8quDoss2rlviouISiAcAzhCO+mZ90zwnP2smKMxDBpENxG4HEMlSp10YjZvVerxvvBUaixIUDMWhezwUOqb9uca5UK9Cmabcv76uuR/9g+LeC0cOMTYc+XyMEW8CgkCKPWdmMKG0fy9GP9MpPHDmL0EWhJYELWD/tiaAluWuCavGnZCwRPGdr2zw2aI53oXq/V96CXY+wd2QaSxO74J4bvGJoUZfBYjP2dtlXi3gyypzyRv15iYqcWG/mXFFgs8TggfAmXHaVMzZKQpYuVm2H0KaGjAAzZ+An+Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jul 10, 2025 at 01:22:59PM -0400, Mike Snitzer wrote: > On Thu, Jul 10, 2025 at 10:29:22AM -0600, Keith Busch wrote: > > The trim calculation assumes the current bi_size is already a block size > > multiple, but it may not be with your propsal. So the trim bytes needs > > to take into account the existing bi_size to know how much to trim off > > to arrive at a proper total bi_size instead of assuming we can append a > > block sized multiple carved out the current iov. > > The trim "calculation" doesn't assume anything, it just lops off > whatever is past the end of the last logical_block_size aligned > boundary of the requested pages (which is meant to be bi_size). The > fact that the trim ever gets anything implies bi_size is *not* always > logical_block_size aligned. No? No. The iov must be a block size, but if it spans more pages than the bio can hold (because of bi_max_vecs), the total size of the pages gotten is only part of iov. That's the case that 'trim' is trying to handle, as we only got part of the iov, so it's aligned down to make sure the next iteration can consider perfectly block size aligned iovecs. At every step of iovec iteration, the bio's bi_size is a block size multiple. Let's say we tried to allow smaller vecs. Assume block size of 512 bytes, and you send a direct IO with 4 vecs of 128 bytes each. That would normally get rejected very early, but if you did send that to the bio layer, the entirety of the first iov would get trimmed off and you should get an EFAULT return.