linux/drivers, branch v3.9.3

target: Use FD_MAX_SECTORS/FD_BLOCKSIZE for blockdevs using fileio

2013-05-19T18:38:47Z

commit e3e84cda321703b123f36488f50700f371bc7230 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 Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

drm/radeon: restore nomodeset operation (v2)

2013-05-19T18:38:45Z

commit e9ced8e040ebe40e9953db90acbe7d0b58702ebb 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: Alex Deucher Reviewed-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon: check incoming cliprects pointer

2013-05-19T18:38:45Z

commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream. The "boxes" parameter points into userspace memory. It should be verified like any other operation against user memory. Signed-off-by: Kees Cook Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex

2013-05-19T18:38:44Z

commit 6368087e851e697679af059b4247aca33a69cef3 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 Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

2013-05-19T18:38:44Z

commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea 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 Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Restart transaction even when the IBF flag set

2013-05-19T18:38:43Z

commit 28fe5c825f8e15744d04c7c1b8df197950923ecd 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=48221 Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

target/iblock: Fix WCE=1 + DPOFUA=1 backend WRITE regression

2013-05-19T18:38:43Z

commit d2bdbee0d91a5d3ba2e439ce889e20bfe6fd4f1b 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 d0c8b259f8970d39354c1966853363345d401330 Author: Nicholas Bellinger 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 Tested-by: Chris Boot Reported-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: close target_put_sess_cmd() vs. core_tmr_abort_task() race

2013-05-19T18:38:43Z

commit ccf5ae83a6cf3d9cfe9a7038bfe7cd38ab03d5e1 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 Acked-by: Greg Kroah-Hartman Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iscsi-target: Fix processing of OOO commands

2013-05-19T18:38:43Z

commit 3eccfdb01da58fbd0f789ae6ca61cee3769e26de 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 Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

cpufreq / intel_pstate: fix ffmpeg regression

2013-05-19T18:38:42Z

commit ca182aee389f8026401510f4c63841cb02c820e8 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 Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman