user/sven/linux.git, branch v3.18.128

Linux 3.18.128

2018-12-01T08:48:05Z

drm/ast: Remove existing framebuffers before loading driver

2018-12-01T08:48:05Z

commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream. If vesafb attaches to the AST device, it configures the framebuffer memory for uncached access by default. When ast.ko later tries to attach itself to the device, it wants to use write-combining on the framebuffer memory, but vesefb's existing configuration for uncached access takes precedence. This results in reduced performance. Removing the framebuffer's configuration before loding the AST driver fixes the problem. Other DRM drivers already contain equivalent code. Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963 Signed-off-by: Thomas Zimmermann Cc: Tested-by: Y.C. Chen Reviewed-by: Jean Delvare Tested-by: Jean Delvare Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

af_unix: move unix_mknod() out of bindlock

2018-12-01T08:48:05Z

commit 0fb44559ffd67de8517098b81f675fa0210f13f0 upstream. Dmitry reported a deadlock scenario: unix_bind() path: u->bindlock ==> sb_writer do_splice() path: sb_writer ==> pipe->mutex ==> u->bindlock In the unix_bind() code path, unix_mknod() does not have to be done with u->bindlock held, since it is a pure fs operation, so we can just move unix_mknod() out. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Cc: Rainer Weikusat Cc: Al Viro Signed-off-by: Cong Wang Signed-off-by: David S. Miller Cc: Petr Vorel Signed-off-by: Greg Kroah-Hartman

tty: wipe buffer if not echoing data

2018-12-01T08:48:05Z

commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream. If we are not echoing the data to userspace or the console is in icanon mode, then perhaps it is a "secret" so we should wipe it once we are done with it. This mirrors the logic that the audit code has. Reported-by: aszlig Tested-by: Milan Broz Tested-by: Daniel Zatovic Tested-by: aszlig Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman

tty: wipe buffer.

2018-12-01T08:48:05Z

commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream. After we are done with the tty buffer, zero it out. Reported-by: aszlig Tested-by: Milan Broz Tested-by: Daniel Zatovic Tested-by: aszlig Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: do not queue commands when unloading

2018-12-01T08:48:04Z

commit 04dfaa53a0b6e66b328a5bc549e3af8f8b6eac02 upstream. When the driver is unloading, in qla2x00_remove_one(), there is a single call/point in time to abort ongoing commands, qla2x00_abort_all_cmds(), which is still several steps away from the call to scsi_remove_host(). If more commands continue to arrive and be processed during that interval, when the driver is tearing down and releasing its structures, it might potentially hit an oops due to invalid memory access: Unable to handle kernel paging request for data at address 0x00000138 <...> NIP [d000000004700a40] qla2xxx_queuecommand+0x80/0x3f0 [qla2xxx] LR [d000000004700a10] qla2xxx_queuecommand+0x50/0x3f0 [qla2xxx] So, fail commands in qla2xxx_queuecommand() if the UNLOADING bit is set. Signed-off-by: Mauricio Faria de Oliveira Acked-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

scsi: ufs: fix race between clock gating and devfreq scaling work

2018-12-01T08:48:04Z

commit 30fc33f1ef475480dc5bea4fe1bda84b003b992c upstream. UFS devfreq clock scaling work may require clocks to be ON if it need to execute some UFS commands hence it may request for clock hold before issuing the command. But if UFS clock gating work is already running in parallel, ungate work would end up waiting for the clock gating work to finish and as clock gating work would also wait for the clock scaling work to finish, we would enter in deadlock state. Here is the call trace during this deadlock state: Workqueue: devfreq_wq devfreq_monitor __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work ufshcd_hold ufshcd_send_uic_cmd ufshcd_dme_get_attr ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div ufs_qcom_clk_scale_notify ufshcd_scale_clks ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_gate_work __switch_to __schedule schedule schedule_preempt_disabled __mutex_lock_slowpath mutex_lock devfreq_monitor_suspend devfreq_simple_ondemand_handler devfreq_suspend_device ufshcd_gate_work process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_ungate_work __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work __cancel_work_timer cancel_delayed_work_sync ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork This change fixes this deadlock by doing this in devfreq work (devfreq_wq): Try cancelling clock gating work. If we are able to cancel gating work or it wasn't scheduled, hold the clock reference count until scaling is in progress. If gate work is already running in parallel, let's skip the frequecy scaling at this time and it will be retried once next scaling window expires. Reviewed-by: Sahitya Tummala Signed-off-by: Subhash Jadavani Signed-off-by: Martin K. Petersen Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

scsi: ufshcd: Fix race between clk scaling and ungate work

2018-12-01T08:48:04Z

commit f2a785ac23125fa0774327d39e837e45cf28fe92 upstream. The ungate work turns on the clock before it exits hibern8, if the link was put in hibern8 during clock gating work. There occurs a race condition when clock scaling work calls ufshcd_hold() to make sure low power states cannot be entered, but that returns by checking only whether the clocks are on. This causes the clock scaling work to issue UIC commands when the link is in hibern8 causing failures. Make sure we exit hibern8 state before returning from ufshcd_hold(). Callstacks for race condition: ufshcd_scale_gear ufshcd_devfreq_scale ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork ufshcd_uic_hibern8_exit ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork Signed-off-by: Venkat Gopalakrishnan Signed-off-by: Subhash Jadavani Signed-off-by: Martin K. Petersen Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

scsi: ufs: fix bugs related to null pointer access and array size

2018-12-01T08:48:04Z

commit e3ce73d69aff44421d7899b235fec5ac2c306ff4 upstream. In this change there are a few fixes of possible NULL pointer access and possible access to index that exceeds array boundaries. Signed-off-by: Yaniv Gardi Signed-off-by: Subhash Jadavani Signed-off-by: Martin K. Petersen Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

cw1200: Don't leak memory if krealloc failes

2018-12-01T08:48:04Z

commit 9afdd6128c39f42398041bb2e017d8df0dcebcd1 upstream. The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by buf->begin. If we just create a temporary variable to assign memory to and assign the memory to it we can mitigate the memory leak. Signed-off-by: Johannes Thumshirn Cc: Johannes Berg Signed-off-by: Kalle Valo Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman