[PATCH] Documentation: change linux-4.x references to 5.x

[Arnd Bergmann]

As linux-5.0.x is coming up soon, the documentation should match,
in particular the README.rst file, so change all 4.x references
accordingly. There was a mix of lowercase and uppercase X here,
which I changed to using lowercase consistently.

Signed-off-by: Arnd Bergmann 
---
 Documentation/admin-guide/README.rst  |  32 ++---
 Documentation/process/applying-patches.rst| 117 +-
 .../translations/it_IT/admin-guide/README.rst |   2 +-
 3 files changed, 78 insertions(+), 73 deletions(-)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 0797eec76be1..47e577264198 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -1,9 +1,9 @@
 .. _readme:
 
-Linux kernel release 4.x 
+Linux kernel release 5.x 
 =
 
-These are the release notes for Linux version 4.  Read them carefully,
+These are the release notes for Linux version 5.  Read them carefully,
 as they tell you what this is all about, explain how to install the
 kernel, and what to do if something goes wrong.
 
@@ -63,7 +63,7 @@ Installing the kernel source
directory where you have permissions (e.g. your home directory) and
unpack it::
 
- xz -cd linux-4.X.tar.xz | tar xvf -
+ xz -cd linux-5.x.tar.xz | tar xvf -
 
Replace "X" with the version number of the latest kernel.
 
@@ -72,26 +72,26 @@ Installing the kernel source
files.  They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
 
- - You can also upgrade between 4.x releases by patching.  Patches are
+ - You can also upgrade between 5.x releases by patching.  Patches are
distributed in the xz format.  To install by patching, get all the
newer patch files, enter the top level directory of the kernel source
-   (linux-4.X) and execute::
+   (linux-5.x) and execute::
 
- xz -cd ../patch-4.x.xz | patch -p1
+ xz -cd ../patch-5.x.xz | patch -p1
 
-   Replace "x" for all versions bigger than the version "X" of your current
+   Replace "x" for all versions bigger than the version "x" of your current
source tree, **in_order**, and you should be ok.  You may want to remove
the backup files (some-file-name~ or some-file-name.orig), and make sure
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
 
-   Unlike patches for the 4.x kernels, patches for the 4.x.y kernels
+   Unlike patches for the 5.x kernels, patches for the 5.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
-   directly to the base 4.x kernel.  For example, if your base kernel is 4.0
-   and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1
-   and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and
-   want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is,
-   patch -R) **before** applying the 4.0.3 patch. You can read more on this in
+   directly to the base 5.x kernel.  For example, if your base kernel is 5.0
+   and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1
+   and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and
+   want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is,
+   patch -R) **before** applying the 5.0.3 patch. You can read more on this in
:ref:`Documentation/process/applying-patches.rst `.
 
Alternatively, the script patch-kernel can be used to automate this
@@ -114,7 +114,7 @@ Installing the kernel source
 Software requirements
 -
 
-   Compiling and running the 4.x kernels requires up-to-date
+   Compiling and running the 5.x kernels requires up-to-date
versions of various software packages.  Consult
:ref:`Documentation/process/changes.rst ` for the minimum version 
numbers
required and how to get updates for these packages.  Beware that using
@@ -132,12 +132,12 @@ Build directory for the kernel
place for the output files (including .config).
Example::
 
- kernel source code: /usr/src/linux-4.X
+ kernel source code: /usr/src/linux-5.x
  build directory:/home/name/build/kernel
 
To configure and build the kernel, use::
 
- cd /usr/src/linux-4.X
+ cd /usr/src/linux-5.x
  make O=/home/name/build/kernel menuconfig
  make O=/home/name/build/kernel
  sudo make O=/home/name/build/kernel modules_install install
diff --git a/Documentation/process/applying-patches.rst 
b/Documentation/process/applying-patches.rst
index dc2ddc345044..fbb9297e6360 100644
--- a/Documentation/process/applying-patches.rst
+++ b/Documentation/process/applying-patches.rst
@@ -216,14 +216,14 @@ You can use the ``interdiff`` program 
(http://cyberelk.net/tim/patchutils/) to
 generate a patch representing the differences between two patches and then
 apply

Re: [RFC][PATCH 0/3] arm64 relaxed ABI

[Catalin Marinas]

On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote:
> On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky  wrote:
> > On 19/12/2018 12:52, Dave Martin wrote:
> > > Really, the kernel should do the expected thing with all "non-weird"
> > > memory.
> > >
> > > In lieu of a proper definition of "non-weird", I think we should have
> > > some lists of things that are explicitly included, and also excluded:
> > >
> > > OK:
> > >   kernel-allocated process stack
> > >   brk area
> > >   MAP_ANONYMOUS | MAP_PRIVATE
> > >   MAP_PRIVATE mappings of /dev/zero
> > >
> > > Not OK:
> > >   MAP_SHARED
> > >   mmaps of non-memory-like devices
> > >   mmaps of anything that is not a regular file
> > >   the VDSO
> > >   ...
> > >
> > > In general, userspace can tag memory that it "owns", and we do not assume
> > > a transfer of ownership except in the "OK" list above.  Otherwise, it's
> > > the kernel's memory, or the owner is simply not well defined.
> >
> > Agreed on the general idea: a process should be able to pass tagged 
> > pointers at the
> > syscall interface, as long as they point to memory privately owned by the 
> > process. I
> > think it would be possible to simplify the definition of "non-weird" memory 
> > by using
> > only this "OK" list:
> > - mmap() done by the process itself, where either:
> >* flags = MAP_PRIVATE | MAP_ANONYMOUS
> >* flags = MAP_PRIVATE and fd refers to a regular file or a well-defined 
> > list of
> > device files (like /dev/zero)
> > - brk() done by the process itself
> > - Any memory mapped by the kernel in the new process's address space during 
> > execve(),
> > with the same restrictions as above ([vdso]/[vvar] are therefore excluded)

Sounds reasonable.

> > >   * Userspace should set tags at the point of allocation only.
> >
> > Yes, tags are only supposed to be set at the point of either allocation or
> > deallocation/reallocation. However, allocators can in principle be nested, 
> > so an
> > allocator could  take a region allocated by malloc() as input and subdivide 
> > it
> > (changing tags in the process). That said, this suballocator must not 
> > free() that
> > region until all the suballocations themselves have been freed (thereby 
> > restoring the
> > tags initially set by malloc()).
> >
> > >   * If you don't know how an object was allocated, you cannot modify the
> > > tag, period.
> >
> > Agreed, allocators that tag memory can only operate on memory with a 
> > well-defined
> > provenance (for instance anonymous mmap() or malloc()).
> >
> > >   * A single C object should be accessed using a single, fixed pointer tag
> > > throughout its entire lifetime.
> >
> > Agreed. Allocators themselves may need to be excluded though, depending on 
> > how they
> > represent their managed memory.
> >
> > >   * Tags can be changed only when there are no outstanding pointers to
> > > the affected object or region that may be used to access the object
> > > or region (i.e., if the object were allocated from the C heap and
> > > is it safe to realloc() it, then it is safe to change the tag; for
> > > other types of allocation, analogous arguments can be applied).
> >
> > Tags can only be changed at the point of deallocation/reallocation. 
> > Pointers to the
> > object become invalid and cannot be used after it has been deallocated; 
> > memory
> > tagging allows to catch such invalid usage.

All the above sound well but that's mostly a guideline on what a C
library can do. It doesn't help much with defining the kernel ABI.
Anyway, it's good to clarify the use-cases.

> > >   * When the kernel dereferences a pointer on userspace's behalf, it
> > > shall behave equivalently to userspace dereferencing the same pointer,
> > > including use of the same tag (where passed by userspace).
> > >
> > >   * Where the pointer tag affects pointer dereference behaviour (i.e.,
> > > with hardware memory colouring) the kernel makes no guarantee to
> > > honour pointer tags correctly for every location a buffer based on a
> > > pointer passed by userspace to the kernel.
> > >
> > > (This means for example that for a read(fd, buf, size), we can check
> > > the tag for a single arbitrary location in *(char (*)[size])buf
> > > before passing the buffer to get_user_pages().  Hopefully this could
> > > be done in get_user_pages() itself rather than hunting call sites.
> > > For userspace, it means that you're on your own if you ask the
> > > kernel to operate on a buffer than spans multiple, independently-
> > > allocated objects, or a deliberately striped single object.)
> >
> > I think both points are reasonable. It is very valuable for the kernel to 
> > access
> > userspace memory using the user-provided tag, because it enables kernel 
> > accesses to
> > be checked in the same way as user accesses, allowing to detect bugs that 
> > are
> > potentially hard to find. For insta

[PATCH v7 7/7] cgroup: document cgroup v2 freezer interface

[Roman Gushchin]

Describe cgroup v2 freezer interface in the cgroup v2 admin guide.

Signed-off-by: Roman Gushchin 
Reviewed-by: Mike Rapoport 
Cc: Tejun Heo 
Cc: linux-doc@vger.kernel.org
Cc: kernel-t...@fb.com
---
 Documentation/admin-guide/cgroup-v2.rst | 27 +
 1 file changed, 27 insertions(+)

diff --git a/Documentation/admin-guide/cgroup-v2.rst 
b/Documentation/admin-guide/cgroup-v2.rst
index 61f8bbb0a1b2..78f078ddbe9c 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -864,6 +864,8 @@ All cgroup core files are prefixed with "cgroup."
  populated
1 if the cgroup or its descendants contains any live
processes; otherwise, 0.
+ frozen
+   1 if the cgroup is frozen; otherwise, 0.
 
   cgroup.max.descendants
A read-write single value files.  The default is "max".
@@ -897,6 +899,31 @@ All cgroup core files are prefixed with "cgroup."
A dying cgroup can consume system resources not exceeding
limits, which were active at the moment of cgroup deletion.
 
+  cgroup.freeze
+   A read-write single value file which exists on non-root cgroups.
+   Allowed values are "0" and "1". The default is "0".
+
+   Writing "1" to the file causes freezing of the cgroup and all
+   descendant cgroups. This means that all belonging processes will
+   be stopped and will not run until the cgroup will be explicitly
+   unfrozen. Freezing of the cgroup may take some time; when this action
+   is completed, the "frozen" value in the cgroup.events control file
+   will be updated to "1" and the corresponding notification will be
+   issued.
+
+   A cgroup can be frozen either by its own settings, or by settings
+   of any ancestor cgroups. If any of ancestor cgroups is frozen, the
+   cgroup will remain frozen.
+
+   Processes in the frozen cgroup can be killed by a fatal signal.
+   They also can enter and leave a frozen cgroup: either by an explicit
+   move by a user, or if freezing of the cgroup races with fork().
+   If a process is moved to a frozen cgroup, it stops. If a process is
+   moved out of a frozen cgroup, it becomes running.
+
+   Frozen status of a cgroup doesn't affect any cgroup tree operations:
+   it's possible to delete a frozen (and empty) cgroup, as well as
+   create new sub-cgroups.
 
 Controllers
 ===
-- 
2.20.1

Re: [RFC v7 0/5] pstore/block: new support logger for block devices

[Kees Cook]

On Wed, Jan 23, 2019 at 4:06 AM liaoweixiong
 wrote:
>
> Why should we need pstore_block?
> 1. Most embedded intelligent equipment have no persistent ram, which
> increases costs. We perfer to cheaper solutions, like block devices.
> In fast, there is already a sample for block device logger in driver
> MTD (drivers/mtd/mtdoops.c).
> 2. Do not any equipment have battery, which means that it lost all data
> on general ram if power failure. Pstore has little to do for these
> equipments.
>
> [PATCH v7]
> On patch 1:
> 1. Fix line over 80 characters.
> On patch 2:
> 1. Insert a separate patch for DT bindings.

This is looking good. Can you address the DT bindings review concerns,
and send a v8?

Thanks!

-- 
Kees Cook

Re: [RFC v7 0/5] pstore/block: new support logger for block devices

[liaoweixiong]

On 2019-02-13 04:54, Kees Cook wrote:
> On Wed, Jan 23, 2019 at 4:06 AM liaoweixiong
>  wrote:
>>
>> Why should we need pstore_block?
>> 1. Most embedded intelligent equipment have no persistent ram, which
>> increases costs. We perfer to cheaper solutions, like block devices.
>> In fast, there is already a sample for block device logger in driver
>> MTD (drivers/mtd/mtdoops.c).
>> 2. Do not any equipment have battery, which means that it lost all data
>> on general ram if power failure. Pstore has little to do for these
>> equipments.
>>
>> [PATCH v7]
>> On patch 1:
>> 1. Fix line over 80 characters.
>> On patch 2:
>> 1. Insert a separate patch for DT bindings.
> 
> This is looking good. Can you address the DT bindings review concerns,
> and send a v8?
> 

Sure. I had little time to send patches as i caught up with the Spring
Festival some days ago, the most grand festival of China. I'll do it
before this weekend, which is already in my plan.

> Thanks!
> 

-- 
liaoweixiong