- Jun 22, 2021
-
-
Paul E. McKenney authored
Currently, WATCHDOG_THRESHOLD is set to detect a 62.5-millisecond skew in a 500-millisecond WATCHDOG_INTERVAL. This requires that clocks be skewed by more than 12.5% in order to be marked unstable. Except that a clock that is skewed by that much is probably destroying unsuspecting software right and left. And given that there are now checks for false-positive skews due to delays between reading the two clocks, it should be possible to greatly decrease WATCHDOG_THRESHOLD, at least for fine-grained clocks such as TSC. Therefore, add a new uncertainty_margin field to the clocksource structure that contains the maximum uncertainty in nanoseconds for the corresponding clock. This field may be initialized manually, as it is for clocksource_tsc_early and clocksource_jiffies, which is copied to refined_jiffies. If the field is not initialized manually, it will be computed at clock-registry time as the period of the clock in question based on the scale and freq parameters to __clocksource_update_freq_scale() function. If either of those two parameters are zero, the tens-of-milliseconds WATCHDOG_THRESHOLD is used as a cowardly alternative to dividing by zero. No matter how the uncertainty_margin field is calculated, it is bounded below by twice WATCHDOG_MAX_SKEW, that is, by 100 microseconds. Note that manually initialized uncertainty_margin fields are not adjusted, but there is a WARN_ON_ONCE() that triggers if any such field is less than twice WATCHDOG_MAX_SKEW. This WARN_ON_ONCE() is intended to discourage production use of the one-nanosecond uncertainty_margin values that are used to test the clock-skew code itself. The actual clock-skew check uses the sum of the uncertainty_margin fields of the two clocksource structures being compared. Integer overflow is avoided because the largest computed value of the uncertainty_margin fields is one billion (10^9), and double that value fits into an unsigned int. However, if someone manually specifies (say) UINT_MAX, they will get what they deserve. Note that the refined_jiffies uncertainty_margin field is initialized to TICK_NSEC, which means that skew checks involving this clocksource will be sufficently forgiving. In a similar vein, the clocksource_tsc_early uncertainty_margin field is initialized to 32*NSEC_PER_MSEC, which replicates the current behavior and allows custom setting if needed in order to address the rare skews detected for this clocksource in current mainline. Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20210527190124.440372-4-paulmck@kernel.org
-
Paul E. McKenney authored
Currently, if skew is detected on a clock marked CLOCK_SOURCE_VERIFY_PERCPU, that clock is checked on all CPUs. This is thorough, but might not be what you want on a system with a few tens of CPUs, let alone a few hundred of them. Therefore, by default check only up to eight randomly chosen CPUs. Also provide a new clocksource.verify_n_cpus kernel boot parameter. A value of -1 says to check all of the CPUs, and a non-negative value says to randomly select that number of CPUs, without concern about selecting the same CPU multiple times. However, make use of a cpumask so that a given CPU will be checked at most once. Suggested-by: Thomas Gleixner <tglx@linutronix.de> # For verify_n_cpus=1. Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20210527190124.440372-3-paulmck@kernel.org
-
Paul E. McKenney authored
Some sorts of per-CPU clock sources have a history of going out of synchronization with each other. However, this problem has purportedy been solved in the past ten years. Except that it is all too possible that the problem has instead simply been made less likely, which might mean that some of the occasional "Marking clocksource 'tsc' as unstable" messages might be due to desynchronization. How would anyone know? Therefore apply CPU-to-CPU synchronization checking to newly unstable clocksource that are marked with the new CLOCK_SOURCE_VERIFY_PERCPU flag. Lists of desynchronized CPUs are printed, with the caveat that if it is the reporting CPU that is itself desynchronized, it will appear that all the other clocks are wrong. Just like in real life. Reported-by:
Chris Mason <clm@fb.com> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20210527190124.440372-2-paulmck@kernel.org
-
Paul E. McKenney authored
When the clocksource watchdog marks a clock as unstable, this might be due to that clock being unstable or it might be due to delays that happen to occur between the reads of the two clocks. Yes, interrupts are disabled across those two reads, but there are no shortage of things that can delay interrupts-disabled regions of code ranging from SMI handlers to vCPU preemption. It would be good to have some indication as to why the clock was marked unstable. Therefore, re-read the watchdog clock on either side of the read from the clock under test. If the watchdog clock shows an excessive time delta between its pair of reads, the reads are retried. The maximum number of retries is specified by a new kernel boot parameter clocksource.max_cswd_read_retries, which defaults to three, that is, up to four reads, one initial and up to three retries. If more than one retry was required, a message is printed on the console (the occasional single retry is expected behavior, especially in guest OSes). If the maximum number of retries is exceeded, the clock under test will be marked unstable. However, the probability of this happening due to various sorts of delays is quite small. In addition, the reason (clock-read delays) for the unstable marking will be apparent. Reported-by:
Chris Mason <clm@fb.com> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20210527190124.440372-1-paulmck@kernel.org
-
Baokun Li authored
Add the missing documentation for the @cpu parameter of tick_cleanup_dead_cpu(). Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210608024305.2750999-1-libaokun1@huawei.com
-
- Jun 18, 2021
-
-
https://git.linaro.org/people/daniel.lezcano/linuxThomas Gleixner authored
Pull clockevent/source updates from Daniel Lezcano: - Remove arch_timer_rate1 variable as it is unused in the architected ARM timer (Jisheng Zhang) - Minor cleanups (whitespace, constification, ...) for the Samsung pwm timer (Krzysztof Kozlowski) - Acknowledge and disable the timer interrupt at suspend time to prevent the suspend to be aborted by the ATF if there is a pending one on the Mediatek timer (Evan Benn) - Save and restore the configuration register at suspend/resume time for TI dm timer (Tony Lindgren) - Set the scene for the next timers support by renaming the array variables on the Ingenic time (Zhou Yanjie) - Add the clock rate change notification to adjust the prescalar value and compensate the clock source on the ARM global timer (Andrea Merello) - Add missing variable static annotation on the ARM global timer (Zou Wei) - Remove a duplicate argument when building the bits field on the ARM global timer (Wan Jiabing) - Improve the timer workaround function by reducing the loop on the Allwinner A64 timer (Samuel Holland) - Do no restore the register context in case of error on the TI dm timer (Tony Lindgren) Link: https://lore.kernel.org/r/65ed5f60-d7a5-b4ae-ff78-0382d4671cc5@linaro.org
-
- Jun 16, 2021
-
-
Tony Lindgren authored
The device is not losing context on CPU_CLUSTER_PM_ERROR. As we are only saving and restoring context with cpu_pm, there is no need to restore the context in case of an error. Note that the unnecessary restoring of context does not cause issues, it's just not needed. Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210518075306.35532-1-tony@atomide.com
-
Samuel Holland authored
Bad counter reads are experienced sometimes when bit 10 or greater rolls over. Originally, testing showed that at least 10 lower bits would be set to the same value during these bad reads. However, some users still reported time skips. Wider testing revealed that on some chips, occasionally only the lowest 9 bits would read as the anomalous value. During these reads (which still happen only when bit 10), bit 9 would read as the correct value. Reduce the mask by one bit to cover these cases as well. Cc: stable@vger.kernel.org Fixes: c950ca8c ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability") Reported-by:
Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210515021439.55316-1-samuel@sholland.org
-
Wan Jiabing authored
Fix the following coccicheck warning: drivers/clocksource/arm_global_timer.c:107:4-23: duplicated argument to & or | Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210615115440.8881-1-wanjiabing@vivo.com
-
Zou Wei authored
The sparse tool complains as follows: drivers/clocksource/arm_global_timer.c:54:23: warning: symbol 'gt_clk_rate_change_nb' was not declared. Should it be static? This symbol is not used outside of arm_global_timer.c, so mark it static. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1623490046-37972-1-git-send-email-zou_wei@huawei.com
-
Andrea Merello authored
Now ARM global timer driver could work even if it's source clock rate changes, so we don't need to disable that driver when cpu frequency scaling is in use. This cause Zynq arch to get support for timer delay and get_cycles(). Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: Michal Simek <michal.simek@xilinx.com> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210406130045.15491-3-andrea.merello@gmail.com
-
Andrea Merello authored
This patch adds rate change notification support for the parent clock; should that clock change, then we try to adjust the our prescaler in order to compensate (i.e. we adjust to still get the same timer frequency). This is loosely based on what it's done in timer-cadence-ttc. timer-sun51, mips-gic-timer and smp_twd.c also seem to look at their parent clock rate and to perform some kind of adjustment whenever needed. In this particular case we have only one single counter and prescaler for all clocksource, clockevent and timer_delay, and we just update it for all (i.e. we don't let it go and call clockevents_update_freq() to notify to the kernel that our rate has changed). Note that, there is apparently no other way to fixup things, because once we call register_current_timer_delay(), specifying the timer rate, it seems that that rate is not supposed to change ever. In order for this mechanism to work, we have to make assumptions about how much the initial clock is supposed to eventually decrease from the initial one, and set our initial prescaler to a value that we can eventually decrease enough to compensate. We provide an option in KConfig for this. In case we end up in a situation in which we are not able to compensate the parent clock change, we fail returning NOTIFY_BAD. This fixes a real-world problem with Zynq arch not being able to use this driver and CPU_FREQ at the same time (because ARM global timer is fed by the CPU clock, which may keep changing when CPU_FREQ is enabled). Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: Michal Simek <michal.simek@xilinx.com> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com> Reviewed-by:
Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210406130045.15491-2-andrea.merello@gmail.com
-
- Jun 15, 2021
-
-
周琰杰 (Zhou Yanjie) authored
1.Rename the "ingenic_ost_clk_info[]" to "x1000_ost_clk_info[]" to facilitate the addition of OST support for X2000 SoC in a later commit 2.When the OST support for X2000 SoC is added, there will be two compatible strings, so renaming "ingenic_ost_of_match[]" to "ingenic_ost_of_matches[]" is more reasonable 3.Remove the unnecessary comma in "ingenic_ost_of_matches[]" to reduce code size as much as possible. Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1622824306-30987-2-git-send-email-zhouyanjie@wanyeetech.com
-
Tony Lindgren authored
As we are using cpu_pm to save and restore context, we must also save and restore the timer sysconfig register TIOCP_CFG. This is needed because we are not calling PM runtime functions at all with cpu_pm. Fixes: b34677b0 ("clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore") Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Andreas Kemnade <andreas@kemnade.info> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210415085506.56828-1-tony@atomide.com
-
Evan Benn authored
Interrupts are disabled during suspend before this driver disables its timers. ARM trusted firmware will abort suspend if the timer irq is pending, so ack and disable the timer interrupt during suspend. Signed-off-by:
Evan Benn <evanbenn@chromium.org> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210512122528.v4.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid
-
- Jun 04, 2021
-
-
Krzysztof Kozlowski authored
The 'source_reg' IO memory is only read, so the pointer can point to const for safety. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210506202729.157260-4-krzysztof.kozlowski@canonical.com
-
Krzysztof Kozlowski authored
Failure of timer initialization is likely to be fatal for the system, so cleanup in such case is not strictly necessary. However the code might be refactored or reused, so better not to rely on such assumption that system won't continue init failure. Unmap the IO memory and put the clock on initialization failures from devicetree. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210506202729.157260-3-krzysztof.kozlowski@canonical.com
-
Krzysztof Kozlowski authored
The 'struct samsung_pwm_variant' argument passed to initialization functions is not modified, so it can be made const for safety. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210506202729.157260-2-krzysztof.kozlowski@canonical.com
-
Krzysztof Kozlowski authored
Cleanup the code to be slightly more readable and follow coding convention - only whitespace. This fixes checkpatch warnings: WARNING: Block comments should align the * on each line WARNING: please, no space before tabs WARNING: Missing a blank line after declarations CHECK: Alignment should match open parenthesis Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210506202729.157260-1-krzysztof.kozlowski@canonical.com
-
Jisheng Zhang authored
This variable is added by my mistake, it's not used at all. Fixes: e2bf384d ("clocksource/drivers/arm_arch_timer: Add __ro_after_init and __init") Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Acked-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210511154856.6afbcb65@xhacker.debian
-
- May 31, 2021
-
-
Will Deacon authored
With the introduction of per-cpu wakeup devices that can be used in preference to the broadcast timer, print the name of such devices when they are available. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210524221818.15850-6-will@kernel.org
-
Will Deacon authored
When configuring the broadcast timer on entry to and exit from deep idle states, prefer a per-CPU wakeup timer if one exists. On entry to idle, stop the tick device and transfer the next event into the oneshot wakeup device, which will serve as the wakeup from idle. To avoid the overhead of additional hardware accesses on exit from idle, leave the timer armed and treat the inevitable interrupt as a (possibly spurious) tick event. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210524221818.15850-5-will@kernel.org
-
Will Deacon authored
Some SoCs have two per-cpu timer implementations where the timer with the higher rating stops in deep idle (i.e. suffers from CLOCK_EVT_FEAT_C3STOP) but is otherwise preferable to the timer with the lower rating. In such a design, selecting the higher rated devices relies on a global broadcast timer and IPIs to wake up from deep idle states. To avoid the reliance on a global broadcast timer and also to reduce the overhead associated with the IPI wakeups, extend tick_install_broadcast_device() to manage per-cpu wakeup timers separately from the broadcast device. For now, these timers remain unused. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210524221818.15850-4-will@kernel.org
-
Will Deacon authored
In preparation for adding support for per-cpu wakeup timers, split _tick_broadcast_oneshot_control() into a helper function which deals only with the broadcast timer management across idle transitions. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210524221818.15850-3-will@kernel.org
-
Will Deacon authored
tick-broadcast.o is only built if CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y so remove the redundant #ifdef guards around the definition of tick_receive_broadcast(). Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210524221818.15850-2-will@kernel.org
-
YueHaibing authored
Use the DEVICE_ATTR_[RO|WO] helpers instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210523065825.19684-1-yuehaibing@huawei.com
-
Linus Torvalds authored
-
- May 30, 2021
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "This is a bit larger than usual at rc4 time. The reason is due to Lee's work of fixing newly reported build warnings. The rest is fixes as usual" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (22 commits) MAINTAINERS: adjust to removing i2c designware platform data i2c: s3c2410: fix possible NULL pointer deref on read message after write i2c: mediatek: Disable i2c start_en and clear intr_stat brfore reset i2c: i801: Don't generate an interrupt on bus reset i2c: mpc: implement erratum A-004447 workaround powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag i2c: busses: i2c-stm32f4: Remove incorrectly placed ' ' from function name i2c: busses: i2c-st: Fix copy/paste function misnaming issues i2c: busses: i2c-pnx: Provide descriptions for 'alg_data' data structure i2c: busses: i2c-ocores: Place the expected function names into the documentation headers i2c: busses: i2c-eg20t: Fix 'bad line' issue and provide description for 'msgs' param i2c: busses: i2c-designware-master: Fix misnaming of 'i2c_dw_init_master()' i2c: busses: i2c-cadence: Fix incorrectly documented 'enum cdns_i2c_slave_mode' i2c: busses: i2c-ali1563: File headers are not good candidates for kernel-doc i2c: muxes: i2c-arb-gpio-challenge: Demote non-conformant kernel-doc headers i2c: busses: i2c-nomadik: Fix formatting issue pertaining to 'timeout' i2c: sh_mobile: Use new clock calculation formulas for RZ/G2E i2c: I2C_HISI should depend on ACPI ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linuxLinus Torvalds authored
Pull seccomp fixes from Kees Cook: "This fixes a hard-to-hit race condition in the addfd user_notif feature of seccomp, visible since v5.9. And a small documentation fix" * tag 'seccomp-fixes-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: seccomp: Refactor notification handler to prepare for new semantics Documentation: seccomp: Fix user notification documentation
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Palmer Dabbelt: "A handful of RISC-V related fixes: - avoid errors when the stack tracing code is tracing itself. - resurrect the memtest= kernel command line argument on RISC-V, which was briefly enabled during the merge window before a refactoring disabled it. - build fix and some warning cleanups" * tag 'riscv-for-linus-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: kexec: Fix W=1 build warnings riscv: kprobes: Fix build error when MMU=n riscv: Select ARCH_USE_MEMTEST riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
Pull xfs fixes from Darrick Wong: "This week's pile mitigates some decades-old problems in how extent size hints interact with realtime volumes, fixes some failures in online shrink, and fixes a problem where directory and symlink shrinking on extremely fragmented filesystems could fail. The most user-notable change here is to point users at our (new) IRC channel on OFTC. Freedom isn't free, it costs folks like you and me; and if you don't kowtow, they'll expel everyone and take over your channel. (Ok, ok, that didn't fit the song lyrics...) Summary: - Fix a bug where unmapping operations end earlier than expected, which can cause chaos on multi-block directory and symlink shrink operations. - Fix an erroneous assert that can trigger if we try to transition a bmap structure from btree format to extents format with zero extents. This was exposed by xfs/538" * tag 'xfs-5.13-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: bunmapi has unnecessary AG lock ordering issues xfs: btree format inode forks can have zero extents xfs: add new IRC channel to MAINTAINERS xfs: validate extsz hints against rt extent size when rtinherit is set xfs: standardize extent size hint validation xfs: check free AG space when making per-AG reservations
-
Sargun Dhillon authored
This refactors the user notification code to have a do / while loop around the completion condition. This has a small change in semantic, in that previously we ignored addfd calls upon wakeup if the notification had been responded to, but instead with the new change we check for an outstanding addfd calls prior to returning to userspace. Rodrigo Campos also identified a bug that can result in addfd causing an early return, when the supervisor didn't actually handle the syscall [1]. [1]: https://lore.kernel.org/lkml/20210413160151.3301-1-rodrigo@kinvolk.io/ Fixes: 7cf97b12 ("seccomp: Introduce addfd ioctl to seccomp user notifier") Signed-off-by:
Sargun Dhillon <sargun@sargun.me> Acked-by:
Tycho Andersen <tycho@tycho.pizza> Acked-by:
Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Tested-by:
Rodrigo Campos <rodrigo@kinvolk.io> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210517193908.3113-3-sargun@sargun.me
-
git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linuxLinus Torvalds authored
Pull thermal fixes from Daniel Lezcano: - Fix uninitialized error code value for the SPMI adc driver (Yang Yingliang) - Fix kernel doc warning (Yang Li) - Fix wrong read-write thermal trip point initialization (Srinivas Pandruvada) * tag 'thermal-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux: thermal/drivers/qcom: Fix error code in adc_tm5_get_dt_channel_data() thermal/ti-soc-thermal: Fix kernel-doc thermal/drivers/intel: Initialize RW trip to THERMAL_TEMP_INVALID
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are some tiny char/misc driver fixes for 5.13-rc4. Nothing huge here, just some tiny fixes for reported issues: - two interconnect driver fixes - kgdb build warning fix for gcc-11 - hgafb regression fix - soundwire driver fix - mei driver fix All have been in linux-next with no reported issues" * tag 'char-misc-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: mei: request autosuspend after sending rx flow control kgdb: fix gcc-11 warnings harder video: hgafb: correctly handle card detect failure during probe soundwire: qcom: fix handling of qcom,ports-block-pack-mode interconnect: qcom: Add missing MODULE_DEVICE_TABLE interconnect: qcom: bcm-voter: add a missing of_node_put()
-
Linus Torvalds authored
Merge tag 'driver-core-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are three small driver core / debugfs fixes for 5.13-rc4: - debugfs fix for incorrect "lockdown" mode for selinux accesses - two device link changes, one bugfix and one cleanup All of these have been in linux-next for over a week with no reported problems" * tag 'driver-core-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers: base: Reduce device link removal code duplication drivers: base: Fix device link removal debugfs: fix security_locked_down() call for SELinux
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging and IIO driver fixes from Greg KH: "Here are some small IIO and staging driver fixes for reported issues for 5.13-rc4. Nothing major here, tiny changes for reported problems, full details are in the shortlog if people are curious. All have been in linux-next for a while with no reported problems" * tag 'staging-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: iio: adc: ad7793: Add missing error code in ad7793_setup() iio: adc: ad7923: Fix undersized rx buffer. iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp() iio: dac: ad5770r: Put fwnode in error case during ->probe() iio: gyro: fxas21002c: balance runtime power in error path staging: emxx_udc: fix loop in _nbu2ss_nuke() staging: iio: cdc: ad7746: avoid overwrite of num_channels iio: adc: ad7192: handle regulator voltage error first iio: adc: ad7192: Avoid disabling a clock that was never enabled. iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers iio: adc: ad7124: Fix missbalanced regulator enable / disable on error.
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty / serial driver fixes from Greg KH: "Here are some small fixes for reported problems for tty and serial drivers for 5.13-rc4. They consist of: - 8250 bugfixes and new device support - lockdown security mode fixup - syzbot found problems fixed - 8250_omap fix for interrupt storm - revert of 8250_omap driver fix as it caused worse problem than the original issue All but the last patch have been in linux-next for a while, the last one is a revert of a problem found in linux-next with the 8250_omap driver change" * tag 'tty-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "serial: 8250: 8250_omap: Fix possible interrupt storm" serial: 8250_pci: handle FL_NOIRQ board flag serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' serial: 8250_pci: Add support for new HPE serial device serial: 8250: 8250_omap: Fix possible interrupt storm serial: 8250: Use BIT(x) for UART_{CAP,BUG}_* serial: 8250: Add UART_BUG_TXRACE workaround for Aspeed VUART serial: 8250_dw: Add device HID for new AMD UART controller serial: sh-sci: Fix off-by-one error in FIFO threshold register setting serial: core: fix suspicious security_locked_down() call serial: tegra: Fix a mask operation that is always true
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB / Thunderbolt fixes from Greg KH: "Here are a number of tiny USB and Thunderbolt driver fixes for 5.13-rc4. They consist of: - thunderbolt fixes for some NVM bound issues - xhci fixes for reported problems - control-request fixups - documentation build warning fixes - new usb-serial driver device ids - typec bugfixes for reported issues - usbfs warning fixups (could be triggered from userspace) - other tiny fixes for reported problems. All of these have been in linux-next with no reported issues" * tag 'usb-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (22 commits) xhci: Fix 5.12 regression of missing xHC cache clearing command after a Stall xhci: fix giving back URB with incorrect status regression in 5.12 usb: gadget: udc: renesas_usb3: Fix a race in usb3_start_pipen() usb: typec: tcpm: Respond Not_Supported if no snk_vdo usb: typec: tcpm: Properly interrupt VDM AMS USB: trancevibrator: fix control-request direction usb: Restore the usb_header label usb: typec: tcpm: Use LE to CPU conversion when accessing msg->header usb: typec: ucsi: Clear pending after acking connector change usb: typec: mux: Fix matching with typec_altmode_desc misc/uss720: fix memory leak in uss720_probe usb: dwc3: gadget: Properly track pending and queued SG USB: usbfs: Don't WARN about excessively large memory allocations thunderbolt: usb4: Fix NVM read buffer bounds and offset issue thunderbolt: dma_port: Fix NVM read buffer bounds and offset issue usb: chipidea: udc: assign interrupt number to USB gadget structure usb: cdnsp: Fix lack of removing request from pending list. usb: cdns3: Fix runtime PM imbalance on error USB: serial: pl2303: add device id for ADLINK ND-6530 GC USB: serial: ti_usb_3410_5052: add startech.com device id ...
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fixes from Paolo Bonzini: "ARM fixes: - Another state update on exit to userspace fix - Prevent the creation of mixed 32/64 VMs - Fix regression with irqbypass not restarting the guest on failed connect - Fix regression with debug register decoding resulting in overlapping access - Commit exception state on exit to usrspace - Fix the MMU notifier return values - Add missing 'static' qualifiers in the new host stage-2 code x86 fixes: - fix guest missed wakeup with assigned devices - fix WARN reported by syzkaller - do not use BIT() in UAPI headers - make the kvm_amd.avic parameter bool PPC fixes: - make halt polling heuristics consistent with other architectures selftests: - various fixes - new performance selftest memslot_perf_test - test UFFD minor faults in demand_paging_test" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (44 commits) selftests: kvm: fix overlapping addresses in memslot_perf_test KVM: X86: Kill off ctxt->ud KVM: X86: Fix warning caused by stale emulation context KVM: X86: Use kvm_get_linear_rip() in single-step and #DB/#BP interception KVM: x86/mmu: Fix comment mentioning skip_4k KVM: VMX: update vcpu posted-interrupt descriptor when assigning device KVM: rename KVM_REQ_PENDING_TIMER to KVM_REQ_UNBLOCK KVM: x86: add start_assignment hook to kvm_x86_ops KVM: LAPIC: Narrow the timer latency between wait_lapic_expire and world switch selftests: kvm: do only 1 memslot_perf_test run by default KVM: X86: Use _BITUL() macro in UAPI headers KVM: selftests: add shared hugetlbfs backing source type KVM: selftests: allow using UFFD minor faults for demand paging KVM: selftests: create alias mappings when using shared memory KVM: selftests: add shmem backing source type KVM: selftests: refactor vm_mem_backing_src_type flags KVM: selftests: allow different backing source types KVM: selftests: compute correct demand paging size KVM: selftests: simplify setup_demand_paging error handling KVM: selftests: Print a message if /dev/kvm is missing ...
-
- May 29, 2021
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 fixes from Vasily Gorbik: "Fix races in vfio-ccw request handling" * tag 's390-5.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: vfio-ccw: Serialize FSM IDLE state with I/O completion vfio-ccw: Reset FSM state to IDLE inside FSM vfio-ccw: Check initialized flag in cp_init()
-