* [PATCH 11/12] Documentation/x86: repointer docs to Documentation/arch/
From: Alex Shi @ 2019-07-12 2:20 UTC (permalink / raw)
To: linux-doc, Jonathan Corbet
Cc: Alex Shi, linux-kernel, linux-stm32, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-omap, linux-fbdev,
linux-samsung-soc, linux-ia64, linux-mips, linux-parisc,
linux-scsi, linux-s390, kvm, linux-sh, Tony Luck, H. Peter Anvin,
x86, Peter Zijlstra, Changbin Du, xen-devel, platform-driver-x86,
virtualization, netdev, linux-security-module
In-Reply-To: <20190712022018.27989-1-alex.shi@linux.alibaba.com>
Since we move Documentation/x86 docs to Documentation/arch/x86
dir, redirect the doc pointer to them.
Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Changbin Du <changbin.du@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: platform-driver-x86@vger.kernel.org
Cc: kvm@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
Documentation/admin-guide/hw-vuln/mds.rst | 2 +-
Documentation/admin-guide/kernel-parameters.rst | 6 +++---
Documentation/admin-guide/kernel-parameters.txt | 8 ++++----
Documentation/admin-guide/ras.rst | 2 +-
Documentation/arch/x86/x86_64/5level-paging.rst | 2 +-
Documentation/arch/x86/x86_64/boot-options.rst | 4 ++--
.../arch/x86/x86_64/fake-numa-for-cpusets.rst | 2 +-
Documentation/devicetree/booting-without-of.txt | 2 +-
Documentation/sysctl/kernel.txt | 4 ++--
MAINTAINERS | 4 ++--
arch/arm/Kconfig | 2 +-
arch/x86/Kconfig | 12 ++++++------
arch/x86/Kconfig.debug | 2 +-
| 2 +-
arch/x86/entry/entry_64.S | 2 +-
arch/x86/include/asm/bootparam_utils.h | 2 +-
arch/x86/include/asm/page_64_types.h | 2 +-
arch/x86/include/asm/pgtable_64_types.h | 2 +-
arch/x86/kernel/cpu/microcode/amd.c | 2 +-
arch/x86/kernel/kexec-bzimage64.c | 2 +-
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/mm/tlb.c | 2 +-
arch/x86/platform/pvh/enlighten.c | 2 +-
drivers/vhost/vhost.c | 2 +-
security/Kconfig | 2 +-
tools/include/linux/err.h | 2 +-
tools/objtool/Documentation/stack-validation.txt | 4 ++--
27 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
index e3a796c0d3a2..303228380fdc 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -58,7 +58,7 @@ Because the buffers are potentially shared between Hyper-Threads cross
Hyper-Thread attacks are possible.
Deeper technical information is available in the MDS specific x86
-architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
+architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`.
Attack scenarios
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index dc283dcffae8..7c32484811c8 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -167,7 +167,7 @@ parameter is applicable::
X86-32 X86-32, aka i386 architecture is enabled.
X86-64 X86-64 architecture is enabled.
More X86-64 boot options can be found in
- Documentation/x86/x86_64/boot-options.rst.
+ Documentation/arch/x86/x86_64/boot-options.rst.
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
X86_UV SGI UV support is enabled.
XEN Xen support is enabled
@@ -181,10 +181,10 @@ In addition, the following text indicates that the option::
Parameters denoted with BOOT are actually interpreted by the boot
loader, and have no meaning to the kernel directly.
Do not modify the syntax of boot loader parameters without extreme
-need or coordination with <Documentation/x86/boot.rst>.
+need or coordination with <Documentation/arch/x86/boot.rst>.
There are also arch-specific kernel-parameters not documented here.
-See for example <Documentation/x86/x86_64/boot-options.rst>.
+See for example <Documentation/arch/x86/x86_64/boot-options.rst>.
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4ceb4691245b..d9eb5895ea9e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -963,7 +963,7 @@
for details.
nompx [X86] Disables Intel Memory Protection Extensions.
- See Documentation/x86/intel_mpx.rst for more
+ See Documentation/arch/x86/intel_mpx.rst for more
information about the feature.
nopku [X86] Disable Memory Protection Keys CPU feature found
@@ -2380,7 +2380,7 @@
mce [X86-32] Machine Check Exception
- mce=option [X86-64] See Documentation/x86/x86_64/boot-options.rst
+ mce=option [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst
md= [HW] RAID subsystems devices and level
See Documentation/admin-guide/md.rst.
@@ -3526,7 +3526,7 @@
See Documentation/blockdev/paride.txt.
pirq= [SMP,APIC] Manual mp-table setup
- See Documentation/x86/i386/IO-APIC.rst.
+ See Documentation/arch/x86/i386/IO-APIC.rst.
plip= [PPT,NET] Parallel port network link
Format: { parport<nr> | timid | 0 }
@@ -5058,7 +5058,7 @@
Can be used multiple times for multiple devices.
vga= [BOOT,X86-32] Select a particular video mode
- See Documentation/x86/boot.rst and
+ See Documentation/arch/x86/boot.rst and
Documentation/svga.txt.
Use vga=ask for menu.
This is actually a boot loader parameter; the value is
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 2b20f5f7380d..2d86862458aa 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_.
mode).
.. [#f3] For more details about the Machine Check Architecture (MCA),
- please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
+ please read Documentation/arch/x86/x86_64/machinecheck.rst at the Kernel tree.
EDAC - Error Detection And Correction
*************************************
diff --git a/Documentation/arch/x86/x86_64/5level-paging.rst b/Documentation/arch/x86/x86_64/5level-paging.rst
index 44856417e6a5..000809878403 100644
--- a/Documentation/arch/x86/x86_64/5level-paging.rst
+++ b/Documentation/arch/x86/x86_64/5level-paging.rst
@@ -20,7 +20,7 @@ physical address space. This "ought to be enough for anybody" ©.
QEMU 2.9 and later support 5-level paging.
Virtual memory layout for 5-level paging is described in
-Documentation/x86/x86_64/mm.rst
+Documentation/arch/x86/x86_64/mm.rst
Enabling 5-level paging
diff --git a/Documentation/arch/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst
index 6a4285a3c7a4..2a093128b28f 100644
--- a/Documentation/arch/x86/x86_64/boot-options.rst
+++ b/Documentation/arch/x86/x86_64/boot-options.rst
@@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here.
Machine check
=============
-Please see Documentation/x86/x86_64/machinecheck.rst for sysfs runtime tunables.
+Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables.
mce=off
Disable machine check
@@ -89,7 +89,7 @@ APICs
Don't use the local APIC (alias for i386 compatibility)
pirq=...
- See Documentation/x86/i386/IO-APIC.rst
+ See Documentation/arch/x86/i386/IO-APIC.rst
noapictimer
Don't set up the APIC timer
diff --git a/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst
index 30108684ae87..d960f5cac258 100644
--- a/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst
+++ b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst
@@ -18,7 +18,7 @@ For more information on the features of cpusets, see
Documentation/cgroup-v1/cpusets.rst.
There are a number of different configurations you can use for your needs. For
more information on the numa=fake command line option and its various ways of
-configuring fake nodes, see Documentation/x86/x86_64/boot-options.rst.
+configuring fake nodes, see Documentation/arch/x86/x86_64/boot-options.rst.
For the purposes of this introduction, we'll assume a very primitive NUMA
emulation setup of "numa=fake=4*512,". This will split our system memory into
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 58d606fca7eb..066778cbbdcb 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -277,7 +277,7 @@ it with special cases.
the decompressor (the real mode entry point goes to the same 32bit
entry point once it switched into protected mode). That entry point
supports one calling convention which is documented in
- Documentation/x86/boot.rst
+ Documentation/arch/x86/boot.rst
The physical pointer to the device-tree block (defined in chapter II)
is passed via setup_data which requires at least boot protocol 2.09.
The type filed is defined as
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 1b2fe17cd2fa..b3e3c56bdab8 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -154,7 +154,7 @@ is 0x15 and the full version number is 0x234, this file will contain
the value 340 = 0x154.
See the type_of_loader and ext_loader_type fields in
-Documentation/x86/boot.rst for additional information.
+Documentation/arch/x86/boot.rst for additional information.
==============================================================
@@ -166,7 +166,7 @@ The complete bootloader version number. In the example above, this
file will contain the value 564 = 0x234.
See the type_of_loader and ext_loader_ver fields in
-Documentation/x86/boot.rst for additional information.
+Documentation/arch/x86/boot.rst for additional information.
==============================================================
diff --git a/MAINTAINERS b/MAINTAINERS
index 84448d5838b7..e1aa61c72cb1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13351,7 +13351,7 @@ L: linux-kernel@vger.kernel.org
S: Supported
F: arch/x86/kernel/cpu/resctrl/
F: arch/x86/include/asm/resctrl_sched.h
-F: Documentation/x86/resctrl*
+F: Documentation/arch/x86/resctrl*
READ-COPY UPDATE (RCU)
M: "Paul E. McKenney" <paulmck@linux.ibm.com>
@@ -17258,7 +17258,7 @@ L: linux-kernel@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
S: Maintained
F: Documentation/devicetree/bindings/x86/
-F: Documentation/x86/
+F: Documentation/arch/x86/
F: arch/x86/
X86 ENTRY CODE
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1b276dda837d..b2b8d3c15285 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1293,7 +1293,7 @@ config SMP
uniprocessor machines. On a uniprocessor machine, the kernel
will run faster if you say N here.
- See also <file:Documentation/x86/i386/IO-APIC.rst>,
+ See also <file:Documentation/arch/x86/i386/IO-APIC.rst>,
<file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO available at
<http://tldp.org/HOWTO/SMP-HOWTO.html>.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dce10b18f4bc..5489f42e005e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -399,7 +399,7 @@ config SMP
Y to "Enhanced Real Time Clock Support", below. The "Advanced Power
Management" code will be disabled if you say Y here.
- See also <file:Documentation/x86/i386/IO-APIC.rst>,
+ See also <file:Documentation/arch/x86/i386/IO-APIC.rst>,
<file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO available at
<http://www.tldp.org/docs.html#howto>.
@@ -1308,7 +1308,7 @@ config MICROCODE
the Linux kernel.
The preferred method to load microcode from a detached initrd is described
- in Documentation/x86/microcode.rst. For that you need to enable
+ in Documentation/arch/x86/microcode.rst. For that you need to enable
CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the
initrd for microcode blobs.
@@ -1347,7 +1347,7 @@ config MICROCODE_OLD_INTERFACE
It is inadequate because it runs too late to be able to properly
load microcode on a machine and it needs special tools. Instead, you
should've switched to the early loading method with the initrd or
- builtin microcode by now: Documentation/x86/microcode.rst
+ builtin microcode by now: Documentation/arch/x86/microcode.rst
config X86_MSR
tristate "/dev/cpu/*/msr - Model-specific register support"
@@ -1496,7 +1496,7 @@ config X86_5LEVEL
A kernel with the option enabled can be booted on machines that
support 4- or 5-level paging.
- See Documentation/x86/x86_64/5level-paging.rst for more
+ See Documentation/arch/x86/x86_64/5level-paging.rst for more
information.
Say N if unsure.
@@ -1801,7 +1801,7 @@ config MTRR
You can safely say Y even if your machine doesn't have MTRRs, you'll
just add about 9 KB to your kernel.
- See <file:Documentation/x86/mtrr.rst> for more information.
+ See <file:Documentation/arch/x86/mtrr.rst> for more information.
config MTRR_SANITIZER
def_bool y
@@ -1913,7 +1913,7 @@ config X86_INTEL_MPX
process and adds some branches to paths used during
exec() and munmap().
- For details, see Documentation/x86/intel_mpx.rst
+ For details, see Documentation/arch/x86/intel_mpx.rst
If unsure, say N.
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 71c92db47c41..814353667075 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -156,7 +156,7 @@ config IOMMU_DEBUG
code. When you use it make sure you have a big enough
IOMMU/AGP aperture. Most of the options enabled by this can
be set more finegrained using the iommu= command line
- options. See Documentation/x86/x86_64/boot-options.rst for more
+ options. See Documentation/arch/x86/x86_64/boot-options.rst for more
details.
config IOMMU_LEAK
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2c11c0f45d49..5ec825c863a6 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -313,7 +313,7 @@ start_sys_seg: .word SYSSEG # obsolete and meaningless, but just
type_of_loader: .byte 0 # 0 means ancient bootloader, newer
# bootloaders know to change this.
- # See Documentation/x86/boot.rst for
+ # See Documentation/arch/x86/boot.rst for
# assigned ids
# flags, unused bits must be zero (RFU) bit within loadflags
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 0ea4831a72a4..981951124d53 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -8,7 +8,7 @@
*
* entry.S contains the system-call and fault low-level handling routines.
*
- * Some of this is documented in Documentation/x86/entry_64.rst
+ * Some of this is documented in Documentation/arch/x86/entry_64.rst
*
* A note on terminology:
* - iret frame: Architecture defined interrupt frame from SS to RIP
diff --git a/arch/x86/include/asm/bootparam_utils.h b/arch/x86/include/asm/bootparam_utils.h
index 101eb944f13c..585daca7682b 100644
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -24,7 +24,7 @@ static void sanitize_boot_params(struct boot_params *boot_params)
* IMPORTANT NOTE TO BOOTLOADER AUTHORS: do not simply clear
* this field. The purpose of this field is to guarantee
* compliance with the x86 boot spec located in
- * Documentation/x86/boot.rst . That spec says that the
+ * Documentation/arch/x86/boot.rst . That spec says that the
* *whole* structure should be cleared, after which only the
* portion defined by struct setup_header (boot_params->hdr)
* should be copied in.
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 288b065955b7..70d71bdd77da 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -48,7 +48,7 @@
#define __START_KERNEL_map _AC(0xffffffff80000000, UL)
-/* See Documentation/x86/x86_64/mm.rst for a description of the memory map. */
+/* See Documentation/arch/x86/x86_64/mm.rst for a description of the memory map. */
#define __PHYSICAL_MASK_SHIFT 52
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 52e5f5f2240d..ec3fe348bbd4 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d;
#define PGDIR_MASK (~(PGDIR_SIZE - 1))
/*
- * See Documentation/x86/x86_64/mm.rst for a description of the memory map.
+ * See Documentation/arch/x86/x86_64/mm.rst for a description of the memory map.
*
* Be very careful vs. KASLR when changing anything here. The KASLR address
* range must not overlap with anything except the KASAN shadow area, which
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index a0e52bd00ecc..146374651036 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -59,7 +59,7 @@ static u8 amd_ucode_patch[PATCH_MAX_SIZE];
/*
* Microcode patch container file is prepended to the initrd in cpio
- * format. See Documentation/x86/microcode.rst
+ * format. See Documentation/arch/x86/microcode.rst
*/
static const char
ucode_path[] __maybe_unused = "kernel/x86/microcode/AuthenticAMD.bin";
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 5ebcd02cbca7..108d72bcfa28 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -419,7 +419,7 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
efi_map_offset = params_cmdline_sz;
efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
- /* Copy setup header onto bootparams. Documentation/x86/boot.rst */
+ /* Copy setup header onto bootparams. Documentation/arch/x86/boot.rst */
setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;
/* Is there a limit on setup header size? */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index f62b498b18fb..a34c72e924ec 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -70,7 +70,7 @@ void __init pci_iommu_alloc(void)
}
/*
- * See <Documentation/x86/x86_64/boot-options.rst> for the iommu kernel
+ * See <Documentation/arch/x86/x86_64/boot-options.rst> for the iommu kernel
* parameter documentation.
*/
static __init int iommu_setup(char *p)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 4de9704c4aaf..855498ab4453 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -712,7 +712,7 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
}
/*
- * See Documentation/x86/tlb.rst for details. We choose 33
+ * See Documentation/arch/x86/tlb.rst for details. We choose 33
* because it is large enough to cover the vast majority (at
* least 95%) of allocations, and is small enough that we are
* confident it will not cause too much overhead. Each single
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index c0a502f7e3a7..15a74dbc9b00 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -86,7 +86,7 @@ static void __init init_pvh_bootparams(bool xen_guest)
}
/*
- * See Documentation/x86/boot.rst.
+ * See Documentation/arch/x86/boot.rst.
*
* Version 2.12 supports Xen entry point but we will use default x86/PC
* environment (i.e. hardware_subarch 0).
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index ff8892c38666..f5c1868d5d5f 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1711,7 +1711,7 @@ EXPORT_SYMBOL_GPL(vhost_dev_ioctl);
/* TODO: This is really inefficient. We need something like get_user()
* (instruction directly accesses the data, with an exception table entry
- * returning -EFAULT). See Documentation/x86/exception-tables.rst.
+ * returning -EFAULT). See Documentation/arch/x86/exception-tables.rst.
*/
static int set_bit_to_user(int nr, void __user *addr)
{
diff --git a/security/Kconfig b/security/Kconfig
index 06a30851511a..d26d9f205441 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -63,7 +63,7 @@ config PAGE_TABLE_ISOLATION
ensuring that the majority of kernel addresses are not mapped
into userspace.
- See Documentation/x86/pti.rst for more details.
+ See Documentation/arch/x86/pti.rst for more details.
config SECURITY_INFINIBAND
bool "Infiniband Security Hooks"
diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
index 25f2bb3a991d..332b983ead1e 100644
--- a/tools/include/linux/err.h
+++ b/tools/include/linux/err.h
@@ -20,7 +20,7 @@
* Userspace note:
* The same principle works for userspace, because 'error' pointers
* fall down to the unused hole far from user space, as described
- * in Documentation/x86/x86_64/mm.rst for x86_64 arch:
+ * in Documentation/arch/x86/x86_64/mm.rst for x86_64 arch:
*
* 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [48:63] sign extension
* ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/stack-validation.txt
index de094670050b..87b6b4d1175a 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -21,7 +21,7 @@ instructions). Similarly, it knows how to follow switch statements, for
which gcc sometimes uses jump tables.
(Objtool also has an 'orc generate' subcommand which generates debuginfo
-for the ORC unwinder. See Documentation/x86/orc-unwinder.rst in the
+for the ORC unwinder. See Documentation/arch/x86/orc-unwinder.rst in the
kernel tree for more details.)
@@ -101,7 +101,7 @@ b) ORC (Oops Rewind Capability) unwind table generation
band. So it doesn't affect runtime performance and it can be
reliable even when interrupts or exceptions are involved.
- For more details, see Documentation/x86/orc-unwinder.rst.
+ For more details, see Documentation/arch/x86/orc-unwinder.rst.
c) Higher live patching compatibility rate
--
2.19.1.856.g8858448bb
^ permalink raw reply related
* [PATCH 09/12] Dcumentation/sh: repointer docs to Documentation/arch/
From: Alex Shi @ 2019-07-12 2:20 UTC (permalink / raw)
To: linux-doc, Jonathan Corbet
Cc: Alex Shi, linux-kernel, linux-stm32, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-omap, linux-fbdev,
linux-samsung-soc, linux-ia64, linux-mips, linux-parisc,
linux-scsi, linux-s390, kvm, linux-sh
In-Reply-To: <20190712022018.27989-1-alex.shi@linux.alibaba.com>
Since we move Documentation/sh docs to Documentation/arch/sh
dir, redirect the doc pointer to them.
Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-sh@vger.kernel.org
---
Documentation/conf.py | 2 +-
MAINTAINERS | 2 +-
arch/sh/Kconfig.cpu | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 3b2397bcb565..8bbe421c1d97 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -402,7 +402,7 @@ latex_documents = [
'The kernel development community', 'manual'),
('security/index', 'security.tex', 'The kernel security subsystem manual',
'The kernel development community', 'manual'),
- ('sh/index', 'sh.tex', 'SuperH architecture implementation manual',
+ ('arch/sh/index', 'sh.tex', 'SuperH architecture implementation manual',
'The kernel development community', 'manual'),
('sound/index', 'sound.tex', 'Linux Sound Subsystem Documentation',
'The kernel development community', 'manual'),
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a245d3f02fd..84448d5838b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15169,7 +15169,7 @@ M: Rich Felker <dalias@libc.org>
L: linux-sh@vger.kernel.org
Q: http://patchwork.kernel.org/project/linux-sh/list/
S: Maintained
-F: Documentation/sh/
+F: Documentation/arch/sh/
F: arch/sh/
F: drivers/sh/
diff --git a/arch/sh/Kconfig.cpu b/arch/sh/Kconfig.cpu
index 4a4edc7e03d4..fdc8b565241b 100644
--- a/arch/sh/Kconfig.cpu
+++ b/arch/sh/Kconfig.cpu
@@ -94,7 +94,7 @@ config CPU_HAS_SR_RB
that are lacking this bit must have another method in place for
accomplishing what is taken care of by the banked registers.
- See <file:Documentation/sh/register-banks.txt> for further
+ See <file:Documentation/arch/sh/register-banks.txt> for further
information on SR.RB and register banking in the kernel in general.
config CPU_HAS_PTEAEX
--
2.19.1.856.g8858448bb
^ permalink raw reply related
* [PATCH 03/12] Documentation/ia64: repointer docs to Documentation/arch/ia64
From: Alex Shi @ 2019-07-12 2:20 UTC (permalink / raw)
To: linux-doc, Jonathan Corbet
Cc: Alex Shi, linux-kernel, linux-stm32, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-omap, linux-fbdev,
linux-samsung-soc, linux-ia64, linux-mips, linux-parisc,
linux-scsi, linux-s390, kvm, linux-sh, Ard Biesheuvel, Tony Luck,
Fenghua Yu
In-Reply-To: <20190712022018.27989-1-alex.shi@linux.alibaba.com>
Since we move 'ia64' docs to Documentation/arch/ia64 dir,
redirect the doc pointer to them.
Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-ia64@vger.kernel.org
---
MAINTAINERS | 2 +-
arch/ia64/kernel/efi.c | 2 +-
arch/ia64/kernel/fsys.S | 2 +-
arch/ia64/mm/ioremap.c | 2 +-
arch/ia64/pci/pci.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c21d5464c86f..583c35cba7bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14286,7 +14286,7 @@ SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
M: Pat Gefre <pfg@sgi.com>
L: linux-ia64@vger.kernel.org
S: Supported
-F: Documentation/ia64/serial.txt
+F: Documentation/arch/ia64/serial.txt
F: drivers/tty/serial/ioc?_serial.c
F: include/linux/ioc?.h
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 8f106638913c..02cdc38d15e8 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -852,7 +852,7 @@ valid_phys_addr_range (phys_addr_t phys_addr, unsigned long size)
* /dev/mem reads and writes use copy_to_user(), which implicitly
* uses a granule-sized kernel identity mapping. It's really
* only safe to do this for regions in kern_memmap. For more
- * details, see Documentation/ia64/aliasing.txt.
+ * details, see Documentation/arch/ia64/aliasing.txt.
*/
attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB || attr & EFI_MEMORY_UC)
diff --git a/arch/ia64/kernel/fsys.S b/arch/ia64/kernel/fsys.S
index d80c99a5f55d..b493ca74890a 100644
--- a/arch/ia64/kernel/fsys.S
+++ b/arch/ia64/kernel/fsys.S
@@ -28,7 +28,7 @@
#include <asm/native/inst.h>
/*
- * See Documentation/ia64/fsys.txt for details on fsyscalls.
+ * See Documentation/arch/ia64/fsys.txt for details on fsyscalls.
*
* On entry to an fsyscall handler:
* r10 = 0 (i.e., defaults to "successful syscall return")
diff --git a/arch/ia64/mm/ioremap.c b/arch/ia64/mm/ioremap.c
index 5e3e7b1fdac5..989cc4df9087 100644
--- a/arch/ia64/mm/ioremap.c
+++ b/arch/ia64/mm/ioremap.c
@@ -42,7 +42,7 @@ ioremap (unsigned long phys_addr, unsigned long size)
/*
* For things in kern_memmap, we must use the same attribute
* as the rest of the kernel. For more details, see
- * Documentation/ia64/aliasing.txt.
+ * Documentation/arch/ia64/aliasing.txt.
*/
attr = kern_mem_attribute(phys_addr, size);
if (attr & EFI_MEMORY_WB)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index e308196c2229..6ba87b70e30c 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -450,7 +450,7 @@ pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma,
return -ENOSYS;
/*
- * Avoid attribute aliasing. See Documentation/ia64/aliasing.txt
+ * Avoid attribute aliasing. See Documentation/arch/ia64/aliasing.txt
* for more details.
*/
if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
--
2.19.1.856.g8858448bb
^ permalink raw reply related
* Re: [PATCH v4] RISC-V: Add an Image header that boot loader can parse.
From: Atish Patra @ 2019-07-11 21:42 UTC (permalink / raw)
To: paul.walmsley@sifive.com
Cc: corbet@lwn.net, mick@ics.forth.gr, palmer@sifive.com,
trini@konsulko.com, aou@eecs.berkeley.edu,
linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, linux-doc@vger.kernel.org,
marek.vasut@gmail.com, Anup Patel, mark.rutland@arm.com,
merker@debian.org, khilman@baylibre.com,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
In-Reply-To: <alpine.DEB.2.21.9999.1907111237520.8586@viisi.sifive.com>
On Thu, 2019-07-11 at 12:42 -0700, Paul Walmsley wrote:
> On Fri, 28 Jun 2019, Atish Patra wrote:
>
> > On Fri, 2019-06-28 at 12:09 -0700, Paul Walmsley wrote:
> > > On Thu, 6 Jun 2019, Atish Patra wrote:
> > >
> > > > Currently, the last stage boot loaders such as U-Boot can
> > > > accept
> > > > only
> > > > uImage which is an unnecessary additional step in automating
> > > > boot
> > > > process.
> > > >
> > > > Add an image header that boot loader understands and boot Linux
> > > > from
> > > > flat Image directly.
> > >
> > > ...
> > >
> > >
> > > > +#if __riscv_xlen == 64
> > > > + /* Image load offset(2MB) from start of RAM */
> > > > + .dword 0x200000
> > > > +#else
> > > > + /* Image load offset(4MB) from start of RAM */
> > > > + .dword 0x400000
> > > > +#endif
> > >
> > > Is there a rationale behind these load offset values?
> > >
> >
> > 2MB/4MB alignment requirement is mandatory for current RISC-V
> > kernel.
> > Anup had a patch that tried to remove that but not accepted yet.
> >
> > https://patchwork.kernel.org/patch/10868465/
>
> Thanks for doing this work; this should really help. Patch queued
> with a
> few minor tweaks to the documentation file and to the
> comments. (Updated
> patch below)
>
Thank you!
> Not sure if this will make it for v5.3-rc1. If not, we'll try to get
> it
> in as soon as possible afterwards.
>
> Something else to think about: we'll probably want some flag bits
> soon to
> identify whether the kernel binary is a 32-bit, 64-bit, or 128-bit
> binary.
> If two bits are used, and 64-bit is defined as 00, then it should be
> backwards compatible. I would hope that this could be something that
> we'd
> be able to coordinate with the ARM64 folks also;
Sure. We can always any bits from 4-64 (reserved in ARM header). That
will still allow the ARM64/RISC-V headers to merge in future if ARM
maintainers are interested.
> otherwise we may need to
> start using that res3 field.
>
>
> - Paul
>
> From: Atish Patra <atish.patra@wdc.com>
> Date: Thu, 6 Jun 2019 16:08:00 -0700
> Subject: [PATCH] RISC-V: Add an Image header that boot loader can
> parse.
>
> Currently, the last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot
> process.
>
> Add an image header that boot loader understands and boot Linux from
> flat Image directly.
>
> This header is based on ARM64 boot image header and provides an
> opportunity to combine both ARM64 & RISC-V image headers in future.
>
> Also make sure that PE/COFF header can co-exist in the same image so
> that EFI stub can be supported for RISC-V in future. EFI
> specification
> needs PE/COFF image header in the beginning of the kernel image in
> order
> to load it as an EFI application. In order to support EFI stub, code0
> should be replaced with "MZ" magic string and res4(at offset 0x3c)
> should point to the rest of the PE/COFF header (which will be added
> during EFI support).
>
> Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot +
> Linux.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Karsten Merker <merker@debian.org>
> Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
> Tested-by: Kevin Hilman <khilman@baylibre.com> (OpenSBI + U-Boot +
> Linux)
> [paul.walmsley@sifive.com: fixed whitespace in boot-image-header.txt;
> converted structure comment to kernel-doc format and added some
> detail]
> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
> ---
> Documentation/riscv/boot-image-header.txt | 50 +++++++++++++++++
> arch/riscv/include/asm/image.h | 65
> +++++++++++++++++++++++
> arch/riscv/kernel/head.S | 32 +++++++++++
> 3 files changed, 147 insertions(+)
> create mode 100644 Documentation/riscv/boot-image-header.txt
> create mode 100644 arch/riscv/include/asm/image.h
>
> diff --git a/Documentation/riscv/boot-image-header.txt
> b/Documentation/riscv/boot-image-header.txt
> new file mode 100644
> index 000000000000..1b73fea23b39
> --- /dev/null
> +++ b/Documentation/riscv/boot-image-header.txt
> @@ -0,0 +1,50 @@
> + Boot image header in RISC-V Linux
> + =============================================
> +
> +Author: Atish Patra <atish.patra@wdc.com>
> +Date : 20 May 2019
> +
> +This document only describes the boot image header details for RISC-
> V Linux.
> +The complete booting guide will be available at
> Documentation/riscv/booting.txt.
> +
> +The following 64-byte header is present in decompressed Linux kernel
> image.
> +
> + u32 code0; /* Executable code */
> + u32 code1; /* Executable code */
> + u64 text_offset; /* Image load offset, little endian */
> + u64 image_size; /* Effective Image size, little
> endian */
> + u64 flags; /* kernel flags, little endian */
> + u32 version; /* Version of this header */
> + u32 res1 = 0; /* Reserved */
> + u64 res2 = 0; /* Reserved */
> + u64 magic = 0x5643534952; /* Magic number, little endian,
> "RISCV" */
> + u32 res3; /* Reserved for additional RISC-V specific
> header */
> + u32 res4; /* Reserved for PE COFF offset */
> +
> +This header format is compliant with PE/COFF header and largely
> inspired from
> +ARM64 header. Thus, both ARM64 & RISC-V header can be combined into
> one common
> +header in future.
> +
> +Notes:
> +- This header can also be reused to support EFI stub for RISC-V in
> future. EFI
> + specification needs PE/COFF image header in the beginning of the
> kernel image
> + in order to load it as an EFI application. In order to support EFI
> stub,
> + code0 should be replaced with "MZ" magic string and res5(at offset
> 0x3c) should
> + point to the rest of the PE/COFF header.
> +
> +- version field indicate header version number.
> + Bits 0:15 - Minor version
> + Bits 16:31 - Major version
> +
> + This preserves compatibility across newer and older version of the
> header.
> + The current version is defined as 0.1.
> +
> +- res3 is reserved for offset to any other additional fields. This
> makes the
> + header extendible in future. One example would be to accommodate
> ISA
> + extension for RISC-V in future. For current version, it is set to
> be zero.
> +
> +- In current header, the flag field has only one field.
> + Bit 0: Kernel endianness. 1 if BE, 0 if LE.
> +
> +- Image size is mandatory for boot loader to load kernel image.
> Booting will
> + fail otherwise.
> diff --git a/arch/riscv/include/asm/image.h
> b/arch/riscv/include/asm/image.h
> new file mode 100644
> index 000000000000..ef28e106f247
> --- /dev/null
> +++ b/arch/riscv/include/asm/image.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __ASM_IMAGE_H
> +#define __ASM_IMAGE_H
> +
> +#define RISCV_IMAGE_MAGIC "RISCV"
> +
> +#define RISCV_IMAGE_FLAG_BE_SHIFT 0
> +#define RISCV_IMAGE_FLAG_BE_MASK 0x1
> +
> +#define RISCV_IMAGE_FLAG_LE 0
> +#define RISCV_IMAGE_FLAG_BE 1
> +
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +#error conversion of header fields to LE not yet implemented
> +#else
> +#define __HEAD_FLAG_BE RISCV_IMAGE_FLAG_LE
> +#endif
> +
> +#define __HEAD_FLAG(field) (__HEAD_FLAG_##field << \
> + RISCV_IMAGE_FLAG_##field##_SHIFT)
> +
> +#define __HEAD_FLAGS (__HEAD_FLAG(BE))
> +
> +#define RISCV_HEADER_VERSION_MAJOR 0
> +#define RISCV_HEADER_VERSION_MINOR 1
> +
> +#define RISCV_HEADER_VERSION (RISCV_HEADER_VERSION_MAJOR << 16 | \
> + RISCV_HEADER_VERSION_MINOR)
> +
> +#ifndef __ASSEMBLY__
> +/**
> + * struct riscv_image_header - riscv kernel image header
> + * @code0: Executable code
> + * @code1: Executable code
> + * @text_offset: Image load offset (little endian)
> + * @image_size: Effective Image size (little endian)
> + * @flags: kernel flags (little endian)
> + * @version: version
> + * @res1: reserved
> + * @res2: reserved
> + * @magic: Magic number
> + * @res3: reserved (will be used for additional RISC-V
> specific
> + * header)
> + * @res4: reserved (will be used for PE COFF offset)
> + *
> + * The intention is for this header format to be shared between
> multiple
> + * architectures to avoid a proliferation of image header formats.
> + */
> +
> +struct riscv_image_header {
> + u32 code0;
> + u32 code1;
> + u64 text_offset;
> + u64 image_size;
> + u64 flags;
> + u32 version;
> + u32 res1;
> + u64 res2;
> + u64 magic;
> + u32 res3;
> + u32 res4;
> +};
> +#endif /* __ASSEMBLY__ */
> +#endif /* __ASM_IMAGE_H */
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index e368106f2228..0f1ba17e476f 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -11,9 +11,41 @@
> #include <asm/thread_info.h>
> #include <asm/page.h>
> #include <asm/csr.h>
> +#include <asm/image.h>
>
> __INIT
> ENTRY(_start)
> + /*
> + * Image header expected by Linux boot-loaders. The image
> header data
> + * structure is described in asm/image.h.
> + * Do not modify it without modifying the structure and all
> bootloaders
> + * that expects this header format!!
> + */
> + /* jump to start kernel */
> + j _start_kernel
> + /* reserved */
> + .word 0
> + .balign 8
> +#if __riscv_xlen == 64
> + /* Image load offset(2MB) from start of RAM */
> + .dword 0x200000
> +#else
> + /* Image load offset(4MB) from start of RAM */
> + .dword 0x400000
> +#endif
> + /* Effective size of kernel image */
> + .dword _end - _start
> + .dword __HEAD_FLAGS
> + .word RISCV_HEADER_VERSION
> + .word 0
> + .dword 0
> + .asciz RISCV_IMAGE_MAGIC
> + .word 0
> + .balign 4
> + .word 0
> +
> +.global _start_kernel
> +_start_kernel:
> /* Mask all interrupts */
> csrw CSR_SIE, zero
> csrw CSR_SIP, zero
--
Regards,
Atish
^ permalink raw reply
* Re: [PATCH] treewide: Rename rcu_dereference_raw_notrace to _check
From: Joel Fernandes @ 2019-07-11 20:50 UTC (permalink / raw)
To: LKML
Cc: Benjamin Herrenschmidt, Ingo Molnar, Jonathan Corbet,
Josh Triplett, kvm-ppc, Lai Jiangshan, open list:DOCUMENTATION,
PowerPC, Mathieu Desnoyers, Michael Ellerman, Paul E. McKenney,
Paul Mackerras, rcu, Steven Rostedt, Byungchul Park, kernel-team
In-Reply-To: <20190711204541.28940-1-joel@joelfernandes.org>
On Thu, Jul 11, 2019 at 4:45 PM Joel Fernandes (Google)
<joel@joelfernandes.org> wrote:
>
> The rcu_dereference_raw_notrace() API name is confusing.
> It is equivalent to rcu_dereference_raw() except that it also does
> sparse pointer checking.
>
> There are only a few users of rcu_dereference_raw_notrace(). This
> patches renames all of them to be rcu_dereference_raw_check with the
> "check" indicating sparse checking.
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
There also these _notrace things but I am Ok with leaving them alone for now:
hash_for_each_possible_rcu_notrace
hlist_for_each_entry_rcu_notrace
- Joel
^ permalink raw reply
* [PATCH 2/2] f2fs: Support case-insensitive file name lookups
From: Daniel Rosenberg @ 2019-07-11 20:45 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
In-Reply-To: <20190711204556.120381-1-drosen@google.com>
Modeled after commit b886ee3e778e ("ext4: Support case-insensitive file
name lookups")
"""
This patch implements the actual support for case-insensitive file name
lookups in f2fs, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is able to configure
directories with the +F (F2FS_CASEFOLD_FL) attribute, enabling lookups
to succeed in that directory in a case-insensitive fashion, i.e: match
a directory entry even if the name used by userspace is not a byte per
byte match with the disk name, but is an equivalent case-insensitive
version of the Unicode string. This operation is called a
case-insensitive file name lookup.
The feature is configured as an inode attribute applied to directories
and inherited by its children. This attribute can only be enabled on
empty directories for filesystems that support the encoding feature,
thus preventing collision of file names that only differ by case.
* dcache handling:
For a +F directory, F2Fs only stores the first equivalent name dentry
used in the dcache. This is done to prevent unintentional duplication of
dentries in the dcache, while also allowing the VFS code to quickly find
the right entry in the cache despite which equivalent string was used in
a previous lookup, without having to resort to ->lookup().
d_hash() of casefolded directories is implemented as the hash of the
casefolded string, such that we always have a well-known bucket for all
the equivalencies of the same string. d_compare() uses the
utf8_strncasecmp() infrastructure, which handles the comparison of
equivalent, same case, names as well.
For now, negative lookups are not inserted in the dcache, since they
would need to be invalidated anyway, because we can't trust missing file
dentries. This is bad for performance but requires some leveraging of
the vfs layer to fix. We can live without that for now, and so does
everyone else.
* on-disk data:
Despite using a specific version of the name as the internal
representation within the dcache, the name stored and fetched from the
disk is a byte-per-byte match with what the user requested, making this
implementation 'name-preserving'. i.e. no actual information is lost
when writing to storage.
DX is supported by modifying the hashes used in +F directories to make
them case/encoding-aware. The new disk hashes are calculated as the
hash of the full casefolded string, instead of the string directly.
This allows us to efficiently search for file names in the htree without
requiring the user to provide an exact name.
* Dealing with invalid sequences:
By default, when a invalid UTF-8 sequence is identified, ext4 will treat
it as an opaque byte sequence, ignoring the encoding and reverting to
the old behavior for that unique file. This means that case-insensitive
file name lookup will not work only for that file. An optional bit can
be set in the superblock telling the filesystem code and userspace tools
to enforce the encoding. When that optional bit is set, any attempt to
create a file name using an invalid UTF-8 sequence will fail and return
an error to userspace.
* Normalization algorithm:
The UTF-8 algorithms used to compare strings in f2fs is implemented
in fs/unicode, and is based on a previous version developed by
SGI. It implements the Canonical decomposition (NFD) algorithm
described by the Unicode specification 12.1, or higher, combined with
the elimination of ignorable code points (NFDi) and full
case-folding (CF) as documented in fs/unicode/utf8_norm.c.
NFD seems to be the best normalization method for F2FS because:
- It has a lower cost than NFC/NFKC (which requires
decomposing to NFD as an intermediary step)
- It doesn't eliminate important semantic meaning like
compatibility decompositions.
Although:
- This implementation is not completely linguistic accurate, because
different languages have conflicting rules, which would require the
specialization of the filesystem to a given locale, which brings all
sorts of problems for removable media and for users who use more than
one language.
"""
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
fs/f2fs/dir.c | 133 ++++++++++++++++++++++++++++++++++++++++++-----
fs/f2fs/f2fs.h | 23 +++++---
fs/f2fs/file.c | 10 +++-
fs/f2fs/hash.c | 34 +++++++++++-
fs/f2fs/inline.c | 6 +--
fs/f2fs/inode.c | 4 +-
fs/f2fs/namei.c | 21 ++++++++
fs/f2fs/super.c | 5 ++
8 files changed, 210 insertions(+), 26 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 59bc460178554..03b5c5d88e647 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -8,6 +8,7 @@
#include <linux/fs.h>
#include <linux/f2fs_fs.h>
#include <linux/sched/signal.h>
+#include <linux/unicode.h>
#include "f2fs.h"
#include "node.h"
#include "acl.h"
@@ -81,7 +82,8 @@ static unsigned long dir_block_index(unsigned int level,
return bidx;
}
-static struct f2fs_dir_entry *find_in_block(struct page *dentry_page,
+static struct f2fs_dir_entry *find_in_block(struct inode *dir,
+ struct page *dentry_page,
struct fscrypt_name *fname,
f2fs_hash_t namehash,
int *max_slots,
@@ -94,20 +96,56 @@ static struct f2fs_dir_entry *find_in_block(struct page *dentry_page,
dentry_blk = (struct f2fs_dentry_block *)page_address(dentry_page);
make_dentry_ptr_block(NULL, &d, dentry_blk);
- de = f2fs_find_target_dentry(fname, namehash, max_slots, &d);
+ de = f2fs_find_target_dentry(dir, fname, namehash, max_slots, &d);
if (de)
*res_page = dentry_page;
return de;
}
-struct f2fs_dir_entry *f2fs_find_target_dentry(struct fscrypt_name *fname,
- f2fs_hash_t namehash, int *max_slots,
- struct f2fs_dentry_ptr *d)
+#ifdef CONFIG_UNICODE
+/*
+ * Test whether a case-insensitive directory entry matches the filename
+ * being searched for.
+ *
+ * Returns: 0 if the directory entry matches, more than 0 if it
+ * doesn't match or less than zero on error.
+ */
+int f2fs_ci_compare(const struct inode *parent, const struct qstr *name,
+ const struct qstr *entry)
+{
+ const struct f2fs_sb_info *sbi = F2FS_SB(parent->i_sb);
+ const struct unicode_map *um = sbi->s_encoding;
+ int ret;
+
+ ret = utf8_strncasecmp(um, name, entry);
+ if (ret < 0) {
+ /* Handle invalid character sequence as either an error
+ * or as an opaque byte sequence.
+ */
+ if (f2fs_has_strict_mode(sbi))
+ return -EINVAL;
+
+ if (name->len != entry->len)
+ return 1;
+
+ return !!memcmp(name->name, entry->name, name->len);
+ }
+
+ return ret;
+}
+#endif
+
+struct f2fs_dir_entry *f2fs_find_target_dentry(const struct inode *parent,
+ struct fscrypt_name *fname, f2fs_hash_t namehash,
+ int *max_slots, struct f2fs_dentry_ptr *d)
{
struct f2fs_dir_entry *de;
unsigned long bit_pos = 0;
int max_len = 0;
+#ifdef CONFIG_UNICODE
+ struct qstr entry;
+#endif
if (max_slots)
*max_slots = 0;
@@ -119,16 +157,29 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(struct fscrypt_name *fname,
}
de = &d->dentry[bit_pos];
+#ifdef CONFIG_UNICODE
+ entry.name = d->filename[bit_pos];
+ entry.len = de->name_len;
+#endif
if (unlikely(!de->name_len)) {
bit_pos++;
continue;
}
+ if (de->hash_code == namehash) {
+#ifdef CONFIG_UNICODE
+ if (F2FS_SB(parent->i_sb)->s_encoding &&
+ IS_CASEFOLDED(parent) &&
+ !f2fs_ci_compare(parent,
+ fname->usr_fname, &entry))
+ goto found;
- if (de->hash_code == namehash &&
- fscrypt_match_name(fname, d->filename[bit_pos],
- le16_to_cpu(de->name_len)))
- goto found;
+#endif
+ if (de->hash_code == namehash &&
+ fscrypt_match_name(fname, d->filename[bit_pos],
+ le16_to_cpu(de->name_len)))
+ goto found;
+ }
if (max_slots && max_len > *max_slots)
*max_slots = max_len;
@@ -157,7 +208,7 @@ static struct f2fs_dir_entry *find_in_level(struct inode *dir,
struct f2fs_dir_entry *de = NULL;
bool room = false;
int max_slots;
- f2fs_hash_t namehash = f2fs_dentry_hash(&name, fname);
+ f2fs_hash_t namehash = f2fs_dentry_hash(dir, &name, fname);
nbucket = dir_buckets(level, F2FS_I(dir)->i_dir_level);
nblock = bucket_blocks(level);
@@ -179,8 +230,8 @@ static struct f2fs_dir_entry *find_in_level(struct inode *dir,
}
}
- de = find_in_block(dentry_page, fname, namehash, &max_slots,
- res_page);
+ de = find_in_block(dir, dentry_page, fname, namehash,
+ &max_slots, res_page);
if (de)
break;
@@ -247,10 +298,18 @@ struct f2fs_dir_entry *__f2fs_find_entry(struct inode *dir,
struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
const struct qstr *child, struct page **res_page)
{
+ struct f2fs_sb_info *sbi = F2FS_I_SB(dir);
struct f2fs_dir_entry *de = NULL;
struct fscrypt_name fname;
int err;
+#ifdef CONFIG_UNICODE
+ if (f2fs_has_strict_mode(sbi) && IS_CASEFOLDED(dir) &&
+ utf8_validate(sbi->s_encoding, child)) {
+ *res_page = ERR_PTR(-EINVAL);
+ return NULL;
+ }
+#endif
err = fscrypt_setup_filename(dir, child, 1, &fname);
if (err) {
if (err == -ENOENT)
@@ -505,7 +564,7 @@ int f2fs_add_regular_entry(struct inode *dir, const struct qstr *new_name,
level = 0;
slots = GET_DENTRY_SLOTS(new_name->len);
- dentry_hash = f2fs_dentry_hash(new_name, NULL);
+ dentry_hash = f2fs_dentry_hash(dir, new_name, NULL);
current_depth = F2FS_I(dir)->i_current_depth;
if (F2FS_I(dir)->chash == dentry_hash) {
@@ -945,3 +1004,51 @@ const struct file_operations f2fs_dir_operations = {
.compat_ioctl = f2fs_compat_ioctl,
#endif
};
+
+#ifdef CONFIG_UNICODE
+static int f2fs_d_compare(const struct dentry *dentry, unsigned int len,
+ const char *str, const struct qstr *name)
+{
+ struct qstr qstr = {.name = str, .len = len };
+
+ if (!IS_CASEFOLDED(dentry->d_parent->d_inode)) {
+ if (len != name->len)
+ return -1;
+ return memcmp(str, name, len);
+ }
+
+ return f2fs_ci_compare(dentry->d_parent->d_inode, name, &qstr);
+}
+
+static int f2fs_d_hash(const struct dentry *dentry, struct qstr *str)
+{
+ const struct f2fs_sb_info *sbi = F2FS_SB(dentry->d_sb);
+ const struct unicode_map *um = sbi->s_encoding;
+ unsigned char *norm;
+ int len, ret = 0;
+
+ if (!IS_CASEFOLDED(dentry->d_inode))
+ return 0;
+
+ norm = kmalloc(PATH_MAX, GFP_ATOMIC);
+ if (!norm)
+ return -ENOMEM;
+
+ len = utf8_casefold(um, str, norm, PATH_MAX);
+ if (len < 0) {
+ if (f2fs_has_strict_mode(sbi))
+ ret = -EINVAL;
+ goto out;
+ }
+ str->hash = full_name_hash(dentry, norm, len);
+out:
+ kfree(norm);
+ return ret;
+}
+
+const struct dentry_operations f2fs_dentry_ops = {
+ .d_hash = f2fs_d_hash,
+ .d_compare = f2fs_d_compare,
+};
+#endif
+
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0e101f699eccd..2060613adf525 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2354,10 +2354,11 @@ static inline void f2fs_change_bit(unsigned int nr, char *addr)
#define F2FS_NOCOW_FL 0x00800000 /* Do not cow file */
#define F2FS_INLINE_DATA_FL 0x10000000 /* Inode has inline data. */
#define F2FS_PROJINHERIT_FL 0x20000000 /* Create with parents projid */
+#define F2FS_CASEFOLD_FL 0x40000000 /* Casefolded file */
#define F2FS_RESERVED_FL 0x80000000 /* reserved for ext4 lib */
-#define F2FS_FL_USER_VISIBLE 0x30CBDFFF /* User visible flags */
-#define F2FS_FL_USER_MODIFIABLE 0x204BC0FF /* User modifiable flags */
+#define F2FS_FL_USER_VISIBLE 0x70CBDFFF /* User visible flags */
+#define F2FS_FL_USER_MODIFIABLE 0x604BC0FF /* User modifiable flags */
/* Flags we can manipulate with through F2FS_IOC_FSSETXATTR */
#define F2FS_FL_XFLAG_VISIBLE (F2FS_SYNC_FL | \
@@ -2372,10 +2373,10 @@ static inline void f2fs_change_bit(unsigned int nr, char *addr)
F2FS_SYNC_FL | F2FS_NODUMP_FL | F2FS_NOATIME_FL |\
F2FS_NOCOMPR_FL | F2FS_JOURNAL_DATA_FL |\
F2FS_NOTAIL_FL | F2FS_DIRSYNC_FL |\
- F2FS_PROJINHERIT_FL)
+ F2FS_PROJINHERIT_FL | F2FS_CASEFOLD_FL)
/* Flags that are appropriate for regular files (all but dir-specific ones). */
-#define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_TOPDIR_FL))
+#define F2FS_REG_FLMASK (~(F2FS_DIRSYNC_FL | F2FS_TOPDIR_FL | F2FS_CASEFOLD_FL))
/* Flags that are appropriate for non-directories/regular files. */
#define F2FS_OTHER_FLMASK (F2FS_NODUMP_FL | F2FS_NOATIME_FL)
@@ -2936,11 +2937,16 @@ int f2fs_update_extension_list(struct f2fs_sb_info *sbi, const char *name,
bool hot, bool set);
struct dentry *f2fs_get_parent(struct dentry *child);
+extern int f2fs_ci_compare(const struct inode *parent,
+ const struct qstr *name,
+ const struct qstr *entry);
+
/*
* dir.c
*/
unsigned char f2fs_get_de_type(struct f2fs_dir_entry *de);
-struct f2fs_dir_entry *f2fs_find_target_dentry(struct fscrypt_name *fname,
+struct f2fs_dir_entry *f2fs_find_target_dentry(const struct inode *parent,
+ struct fscrypt_name *fname,
f2fs_hash_t namehash, int *max_slots,
struct f2fs_dentry_ptr *d);
int f2fs_fill_dentries(struct dir_context *ctx, struct f2fs_dentry_ptr *d,
@@ -3001,8 +3007,8 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi);
/*
* hash.c
*/
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
- struct fscrypt_name *fname);
+f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
+ const struct qstr *name_info, struct fscrypt_name *fname);
/*
* node.c
@@ -3440,6 +3446,9 @@ static inline void f2fs_destroy_root_stats(void) { }
#endif
extern const struct file_operations f2fs_dir_operations;
+#ifdef CONFIG_UNICODE
+extern const struct dentry_operations f2fs_dentry_ops;
+#endif
extern const struct file_operations f2fs_file_operations;
extern const struct inode_operations f2fs_file_inode_operations;
extern const struct address_space_operations f2fs_dblock_aops;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 45b45f37d347e..900018d8b0d80 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1678,7 +1678,16 @@ static int __f2fs_ioc_setflags(struct inode *inode, unsigned int flags)
flags = f2fs_mask_flags(inode->i_mode, flags);
oldflags = fi->i_flags;
+ if ((flags ^ oldflags) & F2FS_CASEFOLD_FL) {
+ if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
+ return -EOPNOTSUPP;
+
+ if (!S_ISDIR(inode->i_mode))
+ return -ENOTDIR;
+ if (!f2fs_empty_dir(inode))
+ return -ENOTEMPTY;
+ }
if ((flags ^ oldflags) & (F2FS_APPEND_FL | F2FS_IMMUTABLE_FL))
if (!capable(CAP_LINUX_IMMUTABLE))
return -EPERM;
@@ -1691,7 +1700,6 @@ static int __f2fs_ioc_setflags(struct inode *inode, unsigned int flags)
set_inode_flag(inode, FI_PROJ_INHERIT);
else
clear_inode_flag(inode, FI_PROJ_INHERIT);
-
inode->i_ctime = current_time(inode);
f2fs_set_inode_flags(inode);
f2fs_mark_inode_dirty_sync(inode, true);
diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
index cc82f142f811f..f5b8e02bde049 100644
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -14,6 +14,7 @@
#include <linux/f2fs_fs.h>
#include <linux/cryptohash.h>
#include <linux/pagemap.h>
+#include <linux/unicode.h>
#include "f2fs.h"
@@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
*buf++ = pad;
}
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
struct fscrypt_name *fname)
{
__u32 hash;
@@ -103,3 +104,34 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
return f2fs_hash;
}
+
+f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
+ const struct qstr *name_info, struct fscrypt_name *fname)
+{
+#ifdef CONFIG_UNICODE
+ const struct unicode_map *um = F2FS_SB(dir->i_sb)->s_encoding;
+ int r, dlen;
+ unsigned char *buff;
+ struct qstr *folded;
+
+ if (name_info->len && IS_CASEFOLDED(dir)) {
+ buff = kzalloc(sizeof(char) * PATH_MAX, GFP_KERNEL);
+ if (!buff)
+ return -ENOMEM;
+
+ dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
+ if (dlen < 0) {
+ kfree(buff);
+ goto opaque_seq;
+ }
+ folded->name = buff;
+ folded->len = dlen;
+ r = __f2fs_dentry_hash(folded, fname);
+
+ kfree(buff);
+ return r;
+ }
+opaque_seq:
+#endif
+ return __f2fs_dentry_hash(name_info, fname);
+}
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 58e23bf562174..9f8e54b2b3125 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -340,12 +340,12 @@ struct f2fs_dir_entry *f2fs_find_in_inline_dir(struct inode *dir,
return NULL;
}
- namehash = f2fs_dentry_hash(&name, fname);
+ namehash = f2fs_dentry_hash(dir, &name, fname);
inline_dentry = inline_data_addr(dir, ipage);
make_dentry_ptr_inline(dir, &d, inline_dentry);
- de = f2fs_find_target_dentry(fname, namehash, NULL, &d);
+ de = f2fs_find_target_dentry(dir, fname, namehash, NULL, &d);
unlock_page(ipage);
if (de)
*res_page = ipage;
@@ -602,7 +602,7 @@ int f2fs_add_inline_entry(struct inode *dir, const struct qstr *new_name,
f2fs_wait_on_page_writeback(ipage, NODE, true, true);
- name_hash = f2fs_dentry_hash(new_name, NULL);
+ name_hash = f2fs_dentry_hash(dir, new_name, NULL);
f2fs_update_dentry(ino, mode, &d, new_name, name_hash, bit_pos);
set_page_dirty(ipage);
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index ccb02226dd2c0..280abef016c04 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -46,9 +46,11 @@ void f2fs_set_inode_flags(struct inode *inode)
new_fl |= S_DIRSYNC;
if (file_is_encrypt(inode))
new_fl |= S_ENCRYPTED;
+ if (flags & F2FS_CASEFOLD_FL)
+ new_fl |= S_CASEFOLD;
inode_set_flags(inode, new_fl,
S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|
- S_ENCRYPTED);
+ S_ENCRYPTED|S_CASEFOLD);
}
static void __get_inode_rdev(struct inode *inode, struct f2fs_inode *ri)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 0f77f92427515..62470466bc4fa 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -491,6 +491,17 @@ static struct dentry *f2fs_lookup(struct inode *dir, struct dentry *dentry,
goto out_iput;
}
out_splice:
+#ifdef CONFIG_UNICODE
+ if (!inode && IS_CASEFOLDED(dir)) {
+ /* Eventually we want to call d_add_ci(dentry, NULL)
+ * for negative dentries in the encoding case as
+ * well. For now, prevent the negative dentry
+ * from being cached.
+ */
+ trace_f2fs_lookup_end(dir, dentry, ino, err);
+ return NULL;
+ }
+#endif
new = d_splice_alias(inode, dentry);
err = PTR_ERR_OR_ZERO(new);
trace_f2fs_lookup_end(dir, dentry, ino, err);
@@ -539,6 +550,16 @@ static int f2fs_unlink(struct inode *dir, struct dentry *dentry)
goto fail;
}
f2fs_delete_entry(de, page, dir, inode);
+#ifdef CONFIG_UNICODE
+ /* VFS negative dentries are incompatible with Encoding and
+ * Case-insensitiveness. Eventually we'll want avoid
+ * invalidating the dentries here, alongside with returning the
+ * negative dentries at f2fs_lookup(), when it is better
+ * supported by the VFS for the CI case.
+ */
+ if (IS_CASEFOLDED(dir))
+ d_invalidate(dentry);
+#endif
f2fs_unlock_op(sbi);
if (IS_DIRSYNC(dir))
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index a346f5a01370b..2d58b4746b9fa 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -3425,6 +3425,11 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
goto free_node_inode;
}
+#ifdef CONFIG_UNICODE
+ if (sbi->s_encoding)
+ sb->s_d_op = &f2fs_dentry_ops;
+#endif
+
sb->s_root = d_make_root(root); /* allocate root dentry */
if (!sb->s_root) {
err = -ENOMEM;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH 1/2] f2fs: include charset encoding information in the superblock
From: Daniel Rosenberg @ 2019-07-11 20:45 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team,
Daniel Rosenberg
Add charset encoding to f2fs to support casefolding. It is modeled after
the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
encoding information in the superblock")
Currently this is not compatible with encryption, similar to the current
ext4 imlpementation. This will change in the future.
From the ext4 patch:
"""
The s_encoding field stores a magic number indicating the encoding
format and version used globally by file and directory names in the
filesystem. The s_encoding_flags defines policies for using the charset
encoding, like how to handle invalid sequences. The magic number is
mapped to the exact charset table, but the mapping is specific to ext4.
Since we don't have any commitment to support old encodings, the only
encoding I am supporting right now is utf8-12.1.0.
The current implementation prevents the user from enabling encoding and
per-directory encryption on the same filesystem at the same time. The
incompatibility between these features lies in how we do efficient
directory searches when we cannot be sure the encryption of the user
provided fname will match the actual hash stored in the disk without
decrypting every directory entry, because of normalization cases. My
quickest solution is to simply block the concurrent use of these
features for now, and enable it later, once we have a better solution.
"""
Signed-off-by: Daniel Rosenberg <drosen@google.com>
---
fs/f2fs/f2fs.h | 6 +++
fs/f2fs/super.c | 81 +++++++++++++++++++++++++++++++++++++++++
include/linux/f2fs_fs.h | 9 ++++-
3 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 06b89a9862ab2..0e101f699eccd 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -150,6 +150,7 @@ struct f2fs_mount_info {
#define F2FS_FEATURE_LOST_FOUND 0x0200
#define F2FS_FEATURE_VERITY 0x0400 /* reserved */
#define F2FS_FEATURE_SB_CHKSUM 0x0800
+#define F2FS_FEATURE_CASEFOLD 0x1000
#define __F2FS_HAS_FEATURE(raw_super, mask) \
((raw_super->feature & cpu_to_le32(mask)) != 0)
@@ -1162,6 +1163,10 @@ struct f2fs_sb_info {
int valid_super_block; /* valid super block no */
unsigned long s_flag; /* flags for sbi */
struct mutex writepages; /* mutex for writepages() */
+#ifdef CONFIG_UNICODE
+ struct unicode_map *s_encoding;
+ __u16 s_encoding_flags;
+#endif
#ifdef CONFIG_BLK_DEV_ZONED
unsigned int blocks_per_blkz; /* F2FS blocks per zone */
@@ -3565,6 +3570,7 @@ F2FS_FEATURE_FUNCS(quota_ino, QUOTA_INO);
F2FS_FEATURE_FUNCS(inode_crtime, INODE_CRTIME);
F2FS_FEATURE_FUNCS(lost_found, LOST_FOUND);
F2FS_FEATURE_FUNCS(sb_chksum, SB_CHKSUM);
+F2FS_FEATURE_FUNCS(casefold, CASEFOLD);
#ifdef CONFIG_BLK_DEV_ZONED
static inline bool f2fs_blkz_is_seq(struct f2fs_sb_info *sbi, int devi,
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 6b959bbb336a3..a346f5a01370b 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -23,6 +23,7 @@
#include <linux/f2fs_fs.h>
#include <linux/sysfs.h>
#include <linux/quota.h>
+#include <linux/unicode.h>
#include "f2fs.h"
#include "node.h"
@@ -211,6 +212,36 @@ void f2fs_msg(struct super_block *sb, const char *level, const char *fmt, ...)
va_end(args);
}
+#ifdef CONFIG_UNICODE
+static const struct f2fs_sb_encodings {
+ __u16 magic;
+ char *name;
+ char *version;
+} f2fs_sb_encoding_map[] = {
+ {F2FS_ENC_UTF8_12_1, "utf8", "12.1.0"},
+};
+
+static int f2fs_sb_read_encoding(const struct f2fs_super_block *sb,
+ const struct f2fs_sb_encodings **encoding,
+ __u16 *flags)
+{
+ __u16 magic = le16_to_cpu(sb->s_encoding);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(f2fs_sb_encoding_map); i++)
+ if (magic == f2fs_sb_encoding_map[i].magic)
+ break;
+
+ if (i >= ARRAY_SIZE(f2fs_sb_encoding_map))
+ return -EINVAL;
+
+ *encoding = &f2fs_sb_encoding_map[i];
+ *flags = le16_to_cpu(sb->s_encoding_flags);
+
+ return 0;
+}
+#endif
+
static inline void limit_reserve_root(struct f2fs_sb_info *sbi)
{
block_t limit = (sbi->user_block_count << 1) / 1000;
@@ -812,6 +843,13 @@ static int parse_options(struct super_block *sb, char *options)
return -EINVAL;
}
#endif
+#ifndef CONFIG_UNICODE
+ if (f2fs_sb_has_casefold(sbi)) {
+ f2fs_msg(sb, KERN_ERR,
+ "Filesystem with casefold feature cannot be mounted without CONFIG_UNICODE");
+ return -EINVAL;
+ }
+#endif
if (F2FS_IO_SIZE_BITS(sbi) && !test_opt(sbi, LFS)) {
f2fs_msg(sb, KERN_ERR,
@@ -1110,6 +1148,9 @@ static void f2fs_put_super(struct super_block *sb)
destroy_percpu_info(sbi);
for (i = 0; i < NR_PAGE_TYPE; i++)
kvfree(sbi->write_io[i]);
+#ifdef CONFIG_UNICODE
+ utf8_unload(sbi->s_encoding);
+#endif
kvfree(sbi);
}
@@ -3157,6 +3198,42 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
sb->s_maxbytes = sbi->max_file_blocks <<
le32_to_cpu(raw_super->log_blocksize);
sb->s_max_links = F2FS_LINK_MAX;
+#ifdef CONFIG_UNICODE
+ if (f2fs_sb_has_casefold(sbi) && !sbi->s_encoding) {
+ const struct f2fs_sb_encodings *encoding_info;
+ struct unicode_map *encoding;
+ __u16 encoding_flags;
+
+ if (f2fs_sb_has_encrypt(sbi)) {
+ f2fs_msg(sb, KERN_ERR,
+ "Can't mount with encoding and encryption");
+ goto free_options;
+ }
+
+ if (f2fs_sb_read_encoding(raw_super, &encoding_info,
+ &encoding_flags)) {
+ f2fs_msg(sb, KERN_ERR,
+ "Encoding requested by superblock is unknown");
+ goto free_options;
+ }
+
+ encoding = utf8_load(encoding_info->version);
+ if (IS_ERR(encoding)) {
+ f2fs_msg(sb, KERN_ERR,
+ "can't mount with superblock charset: %s-%s "
+ "not supported by the kernel. flags: 0x%x.",
+ encoding_info->name, encoding_info->version,
+ encoding_flags);
+ goto free_options;
+ }
+ f2fs_msg(sb, KERN_INFO, "Using encoding defined by superblock: "
+ "%s-%s with flags 0x%hx", encoding_info->name,
+ encoding_info->version?:"\b", encoding_flags);
+
+ sbi->s_encoding = encoding;
+ sbi->s_encoding_flags = encoding_flags;
+ }
+#endif
#ifdef CONFIG_QUOTA
sb->dq_op = &f2fs_quota_operations;
@@ -3511,6 +3588,10 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
free_bio_info:
for (i = 0; i < NR_PAGE_TYPE; i++)
kvfree(sbi->write_io[i]);
+
+#ifdef CONFIG_UNICODE
+ utf8_unload(sbi->s_encoding);
+#endif
free_options:
#ifdef CONFIG_QUOTA
for (i = 0; i < MAXQUOTAS; i++)
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index 65559900d4d76..b7c9c7f721339 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -36,6 +36,11 @@
#define F2FS_MAX_QUOTAS 3
+#define F2FS_ENC_UTF8_12_1 1
+#define F2FS_ENC_STRICT_MODE_FL (1 << 0)
+#define f2fs_has_strict_mode(sbi) \
+ (sbi->s_encoding_flags & F2FS_ENC_STRICT_MODE_FL)
+
#define F2FS_IO_SIZE(sbi) (1 << F2FS_OPTION(sbi).write_io_size_bits) /* Blocks */
#define F2FS_IO_SIZE_KB(sbi) (1 << (F2FS_OPTION(sbi).write_io_size_bits + 2)) /* KB */
#define F2FS_IO_SIZE_BYTES(sbi) (1 << (F2FS_OPTION(sbi).write_io_size_bits + 12)) /* B */
@@ -109,7 +114,9 @@ struct f2fs_super_block {
struct f2fs_device devs[MAX_DEVICES]; /* device list */
__le32 qf_ino[F2FS_MAX_QUOTAS]; /* quota inode numbers */
__u8 hot_ext_count; /* # of hot file extension */
- __u8 reserved[310]; /* valid reserved region */
+ __le16 s_encoding; /* Filename charset encoding */
+ __le16 s_encoding_flags; /* Filename charset encoding flags */
+ __u8 reserved[306]; /* valid reserved region */
__le32 crc; /* checksum of superblock */
} __packed;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH] treewide: Rename rcu_dereference_raw_notrace to _check
From: Joel Fernandes (Google) @ 2019-07-11 20:45 UTC (permalink / raw)
To: linux-kernel
Cc: Joel Fernandes (Google), Benjamin Herrenschmidt, Ingo Molnar,
Jonathan Corbet, Josh Triplett, kvm-ppc, Lai Jiangshan, linux-doc,
linuxppc-dev, Mathieu Desnoyers, Michael Ellerman,
Paul E. McKenney, Paul Mackerras, rcu, Steven Rostedt,
byungchul.park, kernel-team
The rcu_dereference_raw_notrace() API name is confusing.
It is equivalent to rcu_dereference_raw() except that it also does
sparse pointer checking.
There are only a few users of rcu_dereference_raw_notrace(). This
patches renames all of them to be rcu_dereference_raw_check with the
"check" indicating sparse checking.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
Previous discussion is here:
https://lore.kernel.org/linuxppc-dev/20190528200014.GV28207@linux.ibm.com/T/
Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
include/linux/rculist.h | 4 ++--
include/linux/rcupdate.h | 2 +-
kernel/trace/ftrace_internal.h | 8 ++++----
kernel/trace/trace.c | 4 ++--
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index f04c467e55c5..467251f7fef6 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2514,7 +2514,7 @@ disabled across the entire RCU read-side critical section.
<p>
It is possible to use tracing on RCU code, but tracing itself
uses RCU.
-For this reason, <tt>rcu_dereference_raw_notrace()</tt>
+For this reason, <tt>rcu_dereference_raw_check()</tt>
is provided for use by tracing, which avoids the destructive
recursion that could otherwise ensue.
This API is also used by virtualization in some architectures,
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index 21b1ed5df888..53388a311967 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -546,7 +546,7 @@ static inline void note_hpte_modification(struct kvm *kvm,
*/
static inline struct kvm_memslots *kvm_memslots_raw(struct kvm *kvm)
{
- return rcu_dereference_raw_notrace(kvm->memslots[0]);
+ return rcu_dereference_raw_check(kvm->memslots[0]);
}
extern void kvmppc_mmu_debugfs_init(struct kvm *kvm);
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index e91ec9ddcd30..10aab1d2d471 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -642,10 +642,10 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
* not do any RCU debugging or tracing.
*/
#define hlist_for_each_entry_rcu_notrace(pos, head, member) \
- for (pos = hlist_entry_safe (rcu_dereference_raw_notrace(hlist_first_rcu(head)),\
+ for (pos = hlist_entry_safe (rcu_dereference_raw_check(hlist_first_rcu(head)),\
typeof(*(pos)), member); \
pos; \
- pos = hlist_entry_safe(rcu_dereference_raw_notrace(hlist_next_rcu(\
+ pos = hlist_entry_safe(rcu_dereference_raw_check(hlist_next_rcu(\
&(pos)->member)), typeof(*(pos)), member))
/**
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 0c9b92799abc..e5161e377ad4 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -478,7 +478,7 @@ do { \
* The no-tracing version of rcu_dereference_raw() must not call
* rcu_read_lock_held().
*/
-#define rcu_dereference_raw_notrace(p) __rcu_dereference_check((p), 1, __rcu)
+#define rcu_dereference_raw_check(p) __rcu_dereference_check((p), 1, __rcu)
/**
* rcu_dereference_protected() - fetch RCU pointer when updates prevented
diff --git a/kernel/trace/ftrace_internal.h b/kernel/trace/ftrace_internal.h
index 0515a2096f90..0456e0a3dab1 100644
--- a/kernel/trace/ftrace_internal.h
+++ b/kernel/trace/ftrace_internal.h
@@ -6,22 +6,22 @@
/*
* Traverse the ftrace_global_list, invoking all entries. The reason that we
- * can use rcu_dereference_raw_notrace() is that elements removed from this list
+ * can use rcu_dereference_raw_check() is that elements removed from this list
* are simply leaked, so there is no need to interact with a grace-period
- * mechanism. The rcu_dereference_raw_notrace() calls are needed to handle
+ * mechanism. The rcu_dereference_raw_check() calls are needed to handle
* concurrent insertions into the ftrace_global_list.
*
* Silly Alpha and silly pointer-speculation compiler optimizations!
*/
#define do_for_each_ftrace_op(op, list) \
- op = rcu_dereference_raw_notrace(list); \
+ op = rcu_dereference_raw_check(list); \
do
/*
* Optimized for just a single item in the list (as that is the normal case).
*/
#define while_for_each_ftrace_op(op) \
- while (likely(op = rcu_dereference_raw_notrace((op)->next)) && \
+ while (likely(op = rcu_dereference_raw_check((op)->next)) && \
unlikely((op) != &ftrace_list_end))
extern struct ftrace_ops __rcu *ftrace_ops_list;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2c92b3d9ea30..1d69110d9e5b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2642,10 +2642,10 @@ static void ftrace_exports(struct ring_buffer_event *event)
preempt_disable_notrace();
- export = rcu_dereference_raw_notrace(ftrace_exports_list);
+ export = rcu_dereference_raw_check(ftrace_exports_list);
while (export) {
trace_process_export(export, event);
- export = rcu_dereference_raw_notrace(export->next);
+ export = rcu_dereference_raw_check(export->next);
}
preempt_enable_notrace();
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-07-11 20:35 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Jarkko Sakkinen, peterhuewe, jgg, corbet, linux-kernel, linux-doc,
linux-integrity, linux-kernel, thiruan, bryankel, tee-dev,
sumit.garg, rdunlap
In-Reply-To: <20190711201059.GA18260@apalos>
On Thu, Jul 11, 2019 at 11:10:59PM +0300, Ilias Apalodimas wrote:
>On Thu, Jul 11, 2019 at 11:08:58PM +0300, Jarkko Sakkinen wrote:
>> On Fri, Jul 05, 2019 at 04:47:44PM -0400, Sasha Levin wrote:
>> > Changes from v7:
>> >
>> > - Address Jarkko's comments.
>> >
>> > Sasha Levin (2):
>> > fTPM: firmware TPM running in TEE
>> > fTPM: add documentation for ftpm driver
>> >
>> > Documentation/security/tpm/index.rst | 1 +
>> > Documentation/security/tpm/tpm_ftpm_tee.rst | 27 ++
>> > drivers/char/tpm/Kconfig | 5 +
>> > drivers/char/tpm/Makefile | 1 +
>> > drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++
>> > drivers/char/tpm/tpm_ftpm_tee.h | 40 +++
>> > 6 files changed, 424 insertions(+)
>> > create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
>> > create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
>> > create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
>> >
>> > --
>> > 2.20.1
>> >
>>
>> I applied the patches now. Appreciate a lot the patience with these.
>> Thank you.
Thanks Jarkko!
>Will report back any issues when we start using it on real hardware
>rather than QEMU
And thank you Ilias, let us know if we can help with the setup.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Documentation/security-bugs: provide more information about linux-distros
From: Sasha Levin @ 2019-07-11 20:35 UTC (permalink / raw)
To: Will Deacon
Cc: Greg KH, corbet, solar, keescook, peterz, tyhicks, linux-doc,
linux-kernel
In-Reply-To: <20190711170921.ywi43n262s3ckxpi@willie-the-truck>
On Thu, Jul 11, 2019 at 06:09:21PM +0100, Will Deacon wrote:
>On Thu, Jul 11, 2019 at 07:07:32PM +0200, Greg KH wrote:
>> On Thu, Jul 11, 2019 at 12:36:37PM -0400, Sasha Levin wrote:
>> > Provide more information about how to interact with the linux-distros
>> > mailing list for disclosing security bugs.
>> >
>> > First, clarify that the reporter must read and accept the linux-distros
>> > policies prior to sending a report.
>> >
>> > Second, clarify that the reported must provide a tentative public
>> > disclosure date and time in his first contact with linux-distros.
>> >
>> > Suggested-by: Solar Designer <solar@openwall.com>
>> > Signed-off-by: Sasha Levin <sashal@kernel.org>
>> > ---
>> > Documentation/admin-guide/security-bugs.rst | 21 +++++++++++++--------
>> > 1 file changed, 13 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
>> > index dcd6c93c7aac..c62faced9256 100644
>> > --- a/Documentation/admin-guide/security-bugs.rst
>> > +++ b/Documentation/admin-guide/security-bugs.rst
>> > @@ -61,14 +61,19 @@ Coordination
>> >
>> > Fixes for sensitive bugs, such as those that might lead to privilege
>> > escalations, may need to be coordinated with the private
>> > -<linux-distros@vs.openwall.org> mailing list so that distribution vendors
>> > -are well prepared to issue a fixed kernel upon public disclosure of the
>> > -upstream fix. Distros will need some time to test the proposed patch and
>> > -will generally request at least a few days of embargo, and vendor update
>> > -publication prefers to happen Tuesday through Thursday. When appropriate,
>> > -the security team can assist with this coordination, or the reporter can
>> > -include linux-distros from the start. In this case, remember to prefix
>> > -the email Subject line with "[vs]" as described in the linux-distros wiki:
>> > +<linux-distros@vs.openwall.org> mailing list so that distribution vendors are
>> > +well prepared to issue a fixed kernel upon public disclosure of the upstream
>> > +fix. As a reporter, you must read and accept the list's policy as outlined in
>> > +the linux-distros wiki:
>> > +<https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters>.
>> > +When you report a bug, you must also provide a tentative disclosure date and
>> > +time in your very first message to the list. Distros will need some time to
>> > +test the proposed patch so please allow at least a few days of embargo, and
>> > +vendor update publication prefers to happen Tuesday through Thursday. When
>> > +appropriate, the security team can assist with this coordination, or the
>> > +reporter can include linux-distros from the start. In this case, remember to
>> > +prefix the email Subject line with "[vs]" as described in the linux-distros
>> > +wiki:
>> > <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
>>
>> Do we really need to describe all of the information on how to use the
>> distro list here? That's why we included the link, as it has all of
>> this well spelled out and described. If anything, I would say we should
>> say less in this document about what linux-distros do, as that is
>> independent of the Linux security team.
>
>Agreed, and it also means that any changes linux-distros make to their
>policy won't be reflecting in the numerous kernel trees out there, so a
>link is much better imo.
I agree that the 2nd part about embargo timelines is redundant, but I
only addressed it because the document was already addressing embargos.
I only now realized that the link we had there was just going to the
main wiki page by mistake: the tag it was trying to point to was removed
from the wiki page. We should probably update that too.
With regards to the explicit instruction to agree with policies, I think
we do need it there. Right now this section reads as "for embargoes work
with linux-distros@vs.openwall.org, and btw they have a wiki which you
may or may not need to read".
We probably do need to stress here that linux-distros has different
policies than security@kernel.org.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Ilias Apalodimas @ 2019-07-11 20:10 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Sasha Levin, peterhuewe, jgg, corbet, linux-kernel, linux-doc,
linux-integrity, linux-kernel, thiruan, bryankel, tee-dev,
sumit.garg, rdunlap
In-Reply-To: <20190711200858.xydm3wujikufxjcw@linux.intel.com>
On Thu, Jul 11, 2019 at 11:08:58PM +0300, Jarkko Sakkinen wrote:
> On Fri, Jul 05, 2019 at 04:47:44PM -0400, Sasha Levin wrote:
> > Changes from v7:
> >
> > - Address Jarkko's comments.
> >
> > Sasha Levin (2):
> > fTPM: firmware TPM running in TEE
> > fTPM: add documentation for ftpm driver
> >
> > Documentation/security/tpm/index.rst | 1 +
> > Documentation/security/tpm/tpm_ftpm_tee.rst | 27 ++
> > drivers/char/tpm/Kconfig | 5 +
> > drivers/char/tpm/Makefile | 1 +
> > drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++
> > drivers/char/tpm/tpm_ftpm_tee.h | 40 +++
> > 6 files changed, 424 insertions(+)
> > create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
> > create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
> > create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
> >
> > --
> > 2.20.1
> >
>
> I applied the patches now. Appreciate a lot the patience with these.
> Thank you.
>
Will report back any issues when we start using it on real hardware
rather than QEMU
Thanks
/Ilias
> /Jarkko
^ permalink raw reply
* Re: [PATCH v8 0/2] fTPM: firmware TPM running in TEE
From: Jarkko Sakkinen @ 2019-07-11 20:08 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, jgg, corbet, linux-kernel, linux-doc, linux-integrity,
linux-kernel, thiruan, bryankel, tee-dev, ilias.apalodimas,
sumit.garg, rdunlap
In-Reply-To: <20190705204746.27543-1-sashal@kernel.org>
On Fri, Jul 05, 2019 at 04:47:44PM -0400, Sasha Levin wrote:
> Changes from v7:
>
> - Address Jarkko's comments.
>
> Sasha Levin (2):
> fTPM: firmware TPM running in TEE
> fTPM: add documentation for ftpm driver
>
> Documentation/security/tpm/index.rst | 1 +
> Documentation/security/tpm/tpm_ftpm_tee.rst | 27 ++
> drivers/char/tpm/Kconfig | 5 +
> drivers/char/tpm/Makefile | 1 +
> drivers/char/tpm/tpm_ftpm_tee.c | 350 ++++++++++++++++++++
> drivers/char/tpm/tpm_ftpm_tee.h | 40 +++
> 6 files changed, 424 insertions(+)
> create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
>
> --
> 2.20.1
>
I applied the patches now. Appreciate a lot the patience with these.
Thank you.
/Jarkko
^ permalink raw reply
* Re: [PATCH v8 2/2] fTPM: add documentation for ftpm driver
From: Jarkko Sakkinen @ 2019-07-11 20:05 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, jgg, corbet, linux-kernel, linux-doc, linux-integrity,
linux-kernel, thiruan, bryankel, tee-dev, ilias.apalodimas,
sumit.garg, rdunlap
In-Reply-To: <20190705204746.27543-3-sashal@kernel.org>
On Fri, Jul 05, 2019 at 04:47:46PM -0400, Sasha Levin wrote:
> This patch adds basic documentation to describe the new fTPM driver.
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [PATCH v8 1/2] fTPM: firmware TPM running in TEE
From: Jarkko Sakkinen @ 2019-07-11 20:04 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, jgg, corbet, linux-kernel, linux-doc, linux-integrity,
linux-kernel, thiruan, bryankel, tee-dev, ilias.apalodimas,
sumit.garg, rdunlap
In-Reply-To: <20190705204746.27543-2-sashal@kernel.org>
On Fri, Jul 05, 2019 at 04:47:45PM -0400, Sasha Levin wrote:
> This patch adds support for a software-only implementation of a TPM
> running in TEE.
>
> There is extensive documentation of the design here:
> https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/ .
>
> As well as reference code for the firmware available here:
> https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
>
> Tested-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
> Signed-off-by: Thirupathaiah Annapureddy <thiruan@microsoft.com>
> Co-authored-by: Sasha Levin <sashal@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
^ permalink raw reply
* Re: [PATCH v4] RISC-V: Add an Image header that boot loader can parse.
From: Paul Walmsley @ 2019-07-11 19:42 UTC (permalink / raw)
To: Atish Patra
Cc: corbet@lwn.net, mick@ics.forth.gr, palmer@sifive.com,
trini@konsulko.com, aou@eecs.berkeley.edu,
linux-kernel@vger.kernel.org, will.deacon@arm.com,
catalin.marinas@arm.com, linux-doc@vger.kernel.org, Anup Patel,
mark.rutland@arm.com, marek.vasut@gmail.com, merker@debian.org,
khilman@baylibre.com, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
In-Reply-To: <c0bdc25bc3aee9eee8bf9ebe561900b88df0540b.camel@wdc.com>
On Fri, 28 Jun 2019, Atish Patra wrote:
> On Fri, 2019-06-28 at 12:09 -0700, Paul Walmsley wrote:
> > On Thu, 6 Jun 2019, Atish Patra wrote:
> >
> > > Currently, the last stage boot loaders such as U-Boot can accept
> > > only
> > > uImage which is an unnecessary additional step in automating boot
> > > process.
> > >
> > > Add an image header that boot loader understands and boot Linux
> > > from
> > > flat Image directly.
> >
> > ...
> >
> >
> > > +#if __riscv_xlen == 64
> > > + /* Image load offset(2MB) from start of RAM */
> > > + .dword 0x200000
> > > +#else
> > > + /* Image load offset(4MB) from start of RAM */
> > > + .dword 0x400000
> > > +#endif
> >
> > Is there a rationale behind these load offset values?
> >
>
> 2MB/4MB alignment requirement is mandatory for current RISC-V kernel.
> Anup had a patch that tried to remove that but not accepted yet.
>
> https://patchwork.kernel.org/patch/10868465/
Thanks for doing this work; this should really help. Patch queued with a
few minor tweaks to the documentation file and to the comments. (Updated
patch below)
Not sure if this will make it for v5.3-rc1. If not, we'll try to get it
in as soon as possible afterwards.
Something else to think about: we'll probably want some flag bits soon to
identify whether the kernel binary is a 32-bit, 64-bit, or 128-bit binary.
If two bits are used, and 64-bit is defined as 00, then it should be
backwards compatible. I would hope that this could be something that we'd
be able to coordinate with the ARM64 folks also; otherwise we may need to
start using that res3 field.
- Paul
From: Atish Patra <atish.patra@wdc.com>
Date: Thu, 6 Jun 2019 16:08:00 -0700
Subject: [PATCH] RISC-V: Add an Image header that boot loader can parse.
Currently, the last stage boot loaders such as U-Boot can accept only
uImage which is an unnecessary additional step in automating boot
process.
Add an image header that boot loader understands and boot Linux from
flat Image directly.
This header is based on ARM64 boot image header and provides an
opportunity to combine both ARM64 & RISC-V image headers in future.
Also make sure that PE/COFF header can co-exist in the same image so
that EFI stub can be supported for RISC-V in future. EFI specification
needs PE/COFF image header in the beginning of the kernel image in order
to load it as an EFI application. In order to support EFI stub, code0
should be replaced with "MZ" magic string and res4(at offset 0x3c)
should point to the rest of the PE/COFF header (which will be added
during EFI support).
Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Karsten Merker <merker@debian.org>
Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
Tested-by: Kevin Hilman <khilman@baylibre.com> (OpenSBI + U-Boot + Linux)
[paul.walmsley@sifive.com: fixed whitespace in boot-image-header.txt;
converted structure comment to kernel-doc format and added some detail]
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
---
| 50 +++++++++++++++++
arch/riscv/include/asm/image.h | 65 +++++++++++++++++++++++
arch/riscv/kernel/head.S | 32 +++++++++++
3 files changed, 147 insertions(+)
create mode 100644 Documentation/riscv/boot-image-header.txt
create mode 100644 arch/riscv/include/asm/image.h
--git a/Documentation/riscv/boot-image-header.txt b/Documentation/riscv/boot-image-header.txt
new file mode 100644
index 000000000000..1b73fea23b39
--- /dev/null
+++ b/Documentation/riscv/boot-image-header.txt
@@ -0,0 +1,50 @@
+ Boot image header in RISC-V Linux
+ =============================================
+
+Author: Atish Patra <atish.patra@wdc.com>
+Date : 20 May 2019
+
+This document only describes the boot image header details for RISC-V Linux.
+The complete booting guide will be available at Documentation/riscv/booting.txt.
+
+The following 64-byte header is present in decompressed Linux kernel image.
+
+ u32 code0; /* Executable code */
+ u32 code1; /* Executable code */
+ u64 text_offset; /* Image load offset, little endian */
+ u64 image_size; /* Effective Image size, little endian */
+ u64 flags; /* kernel flags, little endian */
+ u32 version; /* Version of this header */
+ u32 res1 = 0; /* Reserved */
+ u64 res2 = 0; /* Reserved */
+ u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
+ u32 res3; /* Reserved for additional RISC-V specific header */
+ u32 res4; /* Reserved for PE COFF offset */
+
+This header format is compliant with PE/COFF header and largely inspired from
+ARM64 header. Thus, both ARM64 & RISC-V header can be combined into one common
+header in future.
+
+Notes:
+- This header can also be reused to support EFI stub for RISC-V in future. EFI
+ specification needs PE/COFF image header in the beginning of the kernel image
+ in order to load it as an EFI application. In order to support EFI stub,
+ code0 should be replaced with "MZ" magic string and res5(at offset 0x3c) should
+ point to the rest of the PE/COFF header.
+
+- version field indicate header version number.
+ Bits 0:15 - Minor version
+ Bits 16:31 - Major version
+
+ This preserves compatibility across newer and older version of the header.
+ The current version is defined as 0.1.
+
+- res3 is reserved for offset to any other additional fields. This makes the
+ header extendible in future. One example would be to accommodate ISA
+ extension for RISC-V in future. For current version, it is set to be zero.
+
+- In current header, the flag field has only one field.
+ Bit 0: Kernel endianness. 1 if BE, 0 if LE.
+
+- Image size is mandatory for boot loader to load kernel image. Booting will
+ fail otherwise.
diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
new file mode 100644
index 000000000000..ef28e106f247
--- /dev/null
+++ b/arch/riscv/include/asm/image.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_IMAGE_H
+#define __ASM_IMAGE_H
+
+#define RISCV_IMAGE_MAGIC "RISCV"
+
+#define RISCV_IMAGE_FLAG_BE_SHIFT 0
+#define RISCV_IMAGE_FLAG_BE_MASK 0x1
+
+#define RISCV_IMAGE_FLAG_LE 0
+#define RISCV_IMAGE_FLAG_BE 1
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#error conversion of header fields to LE not yet implemented
+#else
+#define __HEAD_FLAG_BE RISCV_IMAGE_FLAG_LE
+#endif
+
+#define __HEAD_FLAG(field) (__HEAD_FLAG_##field << \
+ RISCV_IMAGE_FLAG_##field##_SHIFT)
+
+#define __HEAD_FLAGS (__HEAD_FLAG(BE))
+
+#define RISCV_HEADER_VERSION_MAJOR 0
+#define RISCV_HEADER_VERSION_MINOR 1
+
+#define RISCV_HEADER_VERSION (RISCV_HEADER_VERSION_MAJOR << 16 | \
+ RISCV_HEADER_VERSION_MINOR)
+
+#ifndef __ASSEMBLY__
+/**
+ * struct riscv_image_header - riscv kernel image header
+ * @code0: Executable code
+ * @code1: Executable code
+ * @text_offset: Image load offset (little endian)
+ * @image_size: Effective Image size (little endian)
+ * @flags: kernel flags (little endian)
+ * @version: version
+ * @res1: reserved
+ * @res2: reserved
+ * @magic: Magic number
+ * @res3: reserved (will be used for additional RISC-V specific
+ * header)
+ * @res4: reserved (will be used for PE COFF offset)
+ *
+ * The intention is for this header format to be shared between multiple
+ * architectures to avoid a proliferation of image header formats.
+ */
+
+struct riscv_image_header {
+ u32 code0;
+ u32 code1;
+ u64 text_offset;
+ u64 image_size;
+ u64 flags;
+ u32 version;
+ u32 res1;
+ u64 res2;
+ u64 magic;
+ u32 res3;
+ u32 res4;
+};
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_IMAGE_H */
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index e368106f2228..0f1ba17e476f 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -11,9 +11,41 @@
#include <asm/thread_info.h>
#include <asm/page.h>
#include <asm/csr.h>
+#include <asm/image.h>
__INIT
ENTRY(_start)
+ /*
+ * Image header expected by Linux boot-loaders. The image header data
+ * structure is described in asm/image.h.
+ * Do not modify it without modifying the structure and all bootloaders
+ * that expects this header format!!
+ */
+ /* jump to start kernel */
+ j _start_kernel
+ /* reserved */
+ .word 0
+ .balign 8
+#if __riscv_xlen == 64
+ /* Image load offset(2MB) from start of RAM */
+ .dword 0x200000
+#else
+ /* Image load offset(4MB) from start of RAM */
+ .dword 0x400000
+#endif
+ /* Effective size of kernel image */
+ .dword _end - _start
+ .dword __HEAD_FLAGS
+ .word RISCV_HEADER_VERSION
+ .word 0
+ .dword 0
+ .asciz RISCV_IMAGE_MAGIC
+ .word 0
+ .balign 4
+ .word 0
+
+.global _start_kernel
+_start_kernel:
/* Mask all interrupts */
csrw CSR_SIE, zero
csrw CSR_SIP, zero
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v5 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
From: bsegall @ 2019-07-11 17:46 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dave Chiluk, Pqhil Auld, Peter Oskolkov, Ingo Molnar, cgroups,
linux-kernel, Brendan Gregg, Kyle Anderson, Gabriel Munos,
John Hammond, Cong Wang, Jonathan Corbet, linux-doc, Paul Turner
In-Reply-To: <20190711095102.GX3402@hirez.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> FWIW, good to see progress, still waiting for you guys to agree :-)
>
> On Mon, Jul 01, 2019 at 01:15:44PM -0700, bsegall@google.com wrote:
>
>> - Taking up-to-every rq->lock is bad and expensive and 5ms may be too
>> short a delay for this. I haven't tried microbenchmarks on the cost of
>> this vs min_cfs_rq_runtime = 0 vs baseline.
>
> Yes, that's tricky, SGI/HPE have definite ideas about that.
>
>> @@ -4781,12 +4790,41 @@ static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq)
>> */
>> static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b)
>> {
>> - u64 runtime = 0, slice = sched_cfs_bandwidth_slice();
>> + u64 runtime = 0;
>> unsigned long flags;
>> u64 expires;
>> + struct cfs_rq *cfs_rq, *temp;
>> + LIST_HEAD(temp_head);
>> +
>> + local_irq_save(flags);
>> +
>> + raw_spin_lock(&cfs_b->lock);
>> + cfs_b->slack_started = false;
>> + list_splice_init(&cfs_b->slack_cfs_rq, &temp_head);
>> + raw_spin_unlock(&cfs_b->lock);
>> +
>> +
>> + /* Gather all left over runtime from all rqs */
>> + list_for_each_entry_safe(cfs_rq, temp, &temp_head, slack_list) {
>> + struct rq *rq = rq_of(cfs_rq);
>> + struct rq_flags rf;
>> +
>> + rq_lock(rq, &rf);
>> +
>> + raw_spin_lock(&cfs_b->lock);
>> + list_del_init(&cfs_rq->slack_list);
>> + if (!cfs_rq->nr_running && cfs_rq->runtime_remaining > 0 &&
>> + cfs_rq->runtime_expires == cfs_b->runtime_expires) {
>> + cfs_b->runtime += cfs_rq->runtime_remaining;
>> + cfs_rq->runtime_remaining = 0;
>> + }
>> + raw_spin_unlock(&cfs_b->lock);
>> +
>> + rq_unlock(rq, &rf);
>> + }
>
> But worse still, you take possibly every rq->lock without ever
> re-enabling IRQs.
>
Yeah, I'm not sure why I did that, it isn't correctness.
^ permalink raw reply
* Re: [PATCH] Documentation/security-bugs: provide more information about linux-distros
From: Will Deacon @ 2019-07-11 17:09 UTC (permalink / raw)
To: Greg KH
Cc: Sasha Levin, corbet, solar, keescook, peterz, tyhicks, linux-doc,
linux-kernel
In-Reply-To: <20190711170732.GB7544@kroah.com>
On Thu, Jul 11, 2019 at 07:07:32PM +0200, Greg KH wrote:
> On Thu, Jul 11, 2019 at 12:36:37PM -0400, Sasha Levin wrote:
> > Provide more information about how to interact with the linux-distros
> > mailing list for disclosing security bugs.
> >
> > First, clarify that the reporter must read and accept the linux-distros
> > policies prior to sending a report.
> >
> > Second, clarify that the reported must provide a tentative public
> > disclosure date and time in his first contact with linux-distros.
> >
> > Suggested-by: Solar Designer <solar@openwall.com>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> > Documentation/admin-guide/security-bugs.rst | 21 +++++++++++++--------
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> > index dcd6c93c7aac..c62faced9256 100644
> > --- a/Documentation/admin-guide/security-bugs.rst
> > +++ b/Documentation/admin-guide/security-bugs.rst
> > @@ -61,14 +61,19 @@ Coordination
> >
> > Fixes for sensitive bugs, such as those that might lead to privilege
> > escalations, may need to be coordinated with the private
> > -<linux-distros@vs.openwall.org> mailing list so that distribution vendors
> > -are well prepared to issue a fixed kernel upon public disclosure of the
> > -upstream fix. Distros will need some time to test the proposed patch and
> > -will generally request at least a few days of embargo, and vendor update
> > -publication prefers to happen Tuesday through Thursday. When appropriate,
> > -the security team can assist with this coordination, or the reporter can
> > -include linux-distros from the start. In this case, remember to prefix
> > -the email Subject line with "[vs]" as described in the linux-distros wiki:
> > +<linux-distros@vs.openwall.org> mailing list so that distribution vendors are
> > +well prepared to issue a fixed kernel upon public disclosure of the upstream
> > +fix. As a reporter, you must read and accept the list's policy as outlined in
> > +the linux-distros wiki:
> > +<https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters>.
> > +When you report a bug, you must also provide a tentative disclosure date and
> > +time in your very first message to the list. Distros will need some time to
> > +test the proposed patch so please allow at least a few days of embargo, and
> > +vendor update publication prefers to happen Tuesday through Thursday. When
> > +appropriate, the security team can assist with this coordination, or the
> > +reporter can include linux-distros from the start. In this case, remember to
> > +prefix the email Subject line with "[vs]" as described in the linux-distros
> > +wiki:
> > <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
>
> Do we really need to describe all of the information on how to use the
> distro list here? That's why we included the link, as it has all of
> this well spelled out and described. If anything, I would say we should
> say less in this document about what linux-distros do, as that is
> independent of the Linux security team.
Agreed, and it also means that any changes linux-distros make to their
policy won't be reflecting in the numerous kernel trees out there, so a
link is much better imo.
Will
^ permalink raw reply
* Re: [PATCH] Documentation/security-bugs: provide more information about linux-distros
From: Greg KH @ 2019-07-11 17:07 UTC (permalink / raw)
To: Sasha Levin
Cc: corbet, solar, will, keescook, peterz, tyhicks, linux-doc,
linux-kernel
In-Reply-To: <20190711163637.30327-1-sashal@kernel.org>
On Thu, Jul 11, 2019 at 12:36:37PM -0400, Sasha Levin wrote:
> Provide more information about how to interact with the linux-distros
> mailing list for disclosing security bugs.
>
> First, clarify that the reporter must read and accept the linux-distros
> policies prior to sending a report.
>
> Second, clarify that the reported must provide a tentative public
> disclosure date and time in his first contact with linux-distros.
>
> Suggested-by: Solar Designer <solar@openwall.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> Documentation/admin-guide/security-bugs.rst | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
> index dcd6c93c7aac..c62faced9256 100644
> --- a/Documentation/admin-guide/security-bugs.rst
> +++ b/Documentation/admin-guide/security-bugs.rst
> @@ -61,14 +61,19 @@ Coordination
>
> Fixes for sensitive bugs, such as those that might lead to privilege
> escalations, may need to be coordinated with the private
> -<linux-distros@vs.openwall.org> mailing list so that distribution vendors
> -are well prepared to issue a fixed kernel upon public disclosure of the
> -upstream fix. Distros will need some time to test the proposed patch and
> -will generally request at least a few days of embargo, and vendor update
> -publication prefers to happen Tuesday through Thursday. When appropriate,
> -the security team can assist with this coordination, or the reporter can
> -include linux-distros from the start. In this case, remember to prefix
> -the email Subject line with "[vs]" as described in the linux-distros wiki:
> +<linux-distros@vs.openwall.org> mailing list so that distribution vendors are
> +well prepared to issue a fixed kernel upon public disclosure of the upstream
> +fix. As a reporter, you must read and accept the list's policy as outlined in
> +the linux-distros wiki:
> +<https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters>.
> +When you report a bug, you must also provide a tentative disclosure date and
> +time in your very first message to the list. Distros will need some time to
> +test the proposed patch so please allow at least a few days of embargo, and
> +vendor update publication prefers to happen Tuesday through Thursday. When
> +appropriate, the security team can assist with this coordination, or the
> +reporter can include linux-distros from the start. In this case, remember to
> +prefix the email Subject line with "[vs]" as described in the linux-distros
> +wiki:
> <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
Do we really need to describe all of the information on how to use the
distro list here? That's why we included the link, as it has all of
this well spelled out and described. If anything, I would say we should
say less in this document about what linux-distros do, as that is
independent of the Linux security team.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v6 0/6] KASan for arm
From: Florian Fainelli @ 2019-07-11 17:00 UTC (permalink / raw)
To: Linus Walleij, Florian Fainelli, Arnd Bergmann
Cc: Linux ARM, bcm-kernel-feedback-list, Alexander Potapenko,
Dmitry Vyukov, Jonathan Corbet, Russell King, christoffer.dall,
Marc Zyngier, Nicolas Pitre, Vladimir Murzin, Kees Cook,
jinb.park7, Alexandre Belloni, Ard Biesheuvel, Daniel Lezcano,
Philippe Ombredanne, liuwenliang, Rob Landley, Greg KH,
Andrew Morton, Mark Rutland, Catalin Marinas, Masahiro Yamada,
Thomas Gleixner, thgarnie, David Howells, Geert Uytterhoeven,
Andre Przywara, julien.thierry, drjones, philip, mhocko,
kirill.shutemov, kasan-dev, Linux Doc Mailing List,
linux-kernel@vger.kernel.org, kvmarm, Andrey Ryabinin
In-Reply-To: <CACRpkdbqW2kJNdPi6JPupaHA_qRTWG-MsUxeCz0c38MRujOSSA@mail.gmail.com>
On 7/2/19 2:06 PM, Linus Walleij wrote:
> Hi Florian,
>
> On Tue, Jun 18, 2019 at 12:11 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> Abbott submitted a v5 about a year ago here:
>>
>> and the series was not picked up since then, so I rebased it against
>> v5.2-rc4 and re-tested it on a Brahma-B53 (ARMv8 running AArch32 mode)
>> and Brahma-B15, both LPAE and test-kasan is consistent with the ARM64
>> counter part.
>>
>> We were in a fairly good shape last time with a few different people
>> having tested it, so I am hoping we can get that included for 5.4 if
>> everything goes well.
>
> Thanks for picking this up. I was trying out KASan in the past,
> got sidetracked and honestly lost interest a bit because it was
> boring. But I do realize that it is really neat, so I will try to help
> out with some review and test on a bunch of hardware I have.
>
> At one point I even had this running on the ARMv4 SA1100
> (no joke!) and if I recall correctly, I got stuck because of things
> that might very well have been related to using a very fragile
> Arm testchip that later broke down completely in the l2cache
> when we added the spectre/meltdown fixes.
A blast from the past!
>
> I start reviewing and testing.
Great, thanks a lot for taking a look. FYI, I will be on holiday from
July 19th till August 12th, if you think you have more feedback between
now and then, I can try to pick it up and submit a v7 with that feedback
addressed, or it will happen when I return, or you can pick it up if you
refer, all options are possible!
@Arnd, should we squash your patches in as well?
--
Florian
^ permalink raw reply
* Re: [PATCH v6 1/6] ARM: Add TTBR operator for kasan_init
From: Florian Fainelli @ 2019-07-11 16:54 UTC (permalink / raw)
To: Linus Walleij, Russell King
Cc: Linux ARM, bcm-kernel-feedback-list, Abbott Liu, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Jonathan Corbet, Russell King,
christoffer.dall, Marc Zyngier, Arnd Bergmann, Nicolas Pitre,
Vladimir Murzin, Kees Cook, jinb.park7, Alexandre Belloni,
Ard Biesheuvel, Daniel Lezcano, Philippe Ombredanne, Rob Landley,
Greg KH, Andrew Morton, Mark Rutland, Catalin Marinas,
Masahiro Yamada, Thomas Gleixner, thgarnie, David Howells,
Geert Uytterhoeven, Andre Przywara, julien.thierry, drjones,
philip, mhocko, kirill.shutemov, kasan-dev,
Linux Doc Mailing List, linux-kernel@vger.kernel.org, kvmarm,
Andrey Ryabinin
In-Reply-To: <CACRpkdZGqiiax2m5L1y3=Enw0Q5cLc-idAQNae34uenf-drHDw@mail.gmail.com>
On 7/2/19 2:03 PM, Linus Walleij wrote:
> Hi Florian!
>
> thanks for your patch!
>
> On Tue, Jun 18, 2019 at 12:11 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> From: Abbott Liu <liuwenliang@huawei.com>
>>
>> The purpose of this patch is to provide set_ttbr0/get_ttbr0 to
>> kasan_init function. The definitions of cp15 registers should be in
>> arch/arm/include/asm/cp15.h rather than arch/arm/include/asm/kvm_hyp.h,
>> so move them.
>>
>> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
>> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
>> +#include <linux/stringify.h>
>
> What is this for? I think it can be dropped.
Indeed, that can be dropped came from an earlier version of the patch.
>
> This stuff adding a whole bunch of accessors:
>
>> +static inline void set_par(u64 val)
>> +{
>> + if (IS_ENABLED(CONFIG_ARM_LPAE))
>> + write_sysreg(val, PAR_64);
>> + else
>> + write_sysreg(val, PAR_32);
>> +}
>
> Can we put that in a separate patch since it is not
> adding any users, so this is a pure refactoring patch for
> the current code?
Sure, that makes sense, first move all definitions, then add helper
functions, finally make use of them.
--
Florian
^ permalink raw reply
* Re: [PATCH v6 2/6] ARM: Disable instrumentation for some code
From: Florian Fainelli @ 2019-07-11 16:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux ARM, bcm-kernel-feedback-list, Andrey Ryabinin, Abbott Liu,
Alexander Potapenko, Dmitry Vyukov, Jonathan Corbet, Russell King,
christoffer.dall, Marc Zyngier, Arnd Bergmann, Nicolas Pitre,
Vladimir Murzin, Kees Cook, jinb.park7, Alexandre Belloni,
Ard Biesheuvel, Daniel Lezcano, Philippe Ombredanne, Rob Landley,
Greg KH, Andrew Morton, Mark Rutland, Catalin Marinas,
Masahiro Yamada, Thomas Gleixner, thgarnie, David Howells,
Geert Uytterhoeven, Andre Przywara, julien.thierry, drjones,
philip, mhocko, kirill.shutemov, kasan-dev,
Linux Doc Mailing List, linux-kernel@vger.kernel.org, kvmarm,
Andrey Ryabinin
In-Reply-To: <CACRpkdb3P6oQTK9FGUkMj4kax8us3rKH6c36pX=HD1_wMqcoJQ@mail.gmail.com>
On 7/2/19 2:56 PM, Linus Walleij wrote:
> On Tue, Jun 18, 2019 at 12:11 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> @@ -236,7 +236,8 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
>> if (*vsp >= (unsigned long *)ctrl->sp_high)
>> return -URC_FAILURE;
>>
>> - ctrl->vrs[reg] = *(*vsp)++;
>> + ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
>> + (*vsp)++;
>
> I would probably even put in a comment here so it is clear why we
> do this. Passers-by may not know that READ_ONCE_NOCHECK() is
> even related to KASan.
Makes sense, I will add that, thanks!
>
> Other than that,
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
>
--
Florian
^ permalink raw reply
* [PATCH] Documentation: coresight: convert txt to rst
From: Phong Tran @ 2019-07-11 16:52 UTC (permalink / raw)
To: corbet, mathieu.poirier, mchehab, leo.yan, marc.w.gonzalez
Cc: tranmanphong, linux-arm-kernel, linux-doc, linux-kernel-mentees,
linux-kernel, skhan, suzuki.poulose
In-Reply-To: <20190705204512.15444-1-tranmanphong@gmail.com>
This changes from plain text to reStructuredText as suggestion
in doc-guide [1]
[1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html
Some adaptations such as: literal block, ``inline literal`` and
alignment text,...
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
ChangeLog:
V2: review points from Mathieu, Jonathan
* Add coresight-cpu-debug
* Update MAINTAINERS file
* Avoid use markup as much as posible
V3: review points from Mauro
* add the colon author, date
* change to use ```` in the struct
* add line for the acronyms
V4:
* Rebase on linux-next tree
V5:
* Improve the commit message
---
...sight-cpu-debug.txt => coresight-cpu-debug.rst} | 67 ++--
.../trace/{coresight.txt => coresight.rst} | 372 +++++++++++----------
Documentation/trace/index.rst | 2 +
MAINTAINERS | 4 +-
4 files changed, 234 insertions(+), 211 deletions(-)
rename Documentation/trace/{coresight-cpu-debug.txt => coresight-cpu-debug.rst} (84%)
rename Documentation/trace/{coresight.txt => coresight.rst} (56%)
diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.rst
similarity index 84%
rename from Documentation/trace/coresight-cpu-debug.txt
rename to Documentation/trace/coresight-cpu-debug.rst
index 1a660a39e3c0..993dd294b81b 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.rst
@@ -1,8 +1,9 @@
- Coresight CPU Debug Module
- ==========================
+==========================
+Coresight CPU Debug Module
+==========================
- Author: Leo Yan <leo.yan@linaro.org>
- Date: April 5th, 2017
+ :Author: Leo Yan <leo.yan@linaro.org>
+ :Date: April 5th, 2017
Introduction
------------
@@ -69,6 +70,7 @@ Before accessing debug registers, we should ensure the clock and power domain
have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
Debug registers', the debug registers are spread into two domains: the debug
domain and the CPU domain.
+::
+---------------+
| |
@@ -125,18 +127,21 @@ If you want to enable debugging functionality at boot time, you can add
"coresight_cpu_debug.enable=1" to the kernel command line parameter.
The driver also can work as module, so can enable the debugging when insmod
-module:
-# insmod coresight_cpu_debug.ko debug=1
+module::
+
+ # insmod coresight_cpu_debug.ko debug=1
When boot time or insmod module you have not enabled the debugging, the driver
uses the debugfs file system to provide a knob to dynamically enable or disable
debugging:
-To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
+To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable::
+
+ # echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
+
+To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable::
-To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
-# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
+ # echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
As explained in chapter "Clock and power domain", if you are working on one
platform which has idle states to power off debug logic and the power
@@ -154,34 +159,34 @@ subsystem, more specifically by using the "/dev/cpu_dma_latency"
interface (see Documentation/power/pm_qos_interface.rst for more
details). As specified in the PM QoS documentation the requested
parameter will stay in effect until the file descriptor is released.
-For example:
+For example::
-# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
-...
-Do some work...
-...
-# exec 3<>-
+ # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
+ ...
+ Do some work...
+ ...
+ # exec 3<>-
The same can also be done from an application program.
Disable specific CPU's specific idle state from cpuidle sysfs (see
-Documentation/admin-guide/pm/cpuidle.rst):
-# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
+Documentation/admin-guide/pm/cpuidle.rst)::
+ # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
Output format
-------------
-Here is an example of the debugging output format:
-
-ARM external debug module:
-coresight-cpu-debug 850000.debug: CPU[0]:
-coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
-coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
-coresight-cpu-debug 852000.debug: CPU[1]:
-coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
-coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
-coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
-coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
+Here is an example of the debugging output format::
+
+ ARM external debug module:
+ coresight-cpu-debug 850000.debug: CPU[0]:
+ coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+ coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
+ coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
+ coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
+ coresight-cpu-debug 852000.debug: CPU[1]:
+ coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
+ coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
+ coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
+ coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
similarity index 56%
rename from Documentation/trace/coresight.txt
rename to Documentation/trace/coresight.rst
index b027d61b27a6..72f4b7ef1bad 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.rst
@@ -1,8 +1,9 @@
- Coresight - HW Assisted Tracing on ARM
- ======================================
+======================================
+Coresight - HW Assisted Tracing on ARM
+======================================
- Author: Mathieu Poirier <mathieu.poirier@linaro.org>
- Date: September 11th, 2014
+ :Author: Mathieu Poirier <mathieu.poirier@linaro.org>
+ :Date: September 11th, 2014
Introduction
------------
@@ -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,15 +96,24 @@ Acronyms and Classification
Acronyms:
-PTM: Program Trace Macrocell
-ETM: Embedded Trace Macrocell
-STM: System trace Macrocell
-ETB: Embedded Trace Buffer
-ITM: Instrumentation Trace Macrocell
-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
+PTM:
+ Program Trace Macrocell
+ETM:
+ Embedded Trace Macrocell
+STM:
+ System trace Macrocell
+ETB:
+ Embedded Trace Buffer
+ITM:
+ Instrumentation Trace Macrocell
+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 +128,7 @@ Misc:
Device Tree Bindings
-----------------------
+--------------------
See Documentation/devicetree/bindings/arm/coresight.txt for details.
@@ -133,79 +143,79 @@ 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
-register the device with the core framework. The unregister function takes
-a reference to a "struct coresight_device", obtained at registration time.
+The registering function is taking a ``struct coresight_desc *desc`` and
+register the device with the core framework. The unregister function takes
+a reference to a ``struct coresight_device *csdev`` 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:
+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:~#
+ root:~# ls /sys/bus/coresight/devices/
+ replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+ 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+ root:~#
-The functions take a "struct coresight_device", which looks like this:
+The functions take a ``struct coresight_device``, which looks like this::
-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;
-};
+ 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 ``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 ``struct coresight_ops_sink``,
+``struct coresight_ops_link`` and ``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 ``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``::
-static int etm_probe(struct amba_device *adev, const struct amba_id *id)
-{
- ...
- ...
- drvdata->dev = &adev->dev;
- ...
-}
+ 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 ``struct coresight_ops``). The ``**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.
-
Device Naming scheme
-------------------------
+--------------------
+
The devices that appear on the "coresight" bus were named the same as their
parent devices, i.e, the real devices that appears on AMBA bus or the platform bus.
Thus the names were based on the Linux Open Firmware layer naming convention,
which follows the base physical address of the device followed by the device
-type. e.g:
+type. e.g::
-root:~# ls /sys/bus/coresight/devices/
- 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
- 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
- 20070000.etr 20120000.replicator 220c0000.funnel
- 23040000.etm 23140000.etm 23340000.etm
+ root:~# ls /sys/bus/coresight/devices/
+ 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
+ 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
+ 20070000.etr 20120000.replicator 220c0000.funnel
+ 23040000.etm 23140000.etm 23340000.etm
However, with the introduction of ACPI support, the names of the real
devices are a bit cryptic and non-obvious. Thus, a new naming scheme was
introduced to use more generic names based on the type of the device. The
-following rules apply:
+following rules apply::
1) Devices that are bound to CPUs, are named based on the CPU logical
number.
@@ -220,11 +230,11 @@ following rules apply:
e.g, tmc_etf0, tmc_etr0, funnel0, funnel1
-Thus, with the new scheme the devices could appear as :
+Thus, with the new scheme the devices could appear as ::
-root:~# ls /sys/bus/coresight/devices/
- etm0 etm1 etm2 etm3 etm4 etm5 funnel0
- funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
+ root:~# ls /sys/bus/coresight/devices/
+ etm0 etm1 etm2 etm3 etm4 etm5 funnel0
+ funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
Some of the examples below might refer to old naming scheme and some
to the newer scheme, to give a confirmation that what you see on your
@@ -234,9 +244,12 @@ the system under specified locations.
How to use the tracer modules
-----------------------------
-There are two ways to use the Coresight framework: 1) using the perf cmd line
-tools and 2) interacting directly with the Coresight devices using the sysFS
-interface. Preference is given to the former as using the sysFS interface
+There are two ways to use the Coresight framework:
+
+1. using the perf cmd line tools.
+2. interacting directly with the Coresight devices using the sysFS interface.
+
+Preference is given to the former as using the sysFS interface
requires a deep understanding of the Coresight HW. The following sections
provide details on using both methods.
@@ -245,107 +258,107 @@ provide details on using both methods.
Before trace collection can start, a coresight sink needs to be identified.
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#
+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#
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#
-
-Trace collection is stopped the same way:
-
-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
-
-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#
+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#
+
+Trace collection is stopped the same way::
+
+ 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
+ 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.
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
+::
+
+ 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:
@@ -370,19 +383,18 @@ A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
listed along with configuration options within forward slashes '/'. Since a
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.
-On newer kernels the available sinks are listed in sysFS under:
-($SYSFS)/bus/event_source/devices/cs_etm/sinks/
+On newer kernels the available sinks are listed in sysFS under
+($SYSFS)/bus/event_source/devices/cs_etm/sinks/::
root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls
tmc_etf0 tmc_etr0 tpiu0
On older kernels, this may need to be found from the list of coresight devices,
-available under ($SYSFS)/bus/coresight/devices/:
+available under ($SYSFS)/bus/coresight/devices/::
root:~# ls /sys/bus/coresight/devices/
etm0 etm1 etm2 etm3 etm4 etm5 funnel0
funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
-
root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread program
As mentioned above in section "Device Naming scheme", the names of the devices could
@@ -395,14 +407,14 @@ 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:
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:
+specifying the name of the sink to record to, e.g::
perf record -e cs_etm/@tmc_etr0/u --per-thread
@@ -421,12 +433,14 @@ 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.
+::
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).
+::
$ gcc-5 -O3 sort.c -o sort
$ taskset -c 2 ./sort
@@ -455,28 +469,30 @@ 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/stm0
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root@genericarmv8:~#
+ root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
+ 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:
+being used::
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/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:
+interface provided for that purpose by the generic STM API::
+
+ root@genericarmv8:~# ls -l /dev/stm0
+ crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
+ root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [#second]_.
-root@genericarmv8:~# ls -l /dev/stm0
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
-root@genericarmv8:~#
+.. [#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..b7891cb1ab4d 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -23,3 +23,5 @@ Linux Tracing Technologies
intel_th
stm
sys-t
+ coresight
+ coresight-cpu-debug
diff --git a/MAINTAINERS b/MAINTAINERS
index 661def85619c..eb03e5966f11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1582,8 +1582,8 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/hwtracing/coresight/*
-F: Documentation/trace/coresight.txt
-F: Documentation/trace/coresight-cpu-debug.txt
+F: Documentation/trace/coresight.rst
+F: Documentation/trace/coresight-cpu-debug.rst
F: Documentation/devicetree/bindings/arm/coresight.txt
F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
--
2.11.0
^ permalink raw reply related
* [PATCH] Documentation/security-bugs: provide more information about linux-distros
From: Sasha Levin @ 2019-07-11 16:36 UTC (permalink / raw)
To: corbet, solar
Cc: will, keescook, peterz, gregkh, tyhicks, linux-doc, linux-kernel,
Sasha Levin
Provide more information about how to interact with the linux-distros
mailing list for disclosing security bugs.
First, clarify that the reporter must read and accept the linux-distros
policies prior to sending a report.
Second, clarify that the reported must provide a tentative public
disclosure date and time in his first contact with linux-distros.
Suggested-by: Solar Designer <solar@openwall.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/admin-guide/security-bugs.rst | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index dcd6c93c7aac..c62faced9256 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -61,14 +61,19 @@ Coordination
Fixes for sensitive bugs, such as those that might lead to privilege
escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
+<linux-distros@vs.openwall.org> mailing list so that distribution vendors are
+well prepared to issue a fixed kernel upon public disclosure of the upstream
+fix. As a reporter, you must read and accept the list's policy as outlined in
+the linux-distros wiki:
+<https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters>.
+When you report a bug, you must also provide a tentative disclosure date and
+time in your very first message to the list. Distros will need some time to
+test the proposed patch so please allow at least a few days of embargo, and
+vendor update publication prefers to happen Tuesday through Thursday. When
+appropriate, the security team can assist with this coordination, or the
+reporter can include linux-distros from the start. In this case, remember to
+prefix the email Subject line with "[vs]" as described in the linux-distros
+wiki:
<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
CVE assignment
--
2.20.1
^ permalink raw reply related
* Re: [Patch V4] Documentation: coresight: covert txt to rst
From: Marc Gonzalez @ 2019-07-11 16:26 UTC (permalink / raw)
To: Phong Tran, corbet, leo.yan, mathieu.poirier, mchehab
Cc: linux-arm-kernel, linux-doc, linux-kernel-mentees, linux-kernel,
skhan, suzuki.poulose
In-Reply-To: <20190710150133.13992-1-tranmanphong@gmail.com>
On 10/07/2019 17:01, Phong Tran wrote:
> Subject: [Patch V4] Documentation: coresight: covert txt to rst
Typo in patch subject.
s/covert/convert
^ permalink raw reply
* Re: [Patch V4] Documentation: coresight: covert txt to rst
From: Mathieu Poirier @ 2019-07-11 16:18 UTC (permalink / raw)
To: Phong Tran
Cc: Jon Corbet, Leo Yan, mchehab, linux-arm-kernel,
open list:DOCUMENTATION, linux-kernel-mentees,
Linux Kernel Mailing List, skhan, Suzuki K. Poulose
In-Reply-To: <20190710150133.13992-1-tranmanphong@gmail.com>
On Wed, 10 Jul 2019 at 09:01, Phong Tran <tranmanphong@gmail.com> wrote:
>
> as doc-guide of kernel documentation, use Sphinx tool to
> generate the html/pdf... files.
>
> This changes the plan text txt to rst format.
>
I agree with Mauro - although the changelong has already been improved
it is still below the minimum requirements.
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
As for the content of the patch:
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> ChangeLog:
> V2: review points from Mathieu, Jonathan
> * Add coresight-cpu-debug
> * Update MAINTAINERS file
> * Avoid use markup as much as posible
> V3: review points from Mauro
> * add the colon author, date
> * change to use ```` in the struct
> * add line for the acronyms
> V4:
> * Rebase on linux-next tree
> ---
> ...sight-cpu-debug.txt => coresight-cpu-debug.rst} | 67 ++--
> .../trace/{coresight.txt => coresight.rst} | 372 +++++++++++----------
> Documentation/trace/index.rst | 2 +
> MAINTAINERS | 4 +-
> 4 files changed, 234 insertions(+), 211 deletions(-)
> rename Documentation/trace/{coresight-cpu-debug.txt => coresight-cpu-debug.rst} (84%)
> rename Documentation/trace/{coresight.txt => coresight.rst} (56%)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.rst
> similarity index 84%
> rename from Documentation/trace/coresight-cpu-debug.txt
> rename to Documentation/trace/coresight-cpu-debug.rst
> index 1a660a39e3c0..993dd294b81b 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.rst
> @@ -1,8 +1,9 @@
> - Coresight CPU Debug Module
> - ==========================
> +==========================
> +Coresight CPU Debug Module
> +==========================
>
> - Author: Leo Yan <leo.yan@linaro.org>
> - Date: April 5th, 2017
> + :Author: Leo Yan <leo.yan@linaro.org>
> + :Date: April 5th, 2017
>
> Introduction
> ------------
> @@ -69,6 +70,7 @@ Before accessing debug registers, we should ensure the clock and power domain
> have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
> Debug registers', the debug registers are spread into two domains: the debug
> domain and the CPU domain.
> +::
>
> +---------------+
> | |
> @@ -125,18 +127,21 @@ If you want to enable debugging functionality at boot time, you can add
> "coresight_cpu_debug.enable=1" to the kernel command line parameter.
>
> The driver also can work as module, so can enable the debugging when insmod
> -module:
> -# insmod coresight_cpu_debug.ko debug=1
> +module::
> +
> + # insmod coresight_cpu_debug.ko debug=1
>
> When boot time or insmod module you have not enabled the debugging, the driver
> uses the debugfs file system to provide a knob to dynamically enable or disable
> debugging:
>
> -To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable::
> +
> + # echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable::
>
> -To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
> + # echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
>
> As explained in chapter "Clock and power domain", if you are working on one
> platform which has idle states to power off debug logic and the power
> @@ -154,34 +159,34 @@ subsystem, more specifically by using the "/dev/cpu_dma_latency"
> interface (see Documentation/power/pm_qos_interface.rst for more
> details). As specified in the PM QoS documentation the requested
> parameter will stay in effect until the file descriptor is released.
> -For example:
> +For example::
>
> -# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> -...
> -Do some work...
> -...
> -# exec 3<>-
> + # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> + ...
> + Do some work...
> + ...
> + # exec 3<>-
>
> The same can also be done from an application program.
>
> Disable specific CPU's specific idle state from cpuidle sysfs (see
> -Documentation/admin-guide/pm/cpuidle.rst):
> -# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> +Documentation/admin-guide/pm/cpuidle.rst)::
>
> + # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>
> Output format
> -------------
>
> -Here is an example of the debugging output format:
> -
> -ARM external debug module:
> -coresight-cpu-debug 850000.debug: CPU[0]:
> -coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> -coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> -coresight-cpu-debug 852000.debug: CPU[1]:
> -coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> -coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> +Here is an example of the debugging output format::
> +
> + ARM external debug module:
> + coresight-cpu-debug 850000.debug: CPU[0]:
> + coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> + coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> + coresight-cpu-debug 852000.debug: CPU[1]:
> + coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> + coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
> similarity index 56%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index b027d61b27a6..72f4b7ef1bad 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,8 +1,9 @@
> - Coresight - HW Assisted Tracing on ARM
> - ======================================
> +======================================
> +Coresight - HW Assisted Tracing on ARM
> +======================================
>
> - Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> - Date: September 11th, 2014
> + :Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> + :Date: September 11th, 2014
>
> Introduction
> ------------
> @@ -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,15 +96,24 @@ Acronyms and Classification
>
> Acronyms:
>
> -PTM: Program Trace Macrocell
> -ETM: Embedded Trace Macrocell
> -STM: System trace Macrocell
> -ETB: Embedded Trace Buffer
> -ITM: Instrumentation Trace Macrocell
> -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
> +PTM:
> + Program Trace Macrocell
> +ETM:
> + Embedded Trace Macrocell
> +STM:
> + System trace Macrocell
> +ETB:
> + Embedded Trace Buffer
> +ITM:
> + Instrumentation Trace Macrocell
> +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 +128,7 @@ Misc:
>
>
> Device Tree Bindings
> -----------------------
> +--------------------
>
> See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,79 +143,79 @@ 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
> -register the device with the core framework. The unregister function takes
> -a reference to a "struct coresight_device", obtained at registration time.
> +The registering function is taking a ``struct coresight_desc *desc`` and
> +register the device with the core framework. The unregister function takes
> +a reference to a ``struct coresight_device *csdev`` 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:
> +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:~#
> + root:~# ls /sys/bus/coresight/devices/
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:~#
>
> -The functions take a "struct coresight_device", which looks like this:
> +The functions take a ``struct coresight_device``, which looks like this::
>
> -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;
> -};
> + 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 ``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 ``struct coresight_ops_sink``,
> +``struct coresight_ops_link`` and ``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 ``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``::
>
> -static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> -{
> - ...
> - ...
> - drvdata->dev = &adev->dev;
> - ...
> -}
> + 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 ``struct coresight_ops``). The ``**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.
>
> -
> Device Naming scheme
> -------------------------
> +--------------------
> +
> The devices that appear on the "coresight" bus were named the same as their
> parent devices, i.e, the real devices that appears on AMBA bus or the platform bus.
> Thus the names were based on the Linux Open Firmware layer naming convention,
> which follows the base physical address of the device followed by the device
> -type. e.g:
> +type. e.g::
>
> -root:~# ls /sys/bus/coresight/devices/
> - 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> - 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> - 20070000.etr 20120000.replicator 220c0000.funnel
> - 23040000.etm 23140000.etm 23340000.etm
> + root:~# ls /sys/bus/coresight/devices/
> + 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> + 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> + 20070000.etr 20120000.replicator 220c0000.funnel
> + 23040000.etm 23140000.etm 23340000.etm
>
> However, with the introduction of ACPI support, the names of the real
> devices are a bit cryptic and non-obvious. Thus, a new naming scheme was
> introduced to use more generic names based on the type of the device. The
> -following rules apply:
> +following rules apply::
>
> 1) Devices that are bound to CPUs, are named based on the CPU logical
> number.
> @@ -220,11 +230,11 @@ following rules apply:
>
> e.g, tmc_etf0, tmc_etr0, funnel0, funnel1
>
> -Thus, with the new scheme the devices could appear as :
> +Thus, with the new scheme the devices could appear as ::
>
> -root:~# ls /sys/bus/coresight/devices/
> - etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> - funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> + root:~# ls /sys/bus/coresight/devices/
> + etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> + funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
>
> Some of the examples below might refer to old naming scheme and some
> to the newer scheme, to give a confirmation that what you see on your
> @@ -234,9 +244,12 @@ the system under specified locations.
> How to use the tracer modules
> -----------------------------
>
> -There are two ways to use the Coresight framework: 1) using the perf cmd line
> -tools and 2) interacting directly with the Coresight devices using the sysFS
> -interface. Preference is given to the former as using the sysFS interface
> +There are two ways to use the Coresight framework:
> +
> +1. using the perf cmd line tools.
> +2. interacting directly with the Coresight devices using the sysFS interface.
> +
> +Preference is given to the former as using the sysFS interface
> requires a deep understanding of the Coresight HW. The following sections
> provide details on using both methods.
>
> @@ -245,107 +258,107 @@ provide details on using both methods.
> Before trace collection can start, a coresight sink needs to be identified.
> 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#
> +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#
>
> 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#
> -
> -Trace collection is stopped the same way:
> -
> -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
> -
> -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#
> +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#
> +
> +Trace collection is stopped the same way::
> +
> + 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
> + 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.
>
> 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
> +::
> +
> + 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:
>
> @@ -370,19 +383,18 @@ A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
> listed along with configuration options within forward slashes '/'. Since a
> 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.
> -On newer kernels the available sinks are listed in sysFS under:
> -($SYSFS)/bus/event_source/devices/cs_etm/sinks/
> +On newer kernels the available sinks are listed in sysFS under
> +($SYSFS)/bus/event_source/devices/cs_etm/sinks/::
>
> root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls
> tmc_etf0 tmc_etr0 tpiu0
>
> On older kernels, this may need to be found from the list of coresight devices,
> -available under ($SYSFS)/bus/coresight/devices/:
> +available under ($SYSFS)/bus/coresight/devices/::
>
> root:~# ls /sys/bus/coresight/devices/
> etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> -
> root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread program
>
> As mentioned above in section "Device Naming scheme", the names of the devices could
> @@ -395,14 +407,14 @@ 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:
>
> 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:
> +specifying the name of the sink to record to, e.g::
>
> perf record -e cs_etm/@tmc_etr0/u --per-thread
>
> @@ -421,12 +433,14 @@ 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.
> +::
>
> 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).
> +::
>
> $ gcc-5 -O3 sort.c -o sort
> $ taskset -c 2 ./sort
> @@ -455,28 +469,30 @@ 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/stm0
> -enable_source hwevent_select port_enable subsystem uevent
> -hwevent_enable mgmt port_select traceid
> -root@genericarmv8:~#
> + root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
> + 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:
> +being used::
>
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/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:
> +interface provided for that purpose by the generic STM API::
> +
> + root@genericarmv8:~# ls -l /dev/stm0
> + crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> + root@genericarmv8:~#
> +
> +Details on how to use the generic STM API can be found here [#second]_.
>
> -root@genericarmv8:~# ls -l /dev/stm0
> -crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> -root@genericarmv8:~#
> +.. [#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..b7891cb1ab4d 100644
> --- a/Documentation/trace/index.rst
> +++ b/Documentation/trace/index.rst
> @@ -23,3 +23,5 @@ Linux Tracing Technologies
> intel_th
> stm
> sys-t
> + coresight
> + coresight-cpu-debug
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 661def85619c..eb03e5966f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1582,8 +1582,8 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: drivers/hwtracing/coresight/*
> -F: Documentation/trace/coresight.txt
> -F: Documentation/trace/coresight-cpu-debug.txt
> +F: Documentation/trace/coresight.rst
> +F: Documentation/trace/coresight-cpu-debug.rst
> F: Documentation/devicetree/bindings/arm/coresight.txt
> F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
> --
> 2.11.0
>
^ 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