commit c252409a688a831385fb71097db7a86ffe595b74
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Mar 3 15:10:04 2016 -0800
Linux 4.4.4
commit 74e579764007b3ef63d791116c7d252e0032cc1e
Author: Luca Coelho <luciano.coelho@intel.com>
Date: Tue Feb 2 15:11:15 2016 +0200
iwlwifi: mvm: don't allow sched scans without matches to be started
commit 5e56276e7555b34550d51459a801ff75eca8b907 upstream.
The firmware can perform a scheduled scan with not matchsets passed,
but it can't send notification that results were found. Since the
userspace then cannot know when we got new results and the firmware
wouldn't trigger a wake in case we are sleeping, it's better not to
allow scans without matchsets.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3beb469074ec66079f3fcbed1c6cf06ca8bbc873
Author: Oren Givon <oren.givon@intel.com>
Date: Thu Dec 17 14:17:00 2015 +0200
iwlwifi: update and fix 7265 series PCI IDs
commit 006bda75d81fd27a583a3b310e9444fea2aa6ef2 upstream.
Update and fix some 7265 PCI IDs entries.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a55831546e7d558e7cb14e1c40c6d403d779c10
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Jan 5 15:25:43 2016 +0200
iwlwifi: pcie: properly configure the debug buffer size for 8000
commit 62d7476d958ce06d7a10b02bdb30006870286fe2 upstream.
8000 device family has a new debug engine that needs to be
configured differently than 7000's.
The debug engine's DMA works in chunks of memory and the
size of the buffer really means the start of the last
chunk. Since one chunk is 256-byte long, we should
configure the device to write to buffer_size - 256.
This fixes a situation were the device would write to
memory it is not allowed to access.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d19573e8499198a75c2f7a0b22053bdd8eb48050
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Sun Dec 20 08:45:40 2015 +0200
iwlwifi: dvm: fix WoWLAN
commit a1cdb1c59c8c203de2731fc6910598ed19c97e41 upstream.
My commit below introduced a mutex in the transport to
prevent concurrent operations. To do so, it added a flag
(is_down) to make sure the transport is in the right state.
This uncoverred an bug that didn't cause any harm until
now: iwldvm calls stop_device and then starts the firmware
without calling start_hw in between. While this flow is
fine from the device configuration point of view (register,
etc...), it is now forbidden by the new is_down flag.
This led to this error to appear:
iwlwifi 0000:05:00.0: Can't start_fw since the HW hasn't been started
and the suspend would fail.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=109591
Reported-by: Bogdan Bogush <bogdan.s.bogush@gmail.com>
Fixes=fa9f3281cbb1 ("iwlwifi: pcie: lock start_hw / start_fw / stop_device")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4a5a335105a557b5a78c1513650d1cf7c9f2edb
Author: Jann Horn <jann@thejh.net>
Date: Wed Jan 20 15:00:01 2016 -0800
security: let security modules use PTRACE_MODE_* with bitmasks
commit 3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 upstream.
It looks like smack and yama weren't aware that the ptrace mode
can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but
only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch,
all modes have flags ORed into them.
Signed-off-by: Jann Horn <jann@thejh.net>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
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>
commit 9315bf18bec590aa0c4be5b54de55da21d31ac96
Author: Matan Barak <matanb@mellanox.com>
Date: Thu Jan 7 11:19:29 2016 +0200
IB/cma: Fix RDMA port validation for iWarp
commit 649367735ee5dedb128d9fac0b86ba7e0fe7ae3b upstream.
cma_validate_port wrongly assumed that Ethernet devices are RoCE
devices and thus their ndev should be matched in the GID table.
This broke the iWarp support. Fixing that matching the ndev only if
we work on a RoCE port.
Cc: <stable@vger.kernel.org> # 4.4.x-
Fixes: abae1b71dd37 ('IB/cma: cma_validate_port should verify the port
and netdevice')
Reported-by: Hariprasad Shenai <hariprasad@chelsio.com>
Tested-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 996c591227d988ed82e76080ebf4ed0f1f33e0f1
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:54 2015 +0000
x86/irq: Plug vector cleanup race
commit 98229aa36caa9c769b13565523de9b813013c703 upstream.
We still can end up with a stale vector due to the following:
CPU0 CPU1 CPU2
lock_vector()
data->move_in_progress=0
sendIPI()
unlock_vector()
set_affinity()
assign_irq_vector()
lock_vector() handle_IPI
move_in_progress = 1 lock_vector()
unlock_vector()
move_in_progress == 1
So we need to serialize the vector assignment against a pending cleanup. The
solution is rather simple now. We not only check for the move_in_progress flag
in assign_irq_vector(), we also check whether there is still a cleanup pending
in the old_domain cpumask. If so, we return -EBUSY to the caller and let him
deal with it. Though we have to be careful in the cpu unplug case. If the
cleanout has not yet completed then the following setaffinity() call would
return -EBUSY. Add code which prevents this.
Full context is here: http://lkml.kernel.org/r/5653B688.4050809@stratus.com
Reported-and-tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160107.207265407@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f45a0edf314c4f7f4be658bf58e0b7bc477723c
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:53 2015 +0000
x86/irq: Call irq_force_move_complete with irq descriptor
commit 90a2282e23f0522e4b3f797ad447c5e91bf7fe32 upstream.
First of all there is no point in looking up the irq descriptor again, but we
also need the descriptor for the final cleanup race fix in the next
patch. Make that change seperate. No functional difference.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160107.125211743@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 950c362bdfb191aa3b149493c0447c89845f3a87
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:52 2015 +0000
x86/irq: Remove outgoing CPU from vector cleanup mask
commit 56d7d2f4bbd00fb198b7907cb3ab657d06115a42 upstream.
We want to synchronize new vector assignments with a pending cleanup. Remove a
dying cpu from a pending cleanup mask.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160107.045961667@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 00bb447126d363fbf401d973548b193828c83fb2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:52 2015 +0000
x86/irq: Remove the cpumask allocation from send_cleanup_vector()
commit 5da0c1217f05d2ccc9a8ed6e6e5c23a8a1d24dd6 upstream.
There is no need to allocate a new cpumask for sending the cleanup vector. The
old_domain mask is now protected by the vector_lock, so we can safely remove
the offline cpus from it and send the IPI with the resulting mask.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.967993932@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c2b56b62c26ec51f64edea8d20b133efeddd2d0c
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:51 2015 +0000
x86/irq: Clear move_in_progress before sending cleanup IPI
commit c1684f5035b60e9f98566493e869496fb5de1d89 upstream.
send_cleanup_vector() fiddles with the old_domain mask unprotected because it
relies on the protection by the move_in_progress flag. But this is fatal, as
the flag is reset after the IPI has been sent. So a cpu which receives the IPI
can still see the flag set and therefor ignores the cleanup request. If no
other cleanup request happens then the vector stays stale on that cpu and in
case of an irq removal the vector still persists. That can lead to use after
free when the next cleanup IPI happens.
Protect the code with vector_lock and clear move_in_progress before sending
the IPI.
This does not plug the race which Joe reported because:
CPU0 CPU1 CPU2
lock_vector()
data->move_in_progress=0
sendIPI()
unlock_vector()
set_affinity()
assign_irq_vector()
lock_vector() handle_IPI
move_in_progress = 1 lock_vector()
unlock_vector()
move_in_progress == 1
The full fix comes with a later patch.
Reported-and-tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.892412198@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 550ac3f791f5cdf26021dfa6011adcb5f38856b6
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:50 2015 +0000
x86/irq: Remove offline cpus from vector cleanup
commit 847667ef10356b824a11c853fc8a8b1b437b6a8d upstream.
No point of keeping offline cpus in the cleanup mask.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.808642683@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c655fd016c2917c5f88c4c694bdcdf9e68f4f661
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:49 2015 +0000
x86/irq: Get rid of code duplication
commit ab25ac02148b600e645f77cfb8b8ea415ed75bb4 upstream.
Reusing an existing vector and assigning a new vector has duplicated
code. Consolidate it.
This is also a preparatory patch for finally plugging the cleanup race.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.721599216@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2636de2fc22c1f5e1b24ba7d9e6f6615ed9569a5
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:49 2015 +0000
x86/irq: Copy vectormask instead of an AND operation
commit 9ac15b7a8af4cf3337a101498c0ed690d23ade75 upstream.
In the case that the new vector mask is a subset of the existing mask there is
no point to do a AND operation of currentmask & newmask. The result is
newmask. So we can simply copy the new mask to the current mask and be done
with it. Preparatory patch for further consolidation.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.640253454@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4af6a215154b213835420c6cd2442c0436abbad5
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:48 2015 +0000
x86/irq: Check vector allocation early
commit 3716fd27a604d61a91cda47083504971486b80f1 upstream.
__assign_irq_vector() uses the vector_cpumask which is assigned by
apic->vector_allocation_domain() without doing basic sanity checks. That can
result in a situation where the final assignement of a newly found vector
fails in apic->cpu_mask_to_apicid_and(). So we have to do rollbacks for no
reason.
apic->cpu_mask_to_apicid_and() only fails if
vector_cpumask & requested_cpumask & cpu_online_mask
is empty.
Check for this condition right away and if the result is empty try immediately
the next possible cpu in the requested mask. So in case of a failure the old
setting is unchanged and we can remove the rollback code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.561877324@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cb987d4822d38f8540b7cd580c33628858d38120
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:47 2015 +0000
x86/irq: Reorganize the search in assign_irq_vector
commit 95ffeb4b5baca266e1d0d2bc90f1513e6f419cdd upstream.
Split out the code which advances the target cpu for the search so we can
reuse it for the next patch which adds an early validation check for the
vectormask which we get from the apic.
Add comments while at it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.484562040@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6e9ce2b061408d16ba052e6d7612b4660dbc1c8
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:46 2015 +0000
x86/irq: Reorganize the return path in assign_irq_vector
commit 433cbd57d190a1cdd02f243df41c3d7f55ec4b94 upstream.
Use an explicit goto for the cases where we have success in the search/update
and return -ENOSPC if the search loop ends due to no space.
Preparatory patch for fixes. No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.403491024@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cf2e82af2d53bf7894911a9a11fa2fdf0d17ab91
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Thu Dec 31 16:30:46 2015 +0000
x86/irq: Do not use apic_chip_data.old_domain as temporary buffer
commit 8a580f70f6936ec095da217018cdeeb5835c0207 upstream.
Function __assign_irq_vector() makes use of apic_chip_data.old_domain as a
temporary buffer, which is in the way of using apic_chip_data.old_domain for
synchronizing the vector cleanup with the vector assignement code.
Use a proper temporary cpumask for this.
[ tglx: Renamed the mask to searched_cpumask for clarity ]
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/1450880014-11741-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 053c8ecc225a14ff2522f8d493ebc94c1ca7dc48
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Dec 31 16:30:45 2015 +0000
x86/irq: Validate that irq descriptor is still active
commit 36f34c8c63da3e272fd66f91089228c22d2b6e8b upstream.
In fixup_irqs() we unconditionally dereference the irq chip of an irq
descriptor. The descriptor might still be valid, but already cleaned up,
i.e. the chip removed. Add a check for this condition.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20151231160106.236423282@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4d1544b1e35ae7d3c6a5b5ed2af1328fce2c9ec
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Thu Dec 31 16:30:44 2015 +0000
x86/irq: Fix a race in x86_vector_free_irqs()
commit 111abeba67e0dbdc26537429de9155e4f1d807d8 upstream.
There's a race condition between
x86_vector_free_irqs()
{
free_apic_chip_data(irq_data->chip_data);
xxxxx //irq_data->chip_data has been freed, but the pointer
//hasn't been reset yet
irq_domain_reset_irq_data(irq_data);
}
and
smp_irq_move_cleanup_interrupt()
{
raw_spin_lock(&vector_lock);
data = apic_chip_data(irq_desc_get_irq_data(desc));
access data->xxxx // may access freed memory
raw_spin_unlock(&desc->lock);
}
which may cause smp_irq_move_cleanup_interrupt() to access freed memory.
Call irq_domain_reset_irq_data(), which clears the pointer with vector lock
held.
[ tglx: Free memory outside of lock held region. ]
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/1450880014-11741-3-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7df19ad4a9f2e4845dce66b6049bbc7a796a7895
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Jan 14 08:43:38 2016 +0100
x86/irq: Call chip->irq_set_affinity in proper context
commit e23b257c293ce4bcc8cabb2aa3097b6ed8a8261a upstream.
setup_ioapic_dest() calls irqchip->irq_set_affinity() completely
unprotected. That's wrong in several aspects:
- it opens a race window where irq_set_affinity() can be interrupted and the
irq chip left in unconsistent state.
- it triggers a lockdep splat when we fix the vector race for 4.3+ because
vector lock is taken with interrupts enabled.
The proper calling convention is irq descriptor lock held and interrupts
disabled.
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jeremiah Mahler <jmmahler@gmail.com>
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Joe Lawrence <joe.lawrence@stratus.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1601140919420.3575@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eeb241d4f8a1d0c343e0a19c99490e66b7eff346
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed Feb 24 12:18:49 2016 -0800
x86/entry/compat: Add missing CLAC to entry_INT80_32
commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa upstream.
This doesn't seem to fix a regression -- I don't think the CLAC was
ever there.
I double-checked in a debugger: entries through the int80 gate do
not automatically clear AC.
Stable maintainers: I can provide a backport to 4.3 and earlier if
needed. This needs to be backported all the way to 3.10.
Reported-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access")
Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04100683e8f2792d9c715d5a253a260cb30fa3e3
Author: Colin Ian King <colin.king@canonical.com>
Date: Fri Feb 26 18:55:31 2016 +0000
x86/mpx: Fix off-by-one comparison with nr_registers
commit 9bf148cb0812595bfdf5100bd2c07e9bec9c6ef5 upstream.
In the unlikely event that regno == nr_registers then we get an array
overrun on regoff because the invalid register check is currently
off-by-one. Fix this with a check that regno is >= nr_registers instead.
Detected with static analysis using CoverityScan.
Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04d946904c63586c577139964e77601097acbbbd
Author: Mikulas Patocka <mikulas@twibright.com>
Date: Thu Feb 25 18:17:38 2016 +0100
hpfs: don't truncate the file when delete fails
commit b6853f78e763d42c7a158d8de3549c9827c604ab upstream.
The delete opration can allocate additional space on the HPFS filesystem
due to btree split. The HPFS driver checks in advance if there is
available space, so that it won't corrupt the btree if we run out of space
during splitting.
If there is not enough available space, the HPFS driver attempted to
truncate the file, but this results in a deadlock since the commit
7dd29d8d865efdb00c0542a5d2c87af8c52ea6c7 ("HPFS: Introduce a global mutex
and lock it on every callback from VFS").
This patch removes the code that tries to truncate the file and -ENOSPC is
returned instead. If the user hits -ENOSPC on delete, he should try to
delete other files (that are stored in a leaf btree node), so that the
delete operation will make some space for deleting the file stored in
non-leaf btree node.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d57c0477f842af4fdcfa93454bc2ad94d73b7158
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Feb 27 19:37:37 2016 -0500
do_last(): ELOOP failure exit should be done after leaving RCU mode
commit 5129fa482b16615fd4464d2f5d23acb1b7056c66 upstream.
... or we risk seeing a bogus value of d_is_symlink() there.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f4b352f004c696439c5b5d75a4edc3d0823e770
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Feb 27 19:31:01 2016 -0500
should_follow_link(): validate ->d_seq after having decided to follow
commit a7f775428b8f5808815c0e3004020cedb94cbe3b upstream.
... otherwise d_is_symlink() above might have nothing to do with
the inode value we've got.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9108b130f74d13a37e67a96cc0a8642464578a0a
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Feb 11 16:10:26 2016 -0500
xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.
commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e upstream.
Occasionaly PV guests would crash with:
pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
BUG: unable to handle kernel paging request at 0000000d1a8c0be0
.. snip..
<ffffffff8139ce1b>] find_next_bit+0xb/0x10
[<ffffffff81387f22>] cpumask_next_and+0x22/0x40
[<ffffffff813c1ef8>] pci_device_probe+0xb8/0x120
[<ffffffff81529097>] ? driver_sysfs_add+0x77/0xa0
[<ffffffff815293e4>] driver_probe_device+0x1a4/0x2d0
[<ffffffff813c1ddd>] ? pci_match_device+0xdd/0x110
[<ffffffff81529657>] __device_attach_driver+0xa7/0xb0
[<ffffffff815295b0>] ? __driver_attach+0xa0/0xa0
[<ffffffff81527622>] bus_for_each_drv+0x62/0x90
[<ffffffff8152978d>] __device_attach+0xbd/0x110
[<ffffffff815297fb>] device_attach+0xb/0x10
[<ffffffff813b75ac>] pci_bus_add_device+0x3c/0x70
[<ffffffff813b7618>] pci_bus_add_devices+0x38/0x80
[<ffffffff813dc34e>] pcifront_scan_root+0x13e/0x1a0
[<ffffffff817a0692>] pcifront_backend_changed+0x262/0x60b
[<ffffffff814644c6>] ? xenbus_gather+0xd6/0x160
[<ffffffff8120900f>] ? put_object+0x2f/0x50
[<ffffffff81465c1d>] xenbus_otherend_changed+0x9d/0xa0
[<ffffffff814678ee>] backend_changed+0xe/0x10
[<ffffffff81463a28>] xenwatch_thread+0xc8/0x190
[<ffffffff810f22f0>] ? woken_wake_function+0x10/0x10
which was the result of two things:
When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
pointer which was an 'pcifront_sd' structure. However in the
pci_device_add it expects that the 'sd' is 'struct sysdata' and
sets the dev->node to what is in sd->node (offset 4):
set_dev_node(&dev->dev, pcibus_to_node(bus));
__pcibus_to_node(const struct pci_bus *bus)
{
const struct pci_sysdata *sd = bus->sysdata;
return sd->node;
}
However our structure was pcifront_sd which had nothing at that
offset:
struct pcifront_sd {
int domain; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct pcifront_device * pdev; /* 8 8 */
}
That is an hole - filled with garbage as we used kmalloc instead of
kzalloc (the second problem).
This patch fixes the issue by:
1) Use kzalloc to initialize to a well known state.
2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
way access to the 'node' will access the right offset.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4cf5aa2ffe17403385d75a5b1d9d97071500ea18
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Feb 11 16:10:24 2016 -0500
xen/pciback: Save the number of MSI-X entries to be copied later.
commit d159457b84395927b5a52adb72f748dd089ad5e5 upstream.
Commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 (xen/pciback: Save
xen_pci_op commands before processing it) broke enabling MSI-X because
it would never copy the resulting vectors into the response. The
number of vectors requested was being overwritten by the return value
(typically zero for success).
Save the number of vectors before processing the op, so the correct
number of vectors are copied afterwards.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d52a24819677bbb45eb1ce93a42daa1ae6c4d61d
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu Feb 11 16:10:23 2016 -0500
xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY
commit 8d47065f7d1980dde52abb874b301054f3013602 upstream.
Commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't
allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
MSI-X on passed-through virtual functions, because it checked the VF
for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.
Instead, check the physical function for PCI_COMMAND_MEMORY.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e32b123feea78479f8a60a9abf1a645f9c3ee728
Author: Juergen Gross <jgross@suse.com>
Date: Mon Feb 8 15:30:18 2016 +0100
xen/scsiback: correct frontend counting
commit f285aa8db7cc4432c1a03f8b55ff34fe96317c11 upstream.
When adding a new frontend to xen-scsiback don't decrement the number
of active frontends in case of no error. Doing so results in a failure
when trying to remove the xen-pvscsi nexus even if no domain is using
it.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 392abe33d5e5d3d9b822149558eb3da5debc9cd2
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Mon Feb 8 16:02:06 2016 +0000
xen/arm: correctly handle DMA mapping of compound pages
commit 52ba0746b3b44c86aee121babf3b2fd9b8f84090 upstream.
Currently xen_dma_map_page concludes that DMA to anything other than
the head page of a compound page must be foreign, since the PFN of the
page is that of the head.
Fix the check to instead consider the whole of a compound page to be
local if the PFN of the head passes the 1:1 check.
We can never see a compound page which is a mixture of foreign and
local sub-pages.
The comment already correctly described the intention, but fixup the
spelling and some grammar.
This fixes the various SSH protocol errors which we have been seeing
on the cubietrucks in our automated test infrastructure.
This has been broken since commit 3567258d281b ("xen/arm: use
hypercall to flush caches in map_page"), which was in v3.19-rc1.
NB arch/arm64/.../xen/page-coherent.h also includes this file.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 362deccacfef46e1c78acc79ba9721829605a883
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date: Fri Feb 19 20:21:17 2016 +0100
ARM: at91/dt: fix typo in sama5d2 pinmux descriptions
commit 5e45a2589d24573c564630990c88ac93659f8fe4 upstream.
PIN_PA15 macro has the same value as PIN_PA14 so we were overriding PA14
mux/configuration.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Reported-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8b78924f123e7cbb08d9dd25cb793c2a2e58741d
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Date: Fri Feb 5 16:37:08 2016 +0200
ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption
commit 3f315c5b850fa7aff73f50de8e316b98f611a32b upstream.
Commit e7b11dc7b77b ("ARM: OMAP2+: Fix onenand rate detection to avoid
filesystem corruption") partially fixed onenand configuration when GPMC
module is reset. Finish the job by also providing the correct values in
ONENAND_REG_SYS_CFG1 register.
Fixes: e7b11dc7b77b ("ARM: OMAP2+: Fix onenand rate detection to avoid
filesystem corruption")
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 80d18c0026eb6fc9cd9fb5a36540bfaa8a00fb47
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Feb 27 19:17:33 2016 -0500
do_last(): don't let a bogus return value from ->open() et.al. to confuse us
commit c80567c82ae4814a41287618e315a60ecf513be6 upstream.
... into returning a positive to path_openat(), which would interpret that
as "symlink had been encountered" and proceed to corrupt memory, etc.
It can only happen due to a bug in some ->open() instance or in some LSM
hook, etc., so we report any such event *and* make sure it doesn't trick
us into further unpleasantness.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f634ac98bd9218feb31868b43f56e7a5999ce98e
Author: Simon Guinot <simon.guinot@sequanux.org>
Date: Thu Sep 10 00:15:18 2015 +0200
kernel/resource.c: fix muxed resource handling in __request_region()
commit 59ceeaaf355fa0fb16558ef7c24413c804932ada upstream.
In __request_region, if a conflict with a BUSY and MUXED resource is
detected, then the caller goes to sleep and waits for the resource to be
released. A pointer on the conflicting resource is kept. At wake-up
this pointer is used as a parent to retry to request the region.
A first problem is that this pointer might well be invalid (if for
example the conflicting resource have already been freed). Another
problem is that the next call to __request_region() fails to detect a
remaining conflict. The previously conflicting resource is passed as a
parameter and __request_region() will look for a conflict among the
children of this resource and not at the resource itself. It is likely
to succeed anyway, even if there is still a conflict.
Instead, the parent of the conflicting resource should be passed to
__request_region().
As a fix, this patch doesn't update the parent resource pointer in the
case we have to wait for a muxed region right after.
Reported-and-tested-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Tested-by: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc16b4393fc6226af463fd8c1d92411e5c349cf0
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: Thu Feb 18 18:55:54 2016 +0000
sunrpc/cache: fix off-by-one in qword_get()
commit b7052cd7bcf3c1478796e93e3dff2b44c9e82943 upstream.
The qword_get() function NUL-terminates its output buffer. If the input
string is in hex format \xXXXX... and the same length as the output
buffer, there is an off-by-one:
int qword_get(char **bpp, char *dest, int bufsize)
{
...
while (len < bufsize) {
...
*dest++ = (h << 4) | l;
len++;
}
...
*dest = '\0';
return len;
}
This patch ensures the NUL terminator doesn't fall outside the output
buffer.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 36b53e8b2abf1f514e83e2c3207e36e71c8176de
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date: Wed Feb 24 09:04:24 2016 -0500
tracing: Fix showing function event in available_events
commit d045437a169f899dfb0f6f7ede24cc042543ced9 upstream.
The ftrace:function event is only displayed for parsing the function tracer
data. It is not used to enable function tracing, and does not include an
"enable" file in its event directory.
Originally, this event was kept separate from other events because it did
not have a ->reg parameter. But perf added a "reg" parameter for its use
which caused issues, because it made the event available to functions where
it was not compatible for.
Commit 9b63776fa3ca9 "tracing: Do not enable function event with enable"
added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event
from being enabled by normal trace events. But this commit missed keeping
the function event from being displayed by the "available_events" directory,
which is used to show what events can be enabled by set_event.
One documented way to enable all events is to:
cat available_events > set_event
But because the function event is displayed in the available_events, this
now causes an INVALID error:
cat: write error: Invalid argument
Reported-by: Chunyu Hu <chuhu@redhat.com>
Fixes: 9b63776fa3ca9 "tracing: Do not enable function event with enable"
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 222473f70b2c913445c3173ddcf7bbc5375b93b7
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date: Fri Feb 12 16:03:05 2016 +1100
powerpc/eeh: Fix partial hotplug criterion
commit f6bf0fa14cf848ae770e0b7842c9b11ce2f01645 upstream.
During error recovery, the device could be removed as part of the
partial hotplug. The criterion used to come with partial hotplug
is: if the device driver provides error_detected(), slot_reset()
and resume() callbacks, it's immune from hotplug. Otherwise,
it's going to experience partial hotplug during EEH recovery. But
the criterion isn't correct enough: mlx4_core driver for Mellanox
adapters provides error_detected(), slot_reset() callbacks, but
resume() isn't there. Those Mellanox adapters won't be to involved
in the partial hotplug.
This fixes the criterion to a practical one: adpater with driver
that provides error_detected(), slot_reset() will be immune from
partial hotplug. resume() isn't mandatory.
Fixes: f2da4ccf ("powerpc/eeh: More relaxed hotplug criterion")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4aa584e4200f63450b513900ef5a61a8bc04e245
Author: Mike Krinkin <krinkin.m.u@gmail.com>
Date: Wed Feb 24 21:02:31 2016 +0300
KVM: x86: MMU: fix ubsan index-out-of-range warning
commit 17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 upstream.
Ubsan reports the following warning due to a typo in
update_accessed_dirty_bits template, the patch fixes
the typo:
[ 168.791851] ================================================================================
[ 168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
[ 168.791866] index 4 is out of range for type 'u64 [4]'
[ 168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G O L 4.5.0-rc5-next-20160222 #7
[ 168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[ 168.791876] 0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
[ 168.791882] ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
[ 168.791886] 0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
[ 168.791891] Call Trace:
[ 168.791899] [<ffffffff81c9f780>] dump_stack+0xcc/0x12c
[ 168.791904] [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
[ 168.791910] [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
[ 168.791914] [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
[ 168.791918] [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
[ 168.791922] [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
[ 168.791954] [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
[ 168.791958] [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
[ 168.791987] [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
[ 168.792014] [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[ 168.792019] [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[ 168.792044] [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[ 168.792076] [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
[ 168.792121] [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
[ 168.792130] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792178] [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
[ 168.792208] [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
[ 168.792234] [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
[ 168.792238] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792263] [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
[ 168.792290] [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
[ 168.792314] [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
[ 168.792340] [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
[ 168.792367] [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
[ 168.792374] [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
[ 168.792400] [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
[ 168.792424] [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
[ 168.792449] [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
[ 168.792474] [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
[ 168.792499] [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
[ 168.792524] [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
[ 168.792532] [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
[ 168.792539] [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
[ 168.792546] [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
[ 168.792572] [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[ 168.792597] [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
[ 168.792621] [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[ 168.792627] [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
[ 168.792651] [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
[ 168.792656] [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
[ 168.792681] [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
[ 168.792704] [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
[ 168.792727] [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
[ 168.792732] [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[ 168.792735] [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
[ 168.792740] [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
[ 168.792744] [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
[ 168.792747] [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
[ 168.792751] [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[ 168.792756] [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
[ 168.792759] [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
[ 168.792763] [<ffffffff8174aef3>] ? __fget+0x273/0x4a0
[ 168.792766] [<ffffffff8174acd0>] ? __fget+0x50/0x4a0
[ 168.792770] [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
[ 168.792773] [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90
[ 168.792777] [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
[ 168.792780] ================================================================================
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de5b55f616a7ba97e72e33f52ac0cde6c8c47527
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri Feb 19 18:07:21 2016 +0100
KVM: x86: fix conversion of addresses to linear in 32-bit protected mode
commit 0c1d77f4ba5cc9c05a29adca3d6466cdf4969b70 upstream.
Commit e8dd2d2d641c ("Silence compiler warning in arch/x86/kvm/emulate.c",
2015-09-06) broke boot of the Hurd. The bug is that the "default:"
case actually could modify "la", but after the patch this change is
not reflected in *linear.
The bug is visible whenever a non-zero segment base causes the linear
address to wrap around the 4GB mark.
Fixes: e8dd2d2d641cb2724ee10e76c0ad02e04289c017
Reported-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc90441e728aa461a8ed1cfede08b0b9efef43fb
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed Feb 10 17:50:23 2016 +0100
KVM: x86: fix missed hardware breakpoints
commit 172b2386ed16a9143d9a456aae5ec87275c61489 upstream.
Sometimes when setting a breakpoint a process doesn't stop on it.
This is because the debug registers are not loaded correctly on
VCPU load.
The following simple reproducer from Oleg Nesterov tries using debug
registers in two threads. To see the bug, run a 2-VCPU guest with
"taskset -c 0" and run "./bp 0 1" inside the guest.
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <asm/debugreg.h>
#include <assert.h>
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
{
unsigned long dr7;
dr7 = ((len | type) & 0xf)
<< (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
if (enable)
dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
return dr7;
}
int write_dr(int pid, int dr, unsigned long val)
{
return ptrace(PTRACE_POKEUSER, pid,
offsetof (struct user, u_debugreg[dr]),
val);
}
void set_bp(pid_t pid, void *addr)
{
unsigned long dr7;
assert(write_dr(pid, 0, (long)addr) == 0);
dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
assert(write_dr(pid, 7, dr7) == 0);
}
void *get_rip(int pid)
{
return (void*)ptrace(PTRACE_PEEKUSER, pid,
offsetof(struct user, regs.rip), 0);
}
void test(int nr)
{
void *bp_addr = &&label + nr, *bp_hit;
int pid;
printf("test bp %d\n", nr);
assert(nr < 16); // see 16 asm nops below
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
kill(getpid(), SIGSTOP);
for (;;) {
label: asm (
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
);
}
}
assert(pid == wait(NULL));
set_bp(pid, bp_addr);
for (;;) {
assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
assert(pid == wait(NULL));
bp_hit = get_rip(pid);
if (bp_hit != bp_addr)
fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
bp_hit - &&label, nr);
}
}
int main(int argc, const char *argv[])
{
while (--argc) {
int nr = atoi(*++argv);
if (!fork())
test(nr);
}
while (wait(NULL) > 0)
;
return 0;
}
Suggested-by: Nadav Amit <namit@cs.technion.ac.il>
Reported-by: Andrey Wagin <avagin@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d62cca1106558209021273b68118a4b102ac07cf
Author: Mark Rutland <mark.rutland@arm.com>
Date: Tue Feb 16 14:47:31 2016 +0000
KVM: arm/arm64: vgic: Ensure bitmaps are long enough
commit 236cf17c2502007a9d2dda3c39fb0d9a6bd03cc2 upstream.
When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
bits we need by 8 to figure out how many bytes to allocate. However,
bitmap elements are always accessed as unsigned longs, and if we didn't
happen to allocate a size such that size % sizeof(unsigned long) == 0,
bitmap accesses may go past the end of the allocation.
When using KASAN (which does byte-granular access checks), this results
in a continuous stream of BUGs whenever these bitmaps are accessed:
=============================================================================
BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
INFO: Object 0xffffffc935769500 @offset=1280 fp=0x (null)
Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G B 4.4.0+ #17
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffffffc00008e770>] dump_backtrace+0x0/0x280
[<ffffffc00008ea04>] show_stack+0x14/0x20
[<ffffffc000726360>] dump_stack+0x100/0x188
[<ffffffc00030d324>] print_trailer+0xfc/0x168
[<ffffffc000312294>] object_err+0x3c/0x50
[<ffffffc0003140fc>] kasan_report_error+0x244/0x558
[<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
[<ffffffc000745688>] __bitmap_or+0xc0/0xc8
[<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
[<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
[<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
[<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
[<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
[<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Fix the issue by always allocating a multiple of sizeof(unsigned long),
as we do elsewhere in the vgic code.
Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 85212a3690a3eb53ae02219e3153e9d14216e164
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Fri Feb 19 13:11:46 2016 +0100
KVM: async_pf: do not warn on page allocation failures
commit d7444794a02ff655eda87e3cc54e86b940e7736f upstream.
In async_pf we try to allocate with NOWAIT to get an element quickly
or fail. This code also handle failures gracefully. Lets silence
potential page allocation failures under load.
qemu-system-s39: page allocation failure: order:0,mode:0x2200000
[...]
Call Trace:
([<00000000001146b8>] show_trace+0xf8/0x148)
[<000000000011476a>] show_stack+0x62/0xe8
[<00000000004a36b8>] dump_stack+0x70/0x98
[<0000000000272c3a>] warn_alloc_failed+0xd2/0x148
[<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
[<00000000002cd36a>] new_slab+0x382/0x400
[<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
[<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
[<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
[<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
[<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
[<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
[<00000000002f68ec>] SyS_ioctl+0xa4/0xb8
[<0000000000781c5e>] system_call+0xd6/0x264
[<000003ffa24fa06a>] 0x3ffa24fa06a
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1d61091db0ba3ef805510bb5fee46dedd7c8734
Author: Robin Murphy <robin.murphy@arm.com>
Date: Tue Feb 9 11:04:45 2016 +0000
of/irq: Fix msi-map calculation for nonzero rid-base
commit 5d589d81acf974d23af98044aac56c6339d659f8 upstream.
The existing msi-map code is fine for shifting the entire RID space
upwards, but attempting finer-grained remapping reveals a bug. It turns
out that we are mistakenly treating the msi-base part as an offset, not
as a new base to remap onto, so things get squiffy when rid-base is
nonzero. Fix this, and at the same time add a sanity check against
having msi-map-mask clash with a nonzero rid-base, as that's another
thing one can easily get wrong.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Stuart Yoder <stuart.yoder@nxp.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b8558ada696e26f51cbde1d24cdf291bbc7ec79b
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Wed Feb 17 10:41:41 2016 -0500
NFSv4: Fix a dentry leak on alias use
commit d9dfd8d741683347ee159d25f5b50c346a0df557 upstream.
In the case where d_add_unique() finds an appropriate alias to use it will
have already incremented the reference count. An additional dget() to swap
the open context's dentry is unnecessary and will leak a reference.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Fixes: 275bb307865a3 ("NFSv4: Move dentry instantiation into the NFSv4-...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fd921e575636438b8996df1e3d885dea9be5b25c
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Feb 8 21:11:50 2016 +0100
nfs: fix nfs_size_to_loff_t
commit 50ab8ec74a153eb30db26529088bc57dd700b24c upstream.
See http: //www.infradead.org/rpr.html
X-Evolution-Source: 1451162204.2173.11@leira.trondhjem.org
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
We support OFFSET_MAX just fine, so don't round down below it. Also
switch to using min_t to make the helper more readable.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Fixes: 433c92379d9c ("NFS: Clean up nfs_size_to_loff_t()")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 68a9185526f3b0738118c0c87abea9cda38be841
Author: Mike Krinkin <krinkin.m.u@gmail.com>
Date: Sat Jan 30 19:09:59 2016 +0300
block: fix use-after-free in dio_bio_complete
commit 7ddc971f86aa0a4cee9f6886c356a052461957ae upstream.
kasan reported the following error when i ran xfstest:
[ 701.826854] ==================================================================
[ 701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr ffff880080b95f94
[ 701.826870] Read of size 4 by task loop2/3874
[ 701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping: (null) index:0x0
[ 701.826890] flags: 0x100000000000000()
[ 701.826895] page dumped because: kasan: bad access detected
[ 701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G B W L 4.5.0-rc1-next-20160129 #83
[ 701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[ 701.826917] ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[ 701.826941] ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[ 701.826963] 0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[ 701.826987] Call Trace:
[ 701.826997] [<ffffffff81ca67bb>] dump_stack+0x97/0xdc
[ 701.827005] [<ffffffff81ca6724>] ? _atomic_dec_and_lock+0xc4/0xc4
[ 701.827014] [<ffffffff8161c05c>] ? __dump_page+0x32c/0x490
[ 701.827023] [<ffffffff816b0d03>] kasan_report_error+0x5f3/0x8b0
[ 701.827033] [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
[ 701.827040] [<ffffffff816b1119>] __asan_report_load4_noabort+0x59/0x80
[ 701.827048] [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
[ 701.827053] [<ffffffff817c302a>] dio_bio_complete+0x41a/0x600
[ 701.827057] [<ffffffff81bd19c8>] ? blk_queue_exit+0x108/0x270
[ 701.827060] [<ffffffff817c32b0>] dio_bio_end_aio+0xa0/0x4d0
[ 701.827063] [<ffffffff817c3210>] ? dio_bio_complete+0x600/0x600
[ 701.827067] [<ffffffff81bd2806>] ? blk_account_io_completion+0x316/0x5d0
[ 701.827070] [<ffffffff81bafe89>] bio_endio+0x79/0x200
[ 701.827074] [<ffffffff81bd2c9f>] blk_update_request+0x1df/0xc50
[ 701.827078] [<ffffffff81c02c27>] blk_mq_end_request+0x57/0x120
[ 701.827081] [<ffffffff81c03670>] __blk_mq_complete_request+0x310/0x590
[ 701.827084] [<ffffffff812348d8>] ? set_next_entity+0x2f8/0x2ed0
[ 701.827088] [<ffffffff8124b34d>] ? put_prev_entity+0x22d/0x2a70
[ 701.827091] [<ffffffff81c0394b>] blk_mq_complete_request+0x5b/0x80
[ 701.827094] [<ffffffff821e2a33>] loop_queue_work+0x273/0x19d0
[ 701.827098] [<ffffffff811f6578>] ? finish_task_switch+0x1c8/0x8e0
[ 701.827101] [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
[ 701.827104] [<ffffffff821e27c0>] ? lo_read_simple+0x890/0x890
[ 701.827108] [<ffffffff8129dd60>] ? debug_check_no_locks_freed+0x350/0x350
[ 701.827111] [<ffffffff811f63b0>] ? __hrtick_start+0x130/0x130
[ 701.827115] [<ffffffff82a0c8f6>] ? __schedule+0x936/0x20b0
[ 701.827118] [<ffffffff811dd6bd>] ? kthread_worker_fn+0x3ed/0x8d0
[ 701.827121] [<ffffffff811dd4ed>] ? kthread_worker_fn+0x21d/0x8d0
[ 701.827125] [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
[ 701.827128] [<ffffffff811dd57f>] kthread_worker_fn+0x2af/0x8d0
[ 701.827132] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[ 701.827135] [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore+0x36/0x60
[ 701.827138] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[ 701.827141] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[ 701.827144] [<ffffffff811dd00b>] kthread+0x24b/0x3a0
[ 701.827148] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[ 701.827151] [<ffffffff8129d70d>] ? trace_hardirqs_on+0xd/0x10
[ 701.827155] [<ffffffff8116d41d>] ? do_group_exit+0xdd/0x350
[ 701.827158] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[ 701.827161] [<ffffffff82a1f52f>] ret_from_fork+0x3f/0x70
[ 701.827165] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[ 701.827167] Memory state around the buggy address:
[ 701.827170] ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 701.827172] ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 701.827177] ^
[ 701.827179] ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 701.827182] ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 701.827183] ==================================================================
The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.
Fixes: 9b81c842355ac96097ba ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3e643b5cbef9d7d3112e3f64c64e3f3f7b024979
Author: Hannes Reinecke <hare@suse.de>
Date: Fri Feb 12 09:39:15 2016 +0100
bio: return EINTR if copying to user space got interrupted
commit 2d99b55d378c996b9692a0c93dd25f4ed5d58934 upstream.
Commit 35dc248383bbab0a7203fca4d722875bc81ef091 introduced a check for
current->mm to see if we have a user space context and only copies data
if we do. Now if an IO gets interrupted by a signal data isn't copied
into user space any more (as we don't have a user space context) but
user space isn't notified about it.
This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
to notify userland that a signal has interrupted the syscall, otherwise
it could lead to a situation where the caller may get a buffer with
no data returned.
This can be reproduced by issuing SG_IO ioctl()s in one thread while
constantly sending signals to it.
Fixes: 35dc248 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 023e29e467fc46f7f19c6ac96ee5135c2a56e51e
Author: Alexandra Yates <alexandra.yates@linux.intel.com>
Date: Wed Feb 17 18:21:21 2016 -0800
i2c: i801: Adding Intel Lewisburg support for iTCO
commit 1a1503c5396eb7f2edf4b8ef6067853014478c0c upstream.
Starting from Intel Sunrisepoint (Skylake PCH) the iTCO watchdog
resources have been moved to reside under the i801 SMBus host
controller whereas previously they were under the LPC device.
This patch adds Intel lewisburg SMBus support for iTCO device.
It allows to load watchdog dynamically when the hardware is
present.
Fixes: cdc5a3110e7c ("i2c: i801: add Intel Lewisburg device IDs")
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be683dfd4c253e11a8e9d9263f5dd0fed8c21de3
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Thu Jan 28 16:14:18 2016 +0800
phy: core: fix wrong err handle for phy_power_on
commit b82fcabe212a11698fd4b3e604d2f81d929d22f6 upstream.
If phy_pm_runtime_get_sync failed but we already
enable regulator, current code return directly without
doing regulator_disable. This patch fix this problem
and cleanup err handle of phy_power_on to be more readable.
Fixes: 3be88125d85d ("phy: core: Support regulator ...")
Cc: Roger Quadros <rogerq@ti.com>
Cc: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c465723d0b6f2621f6c712035b117d744a51a8b
Author: Tejun Heo <tj@kernel.org>
Date: Tue Feb 16 11:34:07 2016 -0700
writeback: keep superblock pinned during cgroup writeback association switches
commit 5ff8eaac1636bf6deae86491f4818c4c69d1a9ac upstream.
If cgroup writeback is in use, an inode is associated with a cgroup
for writeback. If the inode's main dirtier changes to another cgroup,
the association gets updated asynchronously. Nothing was pinning the
superblock while such switches are in progress and superblock could go
away while async switching is pending or in progress leading to
crashes like the following.
kernel BUG at fs/jbd2/transaction.c:319!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51
Hardware name: Google Google, BIOS Google 01/01/2011
Workqueue: events inode_switch_wbs_work_fn
task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000
RIP: 0010:[<ffffffff803e6922>] [<ffffffff803e6922>] start_this_handle+0x382/0x3e0
RSP: 0018:ffff880209267c30 EFLAGS: 00010202
...
Call Trace:
[<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190
[<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70
[<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0
[<ffffffff8035338b>] evict+0xbb/0x190
[<ffffffff80354190>] iput+0x130/0x190
[<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0
[<ffffffff80279819>] process_one_work+0x129/0x300
[<ffffffff80279b16>] worker_thread+0x126/0x480
[<ffffffff8027ed14>] kthread+0xc4/0xe0
[<ffffffff809771df>] ret_from_fork+0x3f/0x70
Fix it by bumping s_active while cgroup association switching is in
flight.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Tahsin Erdogan <tahsin@google.com>
Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4cbd196324c05809338c7f118b6f374d3c2db7a0
Author: Tejun Heo <tj@kernel.org>
Date: Thu Jan 21 15:31:11 2016 -0500
cgroup: make sure a parent css isn't offlined before its children
commit aa226ff4a1ce79f229c6b7a4c0a14e17fececd01 upstream.
There are three subsystem callbacks in css shutdown path -
css_offline(), css_released() and css_free(). Except for
css_released(), cgroup core didn't guarantee the order of invocation.
css_offline() or css_free() could be called on a parent css before its
children. This behavior is unexpected and led to bugs in cpu and
memory controller.
This patch updates offline path so that a parent css is never offlined
before its children. Each css keeps online_cnt which reaches zero iff
itself and all its children are offline and offline_css() is invoked
only after online_cnt reaches zero.
This fixes the memory controller bug and allows the fix for cpu
controller.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reported-by: Brian Christiansen <brian.o.christiansen@gmail.com>
Link: http://lkml.kernel.org/g/5698A023.9070703@de.ibm.com
Link: http://lkml.kernel.org/g/CAKB58ikDkzc8REt31WBkD99+hxNzjK4+FBmhkgS+NVrC9vjMSg@mail.gmail.com
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fff4dc84e72419196623f118312f571a2e057196
Author: Tejun Heo <tj@kernel.org>
Date: Tue Jan 19 12:18:41 2016 -0500
cpuset: make mm migration asynchronous
commit e93ad19d05648397ef3bcb838d26aec06c245dc0 upstream.
If "cpuset.memory_migrate" is set, when a process is moved from one
cpuset to another with a different memory node mask, pages in used by
the process are migrated to the new set of nodes. This was performed
synchronously in the ->attach() callback, which is synchronized
against process management. Recently, the synchronization was changed
from per-process rwsem to global percpu rwsem for simplicity and
optimization.
Combined with the synchronous mm migration, this led to deadlocks
because mm migration could schedule a work item which may in turn try
to create a new worker blocking on the process management lock held
from cgroup process migration path.
This heavy an operation shouldn't be performed synchronously from that
deep inside cgroup migration in the first place. This patch punts the
actual migration to an ordered workqueue and updates cgroup process
migration and cpuset config update paths to flush the workqueue after
all locks are released. This way, the operations still seem
synchronous to userland without entangling mm migration with process
management synchronization. CPU hotplug can also invoke mm migration
but there's no reason for it to wait for mm migrations and thus
doesn't synchronize against their completions.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a2d25804cd78be1c4f824de13827f3a0e8bf26e1
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Jan 25 10:08:00 2016 -0600
PCI/AER: Flush workqueue on device remove to avoid use-after-free
commit 4ae2182b1e3407de369f8c5d799543b7db74221b upstream.
A Root Port's AER structure (rpc) contains a queue of events. aer_irq()
enqueues AER status information and schedules aer_isr() to dequeue and
process it. When we remove a device, aer_remove() waits for the queue to
be empty, then frees the rpc struct.
But aer_isr() references the rpc struct after dequeueing and possibly
emptying the queue, which can cause a use-after-free error as in the
following scenario with two threads, aer_isr() on the left and a
concurrent aer_remove() on the right:
Thread A Thread B
-------- --------
aer_irq():
rpc->prod_idx++
aer_remove():
wait_event(rpc->prod_idx == rpc->cons_idx)
# now blocked until queue becomes empty
aer_isr(): # ...
rpc->cons_idx++ # unblocked because queue is now empty
... kfree(rpc)
mutex_unlock(&rpc->rpc_mutex)
To prevent this problem, use flush_work() to wait until the last scheduled
instance of aer_isr() has completed before freeing the rpc struct in
aer_remove().
I reproduced this use-after-free by flashing a device FPGA and
re-enumerating the bus to find the new device. With SLUB debug, this
crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
GPR25:
pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
Unable to handle kernel paging request for data at address 0x27ef9e3e
Workqueue: events aer_isr
GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
NIP [602f5328] pci_walk_bus+0xd4/0x104
[bhelgaas: changelog, stable tag]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1de8f1bcb5321bdc35b64bafe4f4a9c389942167
Author: Vineet Gupta <vgupta@synopsys.com>
Date: Tue Feb 23 11:55:16 2016 +0530
ARCv2: SMP: Emulate IPI to self using software triggered interrupt
commit bb143f814ea488769ca2e79e0b376139cb5f134b upstream.
ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.
This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.
All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.
Fixes STAR 9001008624
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0bdce40ce0402ab4d46e33f452eb0c29470e0dc6
Author: Vineet Gupta <vgupta@synopsys.com>
Date: Fri Jan 8 12:29:10 2016 +0530
ARCv2: STAR 9000950267: Handle return from intr to Delay Slot #2
commit cbfe74a753e877b49dc54e9b04d5d42230ca0aed upstream.
Returning to delay slot, riding an interrupti, had one loose end.
AUX_USER_SP used for restoring user mode SP upon RTIE was not being
setup from orig task's saved value, causing task to use wrong SP,
leading to ProtV errors.
The reason being:
- INTERRUPT_EPILOGUE returns to a kernel trampoline, thus not expected to restore it
- EXCEPTION_EPILOGUE is not used at all
Fix that by restoring AUX_USER_SP explicitly in the trampoline.
This was broken in the original workaround, but the error scenarios got
reduced considerably since v3.14 due to following:
1. The Linuxthreads.old based userspace at the time caused many more
exceptions in delay slot than the current NPTL based one.
Infact with current userspace the error doesn't happen at all.
2. Return from interrupt (delay slot or otherwise) doesn't get exercised much
after commit 4de0e52867d8 ("Really Re-enable interrupts to avoid deadlocks")
since IRQ_ACTIVE.active being clear means most returns are as if from pure
kernel (even for active interrupts)
Infact the issue only happened in an experimental branch where I was tinkering with
reverted 4de0e52867d8
Fixes: 4255b07f2c9c ("ARCv2: STAR 9000793984: Handle return from intr to Delay Slot")
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aff4514876f47a45a84118aeaa2b81b33d6f0e29
Author: Tejun Heo <tj@kernel.org>
Date: Mon Feb 1 11:33:21 2016 -0500
libata: fix sff host state machine locking while polling
commit 8eee1d3ed5b6fc8e14389567c9a6f53f82bb7224 upstream.
The bulk of ATA host state machine is implemented by
ata_sff_hsm_move(). The function is called from either the interrupt
handler or, if polling, a work item. Unlike from the interrupt path,
the polling path calls the function without holding the host lock and
ata_sff_hsm_move() selectively grabs the lock.
This is completely broken. If an IRQ triggers while polling is in
progress, the two can easily race and end up accessing the hardware
and updating state machine state at the same time. This can put the
state machine in an illegal state and lead to a crash like the
following.
kernel BUG at drivers/ata/libata-sff.c:1302!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 10679 Comm: syz-executor Not tainted 4.5.0-rc1+ #300
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88002bd00000 ti: ffff88002e048000 task.ti: ffff88002e048000
RIP: 0010:[<ffffffff83a83409>] [<ffffffff83a83409>] ata_sff_hsm_move+0x619/0x1c60
...
Call Trace:
<IRQ>
[<ffffffff83a84c31>] __ata_sff_port_intr+0x1e1/0x3a0 drivers/ata/libata-sff.c:1584
[<ffffffff83a85611>] ata_bmdma_port_intr+0x71/0x400 drivers/ata/libata-sff.c:2877
[< inline >] __ata_sff_interrupt drivers/ata/libata-sff.c:1629
[<ffffffff83a85bf3>] ata_bmdma_interrupt+0x253/0x580 drivers/ata/libata-sff.c:2902
[<ffffffff81479f98>] handle_irq_event_percpu+0x108/0x7e0 kernel/irq/handle.c:157
[<ffffffff8147a717>] handle_irq_event+0xa7/0x140 kernel/irq/handle.c:205
[<ffffffff81484573>] handle_edge_irq+0x1e3/0x8d0 kernel/irq/chip.c:623
[< inline >] generic_handle_irq_desc include/linux/irqdesc.h:146
[<ffffffff811a92bc>] handle_irq+0x10c/0x2a0 arch/x86/kernel/irq_64.c:78
[<ffffffff811a7e4d>] do_IRQ+0x7d/0x1a0 arch/x86/kernel/irq.c:240
[<ffffffff86653d4c>] common_interrupt+0x8c/0x8c arch/x86/entry/entry_64.S:520
<EOI>
[< inline >] rcu_lock_acquire include/linux/rcupdate.h:490
[< inline >] rcu_read_lock include/linux/rcupdate.h:874
[<ffffffff8164b4a1>] filemap_map_pages+0x131/0xba0 mm/filemap.c:2145
[< inline >] do_fault_around mm/memory.c:2943
[< inline >] do_read_fault mm/memory.c:2962
[< inline >] do_fault mm/memory.c:3133
[< inline >] handle_pte_fault mm/memory.c:3308
[< inline >] __handle_mm_fault mm/memory.c:3418
[<ffffffff816efb16>] handle_mm_fault+0x2516/0x49a0 mm/memory.c:3447
[<ffffffff8127dc16>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
[<ffffffff8127e358>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
[<ffffffff8126f514>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
[<ffffffff86655578>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
Fix it by ensuring that the polling path is holding the host lock
before entering ata_sff_hsm_move() so that all hardware accesses and
state updates are performed under the host lock.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
Link: http://lkml.kernel.org/g/CACT4Y+b_JsOxJu2EZyEf+mOXORc_zid5V1-pLZSroJVxyWdSpw@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 921d439c6720c22ad94da1c3354ee4522781809d
Author: Quinn Tran <quinn.tran@qlogic.com>
Date: Thu Feb 4 11:45:16 2016 -0500
qla2xxx: Fix stale pointer access.
commit cb43285ff7039fe3c4b0bc476e6d6569c31104f3 upstream.
[ Upstream Commit 84e32a06f4f8756ce9ec3c8dc7e97896575f0771 ]
Commit 84e32a0 ("qla2xxx: Use pci_enable_msix_range() instead of
pci_enable_msix()") introduced a regression when target mode is enabled.
In qla24xx_enable_msix(), ha->max_rsp_queues was incorrectly set
to a value higher than the number of response queues allocated causing
an invalid dereference. Specifically here in qla2x00_init_rings():
*rsp->in_ptr = 0;
Add additional check to make sure the pointer is valid. following
call stack will be seen
---- 8< ----
RIP: 0010:[<ffffffffa02ccadc>] [<ffffffffa02ccadc>] qla2x00_init_rings+0xdc/0x320 [qla2xxx]
RSP: 0018:ffff880429447dd8 EFLAGS: 00010082
....
Call Trace:
[<ffffffffa02ceb40>] qla2x00_abort_isp+0x170/0x6b0 [qla2xxx]
[<ffffffffa02c6f77>] qla2x00_do_dpc+0x357/0x7f0 [qla2xxx]
[<ffffffffa02c6c20>] ? qla2x00_relogin+0x260/0x260 [qla2xxx]
[<ffffffff8107d2c9>] kthread+0xc9/0xe0
[<ffffffff8107d200>] ? flush_kthread_worker+0x90/0x90
[<ffffffff8172cc6f>] ret_from_fork+0x3f/0x70
[<ffffffff8107d200>] ? flush_kthread_worker+0x90/0x90
---- 8< ----
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 44c7d7625f76a987f59b588fcb8727c7b286b99d
Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Wed Jan 27 17:48:32 2016 +0100
spi: atmel: fix gpio chip-select in case of non-DT platform
commit 70f340df24518d36eeaefb6652d492f250115c19 upstream.
The non-DT platform that uses this driver (actually the AVR32) was taking a bad
branch for determining if the IP would use gpio for CS.
Adding the presence of DT as a condition fixes this issue.
Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller")
Reported-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
[nicolas.ferre@atmel.com: extract from ml discussion]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9d992021215ef0361105c3735aa5625ad261937
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Fri Feb 5 14:51:36 2016 -0800
target: Fix race with SCF_SEND_DELAYED_TAS handling
commit 310d3d314be7f0a84011ebdc4bdccbcae9755a87 upstream.
This patch fixes a race between setting of SCF_SEND_DELAYED_TAS
in transport_send_task_abort(), and check of the same bit in
transport_check_aborted_status().
It adds a __transport_check_aborted_status() version that is
used by target_execute_cmd() when se_cmd->t_state_lock is
held, and a transport_check_aborted_status() wrapper for
all other existing callers.
Also, it handles the case where the check happens before
transport_send_task_abort() gets called. For this, go
ahead and set SCF_SEND_DELAYED_TAS early when necessary,
and have transport_send_task_abort() send the abort.
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb6a326e303451078ee93c1293918aa2e044cff8
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Tue Jan 19 15:23:02 2016 -0800
target: Fix remote-port TMR ABORT + se_cmd fabric stop
commit 0f4a943168f31d29a1701908931acaba518b131a upstream.
To address the bug where fabric driver level shutdown
of se_cmd occurs at the same time when TMR CMD_T_ABORTED
is happening resulting in a -1 ->cmd_kref, this patch
adds a CMD_T_FABRIC_STOP bit that is used to determine
when TMR + driver I_T nexus shutdown is happening
concurrently.
It changes target_sess_cmd_list_set_waiting() to obtain
se_cmd->cmd_kref + set CMD_T_FABRIC_STOP, and drop local
reference in target_wait_for_sess_cmds() and invoke extra
target_put_sess_cmd() during Task Aborted Status (TAS)
when necessary.
Also, it adds a new target_wait_free_cmd() wrapper around
transport_wait_for_tasks() for the special case within
transport_generic_free_cmd() to set CMD_T_FABRIC_STOP,
and is now aware of CMD_T_ABORTED + CMD_T_TAS status
bits to know when an extra transport_put_cmd() during
TAS is required.
Note transport_generic_free_cmd() is expected to block on
cmd->cmd_wait_comp in order to follow what iscsi-target
expects during iscsi_conn context se_cmd shutdown.
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@daterainc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 547551e5a591ce744845202ecfa8b54366832b60
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Sat Jan 16 12:49:49 2016 -0800
target: Fix TAS handling for multi-session se_node_acls
commit ebde1ca5a908b10312db4ecd7553e3ba039319ab upstream.
This patch fixes a bug in TMR task aborted status (TAS)
handling when multiple sessions are connected to the
same target WWPN endpoint and se_node_acl descriptor,
resulting in TASK_ABORTED status to not be generated
for aborted se_cmds on the remote port.
This is due to core_tmr_handle_tas_abort() incorrectly
comparing se_node_acl instead of se_session, for which
the multi-session case is expected to be sharing the
same se_node_acl.
Instead, go ahead and update core_tmr_handle_tas_abort()
to compare tmr_sess + cmd->se_sess in order to determine
if the LUN_RESET was received on a different I_T nexus,
and TASK_ABORTED status response needs to be generated.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91583a21641d148b281ae48e909a56c23c5978f6
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Mon Jan 11 21:53:05 2016 -0800
target: Fix LUN_RESET active TMR descriptor handling
commit a6d9bb1c9605cd4f44e2d8290dc4d0e88f20292d upstream.
This patch fixes a NULL pointer se_cmd->cmd_kref < 0
refcount bug during TMR LUN_RESET with active TMRs,
triggered during se_cmd + se_tmr_req descriptor
shutdown + release via core_tmr_drain_tmr_list().
To address this bug, go ahead and obtain a local
kref_get_unless_zero(&se_cmd->cmd_kref) for active I/O
to set CMD_T_ABORTED, and transport_wait_for_tasks()
followed by the final target_put_sess_cmd() to drop
the local ->cmd_kref.
Also add two new checks within target_tmr_work() to
avoid CMD_T_ABORTED -> TFO->queue_tm_rsp() callbacks
ahead of invoking the backend -> fabric put in
transport_cmd_check_stop_to_fabric().
For good measure, also change core_tmr_release_req()
to use list_del_init() ahead of se_tmr_req memory
free.
Reviewed-by: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b493f9f06d19056669fe94b0933aaea06f3fee6
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Mon Jan 11 21:31:09 2016 -0800
target: Fix LUN_RESET active I/O handling for ACK_KREF
commit febe562c20dfa8f33bee7d419c6b517986a5aa33 upstream.
This patch fixes a NULL pointer se_cmd->cmd_kref < 0
refcount bug during TMR LUN_RESET with active se_cmd
I/O, that can be triggered during se_cmd descriptor
shutdown + release via core_tmr_drain_state_list() code.
To address this bug, add common __target_check_io_state()
helper for ABORT_TASK + LUN_RESET w/ CMD_T_COMPLETE
checking, and set CMD_T_ABORTED + obtain ->cmd_kref for
both cases ahead of last target_put_sess_cmd() after
TFO->aborted_task() -> transport_cmd_finish_abort()
callback has completed.
It also introduces SCF_ACK_KREF to determine when
transport_cmd_finish_abort() needs to drop the second
extra reference, ahead of calling target_put_sess_cmd()
for the final kref_put(&se_cmd->cmd_kref).
It also updates transport_cmd_check_stop() to avoid
holding se_cmd->t_state_lock while dropping se_cmd
device state via target_remove_from_state_list(), now
that core_tmr_drain_state_list() is holding the
se_device lock while checking se_cmd state from
within TMR logic.
Finally, move transport_put_cmd() release of SGL +
TMR + extended CDB memory into target_free_cmd_mem()
in order to avoid potential resource leaks in TMR
ABORT_TASK + LUN_RESET code-paths. Also update
target_release_cmd_kref() accordingly.
Reviewed-by: Quinn Tran <quinn.tran@qlogic.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Cc: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7cb32ae09a6490c27bc3c110ee42d808a5670142
Author: Kai-Heng Feng <kaihengfeng@gmail.com>
Date: Thu Feb 25 15:19:38 2016 +0800
ALSA: hda - Fixing background noise on Dell Inspiron 3162
commit 3b43b71f05d3ecd01c4116254666d9492301697d upstream.
After login to the desktop on Dell Inspiron 3162,
there's a very loud background noise comes from the builtin speaker.
The noise does not go away even if the speaker is muted.
The noise disappears after using the aamix fixup.
Codec: Realtek ALC3234
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0255
Subsystem Id: 0x10280725
Revision Id: 0x100002
No Modem Function Group found
BugLink: http://bugs.launchpad.net/bugs/1549620
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1436e689caee2b92ea30813d587598afea1d0e6b
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 22 15:18:13 2016 +0100
ALSA: hda - Apply clock gate workaround to Skylake, too
commit 7e31a0159461818a1bda49662921b98a29c1187b upstream.
Some Skylake machines show the codec probe errors in certain
situations, e.g. HP Z240 desktop fails to probe the onboard Realtek
codec at reloading the snd-hda-intel module like:
snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000
snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000
snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
hdaudio hdaudioC0D2: no AFG or MFG node found
snd_hda_intel 0000:00:1f.3: no codecs initialized
Also, HP G470 G3 suffers from the similar problem, as reported in
bugzilla below. On this machine, the codec probe error appears even
at a fresh boot.
As Libin suggested, the same workaround used for Broxton in the commit
[6639484ddaf6: ALSA: hda - disable dynamic clock gating on Broxton
before reset] can be applied for Skylake in order to fix this problem.
The Intel HW team also confirmed that this is needed for SKL.
This patch makes the workaround applied to both SKL and BXT
platforms. The referred macros are moved and one superfluous macro
(IS_BROXTON()) is another one (IS_BXT()) as well.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731
Suggested-by: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6684710434d07dfd7e512e5ecc77eefb5a30151e
Author: Tejun Heo <tj@kernel.org>
Date: Tue Feb 9 16:11:26 2016 -0500
Revert "workqueue: make sure delayed work run in local cpu"
commit 041bd12e272c53a35c54c13875839bcb98c999ce upstream.
This reverts commit 874bbfe600a660cba9c776b3957b1ce393151b76.
Workqueue used to implicity guarantee that work items queued without
explicit CPU specified are put on the local CPU. Recent changes in
timer broke the guarantee and led to vmstat breakage which was fixed
by 176bed1de5bf ("vmstat: explicitly schedule per-cpu work on the CPU
we need it to run on").
vmstat is the most likely to expose the issue and it's quite possible
that there are other similar problems which are a lot more difficult
to trigger. As a preventive measure, 874bbfe600a6 ("workqueue: make
sure delayed work run in local cpu") was applied to restore the local
CPU guarnatee. Unfortunately, the change exposed a bug in timer code
which got fixed by 22b886dd1018 ("timers: Use proper base migration in
add_timer_on()"). Due to code restructuring, the commit couldn't be
backported beyond certain point and stable kernels which only had
874bbfe600a6 started crashing.
The local CPU guarantee was accidental more than anything else and we
want to get rid of it anyway. As, with the vmstat case fixed,
874bbfe600a6 is causing more problems than it's fixing, it has been
decided to take the chance and officially break the guarantee by
reverting the commit. A debug feature will be added to force foreign
CPU assignment to expose cases relying on the guarantee and fixes for
the individual cases will be backported to stable as necessary.
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 874bbfe600a6 ("workqueue: make sure delayed work run in local cpu")
Link: http://lkml.kernel.org/g/20160120211926.GJ10810@quack.suse.cz
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
Cc: Jan Kara <jack@suse.cz>
Cc: Shaohua Li <shli@fb.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Bilik <daniel.bilik@neosystem.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21b34b4574f8619907eb751b37c1831bfa3f2440
Author: Tejun Heo <tj@kernel.org>
Date: Wed Feb 3 13:54:25 2016 -0500
workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
commit d6e022f1d207a161cd88e08ef0371554680ffc46 upstream.
When looking up the pool_workqueue to use for an unbound workqueue,
workqueue assumes that the target CPU is always bound to a valid NUMA
node. However, currently, when a CPU goes offline, the mapping is
destroyed and cpu_to_node() returns NUMA_NO_NODE.
This has always been broken but hasn't triggered often enough before
874bbfe600a6 ("workqueue: make sure delayed work run in local cpu").
After the commit, workqueue forcifully assigns the local CPU for
delayed work items without explicit target CPU to fix a different
issue. This widens the window where CPU can go offline while a
delayed work item is pending causing delayed work items dispatched
with target CPU set to an already offlined CPU. The resulting
NUMA_NO_NODE mapping makes workqueue try to queue the work item on a
NULL pool_workqueue and thus crash.
While 874bbfe600a6 has been reverted for a different reason making the
bug less visible again, it can still happen. Fix it by mapping
NUMA_NO_NODE to the default pool_workqueue from unbound_pwq_by_node().
This is a temporary workaround. The long term solution is keeping CPU
-> NODE mapping stable across CPU off/online cycles which is being
worked on.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Len Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/g/1454424264.11183.46.camel@gmail.com
Link: http://lkml.kernel.org/g/1453702100-2597-1-git-send-email-tangchen@cn.fujitsu.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 81bb655358726b0abf888c54d33135dae3a07c12
Author: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com>
Date: Tue Jan 12 14:30:19 2016 +0530
mac80211: Requeue work after scan complete for all VIF types.
commit 4fa11ec726a32ea6dd768dbb2e2af3453a98ec0a upstream.
During a sw scan ieee80211_iface_work ignores work items for all vifs.
However after the scan complete work is requeued only for STA, ADHOC
and MESH iftypes.
This occasionally results in event processing getting delayed/not
processed for iftype AP when it coexists with a STA. This can result
in data halt and eventually disconnection on the AP interface.
Signed-off-by: Sachin Kulkarni <Sachin.Kulkarni@imgtec.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 33bf18e4aa06f4b31eb21c1f77d4286f49dfc72e
Author: Johannes Berg <johannes.berg@intel.com>
Date: Tue Jan 26 11:29:03 2016 +0100
rfkill: fix rfkill_fop_read wait_event usage
commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 upstream.
The code within wait_event_interruptible() is called with
!TASK_RUNNING, so mustn't call any functions that can sleep,
like mutex_lock().
Since we re-check the list_empty() in a loop after the wait,
it's safe to simply use list_empty() without locking.
This bug has existed forever, but was only discovered now
because all userspace implementations, including the default
'rfkill' tool, use poll() or select() to get a readable fd
before attempting to read.
Fixes: c64fb01627e24 ("rfkill: create useful userspace interface")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d024d46ec5203664fac872a20f7d75125db952da
Author: Wanpeng Li <kernellwp@gmail.com>
Date: Wed Jan 27 19:26:07 2016 +0800
tick/nohz: Set the correct expiry when switching to nohz/lowres mode
commit 1ca8ec532fc2d986f1f4a319857bb18e0c9739b4 upstream.
commit 0ff53d096422 sets the next tick interrupt to the last jiffies update,
i.e. in the past, because the forward operation is invoked before the set
operation. There is no resulting damage (yet), but we get an extra pointless
tick interrupt.
Revert the order so we get the next tick interrupt in the future.
Fixes: commit 0ff53d096422 "tick: sched: Force tick interrupt and get rid of softirq magic"
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/1453893967-3458-1-git-send-email-wanpeng.li@hotmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e43193617315070ca9a6ca55794760e328fe4e9b
Author: Jiri Olsa <jolsa@kernel.org>
Date: Wed Jan 20 12:56:34 2016 +0100
perf stat: Do not clean event's private stats
commit 3f416f22d1e21709a631189ba169f76fd267b374 upstream.
Mel reported stddev reporting was broken due to following commit:
106a94a0f8c2 ("perf stat: Introduce read_counters function")
This commit merged interval and overall counters reading into single
read_counters function.
The old interval code cleaned the stddev data for some reason (it's
never displayed in interval mode) and the mentioned commit kept on
cleaning the stddev data in merged function, which resulted in the
stddev not being displayed.
Removing the wrong stddev data cleanup init_stats call.
Reported-and-Tested-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Fixes: 106a94a0f8c2 ("perf stat: Introduce read_counters function")
Link: http://lkml.kernel.org/r/1453290995-18485-4-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19964740ebb3f69fb65a8e10dadb4863dd8a8dfe
Author: Oliver Neukum <oneukum@suse.com>
Date: Mon Jan 18 15:45:18 2016 +0100
cdc-acm:exclude Samsung phone 04e8:685d
commit e912e685f372ab62a2405a1acd923597f524e94a upstream.
This phone needs to be handled by a specialised firmware tool
and is reported to crash irrevocably if cdc-acm takes it.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f021f05c1223ce0424d9bd9bddb013aa68b88801
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Sat Jan 23 14:49:20 2016 +0530
Revert "Staging: panel: usleep_range is preferred over udelay"
commit b64a1cbef6df47c986ad622b5b2e4d3d1940070c upstream.
This reverts commit ebd43516d3879f882a403836bba8bc5791f26a28.
We should not be sleeping inside spin_lock.
Fixes: ebd43516d387 ("Staging: panel: usleep_range is preferred over udelay")
Cc: Sirnam Swetha <theonly.ultimate@gmail.com>
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Reported-by: Huang, Ying <ying.huang@intel.com>
Tested-by: Huang, Ying <ying.huang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 16d9f52201f330b4438467724a0b0691dcf45cc3
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Fri Jan 15 00:47:41 2016 +0100
Staging: speakup: Fix getting port information
commit 327b882d3bcc1fba82dbd39b5cf5a838c81218e2 upstream.
Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h>
instead of <asm/serial.h>") broke the port information in the speakup
driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included,
and no other header includes asm/serial.h.
We here make sure serialio.c does get the arch-specific definition of
SERIAL_PORT_DFNS from asm/serial.h, if any.
Along the way, this makes sure that we do have information for the
requested serial port number (index)
Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>")
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f313f1d809fb055eb9707e6dfd2c77fb4d9cc4ee
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date: Wed Jan 20 11:01:23 2016 -0500
sd: Optimal I/O size is in bytes, not sectors
commit d0eb20a863ba7dc1d3f4b841639671f134560be2 upstream.
Commit ca369d51b3e1 ("block/sd: Fix device-imposed transfer length
limits") accidentally switched optimal I/O size reporting from bytes to
block layer sectors.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Fixes: ca369d51b3e1649be4a72addd6d6a168cfb3f537
Reviewed-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01c3c0f921c8a2743e3d066108081c14618ee98c
Author: Ilya Dryomov <idryomov@gmail.com>
Date: Fri Feb 19 11:38:57 2016 +0100
libceph: don't spam dmesg with stray reply warnings
commit cd8140c673d9ba9be3591220e1b2226d9e1e40d3 upstream.
Commit d15f9d694b77 ("libceph: check data_len in ->alloc_msg()")
mistakenly bumped the log level on the "tid %llu unknown, skipping"
message. Turn it back into a dout() - stray replies are perfectly
normal when OSDs flap, crash, get killed for testing purposes, etc.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 10dada9dad8fbc36840ef5266419bb0fce5945a0
Author: Ilya Dryomov <idryomov@gmail.com>
Date: Fri Feb 19 11:38:57 2016 +0100
libceph: use the right footer size when skipping a message
commit dbc0d3caff5b7591e0cf8e34ca686ca6f4479ee1 upstream.
ceph_msg_footer is 21 bytes long, while ceph_msg_footer_old is only 13.
Don't skip too much when CEPH_FEATURE_MSG_AUTH isn't negotiated.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50c6a283a713c62e6430e6dcc27ecaa91c46ba80
Author: Ilya Dryomov <idryomov@gmail.com>
Date: Wed Feb 17 20:04:08 2016 +0100
libceph: don't bail early from try_read() when skipping a message
commit e7a88e82fe380459b864e05b372638aeacb0f52d upstream.
The contract between try_read() and try_write() is that when called
each processes as much data as possible. When instructed by osd_client
to skip a message, try_read() is violating this contract by returning
after receiving and discarding a single message instead of checking for
more. try_write() then gets a chance to write out more requests,
generating more replies/skips for try_read() to handle, forcing the
messenger into a starvation loop.
Reported-by: Varada Kari <Varada.Kari@sandisk.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Varada Kari <Varada.Kari@sandisk.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee834473805f5fd77a3d2625a40552159641029e
Author: Ilya Dryomov <idryomov@gmail.com>
Date: Mon Dec 28 13:18:34 2015 +0300
libceph: fix ceph_msg_revoke()
commit 67645d7619738e51c668ca69f097cb90b5470422 upstream.
There are a number of problems with revoking a "was sending" message:
(1) We never make any attempt to revoke data - only kvecs contibute to
con->out_skip. However, once the header (envelope) is written to the
socket, our peer learns data_len and sets itself to expect at least
data_len bytes to follow front or front+middle. If ceph_msg_revoke()
is called while the messenger is sending message's data portion,
anything we send after that call is counted by the OSD towards the now
revoked message's data portion. The effects vary, the most common one
is the eventual hang - higher layers get stuck waiting for the reply to
the message that was sent out after ceph_msg_revoke() returned and
treated by the OSD as a bunch of data bytes. This is what Matt ran
into.
(2) Flat out zeroing con->out_kvec_bytes worth of bytes to handle kvecs
is wrong. If ceph_msg_revoke() is called before the tag is sent out or
while the messenger is sending the header, we will get a connection
reset, either due to a bad tag (0 is not a valid tag) or a bad header
CRC, which kind of defeats the purpose of revoke. Currently the kernel
client refuses to work with header CRCs disabled, but that will likely
change in the future, making this even worse.
(3) con->out_skip is not reset on connection reset, leading to one or
more spurious connection resets if we happen to get a real one between
con->out_skip is set in ceph_msg_revoke() and before it's cleared in
write_partial_skip().
Fixing (1) and (3) is trivial. The idea behind fixing (2) is to never
zero the tag or the header, i.e. send out tag+header regardless of when
ceph_msg_revoke() is called. That way the header is always correct, no
unnecessary resets are induced and revoke stands ready for disabled
CRCs. Since ceph_msg_revoke() rips out con->out_msg, introduce a new
"message out temp" and copy the header into it before sending.
Reported-by: Matt Conner <matt.conner@keepertech.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Matt Conner <matt.conner@keepertech.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit df86161e4460cfd4ba504d5c5fd6ba218c75d4aa
Author: Jann Horn <jann@thejh.net>
Date: Sat Dec 26 06:00:48 2015 +0100
seccomp: always propagate NO_NEW_PRIVS on tsync
commit 103502a35cfce0710909da874f092cb44823ca03 upstream.
Before this patch, a process with some permissive seccomp filter
that was applied by root without NO_NEW_PRIVS was able to add
more filters to itself without setting NO_NEW_PRIVS by setting
the new filter from a throwaway thread with NO_NEW_PRIVS.
Signed-off-by: Jann Horn <jann@thejh.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ac4a2a8bae9838d69be6dec3212e3630fb5773c
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date: Mon Jan 25 22:33:46 2016 +0530
cpufreq: Fix NULL reference crash while accessing policy->governor_data
commit e4b133cc4b30b48d488e4e4fffb132f173ce4358 upstream.
There is a race discovered by Juri, where we are able to:
- create and read a sysfs file before policy->governor_data is being set
to a non NULL value.
OR
- set policy->governor_data to NULL, and reading a file before being
destroyed.
And so such a crash is reported:
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
pgd = edfc8000
[0000000c] *pgd=bfc8c835
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 4 PID: 1730 Comm: cat Not tainted 4.5.0-rc1+ #463
Hardware name: ARM-Versatile Express
task: ee8e8480 ti: ee930000 task.ti: ee930000
PC is at show_ignore_nice_load_gov_pol+0x24/0x34
LR is at show+0x4c/0x60
pc : [<c058f1bc>] lr : [<c058ae88>] psr: a0070013
sp : ee931dd0 ip : ee931de0 fp : ee931ddc
r10: ee4bc290 r9 : 00001000 r8 : ef2cb000
r7 : ee4bc200 r6 : ef2cb000 r5 : c0af57b0 r4 : ee4bc2e0
r3 : 00000000 r2 : 00000000 r1 : c0928df4 r0 : ef2cb000
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: adfc806a DAC: 00000051
Process cat (pid: 1730, stack limit = 0xee930210)
Stack: (0xee931dd0 to 0xee932000)
1dc0: ee931dfc ee931de0 c058ae88 c058f1a4
1de0: edce3bc0 c07bfca4 edce3ac0 00001000 ee931e24 ee931e00 c01fcb90 c058ae48
1e00: 00000001 edce3bc0 00000000 00000001 ee931e50 ee8ff480 ee931e34 ee931e28
1e20: c01fb33c c01fcb0c ee931e8c ee931e38 c01a5210 c01fb314 ee931e9c ee931e48
1e40: 00000000 edce3bf0 befe4a00 ee931f78 00000000 00000000 000001e4 00000000
1e60: c00545a8 edce3ac0 00001000 00001000 befe4a00 ee931f78 00000000 00001000
1e80: ee931ed4 ee931e90 c01fbed8 c01a5038 ed085a58 00020000 00000000 00000000
1ea0: c0ad72e4 ee931f78 ee8ff488 ee8ff480 c077f3fc 00001000 befe4a00 ee931f78
1ec0: 00000000 00001000 ee931f44 ee931ed8 c017c328 c01fbdc4 00001000 00000000
1ee0: ee8ff480 00001000 ee931f44 ee931ef8 c017c65c c03deb10 ee931fac ee931f08
1f00: c0009270 c001f290 c0a8d968 ef2cb000 ef2cb000 ee8ff480 00000020 ee8ff480
1f20: ee8ff480 befe4a00 00001000 ee931f78 00000000 00000000 ee931f74 ee931f48
1f40: c017d1ec c017c2f8 c019c724 c019c684 ee8ff480 ee8ff480 00001000 befe4a00
1f60: 00000000 00000000 ee931fa4 ee931f78 c017d2a8 c017d160 00000000 00000000
1f80: 000a9f20 00001000 befe4a00 00000003 c000ffe4 ee930000 00000000 ee931fa8
1fa0: c000fe40 c017d264 000a9f20 00001000 00000003 befe4a00 00001000 00000000
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
1fc0: 000a9f20 00001000 befe4a00 00000003 00000000 00000000 00000003 00000001
pgd = edfc4000
[0000000c] *pgd=bfcac835
1fe0: 00000000 befe49dc 000197f8 b6e35dfc 60070010 00000003 3065b49d 134ac2c9
[<c058f1bc>] (show_ignore_nice_load_gov_pol) from [<c058ae88>] (show+0x4c/0x60)
[<c058ae88>] (show) from [<c01fcb90>] (sysfs_kf_seq_show+0x90/0xfc)
[<c01fcb90>] (sysfs_kf_seq_show) from [<c01fb33c>] (kernfs_seq_show+0x34/0x38)
[<c01fb33c>] (kernfs_seq_show) from [<c01a5210>] (seq_read+0x1e4/0x4e4)
[<c01a5210>] (seq_read) from [<c01fbed8>] (kernfs_fop_read+0x120/0x1a0)
[<c01fbed8>] (kernfs_fop_read) from [<c017c328>] (__vfs_read+0x3c/0xe0)
[<c017c328>] (__vfs_read) from [<c017d1ec>] (vfs_read+0x98/0x104)
[<c017d1ec>] (vfs_read) from [<c017d2a8>] (SyS_read+0x50/0x90)
[<c017d2a8>] (SyS_read) from [<c000fe40>] (ret_fast_syscall+0x0/0x1c)
Code: e5903044 e1a00001 e3081df4 e34c1092 (e593300c)
---[ end trace 5994b9a5111f35ee ]---
Fix that by making sure, policy->governor_data is updated at the right
places only.
Reported-and-tested-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 286ab25d69068cef7c97e305af347288b9f1ab4a
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Jan 25 16:44:38 2016 +0100
cpufreq: pxa2xx: fix pxa_cpufreq_change_voltage prototype
commit fb2a24a1c6457d21df9fae0dd66b20c63ba56077 upstream.
There are two definitions of pxa_cpufreq_change_voltage, with slightly
different prototypes after one of them had its argument marked 'const'.
Now the other one (for !CONFIG_REGULATOR) produces a harmless warning:
drivers/cpufreq/pxa2xx-cpufreq.c: In function 'pxa_set_target':
drivers/cpufreq/pxa2xx-cpufreq.c:291:36: warning: passing argument 1 of 'pxa_cpufreq_change_voltage' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
ret = pxa_cpufreq_change_voltage(&pxa_freq_settings[idx]);
^
drivers/cpufreq/pxa2xx-cpufreq.c:205:12: note: expected 'struct pxa_freqs *' but argument is of type 'const struct pxa_freqs *'
static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
^
This changes the prototype in the same way as the other, which
avoids the warning.
Fixes: 03c229906311 (cpufreq: pxa: make pxa_freqs arrays const)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c2bd0c61ca8a5af85370c71f9c7e05e1e434132
Author: Peter Rosin <peda@axentia.se>
Date: Thu Feb 18 14:07:52 2016 +0100
hwmon: (ads1015) Handle negative conversion values correctly
commit acc146943957d7418a6846f06e029b2c5e87e0d5 upstream.
Make the divisor signed as DIV_ROUND_CLOSEST is undefined for negative
dividends when the divisor is unsigned.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4bbd7acd014a4432b8d15372840184dce62b1002
Author: Nishanth Menon <nm@ti.com>
Date: Fri Feb 19 18:09:51 2016 -0600
hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook
commit 000e0949148382c4962489593a2f05504c2a6771 upstream.
Thermal hook gpio_fan_get_cur_state is only interested in knowing
the current speed index that was setup in the system, this is
already available as part of fan_data->speed_index which is always
set by set_fan_speed. Using get_fan_speed_index is useful when we
have no idea about the fan speed configuration (for example during
fan_ctrl_init).
When thermal framework invokes
gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
especially in a polled configuration for thermal governor, we
basically hog the i2c interface to the extent that other functions
fail to get any traffic out :(.
Instead, just provide the last state set in the driver - since the gpio
fan driver is responsible for the fan state immaterial of override, the
fan_data->speed_index should accurately reflect the state.
Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
Reported-by: Tony Lindgren <tony@atomide.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ff7850139c4e104b974edc09d5cfdb0dc616da9
Author: Thorsten Leemhuis <linux@leemhuis.info>
Date: Sun Jan 17 16:03:04 2016 +0100
hwmon: (dell-smm) Blacklist Dell Studio XPS 8000
commit 6220f4ebd7b4db499238c2dc91268a9c473fd01c upstream.
Since Linux 4.0 the CPU fan speed is going up and down on Dell Studio
XPS 8000 and 8100 for unknown reasons. The 8100 was already
blacklisted in commit a4b45b25f18d ("hwmon: (dell-smm) Blacklist
Dell Studio XPS 8100"). This patch blacklists the XPS 8000.
Without further debugging on the affected machine, it is not possible
to find the problem. For more details see
https://bugzilla.kernel.org/show_bug.cgi?id=100121
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27f356149d599d1ee55318641f9d3ed69e66174a
Author: Chen Yu <yu.c.chen@intel.com>
Date: Fri Oct 30 16:32:10 2015 +0800
Thermal: do thermal zone update after a cooling device registered
commit 4511f7166a2deb5f7a578cf87fd2fe1ae83527e3 upstream.
When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.
This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.
Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a67208e94d945ad890f8dc4734ec5fdb3219cc03
Author: Zhang Rui <rui.zhang@intel.com>
Date: Fri Oct 30 16:31:58 2015 +0800
Thermal: handle thermal zone device properly during system sleep
commit ff140fea847e1c2002a220571ab106c2456ed252 upstream.
Current thermal code does not handle system sleep well because
1. the cooling device cooling state may be changed during suspend
2. the previous temperature reading becomes invalid after resumed because
it is got before system sleep
3. updating thermal zone device during suspending/resuming
is wrong because some devices may have already been suspended
or may have not been resumed.
Thus, the proper way to do this is to cancel all thermal zone
device update requirements during suspend/resume, and after all
the devices have been resumed, reset and update every registered
thermal zone devices.
This also fixes a regression introduced by:
Commit 19593a1fb1f6 ("ACPI / fan: convert to platform driver")
Because, with above commit applied, all the fan devices are attached
to the acpi_general_pm_domain, and they are turned on by the pm_domain
automatically after resume, without the awareness of thermal core.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Tested-by: Matthias <morpheusxyz123@yahoo.de>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 774ac8b7eff69e0786970157de2157e68b22f456
Author: Zhang Rui <rui.zhang@intel.com>
Date: Fri Oct 30 16:31:47 2015 +0800
Thermal: initialize thermal zone device correctly
commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461 upstream.
After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().
Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Tested-by: Matthias <morpheusxyz123@yahoo.de>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f59395e47008b7a6fafbf56b657222c57b1a92a
Author: Leon Romanovsky <leonro@mellanox.com>
Date: Thu Jan 14 08:11:40 2016 +0200
IB/mlx5: Expose correct maximum number of CQE capacity
commit 9f17768611ebf81dfac69948dd12622b6f2e45fc upstream.
Maximum number of EQE capacity per CQ was mistakenly exposed
as CQE. Fix that.
Fixes: 938fe83c8dcb ("net/mlx5_core: New device capabilities handling")
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e759d3185f48fbeb6e4e3f741120c7689741decd
Author: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
Date: Mon Jan 11 12:57:25 2016 -0500
IB/qib: Support creating qps with GFP_NOIO flag
commit fbbeb8632bf0b46ab44cfcedc4654cd7831b7161 upstream.
The current code is problematic when the QP creation and ipoib is used to
support NFS and NFS desires to do IO for paging purposes. In that case, the
GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory
situations.
This fix adds support to create queue pair with GFP_NOIO flag for connected
mode only to cleanly fail the create queue pair in those situations.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7bf68a0afc0f367118ac765081f19c8cfd93823f
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date: Thu Jan 7 16:44:10 2016 -0500
IB/qib: fix mcast detach when qp not attached
commit 09dc9cd6528f5b52bcbd3292a6312e762c85260f upstream.
The code produces the following trace:
[1750924.419007] general protection fault: 0000 [#3] SMP
[1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4
dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd
scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc
ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib
mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core
ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core
[1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D
3.13.0-39-generic #66-Ubuntu
[1750924.420364] Hardware name: Dell Computer Corporation PowerEdge
860/0XM089, BIOS A04 07/24/2007
[1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti:
ffff88007af1c000
[1750924.420364] RIP: 0010:[<ffffffffa0131d51>] [<ffffffffa0131d51>]
qib_mcast_qp_free+0x11/0x50 [ib_qib]
[1750924.420364] RSP: 0018:ffff88007af1dd70 EFLAGS: 00010246
[1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX:
000000000000000f
[1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI:
6764697200000000
[1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09:
0000000000000000
[1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12:
ffff88007baa1d98
[1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15:
0000000000000000
[1750924.420364] FS: 00007ffff7fd8740(0000) GS:ffff88007fc80000(0000)
knlGS:0000000000000000
[1750924.420364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4:
00000000000007e0
[1750924.420364] Stack:
[1750924.420364] ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429
000000007af1de20
[1750924.420364] ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70
ffffffffa00cb313
[1750924.420364] 00007fffffffde88 0000000000000000 0000000000000008
ffff88003ecab000
[1750924.420364] Call Trace:
[1750924.420364] [<ffffffffa0132429>] qib_multicast_detach+0x1e9/0x350
[ib_qib]
[1750924.568035] [<ffffffffa00cb313>] ? ib_uverbs_modify_qp+0x323/0x3d0
[ib_uverbs]
[1750924.568035] [<ffffffffa0092d61>] ib_detach_mcast+0x31/0x50 [ib_core]
[1750924.568035] [<ffffffffa00cc213>] ib_uverbs_detach_mcast+0x93/0x170
[ib_uverbs]
[1750924.568035] [<ffffffffa00c61f6>] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs]
[1750924.568035] [<ffffffff81312e68>] ? apparmor_file_permission+0x18/0x20
[1750924.568035] [<ffffffff812d4cd3>] ? security_file_permission+0x23/0xa0
[1750924.568035] [<ffffffff811bd214>] vfs_write+0xb4/0x1f0
[1750924.568035] [<ffffffff811bdc49>] SyS_write+0x49/0xa0
[1750924.568035] [<ffffffff8172f7ed>] system_call_fastpath+0x1a/0x1f
[1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f
84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10
<f0> ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f
[1750924.568035] RIP [<ffffffffa0131d51>] qib_mcast_qp_free+0x11/0x50
[ib_qib]
[1750924.568035] RSP <ffff88007af1dd70>
[1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ]
The fix is to note the qib_mcast_qp that was found. If none is found, then
return EINVAL indicating the error.
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e97bff5116d8ba6a25848691063d3370b939a4af
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Fri Jan 1 13:17:46 2016 +0100
IB/cm: Fix a recently introduced deadlock
commit 4bfdf635c668869c69fd18ece37ec66fb6f38fcf upstream.
ib_send_cm_drep() calls cm_enter_timewait() while holding a spinlock
that can be locked from inside an interrupt handler. Hence do not
enable interrupts inside cm_enter_timewait() if called with interrupts
disabled.
This patch fixes e.g. the following deadlock:
Acked-by: Erez Shitrit <erezsh@mellanox.com>
=================================
[ INFO: inconsistent lock state ]
4.4.0-rc7+ #1 Tainted: G E
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/8/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&cm_id_priv->lock)->rlock){?.+...}, at: [<ffffffffa036eec4>] cm_establish+0x
74/0x1b0 [ib_cm]
{HARDIRQ-ON-W} state was registered at:
[<ffffffff810a3c11>] mark_held_locks+0x71/0x90
[<ffffffff810a3e87>] trace_hardirqs_on_caller+0xa7/0x1c0
[<ffffffff810a3fad>] trace_hardirqs_on+0xd/0x10
[<ffffffff8151c40b>] _raw_spin_unlock_irq+0x2b/0x40
[<ffffffffa036ea8e>] cm_enter_timewait+0xae/0x100 [ib_cm]
[<ffffffffa036ff76>] ib_send_cm_drep+0xb6/0x190 [ib_cm]
[<ffffffffa052ed08>] srp_cm_handler+0x128/0x1a0 [ib_srp]
[<ffffffffa0370340>] cm_process_work+0x20/0xf0 [ib_cm]
[<ffffffffa0371335>] cm_dreq_handler+0x135/0x2c0 [ib_cm]
[<ffffffffa03733c5>] cm_work_handler+0x75/0xd0 [ib_cm]
[<ffffffff8107184d>] process_one_work+0x1bd/0x460
[<ffffffff81073148>] worker_thread+0x118/0x420
[<ffffffff81078454>] kthread+0xe4/0x100
[<ffffffff8151cbbf>] ret_from_fork+0x3f/0x70
irq event stamp: 1672286
hardirqs last enabled at (1672283): [<ffffffff81408ec0>] poll_idle+0x10/0x80
hardirqs last disabled at (1672284): [<ffffffff8151d304>] common_interrupt+0x84/0x89
softirqs last enabled at (1672286): [<ffffffff8105b4dc>] _local_bh_enable+0x1c/0x50
softirqs last disabled at (1672285): [<ffffffff8105b697>] irq_enter+0x47/0x70
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&cm_id_priv->lock)->rlock);
<Interrupt>
lock(&(&cm_id_priv->lock)->rlock);
*** DEADLOCK ***
no locks held by swapper/8/0.
stack backtrace:
CPU: 8 PID: 0 Comm: swapper/8 Tainted: G E 4.4.0-rc7+ #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014
ffff88045af5e950 ffff88046e503a88 ffffffff81251c1b 0000000000000007
0000000000000006 0000000000000003 ffff88045af5ddc0 ffff88046e503ad8
ffffffff810a32f4 0000000000000000 0000000000000000 0000000000000001
Call Trace:
<IRQ> [<ffffffff81251c1b>] dump_stack+0x4f/0x74
[<ffffffff810a32f4>] print_usage_bug+0x184/0x190
[<ffffffff810a36e2>] mark_lock_irq+0xf2/0x290
[<ffffffff810a3995>] mark_lock+0x115/0x1b0
[<ffffffff810a3b8c>] mark_irqflags+0x15c/0x170
[<ffffffff810a4fef>] __lock_acquire+0x1ef/0x560
[<ffffffff810a53c2>] lock_acquire+0x62/0x80
[<ffffffff8151bd33>] _raw_spin_lock_irqsave+0x43/0x60
[<ffffffffa036eec4>] cm_establish+0x74/0x1b0 [ib_cm]
[<ffffffffa036f031>] ib_cm_notify+0x31/0x100 [ib_cm]
[<ffffffffa0637f24>] srpt_qp_event+0x54/0xd0 [ib_srpt]
[<ffffffffa0196052>] mlx4_ib_qp_event+0x72/0xc0 [mlx4_ib]
[<ffffffffa00775b9>] mlx4_qp_event+0x69/0xd0 [mlx4_core]
[<ffffffffa006000e>] mlx4_eq_int+0x51e/0xd50 [mlx4_core]
[<ffffffffa006084f>] mlx4_msi_x_interrupt+0xf/0x20 [mlx4_core]
[<ffffffff810b67b0>] handle_irq_event_percpu+0x40/0x110
[<ffffffff810b68bf>] handle_irq_event+0x3f/0x70
[<ffffffff810ba7f9>] handle_edge_irq+0x79/0x120
[<ffffffff81007f3d>] handle_irq+0x5d/0x130
[<ffffffff810071fd>] do_IRQ+0x6d/0x130
[<ffffffff8151d309>] common_interrupt+0x89/0x89
<EOI> [<ffffffff8140895f>] cpuidle_enter_state+0xcf/0x200
[<ffffffff81408aa2>] cpuidle_enter+0x12/0x20
[<ffffffff810990d6>] call_cpuidle+0x36/0x60
[<ffffffff81099163>] cpuidle_idle_call+0x63/0x110
[<ffffffff8109930a>] cpu_idle_loop+0xfa/0x130
[<ffffffff8109934e>] cpu_startup_entry+0xe/0x10
[<ffffffff8103c443>] start_secondary+0x83/0x90
Fixes: commit be4b499323bf ("IB/cm: Do not queue work to a device that's going away")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 556dfd8dae7d66b35121ffa8198465e55a34d64d
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed Feb 10 15:59:42 2016 +0200
dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer
commit ee1cdcdae59563535485a5f56ee72c894ab7d7ad upstream.
The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
re-enabled BLOCK interrupts with regard to make cyclic transfers work. However,
this change becomes a regression for non-cyclic transfers as interrupt counters
under stress test had been grown enormously (approximately per 4-5 bytes in the
UART loop back test).
Taking into consideration above enable BLOCK interrupts if and only if channel
is programmed to perform cyclic transfer.
Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mans Rullgard <mans@mansr.com>
Tested-by: Mans Rullgard <mans@mansr.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4fa3d6f9e84d5009d78c732a0a81251b8bfe0b4
Author: Songjun Wu <songjun.wu@atmel.com>
Date: Mon Jan 18 11:14:44 2016 +0100
dmaengine: at_xdmac: fix resume for cyclic transfers
commit 611dcadb01c89d1d3521450c05a4ded332e5a32d upstream.
When having cyclic transfers, the channel was paused when performing
suspend but was not correctly resumed.
Signed-off-by: Songjun Wu <songjun.wu@atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ed338d4a9f58d88cd9fda055425bc6e0b8f3865
Author: Mans Rullgard <mans@mansr.com>
Date: Mon Jan 11 13:04:29 2016 +0000
dmaengine: dw: fix cyclic transfer callbacks
commit 2895b2cad6e7a95104cf396e5330054453382ae1 upstream.
Cyclic transfer callbacks rely on block completion interrupts which were
disabled in commit ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block
interrupts"). This re-enables block interrupts so the cyclic callbacks
can work. Other transfer types are not affected as they set the INT_EN
bit only on the last block.
Fixes: ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts")
Signed-off-by: Mans Rullgard <mans@mansr.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f29e5445382110d6801fedaa9b0582c00beccc8
Author: Mans Rullgard <mans@mansr.com>
Date: Mon Jan 11 13:04:28 2016 +0000
dmaengine: dw: fix cyclic transfer setup
commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 upstream.
Commit 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and
chan_cfg register on resume") moved some channel initialisation to
a new function which must be called before starting a transfer.
This updates dw_dma_cyclic_start() to use dwc_dostart() like the other
modes, thus ensuring dwc_initialize() gets called and removing some code
duplication.
Fixes: 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume")
Signed-off-by: Mans Rullgard <mans@mansr.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ef1fb7d12ac8863557390ead966566ed3477b023
Author: Dan Williams <dan.j.williams@intel.com>
Date: Thu Feb 4 16:51:00 2016 -0800
nfit: fix multi-interface dimm handling, acpi6.1 compatibility
commit 6697b2cf69d4363266ca47eaebc49ef13dabc1c9 upstream.
ACPI 6.1 clarified that multi-interface dimms require multiple control
region entries (DCRs) per dimm. Previously we were assuming that a
control region is only present when block-data-windows are present.
This implementation was done with an eye to be compatibility with the
looser ACPI 6.0 interpretation of this table.
1/ When coalescing the memory device (MEMDEV) tables for a single dimm,
coalesce on device_handle rather than control region index.
2/ Whenever we disocver a control region with non-zero block windows
re-scan for block-data-window (BDW) entries.
We may need to revisit this if a DIMM ever implements a format interface
outside of blk or pmem, but that is not on the foreseeable horizon.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5066e4475fe82ba77afd521bf373c7ee8faac0c8
Author: Insu Yun <wuninsu@gmail.com>
Date: Sat Jan 23 15:44:19 2016 -0500
ACPI / PCI / hotplug: unlock in error path in acpiphp_enable_slot()
commit 2c3033a0664dfae91e1dee7fabac10f24354b958 upstream.
In acpiphp_enable_slot(), there is a missing unlock path
when error occurred. It needs to be unlocked before returning
an error.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eac1122b727753dd6ea32a852d926f228ace6f66
Author: Hans de Goede <hdegoede@redhat.com>
Date: Fri Jan 22 11:41:05 2016 +0100
ACPI: Revert "ACPI / video: Add Dell Inspiron 5737 to the blacklist"
commit b186b4dcb79b1914c3dadb27ac72dafaa4267998 upstream.
The quirk to get "acpi_backlight=vendor" behavior by default on the
Dell Inspiron 5737 was added before we started doing
"acpi_backlight=native" by default on Win8 ready machines.
Since we now avoid using acpi-video as backlight driver on these machines
by default (using the native driver instead) we no longer need this quirk.
Moreover the vendor driver does not work after a suspend/resume where
as the native driver does.
This reverts commit 08a56226d847 (ACPI / video: Add Dell Inspiron 5737
to the blacklist).
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111061
Reported-and-tested-by: erusan@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8b819bf125bb410e265275f9660d98986a9fa802
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Jan 14 14:24:39 2016 +0100
ACPI / video: Add disable_backlight_sysfs_if quirk for the Toshiba Satellite R830
commit b21f2e81bd3fd8ed260590e72901254bca2193cd upstream.
The Toshiba Satellite R830 needs disable_backlight_sysfs_if=1, just like
the Toshiba Portege R830. Add a quirk for this.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Tested-by: To Do <entodoays@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e85dc751231a3b8853e9983363521bdb17f31271
Author: Hans de Goede <hdegoede@redhat.com>
Date: Mon Jan 11 14:46:17 2016 +0100
ACPI / video: Add disable_backlight_sysfs_if quirk for the Toshiba Portege R700
commit de588b8ff057d4de0751f337b930f90ca522bab2 upstream.
The Toshiba Portege R700 needs disable_backlight_sysfs_if=1, just like
the Toshiba Portege R830. Add a quirk for this.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Tested-by: Emma Reisz <emmareisz@outlook.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 96ee50f3b366a0b547dfac776a43af15ccc322e0
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Jan 13 23:24:02 2016 +0100
lib: sw842: select crc32
commit 5b57167749274961baf15ed1f05a4996b3ab0487 upstream.
The sw842 library code was merged in linux-4.1 and causes a very rare randconfig
failure when CONFIG_CRC32 is not set:
lib/built-in.o: In function `sw842_compress':
oid_registry.c:(.text+0x12ddc): undefined reference to `crc32_be'
lib/built-in.o: In function `sw842_decompress':
oid_registry.c:(.text+0x137e4): undefined reference to `crc32_be'
This adds an explict 'select CRC32' statement, similar to what the other users
of the crc32 code have. In practice, CRC32 is always enabled anyway because
over 100 other symbols select it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 2da572c959dd ("lib: add software 842 compression/decompression")
Acked-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7712c014b16f64d344239b190ea9c126123cb14f
Author: Mike Frysinger <vapier@gentoo.org>
Date: Sun Jan 10 20:14:11 2016 -0500
uapi: update install list after nvme.h rename
commit a9cf8284b45110a4d98aea180a89c857e53bf850 upstream.
Commit 9d99a8dda154 ("nvme: move hardware structures out of the uapi
version of nvme.h") renamed nvme.h to nvme_ioctl.h, but the uapi list
still refers to nvme.h. People trying to install the headers hit a
failure as the header no longer exists.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 906bf4dd14c187ee258961a8f0723e4820bfd084
Author: Josh Boyer <jwboyer@fedoraproject.org>
Date: Sun Jan 24 10:46:42 2016 -0500
ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list
commit 6b31de3e698582fe0b8f7f4bab15831b73204800 upstream.
Like the Yoga 900 models the Lenovo Yoga 700 does not have a
hw rfkill switch, and trying to read the hw rfkill switch through the
ideapad module causes it to always reported blocking breaking wifi.
This commit adds the Lenovo Yoga 700 to the no_hw_rfkill dmi list, fixing
the wifi breakage.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1295272
Tested-by: <dinyar.rabady+spam@gmail.com>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d065375e5a40ef7722d2d0ae59d4034938b8e0a
Author: Josh Boyer <jwboyer@fedoraproject.org>
Date: Wed Dec 9 21:12:52 2015 -0500
ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list
commit edde316acb5f07c04abf09a92f59db5d2efd14e2 upstream.
One of the newest ideapad models also lacks a physical hw rfkill switch,
and trying to read the hw rfkill switch through the ideapad module
causes it to always reported blocking breaking wifi.
Fix it by adding this model to the DMI list.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3fb82079c460f979ff99b3e033442e9a948a37f
Author: Azael Avalos <coproscefalo@gmail.com>
Date: Sun Nov 15 20:32:47 2015 -0700
toshiba_acpi: Fix blank screen at boot if transflective backlight is supported
commit bae5336f0aaedffa115dab9cb3d8a4e4aed3a26a upstream.
If transflective backlight is supported and the brightness is zero
(lowest brightness level), the set_lcd_brightness function will activate
the transflective backlight, making the LCD appear to be turned off.
This patch fixes the issue by incrementing the brightness level, and
by doing so, avoiding the activation of the tranflective backlight.
Reported-and-tested-by: Fabian Koester <fabian.koester@bringnow.com>
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bcb1875a069043c70af27dc9f0f5e075a09d76b1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri Jan 22 18:08:52 2016 -0500
make sure that freeing shmem fast symlinks is RCU-delayed
commit 3ed47db34f480df7caf44436e3e63e555351ae9a upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a83b349814dee660caff0a40a22ac2f166c94a8b
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Feb 19 18:05:10 2016 -0500
drm/radeon/pm: adjust display configuration after powerstate
commit 39d4275058baf53e89203407bf3841ff2c74fa32 upstream.
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a72eb45c3342c56bebe9c81c931f0431b71e7a32
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 19 02:06:38 2016 +0100
drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)
commit 2b8341b3f917c108b47f6a8a771a40d226c57883 upstream.
This fixes a regression introduced in Linux 4.4.
Limit the amount of time radeon_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of radeon_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. radeon_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit 5b5561b3660d ("drm/radeon: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
v2: Skip wait immediately if !radeon_crtc->enabled, as
suggested by Michel.
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcf9ef2709b728f6c591d51c5bbf745df319a139
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 12 20:30:30 2016 +0100
drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)
commit bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.
This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.
v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit cd19e52aee922
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.
Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 439c9942ce4f0ced30e24f4864d8b2209215521b
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 12 20:30:29 2016 +0100
drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4
commit c61934ed9a0e3911a9935df26858726a7ec35ec0 upstream.
Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.
This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.
This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.
Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f84d997be26c01ccb6965d802c919987ce85161
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 12 20:30:28 2016 +0100
drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2)
commit 99b8e71597fadd6b2ac85e6e10f221f79dd9c1c1 upstream.
This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:
Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be active at the moment,
as the current implementation of the timestamp caching and updating is
not safe against concurrent readers for calls to store_vblank() with a
bump of anything but +1. A bump != 1 would very likely return corrupted
timestamps to userspace, because the same slot in the cache could
be concurrently written by store_vblank() and read by one of those
readers in a non-atomic fashion and without the read-retry logic
detecting this collision.
Concurrent readers can exist while drm_update_vblank_count() is called
from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
irq callers. However, all those calls are happening with the vbl_lock
locked thereby preventing a drm_vblank_get(), so the vblank refcount
can't increase while drm_update_vblank_count() is executing. Therefore
a zero vblank refcount during execution of that function signals that
is safe for arbitrary counter bumps if called from outside vblank irq,
whereas a non-zero count is not safe.
Whenever the function is called from vblank irq, we have to assume concurrent
readers could show up any time during its execution, even if the refcount
is currently zero, as vblank irqs are usually only enabled due to the
presence of readers, and because when it is called from vblank irq it
can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
Therefore also restrict bumps to +1 when the function is called from vblank
irq.
Such bumps of more than +1 can happen at other times than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.
A better solution would be to rewrite the timestamp caching to use
full seqlocks to allow concurrent writes and reads for arbitrary
vblank counter increments.
v2: Add code comment that this is essentially a hack and should
be replaced by a full seqlock implementation for caching of
timestamps.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
commit 57c0829490bffc6a8488dbd4da3903e902b3ded3
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 12 20:30:27 2016 +0100
drm: No-Op redundant calls to drm_vblank_off() (v2)
commit e8235891b33799d597ff4ab5e45afe173a65da30 upstream.
Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.
At least with the legacy drm helpers it is not unusual to
get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
were observed on radeon-kms during dpms-off -> dpms-on transition.
We don't no-op calls from atomic modesetting drivers, as they
should do a proper job of tracking hw state.
Fixes large jumps of the software maintained vblank counter due to
the hardware vblank counter resetting to zero during dpms off or
modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
instead of drm_vblank_pre/post_modeset().
This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.
v2: Don't no-op on atomic modesetting drivers, per suggestion
of Daniel Vetter.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 96e87f46f186b51e246fece96aa18ae39d535a98
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Mon Feb 15 19:41:47 2016 +0100
drm/radeon: use post-decrement in error handling
commit bc3f5d8c4ca01555820617eb3b6c0857e4df710d upstream.
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b78bd121b4978a8378c8300e0fb2e12c88a05a85
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: Tue Feb 16 14:25:00 2016 +0100
drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command
commit 34855706c30d52b0a744da44348b5d1cc39fbe51 upstream.
This avoids integer overflows on 32bit machines when calculating
reloc_info size, as reported by Alan Cox.
Cc: gnomes@lxorguk.ukuu.org.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f44b766c9b773b43e073259933f78d505badcc1
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Tue Feb 9 21:11:13 2016 +0100
drm/i915: fix error path in intel_setup_gmbus()
commit ed3f9fd1e865975ceefdb2a43b453e090b1fd787 upstream.
This fails to undo the setup for pin==0; moreover, something
interesting happens if the setup failed already at pin==0.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
(cherry picked from commit 2417c8c03f508841b85bf61acc91836b7b0e2560)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 222d0fa4e86370e58e6d4f2e2cf02d76d4003992
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Feb 4 12:50:50 2016 +0200
drm/i915/dsi: don't pass arbitrary data to sideband
commit 26f6f2d301c1fb46acb1138ee155125815239b0d upstream.
Since sequence block v2 the second byte contains flags other than just
pull up/down. Don't pass arbitrary data to the sideband interface.
The rest may or may not work for sequence block v2, but there should be
no harm done.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/ebe3c2eee623afc4b3a134533b01f8d591d13f32.1454582914.git.jani.nikula@intel.com
(cherry picked from commit 4e1c63e3761b84ec7d87c75b58bbc8bcf18e98ee)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a35478f900a01650f00e39423722956d04daedd
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Feb 4 12:50:49 2016 +0200
drm/i915/dsi: defend gpio table against out of bounds access
commit 4db3a2448ec8902310acb78de39b6227a9a56ac8 upstream.
Do not blindly trust the VBT data used for indexing.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cc32d40c2b47f2d2151811855ac2c3dabab1d57d.1454582914.git.jani.nikula@intel.com
(cherry picked from commit 5d2d0a12d3d08bf50434f0b5947bb73bac04b941)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f1e7d5f8f6b3f21db1423e15167e4350bd959d7
Author: Lyude <cpaul@redhat.com>
Date: Tue Feb 2 10:49:43 2016 -0500
drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
commit 3d849b02336be103d312c1574d6f7314d5c0bc9f upstream.
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
result we skip assigning a DPLL to any DP MST ports, which makes link
training fail:
[ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
[ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
[ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
[ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
[ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
[ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000
[ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
[ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
[ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000
[ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
…
[ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
[ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting
After which the pipe state goes completely out of sync:
[ 70.075596] [drm:check_crtc_state] [CRTC:25]
[ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
[ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
[ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
[ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
[ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
[ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
[ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)
And if you're especially lucky, it keeps going downhill:
[ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
[ 83.309265]
[ 83.309265] =================================
[ 83.309266] [ INFO: inconsistent lock state ]
[ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
[ 83.309267] ---------------------------------
[ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
[ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
[ 83.309293] {IN-HARDIRQ-W} state was registered at:
[ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
[ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0
[ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
[ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
[ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
[ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
[ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60
[ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130
[ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120
[ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120
[ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20
[ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
[ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20
[ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
[ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
[ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140
[ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482
[ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
[ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a
Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming")
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 78385cb398748debb7ea2e36d6d2001830c172bc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit feba77fdca12991dc953c133fda6524b086df87c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jan 15 20:46:53 2016 +0200
drm/i915: Don't reject primary plane windowing with color keying enabled on SKL+
commit 6f94b6dd006909a5ef6435cc0af557e945240f48 upstream.
On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logic.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 061e4b8d650a ("drm/i915: clean up atomic plane check functions, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit 693bdc28a733dba68b86af295e7509812fec35d9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6de4682d2845d6aa8883ae62e3ed1b2f915df4e8
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Jan 13 16:35:20 2016 +0200
drm/i915/dp: fall back to 18 bpp when sink capability is unknown
commit 5efd407674068dede403551bea3b0b134c32513a upstream.
Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.
The clamping has been HDMI specific since its introduction in
commit 996a2239f93b03c5972923f04b097f65565c5bed
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 19 11:24:34 2013 +0200
drm/i915: Disable high-bpc on pre-1.4 EDID screens
Reported-and-tested-by: Dihan Wickremasuriya <nayomal@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f39741673c3d54bc84ec30b4e1d21daa75bbcb02
Author: Francisco Jerez <currojerez@riseup.net>
Date: Wed Jan 13 18:59:39 2016 -0800
drm/i915: Make sure DC writes are coherent on flush.
commit 935a0ff0e1ea62a116848c0a187b13838f7b9cee upstream.
We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
that writes performed via the HDC are visible in memory. Fixes an
intermittent failure in a Piglit test that writes to a BO from a
shader using GL atomic counters (implemented as HDC untyped atomics)
and then expects the memory to read back the same value after mapping
it on the CPU.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
Tested-by: Mark Janes <mark.a.janes@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452740379-3194-1-git-send-email-currojerez@riseup.net
(cherry picked from commit 965fd602a6436f689f4f2fe40a6789582778ccd5)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 741598a5bce0a7bb07006cfbcd8044a3c7b91c31
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jan 13 11:55:28 2016 +0100
drm/i915: Init power domains early in driver load
commit f5949141a21ee16edf1beaf95cbae7e419171ab5 upstream.
Since
commit ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).
v4: Ville instead suggested to move gmbus setup later in the sequence,
since it's only needed by the modeset code.
v5: Move even close to the actual user, right next to the comment that
states where we really need gmbus (and interrupts!).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 82ed1aba70ce938097629c41f316826e0a715865
Author: Lyude <cpaul@redhat.com>
Date: Thu Jan 7 10:43:28 2016 -0500
drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
commit 2dc2f761dea65069485110d24eaa5b0d5d808b07 upstream.
This fixes reprobing of display connectors on resume. After some
talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on
resume hasn't been working (this was observed on a T440s):
- We call hpd_init()
- We check each connector for a couple of things before marking
connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
active encoder. Of course, a disconnected port won't have an
active encoder, so we don't add the flag to any of the
connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
so we skip reprobing each connector except that one.
In addition, we also now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
handled by the mst helpers. This is probably what was originally
intended to happen here.
Changes since V1:
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a
check for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
Changes since V2:
* Put patch changelog above Signed-off-by
* Follow Daniel Vetter's suggestion for making the code here a bit more
legible
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Signed-off-by: Lyude <cpaul@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 07c519134417d92c2e1a536e2b66d4ffff4b3be0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 383652ce4ab5504e57fb2ec82cb6eb799cf68db1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Nov 27 13:28:55 2015 +0000
drm/i915: Restore inhibiting the load of the default context
commit 06ef83a705a98da63797a5a570220b6ca36febd4 upstream.
Following a GPU reset, we may leave the context in a poorly defined
state, and reloading from that context will leave the GPU flummoxed. For
secondary contexts, this will lead to that context being banned - but
currently it is also causing the default context to become banned,
leading to turmoil in the shared state.
This is a regression from
commit 6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b [v4.1]
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Mon Mar 16 16:00:58 2015 +0000
drm/i915: Initialize all contexts
which quietly introduced the removal of the MI_RESTORE_INHIBIT on the
default context.
v2: Mark the global default context as uninitialized on GPU reset so
that the context-local workarounds are reloaded upon re-enabling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: This seems to fix a gpu hand on after the first resume,
resulting in any future suspend operation failing with -EIO because
the gpu seems to be in a funky state. Somehow this patch fixes that.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 42f1cae8c079bcceb3cff079fddc3ff8852c788f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de2e68f48bc441cb59b7190b2f53793359ce220c
Author: Insu Yun <wuninsu@gmail.com>
Date: Mon Feb 1 11:08:29 2016 -0500
drm: fix missing reference counting decrease
commit dabe19540af9e563d526113bb102e1b9b9fa73f9 upstream.
In drm_dp_mst_allocate_vcpi, it returns true in two paths,
but in one path, there is no reference couting decrease.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bd4419f7ee1978a1dba107a0f112b797b024ce1d
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date: Fri Feb 5 14:35:53 2016 -0500
drm/radeon: hold reference to fences in radeon_sa_bo_new
commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.
An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.
Based on the analogous fix for amdgpu.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9bf88217c3e18f28482921ad7902ffa178163126
Author: Oded Gabbay <oded.gabbay@gmail.com>
Date: Sat Jan 30 07:59:33 2016 +0200
drm/radeon: mask out WC from BO on unsupported arches
commit c5244987394648913ae1a03879c58058a2fc2cee upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4eb8334b571b1633b5df06cd56f2e665e8e19da
Author: Dave Airlie <airlied@redhat.com>
Date: Sat Jan 30 07:59:32 2016 +0200
drm: add helper to check for wc memory support
commit 4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac6f949bbbd922f5d16fea936522bef7663971ea
Author: Slava Grigorev <slava.grigorev@amd.com>
Date: Tue Jan 26 17:35:57 2016 -0500
drm/radeon: fix DP audio support for APU with DCE4.1 display engine
commit fe6fc1f132b4300c1f6defd43a5d673eb60a820d upstream.
Properly setup the DFS divider for DP audio for DCE4.1.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c38554e8df027f43558b59f6f1205c63b1fdff4a
Author: Slava Grigorev <slava.grigorev@amd.com>
Date: Tue Jan 26 16:56:25 2016 -0500
drm/radeon: Add a common function for DFS handling
commit a64c9dab1c4d05c87ec8a1cb9b48915816462143 upstream.
Move encoding of DFS (digital frequency synthesizer) divider into a
separate function and improve calculation precision.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3bbb4a052d9a891e529c2a54f1782b03b3441aa2
Author: Slava Grigorev <slava.grigorev@amd.com>
Date: Tue Jan 26 16:45:10 2016 -0500
drm/radeon: cleaned up VCO output settings for DP audio
commit c9a392eac18409f51a071520cf508c0b4ad990e2 upstream.
This is preparation for the fixes in the following patches.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 46414c46e79de89588afbbd58f4df16ee4857ed8
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Jan 22 00:13:15 2016 -0500
drm/radeon: properly byte swap vce firmware setup
commit cc78eb22885bba64445cde438ba098de0104920f upstream.
Firmware is LE. Need to properly byteswap some of the fields
so they are interpreted correctly by the driver on BE systems.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 557761e927e79011ce59f07f91e7a0a58788ea62
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Thu Dec 17 12:52:17 2015 -0500
drm/radeon: clean up fujitsu quirks
commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 upstream.
Combine the two quirks.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=109481
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f4e77b9e3fc1a2c6a2908e107c90553fe265c19
Author: Slava Grigorev <slava.grigorev@amd.com>
Date: Thu Dec 17 11:09:58 2015 -0500
drm/radeon: Fix "slow" audio over DP on DCE8+
commit ac4a9350abddc51ccb897abf0d9f3fd592b97e0b upstream.
DP audio is derived from the dfs clock.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b36e52c44ce6728824546d8b5f05b844cede96f1
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Nov 24 14:32:44 2015 -0500
drm/radeon: call hpd_irq_event on resume
commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 upstream.
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7d124d8895ec1345b565f7872e0dbe33b51b1c0f
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date: Mon Nov 23 17:39:11 2015 -0500
drm/radeon: Fix off-by-one errors in radeon_vm_bo_set_addr
commit 42ef344c0994cc453477afdc7a8eadc578ed0257 upstream.
eoffset is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range. Also fixed related errors when checking the VA limit and in
radeon_vm_fence_pts.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 381e33c23c0acc1eb64fb1fe3a245b72da9484ea
Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
Date: Wed Jan 27 09:39:36 2016 -0500
drm/dp/mst: deallocate payload on port destruction
commit 91a25e463130c8e19bdb42f2d827836c7937992e upstream.
This is needed to properly deallocate port payload
after downstream branch get unplugged.
In order to do this unplugged MST topology should
be preserved, to find first alive port on path to
unplugged MST topology, and send payload deallocation
request to branch device of found port.
For this mstb and port kref's are used in reversed
order to track when port and branch memory could be
freed.
Added additional functions to find appropriate mstb
as described above.
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a252d13f411ff3dc7697da09a991f1a4a7065d23
Author: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Date: Fri Jan 22 17:07:29 2016 -0500
drm/dp/mst: Reverse order of MST enable and clearing VC payload table.
commit c175cd16df272119534058f28cbd5eeac6ff2d24 upstream.
On DELL U3014 if you clear the table before enabling MST it sometimes
hangs the receiver.
Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ad9421d86ecd22e8bd9eddbca2ac93980a7b836e
Author: Hersen Wu <hersenxs.wu@amd.com>
Date: Fri Jan 22 17:07:28 2016 -0500
drm/dp/mst: move GUID storage from mgr, port to only mst branch
commit 5e93b8208d3c419b515fb75e2601931c027e12ab upstream.
Previous implementation does not handle case below: boot up one MST branch
to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output
of 1st MST, GUID is not created for 2nd MST branch. When downstream port of
2nd MST branch send upstream request, it fails because 2nd MST branch GUID
is not available.
New Implementation: only create GUID for MST branch and save it within Branch.
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6cd43e68d937462d063fae86be892ec10125e545
Author: Harry Wentland <harry.wentland@amd.com>
Date: Fri Jan 22 17:07:26 2016 -0500
drm/dp/mst: Calculate MST PBN with 31.32 fixed point
commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 upstream.
Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.
This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b870070037823bea90709ea6b4b8a2c8ffcdc5f5
Author: Harry Wentland <harry.wentland@amd.com>
Date: Fri Jan 22 17:07:25 2016 -0500
drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil
commit 64566b5e767f9bc3161055ca1b443a51afb52aad upstream.
drm_fixp_from_fraction allows us to create a fixed point directly
from a fraction, rather than creating fixed point values and dividing
later. This avoids overflow of our 64 bit value for large numbers.
drm_fixp2int_ceil allows us to return the ceiling of our fixed point
value.
[airlied: squash Jordan's fix]
32-bit-build-fix: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e614c50122b2c2470c6c0c79bcdad43bae8021b
Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
Date: Fri Dec 25 16:14:48 2015 +0800
drm/dp/mst: fix in RAD element access
commit 7a11a334aa6af4c65c6a0d81b60c97fc18673532 upstream.
This is needed to receive correct port
number from RAD, so MSTB could be found
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7b713e9ed440bed2d255aa5d247e40c7a8a3fe1b
Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
Date: Fri Dec 25 16:14:47 2015 +0800
drm/dp/mst: fix in MSTB RAD initialization
commit 75af4c8c4c0f60d7ad135419805798f144e9baf9 upstream.
This fix is needed to support more then two
branch displays, so RAD address consist at
least of 2 elements
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1596315171d84391fcf90d5942231cefaf691cee
Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
Date: Fri Dec 18 17:14:43 2015 -0500
drm/dp/mst: always send reply for UP request
commit 1f16ee7fa13649f4e55aa48ad31c3eb0722a62d3 upstream.
We should always send reply for UP request in order
to make downstream device clean-up resources appropriately.
Issue was that reply for UP request was sent only once.
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9e8a98ebe2e6d2633e79f76e353fef1db1f1bcd
Author: Mykola Lysenko <Mykola.Lysenko@amd.com>
Date: Fri Dec 18 17:14:42 2015 -0500
drm/dp/mst: process broadcast messages correctly
commit bd9343208704fcc70a5b919f228a7d26ae472727 upstream.
In case broadcast message received in UP request,
RAD cannot be used to identify message originator.
Message should be parsed, originator should be found
by GUID from parsed message.
Also reply with broadcast in case broadcast message
received (for now it is always broadcast)
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4323b4dbfc7c02f4dda376088c08e6314ff8e5b1
Author: Thierry Reding <treding@nvidia.com>
Date: Wed Feb 24 18:34:43 2016 +0100
drm/nouveau: platform: Fix deferred probe
commit 870571a5698b2e9d0f4d2e5c6245967b582aab45 upstream.
The error cleanup paths aren't quite correct and will crash upon
deferred probe.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2168fe3d7bfe2738d9095e1ed8eaefea2011686a
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Thu Feb 18 08:14:19 2016 +1000
drm/nouveau/disp/dp: ensure sink is powered up before attempting link training
commit 95664e66fad964c3dd7945d6edfb1d0931844664 upstream.
This can happen under some annoying circumstances, and is a quick fix
until more substantial changes can be made.
Fixed eDP mode changes on (at least) the Lenovo P50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a6976c7be5b193b4efd95fb16b2d8599dd98364e
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 12 20:30:32 2016 +0100
drm/nouveau/display: Enable vblank irqs after display engine is on again.
commit ff683df7bf34f90766a50c7e7454e219aef2710e upstream.
In the display resume path, move the calls to drm_vblank_on()
after the point when the display engine is running again.
Since changes were made to drm_update_vblank_count() in Linux 4.4+
to emulate hw vblank counters via vblank timestamping, the function
drm_vblank_on() now needs working high precision vblank timestamping
and therefore working scanout position queries at time of call.
These don't work before the display engine gets restarted, causing
miscalculation of vblank counter increments and thereby large forward
jumps in vblank count at display resume. These jumps can cause client
hangs on resume, or desktop hangs in the case of composited desktops.
Fix this Linux 4.4 regression by reordering calls accordingly.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 61392a0d006b9a3feae3b3afd36cbe8daca0bce7
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Fri Jan 8 08:56:51 2016 +1000
drm/nouveau/kms: take mode_config mutex in connector hotplug path
commit 0a882cadbc63fd2da3994af7115b4ada2fcbd638 upstream.
fdo#93634
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 32c021915d41a56f58c42b1075238b75894cd29a
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Feb 19 17:55:31 2016 -0500
drm/amdgpu/pm: adjust display configuration after powerstate
commit 8e7cedc6f7fe762ffe6e348502be34b11fa79298 upstream.
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ae4fa0cb5ff9ed89f83cc25a85aff69e0103e05d
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri Feb 19 02:06:39 2016 +0100
drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.
commit e1d09dc0ccc6c91e3916476f636edb76da1f65bb upstream.
This fixes a regression introduced in Linux 4.4.
This is a port of the same fix for radeon-kms in the
patch "drm/radeon: Don't hang in radeon_flip_work_func
on disabled crtc. (v2)"
Limit the amount of time amdgpu_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of amdgpu_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. amdgpu_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit 8e36f9d33c13 ("drm/amdgpu: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
commit 8fb49d08fa1bb7a38545d0e7e7eeb2f8feae31f6
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Mon Feb 15 19:41:45 2016 +0100
drm/amdgpu: use post-decrement in error handling
commit 09ccbb74b6718ad4d1290de3f5669212c0ac7d4b upstream.
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4d6bc4fa3202a28dab7a4c03c22a569b87f98f84
Author: Christian König <christian.koenig@amd.com>
Date: Mon Feb 8 10:57:22 2016 +0100
drm/amdgpu: fix issue with overlapping userptrs
commit cc1de6e800c253172334f8774c419dc64401cd2e upstream.
Otherwise we could try to evict overlapping userptr BOs in get_user_pages(),
leading to a possible circular locking dependency.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a42e7cd29f4c9d59fab1a8e306e21d77f57a0a5
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date: Fri Feb 5 10:59:43 2016 -0500
drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)
commit a8d81b36267366603771431747438d18f32ae2d5 upstream.
An arbitrary amount of time can pass between spin_unlock and
fence_wait_any_timeout, so we need to ensure that nobody frees the
fences from under us.
A stress test (rapidly starting and killing hundreds of glxgears
instances) ran into a deadlock in fence_wait_any_timeout after
about an hour, and this race condition appears to be a plausible
cause.
v2: agd: rebase on upstream
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 978b8b828d357197f4f209c9b3a0337a1a7aa7fd
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date: Fri Feb 5 10:49:50 2016 -0500
drm/amdgpu: remove unnecessary forward declaration
commit b19763d0d867eb863953500a5c87f2fd663863b8 upstream.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 94703402213a01ce0fb0aa4e646cdfc2610f17b5
Author: Flora Cui <Flora.Cui@amd.com>
Date: Thu Feb 4 15:10:08 2016 +0800
drm/amdgpu: fix s4 resume
commit ca19852884c8937eed89560f924f5a34cfcc22af upstream.
No need to re-init asic if it's already been initialized.
Skip IB tests since kernel processes are frozen in thaw.
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4474b85771139f2da8f8f4f443e6fad08081e99e
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 2 16:24:20 2016 -0500
drm/amdgpu: remove exp hardware support from iceland
commit dba280b20bfd1c2bed8a07ce3f75a6da8ba7d247 upstream.
It's working now.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92270
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b8b1ad305f8de05b241a57707d5b3de3692dbdfa
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 2 11:15:41 2016 -0500
drm/amdgpu: don't load MEC2 on topaz
commit 97dde76a30c2e67fa5fb9cb6a4072c0178c9df26 upstream.
Not validated.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73b424c77ce34fe8343c32feae15cc9f3dc82356
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 2 10:57:30 2016 -0500
drm/amdgpu: drop topaz support from gmc8 module
commit 8878d8548ac7fae43cd6d82579f966eb8825e282 upstream.
topaz is actually gmc7.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b840f690ab4a782ec8947d7ab00a57fd5309015
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 2 10:56:15 2016 -0500
drm/amdgpu: pull topaz gmc bits into gmc_v7
commit 72b459c8f716ef03a8a0c78078547ce64d8d29a2 upstream.
Add the topaz golden settings into the gmc7 module.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 321dfc30923a07ac90052af222cb40694d00ab2f
Author: Ken Wang <Qingqing.Wang@amd.com>
Date: Wed Feb 3 19:17:53 2016 +0800
drm/amdgpu: The VI specific EXE bit should only apply to GMC v8.0 above
commit 8f3c162961fc2d92ec73a66496aab69eb2e19c36 upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d60703ca942e8d044d61360bc9792fcab54b95d0
Author: Ken Wang <Qingqing.Wang@amd.com>
Date: Wed Feb 3 19:16:54 2016 +0800
drm/amdgpu: iceland use CI based MC IP
commit 429c45deae6e57f1bb91bfb05b671063fb0cef60 upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 61d1fcfc8258c058af665e2abf6e42636cbd0274
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Feb 2 10:59:53 2016 -0500
drm/amdgpu: move gmc7 support out of CIK dependency
commit e42d85261680edfc350a6c2a86b7fbb44a85014b upstream.
It's used by iceland which is VI.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7710d03fbb6768f0ddc106025210a31035134db5
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Thu Jan 28 16:27:41 2016 -0500
drm/amdgpu: no need to load MC firmware on fiji
commit ad32152eb26043d165eed9406cb9e2f7011f6b10 upstream.
Vbios does this for us on asic_init.
Reviewed-by: Ken Wang >Qingqing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c105b06bc6296ce215b4dc942204bdf82237323
Author: Christian König <christian.koenig@amd.com>
Date: Tue Jan 19 12:48:14 2016 +0100
drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2
commit 78d0e182b6c1f5336f6e8cbb197f403276dabc7f upstream.
We could pin BOs into invisible VRAM otherwise.
v2: make logic more readable as suggested by Michel
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> (v1)
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 17ab2f11145f6e0c9657d098f3dcefd22f9e7478
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Thu Jan 14 13:48:24 2016 -0500
drm/amdgpu: fix tonga smu resume
commit e160e4db833c7e8587ec3c88efaed0d84f1bcf42 upstream.
Need to make sure smu buffers are pinned on resume. This
matches what Fiji does.
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3be127a9622d781ea3239f8846087256df988c79
Author: Chunming Zhou <David1.Zhou@amd.com>
Date: Wed Jan 13 12:55:18 2016 +0800
drm/amdgpu: fix lost sync_to if scheduler is enabled.
commit 888c9e33e4c5a503285921046c621f7c73199d2f upstream.
when scheduler is enabled, the semaphore isn't used at all.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d1ad20f15b1d545642474860cc17a7dd6b051d50
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Nov 24 14:30:56 2015 -0500
drm/amdgpu: call hpd_irq_event on resume
commit 54fb2a5cd0baf8e97d743de411e2f832d1afa68d upstream.
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8397905d2d56af92f2ba7e250bec5b6b0fdb9e57
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date: Mon Nov 23 17:43:48 2015 -0500
drm/amdgpu: Fix off-by-one errors in amdgpu_vm_bo_map
commit 005ae95e6ec119c64e2d16eb65a94c49e1dcf9f0 upstream.
eaddr is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 02b0518c0e5a9ba18f71fcc336bc7333b7a8893a
Author: Rob Clark <robdclark@gmail.com>
Date: Wed Oct 15 15:00:47 2014 -0400
drm/vmwgfx: respect 'nomodeset'
commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15ec2c4c10888f6403686be687e79165307e7e92
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date: Fri Jan 8 20:29:40 2016 +0100
drm/vmwgfx: Fix a width / pitch mismatch on framebuffer updates
commit a50e2bf5a0f674d62b69f51f6935a30e82bd015c upstream.
When the framebuffer is a vmwgfx dma buffer and a proxy surface is
created, the vmw_kms_update_proxy() function requires that the proxy
surface width and the framebuffer pitch are compatible, otherwise
display corruption occurs as seen in gnome-shell/native with software
3D. Since the framebuffer pitch is determined by user-space, allocate
a proxy surface the width of which is based on the framebuffer pitch
rather than on the framebuffer width.
Reported-by: Raphael Hertzog <buxy@kali.org>
Tested-by: Mati Aharoni <muts@kali.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4de54fb20e68c235ab7bebf521873b724816c93
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date: Fri Jan 8 20:29:39 2016 +0100
drm/vmwgfx: Fix an incorrect lock check
commit fb89ac5102ae2875d685c847e6b5dbc141622d43 upstream.
With CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y the vmwgfx kernel module
would unconditionally throw a bug when checking for a held spinlock
in the command buffer code. Fix this by using a lockdep check.
Reported-and-tested-by: Tetsuo Handa <penguin-kernel@i-love-sakura.ne.jp>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d56842d88978f54a3f7b8dfac3ae99ec3e732b95
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Thu Jan 14 16:00:41 2016 +0200
virtio_pci: fix use after free on release
commit 2989be09a8a9d62a785137586ad941f916e08f83 upstream.
KASan detected a use-after-free error in virtio-pci remove code. In
virtio_pci_remove(), vp_dev is still used after being freed in
unregister_virtio_device() (in virtio_pci_release_dev() more
precisely).
To fix, keep a reference until cleanup is done.
Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback")
Reported-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit afb02993539468a15700481b54968edc10940b0d
Author: Minchan Kim <minchan@kernel.org>
Date: Mon Dec 28 08:35:13 2015 +0900
virtio_balloon: fix race between migration and ballooning
commit 21ea9fb69e7c4b1b1559c3e410943d3ff248ffcb upstream.
In balloon_page_dequeue, pages_lock should cover the loop
(ie, list_for_each_entry_safe). Otherwise, the cursor page could
be isolated by compaction and then list_del by isolation could
poison the page->lru.{prev,next} so the loop finally could
access wrong address like this. This patch fixes the bug.
general protection fault: 0000 [#1] SMP
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff8800a7ff0000 ti: ffff8800a7fec000 task.ti: ffff8800a7fec000
RIP: 0010:[<ffffffff8115e754>] [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
RSP: 0018:ffff8800a7fefdc0 EFLAGS: 00010246
RAX: ffff88013fff9a70 RBX: ffffea000056fe00 RCX: 0000000000002b7d
RDX: ffff88013fff9a70 RSI: ffffea000056fe00 RDI: ffff88013fff9a68
RBP: ffff8800a7fefde8 R08: ffffea000056fda0 R09: 0000000000000000
R10: ffff8800a7fefd90 R11: 0000000000000001 R12: dead0000000000e0
R13: ffffea000056fe20 R14: ffff880138809070 R15: ffff880138809060
FS: 0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f229c10e000 CR3: 00000000b8b53000 CR4: 00000000000006a0
Stack:
0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060
0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020
ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060
Call Trace:
[<ffffffff812c86d3>] leak_balloon+0x93/0x1a0
[<ffffffff812c8bc7>] balloon+0x217/0x2a0
[<ffffffff8143739e>] ? __schedule+0x31e/0x8b0
[<ffffffff81078160>] ? abort_exclusive_wait+0xb0/0xb0
[<ffffffff812c89b0>] ? update_balloon_stats+0xf0/0xf0
[<ffffffff8105b6e9>] kthread+0xc9/0xe0
[<ffffffff8105b620>] ? kthread_park+0x60/0x60
[<ffffffff8143b4af>] ret_from_fork+0x3f/0x70
[<ffffffff8105b620>] ? kthread_park+0x60/0x60
Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89
RIP [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
RSP <ffff8800a7fefdc0>
---[ end trace 43cf28060d708d5f ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac3981b170863371c0386f9578d6bf4b8f961cc0
Author: Minchan Kim <minchan@kernel.org>
Date: Mon Dec 28 08:35:12 2015 +0900
virtio_balloon: fix race by fill and leak
commit f68b992bbb474641881932c61c92dcfa6f5b3689 upstream.
During my compaction-related stuff, I encountered a bug
with ballooning.
With repeated inflating and deflating cycle, guest memory(
ie, cat /proc/meminfo | grep MemTotal) is decreased and
couldn't be recovered.
The reason is balloon_lock doesn't cover release_pages_balloon
so struct virtio_balloon fields could be overwritten by race
of fill_balloon(e,g, vb->*pfns could be critical).
This patch fixes it in my test.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7d661c4658ce4485d5737eb522303d6eefa42749
Author: Henry Chen <henryc.chen@mediatek.com>
Date: Tue Nov 17 16:36:49 2015 +0800
regulator: mt6311: MT6311_REGULATOR needs to select REGMAP_I2C
commit aab3c3f34cc2dd8230052770712606d65de6538f upstream.
This patch fix the below build error:
drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 40ab2d7d44aff753b6c43f016b6fdb166fe8e4ff
Author: Chen-Yu Tsai <wens@csie.org>
Date: Tue Dec 22 17:08:06 2015 +0800
regulator: axp20x: Fix GPIO LDO enable value for AXP22x
commit 3cb99e2ea99a454c8837a55aac88753ef05fc1eb upstream.
The enable/disable values for GPIO LDOs are reversed. It seems no one
noticed as AXP22x support was introduced recently, and no one was using
the GPIO LDOs, either because no designs actually use them or board
support hasn't caught up.
Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ca59689c947bda700e07fdea4d9e4f582601c68
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Fri Dec 11 15:38:40 2015 +0100
clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs
commit 6b4feaea251a97bf08c7d41eabdec07f63a11073 upstream.
It is allowed to enable/disable clocks from interrupts, so common Exynos
ARM clock management code for CPUfreq should use 'irqsave' version of
spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
The same spin_lock is used by gate/mux clocks during enable/disable calls.
This deadlock, can be reproduced by enabling CPUfreq (ondemand or
userspace) and decoding video with s5p-mfc driver.
Relevant stack trace:
[ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252
[ 5928.061609] lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, .owner_cpu: 0
[ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G W 4.4.0-rc4-00001-g447a7fd #678
[ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5928.083359] [<c00153dc>] (unwind_backtrace) from [<c00121b4>] (show_stack+0x10/0x14)
[ 5928.091072] [<c00121b4>] (show_stack) from [<c0213e28>] (dump_stack+0x68/0xb8)
[ 5928.098275] [<c0213e28>] (dump_stack) from [<c005c1ec>] (do_raw_spin_lock+0x184/0x1ac)
[ 5928.106177] [<c005c1ec>] (do_raw_spin_lock) from [<c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 5928.114943] [<c05cfa98>] (_raw_spin_lock_irqsave) from [<c0468698>] (clk_gate_endisable+0x24/0x98)
[ 5928.123882] [<c0468698>] (clk_gate_endisable) from [<c0464d40>] (clk_core_disable+0x60/0x84)
[ 5928.132299] [<c0464d40>] (clk_core_disable) from [<c0465e00>] (clk_disable+0x24/0x30)
[ 5928.140117] [<c0465e00>] (clk_disable) from [<c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860)
[ 5928.148445] [<c03f3b80>] (s5p_mfc_handle_frame) from [<c03f4b34>] (s5p_mfc_irq+0x890/0xa24)
[ 5928.156778] [<c03f4b34>] (s5p_mfc_irq) from [<c00627bc>] (handle_irq_event_percpu+0x50/0x14c)
[ 5928.165283] [<c00627bc>] (handle_irq_event_percpu) from [<c00628f0>] (handle_irq_event+0x38/0x5c)
[ 5928.174143] [<c00628f0>] (handle_irq_event) from [<c0065864>] (handle_fasteoi_irq+0xdc/0x1a4)
[ 5928.182645] [<c0065864>] (handle_fasteoi_irq) from [<c0062090>] (generic_handle_irq+0x18/0x28)
[ 5928.191236] [<c0062090>] (generic_handle_irq) from [<c00621a4>] (__handle_domain_irq+0x6c/0xdc)
[ 5928.199917] [<c00621a4>] (__handle_domain_irq) from [<c0009470>] (gic_handle_irq+0x4c/0x98)
[ 5928.208249] [<c0009470>] (gic_handle_irq) from [<c0012c54>] (__irq_svc+0x54/0x90)
[ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00)
[ 5928.220745] 5ca0: ee80454c faddfadc
[ 5928.228906] 5cc0: 00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84
[ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff
[ 5928.245225] [<c0012c54>] (__irq_svc) from [<c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270)
[ 5928.253823] [<c046b634>] (exynos_cpuclk_notifier_cb) from [<c003cb58>] (notifier_call_chain+0x44/0x84)
[ 5928.263106] [<c003cb58>] (notifier_call_chain) from [<c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c)
[ 5928.272480] [<c003ccd4>] (__srcu_notifier_call_chain) from [<c003cd1c>] (srcu_notifier_call_chain+0x18/0x20)
[ 5928.282288] [<c003cd1c>] (srcu_notifier_call_chain) from [<c0464ed0>] (__clk_notify+0x6c/0x74)
[ 5928.290881] [<c0464ed0>] (__clk_notify) from [<c0465388>] (clk_propagate_rate_change+0xa0/0xac)
[ 5928.299561] [<c0465388>] (clk_propagate_rate_change) from [<c0465378>] (clk_propagate_rate_change+0x90/0xac)
[ 5928.309370] [<c0465378>] (clk_propagate_rate_change) from [<c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8)
[ 5928.319091] [<c04666fc>] (clk_core_set_rate_nolock) from [<c0466760>] (clk_set_rate+0x20/0x30)
[ 5928.327686] [<c0466760>] (clk_set_rate) from [<c0428c70>] (set_target+0xe8/0x23c)
[ 5928.335152] [<c0428c70>] (set_target) from [<c04244d0>] (__cpufreq_driver_target+0x184/0x29c)
[ 5928.343655] [<c04244d0>] (__cpufreq_driver_target) from [<c0427128>] (cpufreq_set+0x44/0x64)
[ 5928.352074] [<c0427128>] (cpufreq_set) from [<c0423948>] (store_scaling_setspeed+0x5c/0x74)
[ 5928.360407] [<c0423948>] (store_scaling_setspeed) from [<c04238d0>] (store+0x7c/0x98)
[ 5928.368221] [<c04238d0>] (store) from [<c0132540>] (sysfs_kf_write+0x44/0x48)
[ 5928.375338] [<c0132540>] (sysfs_kf_write) from [<c0131b9c>] (kernfs_fop_write+0xb8/0x1bc)
[ 5928.383496] [<c0131b9c>] (kernfs_fop_write) from [<c00d71f8>] (__vfs_write+0x2c/0xd4)
[ 5928.391308] [<c00d71f8>] (__vfs_write) from [<c00d7de8>] (vfs_write+0xa0/0x144)
[ 5928.398598] [<c00d7de8>] (vfs_write) from [<c00d8048>] (SyS_write+0x44/0x84)
[ 5928.405631] [<c00d8048>] (SyS_write) from [<c000f540>] (ret_fast_syscall+0x0/0x3c)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3d4bcc39fcdd54d44afd45f00b9b840961430be
Author: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Date: Wed Nov 4 13:24:09 2015 +1100
cxl: use correct operator when writing pcie config space values
commit 48f0f6b717e314a30be121b67e1d044f6d311d66 upstream.
When writing a value to config space, cxl_pcie_write_config() calls
cxl_pcie_config_info() to obtain a mask and shift value, shifts the new
value accordingly, then uses the mask to combine the shifted value with the
existing value at the address as part of a read-modify-write pattern.
Currently, we use a logical OR operator rather than a bitwise OR operator,
which means any use of this function results in an incorrect value being
written. Replace the logical OR operator with a bitwise OR operator so the
value is written correctly.
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0b1c2d0f53c8368eef4018ed7ce15b6c015aa77
Author: Dmitry V. Levin <ldv@altlinux.org>
Date: Sun Dec 27 02:13:27 2015 +0300
sparc64: fix incorrect sign extension in sys_sparc64_personality
commit 525fd5a94e1be0776fa652df5c687697db508c91 upstream.
The value returned by sys_personality has type "long int".
It is saved to a variable of type "int", which is not a problem
yet because the type of task_struct->pesonality is "unsigned int".
The problem is the sign extension from "int" to "long int"
that happens on return from sys_sparc64_personality.
For example, a userspace call personality((unsigned) -EINVAL) will
result to any subsequent personality call, including absolutely
harmless read-only personality(0xffffffff) call, failing with
errno set to EINVAL.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b49777c656daba9cb9788cebae91c304f6fe5782
Author: Borislav Petkov <bp@suse.de>
Date: Tue Dec 1 15:52:36 2015 +0100
EDAC, mc_sysfs: Fix freeing bus' name
commit 12e26969b32c79018165d52caff3762135614aa1 upstream.
I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:
.loc 1 1108 0
movq 672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
.loc 1 1109 0
popq %rbx #
.loc 1 1108 0
movq (%rax), %rdi # _7->name,
jmp kfree #
and %rax has some funky stuff 2030203020312030 which looks a lot like
something walked over it.
Fix that by saving the name ptr before doing stuff to string it points to.
general protection fault: 0000 [#1] SMP
Modules linked in: ...
CPU: 4 PID: 10318 Comm: modprobe Tainted: G I EN 3.12.51-11-default+ #48
Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
RIP: 0010:[<ffffffffa019da92>] [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
RSP: 0018:ffff88030da3fe28 EFLAGS: 00010292
RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
FS: 00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
Stack:
Call Trace:
i7core_unregister_mci.isra.9
i7core_remove
pci_device_remove
__device_release_driver
driver_detach
bus_remove_driver
pci_unregister_driver
i7core_exit
SyS_delete_module
system_call_fastpath
0x7fc9bf426536
Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
RIP [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
RSP <ffff88030da3fe28>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de46e6540360c72943239bf5ce0a2839432204d8
Author: Borislav Petkov <bp@suse.de>
Date: Fri Nov 27 10:38:38 2015 +0100
EDAC: Robustify workqueues destruction
commit fcd5c4dd8201595d4c598c9cca5e54760277d687 upstream.
EDAC workqueue destruction is really fragile. We cancel delayed work
but if it is still running and requeues itself, we still go ahead and
destroy the workqueue and the queued work explodes when workqueue core
attempts to run it.
Make the destruction more robust by switching op_state to offline so
that requeuing stops. Cancel any pending work *synchronously* too.
EDAC i7core: Driver loaded.
general protection fault: 0000 [#1] SMP
CPU 12
Modules linked in:
Supported: Yes
Pid: 0, comm: kworker/0:1 Tainted: G IE 3.0.101-0-default #1 HP ProLiant DL380 G7
RIP: 0010:[<ffffffff8107dcd7>] [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
< ... regs ...>
Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
Stack:
...
Call Trace:
call_timer_fn
run_timer_softirq
__do_softirq
call_softirq
do_softirq
irq_exit
smp_apic_timer_interrupt
apic_timer_interrupt
intel_idle
cpuidle_idle_call
cpu_idle
Code: ...
RIP __queue_work
RSP <...>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a869e6b05d4bc17afeed7ade9f4ffc0d1c3bac47
Author: James Hogan <james.hogan@imgtec.com>
Date: Mon Jan 25 20:32:03 2016 +0000
MIPS: Fix buffer overflow in syscall_get_arguments()
commit f4dce1ffd2e30fa31756876ef502ce6d2324be35 upstream.
Since commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls
(o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
arguments by incrementing both the start argument number and the number
of arguments to fetch. However only the start argument number needs to
be incremented. The number of arguments does not change, they're just
shifted up by one, and in fact the output array is provided by the
caller and is likely only n entries long, so reading more arguments
overflows the output buffer.
In the case of seccomp, this results in it fetching 7 arguments starting
at the 2nd one, which overflows the unsigned long args[6] in
populate_seccomp_data(). This clobbers the $s0 register from
syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
stack, into which syscall_trace_enter() had placed its syscall number
argument. This caused Chromium to crash.
Credit goes to Milko for tracking it down as far as $s0 being clobbered.
Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
Reported-by: Milko Leporis <milko.leporis@imgtec.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12213/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dbdb0333caf272500f495da2da71125d564146e7
Author: Huacai Chen <chenhc@lemote.com>
Date: Thu Jan 21 21:09:52 2016 +0800
MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs
commit 4f33f6c522948fffc345261896042b58dea23754 upstream.
Commit be0c37c985eddc4 (MIPS: Rearrange PTE bits into fixed positions.)
defines fixed PTE bits for MIPS R2. Then, commit d7b631419b3d230a4d383
(MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS
R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the
later commit are missing, so in this patch I fix that.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12164/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e76f1004a01d5475d9f09c32aa19c912b71f29db
Author: Huacai Chen <chenhc@lemote.com>
Date: Thu Jan 21 21:09:50 2016 +0800
MIPS: hpet: Choose a safe value for the ETIME check
commit 5610b1254e3689b6ef8ebe2db260709a74da06c8 upstream.
This patch is borrowed from x86 hpet driver and explaind below:
Due to the overly intelligent design of HPETs, we need to workaround
the problem that the compare value which we write is already behind
the actual counter value at the point where the value hits the real
compare register. This happens for two reasons:
1) We read out the counter, add the delta and write the result to the
compare register. When a NMI hits between the read out and the write
then the counter can be ahead of the event already.
2) The write to the compare register is delayed by up to two HPET
cycles in AMD chipsets.
We can work around this by reading back the compare register to make
sure that the written value has hit the hardware. But that is bad
performance wise for the normal case where the event is far enough in
the future.
As we already know that the write can be delayed by up to two cycles
we can avoid the read back of the compare register completely if we
make the decision whether the delta has elapsed already or not based
on the following calculation:
cmp = event - actual_count;
If cmp is less than 64 HPET clock cycles, then we decide that the event
has happened already and return -ETIME. That covers the above #1 and #2
problems which would cause a wait for HPET wraparound (~306 seconds).
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12162/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 332e40db5154bb9162ad0bb0621876ac48f75e16
Author: Huacai Chen <chenhc@lemote.com>
Date: Thu Jan 21 21:09:49 2016 +0800
MIPS: Loongson-3: Fix SMP_ASK_C0COUNT IPI handler
commit 5754843225f78ac7cbe142a6899890a9733a5a5d upstream.
When Core-0 handle SMP_ASK_C0COUNT IPI, we should make other cores to
see the result as soon as possible (especially when Store-Fill-Buffer
is enabled). Otherwise, C0_Count syncronization makes no sense.
BTW, array is more suitable than per-cpu variable for syncronization,
and there is a corner case should be avoid: C0_Count of Core-0 can be
really 0.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12160/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 97ff5367a76179adeb2c4003ec9ee83a9a36b242
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Jan 22 09:20:37 2016 -0800
Revert "MIPS: Fix PAGE_MASK definition"
commit 800dc4f49cc002879e1e5e6b79926f86b60528e6 upstream.
This reverts commit 22b14523994588279ae9c5ccfe64073c1e5b3c00.
It was originally sent in an earlier revision of the pfn_t patchset.
Besides being broken, the warning is also fixed by PFN_FLAGS_MASK
casting the PAGE_MASK to an unsigned long.
Reported-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/12182/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 242e16cd87b1d6e19382dc683b6cab121fcfd69c
Author: zengtao <prime.zeng@huawei.com>
Date: Tue Feb 2 11:38:34 2016 +0800
cputime: Prevent 32bit overflow in time[val|spec]_to_cputime()
commit 0f26922fe5dc5724b1adbbd54b21bad03590b4f3 upstream.
The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
overflows in the timeval/timespec to cputime conversion.
Currently the following functions are affected:
1. setitimer()
2. timer_create/timer_settime()
3. sys_clock_nanosleep
This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
enabled, which is required for CONFIG_NO_HZ_FULL.
Enforce u64 conversion to prevent the overflow.
Fixes: 31c1fc818715 ("ARM: Kconfig: allow full nohz CPU accounting")
Signed-off-by: zengtao <prime.zeng@huawei.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 972e9e3c7f447bb2becfdcde9931790e78dd43fa
Author: David Gibson <david@gibson.dropbear.id.au>
Date: Mon Nov 30 12:30:30 2015 +1100
time: Avoid signed overflow in timekeeping_get_ns()
commit 35a4933a895927990772ae96fdcfd2f806929ee2 upstream.
1e75fa8 "time: Condense timekeeper.xtime into xtime_sec" replaced a call to
clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version
of the same logic to avoid keeping a semi-redundant struct timespec
in struct timekeeper.
However, the commit also introduced a subtle semantic change - where
clocksource_cyc2ns() uses purely unsigned math, the new version introduces
a signed temporary, meaning that if (delta * tk->mult) has a 63-bit
overflow the following shift will still give a negative result. The
choice of 'maxsec' in __clocksource_updatefreq_scale() means this will
generally happen if there's a ~10 minute pause in examining the
clocksource.
This can be triggered on a powerpc KVM guest by stopping it from qemu for
a bit over 10 minutes. After resuming time has jumped backwards several
minutes causing numerous problems (jiffies does not advance, msleep()s can
be extended by minutes..). It doesn't happen on x86 KVM guests, because
the guest TSC is effectively frozen while the guest is stopped, which is
not the case for the powerpc timebase.
Obviously an unsigned (64 bit) overflow will only take twice as long as a
signed, 63-bit overflow. I don't know the time code well enough to know
if that will still cause incorrect calculations, or if a 64-bit overflow
is avoided elsewhere.
Still, an incorrect forwards clock adjustment will cause less trouble than
time going backwards. So, this patch removes the potential for
intermediate signed overflow.
Suggested-by: Laurent Vivier <lvivier@redhat.com>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8cf0f282de522d9f44dc2e0f6f58361fdef4d722
Author: Lukasz Duda <lukasz.duda@nordicsemi.no>
Date: Wed Jan 13 16:57:48 2016 +0100
Bluetooth: 6lowpan: Fix handling of uncompressed IPv6 packets
commit 87f5fedb3bebbbb566f847dd0c567fcea49a36a6 upstream.
This patch fixes incorrect handling of the 6lowpan packets that contain
uncompressed IPv6 header.
RFC4944 specifies a special dispatch for 6lowpan to carry uncompressed
IPv6 header. This dispatch (1 byte long) has to be removed during
reception and skb data pointer has to be moved. To correctly point in
the beginning of the IPv6 header the dispatch byte has to be pulled off
before packet can be processed by netif_rx_in().
Test scenario: IPv6 packets are not correctly interpreted by the network
layer when IPv6 header is not compressed (e.g. ICMPv6 Echo Reply is not
propagated correctly to the ICMPv6 layer because the extra byte will make
the header look corrupted).
Similar approach is done for IEEE 802.15.4.
Signed-off-by: Lukasz Duda <lukasz.duda@nordicsemi.no>
Signed-off-by: Glenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cf5d2ff495fdf7b7c3936166ca18f7d37d4f6c25
Author: Glenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
Date: Wed Jan 13 16:41:42 2016 +0100
Bluetooth: 6lowpan: Fix kernel NULL pointer dereferences
commit 4c58f3282e3de43d34f8955f8eca676294380bf9 upstream.
The fixes provided in this patch assigns a valid net_device structure to
skb before dispatching it for further processing.
Scenario #1:
============
Bluetooth 6lowpan receives an uncompressed IPv6 header, and dispatches it
to netif. The following error occurs:
Null pointer dereference error #1 crash log:
[ 845.854013] BUG: unable to handle kernel NULL pointer dereference at
0000000000000048
[ 845.855785] IP: [<ffffffff816e3d36>] enqueue_to_backlog+0x56/0x240
...
[ 845.909459] Call Trace:
[ 845.911678] [<ffffffff816e3f64>] netif_rx_internal+0x44/0xf0
The first modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in order to set a valid net_device before
processing the skb by netif_rx_ni().
Scenario #2:
============
Bluetooth 6lowpan receives an UDP compressed message which needs further
decompression by nhc_udp. The following error occurs:
Null pointer dereference error #2 crash log:
[ 63.295149] BUG: unable to handle kernel NULL pointer dereference at
0000000000000840
[ 63.295931] IP: [<ffffffffc0559540>] udp_uncompress+0x320/0x626
[nhc_udp]
The second modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in the case of a udp compressed packet.
The 6lowpan udp_uncompress function expects that the net_device is set in
the skb when checking lltype.
Signed-off-by: Glenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
Signed-off-by: Lukasz Duda <lukasz.duda@nordicsemi.no>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 701495c14d09658bffe78e0e605f298752edd36c
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Tue Jan 26 14:31:31 2016 -0500
Bluetooth: Fix incorrect removing of IRKs
commit cff10ce7b4f02718ffd25e3914e60559f5ef6ca0 upstream.
The commit cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to
fix handling of devices first using public addresses and then
switching to RPAs after pairing. Unfortunately it missed a couple of
key places in the code.
1. When evaluating which devices should be removed from the existing
white list we also need to consider whether we have an IRK for them or
not, i.e. a call to hci_find_irk_by_addr() is needed.
2. In smp_notify_keys() we should not be requiring the knowledge of
the RPA, but should simply keep the IRK around if the other conditions
require it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b2b55a0d88ef81f33ea77f79cbdeee25b2ed891
Author: Dmitry Tunin <hanipouspilot@gmail.com>
Date: Sat Dec 5 14:09:36 2015 +0300
Bluetooth: Add support of Toshiba Broadcom based devices
commit 1623d0bf847d3b38d8cf24367b3689ba0e3fe2aa upstream.
BugLink: https://bugs.launchpad.net/bugs/1522949
T: Bus=03 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0930 ProdID=0225 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM43142A0
S: SerialNumber=4CBB58034671
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c76633bf38205c9ee640096eb387dce31cb8b8c9
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Thu Dec 3 12:45:19 2015 +0200
Bluetooth: Use continuous scanning when creating LE connections
commit 2f99536a5b34d5b0f54723067d68f6cef3f0fdc6 upstream.
All LE connections are now triggered through a preceding passive scan
and waiting for a connectable advertising report. This means we've got
the best possible guarantee that the device is within range and should
be able to request the controller to perform continuous scanning. This
way we minimize the risk that we miss out on any advertising packets.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a383bcc68ad1437315eb4298a84cdde070a69bc
Author: K. Y. Srinivasan <kys@microsoft.com>
Date: Mon Dec 14 16:01:54 2015 -0800
Drivers: hv: vmbus: Fix a Host signaling bug
commit 8599846d73997cdbccf63f23394d871cfad1e5e6 upstream.
Currently we have two policies for deciding when to signal the host:
One based on the ring buffer state and the other based on what the
VMBUS client driver wants to do. Consider the case when the client
wants to explicitly control when to signal the host. In this case,
if the client were to defer signaling, we will not be able to signal
the host subsequently when the client does want to signal since the
ring buffer state will prevent the signaling. Implement logic to
have only one signaling policy in force for a given channel.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Tested-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7db755f538b093335e43b8ca81667f898ca51ede
Author: Dexuan Cui <decui@microsoft.com>
Date: Mon Dec 14 16:01:58 2015 -0800
tools: hv: vss: fix the write()'s argument: error -> vss_msg
commit a689d2510f188e75391dbebacbddfd74d42f2a7e upstream.
Fix the write()'s argument in the daemon code.
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 61b9408bfd06779c8b2073829bf2f73a81531a99
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Tue Feb 9 16:12:36 2016 +0200
mmc: sdhci: Allow override of get_cd() called from sdhci_request()
commit 8d28b7a72fe18bcdcdb047243ba8fec36b149955 upstream.
Drivers may need to provide their own get_cd() mmc host op, but
currently the internals of the current op (sdhci_get_cd()) are
provided by sdhci_do_get_cd() which is also called from
sdhci_request().
To allow override of the get_cd functionality, change sdhci_request()
to call ->get_cd() instead of sdhci_do_get_cd().
Note, in the future the call to ->get_cd() will likely be removed
from sdhci_request() since most drivers don't need actually it.
However this change is being done now to facilitate a subsequent
bug fix.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bafb71422d791e7c074dadbab5bf8e421a1ef97b
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Tue Feb 9 16:12:35 2016 +0200
mmc: sdhci: Allow override of mmc host operations
commit bf60e592a1af4d6f65dd54593250183f14360eed upstream.
In the past, fixes for specific hardware devices were implemented
in sdhci using quirks. That approach is no longer accepted because
the growing number of quirks was starting to make the code difficult
to understand and maintain.
One alternative to quirks, is to allow drivers to override the default
mmc host operations. This patch makes it easy to do that, and it is
needed for a subsequent bug fix, for which separate patches are
provided.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dfca191876436fd33c6ad18258116a2bf5506618
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Tue Feb 9 16:12:37 2016 +0200
mmc: sdhci-pci: Fix card detect race for Intel BXT/APL
commit 163cbe31e5163459908a41a2b4e0d33a28fd557a upstream.
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7f7a5e2e914e9f5332ea56d10e0db4be3363375
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Fri Jan 29 00:21:26 2016 +0100
mmc: pxamci: fix again read-only gpio detection polarity
commit 41c89159a6ae5472d39ed8bded5b3b4e07a37944 upstream.
The commit fixing the conversion of pxamci to slot-gpio API fixed the
inverted the logic of the read-only gpio. Unfortunately, the commit was
tested on a non-inverted gpio, and not on the inverted one. And the fix
did work partially, by luck.
This is the remaining missing part of the fix, trivial but still necessary.
Fixes: Fixes: 26d49fe71953 ("mmc: pxamci: fix read-only gpio detection polarity")
Reported-by: Andrea Adami <andrea.adami@gmail.com>
Tested-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 43919d0ca15d5e93efd40467c63502b33b7acf5c
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Tue Feb 9 16:12:38 2016 +0200
mmc: sdhci-acpi: Fix card detect race for Intel BXT/APL
commit 6a645dd87a5a506779810d7d9935c25fc2ef4687 upstream.
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bfda88879216667b7f60d91851606f165244b0a
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Mon Jan 4 02:21:55 2016 +0100
mmc: mmci: fix an ages old detection error
commit 0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 upstream.
commit 4956e10903fd ("ARM: 6244/1: mmci: add variant data and default
MCICLOCK support") added variant data for ARM, U300 and Ux500 variants.
The Nomadik NHK8815/8820 variant was erroneously labeled as a U300
variant, and when the proper Nomadik variant was later introduced in
commit 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik MMCI
variant") this was not fixes. Let's say this fixes the latter commit as
there was no proper Nomadik support until then.
Fixes: 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik...")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3cafb70cabf27616ac3da795a92a9b651fb28733
Author: Carlo Caione <carlo@endlessm.com>
Date: Wed Jan 13 09:36:55 2016 +0100
mmc: core: Enable tuning according to the actual timing
commit e10c321977091f163eceedec0650e0ef4b3cf4bb upstream.
While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.
This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.
With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fca2d31d02fd13878137ebba7073ba3d9df9862e
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu Nov 26 14:00:50 2015 +0200
mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off()
commit 5c671c410c8704800f4f1673b6f572137e7e6ddd upstream.
sdhci has a legacy facility to prevent runtime suspend if the
bus power is on. This is needed in cases where the power to
the card is dependent on the bus power. It is controlled by
a pair of functions: sdhci_runtime_pm_bus_on() and
sdhci_runtime_pm_bus_off(). These functions use a boolean
variable 'bus_on' to ensure changes are always paired.
There is an additional check for 'runtime_suspended' which is
the problem. In fact, its use is ill-conceived as the only
requirement for the logic is that 'on' and 'off' are paired,
which is actually broken by the check, for example if the bus
power is turned on during runtime resume. So remove the check.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6eec26b7b07ece01ad547fce01f0229c733f6462
Author: Wenkai Du <wenkai.du@intel.com>
Date: Thu Nov 26 14:00:44 2015 +0200
mmc: mmc: Fix incorrect use of driver strength switching HS200 and HS400
commit adb24d42a516bca8b9741ed21206509daaab5b13 upstream.
Commit cc4f414c885c ("mmc: mmc: Add driver strength selection")
added driver strength selection for eMMC HS200 and HS400 modes.
That patch also set the driver stength when transitioning through
High Speed mode to HS200/HS400, but driver strength is not defined
for High Speed mode. While the JEDEC specification is not clear
on this point it has been observed to cause problems for some eMMC,
and removing the driver strength setting in this case makes it
consistent with the normal use of High Speed mode.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8ae7192d91c8ca19fd0b919b594bc317d33fbede
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu Nov 26 14:00:47 2015 +0200
mmc: sdio: Fix invalid vdd in voltage switch power cycle
commit d9bfbb95ed598a09cf336adb0f190ee0ff802f0d upstream.
The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage. However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid vdd. Fix by passing the card's
ocr value which does not have the flag.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14772905465177b47ff0980eea5acf745ce7f625
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu Nov 26 14:00:48 2015 +0200
mmc: sdhci: Fix DMA descriptor with zero data length
commit 347ea32dc118326c4f2636928239a29d192cc9b8 upstream.
SDHCI has built-in DMA called ADMA2. ADMA2 uses a descriptor
table to define DMA scatter-gather. Each desciptor can specify
a data length up to 65536 bytes, however the length field is
only 16-bits so zero means 65536. Consequently, putting zero
when the size is zero must not be allowed. This patch fixes
one case where zero data length could be set inadvertently.
The problem happens because unaligned data gets split and the
code did not consider that the remaining aligned portion might
be zero length. That case really only happens for SDIO because
SD and eMMC cards transfer blocks that are invariably sector-
aligned. For SDIO, access to function registers is done by
data transfer (CMD53) when the register is bigger than 1 byte.
Generally registers are 4 bytes but 2-byte registers are possible.
So DMA of 4 bytes or less can happen. When 32-bit DMA is used,
the data alignment must be 4, so 4-byte transfers won't casue a
problem, but a 2-byte transfer could. However with the introduction
of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
so all 4-byte transfers not on 8-byte boundaries get "split" into
a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.
In fact, a closer look at the SDHCI specs indicates that only the
descriptor table requires 8-byte alignment for 64-bit DMA. That
will be dealt with in a separate patch, but the potential for a
2-byte access remains, so this fix is needed anyway.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a3d7e16b0f4729151f41061f5fc9cf91279b997
Author: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu Nov 26 14:00:45 2015 +0200
mmc: sdhci-pci: Do not default to 33 Ohm driver strength for Intel SPT
commit 1ca896856281d3f1ad4f6f7d4e32e2943452de23 upstream.
In some cases, the stronger 33 Ohm driver strength must not be used
so it is not a suitable default. Change it to the standard default
50 Ohm value.
The patch applies to v4.2+ except the file name changed. It is
drivers/mmc/host/sdhci-pci.c prior to v.4.4.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84bad9db0d8cfa0d84ab988c40226413cb34e2b3
Author: Rabin Vincent <rabin.vincent@axis.com>
Date: Fri Nov 27 12:59:11 2015 +0100
mmc: usdhi6rol0: handle NULL data in timeout
commit 05caee939f8d58d81e962071da85761e1e3a4c73 upstream.
Commit bb08a7d489bd ("mmc: usdhi6rol0: fix NULL pointer deref in debug
print") fixed one NULL pointer dereference but unfortunately introduced
another. "data" may be NULL if this is a command timeout for a command
without any data, so we should only use it if we're actually waiting for
data.
Fixes: bb08a7d489bd ("mmc: usdhi6rol0: fix NULL pointer deref in debug print")
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0cbcf2cb59c076f4ff6422153534dd2762c3d44
Author: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Fri Jan 15 11:34:21 2016 +0100
clockevents/tcb_clksrc: Prevent disabling an already disabled clock
commit f02b4b72d12cbae7020a959e2ed0410a464b4cc4 upstream.
clockevents_exchange_device is calling clockevents_shutdown() on the new
clockenvents device but it may have never been enabled in the first place.
This results in the tcb clock being disabled without being enabled first:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:680 clk_disable+0x28/0x34()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0+ #6
Hardware name: Atmel AT91SAM9
[<c000f2b8>] (unwind_backtrace) from [<c000d01c>] (show_stack+0x10/0x14)
[<c000d01c>] (show_stack) from [<c00172f0>] (warn_slowpath_common+0x78/0xa0)
[<c00172f0>] (warn_slowpath_common) from [<c00173a8>] (warn_slowpath_null+0x18/0x20)
[<c00173a8>] (warn_slowpath_null) from [<c0361528>] (clk_disable+0x28/0x34)
[<c0361528>] (clk_disable) from [<c034d560>] (tc_shutdown+0x38/0x4c)
[<c034d560>] (tc_shutdown) from [<c0059ad4>] (clockevents_switch_state+0x38/0x6c)
[<c0059ad4>] (clockevents_switch_state) from [<c0059b18>] (clockevents_shutdown+0x10/0x24)
[<c0059b18>] (clockevents_shutdown) from [<c005a458>] (tick_check_new_device+0x84/0xac)
[<c005a458>] (tick_check_new_device) from [<c0059660>] (clockevents_register_device+0x7c/0x108)
[<c0059660>] (clockevents_register_device) from [<c06b5a68>] (tcb_clksrc_init+0x390/0x3e8)
[<c06b5a68>] (tcb_clksrc_init) from [<c00097cc>] (do_one_initcall+0x114/0x1d4)
[<c00097cc>] (do_one_initcall) from [<c069bd54>] (kernel_init_freeable+0xfc/0x1b8)
[<c069bd54>] (kernel_init_freeable) from [<c04c3818>] (kernel_init+0x8/0xe0)
[<c04c3818>] (kernel_init) from [<c000a410>] (ret_from_fork+0x14/0x24)
---[ end trace 0000000000000001 ]---
Check what state we were in before trying to disable the clock.
Fixes: cf4541c101ea ("clockevents/drivers/tcb_clksrc: Migrate to new 'set-state' interface")
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1452854061-30370-1-git-send-email-alexandre.belloni@free-electrons.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b8175b171fde996b5306fd113bd865506166df19
Author: Richard Cochran <richardcochran@gmail.com>
Date: Tue Dec 22 22:19:58 2015 +0100
posix-clock: Fix return code on the poll method's error path
commit 1b9f23727abb92c5e58f139e7d180befcaa06fe0 upstream.
The posix_clock_poll function is supposed to return a bit mask of
POLLxxx values. However, in case the hardware has disappeared (due to
hot plugging for example) this code returns -ENODEV in a futile
attempt to throw an error at the file descriptor level. The kernel's
file_operations interface does not accept such error codes from the
poll method. Instead, this function aught to return POLLERR.
The value -ENODEV does, in fact, contain the POLLERR bit (and almost
all the other POLLxxx bits as well), but only by chance. This patch
fixes code to return a proper bit mask.
Credit goes to Markus Elfring for pointing out the suspicious
signed/unsigned mismatch.
Reported-by: Markus Elfring <elfring@users.sourceforge.net>
igned-off-by: Richard Cochran <richardcochran@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Link: http://lkml.kernel.org/r/1450819198-17420-1-git-send-email-richardcochran@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b966c761afe6d8560b463fe695525c883ce3fea6
Author: Ashok Kumar <ashoks@broadcom.com>
Date: Thu Feb 11 05:38:53 2016 -0800
irqchip/gic-v3-its: Fix double ICC_EOIR write for LPI in EOImode==1
commit 004fa08d7aba2a13974446bf212a48c0b3b0d9fd upstream.
When the GIC is using EOImode==1, the EOI is done immediately,
leaving the deactivation to be performed when the EOI was
previously done.
Unfortunately, the ITS is not aware of the EOImode at all, and
blindly EOIs the interrupt again. On most systems, this is ignored
(despite being a programming error), but some others do raise a
SError exception as there is no priority drop to perform for this
interrupt.
The fix is to stop trying to be clever, and always call into the
underlying GIC to perform the right access, irrespective of the
more we're in.
[Marc: Reworked commit message]
Fixes: 0b996fd35957a ("irqchip/GICv3: Convert to EOImode == 1")
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Ashok Kumar <ashoks@broadcom.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2edd7c99031950e5a66e1254b787b9a70aaa61f1
Author: Milo Kim <milo.kim@ti.com>
Date: Wed Jan 13 16:19:50 2016 +0900
irqchip/atmel-aic: Fix wrong bit operation for IRQ priority
commit 49f34134aea74f19ca016f055d25ee55ec359dee upstream.
Atmel AIC has common structure for SMR (Source Mode Register).
bit[6:5] Interrupt source type
bit[2:0] Priority level
Other bits are unused.
To update new priority value, bit[2:0] should be cleared first and then
new priority level can be written. However, aic_common_set_priority()
helper clears source type bits instead of priority bits.
This patch fixes wrong mask bit operation.
Fixes: b1479ebb7720 "irqchip: atmel-aic: Add atmel AIC/AIC5 drivers"
Signed-off-by: Milo Kim <milo.kim@ti.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: Nicholas Ferre <nicolas.ferre@atmel.com>
Link: http://lkml.kernel.org/r/1452669592-3401-2-git-send-email-milo.kim@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4778f99a2c60a826146000c31472fc79935255c1
Author: Oleksij Rempel <linux@rempel-privat.de>
Date: Fri Jan 29 10:57:53 2016 +0100
irqchip/mxs: Add missing set_handle_irq()
commit c5b635203032462603c503ecce91a7021c1ad44a upstream.
The rework of the driver missed to move the call to set_handle_irq() into
asm9260_of_init(). As a consequence no interrupt entry point is installed and
no interrupts are delivered
Solution is simple: Install the interrupt entry handler.
Fixes: 7e4ac676ee ("irqchip/mxs: Add Alphascale ASM9260 support")
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: kernel@pengutronix.de
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Link: http://lkml.kernel.org/r/1454061473-24957-1-git-send-email-linux@rempel-privat.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 61836242f8a64deec07cfe4d4be3d6ed23875bea
Author: Sekhar Nori <nsekhar@ti.com>
Date: Tue Dec 15 19:56:12 2015 +0530
irqchip/omap-intc: Add support for spurious irq handling
commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d upstream.
Under some conditions, irq sorting procedure used by INTC can go wrong
resulting in a spurious irq getting reported.
If this condition is not handled, it results in endless stream of:
unexpected IRQ trap at vector 00
messages from ack_bad_irq()
Handle the spurious interrupt condition in omap-intc driver to prevent this.
Measurements using kernel function profiler on AM335x EVM running at 720MHz
show that after this patch omap_intc_handle_irq() takes about 37.4us against
34us before this patch.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 53cc688d090bbd461e92ab28ecf4bde8b0c2a6da
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date: Thu Dec 17 08:47:02 2015 -0700
coresight: checking for NULL string in coresight_name_match()
commit fadf3a44e974b030e7145218ad1ab25e3ef91738 upstream.
Connection child names associated to ports can sometimes be NULL,
which is the case when booting a system on QEMU or when the Coresight
power domain isn't switched on.
This patch is adding a check to make sure a NULL string isn't fed
to strcmp(), something that avoid crashing the system.
Reported-by: Tyler Baker <tyler.baker@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c6f66674274958e0ea2d2d6c7a905e4ea73881e
Author: Mike Snitzer <snitzer@redhat.com>
Date: Sun Feb 21 19:09:22 2016 -0500
dm: fix dm_rq_target_io leak on faults with .request_fn DM w/ blk-mq paths
commit 4328daa2e79ed904a42ce00a9f38b9c36b44b21a upstream.
Using request-based DM mpath configured with the following stacking
(.request_fn DM mpath ontop of scsi-mq paths):
echo Y > /sys/module/scsi_mod/parameters/use_blk_mq
echo N > /sys/module/dm_mod/parameters/use_blk_mq
'struct dm_rq_target_io' would leak if a request is requeued before a
blk-mq clone is allocated (or fails to allocate). free_rq_tio()
wasn't being called.
kmemleak reported:
unreferenced object 0xffff8800b90b98c0 (size 112):
comm "kworker/7:1H", pid 5692, jiffies 4295056109 (age 78.589s)
hex dump (first 32 bytes):
00 d0 5c 2c 03 88 ff ff 40 00 bf 01 00 c9 ff ff ..\,....@.......
e0 d9 b1 34 00 88 ff ff 00 00 00 00 00 00 00 00 ...4............
backtrace:
[<ffffffff81672b6e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff811dbb63>] kmem_cache_alloc+0xc3/0x1e0
[<ffffffff8117eae5>] mempool_alloc_slab+0x15/0x20
[<ffffffff8117ec1e>] mempool_alloc+0x6e/0x170
[<ffffffffa00029ac>] dm_old_prep_fn+0x3c/0x180 [dm_mod]
[<ffffffff812fbd78>] blk_peek_request+0x168/0x290
[<ffffffffa0003e62>] dm_request_fn+0xb2/0x1b0 [dm_mod]
[<ffffffff812f66e3>] __blk_run_queue+0x33/0x40
[<ffffffff812f9585>] blk_delay_work+0x25/0x40
[<ffffffff81096fff>] process_one_work+0x14f/0x3d0
[<ffffffff81097715>] worker_thread+0x125/0x4b0
[<ffffffff8109ce88>] kthread+0xd8/0xf0
[<ffffffff8167cb8f>] ret_from_fork+0x3f/0x70
[<ffffffffffffffff>] 0xffffffffffffffff
crash> struct -o dm_rq_target_io
struct dm_rq_target_io {
...
}
SIZE: 112
Fixes: e5863d9ad7 ("dm: allocate requests in target when stacking on blk-mq devices")
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1264fbd72f85446aa75bc3895e13589c1ed2c6df
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Fri Jan 8 19:07:55 2016 -0500
dm snapshot: fix hung bios when copy error occurs
commit 385277bfb57faac44e92497104ba542cdd82d5fe upstream.
When there is an error copying a chunk dm-snapshot can incorrectly hold
associated bios indefinitely, resulting in hung IO.
The function copy_callback sets pe->error if there was error copying the
chunk, and then calls complete_exception. complete_exception calls
pending_complete on error, otherwise it calls commit_exception with
commit_callback (and commit_callback calls complete_exception).
The persistent exception store (dm-snap-persistent.c) assumes that calls
to prepare_exception and commit_exception are paired.
persistent_prepare_exception increases ps->pending_count and
persistent_commit_exception decreases it.
If there is a copy error, persistent_prepare_exception is called but
persistent_commit_exception is not. This results in the variable
ps->pending_count never returning to zero and that causes some pending
exceptions (and their associated bios) to be held forever.
Fix this by unconditionally calling commit_exception regardless of
whether the copy was successful. A new "valid" parameter is added to
commit_exception -- when the copy fails this parameter is set to zero so
that the chunk that failed to copy (and all following chunks) is not
recorded in the snapshot store. Also, remove commit_callback now that
it is merely a wrapper around pending_complete.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7a853e6f7882e91fbdfb56663ed89355463ddef
Author: Mike Snitzer <snitzer@redhat.com>
Date: Mon Dec 14 09:26:01 2015 -0500
dm space map metadata: remove unused variable in brb_pop()
commit 512167788a6fe9481a33a3cce5f80b684631a1bb upstream.
Remove the unused struct block_op pointer that was inadvertantly
introduced, via cut-and-paste of previous brb_op() code, as part of
commit 50dd842ad.
(Cc'ing stable@ because commit 50dd842ad did)
Fixes: 50dd842ad ("dm space map metadata: fix ref counting bug when bootstrapping a new space map")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e862efec7272eab9950ca329eceda7fec272fd20
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date: Wed Feb 3 17:33:48 2016 -0200
tda1004x: only update the frontend properties if locked
commit e8beb02343e7582980c6705816cd957cf4f74c7a upstream.
The tda1004x was updating the properties cache before locking.
If the device is not locked, the data at the registers are just
random values with no real meaning.
This caused the driver to fail with libdvbv5, as such library
calls GET_PROPERTY from time to time, in order to return the
DVB stats.
Tested with a saa7134 card 78:
ASUSTeK P7131 Dual, vendor PCI ID: 1043:4862
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 368e554ba69f8cd9752c74adc7b6bd1f5f7c630e
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date: Thu Oct 29 03:02:06 2015 -0200
vb2: fix a regression in poll() behavior for output,streams
commit 4623e5967448444a4ea1e77beb58898c4af48693 upstream.
In the 3.17 kernel the poll() behavior changed for output streams:
as long as not all buffers were queued up poll() would return that
userspace can write. This is fine for the write() call, but when
using stream I/O this changed the behavior since the expectation
was that it would wait for buffers to become available for dequeuing.
This patch only enables the check whether you can queue buffers
for file I/O only, and skips it for stream I/O.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f51c5d31c88d47a93135b89cf541aeb194f62908
Author: Antonio Ospite <ao2@ao2.it>
Date: Fri Oct 2 17:33:13 2015 -0300
gspca: ov534/topro: prevent a division by 0
commit dcc7fdbec53a960588f2c40232db2c6466c09917 upstream.
v4l2-compliance sends a zeroed struct v4l2_streamparm in
v4l2-test-formats.cpp::testParmType(), and this results in a division by
0 in some gspca subdrivers:
divide error: 0000 [#1] SMP
Modules linked in: gspca_ov534 gspca_main ...
CPU: 0 PID: 17201 Comm: v4l2-compliance Not tainted 4.3.0-rc2-ao2 #1
Hardware name: System manufacturer System Product Name/M2N-E SLI, BIOS
ASUS M2N-E SLI ACPI BIOS Revision 1301 09/16/2010
task: ffff8800818306c0 ti: ffff880095c4c000 task.ti: ffff880095c4c000
RIP: 0010:[<ffffffffa079bd62>] [<ffffffffa079bd62>] sd_set_streamparm+0x12/0x60 [gspca_ov534]
RSP: 0018:ffff880095c4fce8 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffff8800c9522000 RCX: ffffffffa077a140
RDX: 0000000000000000 RSI: ffff880095e0c100 RDI: ffff8800c9522000
RBP: ffff880095e0c100 R08: ffffffffa077a100 R09: 00000000000000cc
R10: ffff880067ec7740 R11: 0000000000000016 R12: ffffffffa07bb400
R13: 0000000000000000 R14: ffff880081b6a800 R15: 0000000000000000
FS: 00007fda0de78740(0000) GS:ffff88012fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000014630f8 CR3: 00000000cf349000 CR4: 00000000000006f0
Stack:
ffffffffa07a6431 ffff8800c9522000 ffffffffa077656e 00000000c0cc5616
ffff8800c9522000 ffffffffa07a5e20 ffff880095e0c100 0000000000000000
ffff880067ec7740 ffffffffa077a140 ffff880067ec7740 0000000000000016
Call Trace:
[<ffffffffa07a6431>] ? v4l_s_parm+0x21/0x50 [videodev]
[<ffffffffa077656e>] ? vidioc_s_parm+0x4e/0x60 [gspca_main]
[<ffffffffa07a5e20>] ? __video_do_ioctl+0x280/0x2f0 [videodev]
[<ffffffffa07a5ba0>] ? video_ioctl2+0x20/0x20 [videodev]
[<ffffffffa07a59b9>] ? video_usercopy+0x319/0x4e0 [videodev]
[<ffffffff81182dc1>] ? page_add_new_anon_rmap+0x71/0xa0
[<ffffffff811afb92>] ? mem_cgroup_commit_charge+0x52/0x90
[<ffffffff81179b18>] ? handle_mm_fault+0xc18/0x1680
[<ffffffffa07a15cc>] ? v4l2_ioctl+0xac/0xd0 [videodev]
[<ffffffff811c846f>] ? do_vfs_ioctl+0x28f/0x480
[<ffffffff811c86d4>] ? SyS_ioctl+0x74/0x80
[<ffffffff8154a8b6>] ? entry_SYSCALL_64_fastpath+0x16/0x75
Code: c7 93 d9 79 a0 5b 5d e9 f1 f3 9a e0 0f 1f 00 66 2e 0f 1f 84 00
00 00 00 00 66 66 66 66 90 53 31 d2 48 89 fb 48 83 ec 08 8b 46 10 <f7>
76 0c 80 bf ac 0c 00 00 00 88 87 4e 0e 00 00 74 09 80 bf 4f
RIP [<ffffffffa079bd62>] sd_set_streamparm+0x12/0x60 [gspca_ov534]
RSP <ffff880095c4fce8>
---[ end trace 279710c2c6c72080 ]---
Following what the doc says about a zeroed timeperframe (see
http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-parm.html):
...
To reset manually applications can just set this field to zero.
fix the issue by resetting the frame rate to a default value in case of
an unusable timeperframe.
The fix is done in the subdrivers instead of gspca.c because only the
subdrivers have notion of a default frame rate to reset the camera to.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c44a410e1680345b13a2e7c1011a3a470beb76d8
Author: Laura Abbott <labbott@fedoraproject.org>
Date: Mon Oct 5 19:33:29 2015 -0300
si2157: return -EINVAL if firmware blob is too big
commit d2cc2f0b35465951eaaf0387fd55e29835ed7ea6 upstream.
A previous patch added a check if the firmware is too big, but it didn't
set the return error code with the right value.
[mchehab@osg.samsung.com: I ended by applying a v1 of Laura's patch, without
the proper return code. This patch contains the difference between v2 and v1 of
the Laura's "si2157: Bounds check firmware" patch]
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Reviewed-by: Olli Salonen <olli.salonen@iki.fi>
Tested-by: Olli Salonen <olli.salonen@iki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
commit aecba569dc08bc746885aeae6086886cd62db7eb
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date: Mon Aug 31 06:13:45 2015 -0300
media: dvb-core: Don't force CAN_INVERSION_AUTO in oneshot mode
commit c9d57de6103e343f2d4e04ea8d9e417e10a24da7 upstream.
When in FE_TUNE_MODE_ONESHOT the frontend must report
the actual capabilities so user can take appropriate
action.
With frontends that can't do auto inversion this is done
by dvb-core automatically so CAN_INVERSION_AUTO is valid.
However, when in FE_TUNE_MODE_ONESHOT this is not true.
So only set FE_CAN_INVERSION_AUTO in modes other than
FE_TUNE_MODE_ONESHOT
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3214cf3b5fbe69b0274cb18a4147f62f926bd7fd
Author: Chen-Yu Tsai <wens@csie.org>
Date: Tue Dec 22 02:27:35 2015 -0200
rc: sunxi-cir: Initialize the spinlock properly
commit 768acf46e1320d6c41ed1b7c4952bab41c1cde79 upstream.
The driver allocates the spinlock but fails to initialize it correctly.
The kernel reports a BUG indicating bad spinlock magic when spinlock
debugging is enabled.
Call spin_lock_init() on it to initialize it correctly.
Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aaf1569ce4575ed163839002f27da2cde4d10a77
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Feb 27 19:23:16 2016 -0500
namei: ->d_inode of a pinned dentry is stable only for positives
commit d4565649b6d6923369112758212b851adc407f0c upstream.
both do_last() and walk_component() risk picking a NULL inode out
of dentry about to become positive, *then* checking its flags and
seeing that it's not negative anymore and using (already stale by
then) value they'd fetched earlier. Usually ends up oopsing soon
after that...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a007fc3d6569b620ec5bca1b4636d952ebdd2627
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date: Sun Jan 17 12:25:01 2016 +0200
mei: validate request value in client notify request ioctl
commit 7326fffb712f09a315bc73cc1ee63843f59b8bd4 upstream.
This patch address a possible security issue:
The request field in client notify request ioctl comes from user space
as u32 and is downcasted to u8 with out validation.
Check request field to have approved values
MEI_HBM_NOTIFICATION_STAR/STOP
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6472e6b6afc6e3fb7ec4d2890b4eed0d25f71ae9
Author: Tomas Winkler <tomas.winkler@intel.com>
Date: Thu Jan 7 14:46:38 2016 +0200
mei: fix fasync return value on error
commit ed6dc538e5a36a331b6256d54f435c80f6715460 upstream.
fasync should return a negative value on error
and not poll mask POLLERR.
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f037c35161f04459ff804eaa197a81f66f973379
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:31 2015 -0600
rtlwifi: rtl8723be: Fix module parameter initialization
commit 7079604ddb83f428359feace3aeaf8a9f435be4a upstream.
This driver has a number of errors in the module initialization. These
include the following:
Parameter msi_support is stored in two places - one is removed.
Paramters sw_crypto and disable_watchdog were never stored in the final
locations, nor were they initialized properly.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1b08009fb532a2785b8b38adec825488abc46fa
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:34 2015 -0600
rtlwifi: rtl8188ee: Fix module parameter initialization
commit 06f34572c6110e2e2d5e653a957f1d74db9e3f2b upstream.
In this driver, parameters disable_watchdog and sw_crypto are never
copied into the locations used in the main code. While modifying the
parameter handling, the copying of parameter msi_support is moved to
be with the rest.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da5c2c01da0cfccde6f2cedf35d8074d2bc19d10
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:36 2015 -0600
rtlwifi: rtl8192se: Fix module parameter initialization
commit 7503efbd82c15c4070adffff1344e5169d3634b4 upstream.
Two of the module parameter descriptions show incorrect default values.
In addition the value for software encryption is not transferred to
the locations used by the driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 626f652ac51b51008d9523db3442284eff35cbeb
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:32 2015 -0600
rtlwifi: rtl8723ae: Fix initialization of module parameters
commit 793b09994211fbe0b5cd5f7b6dd8cc9b6256c3c6 upstream.
This driver has some errors in the handling of module parameters. These
include missing initialization for parameters msi_support and
disable_watchdog. In addition, neither of these parameters nor sw_crypto
are transferred into the locations used by the driver. A final fix is
adding parameter msi to the module named and description macros.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7e9aec7b4c684d4f7af15ede8b23e540bcbfc78
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:35 2015 -0600
rtlwifi: rtl8192de: Fix incorrect module parameter descriptions
commit d4d60b4caaa5926e1b243070770968f05656107a upstream.
Two of the module parameters are listed with incorrect default values.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c2265e9fa89927e9a13cbb26f5fac7dac138333
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:37 2015 -0600
rtlwifi: rtl8192ce: Fix handling of module parameters
commit b24f19f16b9e43f54218c07609b783ea8625406a upstream.
The module parameter for software encryption was never transferred to
the location used by the driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 766e2109218a47821227d12552c174b75931d96e
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 14 16:34:38 2015 -0600
rtlwifi: rtl8192cu: Add missing parameter setup
commit b68d0ae7e58624c33f2eddab471fee55db27dbf9 upstream.
This driver fails to copy the module parameter for software encryption
to the locations used by the main code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78899f827ef13fd7b841acd023a12a2b740ca54e
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon Dec 21 17:05:08 2015 -0600
rtlwifi: rtl_pci: Fix kernel panic
commit f99551a2d39dc26ea03dc6761be11ac913eb2d57 upstream.
In commit 38506ecefab9 (rtlwifi: rtl_pci: Start modification for new
drivers), a bug was introduced that causes a NULL pointer dereference.
As this bug only affects the infrequently used RTL8192EE and only under
low-memory conditions, it has taken a long time for the bug to show up.
The bug was reported on the linux-wireless mailing list and also at
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/ as
bug #1527603 (kernel crashes due to rtl8192ee driver on ubuntu 15.10).
Fixes: 38506ecefab9 ("rtlwifi: rtl_pci: Start modification for new drivers")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d88b00ede29eef3f0b7cbb7d5e769ad5c11b9a0
Author: Jeff Layton <jeff.layton@primarydata.com>
Date: Thu Jan 7 16:38:10 2016 -0500
locks: fix unlock when fcntl_setlk races with a close
commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.
Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.
The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.
Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.
While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Acked-by: "J. Bruce Fields" <bfields@fieldses.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b4d88b5de8641d570600c5c83afe1761fa8d1fd
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Thu Dec 31 17:06:17 2015 +0100
um: link with -lpthread
commit a7df4716d19594b7b3f106f0bc0ca1c548e508e6 upstream.
Similarly to commit fb1770aa78a43530940d0c2dd161e77bc705bdac, with gcc 5
on Ubuntu and CONFIG_STATIC_LINK=y I was seeing these linker errors:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/librt.a(timer_create.o): In function `__timer_create_new':
(.text+0xcd): undefined reference to `pthread_once'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/librt.a(timer_create.o): In function `__timer_create_new':
(.text+0x126): undefined reference to `pthread_attr_init'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/librt.a(timer_create.o): In function `__timer_create_new':
(.text+0x168): undefined reference to `pthread_attr_setdetachstate'
[...]
Obviously we also need -lpthread for librt.a.
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cfcae394f6889cfe502f23433278a303948bdd39
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Wed Dec 16 21:59:56 2015 +0100
uml: fix hostfs mknod()
commit 9f2dfda2f2f1c6181c3732c16b85c59ab2d195e0 upstream.
An inverted return value check in hostfs_mknod() caused the function
to return success after handling it as an error (and cleaning up).
It resulted in the following segfault when trying to bind() a named
unix socket:
Pid: 198, comm: a.out Not tainted 4.4.0-rc4
RIP: 0033:[<0000000061077df6>]
RSP: 00000000daae5d60 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 000000006092a460 RCX: 00000000dfc54208
RDX: 0000000061073ef1 RSI: 0000000000000070 RDI: 00000000e027d600
RBP: 00000000daae5de0 R08: 00000000da980ac0 R09: 0000000000000000
R10: 0000000000000003 R11: 00007fb1ae08f72a R12: 0000000000000000
R13: 000000006092a460 R14: 00000000daaa97c0 R15: 00000000daaa9a88
Kernel panic - not syncing: Kernel mode fault at addr 0x40, ip 0x61077df6
CPU: 0 PID: 198 Comm: a.out Not tainted 4.4.0-rc4 #1
Stack:
e027d620 dfc54208 0000006f da981398
61bee000 0000c1ed daae5de0 0000006e
e027d620 dfcd4208 00000005 6092a460
Call Trace:
[<60dedc67>] SyS_bind+0xf7/0x110
[<600587be>] handle_syscall+0x7e/0x80
[<60066ad7>] userspace+0x3e7/0x4e0
[<6006321f>] ? save_registers+0x1f/0x40
[<6006c88e>] ? arch_prctl+0x1be/0x1f0
[<60054985>] fork_handler+0x85/0x90
Let's also get rid of the "cosmic ray protection" while we're at it.
Fixes: e9193059b1b3 "hostfs: fix races in dentry_name() and inode_name()"
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1f39f82654a34d136bbdb984f0e092946d60625f
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date: Fri Dec 18 21:28:53 2015 +0100
uml: flush stdout before forking
commit 0754fb298f2f2719f0393491d010d46cfb25d043 upstream.
I was seeing some really weird behaviour where piping UML's output
somewhere would cause output to get duplicated:
$ ./vmlinux | head -n 40
Checking that ptrace can change system call numbers...Core dump limits :
soft - 0
hard - NONE
OK
Checking syscall emulation patch for ptrace...Core dump limits :
soft - 0
hard - NONE
OK
Checking advanced syscall emulation patch for ptrace...Core dump limits :
soft - 0
hard - NONE
OK
Core dump limits :
soft - 0
hard - NONE
This is because these tests do a fork() which duplicates the non-empty
stdout buffer, then glibc flushes the duplicated buffer as each child
exits.
A simple workaround is to flush before forking.
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit caa2a2b56b7313b0f5c8373facc44768d3055f3c
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Fri Feb 19 15:29:05 2016 +0100
s390/fpu: signals vs. floating point control register
commit 1b17cb796f5d40ffa239c6926385abd83a77a49b upstream.
git commit 904818e2f229f3d94ec95f6932a6358c81e73d78
"s390/kernel: introduce fpu-internal.h with fpu helper functions"
introduced the fpregs_store / fp_regs_load helper. These function
fail to save and restore the floating pointer control registers.
The effect is that the FPC is not correctly handled on signal
delivery and signal return.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d70325085f56a5aa544afe5a4765e7ec5c72ccc2
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Fri Feb 19 14:44:14 2016 +0100
s390/compat: correct restore of high gprs on signal return
commit 342300cc9cd3428bc6bfe5809bfcc1b9a0f06702 upstream.
git commit 8070361799ae1e3f4ef347bd10f0a508ac10acfb
"s390: add support for vector extension"
broke 31-bit compat processes in regard to signal handling.
The restore_sigregs_ext32() function is used to restore the additional
elements from the user space signal frame. Among the additional elements
are the upper registers halves for 64-bit register support for 31-bit
processes. The copy_from_user that is used to retrieve the high-gprs
array from the user stack uses an incorrect length, 8 bytes instead of
64 bytes. This causes incorrect upper register halves to get loaded.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a90ad5c546fa28f28f5870d884603a7822e9c82a
Author: Stefan Haberland <sth@linux.vnet.ibm.com>
Date: Fri Feb 12 14:50:52 2016 +0100
s390/dasd: fix performance drop
commit 12d319b920fa673a4d5e7c1785c5dc82dcd15257 upstream.
Commit ca369d51b ("sd: Fix device-imposed transfer length limits")
introduced a new queue limit max_dev_sectors which limits the maximum
sectors for requests. The default value leads to small dasd requests
and therefor to a performance drop.
Set the max_dev_sectors value to the same value as the max_hw_sectors
to use the maximum available request size for DASD devices.
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e80d52bc8fb39da0208d73bb2a2ef7f10b7db2e
Author: Stefan Haberland <stefan.haberland@de.ibm.com>
Date: Tue Dec 15 10:45:05 2015 +0100
s390/dasd: fix refcount for PAV reassignment
commit 9d862ababb609439c5d6987f6d3ddd09e703aa0b upstream.
Add refcount to the DASD device when a summary unit check worker is
scheduled. This prevents that the device is set offline with worker
in place.
Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ecf5ebf51d9f006ca9c6a93f38847af8d8b0818c
Author: Stefan Haberland <stefan.haberland@de.ibm.com>
Date: Tue Dec 15 10:16:43 2015 +0100
s390/dasd: prevent incorrect length error under z/VM after PAV changes
commit 020bf042e5b397479c1174081b935d0ff15d1a64 upstream.
The channel checks the specified length and the provided amount of
data for CCWs and provides an incorrect length error if the size does
not match. Under z/VM with simulation activated the length may get
changed. Having the suppress length indication bit set is stated as
good CCW coding practice and avoids errors under z/VM.
Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee17e6e3ec5cf4b3cf23c3925e6969f520d4e10a
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri Jan 1 13:39:22 2016 +0100
s390: fix normalization bug in exception table sorting
commit bcb7825a77f41c7dd91da6f7ac10b928156a322e upstream.
The normalization pass in the sorting routine of the relative exception
table serves two purposes:
- it ensures that the address fields of the exception table entries are
fully ordered, so that no ambiguities arise between entries with
identical instruction offsets (i.e., when two instructions that are
exactly 8 bytes apart each have an exception table entry associated with
them)
- it ensures that the offsets of both the instruction and the fixup fields
of each entry are relative to their final location after sorting.
Commit eb608fb366de ("s390/exceptions: switch to relative exception table
entries") ported the relative exception table format from x86, but modified
the sorting routine to only normalize the instruction offset field and not
the fixup offset field. The result is that the fixup offset of each entry
will be relative to the original location of the entry before sorting,
likely leading to crashes when those entries are dereferenced.
Fixes: eb608fb366de ("s390/exceptions: switch to relative exception table entries")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e59ba555b270e1ab41efb6d632642dd3e5443303
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Jan 15 14:37:15 2016 +0100
btrfs: initialize the seq counter in struct btrfs_device
commit 546bed631203344611f42b2af1d224d2eedb4e6b upstream.
I managed to trigger this:
| INFO: trying to register non-static key.
| the code is fine but needs lockdep annotation.
| turning off the locking correctness validator.
| CPU: 1 PID: 781 Comm: systemd-gpt-aut Not tainted 4.4.0-rt2+ #14
| Hardware name: ARM-Versatile Express
| [<80307cec>] (dump_stack)
| [<80070e98>] (__lock_acquire)
| [<8007184c>] (lock_acquire)
| [<80287800>] (btrfs_ioctl)
| [<8012a8d4>] (do_vfs_ioctl)
| [<8012ac14>] (SyS_ioctl)
so I think that btrfs_device_data_ordered_init() is not invoked behind
a macro somewhere.
Fixes: 7cc8e58d53cd ("Btrfs: fix unprotected device's variants on 32bits machine")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8102f96ea48daf86a5f55c07699e926d8f9dee1f
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date: Thu Jan 7 18:56:59 2016 +0530
Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots
commit f32e48e925964c4f8ab917850788a87e1cef3bad upstream.
The following call trace is seen when btrfs/031 test is executed in a loop,
[ 158.661848] ------------[ cut here ]------------
[ 158.662634] WARNING: CPU: 2 PID: 890 at /home/chandan/repos/linux/fs/btrfs/ioctl.c:558 create_subvol+0x3d1/0x6ea()
[ 158.664102] BTRFS: Transaction aborted (error -2)
[ 158.664774] Modules linked in:
[ 158.665266] CPU: 2 PID: 890 Comm: btrfs Not tainted 4.4.0-rc6-g511711a #2
[ 158.666251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[ 158.667392] ffffffff81c0a6b0 ffff8806c7c4f8e8 ffffffff81431fc8 ffff8806c7c4f930
[ 158.668515] ffff8806c7c4f920 ffffffff81051aa1 ffff880c85aff000 ffff8800bb44d000
[ 158.669647] ffff8808863b5c98 0000000000000000 00000000fffffffe ffff8806c7c4f980
[ 158.670769] Call Trace:
[ 158.671153] [<ffffffff81431fc8>] dump_stack+0x44/0x5c
[ 158.671884] [<ffffffff81051aa1>] warn_slowpath_common+0x81/0xc0
[ 158.672769] [<ffffffff81051b27>] warn_slowpath_fmt+0x47/0x50
[ 158.673620] [<ffffffff813bc98d>] create_subvol+0x3d1/0x6ea
[ 158.674440] [<ffffffff813777c9>] btrfs_mksubvol.isra.30+0x369/0x520
[ 158.675376] [<ffffffff8108a4aa>] ? percpu_down_read+0x1a/0x50
[ 158.676235] [<ffffffff81377a81>] btrfs_ioctl_snap_create_transid+0x101/0x180
[ 158.677268] [<ffffffff81377b52>] btrfs_ioctl_snap_create+0x52/0x70
[ 158.678183] [<ffffffff8137afb4>] btrfs_ioctl+0x474/0x2f90
[ 158.678975] [<ffffffff81144b8e>] ? vma_merge+0xee/0x300
[ 158.679751] [<ffffffff8115be31>] ? alloc_pages_vma+0x91/0x170
[ 158.680599] [<ffffffff81123f62>] ? lru_cache_add_active_or_unevictable+0x22/0x70
[ 158.681686] [<ffffffff813d99cf>] ? selinux_file_ioctl+0xff/0x1d0
[ 158.682581] [<ffffffff8117b791>] do_vfs_ioctl+0x2c1/0x490
[ 158.683399] [<ffffffff813d3cde>] ? security_file_ioctl+0x3e/0x60
[ 158.684297] [<ffffffff8117b9d4>] SyS_ioctl+0x74/0x80
[ 158.685051] [<ffffffff819b2bd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
[ 158.685958] ---[ end trace 4b63312de5a2cb76 ]---
[ 158.686647] BTRFS: error (device loop0) in create_subvol:558: errno=-2 No such entry
[ 158.709508] BTRFS info (device loop0): forced readonly
[ 158.737113] BTRFS info (device loop0): disk space caching is enabled
[ 158.738096] BTRFS error (device loop0): Remounting read-write after error is not allowed
[ 158.851303] BTRFS error (device loop0): cleaner transaction attach returned -30
This occurs because,
Mount filesystem
Create subvol with ID 257
Unmount filesystem
Mount filesystem
Delete subvol with ID 257
btrfs_drop_snapshot()
Add root corresponding to subvol 257 into
btrfs_transaction->dropped_roots list
Create new subvol (i.e. create_subvol())
257 is returned as the next free objectid
btrfs_read_fs_root_no_name()
Finds the btrfs_root instance corresponding to the old subvol with ID 257
in btrfs_fs_info->fs_roots_radix.
Returns error since btrfs_root_item->refs has the value of 0.
To fix the issue the commit initializes tree root's and subvolume root's
highest_objectid when loading the roots from disk.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6edd99cfa44512924be856cdf68c974d52629ca
Author: Filipe Manana <fdmanana@suse.com>
Date: Tue Jan 5 16:24:05 2016 +0000
Btrfs: fix transaction handle leak on failure to create hard link
commit 271dba4521aed0c37c063548f876b49f5cd64b2e upstream.
If we failed to create a hard link we were not always releasing the
the transaction handle we got before, resulting in a memory leak and
preventing any other tasks from being able to commit the current
transaction.
Fix this by always releasing our transaction handle.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6362a1e3e428e101c0fc089b496f30e06b7e3c5
Author: Filipe Manana <fdmanana@suse.com>
Date: Thu Dec 31 18:16:29 2015 +0000
Btrfs: fix number of transaction units required to create symlink
commit 9269d12b2d57d9e3d13036bb750762d1110d425c upstream.
We weren't accounting for the insertion of an inline extent item for the
symlink inode nor that we need to update the parent inode item (through
the call to btrfs_add_nondir()). So fix this by including two more
transaction units.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d70554d661868f8fb87a5eda236a69b1e9b0e615
Author: Filipe Manana <fdmanana@suse.com>
Date: Thu Dec 31 18:07:59 2015 +0000
Btrfs: send, don't BUG_ON() when an empty symlink is found
commit a879719b8c90e15c9e7fa7266d5e3c0ca962f9df upstream.
When a symlink is successfully created it always has an inline extent
containing the source path. However if an error happens when creating
the symlink, we can leave in the subvolume's tree a symlink inode without
any such inline extent item - this happens if after btrfs_symlink() calls
btrfs_end_transaction() and before it calls the inode eviction handler
(through the final iput() call), the transaction gets committed and a
crash happens before the eviction handler gets called, or if a snapshot
of the subvolume is made before the eviction handler gets called. Sadly
we can't just avoid this by making btrfs_symlink() call
btrfs_end_transaction() after it calls the eviction handler, because the
later can commit the current transaction before it removes any items from
the subvolume tree (if it encounters ENOSPC errors while reserving space
for removing all the items).
So make send fail more gracefully, with an -EIO error, and print a
message to dmesg/syslog informing that there's an empty symlink inode,
so that the user can delete the empty symlink or do something else
about it.
Reported-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee695402b83a6c2f03a94aa4c7510adf1971e080
Author: David Sterba <dsterba@suse.com>
Date: Sat Oct 10 17:59:53 2015 +0200
btrfs: statfs: report zero available if metadata are exhausted
commit ca8a51b3a979d57b082b14eda38602b7f52d81d1 upstream.
There is one ENOSPC case that's very confusing. There's Available
greater than zero but no file operation succeds (besides removing
files). This happens when the metadata are exhausted and there's no
possibility to allocate another chunk.
In this scenario it's normal that there's still some space in the data
chunk and the calculation in df reflects that in the Avail value.
To at least give some clue about the ENOSPC situation, let statfs report
zero value in Avail, even if there's still data space available.
Current:
/dev/sdb1 4.0G 3.3G 719M 83% /mnt/test
New:
/dev/sdb1 4.0G 3.3G 0 100% /mnt/test
We calculate the remaining metadata space minus global reserve. If this
is (supposedly) smaller than zero, there's no space. But this does not
hold in practice, the exhausted state happens where's still some
positive delta. So we apply some guesswork and compare the delta to a 4M
threshold. (Practically observed delta was 2M.)
We probably cannot calculate the exact threshold value because this
depends on the internal reservations requested by various operations, so
some operations that consume a few metadata will succeed even if the
Avail is zero. But this is better than the other way around.
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1106639221ef3eb80f3436785948c36e63d45b62
Author: Josef Bacik <jbacik@fb.com>
Date: Thu Oct 22 15:05:09 2015 -0400
Btrfs: igrab inode in writepage
commit be7bd730841e69fe8f70120098596f648cd1f3ff upstream.
We hit this panic on a few of our boxes this week where we have an
ordered_extent with an NULL inode. We do an igrab() of the inode in writepages,
but weren't doing it in writepage which can be called directly from the VM on
dirty pages. If the inode has been unlinked then we could have I_FREEING set
which means igrab() would return NULL and we get this panic. Fix this by trying
to igrab in btrfs_writepage, and if it returns NULL then just redirty the page
and return AOP_WRITEPAGE_ACTIVATE; so the VM knows it wasn't successful. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98d41a063d6584acc62ba1429ae074eac5d9d127
Author: Anand Jain <anand.jain@oracle.com>
Date: Wed Oct 7 17:23:23 2015 +0800
Btrfs: add missing brelse when superblock checksum fails
commit b2acdddfad13c38a1e8b927d83c3cf321f63601a upstream.
Looks like oversight, call brelse() when checksum fails. Further down the
code, in the non error path, we do call brelse() and so we don't see
brelse() in the goto error paths.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3824f7874a7521961642287b4b93f14afbc9565a
Author: David Hildenbrand <dahi@linux.vnet.ibm.com>
Date: Thu Jan 14 22:12:47 2016 +0100
KVM: s390: fix memory overwrites when vx is disabled
commit 9abc2a08a7d665b02bdde974fd6c44aae86e923e upstream.
The kernel now always uses vector registers when available, however KVM
has special logic if support is really enabled for a guest. If support
is disabled, guest_fpregs.fregs will only contain memory for the fpu.
The kernel, however, will store vector registers into that area,
resulting in crazy memory overwrites.
Simply extending that area is not enough, because the format of the
registers also changes. We would have to do additional conversions, making
the code even more complex. Therefore let's directly use one place for
the vector/fpu registers + fpc (in kvm_run). We just have to convert the
data properly when accessing it. This makes current code much easier.
Please note that vector/fpu registers are now always stored to
vcpu->run->s.regs.vrs. Although this data is visible to QEMU and
used for migration, we only guarantee valid values to user space when
KVM_SYNC_VRS is set. As that is only the case when we have vector
register support, we are on the safe side.
Fixes: b5510d9b68c3 ("s390/fpu: always enable the vector facility if it is available")
Cc: stable@vger.kernel.org # v4.4 d9a3a09af54d s390/kvm: remove dependency on struct save_area definition
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
[adopt to d9a3a09af54d]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b5e7257409d78623717550d0f18bcf30003b4b2c
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Fri Oct 23 09:02:32 2015 +0200
s390/kvm: remove dependency on struct save_area definition
commit d9a3a09af54d01ab8b0c320580f4f95328d4a7ac upstream.
Replace the offsets based on the struct area_area with the offset
constants from asm-offsets.c based on the struct _lowcore.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 142ad71dd6de7368cc8cc5c52288b628062f391d
Author: Roman Volkov <rvolkov@v1ros.org>
Date: Fri Jan 1 16:24:41 2016 +0300
clocksource/drivers/vt8500: Increase the minimum delta
commit f9eccf24615672896dc13251410c3f2f33a14f95 upstream.
The vt8500 clocksource driver declares itself as capable to handle the
minimum delay of 4 cycles by passing the value into
clockevents_config_and_register(). The vt8500_timer_set_next_event()
requires the passed cycles value to be at least 16. The impact is that
userspace hangs in nanosleep() calls with small delay intervals.
This problem is reproducible in Linux 4.2 starting from:
c6eb3f70d448 ('hrtimer: Get rid of hrtimer softirq')
From Russell King, more detailed explanation:
"It's a speciality of the StrongARM/PXA hardware. It takes a certain
number of OSCR cycles for the value written to hit the compare registers.
So, if a very small delta is written (eg, the compare register is written
with a value of OSCR + 1), the OSCR will have incremented past this value
before it hits the underlying hardware. The result is, that you end up
waiting a very long time for the OSCR to wrap before the event fires.
So, we introduce a check in set_next_event() to detect this and return
-ETIME if the calculated delta is too small, which causes the generic
clockevents code to retry after adding the min_delta specified in
clockevents_config_and_register() to the current time value.
min_delta must be sufficient that we don't re-trip the -ETIME check - if
we do, we will return -ETIME, forward the next event time, try to set it,
return -ETIME again, and basically lock the system up. So, min_delta
must be larger than the check inside set_next_event(). A factor of two
was chosen to ensure that this situation would never occur.
The PXA code worked on PXA systems for years, and I'd suggest no one
changes this mechanism without access to a wide range of PXA systems,
otherwise they're risking breakage."
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Alexey Charkov <alchark@gmail.com>
Signed-off-by: Roman Volkov <rvolkov@v1ros.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 827685a637e0074e0d61d84eac4a50481c7e1b61
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jan 13 14:07:25 2016 +0100
genirq: Validate action before dereferencing it in handle_irq_event_percpu()
commit 570540d50710ed192e98e2f7f74578c9486b6b05 upstream.
commit 71f64340fc0e changed the handling of irq_desc->action from
CPU 0 CPU 1
free_irq() lock(desc)
lock(desc) handle_edge_irq()
if (desc->action) {
handle_irq_event()
action = desc->action
unlock(desc)
desc->action = NULL handle_irq_event_percpu(desc, action)
action->xxx
to
CPU 0 CPU 1
free_irq() lock(desc)
lock(desc) handle_edge_irq()
if (desc->action) {
handle_irq_event()
unlock(desc)
desc->action = NULL handle_irq_event_percpu(desc, action)
action = desc->action
action->xxx
So if free_irq manages to set the action to NULL between the unlock and before
the readout, we happily dereference a null pointer.
We could simply revert 71f64340fc0e, but we want to preserve the better code
generation. A simple solution is to change the action loop from a do {} while
to a while {} loop.
This is safe because we either see a valid desc->action or NULL. If the action
is about to be removed it is still valid as free_irq() is blocked on
synchronize_irq().
CPU 0 CPU 1
free_irq() lock(desc)
lock(desc) handle_edge_irq()
handle_irq_event(desc)
set(INPROGRESS)
unlock(desc)
handle_irq_event_percpu(desc)
action = desc->action
desc->action = NULL while (action) {
action->xxx
...
action = action->next;
sychronize_irq()
while(INPROGRESS); lock(desc)
clr(INPROGRESS)
free(action)
That's basically the same mechanism as we have for shared
interrupts. action->next can become NULL while handle_irq_event_percpu()
runs. Either it sees the action or NULL. It does not matter, because action
itself cannot go away before the interrupt in progress flag has been cleared.
Fixes: commit 71f64340fc0e "genirq: Remove the second parameter from handle_irq_event_percpu()"
Reported-by: zyjzyj2000@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Huang Shijie <shijie.huang@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1601131224190.3575@nanos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18b75e0bdc6c1413a44db3d37b6d1d82d02eb84b
Author: Mel Gorman <mgorman@techsingularity.net>
Date: Fri Feb 26 15:19:31 2016 -0800
mm: numa: quickly fail allocations for NUMA balancing on full nodes
commit 8479eba7781fa9ffb28268840de6facfc12c35a7 upstream.
Commit 4167e9b2cf10 ("mm: remove GFP_THISNODE") removed the GFP_THISNODE
flag combination due to confusing semantics. It noted that
alloc_misplaced_dst_page() was one such user after changes made by
commit e97ca8e5b864 ("mm: fix GFP_THISNODE callers and clarify").
Unfortunately when GFP_THISNODE was removed, users of
alloc_misplaced_dst_page() started waking kswapd and entering direct
reclaim because the wrong GFP flags are cleared. The consequence is
that workloads that used to fit into memory now get reclaimed which is
addressed by this patch.
The problem can be demonstrated with "mutilate" that exercises memcached
which is software dedicated to memory object caching. The configuration
uses 80% of memory and is run 3 times for varying numbers of clients.
The results on a 4-socket NUMA box are
mutilate
4.4.0 4.4.0
vanilla numaswap-v1
Hmean 1 8394.71 ( 0.00%) 8395.32 ( 0.01%)
Hmean 4 30024.62 ( 0.00%) 34513.54 ( 14.95%)
Hmean 7 32821.08 ( 0.00%) 70542.96 (114.93%)
Hmean 12 55229.67 ( 0.00%) 93866.34 ( 69.96%)
Hmean 21 39438.96 ( 0.00%) 85749.21 (117.42%)
Hmean 30 37796.10 ( 0.00%) 50231.49 ( 32.90%)
Hmean 47 18070.91 ( 0.00%) 38530.13 (113.22%)
The metric is queries/second with the more the better. The results are
way outside of the noise and the reason for the improvement is obvious
from some of the vmstats
4.4.0 4.4.0
vanillanumaswap-v1r1
Minor Faults 1929399272 2146148218
Major Faults 19746529 3567
Swap Ins 57307366 9913
Swap Outs 50623229 17094
Allocation stalls 35909 443
DMA allocs 0 0
DMA32 allocs 72976349 170567396
Normal allocs 5306640898 5310651252
Movable allocs 0 0
Direct pages scanned 404130893 799577
Kswapd pages scanned 160230174 0
Kswapd pages reclaimed 55928786 0
Direct pages reclaimed 1843936 41921
Page writes file 2391 0
Page writes anon 50623229 17094
The vanilla kernel is swapping like crazy with large amounts of direct
reclaim and kswapd activity. The figures are aggregate but it's known
that the bad activity is throughout the entire test.
Note that simple streaming anon/file memory consumers also see this
problem but it's not as obvious. In those cases, kswapd is awake when
it should not be.
As there are at least two reclaim-related bugs out there, it's worth
spelling out the user-visible impact. This patch only addresses bugs
related to excessive reclaim on NUMA hardware when the working set is
larger than a NUMA node. There is a bug related to high kswapd CPU
usage but the reports are against laptops and other UMA hardware and is
not addressed by this patch.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>
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>
commit 915d02457e74344bcd99fe64b159de2f6074b2c6
Author: Andrea Arcangeli <aarcange@redhat.com>
Date: Fri Feb 26 15:19:28 2016 -0800
mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED
commit ad33bb04b2a6cee6c1f99fabb15cddbf93ff0433 upstream.
pmd_trans_unstable()/pmd_none_or_trans_huge_or_clear_bad() were
introduced to locklessy (but atomically) detect when a pmd is a regular
(stable) pmd or when the pmd is unstable and can infinitely transition
from pmd_none() and pmd_trans_huge() from under us, while only holding
the mmap_sem for reading (for writing not).
While holding the mmap_sem only for reading, MADV_DONTNEED can run from
under us and so before we can assume the pmd to be a regular stable pmd
we need to compare it against pmd_none() and pmd_trans_huge() in an
atomic way, with pmd_trans_unstable(). The old pmd_trans_huge() left a
tiny window for a race.
Useful applications are unlikely to notice the difference as doing
MADV_DONTNEED concurrently with a page fault would lead to undefined
behavior.
[akpm@linux-foundation.org: tidy up comment grammar/layout]
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reported-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
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>
commit c88edc09363243dd84d6e8ac7a36773213b26ac8
Author: Guozhonghua <guozhonghua@h3c.com>
Date: Fri Feb 26 15:19:40 2016 -0800
ocfs2: unlock inode if deleting inode from orphan fails
commit a4a8481ff68a8a324a878e281bc37f18665224f7 upstream.
When doing append direct io cleanup, if deleting inode fails, it goes
out without unlocking inode, which will cause the inode deadlock.
This issue was introduced by commit cf1776a9e834 ("ocfs2: fix a tiny
race when truncate dio orohaned entry").
Signed-off-by: Guozhonghua <guozhonghua@h3c.com>
Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
Reviewed-by: Gang He <ghe@suse.com>
Cc: Mark Fasheh <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
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>
commit cc082a1cde269bb3b757162f2af113b134b876a1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab upstream.
We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR disagreeing. No idea what's going on there, but
it's consistent on gen8+, no one seems to care about it and it's
making CI results flaky.
Shut it up.
No idea what's going on here, but we've had fun with PCH interrupts
before:
commit 44498aea293b37af1d463acd9658cdce1ecdf427
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Feb 22 17:05:28 2013 -0300
drm/i915: also disable south interrupts when handling them
Note that there's a regression report in Bugzilla, and other
regression reports on the mailing lists keep croping up. But no ill
effects have ever been reported. But for paranoia still keep the
message at a debug level as a breadcrumb, just in case.
This message was introduced in
commit 38cc46d73ed99dd7002f1406002e52d7975d16cc
Author: Oscar Mateo <oscar.mateo@intel.com>
Date: Mon Jun 16 16:10:59 2014 +0100
drm/i915/bdw: Ack interrupts before handling them (GEN8)
v2: Improve commit message a bit.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 64fb3e29bf47e5db029b81fc99ac40f6cd2620ac
Author: Hariprasad S <hariprasad@chelsio.com>
Date: Fri Dec 11 13:59:17 2015 +0530
iw_cxgb3: Fix incorrectly returning error on success
commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 upstream.
The cxgb3_*_send() functions return NET_XMIT_ values, which are
positive integers values. So don't treat positive return values
as an error.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
[a pox on developers and maintainers who do not cc: stable for bug fixes like this - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50d60403753a0149c82e5b1851e0cd0499ddff4e
Author: Michael Welling <mwelling@ieee.org>
Date: Mon Nov 30 09:02:39 2015 -0600
spi: omap2-mcspi: Prevent duplicate gpio_request
commit 2f538c017e1a8620d19553931199c6d6a6d31bb2 upstream.
Occasionally the setup function will be called multiple times. Only request
the gpio the first time otherwise -EBUSY will occur on subsequent calls to
setup.
Reported-by: Joseph Bell <joe@iachieved.it>
Signed-off-by: Michael Welling <mwelling@ieee.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3e908446627523e106c1edc7cf6fe7706924d6d3
Author: Lisa Du <cldu@marvell.com>
Date: Wed Feb 17 09:32:52 2016 +0800
drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE
commit 7a64cd887fdb97f074c3fda03bee0bfb9faceac3 upstream.
There's one point was missed in the patch commit da49889deb34 ("staging:
binder: Support concurrent 32 bit and 64 bit processes."). When configure
BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
void * is 64bit on 64bit system. Correct it here.
Signed-off-by: Lisa Du <cldu@marvell.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 80d0fecf76920ea2e8f1d45522ac27d4d5ead892
Author: Bjørn Mork <bjorn@mork.no>
Date: Fri Feb 12 16:40:00 2016 +0100
USB: option: add "4G LTE usb-modem U901"
commit d061c1caa31d4d9792cfe48a2c6b309a0e01ef46 upstream.
Thomas reports:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=6001 Rev=00.00
S: Manufacturer=USB Modem
S: Product=USB Modem
S: SerialNumber=1234567890ABCDEF
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aed4333616e0eaabef465dd36bd7fef89ba23390
Author: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Date: Fri Jan 29 00:07:30 2016 +0300
USB: option: add support for SIM7100E
commit 3158a8d416f4e1b79dcc867d67cb50013140772c upstream.
$ lsusb:
Bus 001 Device 101: ID 1e0e:9001 Qualcomm / Option
$ usb-devices:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=101 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2
P: Vendor=1e0e ProdID=9001 Rev= 2.32
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech, Incorporated
S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
The last interface (6) is used for Android Composite ADB interface.
Serial port layout:
0: QCDM/DIAG
1: NMEA
2: AT
3: AT/PPP
4: audio
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a9d2586256f30fe0c4074fd7e845d517e0398df5
Author: Ken Lin <ken.lin@advantech.com.tw>
Date: Mon Feb 1 14:57:25 2016 -0500
USB: cp210x: add IDs for GE B650V3 and B850V3 boards
commit 6627ae19385283b89356a199d7f03c75ba35fb29 upstream.
Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards.
Signed-off-by: Ken Lin <ken.lin@advantech.com.tw>
Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8d634243df782ea93f650588d0abdfb63cd95f8
Author: John Youn <John.Youn@synopsys.com>
Date: Tue Feb 16 20:10:53 2016 -0800
usb: dwc3: Fix assignment of EP transfer resources
commit c450960187f45d4260db87c7dd4fc0bceb5565d8 upstream.
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.
The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:
1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.
2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).
The following simplified method is used instead:
All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.
This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.
Fixes: aebda6187181 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Reported-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f847ff0db6da0b42acb7447f8629dd2a33ddfe24
Author: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Date: Tue Dec 22 17:29:16 2015 +0100
can: ems_usb: Fix possible tx overflow
commit 90cfde46586d2286488d8ed636929e936c0c9ab2 upstream.
This patch fixes the problem that more CAN messages could be sent to the
interface as could be send on the CAN bus. This was more likely for slow baud
rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
heavy TX load this produced another bulk transfer without checking the
free_slots variable and hence caused the overflow in the interface.
Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c8a03a351257ae175d57c9c06f57ab95fc99db3
Author: Nikolay Borisov <kernel@kyup.com>
Date: Thu Dec 17 18:03:35 2015 +0200
dm thin: fix race condition when destroying thin pool workqueue
commit 18d03e8c25f173f4107a40d0b8c24defb6ed69f3 upstream.
When a thin pool is being destroyed delayed work items are
cancelled using cancel_delayed_work(), which doesn't guarantee that on
return the delayed item isn't running. This can cause the work item to
requeue itself on an already destroyed workqueue. Fix this by using
cancel_delayed_work_sync() which guarantees that on return the work item
is not running anymore.
Fixes: 905e51b39a555 ("dm thin: commit outstanding data every second")
Fixes: 85ad643b7e7e5 ("dm thin: add timeout to stop out-of-data-space mode holding IO forever")
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a556b804dfa654f054f3d304c2c4d274ffe81f92
Author: Kent Overstreet <kent.overstreet@gmail.com>
Date: Sun Nov 29 18:47:01 2015 -0800
bcache: Change refill_dirty() to always scan entire disk if necessary
commit 627ccd20b4ad3ba836472468208e2ac4dfadbf03 upstream.
Previously, it would only scan the entire disk if it was starting from
the very start of the disk - i.e. if the previous scan got to the end.
This was broken by refill_full_stripes(), which updates last_scanned so
that refill_dirty was never triggering the searched_from_start path.
But if we change refill_dirty() to always scan the entire disk if
necessary, regardless of what last_scanned was, the code gets cleaner
and we fix that bug too.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9e761c1b436d04823baa161c294fddc524750015
Author: Stefan Bader <stefan.bader@canonical.com>
Date: Sun Nov 29 18:44:49 2015 -0800
bcache: prevent crash on changing writeback_running
commit 8d16ce540c94c9d366eb36fc91b7154d92d6397b upstream.
Added a safeguard in the shutdown case. At least while not being
attached it is also possible to trigger a kernel bug by writing into
writeback_running. This change adds the same check before trying to
wake up the thread for that case.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b38798df6cca121e0df4c6a500408070eba24264
Author: Gabriel de Perthuis <g2p.code@gmail.com>
Date: Sun Nov 29 18:40:23 2015 -0800
bcache: allows use of register in udev to avoid "device_busy" error.
commit d7076f21629f8f329bca4a44dc408d94670f49e2 upstream.
Allows to use register, not register_quiet in udev to avoid "device_busy" error.
The initial patch proposed at https://lkml.org/lkml/2013/8/26/549 by Gabriel de Perthuis
<g2p.code@gmail.com> does not unlock the mutex and hangs the kernel.
See http://thread.gmane.org/gmane.linux.kernel.bcache.devel/2594 for the discussion.
Cc: Denis Bychkov <manover@gmail.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Gabriel de Perthuis <g2p.code@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d81b4c865e68a2db5997a6311dfe5c007dc16b7a
Author: Zheng Liu <wenqing.lz@taobao.com>
Date: Sun Nov 29 17:21:57 2015 -0800
bcache: unregister reboot notifier if bcache fails to unregister device
commit 2ecf0cdb2b437402110ab57546e02abfa68a716b upstream.
In bcache_init() function it forgot to unregister reboot notifier if
bcache fails to unregister a block device. This commit fixes this.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Tested-by: Joshua Schmid <jschmid@suse.com>
Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e086f9f3cf528eb27708618cc45ee3485d84cf2
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sun Nov 29 17:20:59 2015 -0800
bcache: fix a leak in bch_cached_dev_run()
commit 4d4d8573a8451acc9f01cbea24b7e55f04a252fe upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Tested-by: Joshua Schmid <jschmid@suse.com>
Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ebc85013f58e40ee47538481be5236671761c16
Author: Zheng Liu <wenqing.lz@taobao.com>
Date: Sun Nov 29 17:19:32 2015 -0800
bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device
commit fecaee6f20ee122ad75402c53d8278f9bb142ddc upstream.
This bug can be reproduced by the following script:
#!/bin/bash
bcache_sysfs="/sys/fs/bcache"
function clear_cache()
{
if [ ! -e $bcache_sysfs ]; then
echo "no bcache sysfs"
exit
fi
cset_uuid=$(ls -l $bcache_sysfs|head -n 2|tail -n 1|awk '{print $9}')
sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/detach"
sleep 5
sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/attach"
}
for ((i=0;i<10;i++)); do
clear_cache
done
The warning messages look like below:
[ 275.948611] ------------[ cut here ]------------
[ 275.963840] WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xb8/0xd0() (Tainted: P W
--------------- )
[ 275.979253] Hardware name: Tecal RH2285
[ 275.994106] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:09.0/0000:08:00.0/host4/target4:2:1/4:2:1:0/block/sdb/sdb1/bcache/cache'
[ 276.024105] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler
bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas
pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan]
[ 276.072643] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1
[ 276.089315] Call Trace:
[ 276.105801] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0
[ 276.122650] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50
[ 276.139361] [<ffffffff81205c08>] ? sysfs_add_one+0xb8/0xd0
[ 276.156012] [<ffffffff8120609b>] ? sysfs_do_create_link+0x12b/0x170
[ 276.172682] [<ffffffff81206113>] ? sysfs_create_link+0x13/0x20
[ 276.189282] [<ffffffffa03bda21>] ? bcache_device_link+0xc1/0x110 [bcache]
[ 276.205993] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache]
[ 276.222794] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache]
[ 276.239680] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110
[ 276.256594] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170
[ 276.273364] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0
[ 276.290133] [<ffffffff811890b1>] ? sys_write+0x51/0x90
[ 276.306368] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b
[ 276.322301] ---[ end trace 9f5d4fcdd0c3edfb ]---
[ 276.338241] ------------[ cut here ]------------
[ 276.354109] WARNING: at /home/wenqing.lz/bcache/bcache/super.c:720
bcache_device_link+0xdf/0x110 [bcache]() (Tainted: P W --------------- )
[ 276.386017] Hardware name: Tecal RH2285
[ 276.401430] Couldn't create device <-> cache set symlinks
[ 276.401759] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler
bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801
i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas
pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan]
[ 276.465477] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1
[ 276.482169] Call Trace:
[ 276.498610] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0
[ 276.515405] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50
[ 276.532059] [<ffffffffa03bda3f>] ? bcache_device_link+0xdf/0x110 [bcache]
[ 276.548808] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache]
[ 276.565569] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache]
[ 276.582418] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110
[ 276.599341] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170
[ 276.616142] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0
[ 276.632607] [<ffffffff811890b1>] ? sys_write+0x51/0x90
[ 276.648671] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b
[ 276.664756] ---[ end trace 9f5d4fcdd0c3edfc ]---
We forget to clear BCACHE_DEV_UNLINK_DONE flag in bcache_device_attach()
function when we attach a backing device first time. After detaching this
backing device, this flag will be true and sysfs_remove_link() isn't called in
bcache_device_unlink(). Then when we attach this backing device again,
sysfs_create_link() will return EEXIST error in bcache_device_link().
So the fix is trival and we clear this flag in bcache_device_link().
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Tested-by: Joshua Schmid <jschmid@suse.com>
Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4c87d7c2e5d6d20fb35066f3ee51e4bdc467d74
Author: Kent Overstreet <kmo@daterainc.com>
Date: Sun Nov 29 17:18:33 2015 -0800
bcache: Add a cond_resched() call to gc
commit c5f1e5adf956e3ba82d204c7c141a75da9fa449a upstream.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69ccf81eb6cf68f4533e97e355215e0796d7834b
Author: Zheng Liu <gnehzuil.liu@gmail.com>
Date: Sun Nov 29 17:17:05 2015 -0800
bcache: fix a livelock when we cause a huge number of cache misses
commit 2ef9ccbfcb90cf84bdba320a571b18b05c41101b upstream.
Subject : [PATCH v2] bcache: fix a livelock in btree lock
Date : Wed, 25 Feb 2015 20:32:09 +0800 (02/25/2015 04:32:09 AM)
This commit tries to fix a livelock in bcache. This livelock might
happen when we causes a huge number of cache misses simultaneously.
When we get a cache miss, bcache will execute the following path.
->cached_dev_make_request()
->cached_dev_read()
->cached_lookup()
->bch->btree_map_keys()
->btree_root() <------------------------
->bch_btree_map_keys_recurse() |
->cache_lookup_fn() |
->cached_dev_cache_miss() |
->bch_btree_insert_check_key() -|
[If btree->seq is not equal to seq + 1, we should return
EINTR and traverse btree again.]
In bch_btree_insert_check_key() function we first need to check upgrade
flag (op->lock == -1), and when this flag is true we need to release
read btree->lock and try to take write btree->lock. During taking and
releasing this write lock, btree->seq will be monotone increased in
order to prevent other threads modify this in cache miss (see btree.h:74).
But if there are some cache misses caused by some requested, we could
meet a livelock because btree->seq is always changed by others. Thus no
one can make progress.
This commit will try to take write btree->lock if it encounters a race
when we traverse btree. Although it sacrifice the scalability but we
can ensure that only one can modify the btree.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Tested-by: Joshua Schmid <jschmid@suse.com>
Tested-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Joshua Schmid <jschmid@suse.com>
Cc: Zhu Yanhai <zhu.yanhai@gmail.com>
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9e8afc94ffae6f7ab9ba77308a9ab53aaf10335e
Author: Jason Andryuk <jandryuk@gmail.com>
Date: Fri Feb 12 23:13:33 2016 +0000
lib/ucs2_string: Correct ucs2 -> utf8 conversion
commit a68075908a37850918ad96b056acc9ac4ce1bd90 upstream.
The comparisons should be >= since 0x800 and 0x80 require an additional bit
to store.
For the 3 byte case, the existing shift would drop off 2 more bits than
intended.
For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@coreos.com>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9168b9b4cd91c442041a5c3a3d9f9a5b1f8676f5
Author: Matt Fleming <matt@codeblueprint.co.uk>
Date: Mon Feb 15 10:34:05 2016 +0000
efi: Add pstore variables to the deletion whitelist
commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 upstream.
Laszlo explains why this is a good idea,
'This is because the pstore filesystem can be backed by UEFI variables,
and (for example) a crash might dump the last kilobytes of the dmesg
into a number of pstore entries, each entry backed by a separate UEFI
variable in the above GUID namespace, and with a variable name
according to the above pattern.
Please see "drivers/firmware/efi/efi-pstore.c".
While this patch series will not prevent the user from deleting those
UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
entry will continue to delete the backing UEFI variable), I think it
would be nice to preserve the possibility for the sysadmin to delete
Linux-created UEFI variables that carry portions of the crash log,
*without* having to mount the pstore filesystem.'
There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.
Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Tested-by: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 05913989c8892f6dc1726d03b0d8e680aec3c1a5
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:15 2016 -0500
efi: Make efivarfs entries immutable by default
commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 upstream.
"rm -rf" is bricking some peoples' laptops because of variables being
used to store non-reinitializable firmware driver data that's required
to POST the hardware.
These are 100% bugs, and they need to be fixed, but in the mean time it
shouldn't be easy to *accidentally* brick machines.
We have to have delete working, and picking which variables do and don't
work for deletion is quite intractable, so instead make everything
immutable by default (except for a whitelist), and make tools that
aren't quite so broad-spectrum unset the immutable flag.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5134c82b53ddd6f95317f159f62827d9cb7843e1
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:14 2016 -0500
efi: Make our variable validation list include the guid
commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f upstream.
All the variables in this list so far are defined to be in the global
namespace in the UEFI spec, so this just further ensures we're
validating the variables we think we are.
Including the guid for entries will become more important in future
patches when we decide whether or not to allow deletion of variables
based on presence in this list.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 542f954e2d5d4b22cb68fa4cd6b5dcdfd880fccd
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:13 2016 -0500
efi: Do variable name validation tests in utf8
commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 upstream.
Actually translate from ucs2 to utf8 before doing the test, and then
test against our other utf8 data, instead of fudging it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8df7c6d3bcef0f1711f1e775b2ffe0215f32011f
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:12 2016 -0500
efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
commit e0d64e6a880e64545ad7d55786aa84ab76bac475 upstream.
Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
all variable names fit in ASCII.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7f2a86c9106eb9417f4bc7b97f1dfa63140277a
Author: Peter Jones <pjones@redhat.com>
Date: Mon Feb 8 14:48:11 2016 -0500
lib/ucs2_string: Add ucs2 -> utf8 helper functions
commit 73500267c930baadadb0d02284909731baf151f7 upstream.
This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9453c72919e57ee0227c2d1c18538d85cc62346d
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Nov 19 15:03:57 2015 +0100
ARM: 8457/1: psci-smp is built only for SMP
commit be95485a0b8288a93402705730d3ea32f9f812b9 upstream.
The PSCI SMP implementation is built only when both CONFIG_SMP and
CONFIG_ARM_PSCI are set, so a configuration that has the latter
but not the former can get a link error when it tries to call
psci_smp_available().
arch/arm/mach-tegra/built-in.o: In function `tegra114_cpuidle_init':
cpuidle-tegra114.c:(.init.text+0x52a): undefined reference to `psci_smp_available'
This corrects the #ifdef in the psci.h header file to match the
Makefile conditional we have for building that function.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab3b00b70e5552d6060118952312f9c201218dc4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Nov 23 10:32:49 2015 +0100
drm/gma500: Use correct unref in the gem bo create function
commit d3e376f52d095103ca51dbda4d6ff8aaf488f98f upstream.
This is called without dev->struct_mutex held, we need to use the
_unlocked variant.
Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb7d70e1c3cefe4785a291af49c48ff70cf1525c
Author: Toshi Kani <toshi.kani@hpe.com>
Date: Sat Feb 20 14:32:24 2016 -0800
devm_memremap: Fix error value when memremap failed
commit 93f834df9c2d4e362dfdc4b05daa0a4e18814836 upstream.
devm_memremap() returns an ERR_PTR() value in case of error.
However, it returns NULL when memremap() failed. This causes
the caller, such as the pmem driver, to proceed and oops later.
Change devm_memremap() to return ERR_PTR(-ENXIO) when memremap()
failed.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa5f10879d2d745b67a0b21c91d788d8ac6717fe
Author: David Hildenbrand <dahi@linux.vnet.ibm.com>
Date: Fri Jan 22 14:55:56 2016 +0100
KVM: s390: fix guest fprs memory leak
commit 9c7ebb613bffea2feef4ec562ba1dbcaa810942b upstream.
fprs is never freed, therefore resulting in a memory leak if
kvm_vcpu_init() fails or the vcpu is destroyed.
Fixes: 9977e886cbbc ("s390/kernel: lazy restore fpu registers")
Reported-by: Eric Farman <farman@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db8bb76c6f9564e18d5dda4d89e4fc70dc83c3fd
Author: dann frazier <dann.frazier@canonical.com>
Date: Mon Jan 25 16:52:16 2016 -0700
arm64: errata: Add -mpc-relative-literal-loads to build flags
commit 67dfa1751ce71e629aad7c438e1678ad41054677 upstream.
GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses
adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419
is enabled, modules built with this toolchain fail to load:
module libahci: unsupported RELA relocation: 275
This patch fixes the problem by passing '-mpc-relative-literal-loads'
to the compiler.
Cc: stable@vger.kernel.org
Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
BugLink: http://bugs.launchpad.net/bugs/1533009
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Christophe Lyon <christophe.lyon@linaro.org>
Signed-off-by: Dann Frazier <dann.frazier@canonical.com>
[will: backport to 4.4-stable]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb10b5e76eac0a4ea6cd2350c8c9efdc620233ed
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Jan 18 10:45:00 2016 +0100
ARM: debug-ll: fix BCM63xx entry for multiplatform
commit 6c54809977de3c9e2ef9e9934a2c6625f7e161e7 upstream.
During my randconfig build testing, I found that a kernel with
DEBUG_AT91_UART and ARCH_BCM_63XX fails to build:
arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror]
It turns out that the DEBUG_UART_BCM63XX option is enabled whenever
the ARCH_BCM_63XX is, and that breaks multiplatform kernels because
we then end up using the UART address from BCM63XX rather than the
one we actually configured (if any).
This changes the BCM63XX options to only have one Kconfig option,
and only enable that if the user explicitly turns it on.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: b51312bebfa4 ("ARM: BCM63XX: add low-level UART debug support")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c3d1424dd42356a00e83b06c0a39629c4a7e5e3
Author: Jan Kara <jack@suse.com>
Date: Fri Feb 19 00:18:25 2016 -0500
ext4: fix bh->b_state corruption
commit ed8ad83808f009ade97ebbf6519bc3a97fefbc0c upstream.
ext4 can update bh->b_state non-atomically in _ext4_get_block() and
ext4_da_get_block_prep(). Usually this is fine since bh is just a
temporary storage for mapping information on stack but in some cases it
can be fully living bh attached to a page. In such case non-atomic
update of bh->b_state can race with an atomic update which then gets
lost. Usually when we are mapping bh and thus updating bh->b_state
non-atomically, nobody else touches the bh and so things work out fine
but there is one case to especially worry about: ext4_finish_bio() uses
BH_Uptodate_Lock on the first bh in the page to synchronize handling of
PageWriteback state. So when blocksize < pagesize, we can be atomically
modifying bh->b_state of a buffer that actually isn't under IO and thus
can race e.g. with delalloc trying to map that buffer. The result is
that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the
corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.
Fix the problem by always updating bh->b_state bits atomically.
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
[NB: Backported to 4.4.2]
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c2efb14a21bfbd445b9bb6204ac4b33adcab785
Author: Neil Horman <nhorman@tuxdriver.com>
Date: Thu Feb 18 16:10:57 2016 -0500
sctp: Fix port hash table size computation
[ Upstream commit d9749fb5942f51555dc9ce1ac0dbb1806960a975 ]
Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
its size computation, observing that the current method never guaranteed
that the hashsize (measured in number of entries) would be a power of two,
which the input hash function for that table requires. The root cause of
the problem is that two values need to be computed (one, the allocation
order of the storage requries, as passed to __get_free_pages, and two the
number of entries for the hash table). Both need to be ^2, but for
different reasons, and the existing code is simply computing one order
value, and using it as the basis for both, which is wrong (i.e. it assumes
that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).
To fix this, we change the logic slightly. We start by computing a goal
allocation order (which is limited by the maximum size hash table we want
to support. Then we attempt to allocate that size table, decreasing the
order until a successful allocation is made. Then, with the resultant
successful order we compute the number of buckets that hash table supports,
which we then round down to the nearest power of two, giving us the number
of entries the table actually supports.
I've tested this locally here, using non-debug and spinlock-debug kernels,
and the number of entries in the hashtable consistently work out to be
powers of two in all cases.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
CC: Dmitry Vyukov <dvyukov@google.com>
CC: Vladislav Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 82f26aa4a5537b080c0cf71f0f1016c37f01d25e
Author: Dmitry V. Levin <ldv@altlinux.org>
Date: Fri Feb 19 04:27:48 2016 +0300
unix_diag: fix incorrect sign extension in unix_lookup_by_ino
[ Upstream commit b5f0549231ffb025337be5a625b0ff9f52b016f0 ]
The value passed by unix_diag_get_exact to unix_lookup_by_ino has type
__u32, but unix_lookup_by_ino's argument ino has type int, which is not
a problem yet.
However, when ino is compared with sock_i_ino return value of type
unsigned long, ino is sign extended to signed long, and this results
to incorrect comparison on 64-bit architectures for inode numbers
greater than INT_MAX.
This bug was found by strace test suite.
Fixes: 5d3cae8bc39d ("unix_diag: Dumping exact socket core")
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4ac39c3e2c80000a40b11bde33f425a44f1ef55b
Author: Insu Yun <wuninsu@gmail.com>
Date: Wed Feb 17 11:47:35 2016 -0500
tipc: unlock in error path
[ Upstream commit b53ce3e7d407aa4196877a48b8601181162ab158 ]
tipc_bcast_unlock need to be unlocked in error path.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7c2e2acc62c3c1a7d2b36032fd14ee53417fa7d
Author: Anton Protopopov <a.s.protopopov@gmail.com>
Date: Tue Feb 16 21:43:16 2016 -0500
rtnl: RTM_GETNETCONF: fix wrong return value
[ Upstream commit a97eb33ff225f34a8124774b3373fd244f0e83ce ]
An error response from a RTM_GETNETCONF request can return the positive
error value EINVAL in the struct nlmsgerr that can mislead userspace.
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b87f63bf814c3c8445d3e2baca204a37753fc92
Author: Phil Sutter <phil@nwl.cc>
Date: Wed Feb 17 15:37:43 2016 +0100
IFF_NO_QUEUE: Fix for drivers not calling ether_setup()
[ Upstream commit a813104d923339144078939175faf4e66aca19b4 ]
My implementation around IFF_NO_QUEUE driver flag assumed that leaving
tx_queue_len untouched (specifically: not setting it to zero) by drivers
would make it possible to assign a regular qdisc to them without having
to worry about setting tx_queue_len to a useful value. This was only
partially true: I overlooked that some drivers don't call ether_setup()
and therefore not initialize tx_queue_len to the default value of 1000.
Consequently, removing the workarounds in place for that case in qdisc
implementations which cared about it (namely, pfifo, bfifo, gred, htb,
plug and sfb) leads to problems with these specific interface types and
qdiscs.
Luckily, there's already a sanitization point for drivers setting
tx_queue_len to zero, which can be reused to assign the fallback value
most qdisc implementations used, which is 1.
Fixes: 348e3435cbefa ("net: sched: drop all special handling of tx_queue_len == 0")
Tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9653359eb65cfd56036cded9d41a111d1a9c817a
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 18 05:39:18 2016 -0800
tcp/dccp: fix another race at listener dismantle
[ Upstream commit 7716682cc58e305e22207d5bb315f26af6b1e243 ]
Ilya reported following lockdep splat:
kernel: =========================
kernel: [ BUG: held lock freed! ]
kernel: 4.5.0-rc1-ceph-00026-g5e0a311 #1 Not tainted
kernel: -------------------------
kernel: swapper/5/0 is freeing memory
ffff880035c9d200-ffff880035c9dbff, with a lock still held there!
kernel: (&(&queue->rskq_lock)->rlock){+.-...}, at:
[<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0
kernel: 4 locks held by swapper/5/0:
kernel: #0: (rcu_read_lock){......}, at: [<ffffffff8169ef6b>]
netif_receive_skb_internal+0x4b/0x1f0
kernel: #1: (rcu_read_lock){......}, at: [<ffffffff816e977f>]
ip_local_deliver_finish+0x3f/0x380
kernel: #2: (slock-AF_INET){+.-...}, at: [<ffffffff81685ffb>]
sk_clone_lock+0x19b/0x440
kernel: #3: (&(&queue->rskq_lock)->rlock){+.-...}, at:
[<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0
To properly fix this issue, inet_csk_reqsk_queue_add() needs
to return to its callers if the child as been queued
into accept queue.
We also need to make sure listener is still there before
calling sk->sk_data_ready(), by holding a reference on it,
since the reference carried by the child can disappear as
soon as the child is put on accept queue.
Reported-by: Ilya Dryomov <idryomov@gmail.com>
Fixes: ebb516af60e1 ("tcp/dccp: fix race at listener dismantle phase")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 54d77a2201647b826f4be34a95c726dacde1e57b
Author: Xin Long <lucien.xin@gmail.com>
Date: Thu Feb 18 21:21:19 2016 +0800
route: check and remove route cache when we get route
[ Upstream commit deed49df7390d5239024199e249190328f1651e7 ]
Since the gc of ipv4 route was removed, the route cached would has
no chance to be removed, and even it has been timeout, it still could
be used, cause no code to check it's expires.
Fix this issue by checking and removing route cache when we get route.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d4775ea09519074dd41039a39dbcb589390ae08f
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Thu Feb 18 07:38:04 2016 -0500
net_sched fix: reclassification needs to consider ether protocol changes
[ Upstream commit 619fe32640b4b01f370574d50344ae0f62689816 ]
actions could change the etherproto in particular with ethernet
tunnelled data. Typically such actions, after peeling the outer header,
will ask for the packet to be reclassified. We then need to restart
the classification with the new proto header.
Example setup used to catch this:
sudo tc qdisc add dev $ETH ingress
sudo $TC filter add dev $ETH parent ffff: pref 1 protocol 802.1Q \
u32 match u32 0 0 flowid 1:1 \
action vlan pop reclassify
Fixes: 3b3ae880266d ("net: sched: consolidate tc_classify{,_compat}")
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26fd5ed6e8ad66c86eb720cf85d1230c9b45a5f9
Author: Guillaume Nault <g.nault@alphalink.fr>
Date: Mon Feb 15 17:01:10 2016 +0100
pppoe: fix reference counting in PPPoE proxy
[ Upstream commit 29e73269aa4d36f92b35610c25f8b01c789b0dc8 ]
Drop reference on the relay_po socket when __pppoe_xmit() succeeds.
This is already handled correctly in the error path.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9f13d3fa0781ae13051fa644f715d3556244ac7
Author: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Date: Mon Feb 15 16:24:44 2016 +1300
l2tp: Fix error creating L2TP tunnels
[ Upstream commit 853effc55b0f975abd6d318cca486a9c1b67e10f ]
A previous commit (33f72e6) added notification via netlink for tunnels
when created/modified/deleted. If the notification returned an error,
this error was returned from the tunnel function. If there were no
listeners, the error code ESRCH was returned, even though having no
listeners is not an error. Other calls to this and other similar
notification functions either ignore the error code, or filter ESRCH.
This patch checks for ESRCH and does not flag this as an error.
Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1cabc3e35f4b2855c46e4e94fc3b93dd9a307327
Author: Eugenia Emantayev <eugenia@mellanox.com>
Date: Wed Feb 17 17:24:27 2016 +0200
net/mlx4_en: Avoid changing dev->features directly in run-time
[ Upstream commit 925ab1aa9394bbaeac47ee5b65d3fdf0fb8135cf ]
It's forbidden to manually change dev->features in run-time. Currently, this is
done in the driver to make sure that GSO_UDP_TUNNEL is advertized only when
VXLAN tunnel is set. However, since the stack actually does features intersection
with hw_enc_features, we can safely revert to advertizing features early when
registering the netdevice.
Fixes: f4a1edd56120 ('net/mlx4_en: Advertize encapsulation offloads [...]')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7675c3c6bdf9f59ad994334ce05c839ca27dd6a8
Author: Eugenia Emantayev <eugenia@mellanox.com>
Date: Wed Feb 17 17:24:23 2016 +0200
net/mlx4_en: Choose time-stamping shift value according to HW frequency
[ Upstream commit 31c128b66e5b28f468076e4f3ca3025c35342041 ]
Previously, the shift value used for time-stamping was constant and didn't
depend on the HW chip frequency. Change that to take the frequency into account
and calculate the maximal value in cycles per wraparound of ten seconds. This
time slot was chosen since it gives a good accuracy in time synchronization.
Algorithm for shift value calculation:
* Round up the maximal value in cycles to nearest power of two
* Calculate maximal multiplier by division of all 64 bits set
to above result
* Then, invert the function clocksource_khz2mult() to get the shift from
maximal mult value
Fixes: ec693d47010e ('net/mlx4_en: Add HW timestamping (TS) support')
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Reviewed-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b7abf72216b4ac632724eda3b99f6ebad5a6518
Author: Amir Vadai <amir@vadai.me>
Date: Wed Feb 17 17:24:22 2016 +0200
net/mlx4_en: Count HW buffer overrun only once
[ Upstream commit 281e8b2fdf8e4ef366b899453cae50e09b577ada ]
RdropOvflw counts overrun of HW buffer, therefore should
be used for rx_fifo_errors only.
Currently RdropOvflw counter is mistakenly also set into
rx_missed_errors and rx_over_errors too, which makes the
device total dropped packets accounting to show wrong results.
Fix that. Use it for rx_fifo_errors only.
Fixes: c27a02cd94d6 ('mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC')
Signed-off-by: Amir Vadai <amir@vadai.me>
Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 617d22ddf6b7ddf3860ac3d70e0e73b453e2afb9
Author: Bjørn Mork <bjorn@mork.no>
Date: Fri Feb 12 16:42:14 2016 +0100
qmi_wwan: add "4G LTE usb-modem U901"
[ Upstream commit aac8d3c282e024c344c5b86dc1eab7af88bb9716 ]
Thomas reports:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=6001 Rev=00.00
S: Manufacturer=USB Modem
S: Product=USB Modem
S: SerialNumber=1234567890ABCDEF
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4b84d5efbb2aabfb728d717c851eb1e6f521bec
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 11 22:50:29 2016 -0800
tcp: md5: release request socket instead of listener
[ Upstream commit 729235554d805c63e5e274fcc6a98e71015dd847 ]
If tcp_v4_inbound_md5_hash() returns an error, we must release
the refcount on the request socket, not on the listener.
The bug was added for IPv4 only.
Fixes: 079096f103fac ("tcp/dccp: install syn_recv requests into ehash table")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 692925fe2d42092a99d3532cb03932c8fda57786
Author: Jon Paul Maloy <jon.maloy@ericsson.com>
Date: Wed Feb 10 16:14:57 2016 -0500
tipc: fix premature addition of node to lookup table
[ Upstream commit d5c91fb72f1652ea3026925240a0998a42ddb16b ]
In commit 5266698661401a ("tipc: let broadcast packet reception
use new link receive function") we introduced a new per-node
broadcast reception link instance. This link is created at the
moment the node itself is created. Unfortunately, the allocation
is done after the node instance has already been added to the node
lookup hash table. This creates a potential race condition, where
arriving broadcast packets are able to find and access the node
before it has been fully initialized, and before the above mentioned
link has been created. The result is occasional crashes in the function
tipc_bcast_rcv(), which is trying to access the not-yet existing link.
We fix this by deferring the addition of the node instance until after
it has been fully initialized in the function tipc_node_create().
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1bd367857b7f884db302703c624f88adfd8eb171
Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Date: Thu Feb 11 19:37:27 2016 +0000
af_unix: Guard against other == sk in unix_dgram_sendmsg
[ Upstream commit a5527dda344fff0514b7989ef7a755729769daa1 ]
The unix_dgram_sendmsg routine use the following test
if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {
to determine if sk and other are in an n:1 association (either
established via connect or by using sendto to send messages to an
unrelated socket identified by address). This isn't correct as the
specified address could have been bound to the sending socket itself or
because this socket could have been connected to itself by the time of
the unix_peer_get but disconnected before the unix_state_lock(other). In
both cases, the if-block would be entered despite other == sk which
might either block the sender unintentionally or lead to trying to unlock
the same spin lock twice for a non-blocking send. Add a other != sk
check to guard against this.
Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
Reported-By: Philipp Hahn <pmhahn@pmhahn.de>
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Tested-by: Philipp Hahn <pmhahn@pmhahn.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f46f069ccfb28e6fdaa6798544fd30b72835b04
Author: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Date: Mon Feb 8 18:47:19 2016 +0000
af_unix: Don't set err in unix_stream_read_generic unless there was an error
[ Upstream commit 1b92ee3d03af6643df395300ba7748f19ecdb0c5 ]
The present unix_stream_read_generic contains various code sequences of
the form
err = -EDISASTER;
if (<test>)
goto out;
This has the unfortunate side effect of possibly causing the error code
to bleed through to the final
out:
return copied ? : err;
and then to be wrongly returned if no data was copied because the caller
didn't supply a data buffer, as demonstrated by the program available at
http://pad.lv/1540731
Change it such that err is only set if an error condition was detected.
Fixes: 3822b5c2fc62 ("af_unix: Revert 'lock_interruptible' in stream receive code")
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6b567a1abd72a4deb95126f164afcf62a3e091a1
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Feb 4 06:23:28 2016 -0800
ipv4: fix memory leaks in ip_cmsg_send() callers
[ Upstream commit 919483096bfe75dda338e98d56da91a263746a0a ]
Dmitry reported memory leaks of IP options allocated in
ip_cmsg_send() when/if this function returns an error.
Callers are responsible for the freeing.
Many thanks to Dmitry for the report and diagnostic.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07cc96fb15fecbd7f17c1d49eafcf127d3f5709f
Author: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Tue Feb 2 13:35:56 2016 -0800
bonding: Fix ARP monitor validation
[ Upstream commit 21a75f0915dde8674708b39abfcda113911c49b1 ]
The current logic in bond_arp_rcv will accept an incoming ARP for
validation if (a) the receiving slave is either "active" (which includes
the currently active slave, or the current ARP slave) or, (b) there is a
currently active slave, and it has received an ARP since it became active.
For case (b), the receiving slave isn't the currently active slave, and is
receiving the original broadcast ARP request, not an ARP reply from the
target.
This logic can fail if there is no currently active slave. In
this situation, the ARP probe logic cycles through all slaves, assigning
each in turn as the "current_arp_slave" for one arp_interval, then setting
that one as "active," and sending an ARP probe from that slave. The
current logic expects the ARP reply to arrive on the sending
current_arp_slave, however, due to switch FDB updating delays, the reply
may be directed to another slave.
This can arise if the bonding slaves and switch are working, but
the ARP target is not responding. When the ARP target recovers, a
condition may result wherein the ARP target host replies faster than the
switch can update its forwarding table, causing each ARP reply to be sent
to the previous current_arp_slave. This will never pass the logic in
bond_arp_rcv, as neither of the above conditions (a) or (b) are met.
Some experimentation on a LAN shows ARP reply round trips in the
200 usec range, but my available switches never update their FDB in less
than 4000 usec.
This patch changes the logic in bond_arp_rcv to additionally
accept an ARP reply for validation on any slave if there is a current ARP
slave and it sent an ARP probe during the previous arp_interval.
Fixes: aeea64ac717a ("bonding: don't trust arp requests unless active slave really works")
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a34f2f9f2034f7984f9529002c6fffe9cb63189d
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed Feb 10 16:47:11 2016 +0100
bpf: fix branch offset adjustment on backjumps after patching ctx expansion
[ Upstream commit a1b14d27ed0965838350f1377ff97c93ee383492 ]
When ctx access is used, the kernel often needs to expand/rewrite
instructions, so after that patching, branch offsets have to be
adjusted for both forward and backward jumps in the new eBPF program,
but for backward jumps it fails to account the delta. Meaning, for
example, if the expansion happens exactly on the insn that sits at
the jump target, it doesn't fix up the back jump offset.
Analysis on what the check in adjust_branches() is currently doing:
/* adjust offset of jmps if necessary */
if (i < pos && i + insn->off + 1 > pos)
insn->off += delta;
else if (i > pos && i + insn->off + 1 < pos)
insn->off -= delta;
First condition (forward jumps):
Before: After:
insns[0] insns[0]
insns[1] <--- i/insn insns[1] <--- i/insn
insns[2] <--- pos insns[P] <--- pos
insns[3] insns[P] `------| delta
insns[4] <--- target_X insns[P] `-----|
insns[5] insns[3]
insns[4] <--- target_X
insns[5]
First case is if we cross pos-boundary and the jump instruction was
before pos. This is handeled correctly. I.e. if i == pos, then this
would mean our jump that we currently check was the patchlet itself
that we just injected. Since such patchlets are self-contained and
have no awareness of any insns before or after the patched one, the
delta is correctly not adjusted. Also, for the second condition in
case of i + insn->off + 1 == pos, means we jump to that newly patched
instruction, so no offset adjustment are needed. That part is correct.
Second condition (backward jumps):
Before: After:
insns[0] insns[0]
insns[1] <--- target_X insns[1] <--- target_X
insns[2] <--- pos <-- target_Y insns[P] <--- pos <-- target_Y
insns[3] insns[P] `------| delta
insns[4] <--- i/insn insns[P] `-----|
insns[5] insns[3]
insns[4] <--- i/insn
insns[5]
Second interesting case is where we cross pos-boundary and the jump
instruction was after pos. Backward jump with i == pos would be
impossible and pose a bug somewhere in the patchlet, so the first
condition checking i > pos is okay only by itself. However, i +
insn->off + 1 < pos does not always work as intended to trigger the
adjustment. It works when jump targets would be far off where the
delta wouldn't matter. But, for example, where the fixed insn->off
before pointed to pos (target_Y), it now points to pos + delta, so
that additional room needs to be taken into account for the check.
This means that i) both tests here need to be adjusted into pos + delta,
and ii) for the second condition, the test needs to be <= as pos
itself can be a target in the backjump, too.
Fixes: 9bac3d6d548e ("bpf: allow extended BPF programs access skb fields")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b083b36ce3c91abe5ef7b51393d8af66c19fb594
Author: Alexander Duyck <aduyck@mirantis.com>
Date: Tue Feb 9 02:49:54 2016 -0800
flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen
[ Upstream commit 461547f3158978c180d74484d58e82be9b8e7357 ]
This patch fixes an issue with unaligned accesses when using
eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
The fact is when trying to check the length we don't need to be looking at
the flow label so we can reorder the checks to first check if we are
supposed to gather the flow label and then make the call to actually get
it.
v2: Updated path so that either STOP_AT_FLOW_LABEL or KEY_FLOW_LABEL can
cause us to check for the flow label.
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3865b8bb55897cef3ebb23da090a2b756ddf9d6
Author: Alexander Duyck <aduyck@mirantis.com>
Date: Tue Feb 9 06:14:43 2016 -0800
net: Copy inner L3 and L4 headers as unaligned on GRE TEB
[ Upstream commit 78565208d73ca9b654fb9a6b142214d52eeedfd1 ]
This patch corrects the unaligned accesses seen on GRE TEB tunnels when
generating hash keys. Specifically what this patch does is make it so that
we force the use of skb_copy_bits when the GRE inner headers will be
unaligned due to NET_IP_ALIGNED being a non-zero value.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Acked-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2038fb6f957cb3367117ba8c91f2372dd28753aa
Author: Xin Long <lucien.xin@gmail.com>
Date: Wed Feb 3 23:33:30 2016 +0800
sctp: translate network order to host order when users get a hmacid
[ Upstream commit 7a84bd46647ff181eb2659fdc99590e6f16e501d ]
Commit ed5a377d87dc ("sctp: translate host order to network order when
setting a hmacid") corrected the hmacid byte-order when setting a hmacid.
but the same issue also exists on getting a hmacid.
We fix it by changing hmacids to host order when users get them with
getsockopt.
Fixes: Commit ed5a377d87dc ("sctp: translate host order to network order when setting a hmacid")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff9140071bfb29199504563697056f51f9778f9f
Author: Sandeep Pillai <sanpilla@cisco.com>
Date: Wed Feb 3 14:40:44 2016 +0530
enic: increment devcmd2 result ring in case of timeout
[ Upstream commit ca7f41a4957b872577807169bd7464b36aae9b9c ]
Firmware posts the devcmd result in result ring. In case of timeout, driver
does not increment the current result pointer and firmware could post the
result after timeout has occurred. During next devcmd, driver would be
reading the result of previous devcmd.
Fix this by incrementing result even in case of timeout.
Fixes: 373fb0873d43 ("enic: add devcmd2")
Signed-off-by: Sandeep Pillai <sanpilla@cisco.com>
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98673eb04022285598ae9b62aa314d5ea65e2c27
Author: Siva Reddy Kallam <siva.kallam@broadcom.com>
Date: Wed Feb 3 14:09:38 2016 +0530
tg3: Fix for tg3 transmit queue 0 timed out when too many gso_segs
[ Upstream commit b7d987295c74500b733a0ba07f9a9bcc4074fa83 ]
tg3_tso_bug() can hit a condition where the entire tx ring is not big
enough to segment the GSO packet. For example, if MSS is very small,
gso_segs can exceed the tx ring size. When we hit the condition, it
will cause tx timeout.
tg3_tso_bug() is called to handle TSO and DMA hardware bugs.
For TSO bugs, if tg3_tso_bug() cannot succeed, we have to drop the packet.
For DMA bugs, we can still fall back to linearize the SKB and let the
hardware transmit the TSO packet.
This patch adds a function tg3_tso_bug_gso_check() to check if there
are enough tx descriptors for GSO before calling tg3_tso_bug().
The caller will then handle the error appropriately - drop or
lineraize the SKB.
v2: Corrected patch description to avoid confusion.
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Acked-by: Prashant Sreedharan <prashant@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1bec5f40664ccef7efa54102c5e29ac52c7db634
Author: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
Date: Wed Feb 3 09:26:57 2016 +0100
net:Add sysctl_max_skb_frags
[ Upstream commit 5f74f82ea34c0da80ea0b49192bb5ea06e063593 ]
Devices may have limits on the number of fragments in an skb they support.
Current codebase uses a constant as maximum for number of fragments one
skb can hold and use.
When enabling scatter/gather and running traffic with many small messages
the codebase uses the maximum number of fragments and may thereby violate
the max for certain devices.
The patch introduces a global variable as max number of fragments.
Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
Reviewed-by: HÃ¥kon Bugge <haakon.bugge@oracle.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2679161c7712b175053d49536409c4450398067f
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Feb 2 19:31:12 2016 -0800
tcp: do not drop syn_recv on all icmp reports
[ Upstream commit 9cf7490360bf2c46a16b7525f899e4970c5fc144 ]
Petr Novopashenniy reported that ICMP redirects on SYN_RECV sockets
were leading to RST.
This is of course incorrect.
A specific list of ICMP messages should be able to drop a SYN_RECV.
For instance, a REDIRECT on SYN_RECV shall be ignored, as we do
not hold a dst per SYN_RECV pseudo request.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111751
Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
Reported-by: Petr Novopashenniy <pety@rusnet.ru>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ba9b9f2409168fb50d0a0758b922508e7885f48
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed Feb 3 02:11:03 2016 +0100
unix: correctly track in-flight fds in sending process user_struct
[ Upstream commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 ]
The commit referenced in the Fixes tag incorrectly accounted the number
of in-flight fds over a unix domain socket to the original opener
of the file-descriptor. This allows another process to arbitrary
deplete the original file-openers resource limit for the maximum of
open files. Instead the sending processes and its struct cred should
be credited.
To do so, we add a reference counted struct user_struct pointer to the
scm_fp_list and use it to account for the number of inflight unix fds.
Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4c890233fdee1312190b0db8b664baf2ff9a4ad8
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Feb 2 17:55:01 2016 -0800
ipv6: fix a lockdep splat
[ Upstream commit 44c3d0c1c0a880354e9de5d94175742e2c7c9683 ]
Silence lockdep false positive about rcu_dereference() being
used in the wrong context.
First one should use rcu_dereference_protected() as we own the spinlock.
Second one should be a normal assignation, as no barrier is needed.
Fixes: 18367681a10bd ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cdbc66828d250b463c0ca3a1e715965b57f2c1a3
Author: subashab@codeaurora.org <subashab@codeaurora.org>
Date: Tue Feb 2 02:11:10 2016 +0000
ipv6: addrconf: Fix recursive spin lock call
[ Upstream commit 16186a82de1fdd868255448274e64ae2616e2640 ]
A rcu stall with the following backtrace was seen on a system with
forwarding, optimistic_dad and use_optimistic set. To reproduce,
set these flags and allow ipv6 autoconf.
This occurs because the device write_lock is acquired while already
holding the read_lock. Back trace below -
INFO: rcu_preempt self-detected stall on CPU { 1} (t=2100 jiffies
g=3992 c=3991 q=4471)
<6> Task dump for CPU 1:
<2> kworker/1:0 R running task 12168 15 2 0x00000002
<2> Workqueue: ipv6_addrconf addrconf_dad_work
<6> Call trace:
<2> [<ffffffc000084da8>] el1_irq+0x68/0xdc
<2> [<ffffffc000cc4e0c>] _raw_write_lock_bh+0x20/0x30
<2> [<ffffffc000bc5dd8>] __ipv6_dev_ac_inc+0x64/0x1b4
<2> [<ffffffc000bcbd2c>] addrconf_join_anycast+0x9c/0xc4
<2> [<ffffffc000bcf9f0>] __ipv6_ifa_notify+0x160/0x29c
<2> [<ffffffc000bcfb7c>] ipv6_ifa_notify+0x50/0x70
<2> [<ffffffc000bd035c>] addrconf_dad_work+0x314/0x334
<2> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
<2> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
<2> [<ffffffc0000bb40c>] kthread+0xe0/0xec
v2: do addrconf_dad_kick inside read lock and then acquire write
lock for ipv6_ifa_notify as suggested by Eric
Fixes: 7fd2561e4ebdd ("net: ipv6: Add a sysctl to make optimistic
addresses useful candidates")
Cc: Eric Dumazet <edumazet@google.com>
Cc: Erik Kline <ek@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1c4e14bf12eb0a7179eedde41e3a94877a08802
Author: Paolo Abeni <pabeni@redhat.com>
Date: Fri Jan 29 12:30:20 2016 +0100
ipv6/udp: use sticky pktinfo egress ifindex on connect()
[ Upstream commit 1cdda91871470f15e79375991bd2eddc6e86ddb1 ]
Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space application calls connect()
before sendmsg().
Fix it by initializing properly flowi6_oif in connect() before
performing the route lookup.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e8e729ccd2fee9f0445c4949a1aa7dd610bfa8bd
Author: Paolo Abeni <pabeni@redhat.com>
Date: Fri Jan 29 12:30:19 2016 +0100
ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()
[ Upstream commit 6f21c96a78b835259546d8f3fb4edff0f651d478 ]
The current implementation of ip6_dst_lookup_tail basically
ignore the egress ifindex match: if the saddr is set,
ip6_route_output() purposefully ignores flowi6_oif, due
to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
flag if saddr set"), if the saddr is 'any' the first route lookup
in ip6_dst_lookup_tail fails, but upon failure a second lookup will
be performed with saddr set, thus ignoring the ifindex constraint.
This commit adds an output route lookup function variant, which
allows the caller to specify lookup flags, and modify
ip6_dst_lookup_tail() to enforce the ifindex match on the second
lookup via said helper.
ip6_route_output() becames now a static inline function build on
top of ip6_route_output_flags(); as a side effect, out-of-tree
modules need now a GPL license to access the output route lookup
functionality.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 87e40d8d8ba965003611a8bdbe18019d344d9d58
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Jan 27 10:52:43 2016 -0800
tcp: beware of alignments in tcp_get_info()
[ Upstream commit ff5d749772018602c47509bdc0093ff72acd82ec ]
With some combinations of user provided flags in netlink command,
it is possible to call tcp_get_info() with a buffer that is not 8-bytes
aligned.
It does matter on some arches, so we need to use put_unaligned() to
store the u64 fields.
Current iproute2 package does not trigger this particular issue.
Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info")
Fixes: 977cb0ecf82e ("tcp: add pacing_rate information into tcp_info")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba50e6d96f3daf3db8396cc3529f90339d9ef59a
Author: Ido Schimmel <idosch@mellanox.com>
Date: Wed Jan 27 15:16:43 2016 +0100
switchdev: Require RTNL mutex to be held when sending FDB notifications
[ Upstream commit 4f2c6ae5c64c353fb1b0425e4747e5603feadba1 ]
When switchdev drivers process FDB notifications from the underlying
device they resolve the netdev to which the entry points to and notify
the bridge using the switchdev notifier.
However, since the RTNL mutex is not held there is nothing preventing
the netdev from disappearing in the middle, which will cause
br_switchdev_event() to dereference a non-existing netdev.
Make switchdev drivers hold the lock at the beginning of the
notification processing session and release it once it ends, after
notifying the bridge.
Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
when RTNL mutex is held.
Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 649dc6c32e516972128502ad6a45a16b96098567
Author: Joe Stringer <joe@ovn.org>
Date: Fri Jan 22 15:49:12 2016 -0800
inet: frag: Always orphan skbs inside ip_defrag()
[ Upstream commit 8282f27449bf15548cb82c77b6e04ee0ab827bdc ]
Later parts of the stack (including fragmentation) expect that there is
never a socket attached to frag in a frag_list, however this invariant
was not enforced on all defrag paths. This could lead to the
BUG_ON(skb->sk) during ip_do_fragment(), as per the call stack at the
end of this commit message.
While the call could be added to openvswitch to fix this particular
error, the head and tail of the frags list are already orphaned
indirectly inside ip_defrag(), so it seems like the remaining fragments
should all be orphaned in all circumstances.
kernel BUG at net/ipv4/ip_output.c:586!
[...]
Call Trace:
<IRQ>
[<ffffffffa0205270>] ? do_output.isra.29+0x1b0/0x1b0 [openvswitch]
[<ffffffffa02167a7>] ovs_fragment+0xcc/0x214 [openvswitch]
[<ffffffff81667830>] ? dst_discard_out+0x20/0x20
[<ffffffff81667810>] ? dst_ifdown+0x80/0x80
[<ffffffffa0212072>] ? find_bucket.isra.2+0x62/0x70 [openvswitch]
[<ffffffff810e0ba5>] ? mod_timer_pending+0x65/0x210
[<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90
[<ffffffffa03205a2>] ? nf_conntrack_in+0x252/0x500 [nf_conntrack]
[<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70
[<ffffffffa02051a3>] do_output.isra.29+0xe3/0x1b0 [openvswitch]
[<ffffffffa0206411>] do_execute_actions+0xe11/0x11f0 [openvswitch]
[<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70
[<ffffffffa0206822>] ovs_execute_actions+0x32/0xd0 [openvswitch]
[<ffffffffa020b505>] ovs_dp_process_packet+0x85/0x140 [openvswitch]
[<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70
[<ffffffffa02068a2>] ovs_execute_actions+0xb2/0xd0 [openvswitch]
[<ffffffffa020b505>] ovs_dp_process_packet+0x85/0x140 [openvswitch]
[<ffffffffa0215019>] ? ovs_ct_get_labels+0x49/0x80 [openvswitch]
[<ffffffffa0213a1d>] ovs_vport_receive+0x5d/0xa0 [openvswitch]
[<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90
[<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90
[<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90
[<ffffffffa0214895>] ? internal_dev_xmit+0x5/0x140 [openvswitch]
[<ffffffffa02148fc>] internal_dev_xmit+0x6c/0x140 [openvswitch]
[<ffffffffa0214895>] ? internal_dev_xmit+0x5/0x140 [openvswitch]
[<ffffffff81660299>] dev_hard_start_xmit+0x2b9/0x5e0
[<ffffffff8165fc21>] ? netif_skb_features+0xd1/0x1f0
[<ffffffff81660f20>] __dev_queue_xmit+0x800/0x930
[<ffffffff81660770>] ? __dev_queue_xmit+0x50/0x930
[<ffffffff810b53f1>] ? mark_held_locks+0x71/0x90
[<ffffffff81669876>] ? neigh_resolve_output+0x106/0x220
[<ffffffff81661060>] dev_queue_xmit+0x10/0x20
[<ffffffff816698e8>] neigh_resolve_output+0x178/0x220
[<ffffffff816a8e6f>] ? ip_finish_output2+0x1ff/0x590
[<ffffffff816a8e6f>] ip_finish_output2+0x1ff/0x590
[<ffffffff816a8cee>] ? ip_finish_output2+0x7e/0x590
[<ffffffff816a9a31>] ip_do_fragment+0x831/0x8a0
[<ffffffff816a8c70>] ? ip_copy_metadata+0x1b0/0x1b0
[<ffffffff816a9ae3>] ip_fragment.constprop.49+0x43/0x80
[<ffffffff816a9c9c>] ip_finish_output+0x17c/0x340
[<ffffffff8169a6f4>] ? nf_hook_slow+0xe4/0x190
[<ffffffff816ab4c0>] ip_output+0x70/0x110
[<ffffffff816a9b20>] ? ip_fragment.constprop.49+0x80/0x80
[<ffffffff816aa9f9>] ip_local_out+0x39/0x70
[<ffffffff816abf89>] ip_send_skb+0x19/0x40
[<ffffffff816abfe3>] ip_push_pending_frames+0x33/0x40
[<ffffffff816df21a>] icmp_push_reply+0xea/0x120
[<ffffffff816df93d>] icmp_reply.constprop.23+0x1ed/0x230
[<ffffffff816df9ce>] icmp_echo.part.21+0x4e/0x50
[<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70
[<ffffffff810d5f9e>] ? rcu_read_lock_held+0x5e/0x70
[<ffffffff816dfa06>] icmp_echo+0x36/0x70
[<ffffffff816e0d11>] icmp_rcv+0x271/0x450
[<ffffffff816a4ca7>] ip_local_deliver_finish+0x127/0x3a0
[<ffffffff816a4bc1>] ? ip_local_deliver_finish+0x41/0x3a0
[<ffffffff816a5160>] ip_local_deliver+0x60/0xd0
[<ffffffff816a4b80>] ? ip_rcv_finish+0x560/0x560
[<ffffffff816a46fd>] ip_rcv_finish+0xdd/0x560
[<ffffffff816a5453>] ip_rcv+0x283/0x3e0
[<ffffffff810b6302>] ? match_held_lock+0x192/0x200
[<ffffffff816a4620>] ? inet_del_offload+0x40/0x40
[<ffffffff8165d062>] __netif_receive_skb_core+0x392/0xae0
[<ffffffff8165e68e>] ? process_backlog+0x8e/0x230
[<ffffffff810b53f1>] ? mark_held_locks+0x71/0x90
[<ffffffff8165d7c8>] __netif_receive_skb+0x18/0x60
[<ffffffff8165e678>] process_backlog+0x78/0x230
[<ffffffff8165e6dd>] ? process_backlog+0xdd/0x230
[<ffffffff8165e355>] net_rx_action+0x155/0x400
[<ffffffff8106b48c>] __do_softirq+0xcc/0x420
[<ffffffff816a8e87>] ? ip_finish_output2+0x217/0x590
[<ffffffff8178e78c>] do_softirq_own_stack+0x1c/0x30
<EOI>
[<ffffffff8106b88e>] do_softirq+0x4e/0x60
[<ffffffff8106b948>] __local_bh_enable_ip+0xa8/0xb0
[<ffffffff816a8eb0>] ip_finish_output2+0x240/0x590
[<ffffffff816a9a31>] ? ip_do_fragment+0x831/0x8a0
[<ffffffff816a9a31>] ip_do_fragment+0x831/0x8a0
[<ffffffff816a8c70>] ? ip_copy_metadata+0x1b0/0x1b0
[<ffffffff816a9ae3>] ip_fragment.constprop.49+0x43/0x80
[<ffffffff816a9c9c>] ip_finish_output+0x17c/0x340
[<ffffffff8169a6f4>] ? nf_hook_slow+0xe4/0x190
[<ffffffff816ab4c0>] ip_output+0x70/0x110
[<ffffffff816a9b20>] ? ip_fragment.constprop.49+0x80/0x80
[<ffffffff816aa9f9>] ip_local_out+0x39/0x70
[<ffffffff816abf89>] ip_send_skb+0x19/0x40
[<ffffffff816abfe3>] ip_push_pending_frames+0x33/0x40
[<ffffffff816d55d3>] raw_sendmsg+0x7d3/0xc30
[<ffffffff810b732b>] ? __lock_acquire+0x3db/0x1b90
[<ffffffff816e7557>] ? inet_sendmsg+0xc7/0x1d0
[<ffffffff810b63c4>] ? __lock_is_held+0x54/0x70
[<ffffffff816e759a>] inet_sendmsg+0x10a/0x1d0
[<ffffffff816e7495>] ? inet_sendmsg+0x5/0x1d0
[<ffffffff8163e398>] sock_sendmsg+0x38/0x50
[<ffffffff8163ec5f>] ___sys_sendmsg+0x25f/0x270
[<ffffffff811aadad>] ? handle_mm_fault+0x8dd/0x1320
[<ffffffff8178c147>] ? _raw_spin_unlock+0x27/0x40
[<ffffffff810529b2>] ? __do_page_fault+0x1e2/0x460
[<ffffffff81204886>] ? __fget_light+0x66/0x90
[<ffffffff8163f8e2>] __sys_sendmsg+0x42/0x80
[<ffffffff8163f932>] SyS_sendmsg+0x12/0x20
[<ffffffff8178cb17>] entry_SYSCALL_64_fastpath+0x12/0x6f
Code: 00 00 44 89 e0 e9 7c fb ff ff 4c 89 ff e8 e7 e7 ff ff 41 8b 9d 80 00 00 00 2b 5d d4 89 d8 c1 f8 03 0f b7 c0 e9 33 ff ff f
66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48
RIP [<ffffffff816a9a92>] ip_do_fragment+0x892/0x8a0
RSP <ffff88006d603170>
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Signed-off-by: Joe Stringer <joe@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c57e51ffd1d910d595ccb3af3ae70eeeb6d423a2
Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Wed Jan 27 11:35:59 2016 +0100
tipc: fix connection abort during subscription cancel
[ Upstream commit 4d5cfcba2f6ec494d8810b9e3c0a7b06255c8067 ]
In 'commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing
to events")', we terminate the connection if the subscription
creation fails.
In the same commit, the subscription creation result was based on
the value of the subscription pointer (set in the function) instead
of the return code.
Unfortunately, the same function tipc_subscrp_create() handles
subscription cancel request. For a subscription cancellation request,
the subscription pointer cannot be set. Thus if a subscriber has
several subscriptions and cancels any of them, the connection is
terminated.
In this commit, we terminate the connection based on the return value
of tipc_subscrp_create().
Fixes: commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing to events")
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7f76933dbd9bb3a01c060e0a580a4f074c5d0def
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date: Sun Jan 24 09:22:05 2016 +0000
net: dsa: fix mv88e6xxx switches
[ Upstream commit db0e51afa481088e6396f11e02018d64113a6578 ]
Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
ops"), the Marvell 88E6xxx switch has been unable to pass traffic
between ports - any received traffic is discarded by the switch.
Taking a port out of bridge mode and configuring a vlan on it also the
port to start passing traffic.
With the debugfs files re-instated to allow debug of this issue by
comparing the register settings between the working and non-working
case, the reason becomes clear:
GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6
- 7: 1111 707f 2001 2 2 2 2 2 0 2
+ 7: 1111 707f 2001 1 1 1 1 1 0 1
Register 7 for the ports is the default vlan tag register, and in the
non-working setup, it has been set to 2, despite vlan 2 not being
configured. This causes the switch to drop all packets coming in to
these ports. The working setup has the default vlan tag register set
to 1, which is the default vlan when none is configured.
Inspection of the code reveals why. The code prior to this commit
was:
- for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
- if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
- err = ds->drv->port_pvid_set(ds, p->port, vid);
but the new code is:
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
+ }
...
+ if (pvid)
+ err = _mv88e6xxx_port_pvid_set(ds, port, vid);
This causes the new code to always set the default vlan to one higher
than the old code.
Fix this.
Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops")
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 293c41f89596fb17bd3963f9f240000e8ab462ac
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Fri Jan 22 18:29:49 2016 -0200
sctp: allow setting SCTP_SACK_IMMEDIATELY by the application
[ Upstream commit 27f7ed2b11d42ab6d796e96533c2076ec220affc ]
This patch extends commit b93d6471748d ("sctp: implement the sender side
for SACK-IMMEDIATELY extension") as it didn't white list
SCTP_SACK_IMMEDIATELY on sctp_msghdr_parse(), causing it to be
understood as an invalid flag and returning -EINVAL to the application.
Note that the actual handling of the flag is already there in
sctp_datamsg_from_user().
https://tools.ietf.org/html/rfc7053#section-7
Fixes: b93d6471748d ("sctp: implement the sender side for SACK-IMMEDIATELY extension")
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cccf9f37854c9ffd5f658c977345d8159ba1073a
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri Jan 22 01:39:43 2016 +0100
pptp: fix illegal memory access caused by multiple bind()s
[ Upstream commit 9a368aff9cb370298fa02feeffa861f2db497c18 ]
Several times already this has been reported as kasan reports caused by
syzkaller and trinity and people always looked at RCU races, but it is
much more simple. :)
In case we bind a pptp socket multiple times, we simply add it to
the callid_sock list but don't remove the old binding. Thus the old
socket stays in the bucket with unused call_id indexes and doesn't get
cleaned up. This causes various forms of kasan reports which were hard
to pinpoint.
Simply don't allow multiple binds and correct error handling in
pptp_bind. Also keep sk_state bits in place in pptp_connect.
Fixes: 00959ade36acad ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)")
Cc: Dmitry Kozlov <xeb@mail.ru>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 39770be4d6ad29c5ab1f21edbbf01db067f13b52
Author: Eric Dumazet <edumazet@google.com>
Date: Sun Jan 24 13:53:50 2016 -0800
af_unix: fix struct pid memory leak
[ Upstream commit fa0dc04df259ba2df3ce1920e9690c7842f8fa4b ]
Dmitry reported a struct pid leak detected by a syzkaller program.
Bug happens in unix_stream_recvmsg() when we break the loop when a
signal is pending, without properly releasing scm.
Fixes: b3ca9b02b007 ("net: fix multithreaded signal handling in unix recv routines")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5abc10d19b90ab363d8a732bc6cf098249e10c5
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Jan 21 08:02:54 2016 -0800
tcp: fix NULL deref in tcp_v4_send_ack()
[ Upstream commit e62a123b8ef7c5dc4db2c16383d506860ad21b47 ]
Neal reported crashes with this stack trace :
RIP: 0010:[<ffffffff8c57231b>] tcp_v4_send_ack+0x41/0x20f
...
CR2: 0000000000000018 CR3: 000000044005c000 CR4: 00000000001427e0
...
[<ffffffff8c57258e>] tcp_v4_reqsk_send_ack+0xa5/0xb4
[<ffffffff8c1a7caa>] tcp_check_req+0x2ea/0x3e0
[<ffffffff8c19e420>] tcp_rcv_state_process+0x850/0x2500
[<ffffffff8c1a6d21>] tcp_v4_do_rcv+0x141/0x330
[<ffffffff8c56cdb2>] sk_backlog_rcv+0x21/0x30
[<ffffffff8c098bbd>] tcp_recvmsg+0x75d/0xf90
[<ffffffff8c0a8700>] inet_recvmsg+0x80/0xa0
[<ffffffff8c17623e>] sock_aio_read+0xee/0x110
[<ffffffff8c066fcf>] do_sync_read+0x6f/0xa0
[<ffffffff8c0673a1>] SyS_read+0x1e1/0x290
[<ffffffff8c5ca262>] system_call_fastpath+0x16/0x1b
The problem here is the skb we provide to tcp_v4_send_ack() had to
be parked in the backlog of a new TCP fastopen child because this child
was owned by the user at the time an out of window packet arrived.
Before queuing a packet, TCP has to set skb->dev to NULL as the device
could disappear before packet is removed from the queue.
Fix this issue by using the net pointer provided by the socket (being a
timewait or a request socket).
IPv6 is immune to the bug : tcp_v6_send_response() already gets the net
pointer from the socket if provided.
Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
Reported-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jerry Chu <hkchu@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 176d8f37af972f47360d5c3751a61cd6274924cd
Author: Paolo Abeni <pabeni@redhat.com>
Date: Wed Feb 17 19:30:01 2016 +0100
lwt: fix rx checksum setting for lwt devices tunneling over ipv6
[ Upstream commit c868ee7063bdb53f3ef9eac7bcec84960980b471 ]
the commit 35e2d1152b22 ("tunnels: Allow IPv6 UDP checksums to be
correctly controlled.") changed the default xmit checksum setting
for lwt vxlan/geneve ipv6 tunnels, so that now the checksum is not
set into external UDP header.
This commit changes the rx checksum setting for both lwt vxlan/geneve
devices created by openvswitch accordingly, so that lwt over ipv6
tunnel pairs are again able to communicate with default values.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa12fd6d38ce22fc16aaf03f6e53ce8be5de304a
Author: Jesse Gross <jesse@kernel.org>
Date: Wed Jan 20 16:22:47 2016 -0800
tunnels: Allow IPv6 UDP checksums to be correctly controlled.
[ Upstream commit 35e2d1152b22eae99c961affbe85374bef05a775 ]
When configuring checksums on UDP tunnels, the flags are different
for IPv4 vs. IPv6 (and reversed). However, when lightweight tunnels
are enabled the flags used are always the IPv4 versions, which are
ignored in the IPv6 code paths. This uses the correct IPv6 flags, so
checksums can be controlled appropriately.
Fixes: a725e514 ("vxlan: metadata based tunneling for IPv6")
Fixes: abe492b4 ("geneve: UDP checksum configuration via netlink")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c95b96877efc8b258d24d6da93465fbb89082495
Author: Manfred Rudigier <Manfred.Rudigier@omicron.at>
Date: Wed Jan 20 11:22:28 2016 +0100
net: dp83640: Fix tx timestamp overflow handling.
[ Upstream commit 81e8f2e930fe76b9814c71b9d87c30760b5eb705 ]
PHY status frames are not reliable, the PHY may not be able to send them
during heavy receive traffic. This overflow condition is signaled by the
PHY in the next status frame, but the driver did not make use of it.
Instead it always reported wrong tx timestamps to user space after an
overflow happened because it assigned newly received tx timestamps to old
packets in the queue.
This commit fixes this issue by clearing the tx timestamp queue every time
an overflow happens, so that no timestamps are delivered for overflow
packets. This way time stamping will continue correctly after an overflow.
Signed-off-by: Manfred Rudigier <manfred.rudigier@omicron.at>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 306d316588459a0e6ee81098c334f3ef249ab64f
Author: Jesse Gross <jesse@kernel.org>
Date: Wed Jan 20 17:59:49 2016 -0800
gro: Make GRO aware of lightweight tunnels.
[ Upstream commit ce87fc6ce3f9f4488546187e3757cf666d9d4a2a ]
GRO is currently not aware of tunnel metadata generated by lightweight
tunnels and stored in the dst. This leads to two possible problems:
* Incorrectly merging two frames that have different metadata.
* Leaking of allocated metadata from merged frames.
This avoids those problems by comparing the tunnel information before
merging, similar to how we handle other metadata (such as vlan tags),
and releasing any state when we are done.
Reported-by: John <john.phillips5@hpe.com>
Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 626a83d5d55b90fc4df792bb0aa707df2ecafa4b
Author: Ursula Braun <ursula.braun@de.ibm.com>
Date: Tue Jan 19 10:41:33 2016 +0100
af_iucv: Validate socket address length in iucv_sock_bind()
[ Upstream commit 52a82e23b9f2a9e1d429c5207f8575784290d008 ]
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Evgeny Cherkashin <Eugene.Crosser@ru.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>