Cover Letter Detail
Show a cover letter.
GET /api/covers/2216341/?format=api
{ "id": 2216341, "url": "http://patchwork.ozlabs.org/api/covers/2216341/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-cifs-client/cover/20260326104544.509518-1-dhowells@redhat.com/", "project": { "id": 12, "url": "http://patchwork.ozlabs.org/api/projects/12/?format=api", "name": "Linux CIFS Client", "link_name": "linux-cifs-client", "list_id": "linux-cifs.vger.kernel.org", "list_email": "linux-cifs@vger.kernel.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260326104544.509518-1-dhowells@redhat.com>", "list_archive_url": null, "date": "2026-03-26T10:45:15", "name": "[00/26] netfs: Keep track of folios in a segmented bio_vec[] chain", "submitter": { "id": 59, "url": "http://patchwork.ozlabs.org/api/people/59/?format=api", "name": "David Howells", "email": "dhowells@redhat.com" }, "mbox": "http://patchwork.ozlabs.org/project/linux-cifs-client/cover/20260326104544.509518-1-dhowells@redhat.com/mbox/", "series": [ { "id": 497565, "url": "http://patchwork.ozlabs.org/api/series/497565/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-cifs-client/list/?series=497565", "date": "2026-03-26T10:45:15", "name": "netfs: Keep track of folios in a segmented bio_vec[] chain", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/497565/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/2216341/comments/", "headers": { "Return-Path": "\n <linux-cifs+bounces-10523-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-cifs@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=AJd6hKCI;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10523-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com\n header.b=\"AJd6hKCI\"", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=170.10.133.124", "smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=redhat.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=redhat.com" ], "Received": [ "from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fhLHW2wmRz1y1x\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 26 Mar 2026 21:53:59 +1100 (AEDT)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 8DBA430BF963\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 26 Mar 2026 10:46:36 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E8B12347510;\n\tThu, 26 Mar 2026 10:46:13 +0000 (UTC)", "from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id AFCCA3845B4\n\tfor <linux-cifs@vger.kernel.org>; Thu, 26 Mar 2026 10:46:11 +0000 (UTC)", "from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-70-TtKMj9N8PJSjl2tFmZuZHQ-1; Thu,\n 26 Mar 2026 06:46:07 -0400", "from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 19D0119560AE;\n\tThu, 26 Mar 2026 10:46:03 +0000 (UTC)", "from warthog.procyon.org.com (unknown [10.44.33.121])\n\tby mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 00A7E19560B1;\n\tThu, 26 Mar 2026 10:45:53 +0000 (UTC)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1774521973; cv=none;\n b=rCsPID9GXJOpqoHop8PUTI1AZ/OiEG20vmcCGqhfC+12VyFNS2S4nugFR5O9oq1QOmbpi4TlOk2sA1/Glu3/hEN9lgDx9q7FvUl+fAlWKvciLasKj8wk6ze4sJRJCGhS4jCxb95pzlzaX/2fozDyN+ab6m0du2CsMzbMZkxTmyc=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1774521973; c=relaxed/simple;\n\tbh=4HKk9ZJneo7yqa9sC78F9NzNtzyserlOTVs/NLobrIY=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=k+50jGtCXl9LRFZiUzz46lnV+cuidn1YtuY3qtLMeF2dC1MDsHkJ3eTl9AIcZe0d5fiKmuZJIPRZsMHBT4MhoYe2aW8B77nEyJJmS56io1zmWRWSRAM1T5KXF5jdknSPVr4YZDqypoWmJgu1v3BzC9W39Wp+8ZXi6PU8LzzSYcY=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=redhat.com;\n spf=pass smtp.mailfrom=redhat.com;\n dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com\n header.b=AJd6hKCI; arc=none smtp.client-ip=170.10.133.124", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n\ts=mimecast20190719; t=1774521970;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:\n\t content-transfer-encoding:content-transfer-encoding;\n\tbh=I/AwaHoW8Vm6LNELS+H4YAEvj2gOr1h8Aehnm4TULKw=;\n\tb=AJd6hKCIGjvv9QPjbRI/PPYSoLHkrXNpkx7SYC85bbrvopSdHFvoTJTD0tPHAUCvMsh5uR\n\t0qd3+h6rf3VkDPdsr9HXRH5eEqtmEm/ctjFcGMCQ2jB30hO1V7JwDKiVE72ahAG4a0GckP\n\tlAu7Tmj6QFx++jwzxK98ENU5msmuFNs=", "X-MC-Unique": "TtKMj9N8PJSjl2tFmZuZHQ-1", "X-Mimecast-MFC-AGG-ID": "TtKMj9N8PJSjl2tFmZuZHQ_1774521964", "From": "David Howells <dhowells@redhat.com>", "To": "Christian Brauner <christian@brauner.io>,\n\tMatthew Wilcox <willy@infradead.org>,\n\tChristoph Hellwig <hch@infradead.org>", "Cc": "David Howells <dhowells@redhat.com>,\n\tPaulo Alcantara <pc@manguebit.com>,\n\tJens Axboe <axboe@kernel.dk>,\n\tLeon Romanovsky <leon@kernel.org>,\n\tSteve French <sfrench@samba.org>,\n\tChenXiaoSong <chenxiaosong@chenxiaosong.com>,\n\tMarc Dionne <marc.dionne@auristor.com>,\n\tEric Van Hensbergen <ericvh@kernel.org>,\n\tDominique Martinet <asmadeus@codewreck.org>,\n\tIlya Dryomov <idryomov@gmail.com>,\n\tTrond Myklebust <trondmy@kernel.org>,\n\tnetfs@lists.linux.dev,\n\tlinux-afs@lists.infradead.org,\n\tlinux-cifs@vger.kernel.org,\n\tlinux-nfs@vger.kernel.org,\n\tceph-devel@vger.kernel.org,\n\tv9fs@lists.linux.dev,\n\tlinux-erofs@lists.ozlabs.org,\n\tlinux-fsdevel@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org", "Subject": "[PATCH 00/26] netfs: Keep track of folios in a segmented bio_vec[]\n chain", "Date": "Thu, 26 Mar 2026 10:45:15 +0000", "Message-ID": "<20260326104544.509518-1-dhowells@redhat.com>", "Precedence": "bulk", "X-Mailing-List": "linux-cifs@vger.kernel.org", "List-Id": "<linux-cifs.vger.kernel.org>", "List-Subscribe": "<mailto:linux-cifs+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-cifs+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-Scanned-By": "MIMEDefang 3.0 on 10.30.177.12" }, "content": "Hi Christian,\n\nCould you add these patches to the VFS tree for next?\n\nThe patches get rid of folio_queue, rolling_buffer and ITER_FOLIOQ,\nreplacing the folio queue construct used to manage buffers in netfslib with\none based around a segmented chain of bio_vec arrays instead. There are\nthree main aims here:\n\n (1) The kernel file I/O subsystem seems to be moving towards consolidating\n on the use of bio_vec arrays, so embrace this by moving netfslib to\n keep track of its buffers for buffered I/O in bio_vec[] form.\n\n (2) Netfslib already uses a bio_vec[] to handle unbuffered/DIO, so the\n number of different buffering schemes used can be reduced to just a\n single one.\n\n (3) Always send an entire filesystem RPC request message to a TCP socket\n with single kernel_sendmsg() call as this is faster, more efficient\n and doesn't require the use of corking as it puts the entire\n transmission loop inside of a single tcp_sendmsg().\n\nFor the replacement of folio_queue, a segmented chain of bio_vec arrays\nrather than a single monolithic array is provided:\n\n\tstruct bvecq {\n\t\tstruct bvecq\t\t*next;\n\t\tstruct bvecq\t\t*prev;\n\t\tunsigned long long\tfpos;\n\t\trefcount_t\t\tref;\n\t\tu32\t\t\tpriv;\n\t\tu16\t\t\tnr_segs;\n\t\tu16\t\t\tmax_segs;\n\t\tbool\t\t\tinline_bv:1;\n\t\tbool\t\t\tfree:1;\n\t\tbool\t\t\tunpin:1;\n\t\tbool\t\t\tdiscontig:1;\n\t\tstruct bio_vec\t\t*bv;\n\t\tstruct bio_vec\t\t__bv[];\n\t};\n\nThe fields are:\n\n (1) next, prev - Link segments together in a list. I want this to be\n NULL-terminated linear rather than circular to make it possible to\n arbitrarily glue bits on the front.\n\n (2) fpos, discontig - Note the current file position of the first byte of\n the segment; all the bio_vecs in ->bv[] must be contiguous in the file\n space. The fpos can be used to find the folio by file position rather\n then from the info in the bio_vec.\n\n If there's a discontiguity, this should break over into a new bvecq\n segment with the discontig flag set (though this is redundant if you\n keep track of the file position). Note that the beginning and end\n file positions in a segment need not be aligned to any filesystem\n block size.\n\n (3) ref - Refcount. Each bvecq keeps a ref on the next. I'm not sure\n this is entirely necessary, but it makes sharing slices easier.\n\n (4) priv - Private data for the owner. Dispensible; currently only used\n for storing a debug ID for tracing in a patch not included here.\n\n (5) max_segs, nr_segs. The size of bv[] and the number of elements used.\n I've assumed a maximum of 65535 bio_vecs in the array (which would\n represent a ~1MiB allocation).\n\n (6) bv, __bv, inline_bv. bv points to the bio_vec[] array handled by\n this segment. This may begin at __bv and if it does inline_bv should\n be set (otherwise it's impossible to distinguish a separately\n allocated bio_vec[] that follows immediately by coincidence).\n\n (7) free, unpin. free is set if the memory pointed to by the bio_vecs\n needs freeing in some way upon I/O completion. unpin is set if this\n means using GUP unpinning rather than put_page().\n\nI've also defined an iov_iter iterator type ITER_BVECQ to walk this sort of\nconstruct so that it can be passed directly to sendmsg() or block-based DIO\n(as cachefiles does).\n\n\nThis series makes the following changes to netfslib:\n\n (1) The folio_queue chain used to hold folios for buffered I/O is replaced\n with a bvecq chain. Each bio_vec then holds (a portion of) one folio.\n Each bvecq holds a contiguous sequence of folios, but adjacent bvecqs\n in a chain may be discontiguous.\n\n (2) For unbuffered/DIO, the source iov_iter is extracted into a bvecq\n chain.\n\n (3) An abstract position representation ('bvecq_pos') is created that can\n used to hold a position in a bvecq chain. For the moment, this takes\n a ref on the bvecq it points to, but that may be excessive.\n\n (4) Buffer tracking is managed with three cursors: The load_cursor, at\n which new folios are added as we go; the dispatch_cursor, at which new\n subrequests' buffers start when they're created; and the\n collect_cursor, the point at which folios are being unlocked.\n\n Not all cursors are necessarily needed in all situations and during\n buffered writeback, we need a dispatch cursor per stream (one for the\n network filesystem and one for the cache).\n\n (5) ->prepare_read(), buffer setting up and ->issue_read() are merged, as\n are the write variants, with the filesystem calling back up to\n netfslib to prepare its buffer. This simplifies the process of\n setting up a subrequest. It may even make sense to have the\n filesystem allocate the subrequest.\n\n (6) Retry dispatch tracking is added to netfs_io_request so that the\n buffer preparation functions can find it. Retry requires an\n additional buffer cursor.\n\n (7) Netfslib dispatches I/O by accumulating enough bufferage to dispatch\n at least one subrequest, then looping to generate as many as the\n filesystem wants to (they may be limited by other constraints,\n e.g. max RDMA segment count or negotiated max size). This loop could\n be moved down into the filesystem. A new method is provided by which\n netfslib can ask the filesystem to provide an estimate of the data\n that should be accumulated before dispatch begins.\n\n (8) Reading from the cache is now managed by querying the cache to provide\n a list of the next two data extents within the cache.\n\n (9) AFS directories are switched to using a bvecq rather than a\n folio_queue to hold their contents.\n\n(10) CIFS is switch to using a bvecq rather than a folio_queue for holding\n a temporary encryption buffer.\n\n(11) CIFS RDMA is given the ability to extract ITER_BVECQ and support for\n extracting ITER_FOLIOQ, ITER_BVEC and ITER_KVEC is removed.\n\n(12) All the folio_queue and rolling_buffer code is removed.\n\nCachefiles is also modified:\n\n (1) The object type in the cachefiles file xattr is now correctly set to\n CACHEFILES_CONTENT_{SINGLE,ALL,BACKFS_MAP} rather than just being 0,\n to indicate whether we have a single monolithic blob, all the data up\n to cache i_size with no holes or a sparse file with the data mapped by\n the backing file system (as currently upstream).\n\n (2) For \"ALL\" type files, the cache's i_size is used to track how much\n data is saved in the cache and no longer bears any relation to the\n netfs i_size. The actual object size is stored in the xattr.\n\n (3) For most typical files which are contiguous and written progressively,\n the object type is now set to \"ALL\". For anything else, cachefiles\n uses SEEK_DATA/HOLE to find extent outlines at before (this is the\n current behaviour and needs to be fixed, but in a separate set of\n patches as it's not trivial).\n\nTwo further things that I'm working on (but not in this branch) are:\n\n (1) Make it so that a filesystem can be given a copy of a subchain which\n it can then tack header and trailer protocol elements upon to form a\n single message (I have this working for cifs) and even join copies\n together with intervening protocol elements to form compounds.\n\n (2) Make it so that a filesystem can 'splice' out the contents of the TCP\n receive queue into a bvecq chain. This allows the socket lock to be\n dropped much more quickly and the copying of data read to the\n destination buffers to happen without the lock. I have this working\n for cifs too. Kernel recvmsg() doesn't then block kernel sendmsg()\n for anywhere near as long.\n\nThere are also some things I want to consider for the future:\n\n (1) Create one or more batched iteration functions to 'unlock' all the\n folios in a bio_vec[], where 'unlock' is the appropriate action for\n ending a read or a write. Batching should hopefully also improve the\n efficiency of wrangling the marks on the xarray. Very often these\n marks are going to be represented by contiguous bits, so there may be\n a way to change them in bulk.\n\n (2) Rather than walking the bvecq chain to get each individual folio out\n via bv_page, use the file position stored on the bvecq and the sum of\n bv_len to iterate over the appropriate range in i_pages.\n\n (3) Change iov_iter to store the initial starting point and for\n iov_iter_revert() to reset to that and advance. This would (a) help\n prevent over-reversion and (b) dispense with the need for a prev\n pointer.\n\n (4) Use bvecq to replace scatterlist. One problem with replacing\n scatterlist is that crypto drivers like to glue bits on the front of\n the scatterlists they're given (something trivial with that API) - and\n this is one way to achieve it.\n\nThe patches can also be found here:\n\n\thttps://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=netfs-next\n\nThanks,\nDavid\n\nDavid Howells (22):\n netfs: Fix read abandonment during retry\n netfs: Fix the handling of stream->front by removing it\n cachefiles: Fix excess dput() after end_removing()\n cachefiles: Don't rely on backing fs storage map for most use cases\n mm: Make readahead store folio count in readahead_control\n netfs: Bulk load the readahead-provided folios up front\n Add a function to kmap one page of a multipage bio_vec\n iov_iter: Add a segmented queue of bio_vec[]\n netfs: Add some tools for managing bvecq chains\n netfs: Add a function to extract from an iter into a bvecq\n afs: Use a bvecq to hold dir content rather than folioq\n cifs: Use a bvecq for buffering instead of a folioq\n cifs: Support ITER_BVECQ in smb_extract_iter_to_rdma()\n netfs: Switch to using bvecq rather than folio_queue and\n rolling_buffer\n cifs: Remove support for ITER_KVEC/BVEC/FOLIOQ from\n smb_extract_iter_to_rdma()\n netfs: Remove netfs_alloc/free_folioq_buffer()\n netfs: Remove netfs_extract_user_iter()\n iov_iter: Remove ITER_FOLIOQ\n netfs: Remove folio_queue and rolling_buffer\n netfs: Check for too much data being read\n netfs: Limit the the minimum trigger for progress reporting\n netfs: Combine prepare and issue ops and grab the buffers on request\n\nDeepanshu Kartikey (2):\n netfs: Fix NULL pointer dereference in netfs_unbuffered_write() on\n retry\n netfs: Fix kernel BUG in netfs_limit_iter() for ITER_KVEC iterators\n\nPaulo Alcantara (1):\n netfs: fix error handling in netfs_extract_user_iter()\n\nViacheslav Dubeyko (1):\n netfs: fix VM_BUG_ON_FOLIO() issue in netfs_write_begin() call\n\n Documentation/core-api/folio_queue.rst | 209 ------\n Documentation/core-api/index.rst | 1 -\n fs/9p/vfs_addr.c | 49 +-\n fs/afs/dir.c | 43 +-\n fs/afs/dir_edit.c | 43 +-\n fs/afs/dir_search.c | 33 +-\n fs/afs/file.c | 27 +-\n fs/afs/fsclient.c | 8 +-\n fs/afs/inode.c | 20 +-\n fs/afs/internal.h | 14 +-\n fs/afs/write.c | 35 +-\n fs/afs/yfsclient.c | 6 +-\n fs/cachefiles/interface.c | 82 +-\n fs/cachefiles/internal.h | 10 +-\n fs/cachefiles/io.c | 486 ++++++++----\n fs/cachefiles/namei.c | 55 +-\n fs/cachefiles/xattr.c | 20 +-\n fs/ceph/Kconfig | 1 +\n fs/ceph/addr.c | 127 ++--\n fs/netfs/Kconfig | 3 +\n fs/netfs/Makefile | 4 +-\n fs/netfs/buffered_read.c | 524 ++++++++-----\n fs/netfs/buffered_write.c | 30 +-\n fs/netfs/bvecq.c | 706 ++++++++++++++++++\n fs/netfs/direct_read.c | 119 ++-\n fs/netfs/direct_write.c | 174 +++--\n fs/netfs/fscache_io.c | 6 -\n fs/netfs/internal.h | 89 ++-\n fs/netfs/iterator.c | 305 +++-----\n fs/netfs/misc.c | 147 +---\n fs/netfs/objects.c | 21 +-\n fs/netfs/read_collect.c | 134 ++--\n fs/netfs/read_pgpriv2.c | 168 +++--\n fs/netfs/read_retry.c | 227 +++---\n fs/netfs/read_single.c | 170 +++--\n fs/netfs/rolling_buffer.c | 222 ------\n fs/netfs/stats.c | 6 +-\n fs/netfs/write_collect.c | 126 +++-\n fs/netfs/write_issue.c | 987 ++++++++++++++-----------\n fs/netfs/write_retry.c | 135 ++--\n fs/nfs/Kconfig | 1 +\n fs/nfs/fscache.c | 24 +-\n fs/smb/client/cifsglob.h | 2 +-\n fs/smb/client/cifssmb.c | 13 +-\n fs/smb/client/file.c | 146 ++--\n fs/smb/client/smb2ops.c | 78 +-\n fs/smb/client/smb2pdu.c | 28 +-\n fs/smb/client/smbdirect.c | 152 +---\n fs/smb/client/transport.c | 15 +-\n include/linux/bvec.h | 21 +\n include/linux/bvecq.h | 205 +++++\n include/linux/folio_queue.h | 282 -------\n include/linux/fscache.h | 17 +\n include/linux/iov_iter.h | 68 +-\n include/linux/netfs.h | 145 ++--\n include/linux/pagemap.h | 1 +\n include/linux/rolling_buffer.h | 61 --\n include/linux/uio.h | 17 +-\n include/trace/events/cachefiles.h | 17 +-\n include/trace/events/netfs.h | 123 ++-\n lib/iov_iter.c | 395 +++++-----\n lib/scatterlist.c | 57 +-\n lib/tests/kunit_iov_iter.c | 185 ++---\n mm/readahead.c | 4 +\n net/9p/client.c | 8 +-\n 65 files changed, 4144 insertions(+), 3493 deletions(-)\n delete mode 100644 Documentation/core-api/folio_queue.rst\n create mode 100644 fs/netfs/bvecq.c\n delete mode 100644 fs/netfs/rolling_buffer.c\n create mode 100644 include/linux/bvecq.h\n delete mode 100644 include/linux/folio_queue.h\n delete mode 100644 include/linux/rolling_buffer.h" }