linux56-tkg: 5.6.14

This commit is contained in:
Tk-Glitch 2020-05-20 14:29:28 +02:00
parent 5e54a35cfd
commit f834625339
2 changed files with 5 additions and 413 deletions

View File

@ -87,9 +87,9 @@ else
fi
pkgname=("${pkgbase}" "${pkgbase}-headers")
_basekernel=5.6
_sub=13
_sub=14
pkgver="${_basekernel}"."${_sub}"
pkgrel=30
pkgrel=31
pkgdesc='Linux-tkg'
arch=('x86_64') # no i686 in here
url="http://www.kernel.org/"
@ -125,14 +125,14 @@ source=("https://www.kernel.org/pub/linux/kernel/v5.x/linux-${_basekernel}.tar.x
0012-linux-hardened.patch # https://github.com/anthraxx/linux-hardened
)
sha256sums=('e342b04a2aa63808ea0ef1baab28fc520bd031ef8cf93d9ee4a31d4058fcb622'
'd8604aec02928a19e213af003977108e4b93935762b178f86da9e7c18e6cebac'
'07e737cfdc79382dc259c4844a150d8d72ebbcdc9d7e03a9503f8f8e19f1aea4'
'6ac452e2124f92747a57c5a50e11ca2f1e8112669845b4431311545c7fd2a36c'
'116c8bee112e4bbf65fb7ef4770a24ed8e4d17dbb9d6d7911fa7b8cf13c1b086'
'1e15fc2ef3fa770217ecc63a220e5df2ddbcf3295eb4a021171e7edd4c6cc898'
'66a03c246037451a77b4d448565b1d7e9368270c7d02872fbd0b5d024ed0a997'
'31dc68e84aecfb7d069efb1305049122c65694676be8b955634abcf0675922a2'
'd02bf5ca08fd610394b9d3a0c3b176d74af206f897dee826e5cbaec97bb4a4aa'
'5987b3bd713d10fcd3c624785a1d0a8116325afab3e3752da6d4b1075b1a38d4'
'6858fe0c55cda404f30f63824c7fcf970339c2d62a7f366a115f7ff9b87098c5'
'7058e57fd68367b029adc77f2a82928f1433daaf02c8c279cb2d13556c8804d7'
'c605f638d74c61861ebdc36ebd4cb8b6475eae2f6273e1ccb2bbb3e10a2ec3fe'
'bc69d6e5ee8172b0242c8fa72d13cfe2b8d2b6601468836908a7dfe8b78a3bbb'

View File

@ -653,288 +653,6 @@ From: Etienne Juvigny <Ti3noU@gmail.com>
Date: Mon, 3 Sep 2018 17:36:25 +0200
Subject: Zenify & stuff
diff --git a/Documentation/tp_smapi.txt b/Documentation/tp_smapi.txt
new file mode 100644
index 000000000000..a249678a8866
--- /dev/null
+++ b/Documentation/tp_smapi.txt
@@ -0,0 +1,275 @@
+tp_smapi version 0.42
+IBM ThinkPad hardware functions driver
+
+Author: Shem Multinymous <multinymous@gmail.com>
+Project: http://sourceforge.net/projects/tpctl
+Wiki: http://thinkwiki.org/wiki/tp_smapi
+List: linux-thinkpad@linux-thinkpad.org
+ (http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad)
+
+Description
+-----------
+
+ThinkPad laptops include a proprietary interface called SMAPI BIOS
+(System Management Application Program Interface) which provides some
+hardware control functionality that is not accessible by other means.
+
+This driver exposes some features of the SMAPI BIOS through a sysfs
+interface. It is suitable for newer models, on which SMAPI is invoked
+through IO port writes. Older models use a different SMAPI interface;
+for those, try the "thinkpad" module from the "tpctl" package.
+
+WARNING:
+This driver uses undocumented features and direct hardware access.
+It thus cannot be guaranteed to work, and may cause arbitrary damage
+(especially on models it wasn't tested on).
+
+
+Module parameters
+-----------------
+
+thinkpad_ec module:
+ force_io=1 lets thinkpad_ec load on some recent ThinkPad models
+ (e.g., T400 and T500) whose BIOS's ACPI DSDT reserves the ports we need.
+tp_smapi module:
+ debug=1 enables verbose dmesg output.
+
+
+Usage
+-----
+
+Control of battery charging thresholds (in percents of current full charge
+capacity):
+
+# echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh
+# echo 70 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh
+# cat /sys/devices/platform/smapi/BAT0/*_charge_thresh
+
+ (This is useful since Li-Ion batteries wear out much faster at very
+ high or low charge levels. The driver will also keeps the thresholds
+ across suspend-to-disk with AC disconnected; this isn't done
+ automatically by the hardware.)
+
+Inhibiting battery charging for 17 minutes (overrides thresholds):
+
+# echo 17 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes
+# echo 0 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes # stop
+# cat /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes
+
+ (This can be used to control which battery is charged when using an
+ Ultrabay battery.)
+
+Forcing battery discharging even if AC power available:
+
+# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge # start discharge
+# echo 0 > /sys/devices/platform/smapi/BAT0/force_discharge # stop discharge
+# cat /sys/devices/platform/smapi/BAT0/force_discharge
+
+ (When AC is connected, forced discharging will automatically stop
+ when battery is fully depleted -- this is useful for calibration.
+ Also, this attribute can be used to control which battery is discharged
+ when both a system battery and an Ultrabay battery are connected.)
+
+Misc read-only battery status attributes (see note about HDAPS below):
+
+/sys/devices/platform/smapi/BAT0/installed # 0 or 1
+/sys/devices/platform/smapi/BAT0/state # idle/charging/discharging
+/sys/devices/platform/smapi/BAT0/cycle_count # integer counter
+/sys/devices/platform/smapi/BAT0/current_now # instantaneous current
+/sys/devices/platform/smapi/BAT0/current_avg # last minute average
+/sys/devices/platform/smapi/BAT0/power_now # instantaneous power
+/sys/devices/platform/smapi/BAT0/power_avg # last minute average
+/sys/devices/platform/smapi/BAT0/last_full_capacity # in mWh
+/sys/devices/platform/smapi/BAT0/remaining_percent # remaining percent of energy (set by calibration)
+/sys/devices/platform/smapi/BAT0/remaining_percent_error # error range of remaing_percent (not reset by calibration)
+/sys/devices/platform/smapi/BAT0/remaining_running_time # in minutes, by last minute average power
+/sys/devices/platform/smapi/BAT0/remaining_running_time_now # in minutes, by instantenous power
+/sys/devices/platform/smapi/BAT0/remaining_charging_time # in minutes
+/sys/devices/platform/smapi/BAT0/remaining_capacity # in mWh
+/sys/devices/platform/smapi/BAT0/design_capacity # in mWh
+/sys/devices/platform/smapi/BAT0/voltage # in mV
+/sys/devices/platform/smapi/BAT0/design_voltage # in mV
+/sys/devices/platform/smapi/BAT0/charging_max_current # max charging current
+/sys/devices/platform/smapi/BAT0/charging_max_voltage # max charging voltage
+/sys/devices/platform/smapi/BAT0/group{0,1,2,3}_voltage # see below
+/sys/devices/platform/smapi/BAT0/manufacturer # string
+/sys/devices/platform/smapi/BAT0/model # string
+/sys/devices/platform/smapi/BAT0/barcoding # string
+/sys/devices/platform/smapi/BAT0/chemistry # string
+/sys/devices/platform/smapi/BAT0/serial # integer
+/sys/devices/platform/smapi/BAT0/manufacture_date # YYYY-MM-DD
+/sys/devices/platform/smapi/BAT0/first_use_date # YYYY-MM-DD
+/sys/devices/platform/smapi/BAT0/temperature # in milli-Celsius
+/sys/devices/platform/smapi/BAT0/dump # see below
+/sys/devices/platform/smapi/ac_connected # 0 or 1
+
+The BAT0/group{0,1,2,3}_voltage attribute refers to the separate cell groups
+in each battery. For example, on the ThinkPad 600, X3x, T4x and R5x models,
+the battery contains 3 cell groups in series, where each group consisting of 2
+or 3 cells connected in parallel. The voltage of each group is given by these
+attributes, and their sum (roughly) equals the "voltage" attribute.
+(The effective performance of the battery is determined by the weakest group,
+i.e., the one those voltage changes most rapidly during dis/charging.)
+
+The "BAT0/dump" attribute gives a a hex dump of the raw status data, which
+contains additional data now in the above (if you can figure it out). Some
+unused values are autodetected and replaced by "--":
+
+In all of the above, replace BAT0 with BAT1 to address the 2nd battery (e.g.
+in the UltraBay).
+
+
+Raw SMAPI calls:
+
+/sys/devices/platform/smapi/smapi_request
+This performs raw SMAPI calls. It uses a bad interface that cannot handle
+multiple simultaneous access. Don't touch it, it's for development only.
+If you did touch it, you would so something like
+# echo '211a 100 0 0' > /sys/devices/platform/smapi/smapi_request
+# cat /sys/devices/platform/smapi/smapi_request
+and notice that in the output "211a 34b b2 0 0 0 'OK'", the "4b" in the 2nd
+value, converted to decimal is 75: the current charge stop threshold.
+
+
+Model-specific status
+---------------------
+
+Works (at least partially) on the following ThinkPad model:
+* A30
+* G41
+* R40, R50p, R51, R52
+* T23, T40, T40p, T41, T41p, T42, T42p, T43, T43p, T60, T61, T400, T410, T420 (partially)
+* X24, X31, X32, X40, X41, X60, X61, X200, X201, X220 (partially)
+* Z60t, Z61m
+
+Does not work on:
+* X230 and newer
+* T430 and newer
+* Any ThinkPad Edge
+* Any ThinkPad Yoga
+* Any ThinkPad L series
+* Any ThinkPad P series
+
+Not all functions are available on all models; for detailed status, see:
+ http://thinkwiki.org/wiki/tp_smapi
+
+Please report success/failure by e-mail or on the Wiki.
+If you get a "not implemented" or "not supported" message, your laptop
+probably just can't do that (at least not via the SMAPI BIOS).
+For negative reports, follow the bug reporting guidelines below.
+If you send me the necessary technical data (i.e., SMAPI function
+interfaces), I will support additional models.
+
+
+Additional HDAPS features
+-------------------------
+
+The modified hdaps driver has several improvements on the one in mainline
+(beyond resolving the conflict with thinkpad_ec and tp_smapi):
+
+- Fixes reliability and improves support for recent ThinkPad models
+ (especially *60 and newer). Unlike the mainline driver, the modified hdaps
+ correctly follows the Embedded Controller communication protocol.
+
+- Extends the "invert" parameter to cover all possible axis orientations.
+ The possible values are as follows.
+ Let X,Y denote the hardware readouts.
+ Let R denote the laptop's roll (tilt left/right).
+ Let P denote the laptop's pitch (tilt forward/backward).
+ invert=0: R= X P= Y (same as mainline)
+ invert=1: R=-X P=-Y (same as mainline)
+ invert=2: R=-X P= Y (new)
+ invert=3: R= X P=-Y (new)
+ invert=4: R= Y P= X (new)
+ invert=5: R=-Y P=-X (new)
+ invert=6: R=-Y P= X (new)
+ invert=7: R= Y P=-X (new)
+ It's probably easiest to just try all 8 possibilities and see which yields
+ correct results (e.g., in the hdaps-gl visualisation).
+
+- Adds a whitelist which automatically sets the correct axis orientation for
+ some models. If the value for your model is wrong or missing, you can override
+ it using the "invert" parameter. Please also update the tables at
+ http://www.thinkwiki.org/wiki/tp_smapi and
+ http://www.thinkwiki.org/wiki/List_of_DMI_IDs
+ and submit a patch for the whitelist in hdaps.c.
+
+- Provides new attributes:
+ /sys/devices/platform/hdaps/sampling_rate:
+ This determines the frequency at which the host queries the embedded
+ controller for accelerometer data (and informs the hdaps input devices).
+ Default=50.
+ /sys/devices/platform/hdaps/oversampling_ratio:
+ When set to X, the embedded controller is told to do physical accelerometer
+ measurements at a rate that is X times higher than the rate at which
+ the driver reads those measurements (i.e., X*sampling_rate). This
+ makes the readouts from the embedded controller more fresh, and is also
+ useful for the running average filter (see next). Default=5
+ /sys/devices/platform/hdaps/running_avg_filter_order:
+ When set to X, reported readouts will be the average of the last X physical
+ accelerometer measurements. Current firmware allows 1<=X<=8. Setting to a
+ high value decreases readout fluctuations. The averaging is handled by the
+ embedded controller, so no CPU resources are used. Higher values make the
+ readouts smoother, since it averages out both sensor noise (good) and abrupt
+ changes (bad). Default=2.
+
+- Provides a second input device, which publishes the raw accelerometer
+ measurements (without the fuzzing needed for joystick emulation). This input
+ device can be matched by a udev rule such as the following (all on one line):
+ KERNEL=="event[0-9]*", ATTRS{phys}=="hdaps/input1",
+ ATTRS{modalias}=="input:b0019v1014p5054e4801-*",
+ SYMLINK+="input/hdaps/accelerometer-event
+
+A new version of the hdapsd userspace daemon, which uses the input device
+interface instead of polling sysfs, is available seprately. Using this reduces
+the total interrupts per second generated by hdaps+hdapsd (on tickless kernels)
+to 50, down from a value that fluctuates between 50 and 100. Set the
+sampling_rate sysfs attribute to a lower value to further reduce interrupts,
+at the expense of response latency.
+
+Licensing note: all my changes to the HDAPS driver are licensed under the
+GPL version 2 or, at your option and to the extent allowed by derivation from
+prior works, any later version. My version of hdaps is derived work from the
+mainline version, which at the time of writing is available only under
+GPL version 2.
+
+Bug reporting
+-------------
+
+Mail <multinymous@gmail.com>. Please include:
+* Details about your model,
+* Relevant "dmesg" output. Make sure thinkpad_ec and tp_smapi are loaded with
+ the "debug=1" parameter (e.g., use "make load HDAPS=1 DEBUG=1").
+* Output of "dmidecode | grep -C5 Product"
+* Does the failed functionality works under Windows?
+
+
+More about SMAPI
+----------------
+
+For hints about what may be possible via the SMAPI BIOS and how, see:
+
+* IBM Technical Reference Manual for the ThinkPad 770
+ (http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=PFAN-3TUQQD)
+* Exported symbols in PWRMGRIF.DLL or TPPWRW32.DLL (e.g., use "objdump -x").
+* drivers/char/mwave/smapi.c in the Linux kernel tree.*
+* The "thinkpad" SMAPI module (http://tpctl.sourceforge.net).
+* The SMAPI_* constants in tp_smapi.c.
+
+Note that in the above Technical Reference and in the "thinkpad" module,
+SMAPI is invoked through a function call to some physical address. However,
+the interface used by tp_smapi and the above mwave drive, and apparently
+required by newer ThinkPad, is different: you set the parameters up in the
+CPU's registers and write to ports 0xB2 (the APM control port) and 0x4F; this
+triggers an SMI (System Management Interrupt), causing the CPU to enter
+SMM (System Management Mode) and run the BIOS firmware; the results are
+returned in the CPU's registers. It is not clear what is the relation between
+the two variants of SMAPI, though the assignment of error codes seems to be
+similar.
+
+In addition, the embedded controller on ThinkPad laptops has a non-standard
+interface at IO ports 0x1600-0x161F (mapped to LCP channel 3 of the H8S chip).
+The interface provides various system management services (currently known:
+battery information and accelerometer readouts). For more information see the
+thinkpad_ec module and the H8S hardware documentation:
+http://documentation.renesas.com/eng/products/mpumcu/rej09b0300_2140bhm.pdf
diff --git a/init/Kconfig b/init/Kconfig
index b4daad2bac23..c1e59dc04209 100644
--- a/init/Kconfig
@ -944,9 +662,9 @@ index b4daad2bac23..c1e59dc04209 100644
config CC_OPTIMIZE_FOR_PERFORMANCE_O3
bool "Optimize more for performance (-O3)"
- depends on ARC
imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives
help
Choosing this option will pass "-O3" to your compiler to optimize
the kernel yet more for performance.
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 4f32c4062fb6..c0bf039e1b40 100644
--- a/drivers/infiniband/core/addr.c
@ -1745,129 +1463,3 @@ diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
/* Update ghc->generation before performing any error checks. */
ghc->generation = slots->generation;
rom f670269a42bfdd2c83a1118cc3d1b475547eac22 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp@suse.de>
Date: Wed, 22 Apr 2020 18:11:30 +0200
Subject: x86: Fix early boot crash on gcc-10, next try
... or the odyssey of trying to disable the stack protector for the
function which generates the stack canary value.
The whole story started with Sergei reporting a boot crash with a kernel
built with gcc-10:
Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139
Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013
Call Trace:
dump_stack
panic
? start_secondary
__stack_chk_fail
start_secondary
secondary_startup_64
-—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary
This happens because gcc-10 tail-call optimizes the last function call
in start_secondary() - cpu_startup_entry() - and thus emits a stack
canary check which fails because the canary value changes after the
boot_init_stack_canary() call.
To fix that, the initial attempt was to mark the one function which
generates the stack canary with:
__attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
however, using the optimize attribute doesn't work cumulatively
as the attribute does not add to but rather replaces previously
supplied optimization options - roughly all -fxxx options.
The key one among them being -fno-omit-frame-pointer and thus leading to
not present frame pointer - frame pointer which the kernel needs.
The next attempt to prevent compilers from tail-call optimizing
the last function call cpu_startup_entry(), shy of carving out
start_secondary() into a separate compilation unit and building it with
-fno-stack-protector, is this one.
The current solution is short and sweet, and reportedly, is supported by
both compilers so let's see how far we'll get this time.
Reported-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org
---
arch/x86/include/asm/stackprotector.h | 7 ++++++-
arch/x86/kernel/smpboot.c | 8 ++++++++
arch/x86/xen/smp_pv.c | 1 +
include/linux/compiler.h | 6 ++++++
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h
index 91e29b6a86a5..9804a7957f4e 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -55,8 +55,13 @@
/*
* Initialize the stackprotector canary value.
*
- * NOTE: this must only be called from functions that never return,
+ * NOTE: this must only be called from functions that never return
* and it must always be inlined.
+ *
+ * In addition, it should be called from a compilation unit for which
+ * stack protector is disabled. Alternatively, the caller should not end
+ * with a function call which gets tail-call optimized as that would
+ * lead to checking a modified canary value.
*/
static __always_inline void boot_init_stack_canary(void)
{
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index fe3ab9632f3b..4f275ac7830b 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -266,6 +266,14 @@ static void notrace start_secondary(void *unused)
wmb();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+
+ /*
+ * Prevent tail call to cpu_startup_entry() because the stack protector
+ * guard has been changed a couple of function calls up, in
+ * boot_init_stack_canary() and must not be checked before tail calling
+ * another function.
+ */
+ prevent_tail_call_optimization();
}
/**
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 8fb8a50a28b4..f2adb63b2d7c 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -93,6 +93,7 @@ asmlinkage __visible void cpu_bringup_and_idle(void)
cpu_bringup();
boot_init_stack_canary();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+ prevent_tail_call_optimization();
}
void xen_smp_intr_free_pv(unsigned int cpu)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 034b0a644efc..732754d96039 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -356,4 +356,10 @@ static inline void *offset_to_ptr(const int *off)
/* &a[0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+/*
+ * This is needed in functions which generate the stack canary, see
+ * arch/x86/kernel/smpboot.c::start_secondary() for an example.
+ */
+#define prevent_tail_call_optimization() asm("")
+
#endif /* __LINUX_COMPILER_H */