linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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).