]> www.infradead.org Git - users/willy/linux.git/commitdiff
Merge remote-tracking branch 'jc_docs/docs-next'
authorStephen Rothwell <sfr@canb.auug.org.au>
Mon, 10 Dec 2018 00:47:37 +0000 (11:47 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Mon, 10 Dec 2018 00:47:37 +0000 (11:47 +1100)
1  2 
Documentation/admin-guide/kernel-parameters.txt
Documentation/admin-guide/security-bugs.rst
Documentation/filesystems/index.rst
Documentation/media/uapi/v4l/extended-controls.rst
Documentation/networking/rxrpc.txt
Documentation/x86/boot.txt

index 30187d49dc2c7d38869c4073e60093d315c3fc4e,410602752dc40530c9628cc6ee51f71420ccdf2d..dcd6c93c7aacb04f14120bf0c972d2be26fb1c25
@@@ -32,19 -32,18 +32,19 @@@ Disclosure and embargoed informatio
  The security list is not a disclosure channel.  For that, see Coordination
  below.
  
 -Once a robust fix has been developed, our preference is to release the
 -fix in a timely fashion, treating it no differently than any of the other
 -thousands of changes and fixes the Linux kernel project releases every
 -month.
 -
 -However, at the request of the reporter, we will postpone releasing the
 -fix for up to 5 business days after the date of the report or after the
 -embargo has lifted; whichever comes first.  The only exception to that
 -rule is if the bug is publicly known, in which case the preference is to
 -release the fix as soon as it's available.
 +Once a robust fix has been developed, the release process starts.  Fixes
 +for publicly known bugs are released immediately.
 +
 +Although our preference is to release fixes for publicly undisclosed bugs
 +as soon as they become available, this may be postponed at the request of
 +the reporter or an affected party for up to 7 calendar days from the start
 +of the release process, with an exceptional extension to 14 calendar days
 +if it is agreed that the criticality of the bug requires more time.  The
 +only valid reason for deferring the publication of a fix is to accommodate
 +the logistics of QA and large scale rollouts which require release
 +coordination.
  
- Whilst embargoed information may be shared with trusted individuals in
+ While embargoed information may be shared with trusted individuals in
  order to develop a fix, such information will not be published alongside
  the fix or on any other disclosure channel without the permission of the
  reporter.  This includes but is not limited to the original bug report
index 818390c32be6397d99a4db3e47de97b972a0a597,ba921bdd5b063bef1448c79c9fc18aa3ed02f952..03f38cb9a77cd9f7c36d35fc2defa447b2c5bdfa
@@@ -360,13 -360,13 +360,24 @@@ encryption of files and directories
  
      fscrypt
  
 +Verity API
 +==========
 +
 +A library which filesystems can hook into to support transparent
 +authentication of read-only files.
 +
 +.. toctree::
 +    :maxdepth: 2
 +
 +    fsverity
++
+ Pathname lookup
+ ===============
+ Pathname lookup in Linux is a complex beast; the document linked below
+ provides a comprehensive summary for those looking for the details.
+ .. toctree::
+    :maxdepth: 2
+    path-lookup.rst
index 89f1302d593a5c0404ed8a434ba580e8440a9139,aab3c393c10df152bc7c417cafa4b94c9294c0ec..c9d052e0cf5136774c1f9a77de8f5bae7d7ad423
@@@ -1056,23 -1056,18 +1056,23 @@@ The kernel interface functions are as f
  
        u32 rxrpc_kernel_check_life(struct socket *sock,
                                    struct rxrpc_call *call);
 +      void rxrpc_kernel_probe_life(struct socket *sock,
 +                                   struct rxrpc_call *call);
  
 -     This returns a number that is updated when ACKs are received from the peer
 -     (notably including PING RESPONSE ACKs which we can elicit by sending PING
 -     ACKs to see if the call still exists on the server).  The caller should
 -     compare the numbers of two calls to see if the call is still alive after
 -     waiting for a suitable interval.
 +     The first function returns a number that is updated when ACKs are received
 +     from the peer (notably including PING RESPONSE ACKs which we can elicit by
 +     sending PING ACKs to see if the call still exists on the server).  The
 +     caller should compare the numbers of two calls to see if the call is still
 +     alive after waiting for a suitable interval.
  
       This allows the caller to work out if the server is still contactable and
-      if the call is still alive on the server whilst waiting for the server to
+      if the call is still alive on the server while waiting for the server to
       process a client operation.
  
 -     This function may transmit a PING ACK.
 +     The second function causes a ping ACK to be transmitted to try to provoke
 +     the peer into responding, which would then cause the value returned by the
 +     first function to change.  Note that this must be called in TASK_RUNNING
 +     state.
  
   (*) Get reply timestamp.
  
index 5e9b826b5f62fd1cf8dfcae07fc5bde66594428b,7973249cce455baa09942a815af538c409e8fa42..f4c2a97bfdbd0d1ed058013b7dbce161d5fb6d9a
@@@ -58,9 -58,21 +58,9 @@@ Protocol 2.11:       (Kernel 3.6) Added a fie
                protocol entry point.
  
  Protocol 2.12:        (Kernel 3.8) Added the xloadflags field and extension fields
-               to struct boot_params for loading bzImage and ramdisk
+               to struct boot_params for loading bzImage and ramdisk
                above 4G in 64bit.
  
 -Protocol 2.13:        (Kernel 3.14) Support 32- and 64-bit flags being set in
 -              xloadflags to support booting a 64-bit kernel from 32-bit
 -              EFI
 -
 -Protocol 2.14:        (Kernel 4.20) Added acpi_rsdp_addr holding the physical
 -              address of the ACPI RSDP table.
 -              The bootloader updates version with:
 -              0x8000 | min(kernel-version, bootloader-version)
 -              kernel-version being the protocol version supported by
 -              the kernel and bootloader-version the protocol version
 -              supported by the bootloader.
 -
  **** MEMORY LAYOUT
  
  The traditional memory map for the kernel loader, used for Image or