From: kernel test robot <lkp@intel.com>
To: Xiubo Li <xiubli@redhat.com>
Cc: kbuild-all@lists.01.org,
Linux Memory Management List <linux-mm@kvack.org>,
Ilya Dryomov <idryomov@gmail.com>,
David Howells <dhowells@redhat.com>,
linux-doc@vger.kernel.org
Subject: [linux-next:master 9878/10347] htmldocs: Documentation/filesystems/netfs_library.rst:384: WARNING: Inline emphasis start-string without end-string.
Date: Thu, 14 Jul 2022 07:45:46 +0800 [thread overview]
Message-ID: <202207140742.GTPk4U8i-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 4662b7adea50bb62e993a67f611f3be625d3df0d
commit: 157be6ddd9e43835f36264b7bd41a918680ad841 [9878/10347] netfs: do not unlock and put the folio twice
reproduce: make htmldocs
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> Documentation/filesystems/netfs_library.rst:384: WARNING: Inline emphasis start-string without end-string.
>> Documentation/filesystems/netfs_library:609: fs/netfs/buffered_read.c:318: WARNING: Inline emphasis start-string without end-string.
vim +384 Documentation/filesystems/netfs_library.rst
309
310 * ``init_request()``
311
312 [Optional] This is called to initialise the request structure. It is given
313 the file for reference.
314
315 * ``free_request()``
316
317 [Optional] This is called as the request is being deallocated so that the
318 filesystem can clean up any state it has attached there.
319
320 * ``begin_cache_operation()``
321
322 [Optional] This is called to ask the network filesystem to call into the
323 cache (if present) to initialise the caching state for this read. The netfs
324 library module cannot access the cache directly, so the cache should call
325 something like fscache_begin_read_operation() to do this.
326
327 The cache gets to store its state in ->cache_resources and must set a table
328 of operations of its own there (though of a different type).
329
330 This should return 0 on success and an error code otherwise. If an error is
331 reported, the operation may proceed anyway, just without local caching (only
332 out of memory and interruption errors cause failure here).
333
334 * ``expand_readahead()``
335
336 [Optional] This is called to allow the filesystem to expand the size of a
337 readahead read request. The filesystem gets to expand the request in both
338 directions, though it's not permitted to reduce it as the numbers may
339 represent an allocation already made. If local caching is enabled, it gets
340 to expand the request first.
341
342 Expansion is communicated by changing ->start and ->len in the request
343 structure. Note that if any change is made, ->len must be increased by at
344 least as much as ->start is reduced.
345
346 * ``clamp_length()``
347
348 [Optional] This is called to allow the filesystem to reduce the size of a
349 subrequest. The filesystem can use this, for example, to chop up a request
350 that has to be split across multiple servers or to put multiple reads in
351 flight.
352
353 This should return 0 on success and an error code on error.
354
355 * ``issue_read()``
356
357 [Required] The helpers use this to dispatch a subrequest to the server for
358 reading. In the subrequest, ->start, ->len and ->transferred indicate what
359 data should be read from the server.
360
361 There is no return value; the netfs_subreq_terminated() function should be
362 called to indicate whether or not the operation succeeded and how much data
363 it transferred. The filesystem also should not deal with setting folios
364 uptodate, unlocking them or dropping their refs - the helpers need to deal
365 with this as they have to coordinate with copying to the local cache.
366
367 Note that the helpers have the folios locked, but not pinned. It is
368 possible to use the ITER_XARRAY iov iterator to refer to the range of the
369 inode that is being operated upon without the need to allocate large bvec
370 tables.
371
372 * ``is_still_valid()``
373
374 [Optional] This is called to find out if the data just read from the local
375 cache is still valid. It should return true if it is still valid and false
376 if not. If it's not still valid, it will be reread from the server.
377
378 * ``check_write_begin()``
379
380 [Optional] This is called from the netfs_write_begin() helper once it has
381 allocated/grabbed the folio to be modified to allow the filesystem to flush
382 conflicting state before allowing it to be modified.
383
> 384 It may unlock and discard the folio it was given and set the caller's folio
385 pointer to NULL. It should return 0 if everything is now fine (*foliop
386 left set) or the op should be retried (*foliop cleared) and any other error
387 code to abort the operation.
388
389 * ``done``
390
391 [Optional] This is called after the folios in the request have all been
392 unlocked (and marked uptodate if applicable).
393
394
395
--
0-DAY CI Kernel Test Service
https://01.org/lkp
reply other threads:[~2022-07-13 23:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202207140742.GTPk4U8i-lkp@intel.com \
--to=lkp@intel.com \
--cc=dhowells@redhat.com \
--cc=idryomov@gmail.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xiubli@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).