* [PATCH 0/3] [PATCH 0/3] Documentation: virtual: convert files from .txt to
From: Luke Nowakowski-Krijger @ 2019-07-06 21:38 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Converted a few documents in virtual and virtual/kvm to .rst format.
Also added toctree hooks wherever there were .rst files. Adding hooks to
the main doc tree should be in another patch series once there are more
files in the directory.
After confirming with the appropriate lists that all the
Documentation/virtual/* files are not obsolete I will continue
converting the rest of the .txt files to .rst.
Luke Nowakowski-Krijger (3):
Documentation: virtual: Add toctree hooks
Documentation: kvm: Convert cpuid.txt to .rst
Documentation: virtual: Convert paravirt_ops.txt to .rst
Documentation/virtual/index.rst | 18 ++++
Documentation/virtual/kvm/cpuid.rst | 99 +++++++++++++++++++
Documentation/virtual/kvm/cpuid.txt | 83 ----------------
Documentation/virtual/kvm/index.rst | 12 +++
.../{paravirt_ops.txt => paravirt_ops.rst} | 19 ++--
5 files changed, 140 insertions(+), 91 deletions(-)
create mode 100644 Documentation/virtual/index.rst
create mode 100644 Documentation/virtual/kvm/cpuid.rst
delete mode 100644 Documentation/virtual/kvm/cpuid.txt
create mode 100644 Documentation/virtual/kvm/index.rst
rename Documentation/virtual/{paravirt_ops.txt => paravirt_ops.rst} (65%)
--
2.20.1
^ permalink raw reply
* [PATCH 1/3] Documentation: virtual: Add toctree hooks
From: Luke Nowakowski-Krijger @ 2019-07-06 21:38 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <cover.1562448500.git.lnowakow@eng.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Added toctree hooks for indexing. Hooks added only for newly added files
or already existing files.
The hook for the top of the tree will be added in a later patch series
when a few more substantial changes have been added.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
Documentation/virtual/index.rst | 18 ++++++++++++++++++
Documentation/virtual/kvm/index.rst | 12 ++++++++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/virtual/index.rst
create mode 100644 Documentation/virtual/kvm/index.rst
diff --git a/Documentation/virtual/index.rst b/Documentation/virtual/index.rst
new file mode 100644
index 000000000000..19c9fa2266f4
--- /dev/null
+++ b/Documentation/virtual/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Linux Virtual Documentation
+===========================
+
+.. toctree::
+ :maxdepth: 2
+
+ kvm/index
+ paravirt_ops
+
+.. only:: html and subproject
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/virtual/kvm/index.rst b/Documentation/virtual/kvm/index.rst
new file mode 100644
index 000000000000..ada224a511fe
--- /dev/null
+++ b/Documentation/virtual/kvm/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+KVM
+===
+
+.. toctree::
+ :maxdepth: 2
+
+ amd-memory-encryption
+ cpuid
+ vcpu-requests
--
2.20.1
^ permalink raw reply related
* [PATCH 3/3] Documentation: virtual: Convert paravirt_ops.txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-06 21:38 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <cover.1562448500.git.lnowakow@eng.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Convert paravirt_opts.txt to .rst format to be able to be parsed by
sphinx.
Made some minor spacing and formatting corrections to make defintions
much more clear and easy to read.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
.../{paravirt_ops.txt => paravirt_ops.rst} | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
rename Documentation/virtual/{paravirt_ops.txt => paravirt_ops.rst} (65%)
diff --git a/Documentation/virtual/paravirt_ops.txt b/Documentation/virtual/paravirt_ops.rst
similarity index 65%
rename from Documentation/virtual/paravirt_ops.txt
rename to Documentation/virtual/paravirt_ops.rst
index d4881c00e339..6b789d27cead 100644
--- a/Documentation/virtual/paravirt_ops.txt
+++ b/Documentation/virtual/paravirt_ops.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
Paravirt_ops
============
@@ -18,15 +21,15 @@ at boot time.
pv_ops operations are classified into three categories:
- simple indirect call
- These operations correspond to high level functionality where it is
- known that the overhead of indirect call isn't very important.
+ These operations correspond to high level functionality where it is
+ known that the overhead of indirect call isn't very important.
- indirect call which allows optimization with binary patch
- Usually these operations correspond to low level critical instructions. They
- are called frequently and are performance critical. The overhead is
- very important.
+ Usually these operations correspond to low level critical instructions. They
+ are called frequently and are performance critical. The overhead is
+ very important.
- a set of macros for hand written assembly code
- Hand written assembly codes (.S files) also need paravirtualization
- because they include sensitive instructions or some of code paths in
- them are very performance critical.
+ Hand written assembly codes (.S files) also need paravirtualization
+ because they include sensitive instructions or some of code paths in
+ them are very performance critical.
--
2.20.1
^ permalink raw reply related
* [PATCH 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-06 21:38 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <cover.1562448500.git.lnowakow@eng.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Convert cpuid.txt to .rst format to be parsable by sphinx.
Change format and spacing to make function definitions and return values
much more clear. Also added a table that is parsable by sphinx and makes
the information much more clean.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
Documentation/virtual/kvm/cpuid.rst | 99 +++++++++++++++++++++++++++++
Documentation/virtual/kvm/cpuid.txt | 83 ------------------------
2 files changed, 99 insertions(+), 83 deletions(-)
create mode 100644 Documentation/virtual/kvm/cpuid.rst
delete mode 100644 Documentation/virtual/kvm/cpuid.txt
diff --git a/Documentation/virtual/kvm/cpuid.rst b/Documentation/virtual/kvm/cpuid.rst
new file mode 100644
index 000000000000..1a03336a500e
--- /dev/null
+++ b/Documentation/virtual/kvm/cpuid.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+KVM CPUID bits
+==============
+
+:Author: Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
+
+A guest running on a kvm host, can check some of its features using
+cpuid. This is not always guaranteed to work, since userspace can
+mask-out some, or even all KVM-related cpuid features before launching
+a guest.
+
+KVM cpuid functions are:
+
+function: **KVM_CPUID_SIGNATURE (0x40000000)**
+
+returns::
+
+ eax = 0x40000001
+ ebx = 0x4b4d564b
+ ecx = 0x564b4d56
+ edx = 0x4d
+
+Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
+The value in eax corresponds to the maximum cpuid function present in this leaf,
+and will be updated if more functions are added in the future.
+Note also that old hosts set eax value to 0x0. This should
+be interpreted as if the value was 0x40000001.
+This function queries the presence of KVM cpuid leafs.
+
+function: **define KVM_CPUID_FEATURES (0x40000001)**
+
+returns::
+
+ ebx, ecx
+ eax = an OR'ed group of (1 << flag)
+
+where ``flag`` is defined as below:
+
++--------------------------------+------------+---------------------------------+
+| flag | value | meaning |
++================================+============+=================================+
+| KVM_FEATURE_CLOCKSOURCE | 0 | kvmclock available at msrs |
+| | | 0x11 and 0x12 |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_NOP_IO_DELAY | 1 | not necessary to perform delays |
+| | | on PIO operations |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_MMU_OP | 2 | deprecated |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_CLOCKSOURCE2 | 3 | kvmclock available at msrs |
+| | | 0x4b564d00 and 0x4b564d01 |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_ASYNC_PF | 4 | async pf can be enabled by |
+| | | writing to msr 0x4b564d02 |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_STEAL_TIME | 5 | steal time can be enabled by |
+| | | writing to msr 0x4b564d03 |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_PV_EOI | 6 | paravirtualized end of interrupt|
+| | | handler can be enabled by |
+| | | writing to msr 0x4b564d04. |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_PV_UNHAULT | 7 | guest checks this feature bit |
+| | | before enabling paravirtualized |
+| | | spinlock support |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_PV_TLB_FLUSH | 9 | guest checks this feature bit |
+| | | before enabling paravirtualized |
+| | | tlb flush |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_ASYNC_PF_VMEXIT | 10 | paravirtualized async PF VM EXIT|
+| | | can be enabled by setting bit 2 |
+| | | when writing to msr 0x4b564d02 |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_PV_SEND_IPI | 11 | guest checks this feature bit |
+| | | before enabling paravirtualized |
+| | | sebd IPIs |
++--------------------------------+------------+---------------------------------+
+| KVM_FEATURE_CLOCSOURCE_STABLE | 24 | host will warn if no guest-side |
+| _BIT | | per-cpu warps are expeced in |
+| | | kvmclock |
++--------------------------------+------------+---------------------------------+
+
+::
+
+ edx = an OR'ed group of (1 << flag)
+
+Where ``flag`` here is defined as below:
+
++--------------------------------+------------+---------------------------------+
+| flag | value | meaning |
++================================+============+=================================+
+| KVM_HINTS_REALTIME | 0 | guest checks this feature bit to|
+| | | determine that vCPUs are never |
+| | | preempted for an unlimited time |
+| | | allowing optimizations |
++--------------------------------+------------+---------------------------------+
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
deleted file mode 100644
index 97ca1940a0dc..000000000000
--- a/Documentation/virtual/kvm/cpuid.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-KVM CPUID bits
-Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
-=====================================================
-
-A guest running on a kvm host, can check some of its features using
-cpuid. This is not always guaranteed to work, since userspace can
-mask-out some, or even all KVM-related cpuid features before launching
-a guest.
-
-KVM cpuid functions are:
-
-function: KVM_CPUID_SIGNATURE (0x40000000)
-returns : eax = 0x40000001,
- ebx = 0x4b4d564b,
- ecx = 0x564b4d56,
- edx = 0x4d.
-Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
-The value in eax corresponds to the maximum cpuid function present in this leaf,
-and will be updated if more functions are added in the future.
-Note also that old hosts set eax value to 0x0. This should
-be interpreted as if the value was 0x40000001.
-This function queries the presence of KVM cpuid leafs.
-
-
-function: define KVM_CPUID_FEATURES (0x40000001)
-returns : ebx, ecx
- eax = an OR'ed group of (1 << flag), where each flags is:
-
-
-flag || value || meaning
-=============================================================================
-KVM_FEATURE_CLOCKSOURCE || 0 || kvmclock available at msrs
- || || 0x11 and 0x12.
-------------------------------------------------------------------------------
-KVM_FEATURE_NOP_IO_DELAY || 1 || not necessary to perform delays
- || || on PIO operations.
-------------------------------------------------------------------------------
-KVM_FEATURE_MMU_OP || 2 || deprecated.
-------------------------------------------------------------------------------
-KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs
- || || 0x4b564d00 and 0x4b564d01
-------------------------------------------------------------------------------
-KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by
- || || writing to msr 0x4b564d02
-------------------------------------------------------------------------------
-KVM_FEATURE_STEAL_TIME || 5 || steal time can be enabled by
- || || writing to msr 0x4b564d03.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_EOI || 6 || paravirtualized end of interrupt
- || || handler can be enabled by writing
- || || to msr 0x4b564d04.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit
- || || before enabling paravirtualized
- || || spinlock support.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_TLB_FLUSH || 9 || guest checks this feature bit
- || || before enabling paravirtualized
- || || tlb flush.
-------------------------------------------------------------------------------
-KVM_FEATURE_ASYNC_PF_VMEXIT || 10 || paravirtualized async PF VM exit
- || || can be enabled by setting bit 2
- || || when writing to msr 0x4b564d02
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_SEND_IPI || 11 || guest checks this feature bit
- || || before using paravirtualized
- || || send IPIs.
-------------------------------------------------------------------------------
-KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
- || || per-cpu warps are expected in
- || || kvmclock.
-------------------------------------------------------------------------------
-
- edx = an OR'ed group of (1 << flag), where each flags is:
-
-
-flag || value || meaning
-==================================================================================
-KVM_HINTS_REALTIME || 0 || guest checks this feature bit to
- || || determine that vCPUs are never
- || || preempted for an unlimited time,
- || || allowing optimizations
-----------------------------------------------------------------------------------
--
2.20.1
^ permalink raw reply related
* [Linux-kernel-mentees] [PATCH] Documentation: filesystems: Convert jfs.txt to reStructedText format.
From: Shobhit Kukreti @ 2019-07-06 23:22 UTC (permalink / raw)
To: Jonathan Corbet, skhan, linux-kernel-mentees, linux-doc,
linux-kernel
Cc: shobhitkukreti
This converts the plain text documentation of jfs.txt to reStructuredText format.
Added to documentation build process and verified with make htmldocs
Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
---
Documentation/filesystems/index.rst | 1 +
Documentation/filesystems/jfs.rst | 74 +++++++++++++++++++++++++++++++++++++
Documentation/filesystems/jfs.txt | 52 --------------------------
3 files changed, 75 insertions(+), 52 deletions(-)
create mode 100644 Documentation/filesystems/jfs.rst
delete mode 100644 Documentation/filesystems/jfs.txt
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index 1131c34..d700330 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -41,3 +41,4 @@ Documentation for individual filesystem types can be found here.
:maxdepth: 2
binderfs.rst
+ jfs
diff --git a/Documentation/filesystems/jfs.rst b/Documentation/filesystems/jfs.rst
new file mode 100644
index 0000000..bfb6110
--- /dev/null
+++ b/Documentation/filesystems/jfs.rst
@@ -0,0 +1,74 @@
+===========================================
+IBM's Journaled File System (JFS) for Linux
+===========================================
+
+JFS Homepage: http://jfs.sourceforge.net/
+
+Following Mount Options are Supported
+
+(*) == default
+ .. tabularcolumns:: |p{1.3cm}|p{1.3cm}|p{8.0cm}|
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - iocharset
+ - =name
+ - Character set to use for converting from Unicode to ASCII. The default is to do no conversion. Use iocharset=utf8 for UTF-8 translations.
+ This requires CONFIG_NLS_UTF8 to be set in the kernel .config file. iocharset=none specifies the default behavior explicitly.
+
+ * - resize
+ - =value
+ - Resize the volume to <value> blocks. JFS only supports growing a volume, not shrinking it. This option is only valid during a remount,
+ when the volume is mounted read-write. The resize keyword with no value will grow the volume to the full size of the partition.
+
+ * - nointegrity
+ -
+ - Do not write to the journal. The primary use of this option is to allow for higher performance when restoring a volume from backup media.
+ The integrity of the volume is not guaranteed if the system abnormally abends.
+
+ * - integrity
+ - (*)
+ - Commit metadata changes to the journal. Use this option to remount a volume where the nointegrity option was previously specified in order
+ to restore normal behavior.
+
+ * - errors
+ - =continue
+ - Keep going on a filesystem error.
+
+ * - errors
+ - =remount-ro(*)
+ - Remount the filesystem read-only on an error.
+
+ * - errors
+ - =panic
+ - Panic and halt the machine if an error occurs.
+
+ * - uid
+ - =value
+ - Override on-disk uid with specified value
+
+ * - gid
+ - =value
+ - Override on-disk gid with specified value
+
+ * - umask
+ - =value
+ - Override on-disk umask with specified octal value. For directories, the execute bit will be set if the corresponding read bit is set.
+
+ * - discard
+ - =minlen
+ - :rspan:`1` :cspan:`1` This enables/disables the use of discard/TRIM commands.The discard/TRIM commands are sent to the underlying block device when blocks
+ are freed. This is useful for SSD devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl command is also available together with the nodiscard option.
+ The value of minlen specifies the minimum blockcount, when a TRIM command to the block device is considered useful. When no value is given to the
+ discard option, it defaults to 64 blocks, which means 256KiB in JFS. The minlen value of discard overrides the minlen value given on an FITRIM ioctl()
+
+ * - nodiscard(*)
+ -
+
+
+The JFS mailing list can be subscribed to by using the link labeled
+"Mail list Subscribe" at our web page http://jfs.sourceforge.net/
diff --git a/Documentation/filesystems/jfs.txt b/Documentation/filesystems/jfs.txt
deleted file mode 100644
index 41fd757..0000000
--- a/Documentation/filesystems/jfs.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-IBM's Journaled File System (JFS) for Linux
-
-JFS Homepage: http://jfs.sourceforge.net/
-
-The following mount options are supported:
-(*) == default
-
-iocharset=name Character set to use for converting from Unicode to
- ASCII. The default is to do no conversion. Use
- iocharset=utf8 for UTF-8 translations. This requires
- CONFIG_NLS_UTF8 to be set in the kernel .config file.
- iocharset=none specifies the default behavior explicitly.
-
-resize=value Resize the volume to <value> blocks. JFS only supports
- growing a volume, not shrinking it. This option is only
- valid during a remount, when the volume is mounted
- read-write. The resize keyword with no value will grow
- the volume to the full size of the partition.
-
-nointegrity Do not write to the journal. The primary use of this option
- is to allow for higher performance when restoring a volume
- from backup media. The integrity of the volume is not
- guaranteed if the system abnormally abends.
-
-integrity(*) Commit metadata changes to the journal. Use this option to
- remount a volume where the nointegrity option was
- previously specified in order to restore normal behavior.
-
-errors=continue Keep going on a filesystem error.
-errors=remount-ro(*) Remount the filesystem read-only on an error.
-errors=panic Panic and halt the machine if an error occurs.
-
-uid=value Override on-disk uid with specified value
-gid=value Override on-disk gid with specified value
-umask=value Override on-disk umask with specified octal value. For
- directories, the execute bit will be set if the corresponding
- read bit is set.
-
-discard=minlen This enables/disables the use of discard/TRIM commands.
-discard The discard/TRIM commands are sent to the underlying
-nodiscard(*) block device when blocks are freed. This is useful for SSD
- devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
- command is also available together with the nodiscard option.
- The value of minlen specifies the minimum blockcount, when
- a TRIM command to the block device is considered useful.
- When no value is given to the discard option, it defaults to
- 64 blocks, which means 256KiB in JFS.
- The minlen value of discard overrides the minlen value given
- on an FITRIM ioctl().
-
-The JFS mailing list can be subscribed to by using the link labeled
-"Mail list Subscribe" at our web page http://jfs.sourceforge.net/
--
2.7.4
^ permalink raw reply related
* [Linux-kernel-mentees] [PATCH] Documentation: filesystems: Convert ufs.txt to reStructuredText format
From: Shobhit Kukreti @ 2019-07-07 1:39 UTC (permalink / raw)
To: Jonathan Corbet, skhan, linux-kernel-mentees, linux-doc,
linux-kernel
Cc: shobhitkukreti
This converts the plain text documentation of ufs.txt to reStructuredText format.
Added to documentation build process and verified with make htmldocs
Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
---
Documentation/filesystems/index.rst | 1 +
Documentation/filesystems/ufs.rst | 65 +++++++++++++++++++++++++++++++++++++
Documentation/filesystems/ufs.txt | 60 ----------------------------------
3 files changed, 66 insertions(+), 60 deletions(-)
create mode 100644 Documentation/filesystems/ufs.rst
delete mode 100644 Documentation/filesystems/ufs.txt
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index d700330..2b4f870 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -42,3 +42,4 @@ Documentation for individual filesystem types can be found here.
binderfs.rst
jfs
+ ufs
diff --git a/Documentation/filesystems/ufs.rst b/Documentation/filesystems/ufs.rst
new file mode 100644
index 0000000..d6aeef0
--- /dev/null
+++ b/Documentation/filesystems/ufs.rst
@@ -0,0 +1,65 @@
+=========
+USING UFS
+=========
+
+mount -t ufs -o ufstype=type_of_ufs device dir
+
+UFS OPTIONS
+===========
+
+.. tabularcolumns:: |p{0.5cm}|p{0.5cm}|p{8.0cm}|
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - :rspan:`10` ufstype
+ - =type_of_ufs
+ - UFS is a file system widely used in different operating systems. The problem are differences among implementations. Features of some implementations
+ are undocumented, so its hard to recognize type of ufs automatically. That's why user must specify type of ufs manually by mount option ufstype.
+ Possible values are below.
+
+ * - old
+ - old format of ufs default value, supported as read-only
+
+ * - 44bsd
+ - used in FreeBSD, NetBSD, OpenBSD supported as read-write
+
+ * - ufs2
+ - used in FreeBSD 5.x supported as read-write
+
+ * - 5xbsd
+ - synonym for ufs2
+
+ * - sun
+ - used in SunOS (Solaris) supported as read-write
+
+ * - sunx86
+ - used in SunOS for Intel (Solarisx86) supported as read-write
+
+ * - hp
+ - used in HP-UX supported as read-only
+
+ * - nextstep
+ - used in NextStep supported as read-only
+
+ * - nextstep-cd
+ - used for NextStep CDROMs (block_size == 2048) supported as read-only
+
+ * - openstep
+ - used in OpenStep supported as read-only
+
+
+POSSIBLE PROBLEMS
+-----------------
+
+See next section, if you have any.
+
+
+BUG REPORTS
+-----------
+
+Any ufs bug report you can send to daniel.pirkl@email.cz or
+to dushistov@mail.ru (do not send partition tables bug reports).
diff --git a/Documentation/filesystems/ufs.txt b/Documentation/filesystems/ufs.txt
deleted file mode 100644
index 7a602ad..0000000
--- a/Documentation/filesystems/ufs.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-USING UFS
-=========
-
-mount -t ufs -o ufstype=type_of_ufs device dir
-
-
-UFS OPTIONS
-===========
-
-ufstype=type_of_ufs
- UFS is a file system widely used in different operating systems.
- The problem are differences among implementations. Features of
- some implementations are undocumented, so its hard to recognize
- type of ufs automatically. That's why user must specify type of
- ufs manually by mount option ufstype. Possible values are:
-
- old old format of ufs
- default value, supported as read-only
-
- 44bsd used in FreeBSD, NetBSD, OpenBSD
- supported as read-write
-
- ufs2 used in FreeBSD 5.x
- supported as read-write
-
- 5xbsd synonym for ufs2
-
- sun used in SunOS (Solaris)
- supported as read-write
-
- sunx86 used in SunOS for Intel (Solarisx86)
- supported as read-write
-
- hp used in HP-UX
- supported as read-only
-
- nextstep
- used in NextStep
- supported as read-only
-
- nextstep-cd
- used for NextStep CDROMs (block_size == 2048)
- supported as read-only
-
- openstep
- used in OpenStep
- supported as read-only
-
-
-POSSIBLE PROBLEMS
-=================
-
-See next section, if you have any.
-
-
-BUG REPORTS
-===========
-
-Any ufs bug report you can send to daniel.pirkl@email.cz or
-to dushistov@mail.ru (do not send partition tables bug reports).
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Randy Dunlap @ 2019-07-07 19:33 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <a8ee93721a674434e22d31fd1d10bf9472c1c739.camel@linux.intel.com>
On 7/5/19 3:15 AM, Jarkko Sakkinen wrote:
> On Wed, 2019-07-03 at 09:45 -0700, Randy Dunlap wrote:
>>> +This introduces another problem: nothing guarantees that it is not
>>> +called before the stub gets to run. Thus, it needs to copy the final
>>> +events table preboot size to the custom configuration table so that
>>> +kernel offset it later on.
(so that)
the kernel can use that final table preboot size as an events table
offset later on.
>>
>> ? kernel can offset it later on.
>
> EFI stub calculates the total size of the events in the final events
> table at the time.
>
> Later on, TPM driver uses this offset to copy only the events that
> were actually generated after ExitBootServices():
>
> /*
> * Copy any of the final events log that didn't also end up in the
> * main log. Events can be logged in both if events are generated
> * between GetEventLog() and ExitBootServices().
> */
> memcpy((void *)log->bios_event_log + log_size,
> final_tbl->events + log_tbl->final_events_preboot_size,
> efi_tpm_final_log_size);
>
> What would be a better way to describe this?
Yeah, I think I see what it's doing, how it's using that.
See above.
OK?
--
~Randy
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jordan Hand @ 2019-07-08 4:10 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <fcf497b7aa95cd6915986bc4581f10814c4d5341.camel@linux.intel.com>
On 7/5/19 3:26 AM, Jarkko Sakkinen wrote:
> On Wed, 2019-07-03 at 10:08 -0700, Jordan Hand wrote:
>>> +This introduces another problem: nothing guarantees that it is not
>>> +called before the stub gets to run. Thus, it needs to copy the final
>>> +events table preboot size to the custom configuration table so that
>>> +kernel offset it later on.
>>
>> This doesn't really explain what the size will be used for. Matthew's
>> patch description for "tpm: Don't duplicate events from the final event
>> log in the TCG2 log" outlines this well. You could maybe word it
>> differently but I think the information is necessary:
>>
>> "We can avoid this problem by looking at the size of the Final Event Log
>> just before we call ExitBootServices() and exporting this to the main
>> kernel. The kernel can then skip over all events that occured before
>> ExitBootServices() and only append events that were not also logged to
>> the main log."
>
> Not exactly sure what is missing from my paragraph. The way I see it has
> more information as it states what is used at as the vessel for
> exportation (the custom configuration table).
>
> Maybe something like:
>
> "Thus, it nees to save the final events table size at the time to the
> custom configuration table so that the TPM driver can later on skip the
> events generated during the preboot time."
>
Yes, that sounds more clear to me.
Thanks,
Jordan
^ permalink raw reply
* Re: [RFC 0/7] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-07-08 12:41 UTC (permalink / raw)
To: Jens Wiklander
Cc: corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar, jmorris,
serge, Ard Biesheuvel, Daniel Thompson, linux-doc,
Linux Kernel Mailing List, tee-dev, keyrings,
linux-security-module, linux-integrity
In-Reply-To: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org>
Hi Jens,
On Thu, 13 Jun 2019 at 16:01, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key. Also, this is
> an alternative in case platform doesn't possess a TPM device.
>
> This series also adds some TEE features like:
>
> Patch #1, #2 enables support for registered kernel shared memory with TEE.
>
Would you like to pick up Patch #1, #2 separately? I think both these
patches add independent functionality and also got reviewed-by tags
too.
-Sumit
> Patch #3 enables support for private kernel login method required for
> cases like trusted keys where we don't wan't user-space to directly access
> TEE service to retrieve trusted key contents.
>
> Rest of the patches from #4 to #7 adds support for TEE based trusted keys.
>
> This patch-set has been tested with OP-TEE based pseudo TA which can be
> found here [1].
>
> Looking forward to your valuable feedback/suggestions.
>
> [1] https://github.com/OP-TEE/optee_os/pull/3082
>
> Sumit Garg (7):
> tee: optee: allow kernel pages to register as shm
> tee: enable support to register kernel memory
> tee: add private login method for kernel clients
> KEYS: trusted: Introduce TEE based Trusted Keys
> KEYS: encrypted: Allow TEE based trusted master keys
> doc: keys: Document usage of TEE based Trusted Keys
> MAINTAINERS: Add entry for TEE based Trusted Keys
>
> Documentation/security/keys/tee-trusted.rst | 93 +++++
> MAINTAINERS | 9 +
> drivers/tee/optee/call.c | 7 +
> drivers/tee/tee_core.c | 6 +
> drivers/tee/tee_shm.c | 16 +-
> include/keys/tee_trusted.h | 84 ++++
> include/keys/trusted-type.h | 1 +
> include/linux/tee_drv.h | 1 +
> include/uapi/linux/tee.h | 2 +
> security/keys/Kconfig | 3 +
> security/keys/Makefile | 3 +
> security/keys/encrypted-keys/masterkey_trusted.c | 10 +-
> security/keys/tee_trusted.c | 506 +++++++++++++++++++++++
> 13 files changed, 737 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/security/keys/tee-trusted.rst
> create mode 100644 include/keys/tee_trusted.h
> create mode 100644 security/keys/tee_trusted.c
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] Documentation: usb: convert usb-help to rst
From: Jonathan Corbet @ 2019-07-08 13:52 UTC (permalink / raw)
To: Phong Tran
Cc: gregkh, skhan, mchehab, linux-kernel-mentees, linux-usb,
linux-doc, linux-kernel
In-Reply-To: <20190705185519.31033-1-tranmanphong@gmail.com>
On Sat, 6 Jul 2019 01:55:19 +0700
Phong Tran <tranmanphong@gmail.com> wrote:
> Add new index.rst and change usb-help.txt format
> to rst.
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Thank you for working to make the kernel's documentation better. That
said, I really don't think there is value in keeping this document. It
hasn't been updated in any useful way in decades, contains broken links,
and the links that still work are full of obsolete information. Honestly,
a better patch would, IMO, just delete this file.
Thanks,
jon
^ permalink raw reply
* Здравствуйте! Вас интересуют клиентские базы данных?
From: linux-doc @ 2019-07-08 13:49 UTC (permalink / raw)
To: t19oMXDNLwlyadlinux-doc
Здравствуйте! Вас интересуют клиентские базы данных?
^ permalink raw reply
* Re: [PATCH next] softirq: enable MAX_SOFTIRQ_TIME tuning with sysctl max_softirq_time_usecs
From: Thomas Gleixner @ 2019-07-08 14:14 UTC (permalink / raw)
To: Zhiqiang Liu
Cc: corbet, mcgrof, Kees Cook, akpm, manfred, jwilk, dvyukov,
feng.tang, sunilmut, quentin.perret, linux, alex.popov, linux-doc,
linux-kernel, linux-fsdevel, wangxiaogang (F), Zhoukang (A),
Mingfangsen, tedheadster, Eric Dumazet
In-Reply-To: <c1b7a345-fa22-e52a-4db8-1f1288e7ad15@huawei.com>
Zhiqiang,
On Tue, 25 Jun 2019, Zhiqiang Liu wrote:
> I have a doubt about _msecs_to_jiffies funcs, especially when input m is
> equal to 0.
>
> For different HZ setttings, different _msecs_to_jiffies funcs will be
> chosen for msecs_to_jiffies func. However, the performance of different
> _msecs_to_jiffies is inconsistent with input m is equal to 0.
>
> If HZ satisfies the condition: HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC %
> HZ), the return value of _msecs_to_jiffies func with m=0 is different
> with different HZ setting.
> ------------------------------------
> | HZ | MSEC_PER_SEC / HZ | return |
> ------------------------------------
> |1000| 1 | 0 |
> |500 | 2 | 1 |
> |200 | 5 | 1 |
> |100 | 10 | 1 |
> ------------------------------------
>
> Why only the return value of HZ=1000 is equal to 0 with m=0 ?
I don't know how you tested that, but obviously all four HZ values use
this variant:
> #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> static inline unsigned long _msecs_to_jiffies(const unsigned int m)
> {
> return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
> }
and for all four HZ values the result is 0. Why?
For m = 0 the calculation reduces to:
((MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ)
i.e.
(x - 1) / x where x = [1, 2, 5, 10]
which is guaranteed to be 0 for integer math. If not, you have a compiler
problem.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] Documentation: usb: convert usb-help to rst
From: Phong Tran @ 2019-07-08 15:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jonathan Corbet
Cc: Shuah Khan, mchehab, linux-kernel-mentees, linux-usb, linux-doc,
linux-kernel
In-Reply-To: <20190708075255.0f337b28@lwn.net>
On Mon, Jul 8, 2019 at 8:52 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> On Sat, 6 Jul 2019 01:55:19 +0700
> Phong Tran <tranmanphong@gmail.com> wrote:
>
> > Add new index.rst and change usb-help.txt format
> > to rst.
> >
> > Signed-off-by: Phong Tran <tranmanphong@gmail.com>
>
> Thank you for working to make the kernel's documentation better. That
> said, I really don't think there is value in keeping this document. It
> hasn't been updated in any useful way in decades, contains broken links,
> and the links that still work are full of obsolete information. Honestly,
> a better patch would, IMO, just delete this file.
>
@Jonathan Corbet it's fine to me.
Need ack from you @Greg Kroah-Hartman
if yes, I will send the cleanup patch.
Regards,
Phong.
^ permalink raw reply
* Re: [PATCH] docs: automarkup.py: ignore exceptions when seeking for xrefs
From: Jonathan Corbet @ 2019-07-08 15:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <d9b1c85769ba659dba6c7c8b459e385be28ca478.1562430514.git.mchehab+samsung@kernel.org>
On Sat, 6 Jul 2019 13:28:42 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> When using the automarkup extension with:
> make pdfdocs
>
> without passing an specific book, the code will raise an exception:
>
> File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 86, in auto_markup
> node.parent.replace(node, markup_funcs(name, app, node))
> File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 59, in markup_funcs
> 'function', target, pxref, lit_text)
> File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/domains/c.py", line 308, in resolve_xref
> contnode, target)
> File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/util/nodes.py", line 450, in make_refnode
> '#' + targetid)
> File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 159, in get_relative_uri
> return self.get_target_uri(to, typ)
> File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 152, in get_target_uri
> raise NoUri
> sphinx.environment.NoUri
>
> This happens because not all references will belong to a single
> PDF/LaTeX document.
Interesting. I'd like to understand better why the HTML builder doesn't do
this...it seems like a bug in the latex builder somehow.
> Better to just ignore those than breaking Sphinx build.
>
> Fixes: d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/sphinx/automarkup.py | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py
> index b300cf129869..dba14374f269 100644
> --- a/Documentation/sphinx/automarkup.py
> +++ b/Documentation/sphinx/automarkup.py
> @@ -55,8 +55,13 @@ def markup_funcs(docname, app, node):
> reftype = 'function',
> reftarget = target, modname = None,
> classname = None)
> - xref = cdom.resolve_xref(app.env, docname, app.builder,
> - 'function', target, pxref, lit_text)
> +
> + # When building pdf documents, this may raise a NoUri exception
> + try:
> + xref = cdom.resolve_xref(app.env, docname, app.builder,
> + 'function', target, pxref, lit_text)
> + except:
> + xref = None
So this absolutely needs to be "except sphinx.environment.NoUri". I have
seen catch-all "except" clauses paper over or otherwise hide too many
problems over the years; I really try to avoid ever using them.
I want to look at this problem and understand it a bit better; then I'll
probably end up applying this patch with the above tweak.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-08 15:25 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <ec274596-6bc8-07a0-d09b-1d191646c5cd@infradead.org>
On Sun, 2019-07-07 at 12:33 -0700, Randy Dunlap wrote:
> On 7/5/19 3:15 AM, Jarkko Sakkinen wrote:
> > On Wed, 2019-07-03 at 09:45 -0700, Randy Dunlap wrote:
> > > > +This introduces another problem: nothing guarantees that it is not
> > > > +called before the stub gets to run. Thus, it needs to copy the final
> > > > +events table preboot size to the custom configuration table so that
> > > > +kernel offset it later on.
>
> (so that)
> the kernel can use that final table preboot size as an events table
> offset later on.
>
> > > ? kernel can offset it later on.
> >
> > EFI stub calculates the total size of the events in the final events
> > table at the time.
> >
> > Later on, TPM driver uses this offset to copy only the events that
> > were actually generated after ExitBootServices():
> >
> > /*
> > * Copy any of the final events log that didn't also end up in the
> > * main log. Events can be logged in both if events are generated
> > * between GetEventLog() and ExitBootServices().
> > */
> > memcpy((void *)log->bios_event_log + log_size,
> > final_tbl->events + log_tbl->final_events_preboot_size,
> > efi_tpm_final_log_size);
> >
> > What would be a better way to describe this?
>
> Yeah, I think I see what it's doing, how it's using that.
> See above.
>
> OK?
Your propsal looks legit, thank you. I'll send an update that
tries to address yours and Jordan's feedback.
/Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-08 15:27 UTC (permalink / raw)
To: Jordan Hand, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <33ff21e2-1e27-cc85-0ea3-5127cb2598ba@linux.microsoft.com>
On Sun, 2019-07-07 at 21:10 -0700, Jordan Hand wrote:
> > "Thus, it nees to save the final events table size at the time to the
> > custom configuration table so that the TPM driver can later on skip the
> > events generated during the preboot time."
> >
> Yes, that sounds more clear to me.
>
> Thanks,
> Jordan
Awesome, thank you.
/Jarkko
^ permalink raw reply
* Re: [RFC 3/7] tee: add private login method for kernel clients
From: Jens Wiklander @ 2019-07-08 15:39 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, corbet,
dhowells, jejb, jarkko.sakkinen, zohar, jmorris, serge,
ard.biesheuvel, daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-4-git-send-email-sumit.garg@linaro.org>
Hi Sumit,
On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote:
> There are use-cases where user-space shouldn't be allowed to communicate
> directly with a TEE device which is dedicated to provide a specific
> service for a kernel client. So add a private login method for kernel
> clients and disallow user-space to open-session using this login method.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
> drivers/tee/tee_core.c | 6 ++++++
> include/uapi/linux/tee.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> index 0f16d9f..4581bd1 100644
> --- a/drivers/tee/tee_core.c
> +++ b/drivers/tee/tee_core.c
> @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct tee_context *ctx,
> goto out;
> }
>
> + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) {
TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x80000000 which is in the
range specified and implementation defined by the GP spec. I wonder if
we shouldn't filter the entire implementation defined range instead of
just this value.
> + pr_err("login method not allowed for user-space client\n");
pr_debug(), if it's needed at all.
> + rc = -EPERM;
> + goto out;
> + }
> +
> rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
> if (rc)
> goto out;
> diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> index 4b9eb06..f33c69c 100644
> --- a/include/uapi/linux/tee.h
> +++ b/include/uapi/linux/tee.h
> @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data {
> #define TEE_IOCTL_LOGIN_APPLICATION 4
> #define TEE_IOCTL_LOGIN_USER_APPLICATION 5
> #define TEE_IOCTL_LOGIN_GROUP_APPLICATION 6
> +/* Private login method for REE kernel clients */
It's worth noting that this is filtered by the TEE framework, compared
to everything else which is treated opaquely.
> +#define TEE_IOCTL_LOGIN_REE_KERNEL 0x80000000
>
> /**
> * struct tee_ioctl_param - parameter
> --
> 2.7.4
>
Thanks,
Jens
^ permalink raw reply
* Re: [PATCH] docs: automarkup.py: ignore exceptions when seeking for xrefs
From: Mauro Carvalho Chehab @ 2019-07-08 16:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190708092336.01ade0ab@lwn.net>
Em Mon, 8 Jul 2019 09:23:36 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Sat, 6 Jul 2019 13:28:42 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > When using the automarkup extension with:
> > make pdfdocs
> >
> > without passing an specific book, the code will raise an exception:
> >
> > File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 86, in auto_markup
> > node.parent.replace(node, markup_funcs(name, app, node))
> > File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 59, in markup_funcs
> > 'function', target, pxref, lit_text)
> > File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/domains/c.py", line 308, in resolve_xref
> > contnode, target)
> > File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/util/nodes.py", line 450, in make_refnode
> > '#' + targetid)
> > File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 159, in get_relative_uri
> > return self.get_target_uri(to, typ)
> > File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 152, in get_target_uri
> > raise NoUri
> > sphinx.environment.NoUri
> >
> > This happens because not all references will belong to a single
> > PDF/LaTeX document.
>
> Interesting. I'd like to understand better why the HTML builder doesn't do
> this...it seems like a bug in the latex builder somehow.
It took me a while to identify what part of the extension was causing the
build breakage with make pdfdocs, but this occurs upstream too, if you
try to build all documents.
The funny thing is that, if you try to build a single book, e. g.:
make SPHINXDIRS=foo pdfdocs
this won't happen.
I didn't spend too much time trying to identify the exact breakage reason.
All I did were to add some prints inside latex/*.py while debugging it, in
order to get a rough idea about what was happening.
On several places, the code with calls "raise NoUri" is called, but the
caller silently ignores it (that happens, for example, when it parses
:ref:`genindex`).
What I suspect is that, when you do an html build - or when you build just
a single book with SPHINXDIRS=foo, all dependencies are either:
- unsolved; or
- solved within the same document/html URL
In other words, solved references will have a relative position within
a single documentation body. So, there won't be any need for a document
to refer to a symbol on some other document.
With PDF, a symbol defined under, let's say, "core-api" defines a
core_foo() function, and this function is referenced inside the "driver-api"
book. The automarkup.py will convert a driver-api core_foo() to:
:ref:`core_foo()`, instead of :doc:`core-api`, but core_foo label
doesn't exist within the "driver-api" book context.
As we're not using intersphinx extension, Sphinx doesn't have any
URL to convert the cross-reference in a way that, if one clicks at the
reference, it will open the referenced document at the proper page.
So, it bails out.
That's said, I didn't try to use intersphinx in order to check if
LaTeX references to other documents would actually work.
>
> > Better to just ignore those than breaking Sphinx build.
> >
> > Fixes: d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/sphinx/automarkup.py | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py
> > index b300cf129869..dba14374f269 100644
> > --- a/Documentation/sphinx/automarkup.py
> > +++ b/Documentation/sphinx/automarkup.py
> > @@ -55,8 +55,13 @@ def markup_funcs(docname, app, node):
> > reftype = 'function',
> > reftarget = target, modname = None,
> > classname = None)
> > - xref = cdom.resolve_xref(app.env, docname, app.builder,
> > - 'function', target, pxref, lit_text)
> > +
> > + # When building pdf documents, this may raise a NoUri exception
> > + try:
> > + xref = cdom.resolve_xref(app.env, docname, app.builder,
> > + 'function', target, pxref, lit_text)
> > + except:
> > + xref = None
>
> So this absolutely needs to be "except sphinx.environment.NoUri". I have
> seen catch-all "except" clauses paper over or otherwise hide too many
> problems over the years; I really try to avoid ever using them.
Makes sense to me. Feel free to change it when you apply it.
>
> I want to look at this problem and understand it a bit better; then I'll
> probably end up applying this patch with the above tweak.
Btw, I got some other issues when changed Sphinx to include all books to the
pdf output on my documentation development tree:
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=convert_rst_renames_next_v2&id=cd72aaefc8b07ce7909be914e46dfb02bad5d86b
They're related to having nested tables, with got fixed by this patch:
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=convert_rst_renames_next_v2&id=fd0b22e391431f766e9be6f161fab9646c0dd9ca
Thanks,
Mauro
^ permalink raw reply
* Re: [RFC 0/7] Introduce TEE based Trusted Keys support
From: Jens Wiklander @ 2019-07-08 16:31 UTC (permalink / raw)
To: Sumit Garg
Cc: corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar, jmorris,
serge, Ard Biesheuvel, Daniel Thompson, linux-doc,
Linux Kernel Mailing List, tee-dev, keyrings,
linux-security-module, linux-integrity
In-Reply-To: <CAFA6WYPn3HB6BRocKmKTR+ZPE=Fav5w1TUdRgmLp-NkYobp3rw@mail.gmail.com>
Hi Sumit,
On Mon, Jul 08, 2019 at 06:11:39PM +0530, Sumit Garg wrote:
> Hi Jens,
>
> On Thu, 13 Jun 2019 at 16:01, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Add support for TEE based trusted keys where TEE provides the functionality
> > to seal and unseal trusted keys using hardware unique key. Also, this is
> > an alternative in case platform doesn't possess a TPM device.
> >
> > This series also adds some TEE features like:
> >
> > Patch #1, #2 enables support for registered kernel shared memory with TEE.
> >
>
> Would you like to pick up Patch #1, #2 separately? I think both these
> patches add independent functionality and also got reviewed-by tags
> too.
I think it makes more sense to keep them together in the same patch
series or could end up with dependencies between trees.
If you don't think dependencies will be an issue then I don't mind
picking them up, in that case they'd likely sit in an arm-soc branch
until next merge window. However, I think that #3 (support for private
kernel login method) should be included too and that one isn't ready
yet.
Thanks,
Jens
>
>
> -Sumit
>
> > Patch #3 enables support for private kernel login method required for
> > cases like trusted keys where we don't wan't user-space to directly access
> > TEE service to retrieve trusted key contents.
> >
> > Rest of the patches from #4 to #7 adds support for TEE based trusted keys.
> >
> > This patch-set has been tested with OP-TEE based pseudo TA which can be
> > found here [1].
> >
> > Looking forward to your valuable feedback/suggestions.
> >
> > [1] https://github.com/OP-TEE/optee_os/pull/3082
> >
> > Sumit Garg (7):
> > tee: optee: allow kernel pages to register as shm
> > tee: enable support to register kernel memory
> > tee: add private login method for kernel clients
> > KEYS: trusted: Introduce TEE based Trusted Keys
> > KEYS: encrypted: Allow TEE based trusted master keys
> > doc: keys: Document usage of TEE based Trusted Keys
> > MAINTAINERS: Add entry for TEE based Trusted Keys
> >
> > Documentation/security/keys/tee-trusted.rst | 93 +++++
> > MAINTAINERS | 9 +
> > drivers/tee/optee/call.c | 7 +
> > drivers/tee/tee_core.c | 6 +
> > drivers/tee/tee_shm.c | 16 +-
> > include/keys/tee_trusted.h | 84 ++++
> > include/keys/trusted-type.h | 1 +
> > include/linux/tee_drv.h | 1 +
> > include/uapi/linux/tee.h | 2 +
> > security/keys/Kconfig | 3 +
> > security/keys/Makefile | 3 +
> > security/keys/encrypted-keys/masterkey_trusted.c | 10 +-
> > security/keys/tee_trusted.c | 506 +++++++++++++++++++++++
> > 13 files changed, 737 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/security/keys/tee-trusted.rst
> > create mode 100644 include/keys/tee_trusted.h
> > create mode 100644 security/keys/tee_trusted.c
> >
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [PATCH] Documentation: coresight: covert txt to rst
From: Mathieu Poirier @ 2019-07-08 16:43 UTC (permalink / raw)
To: Phong Tran
Cc: Jon Corbet, Suzuki K. Poulose, skhan, mchehab, linux-arm-kernel,
open list:DOCUMENTATION, Linux Kernel Mailing List,
linux-kernel-mentees
In-Reply-To: <20190705204512.15444-1-tranmanphong@gmail.com>
Hi Tran,
Thank you for doing this - it adds much needed consistency to this
file. A few of comments below....
On Fri, 5 Jul 2019 at 14:45, Phong Tran <tranmanphong@gmail.com> wrote:
>
> change the format file and adpate the text style
This changtelog is a little short and mentions what you are doing
rather than why.
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> .../trace/{coresight.txt => coresight.rst} | 296 ++++++++++++---------
> Documentation/trace/index.rst | 1 +
> 2 files changed, 167 insertions(+), 130 deletions(-)
> rename Documentation/trace/{coresight.txt => coresight.rst} (59%)
File "coresight.txt" is referenced in the MAINTAINERS file and should
probably be changed there as well.
Did you look at coresight-cpu-debug.txt? In my opinion both files
should be changed in the same patchset.
Thanks,
Mathieu
>
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
> similarity index 59%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index efbc832146e7..bea24e70cfba 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,5 +1,6 @@
> - Coresight - HW Assisted Tracing on ARM
> - ======================================
> +======================================
> +Coresight - HW Assisted Tracing on ARM
> +======================================
>
> Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> Date: September 11th, 2014
> @@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
> creating an interface to the outside world where data can be transferred to a
> host without fear of filling up the onboard coresight memory buffer.
>
> -At typical coresight system would look like this:
> +At typical coresight system would look like this::
>
> *****************************************************************
> **************************** AMBA AXI ****************************===||
> @@ -95,6 +96,7 @@ Acronyms and Classification
>
> Acronyms:
>
> +======== =============================================================
> PTM: Program Trace Macrocell
> ETM: Embedded Trace Macrocell
> STM: System trace Macrocell
> @@ -104,6 +106,7 @@ TPIU: Trace Port Interface Unit
> TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
> TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
> CTI: Cross Trigger Interface
> +======== =============================================================
>
> Classification:
>
> @@ -118,7 +121,7 @@ Misc:
>
>
> Device Tree Bindings
> -----------------------
> +--------------------
>
> See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,57 +136,63 @@ The coresight framework provides a central point to represent, configure and
> manage coresight devices on a platform. Any coresight compliant device can
> register with the framework for as long as they use the right APIs:
>
> -struct coresight_device *coresight_register(struct coresight_desc *desc);
> -void coresight_unregister(struct coresight_device *csdev);
> +.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
> +.. c:function:: void coresight_unregister(struct coresight_device *csdev);
>
> -The registering function is taking a "struct coresight_device *csdev" and
> +The registering function is taking a :code:`struct coresight_device *csdev` and
> register the device with the core framework. The unregister function takes
> -a reference to a "struct coresight_device", obtained at registration time.
> +a reference to a :code:`struct coresight_device`, obtained at registration time.
>
> If everything goes well during the registration process the new devices will
> show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
>
> -root:~# ls /sys/bus/coresight/devices/
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:~#
> +.. code:: console
>
> -The functions take a "struct coresight_device", which looks like this:
> + root:~# ls /sys/bus/coresight/devices/
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:~#
>
> -struct coresight_desc {
> - enum coresight_dev_type type;
> - struct coresight_dev_subtype subtype;
> - const struct coresight_ops *ops;
> - struct coresight_platform_data *pdata;
> - struct device *dev;
> - const struct attribute_group **groups;
> -};
> +The functions take a :code:`struct coresight_device`, which looks like this:
> +
> +.. code:: c
> +
> + struct coresight_desc {
> + enum coresight_dev_type type;
> + struct coresight_dev_subtype subtype;
> + const struct coresight_ops *ops;
> + struct coresight_platform_data *pdata;
> + struct device *dev;
> + const struct attribute_group **groups;
> + };
>
>
> The "coresight_dev_type" identifies what the device is, i.e, source link or
> sink while the "coresight_dev_subtype" will characterise that type further.
>
> -The "struct coresight_ops" is mandatory and will tell the framework how to
> +The :code:`struct coresight_ops` is mandatory and will tell the framework how to
> perform base operations related to the components, each component having
> -a different set of requirement. For that "struct coresight_ops_sink",
> -"struct coresight_ops_link" and "struct coresight_ops_source" have been
> +a different set of requirement. For that :code:`struct coresight_ops_sink,
> +struct coresight_ops_link` and :code:`struct coresight_ops_source` have been
> provided.
>
> -The next field, "struct coresight_platform_data *pdata" is acquired by calling
> -"of_get_coresight_platform_data()", as part of the driver's _probe routine and
> -"struct device *dev" gets the device reference embedded in the "amba_device":
> +The next field, :code:`struct coresight_platform_data *pdata` is acquired by calling
> +:code:`of_get_coresight_platform_data()`, as part of the driver's _probe routine and
> +:code:`struct device *dev` gets the device reference embedded in the :code:`amba_device`:
>
> -static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> -{
> - ...
> - ...
> - drvdata->dev = &adev->dev;
> - ...
> -}
> +.. code:: c
> +
> + static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> + {
> + ...
> + ...
> + drvdata->dev = &adev->dev;
> + ...
> + }
>
> Specific class of device (source, link, or sink) have generic operations
> -that can be performed on them (see "struct coresight_ops"). The
> -"**groups" is a list of sysfs entries pertaining to operations
> +that can be performed on them (see :code:`struct coresight_ops`). The
> +:code:`**groups` is a list of sysfs entries pertaining to operations
> specific to that component only. "Implementation defined" customisations are
> expected to be accessed and controlled using those entries.
>
> @@ -204,49 +213,56 @@ There is no limit on the amount of sinks (nor sources) that can be enabled at
> any given moment. As a generic operation, all device pertaining to the sink
> class will have an "active" entry in sysfs:
>
> -root:/sys/bus/coresight/devices# ls
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:/sys/bus/coresight/devices# ls 20010000.etb
> -enable_sink status trigger_cntr
> -root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> -root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> -1
> -root:/sys/bus/coresight/devices#
> +.. code:: console
> +
> + root:/sys/bus/coresight/devices# ls
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:/sys/bus/coresight/devices# ls 20010000.etb
> + enable_sink status trigger_cntr
> + root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> + root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> + 1
> + root:/sys/bus/coresight/devices#
>
> At boot time the current etm3x driver will configure the first address
> comparator with "_stext" and "_etext", essentially tracing any instruction
> that falls within that range. As such "enabling" a source will immediately
> trigger a trace capture:
>
> -root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> -1
> -root:/sys/bus/coresight/devices# cat 20010000.etb/status
> -Depth: 0x2000
> -Status: 0x1
> -RAM read ptr: 0x0
> -RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> -Trigger cnt: 0x0
> -Control: 0x1
> -Flush status: 0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> +.. code:: console
> +
> + root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> + 1
> + root:/sys/bus/coresight/devices# cat 20010000.etb/status
> + Depth: 0x2000
> + Status: 0x1
> + RAM read ptr: 0x0
> + RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> + Trigger cnt: 0x0
> + Control: 0x1
> + Flush status: 0x0
> + Flush ctrl: 0x2001
> + root:/sys/bus/coresight/devices#
>
> Trace collection is stopped the same way:
>
> -root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices#
> +.. code:: console
> +
> + root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices#
>
> The content of the ETB buffer can be harvested directly from /dev:
>
> -root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> -of=~/cstrace.bin
> +.. code:: console
>
> -64+0 records in
> -64+0 records out
> -32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> -root:/sys/bus/coresight/devices#
> + root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> + of=~/cstrace.bin
> + 64+0 records in
> + 64+0 records out
> + 32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> + root:/sys/bus/coresight/devices#
>
> The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
>
> @@ -254,55 +270,57 @@ Following is a DS-5 output of an experimental loop that increments a variable up
> to a certain value. The example is simple and yet provides a glimpse of the
> wealth of possibilities that coresight provides.
>
> -Info Tracing enabled
> -Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> -Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> -Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> -Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Timestamp Timestamp: 17106715833
> -Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> -Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> -Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> -Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> -Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> -Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> -Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> -Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> -Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> -Info Tracing enabled
> -Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> -Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> -Timestamp Timestamp: 17107041535
> +.. code:: c
> +
> + Info Tracing enabled
> + Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> + Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> + Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> + Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Timestamp Timestamp: 17106715833
> + Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> + Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> + Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> + Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> + Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> + Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> + Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> + Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> + Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> + Info Tracing enabled
> + Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> + Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> + Timestamp Timestamp: 17107041535
>
> 2) Using perf framework:
>
> @@ -312,6 +330,8 @@ controlling when tracing gets enabled based on when the process of interest is
> scheduled. When configured in a system, Coresight PMUs will be listed when
> queried by the perf command line tool:
>
> +.. code:: console
> +
> linaro@linaro-nano:~$ ./perf list pmu
>
> List of pre-defined events (to be used in -e):
> @@ -329,6 +349,8 @@ Coresight system will typically have more than one sink, the name of the sink to
> work with needs to be specified as an event option. Names for sink to choose
> from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
>
> +.. code:: console
> +
> root@linaro-nano:~# ls /sys/bus/coresight/devices/
> 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> @@ -343,7 +365,7 @@ to use for the trace session.
>
> More information on the above and other example on how to use Coresight with
> the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
> -repository [3].
> +repository [#third]_.
>
> 2.1) AutoFDO analysis using the perf tools:
>
> @@ -352,6 +374,8 @@ perf can be used to record and analyze trace of programs.
> Execution can be recorded using 'perf record' with the cs_etm event,
> specifying the name of the sink to record to, e.g:
>
> +.. code:: console
> +
> perf record -e cs_etm/@20070000.etr/u --per-thread
>
> The 'perf report' and 'perf script' commands can be used to analyze execution,
> @@ -370,12 +394,16 @@ Generating coverage files for Feedback Directed Optimization: AutoFDO
> 'perf inject' accepts the --itrace option in which case tracing data is
> removed and replaced with the synthesized events. e.g.
>
> +.. code:: console
> +
> perf inject --itrace --strip -i perf.data -o perf.data.new
>
> Below is an example of using ARM ETM for autoFDO. It requires autofdo
> (https://github.com/google/autofdo) and gcc version 5. The bubble
> sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
>
> +.. code:: console
> +
> $ gcc-5 -O3 sort.c -o sort
> $ taskset -c 2 ./sort
> Bubble sorting array of 30000 elements
> @@ -403,28 +431,36 @@ difference is that clients are driving the trace capture rather
> than the program flow through the code.
>
> As with any other CoreSight component, specifics about the STM tracer can be
> -found in sysfs with more information on each entry being found in [1]:
> +found in sysfs with more information on each entry being found in [#first]_:
>
> -root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
> -enable_source hwevent_select port_enable subsystem uevent
> -hwevent_enable mgmt port_select traceid
> -root@genericarmv8:~#
> +.. code:: console
> +
> + root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
> + enable_source hwevent_select port_enable subsystem uevent
> + hwevent_enable mgmt port_select traceid
> + root@genericarmv8:~#
>
> Like any other source a sink needs to be identified and the STM enabled before
> being used:
>
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
> +.. code:: console
> +
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
>
> From there user space applications can request and use channels using the devfs
> interface provided for that purpose by the generic STM API:
>
> -root@genericarmv8:~# ls -l /dev/20100000.stm
> -crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
> -root@genericarmv8:~#
> +.. code:: console
> +
> + root@genericarmv8:~# ls -l /dev/20100000.stm
> + crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
> + root@genericarmv8:~#
> +
> +Details on how to use the generic STM API can be found here [#second]_.
> +
> +.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>
> -Details on how to use the generic STM API can be found here [2].
> +.. [#second] Documentation/trace/stm.rst
>
> -[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> -[2]. Documentation/trace/stm.rst
> -[3]. https://github.com/Linaro/perf-opencsd
> +.. [#third] https://github.com/Linaro/perf-opencsd
> diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
> index 6b4107cf4b98..3330c5456bcb 100644
> --- a/Documentation/trace/index.rst
> +++ b/Documentation/trace/index.rst
> @@ -23,3 +23,4 @@ Linux Tracing Technologies
> intel_th
> stm
> sys-t
> + coresight
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH] Documentation: dev-tools: Fixed an outdated directory path in gcov.rst
From: Nick Desaulniers @ 2019-07-08 16:51 UTC (permalink / raw)
To: Jeffrin Jose T, Tri Vo
Cc: Peter Oberparleiter, Jonathan Corbet, linux-doc, LKML,
clang-built-linux
In-Reply-To: <20190705190239.8173-1-jeffrin@rajagiritech.edu.in>
+Tri (on vacation) for review
On Fri, Jul 5, 2019 at 12:03 PM Jeffrin Jose T
<jeffrin@rajagiritech.edu.in> wrote:
>
> Fixed an outdated directory path inside gcov related documentation
> which is part of an example that shows the way in which the gcov
> command should be used in that context
>
> Signed-off-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
> ---
> Documentation/dev-tools/gcov.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst
> index 46aae52a41d0..e3d262d8c7de 100644
> --- a/Documentation/dev-tools/gcov.rst
> +++ b/Documentation/dev-tools/gcov.rst
> @@ -8,7 +8,7 @@ To get coverage data for a specific file, change to the kernel build
> directory and use gcov with the ``-o`` option as follows (requires root)::
>
> # cd /tmp/linux-out
> - # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel spinlock.c
> + # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel/locking spinlock.c
>
> This will create source code files annotated with execution counts
> in the current directory. In addition, graphical gcov front-ends such
> --
> 2.20.1
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20190705190239.8173-1-jeffrin%40rajagiritech.edu.in.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] Documentation: usb: convert usb-help to rst
From: Greg Kroah-Hartman @ 2019-07-08 15:16 UTC (permalink / raw)
To: Phong Tran
Cc: Jonathan Corbet, Shuah Khan, mchehab, linux-kernel-mentees,
linux-usb, linux-doc, linux-kernel
In-Reply-To: <CAD3AR6EN7n5KXnJqW0UdgB_eQjuTedB6KdC8sJ_h+MJNKB6ZmA@mail.gmail.com>
On Mon, Jul 08, 2019 at 10:01:13PM +0700, Phong Tran wrote:
> On Mon, Jul 8, 2019 at 8:52 PM Jonathan Corbet <corbet@lwn.net> wrote:
> >
> > On Sat, 6 Jul 2019 01:55:19 +0700
> > Phong Tran <tranmanphong@gmail.com> wrote:
> >
> > > Add new index.rst and change usb-help.txt format
> > > to rst.
> > >
> > > Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> >
> > Thank you for working to make the kernel's documentation better. That
> > said, I really don't think there is value in keeping this document. It
> > hasn't been updated in any useful way in decades, contains broken links,
> > and the links that still work are full of obsolete information. Honestly,
> > a better patch would, IMO, just delete this file.
> >
> @Jonathan Corbet it's fine to me.
>
> Need ack from you @Greg Kroah-Hartman
> if yes, I will send the cleanup patch.
All of the USB documentation needs a refresh and look again at where it
is and what it contains. After 5.3-rc1 I would recommend doing that (as
that is when all of the recent pending documentation changes will be
merged).
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 35/39] docs: infiniband: add it to the driver-api bookset
From: Jason Gunthorpe @ 2019-07-08 17:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Doug Ledford, linux-rdma
In-Reply-To: <20190706081950.4a629537@coco.lan>
On Sat, Jul 06, 2019 at 08:19:50AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 3 Jul 2019 15:08:02 -0300
> Jason Gunthorpe <jgg@ziepe.ca> escreveu:
>
> > On Fri, Jun 28, 2019 at 09:30:28AM -0300, Mauro Carvalho Chehab wrote:
> > > While this contains some uAPI stuff, it was intended to be
> > > read by a kernel doc. So, let's not move it to a different
> > > dir, but, instead, just add it to the driver-api bookset.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > Documentation/index.rst | 1 +
> > > Documentation/infiniband/index.rst | 2 +-
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > > index ea33cbbccd9d..e69d2fde7735 100644
> > > +++ b/Documentation/index.rst
> > > @@ -96,6 +96,7 @@ needed).
> > > block/index
> > > hid/index
> > > iio/index
> > > + infiniband/index
> > > leds/index
> > > media/index
> > > networking/index
> > > diff --git a/Documentation/infiniband/index.rst b/Documentation/infiniband/index.rst
> > > index 22eea64de722..9cd7615438b9 100644
> > > +++ b/Documentation/infiniband/index.rst
> > > @@ -1,4 +1,4 @@
> > > -:orphan:
> > > +.. SPDX-License-Identifier: GPL-2.0
> > >
> > > ==========
> > > InfiniBand
> >
> > Should this one go to the rdma.git as well? It looks like yes
>
> I'm OK if you want to add to rdma.git. However, this will likely rise
> conflicts, though, as this series has lots of other patches touching
> Documentation/index.rst.
Applied now, it seems better to keep everything consistent
Jason
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-07-08 18:08 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190705201505.GA19023@42.do-not-panic.com>
On Fri, Jul 5, 2019 at 1:15 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > Add core facilities for defining unit tests; this provides a common way
> > to define test cases, functions that execute code which is under test
> > and determine whether the code under test behaves as expected; this also
> > provides a way to group together related test cases in test suites (here
> > we call them test_modules).
> >
> > Just define test cases and how to execute them for now; setting
> > expectations on code will be defined later.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
>
> But a nitpick below, I think that can be fixed later with a follow up
> patch.
>
> > +/**
> > + * struct kunit - represents a running instance of a test.
> > + * @priv: for user to store arbitrary data. Commonly used to pass data created
> > + * in the init function (see &struct kunit_suite).
> > + *
> > + * Used to store information about the current context under which the test is
> > + * running. Most of this data is private and should only be accessed indirectly
> > + * via public functions; the one exception is @priv which can be used by the
> > + * test writer to store arbitrary data.
> > + *
> > + * A brief note on locking:
> > + *
> > + * First off, we need to lock because in certain cases a user may want to use an
> > + * expectation in a thread other than the thread that the test case is running
> > + * in.
>
> This as a prefix to the struct without a lock seems odd. It would be
> clearer I think if you'd explain here what locking mechanism we decided
> to use and why it suffices today.
Whoops, sorry this should have been in the next patch. Will fix.
> > +/**
> > + * suite_test() - used to register a &struct kunit_suite with KUnit.
>
> You mean kunit_test_suite()?
Yep, sorry about that. Will fix.
> > + * @suite: a statically allocated &struct kunit_suite.
> > + *
> > + * Registers @suite with the test framework. See &struct kunit_suite for more
> > + * information.
> > + *
> > + * NOTE: Currently KUnit tests are all run as late_initcalls; this means that
> > + * they cannot test anything where tests must run at a different init phase. One
> > + * significant restriction resulting from this is that KUnit cannot reliably
> > + * test anything that is initialize in the late_init phase.
> initialize prior to the late init phase.
>
>
> That is, this is useless to test things running early.
Yeah, I can add that phrasing in.
> > + *
> > + * TODO(brendanhiggins@google.com): Don't run all KUnit tests as late_initcalls.
> > + * I have some future work planned to dispatch all KUnit tests from the same
> > + * place, and at the very least to do so after everything else is definitely
> > + * initialized.
>
> TODOs are odd to be adding to documentation, this is just not common
> place practice. The NOTE should suffice for you.
Because it is a kernel doc? Would you usually make a separate
non-kernel doc comment for a TODO? I guess that makes sense.
Thanks!
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-07-08 18:12 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190705202051.GB19023@42.do-not-panic.com>
On Fri, Jul 5, 2019 at 1:20 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > +struct kunit {
> > + void *priv;
> > +
> > + /* private: internal use only. */
> > + const char *name; /* Read only after initialization! */
> > + bool success; /* Read only after test_case finishes! */
> > +};
>
> No lock attribute above.
>
> > +void kunit_init_test(struct kunit *test, const char *name)
> > +{
> > + spin_lock_init(&test->lock);
> > + test->name = name;
> > + test->success = true;
> > +}
>
> And yet here you initialize a spin lock... This won't compile. Seems
> you forgot to remove this line. So I guess a re-spin is better.
Oh crap, sorry about that. You can't compile these patches until the
kbuild patch. I will fix this and make sure I didn't make any similar
mistakes on these early patches.
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox