On Wed, 11 Mar 2015 22:13:57 -0500
Scott Wood wrote:
> Use %pS for actual addresses, otherwise you'll get bad output
> on arches like ppc64 where %pF expects a function descriptor.
Thanks, I'll pull this into my tree. Pulling this into the 4.1 queue is
fine, right? It's not marked for stable.
Em Mon, Dec 15, 2014 at 08:20:33PM +0530, Naveen N. Rao escreveu:
> If using the symbol table, symbol addresses are not being fixed up
> properly, resulting in probes being placed at wrong addresses:
>
> # perf probe do_fork
> Added new event:
> probe:do_fork(on do_fork)
>
>
On Thu, Mar 12, 2015 at 4:24 PM, Christophe Leroy
wrote:
> Two config options exist to define powerpc MPC8xx:
> * CONFIG_PPC_8xx
> * CONFIG_8xx
> In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
> communication co-processor
>
> arch/powerpc/platforms/Kconfig.cputype has contained the
On Wed, 11 Mar 2015 23:01:30 +0100
"Rafael J. Wysocki" wrote:
> On Wednesday, March 11, 2015 05:55:09 AM Jacob Pan wrote:
> > The current driver assumes all RAPL domains within a CPU package
> > have the same energy unit. This is no longer true for HSW server
> > CPUs since DRAM domain has is
Heeft u een lening nodig voor het opstarten van een bedrijf of om te betalen uw
facturen op 3%? Wij bieden lening aan particulieren en rechtspersonen, Neem
contact met ons op met uw kredietnemer informatie. E-mail: via
jr9304...@gmail.com
Volledige Namen
Land .
Staat
Em Thu, Mar 12, 2015 at 01:53:29PM -0600, David Ahern escreveu:
> On 3/12/15 1:39 PM, Stephane Eranian wrote:
> >What the point of having all the ordered event logic if you are saying events
> >must be saved in order. I don't think there is a way to make that guarantee
> >when monitoring multiple
There isn't really a valid reason for kvm to intercept cr* reads
on svm hardware. The current kvm code just ends up returning
the register
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 41 -
1 file changed, 4 insertions(+), 37 deletions(-)
diff
match_token() expects a NULL terminator at the end of the token list so that
it would know where to stop. Not having one causes it to overrun to invalid
memory.
In practice, passing a mount option that omfs didn't recognize would sometimes
panic the system.
Signed-off-by: Sasha Levin
---
On Thu, Mar 12, 2015 at 3:53 PM, David Ahern wrote:
> On 3/12/15 1:39 PM, Stephane Eranian wrote:
>>
>> What the point of having all the ordered event logic if you are saying
>> events
>> must be saved in order. I don't think there is a way to make that
>> guarantee
>> when monitoring multiple
Jann Horn writes:
> On Wed, Mar 11, 2015 at 10:43:50PM +0100, Mikael Pettersson wrote:
> > Jann Horn writes:
> > > Or should I throw this patch away and write a patch
> > > for the prctl() manpage instead that documents that
> > > being able to call sigreturn() implies being able to
> >
On Thu, Mar 12, 2015 at 09:28:30PM +0800, Yijing Wang wrote:
> On 2015/3/12 11:36, Bjorn Helgaas wrote:
> > On Mon, Mar 09, 2015 at 10:34:18AM +0800, Yijing Wang wrote:
> >> Sometimes, we need to know the highest reserved
> >> busnr for children bus. Because parent's
> >> bus->busn_res could have
On Thu, Mar 12, 2015 at 3:17 PM, Arnaldo Carvalho de Melo
wrote:
> Em Thu, Mar 12, 2015 at 09:40:09PM +0800, Wang Nan escreveu:
>> On 2015/3/12 20:34, Jiri Olsa wrote:
>> > On Thu, Mar 12, 2015 at 07:37:02PM +0800, Wang Nan wrote:
>> >> Hi Jiri,
>> >>
>> >> Have you noticed that this patch causes
On Thu, Mar 12, 2015 at 09:03:12PM +0800, Yijing Wang wrote:
> On 2015/3/12 10:55, Bjorn Helgaas wrote:
> > On Mon, Mar 09, 2015 at 10:34:07AM +0800, Yijing Wang wrote:
> >> Introduce pci_host_bridge_list to manage pci host
> >> bridges in system, so we could detect whether
> >> the host in
On Thu, Mar 12 2015 at 13:43 -0600, Andy Gross wrote:
On Thu, Mar 12, 2015 at 01:31:50PM -0600, Lina Iyer wrote:
On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote:
>Add driver for Qualcomm Hardware Mutex block found in many Qualcomm
>SoCs.
>
>Based on initial effort by Kumar Gala
>
On Mar 12, 2015, at 1:25 PM, Mark Rutland wrote:
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+
On 3/12/15 1:39 PM, Stephane Eranian wrote:
What the point of having all the ordered event logic if you are saying events
must be saved in order. I don't think there is a way to make that guarantee
when monitoring multiple CPUs at the same time.
The record command does not analyze the events,
On Wed, Mar 11, 2015 at 10:13:43PM -0500, Scott Wood wrote:
> Use %pS for actual addresses, otherwise you'll get bad output
> on arches like ppc64 where %pF expects a function descriptor. Even on
> other architectures, refrain from setting a bad example that people
> copy.
>
> Signed-off-by:
On Thu, Mar 12, 2015 at 08:14:40PM +0800, Yijing Wang wrote:
> On 2015/3/12 9:29, Bjorn Helgaas wrote:
> > On Mon, Mar 09, 2015 at 10:34:03AM +0800, Yijing Wang wrote:
> >> Currently, we use int type for bus number in
> >> pci_create_root_bus(), pci_scan_root_bus() and
> >> pci_scan_bus_legacy.
From: Florian Westphal
Date: Sun, 8 Mar 2015 18:55:53 +0100
> David R wrote:
>
> [ CC Pablo & stable@ ]
>
>> I've just had an exception to my "uneventful kernel upgrade" monotony.
>>
>> My boot scripts failed when setting up the firewall due to this :-
>>
>> xt_recent: hitcount (1) is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/12/2015 03:30 PM, Michal Hocko wrote:
> On Thu 12-03-15 11:22:56, Eric B Munson wrote:
>> Currently, pages which are marked as unevictable are protected
>> from compaction, but not from other types of migration. The
>> mlock desctription does
Hi,
On Thu, Mar 12, 2015 at 02:04:41PM -0400, James Bottomley wrote:
> On Thu, 2015-03-12 at 11:14 -0500, Scott Wood wrote:
> > On Thu, 2015-03-12 at 08:11 -0400, James Bottomley wrote:
> > > On Wed, 2015-03-11 at 22:13 -0500, Scott Wood wrote:
> > > > Use %pS for actual addresses, otherwise
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: a57594a13a446d1a6ab1dcd48339f799ce586843
Add a separate local variable for the boost/deboost logic to make the
code more readable. Add comments
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 2ffa5a5cd2fe792b6399c903d5172adf088d8ff7
There is no point to keep the task ref across the check for lock
owner. Drop the ref before that, so the
On Thu, Mar 12, 2015 at 01:31:50PM -0600, Lina Iyer wrote:
> On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote:
> >Add driver for Qualcomm Hardware Mutex block found in many Qualcomm
> >SoCs.
> >
> >Based on initial effort by Kumar Gala
> >
> >Signed-off-by: Bjorn Andersson
> >---
> >
>
On 03/12/15 10:20, Sebastian Andrzej Siewior wrote:
> On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote:
>> diff =
>> --- arch/arm/mach-imx/mach-imx6q.c
>> +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c
>> @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void)
>> * set bit
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Gustavo Bittencourt
The functions ww_mutex_lock_interruptible and ww_mutex_lock should return
-EDEADLK when faced with
a deadlock. To do so, the paramenter detect_deadlock in
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path is to access this lock is always under a
raw_spin_lock, for
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: ccf9e6a80d9e1b9df69c98e6b9745cf49869ee15
The kernel tries to atomically unlock the futex without checking
whether there is kernel state associated
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 1ca7b86062ec8473d03c5cdfd336abc8b1c8098c
Exit right away, when the removed waiter was not the top priority
waiter on the lock. Get rid of the extra
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 8930ed80f970a90a795239e7415c9b0e6f964649
The conditions under which deadlock detection is conducted are unclear
and undocumented.
Add constants
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Brad Mouring
In task_blocks_on_lock, there's a null check on pi_blocked_on
of the task_struct. This pointer can encode the fact that the
task that contains the pointer is waking
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: c051b21f71d1ffdfd7ad406a1ef5ede5e5f974c5
The deadlock logic is only required for futexes.
Remove the extra arguments for the public functions and
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: e60cbc5ceaa518d630ab8f35a7d05cee1c752648
We want to be a bit more clever in futex_lock_pi_atomic() and separate
the possible states. Split out the
On Thu, Mar 12, 2015 at 3:34 PM, David Ahern wrote:
> On 3/12/15 1:23 PM, Stephane Eranian wrote:
>>>
>>> Rounds and flushing after them helps with the user experience -- at least
>>> for some commands. On systems with 1024 cpus perf data files get large
>>> quickly and the resulting analysis
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 3eb65aeadf701976b084e9171e16bb7d1e83fbb0
Add commentry to document the chain walk and the protection mechanisms
and their scope.
Signed-off-by:
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: af54d6a1c3ad474bbc9893c9905022646be6092c
futex_lock_pi_atomic() is a maze of retry hoops and loops.
Reduce it to simple and understandable states:
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 67792e2cabadbadd1a93f6790fa7bcbd47eca7c3
In case the dead lock detector is enabled we follow the lock chain to
the end in
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream-commit: 88f2b4c15e561bb5c28709d666364f273bf54b98
Oleg noticed that rtmutex_slowtrylock() has a pointless check for
rt_mutex_owner(lock) != current.
To
Please kindly read my message
Hello
it is with tears that i am writing to you i need your help and
assistance am an aging widow suffering from long time cancer of the
throat and I inherited from my late husband, the sum of 9. 5 Millions
Nine Million Five Hundred Thousand Dollars and I
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 358c331f391f3e0432f4f96f25017d12ac8d10b1
The current implementation of try_to_take_rtmutex() is correct, but
requires more than a single brain
---
drivers/hwspinlock/qcom_hwspinlock.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c
b/drivers/hwspinlock/qcom_hwspinlock.c
index 93b62e0..7642524 100644
--- a/drivers/hwspinlock/qcom_hwspinlock.c
+++
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
With task_blocks_on_rt_mutex() returning early -EDEADLK we never add the
waiter to the waitqueue. Later, we try to remove it via remove_waiter()
and go
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 2ffa5a5cd2fe792b6399c903d5172adf088d8ff7
There is no point to keep the task ref across the check for lock
owner. Drop the ref before that, so the
On Thu, Mar 12, 2015 at 07:42:25PM +0800, Yijing Wang wrote:
> >> -static struct resource busn_resource = {
> >> +struct resource busn_resource = {
> >>.name = "PCI busn",
> >>.start = 0,
> >>.end= 255,
> >>.flags = IORESOURCE_BUS,
> >> };
> >>
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
With task_blocks_on_rt_mutex() returning early -EDEADLK we never add the
waiter to the waitqueue. Later, we try to remove it via remove_waiter()
and go
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Steven Rostedt
To ease backporting patches, replace the plist functions with
rt_mutex_enqueue{_pi}() and rt_mutex_dequeue{_pi}() like upstream -rt does.
This will lower the
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 67792e2cabadbadd1a93f6790fa7bcbd47eca7c3
In case the dead lock detector is enabled we follow the lock chain to
the end in
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: c051b21f71d1ffdfd7ad406a1ef5ede5e5f974c5
The deadlock logic is only required for futexes.
Remove the extra arguments for the public functions and
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: af54d6a1c3ad474bbc9893c9905022646be6092c
futex_lock_pi_atomic() is a maze of retry hoops and loops.
Reduce it to simple and understandable states:
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 04e1b2e52b17195c9a1daa5935c55a4c8716095c
We want to be a bit more clever in futex_lock_pi_atomic() and separate
the possible states. Split out the
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: a57594a13a446d1a6ab1dcd48339f799ce586843
Add a separate local variable for the boost/deboost logic to make the
code more readable. Add comments
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 358c331f391f3e0432f4f96f25017d12ac8d10b1
The current implementation of try_to_take_rtmutex() is correct, but
requires more than a single brain
On Thu, Mar 12, 2015 at 07:46:45PM +0800, Yijing Wang wrote:
> >>struct pci_bus *b;
> >> + LIST_HEAD(resources);
> >>struct pcifront_sd *sd = NULL;
> >>struct pci_bus_entry *bus_entry = NULL;
> >>int err = 0;
> >> @@ -470,17 +472,21 @@ static int pcifront_scan_root(struct
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 1ca7b86062ec8473d03c5cdfd336abc8b1c8098c
Exit right away, when the removed waiter was not the top priority
waiter on the lock. Get rid of the extra
On Thu, Mar 12, 2015 at 6:15 AM, Lu Baolu wrote:
> When a device with an isochronous endpoint is plugged into the Intel
> xHCI host controller, and the driver submits multiple frames per URB,
> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
> but the last TD for the URB.
Geert Uytterhoeven writes:
> On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki
> wrote:
>> More CCes.
>>
>> On Wednesday, March 11, 2015 08:27:28 AM Eric Anholt wrote:
>>> If we've declared a power domain in the OF, and the OF node is found
>>> but the requested domain hasn't been registered
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: ccf9e6a80d9e1b9df69c98e6b9745cf49869ee15
The kernel tries to atomically unlock the futex without checking
whether there is kernel state associated
On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote:
Add driver for Qualcomm Hardware Mutex block found in many Qualcomm
SoCs.
Based on initial effort by Kumar Gala
Signed-off-by: Bjorn Andersson
---
[...]
+#include "hwspinlock_internal.h"
+
+#define QCOM_MUTEX_APPS_PROC_ID
Hi Marc,
On Wed, Mar 11, 2015 at 10:43:07PM +0100, Marc Kleine-Budde wrote:
> On 03/11/2015 06:37 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish
> >
> > A number of tx queue wake-up events went missing due to the
> > outlined scenario below. Start state is a pool of 16 tx URBs,
> >
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: e60cbc5ceaa518d630ab8f35a7d05cee1c752648
We want to be a bit more clever in futex_lock_pi_atomic() and separate
the possible states. Split out the
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 3eb65aeadf701976b084e9171e16bb7d1e83fbb0
Add commentry to document the chain walk and the protection mechanisms
and their scope.
Signed-off-by:
On 3/12/15 1:23 PM, Stephane Eranian wrote:
Rounds and flushing after them helps with the user experience -- at least
for some commands. On systems with 1024 cpus perf data files get large
quickly and the resulting analysis command can appear to hang for long
periods (e.g., i have done 1 second
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
Using mutex_acquire_nest() as used in __ww_mutex_lock() fixes the
splat below. Remove superfluous line break in __ww_mutex_lock()
as well.
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Gustavo Bittencourt
The functions ww_mutex_lock_interruptible and ww_mutex_lock should return
-EDEADLK when faced with
a deadlock. To do so, the paramenter detect_deadlock in
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: 8930ed80f970a90a795239e7415c9b0e6f964649
The conditions under which deadlock detection is conducted are unclear
and undocumented.
Add constants
From: Christophe Leroy
Date: Thu, 12 Mar 2015 16:24:09 +0100 (CET)
> Two config options exist to define powerpc MPC8xx:
> * CONFIG_PPC_8xx
> * CONFIG_8xx
> In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
> communication co-processor
>
> arch/powerpc/platforms/Kconfig.cputype has
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream commit: bd1dbcc67cd2c1181e2c01daac51eabf1b964dd8
No point in open coding the same function again.
Signed-off-by: Thomas Gleixner
Reviewed-by: Darren Hart
From: Christophe Leroy
Date: Thu, 12 Mar 2015 16:23:54 +0100 (CET)
> Two config options exist to define powerpc MPC8xx:
> * CONFIG_PPC_8xx
> * CONFIG_8xx
> In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
> communication co-processor
>
> arch/powerpc/platforms/Kconfig.cputype has
On Thu 12-03-15 11:22:56, Eric B Munson wrote:
> Currently, pages which are marked as unevictable are protected from
> compaction, but not from other types of migration. The mlock
> desctription does not promise that all page faults will be avoided, only
> major ones so this protection is not
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
The ARM UP implementation of futex_atomic_cmpxchg_inatomic() assumes that
pagefault_disable() inherits a preempt disabled section. This assumtion
is true
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
Shrug. Lots of hobbyists have a beast in their basement, right?
Cc: stable...@vger.kernel.org
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Paul Gortmaker
On 3.14-rt we see the following trace on Canoe Pass for
SCSI_ISCI "Intel(R) C600 Series Chipset SAS Controller"
when the sas qc_issue handler is run:
BUG: sleeping
On Thu, Mar 12, 2015 at 03:16:56PM -0400, Steven Rostedt wrote:
My most productive RT patch ever!
(that's what I get for kicking off my script in the wrong directory)
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, 12 Mar 2015 18:54:42 +0300 Andrew Vagin wrote:
> v2: use seq_has_overflowed() properly
--- a/fs/proc/fd.c~proc-show-locks-in-proc-pid-fdinfo-x-v2
+++ a/fs/proc/fd.c
@@ -57,17 +57,15 @@ static int seq_show(struct seq_file *m,
real_mount(file->f_path.mnt)->mnt_id);
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
|BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:915
|in_atomic(): 1, irqs_disabled(): 0, pid: 3194, name: rpc.nfsd
|Preemption
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Daniel Wagner
Provides a framework for enqueuing callbacks from irq context
PREEMPT_RT_FULL safe. The callbacks are executed in kthread context.
Bases on wait-simple.
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
|BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:768
|in_atomic(): 1, irqs_disabled(): 0, pid: 26, name: rcuos/2
|2 locks
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
Both pi_stress and sigwaittest in rt-test show performance gain with
__HAVE_ARCH_CMPXCHG. Testing result on coretile_express_a9x4:
pi_stress -p 99 --duration=300 (on linux-3.4-rc5; bigger
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
mm, memcg: make refill_stock() use get_cpu_light()
Nikita reported the following memcg scheduling while atomic bug:
Call Trace:
[e22d5a90] [c0007ea8]
On Thu, 2015-03-12 at 09:56 -0700, John Stultz wrote:
> While I've been interested in the generic sched_clock work since
> it uses the clocksource infrastructure, Stephen has really done
> all the heavy lifting so far.
>
> So while I've been queuing and pushing changes through Thomas/Ingo,
> I'm
On 03/11/2015 06:39 PM, John Stultz wrote:
> I've hosted my timekeeping tests on github for the last few years:
> https://github.com/johnstultz-work/timetests
>
> but I suspect not too many folks have actually used them.
>
> I've been meaning to get them reworked and submitted into the
>
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
If the caller already holds the mutex, task_blocks_on_rt_mutex()
returns -EDEADLK, we proceed directly to rt_mutex_handle_deadlock()
where it's instant game over.
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Paul E. McKenney"
upstream commit: fff421580f512fc044cc7421fdff31a7a6997350
Currently, the tvec_base structure's ->active_timers field tracks only
the non-deferrable timers, which
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Daniel Wagner
Provides a framework for enqueuing callbacks from irq context
PREEMPT_RT_FULL safe. The callbacks are executed in kthread context.
Bases on wait-simple.
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Paul E. McKenney"
upstream commit: 18d8cb64c9c074cbe2bd677ab10fff8283abdb62
The __run_timers() function currently steps through the list one jiffy at
a time in order to update the
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
Shrug. Lots of hobbyists have a beast in their basement, right?
Cc: stable...@vger.kernel.org
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Daniel Wagner
On RT the spin lock in pkg_temp_thermal_platfrom_thermal_notify will
call schedule while we run in irq context.
[] dump_stack+0x4e/0x8f
[] __schedule_bug+0xa6/0xb4
[]
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Mike Galbraith
mm, memcg: make refill_stock() use get_cpu_light()
Nikita reported the following memcg scheduling while atomic bug:
Call Trace:
[e22d5a90] [c0007ea8]
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
This behaviour is required by cpufreq and its logic is "okay": It does a
read_lock followed by a try_read_lock.
Lockdep warns if one try a read_lock twice
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
This patch converts gpio_bank.lock from a spin_lock into a
raw_spin_lock. The call path is to access this lock is always under a
raw_spin_lock, for
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Josh Cartwright
"lockdep: Selftest: Only do hardirq context test for raw spinlock"
disabled the execution of certain tests with PREEMPT_RT_FULL, but did
not prevent the tests from
On Thu, Mar 12, 2015 at 3:13 PM, David Ahern wrote:
> On 3/12/15 1:05 PM, Stephane Eranian wrote:
>>
>> On Thu, Mar 12, 2015 at 5:02 AM, Adrian Hunter
>> wrote:
>>>
>>> On 12/03/15 05:32, Stephane Eranian wrote:
Hi,
I am working on the JIT support to improve the flow and have
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
upstream-commit: 88f2b4c15e561bb5c28709d666364f273bf54b98
Oleg noticed that rtmutex_slowtrylock() has a pointless check for
rt_mutex_owner(lock) != current.
To
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
Both pi_stress and sigwaittest in rt-test show performance gain with
__HAVE_ARCH_CMPXCHG. Testing result on coretile_express_a9x4:
pi_stress -p 99 --duration=300 (on linux-3.4-rc5; bigger
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Paul E. McKenney"
upstream commit: d550e81dc0ddc04f1b417c179c214103a28e0ee8
The __run_timers() function currently steps through the list one jiffy at
a time in order to update the
3.14.34-rt32-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Paul Gortmaker
On 3.14-rt we see the following trace on Canoe Pass for
SCSI_ISCI "Intel(R) C600 Series Chipset SAS Controller"
when the sas qc_issue handler is run:
BUG: sleeping
3.12.38-rt53-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Paul E. McKenney"
upstream commit: 16d937f880312e3f47157d4d6d6ebf7e61523378
The __run_timers() function currently steps through the list one jiffy at
a time in order to update the
On Thu, Mar 12, 2015 at 12:55:13PM +0100, Petr Mladek wrote:
> There is a notifier that handles live patches for coming and going modules.
> It takes klp_mutex lock to avoid races with coming and going patches but
> it does not keep the lock all the time. Therefore the following races are
>
Dear RT Folks,
This is the RT stable review cycle of patch 3.12.38-rt53-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
301 - 400 of 2176 matches
Mail list logo
