From: Stephen Rothwell Date: Mon, 10 Dec 2018 00:47:37 +0000 (+1100) Subject: Merge remote-tracking branch 'jc_docs/docs-next' X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=ec79d131efbc41e280dc31a2cb9029e131768665;p=users%2Fwilly%2Flinux.git Merge remote-tracking branch 'jc_docs/docs-next' --- ec79d131efbc41e280dc31a2cb9029e131768665 diff --cc Documentation/admin-guide/security-bugs.rst index 30187d49dc2c,410602752dc4..dcd6c93c7aac --- a/Documentation/admin-guide/security-bugs.rst +++ b/Documentation/admin-guide/security-bugs.rst @@@ -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 diff --cc Documentation/filesystems/index.rst index 818390c32be6,ba921bdd5b06..03f38cb9a77c --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@@ -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 diff --cc Documentation/networking/rxrpc.txt index 89f1302d593a,aab3c393c10d..c9d052e0cf51 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@@ -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. diff --cc Documentation/x86/boot.txt index 5e9b826b5f62,7973249cce45..f4c2a97bfdbd --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@@ -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