- 24 May, 2013 21 commits
-
-
Alexander van Heukelum authored
commit 5522ddb3 upstream. Commit 49cb25e9 x86: 'get rid of pt_regs argument in vm86/vm86old' got rid of the pt_regs stub for sys_vm86old and sys_vm86. The functions were, however, not changed to use the calling convention for syscalls. [AV: killed asmlinkage_protect() - it's done automatically now] Backported-by:
Satoru Takeuchi <satoru.takeuchi@gmail.com> Reported-and-tested-by:
Hans de Bruin <jmdebruin@xmsnet.nl> Signed-off-by:
Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jon Mason authored
commit 8b19d450 upstream. Fix issue with adding multiple ntb client devices to the ntb virtual bus. Previously, multiple devices would be added with the same name, resulting in crashes. To get around this issue, add a unique number to the device when it is added. Signed-off-by:
Jon Mason <jon.mason@intel.com> Signed-off-by:
-
Jon Mason authored
commit 904435cf upstream. The ntb_netdev device is not removed from the global list of devices upon device removal. If the device is re-added, the removal code would find the first instance and try to remove an already removed device. Signed-off-by:
-
Jon Mason authored
commit c336acd3 upstream. The system will appear to lockup for long periods of time due to the NTB driver spending too much time in memcpy. Avoid this by reducing the number of packets that can be serviced on a given interrupt. Signed-off-by:
-
Jon Mason authored
commit c9d534c8 upstream. The ring logic of the NTB receive buffer/transmit memory window requires there to be at least 2 payload sized allotments. For the minimal size case, split the buffer into two and set the transport_mtu to the appropriate size. Signed-off-by:
-
Jon Mason authored
commit 90f9e934 upstream. If the NTB link toggles, the driver could stop receiving due to the tx_index not being set to 0 on the transmitting size on a link-up event. This is due to the driver expecting the incoming data to start at the beginning of the receive buffer and not at a random place. Signed-off-by:
-
Jon Mason authored
commit b77b2637 upstream. Each link-up will allocate a new NTB receive buffer when the NTB properties are negotiated with the remote system. These allocations did not check for existing buffers and thus did not free them. Now, the driver will check for an existing buffer and free it if not of the correct size, before trying to alloc a new one. Signed-off-by:
-
Jon Mason authored
commit 113fc505 upstream. 64bit BAR sizes are permissible with an NTB device. To support them various modifications and clean-ups were required, most significantly using 2 32bit scratch pad registers for each BAR. Also, modify the driver to allow more than 2 Memory Windows. Signed-off-by:
-
Dan Carpenter authored
commit cc0f868d upstream. ->remote_rx_info and ->rx_info are struct ntb_rx_info pointers. If we add sizeof(struct ntb_rx_info) then it goes too far. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
commit ad3e2751 upstream. These tests are off by one. If "mw" is equal to NTB_NUM_MW then we would go beyond the end of the ndev->mw[] array. Signed-off-by:
-
Jon Mason authored
commit 186f27ff upstream. Correct instances of variable dereferencing before checking its value on the functions exported to the client drivers. Also, add sanity checks for all exported functions. Reported-by:
-
Michael S. Tsirkin authored
commit 6407d75a upstream. uapi should use __u32 not u32. Fix a macro in virtio_console.h which uses u32. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Niels Ole Salscheider authored
commit fc986034 upstream. Add ULL prefix to avoid overflow. Signed-off-by:
Niels Ole Salscheider <niels_ole@salscheider-online.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ben Skeggs authored
commit 46b47b8a upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit 5e427ec2 upstream. In commit 78d77df7 ("x86-64, init: Do not set NX bits on non-NX capable hardware") we added the early_pmd_flags that gets the NX bit set when a CPU supports NX. However, the new variable was marked __initdata, because the main _use_ of this is in an __init routine. However, the bit setting happens from secondary_startup_64(), which is called not only at bootup, but on every secondary CPU start. Including resuming from STR and at CPU hotplug time. So the value cannot be __initdata. Reported-bisected-and-tested-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Peter Anvin <hpa@linux.intel.com> Cc: Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mika Westerberg authored
commit 2a2d95e9 upstream. If the I2C bus is put to a low power state by an ACPI method it might pull the SDA line low (as its power is removed). Once the bus is put to full power state again, the SDA line is pulled back to high. This transition looks like a STOP condition from the controller point-of-view which sets STOP detected bit in its status register causing the driver to fail subsequent transfers. Fix this by always clearing all interrupts before we start a transfer. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Josef Ahmad authored
commit e6f34cea upstream. i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive to/from the bus into the TX FIFO. For master-rx transactions, the maximum amount of data that can be received is calculated depending solely on TX and RX FIFO load. This is racy - TX FIFO may contain master-rx data yet to be processed, which will eventually land into the RX FIFO. This data is not taken into account and the function may request more data than the controller is actually capable of storing. This patch ensures the driver takes into account the outstanding master-rx data in TX FIFO to prevent RX FIFO overrun. Signed-off-by:
Josef Ahmad <josef.ahmad@linux.intel.com> Acked-by:
-
Wei Yongjun authored
commit ecacb0b1 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Gabriel de Perthuis authored
commit 03b71c6c upstream. The search ioctl skips items that are too large for a result buffer, but inline items of a certain size occuring before any search result is found would trigger an overflow and stop the search entirely. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641Signed-off-by:
Gabriel de Perthuis <g2p.code+btrfs@gmail.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
-
Sukanto Ghosh authored
commit b4fed079 upstream. The format of the lower 32-bits of the 64-bit operand to 'dc cisw' is unchanged from ARMv7 architecture and the upper bits are RES0. This implies that the 'way' field of the operand of 'dc cisw' occupies the bit-positions [31 .. (32-A)]. Due to the use of 64-bit extended operands to 'clz', the existing implementation of __flush_dcache_all is incorrectly placing the 'way' field in the bit-positions [63 .. (64-A)]. Signed-off-by:
Sukanto Ghosh <sghosh@apm.com> Tested-by:
Anup Patel <anup.patel@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Will Deacon authored
commit 9c413e25 upstream. During boot, we take the debug OS lock before interrupts are enabled. This is required to prevent clearing of PSTATE.D on the interrupt entry path, which could result in spurious debug exceptions before we've got round to resetting things like the hardware breakpoints registers to a sane state. A problem with this approach is that taking the OS lock prevents an external JTAG debugger from debugging the system, which is especially irritating during boot, where JTAG debugging can be most useful. This patch clears mdscr_el1 rather than taking the lock, clearing the MDE and KDE bits and preventing self-hosted hardware debug exceptions from occurring. Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
- 19 May, 2013 19 commits
-
-
Greg Kroah-Hartman authored
-
Andy Grover authored
commit e3e84cda upstream. We can still see the error reported in https://patchwork.kernel.org/patch/2338981/ when using fileio backed by a block device. I'm assuming this will get us past that error (from sbc_parse_cdb), and also assuming it's OK to have our max_sectors be larger than the block's queue max hw sectors? Reported-by:
Eric Harney <eharney@redhat.com> Signed-off-by:
Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Eric W. Biederman authored
commit 780a7654 upstream. audit rule additions containing "-F auid!=4294967295" were failing with EINVAL because of a regression caused by e1760bd5. Apparently some userland audit rule sets want to know if loginuid uid has been set and are using a test for auid != 4294967295 to determine that. In practice that is a horrible way to ask if a value has been set, because it relies on subtle implementation details and will break every time the uid implementation in the kernel changes. So add a clean way to test if the audit loginuid has been set, and silently convert the old idiom to the cleaner and more comprehensible new idiom. RGB notes: In upstream, audit_rule_to_entry has been refactored out. This is patch is already upstream in functionally the same form in commit 780a7654 . The decimal constant was cast to unsigned to quiet GCC 4.6 32-bit architecture warnings. Reported-By:
Steve Grubb <sgrubb@redhat.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Tested-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Eric Paris <eparis@redhat.com> Backported-by:
-
Helge Deller authored
commit 6880b015 upstream. People/distros vary how they prefix the toolchain name for 64bit builds. Rather than enforce one convention over another, add a for loop which does a search for all the general prefixes. For 64bit builds, we now search for (in order): hppa64-unknown-linux-gnu hppa64-linux-gnu hppa64-linux For 32bit builds, we look for: hppa-unknown-linux-gnu hppa-linux-gnu hppa-linux hppa2.0-unknown-linux-gnu hppa2.0-linux-gnu hppa2.0-linux hppa1.1-unknown-linux-gnu hppa1.1-linux-gnu hppa1.1-linux This patch was initiated by Mike Frysinger, with feedback from Jeroen Roovers, John David Anglin and Helge Deller. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Jeroen Roovers <jer@gentoo.org> Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Mike Frysinger authored
commit 93782eba upstream. The ifeq operator does not accept globs, so this little bit of code will never match (unless uname literally prints out "parsic*"). Rewrite to use a pattern matching operator so that NATIVE is set to 1 on parisc. Signed-off-by:
-
John David Anglin authored
commit bbbfde78 upstream. The "b" branch instruction used in the fork_like macro only can handle 17-bit pc-relative offsets. This fails with an out of range offset with some .config files. Rewrite to use the "be" instruction which can branch to any address in a space. Signed-off-by:
-
John David Anglin authored
commit f0a18819 upstream. Currently, race conditions exist in the handling of TLB interruptions in entry.S. In particular, dirty bit updates can be lost if an accessed interruption occurs just after the dirty bit interruption on a different cpu. Lost dirty bit updates result in user pages not being flushed and general system instability. This change adds lock and unlock macros to synchronize all PTE and TLB updates done in entry.S. As a result, userspace stability is significantly improved. Signed-off-by:
-
John David Anglin authored
parisc: only re-enable interrupts if we need to schedule or deliver signals when returning to userspace commit c207a76b upstream. Helge and I have found that we have a kernel stack overflow problem which causes a variety of random failures. Currently, we re-enable interrupts when returning from an external interrupt incase we need to schedule or delivery signals. As a result, a potentially unlimited number of interrupts can occur while we are running on the kernel stack. It is very limited in space (currently, 16k). This change defers enabling interrupts until we have actually decided to schedule or delivery signals. This only occurs when we about to return to userspace. This limits the number of interrupts on the kernel stack to one. In other cases, interrupts remain disabled until the final return from interrupt (rfi). Signed-off-by:
-
Oleg Nesterov authored
commit 264b83c0 upstream. argv_split(empty_or_all_spaces) happily succeeds, it simply returns argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to check sub_info->path != NULL to avoid the crash. This is the minimal fix, todo: - perhaps we should change argv_split() to return NULL or change the callers. - kill or justify ->path[0] check - narrow the scope of helper_lock() Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-By:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Dave Airlie authored
commit e9ced8e0 upstream. When UMS was deprecated it removed support for nomodeset commandline we really want this in distro land so we can debug stuff, everyone should fallback to vesa correctly. v2: oops -1 isn't used anymore, restore original behaviour -1 is default, so we can boot with nomodeset on the command line, then use radeon.modeset=1 to override it for debugging later. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Kees Cook authored
commit fefaedcf upstream. The "boxes" parameter points into userspace memory. It should be verified like any other operation against user memory. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Axel Lin authored
commit 61559af1 upstream. When set dmic_samplephase and dmic_clk_rate bits for dmic_cfg, current code checks pdata->dmic_data_sel which is wrong. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Benjamin LaHaise authored
commit 6368087e upstream. When a 32 bit version of ipmitool is used on a 64 bit kernel, the ipmi_devintf code fails to correctly acquire ipmi_mutex. This results in incomplete data being retrieved in some cases, or other possible failures. Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this. Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Chen Gang authored
commit a5f2b3d6 upstream. When calling memcpy, read_data and write_data need additional 2 bytes. write_data: for checking: "if (size > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)" read_data: for checking: "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)" for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)" Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Lan Tianyu authored
commit 28fe5c82 upstream. The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Nicholas Bellinger authored
commit d2bdbee0 upstream. This patch fixes a regression bug introduced in v3.9-rc1 where if the underlying struct block_device for a IBLOCK backend is configured with WCE=1 + DPOFUA=1 settings, the rw = WRITE assignment no longer occurs in iblock_execute_rw(), and rw = 0 is passed to iblock_submit_bios() in effect causing a READ bio operation to occur. The offending commit is: commit d0c8b259 Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Tue Jan 29 22:10:06 2013 -0800 target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status Note the WCE=1 + DPOFUA=0, WCE=0 + DPOFUA=1, and WCE=0 + DPOFUA=0 cases are not affected by this regression bug. Reported-by:
Chris Boot <bootc@bootc.net> Tested-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Joern Engel authored
commit ccf5ae83 upstream. It is possible for one thread to to take se_sess->sess_cmd_lock in core_tmr_abort_task() before taking a reference count on se_cmd->cmd_kref, while another thread in target_put_sess_cmd() drops se_cmd->cmd_kref before taking se_sess->sess_cmd_lock. This introduces kref_put_spinlock_irqsave() and uses it in target_put_sess_cmd() to close the race window. Signed-off-by:
Joern Engel <joern@logfs.org> Acked-by:
-
Shlomo Pongratz authored
commit 3eccfdb0 upstream. Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn. Handle command serial numbers wrap around by using iscsi_sna_lt and not regular comparisson. The routine iterates until it finds an entry whose serial number is greater than the serial number of the new one, thus the new entry should be inserted before that entry and not after. Signed-off-by:
Shlomo Pongratz <shlomop@mellanox.com> Signed-off-by:
-
Dirk Brandewie authored
commit ca182aee upstream. The ffmpeg benchmark in the phoronix test suite has threads on multiple cores that rely on the progress on of threads on other cores and ping pong back and forth fast enough to make the core appear less busy than it "should" be. If the core has been at minimum p-state for a while bump the pstate up to kick the core to see if it is in this ping pong state. If the core is truly idle the p-state will be reduced at the next sample time. If the core makes more progress it will send more work to the thread bringing both threads out of the ping pong scenario and the p-state will be selected normally. This fixes a performance regression of approximately 30% Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
