BMC/Intel-BMC/linux.git, branch dev-4.3

net/ncsi: Fix possible deadlock caught with lockdep

2016-02-29T01:22:41+00:00

Bringing the interfaces down with ifdown -a directly after boot causes a lockdep warning. It appears that a network interrupt would result in an attempt to acquire that lock again. The solution is to soft disable interrupts. ================================= [ INFO: inconsistent lock state ] 4.3.6 #1 Not tainted --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. ip/934 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&ndp->ndp_package_lock)->rlock){+.?...}, at: [] ncsi_stop_dev+0x14/0x50 {IN-SOFTIRQ-W} state was registered at: [] _raw_spin_lock+0x28/0x38 [] ncsi_add_package+0x64/0xf0 [] ncsi_rsp_handler_sp+0x80/0xe0 [] ncsi_rcv_rsp+0xd4/0x104 [] __netif_receive_skb_core+0x6c4/0x808 [] netif_receive_skb_internal+0xb4/0x138 [] napi_gro_receive+0x48/0x9c [] ftgmac100_poll+0x360/0x59c [] net_rx_action+0xe8/0x2a0 [] __do_softirq+0x108/0x26c [] do_softirq+0x48/0x70 [] __local_bh_enable_ip+0xc8/0x104 [] __dev_queue_xmit+0x654/0x6c4 [] ncsi_xmit_cmd+0x1d4/0x208 [] ncsi_dev_start+0xd0/0x3c0 [] ncsi_dev_work+0x1b8/0x1fc [] process_one_work+0x228/0x3cc [] worker_thread+0x2a4/0x3d8 [] kthread+0xc4/0xd8 [] ret_from_fork+0x14/0x28 irq event stamp: 2009 hardirqs last enabled at (2009): [] __local_bh_enable_ip+0xe4/0x104 hardirqs last disabled at (2007): [] __local_bh_enable_ip+0x64/0x104 softirqs last enabled at (2008): [] dev_deactivate_many+0x270/0x2ac softirqs last disabled at (2006): [] dev_deactivate_many+0x254/0x2ac other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&ndp->ndp_package_lock)->rlock); lock(&(&ndp->ndp_package_lock)->rlock); *** DEADLOCK *** 1 lock held by ip/934: #0: (rtnl_mutex){+.+.+.}, at: [] devinet_ioctl+0x15c/0x6c8 stack backtrace: CPU: 0 PID: 934 Comm: ip Not tainted 4.3.6 #1 Hardware name: ASpeed SoC [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (print_usage_bug.part.11+0x220/0x288) [] (print_usage_bug.part.11) from [] (mark_lock+0x400/0x678) [] (mark_lock) from [] (__lock_acquire+0xa0c/0x1a9c) [] (__lock_acquire) from [] (lock_acquire+0x9c/0xbc) [] (lock_acquire) from [] (_raw_spin_lock+0x28/0x38) [] (_raw_spin_lock) from [] (ncsi_stop_dev+0x14/0x50) [] (ncsi_stop_dev) from [] (ftgmac100_stop+0x1c/0x28) [] (ftgmac100_stop) from [] (__dev_close_many+0xa0/0xc8) [] (__dev_close_many) from [] (__dev_close+0x20/0x34) [] (__dev_close) from [] (__dev_change_flags+0x8c/0x138) [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [] (dev_change_flags) from [] (devinet_ioctl+0x32c/0x6c8) [] (devinet_ioctl) from [] (sock_ioctl+0x26c/0x2d0) [] (sock_ioctl) from [] (do_vfs_ioctl+0x588/0x67c) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c) Signed-off-by: Cyril Bur Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed-smc: Use io string accessors to fifo

2016-02-22T05:27:33+00:00

Make and use new routines to access the fifo when in user mode. Instead of using memcpy_fromio, base the new routines on the io port string accessors. When the smc controllers are configured to transfer in user mode, the exact address within the chip select region is ignored and all valid data bytes are sent to the device fifo. It has been determined the reason _memcpy_fromio, an arm specific byte-by-byte variant of memcpy_fromio was required in read_reg, is that the later will stutter when coping from memory, discarding some bytes read, when switching from words to bytes for the final unaligned length. This change includes a hack to make inw/outw work. The default generic IO_SPACE_LIMIT is 0, and twenty bits when PCI is selected. While there is a PCMCIA SOC config to select the full 4GB space it would bring in the PCMCIA core for no use to the ast2400. We want to be part of the generic multi-platform arm kernel and therefore mach/io.h is not going to work. However, the limit is under an ifndef, so define it in this file an check it was not redefine at probe time. To avoid redefinition errors or warnings, guard the setting with CONFIG_ARM for cross-arch compile testing and with a Kconfig dependency for arm cross-compile tests. While some other architecture may not accept unsigned long addresses as ioport cookies, that can be addressed when, if ever, the hardware appears on another arch. While the change to use the designed-for-memory optimised copy template, even reusing the bytes of memcpy, was a recent change and only for little endian arm, designing and proposing a patch will take some time and there could be debate if the routine needs to work on changing memory. Signed-off-by: Milton Miller Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

i2c: aspeed: Don't rename added devices

2016-02-22T05:21:47+00:00

Changing the name of a device with dev_set_name after device_add is not allowed. However, of_create_device takes a bus_id parameter that specifies the name of the platform device being added. This does mean the bus property has to be retrieved multiple times. Creation is skiped if there is trouble retrieving or formatting the name. The documentation for kobject_set_name (non-vargs) says: * This sets the name of the kobject. If you have already added the * kobject to the system, you must call kobject_rename() in order to * change the name of the kobject. As the kernel doc for device_rename says: * Make up a "real" name in the driver before you register anything, or add * some other attributes for userspace to find the device, or use udev to add * symlinks -- but never rename kernel devices later, it's a complete mess. We * don't even want to get into that and try to implement the missing pieces in * the core. We really have other pieces to fix in the driver core mess. :) before: 1e78a000.i2c/1e78a1c0.i2c-bus/i2c-6/i2c-dev/i2c-6 1e78a000.i2c/1e78a180.i2c-bus/i2c-5/i2c-dev/i2c-5 1e78a000.i2c/1e78a140.i2c-bus/i2c-4/i2c-dev/i2c-4 1e78a000.i2c/1e78a100.i2c-bus/i2c-3/i2c-dev/i2c-3 1e78a000.i2c/1e78a100.i2c-bus/i2c-3/3-0050 1e78a000.i2c/1e78a0c0.i2c-bus/i2c-2/i2c-dev/i2c-2 1e78a000.i2c/1e78a0c0.i2c-bus/i2c-2/2-004c/hwmon/hwmon0 1e78a000.i2c/1e78a080.i2c-bus/i2c-1/i2c-dev/i2c-1 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/i2c-dev/i2c-0 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/0-0050 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/0-0068/rtc/rtc0 1e78a000.i2c/1e78a340.i2c-bus/i2c-8/i2c-dev/i2c-8 after: 1e78a000.i2c/i2c-0/i2c-0/i2c-dev/i2c-0 1e78a000.i2c/i2c-0/i2c-0/0-0050 1e78a000.i2c/i2c-0/i2c-0/0-0068/rtc/rtc0 1e78a000.i2c/i2c-1/i2c-1/i2c-dev/i2c-1 1e78a000.i2c/i2c-2/i2c-2/i2c-dev/i2c-2 1e78a000.i2c/i2c-2/i2c-2/2-004c/hwmon/hwmon0 1e78a000.i2c/i2c-3/i2c-3/i2c-dev/i2c-3 1e78a000.i2c/i2c-3/i2c-3/3-0050 1e78a000.i2c/i2c-4/i2c-4/i2c-dev/i2c-4 1e78a000.i2c/i2c-5/i2c-5/i2c-dev/i2c-5 1e78a000.i2c/i2c-6/i2c-6/i2c-dev/i2c-6 1e78a000.i2c/i2c-7/i2c-7/i2c-dev/i2c-7 1e620000.fmc 1e78e000.serial 1e620000.fmc:flash@0 1e78f000.serial 1e630000.spi ahb 1e630000.spi:flash ahb:apb 1e660000.ethernet alarmtimer 1e6c0080.interrupt-controller i2c-0 1e6e2000.syscon i2c-1 1e720000.sram i2c-2 1e780000.gpio i2c-3 1e782000.timer i2c-4 1e783000.serial i2c-5 1e784000.serial i2c-6 1e785000.wdt i2c-7 1e787000.vuart i2c-8 1e789140.ibt leds 1e78a000.i2c serial8250 1e78d000.serial Signed-off-by: Milton Miller Signed-off-by: Joel Stanley

Remove GPIO and LPC from WDT reset list

2016-02-22T05:16:02+00:00

WDT reset mode must also be set to SOC mode. These changes are required so host is not interrupted when BMC is reboot. This change will keep the GPIO and LPC units from being reset during an SOC reset. The SOC reset is used to perform a BMC reboot. Signed-off-by: Norman James Signed-off-by: Joel Stanley

Merge tag 'v4.3.6' into dev-4.3

2016-02-22T05:13:27+00:00

This is the 4.3.6 stable release Signed-off-by: Joel Stanley

Linux 4.3.6

2016-02-19T22:35:24+00:00

HID: multitouch: fix input mode switching on some Elan panels

2016-02-19T22:28:38+00:00

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream. as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

mm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress

2016-02-19T22:28:38+00:00

commit 564e81a57f9788b1475127012e0fd44e9049e342 upstream. Jan Stancek has reported that system occasionally hanging after "oom01" testcase from LTP triggers OOM. Guessing from a result that there is a kworker thread doing memory allocation and the values between "Node 0 Normal free:" and "Node 0 Normal:" differs when hanging, vmstat is not up-to-date for some reason. According to commit 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress"), it meant to force the kworker thread to take a short sleep, but it by error used schedule_timeout(1). We missed that schedule_timeout() in state TASK_RUNNING doesn't do anything. Fix it by using schedule_timeout_uninterruptible(1) which forces the kworker thread to take a short sleep in order to make sure that vmstat is up-to-date. Fixes: 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress") Signed-off-by: Tetsuo Handa Reported-by: Jan Stancek Acked-by: Michal Hocko Cc: Tejun Heo Cc: Cristopher Lameter Cc: Joonsoo Kim Cc: Arkadiusz Miskiewicz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

binfmt_elf: Don't clobber passed executable's file header

2016-02-19T22:28:38+00:00

commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream. Do not clobber the buffer space passed from `search_binary_handler' and originally preloaded by `prepare_binprm' with the executable's file header by overwriting it with its interpreter's file header. Instead keep the buffer space intact and directly use the data structure locally allocated for the interpreter's file header, fixing a bug introduced in 2.1.14 with loadable module support (linux-mips.org commit beb11695 [Import of Linux/MIPS 2.1.14], predating kernel.org repo's history). Adjust the amount of data read from the interpreter's file accordingly. This was not an issue before loadable module support, because back then `load_elf_binary' was executed only once for a given ELF executable, whether the function succeeded or failed. With loadable module support supported and enabled, upon a failure of `load_elf_binary' -- which may for example be caused by architecture code rejecting an executable due to a missing hardware feature requested in the file header -- a module load is attempted and then the function reexecuted by `search_binary_handler'. With the executable's file header replaced with its interpreter's file header the executable can then be erroneously accepted in this subsequent attempt. Signed-off-by: Maciej W. Rozycki Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

fs/pipe.c: return error code rather than 0 in pipe_write()

2016-02-19T22:28:38+00:00

commit 6ae08069939f17422835448acae76bda8d96b16a upstream. pipe_write() would return 0 if it failed to merge the beginning of the data to write with the last, partially filled pipe buffer. It should return an error code instead. Userspace programs could be confused by write() returning 0 when called with a nonzero 'count'. The EFAULT error case was a regression from f0d1bec9d5 ("new helper: copy_page_from_iter()"), while the ops->confirm() error case was a much older bug. Test program: #include #include #include int main(void) { int fd[2]; char data[1] = {0}; assert(0 == pipe(fd)); assert(1 == write(fd[1], data, 1)); /* prior to this patch, write() returned 0 here */ assert(-1 == write(fd[1], NULL, 1)); assert(errno == EFAULT); } Signed-off-by: Eric Biggers Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman