Just in case it hasn't been reported yet:
drivers/tty/serial/samsung.c: In function 's3c24xx_serial_set_termios':
drivers/tty/serial/samsung.c:820:19: error: 'UPSTAT_AUTOCTS' undeclared
Guenter
Current overlap check of minor range cannot correctly
handle a case which is baseminor < existing baseminor &&
baseminor + minorct > existing baseminor + minorct.
Fix it and meanwhile do some code cleanups.
Fixes: 01d553d0fe9f90 ("Chardev checking of overlapping ranges")
Signed-off-by: Chengguang Xu <cgxu519(a)gmx.com>
Cc: stable(a)vger.kernel.org
---
fs/char_dev.c | 94 ++++++++++++++++++++++++---------------------------
1 file changed, 44 insertions(+), 50 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index a279c58fe360..b25b1da097d5 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -88,86 +88,80 @@ static int find_dynamic_major(void)
/*
* Register a single major with a specified minor range.
*
- * If major == 0 this functions will dynamically allocate a major and return
- * its number.
- *
- * If major > 0 this function will attempt to reserve the passed range of
- * minors and will return zero on success.
+ * If major == 0 this function will dynamically allocate an unused major,
+ * otherwise attempt to reserve the range of minors with given major.
*
- * Returns a -ve errno on failure.
*/
static struct char_device_struct *
__register_chrdev_region(unsigned int major, unsigned int baseminor,
int minorct, const char *name)
{
- struct char_device_struct *cd, **cp;
- int ret = 0;
+ struct char_device_struct *new, *curr, *prev = NULL;
+ int ret = -EBUSY;
int i;
- cd = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
- if (cd == NULL)
+ if (major >= CHRDEV_MAJOR_MAX) {
+ pr_err("CHRDEV \"%s\" major requested (%u) is greater than the maximum (%u)\n",
+ name, major, CHRDEV_MAJOR_MAX-1);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (minorct > MINORMASK + 1 - baseminor) {
+ pr_err("CHRDEV \"%s\" minor range requested (%u-%u) is out of range of maximum range (%u-%u) for a single major\n",
+ name, baseminor, baseminor + minorct - 1, 0, MINORMASK);
+ return ERR_PTR(-EINVAL);
+ }
+
+ new = kzalloc(sizeof(struct char_device_struct), GFP_KERNEL);
+ if (new == NULL)
return ERR_PTR(-ENOMEM);
mutex_lock(&chrdevs_lock);
if (major == 0) {
- ret = find_dynamic_major();
- if (ret < 0) {
+ major = find_dynamic_major();
+ if (major < 0) {
pr_err("CHRDEV \"%s\" dynamic allocation region is full\n",
name);
goto out;
}
- major = ret;
}
- if (major >= CHRDEV_MAJOR_MAX) {
- pr_err("CHRDEV \"%s\" major requested (%u) is greater than the maximum (%u)\n",
- name, major, CHRDEV_MAJOR_MAX-1);
- ret = -EINVAL;
- goto out;
- }
-
- cd->major = major;
- cd->baseminor = baseminor;
- cd->minorct = minorct;
- strlcpy(cd->name, name, sizeof(cd->name));
-
i = major_to_index(major);
+ for (curr = chrdevs[i]; curr; prev = curr, curr = curr->next) {
+ if (curr->major < major)
+ continue;
- for (cp = &chrdevs[i]; *cp; cp = &(*cp)->next)
- if ((*cp)->major > major ||
- ((*cp)->major == major &&
- (((*cp)->baseminor >= baseminor) ||
- ((*cp)->baseminor + (*cp)->minorct > baseminor))))
+ if (curr->major > major)
break;
- /* Check for overlapping minor ranges. */
- if (*cp && (*cp)->major == major) {
- int old_min = (*cp)->baseminor;
- int old_max = (*cp)->baseminor + (*cp)->minorct - 1;
- int new_min = baseminor;
- int new_max = baseminor + minorct - 1;
+ if (curr->baseminor + curr->minorct <= baseminor)
+ continue;
- /* New driver overlaps from the left. */
- if (new_max >= old_min && new_max <= old_max) {
- ret = -EBUSY;
- goto out;
- }
+ if (curr->baseminor >= baseminor + minorct)
+ break;
- /* New driver overlaps from the right. */
- if (new_min <= old_max && new_min >= old_min) {
- ret = -EBUSY;
- goto out;
- }
+ goto out;
+ }
+
+ new->major = major;
+ new->baseminor = baseminor;
+ new->minorct = minorct;
+ strlcpy(new->name, name, sizeof(new->name));
+
+ if (!prev) {
+ new->next = curr;
+ chrdevs[i] = new;
+ } else {
+ new->next = prev->next;
+ prev->next = new;
}
- cd->next = *cp;
- *cp = cd;
mutex_unlock(&chrdevs_lock);
- return cd;
+ return new;
out:
mutex_unlock(&chrdevs_lock);
- kfree(cd);
+ kfree(new);
return ERR_PTR(ret);
}
--
2.20.1
Thomas,
Andi and I have made an update to our draft of the Spectre admin guide.
We may be out on Christmas vacation for a while. But we want to
send it out for everyone to take a look.
Thanks.
Tim
From: Andi Kleen <ak(a)linux.intel.com>
There are no document in admin guides describing
Spectre v1 and v2 side channels and their mitigations
in Linux.
Create a document to describe Spectre and the mitigation
methods used in the kernel.
Signed-off-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com>
---
Documentation/admin-guide/spectre.rst | 502 ++++++++++++++++++++++++++++++++++
1 file changed, 502 insertions(+)
create mode 100644 Documentation/admin-guide/spectre.rst
diff --git a/Documentation/admin-guide/spectre.rst b/Documentation/admin-guide/spectre.rst
new file mode 100644
index 0000000..0ba708e
--- /dev/null
+++ b/Documentation/admin-guide/spectre.rst
@@ -0,0 +1,502 @@
+Spectre side channels
+=====================
+
+Spectre is a class of side channel attacks against modern CPUs that
+exploit branch prediction and speculative execution to read memory,
+possibly bypassing access controls. These exploits do not modify memory.
+
+This document covers Spectre variant 1 and 2.
+
+Affected processors
+-------------------
+
+The vulnerability affects a wide range of modern high performance
+processors, since most modern high speed processors use branch prediction
+and speculative execution.
+
+The following CPUs are vulnerable:
+
+ - Intel Core, Atom, Pentium, Xeon CPUs
+ - AMD CPUs like Phenom, EPYC, Zen.
+ - IBM processors like POWER and zSeries
+ - Higher end ARM processors
+ - Apple CPUs
+ - Higher end MIPS CPUs
+ - Likely most other high performance CPUs. Contact your CPU vendor for details.
+
+This document describes the mitigations on Intel CPUs. Mitigations
+on other architectures may be different.
+
+Related CVEs
+------------
+
+The following CVE entries describe Spectre variants:
+
+ ============= ======================= ==========
+ CVE-2017-5753 Bounds check bypass Spectre-V1
+ CVE-2017-5715 Branch target injection Spectre-V2
+
+Problem
+-------
+
+CPUs have shared caches, such as buffers for branch prediction, which are
+later used to guide speculative execution. These buffers are not flushed
+over context switches or change in privilege levels. Malicious software
+might influence these buffers and trigger specific speculative execution
+in the kernel or different user processes. This speculative execution can
+then be used to read data in memory and cause side effects, such as displacing
+data in a data cache. The side effect can then later be measured by the
+malicious software, and used to determine the memory values read speculatively.
+
+Spectre attacks allow tricking other software to disclose
+values in their memory.
+
+In a typical Spectre variant 1 attack, the attacker passes an parameter
+to a victim. The victim boundary checks the parameter and rejects illegal
+values. However due to speculation over branch prediction the code path
+for correct values might be speculatively executed, then reference memory
+controlled by the input parameter and leave measurable side effects in
+the caches. The attacker could then measure these side effects
+and determine the leaked value.
+
+There are some extensions of Spectre variant 1 attacks for reading
+data over the network, see [2]. However the attacks are very
+difficult, low bandwidth and fragile and considered low risk.
+
+For Spectre variant 2 the attacker poisons the indirect branch
+predictors of the CPU. Then control is passed to the victim, which
+executes indirect branches. Due to the poisoned branch predictor data
+the CPU can speculatively execute arbitrary code in the victim's
+address space, such as a code sequence ("disclosure gadget") that
+reads arbitrary data on some input parameter and causes a measurable
+cache side effect based on the value. The attacker can then measure
+this side effect after gaining control again and determine the value.
+
+The most useful gadgets take an attacker-controlled input parameter so
+that the memory read can be controlled. Gadgets without input parameters
+might be possible, but the attacker would have very little control over what
+memory can be read, reducing the risk of the attack revealing useful data.
+
+Attack scenarios
+----------------
+
+Here is a list of attack scenarios that have been anticipated, but
+may not cover all possible attack patterns. Reduing the occurrences of
+attack pre-requisites listed can reduce the risk that a spectre attack
+leaks useful data.
+
+1. Local User process attacking kernel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Code in system calls often enforces access controls with conditional
+branches based on user data. These branches are potential targets for
+Spectre v2 exploits. Interrupt handlers, on the other hand, rarely
+handle user data or enforce access controls, which makes them unlikely
+exploit targets.
+
+For typical variant 2 attack, the attacker may poison the CPU branch
+buffers first, and then enter the kernel and trick it into jumping to a
+disclosure gadget through an indirect branch. If the attacker wants to control the
+memory addresses leaked, it would also need to pass a parameter
+to the gadget, either through a register or through a known address in
+memory. Finally when it executes again it can measure the side effect.
+
+Necessary Prequisites:
+1. Malicious local process passing parameters to kernel
+2. Kernel has secrets.
+
+2. User process attacking another user process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In this scenario an malicious user process wants to attack another
+user process through a context switch.
+
+For variant 1 this generally requires passing some parameter between
+the processes, which needs a data passing relationship, such a remote
+procedure calls (RPC).
+
+For variant 2 the poisoning can happen through a context switch, or
+on CPUs with simultaneous multi-threading (SMT) potentially on the
+thread sibling executing in parallel on the same core. In either case,
+controlling the memory leaked by the disclosure gadget also requires a data
+passing relationship to the victim process, otherwise while it may
+observe values through side effects, it won't know which memory
+addresses they relate to.
+
+Necessary Prerequisites:
+1. Malicious code running as local process
+2. Victim processes containing secrets running on same core.
+
+3. User sandbox attacking runtime in process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A process, such as a web browser, might be running interpreted or JITed
+untrusted code, such as javascript code downloaded from a website.
+It uses restrictions in the JIT code generator and checks in a run time
+to prevent the untrusted code from attacking the hosting process.
+
+The untrusted code might either use variant 1 or 2 to trick
+a disclosure gadget in the run time to read memory inside the process.
+
+Necessary Prerequisites:
+1. Sandbox in process running untrusted code.
+2. Runtime in same process containing secrets.
+
+4. Kernel sandbox attacking kernel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The kernel has support for running user-supplied programs within the
+kernel. Specific rules (such as bounds checking) are enforced on these
+programs by the kernel to ensure that they do not violate access controls.
+
+eBPF is a kernel sub-system that uses user-supplied program
+to execute JITed untrusted byte code inside the kernel. eBPF is used
+for manipulating and examining network packets, examining system call
+parameters for sand boxes and other uses.
+
+A malicious local process could upload and trigger an malicious
+eBPF script to the kernel, with the script attacking the kernel
+using variant 1 or 2 and reading memory.
+
+Necessary Prerequisites:
+1. Malicious local process
+2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets
+on the same machine.
+
+5. Virtualization guest attacking host
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An untrusted guest might attack the host through a hyper call
+or other virtualization exit.
+
+Necessary Prerequisites:
+1. Untrusted guest attacking host
+2. Host has secrets on local machine.
+
+For variant 1 VM exits use appropriate mitigations
+("bounds clipping") to prevent speculation leaking data
+in kernel code. For variant 2 the kernel flushes the branch buffer.
+
+6. Virtualization guest attacking other guest
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An untrusted guest attacking another guest containing
+secrets. Mitigations are similar to when a guest attack
+the host.
+
+Runtime vulnerability information
+---------------------------------
+
+The kernel reports the vulnerability and mitigation status in
+/sys/devices/system/cpu/vulnerabilities/*
+
+The spectre_v1 file describes the always enabled variant 1
+mitigation:
+
+/sys/devices/system/cpu/vulnerabilities/spectre_v1
+
+The value in this file:
+
+ ======================================= =================================
+ 'Mitigation: __user pointer sanitation' Protection in kernel on a case by
+ case base with explicit pointer
+ sanitation.
+ ======================================= =================================
+
+The spectre_v2 kernel file reports if the kernel has been compiled with a
+retpoline aware compiler, if the CPU has hardware mitigation, and if the
+CPU has microcode support for additional process specific mitigations.
+
+It also reports CPU features enabled by microcode to mitigate attack
+between user processes:
+
+1. Indirect Branch Prediction Barrier (IBPB) to add additional
+ isolation between processes of different users
+2. Single Thread Indirect Branch Prediction (STIBP) to additional
+ isolation between CPU threads running on the same core.
+
+These CPU features may impact performance when used and can
+be enabled per process on a case-by-case base.
+
+/sys/devices/system/cpu/vulnerabilities/spectre_v2
+
+The values in this file:
+
+ - Kernel status:
+
+ ==================================== =================================
+ 'Not affected' The processor is not vulnerable
+ 'Vulnerable' Vulnerable, no mitigation
+ 'Mitigation: Full generic retpoline' Software-focused mitigation
+ 'Mitigation: Full AMD retpoline' AMD-specific software mitigation
+ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
+ ==================================== =================================
+
+ - Firmware status:
+
+ ========== =============================================================
+ 'IBRS_FW' Protection against user program attacks when calling firmware
+ ========== =============================================================
+
+ - Indirect branch prediction barrier (IBPB) status for protection between
+ processes of different users. This feature can be controlled through
+ prctl per process, or through kernel command line options. For more details
+ see below.
+
+ =================== ========================================================
+ 'IBPB: disabled' IBPB unused
+ 'IBPB: always-on' Use IBPB on all tasks
+ 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks
+ =================== ========================================================
+
+ - Single threaded indirect branch prediction (STIBP) status for protection
+ between different hyper threads. This feature can be controlled through
+ prctl per process, or through kernel command line options. For more details
+ see below.
+
+ ==================== ========================================================
+ 'STIBP: disabled' STIBP unused
+ 'STIBP: forced' Use STIBP on all tasks
+ 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks
+ ==================== ========================================================
+
+ - Return stack buffer (RSB) protection status:
+
+ ============= ===========================================
+ 'RSB filling' Protection of RSB on context switch enabled
+ ============= ===========================================
+
+Full mitigations might require an microcode update from the CPU
+vendor. When the necessary microcode is not available the kernel
+will report vulnerability.
+
+Kernel mitigation
+-----------------
+
+The kernel has default on mitigations for Variant 1 and Variant 2
+against attacks from user programs or guests. For variant 1 it
+annotates vulnerable kernel code (as determined by the sparse code
+scanning tool and code audits) to use "bounds clipping" to avoid any
+usable disclosure gadgets.
+
+For variant 2 the kernel employs "retpoline" with compiler help to secure
+the indirect branches inside the kernel, when CONFIG_RETPOLINE is enabled
+and the compiler supports retpoline. On Intel Skylake-era systems the
+mitigation covers most, but not all, cases, see [1] for more details.
+
+On CPUs with hardware mitigations for variant 2, retpoline is
+automatically disabled at runtime.
+
+Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y
+and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration)
+makes attacks on the kernel generally more difficult.
+
+Host mitigation
+---------------
+
+The Linux kernel uses retpoline to eliminate attacks on indirect
+branches. It also flushes the Return Branch Stack on every VM exit to
+prevent guests from attacking the host kernel when retpoline is
+enabled.
+
+Variant 1 attacks are mitigated unconditionally.
+
+The kernel also allows guests to use any microcode based mitigations
+they chose to use (such as IBPB or STIBP), assuming the
+host has an updated microcode and reports the feature in
+/sys/devices/system/cpu/vulnerabilities/spectre_v2.
+
+Mitigation control at kernel build time
+---------------------------------------
+
+When the CONFIG_RETPOLINE option is enabled the kernel uses special
+code sequences to avoid attacks on indirect branches through
+Variant 2 attacks.
+
+The compiler also needs to support retpoline and support the
+-mindirect-branch=thunk-extern -mindirect-branch-register options
+for gcc, or -mretpoline-external-thunk option for clang.
+
+When the compiler doesn't support these options the kernel
+will report that it is vulnerable.
+
+Variant 1 mitigations and other side channel related user APIs are
+enabled unconditionally.
+
+Hardware mitigation
+-------------------
+
+Some CPUs have hardware mitigations (e.g. enhanced IBRS) for Spectre
+variant 2. The 4.19 kernel has support for detecting this capability
+and automatically disable any unnecessary workarounds at runtime.
+
+User program mitigation
+-----------------------
+
+For variant 1 user programs can use LFENCE or bounds clipping. For more
+details see [3].
+
+For variant 2 user programs can be compiled with retpoline or
+restricting its indirect branch speculation via prctl. (See
+Documenation/speculation.txt for detailed API.)
+
+User programs should use address space randomization
+(/proc/sys/kernel/randomize_va_space = 1 or 2) to make any attacks
+more difficult.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+Spectre v2 mitigations can be disabled and force enabled at the kernel
+command line.
+
+ nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
+ (indirect branch prediction) vulnerability. System may
+ allow data leaks with this option, which is equivalent
+ to spectre_v2=off.
+
+
+ spectre_v2= [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability.
+ The default operation protects the kernel from
+ user space attacks.
+
+ on - unconditionally enable, implies
+ spectre_v2_user=on
+ off - unconditionally disable, implies
+ spectre_v2_user=off
+ auto - kernel detects whether your CPU model is
+ vulnerable
+
+ Selecting 'on' will, and 'auto' may, choose a
+ mitigation method at run time according to the
+ CPU, the available microcode, the setting of the
+ CONFIG_RETPOLINE configuration option, and the
+ compiler with which the kernel was built.
+
+ Selecting 'on' will also enable the mitigation
+ against user space to user space task attacks.
+
+ Selecting 'off' will disable both the kernel and
+ the user space protections.
+
+ Specific mitigations can also be selected manually:
+
+ retpoline - replace indirect branches
+ retpoline,generic - google's original retpoline
+ retpoline,amd - AMD-specific minimal thunk
+
+ Not specifying this option is equivalent to
+ spectre_v2=auto.
+
+For user space mitigation:
+
+ spectre_v2_user=
+ [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability between
+ user space tasks
+
+ on - Unconditionally enable mitigations. Is
+ enforced by spectre_v2=on
+
+ off - Unconditionally disable mitigations. Is
+ enforced by spectre_v2=off
+
+ prctl - Indirect branch speculation is enabled,
+ but mitigation can be enabled via prctl
+ per thread. The mitigation control state
+ is inherited on fork.
+
+ prctl,ibpb
+ - Like "prctl" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different user
+ space processes.
+
+ seccomp
+ - Same as "prctl" above, but all seccomp
+ threads will enable the mitigation unless
+ they explicitly opt out.
+
+ seccomp,ibpb
+ - Like "seccomp" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different
+ user space processes.
+
+ auto - Kernel selects the mitigation depending on
+ the available CPU features and vulnerability.
+
+ Default mitigation:
+ If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
+
+ Not specifying this option is equivalent to
+ spectre_v2_user=auto.
+
+ In general the kernel by default selects
+ reasonable mitigations for the current CPU. To
+ disable Spectre v2 mitigations boot with
+ spectre_v2=off. Spectre v1 mitigations cannot
+ be disabled.
+
+APIs for mitigation control of user process
+-------------------------------------------
+
+When enabling the "prctl" option for spectre_v2_user boot parameter,
+prctl can be used to restrict indirect branch speculation on a process.
+See Documenation/speculation.txt for detailed API.
+
+Processes containing secrets, such as cryptographic keys, may invoke
+this prctl for extra protection against Spectre v2.
+
+Before running untrusted processes, restricting their indirect branch
+speculation will prevent such processes from launching Spectre v2 attacks.
+
+Restricting indirect branch speuclation on a process should be only used
+as needed, as restricting speculation reduces both performance of the
+process, and also process running on the sibling CPU thread.
+
+Under the "seccomp" option, the processes sandboxed with SECCOMP will
+have indirect branch speculation restricted automatically.
+
+References
+----------
+
+Intel white papers and documents on Spectre:
+
+https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
+
+[1]
+https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
+
+https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
+
+[3] https://software.intel.com/security-software-guidance/
+
+https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors
+
+AMD white papers:
+
+https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf
+
+https://www.amd.com/en/corporate/security-updates
+
+ARM white papers:
+
+https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper
+
+https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update
+
+MIPS:
+
+https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/
+
+Academic papers:
+
+https://spectreattack.com/spectre.pdf [original spectre paper]
+
+[2] https://arxiv.org/abs/1807.10535 [NetSpectre]
+
+https://arxiv.org/abs/1811.05441 [generalization of Spectre]
+
+https://arxiv.org/abs/1807.07940 [Spectre RSB, a variant of Spectre v2]
--
2.9.4
On 2019/2/12 9:28 下午, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, v4.4.173, v3.18.134.
>
> v4.20.7: Build OK!
> v4.19.20: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
>
> v4.14.98: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
>
> v4.9.155: Failed to apply! Possible dependencies:
> 752f66a75aba ("bcache: use REQ_PRIO to indicate bio for metadata")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
>
> v4.4.173: Failed to apply! Possible dependencies:
> 09cbfeaf1a5a ("mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros")
> 1c2e54e1ed6f ("dm thin: bump thin and thin-pool target versions")
> 1eff9d322a44 ("block: rename bio bi_rw to bi_opf")
> 202bae52934d ("dm thin: unroll issue_discard() to create longer discard bio chains")
> 38f252553300 ("block: add __blkdev_issue_discard")
> 3dba53a958a7 ("dm thin: use __blkdev_issue_discard for async discard support")
> 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> 9082e87bfbf8 ("block: remove struct bio_batch")
> a6111d11b8b5 ("btrfs: raid56: Use raid_write_end_io for scrub")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
> bbd848e0fade ("block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard")
> c3667cc61904 ("dm thin: consistently return -ENOSPC if pool has run out of data space")
> c8d93247f1d0 ("bcache: use op_is_write instead of checking for REQ_WRITE")
> d57d611505d9 ("kernel/fs: fix I/O wait not accounted for RW O_DSYNC")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 1b94b5567e9c ("Btrfs, raid56: use a variant to record the operation type")
> 1eff9d322a44 ("block: rename bio bi_rw to bi_opf")
> 2c8cdd6ee4e7 ("Btrfs, replace: write dirty pages into the replace target device")
> 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io")
> 4245215d6a8d ("Btrfs, raid56: fix use-after-free problem in the final device replace procedure on raid56")
> 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
> 6e9606d2a2dc ("Btrfs: add ref_count and free function for btrfs_bio")
> 83b5df67c509 ("bcache: use op_is_sync to check for synchronous requests")
> 8e5cfb55d3f7 ("Btrfs: Make raid_map array be inlined in btrfs_bio structure")
> af8e2d1df984 ("Btrfs, scrub: repair the common data on RAID5/6 if it is corrupted")
> b41c9b0266e8 ("bcache: update bio->bi_opf bypass/writeback REQ_ flag hints")
> b7c44ed9d2fc ("block: manipulate bio->bi_flags through helpers")
> b89e1b012c7f ("Btrfs, raid56: don't change bbio and raid_map")
> c4cf5261f8bf ("bio: skip atomic inc/dec of ->bi_remaining for non-chains")
> c8d93247f1d0 ("bcache: use op_is_write instead of checking for REQ_WRITE")
> f90523d1aa3c ("Btrfs: remove noused bbio_ret in __btrfs_map_block in condition")
>
>
> How should we proceed with this patch?
Can I rebase this patch for each stable kernel, and send the patch to
stable(a)vger.kernel.org ?
Thanks.
--
Coly Li
On 2019/2/12 9:28 下午, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155, v4.4.173, v3.18.134.
>
> v4.20.7: Build OK!
> v4.19.20: Failed to apply! Possible dependencies:
> 149d0efada77 ("bcache: replace hard coded number with BUCKET_GC_GEN_MAX")
>
> v4.14.98: Failed to apply! Possible dependencies:
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 25d8be77e192 ("block: move bio_alloc_pages() to bcache")
> 27a40ab9269e ("bcache: add backing_request_endio() for bi_end_io")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 3b304d24a718 ("bcache: convert cached_dev.count from atomic_t to refcount_t")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
> 5fa89fb9a86b ("bcache: don't write back data if reading it failed")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 771f393e8ffc ("bcache: add CACHE_SET_IO_DISABLE to struct cache_set flags")
> 7ba0d830dc0e ("bcache: set error_limit correctly")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 804f3c6981f5 ("bcache: fix cached_dev->count usage for bch_cache_set_error()")
> a8500fc816b1 ("bcache: rearrange writeback main thread ratelimit")
> b1092c9af9ed ("bcache: allow quick writeback when backing idle")
> bc082a55d25c ("bcache: fix inaccurate io state for detached bcache devices")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
>
> v4.9.155: Failed to apply! Possible dependencies:
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 297e3d854784 ("blk-throttle: make throtl_slice tunable")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 87760e5eef35 ("block: hook up writeback throttling")
> 9e234eeafbe1 ("blk-throttle: add a simple idle detection")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> cf43e6be865a ("block: add scalable completion tracking of requests")
> e806402130c9 ("block: split out request-only flags into a new namespace")
> fbbaf700e7b1 ("block: trace completion of all bios.")
>
> v4.4.173: Failed to apply! Possible dependencies:
> 005411ea7ee7 ("doc: update block/queue-sysfs.txt entries")
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 27489a3c827b ("blk-mq: turn hctx->run_work into a regular work struct")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 297e3d854784 ("blk-throttle: make throtl_slice tunable")
> 38f8baae8905 ("block: factor out chained bio completion")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 511cbce2ff8b ("irq_poll: make blk-iopoll available outside the block layer")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 87760e5eef35 ("block: hook up writeback throttling")
> 8d354f133e86 ("blk-mq: improve layout of blk_mq_hw_ctx")
> 9467f85960a3 ("blk-mq/cpu-notif: Convert to new hotplug state machine")
> 9e234eeafbe1 ("blk-throttle: add a simple idle detection")
> af3e3a5259e3 ("block: don't unecessarily clobber bi_error for chained bios")
> ba8c6967b739 ("block: cleanup bio_endio")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> cf43e6be865a ("block: add scalable completion tracking of requests")
> e57690fe009b ("blk-mq: don't overwrite rq->mq_ctx")
> fbbaf700e7b1 ("block: trace completion of all bios.")
>
> v3.18.134: Failed to apply! Possible dependencies:
> 0f8087ecdeac ("block: Consolidate static integrity profile properties")
> 1b94b5567e9c ("Btrfs, raid56: use a variant to record the operation type")
> 1d316e658374 ("bcache: implement PI controller for writeback rate")
> 2831231d4c3f ("bcache: reduce cache_set devices iteration by devices_max_used")
> 2c8cdd6ee4e7 ("Btrfs, replace: write dirty pages into the replace target device")
> 326e1dbb5736 ("block: remove management of bi_remaining when restoring original bi_end_io")
> 3fd47bfe55b0 ("bcache: stop dc->writeback_rate_update properly")
> 4246a0b63bd8 ("block: add a bi_error field to struct bio")
> 4e4cbee93d56 ("block: switch bios to blk_status_t")
> 5138ac6748e3 ("bcache: fix misleading error message in bch_count_io_errors()")
> 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56")
> 6e9606d2a2dc ("Btrfs: add ref_count and free function for btrfs_bio")
> 6f10f7d1b02b ("bcache: style fix to replace 'unsigned' by 'unsigned int'")
> 7e027ca4b534 ("bcache: add stop_when_cache_set_failed option to backing device")
> 8e5cfb55d3f7 ("Btrfs: Make raid_map array be inlined in btrfs_bio structure")
> af8e2d1df984 ("Btrfs, scrub: repair the common data on RAID5/6 if it is corrupted")
> b89e1b012c7f ("Btrfs, raid56: don't change bbio and raid_map")
> c4cf5261f8bf ("bio: skip atomic inc/dec of ->bi_remaining for non-chains")
> c7b7bd07404c ("bcache: add io_disable to struct cached_dev")
> f90523d1aa3c ("Btrfs: remove noused bbio_ret in __btrfs_map_block in condition")
>
>
> How should we proceed with this patch?
Can we rebase this patch for stable kernels, and send them to stable
kernel maintainers separately? If this behavior is accepted for stable
kernel maintenance, I would suggest Junhui Tang to think about to rebase
for these stable kernels.
Thanks.
--
Coly Li
The patch
regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk(a)kernel.org>
Date: Sat, 9 Feb 2019 18:14:14 +0100
Subject: [PATCH] regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
LDO35 uses 25 mV step, not 50 mV. Bucks 7 and 8 use 12.5 mV step
instead of 6.25 mV. Wrong step caused over-voltage (LDO35) or
under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
Arndale Octa board).
Cc: <stable(a)vger.kernel.org>
Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
drivers/regulator/s2mps11.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index ee4a23ab0663..134c62db36c5 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -362,7 +362,7 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_ldo(32, STEP_50_MV),
regulator_desc_s2mps11_ldo(33, STEP_50_MV),
regulator_desc_s2mps11_ldo(34, STEP_50_MV),
- regulator_desc_s2mps11_ldo(35, STEP_50_MV),
+ regulator_desc_s2mps11_ldo(35, STEP_25_MV),
regulator_desc_s2mps11_ldo(36, STEP_50_MV),
regulator_desc_s2mps11_ldo(37, STEP_50_MV),
regulator_desc_s2mps11_ldo(38, STEP_50_MV),
@@ -372,8 +372,8 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_buck1_4(4),
regulator_desc_s2mps11_buck5,
regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV),
- regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_6_25_MV),
- regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_6_25_MV),
+ regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV),
+ regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV),
regulator_desc_s2mps11_buck9,
regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
};
--
2.20.1