4.4.7-stable review
Greg Kroah-Hartman
maintainerPATCH 165/210 tracing: Fix crash from reading trace_pipe with sendfile
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Red Hat) <[email protected]>
commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream.
If tracing contains data and the trace_pipe file is read with sendfile(), then it can trigger a NULL pointer dereference and various BUG_ON within the VM code.
There's a patch to fix this in the splice_to_pipe() code, but it's also a good idea to not let that happen from trace_pipe either.
--- kernel/trace/trace.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/trace/trace.c +4 -1
@@ -4949,7 +4949,10 @@ static ssize_t tracing_splice_read_pipe( spd.nr_pages = i; - ret =splice_to_pipe (pipe, &spd); +if (i) + ret =splice_to_pipe (pipe, &spd); +else + ret =0 ; out:splice_shrink_spd (&spd);return ret;
Greg Kroah-Hartman
maintainerPATCH 166/210 tracing: Fix trace_printk() to print when not using bprintk()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Red Hat) <[email protected]>
commit 3debb0a9ddb16526de8b456491b7db60114f7b5e upstream.
The trace_printk() code will allocate extra buffers if the compile detects that a trace_printk() is used. To do this, the format of the trace_printk() is saved to the __trace_printk_fmt section, and if that section is bigger than zero, the buffers are allocated (along with a message that this has happened).
If trace_printk() uses a format that is not a constant, and thus something not guaranteed to be around when the print happens, the compiler optimizes the fmt out, as it is not used, and the __trace_printk_fmt section is not filled. This means the kernel will not allocate the special buffers needed for the trace_printk() and the trace_printk() will not write anything to the tracing buffer.
Adding a "__used" to the variable in the __trace_printk_fmt section will keep it around, even though it is set to NULL. This will keep the string from being printed in the debugfs/tracing/printk_formats section as it is not needed.
--- include/linux/kernel.h | 6 +++--- kernel/trace/trace_printk.c | 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-)
include/linux/kernel.h +3 -3
@@ -607,7 +607,7 @@ do { \ #define do_trace_printk(fmt, args...) \ do { \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(fmt) ? fmt : NULL; \ \
@@ -651,7 +651,7 @@ int __trace_printk(unsigned long ip, con*/ #define trace_puts (str) ({ \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(str) ? str : NULL; \ \
@@ -673,7 +673,7 @@ extern void trace_dump_stack(int skip);#define ftrace_vprintk (fmt, vargs) \ do { \ if (__builtin_constant_p(fmt)) { \ - static const char *trace_printk_fmt \ + static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(fmt) ? fmt : NULL; \ \
kernel/trace/trace_printk.c +3 -0
@@ -296,6 +296,9 @@ static int t_show(struct seq_file *m, voconst char *str = *fmt;int i; +if (!*fmt) +return 0 ; +seq_printf (m,"0x%lx : \"" , *(unsigned long *)fmt);/*
Greg Kroah-Hartman
maintainerPATCH 167/210 bitops: Do not default to __clear_bit() for __clear_bit_unlock()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit f75d48644c56a31731d17fa693c8175328957e1d upstream.
__clear_bit_unlock() is a special little snowflake. While it carries the non-atomic '__' prefix, it is specifically documented to pair with test_and_set_bit() and therefore should be 'somewhat' atomic.
Therefore the generic implementation of __clear_bit_unlock() cannot use the fully non-atomic __clear_bit() as a default.
If an arch is able to do better; is must provide an implementation of __clear_bit_unlock() itself.
Specifically, this came up as a result of hackbench livelock'ing in slab_lock() on ARC with SMP + SLUB + !LLSC.
The issue was incorrect pairing of atomic ops.
slab_lock() -> bit_spin_lock() -> test_and_set_bit() slab_unlock() -> __bit_spin_unlock() -> __clear_bit()
The non serializing __clear_bit() was getting "lost"
80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set 80543b90: or r3,r2,1 <--- (B) other core unlocks right here 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock)
Fixes ARC STAR 9000817404 (and probably more).
--- include/asm-generic/bitops/lock.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
include/asm-generic/bitops/lock.h +7 -7
@@ -29,16 +29,16 @@ do { \* @nr: the bit to set * @addr: the address to start counting from * -* This operation is like clear_bit_unlock, however it is not atomic. -* It does provide release barrier semantics so it can be used to unlock -* a bit lock, however it would only be used if no other CPU can modify -* any bits in the memory until the lock is released (a good example is -* if the bit lock itself protects access to the other bits in the word). +* A weaker form of clear_bit_unlock() as used by __bit_lock_unlock(). If all +* the bits in the word are protected by this lock some archs can use weaker +* ops to safely unlock. +* +* See for example x86's implementation. */ #define __clear_bit_unlock (nr, addr) \ do { \ - smp_mb(); \ - __clear_bit(nr, addr); \ + smp_mb__before_atomic(); \ + clear_bit(nr, addr); \ } while (0)#endif /* _ASM_GENERIC_BITOPS_LOCK_H_ */
Greg Kroah-Hartman
maintainerPATCH 168/210 scripts/coccinelle: modernize &
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julia Lawall <[email protected]>
commit 1b669e713f277a4d4b3cec84e13d16544ac8286d upstream.
& is no longer allowed in column 0, since Coccinelle 1.0.4.
--- scripts/coccinelle/iterators/use_after_iter.cocci | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/coccinelle/iterators/use_after_iter.cocci +1 -1
@@ -123,7 +123,7 @@ list_remove_head(x,c,...) | sizeof(<+...c...+>) | -&c->member + &c->member | c = E |
Greg Kroah-Hartman
maintainerPATCH 169/210 scripts/kconfig: allow building with make 3.80 again
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 42f9d3c6888bceef6dc7ba72c77acf47347dcf05 upstream.
Documentation/Changes still lists this as the minimal required version, so it ought to remain usable for the time being.
--- scripts/kconfig/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
scripts/kconfig/Makefile +3 -1
@@ -96,13 +96,15 @@ savedefconfig: $(obj)/conf defconfig: $(obj)/conf ifeq ($(KBUILD_DEFCONFIG),) $< $(silent) --defconfig $(Kconfig) -else ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) +else +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) @$(kecho) "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'" $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig) else @$(kecho) "*** Default configuration is based on target '$(KBUILD_DEFCONFIG)'" $(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG) endif +endif %_defconfig: $(obj)/conf $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
Greg Kroah-Hartman
maintainerPATCH 170/210 kbuild/mkspec: fix grub2 installkernel issue
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina <[email protected]>
commit c8b08ca558c0067bc9e15ce3f1e70af260410bb2 upstream.
mkspec is copying built kernel to temporrary location
/boot/vmlinuz-$KERNELRELEASE-rpm
and runs installkernel on it. This however directly leads to grub2 menuentry for this suffixed binary being generated as well during the run of installkernel script.
Later in the process the temporary -rpm suffixed files are removed, and therefore we end up with spurious (and non-functional) grub2 menu entries for each installed kernel RPM.
Fix that by using a different temporary name (prefixed by '.'), so that the binary is not recognized as an actual kernel binary and no menuentry is created for it.
--- scripts/package/mkspec | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
scripts/package/mkspec +4 -4
@@ -131,11 +131,11 @@ echo 'rm -rf $RPM_BUILD_ROOT' echo "" echo "%post" echo "if [ -x /sbin/installkernel -a -r /boot/vmlinuz-$KERNELRELEASE -a -r /boot/System.map-$KERNELRELEASE ]; then" -echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm" -echo "cp /boot/System.map-$KERNELRELEASE /boot/System.map-$KERNELRELEASE-rpm" +echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm" +echo "cp /boot/System.map-$KERNELRELEASE /boot/.System.map-$KERNELRELEASE-rpm" echo "rm -f /boot/vmlinuz-$KERNELRELEASE /boot/System.map-$KERNELRELEASE" -echo "/sbin/installkernel $KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" -echo "rm -f /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" +echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" +echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" echo "fi" echo "" echo "%files"
Greg Kroah-Hartman
maintainerPATCH 171/210 MAINTAINERS: Update mailing list and web page for hwmon subsystem
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit 968ce1b1f45a7d76b5471b19bd035dbecc72f32d upstream.
The old web page for the hwmon subsystem is no longer operational, and the mailing list has become unreliable. Move both to kernel.org.
--- MAINTAINERS | 96 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 48 insertions(+), 48 deletions(-)
MAINTAINERS +48 -48
@@ -230,13 +230,13 @@ F: kernel/sys_ni.c ABIT UGURU 1,2 HARDWARE MONITOR DRIVER M: Hans de Goede <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/abituguru.c ABIT UGURU 3 HARDWARE MONITOR DRIVER M: Alistair John Strachan <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/abituguru3.c
@@ -373,14 +373,14 @@ S: Maintained ADM1025 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/adm1025 F: drivers/hwmon/adm1025.c ADM1029 HARDWARE MONITOR DRIVER M: Corentin Labbe <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/adm1029.c
@@ -425,7 +425,7 @@ F: drivers/video/backlight/adp8860_bl.c ADS1015 HARDWARE MONITOR DRIVER M: Dirk Eibach <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ads1015 F: drivers/hwmon/ads1015.c
@@ -438,7 +438,7 @@ F: drivers/macintosh/therm_adt746x.c ADT7475 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/adt7475 F: drivers/hwmon/adt7475.c
@@ -615,7 +615,7 @@ F: include/linux/ccp.h AMD FAM15H PROCESSOR POWER MONITORING DRIVER M: Andreas Herrmann <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
@@ -779,7 +779,7 @@ F: drivers/input/mouse/bcm5974.c APPLE SMC DRIVER M: Henrik Rydberg <[email protected]> -L: [email protected] +L: [email protected] S: Odd fixes F: drivers/hwmon/applesmc.c
@@ -1777,7 +1777,7 @@ F: include/media/as3645a.h ASC7621 HARDWARE MONITOR DRIVER M: George Joseph <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/asc7621 F: drivers/hwmon/asc7621.c
@@ -1864,7 +1864,7 @@ F: drivers/net/wireless/ath/carl9170/ ATK0110 HWMON DRIVER M: Luca Tettamanti <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/asus_atk0110.c
@@ -2984,7 +2984,7 @@ F: mm/swap_cgroup.c CORETEMP HARDWARE MONITORING DRIVER M: Fenghua Yu <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/coretemp F: drivers/hwmon/coretemp.c
@@ -3549,7 +3549,7 @@ T: git git://git.infradead.org/users/vko DME1737 HARDWARE MONITOR DRIVER M: Juerg Haefliger <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/dme1737 F: drivers/hwmon/dme1737.c
@@ -4262,7 +4262,7 @@ F: include/video/exynos_mipi* F71805F HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/f71805f F: drivers/hwmon/f71805f.c
@@ -4341,7 +4341,7 @@ F: fs/* FINTEK F75375S HARDWARE MONITOR AND FAN CONTROLLER DRIVER M: Riku Voipio <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/f75375s.c F: include/linux/f75375s.h
@@ -4883,8 +4883,8 @@ F: drivers/media/usb/hackrf/ HARDWARE MONITORING M: Jean Delvare <[email protected]> M: Guenter Roeck <[email protected]> -L: [email protected] -W: http://www.lm-sensors.org/ +L: [email protected] +W: http://hwmon.wiki.kernel.org/ T: quilt http://jdelvare.nerim.net/devel/linux/jdelvare-hwmon/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git S: Maintained
@@ -5393,7 +5393,7 @@ F: drivers/usb/atm/ueagle-atm.c INA209 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ina209 F: Documentation/devicetree/bindings/i2c/ina209.txt
@@ -5401,7 +5401,7 @@ F: drivers/hwmon/ina209.c INA2XX HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ina2xx F: drivers/hwmon/ina2xx.c
@@ -5884,7 +5884,7 @@ F: drivers/isdn/hardware/eicon/ IT87 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/it87 F: drivers/hwmon/it87.c
@@ -5920,7 +5920,7 @@ F: drivers/media/dvb-frontends/ix2505v* JC42.4 TEMPERATURE SENSOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/jc42.c F: Documentation/hwmon/jc42
@@ -5970,14 +5970,14 @@ F: drivers/tty/serial/jsm/ K10TEMP HARDWARE MONITORING DRIVER M: Clemens Ladisch <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/k10temp F: drivers/hwmon/k10temp.c K8TEMP HARDWARE MONITORING DRIVER M: Rudolf Marek <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/k8temp F: drivers/hwmon/k8temp.c
@@ -6485,27 +6485,27 @@ F: net/llc/ LM73 HARDWARE MONITOR DRIVER M: Guillaume Ligneul <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/lm73.c LM78 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm78 F: drivers/hwmon/lm78.c LM83 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm83 F: drivers/hwmon/lm83.c LM90 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm90 F: Documentation/devicetree/bindings/hwmon/lm90.txt
@@ -6513,7 +6513,7 @@ F: drivers/hwmon/lm90.c LM95234 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/lm95234 F: drivers/hwmon/lm95234.c
@@ -6580,7 +6580,7 @@ F: drivers/scsi/sym53c8xx_2/ LTC4261 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/ltc4261 F: drivers/hwmon/ltc4261.c
@@ -6749,28 +6749,28 @@ F: include/uapi/linux/matroxfb.h MAX16065 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max16065 F: drivers/hwmon/max16065.c MAX20751 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max20751 F: drivers/hwmon/max20751.c MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER M: "Hans J. Koch" <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c MAX6697 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/max6697 F: Documentation/devicetree/bindings/i2c/max6697.txt
@@ -7303,7 +7303,7 @@ F: drivers/scsi/NCR_D700.* NCT6775 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/nct6775 F: drivers/hwmon/nct6775.c
@@ -8064,7 +8064,7 @@ F: drivers/video/logo/logo_parisc* PC87360 HARDWARE MONITORING DRIVER M: Jim Cromie <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/pc87360 F: drivers/hwmon/pc87360.c
@@ -8076,7 +8076,7 @@ F: drivers/char/pc8736x_gpio.c PC87427 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/pc87427 F: drivers/hwmon/pc87427.c
@@ -8415,8 +8415,8 @@ F: drivers/rtc/rtc-puv3.c PMBUS HARDWARE MONITORING DRIVERS M: Guenter Roeck <[email protected]> -L: [email protected] -W: http://www.lm-sensors.org/ +L: [email protected] +W: http://hwmon.wiki.kernel.org/ W: http://www.roeck-us.net/linux/drivers/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git S: Maintained
@@ -8610,7 +8610,7 @@ F: drivers/media/usb/pwc/* PWM FAN DRIVER M: Kamil Debski <[email protected]> -L: [email protected] +L: [email protected] S: Supported F: Documentation/devicetree/bindings/hwmon/pwm-fan.txt F: Documentation/hwmon/pwm-fan
@@ -9882,28 +9882,28 @@ F: Documentation/devicetree/bindings/med SMM665 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/smm665 F: drivers/hwmon/smm665.c SMSC EMC2103 HARDWARE MONITOR DRIVER M: Steve Glendinning <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/emc2103 F: drivers/hwmon/emc2103.c SMSC SCH5627 HARDWARE MONITOR DRIVER M: Hans de Goede <[email protected]> -L: [email protected] +L: [email protected] S: Supported F: Documentation/hwmon/sch5627 F: drivers/hwmon/sch5627.c SMSC47B397 HARDWARE MONITOR DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/smsc47b397 F: drivers/hwmon/smsc47b397.c
@@ -10830,7 +10830,7 @@ F: include/linux/mmc/sh_mobile_sdhi.h TMP401 HARDWARE MONITOR DRIVER M: Guenter Roeck <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/tmp401 F: drivers/hwmon/tmp401.c
@@ -11564,14 +11564,14 @@ F: Documentation/networking/vrf.txt VT1211 HARDWARE MONITOR DRIVER M: Juerg Haefliger <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/vt1211 F: drivers/hwmon/vt1211.c VT8231 HARDWARE MONITOR DRIVER M: Roger Lucas <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/vt8231.c
@@ -11590,21 +11590,21 @@ F: drivers/w1/ W83791D HARDWARE MONITORING DRIVER M: Marc Hulsman <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/w83791d F: drivers/hwmon/w83791d.c W83793 HARDWARE MONITORING DRIVER M: Rudolf Marek <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: Documentation/hwmon/w83793 F: drivers/hwmon/w83793.c W83795 HARDWARE MONITORING DRIVER M: Jean Delvare <[email protected]> -L: [email protected] +L: [email protected] S: Maintained F: drivers/hwmon/w83795.c
Greg Kroah-Hartman
maintainerPATCH 172/210 ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Dahlstrom <[email protected]>
commit 4db9675d927a71faa66e5ab128d2390d6329750b upstream.
Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail.
Add these models without an rfkill switch to the no_hw_rfkill list.
--- drivers/platform/x86/ideapad-laptop.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/platform/x86/ideapad-laptop.c +14 -0
@@ -865,6 +865,20 @@ static const struct dmi_system_id no_hw_ }, }, { + .ident = "Lenovo ideapad Y700-15ISK", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700-15ISK"), + }, + }, + { + .ident ="Lenovo ideapad Y700 Touch-15ISK" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700 Touch-15ISK"), + }, + }, + { .ident ="Lenovo ideapad Y700-17ISK" , .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
Greg Kroah-Hartman
maintainerPATCH 173/210 mmc: block: fix ABI regression of mmc_blk_ioctl
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Lin <[email protected]>
commit 83c742c344c08c2bbe338d45c6ec63110e9d5e3d upstream.
If mmc_blk_ioctl returns -EINVAL, blkdev_ioctl continues to work without returning err to user-space. But now we check CAP_SYS_RAWIO firstly, so we return -EPERM to blkdev_ioctl, which make blkdev_ioctl return -EPERM to user-space directly. So this will break all the ioctl with BLKROSET. Now we find Android-adb suffer it for the following log:
remount of /system failed;
couldn't make block device writable: Operation not permitted openat(AT_FDCWD, "/dev/block/platform/ff420000.dwmmc/by-name/system", O_RDONLY) = 3 ioctl(3, BLKROSET, 0) = -1 EPERM (Operation not permitted)
--- drivers/mmc/card/block.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)
drivers/mmc/card/block.c +16 -8
@@ -596,6 +596,14 @@ static int mmc_blk_ioctl_cmd(struct blocstruct mmc_card *card;int err =0 , ioc_err =0 ; +/* +* The caller must have CAP_SYS_RAWIO, and must be calling this on the +* whole block device, not on a partition. This prevents overspray +* between sibling partitions. +*/ +if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) +return -EPERM ; + idata =mmc_blk_ioctl_copy_from_user (ic_ptr);if (IS_ERR (idata))return PTR_ERR (idata);
@@ -638,6 +646,14 @@ static int mmc_blk_ioctl_multi_cmd(strucint i, err =0 , ioc_err =0 ;__u64 num_of_cmds; +/* +* The caller must have CAP_SYS_RAWIO, and must be calling this on the +* whole block device, not on a partition. This prevents overspray +* between sibling partitions. +*/ +if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) +return -EPERM ; +if (copy_from_user (&num_of_cmds, &user->num_of_cmds,sizeof (num_of_cmds)))return -EFAULT ;
@@ -693,14 +709,6 @@ cmd_err:static int mmc_blk_ioctl (struct block_device *bdev,fmode_t mode,unsigned int cmd,unsigned long arg) { -/* -* The caller must have CAP_SYS_RAWIO, and must be calling this on the -* whole block device, not on a partition. This prevents overspray -* between sibling partitions. -*/ -if ((!capable (CAP_SYS_RAWIO )) || (bdev != bdev->bd_contains)) -return -EPERM ; -switch (cmd) {case MMC_IOC_CMD : return mmc_blk_ioctl_cmd(bdev,
Greg Kroah-Hartman
maintainerPATCH 174/210 mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Magnus Damm <[email protected]>
commit bcdc9f260bdce09913db1464be9817170d51044a upstream.
This patch fixes the MMC SPI driver from doing polling card detect when a CD GPIO that supports interrupts is specified using the gpios DT property.
Without this patch the DT node below results in the following output:
spi_gpio: spi-gpio { /* SD2 @ CN12 */
compatible = "spi-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>;
status = "okay";
spi@0 {
compatible = "mmc-spi-slot";
reg = <0>;
voltage-ranges = <3200 3400>;
spi-max-frequency = <25000000>;
gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; /* CD */
};};
# dmesg | grep mmc mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling mmc0: host does not support reading read-only switch, assuming write-enable mmc0: new SDHC card on SPI mmcblk0: mmc0:0000 SU04G 3.69 GiB mmcblk0: p1
With this patch applied the "cd polling" portion above disappears.
--- drivers/mmc/host/mmc_spi.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/mmc/host/mmc_spi.c +6 -0
@@ -1436,6 +1436,12 @@ static int mmc_spi_probe(struct spi_devi host->pdata->cd_debounce);if (status !=0 ) goto fail_add_host; + +/* The platform has a CD GPIO signal that may support +* interrupts, so let mmc_gpiod_request_cd_irq() decide +* if polling is needed or not. +*/ + mmc->caps &= ~MMC_CAP_NEEDS_POLL ;mmc_gpiod_request_cd_irq (mmc); }
Greg Kroah-Hartman
maintainerPATCH 175/210 mmc: sdhci: fix data timeout (part 1)
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit fafcfda9e78cae8796d1799f14e6457790797555 upstream.
The data timeout gives the minimum amount of time that should be waited before timing out if no data is received from the card. Simply dividing the nanosecond part by 1000 does not give this required guarantee, since such a division rounds down. Use DIV_ROUND_UP() to give the desired timeout.
--- drivers/mmc/host/sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +1 -1
@@ -666,7 +666,7 @@ static u8 sdhci_calc_timeout(struct sdhcif (!data) target_timeout = cmd->busy_timeout *1000 ;else { - target_timeout = data->timeout_ns /1000 ; + target_timeout =DIV_ROUND_UP (data->timeout_ns,1000 );if (host->clock) target_timeout += data->timeout_clks / host->clock; }
Greg Kroah-Hartman
maintainerPATCH 176/210 mmc: sdhci: fix data timeout (part 2)
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 7f05538af71c7d30b5fc821cbe9f318edc645961 upstream.
The calculation for the timeout based on the number of card clocks is incorrect. The calculation assumed:
timeout in microseconds = clock cycles / clock in Hz
which is clearly a several orders of magnitude wrong. Fix this by multiplying the clock cycles by 1000000 prior to dividing by the Hz based clock. Also, as per part 1, ensure that the division rounds up.
As this needs 64-bit math via do_div(), avoid it if the clock cycles is zero.
--- drivers/mmc/host/sdhci.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci.c +13 -2
@@ -667,8 +667,19 @@ static u8 sdhci_calc_timeout(struct sdhc target_timeout = cmd->busy_timeout *1000 ; else { target_timeout =DIV_ROUND_UP (data->timeout_ns,1000 ); -if (host->clock) - target_timeout += data->timeout_clks / host->clock; +if (host->clock && data->timeout_clks) { +unsigned long long val; + +/* +* data->timeout_clks is in units of clock cycles. +* host->clock is in Hz. target_timeout is in us. +* Hence, us = 1000000 * cycles / Hz. Round up. +*/ + val =1000000 * data->timeout_clks; +if (do_div (val, host->clock)) + target_timeout++; + target_timeout += val; + } }/*
Greg Kroah-Hartman
maintainerPATCH 177/210 mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit 995136247915c5cee633d55ba23f6eebf67aa567 upstream.
Normally the timeout clock frequency is read from the capabilities register. It is also possible to set the value prior to calling sdhci_add_host() in which case that value will override the capabilities register value. However that was being done after calculating max_busy_timeout so that max_busy_timeout was being calculated using the wrong value of timeout_clk.
Fix that by moving the override before max_busy_timeout is calculated.
The result is that the max_busy_timeout and max_discard increase for BSW devices so that, for example, the time for mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds to about 20 seconds.
Note, in the future, the capabilities setting will be tidied up and this override won't be used anymore. However this fix is needed for stable.
--- drivers/mmc/host/sdhci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mmc/host/sdhci.c +3 -3
@@ -3106,14 +3106,14 @@ int sdhci_add_host(struct sdhci_host *hoif (caps[0 ] &SDHCI_TIMEOUT_CLK_UNIT ) host->timeout_clk *=1000 ; +if (override_timeout_clk) + host->timeout_clk = override_timeout_clk; + mmc->max_busy_timeout = host->ops->get_max_timeout_count ? host->ops->get_max_timeout_count (host) :1 <<27 ; mmc->max_busy_timeout /= host->timeout_clk; } -if (override_timeout_clk) - host->timeout_clk = override_timeout_clk; - mmc->caps |=MMC_CAP_SDIO_IRQ |MMC_CAP_ERASE |MMC_CAP_CMD23 ; mmc->caps2 |=MMC_CAP2_SDIO_IRQ_NOTHREAD ;
Greg Kroah-Hartman
maintainerPATCH 178/210 clk: rockchip: rk3368: fix cpuclk mux bit of big cpu-cluster
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit 535ebd428aeb07c3327947281306f2943f2c9faa upstream.
Both clusters have their mux bit in bit 7 of their respective register. For whatever reason the big cluster currently lists bit 15 which is definitly wrong.
--- drivers/clk/rockchip/clk-rk3368.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/rockchip/clk-rk3368.c +1 -1
@@ -165,7 +165,7 @@ static const struct rockchip_cpuclk_reg_ .core_reg = RK3368_CLKSEL_CON(0), .div_core_shift = 0, .div_core_mask = 0x1f, - .mux_core_shift = 15, + .mux_core_shift = 7, };static const struct rockchip_cpuclk_reg_data rk3368_cpuclkl_data = {
Greg Kroah-Hartman
maintainerPATCH 179/210 clk: rockchip: rk3368: fix cpuclk core dividers
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit c6d5fe2ca8286f35a79f7345c9378c39d48a1527 upstream.
Similar to commit 9880d4277f6a ("clk: rockchip: fix rk3288 cpuclk core dividers") it seems the cpuclk dividers are one to high on the rk3368 as well.
And again similar to the previous fix, we opt to make the divider list contain the values to be written to use the same paradigm for them on all supported socs.
--- drivers/clk/rockchip/clk-rk3368.c | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-)
drivers/clk/rockchip/clk-rk3368.c +20 -20
@@ -218,29 +218,29 @@ static const struct rockchip_cpuclk_reg_ }static struct rockchip_cpuclk_rate_table rk3368_cpuclkb_rates[]__initdata = { -RK3368_CPUCLKB_RATE (1512000000 ,2 ,6 ,6 ), -RK3368_CPUCLKB_RATE (1488000000 ,2 ,5 ,5 ), -RK3368_CPUCLKB_RATE (1416000000 ,2 ,5 ,5 ), -RK3368_CPUCLKB_RATE (1200000000 ,2 ,4 ,4 ), -RK3368_CPUCLKB_RATE (1008000000 ,2 ,4 ,4 ), -RK3368_CPUCLKB_RATE (816000000 ,2 ,3 ,3 ), -RK3368_CPUCLKB_RATE (696000000 ,2 ,3 ,3 ), -RK3368_CPUCLKB_RATE (600000000 ,2 ,2 ,2 ), -RK3368_CPUCLKB_RATE (408000000 ,2 ,2 ,2 ), -RK3368_CPUCLKB_RATE (312000000 ,2 ,2 ,2 ), +RK3368_CPUCLKB_RATE (1512000000 ,1 ,5 ,5 ), +RK3368_CPUCLKB_RATE (1488000000 ,1 ,4 ,4 ), +RK3368_CPUCLKB_RATE (1416000000 ,1 ,4 ,4 ), +RK3368_CPUCLKB_RATE (1200000000 ,1 ,3 ,3 ), +RK3368_CPUCLKB_RATE (1008000000 ,1 ,3 ,3 ), +RK3368_CPUCLKB_RATE (816000000 ,1 ,2 ,2 ), +RK3368_CPUCLKB_RATE (696000000 ,1 ,2 ,2 ), +RK3368_CPUCLKB_RATE (600000000 ,1 ,1 ,1 ), +RK3368_CPUCLKB_RATE (408000000 ,1 ,1 ,1 ), +RK3368_CPUCLKB_RATE (312000000 ,1 ,1 ,1 ), };static struct rockchip_cpuclk_rate_table rk3368_cpuclkl_rates[]__initdata = { -RK3368_CPUCLKL_RATE (1512000000 ,2 ,7 ,7 ), -RK3368_CPUCLKL_RATE (1488000000 ,2 ,6 ,6 ), -RK3368_CPUCLKL_RATE (1416000000 ,2 ,6 ,6 ), -RK3368_CPUCLKL_RATE (1200000000 ,2 ,5 ,5 ), -RK3368_CPUCLKL_RATE (1008000000 ,2 ,5 ,5 ), -RK3368_CPUCLKL_RATE (816000000 ,2 ,4 ,4 ), -RK3368_CPUCLKL_RATE (696000000 ,2 ,3 ,3 ), -RK3368_CPUCLKL_RATE (600000000 ,2 ,3 ,3 ), -RK3368_CPUCLKL_RATE (408000000 ,2 ,2 ,2 ), -RK3368_CPUCLKL_RATE (312000000 ,2 ,2 ,2 ), +RK3368_CPUCLKL_RATE (1512000000 ,1 ,6 ,6 ), +RK3368_CPUCLKL_RATE (1488000000 ,1 ,5 ,5 ), +RK3368_CPUCLKL_RATE (1416000000 ,1 ,5 ,5 ), +RK3368_CPUCLKL_RATE (1200000000 ,1 ,4 ,4 ), +RK3368_CPUCLKL_RATE (1008000000 ,1 ,4 ,4 ), +RK3368_CPUCLKL_RATE (816000000 ,1 ,3 ,3 ), +RK3368_CPUCLKL_RATE (696000000 ,1 ,2 ,2 ), +RK3368_CPUCLKL_RATE (600000000 ,1 ,2 ,2 ), +RK3368_CPUCLKL_RATE (408000000 ,1 ,1 ,1 ), +RK3368_CPUCLKL_RATE (312000000 ,1 ,1 ,1 ), };static struct rockchip_clk_branch rk3368_clk_branches[]__initdata = {
Greg Kroah-Hartman
maintainerPATCH 180/210 clk: rockchip: rk3368: fix parents of video encoder/decoder
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit 0f28d98463498c61c61a38aacbf9f69e92e85e9d upstream.
The vdpu and vepu clocks can also be parented to the npll and current parent list also is wrong as it would use the npll as "usbphy" source, so adapt the parent to the correct one.
--- drivers/clk/rockchip/clk-rk3368.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/rockchip/clk-rk3368.c +2 -2
@@ -384,10 +384,10 @@ static struct rockchip_clk_branch rk3368* Clock-Architecture Diagram 3 */ -COMPOSITE (0 ,"aclk_vepu" , mux_pll_src_cpll_gpll_usb_p,0 , +COMPOSITE (0 ,"aclk_vepu" , mux_pll_src_cpll_gpll_npll_usb_p,0 ,RK3368_CLKSEL_CON (15 ),6 ,2 ,MFLAGS ,0 ,5 ,DFLAGS ,RK3368_CLKGATE_CON (4 ),6 ,GFLAGS ), -COMPOSITE (0 ,"aclk_vdpu" , mux_pll_src_cpll_gpll_usb_p,0 , +COMPOSITE (0 ,"aclk_vdpu" , mux_pll_src_cpll_gpll_npll_usb_p,0 ,RK3368_CLKSEL_CON (15 ),14 ,2 ,MFLAGS ,8 ,5 ,DFLAGS , RK3368_CLKGATE_CON(4), 7, GFLAGS),
Greg Kroah-Hartman
maintainerPATCH 181/210 clk: rockchip: rk3368: fix hdmi_cec gate-register
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Stuebner <[email protected]>
commit fd0c0740fac17a014704ef89d8c8b1768711ca59 upstream.
Fix a typo making the sclk_hdmi_cec access a wrong register to handle its gate.
--- drivers/clk/rockchip/clk-rk3368.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/rockchip/clk-rk3368.c +1 -1
@@ -442,7 +442,7 @@ static struct rockchip_clk_branch rk3368GATE (SCLK_HDMI_HDCP ,"sclk_hdmi_hdcp" ,"xin24m" ,0 ,RK3368_CLKGATE_CON (4 ),13 ,GFLAGS ),GATE (SCLK_HDMI_CEC ,"sclk_hdmi_cec" ,"xin32k" ,0 , -RK3368_CLKGATE_CON (5 ),12 ,GFLAGS ), +RK3368_CLKGATE_CON (4 ),12 ,GFLAGS ), COMPOSITE_NODIV(0, "vip_src", mux_pll_src_cpll_gpll_p, 0, RK3368_CLKSEL_CON(21), 15, 1, MFLAGS,
Greg Kroah-Hartman
maintainerPATCH 182/210 clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Kochetkov <[email protected]>
commit e8b63288b37dbb8457b510c9d96f6006da4653f6 upstream.
hclk_cpubus needs to keep running because it is needed for devices like the rom, i2s0 or spdif to be accessible via cpu. Without that all accesses to devices (readl/writel) return wrong data. So add it to the list of critical clocks.
--- drivers/clk/rockchip/clk-rk3188.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/rockchip/clk-rk3188.c +1 -0
@@ -718,6 +718,7 @@ static const char *const rk3188_critical"hclk_peri" ,"pclk_cpu" ,"pclk_peri" , + "hclk_cpubus" };static void __init rk3188_common_clk_init (struct device_node *np)
Greg Kroah-Hartman
maintainerPATCH 183/210 clk: bcm2835: Fix setting of PLL divider clock rates
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
commit 773b3966dd3cdaeb68e7f2edfe5656abac1dc411 upstream.
Our dividers weren't being set successfully because CM_PASSWORD wasn't included in the register write. It looks easier to just compute the divider to write ourselves than to update clk-divider for the ability to OR in some arbitrary bits on write.
Fixes about half of the video modes on my HDMI monitor (everything except 720x400).
--- drivers/clk/bcm/clk-bcm2835.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +7 -5
@@ -1097,13 +1097,15 @@ static int bcm2835_pll_divider_set_rate(struct bcm2835_pll_divider *divider =bcm2835_pll_divider_from_hw (hw);struct bcm2835_cprman *cprman = divider->cprman;const struct bcm2835_pll_divider_data *data = divider->data; -u32 cm; -int ret; +u32 cm, div, max_div =1 <<A2W_PLL_DIV_BITS ; - ret = clk_divider_ops.set_rate (hw, rate, parent_rate); -if (ret) -return ret; + div =DIV_ROUND_UP_ULL (parent_rate, rate); + div =min (div, max_div); +if (div == max_div) + div =0 ; + +cprman_write (cprman, data->a2w_reg, div); cm =cprman_read (cprman, data->cm_reg);cprman_write (cprman, data->cm_reg, cm | data->load_mask);cprman_write (cprman, data->cm_reg, cm & ~data->load_mask);
Greg Kroah-Hartman
maintainerPATCH 184/210 target: Fix target_release_cmd_kref shutdown comp leak
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Himanshu Madhani <[email protected]>
commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e upstream.
This patch fixes an active I/O shutdown bug for fabric drivers using target_wait_for_sess_cmds(), where se_cmd descriptor shutdown would result in hung tasks waiting indefinitely for se_cmd->cmd_wait_comp to complete().
To address this bug, drop the incorrect list_del_init() usage in target_wait_for_sess_cmds() and always complete() during se_cmd target_release_cmd_kref() put, in order to let caller invoke the final fabric release callback into se_cmd->se_tfo->release_cmd() code.
--- drivers/target/target_core_transport.c | 2 -- 1 file changed, 2 deletions(-)
drivers/target/target_core_transport.c +0 -2
@@ -2618,8 +2618,6 @@ void target_wait_for_sess_cmds(struct selist_for_each_entry_safe (se_cmd, tmp_cmd, &se_sess->sess_wait_list, se_cmd_list) { -list_del_init (&se_cmd->se_cmd_list); -pr_debug ("Waiting for se_cmd: %p t_state: %d, fabric state:" " %d\n" , se_cmd, se_cmd->t_state, se_cmd->se_tfo->get_cmd_state (se_cmd));
Greg Kroah-Hartman
maintainerPATCH 185/210 iser-target: Fix identification of login rx descriptor type
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit b89a7c25462b164db280abc3b05d4d9d888d40e9 upstream.
Once connection request is accepted, one rx descriptor is posted to receive login request. This descriptor has rx type, but is outside the main pool of rx descriptors, and thus was mistreated as tx type.
--- drivers/infiniband/ulp/isert/ib_isert.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/ulp/isert/ib_isert.c +2 -1
@@ -2035,7 +2035,8 @@ is_isert_tx_desc(struct isert_conn *iservoid *start = isert_conn->rx_descs;int len =ISERT_QP_MAX_RECV_DTOS *sizeof (*isert_conn->rx_descs); -if (wr_id >= start && wr_id < start + len) +if ((wr_id >= start && wr_id < start + len) || + (wr_id == isert_conn->login_req_buf))return false;return true;
Greg Kroah-Hartman
maintainerPATCH 186/210 iser-target: Add new state ISER_CONN_BOUND to isert_conn
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit aea92980601f7ddfcb3c54caa53a43726314fe46 upstream.
We need an indication that isert_conn->iscsi_conn binding has happened so we'll know not to invoke a connection reinstatement on an unbound connection which will lead to a bogus isert_conn->conn dereferece.
--- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++++-- drivers/infiniband/ulp/isert/ib_isert.h | 1 + 2 files changed, 6 insertions(+), 2 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +5 -2
@@ -820,7 +820,7 @@ isert_put_conn(struct isert_conn *isert_* @isert_conn: isert connection struct * * Notes: -* In case the connection state is FULL_FEATURE, move state +* In case the connection state is BOUND, move state * to TEMINATING and start teardown sequence (rdma_disconnect). * In case the connection state is UP, complete flush as well. *
@@ -836,6 +836,7 @@ isert_conn_terminate(struct isert_conn *case ISER_CONN_TERMINATING :break ;case ISER_CONN_UP : +case ISER_CONN_BOUND :case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ isert_info ("Terminating conn %p state %d\n" , isert_conn, isert_conn->state);
@@ -2062,7 +2063,8 @@ isert_cq_comp_err(struct isert_conn *iseisert_completion_put (desc, isert_cmd, ib_dev, true); }else { isert_conn->post_recv_buf_count--; -if (!isert_conn->post_recv_buf_count) +if (!isert_conn->post_recv_buf_count && + isert_conn->state >=ISER_CONN_BOUND )iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); } }
@@ -3194,6 +3196,7 @@ accept_wait: conn->context = isert_conn; isert_conn->conn = conn; + isert_conn->state =ISER_CONN_BOUND ;isert_set_conn_info (np, conn, isert_conn);
drivers/infiniband/ulp/isert/ib_isert.h +1 -0
@@ -50,6 +50,7 @@ enum iser_ib_op_code {enum iser_conn_state {ISER_CONN_INIT ,ISER_CONN_UP , +ISER_CONN_BOUND ,ISER_CONN_FULL_FEATURE ,ISER_CONN_TERMINATING ,ISER_CONN_DOWN ,
Greg Kroah-Hartman
maintainerPATCH 187/210 iser-target: Separate flows for np listeners and connections cma events
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit f81bf458208ef6d12b2fc08091204e3859dcdba4 upstream.
No need to restrict this check to specific events.
--- drivers/infiniband/ulp/isert/ib_isert.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +5 -6
@@ -884,14 +884,9 @@ isert_disconnected_handler(struct rdma_c enum rdma_cm_event_type event) {struct isert_np *isert_np = cma_id->context; -struct isert_conn *isert_conn; +struct isert_conn *isert_conn = cma_id->qp->qp_context;bool terminating = false; -if (isert_np->cm_id == cma_id) -return isert_np_cma_handler (cma_id->context, event); - - isert_conn = cma_id->qp->qp_context; -mutex_lock (&isert_conn->mutex); terminating = (isert_conn->state ==ISER_CONN_TERMINATING );isert_conn_terminate (isert_conn);
@@ -930,12 +925,16 @@ isert_connect_error(struct rdma_cm_id *cstatic int isert_cma_handler (struct rdma_cm_id *cma_id,struct rdma_cm_event *event) { +struct isert_np *isert_np = cma_id->context;int ret =0 ;isert_info ("%s (%d): status %d id %p np %p\n" ,rdma_event_msg (event->event), event->event, event->status, cma_id, cma_id->context); +if (isert_np->cm_id == cma_id) +return isert_np_cma_handler (cma_id->context, event->event); +switch (event->event) {case RDMA_CM_EVENT_CONNECT_REQUEST : ret =isert_connect_request (cma_id, event);
Greg Kroah-Hartman
maintainerPATCH 188/210 iser-target: Rework connection termination
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jenny Derzhavetz <[email protected]>
commit 6d1fba0c2cc7efe42fd761ecbba833ed0ea7b07e upstream.
When we receive an event that triggers connection termination,
we have a a couple of things we may want to do:
1. In case we are already terminating, bailout early
2. In case we are connected but not bound, disconnect and schedule a connection cleanup silently (don't reinstate)
3. In case we are connected and bound, disconnect and reinstate the connection
This rework fixes a bug that was detected against a mis-behaved initiator which rejected our rdma_cm accept, in this stage the isert_conn is no bound and reinstate caused a bogus dereference.
What's great about this is that we don't need thepost_recv_buf_count anymore, so get rid of it.
--- drivers/infiniband/ulp/isert/ib_isert.c | 107 +++++++++++++++----------------- drivers/infiniband/ulp/isert/ib_isert.h | 1 2 files changed, 52 insertions(+), 56 deletions(-)
drivers/infiniband/ulp/isert/ib_isert.c +52 -55
@@ -66,6 +66,7 @@ isert_rdma_accept(struct isert_conn *isestruct rdma_cm_id *isert_setup_id (struct isert_np *isert_np);static void isert_release_work (struct work_struct *work); +static void isert_wait4flush (struct isert_conn *isert_conn);static inline bool isert_prot_cmd (struct isert_conn *conn,struct se_cmd *cmd)
@@ -815,6 +816,25 @@ isert_put_conn(struct isert_conn *isert_kref_put (&isert_conn->kref, isert_release_kref); } +static void +isert_handle_unbound_conn (struct isert_conn *isert_conn) +{ +struct isert_np *isert_np = isert_conn->cm_id->context; + +mutex_lock (&isert_np->mutex); +if (!list_empty (&isert_conn->node)) { +/* +* This means iscsi doesn't know this connection +* so schedule a cleanup ourselves +*/ +list_del_init (&isert_conn->node); +isert_put_conn (isert_conn); +complete (&isert_conn->wait); +queue_work (isert_release_wq, &isert_conn->release_work); + } +mutex_unlock (&isert_np->mutex); +} +/** * isert_conn_terminate() - Initiate connection termination * @isert_conn: isert connection struct
@@ -832,24 +852,19 @@ isert_conn_terminate(struct isert_conn * {int err; -switch (isert_conn->state) { -case ISER_CONN_TERMINATING : -break ; -case ISER_CONN_UP : -case ISER_CONN_BOUND : -case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ -isert_info ("Terminating conn %p state %d\n" , - isert_conn, isert_conn->state); - isert_conn->state =ISER_CONN_TERMINATING ; - err =rdma_disconnect (isert_conn->cm_id); -if (err) -isert_warn ("Failed rdma_disconnect isert_conn %p\n" , - isert_conn); -break ; -default : -isert_warn ("conn %p teminating in state %d\n" , - isert_conn, isert_conn->state); - } +if (isert_conn->state >=ISER_CONN_TERMINATING ) +return ; + +isert_info ("Terminating conn %p state %d\n" , + isert_conn, isert_conn->state); + isert_conn->state =ISER_CONN_TERMINATING ; + err =rdma_disconnect (isert_conn->cm_id); +if (err) +isert_warn ("Failed rdma_disconnect isert_conn %p\n" , + isert_conn); + +isert_info ("conn %p completing wait\n" , isert_conn); +complete (&isert_conn->wait); } static int
@@ -883,30 +898,27 @@ static int isert_disconnected_handler(struct rdma_cm_id *cma_id, enum rdma_cm_event_type event) { - struct isert_np *isert_np = cma_id->context; struct isert_conn *isert_conn = cma_id->qp->qp_context; -bool terminating = false;mutex_lock (&isert_conn->mutex); - terminating = (isert_conn->state ==ISER_CONN_TERMINATING ); -isert_conn_terminate (isert_conn); -mutex_unlock (&isert_conn->mutex); - -isert_info ("conn %p completing wait\n" , isert_conn); -complete (&isert_conn->wait); - -if (terminating) - goto out; - -mutex_lock (&isert_np->mutex); -if (!list_empty (&isert_conn->node)) { -list_del_init (&isert_conn->node); -isert_put_conn (isert_conn); -queue_work (isert_release_wq, &isert_conn->release_work); +switch (isert_conn->state) { +case ISER_CONN_TERMINATING : +break ; +case ISER_CONN_UP : +isert_conn_terminate (isert_conn); +isert_wait4flush (isert_conn); +isert_handle_unbound_conn (isert_conn); +break ; +case ISER_CONN_BOUND : +case ISER_CONN_FULL_FEATURE :/* FALLTHRU */ +iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); +break ; +default : +isert_warn ("conn %p teminating in state %d\n" , + isert_conn, isert_conn->state); } -mutex_unlock (&isert_np->mutex); +mutex_unlock (&isert_conn->mutex); -out:return 0 ; }
@@ -980,13 +992,10 @@ isert_post_recvm(struct isert_conn *iser rx_wr--; rx_wr->next =NULL ;/* mark end of work requests list */ - isert_conn->post_recv_buf_count += count; ret =ib_post_recv (isert_conn->qp, isert_conn->rx_wr, &rx_wr_failed); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed with ret: %d\n" , ret); - isert_conn->post_recv_buf_count -= count; - }return ret; }
@@ -1002,12 +1011,9 @@ isert_post_recv(struct isert_conn *isert rx_wr.num_sge =1 ; rx_wr.next =NULL ; - isert_conn->post_recv_buf_count++; ret =ib_post_recv (isert_conn->qp, &rx_wr, &rx_wr_failed); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed with ret: %d\n" , ret); - isert_conn->post_recv_buf_count--; - }return ret; }
@@ -1120,12 +1126,9 @@ isert_rdma_post_recvl(struct isert_conn rx_wr.sg_list = &sge; rx_wr.num_sge =1 ; - isert_conn->post_recv_buf_count++; ret =ib_post_recv (isert_conn->qp, &rx_wr, &rx_wr_fail); -if (ret) { +if (ret)isert_err ("ib_post_recv() failed: %d\n" , ret); - isert_conn->post_recv_buf_count--; - }return ret; }
@@ -1620,7 +1623,6 @@ isert_rcv_completion(struct iser_rx_descib_dma_sync_single_for_device (ib_dev, rx_dma, rx_buflen,DMA_FROM_DEVICE ); - isert_conn->post_recv_buf_count--; } static int
@@ -2060,11 +2062,6 @@ isert_cq_comp_err(struct isert_conn *iseisert_unmap_tx_desc (desc, ib_dev); elseisert_completion_put (desc ,isert_cmd ,ib_dev ,true ); - }else { - isert_conn->post_recv_buf_count--; -if (!isert_conn->post_recv_buf_count && - isert_conn->state >=ISER_CONN_BOUND ) -iscsit_cause_connection_reinstatement (isert_conn->conn,0 ); } }
drivers/infiniband/ulp/isert/ib_isert.h +0 -1
@@ -145,7 +145,6 @@ struct isert_device;struct isert_conn {enum iser_conn_state state; -int post_recv_buf_count;u32 responder_resources;u32 initiator_depth;bool pi_support;
Greg Kroah-Hartman
maintainerPATCH 189/210 nfsd4: fix bad bounds checking
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit 4aed9c46afb80164401143aa0fdcfe3798baa9d5 upstream.
A number of spots in the xdr decoding follow a pattern like
n = be32_to_cpup(p++); READ_BUF(n + 4);
where n is a u32. The only bounds checking is done in READ_BUF itself, but since it's checking (n + 4), it won't catch cases where n is very large, (u32)(-4) or higher. I'm not sure exactly what the consequences are, but we've seen crashes soon after.
Instead, just break these up into two READ_BUF()s.
--- fs/nfsd/nfs4xdr.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
fs/nfsd/nfs4xdr.c +8 -5
@@ -1072,8 +1072,9 @@ nfsd4_decode_rename(struct nfsd4_compounREAD_BUF (4 ); rename->rn_snamelen =be32_to_cpup (p++); -READ_BUF (rename->rn_snamelen +4 ); +READ_BUF (rename->rn_snamelen);SAVEMEM (rename->rn_sname, rename->rn_snamelen); +READ_BUF (4 ); rename->rn_tnamelen =be32_to_cpup (p++);READ_BUF (rename->rn_tnamelen);SAVEMEM (rename->rn_tname, rename->rn_tnamelen);
@@ -1155,13 +1156,14 @@ nfsd4_decode_setclientid(struct nfsd4_coREAD_BUF (8 ); setclientid->se_callback_prog =be32_to_cpup (p++); setclientid->se_callback_netid_len =be32_to_cpup (p++); - -READ_BUF (setclientid->se_callback_netid_len +4 ); +READ_BUF (setclientid->se_callback_netid_len);SAVEMEM (setclientid->se_callback_netid_val, setclientid->se_callback_netid_len); +READ_BUF (4 ); setclientid->se_callback_addr_len =be32_to_cpup (p++); -READ_BUF (setclientid->se_callback_addr_len +4 ); +READ_BUF (setclientid->se_callback_addr_len);SAVEMEM (setclientid->se_callback_addr_val, setclientid->se_callback_addr_len); +READ_BUF (4 ); setclientid->se_callback_ident =be32_to_cpup (p++);DECODE_TAIL ;
@@ -1815,8 +1817,9 @@ nfsd4_decode_compound(struct nfsd4_compoREAD_BUF (4 ); argp->taglen =be32_to_cpup (p++); -READ_BUF (argp->taglen +8 ); +READ_BUF (argp->taglen);SAVEMEM (argp->tag, argp->taglen); +READ_BUF (8 ); argp->minorversion =be32_to_cpup (p++); argp->opcnt =be32_to_cpup (p++); max_reply +=4 + (XDR_QUADLEN (argp->taglen) <<2 );
Greg Kroah-Hartman
maintainerPATCH 190/210 nfsd: fix deadlock secinfo+readdir compound
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <[email protected]>
commit 2f6fc056e899bd0144a08da5cacaecbe8997cd74 upstream.
nfsd_lookup_dentry exits with the parent filehandle locked. fh_put also unlocks if necessary (nfsd filehandle locking is probably too lenient), so it gets unlocked eventually, but if the following op in the compound needs to lock it again, we can deadlock.
A fuzzer ran into this; normal clients don't send a secinfo followed by a readdir in the same compound.
--- fs/nfsd/nfs4proc.c | 1 + 1 file changed, 1 insertion(+)
fs/nfsd/nfs4proc.c +1 -0
@@ -877,6 +877,7 @@ nfsd4_secinfo(struct svc_rqst *rqstp, st &exp, &dentry);if (err)return err; +fh_unlock (&cstate->current_fh);if (d_really_is_negative (dentry)) {exp_put (exp); err = nfserr_noent;
Greg Kroah-Hartman
maintainerPATCH 191/210 ARM: dts: at91: sama5d3 Xplained: dont disable hsmci regulator
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
commit ae3fc8ea08e405682f1fa959f94b6e4126afbc1b upstream.
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue.
--- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/at91-sama5d3_xplained.dts +1 -0
@@ -303,6 +303,7 @@ regulator-name = "mmc0-card-supply"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; + regulator-always-on; }; gpio_keys {
Greg Kroah-Hartman
maintainerPATCH 192/210 ARM: dts: at91: sama5d4 Xplained: dont disable hsmci regulator
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
commit b02acd4e62602a6ab307da84388a16bf60106c48 upstream.
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue.
--- arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/at91-sama5d4_xplained.dts +1 -0
@@ -268,5 +268,6 @@ regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&vcc_3v3_reg>; + regulator-always-on; }; };
Greg Kroah-Hartman
maintainerPATCH 193/210 ACPI / PM: Runtime resume devices when waking from hibernate
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit fbda4b38fa3995aa0777fe9cbbdcb223c6292083 upstream.
Commit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered suspend-to-RAM.
Briefly, the motivation was to ensure that devices did not remain in a reset-power-on state after resume, potentially preventing deep SoC-wide low-power states from being entered on idle.
Currently we're not doing the same when leaving suspend-to-disk and this asymmetry is a problem if drivers rely on the automatic resume triggered by pm_complete_with_resume_check(). Fix it.
--- drivers/acpi/sleep.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/sleep.c +1 -0
@@ -714,6 +714,7 @@ static int acpi_hibernation_enter(void)static void acpi_hibernation_leave (void ) { +pm_set_resume_via_firmware ();/* * If ACPI is not enabled by the BIOS and the boot kernel, we need to * enable it here.
Greg Kroah-Hartman
maintainerPATCH 194/210 writeback, cgroup: fix premature wb_put() in locked_inode_to_wb_and_lock_list()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 614a4e3773148a31f58dc174bbf578ceb63510c2 upstream.
locked_inode_to_wb_and_lock_list() wb_get()'s the wb associated with the target inode, unlocks inode, locks the wb's list_lock and verifies that the inode is still associated with the wb. To prevent the wb going away between dropping inode lock and acquiring list_lock, the wb is pinned while inode lock is held. The wb reference is put right after acquiring list_lock citing that the wb won't be dereferenced anymore.
This isn't true. If the inode is still associated with the wb, the inode has reference and it's safe to return the wb; however, if inode has been switched, the wb still needs to be unlocked which is a dereference and can lead to use-after-free if it it races with wb destruction.
Fix it by putting the reference after releasing list_lock.
--- fs/fs-writeback.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
fs/fs-writeback.c +5 -3
@@ -281,13 +281,15 @@ locked_inode_to_wb_and_lock_list(structwb_get (wb);spin_unlock (&inode->i_lock);spin_lock (&wb->list_lock); -wb_put (wb);/* not gonna deref it anymore */ /* i_wb may have changed inbetween, can't use inode_to_wb() */ -if (likely (wb == inode->i_wb)) -return wb;/* @inode already has ref */ +if (likely (wb == inode->i_wb)) { +wb_put (wb);/* @inode already has ref */ +return wb; + }spin_unlock (&wb->list_lock); +wb_put (wb);cpu_relax ();spin_lock (&inode->i_lock); }
Greg Kroah-Hartman
maintainerPATCH 195/210 writeback, cgroup: fix use of the wrong bdi_writeback which mismatches the inode
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit aaf2559332ba272671bb870464a99b909b29a3a1 upstream.
When cgroup writeback is in use, there can be multiple wb's (bdi_writeback's) per bdi and an inode may switch among them dynamically. In a couple places, the wrong wb was used leading to performing operations on the wrong list under the wrong lock corrupting the io lists.
* writeback_single_inode() was taking @wb parameter and used it to remove the inode from io lists if it becomes clean after writeback. The callers of this function were always passing in the root wb regardless of the actual wb that the inode was associated with, which could also change while writeback is in progress.
Fix it by dropping the @wb parameter and using inode_to_wb_and_lock_list() to determine and lock the associated wb.
* After writeback_sb_inodes() writes out an inode, it re-locks @wb and inode to remove it from or move it to the right io list. It assumes that the inode is still associated with @wb; however, the inode may have switched to another wb while writeback was in progress.
Fix it by using inode_to_wb_and_lock_list() to determine and lock the associated wb after writeback is complete. As the function requires the original @wb->list_lock locked for the next iteration, in the unlikely case where the inode has changed association, switch the locks.
Kudos to Tahsin for pinpointing these subtle breakages.
--- fs/fs-writeback.c | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-)
fs/fs-writeback.c +19 -10
@@ -1341,10 +1341,10 @@ __writeback_single_inode(struct inode *i* we go e.g. from filesystem. Flusher thread uses __writeback_single_inode() * and does more profound writeback list handling in writeback_sb_inodes(). */ -static int -writeback_single_inode (struct inode *inode,struct bdi_writeback *wb, -struct writeback_control *wbc) +static int writeback_single_inode (struct inode *inode, +struct writeback_control *wbc) { +struct bdi_writeback *wb;int ret =0 ;spin_lock (&inode->i_lock);
@@ -1382,7 +1382,8 @@ writeback_single_inode(struct inode *ino ret =__writeback_single_inode (inode, wbc);wbc_detach_inode (wbc); -spin_lock (&wb->list_lock); + + wb =inode_to_wb_and_lock_list (inode);spin_lock (&inode->i_lock);/* * If inode is clean, remove it from writeback lists. Otherwise don't
@@ -1457,6 +1458,7 @@ static long writeback_sb_inodes(struct swhile (!list_empty (&wb->b_io)) {struct inode *inode =wb_inode (wb->b_io.prev); +struct bdi_writeback *tmp_wb;if (inode->i_sb != sb) {if (work->sb) {
@@ -1547,15 +1549,23 @@ static long writeback_sb_inodes(struct scond_resched (); } - -spin_lock (&wb->list_lock); +/* +* Requeue @inode if still dirty. Be careful as @inode may +* have been switched to another wb in the meantime. +*/ + tmp_wb =inode_to_wb_and_lock_list (inode);spin_lock (&inode->i_lock);if (!(inode->i_state &I_DIRTY_ALL )) wrote++; -requeue_inode (inode, wb, &wbc); +requeue_inode (inode, tmp_wb, &wbc);inode_sync_complete (inode);spin_unlock (&inode->i_lock); +if (unlikely (tmp_wb != wb)) { +spin_unlock (&tmp_wb->list_lock); +spin_lock (&wb->list_lock); + } +/* * bail out to wb_writeback() often enough to check * background threshold and other termination conditions.
@@ -2342,7 +2352,6 @@ EXPORT_SYMBOL(sync_inodes_sb);*/ int write_inode_now (struct inode *inode,int sync) { -struct bdi_writeback *wb = &inode_to_bdi (inode)->wb;struct writeback_control wbc = { .nr_to_write =LONG_MAX , .sync_mode = sync ?WB_SYNC_ALL :WB_SYNC_NONE ,
@@ -2354,7 +2363,7 @@ int write_inode_now(struct inode *inode, wbc.nr_to_write =0 ;might_sleep (); -return writeback_single_inode (inode, wb, &wbc); +return writeback_single_inode (inode, &wbc); }EXPORT_SYMBOL (write_inode_now);
@@ -2371,7 +2380,7 @@ EXPORT_SYMBOL(write_inode_now);*/ int sync_inode (struct inode *inode,struct writeback_control *wbc) { -return writeback_single_inode (inode, &inode_to_bdi (inode)->wb, wbc); +return writeback_single_inode (inode, wbc); }EXPORT_SYMBOL (sync_inode);
Greg Kroah-Hartman
maintainerPATCH 196/210 Input: synaptics - handle spurious release of trackstick buttons, again
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <[email protected]>
commit 82be788c96ed5978d3cb4a00079e26b981a3df3f upstream.
Looks like the fimware 8.2 still has the extra buttons spurious release bug.
--- drivers/input/mouse/synaptics.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/input/mouse/synaptics.c +3 -2
@@ -862,8 +862,9 @@ static void synaptics_report_ext_buttonsif (!SYN_CAP_MULTI_BUTTON_NO (priv->ext_cap))return ; -/* Bug in FW 8.1, buttons are reported only when ExtBit is 1 */ -if (SYN_ID_FULL (priv->identity) ==0x801 && +/* Bug in FW 8.1 & 8.2, buttons are reported only when ExtBit is 1 */ +if ((SYN_ID_FULL (priv->identity) ==0x801 || +SYN_ID_FULL (priv->identity) ==0x802 ) && !((psmouse->packet[0 ] ^ psmouse->packet[3 ]) &0x02 ))return ;
Greg Kroah-Hartman
maintainerPATCH 197/210 Input: ims-pcu - sanity check against missing interfaces
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff upstream.
A malicious device missing interface can make the driver oops. Add sanity checking.
--- drivers/input/misc/ims-pcu.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/input/misc/ims-pcu.c +4 -0
@@ -1663,6 +1663,8 @@ static int ims_pcu_parse_cdc_data(struct pcu->ctrl_intf =usb_ifnum_to_if (pcu->udev, union_desc->bMasterInterface0); +if (!pcu->ctrl_intf) +return -EINVAL ; alt = pcu->ctrl_intf->cur_altsetting; pcu->ep_ctrl = &alt->endpoint[0 ].desc;
@@ -1670,6 +1672,8 @@ static int ims_pcu_parse_cdc_data(struct pcu->data_intf =usb_ifnum_to_if (pcu->udev, union_desc->bSlaveInterface0); +if (!pcu->data_intf) +return -EINVAL ; alt = pcu->data_intf->cur_altsetting;if (alt->desc.bNumEndpoints !=2 ) {
Greg Kroah-Hartman
maintainerPATCH 198/210 Input: ati_remote2 - fix crashes on detecting device with invalid descriptor
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladis Dronov <[email protected]>
commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream.
The ati_remote2 driver expects at least two interfaces with one endpoint each. If given malicious descriptor that specify one interface or no endpoints, it will crash in the probe function. Ensure there is at least two interfaces and one endpoint for each interface before using it.
The full disclosure: http://seclists.org/bugtraq/2016/Mar/90
--- drivers/input/misc/ati_remote2.c | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-)
drivers/input/misc/ati_remote2.c +30 -6
@@ -817,26 +817,49 @@ static int ati_remote2_probe(struct usb_ ar2->udev = udev; +/* Sanity check, first interface must have an endpoint */ +if (alt->desc.bNumEndpoints <1 || !alt->endpoint) { +dev_err (&interface->dev, +"%s(): interface 0 must have an endpoint\n" , __func__); + r = -ENODEV ; + goto fail1; + } ar2->intf[0 ] = interface; ar2->ep[0 ] = &alt->endpoint[0 ].desc; +/* Sanity check, the device must have two interfaces */ ar2->intf[1 ] =usb_ifnum_to_if (udev,1 ); +if ((udev->actconfig->desc.bNumInterfaces <2 ) || !ar2->intf[1 ]) { +dev_err (&interface->dev,"%s(): need 2 interfaces, found %d\n" , + __func__, udev->actconfig->desc.bNumInterfaces); + r = -ENODEV ; + goto fail1; + } + r =usb_driver_claim_interface (&ati_remote2_driver, ar2->intf[1 ], ar2);if (r) goto fail1; + +/* Sanity check, second interface must have an endpoint */ alt = ar2->intf[1 ]->cur_altsetting; +if (alt->desc.bNumEndpoints <1 || !alt->endpoint) { +dev_err (&interface->dev, +"%s(): interface 1 must have an endpoint\n" , __func__); + r = -ENODEV ; + goto fail2; + } ar2->ep[1 ] = &alt->endpoint[0 ].desc; r =ati_remote2_urb_init (ar2);if (r) - goto fail2; + goto fail3; ar2->channel_mask = channel_mask; ar2->mode_mask = mode_mask; r =ati_remote2_setup (ar2, ar2->channel_mask);if (r) - goto fail2; + goto fail3;usb_make_path (udev, ar2->phys,sizeof (ar2->phys));strlcat (ar2->phys,"/input0" ,sizeof (ar2->phys));
@@ -845,11 +868,11 @@ static int ati_remote2_probe(struct usb_ r =sysfs_create_group (&udev->dev.kobj, &ati_remote2_attr_group);if (r) - goto fail2; + goto fail3; r =ati_remote2_input_init (ar2);if (r) - goto fail3; + goto fail4;usb_set_intfdata (interface, ar2);
@@ -857,10 +880,11 @@ static int ati_remote2_probe(struct usb_return 0 ; - fail3: + fail4:sysfs_remove_group (&udev->dev.kobj, &ati_remote2_attr_group); - fail2: + fail3:ati_remote2_urb_cleanup (ar2); + fail2:usb_driver_release_interface (&ati_remote2_driver, ar2->intf[1 ]); fail1:kfree (ar2);
Greg Kroah-Hartman
maintainerPATCH 199/210 ocfs2/dlm: fix race between convert and recovery
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Qi <[email protected]>
commit ac7cf246dfdbec3d8fed296c7bf30e16f5099dac upstream.
There is a race window between dlmconvert_remote and dlm_move_lockres_to_recovery_list, which will cause a lock with OCFS2_LOCK_BUSY in grant list, thus system hangs.
dlmconvert_remote
{
spin_lock(&res->spinlock);
list_move_tail(&lock->list, &res->converting);
lock->convert_pending = 1;
spin_unlock(&res->spinlock);
status = dlm_send_remote_convert_request();
>>>>>> race window, master has queued ast and return DLM_NORMAL,
and then down before sending ast.
this node detects master down and calls
dlm_move_lockres_to_recovery_list, which will revert the
lock to grant list.
Then OCFS2_LOCK_BUSY won't be cleared as new master won't
send ast any more because it thinks already be authorized.
spin_lock(&res->spinlock);
lock->convert_pending = 0;
if (status != DLM_NORMAL)
dlm_revert_pending_convert(res, lock);
spin_unlock(&res->spinlock);
}In this case, check if res->state has DLM_LOCK_RES_RECOVERING bit set (res is still in recovering) or res master changed (new master has finished recovery), reset the status to DLM_RECOVERING, then it will retry convert.
--- fs/ocfs2/dlm/dlmconvert.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/ocfs2/dlm/dlmconvert.c +10 -1
@@ -262,6 +262,7 @@ enum dlm_status dlmconvert_remote(struct struct dlm_lock *lock, int flags, int type) { enum dlm_status status; +u8 old_owner = res->owner;mlog (0 ,"type=%d, convert_type=%d, busy=%d\n" , lock->ml.type, lock->ml.convert_type, res->state &DLM_LOCK_RES_IN_PROGRESS );
@@ -316,11 +317,19 @@ enum dlm_status dlmconvert_remote(structspin_lock (&res->spinlock); res->state &= ~DLM_LOCK_RES_IN_PROGRESS ; lock->convert_pending =0 ; -/* if it failed, move it back to granted queue */ +/* if it failed, move it back to granted queue. +* if master returns DLM_NORMAL and then down before sending ast, +* it may have already been moved to granted queue, reset to +* DLM_RECOVERING and retry convert */ if (status !=DLM_NORMAL ) {if (status !=DLM_NOTQUEUED )dlm_error (status);dlm_revert_pending_convert (res, lock); + }else if ((res->state &DLM_LOCK_RES_RECOVERING ) || + (old_owner != res->owner)) { +mlog (0 ,"res %.*s is in recovering or has been recovered.\n" , + res->lockname.len, res->lockname.name); + status =DLM_RECOVERING ; } bail:spin_unlock (&res->spinlock);
Greg Kroah-Hartman
maintainerPATCH 200/210 ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Qi <[email protected]>
commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream.
When master handles convert request, it queues ast first and then returns status. This may happen that the ast is sent before the request status because the above two messages are sent by two threads. And right after the ast is sent, if master down, it may trigger BUG in dlm_move_lockres_to_recovery_list in the requested node because ast handler moves it to grant list without clear lock->convert_pending. So remove BUG_ON statement and check if the ast is processed in dlmconvert_remote.
--- fs/ocfs2/dlm/dlmconvert.c | 13 +++++++++++++ fs/ocfs2/dlm/dlmrecovery.c | 1 - 2 files changed, 13 insertions(+), 1 deletion(-)
fs/ocfs2/dlm/dlmconvert.c +13 -0
@@ -288,6 +288,19 @@ enum dlm_status dlmconvert_remote(struct status =DLM_DENIED ; goto bail; } + +if (lock->ml.type == type && lock->ml.convert_type ==LKM_IVMODE ) { +mlog (0 ,"last convert request returned DLM_RECOVERING, but " +"owner has already queued and sent ast to me. res %.*s, " +"(cookie=%u:%llu, type=%d, conv=%d)\n" , + res->lockname.len, res->lockname.name, +dlm_get_lock_cookie_node (be64_to_cpu (lock->ml.cookie)), +dlm_get_lock_cookie_seq (be64_to_cpu (lock->ml.cookie)), + lock->ml.type, lock->ml.convert_type); + status =DLM_NORMAL ; + goto bail; + } + res->state |=DLM_LOCK_RES_IN_PROGRESS ;/* move lock to local convert queue */ /* do not alter lock refcount. switching lists. */
fs/ocfs2/dlm/dlmrecovery.c +0 -1
@@ -2064,7 +2064,6 @@ void dlm_move_lockres_to_recovery_list(sdlm_lock_get (lock);if (lock->convert_pending) {/* move converting lock back to granted */ -BUG_ON (i !=DLM_CONVERTING_LIST );mlog (0 ,"node died with convert pending " "on %.*s. move back to granted list.\n" , res->lockname.len, res->lockname.name);
Greg Kroah-Hartman
maintainerPATCH 201/210 mm/page_alloc: prevent merging between isolated and other pageblocks
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlastimil Babka <[email protected]>
commit d9dddbf556674bf125ecd925b24e43a5cf2a568a upstream.
Hanjun Guo has reported that a CMA stress test causes broken accounting of CMA and free pages:
Quoted 11 lines
Before the test, I got:
-bash-4.3# cat/proc/meminfo| grep CmaCmaTotal: 204800 kB CmaFree: 195044 kBAfter running the test:
-bash-4.3# cat/proc/meminfo| grep CmaCmaTotal: 204800 kB CmaFree: 6602584 kB
Quoted 8 lines
So the freed CMA memory is more than total..
Also the the MemFree is more than mem total:
-bash-4.3# cat
/proc/meminfoMemTotal: 16342016 kB MemFree: 22367268 kB MemAvailable: 22370528 kB
Laura Abbott has confirmed the issue and suspected the freepage accounting rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA pageblocks:
Quoted 9 lines
CMA isolates
MAX_ORDERaligned blocks, but, during the process, partialy isolated block exists. IfMAX_ORDERis 11 andpageblock_orderis 9, two pageblocks make upMAX_ORDERaligned block and I can think following scenario because pageblock (un)isolation would be done one by one.(each character means one pageblock. 'C', 'I' means
MIGRATE_CMA,MIGRATE_ISOLATE, respectively.
Quoted 6 lines
CC -> IC -> II (Isolation)
II -> CI -> CC (Un-isolation)If some pages are freed at this intermediate state such as IC or CI, that page could be merged to the other page that is resident on different type of pageblock and it will cause wrong freepage count.
This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but since it doesn't hold the zone->lock between pageblocks, a race window does exist.
It's also likely that unexpected merging can occur between MIGRATE_ISOLATE and non-CMA pageblocks. This should be prevented in __free_one_page() since commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock"). However, we only check the migratetype of the pageblock where buddy merging has been initiated, not the migratetype of the buddy pageblock (or group of pageblocks) which can be MIGRATE_ISOLATE.
Joonsoo has suggested checking for buddy migratetype as part of page_is_buddy(), but that would add extra checks in allocator hotpath and bloat-o-meter has shown significant code bloat (the function is inline).
This patch reduces the bloat at some expense of more complicated code. The buddy-merging while-loop in __free_one_page() is initially bounded to pageblock_border and without any migratetype checks. The checks are placed outside, bumping the max_order if merging is allowed, and returning to the while-loop with a statement which can't be possibly considered harmful.
This fixes the accounting bug and also removes the arguably weird state in the original commit 3c605096d315 where buddies could be left unmerged.
--- mm/page_alloc.c | 46 +++++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 13 deletions(-)
mm/page_alloc.c +33 -13
@@ -662,34 +662,28 @@ static inline void __free_one_page(strucunsigned long combined_idx;unsigned long uninitialized_var (buddy_idx );struct page *buddy; -unsigned int max_order =MAX_ORDER ; +unsigned int max_order; + + max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);VM_BUG_ON (!zone_is_initialized (zone));VM_BUG_ON_PAGE (page->flags &PAGE_FLAGS_CHECK_AT_PREP , page);VM_BUG_ON (migratetype ==-1 ); -if (is_migrate_isolate (migratetype)) { -/* -* We restrict max order of merging to prevent merge -* between freepages on isolate pageblock and normal -* pageblock. Without this, pageblock isolation -* could cause incorrect freepage accounting. -*/ - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1); - }else { +if (likely (!is_migrate_isolate (migratetype)))__mod_zone_freepage_state (zone,1 << order, migratetype); - } - page_idx = pfn & ((1 << max_order) -1 ); + page_idx = pfn & ((1 <<MAX_ORDER ) -1 );VM_BUG_ON_PAGE (page_idx & ((1 << order) -1 ), page);VM_BUG_ON_PAGE (bad_range (zone, page), page); +continue_merging:while (order < max_order -1 ) { buddy_idx =__find_buddy_index (page_idx, order); buddy = page + (buddy_idx - page_idx);if (!page_is_buddy (page, buddy, order)) -break ; + goto done_merging;/* * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page, * merge with it and move up one order.
@@ -706,6 +700,32 @@ static inline void __free_one_page(struc page_idx = combined_idx; order++; } +if (max_order <MAX_ORDER ) { +/* If we are here, it means order is >= pageblock_order. +* We want to prevent merge between freepages on isolate +* pageblock and normal pageblock. Without this, pageblock +* isolation could cause incorrect freepage or CMA accounting. +* +* We don't want to hit this code for the more frequent +* low-order merging. +*/ +if (unlikely (has_isolate_pageblock (zone))) { +int buddy_mt; + + buddy_idx =__find_buddy_index (page_idx, order); + buddy = page + (buddy_idx - page_idx); + buddy_mt =get_pageblock_migratetype (buddy); + +if (migratetype != buddy_mt + && (is_migrate_isolate (migratetype) || +is_migrate_isolate (buddy_mt))) + goto done_merging; + } + max_order++; + goto continue_merging; + } + +done_merging:set_page_order (page, order);/*
Greg Kroah-Hartman
maintainerPATCH 3/5 perf/x86/intel: Fix PEBS warning by only restoring active PMU in pmi
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 48253050e1a4b8b82c775185c1bc066a2a826f14 upstream.
This patch tries to fix a PEBS warning found in my stress test. The following perf command can easily trigger the pebs warning or spurious NMI error on Skylake/Broadwell/Haswell platforms:
sudo perf record -e 'cpu/umask=0x04,event=0xc4/pp,cycles,branches,ref-cycles,cache-misses,cache-references' --call-graph fp -b -c1000 -a
Also the NMI watchdog must be enabled.
For this case, the events number is larger than counter number. So perf has to do multiplexing.
In perf_mux_hrtimer_handler, it does perf_pmu_disable(), schedule out old events, rotate_ctx, schedule in new events and finally perf_pmu_enable().
If the old events include precise event, the MSR_IA32_PEBS_ENABLE should be cleared when perf_pmu_disable(). The MSR_IA32_PEBS_ENABLE should keep 0 until the perf_pmu_enable() is called and the new event is precise event.
However, there is a corner case which could restore PEBS_ENABLE to stale value during the above period. In perf_pmu_disable(), GLOBAL_CTRL will be set to 0 to stop overflow and followed PMI. But there may be pending PMI from an earlier overflow, which cannot be stopped. So even GLOBAL_CTRL is cleared, the kernel still be possible to get PMI. At the end of the PMI handler, __intel_pmu_enable_all() will be called, which will restore the stale values if old events haven't scheduled out.
Once the stale pebs value is set, it's impossible to be corrected if the new events are non-precise. Because the pebs_enabled will be set to 0. x86_pmu.enable_all() will ignore the MSR_IA32_PEBS_ENABLE setting. As a result, the following NMI with stale PEBS_ENABLE trigger pebs warning.
The pending PMI after enabled=0 will become harmless if the NMI handler does not change the state. This patch checks cpuc->enabled in pmi and only restore the state when PMU is active.
Here is the dump:
Call Trace: <NMI> [<ffffffff813c3a2e>] dump_stack+0x63/0x85 [<ffffffff810a46f2>] warn_slowpath_common+0x82/0xc0 [<ffffffff810a483a>] warn_slowpath_null+0x1a/0x20 [<ffffffff8100fe2e>] intel_pmu_drain_pebs_nhm+0x2be/0x320 [<ffffffff8100caa9>] intel_pmu_handle_irq+0x279/0x460 [<ffffffff810639b6>] ? native_write_msr_safe+0x6/0x40 [<ffffffff811f290d>] ? vunmap_page_range+0x20d/0x330 [<ffffffff811f2f11>] ? unmap_kernel_range_noflush+0x11/0x20 [<ffffffff8148379f>] ? ghes_copy_tofrom_phys+0x10f/0x2a0 [<ffffffff814839c8>] ? ghes_read_estatus+0x98/0x170 [<ffffffff81005a7d>] perf_event_nmi_handler+0x2d/0x50 [<ffffffff810310b9>] nmi_handle+0x69/0x120 [<ffffffff810316f6>] default_do_nmi+0xe6/0x100 [<ffffffff810317f2>] do_nmi+0xe2/0x130 [<ffffffff817aea71>] end_repeat_nmi+0x1a/0x1e [<ffffffff810639b6>] ? native_write_msr_safe+0x6/0x40 [<ffffffff810639b6>] ? native_write_msr_safe+0x6/0x40 [<ffffffff810639b6>] ? native_write_msr_safe+0x6/0x40 <<EOE>> <IRQ> [<ffffffff81006df8>] ? x86_perf_event_set_period+0xd8/0x180 [<ffffffff81006eec>] x86_pmu_start+0x4c/0x100 [<ffffffff8100722d>] x86_pmu_enable+0x28d/0x300 [<ffffffff811994d7>] perf_pmu_enable.part.81+0x7/0x10 [<ffffffff8119cb70>] perf_mux_hrtimer_handler+0x200/0x280 [<ffffffff8119c970>] ? __perf_install_in_context+0xc0/0xc0 [<ffffffff8110f92d>] __hrtimer_run_queues+0xfd/0x280 [<ffffffff811100d8>] hrtimer_interrupt+0xa8/0x190 [<ffffffff81199080>] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [<ffffffff81051bd8>] local_apic_timer_interrupt+0x38/0x60 [<ffffffff817af01d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff817ad15c>] apic_timer_interrupt+0x8c/0xa0 <EOI> [<ffffffff81199080>] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [<ffffffff81123de5>] ? smp_call_function_single+0xd5/0x130 [<ffffffff81123ddb>] ? smp_call_function_single+0xcb/0x130 [<ffffffff81199080>] ? __perf_read_group_add.part.61+0x1a0/0x1a0 [<ffffffff8119765a>] event_function_call+0x10a/0x120 [<ffffffff8119c660>] ? ctx_resched+0x90/0x90 [<ffffffff811971e0>] ? cpu_clock_event_read+0x30/0x30 [<ffffffff811976d0>] ? _perf_event_disable+0x60/0x60 [<ffffffff8119772b>] _perf_event_enable+0x5b/0x70 [<ffffffff81197388>] perf_event_for_each_child+0x38/0xa0 [<ffffffff811976d0>] ? _perf_event_disable+0x60/0x60 [<ffffffff811a0ffd>] perf_ioctl+0x12d/0x3c0 [<ffffffff8134d855>] ? selinux_file_ioctl+0x95/0x1e0 [<ffffffff8124a3a1>] do_vfs_ioctl+0xa1/0x5a0 [<ffffffff81036d29>] ? sched_clock+0x9/0x10 [<ffffffff8124a919>] SyS_ioctl+0x79/0x90 [<ffffffff817ac4b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4 ---[ end trace aef202839fe9a71d ]--- Uhhuh. NMI received for unknown reason 2d on CPU 2. Do you have a strange power saving mode enabled?
--- arch/x86/kernel/cpu/perf_event.c | 13 +++++++++++++ arch/x86/kernel/cpu/perf_event_intel.c | 15 +++++++++++++-- arch/x86/kernel/cpu/perf_event_knc.c | 4 +++- 3 files changed, 29 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/perf_event.c +13 -0
@@ -593,6 +593,19 @@ void x86_pmu_disable_all(void) } } +/* +* There may be PMI landing after enabled=0. The PMI hitting could be before or +* after disable_all. +* +* If PMI hits before disable_all, the PMU will be disabled in the NMI handler. +* It will not be re-enabled in the NMI handler again, because enabled=0. After +* handling the NMI, disable_all will be called, which will not change the +* state either. If PMI hits after disable_all, the PMU is already disabled +* before entering NMI handler. The NMI handler will not change the state +* either. +* +* So either situation is harmless. +*/ static void x86_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuc =this_cpu_ptr (&cpu_hw_events);
arch/x86/kernel/cpu/perf_event_intel.c +13 -2
@@ -1458,7 +1458,15 @@ static __initconst const u64 slm_hw_cach };/* -* Use from PMIs where the LBRs are already disabled. +* Used from PMIs where the LBRs are already disabled. +* +* This function could be called consecutively. It is required to remain in +* disabled state if called consecutively. +* +* During consecutive calls, the same disable value will be written to related +* registers, so the PMU state remains unchanged. hw.state in +* intel_bts_disable_local will remain PERF_HES_STOPPED too in consecutive +* calls. */ static void __intel_pmu_disable_all (void ) {
@@ -1895,7 +1903,10 @@ again: goto again; done: -__intel_pmu_enable_all (0 , true); +/* Only restore PMU state when it's active. See x86_pmu_disable(). */ +if (cpuc->enabled) +__intel_pmu_enable_all (0 , true); +/* * Only unmask the NMI after the overflow counters * have been reset. This avoids spurious NMIs on
arch/x86/kernel/cpu/perf_event_knc.c +3 -1
@@ -263,7 +263,9 @@ again: goto again; done: -knc_pmu_enable_all (0 ); +/* Only restore PMU state when it's active. See x86_pmu_disable(). */ +if (cpuc->enabled) +knc_pmu_enable_all (0 );return handled; }
Greg Kroah-Hartman
maintainerPATCH 202/210 mtd: onenand: fix deadlock in onenand_block_markbad
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaro Koskinen <[email protected]>
commit 5e64c29e98bfbba1b527b0a164f9493f3db9e8cb upstream.
Commit 5942ddbc500d ("mtd: introduce mtd_block_markbad interface") incorrectly changed onenand_block_markbad() to call mtd_block_markbad instead of onenand_chip's block_markbad function. As a result the function will now recurse and deadlock. Fix by reverting the change.
--- drivers/mtd/onenand/onenand_base.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mtd/onenand/onenand_base.c +2 -1
@@ -2599,6 +2599,7 @@ static int onenand_default_block_markbad*/ static int onenand_block_markbad (struct mtd_info *mtd,loff_t ofs) { +struct onenand_chip *this = mtd->priv;int ret; ret =onenand_block_isbad (mtd, ofs);
@@ -2610,7 +2611,7 @@ static int onenand_block_markbad(struct }onenand_get_device (mtd,FL_WRITING ); - ret =mtd_block_markbad (mtd, ofs); + ret = this->block_markbad (mtd, ofs);onenand_release_device (mtd);return ret; }
Greg Kroah-Hartman
maintainerPATCH 203/210 intel_idle: prevent SKL-H boot failure when C8+C9+C10 enabled
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <[email protected]>
commit d70e28f57e14a481977436695b0c9ba165472431 upstream.
Some SKL-H configurations require "intel_idle.max_cstate=7" to boot. While that is an effective workaround, it disables C10.
This patch detects the problematic configuration,
and disables C8 and C9, keeping C10 enabled.
Note that enabling SGX in BIOS SETUP can also prevent this issue, if the system BIOS provides that option.
https://bugzilla.kernel.org/show_bug.cgi?id=109081
"Freezes with Intel i7 6700HQ (Skylake), unless intel_idle.max_cstate=7"
--- drivers/idle/intel_idle.c | 106 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 85 insertions(+), 21 deletions(-)
drivers/idle/intel_idle.c +85 -21
@@ -65,7 +65,7 @@#include <asm/mwait.h> #include <asm/msr.h> -#define INTEL_IDLE_VERSION "0.4" +#define INTEL_IDLE_VERSION "0.4.1"#define PREFIX "intel_idle: "static struct cpuidle_driver intel_idle_driver = {
@@ -994,36 +994,92 @@ static void intel_idle_cpuidle_devices_u }/* -* intel_idle_state_table_update() -* -* Update the default state_table for this CPU-id +* ivt_idle_state_table_update(void) * -* Currently used to access tuned IVT multi-socket targets +* Tune IVT multi-socket targets * Assumption: num_sockets == (max_package_num + 1) */ -void intel_idle_state_table_update (void ) +static void ivt_idle_state_table_update (void ) {/* IVT uses a different table for 1-2, 3-4, and > 4 sockets */ -if (boot_cpu_data.x86_model ==0x3e ) {/* IVT */ -int cpu, package_num, num_sockets =1 ; +int cpu, package_num, num_sockets =1 ; -for_each_online_cpu (cpu) { - package_num =topology_physical_package_id (cpu); -if (package_num +1 > num_sockets) { - num_sockets = package_num +1 ; - -if (num_sockets >4 ) { - cpuidle_state_table = ivt_cstates_8s; -return ; - } +for_each_online_cpu (cpu) { + package_num =topology_physical_package_id (cpu); +if (package_num +1 > num_sockets) { + num_sockets = package_num +1 ; + +if (num_sockets >4 ) { + cpuidle_state_table = ivt_cstates_8s; +return ; } } + } + +if (num_sockets >2 ) + cpuidle_state_table = ivt_cstates_4s; + +/* else, 1 and 2 socket systems use default ivt_cstates */ +} +/* +* sklh_idle_state_table_update(void) +* +* On SKL-H (model 0x5e) disable C8 and C9 if: +* C10 is enabled and SGX disabled +*/ +static void sklh_idle_state_table_update (void ) +{ +unsigned long long msr; +unsigned int eax, ebx, ecx, edx; + + +/* if PC10 disabled via cmdline intel_idle.max_cstate=7 or shallower */ +if (max_cstate <=7 ) +return ; + +/* if PC10 not present in CPUID.MWAIT.EDX */ +if ((mwait_substates & (0xF <<28 )) ==0 ) +return ; + +rdmsrl (MSR_NHM_SNB_PKG_CST_CFG_CTL , msr); + +/* PC10 is not enabled in PKG C-state limit */ +if ((msr &0xF ) !=8 ) +return ; + + ecx =0 ; +cpuid (7 , &eax, &ebx, &ecx, &edx); + +/* if SGX is present */ +if (ebx & (1 <<2 )) { + +rdmsrl (MSR_IA32_FEATURE_CONTROL , msr); -if (num_sockets >2 ) - cpuidle_state_table = ivt_cstates_4s; -/* else, 1 and 2 socket systems use default ivt_cstates */ +/* if SGX is enabled */ +if (msr & (1 <<18 )) +return ; + } + + skl_cstates[5 ].disabled =1 ;/* C8-SKL */ + skl_cstates[6 ].disabled =1 ;/* C9-SKL */ +} +/* +* intel_idle_state_table_update() +* +* Update the default state_table for this CPU-id +*/ + +static void intel_idle_state_table_update (void ) +{ +switch (boot_cpu_data.x86_model) { + +case 0x3e :/* IVT */ +ivt_idle_state_table_update (); +break ; +case 0x5e :/* SKL-H */ +sklh_idle_state_table_update (); +break ; } -return ; }/*
@@ -1063,6 +1119,14 @@ static int __init intel_idle_cpuidle_driif (num_substates ==0 )continue ; +/* if state marked as disabled, skip it */ +if (cpuidle_state_table[cstate].disabled !=0 ) { +pr_debug (PREFIX "state %s is disabled" , + cpuidle_state_table[cstate].name); +continue ; + } + +if (((mwait_cstate +1 ) >2 ) && !boot_cpu_has (X86_FEATURE_NONSTOP_TSC )) mark_tsc_unstable("TSC halts in idle"
Greg Kroah-Hartman
maintainerPATCH 204/210 PM / sleep: Clear pm_suspend_global_flags upon hibernate
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit 276142730c39c9839465a36a90e5674a8c34e839 upstream.
When suspending to RAM, waking up and later suspending to disk, we gratuitously runtime resume devices after the thaw phase. This does not occur if we always suspend to RAM or always to disk.
pm_complete_with_resume_check(), which gets called from pci_pm_complete() among others, schedules a runtime resume if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during a suspend-to-RAM cycle. It is cleared at the beginning of the suspend-to-RAM cycle but not afterwards and it is not cleared during a suspend-to-disk cycle at all. Fix it.
--- kernel/power/hibernate.c | 1 + 1 file changed, 1 insertion(+)
kernel/power/hibernate.c +1 -0
@@ -339,6 +339,7 @@ int hibernation_snapshot(int platform_mopm_message_t msg;int error; +pm_suspend_clear_flags (); error =platform_begin (platform_mode);if (error) goto Close;
Greg Kroah-Hartman
maintainerPATCH 205/210 scsi_common: do not clobber fixed sense information
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hannes Reinecke <[email protected]>
commit ba08311647892cc7912de74525fd78416caf544a upstream.
For fixed sense the information field is 32 bits, to we need to truncate the information field to avoid clobbering the sense code.
--- drivers/scsi/scsi_common.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/scsi/scsi_common.c +10 -2
@@ -278,8 +278,16 @@ int scsi_set_sense_information(u8 *buf, ucp[3 ] =0 ;put_unaligned_be64 (info, &ucp[4 ]); }else if ((buf[0 ] &0x7f ) ==0x70 ) { - buf[0 ] |=0x80 ; -put_unaligned_be64 (info, &buf[3 ]); +/* +* Only set the 'VALID' bit if we can represent the value +* correctly; otherwise just fill out the lower bytes and +* clear the 'VALID' flag. +*/ +if (info <=0xffffffffUL ) + buf[0 ] |=0x80 ; +else + buf[0 ] &=0x7f ; +put_unaligned_be32 ((u32 )info, &buf[3 ]); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 206/210 sched/cputime: Fix steal time accounting vs. CPU hotplug
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit e9532e69b8d1d1284e8ecf8d2586de34aec61244 upstream.
On CPU hotplug the steal time accounting can keep a stale rq->prev_steal_time value over CPU down and up. So after the CPU comes up again the delta calculation in steal_account_process_tick() wreckages itself due to the unsigned math:
u64 steal = paravirt_steal_clock(smp_processor_id()); steal -= this_rq()->prev_steal_time;
So if steal is smaller than rq->prev_steal_time we end up with an insane large value which then gets added to rq->prev_steal_time, resulting in a permanent wreckage of the accounting. As a consequence the per CPU stats in /proc/stat become stale.
Nice trick to tell the world how idle the system is (100%) while the CPU is 100% busy running tasks. Though we prefer realistic numbers.
None of the accounting values which use a previous value to account for fractions is reset at CPU hotplug time. update_rq_clock_task() has a sanity check for prev_irq_time and prev_steal_time_rq, but that sanity check solely deals with clock warps and limits the /proc/stat visible wreckage. The prev_time values are still wrong.
Solution is simple: Reset rq->prev_*_time when the CPU is plugged in again.
--- kernel/sched/core.c | 1 + kernel/sched/sched.h | 13 +++++++++++++ 2 files changed, 14 insertions(+)
kernel/sched/core.c +1 -0
@@ -5525,6 +5525,7 @@ migration_call(struct notifier_block *nfcase CPU_UP_PREPARE : rq->calc_load_update = calc_load_update; +account_reset_rq (rq);break ;case CPU_ONLINE :
kernel/sched/sched.h +13 -0
@@ -1770,3 +1770,16 @@ static inline u64 irq_time_read(int cpu) }#endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ + +static inline void account_reset_rq (struct rq *rq) +{ +#ifdef CONFIG_IRQ_TIME_ACCOUNTING + rq->prev_irq_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT + rq->prev_steal_time =0 ; +#endif +#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + rq->prev_steal_time_rq =0 ; +#endif +}
Greg Kroah-Hartman
maintainerPATCH 207/210 perf/x86/pebs: Add workaround for broken OVFL status on HSW+
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephane Eranian <[email protected]>
commit 8077eca079a212f26419c57226f28696b7100683 upstream.
This patch fixes an issue with the GLOBAL_OVERFLOW_STATUS bits on Haswell, Broadwell and Skylake processors when using PEBS.
The SDM stipulates that when the PEBS iterrupt threshold is crossed, an interrupt is posted and the kernel is interrupted. The kernel will find GLOBAL_OVF_SATUS bit 62 set indicating there are PEBS records to drain. But the bits corresponding to the actual counters should NOT be set. The kernel follows the SDM and assumes that all PEBS events are processed in the drain_pebs() callback. The kernel then checks for remaining overflows on any other (non-PEBS) events and processes these in the for_each_bit_set(&status) loop.
As it turns out, under certain conditions on HSW and later processors, on PEBS buffer interrupt, bit 62 is set but the counter bits may be set as well. In that case, the kernel drains PEBS and generates SAMPLES with the EXACT tag, then it processes the counter bits, and generates normal (non-EXACT) SAMPLES.
I ran into this problem by trying to understand why on HSW sampling on a PEBS event was sometimes returning SAMPLES without the EXACT tag. This should not happen on user level code because HSW has the eventing_ip which always point to the instruction that caused the event.
The workaround in this patch simply ensures that the bits for the counters used for PEBS events are cleared after the PEBS buffer has been drained. With this fix 100% of the PEBS samples on my user code report the EXACT tag.
Before:
$ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase
$ perf report -D | fgrep SAMPLES
PERF_RECORD_SAMPLE(IP, 0x2): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y
\--- EXACT tag is missingAfter:
$ perf record -e cpu/event=0xd0,umask=0x81/upp ./multichase
$ perf report -D | fgrep SAMPLES
PERF_RECORD_SAMPLE(IP, 0x4002): 11775/11775: 0x406de5 period: 73469 addr: 0 exact=Y
\--- EXACT tag is setThe problem tends to appear more often when multiple PEBS events are used.
--- arch/x86/kernel/cpu/perf_event_intel.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/x86/kernel/cpu/perf_event_intel.c +10 -0
@@ -1840,6 +1840,16 @@ again:if (__test_and_clear_bit (62 , (unsigned long *)&status)) { handled++; x86_pmu.drain_pebs (regs); +/* +* There are cases where, even though, the PEBS ovfl bit is set +* in GLOBAL_OVF_STATUS, the PEBS events may also have their +* overflow bits set for their counters. We must clear them +* here because they have been processed as exact samples in +* the drain_pebs() routine. They must not be processed again +* in the for_each_bit_set() loop for regular samples below. +*/ + status &= ~cpuc->pebs_enabled; + status &= x86_pmu.intel_ctrl |GLOBAL_STATUS_TRACE_TOPAPMI ; }/*
Greg Kroah-Hartman
maintainerPATCH 209/210 perf/x86/intel: Use PAGE_SIZE for PEBS buffer size on Core2
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <[email protected]>
commit 3135a66b768c5ee84c8a98b21d0330dc1c1234b4 upstream.
Using PAGE_SIZE buffers makes the WRMSR to PERF_GLOBAL_CTRL in intel_pmu_enable_all() mysteriously hang on Core2. As a workaround, we don't do this.
The hard lockup is easily triggered by running 'perf test attr' repeatedly. Most of the time it gets stuck on sample session with small periods.
# perf test attr -vv
14: struct perf_event_attr setup :
--- start ---
...
'PERF_TEST_ATTR=/tmp/tmpuEKz3B /usr/bin/perf record -o /tmp/tmpuEKz3B/perf.data -c 123 kill >/dev/null 2>&1' ret 1--- arch/x86/kernel/cpu/perf_event.h | 1 + arch/x86/kernel/cpu/perf_event_intel_ds.c | 13 +++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/perf_event.h +1 -0
@@ -591,6 +591,7 @@ struct x86_pmu { pebs_active :1 , pebs_broken :1;int pebs_record_size; +int pebs_buffer_size;void (*drain_pebs)(struct pt_regs *regs);struct event_constraint *pebs_constraints;void (*pebs_aliases)(struct perf_event *event);
arch/x86/kernel/cpu/perf_event_intel_ds.c +11 -2
@@ -269,7 +269,7 @@ static int alloc_pebs_buffer(int cpu)if (!x86_pmu.pebs)return 0 ; - buffer =kzalloc_node (PEBS_BUFFER_SIZE ,GFP_KERNEL , node); + buffer =kzalloc_node (x86_pmu.pebs_buffer_size,GFP_KERNEL , node);if (unlikely (!buffer))return -ENOMEM ;
@@ -286,7 +286,7 @@ static int alloc_pebs_buffer(int cpu)per_cpu (insn_buffer, cpu) = ibuffer; } - max =PEBS_BUFFER_SIZE / x86_pmu.pebs_record_size; + max = x86_pmu.pebs_buffer_size / x86_pmu.pebs_record_size; ds->pebs_buffer_base = (u64 )(unsigned long )buffer; ds->pebs_index = ds->pebs_buffer_base;
@@ -1296,6 +1296,7 @@ void __init intel_ds_init(void) x86_pmu.bts =boot_cpu_has (X86_FEATURE_BTS ); x86_pmu.pebs =boot_cpu_has (X86_FEATURE_PEBS ); + x86_pmu.pebs_buffer_size =PEBS_BUFFER_SIZE ;if (x86_pmu.pebs) {char pebs_type = x86_pmu.intel_cap.pebs_trap ?'+' :'-' ;int format = x86_pmu.intel_cap.pebs_format;
@@ -1304,6 +1305,14 @@ void __init intel_ds_init(void)case 0 :printk (KERN_CONT "PEBS fmt0%c, " , pebs_type); x86_pmu.pebs_record_size =sizeof (struct pebs_record_core ); +/* +* Using >PAGE_SIZE buffers makes the WRMSR to +* PERF_GLOBAL_CTRL in intel_pmu_enable_all() +* mysteriously hang on Core2. +* +* As a workaround, we don't do this. +*/ + x86_pmu.pebs_buffer_size =PAGE_SIZE ; x86_pmu.drain_pebs = intel_pmu_drain_pebs_core;break ;
Greg Kroah-Hartman
maintainerPATCH 210/210 perf/x86/intel: Fix PEBS data source interpretation on Nehalem/Westmere
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
commit 5e3f4cbd906c178510dccfed1131b007c96255ff upstream.
Jiri reported some time ago that some entries in the PEBS data source table in perf do not agree with the SDM. We investigated and the bits changed for Sandy Bridge, but the SDM was not updated.
perf already implements the bits correctly for Sandy Bridge and later. This patch patches it up for Nehalem and Westmere.
--- arch/x86/kernel/cpu/perf_event.h | 2 ++ arch/x86/kernel/cpu/perf_event_intel.c | 2 ++ arch/x86/kernel/cpu/perf_event_intel_ds.c | 11 ++++++++++- 3 files changed, 14 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/perf_event.h +2 -0
@@ -908,6 +908,8 @@ void intel_pmu_lbr_init_hsw(void);void intel_pmu_lbr_init_skl (void ); +void intel_pmu_pebs_data_source_nhm (void ); +int intel_pmu_setup_lbr_filter (struct perf_event *event);void intel_pt_interrupt (void );
arch/x86/kernel/cpu/perf_event_intel.c +2 -0
@@ -3336,6 +3336,7 @@ __init int intel_pmu_init(void) intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND ] = X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1); +intel_pmu_pebs_data_source_nhm ();x86_add_quirk (intel_nehalem_quirk);pr_cont ("Nehalem events, " );
@@ -3398,6 +3399,7 @@ __init int intel_pmu_init(void) intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND ] = X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1); +intel_pmu_pebs_data_source_nhm ();pr_cont ("Westmere events, " );break ;
arch/x86/kernel/cpu/perf_event_intel_ds.c +10 -1
@@ -51,7 +51,8 @@ union intel_x86_pebs_dse {#define OP_LH (P(OP, LOAD) | P(LVL, HIT))#define SNOOP_NONE_MISS (P(SNOOP, NONE) | P(SNOOP, MISS)) -static const u64 pebs_data_source[] = { +/* Version for Sandy Bridge and later */ +static u64 pebs_data_source[] = {P (OP ,LOAD ) |P (LVL ,MISS ) |P (LVL ,L3 ) |P (SNOOP ,NA ),/* 0x00:ukn L3 */ OP_LH |P (LVL ,L1 ) |P (SNOOP ,NONE ),/* 0x01: L1 local */ OP_LH |P (LVL ,LFB ) |P (SNOOP ,NONE ),/* 0x02: LFB hit */
@@ -70,6 +71,14 @@ static const u64 pebs_data_source[] = { OP_LH | P(LVL, UNC) | P(SNOOP, NONE), /* 0x0f: uncached */ }; +/* Patch up minor differences in the bits */ +void __init intel_pmu_pebs_data_source_nhm (void ) +{ + pebs_data_source[0x05 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HIT ); + pebs_data_source[0x06 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HITM ); + pebs_data_source[0x07 ] =OP_LH |P (LVL ,L3 ) |P (SNOOP ,HITM ); +} +static u64 precise_store_data (u64 status) {union intel_x86_pebs_dse dse;
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control
Quoted 1 line · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
A regression was bisected to this commit:
https://bugzilla.kernel.org/show_bug.cgi?id=115321
So it's probably better to hold off on backporting this commit (and possibly the corresponding amdgpu commit as well).
Signature · 2 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control
Quoted 6 lines · Michel D�nzer
Quoted 1 line · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
A regression was bisected to this commit:
Why not just provide stable with the bugfix as well? Being bug-compatible is a big plus :)
Quoted 2 lines
So it's probably better to hold off on backporting this commit (and possibly the corresponding amdgpu commit as well).
What specific commit are you referring to here?
thanks,
greg k-h
Re: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Michel Dänzer
Quoted 1 line · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
A regression was bisected to this commit:
Why not just provide stable with the bugfix as well?
What bugfix are you referring to? I'm not aware of any fix for this regression.
Quoted 4 lines
Quoted 2 lines
So it's probably better to hold off on backporting this commit (and possibly the corresponding amdgpu commit as well).
What specific commit are you referring to here?
bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1 ("drm/amdgpu: disable runtime pm on PX laptops without dGPU power control")
Signature · 2 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control
In reply to Greg Kroah-HartmanQuoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Michel Dänzer
Quoted 1 line · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
A regression was bisected to this commit:
FYI, the backport to 4.5 triggered another bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=116251
Signature · 2 lines
Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control
Quoted 5 lines · Michel D�nzer
Quoted 4 lines · Greg Kroah-Hartman
Quoted 3 lines · Michel D�nzer
Quoted 1 line · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
A regression was bisected to this commit:
FYI, the backport to 4.5 triggered another bug report:
Is it fixed in Linus's tree yet? If so, great, let me know the git commit id.
thanks,
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.7 release. There are 210 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 12 18:34:54 UTC 2016. Anything received after that time might be too late.
Build results:
total: 146 pass: 146 fail: 0 Qemu test results: total: 99 pass: 99 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.7 release. There are 210 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Apr 12 18:34:54 UTC 2016. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.7-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah