- 20 Jun, 2017 14 commits
-
-
Michael Ellerman authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit a7e0fb6c upstream. Currently the opal_exit tracepoint usually shows the opcode as 0: <idle>-0 [047] d.h. 635.654292: opal_entry: opcode=63 <idle>-0 [047] d.h. 635.654296: opal_exit: opcode=0 retval=0 kopald-1209 [019] d... 636.420943: opal_entry: opcode=10 kopald-1209 [019] d... 636.420959: opal_exit: opcode=0 retval=0 This is because we incorrectly load the opcode into r0 before calling __trace_opal_exit(), whereas it expects the opcode in r3 (first function parameter). In fact we are leaving the retval in r3, so opcode and retval will always show the same value. Instead load the opcode into r3, resulting in: <idle>-0 [040] d.h. 636.618625: opal_entry: opcode=63 <idle>-0 [040] d.h. 636.618627: opal_exit: opcode=63 retval=0 Fixes: c49f6353 ("powernv: Add OPAL tracepoints") Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit 4cca0457 upstream. The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both flags set and an assumed base clock of 100 MHz for turbo values. Reported-by:
GSR <gsr.bugs@infernal-iceberg.com> Tested-by:
GSR <gsr.bugs@infernal-iceberg.com> References: https://bugs.debian.org/859978 Fixes: 8fb2e440 (cpupower: Show Intel turbo ratio support via ...) Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit 5008efc8 upstream. The PJ4 inline asm sequence to write to cp15 cannot be built in Thumb-2 mode, due to the way it performs arithmetic on the program counter, so it is built in ARM mode instead. However, building C files in ARM mode under CONFIG_THUMB2_KERNEL is problematic, since the instrumentation performed by subsystems like ftrace does not expect having to deal with interworking branches. Since the sequence in question is simply a poor man's ISB instruction, let's use a straight 'isb' instead when building in Thumb2 mode. Thumb2 implies V7, so 'isb' should always be supported in that case. Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Cong Wang authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit b5c66bab upstream. posix_acl_update_mode() could possibly clear 'acl', if so we leak the memory pointed by 'acl'. Save this pointer before calling posix_acl_update_mode() and release the memory if 'acl' really gets cleared. Link: http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangcong@gmail.comSigned-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reported-by:
Mark Salyzyn <salyzyn@android.com> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Greg Kurz <groug@kaod.org> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Pali Rohár authored
BugLink: https://bugs.launchpad.net/bugs/1693126 When changing keyboard backlight state on new Dell laptops, firmware expects a new timeout AC value filled in Set New State SMBIOS call. Without it any change of keyboard backlight state on new Dell laptops fails. And user can see following error message in dmesg: dell_laptop: Setting old previous keyboard state failed leds dell::kbd_backlight: Setting an LED's brightness failed (-6) This patch adds support for retrieving current timeout AC values and also updating them. Current timeout value in sysfs is displayed based on current AC status, like current display brightness value. Detection if Dell laptop supports or not new timeout AC settings is done by checking existence of Keyboard Backlight with AC SMBIOS token (0x0451). Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Acked-by:
Mario Limonciello <mario.limonciello@dell.com> Tested-by:
Arcadiy Ivanov <arcadiy@ivanov.biz> [andy: fixed merge conflict with defined constants] Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> (backported from commit 9216e0dc) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Alex Hung authored
BugLink: https://bugs.launchpad.net/bugs/1693126 This is to support Latitude 7480 and many other newer Dell laptops. Signed-off-by:
Alex Hung <alex.hung@canonical.com> Reviewed-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit 8d2c4538) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1690498 Vendor release ver: 1.2.RC9 Changelog: 1.2.RC9 - WLAN Bug Fixes: --------------- 1) BT reset added before going to S3/S4/S5 sleep when WoWLAN is enabled. 2) Station connection check before going to S3/S4/S5 sleep removed. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC8 - WLAN Bug Fixes: --------------- 1) Added power leak fixes for S4. 2) S5 WoLAN issue resolved. 3) Wakeup short pulse issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC7 - WLAN Bug Fixes: --------------- 1) Configured host wakeup pin as active low from driver. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC6 - WLAN Bug Fixes: --------------- 1) AP data throughput issue resolved. 2) Scan results issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC4 - WLAN Bug Fixes: --------------- 1) Buffer status interrupt handling improved. 2) Scan results update in sta+bt dual mode issue resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC3 - WLAN Bug Fixes: --------------- 1) WoWLAN multiple cycles issue resolved. 2) Driver Version is correctly updated. 3) Default operating mode for Caracalla board is corrected. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. BT New Features: ---------------- 1) Multiple slaves issue in WLAN-BT coex mode resolved. BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC2 - WLAN Bug Fixes: --------------- 1) Suspend/resume issues resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.2.RC1 - WLAN New Features: ------------------ 1) Restrict functional modes as per device operating mode 2) Default operating mode for Caracalla board is 13 WLAN Bug Fixes: --------------- 1) Driver oops issue if more than 4 clients try to connect in operating mode 14 resolved. 2) Issue with connecting more than max clients and disconnection issue resolved. 3) L2 test stop when wlan interface down issue resolved. 4) Driver version corrected. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested 4) For channels 12 and 13 in US region max TX power is coming 0 in beacons. BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.1 - Generic ------- 1) Firmware file name is displayed along with version information. at the driver load time. 2) Device operating mode is made available in the below files: /sys/module/rsi_sdio/parameters/dev_oper_mode /sys/module/rsi_usb/parameters/dev_oper_mode 3) Wi-Fi BT radio sharing has been improved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested 4) For channels 12 and 13 in US region max TX power is coming 0 in beacons. BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0.RC7 - Generic ------- 1) Driver version, Firmware version and operating mode information is displayed at the driver load time. 2) Driver version is made available in the below files: /sys/module/rsi_91x/version /sys/module/rsi_sdio/version /sys/module/rsi_usb/version WLAN Bug Fixes: --------------- 1) Power save latencies resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT Limitations/Features NOT Supported: -------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0 - WLAN New Features: ------------------ 1) Station mode 2) All Security modes (WEP/WPA/WPA2) 3) Station Power save (legacy and UAPSD) 4) Bgscan and roaming 5) External antenna selection 6) Neighbour report request in RRM 7) Regulatory (802)11d) support 8) Management frame protection support (802)11w) 9) Software RF-kill 10) AP mode 11) S3, S4 suspend and resume 12) WoWLAN 13) AP Power save 14) Wi-Fi direct WLAN Bug Fixes: --------------- 1) Allowed channels 12 and 13 in FCC region. 2) For the allowed channels 12 and 13 in any region, power configuration updated as per Caracalla regulatory rules. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S5 with WoWLAN does not work. 2) For GTK rekey, wakeup trigger send to host. 3) EAP not tested BT New Features: ---------------- 1) BT EDR mode 2) BT LE mode 3) BT coex mode (All the coex modes)) 4) Multi-slave mode supported) BT Limitations/Features NOT Supported: ---------------------------------------- 1) To connect multiple BT slaves, connection should be initiated from rsi module. 2) In coex mode, BT file transfer fails at times with certain mobiles. 1.0_RC3 - Gerenic: -------- 1) Device operating mode is changed as module parameter. Please check README or TRM on how to configure this while loading the modules. 2) Max number of stations supported in Wi-Fi AP alone mode is 32, and AP + BT coex mode is 4. 3) AP + BT-EDR + BLE support added. WLAN Bug Fixes: --------------- 1) Bgscan probe request issue resolved. 2) WoWLAN before association issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) S4 with and without WoWLAN works with the work-around implemented by Canonical. 2) S5 with WoWLAN does not work. 3) For GTK rekey, wakeup trigger send to host. 4) EAP not tested 5) To connect multiple BT slaves, connection should be initiated from rsi module. 6) In coex mode, BT file transfer fails at times with certain mobiles. BT New Features: ---------------- 1) Multi-slave mode supported. BT Bug Fixes: ------------- 1) Radio sharing of coex modes improved. 1.0.RC2 - WLAN Bug Fixes: --------------- 1) PVB preparation issue in AP mode resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. BT Bug Fixes: ------------- 1) BT dual mode disconnection issue resolved 2) AP BT dual mode issue resolved 1.0_RC1 - WLAN Bug Fixes: --------------- 1) WoWLAN in Co-ex mode issue resolved. 2) AP beacon DTIM count update issue resolved. 3) Firmware assertion (0x5d) in bgscan issue is resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 0.9.8.5_RC6 - WLAN Bug Fixes: --------------- 1) Firmware CRC check fail issue resolved 2) Compilation fails on 4.10.1 kernel issue resolved 3) BG scan issues resolved 4) AP mode regulatory fixes 5) WoWLAN issues resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 0.9.8.5_RC4 - WLAN Bug Fixes: ------------------- 1) AP mode configuration in channels 12 and 13 for EU region issue resolved. 2) Data latencies in AP mode issue resolved. 3) Roaming issues resolved. 4) AP WEP mode issue resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Issue while Resume in S4 with or without WoWLAN. 3) S5 with WoWLAN does not work. 4) For GTK rekey, wakeup trigger send to host. 5) WoWLAN does not work in WEP mode. Others: ------- 1) USB binds only to RS9113, let upstream kernel driver handle other RSI chips 0.9.8.5_RC3 - WLAN Bug Fixes: ------------------- 1) Power save issue in station mode (By default UAPSD is enabled on Caracalla board) fixed. 2) WoWLAN with S3 issue resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with and without WoWLAN) 0.9.8.5_RC2 - WLAN Bug Fixes: ------------------- 1) Power save issue in station mode (By default UAPSD is enabled on Caracalla board) fixed. 2) Firmware assert 0x71 (while doing bgscan) issue fixed. 3) Keep alive functionality in station mode issue fixed. 4) Data traffic stops when connected to multiple stations issue resolved 5) WoWLAN not working issue is resolved WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with and without WoWLAN) 4) Wi-Fi direct testing is in progress 0.9.8.5_RC1 - WLAN Bug Fixes: ------------------- 1) Observed unicast probe requests during bgscan issue fixed 2) Firmware assert 0x71 (while doing bgscan) issue fixed. 3) Crash when doing rmmod while data traffic is going on issue resolved. 4) Beacons stopped after 5 minutes of data traffic issue fixed. 5) Keep alive functionality in station mode issue fixed 6) 11n data rates issue in station mode resolved. WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) EAP not supported 2) Not verified removing SDIO interrupt polling 3) S4/S5 sleep states not supported (with.without WoWLAN) 4) power save is not working consistently 5) WoWLAN is not working consistently 0.9.8.3 - WLAN New Features: ----------------------------------------- 1) AP Mode 2) S3, S4 suspend and resume 3) WoWLAN [Testing in progress] WLAN Bug Fixes: ------------------- 1) First EAPOL drop issue is resolved 2) Firmware Assert while roaming issue is resolved (Provide driver bgsan should be enabled along with supplicant bgscan) 3) Roaming takes longer time issue is resolved 4) Added polling support as a work-around for the SDIO interrupt issue on some platforms WLAN Limitations/Features NOT Supported: ---------------------------------------- 1) Wi-Fi Direct mode not supported 2) EAP not supported 3) SDIO interrupts are not being delivered to the 9113 driver 4) In S4 state 9113 device gets reset but device isn't getting re-enumerated. Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1672819 There are two very race windows that need to be taken into consideration when check_unsafe_exec performs the file system accounting comparing the number of fs->users against the number threads that share the same fs. The first race can occur when a pthread creates a new pthread and the the fs->users count is incremented before the new pthread is associated with the pthread performing the exec. When this occurs, the pthread performing the exec has flags with bit PF_FORKNOEXEC set. The second race can occur when a pthread is terminating and the fs->users count has been decremented by the pthread is still associated with the pthread that is performing the exec. When this occurs, the pthread peforming the exec has flags with bit PF_EXITING set. This fix keeps track of any pthreads that may be in the race window (when PF_FORKNOEXEC or PF_EXITING) are set and if the fs count does not match the expected count we retry the count as we may have hit this small race windows. Tests on an 8 thread server with the reproducer (see below) show that this retry occurs rarely, so the overhead of the retry is very small. Below is a reproducer of the race condition. The bug manifests itself because the current check_unsafe_exec hits this race and indicates it is not a safe exec, and the exec'd suid program fails to setuid. $ cat Makefile ALL=a b all: $(ALL) a: LDFLAGS=-pthread b: b.c $(CC) b.c -o b sudo chown root:root b sudo chmod u+s b test: for I in $$(seq 1000); do echo $I; ./a ; done clean: rm -vf $(ALL) $ cat a.c #include <stdio.h> #include <unistd.h> #include <pthread.h> #include <sys/types.h> void *nothing(void *p) { return NULL; } void *target(void *p) { for (;;) { pthread_t t; if (pthread_create(&t, NULL, nothing, NULL) == 0) pthread_join(t, NULL); } return NULL; } int main(void) { struct timespec tv; int i; for (i = 0; i < 10; i++) { pthread_t t; pthread_create(&t, NULL, target, NULL); } tv.tv_sec = 0; tv.tv_nsec = 100000; nanosleep(&tv, NULL); if (execl("./b", "./b", NULL) < 0) perror("execl"); return 0; } $ cat b.c #include <stdio.h> #include <unistd.h> #include <sys/types.h> int main(void) { const uid_t euid = geteuid(); if (euid != 0) { printf("Failed, got euid %d (expecting 0)\n", euid); return 1; } return 0; } $ make make cc -pthread a.c -o a cc b.c -o b sudo chown root:root b sudo chmod u+s b $ for i in $(seq 1000); do ./a; done Without the fix, one will see 'Failed, got euid 1000 (expecting 0)' messages Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Mike Manning authored
BugLink: http://bugs.launchpad.net/bugs/1682871 The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by:
Mike Manning <mmanning@brocade.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 308453aa) Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1690362 The XR21V1412 ports were using the hardware power-on default of 9600bps after resume from S3/S4. This patch re-initialises the baud rate and fixes the re-connection issues after S3/S4. Changelog: Version 1B, 11/6/2015 Fixed Bug: The conditional logic to support kernel 3.9 was incorrect(line 396 in xr_usb_serial_common.c). Version 1A, 1/9/2015 This driver will work with any USB UART function in these Exar devices: XR21V1410/1412/1414 XR21B1411 XR21B1420/1422/1424 XR22801/802/804 The source code has been tested on various Linux kernels from 3.6.x to 3.17.x. This may also work with newer kernels as well. Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1690310 This patch fixes the sensor platform data initialisation for st_pressure and st_accel device drivers. Without this patch, the driver fails to register the sensors when the user removes and re-loads the driver. 1. Unload the kernel modules for st_pressure $ sudo rmmod st_pressure_i2c $ sudo rmmod st_pressure 2. Re-load the driver $ sudo insmod st_pressure $ sudo insmod st_pressure_i2c Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> (cherry picked from commit 7383d44b git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Janis Danisevskis authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690225 The PR_DUMPABLE flag causes the pid related paths of the proc file system to be owned by ROOT. The implementation of pthread_set/getname_np however needs access to /proc/<pid>/task/<tid>/comm. If PR_DUMPABLE is false this implementation is locked out. This patch installs a special permission function for the file "comm" that grants read and write access to all threads of the same group regardless of the ownership of the inode. For all other threads the function falls back to the generic inode permission check. [akpm@linux-foundation.org: fix spello in comment] Signed-off-by:
Janis Danisevskis <jdanis@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: David Rientjes <rientjes@google.com> Cc: Minfei Huang <mnfhuang@gmail.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Calvin Owens <calvinowens@fb.com> Cc: Jann Horn <jann@thejh.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 1b3044e3) Signed-off-by:
Breno Leitao <breno.leitao@gmail.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Thadeu Lima de Souza Cascardo authored
BugLink: https://bugs.launchpad.net/bugs/1691814 In order to allow derivatives to really override do_tools_common inside hooks.mk, it needs to be unconditionally set to true in 0-common-vars.mk, which is included before hooks.mk. Otherwise, hooks.mk won't be able to override it, and it will be true unless other conditions apply. This has caused derivatives to fail to build after commit 13d6fbbe ("UBUNTU: [Packaging] prevent linux-*-tools-common from being produced from non linux packages"). Fixes: 13d6fbbeSigned-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com>
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
- 08 Jun, 2017 3 commits
-
-
Stefan Bader authored
Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Michal Hocko authored
Oleg has noticed that khugepaged will happilly collapse stack vma (as long as it is not an early stack - see is_vma_temporary_stack) and it might effectively remove the stack gap area as well because a larger part of the stack vma is usually populated. The same applies to the page fault handler. Fix this by checking stack_guard_area when revalidating a VMA in hugepage_vma_revalidate. We do not want to hook/replace is_vma_temporary_stack() check because THP might be still useful for stack, all we need is excluding the gap from collapsing into a THP. Also check the to-be-created THP in do_huge_pmd_anonymous_page to make sure it is completely outside of the gap area because we we could create THP covering the gap area. CVE-2017-1000364 Noticed-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Michal Hocko <mhocko@suse.com> [move khugepaged.c code into huge_memory.c] Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Michal Hocko authored
Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in the userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly. Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent but it should reduce attack space a lot. One could argue that the gap size should be configurable from the userspace but that can be done later on top when somebody finds that the new 1MB is not suitable or even wrong for some special case applications. Implementation wise, get rid of check_stack_guard_page and move all the guard page specific code to expandable_stack_area which always tries to guarantee the gap. do_anonymous_page then just calls expand_stack. Also get rid of stack_guard_page_{start,end} and replace them with stack_guard_area to handle stack population and /proc/<pid>/[s]maps. This should clean up the code which is quite scattered currently and therefore justify the change. TODO: ia64 page fault handling calls expand_upwards explicitly for register store. Do we need a gap there as well? CVE-2017-1000364 Signed-off-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
- 31 May, 2017 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
- 17 May, 2017 4 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1688579Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Andy Whitcroft authored
We incorrectly have been producing linux-aws-tools-common and linux-aws-cloud-tools-common packages with conflicting contents to our own. This is wrong. Make our packages Provides: their linux-aws equivalents to allow us to replace them without change to the existing linux-tools-aws packages. Conflicts:/Replaces: on the existing packages to ensure they are removed before we are updated. BugLink: http://bugs.launchpad.net/bugs/1688579Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Andy Whitcroft authored
We incorrectly have been producing linux-gke-tools-common and linux-gke-cloud-tools-common packages with conflicting contents to our own. This is wrong. Make our packages Provides: their linux-gke equivalents to allow us to replace them without change to the existing linux-tools-gke packages. Conflicts:/Replaces: on the existing packages to ensure they are removed before we are updated. BugLink: http://bugs.launchpad.net/bugs/1688579Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 16 May, 2017 1 commit
-
-
Amey Telawane authored
Strcpy is inherently not safe, and strlcpy() should be used instead. __trace_find_cmdline() uses strcpy() because the comms saved must have a terminating nul character, but it doesn't hurt to add the extra protection of using strlcpy() instead of strcpy(). Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.orgSigned-off-by:
Amey Telawane <ameyt@codeaurora.org> [AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10 https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477] Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> [ Updated change log and removed the "- 1" from len parameter ] Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> (backported from commit e09e2867) CVE-2017-0605 Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 12 May, 2017 4 commits
-
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1580272 This will have to do for v4.4, backporting everything from v4.8.6 is just not feasible. Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Konstantin Khlebnikov authored
BugLink: https://bugs.launchpad.net/bugs/1687512 Hierarchy could be already throttled at this point. Throttled next buddy could trigger a NULL pointer dereference in pick_next_task_fair(). Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Ben Segall <bsegall@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/146608183552.21905.15924473394414832071.stgit@buzzSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry-picked from commit 754bd598) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Konstantin Khlebnikov authored
BugLink: https://bugs.launchpad.net/bugs/1687512 Cgroup created inside throttled group must inherit current throttle_count. Broken throttle_count allows to nominate throttled entries as a next buddy, later this leads to null pointer dereference in pick_next_task_fair(). This patch initialize cfs_rq->throttle_count at first enqueue: laziness allows to skip locking all rq at group creation. Lazy approach also allows to skip full sub-tree scan at throttling hierarchy (not in this patch). Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bsegall@google.com Link: http://lkml.kernel.org/r/146608182119.21870.8439834428248129633.stgit@buzzSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry-pick from commit 094f4691) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Jiri Pirko authored
BugLink: http://bugs.launchpad.net/bugs/1687877 Similar to state notifications. We allow caller to indicate if the notification should happen now or later, depending on if he holds rtnl mutex or not. Introduce bond_slave_link_notify function (similar to bond_slave_state_notify) which is later on called with rtnl mutex and goes over slaves and executes delayed notification. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 5d397061) Signed-off-by:
Talat Batheesh <talatb@mellanox.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 08 May, 2017 13 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1689296Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Adrian Salido authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 4617f564 upstream. When calling a dm ioctl that doesn't process any data (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct dm_ioctl are left initialized. Current code is incorrectly extending the size of data copied back to user, causing the contents of kernel stack to be leaked to user. Fix by only copying contents before data and allow the functions processing the ioctl to override. Signed-off-by:
Adrian Salido <salidoa@google.com> Reviewed-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
J. Bruce Fields authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 13bf9fbf upstream. The NFSv2/v3 code does not systematically check whether we decode past the end of the buffer. This generally appears to be harmless, but there are a few places where we do arithmetic on the pointers involved and don't account for the possibility that a length could be negative. Add checks to catch these. Reported-by:
Tuomas Haanpää <thaan@synopsys.com> Reported-by:
Ari Kauppi <ari@synopsys.com> Reviewed-by:
NeilBrown <neilb@suse.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
J. Bruce Fields authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit db44bac4 upstream. Use a couple shortcuts that will simplify a following bugfix. (Minor backporting required to account for a change from f34b9568 "The NFSv2/NFSv3 server does not handle zero length WRITE requests correctly".) Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Jaegeuk Kim authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 03a8bb0e upstream. As Al pointed, d_revalidate should return RCU lookup before using d_inode. This was originally introduced by: commit 34286d66 ("fs: rcu-walk aware d_revalidate method"). Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Theodore Ts'o authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 3d43bcfe upstream. This avoids potential problems caused by a race where the inode gets renamed out from its parent directory and the parent directory is deleted while ext4_d_revalidate() is running. Fixes: 28b4c263Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Theodore Ts'o authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 28b4c263 upstream. Add a validation check for dentries for encrypted directory to make sure we're not caching stale data after a key has been added or removed. Also check to make sure that status of the encryption key is updated when readdir(2) is executed. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit 9a200d07 upstream. ...otherwise an user can enable encryption for certain files even when the filesystem is unable to support it. Such a case would be a filesystem created by mkfs.ext4's default settings, 1KiB block size. Ext4 supports encyption only when block size is equal to PAGE_SIZE. But this constraint is only checked when the encryption feature flag is set. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1689296 The driver causes two warnings about possibly uninitialized variables: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf': drivers/infiniband/hw/ehca/ehca_mrmw.c:1908:4: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/infiniband/hw/ehca/ehca_mrmw.c:1924:14: note: 'prev_pgaddr' was declared here drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_reg_mr': drivers/infiniband/hw/ehca/ehca_mrmw.c:2430:5: warning: 'hret' may be used uninitialized in this function [-Wmaybe-uninitialized] The first one is definitely a false positive, the second one may or may not be one. In both cases, adding an intialization is the safe and easy workaround. The driver was removed in mainline in commit e581d111 ("staging/rdma: remove deprecated ehca driver"), in linux-4.6. In 4.4, the file is located in drivers/staging/rdma/ehca/ehca_mrmw.c, and the fix still applies. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1689296 We get this build warning on arm64 drivers/infiniband/hw/qib/qib_qp.c:44:0: error: "BITS_PER_PAGE" redefined [-Werror] #define BITS_PER_PAGE (PAGE_SIZE*BITS_PER_BYTE) This is fixed upstream in commit 898fa52b ("IB/qib: Remove qpn, qp tables and related variables from qib"), which does a lot of other things as well. Instead, I just backport the rename of the local BITS_PER_PAGE definition to RVT_BITS_PER_PAGE. The driver first showed up in linux-2.6.35, and the fixup should still apply to that. The upstream fix went into v4.6, so we could apply this workaround to both 3.18 and 4.4. Fixes: f931551b ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Ross Lagerwall authored
BugLink: http://bugs.launchpad.net/bugs/1689296 The backport of d35c99ff ("netlink: do not enter direct reclaim from netlink_dump()") to the 4.4 branch (first in 4.4.32) mistakenly removed direct claim from the initial large allocation _and_ the fallback allocation which means that allocations can spuriously fail. Fix the issue by adding back the direct reclaim flag to the fallback allocation. Fixes: 6d123f1d ("netlink: do not enter direct reclaim from netlink_dump()") Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit e434e041 upstream. The tg3_set_eeprom() function correctly initializes the 'start' variable, but gcc generates a false warning: drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom': drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] I have not come up with a way to restructure the code in a way that avoids the warning without making it less readable, so this adds an initialization for the declaration to shut up that warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1689296 commit fddcca51 upstream. When map_word gets too large, we use a lot of kernel stack, and for MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended 1024 bytes in a number of functions: drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers': drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize': drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=] This can be avoided if all operations on the map word are done indirectly and the stack gets reused between the calls. We can mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other bank width is enabled, we also need to use a non-constant map_bankwidth() to convince the compiler to use less stack. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> [Brian: this patch mostly achieves its goal by forcing MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit mappings; the rest of the change is mostly a wash, though it helps reduce stack size slightly. If we really care about supporting 256-bit mappings though, we should consider rewriting some of this code to avoid keeping and assigning so many 256-bit objects on the stack.] Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-