linux-kernel - linux-next: manual merge of the tip tree with the jc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20180314135831.065098e8@canb.auug.org.au>
Date:   Wed, 14 Mar 2018 13:58:31 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jonathan Corbet <corbet@....net>
Cc:     Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Changbin Du <changbin.du@...el.com>
Subject: linux-next: manual merge of the tip tree with the jc_docs tree

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  Documentation/trace/ftrace.txt

between commit:

  1f198e22bc3a ("trace doc: convert trace/ftrace.txt to rst format")

from the jc_docs tree and commit:

  92af4dcb4e1c ("tracing: Unify the "boot" and "mono" tracing clocks")

from the tip tree.

I fixed it up (the former moved the file, so I added the following patch)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell <sfr@...b.auug.org.au>
Date: Wed, 14 Mar 2018 13:53:45 +1100
Subject: [PATCH] trace doc: merge fix for "tracing: Unify the "boot" and
 "mono" tracing clocks"

Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
---
 Documentation/trace/ftrace.rst | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 0bc33ad4a3f9..55637926abdc 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -461,17 +461,9 @@ of ftrace. Here is a list of some of the key files:
 		and ticks at the same rate as the hardware clocksource.
 
 	boot:
-		This is the boot clock (CLOCK_BOOTTIME) and is based on the
-		fast monotonic clock, but also accounts for time spent in
-		suspend. Since the clock access is designed for use in
-		tracing in the suspend path, some side effects are possible
-		if clock is accessed after the suspend time is accounted before
-		the fast mono clock is updated. In this case, the clock update
-		appears to happen slightly sooner than it normally would have.
-		Also on 32-bit systems, it's possible that the 64-bit boot offset
-		sees a partial update. These effects are rare and post
-		processing should be able to handle them. See comments in the
-		ktime_get_boot_fast_ns() function for more information.
+		Same as mono. Used to be a separate clock which accounted
+		for the time spent in suspend while CLOCK_MONOTONIC did
+		not.
 
 		To set a clock, simply echo the clock name into this file::
 
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped