| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The preempt-rt config explicitly disables aufs which can result in
config warnings for kernels where the aufs patches aren't applied.
Since default state of aufs is 'n', there's no need to disable it
explicitly here.
For BSPs relying on aufs, they should enable it by including
features/aufs/aufs-enable.scc.
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
CONFIG_USB_ARCH_HAS_EHCI was removed and isn't used anymore:
https://github.com/torvalds/linux/commit/b797b76fb464ed6939ce71386bee7fdda4b68632
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
As per the upstream changes, we no longer need the early microcode
variant:
commit fe055896c040df571e4ff56fb196d6845130057b
Author: Borislav Petkov <bp@suse.de>
Date: Tue Oct 20 11:54:45 2015 +0200
x86/microcode: Merge the early microcode loader
Merge the early loader functionality into the driver proper. The
diff is huge but logically, it is simply moving code from the
_early.c files into the main driver.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/1445334889-300-3-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit bf13af56252b2b4f50eb6fc8638e8cb9e84ff475
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 23 13:57:47 2015 +0200
drm/i915: Fix up KMS Kconfig removal patch
The module pciid list got lost, but somehow most distros seem to
force-load drm drivers early and no one noticed for a while.
Bug introduced in
commit fd930478fb797e4cbaa799d9ddd970e9a1fa1b4a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 19 20:27:27 2015 +0100
drm/i915: Remove KMS Kconfig option
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit c007fb4a upstream.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
As per upstream commit:
commit 231a091ef8dece94b0ad2b85affb059c483af33c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon Jan 16 15:12:29 2017 +0200
ASoC: Intel: rename SND_SST_MFLD_PLATFORM to SND_SST_ATOM_HIFI2_PLATFORM
Rename SND_SST_MFLD_PLATFORM to SND_SST_ATOM_HIFI2_PLATFORM to make it clear
that is not only about Medfield platform.
The new name is derived from Intel Atom and HiFi2. HiFi2 is the DSP version,
it's public information for Intel *Field/*Trail parts, see
https://www.alsa-project.org/main/index.php/Firmware. By combining HiFi2 with
Atom we get a unique non-ambiguous description of the core+DSP hardware for
Intel Medfield through Intel Cherrytrail.
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Upstream commit adf05168 has removed this option:
commit adf0516845bcd0e626323c858ece28ee58c74455
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri Aug 12 13:47:06 2016 +0200
netfilter: remove ip_conntrack* sysctl compat code
This backward compatibility has been around for more than ten years,
since Yasuyuki Kozakai introduced IPv6 in conntrack. These days, we have
alternate /proc/net/nf_conntrack* entries, the ctnetlink interface and
the conntrack utility got adopted by many people in the user community
according to what I observed on the netfilter user mailing list.
So let's get rid of this.
Note that nf_conntrack_htable_size and unsigned int nf_conntrack_max do
not need to be exported as symbol anymore.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit d4da843e6fad4f278fe82b075d8e394cff05c95c
Author: Paul Bolle <pebolle@tiscali.nl>
Date: Fri Jul 25 14:25:31 2014 +0200
netfilter: kill remnants of ulog targets
The ulog targets were recently killed. A few references to the Kconfig
macros CONFIG_IP_NF_TARGET_ULOG and CONFIG_BRIDGE_EBT_ULOG were left
untouched. Kill these too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The ext3 driver has been dropped, ext4 takes care of things:
commit c290ea01abb7907fde602f3ba55905ef10a37477
Author: Jan Kara <jack@suse.cz>
Date: Thu Jun 18 16:52:29 2015 +0200
fs: Remove ext3 filesystem driver
The functionality of ext3 is fully supported by ext4 driver. Major
distributions (SUSE, RedHat) already use ext4 driver to handle ext3
filesystems for quite some time. There is some ugliness in mm resulting
from jbd cleaning buffers in a dirty page without cleaning page dirty
bit and also support for buffer bouncing in the block layer when stable
pages are required is there only because of jbd. So let's remove the
ext3 driver. This saves us some 28k lines of duplicated code.
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit d886f4e483ce63a3304adc9eda87031b93341c28
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Wed Jan 20 15:02:47 2016 -0800
mm: memcontrol: rein in the CONFIG space madness
What CONFIG_INET and CONFIG_LEGACY_KMEM guard inside the memory
controller code is insignificant, having these conditionals is not
worth the complication and fragility that comes with them.
[akpm@linux-foundation.org: rework mem_cgroup_css_free() statement ordering]
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit b5c9b4f91a6f91cdbf777e6f365d56debe500421
Author: Kalle Valo <kvalo@codeaurora.org>
Date: Wed Nov 18 10:38:32 2015 +0200
ath: unify Kconfig with other vendors
Change menuconfig to config to keep the Kconfig entries unified. Part of
reorganising wireless drivers directory and Kconfig.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit 3bc28ab6da039f8020bbcea8e832b63a900bdb66
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date: Thu Oct 3 20:29:08 2013 +0530
cpufreq: remove CONFIG_CPU_FREQ_TABLE
CONFIG_CPU_FREQ_TABLE will be always enabled when cpufreq framework is used, as
cpufreq core depends on it. So, we don't need this CONFIG option anymore as it
is not configurable. Remove CONFIG_CPU_FREQ_TABLE and update its users.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
commit 4a72a7af462de09a2f6ef2bafd08878062b3cb5d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun May 10 14:54:38 2015 +0200
staging: remove i2o subsystem
This subsystem isn't used anymore, and the hardware isn't around.
It's been in staging for a while, and it's time for it to now be
removed.
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
crypto.scc was removed in the last commit and shouldn't be included
here.
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The only config enabled by this feature, CRYPTO_ZLIB, was removed
starting 4.6 kernel [1].
[1] https://github.com/torvalds/linux/commit/110492183c4b8f572b16fce096b9d78e2da30baf
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
CONFIG_INTEL_PMIC_THERMAL was enabled for the bxt kernel tree which had
in-review patches as well. This config was re-named to
CONFIG_INTEL_BXT_PMIC_THERMAL in the final merged version of patch:
https://github.com/torvalds/linux/commit/b474303ffd57e0a379ce73ca10232350f866f77b
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
These are no longer present and give warnings when used with
KCONF_BSP_AUDIT set.
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
1/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: v4.9.30-rt19
Date: Sat, 27 May 2017 08:46:21 +0200
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
2/69 [
Author: Anna-Maria Gleixner
Email: anna-maria@linutronix.de
Subject: Revert "timers: Don't wake ktimersoftd on every tick"
Date: Fri, 26 May 2017 19:16:07 +0200
This reverts commit 032f93cae150a ("timers: Don't wake ktimersoftd on
every tick").
The problem is that the look ahead optimization from the tick timer
interrupt context can race with the softirq thread expiring timer. As
a consequence the temporary hlist heads which hold the to expire
timers are overwritten and the timers which are already removed from
the wheel bucket for expiry are now dangling w/o a list head.
That means those timers never get expired. If one of those timers is
canceled the removal operation will result in a hlist corruption.
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
3/69 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: futex,rt_mutex: Fix rt_mutex_cleanup_proxy_lock()
Date: Mon, 22 May 2017 13:04:50 -0700
Markus reported that the glibc/nptl/tst-robustpi8 test was failing after
commit:
cfafcd117da0 ("futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()")
The following trace shows the problem:
ld-linux-x86-64-2161 [019] .... 410.760971: SyS_futex: 00007ffbeb76b028: 80000875 op=FUTEX_LOCK_PI
ld-linux-x86-64-2161 [019] ...1 410.760972: lock_pi_update_atomic: 00007ffbeb76b028: curval=80000875 uval=80000875 newval=80000875 ret=0
ld-linux-x86-64-2165 [011] .... 410.760978: SyS_futex: 00007ffbeb76b028: 80000875 op=FUTEX_UNLOCK_PI
ld-linux-x86-64-2165 [011] d..1 410.760979: do_futex: 00007ffbeb76b028: curval=80000875 uval=80000875 newval=80000871 ret=0
ld-linux-x86-64-2165 [011] .... 410.760980: SyS_futex: 00007ffbeb76b028: 80000871 ret=0000
ld-linux-x86-64-2161 [019] .... 410.760980: SyS_futex: 00007ffbeb76b028: 80000871 ret=ETIMEDOUT
Task 2165 does an UNLOCK_PI, assigning the lock to the waiter task 2161
which then returns with -ETIMEDOUT. That wrecks the lock state, because now
the owner isn't aware it acquired the lock and removes the pending robust
list entry.
If 2161 is killed, the robust list will not clear out this futex and the
subsequent acquire on this futex will then (correctly) result in -ESRCH
which is unexpected by glibc, triggers an internal assertion and dies.
Task 2161 Task 2165
rt_mutex_wait_proxy_lock()
timeout();
/* T2161 is still queued in the waiter list */
return -ETIMEDOUT;
futex_unlock_pi()
spin_lock(hb->lock);
rtmutex_unlock()
remove_rtmutex_waiter(T2161);
mark_lock_available();
/* Make the next waiter owner of the user space side */
futex_uval = 2161;
spin_unlock(hb->lock);
spin_lock(hb->lock);
rt_mutex_cleanup_proxy_lock()
if (rtmutex_owner() !== current)
...
return FAIL;
....
return -ETIMEOUT;
This means that rt_mutex_cleanup_proxy_lock() needs to call
try_to_take_rt_mutex() so it can take over the rtmutex correctly which was
assigned by the waker. If the rtmutex is owned by some other task then this
call is harmless and just confirmes that the waiter is not able to acquire
it.
While there, fix what looks like a merge error which resulted in
rt_mutex_cleanup_proxy_lock() having two calls to
fixup_rt_mutex_waiters() and rt_mutex_wait_proxy_lock() not having any.
Both should have one, since both potentially touch the waiter list.
Fixes: 38d589f2fd08 ("futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()")
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Bug-Spotted-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Link: http://lkml.kernel.org/r/20170519154850.mlomgdsd26drq5j6@hirez.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
4/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: v4.9.30-rt20
Date: Sat, 27 May 2017 10:11:49 +0200
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
5/69 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: sched: Prevent task state corruption by spurious lock wakeup
Date: Tue, 6 Jun 2017 14:20:37 +0200
Mathias and others reported GDB failures on RT.
The following scenario leads to task state corruption:
CPU0 CPU1
T1->state = TASK_XXX;
spin_lock(&lock)
rt_spin_lock_slowlock(&lock->rtmutex)
raw_spin_lock(&rtm->wait_lock);
T1->saved_state = current->state;
T1->state = TASK_UNINTERRUPTIBLE;
spin_unlock(&lock)
task_blocks_on_rt_mutex(rtm) rt_spin_lock_slowunlock(&lock->rtmutex)
queue_waiter(rtm) raw_spin_lock(&rtm->wait_lock);
pi_chain_walk(rtm)
raw_spin_unlock(&rtm->wait_lock);
wake_top_waiter(T1)
raw_spin_lock(&rtm->wait_lock);
for (;;) {
if (__try_to_take_rt_mutex()) <- Succeeds
break;
...
}
T1->state = T1->saved_state;
try_to_wake_up(T1)
ttwu_do_wakeup(T1)
T1->state = TASK_RUNNING;
In most cases this is harmless because waiting for some event, which is the
usual reason for TASK_[UN]INTERRUPTIBLE has to be safe against other forms
of spurious wakeups anyway.
But in case of TASK_TRACED this is actually fatal, because the task loses
the TASK_TRACED state. In consequence it fails to consume SIGSTOP which was
sent from the debugger and actually delivers SIGSTOP to the task which
breaks the ptrace mechanics and brings the debugger into an unexpected
state.
The TASK_TRACED state should prevent getting there due to the state
matching logic in try_to_wake_up(). But that's not true because
wake_up_lock_sleeper() uses TASK_ALL as state mask. That's bogus because
lock sleepers always use TASK_UNINTERRUPTIBLE, so the wakeup should use
that as well.
The cure is way simpler as figuring it out:
Change the mask used in wake_up_lock_sleeper() from TASK_ALL to
TASK_UNINTERRUPTIBLE.
Cc: stable-rt@vger.kernel.org
Reported-by: Mathias Koehrer <mathias.koehrer@etas.com>
Reported-by: David Hauck <davidh@netacquire.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
6/69 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: sched: Remove TASK_ALL
Date: Wed, 7 Jun 2017 10:12:45 +0200
It's unused:
$ git grep "\<TASK_ALL\>" | wc -l
1
And dangerous, kill the bugger.
Cc: stable-rt@vger.kernel.org
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
7/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: v4.9.30-rt21
Date: Wed, 7 Jun 2017 10:50:43 +0200
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
8/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: v4.9.33-rt22
Date: Fri, 23 Jun 2017 15:55:31 +0200
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
9/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: sched/migrate disable: handle updated task-mask mg-dis section
Date: Mon, 19 Jun 2017 09:55:47 +0200
If task's cpumask changes while in the task is in a migrate_disable()
section then we don't react on it after a migrate_enable(). It matters
however if current CPU is no longer part of the cpumask. We also miss
the ->set_cpus_allowed() callback.
This patch fixes it by setting task->migrate_disable_update once we this
"delayed" hook.
This bug was introduced while fixing unrelated issue in
migrate_disable() in v4.4-rt3 (update_migrate_disable() got removed
during that).
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
10/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: kernel/locking: use an exclusive wait_q for sleepers
Date: Thu, 22 Jun 2017 17:53:34 +0200
If a task is queued as a sleeper for a wakeup and never goes to
schedule() (because it just obtained the lock) then it will receive a
spurious wake up which is not "bad", it is considered. Until that wake
up happens this task can no be enqueued for any wake ups handled by the
WAKE_Q infrastructure (because a task can only be enqueued once). This
wouldn't be bad if we would use the same wakeup mechanism for the wake
up of sleepers as we do for "normal" wake ups. But we don't…
So.
T1 T2 T3
spin_lock(x) spin_unlock(x);
wake_q_add_sleeper(q1, T1)
spin_unlock(x)
set_state(TASK_INTERRUPTIBLE)
if (!condition)
schedule()
condition = true
wake_q_add(q2, T1)
// T1 not added, still enqueued
wake_up_q(q2)
wake_up_q_sleeper(q1)
// T1 not woken up, wrong task state
In order to solve this race this patch adds a wake_q_node for the
sleeper case.
Reported-by: Mike Galbraith <efault@gmx.de>
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
11/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: v4.9.33-rt23
Date: Fri, 23 Jun 2017 16:05:40 +0200
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
12/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.34-rt24
Date: Mon, 3 Jul 2017 12:07:43 -0400
]
13/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.35-rt25
Date: Mon, 3 Jul 2017 14:19:58 -0400
]
14/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.36-rt26
Date: Tue, 1 Aug 2017 14:47:19 -0400
]
15/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.37-rt27
Date: Tue, 1 Aug 2017 14:48:21 -0400
]
16/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.38-rt28
Date: Tue, 1 Aug 2017 14:48:56 -0400
]
17/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.39-rt29
Date: Wed, 2 Aug 2017 09:42:13 -0400
]
18/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.40-rt30
Date: Wed, 2 Aug 2017 14:09:36 -0400
]
19/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.41-rt31
Date: Tue, 5 Sep 2017 11:06:58 -0400
]
20/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.42-rt32
Date: Tue, 5 Sep 2017 11:08:10 -0400
]
21/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.43-rt33
Date: Tue, 5 Sep 2017 11:08:31 -0400
]
22/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.44-rt34
Date: Tue, 5 Sep 2017 11:09:07 -0400
]
23/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.45-rt35
Date: Tue, 5 Sep 2017 11:09:31 -0400
]
24/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.46-rt36
Date: Tue, 5 Sep 2017 11:11:55 -0400
]
25/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.47-rt37
Date: Tue, 5 Sep 2017 12:52:50 -0400
]
26/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.48-rt38
Date: Fri, 17 Nov 2017 12:44:06 -0500
]
27/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.49-rt39
Date: Fri, 17 Nov 2017 12:45:39 -0500
]
28/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.50-rt40
Date: Fri, 17 Nov 2017 12:46:05 -0500
]
29/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.51-rt41
Date: Fri, 17 Nov 2017 12:46:28 -0500
]
30/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.52-rt42
Date: Fri, 17 Nov 2017 14:21:20 -0500
]
31/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.53-rt43
Date: Fri, 17 Nov 2017 14:22:24 -0500
]
32/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.54-rt44
Date: Fri, 17 Nov 2017 14:22:49 -0500
]
33/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.55-rt45
Date: Fri, 17 Nov 2017 14:23:10 -0500
]
34/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.56-rt46
Date: Fri, 17 Nov 2017 14:23:35 -0500
]
35/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.57-rt47
Date: Fri, 17 Nov 2017 14:24:06 -0500
]
36/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.58-rt48
Date: Fri, 17 Nov 2017 14:25:46 -0500
]
37/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.59-rt49
Date: Fri, 17 Nov 2017 14:26:12 -0500
]
38/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.60-rt50
Date: Fri, 17 Nov 2017 14:26:44 -0500
]
39/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.61-rt51
Date: Fri, 17 Nov 2017 16:07:37 -0500
]
40/69 [
Author: Mike Galbraith
Email: efault@gmx.de
Subject: drivers/zram: fix zcomp_stream_get() smp_processor_id() use in preemptible code
Date: Wed, 23 Aug 2017 11:57:29 +0200
Use get_local_ptr() instead this_cpu_ptr() to avoid a warning regarding
smp_processor_id() in preemptible code.
raw_cpu_ptr() would be fine, too because the per-CPU data structure is
protected with a spin lock so it does not matter much if we take the
other one.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
41/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: fs/dcache: disable preemption on i_dir_seq's write side
Date: Fri, 20 Oct 2017 11:29:53 +0200
i_dir_seq is an opencoded seqcounter. Based on the code it looks like we
could have two writers in parallel despite the fact that the d_lock is
held. The problem is that during the write process on RT the preemption
is still enabled and if this process is interrupted by a reader with RT
priority then we lock up.
To avoid that lock up I am disabling the preemption during the update.
The rename of i_dir_seq is here to ensure to catch new write sides in
future.
Cc: stable-rt@vger.kernel.org
Reported-by: Oleg.Karfich@wago.com
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
42/69 [
Author: Haris Okanovic
Email: haris.okanovic@ni.com
Subject: tpm_tis: fix stall after iowrite*()s
Date: Tue, 15 Aug 2017 15:13:08 -0500
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an SPI-based TPM chip (Intel Atom
E3940 system, PREEMPT_RT_FULL kernel). The spikes are caused by a
stalling ioread8() operation following a sequence of 30+ iowrite8()s to
the same address. I believe this happens because the write sequence is
buffered (in cpu or somewhere along the bus), and gets flushed on the
first LOAD instruction (ioread*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
43/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: fs: convert two more BH_Uptodate_Lock related bitspinlocks
Date: Mon, 6 Nov 2017 18:45:30 +0100
We convert all BH_Uptodate_Lock based bit-spinlocks to use
bh_uptodate_lock_irqsave() instead. Those two were introduced after the
initial change in -RT and were not noticed before.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
44/69 [
Author: Mikulas Patocka
Email: mpatocka@redhat.com
Subject: locking/rt-mutex: fix deadlock in device mapper / block-IO
Date: Mon, 13 Nov 2017 12:56:53 -0500
When some block device driver creates a bio and submits it to another
block device driver, the bio is added to current->bio_list (in order to
avoid unbounded recursion).
However, this queuing of bios can cause deadlocks, in order to avoid them,
device mapper registers a function flush_current_bio_list. This function
is called when device mapper driver blocks. It redirects bios queued on
current->bio_list to helper workqueues, so that these bios can proceed
even if the driver is blocked.
The problem with CONFIG_PREEMPT_RT_FULL is that when the device mapper
driver blocks, it won't call flush_current_bio_list (because
tsk_is_pi_blocked returns true in sched_submit_work), so deadlocks in
block device stack can happen.
Note that we can't call blk_schedule_flush_plug if tsk_is_pi_blocked
returns true - that would cause
BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on)) in
task_blocks_on_rt_mutex when flush_current_bio_list attempts to take a
spinlock.
So the proper fix is to call blk_schedule_flush_plug in rt_mutex_fastlock,
when fast acquire failed and when the task is about to block.
CC: stable-rt@vger.kernel.org
[bigeasy: The deadlock is not device-mapper specific, it can also occur
in plain EXT4]
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
45/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: md/raid5: do not disable interrupts
Date: Fri, 17 Nov 2017 16:21:00 +0100
|BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:974
|in_atomic(): 0, irqs_disabled(): 1, pid: 2992, name: lvm
|CPU: 2 PID: 2992 Comm: lvm Not tainted 4.13.10-rt3+ #54
|Call Trace:
| dump_stack+0x4f/0x65
| ___might_sleep+0xfc/0x150
| atomic_dec_and_spin_lock+0x3c/0x80
| raid5_release_stripe+0x73/0x110
| grow_one_stripe+0xce/0xf0
| setup_conf+0x841/0xaa0
| raid5_run+0x7e7/0xa40
| md_run+0x515/0xaf0
| raid_ctr+0x147d/0x25e0
| dm_table_add_target+0x155/0x320
| table_load+0x103/0x320
| ctl_ioctl+0x1d9/0x510
| dm_ctl_ioctl+0x9/0x10
| do_vfs_ioctl+0x8e/0x670
| SyS_ioctl+0x3c/0x70
| entry_SYSCALL_64_fastpath+0x17/0x98
The interrupts were disabled because ->device_lock is taken with
interrupts disabled.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
46/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.61-rt52
Date: Mon, 20 Nov 2017 22:03:22 -0500
]
47/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.62-rt53
Date: Wed, 29 Nov 2017 12:42:29 -0500
]
48/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.63-rt54
Date: Wed, 29 Nov 2017 13:59:14 -0500
]
49/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.64-rt55
Date: Wed, 29 Nov 2017 13:59:42 -0500
]
50/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.65-rt56
Date: Wed, 29 Nov 2017 14:00:22 -0500
]
51/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Revert "memcontrol: Prevent scheduling while atomic in cgroup code"
Date: Wed, 22 Nov 2017 07:31:19 -0500
The commit "memcontrol: Prevent scheduling while atomic in cgroup code"
fixed this issue:
refill_stock()
get_cpu_var()
drain_stock()
res_counter_uncharge()
res_counter_uncharge_until()
spin_lock() <== boom
But commit 3e32cb2e0a12b ("mm: memcontrol: lockless page counters") replaced
the calls to res_counter_uncharge() in drain_stock() to the lockless
function page_counter_uncharge(). There is no more spin lock there and no
more reason to have that local lock.
Cc: stable-rt@vger.kernel.org
Reported-by: Haiyang HY1 Tan <tanhy1@lenovo.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
[bigeasy: That upstream commit appeared in v3.19 and the patch in
question in v3.18.7-rt2 and v3.18 seems still to be maintained. So I
guess that v3.18 would need the locallocks that we are about to remove
here. I am not sure if any earlier versions have the patch
backported.
The stable tag here is because Haiyang reported (and debugged) a crash
in 4.4-RT with this patch applied (which has get_cpu_light() instead
the locallocks it gained in v4.9-RT).
https://lkml.kernel.org/r/05AA4EC5C6EC1D48BE2CDCFF3AE0B8A637F78A15@CNMAILEX04.lenovo.com
]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
52/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: Revert "fs: jbd2: pull your plug when waiting for space"
Date: Thu, 23 Nov 2017 17:51:51 +0100
This reverts commit "fs: jbd2: pull your plug when waiting for space".
This was a duct-tape fix which shouldn't be needed since commit
"locking/rt-mutex: fix deadlock in device mapper / block-IO".
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
53/69 [
Author: Mike Galbraith
Email: efault@gmx.de
Subject: rtmutex: Fix lock stealing logic
Date: Fri, 23 Jun 2017 09:37:14 +0200
1. When trying to acquire an rtmutex, we first try to grab it without
queueing the waiter, and explicitly check for that initial attempt
in the !waiter path of __try_to_take_rt_mutex(). Checking whether
the lock taker is top waiter before allowing a steal attempt in that
path is a thinko: the lock taker has not yet blocked.
2. It seems wrong to change the definition of rt_mutex_waiter_less()
to mean less or perhaps equal when we have an rt_mutex_waiter_equal().
Remove the thinko, restore rt_mutex_waiter_less(), implement and use
rt_mutex_steal() based upon rt_mutex_waiter_less/equal(), moving all
qualification criteria into the function itself.
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
54/69 [
Author: Alex Shi
Email: alex.shi@linaro.org
Subject: cpu_pm: replace raw_notifier to atomic_notifier
Date: Thu, 6 Jul 2017 16:47:46 +0800
This patch replace a rwlock and raw notifier by atomic notifier which
protected by spin_lock and rcu.
The first to reason to have this replace is due to a 'scheduling while
atomic' bug of RT kernel on arm/arm64 platform. On arm/arm64, rwlock
cpu_pm_notifier_lock in cpu_pm cause a potential schedule after irq
disable in idle call chain:
cpu_startup_entry
cpu_idle_loop
local_irq_disable()
cpuidle_idle_call
call_cpuidle
cpuidle_enter
cpuidle_enter_state
->enter :arm_enter_idle_state
cpu_pm_enter/exit
CPU_PM_CPU_IDLE_ENTER
read_lock(&cpu_pm_notifier_lock); <-- sleep in idle
__rt_spin_lock();
schedule();
The kernel panic is here:
[ 4.609601] BUG: scheduling while atomic: swapper/1/0/0x00000002
[ 4.609608] [<ffff0000086fae70>] arm_enter_idle_state+0x18/0x70
[ 4.609614] Modules linked in:
[ 4.609615] [<ffff0000086f9298>] cpuidle_enter_state+0xf0/0x218
[ 4.609620] [<ffff0000086f93f8>] cpuidle_enter+0x18/0x20
[ 4.609626] Preemption disabled at:
[ 4.609627] [<ffff0000080fa234>] call_cpuidle+0x24/0x40
[ 4.609635] [<ffff000008882fa4>] schedule_preempt_disabled+0x1c/0x28
[ 4.609639] [<ffff0000080fa49c>] cpu_startup_entry+0x154/0x1f8
[ 4.609645] [<ffff00000808e004>] secondary_start_kernel+0x15c/0x1a0
Daniel Lezcano said this notification is needed on arm/arm64 platforms.
Sebastian suggested using atomic_notifier instead of rwlock, which is not
only removing the sleeping in idle, but also getting better latency
improvement.
This patch passed Fengguang's 0day testing.
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
55/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: PM / CPU: replace raw_notifier with atomic_notifier (fixup)
Date: Thu, 17 Aug 2017 11:38:51 +0200
The original patch changed betwen its posting and what finally went into
Rafael's tree so here is the delta.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
56/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: kernel/hrtimer: migrate deferred timer on CPU down
Date: Fri, 18 Aug 2017 10:09:09 +0200
hrtimers, which were deferred to the softirq context, and expire between
softirq shutdown and hrtimer migration are dangling around. If the CPU
goes back up the list head will be initialized and this corrupts the
timer's list. It will remain unnoticed until a hrtimer_cancel().
This moves those timers so they will expire.
Cc: stable-rt@vger.kernel.org
Reported-by: Mike Galbraith <efault@gmx.de>
Tested-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
57/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: net: take the tcp_sk_lock lock with BH disabled
Date: Mon, 21 Aug 2017 15:09:13 +0200
Lockdep may complain about an unsafe locking scenario:
| CPU0 CPU1
| ---- ----
| lock((tcp_sk_lock).lock);
| lock(&per_cpu(local_softirq_locks[i], __cpu).lock);
| lock((tcp_sk_lock).lock);
| lock(&per_cpu(local_softirq_locks[i], __cpu).lock);
in the call paths:
do_current_softirqs -> tcp_v4_send_ack()
vs
tcp_v4_send_reset -> do_current_softirqs().
This should not happen since local_softirq_locks is per CPU. Reversing
the order makes lockdep happy.
Reported-by: Jacek Konieczny <jajcus@jajcus.net>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
58/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock
Date: Thu, 31 Aug 2017 18:19:06 +0200
We must not wake any process (and thus acquire the pi->lock) while
holding the hrtimer's base lock. This does not happen usually because
the hrtimer-callback is invoked in IRQ-context and so
raise_softirq_irqoff() does not wakeup a process.
However during CPU-hotplug it might get called from hrtimers_dead_cpu()
which would wakeup the thread immediately.
Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
59/69 [
Author: Mike Galbraith
Email: efault@gmx.de
Subject: kernel/hrtimer/hotplug: don't wake ktimersoftd while holding the hrtimer base lock
Date: Sun, 3 Sep 2017 04:48:10 +0200
kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock
missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer
raising softirq until after base lock has been released there as well.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
60/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: Bluetooth: avoid recursive locking in hci_send_to_channel()
Date: Thu, 21 Sep 2017 15:35:57 +0200
Mart reported a deadlock in -RT in the call path:
hci_send_monitor_ctrl_event() -> hci_send_to_channel()
because both functions acquire the same read lock hci_sk_list.lock. This
is also a mainline issue because the qrwlock implementation is writer
fair (the traditional rwlock implementation is reader biased).
To avoid the deadlock there is now __hci_send_to_channel() which expects
the readlock to be held.
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable-rt@vger.kernel.org
Fixes: 38ceaa00d02d ("Bluetooth: Add support for sending MGMT commands and events to monitor")
Reported-by: Mart van de Wege <mvdwege@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
61/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: iommu/amd: Use raw_cpu_ptr() instead of get_cpu_ptr() for ->flush_queue
Date: Tue, 5 Sep 2017 14:11:41 +0200
get_cpu_ptr() disabled preemption and returns the ->flush_queue object
of the current CPU. raw_cpu_ptr() does the same except that it not
disable preemption which means the scheduler can move it to another CPU
after it obtained the per-CPU object.
In this case this is not bad because the data structure itself is
protected with a spin_lock. This change shouldn't matter however on RT
it does because the sleeping lock can't be accessed with disabled
preemption.
Cc: stable-rt@vger.kernel.org
Cc: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org
Reported-by: Vinod Adhikary <vinadhy@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
62/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: rt/locking: allow recursive local_trylock()
Date: Thu, 21 Sep 2017 14:39:56 +0200
required for following networking patch which does recursive try-lock.
While at it, add the !RT version of it because it did not yet exist.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
63/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: don't drop the wait_lock twice
Date: Thu, 7 Sep 2017 12:38:47 +0200
Since the futex rework, __rt_mutex_start_proxy_lock() does no longer
acquire the wait_lock so it must not drop it. Otherwise the lock is not
only unlocked twice but also the preemption counter is underflown.
It is okay to remove that line because this function does not disable
interrupts nor does it acquire the ->wait_lock. The caller does this so it is
wrong do it here (after the futex rework).
Cc: stable-rt@vger.kernel.org #v4.9.18-rt14+
Reported-by: Gusenleitner Klaus <gus@keba.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
64/69 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: net: use trylock in icmp_sk
Date: Thu, 21 Sep 2017 14:42:04 +0200
The locking path can be recursive (same as for sk->sk_lock.slock) and
therefore we need a trylock version for the locallock, too.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
]
65/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.65-rt57
Date: Thu, 30 Nov 2017 19:12:26 -0500
]
66/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.66-rt58
Date: Thu, 14 Dec 2017 22:59:51 -0500
]
67/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.67-rt59
Date: Thu, 14 Dec 2017 23:00:48 -0500
]
68/69 [
Author: "Steven Rostedt (VMware)"
Email: rostedt@goodmis.org
Subject: Linux 4.9.68-rt60
Date: Thu, 14 Dec 2017 23:01:31 -0500
]
69/69 [
Author: Julia Cartwright
Email: julia@ni.com
Subject: Linux 4.9.76-rt61
Date: Mon, 15 Jan 2018 13:10:48 -0600
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
AXXIA_FAULT: Axxia Fault Handlers
GPIO_AXXIA: PrimeCell PL061 GPIO support for Axxia
EDAC_AXXIA_L3_5500: AXXIA EDAC L3 Controller for 5500
EDAC_AXXIA_L3_5600: AXXIA EDAC L3 Controller for 5600
Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@windriver.com
Subject: aufs4: refresh for build fixes
Date: Sat, 23 Dec 2017 23:56:44 -0500
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
OE uses qemumips to simulate a Malta board by default.
As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled.
For mips, the `High Memory Support' only makes sense for the 32-bit
kernel.
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Set i915 as a module to trigger the firmware load
at the same time the module is loaded.
This can avoid a timing problem between the driver starting
and it triggering a firmware load, after compile it as module
i915 driver will start after the rootfs is ready, then the
firmware store in /lib/firmware/ can be load successful by
i915 driver.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The IGB driver is showing up on some general hardware (like MinnowBoard)
which is one of the Yocto Project Reference Platforms.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The the new controllers were added several kernels back and are
required for additional functionality. These are applicable to the
4.9 kernel and newer.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
intel-common-drivers: moved the x2apic kernel feature to intel-corei7-64.scc,
because it caused configcheck warnings for intel-core2-32
Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif <syed.johan.arif.syed.mohamad.fauzi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Included features/x2apic/x2apic.scc to enable x2apic as a built-in feature.
Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif <syed.johan.arif.syed.mohamad.fauzi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Adds dependencies that were missing. In some BSPs, they were satisfied,
in others they weren't and caused warnings.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This is needed for some Broadcomm wifi drivers.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
meta-intel (intel-* MACHINEs) plans to use the backported
ixgbe ethernet modules so disable building them in the base kernel
config.
To build the in-kernel drivers, features/ixgbe/ixgbe.scc must be
added in KERNEL_FEATURES.
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
In order to build backport-iwlwifi driver (meta-intel has
the recipe) that ships its own MAC80211 and to use the crypto
drivers from the targeted kernel for it, CONFIG_CRYPTO_CCM must
be enabled.
backport-iwlwifi does have a compat implementation of crypto-ccm.c too
that would be used if CONFIG_CRYPTO_CCM is not set but that currently
fails to build (implicit function declaration).
Therefore, just enable CRYPTO_CCM. And while we're at it, enable
all crypto drivers that are needed by MAC80211.
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The skylake audio driver enables CONFIG_SDW which in turn does not
correcly select/enable its dependencies so the build fails if
CONFIG_CRC8 is not explicitly enabled.
The build failure triggers when disabling common-pc-wifi.cfg.
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
Bruce Ashfield
Bruce Ashfield
Anuj Mittal
Daniel Dragomir
Hongxu Jia
Liwei Song
Saul Wold
Jason Wessel
Syed Mohamad Fauzi, Syed Johan Arif
California Sullivan
Mikko Ylinen